📝 Move the remote effects from owed to shipped

Seven capabilities merged under this document's base, and four of them change
what it may say in the present tense.

`<Git.Push>` and `<PullRequest>` are registered workflow-host components now
(#495, #500, #504), so they leave the unresolved inventory and join the built
list beside the composition and the local Git effects. Push publishes the
selected checkout's exact current branch and commit to the same branch at
canonical `origin`, with no props, no result, no force-push, no upstream change
and no implicit stage or commit. The pull request requires that Push's own
matching successful evidence and never publishes anything itself. Eight names
are host-registered; two — `<Expand>` and `<Issue>` — still resolve to nothing.

The upsert is settled, and this markup does not reach it. Without a number
`<PullRequest>` asks for one to exist; with a number it asks for that one to say
this. A revision iteration commits again, so the head it asks about is not the
head the existing pull request holds, and an unnumbered request over an open
pull request saying anything else is a deliberate conflict. Carrying the bound
number into the next iteration is a composition this document cannot write
today, so the markup stands and the gap is recorded under #301 rather than
spelled by guesswork.

#497 shipped the evaluator, for observation. Complete preflight inside the
admission, pinned identities that consult no directory or bundle, exact request
ceilings, one retained decision, and a continuation held to the ceilings it was
admitted under. What it does not admit is file mutation — so the prose that had
`<Expand>` publishing each admitted `<File>` now says which half is built, and
`<Expand>` itself stays a documented placeholder #369 owes.

#498 shipped explicit history forks, so forkability stops being described as
absent: `history --forkable` adds its two columns, and lineage, reasons,
changed-definition replay admission and retained Workspace-root copying come
with it. A run continuing another run's history is still a different thing from
an Agent provider continuing a session, and nothing schedules either.

A `<Test>` declares its own timeout (#503), so twenty seconds is a default
rather than a ceiling. The two comments that justified the TypeScript proof by
that ceiling now give the reason that actually holds: a stub provider makes the
whole twenty-call trace observable in under a second, where a long ACP scenario
would take longer to prove less. `<Execution host="run">` (#501) is inherited
and unmentioned — no document here discusses nested root execution.

Author: taras

scripts/tests/adversarial-planning-workflow.test.ts

@@ -2,11 +2,15 @@
  * #290 criterion 6 — an exhausted planning loop.
  *
  * `Planning` declares `<Loop name="planning" max={5}>`, so exercising every
- * failing iteration costs twenty agent turns in one invocation. That does not
- * fit the fixed twenty-second `<Test>` timeout when each turn is an ACP round
- * trip, so the run happens here instead: the real `Planning` component, one
- * execution, one contextual working directory, and a synchronous stub root
- * Agent provider in place of the transport.
+ * failing iteration costs twenty agent turns in one invocation. A `<Test>` can
+ * declare its own timeout (#503) and twenty seconds is only the default, so the
+ * bound is not what decides this. What decides it is the evidence: the run
+ * happens here because the stub root Agent provider makes the complete
+ * twenty-call trace and the authorization boundary directly observable, and
+ * finishes in well under a second. A long ACP scenario would take longer to
+ * prove less. So: the real `Planning` component, one execution, one contextual
+ * working directory, and a synchronous stub root Agent provider in place of the
+ * transport.
  *
  * Nothing about the document under test changes. The component resolves from
  * the workflow directory exactly as `xmd test` resolves it, including the

specs/adversarial-implementation-workflow.md

@@ -290,8 +290,9 @@ source that performed it, the implementor's report, and the pull request's
 identity. A verdict describes that head alone, and a moved head requires a fresh
 review.
 
-`<PullRequest>`'s creation result is deliberately minimal: stable provider
-identity, number, URL, state, head SHA and base SHA (#295). Existing reviews,
+`<PullRequest>`'s result is deliberately minimal: filtered Repository identity,
+stable provider identity, number, URL, open state, head SHA and base SHA (#295,
+shipped). Existing reviews,
 comments and check results are separate reads rather than fields on a creation
 result that would otherwise claim to stay fresh against a remote that keeps
 changing. **That read is `<Fetch>`'s** (#456, shipped): a document reads over
@@ -495,19 +496,24 @@ explicit composition rather than one implicit workspace:
   unresolved, which says which host ran the document rather than whether the
   component exists.
 - `<Git.Switch>`, `<Git.Add>` and staged-only `<Git.Commit>` operate on the
-  contextual checkout as Workspace-local durable effects (#294). `<Git.Push>` is
-  explicit and separate (#370), and `<PullRequest>` requires that pushed head
-  rather than performing a hidden push (#295).
+  contextual checkout as Workspace-local durable effects (#294). `<Git.Push />`
+  is explicit and separate (#495, shipped): it publishes the selected checkout's
+  exact current named branch and commit to the same branch at canonical
+  `origin`, with no props, no result, nothing rendered, no force-push, no
+  upstream change and no implicit stage or commit. `<PullRequest>` requires that
+  Push's own matching successful evidence rather than performing a hidden push
+  (#295, shipped).
 - `<Issue>` reconciles an approved deferred finding (#296), over the shared
   external reconciliation of #297.
 
 Each environmental operation declares its inputs and preconditions, reconciles
 existing state, returns a structured result, and records its observed effects. A
 result is a structure, never a string standing in for one: `<PullRequest>`
-resolves stable provider identity, number, URL, state, head SHA and base SHA, and
-a stage that declared any of that as text would fail its own return validation
-after the effect had already happened. Rerunning a pull-request operation
-resolves the existing pull request rather than creating a duplicate, through the
+resolves filtered Repository identity, stable provider identity, number, URL,
+open state, head SHA and base SHA, and a stage that declared any of that as text
+would fail its own return validation after the effect had already happened.
+Rerunning a pull-request operation resolves the existing pull request rather than
+creating a duplicate, through the
 effect's natural key as well as its stable identity (#297).
 
 `<Git.Commit>` journals reconciliation evidence — repository and worktree
@@ -632,9 +638,12 @@ The wait is built too: `suspendFor()` suspends a run durably and gives its
 executor lock back (#367), and a typed answer can be delivered to it (#300).
 What is not built is anything that reaches or acts on it — no v1 Markdown
 element spells the operation, this workflow calls nothing that suspends,
-delivery executes nothing, and no scheduler resumes a run. Versioned history
-checkpoints, compatible forks, `history --forkable`, and forkability reasons
-remain #368.
+delivery executes nothing, and no scheduler resumes a run. Versioned history checkpoints, compatible forks,
+`history --forkable`, forkability reasons, lineage, changed-definition replay
+admission and retained Workspace-root copying are shipped (#368, delivered by
+#498). A fork is an explicit new run continuing one run's retained history; it
+is not an Agent provider continuing a session, and nothing schedules or resumes
+either.
 
 **Still missing: who answered.** The journal records the validated decision, the
 question fingerprint, and the document execution it belongs to. It does not
@@ -874,8 +883,10 @@ The exercise succeeds when:
 7. The run composes a named Repository and Worktree from its pinned base before
    discovery; the change reaches that worktree as admitted generated XMD rather
    than as agent writes, and validation evidence is recorded.
-8. `<Git.Add>`, `<Git.Commit>`, and an explicit `<Git.Push>` precede
-   `<PullRequest>`, and none of them is implied by another.
+8. `<Git.Add>`, `<Git.Commit>`, and an explicit `<Git.Push />` precede
+   `<PullRequest>`, and none of them is implied by another: the pull request
+   requires the run's own matching successful Push evidence and never publishes
+   anything itself.
 9. The planner reviews the resulting pull request, and implementation and
    review repeat when the verdict fails.
 10. The user decides whether to accept the completed change.
@@ -978,18 +989,20 @@ The exercise must resolve enough of these to implement one vertical slice:
 1. What bounded request/result loop lets an Agent observe the repository at all,
    given that it receives no checkout, no materialization, no working directory
    and no registered directory (#302, #369)?
-2. What is the public spelling and response schema of the constrained
-   generated-XMD evaluator, and which components does the first allowlist admit
-   (#369)?
-3. What state makes external effects safe to repeat or resume after
-   interruption, and how does a revision iteration reach the *same* pull request
-   rather than a second one — expansion identity alone cannot answer it, so the
-   effect's natural key has to, and a head that deliberately advanced on the same
-   branch must be distinguishable from a conflicting one (#295, #297)?
-4. Which fetches does a review actually write? `<PullRequest>`'s creation result
-   is deliberately minimal, and `<Fetch>` (#456) is how a network-denied reviewer
-   is handed the rest — but no stage composes those reads yet, and admitting
-   `<Fetch>` inside generated XMD stays #369's.
+2. What is the public spelling of the component a document writes to expand
+   constrained generated XMD, and what does a *mutating* fragment's admission
+   require (#369)? The evaluator itself is settled and built for observation
+   (#497): complete preflight inside the admission, pinned identities, exact
+   request ceilings, one retained decision, and replay held to it.
+3. How does a revision iteration reach the *same* pull request? The effect is
+   settled (#295, #500, #504): an unnumbered invocation asks for one to exist
+   and a numbered one asks for that exact open pull request to say this. What is
+   unsettled is the composition — a loop whose first iteration has no number to
+   carry and whose later iterations do (#301).
+4. Which fetches does a review actually write? `<PullRequest>`'s result is
+   deliberately minimal, and `<Fetch>` (#456) is how a network-denied reviewer is
+   handed the rest — but no stage composes those reads yet, and the public
+   component that expands a fragment carrying one stays #369's.
 5. Which host mechanism closes the validate-then-use race for each supported
    runtime, now that a run-owned Workspace resolves a document path without
    producing a host path at all (#227)?

specs/markdown-agents-vision.md

@@ -197,10 +197,11 @@ supplies the run around them: `xmd workflow start` creates a workflow run with
 one retained Workspace and `xmd workflow resume` continues it from the retained
 journal (#366, shipped). The composition inside that run is there too: named
 `<Repository>`, `<Worktree>` and lexical `<Dir>` are registered by the workflow
-host (#293, shipped). What it still lacks are the durable effects — deterministic
-local Git effects (#294), explicit `<Git.Push>` (#370), `<PullRequest>` (#295),
-and `<Issue>` (#296) — none of which is built. Together they cover the work that
-should not depend on model judgment:
+host (#293, shipped). The durable effects are there too: deterministic
+local Git effects (#294), explicit `<Git.Push>` (#495), and `<PullRequest>`
+(#295) are all registered by the workflow host. `<Issue>` (#296) is the one that
+is still not built. Together they cover the work that should not depend on model
+judgment:
 
 - retain each handoff, plan, review, and decision as a filtered journal event
   bound to the Workspace root current when it was written;
@@ -214,9 +215,13 @@ should not depend on model judgment:
 - record the inputs, observed state, effects, and outputs of each operation.
 
 Agent calls analyze evidence and propose changes; they do not perform them. Under
-a workflow run an Agent is read-only, and a proposal reaches the Workspace as
-generated XMD that a constrained evaluator preflights and expands as ordinary
-durable effects (#302, #369). Deterministic components apply approved
+a workflow run an Agent reaches no checkout at all, and a proposal reaches the
+Workspace as generated XMD that a constrained evaluator preflights completely
+and expands as ordinary durable effects. That evaluator is built for observation
+(#497) — pinned identities, exact request ceilings, one retained admission — and
+what is still owed is admission for a mutating fragment, the bounded
+request/result loop an Agent observes the repository through (#302), and the
+public component a document writes to reach either (#369). Deterministic components apply approved
 environmental changes and provide exact required content to the next call.
 Generated files are optional exports rather than the handoff protocol. This
 removes manual copying between agent-owned transcripts, plan files, and working