Document adversarial implementation workflow WIP

[taras]

Why

We need a concrete, inspectable version of the planner–implementor–human-decider workflow before automating it. The workflow must keep final decisions with the user, make agent handoffs explicit, and move workspace and pull-request effects out of probabilistic agent behavior.

What changes

Before:

The agent vision described composable agents, but it did not show the complete adversarial implementation loop or the environmental data passed between its stages.

After:

The repository contains a conceptual workflow specification and an executable-Markdown-shaped sketch of the full loop. Supporting documents expand the planner handoff, plan convergence, user involvement gate, implementation review, runtime lifecycle, deterministic artifacts, and currently missing primitives.

Stage boundaries are structured, not prose. InstructionFiles and Discovery are text components. UserCheckpoint, Planning, and Implementation declare returns: each resolves a user decision that its caller has to gate on, and a caller cannot branch on rendered prose. Planning and Implementation return their prose, the parsed verdict fields, and the complete UserDecision they resolved — the sources, with nothing derived from them. start.md computes each gate where it uses it:

planning.decision.proceed && planning.verdictPassed
implementation.decision.proceed && implementation.verdictPassed

A precomputed authorized field would be a second copy of that answer, and no return schema can require the copy to agree with its sources, so a record pairing a declining decision with an approving flag would validate. The same two fields tell a decline (proceed false) from a review that reached its bound still failing (proceed true, verdictPassed false); neither advances, and the eventual policy for the second stays unresolved under #290.

Neither stage returns the pull-request handle, but Implementation consumes it in full. <PullRequest> (#295) resolves number, URL, head and base identities, state, reviews, comments, and checks. runtime.md denies agent network access, so whatever the prompt does not render is invisible to the review — the stage therefore renders every category (reviews with their bodies, comments, checks) explicitly, each collection iterated with <Each> and never stringified, into both the planner prompt and the checkpoint material the user reads. The two surfaces carry the same consequential content: a user approving the change reads the original objections, not the planner's summary of them. The checkpoint omits only a check's link, and carries two things the review prompt has no reason to — the focused revision prompt an approval sends to the implementor, and each finding's evidence, since a defer disposition turns that finding into a durable issue. proceed: true authorizes the exact effects presented for assessment, which only means something if the material shows them. The prompt names the revision under review: the diff at headSha against baseSha, with a verdict describing that head alone, so a moved head requires a fresh review.

The member field names within reviews, comments, and checks are #295's to settle; this document depends on that schema rather than defining a competing one. What is settled here is that the planner receives the complete snapshot.

The handle stays internal because start.md gates on the verdict and decision rather than on pull-request state, and the artifact ledger (#291) records the effect independently. A return field typed string would let a conforming <PullRequest> perform its durable effects and only then fail the stage's return validation.

How it works

user discovery → planner handoff → user gate → plan convergence → reviewable PR chain → implementation review → user decision

The workflow works outside in: it first establishes observable, independently reviewable boundaries, then implements smaller PRs within those boundaries. Review findings that would derail the active chain become explicit follow-up issues when deferral is safe.

Review guide

Start with: workflows/adversarial-implementation/start.md

Then review:

1. specs/adversarial-implementation-workflow.md for the behavioral contract and role boundaries.
2. workflows/adversarial-implementation/Discovery.md, Planning.md, and UserCheckpoint.md for the planning loop and the user gate.
3. workflows/adversarial-implementation/Implementation.md for PR-chain review and follow-up issue handling.
4. workflows/adversarial-implementation/InstructionFiles.md for instruction materialization.
5. workflows/adversarial-implementation/primitives.md, artifacts.md, and runtime.md for shipped syntax, missing capabilities, and lifecycle rules.
6. specs/markdown-agents-vision.md for workflow-owned artifacts and the later xmd play direction.

Look carefully at:

• whether the user remains the final authority at every material transition, including decisions a stage resolves internally and returns;
• whether any durable effect can execute before the approval that authorizes it;
• whether the pull-request reviewer can see everything it must judge, given that it has no network access;
• whether data dependencies are explicit enough to implement deterministically;
• whether proposed cleanup and recovery behavior follows structured concurrency;
• whether every claim about shipped behavior matches current main, and whether every unshipped capability is marked as such;
• where the target depends on unresolved runtime work, particularly issues Bind projected content resources to the component invocation scope #203, Implement retained Workflow Workspace restoration #218, Contain filesystem access at the provider boundary #227, and Reject secrets before journal persistence by default #199.

What must stay true

• The planner and implementor are equally capable analysts with different responsibilities: the planner proposes a theory of implementation and the implementor validates it.
• Material product, architecture, scope, and risk decisions remain with the user.
• Large changes are split into observable, independently validatable PRs.
• Deferred review findings remain visible and addressable without silently expanding the active PR chain.
• Workflow-owned resources clean up with their execution unless explicitly retained or recovery requires preservation.

How to verify it

• Read the overview and follow each referenced component to confirm that every stage names its props and outputs.
• inspectDocument parses every frontmatter block and compiles its declared prop and return schemas through current main; compileParseSchema compiles every embedded draft-07 schema; inspectComponent confirms each name resolves to what the target claims it does.
• Executable discrimination over the shipped subset, using the real Planning, Implementation, and UserCheckpoint and stubbing only the agent transport and the three deterministic components that do not exist: a declined plan review reaches no authorization question and no implementation effect; a declined pull-request review creates no deferred issue and reaches no acceptance question; a failed verdict with approval performs the revision turn and reaches the next stage only after a later passing verdict; an exhausted loop reaches neither. Moving <Issue> ahead of its approval, bypassing a caller gate, or reducing either structured return to text each changes an observed result.
• git diff --check origin/main...HEAD verifies that the diff contains no whitespace errors.
• The workflow still does not run end to end, because the workflow-owned components listed under Risks are not implemented.

Scope

Included

• Adversarial implementation workflow contract.
• Full-loop workflow sketch and focused component documents.
• Deterministic artifact and structured-concurrency lifecycle model.
• xmd play as a later layer built on the automated implementation loop.

Intentionally unchanged

• Runtime and CLI behavior.
• Implementation of the proposed primitives.
• Separate root-document input/props work currently present in the local worktree.

New abstractions

• <Worktree>, <File>, <PullRequest>, and <Issue> describe deterministic environmental effects needed by multiple workflow stages.
• <Elicit>, schema parsing, and conditional control flow have all shipped; the target now describes their settled contracts rather than proposing them.
• Each remaining proposed abstraction is validated against an executable implementation.
• No runtime functionality is claimed by this documentation-only WIP.

Risks and limitations

• This is a living end-goal target, not a runnable workflow: <Workflow>, <Stage>, <Worktree>, <Sandbox>, <Commit>, <PullRequest>, and <Issue> do not exist, and neither does sidecar run history or cross-process stage resumption.
• The document logic in InstructionFiles, Discovery, Planning, and UserCheckpoint is written entirely in shipped syntax. The gating behavior is exercised here against the real documents; proving the loop end to end against real agents is Prove the shipped adversarial-planning document logic #290.
• Gating is expressed by nesting, which prevents the remaining stages from running. It is not stopping: the run still expands to <Output> and completes, with no clean halt at a stage boundary and no recorded stop reason. That is Add Stage execution and cross-process manual continuation #298 over Add contextual workflow runs with pinned commits #289.
• <Content /> does not substitute inside a <Prompt> (<Content /> is not substituted when nested inside another element in a component body #328), so Discovery and UserCheckpoint take their material as a prop. An outer <PrintErrors> does not print an output decision (An outer <PrintErrors> does not print a failure an <Output> region decided #327); architecture.md remains authoritative and the target describes the contract, not the current behavior.
• The individual component documents are intentionally more detailed than the overview and need iterative simplification as the runtime becomes capable of executing them.

Scope confirmation

• Every changed file supports the purpose described above.
• Unrelated root-input and local agent-worktree changes are excluded.
• No generated or mechanical changes are included.
• The description matches the current diff and validation results.

[github-actions]

PR #181: Document adversarial implementation workflow WIP

11 files, +2787 / -0

Scope

🔴 PR has 2787 lines changed. Split into focused PRs.

🟡 2787 lines changed. PRs under 400 receive more thorough review.

Structural

✅ No structural bloat detected.

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.

[taras]

End-goal implementation audit — 2026-08-02

Reviewed PR head 28f764e94b9bcaa9f7db0dcc689c31dc06466dac against current main at de4f7757f216063b5b48e431561d141bcbf40097. This audit treats #181 as the target workflow we are building toward, not as a conventional merge candidate. It is invalid after either head changes.

The target remains coherent: the user owns material decisions; planner and implementor converge through evidence; workflow state and environmental effects are explicit; agents do not own Git, GitHub, or workspace effects; and every live resource is scope-owned.

Settled contracts to fold into the target documents

These are documentation updates, not missing product features.

• Replace inputs with props in start.md, runtime.md, InstructionFiles.md, Discovery.md, Planning.md, UserCheckpoint.md, and Implementation.md. props is the settled declaration vocabulary; inputs is ordinary metadata and does not declare component or root props.
• Replace the remaining future-facing Support schema-validated component returns #176 language in artifacts.md and primitives.md with the shipped return contract: Markdown value components declare returns and one direct <Return>; registered function returns bind by reference by default; returns opts into JSON validation and requires as; uncaptured strings render and uncaptured non-strings render nothing.
• Reclassify <If>/<Else>, <Loop>/<Break>, <Answers>/<Answer>, and <Return> as shipped reserved structural syntax. Repository files and registrations cannot claim these names.
• Reclassify <TempDir>, <File>, <Glob>, <Parse>, <SafeParse>, and <Elicit> as shipped core defaults. A repository component may override each ordinary default.
• Update the parsing description to the shipped contracts: schemas compile before content, <Parse> binds the validated JSON value, and <SafeParse> binds { ok: true, value } or { ok: false, input, errors } without swallowing child or schema-compilation failures.
• Update the filesystem description to the shipped contracts: contextual cwd is implemented; <File> reads or atomically replaces UTF-8 text and returns no write handle; <Glob> returns a sorted, deduplicated string[]; both are observationally confined but are not a security sandbox.
• Update the elicitation description to the shipped architecture: <Elicit> is provider-neutral, validates and durably fingerprints the question and answer, xmd run supplies WebForm as the current host provider, and <Answers> supplies document-owned answers without choosing a transport. Cross-stage stop and resume remains separate work.
• Update loop durability language: <Loop> records entered iterations and terminal break, exhausted, or error outcomes and refuses stale replay. Workflow-level cancellation and stage-stop records remain future behavior.
• Record that dynamic agent and session selection through expression props is implemented, and that Agent, Session, Prompt, Elicit, and the other function components resolve through scope-local registration with repository override precedence.
• Update the PR review guide to the actual target files: start.md, Discovery.md, Planning.md, UserCheckpoint.md, and Implementation.md.

Shipped foundation available to the end goal

• Root props and CLI/programmatic prop validation (💥 feat(core): declare component props under "props" #179).
• Schema-validated Markdown, function-component, and root returns (Support schema-validated component returns #176, 💥 feat(core): return schema-validated values from components and roots #200, 💥 Capture props, and returns that bind by reference #265).
• Component invocation scope and explicit retained-resource support (✨ feat: give every component invocation its own resource scope #210, ✨ feat: let a component retain a resource at its invocation site #214).
• Contextual working directory and scoped temporary directories (✨ feat: launch exec and daemon processes in the contextual working directory #222, ✨ feat: add a scoped TempDir component #216).
• <Parse> and <SafeParse> (Add provider-neutral Parse and SafeParse components #193, ✨ feat: parse generated JSON into a value a document can use #224).
• <If>/<Else> (feat: replace Show with structural If / Else control flow #78, ✨ feat: replace Show with structural If / Else control flow #217).
• <File> (✨ feat: add a contextual File component for UTF-8 reads and writes #225).
• <Loop>/<Break> with durable iteration and outcome records (Add bounded Loop and Break structural control flow #194, ✨ feat: add bounded Loop and Break structural control flow #226).
• <Glob> (✨ feat: add a deterministic contextual <Glob> component #229).
• Scope-local component registration and migration of legacy handlers (Register function components and migrate legacy component handlers #202, ✨ Register components scope-locally and resolve them deterministically #242, ✨ Move <Answers> and <WhenPrompt> off the expansion hook (#202, part A of two) #281, 💥 Retire the expansion hook (#202, part B of two) #285).
• Provider-neutral <Elicit> (Add provider-neutral Elicit through the core Context API #197, ✨ Add <Elicit> and the Elicitation Context Api #264).
• <Answers> and WebForm-backed host elicitation (Add <Answers>: provide elicitation responses as a document construct #267, ✨ Add <Answers>/<Answer>: supply elicitation responses as a document construct #269, ✨ Answer elicitations with a browser form, and enforce WebForm's fingerprint #273, Replace scriptElicitations() with <Answers> #274, 💥 Remove scriptElicitations() in favour of <Answers> #277).
• Agent, Session, and Prompt as registered function components with dynamic expression props.

The document-level logic in InstructionFiles, Discovery, Planning, and UserCheckpoint is therefore no longer speculative once its declarations are updated to the settled contracts. The remaining gap is workflow orchestration and ownership, not conditional logic, parsing, file discovery, or elicitation.

Missing feature checklist for the complete workflow

Workflow identity, artifacts, and resumption

• Implement <Workflow> as the owner of one internal run identity without exposing a required runId prop.
• Resolve base once to a pinned source revision and publish the run and revision through a contextual Run API.
• Define immutable artifact versions for handoffs, plans, verdicts, implementation results, user decisions, and environmental effects, keyed by stable component and loop-iteration identity.
• Persist run snapshots in Git objects reachable from refs/xmd/runs, including explicit push/fetch behavior for the custom ref.
• Restore named stage inputs from the run record and render their exact content into later prompts without transfer files.
• Record completed stages, completed loop iterations, success, failure, cancellation, and stop reasons without inventing a successful terminal record for interrupted work.
• Reconcile durable effects with the run identity so resumption cannot duplicate or silently adopt an effect from another run.
• Resolve replay across replaced ephemeral environments (Implement retained Workflow Workspace restoration #218).

Stage execution and user continuation

• Implement <Stage> to select one manual stage, restore its declared inputs, publish its outputs, and stop cleanly at the stage boundary.
• Define how a later invocation selects and resumes the same workflow run and stage.
• Define in-band runtime input that can resume a stopped workflow. <Elicit> solves an in-run question but not cross-process stage continuation.
• Implement the automated stop arbitration from the target: iteration completion, configured file change, or user input, with deterministic priority and cancellation behavior.
• Preserve the current user-authority contract across every resumed transition; resumption must not turn an unanswered material choice into implicit approval.

Workspace ownership

• Implement <Worktree> to create or reconcile one workspace from the pinned revision and reuse it across discovery, planning, implementation, and review.
• Publish contextual cwd for all child file, process, agent, and Git operations.
• Define deterministic worktree identity, branch naming, existing-state reconciliation, and behavior when the base branch moves.
• Clean up a clean workspace on success; retain dirty, unpushed, failed, or cancelled work with its path, branch, state, and recovery reason.
• Ensure projected content resources stop before the owning workspace cleans up (Bind projected content resources to the component invocation scope #203).
• Keep worktree filesystem isolation distinct from the security boundary.

Enforceable sandbox and permissions

• Implement <Sandbox> as an enforceable capability boundary for filesystem roots, environment variables, processes, network access, secrets, and durable effects.
• Give planner stages repository read/search capability without source mutation.
• Give implementor stages write access only to the workflow-owned worktree, never shared Git metadata.
• Give deterministic components narrow Git and GitHub authority rather than exposing that authority through an agent prompt.
• Own and halt every process, agent session, stream, and watcher before the enclosing stage or workflow scope closes.
• Resolve containment that remains safe under concurrent filesystem mutation, or explicitly bind unattended execution to a platform sandbox that provides it (Contain filesystem access at the provider boundary #227).
• Install default-on secret rejection before journal events and sidecar Git snapshots become durable (Reject secrets before journal persistence by default #199).

Deterministic Git and GitHub effects

• Implement <Commit> to validate the exact allowed path set, refuse unrelated changes, write Git metadata outside agent authority, and return a structured commit identity.
• Define commit reconciliation after interruption, including the case where the commit may have succeeded before the process lost its result.
• Implement <PullRequest> to create or resolve the PR for the workflow branch idempotently and return its number, URL, head, base, state, and review/check state.
• Implement <Issue> to create or resolve provenance-linked deferred findings idempotently.
• Record the inputs, observed pre-state, applied effect, and returned state of every Git and GitHub operation in the workflow run.
• Ensure replay never creates duplicate commits, pull requests, or issues and never trusts a moved PR head without a fresh review.

End-to-end workflow contract

• Make start.md execute discovery → handoff checkpoint → plan convergence → authorization → implementation/review loop → final user acceptance in the same workflow-owned workspace.
• Prove malformed agent JSON receives only the bounded correction turns shown in the document and cannot reach control flow or durable effects.
• Prove a failed planner verdict returns its prescriptive revision prompt to the same implementor session and preserves all prior versions.
• Prove material choices stop at <UserCheckpoint> and only the user response authorizes the next transition.
• Prove deferred findings create provenance-linked issues without silently expanding the active PR chain.
• Prove cancellation and failure halt live resources, preserve recoverable work, and leave enough state for an explicit resume.
• Prove the complete run can resume after process exit without hidden transcript state or user copy/paste.
• Prove agents cannot directly perform the workflow-owned Git, GitHub, sandbox, or retention effects.

Not blockers for this workflow

• External JSON Schema references (Resolve external JSON Schema refs through XMD filesystem and fetch capabilities #192): the target already captures self-contained schemas.
• Structured <File> handles: the current target passes relative paths and does not consume a write handle.
• xmd play: it remains the layer built after this implementation loop works; it is not required to make the loop executable.
• Unattended runtime inspector control: ordinary decisions use the in-band user protocol; inspector support remains operational meta-control.

This checklist should shrink as features land. A settled contract updates the target documents and moves to the shipped foundation; only capabilities absent from the runtime remain unchecked.

[taras]

Current delivery map

The root document is the workflow. A durable workflow run may continue through multiple document executions.

Each issue remains an independently reviewable stop point.

Living target and shipped document logic

• PR Document adversarial implementation workflow WIP #181 / Synchronize the #181 living target with settled XMD contracts #292 — align the living target with current architecture: the root document is the workflow and host-installed middleware extends it.
• Namespace Markdown props under the props binding #305 — namespace Markdown props consistently before the workflow proof is pinned.
• Prove the shipped adversarial-planning document logic #290 — prove InstructionFiles, Discovery, UserCheckpoint, and Planning using shipped document behavior.

Workflow identity and environment foundations

• Add contextual workflow runs with pinned commits #289 / PR 💥 Add expansion identity and pinned-commit workflow runs #341 — add workflow-run metadata, pinned commits, deterministic expansion IDs, and the Git revision capability.
• Implement retained Workflow Workspace restoration #218 — use those identities to add a provider-neutral <Workspace> boundary, with @cloudflare/computer as the first provider. A later document execution reattaches the same durable Workspace and reinstalls the existing filesystem, process, and cwd contexts.
• Reject secrets before journal persistence by default #199 — finish cross-backend/runtime secret-detection certification and website documentation.
• Contain filesystem access at the provider boundary #227 — settle filesystem-containment guarantees per runtime.

#199 and #227 can proceed independently. #218 is designed and stacks on PR #341 until #289 merges.

Persistence and workspace composition

• Store WorkflowRuns and filtered journals in SQLite #291 — persist the artifact ledger and own durable lookup plus xmd workflow run/continue.
• Add named Repository and Worktree composition #293 — compose the workflow-owned Git Worktree inside Implement retained Workflow Workspace restoration #218's Workspace boundary. It uses the provider-installed environment contexts rather than defining another restoration mechanism.

Workspace state is retained across completion, failure, cancellation, and interruption; scope teardown releases only ephemeral provider attachments. Point-in-time snapshots, rollback, and training export are not prerequisites for normal resumption.

Deterministic Git and GitHub effects

After #291 and #293:

• Add deterministic local Git workflow effects #294 — Commit.
• Add shared external forge-effect reconciliation #297 — shared GitHub reconciliation; this may proceed in parallel with Add deterministic local Git workflow effects #294.
• Add a deterministic PullRequest workflow effect #295 — PullRequest, after Add deterministic local Git workflow effects #294 and Add shared external forge-effect reconciliation #297.
• Add a deterministic provenance-linked Issue workflow effect #296 — Issue, after Add a deterministic PullRequest workflow effect #295 and Add shared external forge-effect reconciliation #297.

Authority, composition, and certification

• Enforce read-only workflow Agent authority #302 — define and enforce workflow agent authority after Contain filesystem access at the provider boundary #227 and Add named Repository and Worktree composition #293.
• Compose the supervised adversarial implementation workflow #301 — compose the supervised workflow using Store WorkflowRuns and filtered journals in SQLite #291's run/continue lifecycle.
• Resume workflow runs from explicit durable signals #300 — automate continuation without changing the supervised contracts.
• Certify the adversarial implementation workflow end to end #299 — certify interruption, replay, stale state, failure, runtime coverage, and absence of hidden transcript state.

Dependency spine

#181/#292 → #305 → #290

#289 / PR #341 → #218 ─┐
                        ├→ #293 → #294
#199 + #289 / PR #341 → #291 ─┘

#291 → #297
#294 + #297 → #295 → #296
#227 + #293 → #302

#290 + #291 + #293 + #294 + #295 + #296 + #302
  → #301 → #300 → #299

#298 is superseded by #291, which owns durable lookup, xmd workflow run/continue, restoration of declared values, cross-process continuation, and durable outcomes.

Implementors validate authorized slices. Taras settles #227, #290 exhaustion, and #302's term and installation architecture before those stories are delegated. #218's product decisions are recorded in the issue; its implementor validates that design rather than choosing a replay or provider model.

[taras]

Parallel delivery map

Current at PR head 28f764e94b9bcaa9f7db0dcc689c31dc06466dac. Boxes on the same horizontal tier may proceed in parallel. Arrows are merge dependencies, not merely preferred ordering.

                                      START
                                        |
      +---------------------------------+----------------------------------+
      |                                 |                                  |
      v                                 v                                  v
+----------------------+      +----------------------+          +----------------------+
| A. Synchronize #181  |      | B. #203 projected   |          | C. #199 persistence  |
| to settled contracts |      | resource ownership  |          | safety stack         |
+----------+-----------+      +----------+-----------+          +----------+-----------+
           |                             |                                 |
           v                             |                                 |
+----------------------+                 |                                 |
| Prove current        |                 |                                 |
| document logic       |                 |                                 |
+----------+-----------+                 |                                 |
           |                             |                                 |
           |                  +----------v-----------+                     |
           |                  | Run identity +       |                     |
           |                  | pinned base revision |                     |
           |                  +----+-------------+---+                     |
           |                       |             |                         |
           |       +---------------+             +--------------------+    |
           |       |                                                    |    |
           |       |        PRODUCT DECISION TRACKS                     |    |
           |       |                                                    |    |
           |       |   +----------------------+   +------------------+  |    |
           |       +<--| #218 environment     |   | #227 containment |  |    |
           |           | replay ruling + impl |   | / sandbox ruling |  |    |
           |           +----------+-----------+   +---------+--------+  |    |
           |                      |                         |           |    |
           |                      v                         |           |    |
           |           +----------------------+            |           |    |
           |           | Worktree lifecycle   |<-----------+-----------+    |
           |           | and contextual cwd   |            |                |
           |           +----------+-----------+            |                |
           |                      |                        |                |
           |                      |            +-----------v-----------+    |
           |                      |            | Artifact ledger +     |<---+
           |                      |            | refs/xmd/runs history |
           |                      |            +-----------+-----------+
           |                      |                        |
           |                      +------------+-----------+
           |                                   |
           |                                   v
           |                       +------------------------+
           |                       | Stage + manual resume  |
           |                       +-----------+------------+
           |                                   |
           |        +--------------------------+--------------------------+
           |        |                          |                          |
           |        v                          v                          v
           |  +-------------+       +--------------------+      +--------------------+
           |  | Commit      |       | GitHub effect      |      | Sandbox            |
           |  | effect      |       | reconciliation API |      | implementation     |
           |  +------+------+       +---------+----------+      +---------+----------+
           |         |                        |                           |
           |         |              +---------+---------+                 |
           |         |              |                   |                 |
           |         |              v                   v                 |
           |         |       +-------------+     +-------------+          |
           |         |       | PullRequest |     | Issue       |          |
           |         |       | effect      |     | effect      |          |
           |         |       +------+------+     +------+------+          |
           |         |              |                   |                 |
           +---------+--------------+---------+---------+-----------------+
                                            |
                                            v
                              +-----------------------------+
                              | Supervised complete workflow|
                              +--------------+--------------+
                                             |
                                             v
                              +-----------------------------+
                              | Automated continuation      |
                              | file/input/iteration race   |
                              +--------------+--------------+
                                             |
                                             v
                              +-----------------------------+
                              | End-to-end certification    |
                              +-----------------------------+

Parallel waves

Wave 1
  A  Target synchronization -> document-logic proof
  B  #203 projected-resource ownership
  C  #199 scanner and persistence-safety stack
  D  #218 and #227 investigation; Taras resolves the product choices

Wave 2
  Run identity/base pinning
  #218 implementation after the ruling
  remaining #199 slices
  #227 mechanism prototyping after the ruling

Wave 3
  Worktree             requires #203 + Run identity + #218
  Artifact ledger      requires Run identity + #199

Wave 4
  Stage/resume         requires Worktree + artifact ledger
  Commit               requires Worktree + artifact ledger
  GitHub effect core   requires artifact ledger
  Sandbox              requires Worktree interface + #227 ruling

Wave 5
  PullRequest and Issue may proceed in parallel after the shared
  GitHub reconciliation contract lands.

Wave 6
  Supervised workflow joins document logic, Stage/resume, Commit,
  PullRequest, Issue, and Sandbox.

Wave 7
  Automated continuation -> certification

Shared-code collision rules

Execution / durability:
  Run identity, #199, and #218 may be investigated concurrently.
  Their integration commits merge serially because they share execution setup,
  durable context, and replay boundaries.

Expansion / projection:
  #203 owns this lane until its lifecycle contract lands.

Workspace / Git:
  Worktree lands before Commit; both use the same repository ownership boundary.

GitHub:
  PullRequest and Issue split only after one shared idempotent reconciliation
  contract is merged. Neither invents its own replay or uncertain-result rule.

Product decisions:
  Implementors do not choose #218 durability semantics or #227 sandbox guarantees.

Maximum useful initial concurrency is three implementation lanes (A, B, C) plus planner/user investigation of #218 and #227. More implementation lanes would mostly create integration conflicts at the execution and durability boundary.

[taras]

Milestone story map

Created the Adversarial implementation workflow milestone. Every task in the approved delivery sequence now has a canonical story:

• 0 — Synchronize the #181 living target with settled XMD contracts #292 Synchronize the Document adversarial implementation workflow WIP #181 living target with settled XMD contracts
• 1 — Prove the shipped adversarial-planning document logic #290 Prove the shipped adversarial-planning document logic
• 2 — Bind projected content resources to the component invocation scope #203 Bind projected content resources to the component invocation scope
• 3 — Add contextual workflow runs with pinned commits #289 Add Workflow run identity and pin the base revision
• 4 — Implement retained Workflow Workspace restoration #218 Settle replay inside replaced ephemeral environments
• 5 — Add named Repository and Worktree composition #293 Add the workflow-owned Worktree lifecycle
• 6 — Reject secrets before journal persistence by default #199 Reject secrets before journal persistence by default
• 7 — Store WorkflowRuns and filtered journals in SQLite #291 Persist the Workflow artifact ledger under refs/xmd/runs
• 8 — Add Stage execution and cross-process manual continuation #298 Add Stage execution and cross-process manual continuation
• 9 — Add deterministic local Git workflow effects #294 Commit, Add shared external forge-effect reconciliation #297 shared GitHub reconciliation, Add a deterministic PullRequest workflow effect #295 PullRequest, and Add a deterministic provenance-linked Issue workflow effect #296 Issue
• 10 — Contain filesystem access at the provider boundary #227 settle containment and Enforce read-only workflow Agent authority #302 implement Sandbox
• 11 — Compose the supervised adversarial implementation workflow #301 Compose the supervised complete workflow
• 12 — Resume workflow runs from explicit durable signals #300 Automate continuation across completion, files, and user input
• 13 — Certify the adversarial implementation workflow end to end #299 Certify the end goal across failure, replay, and runtimes

PR #181 itself is also attached to the milestone as the living end-goal artifact. Each new story records scope, observable acceptance criteria, dependencies, and its sequence position. Existing stories #199, #203, #218, and #227 remain canonical rather than being duplicated.

[taras]

Fresh head on current main — #292

Replaced the stale head 1a01e58 (based on e0b37ea, seven commits behind) with 014447b, re-derived from 7d7bdf2 — the #325 merge. No commit from the old head was cherry-picked, merged, or reapplied; the 11 files were re-authored. git merge-base with origin/main is exactly 7d7bdf2.

The markup did not run

Every stage passed props through expression props as agent={props.planner}. On current main that fails with props is not defined: an expression prop reads the bare binding, while text and content interpolation read the namespace. Reproduced at the root and inside a component body; the bare form works in both.

This is #305, still open — "Expression-valued component props can read props.name" is one of its acceptance criteria, so the target was written against a language change that has not landed. 22 expression-prop sites are corrected to the spelling main supports; the 16 text-interpolation sites keep {props.X}. The asymmetry is documented with #305 named as what removes it.

The error model reaches the stages

A stage component is split by its <Output> boundary: the region inside runs under the output error mode, everything outside is documentation and runs under throw, which no <PrintErrors> region replaces. A stage therefore returns a complete validated result or it fails, keeping only what it had already rendered. That is what makes each repair loop's final <Parse> a gate.

throwOnError is load-bearing for the same reason, and not for the reason I first assumed: without it a failed prompt records its failure and returns its text, raising nothing for the mode to decide (agent/function-components.ts:210-221).

One claim I did not repeat: architecture.md says an outer <PrintErrors> can print a failure an <Output> region decided, but expand.ts:2292 consults decidedByOutput only on the projected-content path, and a probe showed an outer boundary not printing a nested component's <Output> failure. The target states only what was observed.

Stale claims removed

<CollectFailures> → <PrintErrors> in the structural set · "the unresolved diagnostic" → "the unresolved printed error" · "replays recorded results" → replay restores a recorded outcome without re-executing, and a failed run is still a complete record. Replay is described as reaching the state execution resumes from, never as the continuation itself.

Vocabulary

Collapsed onto the concepts #289, #291 and #298 authorize — artifact ledger, artifact version, run identity, pinned source revision, stop reason, terminal record, stage boundary, declared inputs, cross-process continuation — replacing the four names these files used for a ledger and the three for a run. Engine state is described as scoped to the operation that owns it, with no module-scoped registry. Missing capabilities cite the issue that supplies them (#289, #291, #293, #294, #295, #296, #297, #298, #300, #302) rather than saying only "not implemented".

Classification

Shipped: InstructionFiles, Discovery, UserCheckpoint, Planning. Missing: the <Workflow>/<Sandbox>/<Worktree> spine, <Stage>, the artifact ledger, and — inside Implementation — <Commit>, <PullRequest>, <Issue>, which is why that stage cannot expand rather than merely lacking a wrapper. Blocked on a product decision: #218, #227, and planning-loop exhaustion under #290, which stays explicitly unresolved — the output reports verdict.passed and does not call an exhausted loop converged.

Evidence

Check	Result
inspectDocument on all 9 frontmatter-bearing files	parse and compile; every one returnMode=text
compileParseSchema on all 5 embedded draft-07 schemas	compile
inspectComponent — 21 shipped names	12 structural, 9 registered
inspectComponent — 5 repository components	markdown
inspectComponent — 9 missing names	unresolved
InstructionFiles executed against this repo's AGENTS.md	renders exact path and content

Gates: deno task fmt, lint, check, test (349 passed, 0 failed), check:jsr (Success Dry run complete), and pnpm exec tsc --project tsconfig.node.json --noEmit.

Outstanding before merge

#203 is still open and is an input to this target, not something this PR closes. Before merge this branch rebases onto the origin/main that carries it, and the projected-resource and component-lifetime language is realigned with the behavior actually merged.

[taras]

Rebased onto 511776e — fresh review head 68733d7

014447b → 68733d7, rebased onto origin/main at 511776e (the #326 merge). Lease was pinned to 014447b. git merge-base with origin/main is exactly 511776e; two commits on the branch, both signed.

#203 as merged

#326 is test-and-spec-only: it adds L8 (a projected persist resource stops ahead of one the component retained after projecting) and Q14 (a projected daemon is gone after the invocation, signalled while the <TempDir> still exists). Those were precisely the two acceptance criteria this target had the weakest evidence for — I had cited O23/O24 and CW3, which are adjacent but not the same claim. #203 is now closed.

The target states the merged behavior and why it matters here: projected content keeps its caller's bindings while its live effects belong to the component invocation and stop before it cleans up its own. That ordering is what <Worktree> (#293) is built on — a process a stage starts stops before the workspace it ran in is removed, so cleanup cannot pull the ground out from under a running effect. Recorded in primitives.md (execution foundation, and the <Worktree> entry) and in the specification's cleanup-and-recovery section.

<PrintErrors> — contract restored, discrepancy filed

architecture.md is authoritative, so the output row reads as the registry states it:

| output | fails the run; <PrintErrors> can print instead | every <Output> region |

My earlier head under-stated that row to match observed behavior. That was the wrong call — the target does not get to redefine a settled contract from an engine observation. The engine discrepancy is now classified as missing and filed as #327, reproduced on 511776e in both arrangements: the failure arising in the callee's own <Output> region, and the failure projected into one. A control case (the same failure directly inside <PrintErrors> at the root) prints and continues, so the mechanism is not broken in general.

The distinction the target still draws is the registry's own: throw is the one mode a boundary cannot replace. Every stage's parsing sits in documentation, so each stage's final <Parse> is a gate for that reason — not because printing is unavailable. No workflow document writes <PrintErrors>, so nothing here depends on #327.

Revalidation on the rebased head

All probes rerun: inspectDocument parses all 9 frontmatters; compileParseSchema compiles all 5 embedded draft-07 schemas; inspectComponent resolves 21 shipped and 5 repository names and confirms 9 missing ones unresolved; InstructionFiles still runs end to end against this repo's AGENTS.md. Vocabulary sweep clean.

Gates rerun: deno task fmt, lint (0 errors), check, test (349 passed, 0 failed), check:jsr (Success Dry run complete), pnpm exec tsc --project tsconfig.node.json --noEmit (exit 0).

Everything from the previous head's summary that is not amended above still stands — the #305 expression-prop correction, the error-mode split, the vocabulary collapse onto #289/#291/#298, and planning-loop exhaustion left open under #290.

[taras]

All four blockers addressed — head ef9bcbabdd4114e5781ad90d62166e60331a6231

Base 511776e, fast-forward from 5fcc93b.

1. CI

Not waived, not labelled baseline. Re-ran test-node on the identical head 5fcc93b and it passed, so it did not repeat. All ten checks are green on the new head ef9bcba.

Evidence for the TV6 diagnosis, which another agent is taking: it failed once on 5fcc93b and once on main at 511776e, both on TV6 with the same ["fail"] vs ["pass"] and the same ~20.4s duration; 7d7bdf2 was green; the full Tier TV suite passes locally under Deno in 33s. Flaky, Node-only, first appearing at the #326 merge.

2. The handle boundary

artifacts.md no longer says nothing consumes it. Stated exactly: Implementation consumes all of it internally; start.md never receives it — what crosses the stage boundary is the verdict and the decision; the artifact ledger records it independently (#291).

3. The two text components

Probing this corrected a second error in the same sentence. I had written that InstructionFiles' reads are decided under output and that both text components end the run. Neither holds:

<InstructionFiles paths={["does-not-exist.md"]} as="text" />
→ exit 0
→ <!-- ERROR: Function component File error: cannot read "does-not-exist.md" -->
→ {text} stays literal; tail still renders

<File> prints its own failures, so an unreadable instruction file is decided as a printed error before the region's output mode sees it. The run continues, and what stops the caller is the binding rule: as refuses a body holding a printed error, so instructions stays unbound and the error surfaces at the invocation. Discovery is the genuine documentation case — its prompt is raised under throw and ends the run.

start.md gains the same qualifier, since "an undecided error fails the run" is true only of undecided ones.

4. The checkpoint's review evidence

review.body reached the planner prompt but not checkpointMaterial, so a user approving the change saw who objected but not what they said. It is now in both, and the claims are narrowed to what is true: the two surfaces carry the same categories and the same consequential content, and the checkpoint omits only a check's link.

The earlier probe missed this because it asserted the review author on the checkpoint material and the body only on the prompt — an assertion too weak to see the omission it existed to cover.

Omitted	Planner prompt	Checkpoint material
none	body / comment / check all pass	body / comment / check all pass
reviews	body fails	body fails
comments	comment fails	comment fails
checks	check fails	check fails
review.body from checkpoint only	passes	fails — the shape of the shipped defect

Sweep and verification

All eleven files and the PR body swept for the three stale claim families — "nothing consumes" the handle, text work running in documentation, and a complete snapshot reaching both surfaces: clean.

• Document probes: ALL CHECKS PASS — 9 frontmatters parse, 5 embedded schemas compile, 21 shipped + 5 repository names resolve, 9 missing unresolved
• git diff --check against 511776e: no whitespace errors
• deno task fmt · lint (0 errors) · check · test (349 passed, 0 failed) · check:jsr (Success Dry run complete) · pnpm exec tsc --project tsconfig.node.json --noEmit (exit 0)
• All ten PR checks green: composability, deploy, jsr, lint, review, site, smoke, test-bun, test-deno, test-node

[taras]

Approval now shows every effect it performs — head 382d11500fd403a15f18c2da926101870724d156

Base 511776e, fast-forward from ef9bcba. All ten checks green.

The finding was right, and it is the same leak as the earlier ones in a new place. The document's rule says proceed: true authorizes the exact transition and the exact effects presented for assessment. The material presented neither of the two things approval actually performs:

• a failing verdict sends verdict.revisionPrompt to the implementor, and the checkpoint never showed it;
• a defer disposition sends the complete finding to <Issue> including finding.evidence, and the checkpoint showed only title, disposition, and description.

A user could approve revision instructions and issue evidence they had never read. Worth noting that Planning already rendered its revision prompt — the asymmetry was sitting in the repository and I did not look at it.

Both are now in checkpointMaterial, unchanged and unsummarized: the literal verdict.revisionPrompt, and each finding's evidence rendered beneath it with a nested <Each>. Original values, not reconstructions.

Discrimination

Distinct markers for revisionPrompt and findings[].evidence. The <Issue> stub records the finding it was passed, so the checkpoint can be compared against the effect rather than against itself.

	checkpoint: revisionPrompt	checkpoint: evidence	implementor receives same prompt	issue receives full finding
baseline	ok	ok	ok (prompt-7, "Revise the implementation")	ok
revisionPrompt removed from checkpoint	FAIL	ok	ok	ok
evidence removed from checkpoint	ok	FAIL	ok	ok
restored	ok	ok	ok	ok

The two effect columns stay green under both mutations, which is exactly the shape of the leak being closed: the effect fires either way; the only thing that changes is whether the user saw it before authorizing it.

The issue stub confirms what it received:

{"disposition":"defer","title":"t","description":"d","evidence":["EVIDENCE-MARKER"]}

Sweep

Implementation.md, the specification, and the PR body now describe what the markup renders. The "same consequential content" claim states what each surface carries and why they differ: the checkpoint omits a check's link and adds the revision prompt and finding evidence, because those are what an approval performs rather than what the review consumed.

Verification

• Document probes: ALL CHECKS PASS — 9 frontmatters, 5 embedded schemas, 21 shipped + 5 repository + 9 unresolved names
• git diff --check against 511776e: no whitespace errors
• deno task fmt · lint (0 errors) · check · test (349 passed, 0 failed) · check:jsr · tsc (exit 0)
• All ten PR checks green: composability, deploy, jsr, lint, review, site, smoke, test-bun, test-deno, test-node

[taras]

Workspace-direction milestone audit

This review follows the provider-backed Workspace decision in #218 and the host-topology decision opened as #346. It records recommendations only; it does not authorize implementors to rewrite product scope, and no issue below was closed or edited by this audit.

Verdict

The milestone’s end goal remains relevant. No open story is wholly obsolete at the product-outcome level.

The new direction does invalidate or unset several implementation mechanisms:

• local host paths are no longer the only containment domain;
• refs/xmd/runs is no longer an obviously correct universal persistence backend; and
• Cloudflare Computer exposes a durable VFS and Git checkout operations, not the traditional shared-repository git worktree lifecycle Add named Repository and Worktree composition #293 currently specifies.

Keep essentially as written

Item	Reason
#290	The shipped planning-document proof is independent of Workspace topology.
#292	Synchronizing this living target is still required and is where the new Workspace vocabulary should appear.
#295	Pull-request reconciliation remains a deterministic external effect.
#296	Provenance-linked deferred issues remain necessary.
#305	Namespaced props remain a prerequisite for the document proof.
#346	This is the decision gate introduced by the Workspace provider plan.

Keep the outcome, amend the issue before delegation

Item	Required change
#199	Keep the existing journal and snapshot policy. Once #346 selects the host, make the final runtime matrix cover that host if execute() runs there. Do not silently broaden this story into scanning live Workspace state.
#218	Remains the Workspace implementation story, blocked by #346. Its provider lookup must use host-owned authority even though its provenance key uses run and expansion identity.
#227	Split or reframe the guarantee by environment provider. The local File TOCTOU problem remains real, but an openat solution for Deno/Node/Bun is not automatically the containment boundary of Cloudflare’s virtual filesystem and sandbox. Decide whether the local hardening stays in this milestone or becomes a separate general-XMD story.
#291	Preserve durable lookup, continuation, immutable artifact versions, outcomes, and declared values. Reopen the storage decision: Git refs may remain one adapter, while a Cloudflare-native host may place the journal/run index in Durable Object storage and immutable repositories in Cloudflare Artifacts. #346 must decide ownership before this mechanism is implemented.
#293	Preserve the workflow-owned isolated repository state, pinned starting commit, dirty-state retention, and deterministic recovery. Reconsider the literal Worktree mechanism and possibly its authored name: Cloudflare Computer supplies Workspace Git operations but does not document git worktree. Decide between a provider-neutral checkout/repository component, a provider-specific implementation behind <Worktree>, or an Artifacts fork.
#294	Commit remains required. Express it over the selected repository capability rather than assuming local shared Git metadata. The host, not document-controlled context, authorizes the repository and path set.
#297	Shared GitHub reconciliation remains required. Clarify that runId + expansionId is provenance/idempotency identity, not authorization, and remove any hard dependency on one artifact-ledger backend.
#299	Add the selected Cloudflare host/provider, Workspace reattachment, lost attachment, pending post-command sync, provider-state loss, and journal/VFS uncertain-completion cases. Do not certify snapshot rewind because #218 excludes it.
#300	Automatic continuation remains useful, but “configured file change” must name how the selected provider observes changes. Cloudflare Computer’s documented filesystem surface does not itself establish the current local watcher model.
#301	The supervised composition remains the milestone’s integration point. Replace “workflow-owned worktree” with the repository abstraction selected for #293 and install <Workspace> at the appropriate outer boundary.
#302	Authority enforcement becomes more important. Define guarantees per selected provider/host, including Workspace lookup, filesystem, process backend, environment, network/egress, Git, GitHub, and provider administration. It should depend on #346 and the revised #218/#227/#293 boundaries.

Living target

PR #181 remains the correct end-goal artifact but is intentionally stale until #292 updates it. Its <Sandbox> / <Worktree> lifecycle and cleanup language must be reconciled with:

• retained provider Workspace state;
• ephemeral attachments and compute;
• provider-installed Fs, Process, and Env.cwd;
• the repository abstraction selected for Add named Repository and Worktree composition #293; and
• no default deletion of the run’s environment.

Do not merge #181 merely because its current checks pass; its purpose is semantic alignment with the settled architecture.

Completed foundations

Keep the completed items in the milestone as delivery history:

• Bind projected content resources to the component invocation scope #203 — component/resource lifetime;
• Add contextual workflow runs with pinned commits #289 / merged PR 💥 Add expansion identity and pinned-commit workflow runs #341 — workflow-run and expansion identity;
• Align error vocabulary with the architecture.md registry #316 — error vocabulary;
• 💥 Build the error propagation and partial output rules #318 / PR 💥 Build the error propagation and partial output rules #319 — failure and partial-output semantics;
• 💥 Scope engine state to the operation that owns it #323 / PR 💥 Scope engine state to the operation that owns it #325 — operation-owned state; and
• Add Stage execution and cross-process manual continuation #298 — correctly closed as superseded by the durable lookup/continuation outcome that remains in Store WorkflowRuns and filtered journals in SQLite #291.

Proposed dependency shape

The exact graph after #346 depends on its selected topology, but the current map should no longer say #218 can proceed independently of #289 or that it should stack on #341. #341 has merged.

completed: #289 / PR #341

#292 + #305 -> #290

#346 -> #218
#346 -> storage decision in #291
#346 -> provider scope of #227 and #302
#346 -> final runtime scope of #199 and #299

#218 + revised #291 -> revised #293
revised #291 + #293 -> #294
revised #291 -> #297
#294 + #297 -> #295 -> #296
revised #227 + #218 + #293 -> #302

#290 + #291 + #293 + #294 + #295 + #296 + #302
  -> #301 -> #300 -> #299

Implementation of #199 and #291 can overlap because the scanner and policy already exist, but neither should claim final cross-runtime certification until #346 establishes whether a Cloudflare Workers runtime is part of the supported execution surface.

[taras]

Adversarial Implementation dependency-map delta

The Workspace path now includes an evidence-producing spike:

#347 bundle workerd POC
  -> #346 select the Workspace host topology
    -> #218 provider-backed Workspace restoration
      -> #293 workflow-owned Worktree lifecycle

#347 tests whether XMD can remain a single-download executable while supervising a bundled local workerd, whether Durable Object and @cloudflare/computer filesystem state survive full process restarts, and which Computer execution backends are actually available outside Cloudflare's hosted runtime. It does not select the topology or change the #218 contract by itself.

[taras]

Adversarial Implementation dependency-map delta

The Workspace topology decision now has two evidence paths:

#347 bundled workerd POC ----+
                              +-> #346 topology decision -> #218 -> #293
#349 Deno SQLite/DOFS POC ---+

#349 tests whether Deno can own the persistent SQLite Workspace directly while reusing Cloudflare's DOFS and FUSE layers. It compares real FUSE and the userspace shim independently, and compares its portability, durability, security, and maintenance boundary against PR #348's bundled-workerd result.

[taras]

Adversarial Implementation dependency map — Workspace design revision

PR #358 captures the design decisions produced by #346 and the Workspace interview. It changes the implementation path materially: xmd workflow owns one implicit retained Workspace; Deno owns the run's SQLite database and DOFS state; local effects and journal results share a transaction; workflow Agents are read-only and propose constrained XMD.

Evidence and decisions

#347 / #348  bundled workerd evidence ─┐
#349 / #350  Deno + DOFS evidence ─────┼→ #346 / #358 topology decision
#351 / #353  Worker boundaries ────────┘              │
                                                     ├→ #218 Workspace implementation
#357 Worker Shell transaction proof ─────────────────┘  (optional Shell gate)

• Spike: bundle workerd into the compiled XMD host #347, Spike: host Cloudflare DOFS directly in Deno with SQLite and FUSE #349 and Spike: run Cloudflare Worker Shell and Worker JavaScript natively in Deno #351 are completed evidence spikes. Merge their reviewable PRs and close the spike issues; they are not implementation prerequisites after their evidence is retained.
• Define the local Workspace host topology #346 closes when 📝 Specify retained workflow Workspaces #358 merges.
• Spike: make Worker Shell effects transactional with the workflow journal #357 is the only remaining topology-adjacent experiment. Failure excludes Worker Shell from the first release; it does not block the declarative Workspace.

Current implementation path

#305 props namespace → #290 shipped planning logic

#341 run + expansion identity
        + #358 contract
        + #350 Deno/DOFS foundation
                ↓
              #218 implicit Workspace, lifecycle, replay and local transactions
                ├→ revised #293 Repository + named Worktree lifecycle
                ├→ revised #291 SQLite journal/history/checkpoint/fork storage
                ├→ revised #302 read-only Agent + generated-XMD authority
                └→ revised #294 Git.Add + Git.Commit local effects

#297 external reconciliation → revised #295 PullRequest + #296 Issue

all document/runtime effects → #292 synchronize this living target → #301 compose → #299 certify

Relevance audit

• Still relevant without a contract change: Reject secrets before journal persistence by default #199, Prove the shipped adversarial-planning document logic #290, Synchronize the #181 living target with settled XMD contracts #292, Add a deterministic provenance-linked Issue workflow effect #296, Add shared external forge-effect reconciliation #297, Certify the adversarial implementation workflow end to end #299, Compose the supervised adversarial implementation workflow #301 and Namespace Markdown props under the props binding #305.
• Still relevant but must be rewritten against 📝 Specify retained workflow Workspaces #358:
  • Store WorkflowRuns and filtered journals in SQLite #291 must stop using refs/xmd/runs as the authoritative ledger and instead own the SQLite lifecycle/history/checkpoint/fork slice described by the spec.
  • Add named Repository and Worktree composition #293 must stop assuming one workflow-owned worktree from the definition's pinned commit and instead implement named Repository primary checkouts plus optional named Worktrees.
  • Add deterministic local Git workflow effects #294 must implement separate Git.Add and staged-only Git.Commit; an Agent no longer owns file mutation or supplies an authorized path set to Commit.
  • Add a deterministic PullRequest workflow effect #295 should initially return the request URL and follow the explicit Push/precondition contract; richer observations can remain internal or become a later surface.
  • Enforce read-only workflow Agent authority #302's product decision is now settled: workflow Agents are mandatorily read-only, inspect disposable read-only materializations and propose allowlisted XMD.
  • Contain filesystem access at the provider boundary #227 still matters for generated-XMD path authority and any host-backed reads, but workflow Agent mutation containment is now achieved by removing its write-back path.
  • Resume workflow runs from explicit durable signals #300 should become host scheduling around the explicit suspended/interrupted lifecycle. File watching and unattended arbitration are not prerequisites for the first resumable workflow.
• Superseded/closing: Define the local Workspace host topology #346 is superseded by the merged design decision once 📝 Specify retained workflow Workspaces #358 lands; Spike: bundle workerd into the compiled XMD host #347, Spike: host Cloudflare DOFS directly in Deno with SQLite and FUSE #349 and Spike: run Cloudflare Worker Shell and Worker JavaScript natively in Deno #351 end with their evidence PRs.

No implementation issue should independently re-decide Workspace explicitness, filesystem restoration, topology, Agent write authority or transaction granularity. Those changes now require an architecture/spec revision first.

[taras]

Worker Shell topology delta — INCLUDE

#357 / PR #362 resolves the final optional topology gate positively. One Worker Shell invocation satisfies one expansion → one effect → one SQLite transaction using an immediate outer transaction and shell_mutations savepoint. Success publishes mutations with the filtered result; every known failure path rolls mutations back and retains one failed result; a real host crash publishes neither. Effect identity plus a per-invocation token fences missing, foreign, completed, cancelled and stale Worker messages.

The initial local capability set therefore includes Workspace-scoped Worker Shell through just-bash and a Deno Worker. It still excludes Worker JavaScript, native subprocesses, writable FUSE and bundled workerd.

Production implementation moves to #363 with four constraints that are no longer open design questions:

1. One host-owned DOFS connection is authoritative per workflow database, and Workspace-local effect transactions execute serially on it.
2. Cancellation forcefully terminates CPU-bound Worker execution before rollback and failed-result publication; graceful-only shutdown is insufficient.
3. Every filesystem RPC remains fenced by effect identity and invocation token.
4. The existing journal security policy filters results before they enter the shared transaction boundary.

Updated path:

#350 Deno/DOFS foundation
  → #353 contained Worker Shell
  → #362 transactional proof
  → #363 production contextual process provider
  → #218 retained Workspace integration
  → #301 composition
  → #299 certification

PR #358 records the accepted architecture and observable contract. #357 closes when its evidence PR is accepted.

[taras]

Correction: spike evidence remains outside production main

PRs #350 and #353 were accidentally merged while their stack was being collapsed. PR #364 reverts both squash commits, restoring main exactly to its pre-spike tree. PR #362 remains an unmerged 20-file proof stacked on the #351 evidence branch.

The disposition is:

• 🔬 Spike: host Cloudflare DOFS directly in Deno with SQLite (#349) #350, 🔬 Spike: run Cloudflare Worker Shell and Worker JavaScript natively in Deno (#351) #353 and 🔬 Spike: make Worker Shell effects transactional (#357) #362 are reviewable implementation evidence, not production source shipped from main;
• their findings remain valid and continue to support the architecture decisions;
• Add transactional Worker Shell to workflow Workspaces #363 is the production Worker Shell implementation path; and
• Implement retained Workflow Workspace restoration #218 owns the production Workspace foundation.

Do not merge the spike source trees as prerequisites for #363. Production work consumes their measured contracts and may selectively adapt proven code under the repository's normal architecture and dependency rules.

[taras]

Adversarial Implementation issue reconciliation after #358

The authoritative production dependency map now lives in #218.

The retained Workspace foundation is sequenced as:

#291 WorkflowRun SQLite + filtered journal
  → #365 atomic Workspace mutation/root/journal transaction
  → #366 foreground start/resume + File vertical slice
  → #367 lifecycle/inspection/ownership
  → #368 versioned history forks

The missing production stories are now explicit:

• Commit Workspace mutations and journal results atomically #365 atomic Workspace transactions
• Add the xmd workflow start/resume filesystem vertical slice #366 start/resume filesystem vertical slice
• Add workflow inspection, cancellation, suspension, and deletion #367 inspection, suspension, cancellation, and deletion
• Add versioned workflow history checkpoints and forks #368 checkpoints and forks
• Evaluate Agent-generated XMD through a constrained allowlist #369 constrained Agent-generated XMD
• Add a deterministic Git.Push workflow effect #370 explicit deterministic Git push

Stale contracts were reconciled in #199, #227, #290–#295, #297, #299–#302. In particular, the plan no longer uses refs/xmd/runs, a single implicit worktree, writable Agents, a hidden push in PullRequest, or file-watcher arbitration as the initial continuation model.

#357 is closed with an INCLUDE verdict. PR #362 remains unmerged experimental evidence; #363 owns production Worker Shell after #365/#366. PRs #350 and #353 likewise remain unmerged evidence.