docs/test: align scheduling cleanup

docs/superpowers/specs/2026-09-08-deployment-scheduling-design.md

@@ -56,8 +56,8 @@ Cron uses an explicit IANA time zone, default UTC. One-shot timestamps must
 include an offset. Persist occurrence instants as UTC timestamps; retain the
 cron time-zone name in the definition. Reject invalid zones and naive times.
 
-Proposed default lateness allowance: 60 seconds, configurable per schedule as
-a non-negative finite duration. During uninterrupted operation, a due instant
+Default lateness allowance: 60 seconds, configurable per schedule as a
+non-negative finite duration. During uninterrupted operation, a due instant
 within the allowance can be admitted. Older instants and enabled times missed
 while the server was unavailable follow the configured misfire policy.
 With `skip`, startup selects the next future instant regardless of lateness
@@ -178,12 +178,20 @@ are invalid here. Do not extend GraphSourcePath with schedule-only roots.
 Existing expressions compose data; they do not implement date formatting,
 arithmetic, template evaluation, Python execution, or arbitrary transforms.
 
-Proposed persisted binding example, pending concrete model names:
+The persisted `Schedule.input_bindings` field is a list of
+`ScheduleInputBinding` objects. Each binding has a `target: LocalPath` and a
+discriminated `ScheduleExpression`, whose concrete models are
+`LiteralExpression`, `OccurrenceExpression`, `ScheduleArrayExpression`, and
+`ScheduleObjectExpression`. The API accepts and returns these bindings as
+JSON through `Schedule.model_dump(mode="json")`; for example:
 
 ```json
 {
   "input_bindings": [
-    {"target": "team", "value": "engineering"},
+    {
+      "target": "team",
+      "expression": {"kind": "literal", "value": "engineering"}
+    },
     {
       "target": "report_time",
       "expression": {"kind": "occurrence", "field": "scheduled_at"}
@@ -192,9 +200,11 @@ Proposed persisted binding example, pending concrete model names:
 }
 ```
 
-Occurrence references initially expose schedule_id, occurrence_id, and
-scheduled_at. Date-time values serialize as UTC RFC 3339 strings. The admitted
-run's resolved input is persisted once and never re-evaluated on restart.
+`OccurrenceExpression` exposes `schedule_id`, `occurrence_id`, and
+`scheduled_at` from the admitted occurrence. `scheduled_at` is serialized as
+a UTC RFC 3339 string; the other occurrence fields are strings as well. The
+admitted run's resolved input is persisted once and never re-evaluated on
+restart.
 Validate target conflicts, expression bounds, source fields, and the resulting
 workflow input schema. Recheck the current deployment contract at admission;
 an edit may have changed the expected input since schedule creation.
@@ -211,7 +221,9 @@ values through their declared input bindings as before.
 
 ## Durable admission and recovery
 
-Current seams needing change:
+### Historical pre-implementation seams
+
+Before T01–T14 were implemented, these were the seams that required change:
 
 - wf_api/runs.py executes before persisting a stopped run.
 - wf_artifacts/runs/models.py permits only stopped summaries, with a required
@@ -281,8 +293,10 @@ schedules at `<root>/schedules`, one lock at `<root>/scheduler.lock`).
 ## Lifecycle, administration, and resource bounds
 
 Expose create/get/list/update/pause/resume/delete and paginated occurrence
-inspection through the workflow API and Python client. Public client names
-are finalized in the implementation plan, not treated as existing methods.
+inspection through the workflow API and Python client. The implemented names
+are `create_schedule`, `get_schedule`, `list_schedules`, `update_schedule`,
+`pause_schedule`, `resume_schedule`, `delete_schedule`, and
+`list_schedule_occurrences`.
 Reject stale schedule edits using revisions within the owning process.
 
 Occurrence inspection distinguishes pending, coalesced/superseded,
@@ -397,11 +411,14 @@ Use injected clocks and controlled executors, not real-time sleeps:
 - Public API/client round trips, pagination, inspection without a checkpoint,
   and existing manual run/resume behavior remain valid.
 
-## Review before implementation planning
+## Verification and operations guidance
 
-User policy decisions above are settled. Review the proposed 60-second
-allowance, expression seam, and admission/recovery representation together.
-The calendar-library probe is an explicit gate, not a claimed passing test.
-After approval, create a sequenced implementation plan with fault-injection
-tests before enabling scheduling in the server. WaitNode is a later contract
-that may reuse timed admission but must persist its own suspended execution.
+The implementation plan is archived as historical context; no further
+design-approval or implementation-planning step remains for this slice. When
+changing the calendar dependency or adapter, rerun the calendar-library probe
+and retain the calendar boundary coverage above. Keep fault-injection tests at
+each persistence boundary, including resume, when changing admission or
+recovery before enabling a changed scheduler build. Use the deployment
+scheduling operations guide for local/static server configuration and runtime
+operations. WaitNode is a later contract that may reuse timed admission but
+must persist its own suspended execution.