workflow(meta): key delivery on agent context; retire checkpoint-at-entry (#353 corpus)

[m2ux]

Corpus half of #353 (§2.1, §2.2). Merge this first — the server PR (#356, fix/353-dispatch-overhead → main) carries §2.3's pointer bump, so the relaxed rule reaches the server only through that gitlink and never goes live without the context-scoped ledger underneath it.

§2.1 — delivery keyed on agent context

workers-need-full-delivery was not the defect; the ledger was. It read state.deliveredContent[state.agentId], and a dispatched worker authenticates against the orchestrator's session_index — so every worker of a session shared one ledger, and reference delivery on a worker session would have handed worker B unchanged-markers for content worker A received. The rule was a correct guard over a ledger that could not tell contexts apart. The server PR scopes that ledger on a per-call agent_id, so the rule can now key on the question that matters: is this the same agent context?

Surface	Change
workflow-engine::TECHNIQUE.md	new agent-id-scopes-delivery — the authoritative statement: pass agent_id on the three delivery calls; a fresh id takes full delivery, the same id resumed may pass bundle: "reference"
workflow-engine::dispatch-activity	workers-need-full-delivery → delivery-keys-on-agent-context, rewritten to the orchestrator-side duty: mint per dispatch, reuse on resume, keep context_mode: "persistent" off worker sessions
workflow-engine::activity-worker	agent-id-on-delivery-calls, mirroring the existing session-index-on-each-call shape
workflow-engine::compose-prompt	the worker's entry instruction becomes get_activity { session_index, context_tokens, agent_id }
harness-compat::continue-agent	resume-preserves-delivery-scope — the resume re-binds the workflow-server worker agent_id, called out as distinct from the harness {agent_id} this op resumes

agent_id is not a new designator: activity-worker already declares it ("Worker agent identity for this dispatch"), compose-prompt already requires it in {substitutions}, and dispatch-activity already binds it into the stub. It simply never reached the wire. force-full-after-summarization stays the escape and is cited, not restated at both call sites.

Rule renamed rather than left contradicting its body; all four citation sites updated (TECHNIQUE.md#dispatch-topology, workflow-orchestrator, create-session, and the definition). check:anchors proves they resolve.

§2.2 — no activity opens with a checkpoint

The issue named 11-validate. The new guard found four. Each relocation keeps the checkpoint atomic (no combining — atomic-checkpoints) and preserves reachability exactly:

Workflow	Checkpoint	Moved to	Why there
work-package	local-validation-permission	10-post-impl-review tail, gated has_critical_blocker != true	validate's only predecessor; the gate is the exact complement of the blocker branch, so producer and readers stay exhaustive (unproduced-value-read)
prism-evaluate	confirm-apply	05-resolution-dialogue tail	after compile-plan produces the plan the confirmation is about
work-packages	analysis-type-selection	02-folder-setup, before folder-created	folder-created's options carry the routing effects, so it stays the activity's last step
workflow-design	design-context	after set-design-dimensions, same activity	see below

Why design-context moves within its activity rather than to the predecessor's tail: requirements-refinement is reachable on more than one transition condition from 01-intake-and-context, so relocating would have required duplicating those conditions at the predecessor — a state shadow for no gain. It is non-blocking with a defaultOption and autoAdvanceMs, so it forces no resume where it now sits; moving it off step 0 satisfies the guard and keeps its operation_type != update gate untouched.

One subtlety worth review attention. local-validation-permission used to set both run_local_validation and mark_progress_na. mark_progress_na is consumed by commit-and-persist at the completing activity and then reset — so setting it in post-impl-review would have marked that activity cancelled/N/A instead of validate. The relocated checkpoint therefore sets run_local_validation only, and 11-validate derives the flag itself in a first kind: action step gated when: run_local_validation == false. Same observable Progress behaviour, correct owner.

Restatement sweep

stale-restatement-after-change applies to a relocation. Swept and updated in this commit: activity and root READMEs for all four workflows, including the mermaid flows that drew the moved gates (work-package/activities/README.md validate + post-impl-review diagrams, prism-evaluate 05/06 sections and root flow + roster, work-packages folder-setup/analysis diagrams, workflow-design/activities/README.md ordering clause).

Verification

• npm run check:all — 18/18 guards pass, including the new checkpoint-entry guard, resource-anchors (the renamed rule's citations), variable-model (the relocated setVariable effects), and review-mode-gating.
• Full server suite green against this corpus, with the walk re-baselined in the server PR. The snapshot delta is the relocation and nothing else.

🤖 Generated with Claude Code