docs(changelog): known issues from part B's review, rounds 1 and 2

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-11-04 12:08:40 +01:00
commit fa0d4f036c
Signed by: ktg
SSH key fingerprint: SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q

View file

@ -139,7 +139,7 @@ Part C fixes the eight code MAJOR findings of part B's review, round 1, on the s
- **A linked instruction file keeps its own name** (SYM). A tracked symlink whose target is a tracked regular file inside the repo adds both its own path and its target's to the set, so a finding that cites the link's name is not declined as out of set; a link that resolves outside the repo still adds nothing. It names review finding `d81f3c45`. - **A linked instruction file keeps its own name** (SYM). A tracked symlink whose target is a tracked regular file inside the repo adds both its own path and its target's to the set, so a finding that cites the link's name is not declined as out of set; a link that resolves outside the repo still adds nothing. It names review finding `d81f3c45`.
- **The evidence writer takes a verdict only for the branch head** (WHD). `lib/review/merge-evidence.mjs write` asks the verdict gate only when `git rev-parse --verify HEAD` in `--repo` is the branch head; from any other HEAD the review verdict is null and the merge question reads "review not measured". It names review finding `561d6f11`. - **The evidence writer takes a verdict only for the branch head** (WHD). `lib/review/merge-evidence.mjs write` asks the verdict gate only when `git rev-parse --verify HEAD` in `--repo` is the branch head; from any other HEAD the review verdict is null and the merge question reads "review not measured". It names review finding `561d6f11`.
- **No run evidence for a merged name git reads as a tag or another ref** (AMB). The guard's reader (`hooks/lib/merge-evidence.mjs`) gives "no run evidence" when the merged name is also `refs/<name>` or `refs/tags/<name>`, loose or in `packed-refs`, or an entry in the git directory, and when `packed-refs` cannot be read; the writer refuses such a name (`"written": false`). It names review finding `df9f9870`. - **No run evidence for a merged name git reads as a tag or another ref** (AMB). The guard's reader (`hooks/lib/merge-evidence.mjs`) gives "no run evidence" when the merged name is also `refs/<name>` or `refs/tags/<name>`, loose or in `packed-refs`, or an entry in the git directory, and when `packed-refs` cannot be read; the writer refuses such a name (`"written": false`). It names review finding `df9f9870`.
- **The reader knows that `--cleanup` takes a value** (CLU). The reader skips the value of `--cleanup`, so `git merge --cleanup strip --no-ff feat` shows feat's run evidence. A quoted `-m` value with spaces before the branch still gives "no run evidence", the fail-safe side; its fix goes with the guard's quoted-value reading (decision 137). It names review finding `b5ae9798`. - **The reader knows that `--cleanup` takes a value** (CLU). The reader skips the value of `--cleanup`, so `git merge --cleanup strip --no-ff feat` shows feat's run evidence. A quoted `-m` value with spaces before a single branch still gives "no run evidence"; before two branches it can show one branch's run evidence for both (see Known issues); its fix goes with the guard's quoted-value reading (decision 137). It names review finding `b5ae9798`.
- **A command with several merges says its run evidence is not shown** (MMG). The Bash guard hands every merge of the command to `evidenceForMerges` in `hooks/lib/merge-evidence.mjs`: one merge keeps its two lines, and two or more give a "Tested by: not shown" line that names the count and says to merge one at a time, followed by "Undone by: not shown". Before, only the first merge got run evidence. The answer stays "ask". It names review finding `73e1d174`. - **A command with several merges says its run evidence is not shown** (MMG). The Bash guard hands every merge of the command to `evidenceForMerges` in `hooks/lib/merge-evidence.mjs`: one merge keeps its two lines, and two or more give a "Tested by: not shown" line that names the count and says to merge one at a time, followed by "Undone by: not shown". Before, only the first merge got run evidence. The answer stays "ask". It names review finding `73e1d174`.
Fix round 4.5a (decisions 57, 67 and 68): the round's 30 findings, where a Voyage control could be bypassed or was too lax, or where the text gave a guarantee no code held. Each is fixed, and each has a test that fails on the code before it, except DJ, whose sentences already stood and whose pins fail when they are deleted (`tests/fix-round-4-5a-red.sh` proves every other id red at the round's start point, and DJ under its two mutations). Fix round 4.5a (decisions 57, 67 and 68): the round's 30 findings, where a Voyage control could be bypassed or was too lax, or where the text gave a guarantee no code held. Each is fixed, and each has a test that fails on the code before it, except DJ, whose sentences already stood and whose pins fail when they are deleted (`tests/fix-round-4-5a-red.sh` proves every other id red at the round's start point, and DJ under its two mutations).
@ -256,6 +256,8 @@ Fix round 4.5a (decisions 57, 67 and 68): the round's 30 findings, where a Voyag
- **Review answers cannot be recorded with the installed 6.5.0 plugin** (part B). Its `/trekreview` has no answers step, and its review stays at 1.1. This delivery's own review runs on 6.5.0, so before its release check the operator answers its MAJORs with this repo's `lib/review/review-answers.mjs` (`pending`, then `record`), the path `docs/release-runbook.md` gives. - **Review answers cannot be recorded with the installed 6.5.0 plugin** (part B). Its `/trekreview` has no answers step, and its review stays at 1.1. This delivery's own review runs on 6.5.0, so before its release check the operator answers its MAJORs with this repo's `lib/review/review-answers.mjs` (`pending`, then `record`), the path `docs/release-runbook.md` gives.
- **The fork point is read from a ref the session can move** (part B). `lib/review/pre-existing.mjs` reads the fork point from `refs/heads/main` (or `master`), and that ref can be moved with `git update-ref`, `git branch -f` or a plain commit on main before the branch is made; the Bash guard does not ask about any of them, so the binding is a trace, not a signature. - **The fork point is read from a ref the session can move** (part B). `lib/review/pre-existing.mjs` reads the fork point from `refs/heads/main` (or `master`), and that ref can be moved with `git update-ref`, `git branch -f` or a plain commit on main before the branch is made; the Bash guard does not ask about any of them, so the binding is a trace, not a signature.
- **The Bash guard lets some commands with a quoted value through unasked** (part C, decision 137). The guard's view of a command loses a quoted value that holds a space or is empty, so the option before it takes the next word as its value, and a merge into main, a push, a tag or a publish is not asked about. Measured with the guard's classifier (`classifyGitApproval`), each of these gives no question: `git tag -m "Release one" v1.0`, `git -C "/tmp/a b" push origin main`, `git -c "x.y=a b" push origin main`, `echo "a b"#; git push origin main`, `git tag -m '' v1.0`, `git -C ~/"My Repos"/x merge --no-ff feat`, `npm --workspace "$WS" publish`, and `git -C "<path with a space>" merge --no-ff feat`, the form `/trekexecute` Phase 8 merges with when the repo path holds a space. The hole is on main already, and part B's merge does not widen it. Under decision 137 the fix gets its own round with its own brief, where the mechanism is chosen on purpose. - **The Bash guard lets some commands with a quoted value through unasked** (part C, decision 137). The guard's view of a command loses a quoted value that holds a space or is empty, so the option before it takes the next word as its value, and a merge into main, a push, a tag or a publish is not asked about. Measured with the guard's classifier (`classifyGitApproval`), each of these gives no question: `git tag -m "Release one" v1.0`, `git -C "/tmp/a b" push origin main`, `git -c "x.y=a b" push origin main`, `echo "a b"#; git push origin main`, `git tag -m '' v1.0`, `git -C ~/"My Repos"/x merge --no-ff feat`, `npm --workspace "$WS" publish`, and `git -C "<path with a space>" merge --no-ff feat`, the form `/trekexecute` Phase 8 merges with when the repo path holds a space. The hole is on main already, and part B's merge does not widen it. Under decision 137 the fix gets its own round with its own brief, where the mechanism is chosen on purpose.
- **The merge question and the gate have rests from part B's review, round 2** (part C, decision 131). Each was answered as accepted in that review and goes to the next hardening round. The merge question can mislead in its text only; the guard still asks: a quoted `-m` value with spaces before two branches (`git merge -m "merge two" a feat`) shows feat's run evidence for a merge of both; without a `## Doors` list in the plan and without a new CHANGELOG section, the undo line takes the door of the previous section; a loose ref that is not a plain sha falls back to an older `packed-refs` entry. The gate stays closed but says the wrong thing: an approval log that cannot be read or checked gives `review-unanswered:` instead of "not measured", so the release check says "not ready" instead of "could not decide". R6 now reads a review as stale after a merge of a side branch forked before the review, even when its content is allowed (stricter, never greener). When a carried finding has a severity word outside the four known ones, the carry keeps that word instead of ranking it highest, so a MAJOR could leave the count; no known path writes such a word, and the gate does not refuse one. The writer's refusal of a name that is an entry in the git directory has no test of its own. On a review with a duplicate finding id, `review-answers.mjs pending` exits 1 with an empty list, so Phase 8.8 asks nothing; the merge stays closed.
- **Copies and repeated work in the review code** (part C, decision 131). `RECORD_KEYS` in `lib/review/reviewed-commit.mjs` copies the approval log's private field list; the answers-table reader in `lib/review/review-answers.mjs` copies the validator's and already treats a duplicate row differently; the guard's evidence reader copies the git-directory lookup of `hooks/lib/git-approval.mjs` (with `lstat`, so a `.git` link gives "no run evidence"); callers tell an unanswered MAJOR from "not measured" by the reason's prefix; `recordAnswer` validates `--store` but commits the log without it; without `--repo` the gate starts git three times for the same top level.
### Doors ### Doors