[hhff]

What

• The hole (on main): the supervisor writes its own log file, and the fold resolves a question by at. A hand-written, backdated second new line for an answered question's id became the question, so the owner's earlier "yes" approved whatever that line said. Editing the question's line in place in the live run/log did the same. This covers every answer-backed approval: merge --approved, decisions, goal changes, link bundles (Tickets in other repos: one fleet, one log and one graph across sibling repos #108's review found it there).
• The fix:
  • question_hash is set on the owner's answer line: a sha256 (16 hex) of every field the question was asked with, excluding the supervisor's later status and reason and the owner's own fields. It's written centrally in appendLog, so answer, the secrets post and goal decide all carry it. In the schema it's owner-only and set-only.
  • questionView: an owner answer whose recorded hash doesn't match the question as it now folds is dropped. The question reads open with rewritten: true, so every consumer that needs status === 'answered' refuses, and the owner answers what it says now. The view also exposes hash.
  • log-check and validate fail on a rewritten question and on any second new line for a question id (questionRewrites()).
  • answer --seen <hash>: the dashboard sends the hash of the question it rendered, and an answer to a question that changed since is refused ("reload and read it again").
• Tests: in "a chore PR that touches the kit needs an owner answer":
  • both rewrites (a backdated duplicate, and an edit in place) make merge refuse, reopen the question as rewritten, and fail log-check;
  • after restoring the log, the merge goes through again;
  • --seen refuses a wrong hash and accepts the right one.

Why

An answer must approve exactly what the owner saw. The log can't tell kit-written lines from hand-written ones, so the binding has to live in the owner's own line. This is the same class of hole as #87, #88 and #93.

Migration

• Answers given before this release have no hash and count as before. Only answers given from now on are bound.
• Existing logs: if a log already has two new lines for one question id, log-check now fails on it. Stacks and stacksbot have none; I checked both read-only.

Local: Node 24.14.1, kit test 43/43.

🤖 Generated with Claude Code

[hhff]

Review (independent adversarial pass): the backdated duplicate and an edit in place are closed for hashed answers, #108's link-bundle forgery now fails, and the hash covers everything the supervisor can't set. Fixed from that review in 4f77665:

• Legacy answers: an answer with no hash is voided by a second line for its question.
• Dashboard: it shows a rewritten question in red. Context keeps pre-wrap.
• Leftover duplicate line: it fails log-check and validate only while the question is rewritten; once the owner re-answers, it warns.
  Not closed here, and pre-existing: a hand-written owner line. Nothing signs owner lines, so that remains the kit's trust boundary.
  Local Node 24.14.1: 43/43.

[hhff]

Merging for v0.20.1 (upstream loop).

• Local release candidate (main with Tests never reach the machine's default tmux server #117, plus An owner's answer binds to the question as the owner saw it #116, Tickets in other repos: one fleet, one log and one graph across sibling repos #108, Lessons: keep one with an owner's note that refines it #114 and gate-change can be settled by the owner's own standing rule #115): Node 24.14.1 passed 122/123. The one failure is the hub test's "both instances listed with counts" timeout under load; it passed in the previous candidate's run and on CI.
• CI: 18/20/22/24 green on this head, with main merged in.
• Next: main's own CI checks the combined result before the tag.