fleet-floor's durable control plane — what the collector already does, and the two halves that are still missing

[dan-claude-bot]

Moved from #109, filed directly on the board by @codex-bot-andresmgsl on 2026-07-28 at danmt's request. Nothing is retracted or summarised away: the proposal is carried verbatim at the foot of this thread. It is here rather than on the board because only triage mints issues (AGENTS.md), and this one arrived without passing that door — and because, four days on, the code has answered part of it.

Why triage sent it back through this door

This is a good piece of design writing. The source-of-truth boundary section in particular — "SQLite is authoritative for accepted fleet-floor actions … the box remains authoritative for its actual runtime state" — is the sentence that stops a control plane becoming a fictional second fleet, and it is worth keeping whatever gets built. Four reasons it is a thread and not a board entry:

1. Half of it has already shipped, and nothing noticed

This is the load-bearing reason, and it is why minting children from the text as written would have been the expensive mistake.

The proposal's opening premise is that fleet-floor "pays for live truth through box exec" on the page-read path: "every refresh fans out to boxes, results arrive slowly, one unavailable box stretches the request." That is not what the collector does today. floor.py is already the background collector the proposal's scope section asks for:

#109 asks for	today, at 81687ad
"Move the existing box probes behind a collector that runs independently of page requests"	Fleet — "the telemetry snapshot, refreshed by one background thread"; loop() polls on an interval and page reads serve the snapshot
"Every API/UI view exposes freshness (observed_at)"	the snapshot carries generated, and the page renders staleness from it (test/stale.js)
"Bound probe concurrency and per-box timeouts; one wedged box does not stall the fleet"	PROBE_TIMEOUT_S=45, PING_TIMEOUT_S=5, ACTION_WORKERS=8, a single-flight _poll_lock that coalesces click bursts, and a separate ping tier so the fast signal is not queued behind a 45s evidence probe
"one unavailable box does not stall the rest"	regression-tested — test/concurrent-actions.py is the #44 guard, asserting peak concurrency across a wedged fleet

So acceptance criteria 1 and 3 — "loading the ordinary fleet dashboard performs no synchronous fan-out" and "a slow or unreachable box does not block the rest of the fleet from being displayed" — are already met by merged work. An epic whose first two criteria are green before anyone starts is an epic that will send its first builder to rebuild something that exists. This board has the lesson written down already, on #116: "a Blocked by declaration is a snapshot, and nothing re-validates it." A problem statement is a snapshot too.

2. What is actually left is real, unmet, and a different shape than the title

Stripping out what shipped leaves two genuinely open gaps, and they are not one piece of work:

• Durability. The snapshot is self.snapshot, in memory, and floor.py writes nothing to disk — every open() in the file is a read. Restart the collector and the fleet's entire observed history is gone; there is no last-known-good to show during an outage, and no separate record of the most recent failure. This is the proposal's "persist each box's last successful observation and its most recent failure separately", and it is the small half.
• The action ledger. Actions are synchronous today: no durable action ID, no lifecycle a second browser can reconstruct, no idempotency key, no per-box conflict lock, no fencing token. This is the large half, and it carries all of the proposal's genuinely hard parts (restart recovery, late-result fencing, indeterminate outcomes).

The first is small and buildable now. The second is not, and its cost is mostly in crew floor growing a second long-lived process — see Q2.

3. It organizes nothing, while claiming to

It has carried the epic label since 2026-07-28. Under LABELS.md an epic "organizes other issues via a dependency-ordered task list". Four days on it has zero children; its "Road" is a numbered list of work nobody has minted. That label is not true. And — this is the part worth recording — the epic label is why nobody caught it: the work-queue sweep's invariant exempts epic from the one-of-ready/claimed/blocked/post-merge check, so it never drew a needs-triage flag. #212 arrived on 2026-07-31 and was flagged in 39 seconds. #109 arrived on 2026-07-28 and was never flagged at all. An epic label on an untriaged issue is a hole in the door.

Struck by triage, 2026-08-01, against #109's label events. That paragraph accused the machinery of something the timeline refutes: #109 was flagged, in 13 seconds — needs-triage at 2026-07-28T15:10:43Z, thirteen seconds after it opened — and triage removed the flag itself 45 minutes later, at 15:55:23Z, one second after applying epic. The door held; triage opened it. What is true, and smaller, is in the correction below. It was written by reading the thread instead of the label events, which is the one thing TRIAGE.md says to read first.

4. Its own text defers the cut

"Follow-on issues should be cut from this epic after the boundaries are reviewed."

That review is this thread. The proposal is explicit that it is not yet a set of work orders, and triage agrees with it.

The questions whose answers let triage mint

Three, in the order their answers unblock work. @danmt — Q1 is the cheap one and yields a buildable issue on its own.

Q1 — durability alone, now?

Given that the collector exists and only its memory is volatile, the small half stands on its own: persist the snapshot so it survives a restart, keep last-success and last-failure apart, and serve a last-known-good with its observed_at during an outage. No action ledger, no locks, no worker, no lifecycle model.

sqlite3 is in the Python standard library, so this keeps the stdlib-only property crew floor advertises and README.md restates — that constraint is not a reason to avoid SQLite, and a flat JSON file would be the weaker choice for the same cost. Is that worth minting as one issue today, independent of everything below?

Q2 — does crew floor become a supervised service?

This is the question that sizes the large half, and the proposal does not name it.

Today crew floor is one process an operator runs. A durable action ledger needs a worker that outlives an HTTP request, and the proposal's recovery semantics ("worker/browser/API restarts do not lose accepted actions") only mean something if something restarts the worker. Two answers, very different bills:

• A worker thread inside floor.py — single writer, no new process, dies and restarts with the page server. Cheap, and honest as long as the docs say a stopped collector means stopped actions.
• A supervised daemon on the host — crew acquires a service-management story it does not have today, on a host whose only current contract is "python3 exists".

Which one is being asked for? The answer decides whether this is a fleet-floor change or a crew-platform change.

Q3 — which gate? (danmt's alone)

#163 (0.2.0) names #109 under "the console must show what a human needs", beside #125, #126 and #129. But a control plane is not a console feature — it is fleet-floor's read and write path, and the large half touches every mutation the console has. 0.1.0 is in its acceptance phase (#207) and 0.1.1 (#162) is the polish gate.

Prioritisation is yours. Q1's answer may make this moot for the small half — durability is cheap enough to ride 0.1.1 — while the ledger waits for a gate with room.

Where this sits on the board meanwhile

#163 already names it on the 0.2.0 road, and that reference stands — it now points here. #126 (a box's OS, health and process view) declared Blocked by #109; that declaration is being re-pointed, since it was waiting on the collector substrate that turns out to already exist.

Nothing on the board is blocked by this thread. #207, #162 and #163 are unaffected, and every ready issue continues.

---

The proposal, as filed on #109 — verbatim

Filed from the operator conversation at danmt's request. Epic — organizes follow-on issues; not pickable as one change.

Problem

fleet-floor currently pays for live truth through box exec.

That is tolerable for an operator command, but a poor read path for an application: every refresh fans out to boxes, results arrive slowly, one unavailable box stretches the request, and the UI has little durable state to explain the wait. Mutations have the sharper version of the same problem. An operator can click on, off, hire, or another conflicting action repeatedly while an earlier box exec is still running. The browser knows that it sent an HTTP request, but the system does not expose a durable answer to:

• Was the action accepted, queued, started, completed, failed, or timed out?
• Is another action allowed against this box right now?
• Did the command continue after the browser disconnected?
• Which result is authoritative if two conflicting commands overlap or finish out of order?
• What did the application know about the box, and how fresh was that knowledge?

This is a correctness and operability gap, not only a loading-state problem.

Direction

Introduce a deliberately small fleet control plane backed by SQLite.

box exec probes ─→ collector ─→ SQLite snapshots/projections ─→ read API ─→ UI
                                    ↑
UI ─→ action API ─→ action ledger + locks ─→ worker ─→ box exec ─→ result

box exec remains the mechanism for actions, installation, recovery, and detailed live diagnostics. It stops being the synchronous source for routine page reads. The application reads projections from an API backed by SQLite and reports their freshness.

A click creates a durable action and returns an action ID promptly. A worker performs the slow command, while the UI follows recorded state rather than holding one opaque request open.

requested → running → succeeded
                    ↘ failed
                    ↘ timed_out
                    ↘ cancelled

Scope

1. SQLite store and migrations

• One documented database location and one migration path.
• WAL mode, transactions, foreign keys, and a clear single-writer policy.
• Schema/version compatibility is explicit; startup never silently discards incompatible state.
• Backup/recovery expectations are documented. SQLite is a local file, not placed on a network filesystem.

The first useful model should stay small:

• boxes / snapshots: last observed state, observation time, probe result, and error/freshness metadata.
• actions: type, target, requester, idempotency key, lifecycle state, timestamps, timeout, result, and bounded output/error detail.
• locks: resource, owning action, expiry, and fencing/version token.
• projection tables needed by the dashboard; these are rebuildable views of durable observations and actions, not a second hand-maintained truth.

Names and normalization belong to the implementation issues; the invariant is that observations, commands, and their status survive an HTTP request or browser session.

2. Background collector and projections

• Move the existing box probes behind a collector that runs independently of page requests.
• Persist each box's last successful observation and its most recent failure separately, so an outage does not erase the last known state.
• Build dashboard projections in SQLite and serve them through a small read API.
• Every API/UI view exposes freshness (observed_at) and distinguishes current, stale, unknown, and unreachable.
• Bound probe concurrency and per-box timeouts; one wedged box does not stall the fleet.
• Collector restarts converge without inventing duplicate boxes or corrupting projections.

3. Durable action ledger and worker

• Mutation endpoints enqueue an action and return its ID instead of synchronously pretending the final state is known.
• A worker claims actions, records start/completion, enforces timeouts, and records bounded stdout/stderr or a reference to retained logs.
• Idempotency keys make retries and double-clicks safe.
• Worker/browser/API restarts do not lose accepted actions or misreport running work as success.
• Recovery semantics for an interrupted running action are explicit: retry only when safe, otherwise reconcile and surface an indeterminate/failed result.
• Box state changes only when observation confirms them; the UI may say “turning on” but must not claim “on” merely because the command was accepted.

4. Conflict locks

Locks are scoped to the affected resource, not a global “disable the whole app” switch:

• lifecycle actions (on, off, restart/delete if present) conflict per box;
• hire/upgrade and other engine mutations conflict per box;
• fleet-wide operations acquire a fleet lock or the relevant set of box locks using a defined order;
• unrelated boxes and read-only navigation remain usable;
• stale locks expire, but expiry alone does not prove the remote command stopped;
• fencing tokens prevent a late result from an expired worker overwriting a newer action;
• any operator override is deliberate, visible, and audited.

The API enforces conflicts. Disabled buttons are feedback, not the safety boundary.

5. Action-aware UI

• A successful click immediately shows that the action was accepted, with action ID/state and elapsed time.
• Conflicting controls are disabled for every client while the server-side lock is held.
• Refreshing or opening a second browser reconstructs the same action state from the API.
• Long-running, timed-out, failed, and indeterminate outcomes are distinct and actionable.
• The operator can inspect recent actions and bounded failure detail.
• Read-only parts of the app remain responsive while a mutation runs.

Source-of-truth boundary

• The box remains authoritative for its actual runtime state.
• SQLite is authoritative for accepted fleet-floor actions, delivery/attempt history, locks, and the latest observed projections.
• A projection is never presented without its observation time.
• box exec action results are evidence, not a substitute for subsequent state reconciliation.

This boundary keeps the database useful without allowing it to become a fictional second fleet.

Road

Follow-on issues should be cut from this epic after the boundaries are reviewed. A likely order is:

1. SQLite store, migrations, and repository interfaces.
2. Background box collector plus snapshot/projection read API; switch dashboard reads off synchronous box exec fan-out.
3. Durable action ledger and a single worker for one narrow action.
4. Per-resource conflict locks, idempotency, fencing, timeout, and restart recovery.
5. Move the remaining fleet-floor mutations onto the action model and add action-aware UI/history.
6. Drill restart, double-submit, conflicting-action, stale-data, wedged-box, and late-result cases.

Each step must remain deployable and testable; this epic does not authorize a big-bang rewrite.

Acceptance criteria

• Loading the ordinary fleet dashboard performs no synchronous fan-out to every box.
• The UI reads SQLite-backed projections through an API and displays observation freshness.
• A slow or unreachable box does not block the rest of the fleet from being displayed.
• Every control mutation has a durable action ID and observable lifecycle.
• Repeated submission of the same action is idempotent.
• Conflicting actions for one box cannot execute concurrently, including submissions from different browser sessions.
• A late result from an expired/older worker cannot overwrite the result or projection of a newer action.
• Browser, API, collector, and worker restarts have specified and tested recovery behavior.
• Failure and timeout never appear as success; accepted command state and observed box state remain distinct.
• Existing action authorization and safety checks remain server-side and are not weakened by disabled UI controls.
• SQLite corruption/incompatibility fails loudly and recoverably; migrations and backup expectations are documented.
• A drill covers double-clicks, on/off conflict, worker death, stale locks, late completion, a wedged box, and stale snapshot rendering.

Non-goals

• No message broker, distributed database, or multi-writer SQLite deployment.
• No requirement for WebSockets; polling or server-sent events are sufficient if they keep state legible.
• No claim of exactly-once remote execution. The design provides durable intent, idempotency where possible, fencing, and reconciliation.
• No removal of box exec; it remains the command and diagnostic channel.
• No optimistic declaration that a box changed state before it is observed.
• No centralization of GitHub writes or agent duties in this epic.

Later: centralize the GitHub transport

Once the SQLite collector, durable action model, locks, and projections are operating successfully, revisit crew's GitHub integration.

The same control-plane foundation could support one central GitHub collector that normalizes repository events into a durable event log and gives duties pull-based inboxes, acknowledgements, retries, leases, and replay. That may reduce duplicated polling, rate-limit pressure, credential variance, and coordination races across agents.

That is intentionally follow-on work, not hidden scope here. GitHub should remain authoritative for repository facts; a future transport would be authoritative for delivery, acknowledgement, leases, and cached projections. Centralize observation first and assess measured pain before deciding whether GitHub mutations should also move behind it.

[dan-claude-bot]

Correction — section 3 accused the machinery of something the label events refute

Found by re-reading /repos/heavy-duty/crew/issues/109/timeline rather than this thread. The claim was mine, it was wrong, and it was wrong in the way this doctrine specifically warns about: it was written from the issue's prose and comments instead of its label events. The paragraph is struck in the body above; here is what actually happened, and the smaller thing that is true.

What section 3 said

"the work-queue sweep's invariant exempts epic … so it never drew a needs-triage flag. #212 arrived on 2026-07-31 and was flagged in 39 seconds. #109 arrived on 2026-07-28 and was never flagged at all. An epic label on an untriaged issue is a hole in the door."

What #109's label events say

2026-07-28T15:10:30Z	opened by @codex-bot-andresmgsl
2026-07-28T15:10:43Z	needs-triage by github-actions[bot] — 13 seconds later
2026-07-28T15:55:22Z	epic by dan-claude-bot
2026-07-28T15:55:23Z	needs-triage removed by dan-claude-bot, one second after the line above

The door held, and it held three times faster than #212's 39 seconds. Triage opened it — a session applied epic to a stray and cleared its own flag in the same edit, then never returned. The four days are triage's, not the sweep's, and the comparison that made the paragraph persuasive was measuring the machine against itself.

The same correction lands on #236, which cited this as "the second instance found today of the same hole." It is not an instance at all: #128 was minted by triage, at 2026-07-28T21:45:40Z, carried blocked three seconds later and epic ten minutes after that. No flag was ever owed on it, and none was missed.

What is actually true, stated smaller

The mechanism, read at the pin crew consumes (labels.yml@0.4.0, actions/issueflow-reconcile/issueflow-reconcile.sh), is two functions:

• reconcile_opened_issue runs on the issues: opened event only. A non-triage author with no needs-triage gets the flag added and epic plus every queue label stripped — the taxonomy already refuses to let a stray call itself an epic at the door.
• queue_decision is the standing check, over every open issue, hourly and on subscribed events. It counts epic as a satisfying category, so an epic issue is KEEP forever.

So the residual property is real but narrow: epic is the one queue category the standing sweep cannot re-derive, which means a triage error made inside it is not machine-recoverable. That is a property of the design rather than a defect in it. LABELS.md's rule is that intent labels are hand-set and the reconciler never guesses intent, and the opened-path already encodes the judgement that a non-triage epic is illegitimate. A sweep that second-guessed a hand-set epic would be guessing intent, which is the thing it is built not to do.

Nothing is owed to heavy-duty/ceremony. I was about to open a discussion there, and the timeline is the reason I did not. The finding this thread should carry instead is one sentence about triage's own conduct: do not label a stray epic — it is the one label that makes clearing needs-triage irreversible by machine. That is now recorded here and on #236, and it needs no fix in any repo.

Nothing else in this thread changes. The reading of what already shipped in floor.py, the durability/ledger split, and the three questions to @danmt all stand — section 3 was an argument about why nobody caught it, never about what is left to build.

[dan-claude-bot]

Correction — Q3 offers durability a seat on 0.1.1, and since yesterday's renumber that names a cut which happens tomorrow morning

Two sentences in this thread are stale, both in Q3, and both in the direction that misleads: they make the cheap half of this work sound placeable in a window that is now hours from closing. The technical half of the thread was re-verified at main's current head and is unchanged — that part is below the correction, because it is the part that decides anything.

What Q3 says:

"0.1.0 is in its acceptance phase (#207) and 0.1.1 (#162) is the polish gate."

"Q1's answer may make this moot for the small half — durability is cheap enough to ride 0.1.1."

What is true. Both were written on 2026-08-01 before the renumber landed on #162, and re-read from the board rather than from this thread:

0.1.1	#280 — a list of its own, cut from main tomorrow morning, 2026-08-03. Not #162, and not a polish gate: it is the acceptance-wave fixes that have already landed.
0.1.2	#162 — the polish gate, retitled in the same ruling. It holds twenty open issues.
0.2.0	#163, unchanged — and it is where this thread is already named.
#207	back to its original scope, the 0.1.0 acceptance run; it no longer owns the 0.1.1 cut, which moved to #280 with the list.

So the honest option set for Q3 today is #162 (0.1.2) or #163 (0.2.0). 0.1.1 is not an available answer: #280 takes whatever has landed by the cut and everything unlanded reverts to #162 by its own standing rule, so an issue minted from this thread today could not reach it. That is the third correction of this class in two days — #279 took the same one this morning, and the welcome thread took it in place — and it is worth making here because Q3 is the one question whose answer is a gate name.

The load-bearing half re-verified, because a stale problem statement is what put this thread here

This thread exists because #109's premise had gone stale under it — half the epic had shipped and nobody re-read it. So the claim this thread rests its own split on was re-checked rather than assumed, at a17b962, main's head at the time of writing:

"The snapshot is self.snapshot, in memory, and floor.py writes nothing to disk — every open() in the file is a read."

Still exactly true. Five open() sites, all reads (the floor envelope, the roster, the probe, an agent conf, the index blob); the only writes in the file are sys.stdout and the HTTP response socket. No sqlite3, no json.dump, no write_text. Restart the collector and the fleet's observed history is still gone.

So the split this thread proposed is intact and both halves are still unbuilt — durability the small half, the action ledger the large one — and Q1 is still the cheap question that yields a buildable issue on its own.

One thing did move on the board, and it lands beside Q3 rather than on Q1 or Q2

#291 was minted 2026-08-02 at danmt's direction (blocked on #163): a droid is a chair with a CPU — one instance, one room, the room being that instance's details page. It is a read-path change to the same surface these projections would eventually feed, and its own open list asks whether its floor-only half justifies an 0.1.2 slice.

It answers neither Q1 nor Q2 — durability and an action ledger are orthogonal to how a page is composed — but it means the fleet-floor surface now has two candidate claims on the same window, and whoever answers Q3 should know that rather than discover it. Recorded, not absorbed.

Outcome unchanged: ask, waiting on @danmt, with Q1 still the cheap one. Only Q3's gate names move, and they move to #162 or #163.

Nothing is waiting on this thread. Re-checked across every open blocked body rather than inferred from the cross-reference list: no open issue's parsed blocker set names it, and #125, which cites it, declares Blocked by #123.

Triage, 2026-08-02.

[dan-claude-bot]

Re-verified after four fleet-floor merges, and one inference to head off before someone makes it

Two things since yesterday's comment, one mechanical and one that arrives with this morning's corpus. The outcome does not move: ask, waiting on @danmt, Q1 still the cheap one.

1. The load-bearing claim, re-checked at main's head rather than assumed

Yesterday's verification was at a17b962. Four fleet-floor PRs have merged since — #305, #307, #309, #310 — and this thread exists because #109's premise went stale under it, so the claim was re-run rather than carried forward. At 1782445:

Still exactly true. Five open() sites (the floor envelope, the roster, the probe, an agent conf, the index blob) — all reads. The only writes in the file are sys.stdout and the HTTP response socket. No sqlite3, no json.dump to a path, no write_text. Restart the collector and the fleet's observed history is still gone, after two days of active work on this exact file.

2. The fleet lost a history this morning — and Q1's mechanism would not have saved it

Worth stating plainly, because the opposite reading is the natural one and it is wrong.

The operator hand-exported every box's ~/duty to a public repository at 2026-08-03T10:18:04Z (dan-claude-bot/crew-corpus) — 680 MB across eight boxes, ahead of the 0.1.1 re-mint that would have destroyed it. Two working days of session records, rescued by hand against a deadline. That looks like this thread's argument winning, and someone will cite it here as evidence for Q1.

It is not. The corpus is each box's duty.log, its .seen-* ledgers and one transcript per session — records the collector has never held. fleet-floor's snapshot is a poll of box state; it carries no session-level history at all, so a durable snapshot store built to Q1's spec would have persisted none of what was rescued this morning. Q1's case is unchanged and rests where it always did: a restart currently loses the observed history and leaves no last-known-good to show during an outage.

What the two do share is a class, and that is the honest version of the argument: this fleet keeps its history in volatile places and finds out at the worst moment. Two instances now, in two different substrates, three days apart. That is a reason to answer Q1 rather than evidence for a particular answer — and it says nothing at all about Q2, which is what actually sizes the work.

Unchanged

Q1, Q2 and Q3 are open and unanswered; Q3's honest gate set is still #162 (0.1.2) or #163 (0.2.0), and 0.1.1 is still not an available answer — #280 cuts it from main today, which is the deadline yesterday's correction described as hours away.

Nothing is waiting on this thread, and no open issue's parsed blocker set names it.

Triage, 2026-08-03.

[dan-claude-bot]

One word in my comment above is now false — the corpus is private, not public — and the claim it was arguing for is unchanged

This morning's comment called dan-claude-bot/crew-corpus "a public repository". It went private at 2026-08-03T12:10:11Z at @danmt's direction (recorded on #290), deliberately held until after #290's report merged so no reviewer verified its box figures against a 404. Access is now by request through @danmt, and the operator retains the original tarballs on dev-server-1. Correcting it here because a reader who followed that link to test the argument would meet a 404 and conclude the evidence was withdrawn.

The argument is untouched, and the correction slightly sharpens it. The point was that the corpus is not evidence for Q1 — it is each box's duty.log, .seen-* ledgers and session transcripts, records the collector has never held, so a durable snapshot store built to Q1's spec would have persisted none of what was rescued. That remains true whatever the repository's visibility. What the two share is a class: this fleet keeps its history in volatile places and finds out at the worst moment. Private-but-preserved is not lost, so that class now has one rescued instance rather than one lost one — which is a reason to answer Q1, not evidence for a particular answer, exactly as stated.

For anyone following the citation: the public artifact is postmortems/2026-08-01-to-2026-08-02-fleet-run.md on main (525a041), merged 12:08:44Z. Its board half is reproducible with no corpus access at all; its box half names the pinned corpus commit for each figure.

The load-bearing claim, re-checked at main's head rather than carried forward

This thread exists because #109's premise went stale under it, so the claim it rests on is re-run at each write rather than assumed. main has moved again since this morning's check at 1782445 — at 525a041:

Still exactly true. Five open() sites — the floor envelope, the roster, the probe, an agent conf, the index blob — all reads. The only writes are sys.stdout and the HTTP response socket. No sqlite3, no json.dump to a path, no write_text. Restart the collector and the fleet's observed history is still gone.

One thing worth knowing before Q3 is answered, because it has a clock on it

Q3 is the which gate question, and its honest option set is still #162 (0.1.2) or #163 (0.2.0) — 0.1.1 is not available, and #280 cuts it from main today. What is new is that #162 is under an open ruling ask as of 2026-08-03T12:21:08Z — re-read from that issue's label events, not from a thread: needs-ruling applied then, carrying a proposed 0.1.2 re-cut ranked off the merged report above. So one of Q3's two options is, at this moment, having its contents and its window decided by @danmt. An answer of "#162" to Q3 would land inside that ruling rather than after it; an answer of "#163" is unaffected. Recorded so the timing is visible, not to press for either.

Outcome unchanged: ask, waiting on @danmt, and Q1 — durability alone, now — is still the cheap one that yields a buildable issue on its own.

Nothing is waiting on this thread, and no open issue's parsed blocker set names it.

Triage, 2026-08-03.

[dan-claude-bot]

Q3's option set is void — and the roadmap has since put a better answer on the board than either option this thread offered

My comment at 12:36Z said Q3's honest option set was "#162 (0.1.2) or #163 (0.2.0)" and that #162 was under an open ruling ask. Re-read from #162's timeline rather than from this thread: needs-ruling was removed at 17:15:21Z and the issue closed at 16:23:53Z — the ruling closed out, and 0.1.2's working surface and declarations anchor is now #346. Re-measured at this write with blockers.jq's own clause parse over all 22 open blocked bodies: 22 name #346, none names #162. So one of Q3's two options no longer exists as a gate anyone can be placed on.

The better answer: this thread's subject is now a release, one arc wide

#328 — 0.1.4 — collector + database: evidence survives the box — was minted 2026-08-03 at @danmt's direction, and it is this thread's large question at fleet scope:

"One aggregation store on the crew server pulling every box's duty/hygiene/notify logs and 0.1.3's telemetry on a cadence, so a stopped box's history is queryable and postmortems become queries instead of expeditions. […] Keep it boring: SQLite plus a puller; the floor reads it."

Its to-mint list carries the puller ("host-side, per-box, cadence + on-demand"), the store and its schema, and — the line that matters most here — "the floor and crew report read from the store, not from live boxes; off boxes stay reportable." #123 was carried onto it in the 15:54Z hygiene pass as "the collector's first consumer".

So Q3's honest option set today is #328 (0.1.4) or #163 (0.2.0), and #328 is the one that names the deliverable rather than the surface.

What that does to Q1 — it does not answer it, it re-shapes it

Q1 asked whether fleet-floor's own snapshot durability is worth minting as one small issue, now, independent of the ledger. #328 answers a strictly larger question from the other side: a host-side store the floor reads instead of live boxes. Two stores, one of them per-process and one of them fleet-wide, is the duplication this thread was moved off the board for in the first place — "building this first would mean building a worse version of it."

So the question to carry into 0.1.4's init, in place of Q1 as written: is floor-local durability still worth building once the floor reads a host-side store, or is it the same durability arriving from the other side? The honest answer may be that the small half stops existing as separate work — which would be this thread doing its job, not losing it. What is not answered either way is the outage case Q1 names: a last-known-good with its observed_at while a box is unreachable is a property of whatever the floor reads, wherever it lives.

And Q2 is untouched but no longer hypothetical. Does crew floor become a supervised service? #328's puller is exactly the long-lived, out-of-request process Q2 sizes — so the supervision story arrives with 0.1.4 whether or not anyone decides it on this thread. Better to decide it there deliberately than to inherit it.

The load-bearing claim, re-checked at main's head rather than carried forward

This thread exists because #109's premise went stale under it, so the claim is re-run at every write. At f3ecd3c, twenty-six commits and six merges past the last check at 525a041, none of them touching this file:

Still exactly true. Five open() sites — the floor envelope, the roster, the probe, an agent conf, the index blob — all reads. No sqlite3, no json.dump to a path, no write_text; the only writes are sys.stdout and the HTTP response socket. Restart the collector and the fleet's observed history is still gone.

Outcome unchanged: ask, waiting on @danmt

Q1 is still the cheap one, in its re-shaped form; Q2 is unchanged and now has a date attached to it; Q3's answer is a placement between #328 and #163. #163 still names this thread under its requirement 5, and that reference stands.

Nothing is waiting on this thread — no open issue's parsed blocker set names it.

Triage, 2026-08-03.

[dan-claude-bot]

Five fleet-floor merges later the load-bearing claim still holds — and Q3's two options are unchanged in membership and much closer in distance

First comment here since 2026-08-03 18:07Z. This thread exists because #109's premise went stale under it, so the claim is re-run at every write rather than carried forward.

1. Re-verified at main's head, across the busiest four days this file has had

Last checked at f3ecd3c. Five fleet-floor PRs have merged since — #368, #385, #389, #392, #395 — several of them landing in this file. At f5bd61c, 1,609 lines:

Still exactly true. Five open() sites — the floor envelope, the roster, the probe, an agent conf, the index blob — all reads. No sqlite3, no json.dump to a path, no write_text; the only writes are sys.stdout and the HTTP response socket. Restart the collector and the fleet's observed history is still gone.

That is worth more than a repeat: four days of active work on this exact file, including a new probe field rendered end to end, and not one byte of it persists. The durability gap is not being closed incidentally by the work that is happening.

2. One merge is this thread's own discipline arriving from the other side

#385 put the engine-manifest divergence verdict on the console by adding one field to the probe that already runs — probe.sh emits integrity, floor.py carries it into the box record, app.js renders it. No new box round trip, no new process.

That is the shape this thread's split predicted: new facts ride the collector that already exists, and only durability and the action ledger need anything new. Nothing in it touches either half.

3. What moved for Q3, and it is distance rather than membership

Q3's honest option set is unchanged — #328 (0.1.4) or #163 (0.2.0) — and #328 is still the one that names the deliverable rather than the surface.

What changed is that it is no longer an abstract placement. 0.1.2 is at its cut: #400 is claimed with PR #401 open in draft, and #346 is still open. The chain then opens #327 (0.1.3) and #328 immediately after it — so #328 is two windows out, by hand, at a release-init that mints from that epic's to-mint list.

The consequence for Q1, in its re-shaped form: is floor-local durability still worth building once the floor reads a host-side store? — is a question 0.1.4's init will have to answer whether or not it is answered here first. Answering it here is cheaper, because the init reads this thread; discovering it there means designing the boundary while minting against it.

Q2 is untouched and its date has closed in the same way. Does crew floor become a supervised service? #328's puller is exactly the long-lived out-of-request process Q2 sizes, and it now arrives two windows out.

4. The census in my last comment is void

It read "re-derived at this write with blockers.jq's own clause parse over all 22 open blocked bodies: every one names #346." That described the window at its widest.

Board at this write: 31 open — 19 epic, 6 post-merge, 3 blocked, 2 claimed, 1 ready (19+6+3+2+1 = 31), zero needs-triage, attention, stale and offsite, two open PRs (#401 draft, #410 at state:needs-human). Blocker parse over every open blocked body: #406 → {#402, #403}, #408 → {#406}, #411 → {#408}; union {#402, #403, #406, #408}, none of them this thread. One needs-ruling stands on the board — on #400 since 2026-08-07T21:32:17Z, the release cut's drill-sequencing ask — and it names nothing here.

Outcome unchanged: ask, waiting on @danmt

Q1 in its re-shaped form is still the cheap one; Q2 is unchanged and now dated; Q3 is a placement between #328 and #163. Nothing is waiting on this thread.

And this ask gets the return date its siblings carry. No needs-ruling label is owed here, so no rung of the ruling ladder has a clock to sit on; the 7-day nudge applies, and absent real activity triage returns on 2026-08-14 — the discipline #317 holds for 2026-08-10 and #338 and #351 for 2026-08-11.

Triage, 2026-08-07.

[dan-claude-bot]

The load-bearing claim holds at a237f42 — and the two halves this thread is named for got a record shape, two retention regimes and, for the drain, a window

One delta since my comment of 2026-08-07 21:42Z. The claim is re-run first rather than carried forward, which is this thread's own rule — it exists because #109's premise went stale underneath it.

1. Re-verified at main's head

At a237f42, floor.py is 1,609 lines — the same length as at the last check. Five open() sites and all five are reads: the floor envelope (:56), the roster (:303), the probe (:573), an agent conf (:891), the index blob (:1485) — four with no mode argument, one "rb". Zero sqlite3, zero json.dump(, zero write_text.

Still exactly true: restart the collector and the fleet's observed history is gone.

2. The durable half got specified this morning — specified, not built

The boundary annotation at 10:52Z ruled 0.1.3's emission contract, which is most of what #328's store inherits:

• Everything is emitted structured, as a requirement on 0.1.3 rather than a request from 0.1.4 — versioned JSON on stdout for the probe, append-only JSON lines at a known box-local path for events. The purpose is stated: "0.1.4 ingests rather than parses." No parser reverse-engineering a schema out of prose log lines, because 0.1.4 — collector + database: evidence survives the box #328's schema is declared to be 0.1.10's transport data model and "a schema derived from formatting accidents propagates four windows forward."
• Two retention regimes, not one — machine readings in a rolling window that prunes, the event corpus append-only and kept, "aligned on box id and timestamp so they join, rather than one policy serving two needs badly."
• Records self-attribute — box identity and session id in the record, never implied by which file it came from — with ingest idempotent on those ids, so at-least-once draining is safe and a range can be re-read without duplicating rows.

This thread has asked what the durable half actually is since it opened. That is the answer, at the level a builder executes, and it landed as a constraint on the window before the one that builds the store — the only ordering in which it is cheap.

3. The drain — the hardest half — is on #328's list and has a later window

#328's to-mint list now carries it in as many words: "The drain is triggered by teardown, not by a clock alone. A cadence-only puller cannot make this epic's own guarantee once boxes are ephemeral […] Teardown drains before the box goes; the cadence keeps its role for the long-running case."

And it was carried onward the same morning to #442 (0.2.5 — ephemeral boxes), minted 11:16Z at @danmt's direction, as one of four conditions "correct as built for long-running boxes, and unsatisfiable the day a box stops outliving the interval."

Read against this thread's Q3, that is an answer neither of its options offered. Q3 asked which window the durable control plane lands in. It is not one landing: the record shape is 0.1.3, the store is 0.1.4, and the guarantee that store promises — evidence survives the box — is not actually complete until 0.2.5, because until then a box destroyed between polls still takes its undrained events with it and box → host is blocked so nothing can push.

4. One thing held deliberately still

No third window. If normalising the existing logs into rows proves larger than expected it is "a member of 0.1.4, not a window of its own" — 0.1.5, 0.1.6 and 0.1.10 are already cross-referenced by number, and #328 alone names its schema as 0.1.10's data model. Recorded here because a thread about a store whose scope keeps widening is precisely where a third window gets proposed.

5. Outcome

Answered; this thread mints nothing and stays open on its claim. Its subject is now four windows wide with every part named and owned. The claim in §1 is re-run at every write and still holds; the day floor.py grows a write, this thread's reason for existing changes — and that is when it converges, not before.

Triage 2026-08-09 12:3xZ.

[dan-claude-bot]

The first of the three landings Q3's answer named is done — the record shape is on main

Triage 2026-09-01, re-measured at main 70bd7d4.

Dateless, correctly — the wake is an event, and it fired unwatched. Third such thread served today for that reason, and the pattern is recorded on each rather than in one place nobody reads.

Q3's answer was "not one landing, but three". The first has landed

My comment of 2026-08-09 resolved Q3 — which window the durable control plane lands in — into something neither of its options offered: the record shape is 0.1.3, the store is 0.1.4, and the guarantee evidence survives the box is not complete until 0.2.5, because until then a box destroyed between polls takes its undrained events with it and box → host is blocked.

Measured against that three-part answer at this write:

part	window	state
record shape	0.1.3 — #327	landed. shared/bin/vitals.sh and shared/lib/common/tick-health.sh exist; the session record carries cost_usd= and sid=. #483, #484, #475, #485, #538 all CLOSED
store	0.1.4 — #328	open, epic + release, window not opened
guarantee	0.2.5 — #442	open, epic + release, window not opened

The emission contract is worth re-checking rather than assuming, and it half holds

The boundary annotation made structured emission "a requirement on 0.1.3 rather than a request from 0.1.4" — versioned JSON on stdout for the probe, append-only JSON lines at a known box-local path for events — with the stated purpose that "0.1.4 ingests rather than parses" and the stated hazard that "a schema derived from formatting accidents propagates four windows forward."

The probe half is built. The append-only JSON-lines event path is the half I could not confirm: grepping the engine at 70bd7d4 for a JSON-lines emitter turns up shared/lib/duty-reaper.sh and nothing that looks like the events path the annotation describes — the session record is still a SESSION END line with key=value fields, now including cost_usd= and sid=, which is a formatted log line rather than a JSON object.

I am stating that as a measurement I took and not as a defect I am asserting. I did not read every consumer, and the annotation's requirement may be satisfied somewhere I did not look or may have been deliberately re-scoped inside the wave. But it is exactly the thing 0.1.4's init has to check before it builds an ingester, because the annotation's own hazard sentence is about precisely this: an ingester written against key=value log lines is the schema-from-formatting-accidents case, and it propagates forward from there.

Outcome: answered, and the next check is 0.1.4's init

Nothing is minted by this comment and no label moves. No ask for @danmt, and so still no return date.

Wake condition, re-stated so it is checkable rather than implicit: this thread wakes when 0.1.4's window opens. The one thing to carry into that init, so it is not re-derived: verify the append-only JSON-lines event path exists before designing the store against it — if what landed in 0.1.3 is a formatted log line rather than structured events, that is a 0.1.3 gap discovered at 0.1.4's door, and it is much cheaper to find it at the init than inside the ingester.

Triage, 2026-09-01.