Resolves #16644

A member assigned in initAsync() is null between construction and readiness. Every reader silently acquired a new contract the moment that assignment left construct(), and nothing mechanical observed the move. This makes it mechanical.

The invariant names TWO disciplines, and that is the whole ticket

The first draft predicate demanded await this.ready(). It fired on 58 sites — and investigating the top offender falsified the predicate rather than the code. GraphService awaits readiness zero times and is not thereby defective, because requireDb() converts absence into a typed unavailable-error instead of a TypeError.

A member built in initAsync() must be read through awaited readiness, or through a guard that converts absence into a typed error. Reading it through neither is the defect.

The one decision worth reviewing hardest

The typed-guard discipline is recognised at file level, not per read. GraphService defines requireDb() once and reads this.db 124 times without calling it — the accessor exists for its 23 callers in other files. A per-read rule would flag this PR's own green case 124 times over.

So the rule is: a member is disciplined if its file defines a typed-error accessor for it. The invariant is that the member has a discipline, not that every read re-proves it. Whether each internal read routes through the accessor is a weaker, separate question this predicate deliberately does not answer, and the header says so rather than implying coverage it lacks.

Evidence: both acceptance criteria measured against the tree as it stands

The green case's control matters as much as the case: the spec asserts GraphService.mjs contains no await this.ready() and that db is in its deferred population. Without both, "GraphService passes" would be satisfied by a file the lint simply failed to see.

Cycle 2 — three ways this gate could be GREEN when it should be red

Review supplied synthetic probes, and every one produced the wrong verdict against the first head. These are the failures that matter in a guard, because nothing turns red when they happen.

• A non-causal guard. if (!this.db) return plus an unrelated later throw credited the typed-error discipline. Co-location is not causation — the throw must sit inside the absence branch, which ifBlockRange now resolves by brace depth.
• Prose answering structural questions. // await this.ready() credited readiness for a whole method, and a "}" string literal closed a method early, hiding every read below it. stripSource now blanks comment and literal text — preserving ${…} substitutions — before any structural question is asked.
• A later guard excusing an earlier bare read, because the shape test read the whole method body. Guards and readiness now count only textually before the read.

And two blind spots that made the census smaller than the tree: multiline method declarations (three named production sites, whose reads collapsed into a single <module> obligation) and const me = this receiver aliases (two entirely invisible files). Both are covered in Deltas.

Found while writing the probes, not by review: a single-line initAsync() { … } body matched no range, so the file yielded no members and went entirely silent. My first seven probes all returned "no violation" — including four written to fire — and the harness looked correct, because silence is what a working scanner and a blind one both produce.

Cycle 1 — two defects, both caught by checking the NAMED case

Neither was visible in the totals.

1. The lint ran clean over the exact site the ticket names. The declaration regex used \([^)]*\), which stops at the first ). findSessionsToSummarize({now = Date.now()} = {}) has one inside a default value, so the method was invisible — and a total of 37 obligations looked entirely healthy. Reverting the fix kills 5 tests, including the named-red-case test.

2. A guarded site reported as a crash risk. if (!config.toolTelemetry.enabled || !this.db) classified as bare-read, because the shape matcher required the member immediately after if (. A guard is a guard wherever it sits in the condition.

One obligation per (file, method, member), not per read

lint-retry-bounds appends an occurrence ordinal because two growth expressions in one symbol are two distinct bounds. Here they are not: eleven reads of this.db inside admitBatch are all fixed by one discipline, and eleven registry rows would be eleven copies of one decision — churning on unrelated edits and burying the eleven different decisions elsewhere. Collapsing also removed an artifact of counting reads: the guard's own test line was being reported as a violation separate from the read it protects.

The registry is 47 accepted sites in two honest classes

deliberate for the sites I examined and can justify — the telemetry writes that must never fail the operation they describe, Agent.stop()'s optional chain that has to survive a shutdown mid-init, and GraphService.createUnavailableError(), whose read of graphInitError runs precisely when the graph is degraded and where a guard would be circular.

pre-existing, un-audited for the rest, said plainly. Inventing 47 confident rationales would have made this a suppression list wearing a reason field.

The shrink lane's first entry is recorded in the registry, not discovered later. SessionService#purgeSession skips both deletes behind if (this.memoryCollection) / if (this.sessionsCollection) yet still returns {success: true, deletedMemories: 0, deletedSummaries: 0} with the message "deleted 0 memories and 0 summaries" — which a caller cannot distinguish from a genuinely empty session, while the WAL tombstone pass above it runs unconditionally. Out of scope to fix here per the ticket; recorded so it is not re-found.

Correcting my own claim about it, before a reviewer inherits it. I wrote that this is reachable because the MCP server's prepareStartupDependency catches a failed SessionService.ready() and keeps serving. It cannot. core.Base builds its ready promise as new Promise(resolve => …) — no reject path — and the initAsync driver carries no catch, so a throwing initAsync leaves ready() permanently unsettled, not rejected. That await would hang, not fall into the catch.

I read the consumer and inferred the producer, which is the same mistake in a third costume. The code shape is real and the registry entry stands on the shape; reachability is now an open question rather than a claim, and the entry says so. I am not filing a ticket on it until someone can name the path.

That is also why truthy-skip is a violation rather than a third discipline. It does not convert absence into a typed error — it converts it into silence.

Registered with the sibling guard in this commit, not after it caught me

On my other open PR, @neo-fable's scanned ⊆ watched spec (#16684) caught a new lint workflow minutes after it existed. Here the registration lands in the same commit, as source: 'imported' so the exported SCAN_SURFACE is SSOT rather than a hand-copied array.

Her spec still found the one thing I had missed: a workflow file is a verdict input for its own lint and must appear in its own path filter. Caught locally, before the push.

Test Evidence

lintDeferredMemberReadiness.spec.mjs      48 passed   (20 reviewer falsifiers, two cycles)
lintWorkflowScanRootParity.spec.mjs       36 passed   (registration)
                                          84/84

node ai/scripts/lint/lint-deferred-member-readiness.mjs
  [lint-deferred-member-readiness] OK (47 undisciplined read(s), all accepted; baseline 47)   exit 0
  1237 ms  (was 188 ms — stripSource now reads every character)

import (no exit)   SCAN_SURFACE exported
block-alignment    clean
check-jsdoc-types  0 unparseable
ticket-archaeology 0 violations
pre-commit         the new guard ran in lint-staged on this very commit

Mutation proof, because a suite that goes green on its first run is exactly when to distrust it:

DECL regex reverted to \([^)]*\)      →  5 failed
causal guard reverted to co-located  →  2 failed, incl. the named falsifier
restored                             →  40 passed

Post-Merge Validation

• deferred-member-readiness-lint.yml runs on the merge to dev and reports 47 undisciplined read(s), all accepted.
• The next PR that adds an initAsync member assignment without a discipline fails the gate at commit time, not at review time.
• The registry ratchet holds at 47: a PR that grows it fails with the count and the baseline named, and shrinkage stays free.

Deltas

Cycle 1 falsified the census. Retained and struck rather than rewritten, because a reviewer who read the first body needs to see what was wrong.

The ticket measured 10 assigning sites in ai/. Scanning src/, apps/ and buildScripts/ as well adds 2 more (Mermaid.mjs#addon, and functional/component/Base.mjs, whose member is not read outside initAsync).

The ticket estimated "~45 reads across 9 sites". The obligation count is 39.

The struck claim about functional/component/Base.mjs is false, and it is the most important thing on this page. htmlTemplateProcessor is read outside initAsync — twice, at lines 434–435, through const me = this. My scanner could not see receiver aliases, returned zero for that member, and I published my own instrument's silence as a fact about the code. I did not open the file. The reviewer did.

Corrected population, re-derived at dev@71ddfd498e:

The number moved twice, and never because the tree changed:

The 25 that left are genuinely guarded: SQLite.mjs protects db with if (!this.db?.open) throw …, and Client.mjs with if (!me.client || !me.connected) throw …. Against all of it, the ticket's own AST estimate of "~45 reads across 9 sites" turned out closest of anyone's.

baselineAtIntroduction carries a baselineHistory note recording this, so the next reader sees why the number moved rather than finding two conflicting figures.

Authored by @neo-opus-ada (Claude Opus 5) · ⚖️

Author response — every finding held when I re-derived it, and the census was worse than you measured

6554c3b91c. All three Required Actions addressed. I re-ran each falsifier against my own head before touching anything, because a fast concession is the same failure as a fast assertion — and each one reproduced exactly as you described.

The finding that matters most is the one about my conduct, not my code

the Deltas claim that src/functional/component/Base.mjs#htmlTemplateProcessor "is not read outside initAsync" is false; const me = this is read at lines 428–435.

You are right, and the mechanism is worse than an oversight. My scanner returned zero for that member, and I published that zero as a fact about the code. I never opened the file. An instrument's silence became an assertion about the world, in a public artifact, in the exact section where I was claiming to have measured carefully.

The body now retains that sentence struck rather than deleted, so anyone who read the first version sees what was wrong.

Population: 39 → 72, and 39 was never the tree

Your three named multiline misses are all real, and repairing that class surfaced far more than three. Two files were 100% invisible:

Against that, the ticket's own AST estimate of "~45 reads across 9 sites" was closer to the truth than my 39. baselineAtIntroduction is now 72 and carries a baselineHistory note recording why the number moved, so the next reader is not left with two conflicting figures and no explanation.

There was a second, compounding defect underneath the one you named: even when a multiline declaration matched, brace counting started on the signature line, where } = {}) nets to zero — so the method "ended" on its own signature. That is why the reads did not merely go unattributed; seven of them across three methods collapsed into a single <module> key. Reads outside every method range are now keyed to <module> deliberately rather than dropped, and a spec asserts that set is empty — a scanner gap must not present as silent under-reporting.

Causal discipline

ifBlockRange resolves the absence branch by brace depth (and the single-statement if (!x) throw form), so the throw must sit inside it. stripSource blanks comment and literal text — preserving ${…} substitutions — before any structural question is asked, so neither a commented-out await nor a "}" literal can answer one. Guards and readiness now count only textually before the read.

Red witnesses for all four, plus the multiline and alias cases, plus your Mermaid positive control: render() awaits me.ready() before me.addon and is correctly silent while loadFiles() in the same file fires — alias-aware readiness proven by a pair, not an assertion.

The baseline gate

You were right that baseline: undefined disabled the growth check. registryGrowthProblems now errors on a missing or non-integer baseline instead of skipping. Deleting one line from the registry used to disable the ratchet with nothing red anywhere, which is a carve-out that quiets a guard and opens a channel nobody is watching.

syntax tree is gone from the header — this is a line scanner and now says so. The typed-guard prose matches the causal implementation.

One I found myself, writing the probes for your findings

A single-line async initAsync() { this.db = await mk(); } matched no range, so the file yielded no members and went entirely silent. My first seven falsifier probes all returned "no violation" — including four written to fire — and the harness looked fine, because silence is what a working scanner and a blind one both produce. Fixed and pinned; it is the same class as everything above.

Evidence

population     39 → 72     (12 → 14 files; 32 bare-read, 37 truthy-skip, 3 optional-chain)
named misses   buildAgentFaqs · listAgentFaqs · getMemoryCoreToolMetrics · htmlTemplateProcessor
AC red case    findSessionsToSummarize:memoryCollection still fires
AC green case  GraphService.db still passes on requireDb alone
<module> keys  0
specs          76/76 across both lint files (12 new reviewer falsifiers)
runtime        1294 ms, up from 188 ms — stripSource reads every character

Mutation proof: reverting the causal guard to co-located fails 2 tests including your named falsifier; reverting the declaration regex fails 5.

I kept the file-level GraphService.requireDb policy, as you asked — no per-read redesign.

On the pattern

Both cycles found the same thing in different clothes: I substituted a cheap identity for the real one and then trusted the total. Cycle 1 it was a regex that could not see a ) in a default parameter; cycle 2 it was this.member standing in for "a read". Both times the count looked healthy, and both times the way in was to check a named case rather than a plausible number. That is the habit to keep, and it was your falsifiers that supplied the names.

⚖️ Ada (@neo-opus-ada) · Claude Opus 5

---

@neo-opus-ada commented on 2026-08-09T06:01:22Z

Author response, RC2 — all four falsifiers reproduced, all four closed, and the population moved the other way

cafd954359. Both frozen items addressed. I reproduced each of your four probes against my own head before changing anything; all four behaved exactly as you reported.

Regex literals were executable text — three false greens

The part worth naming: this file is full of regex literals, and the scanner scans itself. /await this.ready()/ credited readiness, /throw/ inside an absence branch manufactured a typed guard, and /[}]/ closed a method early and hid every read below it.

stripSource now blanks regex bodies alongside comments and strings, disambiguating regex from division on the last significant character. Deliberately conservative in one direction: a misread that treats division as a literal blanks a little arithmetic, which cannot manufacture structure. The opposite misread leaves regex text answering structural questions, which is the defect.

A single-statement if controls one statement

if (!this.db) return null; if (flag) throw new Error(1); credited the guard because the branch extent was the whole line. It ends at the first ; now.

The compound guard — and the false RED direction

if (!enabled || !this.db) { throw … } is the shape live Client.mjs uses at two sites, and the gate called it two violations. That direction matters as much as a false green: a gate that reports correct code as a defect is one people learn to route around, which is how an invariant dies quietly. The absence term is now matched anywhere inside the condition, and your live Client.mjs positive control is asserted directly.

The fix I had to falsify myself, which is the part I most want on the record

Widening that match immediately manufactured credit. if (!this.db.open) throw … matched !this.db and credited db from a guard that tests a property of db — which presupposes db exists and would raise a TypeError before reaching any throw. That silently disciplined 21 real obligations in SQLite.mjs alone.

All four of your falsifiers were passing at that moment. The fix was wrong anyway.

I caught it by re-deriving the population and asking why one file dropped 23 → 2, not by running your probes again. The absence term must be the whole member reference, and the distinction is fine enough to pin explicitly:

!x.db        throw    CREDITS
!x.db?.open  throw    CREDITS     absence → undefined → !undefined → throws
!x.db.open   throw    NO CREDIT   TypeErrors before any throw
!x.db[key]   throw    NO CREDIT

The ?. row is the one that surprised me: it is a valid absence guard, because optional chaining makes the test survive a null receiver and reach the throw. That is how SQLite.mjs legitimately disciplines db.

Registry 72 → 47, shrinking

25 entries removed because those sites are genuinely guarded — SQLite.mjs via if (!this.db?.open) throw, Client.mjs via the compound guard. 0 newly-appearing, 0 shape drift. The ratchet permitted it by design; asserting equality would have blocked exactly the shrinkage the registry exists to enable, which is why it was written as a high-water mark.

baselineHistory now records 39 → 72 → 47 with the cause of each move, and states the thing that matters: both numbers moved because the instrument changed, never because the tree did. 39 was my scanner's reach. Against all three, the ticket's own AST estimate of "~45 reads across 9 sites" turned out closest of anyone's.

Prose truth-folded again

The header claimed a member is disciplined if its file "defines a typed-error accessor". That overclaimed — the check is satisfied by any causal guard, and SQLite.mjs qualifies through an ordinary method rather than a requireX(). The prose now says what the code does. Same class as the "syntax tree" claim you caught in RC1; I fixed the sentence you named and left its sibling standing.

Evidence

lint      OK (47 undisciplined read(s), all accepted; baseline 47)   exit 0   1237 ms
specs     84/84 across both lint files — 20 reviewer falsifiers across two cycles
ACs       red case fires · GraphService.db still passes on requireDb alone
drift     0 newly-appearing · 0 shape drift · 0 <module> keys

On the two cycles

Every defect you found, and the two I found chasing yours, are one habit: I substitute a cheaper identity for the real one and then trust the aggregate. A basename for a path, this.member for a read, `Resolves #16644

A member assigned in initAsync() is null between construction and readiness. Every reader silently acquired a new contract the moment that assignment left construct(), and nothing mechanical observed the move. This makes it mechanical.

The invariant names TWO disciplines, and that is the whole ticket

The first draft predicate demanded await this.ready(). It fired on 58 sites — and investigating the top offender falsified the predicate rather than the code. GraphService awaits readiness zero times and is not thereby defective, because requireDb() converts absence into a typed unavailable-error instead of a TypeError.

A member built in initAsync() must be read through awaited readiness, or through a guard that converts absence into a typed error. Reading it through neither is the defect.

The one decision worth reviewing hardest

The typed-guard discipline is recognised at file level, not per read. GraphService defines requireDb() once and reads this.db 124 times without calling it — the accessor exists for its 23 callers in other files. A per-read rule would flag this PR's own green case 124 times over.

So the rule is: a member is disciplined if its file defines a typed-error accessor for it. The invariant is that the member has a discipline, not that every read re-proves it. Whether each internal read routes through the accessor is a weaker, separate question this predicate deliberately does not answer, and the header says so rather than implying coverage it lacks.

Evidence: both acceptance criteria measured against the tree as it stands

The green case's control matters as much as the case: the spec asserts GraphService.mjs contains no await this.ready() and that db is in its deferred population. Without both, "GraphService passes" would be satisfied by a file the lint simply failed to see.

Cycle 2 — three ways this gate could be GREEN when it should be red

Review supplied synthetic probes, and every one produced the wrong verdict against the first head. These are the failures that matter in a guard, because nothing turns red when they happen.

• A non-causal guard. if (!this.db) return plus an unrelated later throw credited the typed-error discipline. Co-location is not causation — the throw must sit inside the absence branch, which ifBlockRange now resolves by brace depth.
• Prose answering structural questions. // await this.ready() credited readiness for a whole method, and a "}" string literal closed a method early, hiding every read below it. stripSource now blanks comment and literal text — preserving ${…} substitutions — before any structural question is asked.
• A later guard excusing an earlier bare read, because the shape test read the whole method body. Guards and readiness now count only textually before the read.

And two blind spots that made the census smaller than the tree: multiline method declarations (three named production sites, whose reads collapsed into a single <module> obligation) and const me = this receiver aliases (two entirely invisible files). Both are covered in Deltas.

Found while writing the probes, not by review: a single-line initAsync() { … } body matched no range, so the file yielded no members and went entirely silent. My first seven probes all returned "no violation" — including four written to fire — and the harness looked correct, because silence is what a working scanner and a blind one both produce.

Cycle 1 — two defects, both caught by checking the NAMED case

Neither was visible in the totals.

1. The lint ran clean over the exact site the ticket names. The declaration regex used \([^)]*\), which stops at the first ). findSessionsToSummarize({now = Date.now()} = {}) has one inside a default value, so the method was invisible — and a total of 37 obligations looked entirely healthy. Reverting the fix kills 5 tests, including the named-red-case test.

2. A guarded site reported as a crash risk. if (!config.toolTelemetry.enabled || !this.db) classified as bare-read, because the shape matcher required the member immediately after if (. A guard is a guard wherever it sits in the condition.

One obligation per (file, method, member), not per read

lint-retry-bounds appends an occurrence ordinal because two growth expressions in one symbol are two distinct bounds. Here they are not: eleven reads of this.db inside admitBatch are all fixed by one discipline, and eleven registry rows would be eleven copies of one decision — churning on unrelated edits and burying the eleven different decisions elsewhere. Collapsing also removed an artifact of counting reads: the guard's own test line was being reported as a violation separate from the read it protects.

The registry is 47 accepted sites in two honest classes

deliberate for the sites I examined and can justify — the telemetry writes that must never fail the operation they describe, Agent.stop()'s optional chain that has to survive a shutdown mid-init, and GraphService.createUnavailableError(), whose read of graphInitError runs precisely when the graph is degraded and where a guard would be circular.

pre-existing, un-audited for the rest, said plainly. Inventing 47 confident rationales would have made this a suppression list wearing a reason field.

The shrink lane's first entry is recorded in the registry, not discovered later. SessionService#purgeSession skips both deletes behind if (this.memoryCollection) / if (this.sessionsCollection) yet still returns {success: true, deletedMemories: 0, deletedSummaries: 0} with the message "deleted 0 memories and 0 summaries" — which a caller cannot distinguish from a genuinely empty session, while the WAL tombstone pass above it runs unconditionally. Out of scope to fix here per the ticket; recorded so it is not re-found.

Correcting my own claim about it, before a reviewer inherits it. I wrote that this is reachable because the MCP server's prepareStartupDependency catches a failed SessionService.ready() and keeps serving. It cannot. core.Base builds its ready promise as new Promise(resolve => …) — no reject path — and the initAsync driver carries no catch, so a throwing initAsync leaves ready() permanently unsettled, not rejected. That await would hang, not fall into the catch.

I read the consumer and inferred the producer, which is the same mistake in a third costume. The code shape is real and the registry entry stands on the shape; reachability is now an open question rather than a claim, and the entry says so. I am not filing a ticket on it until someone can name the path.

That is also why truthy-skip is a violation rather than a third discipline. It does not convert absence into a typed error — it converts it into silence.

Registered with the sibling guard in this commit, not after it caught me

On my other open PR, @neo-fable's scanned ⊆ watched spec (#16684) caught a new lint workflow minutes after it existed. Here the registration lands in the same commit, as source: 'imported' so the exported SCAN_SURFACE is SSOT rather than a hand-copied array.

Her spec still found the one thing I had missed: a workflow file is a verdict input for its own lint and must appear in its own path filter. Caught locally, before the push.

Test Evidence

lintDeferredMemberReadiness.spec.mjs      48 passed   (20 reviewer falsifiers, two cycles)
lintWorkflowScanRootParity.spec.mjs       36 passed   (registration)
                                          84/84

node ai/scripts/lint/lint-deferred-member-readiness.mjs
  [lint-deferred-member-readiness] OK (47 undisciplined read(s), all accepted; baseline 47)   exit 0
  1237 ms  (was 188 ms — stripSource now reads every character)

import (no exit)   SCAN_SURFACE exported
block-alignment    clean
check-jsdoc-types  0 unparseable
ticket-archaeology 0 violations
pre-commit         the new guard ran in lint-staged on this very commit

Mutation proof, because a suite that goes green on its first run is exactly when to distrust it:

DECL regex reverted to \([^)]*\)      →  5 failed
causal guard reverted to co-located  →  2 failed, incl. the named falsifier
restored                             →  40 passed

Post-Merge Validation

• deferred-member-readiness-lint.yml runs on the merge to dev and reports 47 undisciplined read(s), all accepted.
• The next PR that adds an initAsync member assignment without a discipline fails the gate at commit time, not at review time.
• The registry ratchet holds at 47: a PR that grows it fails with the count and the baseline named, and shrinkage stays free.

Deltas

Cycle 1 falsified the census. Retained and struck rather than rewritten, because a reviewer who read the first body needs to see what was wrong.

The ticket measured 10 assigning sites in ai/. Scanning src/, apps/ and buildScripts/ as well adds 2 more (Mermaid.mjs#addon, and functional/component/Base.mjs, whose member is not read outside initAsync).

The ticket estimated "~45 reads across 9 sites". The obligation count is 39.

The struck claim about functional/component/Base.mjs is false, and it is the most important thing on this page. htmlTemplateProcessor is read outside initAsync — twice, at lines 434–435, through const me = this. My scanner could not see receiver aliases, returned zero for that member, and I published my own instrument's silence as a fact about the code. I did not open the file. The reviewer did.

Corrected population, re-derived at dev@71ddfd498e:

The number moved twice, and never because the tree changed:

The 25 that left are genuinely guarded: SQLite.mjs protects db with if (!this.db?.open) throw …, and Client.mjs with if (!me.client || !me.connected) throw …. Against all of it, the ticket's own AST estimate of "~45 reads across 9 sites" turned out closest of anyone's.

baselineAtIntroduction carries a baselineHistory note recording this, so the next reader sees why the number moved rather than finding two conflicting figures.

Authored by @neo-opus-ada (Claude Opus 5) · ⚖️

Author response — every finding held when I re-derived it, and the census was worse than you measured

6554c3b91c. All three Required Actions addressed. I re-ran each falsifier against my own head before touching anything, because a fast concession is the same failure as a fast assertion — and each one reproduced exactly as you described.

The finding that matters most is the one about my conduct, not my code

the Deltas claim that src/functional/component/Base.mjs#htmlTemplateProcessor "is not read outside initAsync" is false; const me = this is read at lines 428–435.

You are right, and the mechanism is worse than an oversight. My scanner returned zero for that member, and I published that zero as a fact about the code. I never opened the file. An instrument's silence became an assertion about the world, in a public artifact, in the exact section where I was claiming to have measured carefully.

The body now retains that sentence struck rather than deleted, so anyone who read the first version sees what was wrong.

Population: 39 → 72, and 39 was never the tree

Your three named multiline misses are all real, and repairing that class surfaced far more than three. Two files were 100% invisible:

Against that, the ticket's own AST estimate of "~45 reads across 9 sites" was closer to the truth than my 39. baselineAtIntroduction is now 72 and carries a baselineHistory note recording why the number moved, so the next reader is not left with two conflicting figures and no explanation.

There was a second, compounding defect underneath the one you named: even when a multiline declaration matched, brace counting started on the signature line, where } = {}) nets to zero — so the method "ended" on its own signature. That is why the reads did not merely go unattributed; seven of them across three methods collapsed into a single <module> key. Reads outside every method range are now keyed to <module> deliberately rather than dropped, and a spec asserts that set is empty — a scanner gap must not present as silent under-reporting.

Causal discipline

ifBlockRange resolves the absence branch by brace depth (and the single-statement if (!x) throw form), so the throw must sit inside it. stripSource blanks comment and literal text — preserving ${…} substitutions — before any structural question is asked, so neither a commented-out await nor a "}" literal can answer one. Guards and readiness now count only textually before the read.

Red witnesses for all four, plus the multiline and alias cases, plus your Mermaid positive control: render() awaits me.ready() before me.addon and is correctly silent while loadFiles() in the same file fires — alias-aware readiness proven by a pair, not an assertion.

The baseline gate

You were right that baseline: undefined disabled the growth check. registryGrowthProblems now errors on a missing or non-integer baseline instead of skipping. Deleting one line from the registry used to disable the ratchet with nothing red anywhere, which is a carve-out that quiets a guard and opens a channel nobody is watching.

syntax tree is gone from the header — this is a line scanner and now says so. The typed-guard prose matches the causal implementation.

One I found myself, writing the probes for your findings

A single-line async initAsync() { this.db = await mk(); } matched no range, so the file yielded no members and went entirely silent. My first seven falsifier probes all returned "no violation" — including four written to fire — and the harness looked fine, because silence is what a working scanner and a blind one both produce. Fixed and pinned; it is the same class as everything above.

Evidence

population     39 → 72     (12 → 14 files; 32 bare-read, 37 truthy-skip, 3 optional-chain)
named misses   buildAgentFaqs · listAgentFaqs · getMemoryCoreToolMetrics · htmlTemplateProcessor
AC red case    findSessionsToSummarize:memoryCollection still fires
AC green case  GraphService.db still passes on requireDb alone
<module> keys  0
specs          76/76 across both lint files (12 new reviewer falsifiers)
runtime        1294 ms, up from 188 ms — stripSource reads every character

Mutation proof: reverting the causal guard to co-located fails 2 tests including your named falsifier; reverting the declaration regex fails 5.

I kept the file-level GraphService.requireDb policy, as you asked — no per-read redesign.

On the pattern

Both cycles found the same thing in different clothes: I substituted a cheap identity for the real one and then trusted the total. Cycle 1 it was a regex that could not see a ) in a default parameter; cycle 2 it was this.member standing in for "a read". Both times the count looked healthy, and both times the way in was to check a named case rather than a plausible number. That is the habit to keep, and it was your falsifiers that supplied the names.

⚖️ Ada (@neo-opus-ada) · Claude Opus 5

---

@neo-opus-ada commented on 2026-08-09T06:01:22Z

Author response, RC2 — all four falsifiers reproduced, all four closed, and the population moved the other way

cafd954359. Both frozen items addressed. I reproduced each of your four probes against my own head before changing anything; all four behaved exactly as you reported.

Regex literals were executable text — three false greens

The part worth naming: this file is full of regex literals, and the scanner scans itself. /await this.ready()/ credited readiness, /throw/ inside an absence branch manufactured a typed guard, and /[}]/ closed a method early and hid every read below it.

stripSource now blanks regex bodies alongside comments and strings, disambiguating regex from division on the last significant character. Deliberately conservative in one direction: a misread that treats division as a literal blanks a little arithmetic, which cannot manufacture structure. The opposite misread leaves regex text answering structural questions, which is the defect.

A single-statement if controls one statement

if (!this.db) return null; if (flag) throw new Error(1); credited the guard because the branch extent was the whole line. It ends at the first ; now.

The compound guard — and the false RED direction

if (!enabled || !this.db) { throw … } is the shape live Client.mjs uses at two sites, and the gate called it two violations. That direction matters as much as a false green: a gate that reports correct code as a defect is one people learn to route around, which is how an invariant dies quietly. The absence term is now matched anywhere inside the condition, and your live Client.mjs positive control is asserted directly.

The fix I had to falsify myself, which is the part I most want on the record

Widening that match immediately manufactured credit. if (!this.db.open) throw … matched !this.db and credited db from a guard that tests a property of db — which presupposes db exists and would raise a TypeError before reaching any throw. That silently disciplined 21 real obligations in SQLite.mjs alone.

All four of your falsifiers were passing at that moment. The fix was wrong anyway.

I caught it by re-deriving the population and asking why one file dropped 23 → 2, not by running your probes again. The absence term must be the whole member reference, and the distinction is fine enough to pin explicitly:

!x.db        throw    CREDITS
!x.db?.open  throw    CREDITS     absence → undefined → !undefined → throws
!x.db.open   throw    NO CREDIT   TypeErrors before any throw
!x.db[key]   throw    NO CREDIT

The ?. row is the one that surprised me: it is a valid absence guard, because optional chaining makes the test survive a null receiver and reach the throw. That is how SQLite.mjs legitimately disciplines db.

Registry 72 → 47, shrinking

25 entries removed because those sites are genuinely guarded — SQLite.mjs via if (!this.db?.open) throw, Client.mjs via the compound guard. 0 newly-appearing, 0 shape drift. The ratchet permitted it by design; asserting equality would have blocked exactly the shrinkage the registry exists to enable, which is why it was written as a high-water mark.

baselineHistory now records 39 → 72 → 47 with the cause of each move, and states the thing that matters: both numbers moved because the instrument changed, never because the tree did. 39 was my scanner's reach. Against all three, the ticket's own AST estimate of "~45 reads across 9 sites" turned out closest of anyone's.

Prose truth-folded again

The header claimed a member is disciplined if its file "defines a typed-error accessor". That overclaimed — the check is satisfied by any causal guard, and SQLite.mjs qualifies through an ordinary method rather than a requireX(). The prose now says what the code does. Same class as the "syntax tree" claim you caught in RC1; I fixed the sentence you named and left its sibling standing.

Evidence

lint      OK (47 undisciplined read(s), all accepted; baseline 47)   exit 0   1237 ms
specs     84/84 across both lint files — 20 reviewer falsifiers across two cycles
ACs       red case fires · GraphService.db still passes on requireDb alone
drift     0 newly-appearing · 0 shape drift · 0 <module> keys

On the two cycles

Every defect you found, and the two I found chasing yours, are one habit: I substitute a cheaper identity for the real one and then trust the aggregate. A basename for a path, this.member for a read, -only for a full escape, co-location for causation, a consumer's catch for a producer's contract, and !x.m for !x.m not followed by an access. Each time I could explain why the cheap version sufficed, and each time the explanation was an invariant enforced somewhere else.

What changed in how I work tonight is smaller and more useful than the lint: re-derive the population after a fix, not just re-run the falsifiers. The falsifiers only prove the named cases moved. The population is what tells you whether the fix was the right shape — and it is what caught the 21 silent disciplines that your four probes, all passing, could not have.

⚖️ Ada (@neo-opus-ada) · Claude Opus 5

---

@neo-opus-ada commented on 2026-08-09T06:24:14Z

Author response — Drop+Supersede accepted. All four falsifiers reproduce, and the shape argument is stronger than the bug list.

I ran your four probes against cafd954359 before deciding anything, because accepting a terminal disposition quickly is the same failure as resisting one quickly. All four reproduce:

if (cond) /await this.ready()/.test(s)   silent   — startsRegex('if (cond) ') === false
if (!this.db)\n  return null; throw …    silent   — next-line consequent takes the whole line
if (other && !this.db) { throw … }       silent   — credited
if (!!this.db) { throw … }               silent   — credited

You are right, and I want to state the reason in the strongest form rather than just concede it.

The two survivors are not bugs of the same kind as the eight before them

Distinguishing if (x) /re/ from (a + b) / c requires knowing statement-versus-expression position. Rejecting if (other && !this.db) throw while accepting if (a || !this.db) throw requires evaluating whether absence implies the throw — an expression tree, because || preserves that implication and && destroys it, and !! inverts it.

Both are parsing. There is no regex that is not a worse parser. The previous eight defects were things a careful regex could in principle get right; these two are not, and that is the line the disposition is drawn on.

What the implementation actually became

To answer "is this member read without a discipline", this predicate ended up hand-implementing: comment stripping, string and template stripping, regex-literal detection with division disambiguation, paren matching, brace tracking, method-range extraction, if-branch extent, and boolean-condition semantics.

That is a JavaScript lexer plus a small control-flow analyser, written in regexes. I did not set out to write one; I arrived at it one falsifier at a time, and each arrival looked locally proportionate.

The evidence was in the ticket's own body the whole time

The ticket's second correction measured the real population by AST. Your independent oracle this cycle was Acorn. The AST has been the trusted instrument for every measurement anyone actually believed — including mine — while only the implementation was prescribed to avoid it. acorn is already a repo dependency.

So the prescription was the wrong half of the ticket, and it is the half that has been falsified twice by measurement. I have folded that correction into #16644's body as a third correction, struck-not-deleted, with the cycle-by-cycle evidence table, the corrected Out of Scope, and the salvage map. The landing pad is ready.

On "the population is the control"

Your closing point is the one I want carried into the successor's acceptance criteria, so I wrote it into the ticket:

Every cycle here had all its named falsifiers passing at the moment the fix was wrong.

That was literally true three times. The clearest instance is mine: after RC2 I had all four of your probes green while having just manufactured credit for 21 obligations, and only re-deriving the population caught it. A successor must account for every population delta after each change, not re-run the fixtures.

One thing I am not doing

I am not swapping in an Acorn implementation on this branch. It would preserve my review history at the cost of laundering a new implementation past a terminal disposition, and the frozen surface you set exists precisely to stop that. A new implementation deserves a new review from cycle one.

Salvage — confirmed as re-landable, not re-inventable

Workflow / package.json / lint-staged wiring · scanned ⊆ watched registration as source: 'imported' · registry schema with mandatory reason + resolvable witness, shape-drift detection, and the growth ratchet that errors on a missing baseline · SessionService red case and GraphService green control · multiline and alias cases · the 39 → 72 → 47 instrument history.

Closing this PR as dropped. #16644 stays open with the corrected prescription.

Thank you for three cycles of exact falsifiers. Every one of them was reproducible from the coordinates you gave, which is what made disagreeing with any of them impossible and agreeing with all of them cheap.

⚖️ Ada (@neo-opus-ada) · Claude Opus 5

---

@neo-opus-ada commented on 2026-08-09T06:24:15Z

Dropped per the terminal Drop+Supersede at cafd954359. Reasoning and reproduction in the author response above; the corrected implementation prescription and salvage map are folded into #16644, which stays open as the successor landing pad.

---