@defrex/autobuild 0.12.0 → 0.14.0

package/README.md

@@ -24,7 +24,7 @@ needs an authenticated [`gh` CLI](https://cli.github.com) or an exported
 <!-- release-install:start -->
 
 ```sh
-bun add -g @defrex/autobuild@0.12.0
+bun add -g @defrex/autobuild@0.14.0
 ```
 
 <!-- release-install:end -->

package/SPEC.md

@@ -432,6 +432,13 @@ body file leaves the pinned assets unchanged. The one case this cannot cover is
 a record an older dispatcher created with an empty stream: recovery can only
 sample the ticket's current assets for it.
 
+For hosted tickets, exact sampled revisions are copied into immutable repository
+artifacts in the destination build store before pins are published. Pins carry
+explicit manifest references; bounded binary chunks preserve files and empty
+directories without contacting the ticket service during build reads. Original
+ticket revision numbers are preserved. Old pins without snapshot references
+continue reading their existing ticket rows.
+
 ## 7. The build store
 
 The v1 repo-bloat and no-observability problems share one root cause: the
@@ -450,7 +457,7 @@ builds       id/slug, ticket ref, repo, branch, status (derived), created/update
              lease + heartbeat (mutable liveness columns — §15.2.6, never events)
 events       build_id, seq, timestamp, actor, type, payload (JSON)   — append-only
 artifacts    build_id, kind, revision, blobRef, metadata
-repo_streams repo, created/updated, lease + heartbeat
+repo_streams repo, created/updated, lease + heartbeat, bounded tick observation
 repo_events  repo, seq, timestamp, actor, type, payload (JSON) — append-only
 repo_artifacts repo, kind, revision, blobRef, metadata
 ticket_assets repo, ticket_id, kind, name, revision, layout, manifest (JSON), size,
@@ -618,15 +625,23 @@ resume or turn — no second turn, no concurrent turns, no subagents.
 
 A **ticket asset** is a named, versioned bundle of files attached to a ticket —
 a design export, a reference screenshot, a sample payload — that shapes a change
-but belongs neither in the repository (where it goes stale once the change
-ships) nor in the ticket tool (which build agents cannot reach). It is keyed by
+but belongs outside the repository, where it would go stale once the change ships. It is keyed by
 `(repo, ticketId, kind, name)` and works identically whichever ticket source is
 configured. It is a fourth resource family beside builds, repository journals,
 and sessions, but a deliberately thin one: no event log, because nothing here
 needs reduction, and no retention pruning, because assets live as long as the
 ticket's other durable data and never expire on their own.
 
-Each put creates a new 0-based **revision**; earlier revisions stay retrievable.
+Hosted ticket assets live in the ticket service's repository-keyed storage,
+regardless of where builds run or which BuildStore is selected. File tickets use
+native portable storage composed with legacy BuildStore attachments; Linear
+tickets retain BuildStore storage. Existing service assets need no migration;
+old local hosted-ticket attachments are not moved or used as a fallback.
+
+Each put creates a new increasing **revision**; earlier revisions stay retrievable.
+Adapters normally start at 0. Native file assets reserve revisions from
+1,000,000,000 upward so explicit reads of old BuildStore revisions remain
+unambiguous when native and legacy assets are composed.
 An asset is a `file` (exactly one file) or a `tree` (a folder: its root is
 implicit, so a tree with zero entries is a valid empty folder). The manifest is
 a list of entries — `file` entries with size and content address, and `dir`
@@ -1071,9 +1086,9 @@ kind and operation.
 
 Ticket admission uses the credential project. Hosted tickets, comments, blockers, creation-key
 deduplication and assets are partitioned by registered repository, never team.
-Lifecycle comes from that project's latest durable effective configuration
-(triage Backlog, claim Doing, completion Done by default; configurable
-`doneState`). Owner admin ticket requests explicitly select a registered
+Lifecycle comes from independent project ticket policy (triage, ready, doing, done
+by default; configurable doneState). Legacy projects without independent policy
+use their uploaded configuration with Backlog / Doing / Done defaults. Owner admin ticket requests explicitly select a registered
 repository. The service has no Linear ticket backend: external tracker and
 file sources remain dispatcher-side, and service ticket surfaces refuse those
 projects with actionable source feedback. Legacy team queues migrate atomically
@@ -1273,9 +1288,10 @@ implementer:  ab context   (findings.json now materialized) → …
 
 Human/pre-build ticket grooming uses one configured-source namespace
 (`ab ticket create|update|block|unblock|list|show|move`, plus the ticket-asset
-forms below). These commands are
+forms below). Migration adds `ab ticket export <dir>` and `ab ticket import <dir>`
+(see [Ticket source migration](#ticket-source-migration)). These commands are
 sessionless, source-agnostic, and never available as a mid-build spec
-mutation path. Every subcommand accepts `--json` and then writes exactly one
+mutation path. The CRUD subcommands accept `--json` and then writes exactly one
 bare value: `list` emits `Ticket[]`; every other form emits the complete
 created, read, or post-mutation `Ticket`. Human-readable confirmations are not
 a data format and callers must not parse ids from them.
@@ -1290,8 +1306,10 @@ creates tickets directly in its ready state must therefore create a dependency
 chain in dependency order, carrying each predecessor id into the next create,
 before a later ticket can be claimed.
 
-**Ticket assets** (§7.1) attach files to a ticket without touching the ticket
-source's storage:
+**Ticket assets** (§7.1) attach files to a ticket. Hosted tickets use their
+ticket service storage independently of the selected build store; file tickets use
+native storage with legacy fallback, and sources without native assets use the
+selected BuildStore:
 
 - `ab ticket attach <id> <kind> <path> [--name <name>] [--store <ref>] [--json]`
   stores a file or a whole folder (its relative tree preserved) as an asset.
@@ -1762,9 +1780,10 @@ event-level mechanics live in the repository catalog and reducer tests):
 repository; an owner selects a registered repository explicitly. Team and state
 fields from clients convey no authority or lifecycle policy. Tickets, comments,
 blockers, creation-key deduplication and assets are isolated by repository.
-The project's latest effective configuration supplies hosted lifecycle names:
-triage Backlog, claimed Doing, completion Done (`doneState`) and create/proposal
-equal to triage by default; `readyState` is required. Configured roles may overlap.
+Independent project ticket policy supplies hosted lifecycle names: triage, ready,
+doing, done (`doneState`), and create/proposal equal to triage by default. Hosted
+readyState defaults to ready; other sources require it. Legacy clients without
+independent policy use uploaded dispatcher config and its old defaults. Configured roles may overlap.
 The service has no Linear backend and never relays external ticket sources.
 Projects using Linear, files or plugins keep their direct dispatcher connection;
 service ticket surfaces refuse with project/source feedback instead of empty data.
@@ -1780,14 +1799,16 @@ This keeps the abstraction honest: a file-based TicketSource with nowhere to
 put blobs must be fully workable.
 
 **Ticket assets follow the same rule.** The contents of a ticket asset (§7.1)
-live in the BuildStore and the ticket source never stores them. Attaching,
+live in the ticket service for hosted tickets, independently of build storage;
+file sources keep portable bundles and source-local history, while sources without
+native assets keep them in the BuildStore. Attaching,
 replacing, or removing an asset instead leaves a note on the ticket through the
 existing `comment()` port — the outward projection every source, including the
 plugin surface, already supports. The note names the asset, its revision, file
 count, and size, and gives the `ab ticket asset get` command that fetches it, so
 a person reading the ticket in Linear, the hosted service, or a local file knows
 the asset exists. The note is a projection outward only; nothing reads it back,
-and no TicketSource port or plugin-protocol change is needed.
+and existing sources and plugins need no asset capability.
 
 **Claim lifecycle.** Claim acquires nonterminal work: it returns `true` and
 moves a claimable ticket to the source's claimed state. It returns `false` for
@@ -1905,6 +1926,24 @@ head (or an explicit commit) to a deterministic operator branch and a pull
 request against the base branch and records published/publish-failed journal
 facts.
 
+Successful dispatcher ticks with no effects, counters, diagnostics, queue change,
+or attention transition append no tick boundary events. The first queue baseline,
+failed ticks, meaningful ticks, diagnostic clearing, failure recovery, and the
+first retry after a source cooldown remain recorded. Recorded starts may arrive
+with completion; optional `startedAt` preserves the actual start time, falling
+back to envelope time for historical journals.
+
+Repository tick telemetry is bounded mutable operational metadata, like leases.
+`beginRepoTick` persists the open boundary before unsafe work; `finishRepoTick`
+atomically replaces it with actual completion time and outcome and appends any
+validated tick boundaries. Both are fenced by the unexpired repository lease,
+and neither renews it. Quiet completions advance telemetry without advancing the
+journal. Readers refresh telemetry independently of event cursors, correlate it
+by run, and merge with historical completions by actual time; heartbeat never
+stands in for tick completion. Telemetry survives lease release. Safe shutdown
+uses the matching run's open observation, historical journal boundaries when
+absent, and refuses forced termination when the observation cannot be read.
+
 The operator's job across many concurrent builds: see status at a glance,
 act on a selected build, find blocked builds, answer escalations, and inspect
 any build's trail. Each dashboard build row spends its header on identity and
@@ -2230,6 +2269,21 @@ adapter never re-cuts it from a newer base (§7.4). `ab context` rehydrates
 scratch from the store into a fresh session. Uncommitted round-2 work is lost by
 design (§7.3 — phase boundaries are the resume points).
 
+The dispatcher also applies a fixed, non-configurable limit of three consecutive
+executions that complete normally with exit code zero and no durable build
+progress. Execution start/end, runner attachment and workspace lifecycle
+bookkeeping do not count as progress. Pipeline, session, spec, publication/PR,
+observation and acknowledged operator facts reset the streak; infrastructure,
+budget and provider failures do not consume the allowance and retain their own
+retry limits. Before a fourth actionable launch, the dispatcher raises one
+setup-targeted `execution-no-progress` policy escalation naming the count and
+the next action it expected the runner to take. Waiting, paused and terminal
+builds are left parked, and pending operator commands remain executable.
+Answering that escalation with guidance or a bare `ab answer <slug>` retry grants
+three fresh executions. The guard is derived from durable facts, including on
+supervisor restart, and uses the ordinary watch, dashboard and operator API
+attention paths.
+
 Two liveness rules complete the picture. Within one dispatcher process,
 build-runner launches are single-flighted by slug through supervised process
 liveness — execution completion means the complete environment has been reaped,
@@ -2781,3 +2835,71 @@ or installs releases in the foreground or background.
    enforcement and will colocate later session-authenticated human routes.
    Artifacts remain content-by-value for now; direct-to-blob references are a
    possible later protocol revision, not a second current deployment path.
+
+## Revision-checked ticket writes
+
+Every ticket read includes an opaque `revision`. Pass it as `expectedRevision`
+(on MCP/operator requests) or `--expected-revision <opaque>` on `ab ticket update`,
+`move`, `block` and `unblock`. A stale write fails without changing anything and
+reports the current revision. Omission preserves unguarded behavior. Blocker
+checks cover the entire batch. Dispatcher moves remain unguarded and change the
+revision. Sources without guarded writes, including Linear, refuse supplied
+revisions rather than ignoring them.
+
+`ab ticket edit <id>` opens `$VISUAL`, falling back to `$EDITOR`, using TOML
+frontmatter and a Markdown body. Only title, body and labels are editable;
+id, blockers, creation key and reference comments are read-only. It saves only
+changed fields with the opening revision. Unchanged or formatting-only edits
+write nothing. On conflict, invalid input or editor failure, the error names an
+absolute file path containing the edited text. Read the current ticket and
+reapply the intended changes before retrying; conflicts are never merged.
+
+File and Linear revisions fingerprint title, body, canonical label/blocker sets
+and state; reverting identical content restores its fingerprint. File checks
+re-read immediately before writing, with the existing no-lock race window.
+Direct file edits and state-directory moves change revisions. File revisions also
+cover structured comments and portable attachments. Legacy file comments change
+the body; structured comments preserve it. Separate hosted comments do not change
+ticket revisions. Hosted revisions
+are monotonic decimal bigint strings, and checks run under the same row lock
+and transaction as all requested changes. Hosted reads return a coherent
+snapshot of fields, blockers and revision.
+
+### Independent hosted ticket service
+
+`[tickets] url` selects hosted ticket transport independently of BuildStore selection;
+without it, tickets use the selected remote build store. Local builds require an
+explicit ticket URL. Project registration and ticket policy publication through
+`ab connect --tickets URL` work before dispatch. Policy is a durable per-registration
+record, outside BuildStore events/artifacts; legacy uploaded configuration remains
+a compatibility fallback. Hosted lifecycle defaults are triage/ready/doing/done.
+Independent harvest uses revocable, expiring, service-bound ticket grants with
+read/create runner authority and read-only child authority. Build state and harvest
+journals remain exclusively in the selected BuildStore.
+
+### Ticket source migration
+
+`ab ticket export <dir>` enumerates all states through TicketSource and writes a
+portable file tracker atomically to an absent or empty destination.
+`ab ticket import <dir>` preflights the entire tracker and target inventory, then
+creates or adopts tickets, maps blockers, deduplicates comments by exact body and
+restores current attachments. Both run sessionless without forge access.
+
+TicketCreateOptions includes optional `requestedId`. Unsupported sources reject
+it. File keeps safe ids exactly; hosted preserves canonical own-team positive
+numbers and advances its counter above every occupied number. Creation-key
+adoption precedes collision checks. Known kept-number clashes stop import before
+any target mutation. Stable migration identities and atomic mapping files make
+interrupted imports resumable without content-based adoption.
+
+File frontmatter additionally supports optional structured `comments` (body,
+createdAt, optional author) and `attachments` (kind, name, layout, entries with
+file base64 bytes or directory paths). Legacy absent fields retain old behavior;
+new creates use structured comments. Native file assets retain historical
+revisions in hidden source-local metadata and compose with legacy BuildStore
+assets. Build claims and spec re-pins freeze native assets into durable snapshots.
+
+State normalization and the complete operator procedure are documented in
+[Ticket migration](docs/ticket-migration.md). The same reference is delivered in
+the installed guide. Export keeps lifecycle membership without inferring roles;
+import reuses unique case-insensitive states and creates normalized missing ones.

package/bin/ab-dispatch-kernel.ts

@@ -1,4 +1,5 @@
 #!/usr/bin/env bun
+import { readDispatcherRunFacts } from '../packages/core/src/store/reduced-reads'
 /** Private, shipped child for the interactive `ab dispatch` kernel. It owns no
  * terminal handles; the public command launches it with immutable options. */
 import { abDispatch } from '../packages/core/src/cli/dispatch'
@@ -61,12 +62,9 @@ try {
     const opened = openStoreForRepoState(state, { env: process.env })
     try {
       await opened.store.ensureRepo(state.repo)
-      const events = await opened.store.getRepoEvents(state.repo)
-      if (
-        !events.some(
-          (event) => event.type === 'dispatcher.run-stopped' && event.payload.run === options.run,
-        )
-      ) {
+      const facts = (await readDispatcherRunFacts(opened.store, state.repo, options.run, false))
+        .value
+      if (!facts.stop) {
         await opened.store.appendRepo(state.repo, {
           actor: DISPATCHER,
           type: 'dispatcher.run-stopped',

package/docs/architecture.md

@@ -145,9 +145,9 @@ by a later advance. Each reducer publishes a `version`; bump it whenever the
 accumulator shape or the fold semantics change, because a cached accumulator is
 only valid for the version that wrote it. `kernel/reducer-registry.ts` lists
 every reducer with its version, and its snapshot test fails when an accumulator
-shape changes without a bump. Most callers still read whole logs (the terminal
-dashboard poll advances a carried build accumulator by per-build deltas; the
-dispatcher view below restores from stored accumulators).
+shape changes without a bump. Current-state consumers use the typed persisted
+read helpers in `store/reduced-reads.ts`; whole-array reducers remain pure
+reference projections for tests and explicit historical output.
 
 **Reducer snapshots.** The `BuildStore` port can keep, per scope (one build log
 or the repository journal) and registered reducer, that reducer's accumulator as
@@ -173,72 +173,86 @@ reads every snapshot as missing and replays (SQLSTATE `42P01` is never an
 error), and an older client never asks. Run `bun run postgres:migrate` once to
 gain the table; until then the dispatcher and every other reader replay in full.
 
-**Dispatcher repository view.** A dispatcher process builds its view of the
-repository once and refreshes it by deltas
-(`packages/core/src/processes/repo-view.ts`). `RepoViewStore` decorates the
-`BuildStore` port: the first `refresh()` reads the journal's high-water mark
-(`getRepoHighWater`), the bounded journal subset, the build listing and digests,
-and the full log of every build that still has work (the same predicate the tick
-loops use); every later `refresh()` reads only events newer than its cursors —
-one journal delta, one delta per held build, plus the listing and digest reads
-that discover new builds. Every tick stage reads and writes through the view, so
-an event a stage appends is folded in at once and later stages in the same tick
-see it with no re-read; a foreign append interleaved with ours leaves a seq gap
-that marks the log dirty, a lost compare-and-set does the same, and any delta
-that is not contiguous from its cursor discards the log and re-reads it in full,
-so no event is skipped. Every state transition of one source (a build, the
-journal) runs on that source's single promise chain — snapshot and delta reads,
-window opening and widening, the fold after an own append, a lost
-compare-and-set's invalidation — and readers queue on it too, so overlapping
-readers join the repair in flight instead of observing half-applied state.
-Decisions that deliberately re-read at the last moment
-(`refreshBuild`) take an explicit delta. Cursor-bearing readers such as the
-orchestrator wake pass get per-source windows that hold only events above the
-lowest session cursor. A `--once` invocation builds the view cold and reads each
-log once; a long-running dispatcher pays that replay at its first tick and not
-again.
-
-The view restores from reducer snapshots on cold start. The journal comes from
-the `journalView` reducer (the journal pruned on arrival: durable types plus the
-tail from the latest `dispatcher.run-started`); each work build comes from one
-`work` snapshot row — the `build`, `logIndex`, `openExecution`,
-`openBuildWorkspace`, `publicationState`, `lastExecutionOutcome`, `buildDigest`,
-`dashboardFacts` and `currentDeferralObservation` accumulators at a single
-cursor. One row is one atomic write on every adapter, so a reader in another
-process sees the old bundle or the new, never a mix; the bundle version is
-derived from the component reducer versions, so a stale bundle misses and the
-build is replayed once. The view
-reads only the events newer than that cursor and holds, for a snapshot-backed
-build, just that delta plus the reduced state of everything before it, so a tick
-with no new events reads zero event rows (apart from the discovery listing and
-digests) and one with M new events reads exactly M. Tick stages that run for every
-build each tick take `buildFacts(slug)` (state, log index, open execution, open
-workspace, publication view) instead of the event array, and read raw history
-only on the branches that act on it. `persistSnapshots()` writes the advanced
-state back at the end of each tick and on shutdown — best effort, throttled in a
-resident dispatcher, always run by a cold single-tick process — and never writes
-a cursor that was not read from the log.
-
-**Operator reads.** The web dashboard, the repository and Harvest status
-routes, the operator build listings, and the `ab watch`/`ab wait` discovery
-passes derive from that same view instead of replaying the log
-(`packages/core/src/operator/read-view.ts`). A dashboard row renders from the
-`BuildState` plus the `dashboardFacts` reducer
-(`packages/core/src/cli/dashboard/facts.ts`: queued-row dispatch text, session
-brackets, phase intervals, pause time, and the per-round loop-output seqs) and
-the auto-merge deferral ledger; `projectBuild(…, events)` is the same projection
-over the whole-array reduction, so the snapshot and replay paths cannot differ.
-Within one serving process, passes are single-flight per repository: requests
-arriving while a pass runs join the one trailing pass, which restores from the
-snapshot the previous pass persisted. A poll at idle therefore reads no event
-rows beyond snapshot lookups and build discovery, and a poll after M new events
-reads those M rows once, however many tabs or watchers the process serves.
-Serving processes do not coordinate: with P of them, each may read the same M
-rows once, so duplicate reads are bounded by P and never by history, tabs, or
-watchers. A settled build listed under `--all` is restored from the snapshot the
-dispatcher left at settlement, or read once and then persisted. The first
-operator poll after upgrading replays each work build once, because the stored
-bundle layout changed.
+**Named reducer values.** `BuildStore.getReducerValue(scope, {reducer, args?})`
+returns `{version, cursor, value}` for each eligible entry in the executable
+reducer registry. Eligible reducers consume build or repository events and finish
+as plain JSON; raw journal-event lists, operator-session reducers, collections,
+selector functions, and top-level optional results are explicitly excluded with
+reasons. Factory arguments are validated and participate in a bounded digest
+cache key. The persisted envelope also records the canonical scope, arguments,
+name and version, and nested accumulator shapes are validated before restore.
+The `value.*` namespace is reserved: public snapshot reads and writes reject it,
+and the engine persists through private adapter hooks. Versioned cache keys
+exclude checkpoints produced while the old namespace was publicly writable.
+`tools/reducer-value-shapes.ts` regenerates those structural validators from the
+declared accumulator types.
+
+Memory, SQLite and Postgres use the same algorithm: capture the authoritative
+high-water, load persisted state on every call, fold the indexed contiguous delta
+through that boundary, persist, and return an independent JSON value. There is
+no process-local accumulator cache. A foreign checkpoint newer than the initial
+boundary causes a fresh high-water check. Normal writes are monotone; corrupt,
+wrong-version or ahead-of-log rows are repaired only by comparing the exact row
+observed, atomically with the log boundary. A losing writer still returns its
+correct prefix. Missing or unreadable cache state replays; log failures propagate.
+
+The remote adapter makes one value request; only the finished answer crosses the
+wire. The service uses named effective-configuration references for hosted ticket
+operations (including policy publication) and semantic build/harvest lifecycle
+facts for delegated authentication and issuance. Lifecycle snapshots keep session,
+execution and terminal evidence, including historical endings, without dispatcher
+tick tails. Anchor membership follows the contiguous log prefix. The legacy
+state-events route remains a deprecated compatibility endpoint. Public generic
+snapshot routes remain compatible, but current consumer reads do not restore the
+former dispatcher work bundles.
+
+**Dispatcher repository view.** `RepoViewStore`
+(`packages/core/src/processes/repo-view.ts`) coordinates repository metadata and
+source promise chains. Its build and journal facts come from persisted reduced
+values. Reads after an append or lost conditional append consult that boundary
+again, so no process-local memo suppresses a required delta. The adapter owns
+cache persistence and recovery; the view neither writes work bundles nor hydrates
+whole logs for decisions. Discovery uses persisted build digests, including for
+settled builds. Raw methods forward actual cursor event output.
+
+JSON-safe companion projections preserve collection and optional-value contracts.
+The build facts projection returns one prefix for engine routing; its log-index
+rounds and finalize steps reconstruct Maps and Sets explicitly, while publication
+selectors reconstruct from a JSON ledger. Repository facts retain configuration,
+control, Harvest, and dispatcher run correlations. Lease metadata and clocks stay
+outside event reducers: liveness combines durable run facts with the current
+repository record and observation time, including an older lease holder hidden
+by a newer run. The shared repository value keeps a bounded recent-run window, including the
+latest started and stopped runs. Fresh invocations use those shared facts for
+first-tick publication, liveness and supervision without creating a cold
+parameterized cache. Older holder correlations can use `dispatcherRunFacts` for
+the requested historical run. A never-started fresh invocation does not request
+historical correlation. Stopped dispatcher history is not copied into every
+current read.
+
+**Operator and CLI reads.** Build listings and details, repository and Harvest
+status, dispatcher decisions, operator API queries, MCP delegation and web
+dashboard refreshes use the same typed persisted read helpers. Shared projection
+functions render those facts; whole-array overloads remain reference oracles.
+Operator passes are single-flight per repository, with requests arriving during a
+pass queued for one trailing pass. Fresh readers use persisted cache rows too;
+steady-state event-row cost depends on newly appended events at fixed build/run
+cardinality, not on log length. Reduced collections may legitimately grow in JSON
+size. Cache loss or corruption can replay history once to recover the same answer.
+
+Watch and wait register from a compound persisted `buildStreamSeed` at cursor C.
+Its build accumulator, deferral ledger and insertion-ordered historical PR
+eligibility describe that same prefix. Ordinary polling, including the first
+batch on an old build, reads only events after the cursor and advances that seed
+event by event, preserving state at event N in each emitted record. Watch uses
+historical eligibility for baseline suppression; wait retains its separate
+current-attention registration policy. Only an explicit `--since` older than C
+reconstructs a historical prefix once in `cli/historical-build-state.ts`.
+Actual event listings, transcripts and cursor streams remain raw reads. The
+interactive terminal frontend retains its independently established incremental
+feed. `tools/persisted-reduced-reads.test.ts` scans production TypeScript calls
+and maintains precise, reason-bearing exceptions for these boundaries and pure
+reference projections; stale exceptions fail the check.
 
 **Session Store authority.** `packages/core/src/cli/binary.ts` validates a complete build or
 Harvest ambient tuple before opening its phase Store through
@@ -364,6 +378,10 @@ once. Guidance answering the policy escalation after failed-report exhaustion
 instead routes to `implement` and outranks the pending report. A bare retry carries no
 feedback.
 
+The dispatcher launch boundary uses `processes/execution-no-progress.ts` to
+project clean empty execution streaks through `RepoViewStore` snapshots and
+conditionally raise an ordinary setup policy escalation before a fourth launch.
+
 **Launch ownership.** `packages/core/src/cli/dispatch.ts` is the kernel owner and
 single-flights supervised build executions per slug within its process. It
 publishes effective config into the build artifact namespace, claims the exact
@@ -383,7 +401,19 @@ SIGTERM restore terminal modes immediately and begin one supervised drain;
 persistent frontend and child handlers keep repeated signals graceful until the
 kernel child is reaped, after which a non-SIGINT terminating signal is replayed
 in the frontend. A parent-liveness watch remains the detached-kernel fallback.
-Timeout escalation is held while a durable `tick-started` fact remains open,
+The repository record carries constant-size, lease-holder-fenced tick telemetry:
+`beginRepoTick` opens the unsafe boundary, and `finishRepoTick` atomically closes
+it and appends selected tick facts. Successful unchanged ticks append nothing;
+queue transitions, counters, diagnostics, attention resets/retries, and failures
+retain their journal evidence. Buffered starts preserve actual `startedAt` for
+attention cooldowns; old starts use their envelope time. Liveness reads refresh
+the repository record even with an unchanged event cursor, merging matching-run
+completion samples with journal ticks. Heartbeat renewal cannot invent progress.
+The memory, SQLite, Postgres and remote adapters share this contract, including
+no mutation after lease expiry and no partial publication on validation failure.
+
+Timeout escalation is held while the matching repository tick observation is open
+(with historical `tick-started` journal fallback when no observation exists),
 because force-killing the ticket claim before build creation would not be
 recoverable. After a build child claims a takeover lease, it reduces one
 captured event prefix and appends transcriptless reclaimed `session.ended`
@@ -771,17 +801,24 @@ selected through the plugin ticket-source registry, the real filesystem and
 local-git adapters, the injected Claude and Codex CLI subprocess contracts,
 and the injected Pi CLI/RPC contract.
 Ticket assets (SPEC §7.1.3) are files attached to a ticket and kept in the
-BuildStore, never in the ticket source. `packages/core/src/store/ticket-assets.ts`
+ticket service for hosted tickets, independently of build storage, and in the
+BuildStore for other sources. `packages/core/src/store/ticket-assets.ts`
 holds the types, the limits, and the one validator every adapter calls;
 `packages/core/src/cli/ticket-assets.ts` holds the filesystem walk, the download
 writer, and the note builder; `ab ticket attach`, `asset get`, and `asset rm`
-live in `packages/core/src/cli/ticket.ts`. The only thing a ticket source sees is
-a note through `comment()`, so no source or plugin protocol changed.
+live in `packages/core/src/cli/ticket.ts`. The optional hosted source asset
+capability reuses RemoteBuildStore transport with the ticket URL and credential.
+Other sources retain the existing store path.
 A claim freezes the ticket's current assets into the build (SPEC §6.3):
 `build.created.assets` (and, when a spec is revised from the ticket,
 `spec.revised.assets`) record the pinned revisions, `state.pinnedAssets` in the
 reducer projects them, `getPinnedTicketAsset` reads them back by pinned revision,
 and `ab context` writes them under `.ab/assets/`.
+For hosted tickets, `store/ticket-asset-snapshots.ts` copies exact revisions
+into chunked immutable repository artifacts in the build store before pinning.
+Reads use explicit manifest/chunk revisions without a ticket connection. Old
+pins retain ticket-row reads; existing service attachments need no migration,
+and attachments in old local stores are not moved.
 
 Both `ab dispatch` and sessionless `ab ticket` load the repository's plugins
 before selecting their TicketSource; dispatch passes that one adapter instance
@@ -938,3 +975,48 @@ the shared `connection.ts` wire types, and Postgres `connections.ts`. Approval
 commits registry membership, a credential digest, and the outcome atomically.
 The web connection routes authenticate the existing Better Auth session and
 reuse the sign-in/consent layout; CLI polling uses a separate private capability.
+
+## Revision-checked ticket writes
+
+Every ticket read includes an opaque `revision`. Pass it as `expectedRevision`
+(on MCP/operator requests) or `--expected-revision <opaque>` on `ab ticket update`,
+`move`, `block` and `unblock`. A stale write fails without changing anything and
+reports the current revision. Omission preserves unguarded behavior. Blocker
+checks cover the entire batch. Dispatcher moves remain unguarded and change the
+revision. Sources without guarded writes, including Linear, refuse supplied
+revisions rather than ignoring them.
+
+`ab ticket edit <id>` opens `$VISUAL`, falling back to `$EDITOR`, using TOML
+frontmatter and a Markdown body. Only title, body and labels are editable;
+id, blockers, creation key and reference comments are read-only. It saves only
+changed fields with the opening revision. Unchanged or formatting-only edits
+write nothing. On conflict, invalid input or editor failure, the error names an
+absolute file path containing the edited text. Read the current ticket and
+reapply the intended changes before retrying; conflicts are never merged.
+
+File and Linear revisions fingerprint title, body, canonical label/blocker sets
+and state; reverting identical content restores its fingerprint. File checks
+re-read immediately before writing, with the existing no-lock race window.
+Direct file edits and state-directory moves change revisions. File comments
+change the body and revision; separate hosted comments do not. Hosted revisions
+are monotonic decimal bigint strings, and checks run under the same row lock
+and transaction as all requested changes. Hosted reads return a coherent
+snapshot of fields, blockers and revision.
+
+### Independent hosted ticket service
+
+`[tickets] url` selects hosted ticket transport independently of BuildStore selection;
+without it, tickets use the selected remote build store. Local builds require an
+explicit ticket URL. Project registration and ticket policy publication through
+`ab connect --tickets URL` work before dispatch. Policy is a durable per-registration
+record, outside BuildStore events/artifacts; legacy uploaded configuration remains
+a compatibility fallback. Hosted lifecycle defaults are triage/ready/doing/done.
+Independent harvest uses revocable, expiring, service-bound ticket grants with
+read/create runner authority and read-only child authority. Build state and harvest
+journals remain exclusively in the selected BuildStore.
+
+Hosted ticket detail reads expose complete, oldest-first structured comments in
+`ticket.comments`, preserving exact bodies. Scans do not fetch comments. Hosted
+HTTP clients opt in with `x-autobuild-ticket-comments: 1` so historical strict
+decoders retain compatible responses. File comments remain embedded in the body;
+Linear comment reads are unchanged.