docs(claude): re-derive the gate table's callers against bh 0.15.0, and replace the citation form that failed (phaze-g9cus) - #538
Merged
Conversation
…haze-g9cus)
The "Boundary -> recipe" table cited bh 0.14.0 and seven `work.py` line
numbers. bh 0.15.0 split that module, leaving `work.py` at 1777 lines, so all
seven numbers were past EOF: `sed -n "${n}p"` returned empty for every one.
They did not point at the wrong code, they dangled -- unreadable and
uncheckable, with nothing about the table's appearance changed.
Re-derive all seven by reading each new call site rather than mapping numbers
forward. No boundary's resolved recipe changed; the BLOCK -> COMMAND mapping
was re-executed against the live config on 0.15.0 and reproduces exactly.
Replace the citation form rather than refreshing the digits: `module.py::symbol`
plus the resolver call as written, the bh version in the table header, and a
command that regenerates the whole boundary population. A bare line number is a
pointer with no redundancy, so nothing can check it -- this file's
ADR-numbering argument one level down.
Also:
- three sharpenings: merge/merge-main is a POST-land re-test with rollback,
postland is molecule-only, union can only fire on a per-bead merge
- group-merge sits outside what the five pinned keys can cover; the schema
accepts an inert `batch:`/`check:` key, and an ad-hoc batch lands on main
past `merge-main`. Escalated as hq-f9w
- `work.validate_precheck` no longer exists; `work.always_run` documented
- ledger fields corrected to seven plus a conditional eighth, with the
two-of-seven-are-the-key framing
- a `merge-main` bounce that ran zero tests is an unmeasured gate, not a red one
- the fixed-enumeration trap generalised alongside the line-number one
The two dated measurements and the verbatim operator question keep their 0.14.0
citations, with re-verification appended: correct a standing claim, preserve a
dated one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GazEx6kCcyQuRvifWb3aBF
…phaze-g9cus) The previous wording said no verdict in the ledger holds test counts "even in principle" -- a standing claim about a permanent property. It was true when measured (0 of 49) and false the same day (1 of 56): a hive opts into the drop zone from its own test config, and the field is per-entry, so both shapes coexist and nothing rewrites old entries. Restate it as a property of the ENTRY rather than of replay, quote the measured ratio with its date, say explicitly not to read the ratio forward, and give the one command that answers it. Landing a permanent claim that had already gone stale would have been this bead's own defect, committed inside the fix for it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GazEx6kCcyQuRvifWb3aBF
…ces (phaze-g9cus)
Two sections landed a `{tree, cmd_hash, rc, at, host, sha}` list -- six fields,
missing `shas` -- one of them as an emphatic "take from the ledger only what it
stores". The live ledger records seven plus a conditional eighth, so both were
already wrong when written, in the same way the ledger section's own list was
before this bead corrected it.
Point at the canonical list instead of repeating it. A fixed enumeration is a
pointer with no redundancy -- nothing in it says whether it is complete -- so
every copy is an independent thing to go stale, and this file had three. The
arguments around them (rc=143 vs rc=1 being indistinguishable; what the two
killed runs do and do not establish) are untouched; only the list is.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GazEx6kCcyQuRvifWb3aBF
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Re-derives the "Boundary → recipe" table's caller citations against the bh actually installed, and replaces the citation form that failed rather than refreshing its digits.
What was wrong
The table cited bh 0.14.0 and seven
work.pyline numbers. bh 0.15.0 split that module, leavingwork.pyat 1777 lines, sosed -n "${n}p"returned empty for all seven (1909, 2417, 3557, 2923, 2948, 2972, 3525). They did not point at the wrong code — a wrong citation can be read and recognised as wrong. They dangled: unreadable, uncheckable, and nothing about the table's appearance changed.What this does
Re-derived all seven by reading each new call site, not by mapping numbers forward or diffing versions. No boundary's resolved recipe changed. The BLOCK → COMMAND half was re-executed against the live
~/.beadhive/config.yamlon 0.15.0 and reproduces exactly; the BOUNDARY → PHASE half stays I, as the table's own discipline requires.Changed the citation form. Each row now cites
module.py::symbolplus the resolver call as written, the bh version sits in the table header, and a one-command recipe regenerates the whole boundary population. A bare line number is a pointer with no redundancy —sed -n '3557p'succeeds against any file long enough — which is this repo's ADR-numbering argument one level down. Not an argument from principle: all seven boundaries changed file and line, and all seven are still findable by symbol and phase literal.Also in scope, because bumping a version citation without re-checking the claims attached to it is the defect this bead exists to fix:
merge/merge-mainis a post-land re-test with rollback,postlandis molecule-only,unioncan only fire on a per-bead merge.validate_cmd, nowork.validatekey can reach it, the schema accepts an inertbatch:/check:key, and a batch of parent-less beads lands onmainpastmerge-main. Escalated to HQ ashq-f9w.work.validate_precheckno longer exists in 0.15.0;work.always_rundocumented in its place.--git-common-diris load-bearing.merge-mainbounce that ran zero tests is an unmeasured gate, not a red one — cited as a dated observation, with the general form: a gate is RED only if its own pytest summary line says so.Evidence
Three gate runs, each forced by a base move rather than by rework. The last, quoted from the log body:
Submit replayed that verdict rather than re-running it:
Reviewer notes
0.14.0citations, with re-verification appended rather than substituted. Editing a quoted question so the asker appears to have said something they did not would falsify the durable record; a measurement is a property of a run at a time. Correct a standing claim, preserve a dated one.docs/design/0016-transferred-model-verification.md§3.3 describes this table's pre-repair state and explicitly defers the fix here ("Tracked asphaze-g9cus; do not repair them from here"). Its Consequence row reads present-tense and will describe a state that no longer exists once this lands. Left alone deliberately — an ADR is a dated analytical record, and it points at this bead — but flagging it for whoever next touches that file.🤖 Generated with Claude Code
https://claude.ai/code/session_01GazEx6kCcyQuRvifWb3aBF