Filed from the pepper seat, following mos-dt's fw-wake-digest-snapshot-lag finding (SSOT: jarvis-brain data/tasks/work.json).
Problem (measured, live)
A digest's ACTIONABLE/ORIENTATION locator carries observed_hash (content hash) + emit_ts, but nothing that DATES the snapshot. Live measurement (mos-dt): digest seq 56's observed_hash matched board revision 95c38cd30 (04:45:45); the next revision d4cf1aff1 (04:48:55) landed ~5s BEFORE the digest was delivered and introduced a FLEET STOP block — the digest read as "(none) actionable" while the board already said otherwise. The fast path cannot tell a fresh snapshot from a stale one without a tool call.
Why the fix is NOT operator-adapter-only
The dragon-lin adapter already knows the snapshot commit at observe time (it rev-parses origin/main:<path>), but the W4 adapter contract has exactly one output channel — stdout — and EVERYTHING on stdout is hashed by the detector's delta gate. Embedding the tip commit SHA in the descriptor would advance observed_hash on every unrelated push to the repo → a spurious delta wake for every watched file. The metadata needs an out-of-band channel.
Proposed fix (additive, backward-compatible)
detector.sh (A1): invoke the source adapter with fd 3 redirected to a temp file. The adapter MAY write a single JSON object there: {"snapshot_sha": "<git commit sha>", "snapshot_ts": <epoch>}. Validate strictly (sha ^[0-9a-f]{7,64}$, ts integer); malformed metadata is dropped with a LOUD stderr diagnostic but never gates/fails the poll (metadata is advisory — the wake obligation never depends on it). Valid fields merge into the enqueue locators. Old adapters write nothing to fd 3 → empty file → no fields → byte-identical behavior.
digest.sh (A3):_locator_line renders snapshot_sha= / snapshot_ts= (scrubbed) alongside observed_hash=; when snapshot_sha + path are present the one-call re-verify hint upgrades to git show <snapshot_sha>:<path> (snapshot_sha IS a commit sha, unlike observed_hash, so it may feed the git hint).
Tests: detector — metadata captured into locators; malformed metadata dropped loudly without failing the poll; no-fd3-write → no fields. digest — snapshot fields render; reverify hint upgrade.
manifest.txt: 0.6.12 entry. Watch-list schema untouched ([1,1] unchanged — this is adapter-contract + locator vocabulary, not watch-list config).
With snapshot_ts + the existing emit_ts, snapshot age becomes local arithmetic and the digest-lag class above is self-evident to the consumer with zero round trips.
Operator side (not this repo): dragon-lin's source-adapter.sh gains a guarded fd-3 write (git rev-parse origin/main + committer ts for repo sources; mtime for local-file sources).
Filed from the pepper seat, following mos-dt's fw-wake-digest-snapshot-lag finding (SSOT: jarvis-brain data/tasks/work.json).
## Problem (measured, live)
A digest's ACTIONABLE/ORIENTATION locator carries `observed_hash` (content hash) + `emit_ts`, but nothing that DATES the snapshot. Live measurement (mos-dt): digest seq 56's observed_hash matched board revision 95c38cd30 (04:45:45); the next revision d4cf1aff1 (04:48:55) landed ~5s BEFORE the digest was delivered and introduced a FLEET STOP block — the digest read as "(none) actionable" while the board already said otherwise. The fast path cannot tell a fresh snapshot from a stale one without a tool call.
## Why the fix is NOT operator-adapter-only
The dragon-lin adapter already knows the snapshot commit at observe time (it rev-parses `origin/main:<path>`), but the W4 adapter contract has exactly one output channel — stdout — and EVERYTHING on stdout is hashed by the detector's delta gate. Embedding the tip commit SHA in the descriptor would advance observed_hash on every unrelated push to the repo → a spurious delta wake for every watched file. The metadata needs an out-of-band channel.
## Proposed fix (additive, backward-compatible)
1. **detector.sh (A1):** invoke the source adapter with **fd 3** redirected to a temp file. The adapter MAY write a single JSON object there: `{"snapshot_sha": "<git commit sha>", "snapshot_ts": <epoch>}`. Validate strictly (sha `^[0-9a-f]{7,64}$`, ts integer); malformed metadata is dropped with a LOUD stderr diagnostic but never gates/fails the poll (metadata is advisory — the wake obligation never depends on it). Valid fields merge into the enqueue locators. Old adapters write nothing to fd 3 → empty file → no fields → byte-identical behavior.
2. **digest.sh (A3):** `_locator_line` renders `snapshot_sha=` / `snapshot_ts=` (scrubbed) alongside `observed_hash=`; when `snapshot_sha` + `path` are present the one-call re-verify hint upgrades to `git show <snapshot_sha>:<path>` (snapshot_sha IS a commit sha, unlike observed_hash, so it may feed the git hint).
3. **Tests:** detector — metadata captured into locators; malformed metadata dropped loudly without failing the poll; no-fd3-write → no fields. digest — snapshot fields render; reverify hint upgrade.
4. **manifest.txt:** 0.6.12 entry. Watch-list schema untouched ([1,1] unchanged — this is adapter-contract + locator vocabulary, not watch-list config).
With `snapshot_ts` + the existing `emit_ts`, snapshot age becomes local arithmetic and the digest-lag class above is self-evident to the consumer with zero round trips.
Operator side (not this repo): dragon-lin's source-adapter.sh gains a guarded fd-3 write (`git rev-parse origin/main` + committer ts for repo sources; mtime for local-file sources).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Filed from the pepper seat, following mos-dt's fw-wake-digest-snapshot-lag finding (SSOT: jarvis-brain data/tasks/work.json).
Problem (measured, live)
A digest's ACTIONABLE/ORIENTATION locator carries
observed_hash(content hash) +emit_ts, but nothing that DATES the snapshot. Live measurement (mos-dt): digest seq 56's observed_hash matched board revision 95c38cd30 (04:45:45); the next revision d4cf1aff1 (04:48:55) landed ~5s BEFORE the digest was delivered and introduced a FLEET STOP block — the digest read as "(none) actionable" while the board already said otherwise. The fast path cannot tell a fresh snapshot from a stale one without a tool call.Why the fix is NOT operator-adapter-only
The dragon-lin adapter already knows the snapshot commit at observe time (it rev-parses
origin/main:<path>), but the W4 adapter contract has exactly one output channel — stdout — and EVERYTHING on stdout is hashed by the detector's delta gate. Embedding the tip commit SHA in the descriptor would advance observed_hash on every unrelated push to the repo → a spurious delta wake for every watched file. The metadata needs an out-of-band channel.Proposed fix (additive, backward-compatible)
{"snapshot_sha": "<git commit sha>", "snapshot_ts": <epoch>}. Validate strictly (sha^[0-9a-f]{7,64}$, ts integer); malformed metadata is dropped with a LOUD stderr diagnostic but never gates/fails the poll (metadata is advisory — the wake obligation never depends on it). Valid fields merge into the enqueue locators. Old adapters write nothing to fd 3 → empty file → no fields → byte-identical behavior._locator_linerenderssnapshot_sha=/snapshot_ts=(scrubbed) alongsideobserved_hash=; whensnapshot_sha+pathare present the one-call re-verify hint upgrades togit show <snapshot_sha>:<path>(snapshot_sha IS a commit sha, unlike observed_hash, so it may feed the git hint).With
snapshot_ts+ the existingemit_ts, snapshot age becomes local arithmetic and the digest-lag class above is self-evident to the consumer with zero round trips.Operator side (not this repo): dragon-lin's source-adapter.sh gains a guarded fd-3 write (
git rev-parse origin/main+ committer ts for repo sources; mtime for local-file sources).