@defrex/autobuild 0.10.0 → 0.11.0

package/README.md

@@ -2,72 +2,29 @@
 
 # Autobuild
 
-**Tickets in, PRs out. No babysitting required.**
+**Tickets in, Product out.**
 
 </div>
 
-Every build runs headless, so ten tickets in flight cost the same 
-attention as one. You groom tickets in, you review pull requests out. 
-Agents do the work, and deterministic code keeps them honest.
+Autobuild runs coding agents through a fixed pipeline that plans, implements,
+reviews, and verifies every ticket before it merges. You groom tickets in and
+review pull requests out; agents do the work, and deterministic code keeps
+them honest.
 
 ![The autobuild dispatch dashboard with four builds in flight, each partway
 through the pipeline](docs/assets/headline-wide.png)
 
-## Groomed ticket in, reviewed PR out
-
-Running several coding agents by hand doesn't scale well. Every session wants
-prompts, permissions, and attention, and your focus becomes the ceiling.
-With Autobuild, each build runs the whole loop headlessly and escalates only
-when it is truly blocked. With attention off the critical path, throughput
-is only limited by how fast you can write good tickets.
-
-Headless is safe because the pipeline is deterministic code, not model
-judgment. State lives in a typed, append-only event log, phase transitions
-are owned by tested code, and every build leaves a queryable paper trail. Your
-merge gates are never bypassed: a PR lands when your required checks and your
-consent say it lands.
-
-The loop also feeds itself. While building, agents record observations —
-latent bugs, worthwhile refactors, follow-ups they noticed but rightly left
-alone. A harvester distills them into proposed tickets and files them for
-triage; approve one and it runs the same loop.
-
-Every seam is an adapter: ticket sources (the hosted service with database or
-Linear backend, direct Linear, local files, or a configured plugin), agent runtimes (Claude, Codex, Pi, or a configured plugin), the forge
-(GitHub via `gh`, credential-free local Git, or a configured plugin), workspaces,
-and the build store all sit behind
-narrow interfaces. Trusted Bun plugins declared in `autobuild.toml` can register
-third-party ticket, runtime, workspace, and forge adapters against the versioned
-`@defrex/autobuild/plugin-sdk` surface. Repositories may also opt into the shipped
-`vercel-sandbox` workspace provider: the complete build runs in an isolated
-Vercel VM while the local supervisor retains credentialed branch/PR publication.
-The default remains a local Git worktree. See the [workspace configuration and
-security contract](docs/configuration.md#vercel-sandbox).
-Teams that need one durable store across hosts
-can deploy the optional [hosted service](packages/hosted-store-service/README.md),
-which also serves a GitHub-authenticated browser dashboard, can own ticket
-persistence and external tracker credentials, and can run the dispatcher itself on a schedule (see [the hosted dispatcher](docs/hosted-dispatcher.md)). Repository identity across the
-Store, dispatcher, query commands, and that dashboard is the repository's
-normalized origin URL (e.g. `https://github.com/defrex/autobuild`), never a
-checkout path; pre-origin records are not migrated. The web UI uses a server-managed
-session; automation clients can use the versioned [operator API](docs/operator-api.md)
-for the same controls and projections without exposing service credentials, and
-external MCP agents connect through the [hosted MCP server](docs/mcp.md).
-
 ## Quickstart
 
 You need [Bun](https://bun.sh), `git`, and the local prerequisites for the
-agent runtime you select: Claude Code, Codex CLI, or Pi. Choosing the GitHub
-forge also requires an authenticated [`gh` CLI](https://cli.github.com)
-(`gh auth login`) or an exported `GITHUB_TOKEN`/`GH_TOKEN`; the local-git forge needs no
-account or remote.
-Init suggests only runtimes whose executable and/or provider authentication is
-usable on your machine.
+agent runtime you select: Claude Code, Codex CLI, or Pi. The GitHub forge also
+needs an authenticated [`gh` CLI](https://cli.github.com) or an exported
+`GITHUB_TOKEN`/`GH_TOKEN`; the local-git forge needs no account or remote.
 
 <!-- release-install:start -->
 
 ```sh
-bun add -g @defrex/autobuild@0.10.0
+bun add -g @defrex/autobuild@0.11.0
 ```
 
 <!-- release-install:end -->
@@ -78,44 +35,36 @@ Then, from the repository you want built:
 ab init
 ```
 
-Vendors the editable `ab-*` skills, writes a stack-neutral config, and hands
-repository-aware setup to a coding agent. Follow the canonical
-[installation and setup procedure](docs/setup.md) to keep local worktrees or
-explicitly configure Vercel, then commit the setup and check its real execution
-environment without creating build history:
-
-```sh
-ab init --validate
-```
-
-See the [configuration reference](docs/configuration.md) for every field. Only
-a clean readiness result should be followed by:
+This vendors the editable `ab-*` skills, writes a stack-neutral config, and
+hands repository-aware setup to a coding agent. The
+[configuration reference](docs/configuration.md) covers every field. Then
+start the dispatcher and its live dashboard:
 
 ```sh
 ab dispatch
 ```
 
-Starts the dispatcher, with the live dashboard on a TTY.
-
-In your selected coding agent, invoke the ticket-grooming skill:
+Then groom your first ticket in your coding agent:
 
 ```text
-/ab-spec I want to build a feature!
+/ab-spec add a retry budget
 ```
 
-The agent asks the questions needed to produce a quality ticket and adds it
-directly to your ticketing system. Using the skill to create tickets then
-largely becomes your input workflow.
+The agent asks the questions needed to produce a buildable ticket and files it
+in your tracker. From then on, that skill is how work goes in.
 
 ## How it works
 
-Every build moves through the same fixed pipeline:
+### Every ticket runs the pipeline
 
 ```text
 spec → plan ⇄ plan-review → implement ⇄ code-review → verify:* → finalize
       epilogue: (pr.conflicted → reconcile → verify:*)* → merged or closed
 ```
 
+Each ticket moves through deterministic phases inside its own build-runner.
+Every phase is a fresh agent session, with artifacts knitting them together.
+
 1. **spec** — the dispatcher claims a ready ticket, establishes the final
    spec, and cuts a branch. The spec is the contract for everything after.
 2. **plan ⇄ plan-review** — a planner writes an implementation plan; an
@@ -125,54 +74,88 @@ spec → plan ⇄ plan-review → implement ⇄ code-review → verify:* → fin
    you instead of looping forever.
 4. **verify:\*** — your verification steps, in the order you declare them:
    shell commands judged by exit code, or agent verifiers that return a
-   verdict.
-5. **finalize** — the PR opens with an agent-written description and a summary
-   of explicitly attached evidence, then any post-PR steps you've configured
-   (changelogs, release notes) run failure-tolerant. A content-producing step
-   commits selected files locally; the runner extends the open PR branch with
-   a regular push. A no-op adds no commit, and a publication failure becomes a
-   follow-up observation rather than failing the green build. Agent verifiers
-   attach an exact screenshot, trace, or other artifact with
-   `ab artifact put <kind> <file> --attach`; the PR always gets a pinned
-   retrieval command, and configured public image hosting can also render
-   images inline.
+   verdict and can attach evidence such as screenshots.
+5. **finalize** — the PR opens with an agent-written description and the
+   attached evidence, then any post-PR steps you've configured (changelogs,
+   release notes) run.
 6. **epilogue** — the dispatcher watches the open PR. Conflicts route back
    through reconcile and re-verify; the build ends `merged` or `closed`.
 
-Each phase is an agent session, but the pipeline itself is not agentic:
-agents never decide what phase comes next, and outcomes are never inferred
-from what a model printed. Every phase reports through a typed CLI into an
-append-only event log, and tested code decides the transition. That log is
-the build — kill the process at any point and the dispatcher resumes from
-durable state, and every decision along the way stays queryable after the
-fact.
+### A dispatcher spawns builds
+
+The dispatcher claims ready tickets and starts a build-runner for each.
+Runners are isolated, and all state is logged. Agents never decide what phase
+comes next, and outcomes are never inferred from what a model printed: every
+phase reports through a typed CLI into the event log, and tested code decides
+the transition. That log is the build. Kill the process at any point and the
+dispatcher resumes from durable state.
 
 The pipeline grammar is fixed on purpose; `verify:*` and `finalize:*` are the
-extension points, declared per-repo in `autobuild.toml`. Post-step agents may
-commit locally but never push or call the forge; publication stays
-kernel-owned. For the seams and the reasoning behind them, see
-[`docs/architecture.md`](docs/architecture.md) and [`SPEC.md`](SPEC.md).
-
-### Observation harvesting
-
-Builds notice things they shouldn't fix. An implementer that spots a latent
-bug, a worthwhile refactor, or a missing follow-up outside its spec records a
-structured observation (`ab observe`) and moves on — the insight is kept, and
-scope creep stays out of the PR.
-
-Observations accumulate per repository, and once enough pile up the
-dispatcher runs a separate outer workflow — scan → synthesize ⇄ review →
-file — that distills them into proposed tickets, deduplicated against work
-already filed. By default, proposals land in triage with the reserved
-`autobuild:proposal` label and never dispatch themselves: the label means
-observation harvest created the ticket for human triage, not that Autobuild has
-groomed or claimed it. Autobuild does not use this label as a readiness gate or
-remove it; it is distinct from any configured or historical `autobuild` ready
-label. You groom and ready proposals like any ticket you wrote yourself. Agents
-propose; humans dispatch.
+extension points, declared per repository in `autobuild.toml`. For the seams
+and the reasoning behind them, see [`docs/architecture.md`](docs/architecture.md)
+and [`SPEC.md`](SPEC.md).
+
+## All local, all remote, or anywhere between
+
+Every seam is an adapter you can customize for your project. The build
+pipeline stays the same.
+
+| Seam       | Decides               | Adapters                                   |
+| ---------- | --------------------- | ------------------------------------------ |
+| tickets    | where work comes from | local files, Linear, hosted, plugin        |
+| dispatcher | what starts builds    | local process, scheduled (hosted)          |
+| workspace  | where a build runs    | git worktree, Vercel Sandbox, plugin       |
+| runtime    | who does the thinking | Claude Code, Codex, Pi, plugin             |
+| forge      | where code lands      | local git, GitHub, plugin                  |
+| store      | where state lives     | SQLite, Postgres, any HTTP store           |
+| operators  | how you watch         | terminal, web UI, MCP                      |
+
+Plugins are trusted Bun modules declared in `autobuild.toml` against the
+versioned `@defrex/autobuild/plugin-sdk`. Teams that want one durable store
+across hosts can deploy the optional
+[hosted service](packages/hosted-store-service/README.md), which adds a
+browser dashboard, a [scheduled dispatcher](docs/hosted-dispatcher.md), an
+[operator API](docs/operator-api.md), and an [MCP server](docs/mcp.md).
+
+
+## Built for throughput, not latency
+
+One build may take longer than a chat with an agent. The trade is far more
+changes landing every day, with much greater reliability.
+
+- **File it and walk away.** Nothing in the pipeline waits on you. You don't
+  approve tool calls, paste errors back, or watch a terminal. A build
+  escalates to you only when it is truly blocked.
+- **As many builds as you can groom.** Builds run side by side, each in its
+  own workspace, up to the limit you set. Your attention stops being the
+  ceiling; how fast you can write good tickets becomes the limit.
+
+Headless is safe because the pipeline is deterministic code, not model
+judgment. State lives in a typed, append-only event log, phase transitions
+are owned by tested code, and every build leaves a queryable paper trail. Your
+merge gates are never bypassed: a PR lands when your required checks and your
+consent say it lands.
+
+## Let the queue fill itself
+
+Once tickets are the interface, anything that can write a ticket can put work
+in front of you.
+
+Builds feed the queue themselves. An implementer that spots a latent bug, a
+worthwhile refactor, or a missing follow-up outside its spec records an
+observation (`ab observe`) and moves on: the insight is kept, and scope creep
+stays out of the PR. Once enough pile up, the dispatcher distills them into
+proposed tickets, deduplicated against work already filed, and by default
+files them into triage. You groom them like any ticket you wrote yourself.
+Agents propose; humans dispatch.
+
+Support threads, meeting notes, and error telemetry can feed it the same way.
+An agent with the `ab` CLI or the MCP server can file tickets and answer
+routine escalations, leaving you only the real product calls.
 
 ## Learn more
 
+- [autobuild.run](https://www.autobuild.run) — the project site.
 - [`docs/spec-standard.md`](docs/spec-standard.md) — what makes a ticket
   buildable: the standard every dispatched spec must meet.
 - [`docs/configuration.md`](docs/configuration.md) — the complete strict
@@ -181,7 +164,8 @@ propose; humans dispatch.
   configuration, as a worked example of the config surface.
 - [`docs/architecture.md`](docs/architecture.md) — how the design maps to the
   codebase: kernel, ports, processes, and stores.
-- [`packages/postgres-store/README.md`](packages/postgres-store/README.md) — serverless PostgreSQL persistence with S3-compatible or Vercel Blob storage.
+- [`packages/postgres-store/README.md`](packages/postgres-store/README.md) —
+  serverless PostgreSQL persistence with S3-compatible or Vercel Blob storage.
 - [`docs/remote-store-protocol.md`](docs/remote-store-protocol.md) — the
   complete HTTP server contract and BuildStore conformance instructions.
 - [`SPEC.md`](SPEC.md) — the source of truth for the design and its

package/SPEC.md

@@ -233,6 +233,19 @@ Small, independently runnable, crash-safe:
 - **ingesters** — other outer-loop processes turning signals into proposals (§12).
 - **operator** — UI process(es); see §14.
 
+Ticket-source ready scans run immediately when no completed measurement exists,
+then every
+`ticketScanIntervalSeconds` (default 60 seconds, a positive integer). Actual
+tick spacing is the floor when the configured interval is shorter. A
+same-repository `pr.merged`, `build.completed`, or `build.aborted` fact forces
+another scan on the next tick; changed ready criteria also force a scan.
+Housekeeping keeps its ordinary tick cadence. Between scans, queue depth and
+standing diagnostics repeat the last completed measurement, including across
+process restarts. Tickets groomed directly in the tracker are picked up within
+one scan interval plus one tick when capacity permits. Observation while intake
+is off shares the cadence; an observation measurement cannot suppress a fresh
+admission scan when intake is enabled.
+
 ### 3.4 The event log spine
 
 Build processes append typed events to per-build logs; repository-scoped outer
@@ -501,8 +514,11 @@ stream read's ([docs/remote-store-protocol.md](docs/remote-store-protocol.md),
 
 #### 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
+The orchestrator is a role, not a deployment: the agent that files tickets,
+watches builds, unblocks them, and discusses direction. Any agent can take it
+on — a coding-agent session at the repository root using the `ab` CLI or
+`ab mcp` needs no initialization — and the canonical `ab-operate` skill is its
+manual in either setting. In the hosted service it is played 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
@@ -2240,6 +2256,7 @@ ordinary boundary reload resumes.
 ```toml
 baseBranch = "main"
 capacity = 3                    # concurrent builds for this repo
+ticketScanIntervalSeconds = 60  # positive integer; ready scans, with tick spacing as floor
 forge = "github"                # builtin: github | local-git; or a plugin name
 plugins = ["./plugins/local.ts", "@acme/autobuild-plugin"]
 
@@ -2347,7 +2364,7 @@ decide where a build's effective configuration is composed from:
 |---|---|---|
 | 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. |
+| Dispatcher-owned | `baseBranch`, `capacity`, `ticketScanIntervalSeconds`, `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
@@ -2423,8 +2440,8 @@ installs into a repo:
   non-agent-invocable: they are invoked explicitly by the runner or a human,
   never auto-triggered by a model pattern-matching a description — a model
   must not start a pipeline phase by accident. The model-invocable exceptions
-  (`ab-spec`, `ab-tickets`, `ab-guide`) are exactly the three skills that
-  **drive no phase**; membership is decided by that criterion, not taste.
+  (`ab-spec`, `ab-tickets`, `ab-guide`, `ab-operate`) are exactly the four
+  skills that **drive no phase**; membership is decided by that criterion, not taste.
 
 When `.agents/skills` and `.claude/skills` resolve to the same filesystem
 entry, that repository-level alias already satisfies harness discovery. Init

package/bin/ab-dispatch-kernel.ts

@@ -23,7 +23,7 @@ try {
 }
 
 const stop = new AbortController()
-const requestStop = (): void => stop.abort()
+const requestStop = (signal?: string): void => stop.abort(signal)
 // Keep both handlers installed through the complete graceful drain. The first
 // targeted SIGINT comes from the supervisor; later foreground-group signals
 // must not regain their default disposition inside an open claim tick.

package/docs/configuration.md

@@ -168,7 +168,7 @@ the branch head never carried the file — the deposit records the source
 provenance declines to attribute them to any commit. **Deployment-owned** sections — `[roles]`
 (runtime, model, args, alternates, per-role `sessionBudgetSeconds`) and
 `[policy]` — keep flowing live. **Dispatcher-owned** sections (`baseBranch`,
-`capacity`, `forge`, `plugins`, `pr`, `tickets`, `orchestrator`) configure the
+`capacity`, `ticketScanIntervalSeconds`, `forge`, `plugins`, `pr`, `tickets`, `orchestrator`) configure the
 dispatcher itself and are never interpreted by the build runner.
 
 Consequently, an accepted base-branch reload re-deposits only the
@@ -195,6 +195,7 @@ These fields hot-reload:
 | Field or table | Boundary where a new value applies |
 |---|---|
 | `baseBranch` | Next dispatch or base fallback decision; existing `build.created` facts remain immutable. |
+| `ticketScanIntervalSeconds` | Next tick; evaluates elapsed time against the new interval. |
 | `capacity` | Next dispatcher tick. |
 | `[pr]` | Next build creation. |
 | `[commands]` | Next setup, verify check, or finalize check selected for a build whose OWN branch carries it. A base-branch reload does not retarget an in-flight build. |
@@ -229,10 +230,24 @@ any table header.
 | Field | Default | Constraints | Purpose |
 |---|---:|---|---|
 | `baseBranch` | `"main"` | nonempty string | Branch used to cut builds, target PRs, and merge during reconciliation. |
+| `ticketScanIntervalSeconds` | `60` | positive integer seconds | Ticket-source ready scan cadence; tick spacing is the effective minimum. |
 | `capacity` | `1` | positive integer | Maximum concurrent nonterminal builds for this repository. Paused and blocked builds still occupy capacity. |
 | `forge` | `"github"` | nonblank string | Forge adapter name. Shipped values are `github` and `local-git`; configured plugins may register other names. |
 | `plugins` | `[]` | array of unique nonblank module specifiers | Trusted Bun plugin modules loaded by dispatch, `ab ticket`, and scoped phase CLI processes. |
 
+Ticket-source ready scans run immediately when no completed measurement exists,
+then every
+`ticketScanIntervalSeconds` (default 60 seconds, a positive integer). Actual
+tick spacing is the floor when the configured interval is shorter. A
+same-repository `pr.merged`, `build.completed`, or `build.aborted` fact forces
+another scan on the next tick; changed ready criteria also force a scan.
+Housekeeping keeps its ordinary tick cadence. Between scans, queue depth and
+standing diagnostics repeat the last completed measurement, including across
+process restarts. Tickets groomed directly in the tracker are picked up within
+one scan interval plus one tick when capacity permits. Observation while intake
+is off shares the cadence; an observation measurement cannot suppress a fresh
+admission scan when intake is enabled.
+
 ### Plugin modules
 
 <!-- config-fragment:plugins -->
@@ -313,7 +328,12 @@ without adding a runtime Autobuild dependency to the plugin. That entry point
 exports the manifest/factory types, port types, fake adapters, and reusable
 TicketSource, AgentRunner, WorkspaceProvider, Forge, BuildStore, and BlobStore
 contract suites. Adapter values may use the backward-compatible bare factory or
-carry a contract fixture descriptor. Ticket sources may also declare
+carry a contract fixture descriptor.
+TicketSource adapters must populate the required `Ticket.resolved` boolean on
+listReady, get, and create projections, using the same native lifecycle rules as
+`dependencyStates`. Plugin authors upgrading older adapters must add this field;
+ready-state membership does not imply that a ticket is unresolved. Dispatch
+reuses these facts only within the current tick. Ticket sources may also declare
 `requiredEnv`; the host checks every declared variable for a nonempty value
 before invoking the adapter factory. Plugins using Forge abort-cleanup and
 AgentRunner turn-cancellation capabilities introduced in API 1.2 should require
@@ -1259,6 +1279,15 @@ triageState = "Backlog"
 Linear credentials do not belong in this table. Set `LINEAR_API_KEY` in the
 environment or local `.env` file described below.
 
+[Linear's request budget](https://linear.app/developers/rate-limiting) is shared
+by every dispatcher and `ab ticket` command using the API key, and by other keys
+belonging to the same authenticated user. A rate-limited ready scan or dependency
+read fails the evaluation tick without new intake claims or synthetic
+dependency-blocked counts. That source instance suppresses requests until the
+reported reset time; the next call then runs normally. Missing, invalid or expired
+reset headers use a conservative 60-second cooldown. Cooldowns are local to the
+instance: processes and restarts do not coordinate their budgets.
+
 For a hosted backend, repository policy remains local while credentials remain
 at the service:
 
@@ -1323,7 +1352,7 @@ restart-classified as a whole.
 | `model` | — | nonblank string, required when `enabled = true` | Provider-qualified model string for the turn runner, in the same vocabulary as `[roles]` model strings (a leading `vercel-ai-gateway/` prefix is accepted and stripped). Resolved through the deployment's gateway credential. |
 | `invocationBudgetSeconds` | `240` | positive integer, clamped to 300 | Wall-clock budget for one turn invocation. A larger value is clamped — not rejected — to the 300-second hosted function limit the runner executes under (`ORCHESTRATOR_ROUTE_LIMIT_SECONDS`, the same number the operator route pins as `maxDuration`). |
 | `approvals` | see below | array of `tool` or `tool:qualifier` strings | Registry tool names whose calls suspend a turn until the operator answers. Default: `["builds.control:abort", "builds.control:discard", "builds.answer:revise-spec", "sandbox.publish", "tickets.move:ready"]`. Empty (`[]`) means none — autonomous operation. An entry naming an absent or unknown tool is **inert by design**, never a config error: the list stays stable while the registry grows, and a tool's removal cannot break parsing. A `tool:qualifier` entry applies to the named discriminator value only (for example `tickets.move:ready` approves moving a ticket to `ready`); for a tool without a discriminator, only the bare form matches. |
-| `wake` | inherits the default | array of event-type globs | The attention events a **new** session wakes for. Kept schema-optional so absent (inherit the default attention set — the build events `ab watch` filters on by default plus the repository-journal events `ab watch --repository` follows) and `[]` (never wake; message-only) stay distinct. Each glob must match at least one build or repository-journal event type, validated with the same compiler `ab watch` uses. Existing sessions never retroactively inherit; an explicit `PUT .../wake` always wins. |
+| `wake` | inherits the default | array of event-type globs | The attention events a **new** session wakes for. Kept schema-optional so absent (inherit the default attention set — the build events `ab watch` filters on by default plus the repository-journal events `ab watch` follows) and `[]` (never wake; message-only) stay distinct. Each glob must match at least one build or repository-journal event type, validated with the same compiler `ab watch` uses. Existing sessions never retroactively inherit; an explicit `PUT .../wake` always wins. |
 | `sandbox` | — | strict subtable; absence reads as the defaults | Sandbox behavior knobs. |
 
 `[orchestrator.sandbox]` fields:
@@ -1572,10 +1601,8 @@ pre-attempt index and reports the original Git failure; merged worktree files
 remain in place and the merge's exit status is unchanged. Upgrade never pushes
 or rewrites history.
 
-Autobuild now installs 12 skills; only `ab-spec`, `ab-tickets`, and `ab-guide`
-are model-invocable. (`ab-operate` — the embedded orchestrator's operating
-manual — also carries `disable-model-invocation: true`; it is read by the
-hosted turn runner, never invoked by a model in a build session.) The setup reference is an ordinary support file in the
+Autobuild now installs 12 skills; only `ab-spec`, `ab-tickets`, `ab-guide`,
+and `ab-operate` are model-invocable. The setup reference is an ordinary support file in the
 editable/pristine `ab-guide` tree and participates in the same three-way
 upgrade merge as every other vendored file.
 

package/docs/operator-api.md

@@ -184,3 +184,20 @@ The API does not expose phase-session commands, runner startup, a push or
 long-poll streaming transport, or a generic event-append operation; event
 streaming is composed client-side by `ab watch`, which polls the store's
 event reads.
+
+
+Dispatcher liveness is also visible through `ab repository status --json`:
+`dispatcher.holder` identifies the unexpired repository lease owner, independently
+of `latestRun`. Heartbeat age measures attributable renewals; tick age measures
+durable progress. Missing historical evidence is null. The liveness query uses
+bounded repository facts first, with a full-history fallback when a later
+invocation hides the holder start or the latest stop. Other state reads retain
+their bounded semantics.
+
+Repository-following `ab watch` additionally emits a read-only `dispatcher.lost`
+observation when an observed lease expires without a matching stop. JSON carries
+`observation` instead of `event`, with run, observedAt, leaseExpiresAt and available
+identity, plus the usual repo/build/state/cursor fields. It invents no durable
+sequence or actor. Retain the cursor to avoid repeat reports across invocations.
+No lease alone is not evidence of death. SIGINT, SIGHUP and SIGTERM drain dispatch,
+record the first signal in the stop fact, and release its lease before exit.

package/docs/remote-ticket-protocol.md

@@ -77,3 +77,8 @@ The shared `TicketSource` contract is normative for the database adapter and
 the hosted client/server pair. External pass-through is tested with a fake
 source behind HTTP. The existing opt-in live Linear contract remains the proof
 of Linear's GraphQL behavior; the hosted service uses that adapter unchanged.
+
+Every ticket returned by list, get, or create requires a boolean `resolved`,
+with the same source-native completion semantics as `DependencyState.resolved`.
+The client preserves it when remapping ticket references. Missing or non-boolean
+values fail wire validation. Client and service still require exact version matches.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@defrex/autobuild",
-  "version": "0.10.0",
+  "version": "0.11.0",
   "description": "Agent-driven software delivery from groomed ticket to merged PR",
   "repository": {
     "type": "git",
@@ -139,8 +139,8 @@
   },
   "devDependencies": {
     "@biomejs/biome": "2.5.5",
-    "@defrex/autobuild-postgres-store": "0.9.0",
-    "@defrex/autobuild-vercel-sandbox": "0.9.0",
+    "@defrex/autobuild-postgres-store": "0.10.1",
+    "@defrex/autobuild-vercel-sandbox": "0.10.1",
     "@resvg/resvg-js": "2.6.2",
     "@types/bun": "^1.3.14",
     "@types/node": "^24.0.0",

package/packages/core/src/cli/binary.ts

@@ -53,7 +53,7 @@ export async function withDispatchTerminalRestore<T>(
   terminal: TerminalOut,
   run: () => Promise<T>,
   boundary: TerminalRestoreProcess = process as unknown as TerminalRestoreProcess,
-  requestStop: () => void = () => {},
+  requestStop: (signal: NodeJS.Signals) => void = () => {},
 ): Promise<T> {
   const hook =
     command === 'dispatch'
@@ -96,7 +96,7 @@ export async function runBinary(
     // cleanly at the next tick boundary (§15.6-C: in-flight leases expire and
     // a future dispatch re-attaches).
     const controller = new AbortController()
-    const onSigint = (): void => controller.abort()
+    const onSigint = (): void => controller.abort('SIGINT')
     const ownsSigint = usesGenericSessionlessSigintHandler(command)
     const terminal = processTerminal(process.stdout)
     const removeSigint = installSessionlessSigintHandler(command, onSigint)
@@ -119,7 +119,7 @@ export async function runBinary(
             ...(resolveDashboardRenderer !== undefined ? { resolveDashboardRenderer } : {}),
           }),
         process as unknown as TerminalRestoreProcess,
-        onSigint,
+        (signal) => controller.abort(signal),
       )
     } finally {
       removeSigint()

package/packages/core/src/cli/dashboard/model.ts

@@ -268,6 +268,8 @@ export interface DashboardModel {
   harvestPaused: boolean
   /** Stable row identity, never a row index. */
   selection?: DashboardSelection
+  /** Invocation-local standby identity, independent of notices and build rows. */
+  standby?: string
   /** Release courtesy, separate from transient and startup warnings so those
    * notices can never overwrite one another. Store-only frontends project it
    * from their correlated dispatcher run. */
@@ -1090,6 +1092,7 @@ interface DashboardFrameHeader {
   queued: number
   observationCount: number
   selection?: DashboardSelection
+  standby?: string
   availableUpgrade?: string
   warningLines?: readonly string[]
   resumeInput?: ResumeInputView
@@ -1125,6 +1128,7 @@ export function buildDashboardFromProjected(
     defaultAutoMerge: settings.defaultAutoMerge,
     harvestPaused: harvestProjection.harvestPaused,
     ...(header.selection !== undefined ? { selection: header.selection } : {}),
+    ...(header.standby !== undefined ? { standby: header.standby } : {}),
     ...(header.availableUpgrade !== undefined ? { availableUpgrade: header.availableUpgrade } : {}),
     ...(header.warningLines !== undefined && header.warningLines.length > 0
       ? { warningLines: header.warningLines }