god: evidence discipline — record structured commit/deliverable on done cards

[LavaDMan]

What & why

god's standing prompt tells it to keep the board accurate but never asks it to record where the evidence is. A done card says what happened in prose; it doesn't say which commit it landed in or which file it produced, so auditing the board means re-reading every result.

This adds an EVIDENCE DISCIPLINE paragraph to the god prompt asking for structured commit ({repo, sha}), commits ({repo, sha}[]) and deliverable (a path) on done cards — and declares and renders those fields, so the evidence has somewhere to land and somewhere to be seen.

Two guards learned from practice: record the full 40-character SHA reachable from main (a worker-branch SHA becomes a dead pointer once that worktree is reaped), and set the fields to null explicitly for decisions, answers and dropped cards, so "no artifact by design" stays distinguishable from "nobody filled this in".

Type of change

• New feature

Evidence

Same fixture hive, same card, two builds — one of main, one of this branch. The only difference between the images is the code. The block renders in TaskDetail, where description, result and humanQA already live; the compact column card is unchanged.

Before

After

How I tested it

• OS: Linux (Ubuntu 24.04), Electron 32.3.3
• npm run typecheck → 0
• npm run build → 0
• npm run test:focused → 721/724
• The 3 failures are hive-runtime-path, update-download-asset and win-cmd-shim. They reproduce identically on unmodified upstream/main in the same worktree — I stashed the change and re-ran rather than assume. They need the native postinstall steps, which were skipped by npm ci --ignore-scripts. Not caused by this change.
• The screenshots were captured by driving the built app under Xvfb over the DevTools protocol against a throwaway fixture hive, not by hand-editing an image.
• Rebased onto main at 53eb685f. The added block was spliced into main's current line at the same anchor with an assertion that both halves survive, rather than resolved by hand inside a 2,500-character template literal. git merge-tree against main exits 0.

Checklist

• This PR is one change.
• I read the diff myself — no debug output, commented-out code, or unrelated churn.
• No new UI / colors / spacing / fonts. This PR does add UI: an EVIDENCE block in TaskDetail, using existing --cth-* tokens and the same inset-border treatment as the surrounding rows. No new colors, fonts or spacing values are introduced.
• npm run typecheck / test:focused / build — run, numbers above.

[github-actions]

✅ Evidence received. Before and after are both attached. Thanks — this is what makes a PR reviewable in one pass.

[chaitanyagiri]

Reviewed by an agent on the Munder Difflin hive floor, posted from @chaitanyagiri.
First person statements below are the agent's, including the scope limits.
Replies here are read. Questions in this comment are real questions.
Base: origin/main at 956bfb4.

---

Two things, and the first one blocks.

This conflicts. The API reports mergeable: false, and the reason is visible in the diff:
it edits the single template literal that begins MONITOR the floor by reading, and main has
since edited the same line. The version on origin/main at 956bfb4c now contains a paragraph
starting WRITE THE ASK SHORT AND IN MARKDOWN, which this branch does not have. A careless
conflict resolution that takes this side wholesale deletes that paragraph. Worth saying in the
PR so whoever rebases knows what to keep.

Nothing reads the fields. The new text tells god to write commit, commits and
deliverable onto a task card. interface HiveTask in src/main/hive.ts declares
humanQA, result, slack and webhook, and none of the three new ones. I grepped
src/renderer, src/preload and src/main/hive.ts on origin/main at 956bfb4c for reads of
them and found none. So god will write the evidence and nothing will surface it. That is not
fatal, extra keys survive a JSON read-modify-write at runtime, but the stated purpose is that
the board can be audited by pointing at evidence, and right now the board has nowhere to point.
Either declare the fields and render them, or say in the PR that the UI half is a follow up.

One part I would keep exactly as written: Record the FULL 40-character commit SHA, and one reachable from the main branch, never a SHA that lives only on a worker branch, which becomes a dead pointer once that worktree is reaped. That is the right rule and the reason is in it.

[LavaDMan]

Both right, and the second one was the useful catch. Fixed both — force-pushed.

The conflict

Rebased onto main at 53eb685f. Rather than resolve inside that template literal by hand — the exact operation you flagged as the risk — I extracted the added block from the old head and spliced it into main's current line at the same anchor (after …who-did-what).), with an assertion that both halves survive before the write. git merge-tree against main now exits 0.

Your paragraph is intact and verbatim: WRITE THE ASK SHORT AND IN MARKDOWN through …each option stays on its own line, and the ASK ME board sentence after it. The EVIDENCE DISCIPLINE block sits between the assignee rule and HUMAN FEEDBACK, where it was.

Worth noting for anyone reading later: hive.ts is byte-identical between the 956bfb4c you reviewed and 53eb685f, so the nine intervening commits are all supporter-wall and the conflict was the same one you described.

The fields

You're right, and "extra keys survive a JSON read-modify-write" was the wrong thing to be relying on. I took the first branch of your either/or rather than deferring the UI, because declaring alone leaves the actual objection standing — the board still has nowhere to point.

• HiveTask declares commit, commits and deliverable, with TaskCommit as the shape.
• Typed T | null rather than optional-only. The prompt asks for an explicit null on artifact-free cards, and "no artifact by design" is only distinguishable from "nobody filled this in" if null is a value the type admits. Optional-only would have quietly made those two the same thing.
• TasksKanban renders them under an EVIDENCE label, above the human Q&A trail. The card shows the first 12 characters of the SHA and carries the full 40 in the title attribute, so it stays copyable and verifiable without a 40-character monospace run across the card. commit and commits are merged and de-duplicated by SHA, so a card that sets both doesn't list the same commit twice.
• normalizeCommit() validates the shape off disk. tasks.json is agent-written, so a non-object, a missing sha, or a blank sha degrades to "no evidence" rather than rendering [object Object] on the board. An explicit null renders exactly like an absent field — nothing — which is the honest display for a card with nothing to point at.
• kanban.evidence added to en, ar and zh-CN.

It renders in TaskDetail, not on the column card. That is where description, result and humanQA already live, and the compact card is deliberately two lines. If you'd rather the board itself carried a marker — a dot, or the short SHA under the assignee — say so and I'll add it; I didn't want to change card density on your board without asking.

Two commits: the rebased prompt change, then the declaration and rendering, so the review history stays readable.

On the SHA rule

Kept verbatim — thank you for saying so. It's in there because a worker-branch SHA had already become a dead pointer on us once.

Gate

typecheck 0, build 0, test:focused 721/724.

The three failures are hive-runtime-path, update-download-asset and win-cmd-shim. They reproduce identically on unmodified upstream/main in the same worktree — I stashed the changes and re-ran to check rather than assume. They need the native postinstall steps, which I skipped with npm ci --ignore-scripts. Not from this change, but I'd rather name them than report a clean number.

The description was stale — rewritten

Flagging this rather than quietly fixing it, since it changes what the PR is. When this was one line of prompt text the body correctly said "no UI or runtime" and ticked No new UI / colors / spacing / fonts. That is no longer true — the detail pane now renders an evidence block with its own styles. The body is rewritten, the before/after are new (same fixture hive, same card, one build of main and one of this branch, so the only difference in the two images is the code), and the gate box is ticked with the numbers above.

Happy to split the rendering into a follow-up PR instead if you'd rather keep this one to the prompt change — say the word and I'll pull it out.