[DealAppSeo]

What

Increment 2 of the Evidence Pack (D-130 / D-141 #1510): cross-join each cited trinity_tasks:<id> to real task state, so "656 experimental rows" is defensible as "656 deltas grounded in tasks that actually exist and were done" — not just that a task is cited.

Opt-in, reducer stays pure. evidencePack(rows, taskEvidence?) — the caller runs the read-only trinity_tasks query and passes in the resolved existing / done id sets, exactly as it passes the rows. Two new tripwires when taskEvidence is supplied:

• cited_task_exists — every row citing trinity_tasks:<id> resolves to a real task row.
• cited_task_verified_done — that task is verified done by the caller's bar (doneBar).

Omit taskEvidence → behaviour is identical to increment 1 (citedTasks: null, no new invariants). No live state touched; writes nothing.

Verified live [V 2026-11-04, read-only]

656 rows cite 330 distinct tasks; all 330 exist, all 330 are status='done' with a non-null result and known-answer lineage → both invariants hold, citedTasks = {cited:330, existing:330, done:330, missingRows:0, notDoneRows:0}, ok:true.

Done-bar nuance (enumerated, not assumed): status='completed' is 0 for these — the lifecycle marks them 'done', and the code's own done-bar is result IS NOT NULL (loadKnownAnswerRows filters on that, never status). A status='completed' literal would false-alarm on all 330; the reducer records the caller's bar on the invariant.

Tests

14/14 jest (increment 1 unchanged + 4 new increment-2 cases + the citedTaskId parser): happy join, a cited task that doesn't exist, a cited task that exists but isn't done, and back-compat (no taskEvidence ⇒ null + no new invariants).

🤖 Generated with Claude Code

[strix-security]

Strix Security Review

✅ No open security findings.

PR summary: Increment 2 of the Evidence Pack adds an opt-in, caller-fed cross-join that verifies each `trinity_tasks:<id>` cited by an experimental row resolves to a real and done task, emitting two new tripwire invariants. The reducer stays pure and inert: omitting the new `taskEvidence` argument preserves increment-1 behaviour exactly.

Review summary

I reviewed both changed files in full — the pure evidencePack reducer and its jest suite. The change adds an optional taskEvidence parameter, a citedTaskId parser, and two conditional invariants to a function that performs no I/O, touches no database, reads no live state, and has no production caller anywhere in the repository (only its own tests reference it). Data flowing through it is caller-supplied rows and id sets, not request input, and nothing in the diff removed an authentication, authorization, or validation control. The regex /^trinity_tasks:(.+)$/ is linear with no backtracking risk, and no string from the diff reaches a query, shell, file path, redirect, or HTML sink. I found no security issue introduced by this PR.

_{Review 1 on this PR · cca6ea7 · requested Nov 4 23:21 UTC when the PR was opened}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[strix-security]

I reviewed both changed files in full — the pure evidencePack reducer and its jest suite. The change adds an optional taskEvidence parameter, a citedTaskId parser, and two conditional invariants to a function that performs no I/O, touches no database, reads no live state, and has no production caller anywhere in the repository (only its own tests reference it). Data flowing through it is caller-supplied rows and id sets, not request input, and nothing in the diff removed an authentication, authorization, or validation control. The regex /^trinity_tasks:(.+)$/ is linear with no backtracking risk, and no string from the diff reaches a query, shell, file path, redirect, or HTML sink. I found no security issue introduced by this PR.

---

Reviewed by Strix
_{Configure security review settings}