@defrex/autobuild 0.11.0 → 0.13.0

package/README.md

@@ -24,7 +24,7 @@ needs an authenticated [`gh` CLI](https://cli.github.com) or an exported
 <!-- release-install:start -->
 
 ```sh
-bun add -g @defrex/autobuild@0.11.0
+bun add -g @defrex/autobuild@0.13.0
 ```
 
 <!-- release-install:end -->
@@ -174,3 +174,5 @@ routine escalations, leaving you only the real product calls.
 ## License
 
 [Apache License 2.0](LICENSE).
+
+Deploy your own store and dashboard with the [hosted service setup](docs/hosted-service.md).

package/SPEC.md

@@ -432,6 +432,13 @@ 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.
 
+For hosted tickets, exact sampled revisions are copied into immutable repository
+artifacts in the destination build store before pins are published. Pins carry
+explicit manifest references; bounded binary chunks preserve files and empty
+directories without contacting the ticket service during build reads. Original
+ticket revision numbers are preserved. Old pins without snapshot references
+continue reading their existing ticket rows.
+
 ## 7. The build store
 
 The v1 repo-bloat and no-observability problems share one root cause: the
@@ -581,9 +588,8 @@ 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.
+empty wake settings are never woken. The legacy hosted wake settings retain their event defaults independently of
+the actionable CLI watch projection.
 
 **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
@@ -619,15 +625,23 @@ resume or turn — no second turn, no concurrent turns, no subagents.
 
 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
+but belongs outside the repository, where it would go stale once the change ships. 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.
+Hosted ticket assets live in the ticket service's repository-keyed storage,
+regardless of where builds run or which BuildStore is selected. File tickets use
+native portable storage composed with legacy BuildStore attachments; Linear
+tickets retain BuildStore storage. Existing service assets need no migration;
+old local hosted-ticket attachments are not moved or used as a fallback.
+
+Each put creates a new increasing **revision**; earlier revisions stay retrievable.
+Adapters normally start at 0. Native file assets reserve revisions from
+1,000,000,000 upward so explicit reads of old BuildStore revisions remain
+unambiguous when native and legacy assets are composed.
 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`
@@ -701,7 +715,8 @@ conformance suite):
    hosted HTTP service, selected by an `http(s)://` reference. Kernels,
    sandboxes, terminal dashboards, and later human-facing pages share this
    service tier; it owns token authorization, protocol write validation,
-   artifact policy, and exact package/protocol version-skew enforcement. The
+   artifact policy, release-line compatibility, and independent protocol
+   enforcement. The
    later human routes share its deployment so a browser or second service never
    receives the machine signing secret. Artifacts remain content-by-value. The
    documented [remote store protocol](docs/remote-store-protocol.md) is the
@@ -710,6 +725,24 @@ conformance suite):
    client, is the conformance bar. Autobuild does not load in-process BuildStore
    plugins. Git worktrees and default file tickets necessarily remain local.
 
+A service accepts stable clients from its own `major.minor` release line and
+the two preceding minor lines in the same major. A major starts a new family:
+X.0 accepts only X.0, X.1 accepts X.0/X.1, and X.2 onward accepts three lines.
+Patch versions are interchangeable in both directions and must never change
+the protocol. Upgrade the service first, then projects independently within
+its window. Supported release lines retain their wire handlers and known
+protocol identities; an unknown protocol is refused independently of version.
+Malformed, missing, and prerelease identities are refused with HTTP 409.
+A newer client is told to upgrade the service; a client below the window is
+told to upgrade the project's Autobuild. Diagnostics name the service version
+and supported range.
+
+Unauthenticated `GET /health` publishes `ok`, `autobuildVersion`,
+`protocolVersion`, and `supportedClientRange: { minVersion, maxVersionExclusive }`.
+The range is inclusive at the minimum and exclusive at the maximum; a 0.11.x
+service publishes `>=0.9.0 <0.12.0`. Health needs no credentials, version
+headers, or available backend.
+
 `subscribe` is specced in the interface; the v2.0 implementation is polling
 `getEvents(since)`. True push comes later.
 
@@ -734,6 +767,43 @@ 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.
 
+#### Hosted connected projects
+
+The product's hosted service keeps a durable PostgreSQL project registry,
+independent of BuildStore repository journals and ticket data. Entries record
+normalized repository origin, addition timestamp and adding identity. An
+append-only journal records additions/removals; latest sequence determines
+membership. Removal never deletes build, event, artifact or ticket history;
+re-registration restores access and records fresh addition metadata.
+
+Database-authorized owners administer it without redeploying through
+`ab-hosted-store projects list`, `projects add REPOSITORY --user IDENTITY`, and
+`projects remove REPOSITORY --user IDENTITY`. Attribution is declared by the
+administrator; ordinary store/project tokens cannot administer registration.
+All allowlisted signed-in users own every registered project (single-owner
+model). Per-project memberships and machine credential boundaries are deferred.
+
+Dashboard discovery, MCP `repositories.list` and every repository tool call,
+and all operator API routes for every operator credential consult current
+membership. Unregistered operator paths return not-found before execution.
+Registry failures fail closed and transient initialization can retry.
+The dashboard selection lives at `/?repo=<URL-encoded normalized origin>`;
+missing/invalid selections canonicalize to the first active entry, and an
+empty registry issues no project data/control requests.
+
+The hosted dispatcher queries the registry each authorized invocation when
+`AB_DISPATCHER_REPOSITORIES` is unset. An explicit list is intersected with
+current registration in its configured order. Empty registration is a
+successful zero-project tick. Removal stops later invocations, without
+cancelling already-started work or changing machine-route token authority.
+
+`AB_WEB_REPOSITORIES` is deprecated: the first initialization with a nonempty
+CSV imports absent projects once per database as `system:AB_WEB_REPOSITORIES`.
+The import and durable marker share one transaction and mutation lock across
+processes. Absence does not consume the marker. Restarts or later variable
+edits cannot resurrect removals. Deployments migrate the pinned schema before
+starting services; runtime initialization never runs DDL.
+
 ### 7.3 Persistence granularity
 
 Required phase outputs persist at **phase/round boundaries**; a killed phase
@@ -781,8 +851,27 @@ Four base-selection invariants make this safe with Git:
 
 ### 7.5 What the PR gets
 
-A summary comment — verdict history, verification results, links into the
-store. The full audit trail is queryable, not committed to the branch.
+One marked summary comment contains verdict history, verification results,
+and links into the store. Built-in forges discover its per-build marker on
+every refresh and edit it, recreating it only after confirmed absence. The
+full audit trail is queryable, not committed to the branch.
+
+Summary publication is best effort, once per completed phase occurrence,
+after sessions end; attaching artifacts performs no summary write. Durable
+claim-before-write facts consume the occurrence budget even across crashes.
+Rate limits stop that occurrence and persist a cooldown (provider headers or
+at least one minute) before a later phase may catch up. Failures never fail
+artifact designation or phase completion. Bodies are capped at 65,536 UTF-16
+code units. Oversized projections are deposited as a non-attached `pr-summary`
+artifact; a compact comment provides the exact pinned download command.
+Current-API plugins retain `commentOnPr` and receive the same bounded calls;
+legacy plugins may append instead of editing.
+
+Local runners publish under their build lease. Remote guests record durable
+summary boundary requests and yield; only the credentialed dispatcher settles
+those requests, after guest execution ends and under exclusive ownership,
+before replacement execution or workspace cleanup. Attempts and request
+dispositions survive restart and do not alter pipeline routing.
 
 Any agent session can explicitly designate an exact deposited artifact as a PR
 attachment through `ab artifact put <kind> <file> --attach`. Designation is a
@@ -802,8 +891,8 @@ dispatcher reclaims them after the build reaches a terminal outcome, while
 store artifacts remain under the store's retention policy. Upload/validation/timeout failures record follow-up
 observations and preserve the complete text projection; they never fail
 verification or block finalize. Agents receive no forge credentials. A
-designation after the PR exists publishes a new complete summary, so finalize
-post-steps and post-reconcile verifiers need no custom phase.
+designation after the PR exists is included at the completed phase boundary,
+so finalize post-steps and post-reconcile verifiers need no custom phase.
 
 ### 7.6 Streams (the third primitive)
 
@@ -925,7 +1014,7 @@ AB_STORE     # store URL or local path
 AB_BUILD     # build slug
 AB_PHASE     # current phase (+ round)
 AB_SESSION   # session id
-AB_TOKEN     # transports the scoped handle's authority to a remote store
+AB_TOKEN     # signed credential for this exact phase session (remote store)
 ```
 
 A harvest session instead carries `AB_REPO`, `AB_HARVEST`, and an `AB_PHASE`
@@ -933,14 +1022,18 @@ of `synthesize@N` or `review@N`. The AgentRunner invocation argument is
 opaque: a build skill receives its slug; a harvest skill receives its run id.
 The CLI resolves identity from ambient auth. Every build process holds an
 interface-enforced build-scoped Store handle. At the phase CLI opening boundary,
-a remote handle forwards the runner-minted token unchanged, while a local handle
-is wrapped with authority over exactly `AB_BUILD` or `AB_REPO`. Build and
+both local and remote handles are wrapped with authority over exactly
+`AB_BUILD` or `AB_REPO`. Before launch, the dispatcher exchanges its project credential with the service
+for a build or prepared harvest-execution grant. After recording a session start,
+the runner exchanges that grant for an exact phase-session grant. The remote
+handle forwards only this delegated credential; the service enforces its project,
+resource and session boundaries on the wire. Build and
 repository resources cannot cross, and naming another resource to a Store
 operation cannot widen either handle. Event-bearing writes attributed to an
 agent must name the ambient `AB_SESSION`; non-agent writes remain allowed so the
 CLI can perform its existing trusted kernel plumbing, including finalize.
-Operator and kernel processes with no agent identity markers retain unscoped
-Store access. Three read-only forms are also valid inside a phase: `ab build
+Operator and kernel processes with no agent identity markers retain interface-unscoped
+Store handles; remote authorization still limits access to the credential project. Three read-only forms are also valid inside a phase: `ab build
 status` and `ab artifact download` may read only `AB_BUILD`, while `ab builds`
 is denied because collection access cannot represent one build. A complete
 Harvest identity has repository scope and cannot use those build/admin reads.
@@ -949,10 +1042,60 @@ If any build or Harvest identity marker is present, the corresponding
 partial, empty, malformed, shared-only, or mixed identity fails before Store
 access rather than falling back to operator authority. `AB_STORE` and
 `AB_TOKEN` alone remain operator selection and credentials, not identity.
-Remote tokens transport the corresponding resource and session authority over
-the wire; build-process resource scope is already enforced by the Store
-interface. Least privilege comes from the Store and runner, not prompt
-instructions.
+Dispatcher machine authority is an opaque, revocable credential for exactly one
+registered project. The service keeps only a digest of its random secret and
+credential metadata (creator, creation, last use, expiry and revocation), and
+checks both credential status and project registration on each request. It
+checks actual build/session/stream ownership and filters collections server-side.
+Explicit project mismatch is 403; missing and foreign indirect IDs share 404.
+Remote project build creation allocates a fresh slug and branch; the returned
+record is authoritative. Local adapters retain exact-slug behavior.
+
+Owners issue/list/revoke credentials with deployment-local `ab-hosted-store
+credentials` commands. Retired deployment-wide and repository-less operator
+tokens are rejected with migration guidance. An explicit versioned owner-only
+break-glass admin is the sole machine cross-project exception. Internal signed
+owner delegation is short-lived, repository-bound and operator-only. The hosted
+dispatcher issues stored credentials with immutable dispatcher purpose (raw
+store and tickets only) per invocation and keeps them valid through configured
+expiry. Already issued delegated grants do not depend on that parent expiry.
+Owner-issued project credentials attribute operator writes to their recorded
+creator. Agents never receive the dispatcher's project credential. Delegated
+reads retain access to same-project repository state; build mutations target only
+that build, and harvest mutations target only the prepared run and execution,
+its artifacts and streams, with heartbeat authority for its adopted lease holder.
+Phase grants also enforce agent session attribution. They cannot create builds or
+operator sessions, administer repositories, invoke operator routes, or delegate.
+A runner can delegate only to a recorded session within its own authority.
+
+Delegated grants have no fixed wall-clock expiry. The service checks signed
+bindings against authoritative durable lifecycle facts on every request and
+fails closed if those reads fail. Active, paused and escalated builds may outlive
+a dispatcher restart or a week-long parent credential. Build termination,
+harvest execution/run termination, or the phase's own session end retires the
+corresponding grant after a 60-second evidence grace window. A durable ending
+permanently closes that grant; recovered harvest executions use fresh durable
+authorizations and fresh grants. Project removal denies all its grants immediately.
+Local-store projects require no exchange.
+
+Hosted ticket operations are gated by grant kind: build-runner and build-phase
+grants have no access; harvest-phase grants can only list-ready, get and read
+dependency-states; harvest-runner grants can also create proposals. All other
+ticket mutations require project or admin authority. Refusals name the grant
+kind and operation.
+
+Ticket admission uses the credential project. Hosted tickets, comments, blockers, creation-key
+deduplication and assets are partitioned by registered repository, never team.
+Lifecycle comes from independent project ticket policy (triage, ready, doing, done
+by default; configurable doneState). Legacy projects without independent policy
+use their uploaded configuration with Backlog / Doing / Done defaults. Owner admin ticket requests explicitly select a registered
+repository. The service has no Linear ticket backend: external tracker and
+file sources remain dispatcher-side, and service ticket surfaces refuse those
+projects with actionable source feedback. Legacy team queues migrate atomically
+to their sole configured claimant; conflicts stop unchanged for an owner
+assignment and rerun. See the hosted service migration procedure.
+See the remote store, remote ticket and operator protocol references for wire
+and revocation details. Least privilege comes from code, not prompt instructions.
 
 Every phase and harvest turn also receives a runner-controlled `PATH` prefix
 containing a private `ab` launcher from the same Autobuild distribution that
@@ -1145,9 +1288,10 @@ implementer:  ab context   (findings.json now materialized) → …
 
 Human/pre-build ticket grooming uses one configured-source namespace
 (`ab ticket create|update|block|unblock|list|show|move`, plus the ticket-asset
-forms below). These commands are
+forms below). Migration adds `ab ticket export <dir>` and `ab ticket import <dir>`
+(see [Ticket source migration](#ticket-source-migration)). 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
+mutation path. The CRUD subcommands accept `--json` and then writes exactly one
 bare value: `list` emits `Ticket[]`; every other form emits the complete
 created, read, or post-mutation `Ticket`. Human-readable confirmations are not
 a data format and callers must not parse ids from them.
@@ -1162,8 +1306,10 @@ 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:
+**Ticket assets** (§7.1) attach files to a ticket. Hosted tickets use their
+ticket service storage independently of the selected build store; file tickets use
+native storage with legacy fallback, and sources without native assets use the
+selected BuildStore:
 
 - `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.
@@ -1219,6 +1365,17 @@ be narrowed to the ambient build — and `--repo` constrains every call to one
 repository. Mutating tools attribute their writes to the sessionless operator
 identity, exactly as the other operator commands do.
 
+### 8.10 Hosted project connection
+
+`ab connect <service-url>` requests owner browser approval for the normalized
+origin, registers the project, and saves a project credential outside the
+checkout. `ab connect` reports its status; `ab disconnect` revokes and removes
+only that credential, retaining project data. Store precedence is `--store`,
+nonblank `AB_STORE`, `[store] url`, then local state. `AB_TOKEN` overrides saved
+credentials. Configured services without credentials fail closed. Connection
+commands require a network origin and are unavailable in phase sessions.
+
+
 ## 9. AgentRunner
 
 Session-based, because review loops need memory:
@@ -1619,6 +1776,19 @@ event-level mechanics live in the repository catalog and reducer tests):
 
 ## 13. Ticket source policy
 
+**Hosted tickets are project-scoped.** A project credential selects one registered
+repository; an owner selects a registered repository explicitly. Team and state
+fields from clients convey no authority or lifecycle policy. Tickets, comments,
+blockers, creation-key deduplication and assets are isolated by repository.
+Independent project ticket policy supplies hosted lifecycle names: triage, ready,
+doing, done (`doneState`), and create/proposal equal to triage by default. Hosted
+readyState defaults to ready; other sources require it. Legacy clients without
+independent policy use uploaded dispatcher config and its old defaults. Configured roles may overlap.
+The service has no Linear backend and never relays external ticket sources.
+Projects using Linear, files or plugins keep their direct dispatcher connection;
+service ticket surfaces refuse with project/source feedback instead of empty data.
+
+
 The TicketSource **initiates and receives projections; it is never consulted
 mid-build and never used as artifact storage.** Dispatch reads the ticket
 (including the spec) as part of initiation — at claim time, or on a later tick
@@ -1629,14 +1799,16 @@ 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,
+live in the ticket service for hosted tickets, independently of build storage;
+file sources keep portable bundles and source-local history, while sources without
+native assets keep them in the BuildStore. 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.
+and existing sources and plugins need no asset capability.
 
 **Claim lifecycle.** Claim acquires nonterminal work: it returns `true` and
 moves a claimable ticket to the source's claimed state. It returns `false` for
@@ -1871,7 +2043,8 @@ with illustrative members:
 | 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?}` |
+| Verify/finalize | `verify.started {step, attempt, feedback?}`, `verify.completed {step, outcome, skipCause?}`, `verify.reconcile-policy-captured {reconcileSeq, steps}`, `finalize.completed {pr}`, `finalize.step-started {step}`, `finalize.step-completed {step, ok, headSha?}` |
+| PR summary | Kernel-authored `pr-summary.requested {occurrence, boundary}`, `pr-summary.attempted {occurrence, boundary, pr}`, `pr-summary.result {attempt, outcome, eligibleAfter?}`, `pr-summary.settled {request, disposition}`; sequence identities correlate durable starts, completed boundaries, attempts, and handoffs (§7.5) |
 | PR attachments | `pr-attachment.designated`, `pr-attachment.hosted`, `pr-attachment.reclaimed`, `pr-attachment.reclaim-failed` |
 | Post-PR [D1] | `pr.merged`, `pr.conflicted`, `reconcile.progress-checked`, `reconcile.started`, `reconcile.completed` |
 | Cross-cutting | `observation.recorded`, `escalation.raised`, `phase.failed` |
@@ -1975,8 +2148,18 @@ ordinary dispatcher tick provisions the workspace, atomically imports the spec,
 posts the ticket notice once, and launches the runner. Claim-time auto-merge
 attribution retained by `build.created` is materialized as the ordinary
 human-authored request before launch. A failed boundary appends `dispatch.failed
-{stage,attempt,error}` and stays queued for another tick. A discard request is
-honored only while the build remains queued; one that races with runner
+{stage,attempt,error}` and stays queued for another tick until its budget is
+exhausted. Dispatch failures share a `[policy].maxDispatchAttempts` budget
+(default 3) across
+create, workspace, spec, comment, and launch stages. Exhaustion raises one
+`dispatch-failure-limit` policy escalation naming the latest stage and error,
+and parks dispatch until answered. Both bare `ab answer <slug>` retries and
+text guidance grant a fresh budget; abort does not. Confirmed runner attachment
+clears the streak. Recovery-provider workspace failures belong exclusively to
+the infrastructure budget. Exhaustion is repaired from durable facts on restart
+before further dispatch work.
+
+A discard request is honored only while the build remains queued; one that races with runner
 attachment is inert and cannot tear down live work. A human discard waits out
 any unexpired execution lease, then releases a partial workspace and stale
 lease, returns the ticket to Ready, and appends `build.completed {outcome:
@@ -2068,6 +2251,21 @@ adapter never re-cuts it from a newer base (§7.4). `ab context` rehydrates
 scratch from the store into a fresh session. Uncommitted round-2 work is lost by
 design (§7.3 — phase boundaries are the resume points).
 
+The dispatcher also applies a fixed, non-configurable limit of three consecutive
+executions that complete normally with exit code zero and no durable build
+progress. Execution start/end, runner attachment and workspace lifecycle
+bookkeeping do not count as progress. Pipeline, session, spec, publication/PR,
+observation and acknowledged operator facts reset the streak; infrastructure,
+budget and provider failures do not consume the allowance and retain their own
+retry limits. Before a fourth actionable launch, the dispatcher raises one
+setup-targeted `execution-no-progress` policy escalation naming the count and
+the next action it expected the runner to take. Waiting, paused and terminal
+builds are left parked, and pending operator commands remain executable.
+Answering that escalation with guidance or a bare `ab answer <slug>` retry grants
+three fresh executions. The guard is derived from durable facts, including on
+supervisor restart, and uses the ordinary watch, dashboard and operator API
+attention paths.
+
 Two liveness rules complete the picture. Within one dispatcher process,
 build-runner launches are single-flighted by slug through supervised process
 liveness — execution completion means the complete environment has been reaped,
@@ -2182,7 +2380,8 @@ fresh from `origin`, and records the resolved SHA on `reconcile.started` — kno
 used (§15.3). The agent merges that base into the branch guided by the spec,
 plan, and implement-notes, with the explicit charge to regress against
 neither; the resolution lands as a merge commit, and because reconciliation
-changed code, **`verify:*` re-runs in full**. A resolution the agent judges
+changed code, **`verify:*` starts a fresh cycle**, subject to the captured
+post-reconcile policy (default: re-run all applicable steps). A resolution the agent judges
 risky — semantic conflicts, spec-relevant choices — escalates rather than
 guesses. Reconcile skips `code-review` by default (escalation covers the
 judgment cases; policy can force it).
@@ -2314,6 +2513,7 @@ sessionBudgetSeconds = 7200       # optional role override
 sessionBudgetSeconds = 3600       # non-infinite default for build agent sessions
 stallRounds = 3
 maxVerifyAttempts = 3
+maxDispatchAttempts = 3
 maxSetupAttempts = 3
 maxInfrastructureAttempts = 3
 maxReconcileAttempts = 3
@@ -2386,9 +2586,12 @@ 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
+Three configurable narrowing mechanisms govern which verify steps run, all
 resolving to the ordinary `skipped` outcome so exclusions stay queryable:
 
+- **Post-reconcile policy.** The cycle snapshot resolves repository and step
+  `afterReconcile` settings before any plan or path exclusions, including for
+  `always` steps. It applies only after a completed reconcile.
 - **Plan selection.** An approved plan may declare the complete subset of
   optional verify steps warranted by the spec, in strict front matter
   validated at deposit. The selection paired with the approving review
@@ -2402,6 +2605,30 @@ resolving to the ordinary `skipped` outcome so exclusions stay queryable:
   match skips without launching anything; a Git failure is infrastructure and
   fails closed, never a synthetic skip.
 
+
+#### Post-reconcile verification policy
+
+Post-reconcile verification defaults to enabled: `[verify].afterReconcile = true`.
+Set it to `false` to retain pre-reconcile verification and skip all steps after
+reconciliation. An optional boolean `[verify.<step>].afterReconcile` overrides
+the repository setting in either direction; overrides require a configured step.
+For example, set `afterReconcile = false` in `[verify]` and
+`afterReconcile = true` in `[verify.types]` to keep only that step re-running.
+
+The kernel freezes the resolved ordered policy in
+`verify.reconcile-policy-captured` at the next engine action after reconcile
+completion. Live configuration changes apply at that boundary; a cycle already
+started keeps its policy through recovery. Historical cycles already started
+without a captured policy retain the rerun-all behavior. Initial verification
+and verification after subsequent code review always use ordinary applicability.
+Policy exclusion precedes plan selection and paths, including `always = true`.
+Enabled steps still follow plan selection and path rules. Excluded steps record
+`verify.completed` with outcome `skipped`, `skipCause = "post-reconcile-policy"`,
+and a reason naming the setting. Dashboards and PR summaries call this
+"skipped by post-reconcile policy"; it is never a pass. Forge-side required
+checks and branch protections still gate merge. For excluded steps, merged code
+is not re-verified, so breakage that only exists in the combination can land.
+
 ### 16.3 Skill installation: vendored, namespaced, editable [D11]
 
 This project ships 11 canonical default skills for the fixed phases, the
@@ -2483,6 +2710,15 @@ install failure is fatal and does not merge against the wrong defaults.
 `--no-self-update` always selects merge-only
 behavior. An exact version may be older than the installed version.
 
+Before installation or project writes, upgrades targeting a hosted store probe
+its public health range. An incompatible target produces a directional warning
+(service first for a newer target, project upgrade for a stale target) and
+continues. A legacy health response has an exact-version contract; different
+targets warn that the service needs the compatibility-window release. Failed,
+timed-out, or malformed probes warn that connectivity could not be verified
+and may fail after upgrade, then continue. Merge-only and replacement-process
+handoffs check the distribution actually applied before skill writes.
+
 Upgrade records its successful work in one local commit on the target's current
 HEAD by default. The exact ownership boundary is the reported skills' canonical
 `.agents` trees, pristine records, and `.claude` discovery paths, plus
@@ -2581,3 +2817,71 @@ or installs releases in the foreground or background.
    enforcement and will colocate later session-authenticated human routes.
    Artifacts remain content-by-value for now; direct-to-blob references are a
    possible later protocol revision, not a second current deployment path.
+
+## Revision-checked ticket writes
+
+Every ticket read includes an opaque `revision`. Pass it as `expectedRevision`
+(on MCP/operator requests) or `--expected-revision <opaque>` on `ab ticket update`,
+`move`, `block` and `unblock`. A stale write fails without changing anything and
+reports the current revision. Omission preserves unguarded behavior. Blocker
+checks cover the entire batch. Dispatcher moves remain unguarded and change the
+revision. Sources without guarded writes, including Linear, refuse supplied
+revisions rather than ignoring them.
+
+`ab ticket edit <id>` opens `$VISUAL`, falling back to `$EDITOR`, using TOML
+frontmatter and a Markdown body. Only title, body and labels are editable;
+id, blockers, creation key and reference comments are read-only. It saves only
+changed fields with the opening revision. Unchanged or formatting-only edits
+write nothing. On conflict, invalid input or editor failure, the error names an
+absolute file path containing the edited text. Read the current ticket and
+reapply the intended changes before retrying; conflicts are never merged.
+
+File and Linear revisions fingerprint title, body, canonical label/blocker sets
+and state; reverting identical content restores its fingerprint. File checks
+re-read immediately before writing, with the existing no-lock race window.
+Direct file edits and state-directory moves change revisions. File revisions also
+cover structured comments and portable attachments. Legacy file comments change
+the body; structured comments preserve it. Separate hosted comments do not change
+ticket revisions. Hosted revisions
+are monotonic decimal bigint strings, and checks run under the same row lock
+and transaction as all requested changes. Hosted reads return a coherent
+snapshot of fields, blockers and revision.
+
+### Independent hosted ticket service
+
+`[tickets] url` selects hosted ticket transport independently of BuildStore selection;
+without it, tickets use the selected remote build store. Local builds require an
+explicit ticket URL. Project registration and ticket policy publication through
+`ab connect --tickets URL` work before dispatch. Policy is a durable per-registration
+record, outside BuildStore events/artifacts; legacy uploaded configuration remains
+a compatibility fallback. Hosted lifecycle defaults are triage/ready/doing/done.
+Independent harvest uses revocable, expiring, service-bound ticket grants with
+read/create runner authority and read-only child authority. Build state and harvest
+journals remain exclusively in the selected BuildStore.
+
+### Ticket source migration
+
+`ab ticket export <dir>` enumerates all states through TicketSource and writes a
+portable file tracker atomically to an absent or empty destination.
+`ab ticket import <dir>` preflights the entire tracker and target inventory, then
+creates or adopts tickets, maps blockers, deduplicates comments by exact body and
+restores current attachments. Both run sessionless without forge access.
+
+TicketCreateOptions includes optional `requestedId`. Unsupported sources reject
+it. File keeps safe ids exactly; hosted preserves canonical own-team positive
+numbers and advances its counter above every occupied number. Creation-key
+adoption precedes collision checks. Known kept-number clashes stop import before
+any target mutation. Stable migration identities and atomic mapping files make
+interrupted imports resumable without content-based adoption.
+
+File frontmatter additionally supports optional structured `comments` (body,
+createdAt, optional author) and `attachments` (kind, name, layout, entries with
+file base64 bytes or directory paths). Legacy absent fields retain old behavior;
+new creates use structured comments. Native file assets retain historical
+revisions in hidden source-local metadata and compose with legacy BuildStore
+assets. Build claims and spec re-pins freeze native assets into durable snapshots.
+
+State normalization and the complete operator procedure are documented in
+[Ticket migration](docs/ticket-migration.md). The same reference is delivered in
+the installed guide. Export keeps lifecycle membership without inferring roles;
+import reuses unique case-insensitive states and creates normalized missing ones.