@defrex/autobuild 0.8.0 → 0.9.0

package/README.md

@@ -67,7 +67,7 @@ usable on your machine.
 <!-- release-install:start -->
 
 ```sh
-bun add -g @defrex/autobuild@0.8.0
+bun add -g @defrex/autobuild@0.9.0
 ```
 
 <!-- release-install:end -->

package/SPEC.md

@@ -218,10 +218,12 @@ Small, independently runnable, crash-safe:
   repo, so re-running `ab dispatch` resumes durable work rather than only
   looking for new tickets. Every ordinary tick also completes queued dispatch
   records whose pre-run sequence was interrupted: it reconstructs a missing
-  `build.created` from the immutable record, executes only missing workspace,
+  `build.created` from the immutable record (only records an older dispatcher
+  left with an empty stream: new claims write it atomically with the record), executes only missing workspace,
   spec, and ticket-notification boundaries, and records each failed attempt as
   `dispatch.failed`. `build.created` retains any claim-time auto-merge
-  attribution until its human-authored command fact is materialized, while
+  attribution and the sampled default fact's seq until the human-authored
+  command fact is materialized, while
   `dispatch.comment-posted` prevents retries from duplicating the ticket notice.
   It also owns observation back-pressure: settling
   outstanding recoverable harvest runs takes priority over starting new scans
@@ -386,6 +388,27 @@ raises an `escalation`; a human uses `ab answer --revise-spec` (or
 `--revise-spec-from-ticket`), the spec gets rev N+1, and the build restarts
 from `plan` (cheap — downstream was invalidated anyway).
 
+**Ticket assets are frozen with the spec.** Claiming a ticket pins the
+ticket's current assets (§7.1.3) into the build the same way the spec becomes
+revision 0: `build.created.assets` lists exactly which `(kind, name, revision)`
+the build sees, omitted when the ticket has none. The set is sampled
+immediately after the claim succeeds and before spec authoring, and it is
+written atomically with the build record (`createBuild` takes the initial
+`build.created` event), so an edit made while a spec is being authored, or a
+crash between the two writes, can never change or lose the pin; interrupted
+dispatch recovery re-reads it from the log. Attaching, replacing, or removing
+an asset afterwards leaves the running build alone, because a build reads its
+assets by pinned revision, never "latest". `ab ticket attach` and `asset rm`
+warn when the ticket has an active build. Revising the spec **from the ticket**
+(`ab answer --revise-spec-from-ticket`) re-pins the ticket's then-current
+assets together with its body, as `spec.revised.assets` (present, possibly
+empty, means "re-pin to this set"); the set is sampled once, when the body is
+read, and recorded on the `escalation.answered` authorization too, so a retry
+after a crash publishes the originally authorized set. Revising from a supplied
+body file leaves the pinned assets unchanged. The one case this cannot cover is
+a record an older dispatcher created with an empty stream: recovery can only
+sample the ticket's current assets for it.
+
 ## 7. The build store
 
 The v1 repo-bloat and no-observability problems share one root cause: the
@@ -407,6 +430,8 @@ artifacts    build_id, kind, revision, blobRef, metadata
 repo_streams repo, created/updated, lease + heartbeat
 repo_events  repo, seq, timestamp, actor, type, payload (JSON) — append-only
 repo_artifacts repo, kind, revision, blobRef, metadata
+ticket_assets repo, ticket_id, kind, name, revision, layout, manifest (JSON), size,
+             removed, created — one row per revision
 ```
 
 #### 7.1.1 Operator sessions (the third resource kind)
@@ -464,6 +489,141 @@ over the remote protocol the read is
 stream read's ([docs/remote-store-protocol.md](docs/remote-store-protocol.md),
 §5).
 
+#### 7.1.2 The embedded orchestrator (turns)
+
+The orchestrator is the agent that files tickets, watches builds, unblocks
+them, and discusses direction — played in the hosted service by a stateless
+turn runner over the operator tool registry, not by an agent living in a
+sandbox (parity with MCP; no credential plumbing) and not by an external
+workflow engine (durability comes from the store; the tick pattern already
+exists). Posting a message to a session of an enabled repository starts a
+turn in the same invocation: an AI SDK tool-loop agent, running with the
+registry bound in process, reads the conversation from the session's durable
+state, streams its output as protocol parts onto the turn's session-scoped
+stream (§7.6), calls tools with the operator's attributed identity — the
+session operator as the human actor, `via: {kind: "session", id}` —
+checkpoints as it goes, and completes or suspends.
+
+**Turn lifecycle.** `turn.started` (naming a new session-scoped stream and
+the trigger — a message or a wake) → running → either `turn.completed`
+(with input/output token usage and the step count), `turn.suspended`
+(cause `budget` or `approval`), or typed `turn.failed`. A suspended turn
+resumes via `turn.resumed` — the sole resume fact, recorded by the runner
+when it actually picks the turn up; `approval.answered` only clears the
+pending approval, so an answered approval whose resuming invocation died
+stays recoverable. The stream stays open across a suspension and is the
+resume checkpoint; it closes `completed` or `aborted` at the outcome.
+Conversation state is reconstructed from durable state alone — the finalized
+artifacts of earlier turns, the live stream of the open turn, and the session
+events — so a turn resumed in a fresh invocation continues from the last
+checkpointed step with identical model input; no process memory survives
+between invocations. A turn's assembled messages attach at its `turn.started`
+event, so a message posted during a suspension reads as the next user message
+after the checkpoint, never interleaved into it.
+
+**Budget suspension.** `[orchestrator].invocationBudgetSeconds` (default 240,
+clamped to the 300-second hosted function limit) bounds one invocation. When
+elapsed time approaches the budget — or a hard abort at the deadline
+interrupts a runaway step — the runner records `turn.suspended` cause
+`budget` and ends the invocation; a new invocation resumes it within 60
+seconds (immediately when the service can self-trigger, otherwise on the
+next dispatcher tick). The dispatcher tick's orchestrator step runs LAST,
+after every build stage, against min(configured, remaining tick budget) with
+a 30-second floor: it can only consume slack, and skipping is always safe
+because suspension state is durable.
+
+**Approval suspension.** A call to a tool named in
+`[orchestrator].approvals` records `approval.requested`, emits the protocol's
+tool-approval-request part, and suspends the turn with cause `approval`. An
+`approve` answer resumes the turn and executes the call; a `deny` answer
+resumes it with a denied tool output. Tools not on the list run without
+pause. Entries are `tool` or `tool:qualifier`; an entry naming an absent or
+unknown tool is inert by design.
+
+**Wake rule.** The dispatcher tick's orchestrator step wakes each idle
+session with non-empty wake settings: it scans the repository's builds for
+build events after the session's per-build wake cursor and the repository
+journal for events after the session's journal wake cursor — both filtered
+by the same compiled settings, which may name build event types,
+repository-journal event types, or both — and starts one turn per session
+per tick with a `wake` trigger naming the winning event's source: the build,
+seq, and type for a build-log wake, or the journal flag, seq, and type for a
+repository-journal wake. A build wake delivers the event record and the
+build's reduced state — frozen into the `turn.started` fact — as the turn's
+input; a journal wake delivers the event record only (the turn's operator
+registry already exposes bounded repository reads). Each source's cursor
+advances only through a recorded trigger naming that source, so a crash
+between scan and start cannot skip or duplicate a wake, and other builds' —
+and the journal's — matching events re-trigger on later ticks. Sessions with
+empty wake settings are never woken. The default wake settings span both
+halves of the attention set: the build events `ab watch` filters on by
+default plus the repository-journal events `ab watch --repository` follows.
+
+**Crash recovery.** A turn invocation that dies without an outcome leaves the
+session `running` with a silent open stream; the tick's reaper fails such a
+turn (`turn.failed`, kind `internal`) after 15 minutes of stream silence,
+closing the stream `aborted` and leaving the session `idle`. The reaper never
+touches suspended or awaiting-approval sessions — a turn suspended for
+approval is precisely an open stream that goes quiet for however long the
+operator takes.
+
+**Typed failures.** Model failures are typed on `turn.failed`:
+`provider-unavailable`, `exhausted`, `credentials`, `configuration` (plus
+`internal` for non-model failures) — never retried unboundedly; a failed
+turn leaves the session `idle` with the error class visible in the session's
+reduced state.
+
+**Opt-in guarantee.** The whole feature is off unless a repository's
+effective config enables it, and it is doubly gated: the tick step is
+constructed only in origin mode (a local `ab dispatch` never constructs it —
+enabled = true in a local autobuild.toml lists no sessions, builds no
+registry, and calls no model), and in origin mode it returns immediately
+unless the effective config enables the orchestrator. The system prompt is
+the canonical `ab-operate` skill shipped in `skills/operate/` — self-contained
+per the vendored-skill rule, teaching the tool surface, the attention set,
+and when to escalate to the operator rather than act — plus the current
+`operator-notes` artifact, the session's wake settings, and the session's
+repository identity. The model never supplies a repository argument: the
+tools' model-facing schemas strip `repo`, and the runner injects the
+session's repository before the registry re-validates. A message posted
+while a turn is open is durable and enters the conversation at the next
+resume or turn — no second turn, no concurrent turns, no subagents.
+
+#### 7.1.3 Ticket assets
+
+A **ticket asset** is a named, versioned bundle of files attached to a ticket —
+a design export, a reference screenshot, a sample payload — that shapes a change
+but belongs neither in the repository (where it goes stale once the change
+ships) nor in the ticket tool (which build agents cannot reach). It is keyed by
+`(repo, ticketId, kind, name)` and works identically whichever ticket source is
+configured. It is a fourth resource family beside builds, repository journals,
+and sessions, but a deliberately thin one: no event log, because nothing here
+needs reduction, and no retention pruning, because assets live as long as the
+ticket's other durable data and never expire on their own.
+
+Each put creates a new 0-based **revision**; earlier revisions stay retrievable.
+An asset is a `file` (exactly one file) or a `tree` (a folder: its root is
+implicit, so a tree with zero entries is a valid empty folder). The manifest is
+a list of entries — `file` entries with size and content address, and `dir`
+entries so empty directories survive. File bytes live in the `BlobStore`; the
+database holds only the manifest, the same rule as artifacts. **Removal is a
+tombstone**: a row taking the next revision number with an empty manifest. The
+latest row decides liveness, so the default read and list skip a removed asset,
+while an explicit earlier revision stays readable — a build that pinned revision
+N keeps retrieving it. Re-attaching after a removal takes the next revision, so
+revision numbers may skip the tombstone.
+
+Every adapter runs one shared validator before any write. `kind` and `name` are
+`[A-Za-z0-9._-]+` and at most 64 characters, so they are safe to print in a
+command line. Entry paths are relative, `/`-separated, with no empty, `.`, or
+`..` segment, at most 256 bytes each and 128 per segment, with no duplicates and
+no file as an ancestor of another entry. A revision holds at most 1000 entries
+(files plus directories) and **25 MiB** of file bytes; a larger put is refused
+with an error that names the limit, and nothing is stored. A remote deployment
+may advertise a lower effective limit (§7.2): a platform that rejects oversized
+request bodies before application code runs cannot rely on server-side
+validation alone, so the client enforces the advertised limit before uploading.
+
 ### 7.2 Interface and adapters
 
 Deliberately narrow: build runners need `append(event)`, `putArtifact`,
@@ -476,11 +636,23 @@ snapshot or side ledger. Sequence 0 names an empty stream, candidates receive
 ordinary event validation, unknown builds reject, and a comparison miss leaves
 the log and build timestamps untouched.
 The same contract has repository-scoped `ensureRepo`, event/artifact deposit
-and read methods, plus a repository lease. Before execution, a runner obtains
+and read methods, plus a repository lease. Ticket assets (§7.1) add
+`putTicketAsset`, `getTicketAsset` (latest live revision, or an explicit
+revision), `listTicketAssets` (summaries without manifests: the latest live
+revision per kind and name, or every real revision), `removeTicketAsset`, and
+`ticketAssetLimits(repo)`, the effective ceilings the store accepts. Scoped
+build and session handles reject all of them. Before execution, a runner obtains
 an interface-enforced handle scoped to exactly its build. Own-build records,
 stream, artifacts, lease, and subscription remain available; another build,
 collection/admin operations, nested foreign scope, and every repository-journal
-operation reject. This guard applies identically to every adapter; remote tokens
+operation reject. The one ticket-asset read a build handle keeps is
+`getPinnedTicketAsset(slug, kind, name, rev?)`: the asset as that build froze it
+(the latest pinned revision, or any revision the build ever pinned), found by
+reducing the build's own events and then reading that exact revision. It needs
+no lease, so it answers for a finished build, and remote build tokens reach it
+through `GET /builds/:slug/ticket-assets`. `createBuild` optionally takes the
+build's initial `build.created` event and appends it as seq 1 in the same atomic
+step as the record on every adapter. This guard applies identically to every adapter; remote tokens
 carry the same authority over the wire as defense in depth rather than creating
 it. Two implementations of one contract (`packages/core/src/store/contract.ts` is the shared
 conformance suite):
@@ -515,6 +687,27 @@ conformance suite):
 `subscribe` is specced in the interface; the v2.0 implementation is polling
 `getEvents(since)`. True push comes later.
 
+Operator UIs additionally have a repository-scoped batch read,
+`getRepoBuildDigests(repo)`: the projection of every build's log onto its
+terminal fact, its `observation.recorded` occurrences with their event
+timestamps, and the ts of its latest `pr.merged`, derived from the event log on
+each call. It lets a dashboard snapshot count unclaimed observations and gate
+rows without reading the full history of finished builds (§16.1), and it backs
+the harvest-launch pressure gate (dispatcher and harvest runner alike): launch
+decisions evaluate from digests and the repository journal alone, so
+gate-evaluation cost is flat in accumulated build history, with the full
+per-build scan paid only when a gate actually trips and a scan packet is built.
+
+Stateless repository-level readers also have a bounded journal read,
+`getRepoStateEvents(repo)` (AUT-489): every durable, slow-growing event type
+(all harvest facts, operator-sandbox facts, and the three dispatcher setting
+types) plus, when the journal has one, the tail from the latest
+`dispatcher.run-started`. Reducing this subset with the state readers yields
+exactly what a full replay yields, so the cost of reading repository state no
+longer grows with the number of past dispatcher invocations. The journal
+itself stays append-only: full replay remains the normative truth, and
+`ab watch` still sees every recorded fact.
+
 ### 7.3 Persistence granularity
 
 Required phase outputs persist at **phase/round boundaries**; a killed phase
@@ -782,11 +975,19 @@ A phase-scoped hydration into the gitignored scratch dir:
   findings.json     # current feedback, when round > 1
   history/          # prior-round artifacts where the phase needs them
   verify/           # failure reports routed back to implement
+  assets/           # the ticket assets the build froze (§6.3), every phase:
+                    #   assets/<kind>/<name>/…, folders keep their trees
 ```
 
 The manifest tells the agent its contract — `required` deposits and
 `allowedTerminals` — so skills are self-checking against the same data the
-CLI validates with. Per-phase inputs and terminals:
+CLI validates with. When the build pinned ticket assets, every phase also gets
+them under `.ab/assets/<kind>/<name>/` and the manifest lists each as
+`assets: [{kind, name, revision, layout, size, path}]`; a `file` asset is the
+single file inside its directory. A build with no assets gets no `assets` key
+and no directory. `ab build asset get <slug> <kind> <name> <dest>` downloads a
+pinned asset by build, also after the build has finished. Per-phase inputs and
+terminals:
 
 | Phase | Materialized inputs | Terminal |
 |---|---|---|
@@ -817,7 +1018,7 @@ Provider/runtime-declared turn failures are a separate `AgentRunner` result
 alternates, availability failures (overload, rate limit, 5xx, timeout,
 transport, and unclassified provider failure) and provider exhaustion (quota,
 usage limit, and billing) start the next target inside the same phase attempt.
-Authentication, permission, and local runtime-configuration failures do not.
+Authentication, permission, and local runtime-configuration failures do not, with one exception: a runtime whose CLI executable is not installed is skipped like any other eligible failure, so the phase runs on the first declared target whose CLI is present. An unsupported installed version is still a stopping configuration failure. If no target's CLI is installed, the chain ends in one non-retried `configuration` failure carrying the last target's missing-CLI message.
 Each failed target's transcript is deposited. Only a stopped or exhausted chain
 emits one `phase.failed` with the final provider message verbatim; that final
 failure controls retry policy. Provider exhaustion skips the retry budget and
@@ -867,7 +1068,12 @@ A no-op step has no push. Agents only ever commit locally. Consequences: forge
 credentials **never enter the sandbox** (load-bearing once builds run on
 remote sandboxes), history is extended rather than force-pushed, and the
 push-at-boundary rule from [D3] is enforced by construction rather than
-convention.
+convention. The same rule bounds the orchestrator's small fixes: an operator
+sandbox publishes work only through the `sandbox.publish` tool, whose push and
+PR creation are kernel-side plumbing executed by the sandbox service through
+the workspace provider's publication capability — the only publication path
+from an operator sandbox, always to a dedicated operator branch and a pull
+request, never to the base branch.
 
 ### 8.7 Walkthroughs
 
@@ -912,7 +1118,8 @@ implementer:  ab context   (findings.json now materialized) → …
 ### 8.8 Outer-loop namespace
 
 Human/pre-build ticket grooming uses one configured-source namespace
-(`ab ticket create|update|block|unblock|list|show|move`). These commands are
+(`ab ticket create|update|block|unblock|list|show|move`, plus the ticket-asset
+forms below). These commands are
 sessionless, source-agnostic, and never available as a mid-build spec
 mutation path. Every subcommand accepts `--json` and then writes exactly one
 bare value: `list` emits `Ticket[]`; every other form emits the complete
@@ -929,6 +1136,27 @@ creates tickets directly in its ready state must therefore create a dependency
 chain in dependency order, carrying each predecessor id into the next create,
 before a later ticket can be claimed.
 
+**Ticket assets** (§7.1) attach files to a ticket without touching the ticket
+source's storage:
+
+- `ab ticket attach <id> <kind> <path> [--name <name>] [--store <ref>] [--json]`
+  stores a file or a whole folder (its relative tree preserved) as an asset.
+  `--name` defaults to the path's basename. Attaching again under the same kind
+  and name creates a new revision. The CLI asks the source first, so an unknown
+  id stores nothing; it refuses symlinks and non-regular files, and refuses a
+  bundle over the store's limit from `stat` sizes before reading any bytes. The
+  store write precedes the note: if the note then fails, the error says the
+  asset was stored as revision N, and the write is not rolled back.
+- `ab ticket asset get <id> <kind> <name> <dest> [--rev <n>]` writes the exact
+  bytes of the latest (or a named) revision: a file asset to `<dest>` (or into
+  `<dest>` when it is an existing directory), a folder asset into the directory
+  `<dest>`, empty directories included. Stored paths are re-checked against
+  traversal on write.
+- `ab ticket asset rm <id> <kind> <name>` removes it from the ticket's current
+  assets; revisions a build has pinned stay retrievable.
+- `ab ticket show <id>` lists the current assets (kind/name, revision, size);
+  with `--json` the `Ticket` is extended with an `assets` array.
+
 Observation harvest uses a separate typed, repository-scoped namespace
 (`ab harvest context|submit|verdict|status`), mirroring the build session
 commands: context hydration, a producer terminal, a reviewer terminal, and a
@@ -936,7 +1164,7 @@ sessionless read-only status projection.
 
 `ab repository status [--json] [--store <ref>]` is the sessionless read-only
 projection of the repository journal's dispatcher controls: ticket intake, the
-repository-wide pause, and the claim-time auto-merge default. It uses the same
+repository-wide pause, and the auto-merge default. It uses the same
 dispatch-settings reducer as dispatcher decisions and the dashboard. An absent
 repository stream reduces as an empty journal and reports intake on, repository
 pause off, and auto-merge default off; the query does not create that stream,
@@ -990,6 +1218,9 @@ distinction from `no-terminal`. `failure.message` preserves provider text and
 and local runtime configuration. `permanent` remains the retry-policy and
 legacy-plugin compatibility bit: exhaustion and credential/configuration
 failures are permanent, while availability uses existing bounded retry. A
+`configuration` failure flagged `missingExecutable` (the runtime's CLI is not
+installed) is the one configuration failure that is alternate-eligible; it is
+still permanent and never retried. A
 legacy plugin may omit `cause`; `permanent: false` remains alternate-eligible
 and `permanent: true` remains a stopping failure. A failed `start` still returns
 an endable session handle, guaranteeing transcript deposition.
@@ -1078,7 +1309,8 @@ deterministic fail-safe.
   runtime touches only the adapter registry, never the kernel. Mixing models
   across roles is intentional — a different reviewer catches more. The
   Within one agent-session attempt, eligible failures try the primary then each
-  alternate in order without spending another phase attempt. Each target has a
+  alternate in order without spending another phase attempt. A runtime whose CLI executable is not installed is skipped the same way;
+  credential, permission, and other configuration failures stop the chain. Each target has a
   fresh session bracket. A failed producer continuation may therefore continue
   on a different runtime only by rehydrating durable context, not by inheriting
   the failed conversation. Selection is non-sticky: every later phase, loop
@@ -1204,6 +1436,10 @@ escalation after an exhausted failed verify report feeds `implement`, where its
 guidance outranks
 the pending report.
 
+Answering with `--revise-spec-from-ticket` also re-pins the build's ticket assets
+(§6.3): the sampled set rides on the answer and on `spec.revised`. A supplied
+body file changes the spec only.
+
 Only an operator answering an open `review-round-limit` policy escalation may
 set `escalation.answered.reviewRoundCeiling`. The same event both clears the
 human gate and replaces the cap; no standalone or pre-emptive form exists. A
@@ -1366,6 +1602,16 @@ posted as a comment, final summary, status transitions) flow outward only.
 This keeps the abstraction honest: a file-based TicketSource with nowhere to
 put blobs must be fully workable.
 
+**Ticket assets follow the same rule.** The contents of a ticket asset (§7.1)
+live in the BuildStore and the ticket source never stores them. Attaching,
+replacing, or removing an asset instead leaves a note on the ticket through the
+existing `comment()` port — the outward projection every source, including the
+plugin surface, already supports. The note names the asset, its revision, file
+count, and size, and gives the `ab ticket asset get` command that fetches it, so
+a person reading the ticket in Linear, the hosted service, or a local file knows
+the asset exists. The note is a projection outward only; nothing reads it back,
+and no TicketSource port or plugin-protocol change is needed.
+
 **Claim lifecycle.** Claim acquires nonterminal work: it returns `true` and
 moves a claimable ticket to the source's claimed state. It returns `false` for
 an unknown ticket, an already-claimed or contested ticket, and a ticket that
@@ -1455,12 +1701,15 @@ signal, and error evidence. `--plain`, non-TTY,
 and `--once` kernel semantics remain the line-oriented/direct compatibility
 path; `--once` still performs one tick and drains its in-flight work.
 
-Durable operator settings (intake, the repository-wide pause, the claim-time
-auto-merge default, the harvest gate) are repository-journal facts: they
-survive restarts, propagate between dispatchers by ordinary polling, and are
-never optimistically rendered — the UI shows acknowledged state. The
-repository-wide pause holds every queued build: while it is set, no dispatcher
-tick may attach a runner to a build that does not have one yet.
+Durable operator settings (intake, the repository-wide pause, the auto-merge
+default, the harvest gate) are repository-journal facts: they survive restarts,
+propagate between dispatchers by ordinary polling, and are never optimistically
+rendered — the UI shows acknowledged state. The repository-wide pause holds
+every queued build: while it is set, no dispatcher tick may attach a runner to
+a build that does not have one yet. The auto-merge default both seeds new
+claims and, on each change, fans out onto every current non-terminal build of
+the repository as a bulk request or withdrawal attributed to the toggling
+operator (§15.7).
 
 The **operator sandbox** is the third execution kind beside build and harvest
 executions: a persistent, credential-free, per-operator-per-repository
@@ -1473,7 +1722,11 @@ is repository-journal fact: provisioned/resumed/activity/stopped/released facts
 bracket one deterministic environment per operator × repository, the
  dispatcher tick's idle settlement stops an environment whose evidence is
 stale (settling an orphan exactly as harvest executions are settled), and
-`ab repository status` reports each operator's sandbox.
+`ab repository status` reports each operator's sandbox. An operator's work
+leaves the sandbox only through `sandbox.publish`, which takes the checkout's
+head (or an explicit commit) to a deterministic operator branch and a pull
+request against the base branch and records published/publish-failed journal
+facts.
 
 The operator's job across many concurrent builds: see status at a glance,
 act on a selected build, find blocked builds, answer escalations, and inspect
@@ -1587,9 +1840,9 @@ with illustrative members:
 
 | Family | Examples |
 |---|---|
-| Build lifecycle | `build.created`, `workspace.provisioned`, `workspace.released`, `execution.started`, `execution.ended`, `infrastructure.failed`, `infrastructure.cleanup-attempted`, `dispatch.comment-posted`, `dispatch.failed`, `runner.attached`, `runner.setup-failed`, `abort.remote-branch-deleted`, `abort.local-branch-deleted`, `abort.ticket-returned`, `build.completed` |
-| Operator commands [D2] | `build.pause-requested` → `build.paused`; `build.discard-requested`; `build.auto-merge-requested`; `escalation.answered` (optionally carrying a validated `reviewRoundCeiling`) |
-| Spec | `spec.imported`, `spec.authored`, `spec.revised` |
+| Build lifecycle | `build.created` (carrying `assets`, the claim-time pin, §6.3), `workspace.provisioned`, `workspace.released`, `execution.started`, `execution.ended`, `infrastructure.failed`, `infrastructure.cleanup-attempted`, `dispatch.comment-posted`, `dispatch.failed`, `runner.attached`, `runner.setup-failed`, `abort.remote-branch-deleted`, `abort.local-branch-deleted`, `abort.ticket-returned`, `build.completed` |
+| Operator commands [D2] | `build.pause-requested` → `build.paused`; `build.discard-requested`; `build.auto-merge-requested`; `escalation.answered` (optionally carrying a validated `reviewRoundCeiling`, or the `assets` sampled with a revise-from-ticket authorization) |
+| Spec | `spec.imported`, `spec.authored`, `spec.revised` (optionally carrying `assets`, a re-pin of the ticket's assets, §6.3) |
 | Sessions | `session.started`; `session.ended` with transcript ref and usage (ordinary completion — the analysis corpus), or `session.ended {outcome: reclaimed, reclaimedBy: {instance, resumedFromSeq}}` (explicit transcriptless takeover) |
 | Plan/code loops | `plan.started` … `plan-review.verdict`; `implement.started` … `code-review.verdict` |
 | Verify/finalize | `verify.started {step, attempt, feedback?}`, `verify.completed {step, outcome}`, `finalize.completed {pr}`, `finalize.step-completed {step, ok, headSha?}` |
@@ -1954,13 +2207,18 @@ Decisions here continue the series: **[D9]** declarative repo config and
 One declarative file at the repo root. A running dispatcher owns an accepted
 snapshot read from the **main checkout** and refreshes it before each dispatch
 tick. Before launch and after each accepted revision, the dispatcher deposits
-the composed snapshot into each affected build's artifact namespace. The child
-samples that durable artifact at setup and pipeline-step boundaries, so a valid
-change may affect the next action of an in-flight build but never interrupts an agent turn
-or deterministic command already running. Scoped phase CLI processes separately
+one composed snapshot into each affected build's artifact namespace: its
+build-owned sections come from the build's own branch, and its deployment- and
+dispatcher-owned sections from the live snapshot (the three ownership classes
+are defined below). The child samples that durable artifact at setup and
+pipeline-step boundaries, so a valid change to a deployment-owned section may
+affect the next action of an in-flight build but never interrupts an agent turn
+or deterministic command already running, and a change to a build-owned section
+never retargets an in-flight build at all. Scoped phase CLI processes separately
 read the build worktree's branch-owned file. Because the file is repo-versioned,
-changes still flow through the pipeline itself: once merged, the system can
-adopt a retuned configuration without restarting the dispatcher.
+changes still flow through the pipeline itself: once a build's own branch
+carries them, the system can adopt a retuned configuration without restarting
+the dispatcher.
 
 A missing or unreadable file and a malformed or routing-invalid candidate are
 rejected atomically: the last valid snapshot, resolver, and revision remain in
@@ -2072,6 +2330,35 @@ existing ticket table as factory config, and fails with the complete available
 name set when unregistered. Plugin-declared `requiredEnv` values are never TOML
 fields: secrets stay in the process environment or local `.env`.
 
+`autobuild.toml` sections belong to one of three ownership classes, which
+decide where a build's effective configuration is composed from:
+
+| Class | Sections | Source at deposit |
+|---|---|---|
+| Build-owned (pinned) | `[verify]` and `[verify.<step>]`, `[finalize]` and `[finalize.<step>]`, `[commands]`, `[workspace]` (provider and config, including `provisioning` and `runtimeProvisioning`) | The build's own branch: its branch head once it has published commits, otherwise the recorded base commit its workspace was cut from. The exact commit is recorded once per deposit in the effective-config artifact metadata — except in checkout mode when the worktree read cannot be attributed to the branch-head commit: because the worktree file has uncommitted edits, because the clean/dirty comparison could not be performed (non-git workspace or a transient git error), or because the branch head never carried the file. The deposit then records the source `worktree-dirty` and no commit, because no commit claims the worktree bytes (the build still runs them). |
+| Deployment-owned (live) | `[roles]` (runtime, model, args, alternates, per-role `sessionBudgetSeconds`) and `[policy]` (budgets, retry bounds, stall and harvest knobs) | The dispatcher's live snapshot; an accepted reload delivers these to active builds. |
+| Dispatcher-owned | `baseBranch`, `capacity`, `forge`, `plugins`, `pr`, `tickets`, `orchestrator` | The dispatcher's live snapshot; the build runner never interprets them. |
+
+A build's pipeline definition is therefore composed from the build's own
+branch: in origin mode the dispatcher reads `autobuild.toml` at the build's
+recorded base commit (or its branch head once the build has published commits)
+through the forging adapter; in checkout mode it reads the workspace's file. The
+effective-config artifact records the commit the build-owned sections were
+taken from — except in checkout mode when the worktree read cannot be
+attributed to the branch-head commit: because the worktree file has uncommitted
+edits, because the clean/dirty comparison could not be performed (non-git
+workspace or a transient git error), or because the branch head never carried
+the file. The artifact then records the source `worktree-dirty` and no commit,
+because attributing worktree bytes to a commit that has not been shown to carry
+them would be false provenance. A base-branch change to `[verify]`, `[finalize]`, `[commands]`, or
+the workspace provisioning after a build's base was cut does not change that
+build's verify universe, finalize steps, commands, or provisioning; a build
+that publishes such a change to its own branch picks it up at its next launch.
+A live reload delivers only deployment-owned sections to active builds, so the
+artifact deposited on reload changes only those sections. In-flight
+environments are never re-provisioned; a fresh build from the new base is the
+path for a changed provisioning definition.
+
 Two configurable narrowing mechanisms govern which verify steps run, both
 resolving to the ordinary `skipped` outcome so exclusions stay queryable:
 

package/bin/ab-build-runner.ts

@@ -19,6 +19,12 @@ try {
 if (input === undefined) process.exit(2)
 
 let exitCode = 0
+// Guest tolerance (AUT-517): an environment-supervised build child is
+// structurally a guest — it never constructs workspace providers — so a
+// configured provider plugin it cannot resolve is skipped with a notice
+// instead of failing the build. A local-parent child runs on the host with
+// the repository's full dependency tree, so it stays strict.
+const guest = input.supervision.kind === 'environment'
 if (input.supervision.kind === 'local-parent') {
   // Every local exit first transfers group teardown to an owner outside this
   // session. Environment-owned execution deliberately installs neither this
@@ -30,7 +36,7 @@ if (input.supervision.kind === 'local-parent') {
     watchBuildParent(input.supervision.parentPid, () => terminal.terminate(143)),
   )
   try {
-    await runBuildChild(input, process.env)
+    await runBuildChild(input, process.env, undefined, { guest })
   } catch {
     exitCode = 1
   }
@@ -39,7 +45,7 @@ if (input.supervision.kind === 'local-parent') {
   // Vercel owns teardown of the complete VM session. Addressing a POSIX group
   // here could leave the SDK believing a still-running environment completed.
   try {
-    await runBuildChild(input, process.env)
+    await runBuildChild(input, process.env, undefined, { guest })
   } catch {
     exitCode = 1
   }