@defrex/autobuild 0.11.0 → 0.12.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.12.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

@@ -581,9 +581,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
@@ -701,7 +700,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 +710,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 +752,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 +836,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 +876,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 +999,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 +1007,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 +1027,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 that project's latest durable effective configuration
+(triage Backlog, claim Doing, completion Done by default; configurable
+`doneState`). 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
@@ -1219,6 +1347,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 +1758,18 @@ 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.
+The project's latest effective configuration supplies hosted lifecycle names:
+triage Backlog, claimed Doing, completion Done (`doneState`) and create/proposal
+equal to triage by default; `readyState` is required. 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
@@ -1871,7 +2022,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 +2127,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:
@@ -2182,7 +2344,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 +2477,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 +2550,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 +2569,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 +2674,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

package/docs/architecture.md

@@ -333,7 +333,19 @@ head is a no-op; Git/Forge failures stay failure-tolerant observations.
 **Verify gating.** `packages/core/src/ontology.ts` owns the canonical
 `pass | fail | skipped` outcome (only `fail` routes back to implement or
 consumes attempts; a skip satisfies one step without being passing
-evidence). Two kernel-authored skip sources narrow the configured universe:
+evidence). Three kernel-authored skip sources narrow the configured universe:
+post-reconcile policy, approved plan selection, and changed paths.
+The engine captures the ordered effective `afterReconcile` policy in
+`verify.reconcile-policy-captured` at the action after reconciliation completes,
+before verification starts. Log-index replay keeps it scoped to that completion;
+subsequent config changes cannot replace it mid-cycle. Historical already-started
+cycles without a snapshot retain rerun-all behavior. A later code-review approval
+restores ordinary verification. Policy exclusions precede plan/path applicability
+and carry `skipCause: "post-reconcile-policy"` plus a setting-specific reason.
+The shared dashboard model renders that reason, as does the PR summary.
+Excluded steps do not re-verify merged code, so combination-only breakage can
+land; forge requirements and reconcile budgets remain independent.
+For enabled steps,
 `packages/core/src/kernel/plan-verify-selection.ts` resolves an approved plan's front-matter
 selection (applied at the planner's `ab done` in `packages/core/src/cli/terminals.ts`,
 snapshotted by the engine at approval), and
@@ -341,7 +353,7 @@ snapshotted by the engine at approval), and
 selectors, resolved by the build runner via `git diff` against the initial
 branch-cut base (or the refreshed base promoted by a completed reconcile).
 This verify-only base is deliberately independent from implementation's
-focused review range. Both narrowing mechanisms produce the ordinary
+focused review range. All narrowing mechanisms produce the ordinary
 queryable skipped outcome; Git failure is infrastructure and fails closed,
 never a synthetic skip. Verify escalation routing is also explicit in the
 engine: guidance answering an agent verifier's own `ab escalate` returns to the
@@ -579,7 +591,7 @@ slug routing. Upgrade performs the same composition lazily at its first merge
 conflict.
 
 `packages/core/src/cli/repo-state.ts` owns repository identity and store precedence
-(`--store` > `AB_STORE` > `.autobuild/`); `packages/core/src/cli/store-opening.ts` is the
+(`--store` > `AB_STORE` > `[store] url` > `.autobuild/`); `packages/core/src/cli/store-opening.ts` is the
 production store composition boundary shared by finite sessionless queries and
 phase sessions. Its shared scoping primitive preserves remote token composition
 and adds local ambient authority only for filesystem stores. The dedicated
@@ -599,7 +611,15 @@ phase-only commands report their complete runner context when run by hand.
 correlations, and pending cleanup without coupling to a producer or verify-step
 name. `packages/core/src/cli/pr-attachments.ts` performs optional image hosting through the
 narrow Forge capability, while `packages/core/src/cli/pr-summary.ts` renders the same complete
-text projection for finalize and late designations. The GitHub release transport
+text projection for finalize and late designations. `cli/pr-summary-publication.ts`
+coalesces these at completed phase boundaries with durable attempt, result,
+cooldown, request, and disposition facts. Built-in forges upsert one hidden
+per-build marker; legacy plugins keep the existing bounded `commentOnPr` API.
+Oversized bodies become a compact pinned download of a full `pr-summary`
+store artifact. Local runners publish under their lease; remote guests request
+and yield, and dispatcher settlement fences ended execution and owns the
+publication lease before launching replacement work. Summary failure never
+changes phase outcomes. The GitHub release transport
 lives in `packages/core/src/ports/forge/github-pr-attachments.ts`; terminal-build reclamation
 and retry facts remain dispatcher janitor duty.
 
@@ -876,3 +896,45 @@ because they cannot be manufactured safely against a live account.
 
 Provisioning or scheduling these credentials/resources in CI is deliberately
 out of scope; live runs remain explicit.
+
+## Hosted project registry
+
+`packages/postgres-store/src/projects.ts` owns a narrow project registry port
+beside BuildStore. Schema v10 adds an independent append-only project journal
+and singleton mutation/bootstrap lock and marker, with no build/ticket foreign
+keys. Active entries reduce the latest sequence per origin; timestamps are
+metadata, not ordering. Runtime opens assert schema and never run DDL.
+`ab-hosted-store projects` administers registrations using database authority.
+The service exposes one lazy live reader to the operator server, web gateway,
+MCP and server-rendered repository picker. Initialization failures clear the
+cached promise for retry. The dispatcher opens its own shared pool and queries
+membership each invocation. See [owner workflow](setup.md#connected-projects).
+
+## Delegated execution authority
+
+`store/remote/credentials.ts` owns the credential exchange client independently
+of the BuildStore persistence port. The hosted service's `delegated-authority.ts`
+validates issuance, durable lifecycle bindings and the 60-second terminal grace;
+`machine-auth.ts` authenticates these signed version-2 grants as delegated
+principals. `remote-store-server.ts` enforces resource mutations before deposits,
+including body-selected and addressed-stream resources. Operator routes reject
+these principals. Ticket routes deny build grants and allow harvest grants only the reads and
+runner filing operations they require. Ticket sources and assets are partitioned
+by the authenticated project.
+
+Dispatch prepares harvest claims using `HarvestRunner.run(true)` before issuing
+an execution grant. `harvest.execution.authorized` binds the selected run,
+execution and adopted lease holder; the guest resumes only that prepared run.
+Local completion records `harvest.execution.ended`; hosted completion retains
+its provider release fact. Recovery controls remain trusted dispatcher work.
+Execution launch auth is transient and separate from serialized identity. Runners
+request exact phase grants after session-start facts and before runtime calls.
+Workspace plugin factories receive an exchange callback and a scrubbed environment,
+while local children and sandbox bootstrap/launch replace inherited authority.
+Service requests reread durable state; detached executions need neither renewal
+secrets nor their original dispatcher. Local stores retain their existing path.
+Project onboarding uses `cli/connect.ts`, user-level `cli/project-credentials.ts`,
+the shared `connection.ts` wire types, and Postgres `connections.ts`. Approval
+commits registry membership, a credential digest, and the outcome atomically.
+The web connection routes authenticate the existing Better Auth session and
+reuse the sign-in/consent layout; CLI polling uses a separate private capability.