chore: tighten scheduling review coverage

docs/thesis/generate.ps1

@@ -93,7 +93,7 @@ if (-not (Test-Path $include_markdown_filter)) {
 }
 
 $agent_results = Join-Path $PSScriptRoot "agent-challenge-results.md"
-if ((Test-RenderNeedsAgentResults $RemainingArgs) -and -not (Test-Path $agent_results)) {
+if ((Test-RenderNeedsAgentResults (@($InputFile) + $RemainingArgs)) -and -not (Test-Path $agent_results)) {
     Write-Error "agent-challenge-results.md is missing. Run generate_agent_challenge_evaluation.py first."
     exit 1
 }

docs/thesis/system-design-implementation.md

@@ -1433,7 +1433,9 @@ would still need to preserve the lifecycle's transaction and ownership
 contracts; changing the storage engine alone would not prove those
 properties.
 
-Scheduled deployment execution is not implemented. Nor does exposing a
+Scheduled deployment execution is implemented within the documented first
+slice. It remains bounded by the filesystem-backed, single-process store and
+the explicitly enabled local/static server composition. Nor does exposing a
 provider's callable operations imply that its interactive widgets or entire
 user experience are reproduced through the workflow API.
 
@@ -1501,11 +1503,11 @@ and data-binding model are understandable without implementation knowledge.
 
 ## Scheduling and the Surrounding Application
 
-Scheduled deployment execution is a required product direction, not an
-implemented capability. It introduces trigger identity, overlap policy,
-and recovery decisions in addition to time-expression parsing. It should
-build on the same run lifecycle rather than create a separate execution
-model. Suspending an already-running workflow until a time or event is a
+Scheduled deployment execution is implemented for the current slice. It
+introduces trigger identity, overlap policy, and recovery decisions in
+addition to time-expression parsing, and builds on the same run lifecycle
+rather than creating a separate execution model. Extending it to distributed
+workers or suspending an already-running workflow until a time or event is a
 related but distinct design question; a wait node is not specified here.
 
 The surrounding application is intended to combine assistant-backed chat

docs/wf_cli.md

@@ -117,7 +117,8 @@ wf-rpc-server --store-root .wf_store --enable-scheduler
 ```
 
 or set `server.scheduler.enabled` (plus optional `poll_interval_s`,
-`max_concurrent_runs`, `drain_grace_s`) in the neutral config. See
+`max_concurrent_runs`, `drain_grace_s`) in a local/static neutral config.
+MCP-backed servers reject this setting. See
 [`deployment scheduling operations`](deployment_scheduling.md).
 
 `admin registry` shows desired persisted source entries. It is separate from