@shivaedev/work-fleet 0.2.1 → 0.4.0

package/CHANGELOG.md

@@ -1,5 +1,60 @@
 # Changelog
 
+## 0.4.0 - 2026-10-18
+
+### Added
+
+- `readRetryMs` in Fleet policy and `fleet.config.json` sets the first provider and integration read-retry delay, defaulting to 30 seconds; later retries still double it. The daemon applies an edited value without a restart.
+
+### Fixed
+
+- Conflict repairs on existing PRs keep or regain their area ahead of prepared items with terminal provider attempts.
+
+### Breaking
+
+- `readHostConfig` and `loadHost` moved from `@shivaedev/work-fleet/host/config.ts` to `@shivaedev/work-fleet/host/configFile.ts`.
+
+## 0.3.0 - 2026-10-17
+
+### Added
+
+- `cloud.recoveryGraceMs` in the host configuration sets how long Fleet polls an acknowledged, empty Cloud thread for a late-accepted turn before it starts the saved turn on that thread. The default stays five seconds.
+- The Fleet daemon watches its config file and applies valid edits to `concurrency`, `backlog`, `intervalSeconds`, `quota`, `launch`, `openPullRequests`, `stallMinutes`, `areaMergeWaitMs` and worker or reviewer guidance on the next scheduler pass or launch, without a restart. Running turns keep their launch settings.
+- Edits to restart-only settings such as `provider`, `database`, `namespace` or `cloud` keep their running values and are reported as needing a restart. An invalid or partly written file keeps the last good config and logs a `HostConfigRejected` warning naming the failing field.
+- `work-fleet status` shows the config the daemon applies, when it was loaded, the settings waiting for a restart and the last rejected edit; `daemon.status` returns it as `config`.
+- `openPullRequests: { ease, max, floor? }` in `fleet.config.json` slows new implementer launches as Fleet-owned open PRs pile up: full `concurrency` up to `ease` open PRs, then linearly fewer down to `floor` (default 0) at `max`. Held items wait with `waiting for open PRs to merge: <open> of <max>`. Reviews, repairs and answers are never throttled, and when slots are short they go ahead of new implementers.
+- `work-fleet dispatch --now <id>`, or `fleet-priority: urgent` in a task's frontmatter, launches the item over `concurrency`, the open-PR curve and `backlog` while still respecting area claims and dependencies; `--ignore-areas` also skips area claims. `work-fleet status` marks such launches as `launched over the limit`.
+- `fleet-priority: urgent | high | normal` in task frontmatter orders prepared work for admission when slots are short.
+- `Fleet.recordResponse(workId, decisionId, responseId)` validates a saved Board response, marks it durably and applies it in the Fleet service's background scope. Reconciliation can recover the saved response after a restart.
+- `ANSWER_RECORDED` in `attention.ts` identifies pending answer application. `answerWork` accepts an optional background flag, and `daemonRequest` accepts a request name and timeout in milliseconds.
+- `DispatchRequest` receipts record acceptance and completion or failure independently of preparation. `dispatchStore(namespace)` persists the latest receipt per item; `dispatchRequests(host)` runs pending requests in the daemon scope and resumes them after a restart. `daemon.dispatch-status` reads the receipt, and `FleetViews.dispatches` exposes pending and failed requests to status.
+
+### Fixed
+
+- The daemon records and applies an answer or release even when the CLI stops waiting for it. Before, a client timeout interrupted the request and the answer was lost.
+- Daemon answers and releases share one watched Board response index instead of reindexing the whole Board for every request.
+- `work-fleet answer --release` without text no longer waits for stdin.
+- Scheduler passes no longer rewrite prepared work whose wait reason is unchanged, and Fleet record lists reuse decoded records that have not changed. A pass over many waiting items stays cheap enough for the daemon to keep answering requests.
+- Fleet store failures from `daemon.fleetItems` reach HTTP RPC clients as the diagnostics contract's typed `ServiceUnavailable` rejection instead of a defect.
+- Fleet no longer exhausts the GitHub budget. PR state, checks, rulesets, PR files and report publication are read through GitHub's REST API with conditional requests, so an unchanged resource answers `304 Not Modified` and costs no rate limit. Delivery polling no longer uses GraphQL.
+- The scheduler runs at the configured interval while the recorded REST `core` budget is above half and slows down between half and 20%. Below 20% remaining Fleet makes no call to that resource until its reset, keeping the rest of the shared token for agents and people, and affected work shows `GitHub paused below the 20% reserve until <time>`.
+- A rate-limited GitHub response stops further calls to that resource until its reset, `retry-after` time or backoff. Affected work shows `GitHub is rate-limited until <time>` and does not escalate as a read failure.
+- `fleet/health.json` and the daemon's diagnostics carry the rate-limit headers of Fleet's own GitHub responses per resource with their observation time. Release together with `@shivaedev/work-board`, whose diagnostics schema changes with it.
+- Cloud dispatch flags a criterion as local-only only when it names the local Board directory as a whole path segment. A criterion that names a longer path starting with the same letters, such as a `.worktrees` folder next to a `.work` Board, now launches.
+- Daemon answer and dispatch commands acknowledge durable recording before provider work completes. Reconciliation applies saved answers after a restart, and watch reports the outcome.
+- Background dispatch preserves explicit approval and the current launch prompt, including when an edited criterion unblocks work before its first attempt.
+- Dispatch records acceptance before refreshing remote main or preparing execution. Status and watch report pending dispatches and background refresh failures even before an execution record exists.
+- Watch preserves the current execution and terminal outcome after scheduler recovery from a failed dispatch without another dispatch. The failed receipt remains available through `daemon.dispatch-status`.
+- CLI request errors distinguish refused connections from timeouts and server failures, name answer and dispatch requests, and say when answer recording is unconfirmed.
+- A broken Fleet database now reports unavailable instead of an empty status when the records or dispatches table is missing.
+
+### Breaking
+
+- `answerWork` and `releaseItems` require the Board `Responses` service. Provide it with `decisionResponses(host)` or `withDecisionResponses(host, effect)`.
+- `ClientContract`'s `daemon.dispatch` returns a `DispatchRequest` receipt instead of a prepared `FleetRecord`.
+- Remove `makePostgresFleetStore(...).initialize()`, the `storage/migrateFleet.ts` export and the `legacyOnly` argument to `fleetMigrations`. Migrate through `appDatabase` with the `fleetMigrations(namespace)` loader before using the store.
+- Remove the unused `recordPayloads` export from `@shivaedev/work-fleet/host/recordPayloads.ts`.
+
 ## 0.2.1 - 2026-10-17
 
 ### Fixed

package/README.md

@@ -58,7 +58,7 @@ For this repository, configure the `worker` section in `.work/fleet.config.json`
 }
 ```
 
-The host defaults to `concurrency: 100`, `backlog: 100`, `namespace: "work_fleet"`, `quota: "codex"` and an empty `launch`. `concurrency` limits execution; `backlog` limits undelivered adopted changes. The Codex quota policy uses ordinary-usage eligibility and caches observations for a minute; `quota: "unlimited"` admits without that provider limit. An unknown quota response fails rather than granting capacity.
+The host defaults to `concurrency: 100`, `backlog: 100`, `namespace: "work_fleet"`, `quota: "codex"`, an empty `launch` and no `openPullRequests` curve. `concurrency` limits execution; `backlog` limits undelivered adopted changes; `openPullRequests` slows new implementer launches as Fleet's open PRs pile up, as described under [Pace new work by open PRs](#pace-new-work-by-open-prs). The Codex quota policy uses ordinary-usage eligibility and caches observations for a minute; `quota: "unlimited"` admits without that provider limit. An unknown quota response fails rather than granting capacity.
 
 `stallMinutes` is a positive integer, defaulting to 30. Fleet records each running turn's item count and statuses; added items or changed statuses reset its progress timer. One idle interval sends a Codex steer asking the worker to continue or stop with a question. A second idle interval interrupts the turn; after observing it interrupted, Fleet continues the same thread with the retry prompt. A third idle interval publishes an orchestrator decision. Progress times and recovery stages persist across host restart. CLI status and the generated status page show each turn's last progress time and Fleet's steer and interrupt timestamps. PostgreSQL specs with a synthetic Codex server and test clock in `src/engine/stallRecovery.spec.ts`, `src/engine/stallProgress.spec.ts` and `src/engine/stalledReviewer.spec.ts` prove the recovery sequence, timer resets, restart handling and read-only reviewer continuation.
 
@@ -68,7 +68,7 @@ Missing or invalid configuration fails. Configuration and Cloud request tests ar
 
 Scheduler dispatch submits prepared items in sequence and stops the pass after a transient provider rejection. Worker and repair launches wait up to one second for acknowledgement after persisting their intent; missing replies retain execution ownership while the pass continues dispatching. The provider request continues in the service scope so late replies are persisted, and reconciliation waits for that request to finish before recovering the operation. Explicit caller interruption still cancels the submission. Rejected work releases execution capacity and retries on later passes with durable delays of 30, 60, 120 and 240 seconds. Queue-full, structured provider capacity failures and the explicit “Selected model is at capacity” rejection receive at most five attempts. Failed worker and reviewer turns with those capacity failures use the same retry budget. When it runs out, Fleet parks the item with the provider failure and the number of attempts. The waiting item is tried before the rest of the prepared backlog, so provider capacity backoff also pauses that backlog. `work-fleet status` shows waiting for provider capacity with the last rejection time and next retry time. Rejected credentials and refused policy still require a human decision; ambiguous submissions retain their existing ownership for reconciliation. A retry after an explicitly rejected first turn reuses the acknowledged thread. PostgreSQL tests with synthetic providers in `src/engine/launchPacing.spec.ts`, `src/engine/launchBackpressure.spec.ts`, `src/engine/providerTransient.spec.ts`, `src/engine/providerTerminal.spec.ts` and `src/engine/workerContinuation.spec.ts` cover acknowledgement pacing, late replies, recovery, interruption, capacity backoff and thread reuse.
 
-A capacity rejection while reading or reconciling a turn does not establish that its submission failed. Fleet backs off those reads on the existing operation, retaining the attempt, receipt and execution reservation across restart. Reads use a separate five-attempt budget with delays of 30, 60, 120 and 240 seconds; a successful observation clears that wait. Exhaustion parks with the provider read failure and attempt count while retaining execution ownership. A human retry reconciles that operation; it does not launch a replacement. `src/engine/providerReadRetry.spec.ts` proves recovery after a lost acknowledgement and an acknowledged running turn against real PostgreSQL with synthetic providers. The recovery matrix covers read exhaustion, retry and safe release.
+A capacity rejection while reading or reconciling a turn does not establish that its submission failed. Fleet backs off those reads on the existing operation, retaining the attempt, receipt and execution reservation across restart. Reads use a separate five-attempt budget with delays of 30, 60, 120 and 240 seconds; a successful observation clears that wait. `readRetryMs` in Fleet policy or `fleet.config.json` sets the first delay, defaulting to `30000`, and each later delay doubles it; integration evidence reads use the same schedule. Exhaustion parks with the provider read failure and attempt count while retaining execution ownership. A human retry reconciles that operation; it does not launch a replacement. `src/engine/providerReadRetry.spec.ts` proves recovery after a lost acknowledgement and an acknowledged running turn, with the default and a configured `readRetryMs`, against real PostgreSQL with synthetic providers. The recovery matrix covers read exhaustion, retry and safe release.
 
 A review with a lost thread acknowledgement or an unobservable submitted turn is safe to repeat because it changes no code. When its provider read budget runs out, or reconciliation reports `session-turn-missing` without a pending read retry, Fleet retires the unacknowledged review and queues a fresh read-only thread for the same head under the shared five-attempt provider retry budget. Late acknowledgements of the retired attempt are rejected. Lost worker and repair threads still retain execution ownership and require a human decision after read exhaustion. PostgreSQL tests with synthetic providers in `src/engine/lostReview.spec.ts`, `src/engine/missingReview.spec.ts` and `src/engine/lostExecution.spec.ts` cover automatic review recovery through ready-to-merge, shared budget exhaustion, late acknowledgements and worker/repair ownership.
 
@@ -76,10 +76,20 @@ A review with a lost thread acknowledgement or an unobservable submitted turn is
 
 `work-fleet serve <board-dir>` binds to `127.0.0.1:3457`; `--port <port>` selects another port. The daemon composes `Fleet.layer`, the host and scheduler once for its lifetime. Its HTTP clients share one PostgreSQL pool, bounded by `database.maxConnections` (20 by default, at least 2), and one provider connection set. One connection is reserved for the PostgreSQL change listener; the remaining connections serve queries and transactions. Fleet record commits notify followers through PostgreSQL, including followers in another host runtime. A listener resync refreshes their stored-state snapshots. Work Board runs independently.
 
-Native Effect HTTP RPC uses NDJSON at `/_fleet/rpc`. Import `DaemonContract` from `@shivaedev/work-fleet/host/daemonContract.ts` and provide `RpcClient.layerProtocolHttp` with `RpcSerialization.layerNdjson` and an HTTP client. The contract exposes Fleet's existing prepare, dispatch, continue, reconcile, resolve, reassign, get and views operations, plus `daemon.dispatch` for explicit Board preparation and dispatch, `daemon.status` for filtered views and the `daemon.follow` snapshot stream. Platform's `RequestTracing` supplies a request id for each call, preserving valid `x-request-id` values. Only loopback Host values and missing or same-origin transport Origin headers are accepted; requests must use `application/ndjson`.
+Native Effect HTTP RPC uses NDJSON at `/_fleet/rpc`. Import `DaemonContract` from `@shivaedev/work-fleet/host/daemonContract.ts` and provide `RpcClient.layerProtocolHttp` with `RpcSerialization.layerNdjson` and an HTTP client. The contract exposes Fleet's existing prepare, dispatch, continue, reconcile, resolve, reassign, get and views operations, plus `daemon.dispatch` for explicit Board dispatch, `daemon.dispatch-status` for its receipt, `daemon.status` for filtered views and the `daemon.follow` snapshot stream. Platform's `RequestTracing` supplies a request id for each call, preserving valid `x-request-id` values. Only loopback Host values and missing or same-origin transport Origin headers are accepted; requests must use `application/ndjson`.
+
+`work-fleet dispatch <id>` validates Board approval, saves a dispatch receipt in PostgreSQL and replies before refreshing remote main, preparing execution or contacting the provider. `daemon.dispatch` returns a `DispatchRequest` with `id`, `workId`, `acceptedAt` and `status`; `daemon.dispatch-status` reads the latest receipt for an item. Pending duplicate requests share that receipt. Background processing records `completedAt` and either `status: completed` or `status: failed` with an `error`. Completion here means dispatch processing finished; the work's execution stage remains separate. `status` includes pending and failed receipts in `FleetViews.dispatches`, and `watch` waits through pending preparation and reports a background refresh failure even when no execution record exists. When the scheduler recovers after a failed dispatch, watch preserves the current execution and terminal outcome instead of showing the old dispatch failure. The failed receipt remains available through `daemon.dispatch-status`. Pending receipts resume when the daemon restarts; dispatching a failed request creates a new receipt. The PostgreSQL and daemon/CLI tests in `src/host/dispatchTimeout.spec.ts` and `src/host/dispatchRecovery.spec.ts` cover blocked first refreshes, recorded outcomes, duplicate requests, restart recovery, retry and scheduler recovery without another dispatch with synthetic providers.
 
 Compose `daemonLayer(host, parts, port)` in a scoped host, or launch it with `serveFleet(host, parts, port)`, both from `@shivaedev/work-fleet/host/daemon.ts`. The daemon uses Platform’s `appHost` with the loopback policy and its existing RPC path. Its shared `appDatabase` layer completes Fleet migrations in the namespace ledger before acquiring application services. The listener starts before scheduling. Closing the scope stops scheduling and HTTP, then closes the provider services and pool. Restart recovery reuses saved launch intents and acknowledged threads; retry or release fences late acknowledgements and retires an intent without a persisted thread acknowledgement before a turn can start. The PostgreSQL and real HTTP tests in `src/host/daemon.test.ts` cover a completed item, concurrent clients, pool/provider lifetime and request ids. `src/host/migrationStartup.spec.ts` proves that a migration failure prevents provider acquisition and scheduling. `src/host/cloudRestart.spec.ts` kills and restarts the daemon at launch boundaries against a synthetic Cloud backend without creating a second thread or accepted turn. These tests do not launch live Cloud workers.
 
+### Edit the configuration while the daemon runs
+
+The daemon watches its `fleet.config.json` (or the `--config` file) and applies a valid edit without a restart. `concurrency`, `backlog`, `intervalSeconds`, `quota`, `launch`, `openPullRequests`, `stallMinutes`, `areaMergeWaitMs`, `readRetryMs`, `worker.workerGuidance` and `worker.reviewerGuidance` take effect on the next scheduler pass or launch; an applied edit starts that pass at once. Running turns keep the launch settings they started with, and work that already holds capacity keeps running after `concurrency` is lowered. Every other setting, such as `provider`, `database`, `namespace`, `cloud`, `local`, `repository`, `result`, `worker.branchPrefix` and `worker.sharedEnvironment`, keeps its running value: the daemon logs a warning and lists the changed paths as needing a restart. An edit saved by replacing the file keeps applying.
+
+An edit that fails validation, is partly written, cannot be read, or names an unreadable guidance file keeps the last good config. The daemon logs a `HostConfigRejected` warning that names the failing field, and the next valid edit applies. A rejected edit never stops the daemon or drops tracked work.
+
+`work-fleet status` ends with the config the daemon applies now: when and from which file it was loaded, the provider and the reloadable settings with their defaults filled in, the paths waiting for a restart and the last rejected edit. `--json` carries the same view as `config`, with the database URL left out. `src/host/configReload.spec.ts` covers these rules on the real daemon host against PostgreSQL: lowering concurrency stops new launches while running work continues, raising it resumes launches with edited launch settings and interval, invalid and partly written edits keep the old values and log a warning, a provider change is reported as restart-only, guidance paths apply to the next launch, and replaced files keep applying.
+
 ### Approve work and override launch settings
 
 Set the exact `fleet: approved` value in the item's frontmatter. Missing approval or `fleet: draft` does not approve it. The optional `fleet-launch` object overrides host `launch` settings per field:
@@ -119,7 +129,7 @@ relationships:
 # Add the follow-up behavior
 ```
 
-An overlapping task remains prepared, waiting on automation, with a reason such as `waiting for area work-fleet/host held by task.foundation`. Areas are held through execution, review and validation, and are freed on completion or safe release. For a reviewed, green PR ready for a human merge, `areaMergeWaitMs` in Fleet policy or `fleet.config.json` defaults to `1800000` (30 minutes), counted from that readiness event. Once the wait expires, other tasks can use its areas while Fleet continues observing the PR for delivery. PostgreSQL preserves admission order across restarts; eligible overlapping tasks wait behind earlier prepared work.
+An overlapping task remains prepared, waiting on automation, with a reason such as `waiting for area work-fleet/host held by task.foundation`. Areas are held through execution, review and validation, and are freed on completion or safe release. For a reviewed, green PR ready for a human merge, `areaMergeWaitMs` in Fleet policy or `fleet.config.json` defaults to `1800000` (30 minutes), counted from that readiness event. Once the wait expires, other tasks can use its areas while Fleet continues observing the PR for delivery. PostgreSQL preserves admission order across restarts; eligible overlapping tasks wait behind earlier prepared work. Each scheduler pass retries waiting work but rewrites a waiting item only when its reason changes, and admission reads decode only the records that changed since the previous read; `src/host/preparedAdmission.spec.ts` and `src/storage/listReuse.spec.ts` prove both against PostgreSQL, including a write that rolled back.
 
 Fleet identifies work by its authored brief: the Markdown title and body, criteria, Board kind, deliverable kind and authored relationships. Bookkeeping fields such as `status`, `next_action` and `owner` do not change that revision. Editing them on executing or reviewing work preserves the attempts; editing them on work with an open decision preserves the question and its recorded answers. Criteria or body edits refresh eligible prepared and active work in place. Work waiting on a human decision still stops with Board context changed; an answer to the earlier decision cannot authorize execution against the changed brief. This revision rule applies to every status, including `done`: marking executing work done leaves its original work and decision intact and resolvable. Completed work can be prepared again only after its authored brief changes; unchanged source or bookkeeping edits leave its accepted outcome intact. Saved whole-file revisions are compared through their exact saved source without rewriting records or publication receipts; records without that source still need renewed preparation when their revision differs. Approval remains a separate execution requirement. `src/board/briefRevision.test.ts`, `src/engine/briefBookkeeping.spec.ts`, `briefChanges.spec.ts`, `doneBookkeeping.spec.ts`, `completedRenewal.spec.ts` and `dependencySavedRevision.spec.ts` cover the revision rule, restart and decision resolution with real PostgreSQL and synthetic providers.
 
@@ -127,25 +137,55 @@ A `depends_on` relationship waits on automation for an accepted Fleet outcome on
 
 Before launching prepared work, Fleet rereads its Markdown source for the current Board status, including changes made during preparation assessment in the same scheduler pass. A `done`, `superseded` or `deferred` item moves to `released` with a durable `releaseReason`, clears its admission blocker and leaves the waiting list. PostgreSQL regressions in `src/engine/closedDispatch.spec.ts` cover closing a prepared item while it waits for an area lock or a dependency, freeing the wait without starting a worker, and preserving release across restart.
 
+### Pace new work by open PRs
+
+Merge throughput, not launch throughput, limits a fleet. Every implementer that launches while earlier PRs wait to merge adds a PR that will conflict with, duplicate or go stale behind the others, and one flaky check can then pull many of them out of the merge queue at once. Fleet therefore applies back pressure: it launches new implementers freely while few of its PRs are open, launches fewer as they pile up, and always runs the work that moves existing PRs toward merge.
+
+```json
+{
+  "concurrency": 20,
+  "openPullRequests": { "ease": 6, "max": 15 }
+}
+```
+
+This configuration allows full concurrency for new implementers up to 6 open Fleet PRs, then linearly fewer, and none at 15 or more. A new implementer launches only while running work plus work waiting to launch stays below the limit for the current count of open Fleet PRs. The limit is `concurrency` up to `ease` open PRs, falls linearly to `floor` at `max`, and stays at `floor` beyond it, rounding down. `floor` defaults to 0, `ease` may be 0, and `ease` must not exceed `max`. An open Fleet PR is the adopted change of a current Fleet cycle that has not completed or been released; PRs Fleet did not adopt, such as Renovate or human PRs, do not count, and the count comes from Fleet's own records rather than GitHub polling. A held item stays prepared, waiting on automation, with a reason such as `waiting for open PRs to merge: 14 of 15`.
+
+Only new implementer launches, from prepared work, are throttled. Reviews, repairs and workers continuing after an answered question never wait on the curve. When slots are short, they also go first: an item in review or repair, or with queued answers, that waits for a slot holds it ahead of new implementers, which wait with a reason such as `waiting for 1 review or repair launches to go first (limit 1)`. A merged PR completes its item, lowers the count and frees new launches on the next pass. Without `openPullRequests`, that reservation still applies within `concurrency`. PostgreSQL stories in `src/engine/dispatchBackPressure.spec.ts` drive the real scheduler and store to prove the launches allowed for each open-PR count, a repair, a second review and an answered worker question proceeding while a new implementer is held, a waiting review going before a new implementer, and a merged PR freeing launches.
+
+### Launch urgent work now
+
+Lower limits help merge throughput, but some small, independent work, such as a fix to Fleet itself, should start at once. `work-fleet dispatch --now <id>` launches the item over `concurrency`, the open-PR curve and `backlog`. A `fleet-priority: urgent` field in the item's frontmatter does the same whenever the scheduler reaches it. Area claims and `depends_on` dependencies still apply because they protect correctness rather than capacity; `--now --ignore-areas` also skips area claims. The request stays on the prepared item until it launches, across later scheduler passes, and the daemon resumes a pending `--now` receipt after a restart. Fleet first asks for admission within the limits; only a launch the limits refused is recorded as over the limit, and `work-fleet status` shows that item as `launched over the limit` while it runs, so the operator sees why running work exceeds `concurrency`. The override covers the new implementer launch; its later reviews and repairs use the normal limits and go first as above.
+
+```markdown
+---
+id: fleet.small-fix
+kind: task
+fleet: approved
+fleet-priority: high
+---
+```
+
+`fleet-priority` takes `urgent`, `high` or `normal`, the default; Board treats the field as Fleet-owned, and any other value fails Fleet's Board read for that item. When slots are short, the scheduler admits prepared work in priority order, and within a priority the existing admission order holds. `src/engine/dispatchPriority.spec.ts` proves, against PostgreSQL and the real scheduler, that `dispatch --now` launches at full concurrency while a normal dispatch waits and is marked in status, that urgent work still waits for an area held by another item unless `--ignore-areas` is given while urgent work with a free area launches over the limit, that a waiting `--now` request launches over the limit once its area frees, that `--now` still waits for an unfinished dependency, and that high-priority work, from the fixture or from Markdown frontmatter, is admitted before earlier normal work while an unknown `fleet-priority` is rejected; `src/engine/dispatchBackPressure.spec.ts` proves that urgent work launches over the open-PR curve, and `src/host/dispatchRecovery.spec.ts` that the daemon resumes a pending `--now` receipt with its override after a restart.
+
 ### Run, dispatch and inspect
 
 | Command | Behavior |
 |---|---|
 | `work-fleet serve <board-dir> [--port <port>]` | Starts the local HTTP RPC daemon, admits approved work, dispatches prepared items and reconciles running work. |
-| `work-fleet dispatch <work-id> [--port <port>]` | Prepares and dispatches one approved item; explicit dispatch can re-approve an edited revision. |
-| `work-fleet status [--port <port>]` | Prints Active, owner-grouped waiting and Completed views from stored records. |
+| `work-fleet dispatch <work-id> [--now [--ignore-areas]] [--port <port>]` | Prepares and dispatches one approved item; explicit dispatch can re-approve an edited revision. `--now` launches over capacity limits; `--ignore-areas` also skips area claims. |
+| `work-fleet status [--port <port>]` | Prints Active, owner-grouped waiting and Completed views from stored records, then the config the daemon applies. |
 | `work-fleet status <work-id> --json [--port <port>]` | Filters to one item and prints the views as JSON. |
 | `work-fleet release <work-id>... [--port <port>]` | Releases terminal needs-human items and records closing responses on their Board decisions. |
 | `work-fleet reassign <work-id> <decision-id> <owner> [--port <port>]` | Reassigns the exact current question to maintainer, orchestrator or automation. |
 | `work-fleet wait <work-id> --timeout <seconds> [--port <port>]` | Subscribes to daemon snapshots until an outcome or timeout. |
 | `work-fleet watch [work-ids...] [--follow] [--port <port>]` | Reports outcomes once, or keeps reporting transitions with `--follow`. |
 | `work-fleet continue <work-id> [message] [--port <port>]` | Continues terminal work on its existing worker thread; reads stdin when the message is omitted. |
-| `work-fleet answer <work-id> [text] [--release] [--port <port>]` | Answers the waiting worker question or Fleet decision; reads text from stdin when omitted. |
+| `work-fleet answer <work-id> [text] [--release] [--port <port>]` | Answers the waiting worker question or Fleet decision; reads text from stdin when omitted, except with `--release`. |
 | `work-fleet name-threads [--port <port>]` | Names existing Cloud threads from Fleet records and reports each rename or failure. |
 
 Automatic reconciliation refreshes eligible edited briefs in place. Explicit dispatch can re-approve work waiting on a context decision; renewal still requires safe execution and result ownership. Keep `serve` active to reconcile worker progress. All commands except `serve` connect to its loopback port (3457 by default) over RPC and open no PostgreSQL connection. Their retained `--board` and `--config` flags do not select a host; the running daemon owns its Board and configuration. Without a daemon, they exit 1 with the address and a command to start it. The host loop and approval behavior are exercised against PostgreSQL in `src/host/commands.test.ts` and `src/host/cloudRestart.spec.ts`; `src/host/statusProcess.spec.ts` exercises status output and flags.
 
-`answer` records an orchestrator response on Board and resolves what the item waits on. Worker questions require nonempty text and continue on the same thread. Fleet decisions receive retry with the text as the overall response; for a reviewed, ready PR, nonempty text requests changes on the same branch and PR. Use `--release` to release terminal ownership instead. The command refreshes the managed decision and registers its current question before answering, including after a changed template was republished. If reconciliation replaces a decision with another of the same kind during the command, the answer applies to the current decision. A different kind or a move out of needs-human returns `Decision changed` with the current reason. Nonempty text sent during execution or repair is stored for the next worker turn, survives daemon restart and prints `queued for the next turn`; release requests still require terminal waiting work. Items waiting on nothing return a typed error naming their stage. `status` prints each waiting question or reason, with `work-fleet answer <work-id>` in the maintainer and orchestrator lanes. Automation waits have no answer command. `src/host/daemonCommands.spec.ts`, `src/host/answerWorker.spec.ts`, `src/host/answerPublication.spec.ts`, `src/host/answerReplacement.spec.ts`, `src/host/answerQueue.spec.ts` and `src/host/approvedRework.spec.ts` prove these paths through daemon HTTP against PostgreSQL and synthetic Board directories.
+`answer` records an orchestrator response on Board and resolves what the item waits on. Worker questions require nonempty text and continue on the same thread. Fleet decisions receive retry with the text as the overall response; for a reviewed, ready PR, nonempty text requests changes on the same branch and PR. Use `--release` to release terminal ownership instead. The command refreshes the managed decision and registers its current question before answering, including after a changed template was republished. If reconciliation replaces a decision with another of the same kind during the command, the answer applies to the current decision. A different kind or a move out of needs-human returns `Decision changed` with the current reason. Nonempty text sent during execution or repair is stored for the next worker turn, survives daemon restart and prints `queued for the next turn`; release requests still require terminal waiting work. Items waiting on nothing return a typed error naming their stage. `status` prints each waiting question or reason, with `work-fleet answer <work-id>` in the maintainer and orchestrator lanes. Automation waits have no answer command. `src/host/daemonCommands.spec.ts`, `src/host/answerWorker.spec.ts`, `src/host/answerPublication.spec.ts`, `src/host/answerReplacement.spec.ts`, `src/host/answerQueue.spec.ts` and `src/host/approvedRework.spec.ts` prove these paths through daemon HTTP against PostgreSQL and synthetic Board directories. The daemon still records and applies an answer or release after its client stops waiting, and all answers and releases share one watched Board response index, so a request rereads only changed Board files; `src/host/answerDisconnect.spec.ts` proves both through daemon HTTP while another connection holds the admission lock.
 
 `wait` prints a summary and exits with these codes:
 
@@ -193,7 +233,7 @@ Retrying the original decision ID for the same committed reassignment recovers p
 
 Reassignment publishes a new question for the assigned owner and acknowledges the old question as superseded, preserving both reviewed sources. Answers to the old question cannot continue the worker. Reconciliation retries publication and acknowledgement after failure or restart. Existing unowned decisions recover their original publication before publishing a replacement for the assigned owner. Owner labels do not grant runtime approval or delivery authority.
 
-The CLI host also atomically publishes `fleet/health.json`, using Board's versioned `FleetHealth` schema from `@shivaedev/work-board/diagnostics/health.ts`. Running counts work with submitting, accepted or running attempts; queued counts prepared work; waiting counts group every wait by maintainer, orchestrator and automation, including capacity and quota blockers and pending checks. The snapshot uses version 2. The snapshot carries the configured concurrency cap, publication time and freshness threshold, last completed scheduler pass and last observed structured provider capacity rejection. A host restart reloads the two last observations. Status-board and health publication failures do not change execution outcomes; the next publication retries. The daemon retains the same health observation in memory and serves it through the shared `daemon.diagnostics` HTTP RPC query, together with Codex and GitHub rate-limit observations cached for one minute. Board's Diagnostics view reads this RPC query without Fleet or database dependencies; it does not read the health file. Health observations retain their publication time so a stalled runtime remains visibly stale. `src/host/boardDiagnostics.spec.ts` covers Board-to-daemon HTTP reads against PostgreSQL after the health file is removed.
+The CLI host also atomically publishes `fleet/health.json`, using Board's versioned `FleetHealth` schema from `@shivaedev/work-board/diagnostics/health.ts`. Running counts work with submitting, accepted or running attempts; queued counts prepared work; waiting counts group every wait by maintainer, orchestrator and automation, including capacity and quota blockers and pending checks. The snapshot uses version 2. The snapshot carries the configured concurrency cap, publication time and freshness threshold, last completed scheduler pass and last observed structured provider capacity rejection. A host restart reloads the two last observations. Status-board and health publication failures do not change execution outcomes; the next publication retries. The daemon retains the same health observation in memory and serves it through the shared `daemon.diagnostics` HTTP RPC query, together with Codex rate-limit observations cached for one minute. The snapshot's `github` field carries the rate-limit headers of Fleet's own GitHub responses per resource, with their observation time and any active rate-limit wait, and the daemon serves these as its GitHub limits. Board's Diagnostics view reads this RPC query without Fleet or database dependencies; it does not read the health file. Health observations retain their publication time so a stalled runtime remains visibly stale. `src/host/boardDiagnostics.spec.ts` covers Board-to-daemon HTTP reads against PostgreSQL after the health file is removed.
 
 A composed runtime enables health publication with `statusLayer(boardRoot, { concurrency, staleAfterMs })`, provides `healthLayer(boardRoot)` from `@shivaedev/work-fleet/host/healthLayer.ts`, and wraps its provider with `providerHealth` from `@shivaedev/work-fleet/host/providerHealth.ts`. Capacity comes only from structured `rateLimitExceeded`, `flexUnavailable` or `serverOverloaded` errors; unclassified rejection text is not treated as capacity. A repeatedly observed terminal turn does not refresh the same rejection's timestamp.
 
@@ -203,7 +243,7 @@ Every new Fleet decision records a stable `code` beside its human `reason`. Impo
 
 The guided actions offer retry when Fleet can launch a new turn, review or delivery observation. Incompatible preparation, changed result identity, invalid adopted GitHub identity, oversized immutable reports, unconfigured stock-host no-change validation and report workers that published to GitHub offer only release, with a sentence explaining what must happen outside retry. Closing a published PR and deleting its branch retain publication evidence. Worker questions accept a recorded answer to continue the same thread, or a guided release answer to free terminal ownership.
 
-`src/engine/recoveryMatrix.spec.ts` inventories production decision creation sites and requires a recovery row for every code in `DecisionCode`. Human-decision rows check retry progress and release after restart against real PostgreSQL with synthetic providers and GitHub readers, production host checks, Board report publication, attachment and payload boundaries, and the PostgreSQL session journal. Automatic-capacity rows reword queue-full and quota failures, preserve their waits across restart, and resume without a human decision. Separate rows record an answer while the HTTP daemon is closed, then restart it against the same records. New decision sites or Schema codes without a matrix row fail the suite. Mutation regressions add a decision site and remove a code’s recovery rows to prove this guard.
+`src/engine/recoveryMatrix.spec.ts` inventories production decision creation sites and requires a recovery row for every code in `DecisionCode`. The human-decision rows run in case groups, one `src/engine/<group>RecoveryMatrix.spec.ts` per group, and the inventory requires a spec file for every group. Human-decision rows check retry progress and release after restart against real PostgreSQL with synthetic providers and GitHub readers, production host checks, Board report publication, attachment and payload boundaries, and the PostgreSQL session journal. Automatic-capacity rows reword queue-full and quota failures, preserve their waits across restart, and resume without a human decision. Separate rows record an answer while the HTTP daemon is closed, then restart it against the same records. New decision sites or Schema codes without a matrix row fail the suite. Mutation regressions add a decision site and remove a code’s recovery rows to prove this guard.
 
 Codex RPC overload code `-32001` produces a `SessionFailure` with code `session-queue-full`; launch backoff uses that code and the rejected failure kind. Quota admission produces a platform `Forbidden` with `provider-quota-unavailable` in its failure context, which reconciliation keeps waiting on automation. Rewording either failure message leaves its retry or waiting behavior unchanged. Custom integrations supply these codes for the same behavior. `src/providers/capacityWire.spec.ts` checks the protocol classification independently of wording; `src/engine/recoveryMatrix.spec.ts` proves both waits and their recovery against PostgreSQL.
 
@@ -231,7 +271,7 @@ A failed worker or repair attempt without a receipt is never adopted. Review ref
 
 Codex protocol rejections with no specific cause retry the same method and parameters, including the saved operation ID and thread, after 30 and 60 seconds. A third rejection reaches the existing failure handling and publishes a decision for a turn submission. Generic messages are “Something went wrong”, “Internal error”, “Internal server error” or an absent message, with an optional request ID. Invalid request, permission and quota messages do not use these retries or contention replay. Structured capacity failures keep their separate retry budget. `src/engine/genericRejection.spec.ts` proves same-thread recovery, the three-rejection limit and immediate decisions for specific causes through a synthetic Codex WebSocket server and real PostgreSQL. `src/providers/genericRejection.test.ts` covers generic wording and exclusion of structured capacity and uncertain submissions.
 
-When an otherwise unclassified definite Codex turn rejection has an active turn in the provider's paginated turn state, Fleet classifies it with code `session-active-turn`. The retry rule uses that code, polls until the thread is idle, then submits the same saved operation, prompt and settings. Rewording the rejection leaves this behavior unchanged. An idle thread or unreadable state cannot authorize contention replay; distinct coded failures retain their own handling. Polling starts immediately, with delays doubling from two seconds to a maximum of thirty seconds. The attempt stays submitting with its execution ownership while waiting. The wait has a five-minute deadline across classification and busy rejections and permits at most three resubmissions. Reaching the wait deadline retains `session-active-turn`; exhausting resubmissions records `session-active-turn-exhausted`. Both mark the receiptless attempt failed, release execution capacity and queue a fresh thread with the saved instructions on the same branch and PR. The explicit “turn already active for thread” rejection uses that fallback even when the turn state appears idle. Fresh-thread retries share the five-attempt provider budget and persist their backoff across restart; exhaustion parks with the failure and attempt count. Credential and policy rejections cannot authorize contention replay even when the provider has an active turn. `src/engine/activeTurn.spec.ts` covers reworded contention across paginated turn observations, continuation and delivery; `src/engine/activeTurnDeadline.spec.ts` covers polling backoff, a hung active turn reaching the deadline and automatic recovery after restart. Both use real PostgreSQL with a synthetic provider. `src/providers/activeTurn.spec.ts` covers rewording, idle and unreadable state, and the resubmission cap through the Codex wire boundary; the recovery matrix covers retry and release after the provider retry budget is exhausted. `src/engine/wedgedRetry.spec.ts` proves a busy repair automatically starts a fresh thread on the same PR after restart.
+When an otherwise unclassified definite Codex turn rejection has an active turn in the provider's paginated turn state, Fleet classifies it with code `session-active-turn`. The retry rule uses that code, polls until the thread is idle, then submits the same saved operation, prompt and settings. Rewording the rejection leaves this behavior unchanged. An idle thread or unreadable state cannot authorize contention replay; distinct coded failures retain their own handling. Polling starts immediately, with delays doubling from two seconds to a maximum of thirty seconds. The attempt stays submitting with its execution ownership while waiting. The wait has a five-minute deadline across classification and busy rejections and permits at most three resubmissions. Reaching the wait deadline retains `session-active-turn`; exhausting resubmissions records `session-active-turn-exhausted`. Both mark the receiptless attempt failed, release execution capacity and queue a fresh thread with the saved instructions on the same branch and PR. The explicit “turn already active for thread” rejection uses that fallback even when the turn state appears idle. Fresh-thread retries share the five-attempt provider budget and persist their backoff across restart; exhaustion parks with the failure and attempt count. Credential and policy rejections cannot authorize contention replay even when the provider has an active turn. `src/engine/activeTurn.spec.ts` covers reworded contention across paginated turn observations, continuation and delivery; `src/engine/activeTurnDeadline.spec.ts` covers polling backoff, a hung active turn reaching the deadline and automatic recovery after restart. Both use real PostgreSQL with a synthetic provider. `src/providers/activeTurn.spec.ts` covers rewording, unreadable state and the resubmission cap through the Codex wire boundary; `src/providers/startCodexTurn.test.ts` covers the idle-thread backoff and same-turn resubmission without new threads or interrupts on a test clock; the recovery matrix covers retry and release after the provider retry budget is exhausted. `src/engine/wedgedRetry.spec.ts` proves a busy repair automatically starts a fresh thread on the same PR after restart.
 
 ### Answer a worker question
 
@@ -263,19 +303,19 @@ After a terminal report turn, the host checks the configured GitHub remote for t
 
 Local attachment validation and saved-payload failures park the completed attempt with the failed file path and cause. Report file errors stay tagged in the Effect channel until the Board or platform boundary maps them. `src/engine/reportFileFailures.spec.ts` proves distinct reasons for a path escape, an oversized payload and a file replaced after validation against PostgreSQL. `src/board/reportPayload.test.ts` covers platform error mapping without losing the failed path.
 
-Successful publication records the report in the current Board read pass and completes the Fleet attempt without PR adoption, independent review, checks or delivery. Empty or whitespace-only output, or a complete report document over Board’s 256 KiB UTF-8 context limit, creates an orchestrator decision with a concrete reason instead of a result. The size check includes metadata, the worker receipt and attachment links, and runs before writing attachment files. Oversized reports leave no attachment folder. `src/host/attachmentSize.spec.ts` covers rejection before attachment writes, including a report that fits the limit until attachment links are added. `wait` and the status views expose the same terminal states and result path. A retry after a publication failure republishes the existing completed attempt; a retry after empty output prepares another worker attempt. Oversized output offers only release because retry cannot shorten a completed report; prepare a worker to produce a shorter report after release. Scheduler passes do not repeat publication. `src/engine/recoveryMatrix.spec.ts` proves release after restart and recovery when report publication evidence becomes available. `src/board/publishReport.test.ts` and `src/host/reportSize.spec.ts` cover the size boundary, immediate visibility and durable orchestrator decision. These prompts direct worker behavior; runtime policy still owns execution authority.
+Successful publication records the report in the current Board read pass and completes the Fleet attempt without PR adoption, independent review, checks or delivery. Empty or whitespace-only output, or a complete report document over Board’s 256 KiB UTF-8 context limit, creates an orchestrator decision with a concrete reason instead of a result. The size check includes metadata, the worker receipt and attachment links, and runs before writing attachment files. Oversized reports leave no attachment folder. `src/host/attachmentSize.spec.ts` covers rejection before attachment writes, including a report that fits the limit until attachment links are added. `wait` and the status views expose the same terminal states and result path. A retry after a publication failure republishes the existing completed attempt; a retry after empty output prepares another worker attempt. Oversized output offers only release because retry cannot shorten a completed report; prepare a worker to produce a shorter report after release. Scheduler passes do not repeat publication. `src/engine/reportRecoveryMatrix.spec.ts` proves release after restart and recovery when report publication evidence becomes available. `src/board/publishReport.test.ts` and `src/host/reportSize.spec.ts` cover the size boundary, immediate visibility and durable orchestrator decision. These prompts direct worker behavior; runtime policy still owns execution authority.
 
 ### Cloud provider
 
 The hosted Codex transport sends the configured environment and launch fields, then reads the final answer from a terminal turn. It authenticates from a Codex login file and can run a configured refresh command for an expired login. Failed refresh remains unavailable. These boundaries are tested with a synthetic WebSocket backend in `src/providers/codexCloud.test.ts`.
 
-Cloud host configuration accepts `cloud.threadNamePrefix` (default `Fleet: `), `cloud.projectId` for an existing project, and `cloud.archiveThreads` (default `true`). Names use `<prefix><work-id>: <title>` from the prepared Board context's first heading. Titles have normalized whitespace and at most 80 Unicode characters, with an ellipsis when trimmed; a missing heading falls back to the work ID. Separate reviewer and repair threads add `(review)` or `(repair)` after the work ID. A repair that continues the worker thread retains its name. The Fleet session journal resolves names from persisted operation intents, so review integrations that start through the same session service receive reviewer names automatically.
+Cloud host configuration accepts `cloud.threadNamePrefix` (default `Fleet: `), `cloud.projectId` for an existing project, `cloud.archiveThreads` (default `true`), `cloud.requestTimeoutMs` (default 60 seconds) and `cloud.recoveryGraceMs` (default five seconds). Names use `<prefix><work-id>: <title>` from the prepared Board context's first heading. Titles have normalized whitespace and at most 80 Unicode characters, with an ellipsis when trimmed; a missing heading falls back to the work ID. Separate reviewer and repair threads add `(review)` or `(repair)` after the work ID. A repair that continues the worker thread retains its name. The Fleet session journal resolves names from persisted operation intents, so review integrations that start through the same session service receive reviewer names automatically.
 
 Fleet persists the session acknowledgement before naming it. Launch naming retains the acknowledged work ID and loads only that record; `src/engine/sessionNaming.spec.ts` proves one lookup with both one and 1,000 stored records, and rejection of missing or ambiguous intents without scanning other records. Naming is best-effort: a rejected or failed request logs a warning with the session ID and cause, then Fleet starts the turn. Project assignment is sent with `thread/start`. `work-fleet name-threads` reads all stored Fleet records, including archived cycles and acknowledged sessions without turns, and renames threads whose current names differ from their Fleet names. It reports each rename to stdout and each read or rename failure to stderr, then continues other sessions. Shared threads are visited once and retain their original role and context. Repeating the command skips successful names and retries failures. `src/engine/threadNames.test.ts`, `src/providers/cloudMetadataFlow.spec.ts` and `src/host/cloudThreadNamesFlow.spec.ts` cover formatting, startup ordering, best-effort failures and backfill idempotence with real PostgreSQL and a synthetic Cloud backend.
 
-Restart the host with the same SQL namespace. An attempt intent commits before `thread/start`, its session acknowledgement commits before `turn/start`, and its turn acknowledgement commits before observation. SIGKILL tests against real PostgreSQL and a synthetic Cloud server cover both sides of these mutations and recovery of 100 concurrent attempts with lost turn acknowledgements. These tests prove host persistence and Cloud adapter wire behavior; they do not prove live hosted execution.
+Restart the host with the same SQL namespace. An attempt intent commits before `thread/start`, its session acknowledgement commits before `turn/start`, and its turn acknowledgement commits before observation. SIGKILL tests against real PostgreSQL and a synthetic Cloud server cover both sides of these mutations and recovery of 10 concurrent attempts with lost turn acknowledgements. These tests prove host persistence and Cloud adapter wire behavior; they do not prove live hosted execution.
 
-If the session ID is known, reconciliation searches all provider turn pages for the persisted operation ID and adopts the exact existing receipt. For an acknowledged Cloud thread with no turns, Fleet polls for up to five seconds to allow late acceptance to appear. If the thread remains empty, Fleet confirms its environment and starts the saved turn on that same thread, retaining the attempt and operation ID. Retry on a missing-turn decision uses the same recovery, including prepared prompts from older worker records. Recovery requires the current Board revision to remain approved. Missing or incomplete thread evidence, unrelated turns and duplicate operation matches stay blocked. If the thread acknowledgement itself was lost, the current protocol cannot locate that thread by operation ID: Fleet retains the attempt and reservation and raises a human blocker. Recovery never starts another thread for that attempt. `src/host/cloudRestart.spec.ts` proves empty-thread recovery, late acceptance and guided retry after SIGKILL against real PostgreSQL and a synthetic Cloud server; `src/providers/recoverTurn.test.ts` covers the grace period and uncertain evidence. Provider unavailability after session acknowledgement and a mismatched setting after thread creation also retain unresolved ownership.
+If the session ID is known, reconciliation searches all provider turn pages for the persisted operation ID and adopts the exact existing receipt. For an acknowledged Cloud thread with no turns, Fleet polls for `cloud.recoveryGraceMs` (default five seconds) to allow late acceptance to appear. If the thread remains empty, Fleet confirms its environment and starts the saved turn on that same thread, retaining the attempt and operation ID. Retry on a missing-turn decision uses the same recovery, including prepared prompts from older worker records. Recovery requires the current Board revision to remain approved. Missing or incomplete thread evidence, unrelated turns and duplicate operation matches stay blocked. If the thread acknowledgement itself was lost, the current protocol cannot locate that thread by operation ID: Fleet retains the attempt and reservation and raises a human blocker. Recovery never starts another thread for that attempt. `src/host/cloudRestart.spec.ts` proves empty-thread recovery after the configured grace, late acceptance and guided retry after SIGKILL against real PostgreSQL and a synthetic Cloud server; `src/providers/recoverTurn.test.ts` covers the grace period and uncertain evidence. Provider unavailability after session acknowledgement and a mismatched setting after thread creation also retain unresolved ownership.
 
 Fleet cleans up worker, repair and reviewer threads after accepted completion or explicit safe release, and after renewal makes a prior conversation unusable for further repair. Terminal provider turns alone do not trigger cleanup: review, checks and human retry can still require the conversation. Cleanup deduplicates shared repair threads, includes acknowledged sessions without a turn, and persists completion markers. Archive failures leave the Fleet outcome accepted; scheduler reconciliation retries pending cleanup, including after restart or renewal, without repeating delivery. `cloud.archiveThreads: false` retains sessions and settles cleanup for that cycle. Transports without an archive capability also retain their sessions.
 
@@ -291,7 +331,7 @@ A PR merged before adoption or during review still requires independent approval
 
 A final `FLEET_PR: none` claims no change at the reported `FLEET_HEAD`. Fleet retains that head and the report as evidence, and passes the result through independent review and required checks. Main movement does not invalidate the report; a changed task revision prevents adoption. Fixture tests exercise GitHub responses and the PostgreSQL adoption path, not live GitHub or worker execution.
 
-When GitHub adoption rejects a completed worker or repair report's format, Fleet requests one corrected report on the same worker thread, with the exact required ending. A second malformed report needs a human; answering `retry` starts a new correction turn. Reports whose PR head moved also receive a correction turn on the existing worker thread; a second stale report needs a human retry. `src/engine/recoveryMatrix.spec.ts` covers moved-head report correction after restart. Reports rejected for repository identity or PR state still need a human decision. Correction attempts retain launch settings, persist before submission and reconcile lost acknowledgements after restart. `src/engine/reportCorrection.spec.ts` and `src/engine/workerReportRecovery.spec.ts` cover these paths with real PostgreSQL and a synthetic provider.
+When GitHub adoption rejects a completed worker or repair report's format, Fleet requests one corrected report on the same worker thread, with the exact required ending. A second malformed report needs a human; answering `retry` starts a new correction turn. Reports whose PR head moved also receive a correction turn on the existing worker thread; a second stale report needs a human retry. `src/engine/deliveryRecoveryMatrix.spec.ts` covers moved-head report correction after restart. Reports rejected for repository identity or PR state still need a human decision. Correction attempts retain launch settings, persist before submission and reconcile lost acknowledgements after restart. `src/engine/reportCorrection.spec.ts` and `src/engine/workerReportRecovery.spec.ts` cover these paths with real PostgreSQL and a synthetic provider.
 
 `src/host/githubResult.test.ts`, `src/host/githubResultFailures.spec.ts` and `src/engine/resultAdoption.spec.ts` cover these adoption boundaries.
 
@@ -299,7 +339,7 @@ When GitHub adoption rejects a completed worker or repair report's format, Fleet
 
 After adopting a result, Fleet starts an independent reviewer through the same `SessionService`, provider and durable journal as workers. Reviewers receive the Board task and criteria plus the adopted result at its exact head, without the worker conversation or preparation prompt. They use `FleetPolicy.launch` from host configuration; task launch overrides remain worker and repair settings. `FleetPolicy.reviewerGuidance` supplies repository-specific validation instructions, resolved by the command host from `worker.reviewerGuidance`. The Codex adapters request read-only execution with shell network access for read-only PR and exact-head CI inspection, and no escalation. Reviewers use existing exact-head repository objects, read-only repository tools or `gh pr view`, `gh pr diff` and `gh api --method GET`; network writes are prohibited. When the exact-head diff and check results are readable, the prompt requires a verdict. Passing required checks at that head are CI evidence even when job logs or artifacts are unavailable; reviewers record that limitation in their evidence.
 
-The reviewer ends with `FLEET_REVIEW:` followed by JSON containing `head`, `verdict` (`approve` or `changes`), nonempty `evidence` and `findings`. Changes require concrete findings; approval requires an empty findings array. Fleet accepts this verdict only after the exact turn completes and records it with that revision and receipt. Accepted or running turns keep their execution slot without a verdict. A lost acknowledgement reconciles the existing operation. Failed turns with transient capacity failures use the bounded provider retry path; other failed turns produce a decision waiting on the orchestrator. A malformed completed verdict gets one automatic follow-up on the same read-only reviewer thread requesting the required format. Fleet persists that attempt before submission and reconciles its receipt after restart; a second malformed reply produces a decision waiting on the orchestrator. Retry after that decision starts a fresh independent reviewer instead of parsing the same completed verdict again. When delivery observation finds a moved PR head after approval, Fleet verifies the current PR and its reserved paths, retains the prior result and review, clears stale checks and automatically starts a fresh independent reviewer before checks or delivery. The new result and review stage are persisted before reviewer launch so reconciliation can resume after restart. Retrying a stored moved-head decision observes the current PR and starts that review without re-parsing the old worker report, including when the prior review evidence is missing or stale. `src/engine/recoveryMatrix.spec.ts` covers both cases after restart.
+The reviewer ends with `FLEET_REVIEW:` followed by JSON containing `head`, `verdict` (`approve` or `changes`), nonempty `evidence` and `findings`. Changes require concrete findings; approval requires an empty findings array. Fleet accepts this verdict only after the exact turn completes and records it with that revision and receipt. Accepted or running turns keep their execution slot without a verdict. A lost acknowledgement reconciles the existing operation. Failed turns with transient capacity failures use the bounded provider retry path; other failed turns produce a decision waiting on the orchestrator. A malformed completed verdict gets one automatic follow-up on the same read-only reviewer thread requesting the required format. Fleet persists that attempt before submission and reconciles its receipt after restart; a second malformed reply produces a decision waiting on the orchestrator. Retry after that decision starts a fresh independent reviewer instead of parsing the same completed verdict again. When delivery observation finds a moved PR head after approval, Fleet verifies the current PR and its reserved paths, retains the prior result and review, clears stale checks and automatically starts a fresh independent reviewer before checks or delivery. The new result and review stage are persisted before reviewer launch so reconciliation can resume after restart. Retrying a stored moved-head decision observes the current PR and starts that review without re-parsing the old worker report, including when the prior review evidence is missing or stale. `src/engine/deliveryRecoveryMatrix.spec.ts` covers both cases after restart.
 
 `src/engine/reviewerSession.spec.ts`, `src/engine/reviewerEvidence.spec.ts`, `src/engine/recovery.spec.ts`, `src/prompt/reviewer.test.ts` and `src/providers/readOnly.spec.ts` cover these boundaries with real PostgreSQL and synthetic providers; they do not prove live Cloud review.
 
@@ -311,7 +351,9 @@ For built capabilities and open host integrations, see the [roadmap](https://git
 
 ### Human delivery
 
-Fleet never submits a merge. Reviewed, green PRs wait on the maintainer as ready to merge. Reconciliation keeps observing the adopted PR through `gh pr view` with the host's existing CLI authentication, accepts only a merge of the reviewed head and records the PR head and merge commit. A PR closed without merging waits on the orchestrator with that fact. A head moved after approval goes through fresh independent review and checks automatically. A temporary observation failure preserves the current Board decision and ownership until GitHub evidence is available again. `src/host/githubDelivery.test.ts`, `src/engine/humanDelivery.spec.ts`, `src/engine/deliveryObservation.spec.ts`, `src/engine/movedHeadDelivery.spec.ts` and `src/engine/movedHeadRecovery.spec.ts` cover these rules with synthetic GitHub responses and real PostgreSQL.
+Fleet never submits a merge. Reviewed, green PRs wait on the maintainer as ready to merge. Reconciliation keeps observing the adopted PR through GitHub's REST API with the host's existing CLI authentication, accepts only a merge of the reviewed head and records the PR head and merge commit. A PR closed without merging waits on the orchestrator with that fact. A head moved after approval goes through fresh independent review and checks automatically. A temporary observation failure preserves the current Board decision and ownership until GitHub evidence is available again. `src/host/githubDelivery.test.ts`, `src/engine/humanDelivery.spec.ts`, `src/engine/deliveryObservation.spec.ts`, `src/engine/movedHeadDelivery.spec.ts` and `src/engine/movedHeadRecovery.spec.ts` cover these rules with synthetic GitHub responses and real PostgreSQL.
+
+Every GitHub read Fleet makes, for PR state, checks, rulesets, PR files and report publication, goes through one `GithubApi` seam that runs `gh api --include` against the REST API. The seam keeps the ETag of each URL and repeats reads as conditional requests, so an unchanged resource answers `304 Not Modified`, costs no rate limit and returns the cached body. It records the rate-limit headers of every response per resource with the time Fleet observed them. Every local tool shares one GitHub token, so Fleet keeps the last 20% of each resource's budget for agents and people. While the `core` budget stays above half, the scheduler runs at the configured interval; between half and 20% the pause stretches smoothly toward five minutes. Below 20% remaining Fleet makes no call to that resource until its reset, and affected work shows `GitHub paused below the 20% reserve until <time>`. A rate-limited response, primary or secondary, blocks further calls to that resource until the reset, the `retry-after` time or a backoff starting at one minute, and affected work shows `GitHub is rate-limited until <time>` without counting toward read-failure escalation. Fleet does not call `/rate_limit`. `src/host/githubRateLimits.spec.ts` covers the seam with a synthetic `gh`, and `src/engine/githubBudget.spec.ts` covers conditional delivery reads, rate-limit and reserve waits and pacing against real PostgreSQL.
 
 A ready-to-merge decision answered with `retry` and a nonempty overall response sends those requested changes to the existing worker thread on the same branch and PR. Fleet clears approval and checks before repair, then independently reviews and checks the worker's next result. A retry with an empty or whitespace-only overall response retains the approved head and republishes merge readiness. GitHub's explicit `CONFLICTING` mergeability observation sends an approved PR to its worker to merge main once per observed main revision; durable revision receipts prevent repeated automatic repair across restart. A conflict that remains after that repair waits on the orchestrator. `src/host/approvedRework.spec.ts` and `src/host/approvedConflict.spec.ts` cover these transitions through the HTTP daemon with real PostgreSQL and synthetic provider and GitHub responses.
 
@@ -342,7 +384,7 @@ Dependencies require accepted outcomes for their current authored brief revision
 
 ### Errors and service declarations
 
-Fleet commands and daemon streams declare `BadRequest`, `Conflict`, `Forbidden`, `NotFound` and `ServiceUnavailable` from `@shivaedev/platform/errors/taxonomy.ts`. Invalid input, stale state, denied actions, missing records and unavailable integrations use those tags respectively. The RPC boundary maps storage conflicts to `Conflict` and admission failures to `Forbidden`; clients retain declared tags and messages in the error channel. Internal recovery metadata carries moved PR heads, conflicting main revisions and attention ownership without adding fields to platform errors. `src/host/errorChannels.spec.ts` checks all five tags through real daemon HTTP; `src/host/streamErrors.spec.ts` checks subscription errors through in-process native RPC; `src/exposeFailure.test.ts` checks storage translation, internal ownership, defects and interruption. The moved-head and attention-owner engine specs cover their recovery behavior against PostgreSQL.
+Fleet commands and daemon streams declare `BadRequest`, `Conflict`, `Forbidden`, `NotFound` and `ServiceUnavailable` from `@shivaedev/platform/errors/taxonomy.ts`. Invalid input, stale state, denied actions, missing records and unavailable integrations use those tags respectively. The RPC boundary maps storage conflicts to `Conflict` and admission failures to `Forbidden`; clients retain declared tags and messages in the error channel. After a dispatch is accepted, its background failures are recorded in the dispatch receipt. Internal recovery metadata carries moved PR heads, conflicting main revisions and attention ownership without adding fields to platform errors. `src/host/errorChannels.spec.ts` checks missing, invalid, denied and stale errors and recorded dispatch refresh failures through real daemon HTTP; `src/host/streamErrors.spec.ts` checks subscription errors through in-process native RPC; `src/exposeFailure.test.ts` checks storage translation, internal ownership, defects and interruption. The moved-head and attention-owner engine specs cover their recovery behavior against PostgreSQL.
 
 `Fleet`, `SessionService`, `MarkdownBoard`, `PostgresFleetRepository`, `FleetSessionJournal`, `GitMainSource`, `HostIntegrations`, `CodexLocal`, `CodexCloud`, `ReportBoard`, `ProviderHealth` and `StatusPublication` use `defineService`. Their Layers declare dependencies and keep initialization state private. The daemon, provider, journal, Board publication and status tests exercise those implementations through the existing ports.
 

package/dist/DispatchRequest.d.ts

@@ -0,0 +1,13 @@
+import { Schema } from "effect";
+export declare const DispatchRequest: Schema.Struct<{
+    readonly acceptedAt: Schema.Number;
+    readonly completedAt: Schema.optional<Schema.Number>;
+    readonly error: Schema.optional<Schema.String>;
+    readonly id: Schema.String;
+    readonly ignoreAreas: Schema.optional<Schema.Boolean>;
+    readonly now: Schema.optional<Schema.Boolean>;
+    readonly status: Schema.Literals<readonly ["pending", "completed", "failed"]>;
+    readonly workId: Schema.String;
+}>;
+export type DispatchRequest = typeof DispatchRequest.Type;
+//# sourceMappingURL=DispatchRequest.d.ts.map

package/dist/DispatchRequest.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"DispatchRequest.d.ts","sourceRoot":"","sources":["../src/DispatchRequest.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AAEhC,eAAO,MAAM,eAAe;;;;;;;;;EAS1B,CAAC;AACH,MAAM,MAAM,eAAe,GAAG,OAAO,eAAe,CAAC,IAAI,CAAC"}

package/dist/DispatchRequest.js

@@ -0,0 +1,12 @@
+import { Schema } from "effect";
+export const DispatchRequest = Schema.Struct({
+    acceptedAt: Schema.Number,
+    completedAt: Schema.optional(Schema.Number),
+    error: Schema.optional(Schema.String),
+    id: Schema.String,
+    ignoreAreas: Schema.optional(Schema.Boolean),
+    now: Schema.optional(Schema.Boolean),
+    status: Schema.Literals(["pending", "completed", "failed"]),
+    workId: Schema.String,
+});
+//# sourceMappingURL=DispatchRequest.js.map

package/dist/DispatchRequest.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"DispatchRequest.js","sourceRoot":"","sources":["../src/DispatchRequest.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AAEhC,MAAM,CAAC,MAAM,eAAe,GAAG,MAAM,CAAC,MAAM,CAAC;IAC5C,UAAU,EAAE,MAAM,CAAC,MAAM;IACzB,WAAW,EAAE,MAAM,CAAC,QAAQ,CAAC,MAAM,CAAC,MAAM,CAAC;IAC3C,KAAK,EAAE,MAAM,CAAC,QAAQ,CAAC,MAAM,CAAC,MAAM,CAAC;IACrC,EAAE,EAAE,MAAM,CAAC,MAAM;IACjB,WAAW,EAAE,MAAM,CAAC,QAAQ,CAAC,MAAM,CAAC,OAAO,CAAC;IAC5C,GAAG,EAAE,MAAM,CAAC,QAAQ,CAAC,MAAM,CAAC,OAAO,CAAC;IACpC,MAAM,EAAE,MAAM,CAAC,QAAQ,CAAC,CAAC,SAAS,EAAE,WAAW,EAAE,QAAQ,CAAC,CAAC;IAC3D,MAAM,EAAE,MAAM,CAAC,MAAM;CACrB,CAAC,CAAC"}

package/dist/admit.d.ts

@@ -7,6 +7,7 @@ export declare const admit: (work: {
     readonly context: string;
     readonly deliverable?: "report" | undefined;
     readonly dependsOn: readonly string[];
+    readonly priority?: "high" | "normal" | "urgent" | undefined;
     readonly revision: string;
     readonly sourcePath: string;
     readonly status?: string | undefined;
@@ -47,6 +48,7 @@ export declare const admit: (work: {
         readonly observationRetries?: number | undefined;
         readonly operationId: string;
         readonly output?: string | undefined;
+        readonly overLimit?: boolean | undefined;
         readonly progress?: {
             readonly at: number;
             readonly signature: string;
@@ -117,6 +119,7 @@ export declare const admit: (work: {
             readonly context: string;
             readonly deliverable?: "report" | undefined;
             readonly dependsOn: readonly string[];
+            readonly priority?: "high" | "normal" | "urgent" | undefined;
             readonly revision: string;
             readonly sourcePath: string;
             readonly status?: string | undefined;
@@ -142,6 +145,9 @@ export declare const admit: (work: {
     readonly decisionAcknowledged?: boolean | undefined;
     readonly decisionPublished?: boolean | undefined;
     readonly deliverable?: "report" | undefined;
+    readonly dispatchNow?: {
+        readonly ignoreAreas: boolean;
+    } | undefined;
     readonly integrationRetry?: {
         readonly error: string;
         readonly failures: number;
@@ -312,6 +318,7 @@ export declare const admit: (work: {
             readonly observationRetries?: number | undefined;
             readonly operationId: string;
             readonly output?: string | undefined;
+            readonly overLimit?: boolean | undefined;
             readonly progress?: {
                 readonly at: number;
                 readonly signature: string;
@@ -382,6 +389,7 @@ export declare const admit: (work: {
                 readonly context: string;
                 readonly deliverable?: "report" | undefined;
                 readonly dependsOn: readonly string[];
+                readonly priority?: "high" | "normal" | "urgent" | undefined;
                 readonly revision: string;
                 readonly sourcePath: string;
                 readonly status?: string | undefined;
@@ -407,6 +415,9 @@ export declare const admit: (work: {
         readonly decisionAcknowledged?: boolean | undefined;
         readonly decisionPublished?: boolean | undefined;
         readonly deliverable?: "report" | undefined;
+        readonly dispatchNow?: {
+            readonly ignoreAreas: boolean;
+        } | undefined;
         readonly integrationRetry?: {
             readonly error: string;
             readonly failures: number;

package/dist/admit.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"admit.d.ts","sourceRoot":"","sources":["../src/admit.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AAChC,OAAO,EAAE,SAAS,EAAE,MAAM,wCAAwC,CAAC;AAGnE,OAAO,KAAK,EAAE,YAAY,EAAE,SAAS,EAAE,kBAAkB,EAAE,MAAM,YAAY,CAAC;AAE9E,eAAO,MAAM,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;+CAIH,MAAM,KAAK,MAAM,CAAC,MAAM,CAAC,SAAS,EAAE,YAAY,CAAC,+CA4B9D,CAAC"}
+{"version":3,"file":"admit.d.ts","sourceRoot":"","sources":["../src/admit.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AAChC,OAAO,EAAE,SAAS,EAAE,MAAM,wCAAwC,CAAC;AAGnE,OAAO,KAAK,EAAE,YAAY,EAAE,SAAS,EAAE,kBAAkB,EAAE,MAAM,YAAY,CAAC;AAE9E,eAAO,MAAM,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;+CAIH,MAAM,KAAK,MAAM,CAAC,MAAM,CAAC,SAAS,EAAE,YAAY,CAAC,+CA4B9D,CAAC"}

package/dist/attention.d.ts

@@ -1,6 +1,7 @@
 import { Schema } from "effect";
 export declare const AttentionOwner: Schema.Literals<readonly ["maintainer", "orchestrator", "automation"]>;
 export type AttentionOwner = typeof AttentionOwner.Type;
+export declare const ANSWER_RECORDED = "Answer recorded; applying in the background";
 export declare function waitingOwner(record: {
     readonly attentionOwner?: AttentionOwner | undefined;
     readonly blocker?: string | undefined;

package/dist/attention.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"attention.d.ts","sourceRoot":"","sources":["../src/attention.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AAEhC,eAAO,MAAM,cAAc,wEAAgE,CAAC;AAC5F,MAAM,MAAM,cAAc,GAAG,OAAO,cAAc,CAAC,IAAI,CAAC;AAExD,wBAAgB,YAAY,CAAC,MAAM,EAAE;IACpC,QAAQ,CAAC,cAAc,CAAC,EAAE,cAAc,GAAG,SAAS,CAAC;IACrD,QAAQ,CAAC,OAAO,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACtC,QAAQ,CAAC,MAAM,CAAC,EAAE;QAAE,QAAQ,CAAC,OAAO,CAAC,EAAE,OAAO,GAAG,SAAS,CAAA;KAAE,GAAG,SAAS,CAAC;IACzE,QAAQ,CAAC,QAAQ,CAAC,EAAE;QAAE,QAAQ,CAAC,cAAc,CAAC,EAAE,cAAc,GAAG,SAAS,CAAA;KAAE,GAAG,SAAS,CAAC;IACzF,QAAQ,CAAC,WAAW,CAAC,EAAE;QAAE,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAA;KAAE,GAAG,SAAS,CAAC;IAChE,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;CACvB,GAAG,cAAc,GAAG,SAAS,CAW7B"}
+{"version":3,"file":"attention.d.ts","sourceRoot":"","sources":["../src/attention.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AAEhC,eAAO,MAAM,cAAc,wEAAgE,CAAC;AAC5F,MAAM,MAAM,cAAc,GAAG,OAAO,cAAc,CAAC,IAAI,CAAC;AAExD,eAAO,MAAM,eAAe,gDAAgD,CAAC;AAE7E,wBAAgB,YAAY,CAAC,MAAM,EAAE;IACpC,QAAQ,CAAC,cAAc,CAAC,EAAE,cAAc,GAAG,SAAS,CAAC;IACrD,QAAQ,CAAC,OAAO,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;IACtC,QAAQ,CAAC,MAAM,CAAC,EAAE;QAAE,QAAQ,CAAC,OAAO,CAAC,EAAE,OAAO,GAAG,SAAS,CAAA;KAAE,GAAG,SAAS,CAAC;IACzE,QAAQ,CAAC,QAAQ,CAAC,EAAE;QAAE,QAAQ,CAAC,cAAc,CAAC,EAAE,cAAc,GAAG,SAAS,CAAA;KAAE,GAAG,SAAS,CAAC;IACzF,QAAQ,CAAC,WAAW,CAAC,EAAE;QAAE,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAA;KAAE,GAAG,SAAS,CAAC;IAChE,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;CACvB,GAAG,cAAc,GAAG,SAAS,CAc7B"}

package/dist/attention.js

@@ -1,6 +1,10 @@
 import { Schema } from "effect";
 export const AttentionOwner = Schema.Literals(["maintainer", "orchestrator", "automation"]);
+export const ANSWER_RECORDED = "Answer recorded; applying in the background";
 export function waitingOwner(record) {
+    if (record.blocker === ANSWER_RECORDED) {
+        return "automation";
+    }
     if (record.launchRetry !== undefined || (record.stage === "prepared" && record.blocker?.startsWith("waiting for dependency "))) {
         return "automation";
     }

package/dist/attention.js.map

@@ -1 +1 @@
-{"version":3,"file":"attention.js","sourceRoot":"","sources":["../src/attention.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AAEhC,MAAM,CAAC,MAAM,cAAc,GAAG,MAAM,CAAC,QAAQ,CAAC,CAAC,YAAY,EAAE,cAAc,EAAE,YAAY,CAAC,CAAC,CAAC;AAG5F,MAAM,UAAU,YAAY,CAAC,MAO5B;IACA,IAAI,MAAM,CAAC,WAAW,KAAK,SAAS,IAAI,CAAC,MAAM,CAAC,KAAK,KAAK,UAAU,IAAI,MAAM,CAAC,OAAO,EAAE,UAAU,CAAC,yBAAyB,CAAC,CAAC,EAAE,CAAC;QAChI,OAAO,YAAY,CAAC;IACrB,CAAC;IACD,IAAI,MAAM,CAAC,KAAK,KAAK,aAAa,EAAE,CAAC;QACpC,OAAO,MAAM,CAAC,cAAc,IAAI,MAAM,CAAC,QAAQ,EAAE,cAAc,IAAI,cAAc,CAAC;IACnF,CAAC;IACD,IAAI,MAAM,CAAC,OAAO,KAAK,SAAS,EAAE,CAAC;QAClC,OAAO,MAAM,CAAC,cAAc,IAAI,cAAc,CAAC;IAChD,CAAC;IACD,OAAO,MAAM,CAAC,KAAK,KAAK,YAAY,IAAI,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CAAC,YAAY,CAAC,CAAC,CAAC,SAAS,CAAC;AAC3F,CAAC"}
+{"version":3,"file":"attention.js","sourceRoot":"","sources":["../src/attention.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AAEhC,MAAM,CAAC,MAAM,cAAc,GAAG,MAAM,CAAC,QAAQ,CAAC,CAAC,YAAY,EAAE,cAAc,EAAE,YAAY,CAAC,CAAC,CAAC;AAG5F,MAAM,CAAC,MAAM,eAAe,GAAG,6CAA6C,CAAC;AAE7E,MAAM,UAAU,YAAY,CAAC,MAO5B;IACA,IAAI,MAAM,CAAC,OAAO,KAAK,eAAe,EAAE,CAAC;QACxC,OAAO,YAAY,CAAC;IACrB,CAAC;IACD,IAAI,MAAM,CAAC,WAAW,KAAK,SAAS,IAAI,CAAC,MAAM,CAAC,KAAK,KAAK,UAAU,IAAI,MAAM,CAAC,OAAO,EAAE,UAAU,CAAC,yBAAyB,CAAC,CAAC,EAAE,CAAC;QAChI,OAAO,YAAY,CAAC;IACrB,CAAC;IACD,IAAI,MAAM,CAAC,KAAK,KAAK,aAAa,EAAE,CAAC;QACpC,OAAO,MAAM,CAAC,cAAc,IAAI,MAAM,CAAC,QAAQ,EAAE,cAAc,IAAI,cAAc,CAAC;IACnF,CAAC;IACD,IAAI,MAAM,CAAC,OAAO,KAAK,SAAS,EAAE,CAAC;QAClC,OAAO,MAAM,CAAC,cAAc,IAAI,cAAc,CAAC;IAChD,CAAC;IACD,OAAO,MAAM,CAAC,KAAK,KAAK,YAAY,IAAI,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CAAC,YAAY,CAAC,CAAC,CAAC,SAAS,CAAC;AAC3F,CAAC"}

package/dist/board/fleetField.d.ts

@@ -2,4 +2,5 @@ import type { ParsedMetadata } from "@shivaedev/work-board/integration/board.ts"
 export declare function fleetApproved(parsed: ParsedMetadata): boolean;
 export declare function fleetLaunch(parsed: ParsedMetadata): unknown;
 export declare function fleetDeliverable(parsed: ParsedMetadata): unknown;
+export declare function fleetPriority(parsed: ParsedMetadata): unknown;
 //# sourceMappingURL=fleetField.d.ts.map

package/dist/board/fleetField.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"fleetField.d.ts","sourceRoot":"","sources":["../../src/board/fleetField.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,4CAA4C,CAAC;AAuBjF,wBAAgB,aAAa,CAAC,MAAM,EAAE,cAAc,GAAG,OAAO,CAE7D;AAED,wBAAgB,WAAW,CAAC,MAAM,EAAE,cAAc,GAAG,OAAO,CAE3D;AAED,wBAAgB,gBAAgB,CAAC,MAAM,EAAE,cAAc,GAAG,OAAO,CAEhE"}
+{"version":3,"file":"fleetField.d.ts","sourceRoot":"","sources":["../../src/board/fleetField.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,4CAA4C,CAAC;AAwBjF,wBAAgB,aAAa,CAAC,MAAM,EAAE,cAAc,GAAG,OAAO,CAE7D;AAED,wBAAgB,WAAW,CAAC,MAAM,EAAE,cAAc,GAAG,OAAO,CAE3D;AAED,wBAAgB,gBAAgB,CAAC,MAAM,EAAE,cAAc,GAAG,OAAO,CAEhE;AAED,wBAAgB,aAAa,CAAC,MAAM,EAAE,cAAc,GAAG,OAAO,CAE7D"}

package/dist/board/fleetField.js

@@ -2,6 +2,7 @@ import { parse } from "yaml";
 const APPROVAL = "fleet";
 const LAUNCH = "fleet-launch";
 const DELIVERABLE = "fleet-deliverable";
+const PRIORITY = "fleet-priority";
 const parsedFields = new WeakMap();
 function fleetField(parsed, field) {
     if (parsed.raw === undefined || parsed.lines[field] === undefined || parsed.diagnostics.some((diagnostic) => diagnostic.field === undefined)) {
@@ -27,4 +28,7 @@ export function fleetLaunch(parsed) {
 export function fleetDeliverable(parsed) {
     return fleetField(parsed, DELIVERABLE);
 }
+export function fleetPriority(parsed) {
+    return fleetField(parsed, PRIORITY);
+}
 //# sourceMappingURL=fleetField.js.map

package/dist/board/fleetField.js.map

@@ -1 +1 @@
-{"version":3,"file":"fleetField.js","sourceRoot":"","sources":["../../src/board/fleetField.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,EAAE,MAAM,MAAM,CAAC;AAG7B,MAAM,QAAQ,GAAG,OAAO,CAAC;AACzB,MAAM,MAAM,GAAG,cAAc,CAAC;AAC9B,MAAM,WAAW,GAAG,mBAAmB,CAAC;AACxC,MAAM,YAAY,GAAG,IAAI,OAAO,EAAgD,CAAC;AAEjF,SAAS,UAAU,CAAC,MAAsB,EAAE,KAAa;IACxD,IAAI,MAAM,CAAC,GAAG,KAAK,SAAS,IAAI,MAAM,CAAC,KAAK,CAAC,KAAK,CAAC,KAAK,SAAS,IAAI,MAAM,CAAC,WAAW,CAAC,IAAI,CAAC,CAAC,UAAU,EAAE,EAAE,CAAC,UAAU,CAAC,KAAK,KAAK,SAAS,CAAC,EAAE,CAAC;QAC9I,OAAO,SAAS,CAAC;IAClB,CAAC;IACD,MAAM,MAAM,GAAG,YAAY,CAAC,GAAG,CAAC,MAAM,CAAC,CAAC;IACxC,IAAI,MAAM,KAAK,SAAS,EAAE,CAAC;QAC1B,OAAO,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC;IAC1B,CAAC;IACD,MAAM,KAAK,GAAG,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,QAAQ,CAAC,CAAC;IACzC,MAAM,OAAO,GAAG,KAAK,CAAC,aAAa,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,OAAO,EAAE,KAAK,KAAK,CAAC,CAAC;IACxE,MAAM,IAAI,GAAY,KAAK,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC,EAAE,OAAO,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC;IAChE,MAAM,MAAM,GAAG,IAAI,GAAG,CAAC,OAAO,IAAI,KAAK,QAAQ,IAAI,IAAI,KAAK,IAAI,CAAC,CAAC,CAAC,MAAM,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;IAC9F,YAAY,CAAC,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IACjC,OAAO,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC;AAC1B,CAAC;AAED,MAAM,UAAU,aAAa,CAAC,MAAsB;IACnD,OAAO,UAAU,CAAC,MAAM,EAAE,QAAQ,CAAC,KAAK,UAAU,CAAC;AACpD,CAAC;AAED,MAAM,UAAU,WAAW,CAAC,MAAsB;IACjD,OAAO,UAAU,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;AACnC,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,MAAsB;IACtD,OAAO,UAAU,CAAC,MAAM,EAAE,WAAW,CAAC,CAAC;AACxC,CAAC"}
+{"version":3,"file":"fleetField.js","sourceRoot":"","sources":["../../src/board/fleetField.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,KAAK,EAAE,MAAM,MAAM,CAAC;AAG7B,MAAM,QAAQ,GAAG,OAAO,CAAC;AACzB,MAAM,MAAM,GAAG,cAAc,CAAC;AAC9B,MAAM,WAAW,GAAG,mBAAmB,CAAC;AACxC,MAAM,QAAQ,GAAG,gBAAgB,CAAC;AAClC,MAAM,YAAY,GAAG,IAAI,OAAO,EAAgD,CAAC;AAEjF,SAAS,UAAU,CAAC,MAAsB,EAAE,KAAa;IACxD,IAAI,MAAM,CAAC,GAAG,KAAK,SAAS,IAAI,MAAM,CAAC,KAAK,CAAC,KAAK,CAAC,KAAK,SAAS,IAAI,MAAM,CAAC,WAAW,CAAC,IAAI,CAAC,CAAC,UAAU,EAAE,EAAE,CAAC,UAAU,CAAC,KAAK,KAAK,SAAS,CAAC,EAAE,CAAC;QAC9I,OAAO,SAAS,CAAC;IAClB,CAAC;IACD,MAAM,MAAM,GAAG,YAAY,CAAC,GAAG,CAAC,MAAM,CAAC,CAAC;IACxC,IAAI,MAAM,KAAK,SAAS,EAAE,CAAC;QAC1B,OAAO,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC;IAC1B,CAAC;IACD,MAAM,KAAK,GAAG,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,QAAQ,CAAC,CAAC;IACzC,MAAM,OAAO,GAAG,KAAK,CAAC,aAAa,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,OAAO,EAAE,KAAK,KAAK,CAAC,CAAC;IACxE,MAAM,IAAI,GAAY,KAAK,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC,EAAE,OAAO,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC;IAChE,MAAM,MAAM,GAAG,IAAI,GAAG,CAAC,OAAO,IAAI,KAAK,QAAQ,IAAI,IAAI,KAAK,IAAI,CAAC,CAAC,CAAC,MAAM,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC;IAC9F,YAAY,CAAC,GAAG,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;IACjC,OAAO,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC;AAC1B,CAAC;AAED,MAAM,UAAU,aAAa,CAAC,MAAsB;IACnD,OAAO,UAAU,CAAC,MAAM,EAAE,QAAQ,CAAC,KAAK,UAAU,CAAC;AACpD,CAAC;AAED,MAAM,UAAU,WAAW,CAAC,MAAsB;IACjD,OAAO,UAAU,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC;AACnC,CAAC;AAED,MAAM,UAAU,gBAAgB,CAAC,MAAsB;IACtD,OAAO,UAAU,CAAC,MAAM,EAAE,WAAW,CAAC,CAAC;AACxC,CAAC;AAED,MAAM,UAAU,aAAa,CAAC,MAAsB;IACnD,OAAO,UAAU,CAAC,MAAM,EAAE,QAAQ,CAAC,CAAC;AACrC,CAAC"}

package/dist/board/markdown.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"markdown.d.ts","sourceRoot":"","sources":["../../src/board/markdown.ts"],"names":[],"mappings":"AAAA,OAAO,EAAmB,UAAU,EAAE,KAAK,EAAE,IAAI,EAAU,MAAM,QAAQ,CAAC;AAc1E,OAAO,EAAgB,YAAY,EAAE,MAAM,YAAY,CAAC;AAsFxD,wBAAgB,aAAa,CAAC,IAAI,EAAE,MAAM,8GAEzC"}
+{"version":3,"file":"markdown.d.ts","sourceRoot":"","sources":["../../src/board/markdown.ts"],"names":[],"mappings":"AAAA,OAAO,EAAmB,UAAU,EAAE,KAAK,EAAE,IAAI,EAAU,MAAM,QAAQ,CAAC;AAc1E,OAAO,EAAgB,YAAY,EAAY,MAAM,YAAY,CAAC;AA2FlE,wBAAgB,aAAa,CAAC,IAAI,EAAE,MAAM,8GAEzC"}

package/dist/board/markdown.js

@@ -6,13 +6,13 @@ import { briefRevision } from "#board/briefRevision.ts";
 import { completionMarkdown } from "#board/completionMarkdown.ts";
 import { decisionReading } from "#board/decisionReading.ts";
 import { boundDocuments, boundSnapshot, refreshSnapshotDocument, snapshotDocument } from "#board/documents.ts";
-import { fleetApproved, fleetDeliverable } from "#board/fleetField.ts";
+import { fleetApproved, fleetDeliverable, fleetPriority } from "#board/fleetField.ts";
 import { publishBoard } from "#board/publish.ts";
 import { publishReport } from "#board/publishReport.ts";
 import { workMetadata } from "#board/readPass.ts";
 import { workRevision } from "#board/workRevision.ts";
 import { writeCompletion } from "#board/writeCompletion.ts";
-import { BoardFailure, BoardGateway } from "#policy.ts";
+import { BoardFailure, BoardGateway, Priority } from "#policy.ts";
 import { RepositoryPath } from "#preparation/schema.ts";
 class BoardRoot extends Context.Service()("Fleet/BoardRoot") {
 }
@@ -34,6 +34,10 @@ const MarkdownBoard = defineService({
             if (deliverable !== undefined && deliverable !== "report") {
                 return yield* Effect.fail(new BoardFailure({ message: "Invalid fleet-deliverable; use report or omit the field for pull requests." }));
             }
+            const priority = fleetPriority(found.parsed);
+            if (priority !== undefined && !Schema.is(Priority)(priority)) {
+                return yield* Effect.fail(new BoardFailure({ message: "Invalid fleet-priority; use urgent, high or normal, or omit the field." }));
+            }
             return {
                 approved: fleetApproved(found.parsed),
                 areas: found.parsed.fields.areas,
@@ -41,6 +45,7 @@ const MarkdownBoard = defineService({
                 ...(deliverable === "report" ? { deliverable: "report" } : {}),
                 context: found.source,
                 dependsOn: (found.parsed.fields.relationships ?? []).filter((relation) => relation.kind === "depends_on").map((relation) => relation.target),
+                ...(priority === undefined ? {} : { priority }),
                 revision: briefRevision(found.parsed),
                 sourcePath: path.join(realRoot, found.file),
                 workId,