@defrex/autobuild 0.10.1 → 0.12.0

package/skills/guide/references/setup.md

@@ -28,7 +28,7 @@ maintainer before selecting it:
 - a dispatcher-side push-capable `GITHUB_TOKEN` or `GH_TOKEN`;
 - for a private repository, a separate read-only clone identity named by
   `gitUsernameEnv` and `gitPasswordEnv`;
-- an HTTPS hosted `AB_STORE` reachable from Vercel and a scoped `AB_TOKEN`;
+- an HTTPS hosted service reachable from Vercel, configured through `ab connect <url>`;
 - each selected role and alternate's runtime/model, its pinned
   `[workspace.config.runtimeProvisioning.<runtime>]` commands, and the API
   credential names it needs in `[workspace.config].environmentVariables`.
@@ -177,7 +177,7 @@ ab dispatch --repository https://github.com/owner/repository \\
 ```
 
 `--repository` (or `AB_REPOSITORY`) is the normalized origin. Origin mode
-requires an HTTPS `AB_STORE` plus `AB_TOKEN`, an exported `GITHUB_TOKEN` or
+requires an HTTPS service selected through `[store] url` or `AB_STORE`, a saved project credential or `AB_TOKEN`, an exported `GITHUB_TOKEN` or
 `GH_TOKEN`, and `forge = "github"`; the interactive dashboard is unavailable
 (`--plain` or no TTY). Origin mode never consults the gh CLI: a checkout-less
 host has no gh and no keyring, and the only workspace provider it can run,
@@ -208,17 +208,34 @@ sources agree with the running system by construction:
   **running dispatcher's version** (read from the deployed distribution's
   `package.json`), so the guest runs the dispatcher's own release.
 
-The hosted remote store enforces exact **version lockstep**: every client
-request must carry an `x-autobuild-version` equal to the server's, and any
-mismatch — a guest older *or* newer than the store — is rejected with a 409
-`remote store version mismatch`. Guest, store, and dispatcher versions
-therefore cannot be mixed: a distribution fix reaches guests only after
-`tools/release.ts` cuts a release (credential-gated; requires GitHub
-credentials — a documented delivery dependency, not an automatic propagation)
-**and** the hosted store and dispatcher are upgraded to that release in the
-same lockstep window. If the release is cut but the store upgrade lags, guests
-carrying the new distribution fail loudly against the old store (409) rather
-than running silently stale.
+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.
+
+`ab upgrade` probes this public range before installation or project changes.
+It warns and continues when the target is outside the range, naming the
+required service upgrade for a newer target or a compatible project range for
+an older one. An unavailable or malformed probe warns that connectivity may
+fail after upgrade. Legacy health without a range means exact-version matching;
+upgrade that service to the compatibility-window release first.
+
+A distribution fix reaches origin-mode guests after a release is cut and the
+dispatcher is upgraded. Guests continue to run the dispatcher's own version;
+the hosted service must support that release line.
 
 Provisioning records the installed distribution's identity — package version
 and remote-store protocol version — in the guest's
@@ -229,10 +246,10 @@ against the identity the current system would deliver and, when they disagree
 (which includes every guest provisioned before the marker existed), refreshes
 it in place (archive re-fetched, extracted, and production-installed) first,
 so an upgraded dispatcher retrofits its existing guests instead of resuming a
-stale distribution the hosted store would reject. A refresh failure deletes
+stale distribution. A refresh failure deletes
 the sandbox so the next provisioning pass rematerializes it from scratch.
 
-After a lockstep upgrade, confirm a fix-bearing guest from the guest
+After a dispatcher upgrade, confirm a fix-bearing guest from the guest
 perspective:
 
 1. `ab build status <slug> --json` with the ambient build identity for a
@@ -250,7 +267,7 @@ apart from the identity change, `ab dispatch` behaves as it did.
 A hosted-store deployment configures its web/auth variables once — see the
 hosted service README and the complete environment reference in the pinned
 distribution checkout: `BETTER_AUTH_URL`, `AB_WEB_ALLOWED_EMAILS`,
-`AB_WEB_REPOSITORIES`, and the optional `AB_WEB_MCP_RESOURCE` — the protected
+and the optional `AB_WEB_MCP_RESOURCE` — the protected
 resource the hosted MCP server (docs/mcp.md) binds its OAuth tokens to,
 defaulting to `<BETTER_AUTH_URL>/mcp`. Set it only when a proxy or custom
 domain fronts the deployment under a different public URL than
@@ -258,6 +275,93 @@ domain fronts the deployment under a different public URL than
 production) or every MCP client's discovery binds tokens to the wrong
 resource.
 
+
+## Connect a project
+
+From a checkout with an origin remote, run `ab connect https://YOUR_ORIGIN`.
+The CLI prints a verification URL and short code and attempts to open a browser.
+Sign in as an allowed owner, check the full repository identity and code, and
+approve or deny. Another device can open the printed URL, or visit `/connect`
+and enter the code. Approval requires the web-enabled service origin; a
+standalone machine-only listener cannot present browser consent. Requests
+expire after ten minutes. Denial and timeout leave local configuration unchanged.
+
+On approval the service registers the project and issues a project credential.
+The CLI keeps it in `$XDG_CONFIG_HOME/autobuild/credentials` (or
+`~/.config/autobuild/credentials`), keyed by normalized service and origin,
+with directory mode 0700 and file mode 0600. Credentials never belong in the
+repository. It adds the non-secret `[store] url` to `autobuild.toml` when
+absent; review and commit that change yourself. An existing different URL
+must be changed explicitly before connecting. Reconnecting replaces the saved
+credential only after approval and revokes the previous credential.
+
+All worktrees share the main checkout's configuration and the user's saved
+credential. A service manager running as that user uses the same HOME and
+XDG_CONFIG_HOME, with no AB_STORE or AB_TOKEN exports. A fresh clone with
+committed store configuration but no saved credential fails with `ab connect`
+guidance; it never silently creates local state. Run connect on each host/user.
+
+`ab connect` without a URL reports service, project, and credential status:
+accepted, rejected, missing, or unreachable. `ab disconnect` revokes the saved
+credential remotely before removing it locally, keeping the project registered,
+its data, and store configuration. A network/server failure retains the local
+entry for retry; an already revoked credential can be removed. If saving a new
+connection fails, the CLI cancels/revokes it and retains the previous entry.
+If remote cleanup cannot be confirmed, check the printed credential id with
+the owner's administrative tools before retrying.
+
+Store selection is `--store` > nonblank `AB_STORE` > `[store] url` > the
+main checkout's `.autobuild/`. `AB_TOKEN` overrides the exact service/project's
+saved credential for CI and other non-interactive hosts. A service override
+never borrows another service's credential. Build and harvest sessions keep
+their explicit scoped authority.
+
+## Connected projects
+
+Migrate PostgreSQL from the pinned release before deploying (`bun run
+postgres:migrate`). The service keeps an independent, durable project registry;
+existing build or ticket data does not register a project. An administrator
+with deployment database credentials manages it without redeploying:
+
+```sh
+ab-hosted-store projects list
+ab-hosted-store projects add https://github.com/owner/project --user owner@example.com
+ab-hosted-store projects remove https://github.com/owner/project --user owner@example.com
+```
+
+From a source checkout, substitute `bun packages/hosted-store-service/src/bin.ts`
+for `ab-hosted-store`. Configure `AB_POSTGRES_URL` or `DATABASE_URL` in that
+process. Database possession grants administration; `--user` is declared audit
+attribution, not a verified login. Ordinary project/store tokens cannot manage
+registrations. Each entry records the normalized origin URL, addition time,
+and adding identity. SSH git spellings normalize to HTTPS; local paths and
+credential-bearing HTTPS URLs are rejected. Duplicate adds preserve metadata;
+remove is idempotent, and re-adding records a fresh addition.
+
+Every allowlisted signed-in user owns every registered project. The dashboard,
+MCP discovery and calls, and every operator API route consult current
+registration. Removal hides a project from all these surfaces and subsequent
+hosted dispatcher invocations; builds, events, artifacts and tickets remain,
+and re-registration restores access. Already-started work is not cancelled.
+Project credentials issued by connect authorize only their registered project. Administrative credential issuance remains available for non-interactive hosts.
+
+Link directly to `/?repo=<URL-encoded normalized origin>`. The page selects the
+first registered origin when the requested one is missing or removed, and an
+empty registry shows no project data or controls. Registry errors fail closed;
+there is no environment fallback on database failure.
+
+`AB_WEB_REPOSITORIES` is deprecated. A nonempty CSV is imported exactly once per
+database, on the first registry initialization with that variable configured,
+with actor `system:AB_WEB_REPOSITORIES`. The import and durable marker commit
+atomically across concurrent starts. An absent variable does not consume the
+marker. Later restarts or edits to the variable never re-add removed projects;
+use the owner commands for subsequent administration.
+
+The hosted dispatcher queries current registrations on every authorized
+invocation. With `AB_DISPATCHER_REPOSITORIES` unset, it serves all registered
+projects; an explicit list preserves its order and is intersected with current
+registration. An empty registry is a successful zero-project invocation.
+
 ## Authoring an agent verifier
 
 A repository-owned agent-verify skill is a verifier, not a reviewer: it drives
@@ -290,3 +394,56 @@ explanation, never a skip or silent pass. Use `skip` only when the complete step
 does not apply. If guidance still cannot make a verdict possible, escalate and
 explain what remains unresolved. Record out-of-scope work with `ab observe`;
 the verifier does not fix it.
+
+### Project-scoped hosted tickets
+
+Hosted ticket queues belong to the credential's registered repository, even
+when projects share a team key. The latest uploaded effective `[tickets]`
+configuration owns lifecycle: hosted defaults are Backlog / Doing / Done,
+`readyState` is required, `doneState` customizes completion, and create/proposal
+default to triage. The union of configured roles is allowed; roles may overlap.
+Owner admin requests require an explicit registered `context.repo`; project
+credentials cannot select another project. Missing effective configuration is
+an actionable refusal: run the project's dispatcher to publish it.
+
+The service never contacts Linear. Projects with external sources (including
+file and Linear) keep using those sources directly through their dispatcher;
+service ticket HTTP, operator and MCP surfaces refuse with project/source
+feedback rather than returning an empty queue. Removed `AB_TICKET_BACKEND` and
+`LINEAR_API_KEY` values are ignored with one startup removal message, including
+blank/unknown values. Removed `AB_TICKET_TRIAGE_STATE`, `AB_TICKET_READY_STATE`,
+`AB_TICKET_DOING_STATE` and `AB_TICKET_DONE_STATE` values are ignored even when
+malformed. None of these retired settings prevents startup.
+
+The environment-aware migration imports `AB_WEB_REPOSITORIES` once before
+ownership preflight, including released main-v9 deployments without registry
+tables. A failed migration rolls back the import, main-schema promotion and
+ticket changes together. Owner `projects add` and `tickets assign-team` commands
+bootstrap only the registry/recovery journals and work while the main marker
+is still v9. Without the retired environment, first register the intended
+project with `ab-hosted-store projects add REPOSITORY --user IDENTITY`, then
+assign the team and rerun migration. A successful one-time import is never
+reapplied from later environment edits.
+
+Ticket schema v1 migration assigns each whole legacy team to its sole claimant
+among registered projects' latest effective configs, reading their actual blob
+bytes. Projects with no dispatcher run or no effective-config reference make
+no team claim and do not block other projects. Unclaimed teams still fail closed.
+When inferring ownership, a selected configuration whose revision/blob is missing,
+unreadable or invalid stops unchanged with recovery guidance. Restore the selected
+configuration or assign every remaining legacy team explicitly; complete owner
+assignments to registered projects bypass unrelated configuration reads. Conflicts
+and asset ownership mismatches also stop unchanged. Resolve ownership, then rerun:
+
+```sh
+ab-hosted-store tickets assign-team TEAM https://github.com/acme/app --user owner@example.com
+ab-postgres-store migrate
+```
+
+The assignment journal works before v2 assertion, retains the actor, and grants
+no future cross-project access. Migration preserves ids, states, comments,
+blockers, timestamps and assets. Populated-v1 migration and deployment builds
+require the running service's blob backend, access mode, credentials and prefix
+(`AB_BLOB_PREFIX`), not just PostgreSQL access. `deploy:build` inherits this
+environment and migration failure stops Next build. Fresh databases, empty v1
+queues and v2 reruns stay SQL-only and do not initialize blob storage.

package/skills/guide/references/ticket-dependencies.md

@@ -2,7 +2,7 @@
 
 `ab ticket create --blocked-by` validates prerequisite ids and records blocking
 relationships, but a single CLI command is **not an atomic publication guarantee**.
-In particular, direct Linear and hosted Linear create the issue first and add
+In particular, direct Linear creates the issue first and adds
 its blocker relationships in separate requests. If the issue is already in the
 ready state, a dispatcher can see it before those relationships exist. A
 successful create response containing every blocker does not prove that no build

package/skills/operate/SKILL.md

@@ -24,20 +24,83 @@ after them apply to both.
 
 ## Running locally with the `ab` CLI
 
-Run the commands below from the repository root. Each acts with the operator's
-authority, so say what you are doing before you do anything destructive.
+Each command acts with the operator's authority, so say what you are doing
+before you do anything destructive.
+
+### Resolve the local invocation first
+
+Before your first Autobuild command, read the repository's package manifests
+and package-manager evidence. A direct `@defrex/autobuild` declaration in
+`dependencies` or `devDependencies` requires the repository's installed
+version. The manifest's own `name` and a transitive dependency are not declarations.
+
+Determine the package manager from `packageManager` and the lockfile:
+`bun.lock` / `bun.lockb`, `package-lock.json` / `npm-shrinkwrap.json`,
+`pnpm-lock.yaml`, or `yarn.lock`. Resolve workspace context from the manifest
+declaring the dependency and the repository's package-manager configuration.
+If evidence conflicts or cannot establish the manager, diagnose and tell the
+operator instead of guessing.
+
+Verify that the dependency is already installed and that its installed package
+exposes the `ab` binary you will execute. For node_modules installs, verify
+that `./node_modules/.bin/ab` resolves to that installed
+`@defrex/autobuild` package, not another package or a global binary. For Yarn
+PnP, use Yarn's installed dependency and binary evidence to establish ownership.
+Run from the resolved repository/workspace directory:
+
+| Package manager | Local-only invocation |
+| --- | --- |
+| Bun | `bun run ./node_modules/.bin/ab …` |
+| npm | `npm exec --offline --no --call './node_modules/.bin/ab …'` |
+| pnpm | `pnpm exec ./node_modules/.bin/ab …` |
+| Modern Yarn | `yarn run --binaries-only ab …` |
+| Yarn Classic | `yarn run ab …` |
+
+Replace the ellipsis with CLI arguments; for npm they go inside the quoted
+call, with appropriate shell quoting. Do not add `--package` or an inferred
+package name. The explicit path prevents global PATH fallback, and npm's
+offline/no flags prevent registry installation. Modern Yarn's binary-only
+selection supports installed PnP dependencies without assuming node_modules.
+Before using Yarn Classic, verify its installed local binary and check that
+`scripts.ab`, `scripts.preab`, and `scripts.postab` cannot intercept the
+command. Report a script conflict instead of executing it.
+
+These forms execute an already-installed dependency. A missing dependency,
+unavailable binary, or failed local execution must be reported to the operator;
+never hide it with global fallback or install dependencies automatically.
+Never use bare `bunx ab`, `npx ab`, `dlx`, or other registry-fetching
+variants: the registry package named `ab` is not Autobuild. Offline cache
+availability alone does not prove a local installation.
+
+Only when no local declaration exists may you use global `ab`. In either
+case run the resolved invocation with `--version` and report the invocation,
+working directory, and actual version when you start orchestrating.
+
+Every `ab …` example in this skill means this resolved invocation, run from
+the same resolved working directory.
 
 ### Watch for attention events
 
-`ab watch --json` streams the attention set (escalations, failures, finalize,
-PR conflicted/merged/closed, build completed/aborted) as newline-delimited
-records. Every record carries a `cursor`; a bounded watch ends with a trailing
-`{"cursor": …}` line. Resume with `--since <cursor>` and every event after it
-is delivered exactly once, including events that landed while nothing was
-watching. Name slugs to watch only those builds; with none, every active build
-(including ones created later) is watched. `--event <glob>` replaces the
-default filter, `--timeout <dur>` bounds it (default 30 minutes, `0` is
-unbounded), `--count <n>` ends it after n records.
+`ab watch --json` is the standing monitor. Keep its default filter: every
+record calls for action. It reports build escalations and merge decisions,
+harvest escalations/recovery exhaustion, rejected configuration, reloads needing
+restart, abnormal dispatcher stops/loss, degradation past reset (15 minutes
+without reset), and five minutes of continuous tick failures. Advertised resets
+wait for a post-reset tick to finish before requiring action; ordinary recovery
+on that retry stays silent. Source grace and cooldown-driven failures do not
+start the tick-failure clock. Routine outcomes and self-healing failures stay silent.
+
+Every record carries a cursor; bounded watches end with a bare `{"cursor": …}`
+line. Resume with `--since <cursor>`. Named watches end when all named builds
+are terminal; add `--repository` for repository attention. With no slugs all
+active builds and repository attention are included. Reconcile status after
+arming because historical build attention is silently baselined.
+
+Add an extra monitor only for an identified need, such as an operator asking
+to hear when a particular build merges or an outcome triggering follow-up work.
+Scope it to named slugs and explicit `--event` globs (for example,
+`ab watch my-build --event pr.merged --json`), and retire it when that need ends.
+An extra monitor supplements the default standing watch.
 
 `ab wait [<slug>...] (--for <condition> | --event <glob>) [--since <cursor>] [--json]`
 blocks until a condition holds and prints one record. `--for` state conditions
@@ -51,7 +114,44 @@ bare `{"cursor": …}` to resume from.
 
 Run long watches and waits in whatever background or monitor facility your
 harness provides, so the session stays responsive and you are woken when they
-emit. Never block a foreground command for their whole duration.
+emit. Use precisely the same resolved invocation and working directory as
+foreground commands, including inside background shells and harness monitors.
+Do not rely on a shell alias or function that those facilities may lose.
+Never block a foreground command for their whole duration.
+
+Ticket-source degradation records mean dispatch intake cannot evaluate the source;
+existing builds may still advance. Inspect `ab repository status --json` for the
+active cause, operation, message, and expected reset. Reset times are advisory;
+recovery means reads actually succeeded. Allow the existing cooldown and retry
+behavior, investigate persistent ready-scan failures or a condition still active
+after its reset estimate, and keep watching through recovery. Empty builds do
+not establish idle intake; diagnose persistent trouble and report it to the operator.
+
+Repository records have null build and state. Handle them with repository
+status rather than build commands, keep their cursor, and re-arm. A legacy
+cursor without a repository position baselines that stream at attachment and
+cannot recover its earlier interval: reconcile current repository status.
+`ab wait --for attention` remains build-only and does not replace a repository
+attention watch.
+
+
+Check dispatcher liveness with `ab repository status --json` after a watch
+timeout or `dispatcher.lost` observation, or when dispatch appears unhealthy. Do not
+use process lists to decide whether a dispatcher owns this repository. The
+`dispatcher` projection distinguishes `held` (an unexpired lease), `lost`
+(expired ownership without a recorded stop), `stopped`, and `absent`. Its holder
+identity resolves a yield message to run, pid, host, start time, and heartbeat
+age. Historical identity and a new holder's heartbeat may be unknown until its
+first attributable renewal. Source degradation or an old tick alone does not
+establish loss: a healthy lease can accompany a slow tick.
+
+An unscoped watch, or a named watch with `--repository`, reports loss as a
+read-only observation: `{repo, build:null, state:null, observation:{type:
+"dispatcher.lost", run, observedAt, leaseExpiresAt, ...identity}, cursor}`.
+It has no durable event envelope. Keep its cursor just as for event records;
+resuming it suppresses repeated loss reports for that run. Inspect repository
+status to diagnose the condition and report dispatcher trouble to the operator.
+Neither a loss observation nor a later retry authorizes dispatcher intervention.
 
 ### Keep watching until the work is done
 
@@ -59,8 +159,8 @@ Checking once is not shepherding. When you take responsibility for builds:
 
 1. Record the set you are shepherding (`ab builds --all --json`, or the slugs
    you were given).
-2. Arm an event-only watch and keep its cursor:
-   `ab watch <slugs…> --json --since <cursor>` (omit `--since` the first
+2. Arm the default standing watch and keep its cursor:
+   `ab watch --json --since <cursor>` (or named slugs with `--repository`) (omit `--since` the first
    time). Events are delivered exactly once, so a build that already finished
    is never replayed. Do not loop on `ab wait --for terminal|attention|…`:
    state conditions are satisfied at once by any build already in that state,
@@ -72,14 +172,16 @@ Checking once is not shepherding. When you take responsibility for builds:
    current position and does not emit what already happened, so a build that
    merged, or an escalation already open, before registration would otherwise
    never reach you. Run `ab build status <slug> --json` for every slug in the
-   set. Reading status after arming leaves no gap — anything earlier shows in
+   set, and `ab repository status --json` for source health, initially and after
+   every timeout or legacy-cursor attachment. Reading status after arming leaves no gap — anything earlier shows in
    the status, anything later arrives as an event. Treat a terminal status
    (merged, closed, aborted) as that build's outcome, and an open escalation
-   or failed phase as attention to handle now.
+   or merge decision as attention to handle now.
 4. When a watch returns records, react: read the record, inspect the build,
-   answer or escalate, then re-arm from the last cursor. Keep your own
-   outcome table: mark a build done when you see `pr.merged`, `pr.closed`, or
-   `build.aborted`, or when status shows it. A timeout (exit 3, or a watch
+   resolve attention using the shared rules; for a repository record inspect repository status and act
+   on its condition without assuming a build slug. Then re-arm from the last cursor. Keep your own
+   outcome table from status reconciliation after named-watch exit and bounded
+   watch timeouts. Default watches do not emit routine merge/completion records. A timeout (exit 3, or a watch
    that ends with only a `{"cursor": …}` line) is not completion — reconcile
    as in step 3, then re-arm from that cursor.
 5. Stop only when every build in the set has an outcome in your table.
@@ -206,19 +308,24 @@ report it, adapt, and carry on.
 
 ### The attention set
 
-When the session has wake settings, the dispatcher wakes you when a build
-event matching them lands. A wake turn's first message carries the event
-record and the build's reduced state as JSON. Typical wakes and what to do:
-
-- `escalation.raised` / `phase.failed` / `infrastructure.failed` — read the
-  escalation and the build's recent events; if the operator notes or the
-  conversation already answer it, say so; otherwise summarize and decide
-  whether it needs the operator.
-- `finalize.completed` / `build.completed` / `pr.merged` / `pr.closed` /
-  `pr.conflicted` / `build.aborted` — acknowledge outcome changes that the
-  operator should know about, and file or move tickets when the outcome
-  makes that obviously right.
-- Anything else matching the wake settings — read the event, then decide.
+A wake turn's first message carries the configured event record and the
+build's reduced state as JSON. Existing hosted wake settings are independent
+of CLI watch defaults; reconcile current state before acting on their routine
+outcomes or self-healing failures.
+
+Treat every default-watch record as a call to act:
+
+- `escalation.raised`: inspect the question and evidence, then resolve it using
+  the shared rules.
+- `build.merge-decision`: inspect the PR and current merge gate, then apply
+  the operator's merge policy or request the decision that is missing.
+- Harvest escalation or recovery exhaustion: inspect harvest status and resolve
+  the reported blocker.
+- Dispatcher loss, abnormal stop, restart-required reload, rejected config, or
+  persistent tick failure: diagnose through repository status and report the
+  condition to the operator. Never start or run a dispatcher.
+- Persistent source degradation: inspect the source cause and reset evidence,
+  diagnose and report the continuing intake problem.
 
 Do not re-derive history the build's events already tell you; read events
 with a cursor and keep it short.
@@ -227,6 +334,16 @@ with a cursor and keep it short.
 
 These apply in both settings. Where the text below says "plain streamed text", a local session means plain text to the human in the session.
 
+### Resolve attention by default
+
+Make a best effort to resolve attention without operator input. Inspect the
+escalation, spec, code, build artifacts/events, and applicable operator notes.
+Answer questions supported by that evidence, retry when the evidence warrants
+it, and file or move tickets where that is clearly right, within the existing
+ready-state authorization boundary. Investigate before asking; the exceptions
+below govern when the evidence or available tools cannot resolve the issue,
+or a human decision is required.
+
 ### When to escalate instead of act
 
 Stop and ask the operator — in plain streamed text — whenever:
@@ -238,11 +355,19 @@ Stop and ask the operator — in plain streamed text — whenever:
 - A tool refusal repeats and you cannot resolve it with the tools you have.
 - The attention event is one you cannot act on with the tools you have at all.
 
-Filing a ticket IS acting — do it when the request is concrete. Asking is
-not a failure; an unasked destructive action is.
+Filing a ticket is acting — do it when the request is concrete. Default to
+resolving attention yourself within these boundaries; ask the operator only
+for the exceptions above.
 
 ### Boundaries
 
+- Never start, restart, or stop a dispatcher: no `ab dispatch` in any mode,
+  and no dispatcher process-management commands. This applies when the
+  dispatcher is lost, stopped, absent, or failing repeatedly. Its lease,
+  process, and configuration management belong to the operator. Diagnose
+  through repository status and report trouble to the operator; reporting
+  does not authorize process intervention, including on a later retry.
+
 - You never claim to have done anything outside the tools you have. If you cannot
   observe it with a tool, say you cannot observe it.
 - You never invent repository identity, ticket ids, or build slugs; every

package/templates/hosted-service/package.json

@@ -0,0 +1,13 @@
+{
+  "private": true,
+  "scripts": {
+    "build": "ab-hosted-service-build"
+  },
+  "dependencies": {
+    "@defrex/autobuild-hosted-store-service": "0.12.0",
+    "@defrex/autobuild": "0.12.0",
+    "next": "16.1.6",
+    "react": "19.2.4",
+    "react-dom": "19.2.4"
+  }
+}

package/templates/hosted-service/vercel.json

@@ -0,0 +1,7 @@
+{
+  "$schema": "https://openapi.vercel.sh/vercel.json",
+  "framework": "nextjs",
+  "installCommand": "bun install --frozen-lockfile",
+  "buildCommand": "bun run build",
+  "bunVersion": "1.4.x"
+}