docs/test: align scheduling cleanup

docs/current_roadmap.md

@@ -152,11 +152,12 @@ The active sequence can assume these foundations:
   runs through the API
 
 The active sequence can also assume deployment scheduling: an opt-in
-same-server scheduler starts ordinary deployment runs without a connected
-client (one-shot and recurring cron, durable admission, coalesced
-missed-start recovery, bounded parallel runs, occurrence inspection, and
-API/Python-client administration). Scheduling is disabled by default and
-enabled per server. The current contract is
+same-server scheduler for local/static servers only starts ordinary deployment
+runs without a connected client (one-shot and recurring cron, durable
+admission, coalesced missed-start recovery, bounded parallel runs, occurrence
+inspection, and API/Python-client administration). Scheduling is disabled by
+default and enabled per server; MCP-backed servers reject scheduler
+enablement. The current contract is
 [`deployment scheduling`](superpowers/specs/2026-09-08-deployment-scheduling-design.md);
 operator usage is under
 [`deployment scheduling operations`](deployment_scheduling.md).

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.

docs/wf_api_architecture.md

@@ -20,7 +20,7 @@ frontends can share.
 | `wf_sources_mcp` | MCP-as-upstream-source implementation: source ids, source registry DTOs, auth/catalog stores, discovery, SDK client/facade, persistent runtime pool, and tool-wrapper helpers. |
 | `wf_mcp` | MCP frontend/compatibility package: old `wf-mcp` server entry points, broker glue around MCP-hosted services, proxy/admin tools, and compatibility shims while callers migrate. |
 | `wf_transport_rpc_http` | JSON-RPC-over-HTTP transport adapter and remote client over `WorkflowApiSurface`, not a reimplementation of workflow business logic. |
-| `wf_client` | Async Python consumer facade over a narrow capability/artifact/deployment/run port. It reconstructs immutable snapshots and keeps representations bounded and inert. |
+| `wf_client` | Async Python consumer facade over a narrow capability/artifact/deployment/run/schedule port. It reconstructs immutable snapshots and keeps representations bounded and inert. |
 | future `wf_http` / WebSocket / MCP server transports | Additional transports over `WorkflowApiSurface`, not new workflow application APIs. |
 | `wf_cli` | CLI frontend over `WorkflowApiSurface`; it may run locally against process-local stores or target a remote JSON-RPC backend. |