CR-2026-217 — Candidate cards' open_finding_count gets the lineage filter (B-106) — v0.1

Version. 0.1 Date. 2026-08-15 Author. Claude.ai, drafted against the B-105 Step 0 inspection (inspection-briefs/loomworks-b105-sweep-step-0-inspection-v0_1.md, reader §5) and the CR-2026-216 completion evidence. Repository. loomworks-engine. Build-list item. B-106 (full close).

Plain-language summary

Every candidate card's open-findings count is computed with no filter tying it to that candidate — so every card shows the same global number (21 today, post-sweep). The cycle count directly above it in the same function filters correctly by seed lineage. This change request applies the same filter to the findings count, so each card counts only its own candidate's open findings. The defect is API-visible only today: the surface types the field but no component renders it. One filter, one test. No decision needed from the Operator.

0. Established facts (from the inspection; verify current at Step 0)

list_my_candidate_engagements (engagements.py:1400 at inspection time) computes open_finding_count with no seed_id filter.
The cycle count directly above it (:1385 at inspection time) filters by seed lineage correctly — the pattern to borrow is in the same function.
Surface: door3.ts:145 types the field; no component renders it. API-visible change only.
Post-CR-216 state: 21 global open findings = 12 living (across candidates) + 9 legacy NULL-seed_id. A correct per-candidate count keys on that candidate's seed_id; legacy NULL-seed_id rows match no candidate and fall out naturally — no special-casing needed, but the test names it (§3).

1. Scope

In scope. The lineage filter on open_finding_count, matching the cycle count's existing filter; tests per §3.

Out of scope. Rendering the field on any surface (nothing renders it today; a surface affordance is its own future item). The legacy NULL-seed_id findings themselves (outside the B-105 ruling, untouched). The schema move (behind B-69).

2. Steps

Step 0 — branch and verify. Branch cr-2026-217-finding-count-lineage-filter. Verify CR-2026-217 is unclaimed in loomworks-record; HALT if claimed. Confirm the two line numbers in §0 still hold on current main; if the code has moved, report the new locations and proceed only if the shape is unchanged — HALT if the shape has changed.

Step 1 — the filter. Apply the cycle count's seed-lineage filter to the findings count. Borrow the existing construct in the same function; do not reinvent it.

Step 2 — tests.

Two candidates with differing open-finding counts → each card reports its own number, not the global.
A candidate whose seed has zero open findings → 0, not the global.
Legacy NULL-seed_id findings present in ADMIN → counted by no card.
The test must be observed failing against pre-fix code before being trusted (the CR-216 forward-fix discipline).

Step 3 — quality gates. ruff zero-tolerance; mypy message-level non-regression.

Checkpoint A — after the green run, before tag and push. Gate string: GATE A APPROVED — PROCEED for CR-2026-217. Include in the report: the live route's per-candidate numbers before and after, for at least two real candidates (read-only queries; synthetic engagements for any write-path testing — never shared test engagements, never the personal engagement).

3. Acceptance

Each candidate card's open_finding_count equals the open findings of its own seed lineage — verified against the live route with the route's verbatim query, per-candidate, pre/post.
Legacy NULL-seed_id rows appear in no card's count.
Suite green at the zero-failures baseline; ruff clean; mypy at baseline.
Build list v0.91 closes B-106, new file alongside v0.90.

4. Discipline

Stage by explicit path, never git add -A. Re-verify HEAD before each write. Halt before every push. One session, one repository.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-217 — finding-count lineage filter — v0.1 — 2026-08-15