Sixteen unreachable or unchecked things, the gates that derive them, and the times those gates caught me

[ibuilder]

What & why

Sixteen items on one theme: things that shipped correct and were never checked or never reached,
and the gates that turn the class from hand-found into derived. Those gates then caught me three
times — on the card written to demonstrate one of them, on a shim I justified for callers that do
not exist, and on an edit I had convinced myself was fully verified. Two items carry a live wrong
answer; one exists only because I went to check whether a sentence I had written in the item before
it was true.

	item	what it was
7e39f34	SCHEMA-UNGENERATED	the committed client types described half the API, and had since the day they were generated
6be23d3	RESIDUAL-DARK	the developer's actual question — what can I pay for the dirt? — built, routed, tested, unreachable
43cd696	RENTROLL-DARK	two engines that say whether you can believe the rent roll; no screen called either
5c6b8e6	T12-SELFTIE	a tie-out gate that could not fail, because nobody was handing it evidence
f8bae56	COVENANT-DARK	two verdicts that read clean when nothing was evaluated
f661a33	VERDICT-COVERAGE	the class found five times by hand, now derived — and it found three more
6fc46a2	AUTHORITY-DARK	a gate you could read and could not satisfy
f779f0c	DECISION-GATE-DARK	the keystone over the whole tab, and nothing called it
482084b	the gate caught its own demonstration	test_verdict_coverage failed on the card written to argue for it — and the first reading of that failure was "false positive"
b2bb594	SUPPLY-DARK	a market where every project was filtered out reported the most favourable verdict there is
b2cc295	SCAN-TRUNC	a model cut short turned a correct building into 500 as-built findings — and it is the opposite sign from CLASH-TRUNC
e22c282	the dead-code gate caught a shim	I kept a wrapper "for callers that only want the array". There are none
0601e21	TRUNC-COUNTED	three screens printed the size of a page as the total, and one of them acted on it
d1085e8	the size ratchet caught an edit I had verified	I enumerated behavioural coverage and called it coverage
e3905a4	SCAN-DARK	SCAN-TRUNC's refusal pointed at a route formally frozen as unreachable
850aa32	PROGRESS-UNMATCHED	an engine whose own note promised "never silently dropped" and silently dropped
5abcc1c	SCOPE-EMPTY	an empty register and one with nothing done were the same three numbers
7e1c0d0	DEGENERATE-SWEEP	the ledger: 17 engines measured, 9 defects, 8 clean
9db199b	CI-LATEST-DARK	the model-CI badge is stored so it need not be recomputed, and recomputing it was the only way to see it
ba3bddd	PORTAL-TXN-DARK	a whole client-decision transaction with neither end built — recorded and parked, not half-built
999bdd8	SSO-DOOR-DERIVED	the predicted fourth sign-in door arrived guarded, and the gate watching for it could not see it

SCHEMA-UNGENERATED

apps/web/src/api/schema.d.ts is generated from the FastAPI spec and committed, so it is a claim
about the server checked in beside the client. Nothing checked the claim:

paths the app serves	947 (1,021 operations)
paths schema.d.ts declared	500 (541 operations)
operations served but undeclared	482, across 165 of 203 path groups
operations declared but no longer served	2

It was not staleness, and the name it was filed under pointed at the one action that could not fix
it. schema.d.ts and the apps/web/.gitignore line hiding its input were written in the same
commit (8432a88), and the app has fewer route decorators today — 1016 against 1022 — so drift
cannot account for a gap running the other way. And re-running the generator reproduced it:
package.json ran openapi-typescript src/api/openapi.json …, which .gitignore ignores, so it
regenerated from whatever untracked dump was on the machine and printed a green tick.

Fixed in three parts: gen-api-types.mjs dumps the spec from aec_api.main:app into a temp file it
deletes and sorts paths first (so the next regeneration is a reviewable diff); schema.d.ts
regenerated by that script, byte-identical across two runs; and
services/api/test_schema_types_agree.py asserts every live (path, method) is declared — a
generator can only be run, and nothing makes anyone run it.

Four callerless CRE engines, and what each one's refusal cost

Each of these shipped complete, correct and tested, with a client method written for it and no
screen calling it — so nothing had yet had the chance to get its careful parts wrong.

• RESIDUAL-DARK — residual land value on the Feasibility tab. The substance is the three caveats:
  unreachable-at-$0-land ("the deal, not the dirt"), converged: false (a bracket, not a price), and
  bounds — declared nowhere in the client, so no unread-field audit could see it. The applied
  value goes back as the basis the engine solved for (the first category: "land" line, others
  zeroed), not the one the driver form is bound to.
• RENTROLL-DARK — net effective rent + the rent-roll scrub, under the Operations rent roll.
  clean is bool(ran) and not failed, so one check passing with six unable to run is true; the
  card leads with coverage. NER's totals cover only the computable leases, so its Face GPR is a
  different population from the base rent three lines above it — said out loud. And skipped is
  capped at 50 while skipped_count is not, so the card says when it is showing a page.
• T12-SELFTIE — measured through the real engine, one unmapped $90,000 line: no stated totals →
  reconciles: true, all deltas 0.0, adjusted NOI published ($3,180,000); with stated totals →
  stopped, null. Without totals the reference is the sum of the source lines, so both sides come
  from the same mapping. The two responses are indistinguishable, which is why "were totals stated"
  is a parameter of the renderer rather than something inferred.
• COVENANT-DARK — again measured: a register with 2 uncomputable obligations and 2 untested
  covenants reports at_risk: false, because every count that flag reads is zero for want of
  inputs; and clean is true with 1 of 3 tested. Also rendered, all previously undeclared: the four
  fields that make a due date re-derivable ("A due date a reviewer cannot re-derive by hand is not a
  due date" — and its client could not see them), both readings when the lender's notice and our
  receipt dates disagree, and the note separating a breach inside an open cure window from one outside.

AUTHORITY-DARK and DECISION-GATE-DARK — the two gates at the top of the tab

AUTHORITY-DARK is sharper than "nobody called it", and my first reading of it was wrong.
dealAuthority() — the READ — has had a caller all along: portal/panels/design.ts renders the gate
on its go/no-go card. What was callerless is saveDealAuthority() — the WRITE. So the table could be
seen and never declared: the design panel could say "Source facts NOT current" and nothing in
the product could make them current. A gate you can read and cannot satisfy is worse to ship than one
nobody can see — it is visibly unfinished and reads as a bug in the analysis rather than a missing
surface. The load-bearing test is a tripwire reading deal_authority.py off disk, because
FACT_TYPES has to be mirrored (the GET returns declared rows plus the required missing ones, so an
optional type nobody has declared appears in neither) and the required flag is the column that
matters: a drift there shows a fact type as optional while the engine blocks on it.

DECISION-GATE-DARK is the keystone, and its contract is the principle this whole PR is about,
implemented in the engine rather than in a consumer: "A gate whose evidence was not supplied is
unknown, and unknown BLOCKS — absent evidence must never read as a pass. The actions list says what
to do, not just what failed." Measured with no evidence: 6 of 7 unknown, blocked, six actions.
The card leads with the actions, renders unknown as blocking in word and colour, and keeps the
reason on a vacuous pass (exhibits passes "no exhibits were required for this package" — a gate
that tested nothing). It gathers the two pieces of evidence this app can produce and leaves the rest
absent, which blocks; a source that fails is omitted rather than filled in, because an invented
payload would make a gate pass or fail on something the card made up.

VERDICT-COVERAGE — and the defect it found on its first run

Five engines, one shape: a boolean verdict beside a count of what could not be evaluated. Every one
of those engines is careful; the defect is always in the consumer, and four of five had none.

A subset verdict is derived structurally — bool(A) and (all(…) | not B), the guard being the
author recording that the subset can be empty. Coverage-word matching returned 24 candidates of
mostly unrelated senses and would have needed five exemptions; the structural form returns 5 with
none, and three were instances nobody had found by hand.

One was live: viewer/tools/analyseSection.ts printed "clean" over whatever fraction of the
schedule was analysable. sequence_clash skips any activity with no location, no dates or
finish-before-start, each with a stated reason, and the panel never rendered skipped_count. Fixed,
with skipped declared on the client for the first time and a warn kind added to resultNote, which
had no way to say the check ran and part of the input was not examined.

The gate caught the card written to demonstrate it — 482084b

test_verdict_coverage.py landed in f661a33. One commit later it failed on
apps/web/src/proforma/decisionGateCard.ts — the card written to demonstrate the principle it
enforces — and that commit (f779f0c) was pushed red.

The first reading was "false positive", and measuring is what overturned it. The card does not
render the scrub's clean; it forwards the whole payload to decision_gate.evaluate and renders
that engine's answer. A forwarder, not a renderer. But _gate() splats **extra onto the row, so
rent_roll_scrubbed arrives at the client carrying ran, failed and not_applicable, and the
card declared five fields and rendered detail. Through the real engine, a scrub of
{ran: 1, not_applicable: 6, failed: 0}:

status: "pass" · detail: "the scrub ran but found nothing"

"Nothing" there means no problems found. It reads as "nothing was wrong", over six checks that
never ran — the same defect one layer up from the four already fixed here, in the card that argues
for fixing them. The engine is sound and untouched: decision_gate already requires ran > 0 and
already attaches the coverage. It measured the thing and handed it over; the client dropped it.

DecisionGateRow/DecisionGateResult are now named interfaces rather than an inline re-spelling —
which is why three fields could sit on the wire unread by any derivation over declarations — and
coverageOf() is written as a rule over whatever a row carries, not a special case for the one gate
that carries it today. The engine's status word is left alone: this card declines to drop what the
engine measured, it does not overrule it.

SUPPLY-DARK — the sharpest instance of the whole theme

supply_pipeline.py weighs a competitive pipeline by what is recorded about each project rather
than by the label on the deck. competitiveSupply() was callerless and typed
Record<string, unknown>, so every field was invisible to deadFieldTyped.test.ts and to any other
audit starting from the client's declarations — the excluded_comparables hole again.

Measured before writing the card. Four projects, none matching the subject's product type:

counts.competing	0
excluded.counts.wrong_product	4
weighted_index.band	"undersupplied"
discount_pct	0.0

The most favourable verdict the engine can produce, byte-identical to a market with genuinely no
competition. "Undersupplied" is an argument to build — worse than the four clean: true cases,
which at least read as neutral. The engine claims nothing: the coverage is in the response and its
note says the exclusions are listed "so a thin competitive set is visible, not implied". So the
card withholds rather than annotates — no band, no totals, no discount on a vacuous set — and
separates "the filters ate the pipeline" from "there was no pipeline", which are different findings.

test_verdict_coverage does not flag this, and the limit is recorded rather than papered over.
It derives boolean subset verdicts; a band string and an lsi integer match no part of that
shape. A derived population is bounded by the form it derives, and that form came from five
hand-found instances that all happened to be booleans.

SCAN-TRUNC — the one live wrong answer, and it points the other way

scan_deviation.model_surface_points caps the model reference at 200,000 surface vertices and
reaches that cap by breaking out of the element iterator, so it drops whole elements rather than
thinning evenly — in whatever order ifcopenshell yielded them. Scan points over a dropped element
were measured against whatever surface remained. Nothing in the response said the cap was hit.

Measured on a two-wing model built exactly to design:

reference	within_pct	out of tolerance	max deviation
full	100.0	0	0.004 m
truncated to the first wing	50.0	500	50.0 m

That is a fabricated defect, not a loss of precision — on a QA/QC as-built check it sends a crew
to re-survey a wing that is fine. The cap exists for large models, so this is the normal case on a
real project. And it is the opposite sign from CLASH-TRUNC, where truncation made a partial
matrix read clean: the direction a silent bound pushes the answer is a property of the bound, not
of truncation, so neither case predicts the other and both had to be measured.

The two caps are now handled differently, and the asymmetry is the decision. A truncated scan
is a coverage claim — the points read were read correctly — so the verdict stands with its coverage
beside it. A truncated reference is a correctness claim: there is no population the figure is true
of, so within_pct and the histogram are withheld. A caveat is for a number that means
something.

And the gate's first draft verified the refusal without verifying anything could reach it. Two
mutations — the producer returning False unconditionally, and the route dropping the keyword —
both left it reporting a clean tree, because it exercised analyze() in isolation and never the
chain. The refusal could have been correct and dead, and the gate would have agreed with itself.
Closed by exercising the producer against a fake geometry iterator and reading the route's call by
AST, with both keywords required to be names rather than constants — a hardcoded False was exactly
what the second mutation did. Ten mutations now, all red, in both directions: over-correcting
reds as well as under-correcting.

TRUNC-COUNTED — three screens printed the size of a page, and one ACTED on it

roundtrip_diff carries three bounds — rows[1:5001], changes[:1000], unknown_guids[:100] — and
disclosed one, via truncated. model.ts never declared even that one, so qaSection.ts could
not read it, while the same file reads the identical flag correctly forty lines earlier on a response
whose type does declare it. The CLASH-TRUNC hole in a second place.

The Apply button posts the truncated changes page, so a sheet past the cap was applied in part
and reported as whole — the model ends up differing from the spreadsheet the operator believes they
applied, with no error. Reachable by construction: one change per changed cell against a 5,000-row
bound overflows a 1,000 cap with a single property column.

Why there is no sweep gate, which is the finding. 43 list truncations, 26 already carrying a
sibling count — the good pattern is the house convention, which is what makes the rest anomalous.
Of the 17 without, 11 carry the count under another name or are top-N by design. Joining the rest to
.length reads by NAME reports 35 sites and it is not a finding: guids alone accounts for 12,
and the two I read in full were correct code. Even a checker-resolved join must separate ".length
shown as a count" from ".length used for an ellipsis" — a judgement call, and a rule needing those
needs an exemption list.

SCAN-DARK — and why it exists

SCAN-TRUNC's refusal says "use /scan/verify-lod500, which queries per element and never truncates
the model." I went to check whether that was true. That route had no client method at all and was
listed in test_route_reachability.py as deliberately clientless — so I had written a refusal that
redirects to something unreachable, which is the AUTHORITY-DARK shape, authored by me one commit
earlier. scanDeviation's declared type also omitted every field SCAN-TRUNC added.

A clean negative, measured before any UI. verify_from_scan on a scan covering nothing:
verified: 0, stamped: 0, uncovered: 50, nothing stamped, within_tolerance null rather than
false. It fails closed and needed no repair — so the card's job was only not to subtract that care.

The method behind nine of these, and the eight times it found nothing

Every item from RENTROLL-DARK onward began the same way: call the engine with nothing to evaluate,
before writing a line of UI. Not reading the code — calling it. Seventeen engines were measured
that way. Nine carried a defect; eight were clean, and 7e1c0d0 records the whole table because
a sweep that only ever finds things is one nobody should trust.

The clean results are the interesting half. ci/latest returns overall: "none", badge: "NONE",
"No CI run yet." — it already refuses to let a no-run read as a pass, which is this sweep's entire
thesis, implemented before I got here. doc-graph 409s with its reason. verify_from_scan stamps
nothing and says absence is not a pass. The axis ended rather than being abandoned: the last four
probes came back clean against an actually-empty project.

Two of the nine came in this batch:

• PROGRESS-UNMATCHED — capture_diff filtered both its sets through if g in known while its
  note promised disappearances were "never silently dropped". The promise held only among elements
  the current model still contains, which excludes the case a rework flag is for. Measured: 500
  capture GUIDs against a 300-element model → 100% complete, 200 dropped, no key naming them. The
  filter stays (removing it crashes the engine, which the gate proves by doing it); only the silence
  is fixed.
• SCOPE-EMPTY — an empty scope register and one holding a single un-quantified item returned the
  identical 0.0 / 0.0 / 0.0. Opposite findings — go write the register, versus go do the work.
  The repair needed no judgement: spine.traceability, named beside it in coverageMaps.ts as the
  other completeness mapper, already returned None. An existing test asserted the defect, and
  changing it is only legitimate because the old line pinned a value standing in for a property it
  never stated; it now states the property.

The sweep is deliberately NOT a gate, which this repo's rules make a claim I have to justify. The
derivable part already is one — test_verdict_coverage, no exemptions. The rest is not: band: "undersupplied" is a string, 0.0 is a float, and "would a reader mistake this for a
measurement" is a judgement. A rule needing judgement calls needs an exemption list, which is where
the next instance hides.

Following a prediction a previous session left in the roadmap

The concurrency sweep record ends with "a fourth sign-in path is the risk." It arrived, and the
code was already right — SCIM auto-provisions and does route through the shared helper. What was
wrong is that test_sso_provision_race tested a hardcoded list of three and printed "all 3
auto-provisioning doors": silent about the fourth, and about any fifth. A registry reports on what
it contains, and its silence is indistinguishable from a clean bill.

The population is derived twice now, neither derivation needing an exemption list — every caller
of the helper must be a known door, and every site constructing a User must reach the helper or
be a by-request creation. Both proved by writing a real fifth door into the tree: wired to the helper
it reds one, provisioning inline it reds the other.

My own walk double-counted on its first draft and did not fail, it answered — attributing each
User(...) to every enclosing function gave 11 sites where an independent probe found 7, with the
precondition floor calibrated on the inflated number. The only reason it was caught is that the
population had been derived separately first and the two disagreed.

Two things deliberately not built, and why

• PORTAL-TXN-DARK. POST /shared/{token}/decision is complete and careful — public by design,
  whitelisted, length-capped, a hard per-token cap. Nothing can reach it and nothing can read what it
  stores: the page a client sees is read-only HTML (no <form, no <button, no fetch(), and both
  client methods are callerless. Two callerless methods on the same seam are one missing feature,
  not two missing buttons. The write half means putting interactive elements on a public,
  unauthenticated surface — a security posture, not a layout choice — and building only the owner's
  feed would be a panel empty by construction, whose emptiness reads as "no client has decided"
  rather than "no client can." Parked with the six other items needing a decision.
• A 500-where-409 race in register/create_user. Real, and low severity: unlike a sign-in,
  where both racers are the same legitimate user and the loser must succeed, here the loser is
  claiming a taken username and its request correctly fails either way. Inflating it to match the SSO
  finding would make the ledger less useful, not more.

Gate defects found in my own work, each by measuring

• A relative path is a question about where somebody stood. An env-independence precondition
  globbed Path("src") — fine under run_tests.py (cwd=services/api), names nothing under ci.yml
  (repo root), where rglob yields nothing and reports a clean tree.
• A parity check between two derivations that share a failure mode is not a check. Path keys were
  counted independently of group bodies… with a regex failing the same way. One whitespace mutation
  broke both and the counts stayed equal.
• The XSS source pin accused a safe line, matching the escaper's name rather than its binding —
  not a miss, a confident accusation telling the author they had an XSS.
• A mutation that did not compile printed no results line, and the harness read that as silence
  rather than a failed experiment.
• Asserting one inequality is not asserting that three states are three states. A mutation giving a
  curable covenant breach the passing colour satisfied curable !== uncured while being worse than
  folding the two together.
• day() formatted through toLocaleDateString, which renders en-GB September as "Sept" on this
  Node's ICU and "Sep" on another — a calendar spelled differently on two machines.
• clearCacheKeys.test.ts caught a localStorage key with no readable stem — "an unread key is an
  unclassified key", because Clear cached data then decides about it unchecked.
• .btn matches no rule in style.css — copied from portal/panels/, where six files carry the
  same unstyled class. A class name is not a style, and nothing typechecks the gap.
• An assertion satisfied by a different code path is not an assertion about that path. The
  authority blocking-table test checked a label against the whole card's text, and the same label
  appears in the "Not declared" line built straight from FACT_TYPES — so rendering the raw key in
  the blocking table passed.
• The one mutation that survived was the one that mattered. 11 of 12 supply mutations redded;
  the twelfth — folding rumored units into the certain total, the single thing that engine is most
  careful to keep apart — passed, because the test asserted the engine's wording on the stated
  grounds that "750 is the raw total and is legitimately shown, so the number is not checkable". It
  is checkable; it just has to be read out of the row it belongs to. A number asserted against the
  whole card is not asserted at all — the line above, arriving from the opposite direction. 14 of
  14 after the repair.
• I sized two items wrong, in opposite directions. Both progressCaptureDiff and
  scopeRegister were opened as small wiring jobs. The first has no producer at all — nothing in
  the product makes an "installed GUIDs at time T" set. The second has producers but needs three
  datasets assembled. An item's size is a claim about its dependencies, and neither claim survived
  looking. Both stay in the callerless freeze list with the reason recorded.
• I enumerated one kind of coverage and called it coverage. Before pushing 0601e21 I checked
  that every suite covering the changed files' behaviour had passed, and concluded the rest could
  not touch the diff. test_file_sizes could: it covers changed files structurally. Two files
  under down-only ratchets had grown. The repair was extraction, not a raised cap — and it made
  three rendering decisions unit-testable that the Python gate had been string-matching.
• A shim justified for callers that do not exist. model_surface_points kept an array-only
  wrapper "for callers that only want the array"; test_dead_code_population found none within the
  hour. Its sibling parse_point_cloud kept its wrapper and is not dead, because a second route
  still calls it — the asymmetry is the evidence that checking callers, rather than applying a
  symmetric habit, would have caught it.
• Asserting the one case you thought of is not asserting the property. refused() keyed on
  reference_truncated passed all 14 scan tests, because every fixture set that flag and the null
  figure together — and the engine has a third refusal branch where the flag is false.
• Bare python here is 3.11 and the venv is 3.12, so launching the backend suite with it
  produced ~500 failures in 0.0s each — ModuleNotFoundError: No module named 'fastapi'. An
  environment failure that looks exactly like a catastrophic regression, and the only thing that
  told them apart was reading one traceback before reacting to the count.
• A suite run against a tree you are editing is a claim about no particular commit. The
  confirming backend run for f779f0c came back 719/720 — but it had read the working tree while I
  was editing it, so its one red was my own mid-run roadmap edit and its test_verdict_coverage
  pass came after I had already applied the fix. Both results were worthless. f779f0c's true
  state was established from the commit instead: git show f779f0c:…/decisionGateCard.ts reads zero
  coverage names.
• Three gates in this repo caught me while I worked, which is the best evidence in this PR that
  they earn their keep: test_gap_records on a roadmap marker I had invented (⭐⭐),
  clearCacheKeys.test.ts on a localStorage key with no readable stem, and roadmapLanes.test.ts on
  an item I opened and assigned to neither a lane nor Parked. Each repair was the narrow one the gate
  implied, never a widened allowance.

Checklist (mirrors CONTRIBUTING.md)

• Backend: cd services/api && python -m ruff check ../.. clean
• Backend: full suite re-run on every commit. The first five were 719/719, 0 failures. The
  sixth came back 719/720, and the one red is worth stating rather than smoothing over:
  test_gap_records' loose-vs-strict parity check caught a marker I had invented in the roadmap
  heading (⭐⭐), which "shrinks its population without changing a word of its verdict". The
  repair is the established single ⭐, not a wider marker list — that gate's own lesson is
  that a hand-widened list is a list somebody stopped widening. Fixed, and re-verified across
  every gate that reads docs/roadmap.md, derived rather than guessed: 9 backend + 5 web, all
  green. test_schema_types_agree and test_verdict_coverage are registered in run_tests.py
  TESTS, the former also in test_roadmap_status.py's DONE_WHEN. Later runs are 720/720.
• Web: npm run typecheck && npm run lint && npm run build clean (Node 24); npm run test
  271 files / 2,958 tests pass
• No import cycles introduced
• CHANGELOG.md entries added (newest at top); roadmap items updated, Lane I cell corrected
• Version bumped — deliberately not. test_release_current reports v0.3.1143 is already
  10 releases ahead of the newest tag (v0.3.1133), exactly at its bound, so the next bump reds
  that gate. Ten merged versions have not reached a user; tagging is the repair, not raising the
  bound.
• No secrets, no competitor names in shipped docs

Each item is its own commit and independently revertible. The diff statistics are deliberately not
restated here — GitHub shows them at the top of this page, and an earlier revision of this body
carried a hardcoded +43,917 / −7,640 across 35 files that was stale within two commits. A number
that has to be re-edited on every push is one that should point at its source instead. What is worth
saying and does not decay: the great majority of the insertions are the regenerated
apps/web/src/api/schema.d.ts, which is machine-produced and was byte-identical across two runs; the
hand-written part is the pro-forma and scan cards, their tests, the generator script, and six gates.

One red was this PR's — f779f0c's — and it is fixed in 482084b. test_verdict_coverage,
the gate added two commits earlier, failed on that commit's own card. Stated precisely, because CI
never ruled on it: the API test gate on both f779f0c and b2bb594b came back cancelled, each
superseded by my next push, so the run on b2cc295 is the first CI backend run on any of this work.
The claim rests on local evidence — git show f779f0c:…/decisionGateCard.ts reads zero coverage
names, and the gate failed on a tree whose only other diffs were elsewhere — not on a CI result.

Three checks are red and none of them is this PR's. Two of the three are one cause:

check	why
python (security.yml — pip-audit)	anyio 4.14.1, CVE-2026-63374 (CRITICAL, fixed in 4.14.2) — pre-existing on main; the scheduled Dependency scan on main failed 2026-09-21
Container build (api) (containers.yml — Trivy)	the same anyio CVE. The image builds; Trivy scans it and exits 1. Named here because the earlier triage said "pip-audit and Trivy" without naming the check, which reads as two findings rather than one
Android debug build (mobile.yml)	android-actions/setup-android asks Google's repository for the deprecated tools package

Triaged with patches in this comment.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Tt2XKB83wwNt2nrMbK6eEA

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ibuilder]

Three red checks, none of them this PR's — standing down on all three, with patches

This branch touches no dependency file, no workflow and no mobile file. git diff origin/main...HEAD --name-only is 17 files, all under apps/web/src/, services/api/test_*, docs/ and CHANGELOG.md/CLAUDE.md; the only package.json change is the gen:api-types script string. So none of the three can be caused by the diff, and each is verifiable as pre-existing rather than asserted as such.

1 + 2 — python (Dependency scan) and Container build (api) — one dependency between them

Both are anyio==4.14.1:

check	finding
python → pip-audit gate	CVE-2026-64847, CVE-2026-63349 → fixed in 4.14.2 (+1 more advisory with a published fix)
Container build (api) → Trivy	CVE-2026-63374 — CRITICAL, fixed in 4.14.2

Pre-existing on main, not merely "unrelated". services/api/requirements.lock is byte-identical between origin/main and this head, and the scheduled Dependency scan on main itself failed on 2026-09-21 (run 35598718812, head e736c4d9, which predates this branch). The Trivy half is red by construction for the same reason: it is a function of the lock on main × today's Trivy DB.

No fix exists to port, so here is the patch rather than a widening of this PR. anyio is transitive (# via anthropic, httpx, httpx2), so the floor goes in the input file:

  # --- web / API framework ---
+ # CVE-2026-63374 (CRITICAL), CVE-2026-64847, CVE-2026-63349 — all fixed in 4.14.2. Transitive
+ # via anthropic / httpx / httpx2; pinned here because pip-compile reads only this file.
+ anyio>=4.14.2

It cannot be finished from this PR in one push, and that is the reason I have not started it. requirements.in's own header says the lock is "generated … inside python:3.12-slim … never on a dev box", and lockfile.yml's auto-commit is scoped to dependabot/pip/**. So editing requirements.in on this branch makes Verify committed lock is up to date fail — a fourth red check — until the recompiled bytes are transcribed back from that step's head -60 diff on a second push. That is the #546/#547 dance, and it belongs in a dependency PR of its own rather than inside a PR about type generation and a pro-forma card. anyio carries exactly two hashes, so the diff will fit inside head -60 when someone does run it.

3 — Android debug build — a third-party action, upstream

[command] …/cmdline-tools/20.0/bin/sdkmanager tools
Warning: Failed to find package 'tools'
Error: The process '…/sdkmanager' failed with exit code 1

android-actions/setup-android@40fd30f (v4) is invoked with no inputs, so this is its default package set; Google has removed the deprecated tools SDK package from the remote repository. The job died in setup, before any build step ran, and names a toolchain the diff does not touch. No re-run spent: the remote repository either has the package or does not, so a second attempt answers nothing.

The likely fix is a with: packages: list on that step omitting tools — written as "likely" on purpose. I cannot read android-actions/setup-android's action.yml from this session to confirm the input's name and default, and guessing at another action's internals is exactly the unwritten precondition this PR's own gate work is about. Someone who can read it should pin the input rather than take my word for the spelling.

Where that leaves the PR

API test gate is still running; everything else that can be green is green — web typecheck/test/build, both CodeQL analyses, the Postgres alembic parity job, the web and converter container builds, sbom. Locally on this exact tree: 719/719 backend suites, 0 failures, and 266 files / 2,875 web tests. I'll keep watching and re-check on a timer.

---

Generated by Claude Code