Summary
Field report from the [Adopter] Weft project (#357; greenfield .NET 10 / Rust CRDT library, same adopter as #345/#346/#355/#360). Draining a follow-up backlog before an irreversible publish (7 open → 1) surfaced a consistent, load-bearing observation about what a registry entry is.
Of the seven entries, three were genuine unresolved work. All three rested on a premise that was false the moment it was checked — and none was false because the code had drifted under it. Each was false at the time it was written, and the falseness cost only a 30-second check to surface months later. This is an argument for a small change in how the framework frames follow-ups and where it places verification — plus a secondary, concrete extractor-fidelity bug.
This is a framing/ergonomics enhancement, not a correctness bug in existing commands.
What happened — three follow-ups, three false premises
-
A test to "replicate" that never existed. FU-017 read "replicate for the Loro shim the header↔binding parity test the yrs shim already has." The yrs test did not exist — what existed were two code comments (in the C# binding and the C header) asserting "a CI test validates these match." The line was aspirational. The follow-up author read a comment as fact; the follow-up inherited the falseness and added a hop of authority.
-
A gate against a reference that can't exist. FU-016 asked for a Loro determinism gate mirroring the yrs↔Yjs parity gate. yrs has an independent reference (Yjs); Loro has none — the npm package is a WASM build of the same Rust core, so the comparison is the crate against itself. Reasoning by symmetry; the analogy silently failed.
-
An optimization for a cost that wasn't there. FU-010 feared persist-before-broadcast would put I/O on the actor's hot path. Tracing the actual await chain showed the persistence call was already awaited on the receive loop — reordering added no I/O to any hot path. The follow-up encoded a slightly-stale mental model of the architecture, not the code as built.
Three distinct failure modes — a comment believed, an analogy over-trusted, a mental model gone stale — one shared shape: each premise was false at write time and cheap to falsify at read time.
The design observation
There are two moments a "verify the premise" rule could live: at write time or at read/execution time.
- Write time is the worst moment to verify. A follow-up is a note jotted while finishing something else — closing Charter N, attention on the current subsystem, glancing at a different one about to be left. Verifying means a full context switch away from the work being landed.
- Read time is the best moment to verify. When you act on the entry you are already inside that subsystem with the code open; checking the premise is a
grep / a file read / a traced call chain — seconds, and you've already paid the context-switch cost for other reasons.
The important reframe: a follow-up backlog is a speculative buffer. Its value is cheap capture so a signal isn't lost. Demanding verification at capture time would defeat that purpose (the rational response would be to stop writing follow-ups). So an under-verified entry is not an authoring defect — it is the expected epistemic status of anything in a speculative buffer. A follow-up is a dated hypothesis, and the only real bug is executing one without re-testing it.
The current registry framing works against this: entries are presented as a to-do list / instruction set / plan. Read as instructions, false premises become wasted Charters. Read as dated hypotheses to re-check at execution, they become cheap bets.
Proposal
Human prioritization stays out of the CLI, as with promote.
-
Frame entries as hypotheses; move verification to execution. In FOLLOW-UPS-BACKLOG-PATTERN.md and the CLI's own language, treat entries as dated, decaying hypotheses, not a plan. Make the discipline explicit: re-verify the premise when you promote/act, not at capture. Consider a lightweight affordance at execution time — a promote/act path that surfaces the entry's premise and prompts "is this still true? check it." Optionally an explicit premise: + verified-at: pair on the entry so the re-check has something to target and stamp.
-
(Secondary, concrete) Fix extractor title fidelity. followups drift --apply auto-appends from an AILOG ## Follow-ups section and takes the first line of the bullet as the title. When the bullet opens with a formatted sentence, the title becomes a truncated markdown fragment — three entries this session were literally titled e.g. "Stale comment in ci.yml:76-81 — two false claims, and…", cut mid-thought. A machine grabbing a line-fragment loses the nuance a hand title carries, and an entry whose title misrepresents it starts life already skewed — compounding the "read as instruction" hazard. Fix: extract the first sentence, or require a title field, or add a curation step.
Relation to existing issues
Context
This report was produced with assistance from generative AI tools (Claude Opus 4.8); responsibility for the content rests with the human author.
Summary
Field report from the [Adopter] Weft project (#357; greenfield .NET 10 / Rust CRDT library, same adopter as #345/#346/#355/#360). Draining a follow-up backlog before an irreversible publish (7 open → 1) surfaced a consistent, load-bearing observation about what a registry entry is.
Of the seven entries, three were genuine unresolved work. All three rested on a premise that was false the moment it was checked — and none was false because the code had drifted under it. Each was false at the time it was written, and the falseness cost only a 30-second check to surface months later. This is an argument for a small change in how the framework frames follow-ups and where it places verification — plus a secondary, concrete extractor-fidelity bug.
This is a framing/ergonomics enhancement, not a correctness bug in existing commands.
What happened — three follow-ups, three false premises
A test to "replicate" that never existed. FU-017 read "replicate for the Loro shim the header↔binding parity test the yrs shim already has." The yrs test did not exist — what existed were two code comments (in the C# binding and the C header) asserting "a CI test validates these match." The line was aspirational. The follow-up author read a comment as fact; the follow-up inherited the falseness and added a hop of authority.
A gate against a reference that can't exist. FU-016 asked for a Loro determinism gate mirroring the yrs↔Yjs parity gate. yrs has an independent reference (Yjs); Loro has none — the npm package is a WASM build of the same Rust core, so the comparison is the crate against itself. Reasoning by symmetry; the analogy silently failed.
An optimization for a cost that wasn't there. FU-010 feared persist-before-broadcast would put I/O on the actor's hot path. Tracing the actual
awaitchain showed the persistence call was already awaited on the receive loop — reordering added no I/O to any hot path. The follow-up encoded a slightly-stale mental model of the architecture, not the code as built.Three distinct failure modes — a comment believed, an analogy over-trusted, a mental model gone stale — one shared shape: each premise was false at write time and cheap to falsify at read time.
The design observation
There are two moments a "verify the premise" rule could live: at write time or at read/execution time.
grep/ a file read / a traced call chain — seconds, and you've already paid the context-switch cost for other reasons.The important reframe: a follow-up backlog is a speculative buffer. Its value is cheap capture so a signal isn't lost. Demanding verification at capture time would defeat that purpose (the rational response would be to stop writing follow-ups). So an under-verified entry is not an authoring defect — it is the expected epistemic status of anything in a speculative buffer. A follow-up is a dated hypothesis, and the only real bug is executing one without re-testing it.
The current registry framing works against this: entries are presented as a to-do list / instruction set / plan. Read as instructions, false premises become wasted Charters. Read as dated hypotheses to re-check at execution, they become cheap bets.
Proposal
Human prioritization stays out of the CLI, as with
promote.Frame entries as hypotheses; move verification to execution. In
FOLLOW-UPS-BACKLOG-PATTERN.mdand the CLI's own language, treat entries as dated, decaying hypotheses, not a plan. Make the discipline explicit: re-verify the premise when you promote/act, not at capture. Consider a lightweight affordance at execution time — apromote/act path that surfaces the entry's premise and prompts "is this still true? check it." Optionally an explicitpremise:+verified-at:pair on the entry so the re-check has something to target and stamp.(Secondary, concrete) Fix extractor title fidelity.
followups drift --applyauto-appends from an AILOG## Follow-upssection and takes the first line of the bullet as the title. When the bullet opens with a formatted sentence, the title becomes a truncated markdown fragment — three entries this session were literally titled e.g. "Stale comment inci.yml:76-81— two false claims, and…", cut mid-thought. A machine grabbing a line-fragment loses the nuance a hand title carries, and an entry whose title misrepresents it starts life already skewed — compounding the "read as instruction" hazard. Fix: extract the first sentence, or require a title field, or add a curation step.Relation to existing issues
driftextraction fidelity from AILOGs (this sharpens it with the title-fragment case).note/set-statusmutation verbs.Context
drift --apply.This report was produced with assistance from generative AI tools (Claude Opus 4.8); responsibility for the content rests with the human author.