docs(test-plan): the BACKLOG #1100 master-test-plan audit -- PR 433's clean half, split per owner ruling - #614
Merged
Merged
Conversation
…ng test plan (BACKLOG #1100) Five cells in chapter 15 assert that the alert/security-notify STARTTLS hop is unauthenticated and that docs/PHI.md and docs/BACKLOG.md contradict each other about it. BOTH PREMISES WERE ALREADY FALSE WHEN THE PLAN WAS WRITTEN: #323 closed it on 2026-08-02. I VERIFIED BOTH PRECONDITIONS AGAINST THE CODE BEFORE TOUCHING A WORD, because this chapter's only P0 "with a real security consequence" was one of the cells, and correcting it wrongly would have silently closed a live security question: alert_sinks.py:385 states "The STARTTLS hop is VERIFIED (#323, layer 3)", and :430-431 pass it -- `smtp.starttls(context=tls_context)`, commented "context= is REQUIRED (#323): starttls()'s own default verifies NOTHING". docs/PHI.md ROW 11 (:1015) states the verifying posture in full -- explicit context, chain + hostname + strict RFC 5280, TLS 1.2 floor, via tls_policy.build_smtp_tls_context() -- and records the pre-#323 state as history. tests/test_alert_smtp_tls.py exists, 21 tests. THE TRAP THAT NEARLY CAUGHT ME IS IN THE FILE I WAS READING. alert_sinks.py:387-388 describes `ssl._create_unverified_context`, `CERT_NONE`, `check_hostname=False` -- in the PAST TENSE, as the defect #323 fixed. Read as current, it confirms the plan's claim exactly. The first pass of this work stopped and reported the preconditions as UNMEASURED rather than guess which tense governed; the answer came from :385 and :430-431, not from :387. THE TESTS SURVIVE; ONLY THE PREMISE GOES. ALERT-08, 58 and 67 are still worth building -- pinning the posture at send time and binding the docs to the code catch a FUTURE divergence, which is the only thing they were ever able to catch. What changed is that ALERT-67 is now expected to PASS on arrival rather than "fail today", and S4's manual matrix expects a self-signed and a hostname-mismatched cert to be REJECTED. Running S4 against the old sentence would have recorded three passes as the expected result and read a working control as a finding. THE EXIT CRITERION WAS THE WORST OF THE FIVE: "the three contradicting documents agree with the code", naming a contradiction that was already resolved. An exit criterion demanding that a resolved contradiction be resolved CANNOT FAIL, so passing it says nothing while a reader believes a check ran. AND OQ-3 WAS THE MOST EXPENSIVE: an OPEN P0 blocking four rows, describing a fix as a live exposure. Its second half has a recorded answer too -- this path did NOT adopt the connector hop gradient; its deviations are gated by a [security].allow_unverified_alert_smtp_tls acknowledgment switch at the serve gate. It blocks nothing. Each dead assertion is QUOTED inside its correction rather than deleted, so a reader can see what the plan used to claim and why it was wrong -- the same reason #1215's marker paragraph records both of its inversions. A grep for the old strings therefore still matches, inside the corrections. SCOPE: this is the clearest cluster only -- five cells in 15-alerting-and-observability.md, whose premise I verified. The item names NINE sites; the other four are NOT verified and the item stays open for them. The cited docs/BACKLOG.md:5152 anchor has drifted and is flagged in place as re-derive-by-content. Verified: 112 passed / 91 skipped across the test-plan, doc-drift, feature-map and phi-logging suites; no-glyph cp1252 test run against the DIFF rather than the file, because the chapter carries pre-existing glyphs that are not mine to sweep. My added lines introduce none.
…r test plans (BACKLOG #1100) Both rows were re-measured against the current tree, and both were making claims the code and docs had already overtaken. 02-pipeline-reliability.md: the Postgres 2-engine crash-and-restart row said tests/test_shard_recovery_postgres.py "runs nowhere". It runs -- in ci.yml's postgres-store job -- but that job is gated on schedule || workflow_dispatch || serverdb == 'true', so it does not run on a PR that touches no server-DB path. "Runs nowhere" understates the coverage and "runs in CI" would overstate it; only the gated form supports a decision about PIPE-01, which is what the row exists to inform. 05-connections-and-transports.md: the "CONNECTIONS.md contradicts the code" row is fully closed. SFTP-IN, REST-IN and SMTP-OUT are all marked shipped now; DB-IN agrees with FEATURE-MAP's "Production" rather than contradicting it; SOAP-IN is receive-only rather than planned; and all six connectors the row called undocumented have settings headings. FHIR-IN still reads "planned" and that is correct -- the facade is unshipped -- so the row's inference (the listener is built, therefore FHIR-IN is built) does not follow: shipping the substrate does not ship the facade. Both rows are rewritten in place rather than deleted, so the re-measurement is auditable and the tables keep their shape. All seven line citations in the connector row had drifted off their subjects and had to be re-found by content before any of them could be judged; that is the sixth recorded instance of the anchor rule this sweep has produced.
… run (BACKLOG #1100) Both rows asserted that live server-DB suites are invoked by no workflow. Measured against ci.yml by parsing the YAML rather than grepping it: Row 80: tests/test_cluster_failover_postgres.py runs at ci.yml:1570, in the postgres-store job's step "Run the failover + engine-shard recovery suites on real Postgres". The anchor the row cites as its evidence, ci.yml:614, has drifted and now lands on a comment about arithmetic. Row 81: all six DR suites exist and all six are invoked -- the Postgres trio by postgres-store, the SQL Server trio by sqlserver-store, each in a step named for exactly those suites. BOTH STAY P0. The residual risk is real, but it is a GATING risk rather than an absence: both jobs carry schedule || workflow_dispatch || serverdb == 'true', so a PR that changes election or DR logic without touching a server-DB path still ships unverified. "Detected today?" moves from "No" to "Partly -- on the gated server-DB leg only, never on an ordinary PR", which is the form that supports a decision. "No" understates the coverage and a bare "yes, it runs" would overstate it. Row 81's MEFOR_TEST_* env gating is a SECOND, INDEPENDENT condition and was not re-measured here. The row now says so, so that correcting one half of its claim does not read as clearing the whole row. Found by transferring probe 6's shape rather than by a new search: the identical "runs nowhere" phrasing about a sibling Postgres suite was already falsified in 02-pipeline-reliability.md, and the two test files turn out to sit on consecutive lines of the same CI step. A defect class, once named, is worth re-running across the corpus -- this is the third and fourth instance of it.
…w that says it cannot (BACKLOG #1100) 05-connections-and-transports.md row 98 claimed "Inbound HTTP listener has no application-layer authentication", evidenced by "grep for auth/Authorization/ bearer/hmac in http_listener.py returns 0 hits". EVERY PART OF THAT EVIDENCE IS NOW FALSE: the same grep measures 52 matching lines; Http() does not expose "caps + TLS/mTLS only"; ADR 0023 no longer defers auth -- ADR 0154 (Accepted 2026-07-31) is titled its "deferred tail" and delivered it. Built and measured: intake_auth: Literal["none","api_key","bearer", "mtls_subject"], enforced by _authorize_head (http_listener.py:618) with a 401 plus WWW-Authenticate, credentials env()-only, rotation via intake_api_key_next, health probes inside the gate by default, and failed-attempt rate limits at 10/min/peer and 60/min global. The row's "Covered?" cell is equally stale: there is a dedicated tests/test_inbound_http_intake_auth.py plus four more files, 18 test functions naming the surface. THE ROW STAYS P1 BECAUSE ITS CONCERN SURVIVES ITS EVIDENCE, IN A NARROWER FORM. intake_auth defaults to "none" and _authorize_head returns early when unset, so a site deploying the listener off-loopback without setting it would accept unauthenticated POSTs. That is now an explicit, documented, tested opt-in rather than an implicit omission -- a different decision, and the only one still open is whether "none" is the right default for a PHI intake path. Written in the conditional per CLAUDE.md section 0: there are no deployments, so this is what a deploying site would hit, not something happening now. Found by a reversed discriminator: rows asserting a grep returns ZERO hits go stale precisely because code gets added. Four such claims exist in the plan; this is the one that broke, and the other three (ADR coverage-plan hits in 05:95 and 09:122, and 0 occurrences of "validate" in 06:86) were re-measured and HOLD.
…G #1100) 05-connections-and-transports.md row 105 said five ADR status lines contradict their code. Re-measured against the ADR files, both halves of each claim: 0011 "Proposed" transports/timer.py, 341 lines LAGS 0015 "No code written yet" transports/soap.py, 844 lines LAGS 0016 "No code written yet" tests/test_x12_rte.py, 625 lines LAGS 0022 "Design-only (no code yet)" test_ack_capture_runner.py, fhir.py LAGS 0021 "No code yet" -> NOW READS "Built and shipped" FIXED ADR 0021's status has been corrected since the row was written and now reads "Accepted (2026-06-19, owner go). Built and shipped (eventlog #16, Lane S)". It is struck from the count rather than left inflating it. The row keeps its point and its priority: four is still four, and a wrong ADR status is still a governance defect. What changes is that a count carried forward without re-measurement drifts upward relative to reality -- 0021 is itself the evidence that these get fixed one at a time, so the count has to be re-derived rather than quoted. Found by generalising the discriminator that broke row 98 in the same file: that row cited "ADR 0023 defers auth" when ADR 0154, titled ADR 0023's "deferred tail", had closed it. A plan row citing an ADR's status is asserting something about a FILE THAT MOVES INDEPENDENTLY of the plan, which makes it stale by construction.
…s one drifted anchor (BACKLOG #1100) 04-high-availability-and-dr.md row 97 was probed for staleness and turned out to be CORRECT. Every claim re-measured: FEATURE-MAP omits ADR 0047/0048/0049/0056/0096 0 grep hits each TRUE BACKLOG #100 ranked Tier cell still reads "P1" BACKLOG.md:373 TRUE BACKLOG #101 ranked Tier cell reads DEMAND-GATE BACKLOG.md:380 TRUE ADR 0096 is Accepted TRUE code is in settings.py:2896-2910 that range is now ADR 0014 alert rules DRIFTED Only the code anchor was wrong. The ADR 0096 surface is `promotable: bool = True` at settings.py:3026, with its explanation from :3016, so the citation is corrected to settings.py:3016-3026 and named rather than left as a bare line range. The row is annotated as re-verified rather than rewritten, because a sweep that only marks stale rows leaves the next reader unable to tell "checked and live" from "not yet checked". Both are useful; only one of them was recorded until now. NOTE FOR WHOEVER OWNS THE LEDGER: the two Tier cells are a real, still-open defect -- two archived/shipped items carrying pre-shipping scores in the ranked backlog. They live in docs/BACKLOG.md, which a Builder may not edit under the owner ruling, so this commit records and locates the defect without touching it. Found by probing plan rows that cite a BACKLOG item as open. 28 raw hits, of which nearly all were co-occurrence rather than claims -- "#1"/"#2" were "synthetic ADT #1", and one trigger was the word "pending" in unrelated prose. One row carried real, checkable ledger claims, and it was right.
… drifted citation (BACKLOG #1100) 04-high-availability-and-dr.md row 82 was probed on the assumption that its "18 members" count had drifted, since counts were the class that broke row 105. IT HAD NOT. Measured via AST rather than a text window: _ALERT_EVENT_TYPES frozenset, settings.py:2599, EXACTLY 18 members only leader-related member is leadership_acquired -- nothing fires on ABSENCE alerts.py:206-213 still lands on leadership_lost, "Emits no notification" So the row is correct on every claim and the P0 gap it describes is real and open: a cluster that loses leadership entirely pages nobody, because the alert vocabulary has a member for ACQUIRING leadership and none for having none. Only the settings anchor was stale (cited :2499-2526, declared at :2599). It is now cited by NAME plus declaration line rather than as a range, because a range drawn around a growing frozenset re-drifts the next time a member is added -- which is precisely how this one drifted. The row is annotated as re-verified rather than left silent, matching the practice adopted in c4d6030: a sweep that marks only stale rows cannot tell the next reader "checked, still true" from "not yet checked".
… at startup (BACKLOG #1100)
04-high-availability-and-dr.md row 83 claimed engine shards and [cluster] "collide
on one lease", on the strength of two claims. The load-bearing one is false.
"no validator relates serve --shard to [cluster].enabled"
THERE IS ONE, IT FAILS CLOSED, AND IT IS TESTED.
ADR 0073 makes them mutually exclusive; __main__.py:2649-2659 refuses the
combination with exit 2 BEFORE the store or app is built; and
test_shard_recovery_engine.py:321::test_serve_refuses_shard_with_cluster_enabled
asserts rc == 2. Executed here: 1 passed.
"_lease_key is not engine-shard-namespaced"
STILL TRUE, and the anchor drifted (cited cluster.py:414, actual :484).
But it is MOOT for this failure mode: N engine-shard processes can never
come up against an enabled [cluster] to contend at all.
The stated blast radius -- "silent full stop for every engine shard but one,
looking healthy on /cluster/status" -- CANNOT OCCUR. A fail-closed startup
refusal is the opposite of silent, so the row is closed rather than narrowed.
That makes it the first row in this sweep whose concern did not survive its
evidence; the previous nine were all narrowings.
What remains is a design note, not a gap: the un-namespaced lease key matters
only if ADR 0073's mutual exclusion is ever lifted, so it is a CONSTRAINT TO
PRESERVE and is recorded as such.
Also noted in the row: this satisfies the HA-03 exit criterion at :399 by its
FIRST alternative (a config-load rejection, not an engine-shard-namespaced lease
key) -- though the assertion lives in test_shard_recovery_engine.py rather than
the tests/test_cluster_shard_interaction.py that the criterion names, so anyone
grepping for that filename would wrongly conclude the criterion is unmet.
…is actually missing (BACKLOG #1100)
04-high-availability-and-dr.md row 84 was re-measured and is CORRECT on all
three claims -- the last unchecked P0 in this chapter's risk table:
dr.py:296-301 disclaims a cross-store guarantee TRUE, and the anchor lands
exactly on "the engine gives
no cross-store loss/duplicate
guarantee -- documented, not
an engine AC"
harness/reconcile/ has capture/compare/normalize/report TRUE, all four
nothing binds it to the DR release path TRUE -- 4 unit-test files
exercise harness.reconcile,
but no workflow and no
runbook step invokes it
The two "reconcile" hits under .github/workflows/ are an unrelated ingress probe
and an English verb, not a binding. Worth stating because a grep for the word
alone suggests coverage that does not exist.
AND THE GAP IS SHARPER THAN THE ROW SAID. AOAG-DEPLOYMENT.md:708 DOES instruct
the operator -- "reconcile before you discard; do not rubber-stamp the loss" --
and never names harness/reconcile/. The runbook asks for the activity and points
at no tool, which is worse than saying nothing: the operator is told to do it and
left to invent how, at the exact moment they are recovering from a failover.
That makes the remedy cheap and specific rather than open-ended: have :708 name
the tool. Recorded in the row so whoever picks up this P0 starts from a one-line
fix rather than from "bind the harness to the release path".
Note: correcting the AOAG runbook is not in this claim's scope, and the row now
carries the pointer instead.
… is its inverse (BACKLOG #1100) 02-pipeline-reliability.md row 145 claimed six MEFOR_TEST_*-gated pipeline suites are "named in no workflow step", citing batch_handoff_statements and engine-shard recovery, and asserting they are "in neither the steps nor the gate regex". BOTH PARTS ARE FALSE FOR BOTH NAMED EXAMPLES: tests/test_adr0075_batch_sqlserver.py ci.yml:1375, sqlserver-store step tests/test_shard_recovery_sqlserver.py ci.yml:1371, same step adr0075 and shard_recovery are both in the gate alternation at ci.yml:993 The cited anchor :424-428 had drifted onto a comment about CI run timings; the "MUST list every file" comment is at :983-988. THE RESIDUAL GAP IS REAL AND SHARPER THAN THE ROW STATED. Of 54 MEFOR_TEST_-gated suites, 19 are named in no workflow step, and every server-DB step invokes EXPLICIT FILES rather than a directory -- so an unnamed suite runs nowhere on a real backend. THREE OF THE 19 ARE MATCHED BY THE GATE REGEX: test_adr0157_fence_scope 8 tests test_sqlserver_sync_handoff_offline 6 tests test_adr0071_fusion_wiring each named ZERO times anywhere in .github/ (positive control: shard_recovery_ sqlserver = 1). A change to any of them PULLS the expensive server-DB legs and then never executes them -- the leg goes green having not run the suite the gate fired for. ci.yml:983-988 states only one direction of the invariant: the alternation must list every file the steps run. THE INVERSE IS UNSTATED AND VIOLATED THREE TIMES: every file the alternation lists should be run by some step. That asymmetry is why this went unnoticed -- the stated half is checked by the comment's own instruction, and nothing looks at the other half. Stays P0. The original blast radius (duplicate PHI delivery across engine shards) is in fact covered, since shard_recovery and adr0075 both run; what remains is ADR 0157 fence scope with no real-Postgres execution, which is a correctness mechanism against duplicate delivery in its own right.
…s ceiling is missing (BACKLOG #1100)
02-pipeline-reliability.md row 146 is CORRECT, and re-deriving it from the code
turns "no ceiling exists" into something a fixer can act on.
What is actually there:
queue table carries an attempts column for EVERY stage store.py:1319
a max_attempts ceiling IS enforced :5756 mark_failed
:5816 mark_batch_failed
reset_stale_inflight, 69 lines :5948 -- references
NEITHER attempts NOR
dead_letter
So the ceiling is real but sits ONLY on the caught-Python-exception path. A hard
abort -- C-extension segfault, OOM kill -- calls neither mark_failed nor
mark_batch_failed, and recovery runs reset_stale_inflight instead, which re-pends
the head without counting anything. The lane re-runs and the process dies again,
exactly as the row says.
THE FIX HAS A LOCATION: the increment must happen at CLAIM time or inside
reset_stale_inflight, NOT on the failure path -- because the failure path is
precisely what a hard abort skips. A ceiling added to mark_failed would pass
review and change nothing about this failure mode.
Also recorded: G6 is an OUTBOX-stage mechanism throughout (every reference reads
OutboxItem.attempts), which is why it does not cover the split ingress/routed
path. Worth stating because "there is a poison ceiling" is true and misleading
in the same breath.
Verified by reading the whole function via AST rather than a byte window -- the
same instrument that produced a wrong member count earlier tonight.
…rvives (BACKLOG #1100) 16-security-phi-and-supply-chain.md row 201 said nothing asserts that the MEFOR_MIN_DETECTORS floor matches the real list, that the spec parses, or that a partially-mangled secret is caught. TWO OF THOSE THREE ARE NOW FALSE. test_scan_tokens_source.py carries 56 tests. The spec IS parse-asserted (test_min_spec_parsing_rejects_nonsense, test_unrecognised_require_value_refuses) and a partially-mangled secret IS covered (test_present_but_unusable_token_source_ fails_closed, parametrized over `mangled`, whose docstring records that a mangled secret once yielded ZERO detectors). Ran the cited tests: 7 passed. Materially, the ESTATE half no longer depends on the token list at all. BACKLOG #321's structural estate-identifier shape detector fires with NO token source present, and the allowlist validator refuses an entry broad enough to disable it. DEPENDENCY STATED IN THE ROW ITSELF: that detector is commit c395944, which is on this builder branch and NOT on main. If the plan edit lands without it, the cell is wrong. A row whose truth depends on an unlanded sibling commit has to say so, or it becomes a false claim the moment the two are separated -- and they are separable, because I reported these items as individually landable. THE SURVIVING CLAIM IS THE INTERESTING ONE AND IT STAYS P0. Every floor test uses a SYNTHETIC floor (names=2 + estate=2 + site_prefixes=1), so nothing asserts the real names=7,estate=13,site_prefixes=1. That cannot be fixed in pytest: scan-tokens.local.txt is gitignored and the real list arrives only via MEFOR_FORBIDDEN_TOKENS, so no checkout can hold it. Any real fix must compare the floor against the list INSIDE THE GATE RUN. Recorded so the next attempt does not start by writing a unit test that cannot see the data. Anchor corrected: security.yml:403 -> :674 (commented at :655).
…G #1100) 16-security-phi-and-supply-chain.md row 200 said the continue-on-error guard pattern "was never extended to security.yml". IT WAS. tests/test_security_posture.py is that guard -- 12 tests, all passing, last touched 72e6709 on 2026-08-10 under BACKLOG #1079. It covers BOTH vectors the row names: test_required_jobs_carry_no_continue_on_error test_required_jobs_declare_no_skippable_job_level_if -- "a job-level `if:` is the other way a required context silently never reports", allowlisted per job _BLOCKING_SECURITY_JOBS is exactly the seven jobs this row lists, and each is asserted present in .github/required-contexts.txt, so "blocking" is a checked claim rather than a label. The module also runs the REVERSE direction (sbom and trivy must KEEP continue-on-error, catching a silent promotion), and it is not vacuous by construction: test_every_security_job_is_classified fails when a new job arrives in security.yml unclassified. THE REASON THIS ROW SURVIVED IS WORTH RECORDING, BECAUSE IT WILL RECUR. The guard's own module docstring restates this row's claim VERBATIM -- "nothing guarded it: the three tests in this repo that read a workflow's continue-on-error cover quality-advisory.yml and freethread-smoke.yml" -- as THE HISTORY IT WAS WRITTEN TO CLOSE. Anyone who greps for the claim finds it, in the very file that refutes it, and comes away confirmed. A test that documents the defect it fixes reads exactly like evidence the defect is open. Second closure of this sweep, after row 83. Both were P0s asserting a gap that the engine or its CI had already closed, and in both cases the refutation was one file away from the row's own citation.
…e control (BACKLOG #1100) 16-security-phi-and-supply-chain.md row 199 is CORRECT and still open. FEATURE-COVERAGE-PLAN.md returns zero hits for all 17 of ADR 0135 and 0138-0153, and its status blocks still date to 2026-07-13. Re-measured WITH A POSITIVE CONTROL, which is the part worth keeping: ADRs 0010/0023/0030/0066 DO resolve in that file. Without that, "zero hits" is indistinguishable from a grep that matches nothing for a reason of its own -- the exact failure that made an earlier probe in this sweep report 0 for eight ADRs it had never actually tested. Zero-hits claims now stand 3 verified-true (05:95, 09:122, this row) to 1 broken (05:98, the HTTP listener auth row). Worth recording as a base rate: the class is productive precisely BECAUSE it usually holds -- when one breaks, it breaks loudly and in the direction of understated coverage. The row is annotated rather than changed. It is also the row whose staleness would be hardest to notice from inside the document, because the instrument it indicts is the same one a reader reaches for to check it.
…rse than suspected (BACKLOG #1100)
10-auth-rbac-and-active-directory.md row 91 carried this as a SUSPECTED live
defect. It is confirmed, against pyspnego's own signature rather than by
inference:
spnego.server(hostname: str = 'unspecified', service: str = 'host', ...)
hostname: The principal part of the SPN. Required to build the SPN.
service: The service part of the SPN. Required to build the SPN.
The library BUILDS the SPN from the two fields. Both acceptor sites pass the whole
SPN into service= -- auth/ldap.py:315 and :375 -- and settings.py:1905 documents
kerberos_spn as "HTTP/host.example.com".
WORSE THAN THE ROW ASSUMED: hostname is never passed at EITHER site, so it takes
its default. The acceptor principal is HTTP/host.example.com/unspecified, not
.../<hostname>. The row inferred a hostname would be supplied from somewhere; none
is.
Scope stated honestly per CLAUDE.md section 0: kerberos_enabled defaults to False
and is marked experimental (settings.py:1904), so this WOULD bite the first site
that turns Kerberos SSO on. It is not affecting anything now, and the conditional
is the accurate tense -- but the row's blast radius (a working-looking feature
that always fails, every failure an audited generic reject) is correct for that
site.
Three anchors re-pointed: :300 -> :315, :360 -> :375, :1846 -> :1905.
Not fixing the code here: that is auth-surface engine work outside this claim, and
the row now carries the exact evidence -- both call sites, the signature, and the
missing hostname= -- so the fix does not need re-derivation.
…drifted anchors (BACKLOG #1100)
10-auth-rbac-and-active-directory.md row 93 is CORRECT on every claim. Only its
citations had rotted, and they had rotted in a way that reads as confirmation:
cited auth/ldap.py:182-187 as the ACCOUNTDISABLE reject
-> that range now lands on the ATTRIBUTE LIST, which is the other thing
this same row cites. A reader checking the anchor sees plausible code
and moves on.
actual reject auth/ldap.py:197-201 (uac & 0x2)
actual attribute list auth/ldap.py:185-192 (requests userAccountControl)
_find_user auth/ldap.py:174
resolve_principal auth/ldap.py:277
_probe_principal service.py:1244 (cited :1207), calls it at :1253
Verified by reading _find_user and resolve_principal whole via AST rather than by
grepping a window: neither contains accountExpires, lockoutTime or UF_LOCKOUT.
So an AD account that is EXPIRED or LOCKED but not explicitly DISABLED is accepted
by all three password-free paths -- Kerberos SSO, OIDC, and the ADR-0079
reconciler, which would probe it PRESENT every pass. Offboarding-by-expiry, the
common HR pattern, would not propagate. service.py:959 states the shared path in
as many words: "Roles come from resolve_principal -- the same password-free LDAP
lookup Kerberos uses".
Not fixing it: auth-surface engine work outside this claim. The row now carries
the exact reject site, the exact attribute list, and the three entry points, so
the fix does not need re-deriving.
…can see (BACKLOG #1100) 10-auth-rbac-and-active-directory.md row 92 makes three claims. Two are confirmed from here; the third cannot be, and saying so is the point of this commit. CONFIRMED the ADR status line still reads exactly "Proposed -- code COMPLETE, awaiting lab validation", and its inline note adds "flips to Accepted only when runbook cells L6a, L9 and L18 report" docs/testing/ holds 26 files, all plan documents, with no AD-lab run record NOT CHECKABLE FROM THIS REPOSITORY whether L6a / L9 / L18 have since run. The runbook is docs/security/AD-FEDERATION-LAB-RUNBOOK.md, and docs/security/ DOES NOT EXIST in this checkout -- it is the private companion repo. My brief also assigns that half to the ASVS Tracker, so the constraint and the practical limit coincide. The row now says UNKNOWN for that clause rather than leaving it reading as CONFIRMED OPEN. The distinction matters here more than usual: L18 is described as the proof of a control that a review once found to be a live privilege-escalation route, so "we have not verified this" and "this is still broken" are very different statements to leave in a security test plan. The ADR status is the honest public proxy -- it has not flipped -- and the row now says that instead of implying more. This is the first row in the sweep whose evidence lives outside the repository. A verification pass has to be able to say "I cannot see this from here" without either guessing or going quiet.
… reader could refute it with (BACKLOG #1100) 10-auth-rbac-and-active-directory.md row 90 is substantively CORRECT. All six acceptor sites are still pragma: no cover, annotated "needs real AD" and "requires a domain-joined server + keytab": ldap3 LDAPException arms :267 :289 (cited :252, :274) SPNEGO acceptor lines :313 :321 :373 :378 (cited :298, :306, :358, :363) Zero workflows mention ldap, and there is no OpenLDAP / Samba / 389ds service container anywhere. ONE CLAUSE IS FALSE AS WRITTEN: "no self-hosted runner ... exists in .github/workflows/". One does -- selfhosted-win2025-sql.yml :: sqlserver-real, "SQL Server 2025 suites (real hardware)". It mentions no ldap, kerberos, spnego, ad_domain or directory, so the row's INTENT holds exactly; its literal claim does not. That is worth fixing in both directions. Defensively: as written, a reader can refute a P0 by pointing at one file, and a row that can be dismissed on a technicality does not survive the meeting it matters in. Constructively: A SELF-HOSTED WINDOWS RUNNER WITH A LABEL SCHEME ALREADY EXISTS AND IS PROVEN, so the remedy here is "point an existing pattern at a directory", not "stand up runner infrastructure". The row previously implied the expensive half was missing when it is already built. This is the sixth row in the sweep that understated something -- coverage, its own gap, or as here, how close the fix already is.
…at the moved gate (BACKLOG #1100)
03-store-and-data-lifecycle.md R3 is CONFIRMED. The gate has MOVED since the row
was written, which is why its anchor no longer showed the defect:
cited __main__.py:1968-1975 "builds unbounded_windows"
actual config/retention_classification.py:186 defines it (20 lines)
__main__.py:2240 is its ONLY caller: _unbounded_windows(settings)
Read whole via AST, unbounded_windows contains no registry / connection /
per_connection / overrides / inbound token. It sees global settings and nothing
else.
The override that defeats it is documented in the code that creates it,
wiring.py:3125-3126: "None = inherit the global [retention].messages_days window;
0 = keep this connection's bodies forever; >0 = days" -- and pipeline/retention.py:150
honours it at purge time.
BOTH HALVES ARE INDIVIDUALLY CORRECT AND JOINTLY PERMISSIVE. A deploying PHI
instance with a global 30-day window would pass the startup gate while every
inbound set to messages_days=0 retains bodies forever, with no warning, no audit
entry and no test. Written conditionally per CLAUDE.md section 0: there are no
deployments, so nothing retains PHI today; it is wrong in the shipped code.
This is the most consequential of the three code defects this sweep has confirmed,
because the control is LABELLED fail-closed and audited (ASVS 14.2.4) -- its
existence is exactly what a reviewer would rely on instead of checking. That is
the compensating-control-on-a-false-premise shape in its purest form.
Not fixed: store/config surface, outside this claim. The row names the fix -- hand
the gate the registry's resolved per-connection windows rather than settings alone.
…what is actually missing (BACKLOG #1100)
03-store-and-data-lifecycle.md R2's core claim is CONFIRMED: no workflow sets
MEFOR_TEST_FORCE_AAD_BIND -- 0 occurrences across .github/workflows/, against a
positive control of 14 for MEFOR_TEST_SQLSERVER. aad_bind still defaults True
(settings.py:388) and make_cipher's library default is still write_v2=False
(crypto.py:812).
BUT "THE SHIPPED WRITER IS BARELY EXERCISED" NOW OVERSTATES IT, and the flag's own
docstring (tests/conftest.py:133-138) is the authority:
"The flag is OFF by default and stays meaningful even though [store].aad_bind
now DEFAULTS TRUE (ADR 0148 GIVEN 1). ... The settings default governs what
open_store builds; this flag governs every cipher in the process, which is
what makes the sweep exhaustive rather than merely representative."
The flag is a SWEEP AMPLIFIER, not a gate: unset, the suites still run and
open_store still builds the mfenc:v2 writer because the setting defaults True. So
the shipped writer IS exercised. What never runs is the process-wide forcing that
also catches ciphers constructed with an EXPLICIT write_v2=False.
The parenthetical was wrong too: EIGHT test files reference the flag, not
conftest.py alone.
STAYS P0. The residual risk is exactly as stated -- a half-threaded cell_aad on
purge re-encrypt, document strip write-back, attachment re-seal or restore
surfaces only under the forced sweep, and that sweep runs nowhere. Narrowing the
headline does not shrink the gap; it stops the row being refutable by anyone who
checks whether the writer runs at all.
…BACKLOG #1100) eb32618 introduced a stray `|` in 03-store-and-data-lifecycle.md row 107, turning a 5-column row into 6 and breaking the risk table's alignment from that row on. Replaced the stray boundary with a full stop; header and both neighbouring rows now agree at 5. I RAN THE COLUMN CHECK AND COMMITTED ANYWAY. The check printed "row107: 6" against a header of 5, in the same command that staged and committed. Running a verification and GATING on it are different things, and batching them into one command guaranteed the output arrived after the decision it was supposed to inform. That is the same instrument-vs-question failure this whole sweep keeps finding, in its most avoidable form: the measurement was correct, present, and ignored. Every other near-miss tonight needed a subtle reason -- a truncated window, a pipe swallowing an exit code, a docstring quoting the claim it refutes. This one needed only that I put the check and the commit in the same breath. Splitting them from here: verify, read the result, then stage.
…tables (BACKLOG #1100) After breaking a row in eb32618 I checked whether I had done it elsewhere. I had. 15-alerting-and-observability.md:138 -- my FIRST #1100 commit tonight, 1e926ec -- merged the Risk and Failure-mode cells into one, leaving a 4-column row under a 5-column header (Risk | Failure mode | Blast radius | Detected today? | Priority). It has been misaligned for the whole session. Split at the natural boundary: the verdict sentence stays in Risk, the send_plain_email evidence moves to Failure mode. THE POINT IS NOT THE TWO ROWS, IT IS THAT I ONLY EVER CHECKED THE ROW IN FRONT OF ME. The per-edit column check I adopted mid-session cannot see damage done before I adopted it, and never looked at the other 171 tables. A check scoped to the thing you are currently touching is blind to your own history with the file. Swept all 20 chapters: 172 tables checked, 0 misaligned rows remaining. Process corrected as well as the rows: the integrity check now runs as its own step and I read the result BEFORE staging. In eb32618 the check and the commit were one command, so the output that would have stopped me arrived after the decision it was meant to inform.
…w it is the DOUBLE kind (BACKLOG #1100) 03-store-and-data-lifecycle.md R1 holds on every claim, measured with a positive control: connection_cutoffs in test_postgres_store.py 0 connection_cutoffs in test_sqlserver_store.py 0 control: it appears in exactly 2 files repo-wide, so the zeros are real serverdb path-gate regex matches per_connection_retention 0 times regex is at ci.yml:993, not the cited :434 TWO ADDITIONS. The row named only test_per_connection_retention.py; the second file carrying connection_cutoffs is test_embedded_document_pruning.py, and it is in the same position. And BOTH are in the 19 MEFOR_TEST_-gated suites that 02-pipeline-reliability.md:145 was corrected to describe -- so the two rows are looking at one CI defect from opposite ends. THE SHAPES ARE NOT EQUIVALENT, AND THIS ONE IS WORSE. The three suites in that other row are MATCHED BY THE GATE BUT RUN BY NO STEP: the expensive server-DB leg fires and then does not test them, which is waste plus false assurance. These two are MATCHED BY NOTHING AND NAMED BY NOTHING: editing the per-connection purge predicate fires no server-DB leg at all, and no test that mentions connection_cutoffs runs anywhere. For a predicate that decides WHICH FEED'S PHI BODIES GET DELETED -- irreversible in one direction, unbounded retention in the other -- "no signal at all" is the weaker of two weak positions. Recorded in the row so the two CI findings can be fixed as one change to the gate regex plus the step lists.
…that look like counter-evidence (BACKLOG #1100) 09-engine-api.md row 113 is CORRECT on its load-bearing half. tests/test_webconsole_seam_snapshot.py is a digest over rendered-DTO FIELD NAMES and contains no status_code, methods, __annotations__, type_ or optional reference at all. Types, optionality, path, method and status code are unpinned, exactly as the row says. I LEFT THE COUNT ALONE ON PURPOSE. Re-counted by AST walk over all of api/: 117 BaseModel/RootModel classes (models.py 84, auth_models.py 32, phi_gate.py 1) against the "~121" written here. That is inside the row's own tilde, and re-pinning it to 117 would replace one figure that will drift with another. The hedge is doing its job; round 4's lesson was that a HARD count rots, not that every number must be restated. RECORDED FOR THE NEXT CHECKER: two tokens in that test file look like counter-evidence and are not. `annotation` is `from __future__ import annotations` at :14, and `required` is the English word at :76. A grep for either returns a hit in the file that would otherwise settle the question, and suggests types are pinned when nothing of the sort is happening. I spent a step on exactly that detour. That is the same shape as 16-security row 200, where the guard's docstring quoted the claim it refutes: THE FILE THAT ANSWERS THE QUESTION ALSO CONTAINS THE STRING THAT ANSWERS IT WRONGLY. My own first count was wrong too -- 89, from a base filter matching any name containing "Model" rather than BaseModel/RootModel specifically. Re-measured before reporting.
…pulations measured (BACKLOG #1100) 09-engine-api.md row 114 is CORRECT, and measuring it properly makes it much harder to wave away than "verified by cross-grep" did: tests setting MEFOR_TEST_SQLSERVER / MEFOR_TEST_POSTGRES 46 tests constructing create_app 63 intersection 0 BOTH POPULATIONS ARE LARGE, which is the part that matters. A bare "zero hits" cannot distinguish a real disjointness from an empty set, a typo'd token, or a grep that never matched anything -- and this sweep has already produced one probe that reported 0 for eight ADRs it had never tested. 46 and 63 with no overlap is a structural fact about the test estate, not an absence of evidence. The two halves do not meet: everything that exercises a route runs on SQLite, and everything that runs on a real server backend addresses the store directly. So every backend divergence the row lists -- list_messages + count_messages composition, search truncation, record_audit against the ADR 0150 client column on NVARCHAR(256), preset listing, dead-letter paging, audit filters -- would first appear at a deploying site rather than in CI. Chapter 09's P0 risk set is now complete (113 confirmed, 114 confirmed), making six chapters: 02, 03, 04, 09, 10, 16.
…ares the wrong two things (BACKLOG #1100) 08-publishing-and-promotion.md row 109 said "Nothing recomputes or compares a fingerprint". THAT IS FALSE. ConfigProvenance (api/app.py:4570-4590) reads engine.loaded_config_fingerprint, RECOMPUTES config_fingerprint_detail(target) off the loop, COMPARES them, and returns a drift flag. ADR 0041 D1 additionally writes a fingerprint-bearing config_reload audit row on every reload (:554-581). BUT IT COMPARES LOADED-VS-DISK-NOW, AND THE RISK IS DISK-VS-THE-COMMIT-CI-WAS- MEANT-TO-DELIVER. In the exact scenario this row describes -- CI/CD never delivered the commit -- the disk still equals what was loaded, so drift is False and provenance reports clean. SO THE CONCERN SURVIVES ITS EVIDENCE ENTIRELY, AND IS NOW HARDER TO SEE THAN BEFORE. A reviewer who greps for fingerprint handling finds a recompute, a comparison and a drift flag, and reasonably concludes the risk is covered. The control is real, well-built, and answers a different question. That is the compensating-control-on-a-false-premise shape for the fourth time in this sweep, and the most dangerous instance: the other three rested on evidence that had rotted, while this one rests on a control that genuinely exists. Still true, and re-anchored: ReloadResult (api/models.py:371, cited :351-360) carries no fingerprint, so the promoting caller never receives one; and there is no `messagefoundry fingerprint` CLI -- the subcommands are graph, serve, validate. THE FIX IS SMALLER THAN THE ROW IMPLIED. The fingerprint is already computed on every reload. It needs surfacing in ReloadResult and comparing against an EXPECTED value, rather than building fingerprinting from nothing.
…inst ADR 0041's SHALL (BACKLOG #1100)
08-publishing-and-promotion.md row 108 is CONFIRMED, measured on this checkout.
fingerprint.py:44 lists environments/*.toml in _FINGERPRINT_GLOBS, globbed at :59
as base.glob(pattern) where base is the directory passed in -- last_reload_dir /
config_dir, the CONFIG DIR. Repo-root environments/ holds 2 .toml files;
samples/config/environments/ does not exist. Every documented layout (ADR 0017,
ADR 0050) keeps environments/ as a SIBLING of --config, so the declared glob
resolves to nothing.
WHAT THOSE FILES HOLD IS WHY THIS MATTERS: acme_adt_host, acme_adt_port,
demo_oru_host, demo_oru_port, fhir_base_url, payer_rte_host, payer_rte_port --
14 keys each. Repointing a peer host changes WHERE PHI IS SENT and produces an
identical fingerprint, no drift flag, and an audit row indistinguishable from a
clean reload.
AND ADR 0041 STATES THE OPPOSITE AS A REQUIREMENT, NOT A DESCRIPTION:
:100 "It spans connections.toml AND environments/ so a transport/env-value
redirect cannot change [the graph without changing the fingerprint]"
:153 "... or environments/*.toml -- THE SYSTEM SHALL produce a different
fingerprint."
So this is not a doc gap. SHIPPED CODE DOES NOT MEET A SHALL ITS OWN ADR RECORDS,
and the attestation built to detect a redirect is blind to the file that performs
one. Conditional per section 0: no deployments, so nothing is mis-attested today.
ADR 0041:238 separately leaves "Fingerprint env-value scope" open -- that question
is about hashing RESOLVED values and does not cover this. This is the declared
scope failing to resolve at all, which is a different and simpler failure.
Not fixed: config surface, outside this claim. The fix is to anchor the
environments/ glob at the project root rather than the config dir.
…ACKLOG #1100)
08-publishing-and-promotion.md row 110 is CONFIRMED on all four claims, and BOTH
ANCHORS STILL LAND -- rare in this sweep.
engineClient.ts:94-96 if (status >= 200 && status < 300) {
resolve((text ? JSON.parse(text) : {}) as T)
promote.ts:191-195 prints "promoted to <target> -- live graph:
${result.inbound} inbound, ..." with NO status check
41 IDE test files exist and NOT ONE drives promote.ts
(promote-target.test.ts tests promoteTarget.ts, a
different module)
STRONGER THAN THE ROW STATES: PendingApproval appears nowhere in ide/, and there
is no 202 handling anywhere in ide/src. This is not a missed branch -- the client
does not model the pending-approval response as a concept. So the fix is one
status check at the postJson call site, not new machinery.
WORTH RECORDING ABOUT THE ANCHORS. Nearly every Python row in this sweep had
drifted citations; both TypeScript anchors here are exact. ANCHOR DRIFT TRACKS
CHURN, and the IDE surface has moved far less than the engine. That is a useful
prior for whoever sweeps next: weight re-derivation toward the fastest-moving
code, and treat a stable surface's citations as more trustworthy -- but still not
as evidence.
…ng both drifted anchors (BACKLOG #1100)
08-publishing-and-promotion.md row 107 is CONFIRMED on substance. Both of its
anchors had drifted, one of them onto text that looks nothing like the claim:
cited api/app.py:5455-5462 as the start-path load
-> that range is now a function signature's KEYWORD PARAMETERS
(priority_default, retention_settings, ...), ~270 lines away
actual api/app.py:5725 loaded = load_config(config_dir)
api/app.py:5730 engine.add_registry(loaded)
cited engine.py:1488-1500 as "only reload sets loaded_config_fingerprint"
actual engine.py:450 initialised None
engine.py:1610 / :1615 BOTH inside reload() (def :1479)
-- right method, wrong lines
VERIFIED FROM THE OTHER SIDE TOO, which is what makes it conclusive rather than
suggestive: Engine.start() (engine.py:875, 301 lines) mentions NONE of
loaded_config_fingerprint, config_fingerprint, add_registry or load_config. The
fingerprint-bearing config_reload audit row is written only from the reload path
(app.py:554-573, gate action registered :547).
So the primary CI/CD path -- copy files, restart the service -- leaves the engine
unattested, and GET /config/provenance answers loaded=false. Its own comment shows
the conflation: "no graph loaded yet, or fingerprint unavailable". Two very
different states, one indistinguishable answer.
PROCESS NOTE: my first edit dropped the cell boundary between Risk and Failure
mode (the old text had two pipes, my replacement had one) -- the same error I
committed twice earlier tonight. THE INTEGRITY GATE CAUGHT IT BEFORE STAGING this
time, because it now runs as its own step and I read it before deciding. Fixed
before the commit rather than after.
…s are one gap (BACKLOG #1100) 08-publishing-and-promotion.md row 111 CONFIRMED. ClusterStatus (api/models.py:786, cited :737-748) has exactly node_id, clustered, is_leader, role, config_version -- no fingerprint; ClusterNode (:800) adds none either. The convergence anchor lands exactly, and the module states the assumption in its own words: config_convergence.py:16-18, "The version token coordinates when nodes reload; each node reloads its OWN config dir. Skewed config dirs would diverge." THE FINDING WORTH MORE THAN THE ROW: 107, 109 AND 111 ARE ONE GAP SEEN THREE TIMES. ADR 0041 D1 computes a content fingerprint on every reload, and it is surfaced in NONE of the three places a consumer could compare it -- not on the restart path (107 never sets it), not in ReloadResult (109), not in ClusterStatus (111). THE VALUE IS ALREADY COMPUTED; THE GAP IS ENTIRELY IN EXPOSURE. That matters because each row scopes as its own piece of work. Read separately they suggest three investigations into attestation. Read together they are one change -- surface the existing fingerprint on those responses and compare it against an EXPECTED value at the promote site. ConfigProvenance already proves the recompute-and-compare machinery works; it just compares the wrong two things. Recorded in all three rows and as handoff 6h, so whichever is picked up first finds the other two rather than solving a third of the problem well.
…hapter that did not drift (BACKLOG #1100)
TrayApp is tray/app.py:42-154, which is 113 lines, not the '154 lines'
the row claimed. 154 is the END LINE NUMBER relabelled as a LENGTH,
overstating the untested surface by 36%. Same root cause as the three
false enumerations I committed earlier this session: take the number a
tool returned, then call it something narrower than what it measures.
Everything else in ch14 verified EXACT, which is itself the finding:
:450 Start SERVICE_AUTO_START
:463-464 AppExit Default Restart + AppThrottle 5000
:472-477 the virtual-account default block
:516-548 the S4 ACL block ('applied AFTER ... ObjectName is set')
:81 Resolve-Nssm
winshell.py:299-451 spans precisely the ten dispatch functions
_add_icon through _message_loop, which ends at :451
Every wiring_runner.py anchor checked in ch02-10 had moved; none here
did. So drift tracks the CHURN OF THE CITED FILE, not the age of the
plan -- a re-sweep should re-point per file, not uniformly. Recorded in
the row so the next sweeper does not redo this chapter.
… three-state collapse (BACKLOG #1100)
Every hop of the row's chain verified in code:
_read_toml (tray/config.py:279-286) -- 'None on any read/parse
failure. Never raises' -- catches (OSError, ValueError) at :284,
and PermissionError IS an OSError, so -LockConfigDir yields None
service_toml_uses_tls :212-213 'if not service_toml: return False'
build_engine_url :188 renders http:// when tls is False
The row described a symptom; the defect underneath is a THREE-STATE
COLLAPSE. Parsed-and-no-TLS, file-absent, and file-present-but-
UNREADABLE all become the same None and then the same False. The
distinguishing information is destroyed at :284, so NO downstream fix
is possible and the test has to drive the unreadable case specifically
-- which is why 'a healthy engine renders WEDGED' is not a UI bug.
Recorded the contrast rather than just the finding: seat-tick.ps1
handles the identical distinction correctly, with a roster-blind flag
and a comment saying a roster that could not be read is not evidence
that nobody is live. Same distinction, one place kept it and one
folded it into the empty case.
…tion' P0 -- it is false (BACKLOG #1100)
The most consequential correction of this sweep. The row asserted a
TOTAL coverage gap over work that has DEDICATED CI STEPS BUILT TO
COVER IT, and would have sent someone to build tests that already
exist and already run.
Refuted, two of three clauses:
'no workflow file contains shard' -- ci.yml has it 7+ times, incl.
named steps at :1348 and :1551 and the path gate at :993.
Positive control: 'test' matched 24/24 workflow files.
'named by no CI step, so they execute nowhere' -- all three are
named (ci.yml:1371, :1372, :1571) and the steps set EXACTLY the
variable the modules gate on (MEFOR_TEST_SQLSERVER: '1' against
not os.getenv('MEFOR_TEST_SQLSERVER')), so the gate makes them RUN.
The ci.yml comments say these steps were added to close this very gap,
and tests/test_serverdb_ci_coverage.py now fails if a module-gated
suite is added without being named -- a meta-gate against exactly this
regression. The row was describing a state that had already been fixed.
What survives is real but far narrower than P0: test_supervisor.py
drives _FakeProcess (11 refs, docstring 'without launching real engine
subprocesses'), no Popen/create_subprocess. Re-scoped the row to that:
shard RECOVERY is covered on both server backends, SUPERVISOR PROCESS
HANDLING against a real subprocess is not.
Checked the surviving clause BEFORE withdrawing, so the correction does
not overshoot from 'zero coverage' to 'fully covered'.
…ology P0 confirmed exact (BACKLOG #1100) Row 112 WITHDRAWN. The document was FIXED after the plan was written: the '~500 - low-thousands msg/s / ~40M+/day' tier NO LONGER EXISTS. SYSTEM-REQUIREMENTS.md:216-219 now tops out at ~165 msg/s at 4 engine shards and discloses the topology inline. Anchors drifted too (:163 is blank; :195-198 is bench guidance). The alleged self-contradiction is unreproducible: 'future direction, not built' appears NOWHERE in docs/. Flagged the arithmetic even though it is moot -- ~500/~72 is 6.94x, not the 7.23x claimed, so the multiplier did not come from the two numbers the row set beside each other. Kept the row's last column, which is still true: no doc-vs-measurement guard exists, so nothing caught the over-claim while it was live and nothing will catch the next one. Row 113 CONFIRMED, anchor EXACT -- worth stating precisely because the two rows above it in the same chapter did not survive. TUNING-BASELINE .md:150 is verbatim the 'per-shard SQLite ... no shared DB' store line, with E_core ~42 / eta ~0.85 at :161-162. One qualification: both files now DISCLOSE the topology (:165-171 separates the portable shape from the non-portable absolute; SYSTEM-REQUIREMENTS:219 names it), so this is a reproducibility problem, not a hidden-caveat one. Three P0s examined in this chapter, three different verdicts. Grading them as a block would have been wrong in both directions.
… row stated (BACKLOG #1100) Row 92 CONFIRMED verbatim. The webconsole pyproject dependency really is a bare 'messagefoundry', and the comment beside it reads: 'A PEP 508 compat RANGE is ideal (messagefoundry>=X,<Y); a bare dep is fine for now -- the ENGINE_UI_SEAM handshake (assert_engine_seam) is the runtime backstop.' That sentence IS the finding, not evidence for it: layer 1 is knowingly absent and the stated justification is that a LATER layer covers it. COMPOSED IT WITH THE serve_ui ROW, which neither row says alone. If the PEP 508 range does not exist, assert_engine_seam is not a backstop, it is the ONLY layer -- and per that row it does not degrade to a broken /ui, it propagates UiSeamMismatch and takes the whole engine down. A documented three-layer defence that is really one layer whose failure mode is total, with the pyproject comment pointing AT that layer as its reason for relaxing. Row 94 CONFIRMED with a positive control on the absence claim: an AST pass finds 13 add_argument calls in harness/reconcile/__main__.py (zero would have meant a broken probe, not clean code), the capture ones being --port/--out/--host/--ack-mode, and none is --anonymize or --salt-env. anonymizer appears nowhere in __main__.py. The sharp part is that the de-identification is BUILT AND CORRECT and simply unreachable: capture.py:133-137 applies it and FAILS CLOSED on any anonymizer error, calling itself 'this PHI choke point'. Not a missing control -- a finished fail-closed control with no way to switch it on, which is exactly why capture.py reads as safe in isolation.
…-output defect found beside it (BACKLOG #1100)
Row 93 CONFIRMED, anchors exact -- but the line that actually leaks is
NEITHER of the two cited. Both renderers get their values from one
shared helper, Difference.describe() at normalize.py:102-104, whose
entire body is:
return f'{self.kind} @ {loc}: left={self.left!r} right={self.right!r}'
The !r on a raw HL7 field value IS the PHI, and because it is one
helper feeding both paths the fix belongs there, not twice in
report.py. render_text's default really is max_diffs=20 (:50) and
render_json really does emit left/right unconditionally (:35-36).
SEPARATE DEFECT FOUND WHILE VERIFYING, recorded nowhere else:
report.py writes non-ASCII glyphs to operator stdout at :63 (U+2717),
:67 (U+2026), :72 (U+2713/U+2717). On a stock Windows cp1252 console
that raises UnicodeEncodeError -- on a WINDOWS-TARGETED product. So the
reconcile report can crash WHILE PRINTING rather than print wrongly,
and no assertion about report CONTENT would ever catch it.
Row 91 anchors re-pointed: settings.py :672 -> :710, api/app.py :4951
-> :5166 (~215 lines). Worth noting why that one is nasty: :4951 now
lands on an unrelated DR_OPERATE dependency, so the stale anchor reads
as plausible code rather than as an obvious miss.
…rse than stated (BACKLOG #1100) Row 97 CONFIRMED, and the confirmation is sharper than the claim. No JavaScript-execution tooling exists anywhere: playwright, jsdom, selenium, puppeteer, node --test all return zero across tests/, packaging/ and .github/workflows/ (positive control: 173 test files match 'console', so the probe was sound). But EIGHT test files DO reference app.js -- csp_canary, hardening, logout_affordance, mfa_gate, session_watchdog, static_allowlist, webui, webconsole_mount -- all asserting on the SERVED TEXT. Those eight are exactly the 'grep-matched strings' the row warns about, and ONE OF THEM IS NAMED FOR THE WATCHDOG ITSELF. So a coverage review that counts files touching app.js finds eight and concludes the surface is tested. Asserted-as-text versus executed is the distinction that matters, and no count distinguishes them. Row 99 CONFIRMED, all three anchors exact -- each range ends precisely on its 'Approval id:' line (:105, :212, :685), under 'Reload/Purge/ Replay held for approval'. Three independently-written dead-ends with identical shape, which is what makes it a design gap and not three oversights. Recorded a navigation note because it cost me time: the module tree is messagefoundry_webconsole/pages/ at the REPO ROOT; packaging/ messagefoundry-webconsole/ holds only metadata and tests.
…the asymmetry is the defect (BACKLOG #1100) G2 CONFIRMED, all four anchors exact. db_lookup and fhir_lookup are imported at :32/:33 and listed in __all__ at :150/:153; content_match appears NOWHERE in messagefoundry/__init__.py. This row is trustworthy precisely because it carries its own positive control -- the same search that returns zero for content_match finds both comparators, so the zero is a fact about the code and not about the probe. G3 CONFIRMED, anchor re-pointed :100 -> :101 (the cited line holds the sibling 'connection_restored': 'connection_error' entry). Ran the absence claim with a control, and the control is what makes it a finding rather than a failed grep: 'connection_started' occurs in exactly ONE place in messagefoundry/ -- the _AUTO_RESOLVE mapping -- while the same search finds 'connection_stopped' genuinely emitted at alert_sinks.py:682. So the asymmetry IS the defect: one half of an auto-resolve PAIR can never fire. connection_stopped raises and connection_started only ever resolves, so a lane that stops on an internal error and is restarted never clears. An alert that is raisable but not resolvable is worse than one never wired, because the operator sees a live alert against a healthy lane and learns to distrust the panel.
…chors drifted (BACKLOG #1100) Substance CONFIRMED and stronger than the row states. Anchors fixed: the assignment is api/app.py:1134 (cited :1120), /config/reload is at :2791 (cited :2741, now blank), and the cited :5485 lands on an unrelated phi_read_hop_secure parameter. The row claims TWO write sites. There is exactly ONE. 'app.state.alerts_settings =' occurs once in the module (:1134); every other occurrence is a constructor parameter (:1038, :5453), a call argument (:1546, :5580), or a READ via getattr(request.app.state, 'alerts_settings', None) or AlertsSettings() (:1516, :2517, :4517). The 'lifespan startup' site is not a second write, it is the plumbing feeding the one write. That makes the gap CLEANER to test than the row implies -- a single assignment is a single point to prove unreachable from reload. And the read pattern matters: 'or AlertsSettings()' means a reload-time change does not merely fail to apply, it silently falls back to DEFAULTS at every read site, so the operator sees alerting behaviour that matches neither the old config nor the new one.
…alked into first (BACKLOG #1100)
The row's own assessment is CONFIRMED structurally. AST census:
_ALERT_EVENT_TYPES holds 18 types, messagefoundry/ emits 22 distinct
{'type': ...} literals, giving 4 emitted-but-not-routable and 0
routable-but-never-emitted. All 4 are deliberate --
connection_restored, leadership_lost and dr_released are three of the
four _AUTO_RESOLVE KEYS (resolution events, not raisable alerts), and
test_email is the API's diagnostic probe. So there is no live
type-level drift, exactly as the row already said.
RECORDED A SECOND NAIVE-GUARD TRAP, worse than the method-name-vs-
event-type one the row already names, because I hit it: the constant
is frozenset({...}), NOT a bare set literal, so a regex expecting '{'
after '=' matches nothing and yields an EMPTY routable set. Every
emitted type then reads as unroutable. My first pass produced a
confident 22-of-22 'EMITTED BUT NOT ROUTABLE' list -- indistinguishable
from a catastrophic real finding, and refuted only by noticing that 0
routable-but-never-emitted cannot coexist with it.
This matters because the row's whole point is that someone must WRITE
this guard. Parse with AST and assert the routable set is non-empty
before comparing; the failure mode is to fail LOUD and WRONG.
Independent corroboration of G3 fell out of the same census, from a
probe built for a different purpose: exactly 3 of the 4 _AUTO_RESOLVE
keys are emitted, and the missing one is connection_started.
… trap recorded (BACKLOG #1100) Every figure in the chapter-05 summary paragraph checks out when the tables are PARSED rather than read: 67 CONN-nn rows, the 63 T / 4 C / 0 A split, CONN-34/35/38/49 present as the C rows, and the nine claimed P0 T rows all present and all P0 with nothing claimed that is missing. A clean accounting row, which is worth recording so nobody re-derives it. Recorded the trap that caught me, because it will catch the next counter: a naive scan for a P0 priority cell returns ELEVEN, not nine. The two extras are RISK-TABLE rows -- the risk table carries its own priority column. The chapter has TWO tables with P0 cells and only ONE is the T-row matrix this sentence counts, so a discrepancy against 9 is the counter's error and not the document's. This is the same shape as the false enumerations I committed earlier in this sweep: rows from two tables, counted together, then named after one of them.
…ied forward unchecked (BACKLOG #1100) Ran the Steward's audit method against my own work: a correction that replaces a wrong NUMBER while leaving the surrounding STORY standing. Two hits, both mine, both blessed by me earlier today. ch14 r113 -- the coverage claim was FALSE. I corrected TrayApp's line count (154 -> 113) and carried 'test_tray_shell.py only asserts imports + non-zero struct sizes' forward without opening the file. It has SIX tests; only ONE is the imports/structs one. Two of the other five cover this row's OWN stated risk: test_disabled_action_is_not_dispatchable (an action routed to the wrong handler) and test_assign_command_ids_maps_actionable_items_only (TRAY-20's subject). The gap is real but much narrower than 'behaviourally untested' -- what is genuinely uncovered is the Win32 pump (which icon paints, whether a toast fires, WM_DESTROY/WM_ENDSESSION teardown). Re-scoped TRAY-19/20/ 22 to the pump rather than to action routing. ch17 r112 -- conclusion survives, its SUPPORT does not. I kept 'no doc-vs-measurement guard exists' as still-true, including its enumeration. test_feature_map_claims.py does not check 'only' three things; it has six tests. None compares a PUBLISHED number against a MEASURED one, which is WHY the conclusion survives -- but a reader quoting the enumeration to argue the file is nearly empty would be wrong, and the enumeration is what gets quoted. Both are the same shape I have been writing into other people's rows all afternoon: I checked the part that was false and carried the adjacent part because it sat next to something I had just verified.
…tradicting themselves (BACKLOG #1100) Both rows I withdrew earlier today kept their ORIGINAL coverage and priority columns, which I never touched. As published in between, ch17 r111 CONTRADICTED ITSELF: its evidence column said the suites run in CI on both server backends while the coverage column beside it still said 'No' and the priority still said P0. r112 carried the false 'checks only three things' enumeration verbatim in its coverage column even after I corrected that same enumeration two columns to the left. Fixed both. Coverage columns now state what is actually covered. Priorities are FLAGGED as needing re-grading rather than re-graded by me: I am not the party to assign the number, but a P0 left standing on a withdrawn finding reads as an open defect forever, which is the worse of the two errors. Also re-verified the ch06 r74 claim I had carried while re-pointing its anchors, and that one HOLDS verbatim: _eq() at :74 is 'return type(expected) is type(got)' with the docstring 'exceptions compare by type', and _EMPTY_FIELDS at :183-189 contains a literal blank-segment line whose own comment names it. The parity suite really does certify the defect as a PASS, via a type-only exception comparison that is correct for its purpose and wrong for this case. Not every carried claim was wrong. The point of the audit is that I had not checked any of them -- I verified what a row got wrong and then took its neighbours on trust because they sat next to something I had just confirmed.
…pointed (BACKLOG #1100) The chapter I wrongly skipped, and the row is right. ci-gate is at ci.yml:2132 and its needs: (:2135-2141) parses to exactly changes, sqlserver-store, postgres-store, load-test, load-test-sqlserver, windows-service-smoke. 'ide' is ABSENT (that job is :818), so the leg is not rolled up and a red IDE leg does not block a merge. Anchors re-pointed: the cited :265-274 is now a uv pip install block and :1386-1392 is a DR seed-gate step, so neither landed on what it claimed. The distinction is easy to invert and I had it inverted in my own project memory, which lumped 'ide' in with the rolled-up legs. Fixed there too. 'Not individually required' and 'cannot block a merge' are DIFFERENT properties: the server-DB and load legs have the first and not the second; ide is the only leg with both.
… (BACKLOG #1100) Applied to myself the standard the Lander named: a retraction needs the same evidence as an assertion, and the asymmetry feels like humility while being the same laziness in the other direction. I withdrew this P0 as STALE and wrote 'the document was FIXED after this row was written'. I never checked that. 'The claimed text is not in this file' and 'the text was removed from this file' are different statements and I published the stronger one. git log -S settles it, and the answer is a THIRD verdict: 'low-thousands' NEVER appears in docs/SYSTEM-REQUIREMENTS.md at any point in that path's history -- nothing was removed from it it DID exist elsewhere in the repo before this plan (5fa6db9, abedf86, 39990f8 'bring the documentation set back in line with the code') today it survives in docs/ ONLY in this row the file's current ~165 msg/s table arrived via 959821a (#79) So the over-claim was real in SOME document and this row attributes it to a file that did not contain it. Whether it was ever live in THIS file is UNDETERMINED and a path-scoped query cannot settle it. MIS-CITATION, not staleness -- and the worse of the two: staleness is blameless drift, while a quotation that cannot be sourced to the file it names discredits the row carrying it. Three passes to get here ('stale', then 'never existed', then this). The first two were reached faster and on thinner evidence than I would have accepted for an assertion.
…OG #1100) Row 128 CONFIRMED, and its ranges were right where row 122's were not: isExecGated() is defined at cli.ts:67 and guards at :152 and :186, both inside the cited :147-152 / :183-189. The 'nothing asserts' half holds with a POSITIVE CONTROL -- isExecGated is referenced by NO file under the IDE test directories, while 8 files there mention 'exec', so the directories exist and the search works. The zero is about coverage, not about the probe. A CWE-426 untrusted-workspace exec gate with no test is exactly as bad as the row prices it. Row 131 CONFIRMED VERBATIM, and the module states both halves in one comment: invariant 1 opens 'NOTHING ON THE RECORD IS EVER DROPPED' and then explains why that must be engineered -- 'connection upsert is a FULL REPLACE of the table, so a key the form fails to render is a key the form DELETES.' The invariant is the MITIGATION; the full replace is the HAZARD that makes it load-bearing. The row's real point is that the tested part (planSave) is the mitigation while the untested part is what the mitigation depends on: the webview posting every key. Recorded a caution in the row because it nearly caught me. Reading ONLY the cited first line makes the module look like it CONTRADICTS the row. The qualifying sentence is two lines below. I had the false finding half-written before reading the whole block -- a byte-window read where a structural one was needed, which is the same mistake this sweep keeps correcting in the plan.
…t (BACKLOG #1100)
Row 123's title 'auth.ts has zero tests' is literally false
(ai-policy.test.ts:14 imports peekToken from it) and its framing
understates the trap. Corrected to name the real gap.
Measured:
signIn is auth.ts:108; the guard is assertTargetAllowed(url) at :111,
inside the cited :110-115 -- anchor EXACT
assertTargetAllowed is NOT untested. engine-target.test.ts imports it
from ../../engineTarget and asserts at least six cases, including
'non-loopback over plain http is REFUSED (the core SEC-005 case)'
and 'an unparseable URL fails safe'
NO test exercises signIn, so nothing asserts :111 is ever reached
So deleting that one line leaves all six gate tests GREEN. The control
is proven correct and its call site is unpinned -- the same shape as
the planSave/full-replace row, and the reason 'write tests for auth.ts'
is the wrong instruction. The test to write asserts that signIn
CONSULTS the gate BEFORE prompting: an ORDERING property, which no test
of the gate alone can express.
Second time today a 'zero tests' claim was not zero (after
test_tray_shell.py). Both times the coverage that existed sat one
import away from the thing the row was worried about.
…act (BACKLOG #1100) Four for four, which is worth stating because it is the opposite of what ch02-10 produced against wiring_runner.py. Drift really does track the churn of the cited file. 124 signOut revoke -- the code states it in its own comments: :76 is 'return true; // nothing to revoke' and :82 is 'return false; // could not reach the engine to revoke -- the session lives until it times out'. BOTH non-revoking paths return a value the caller cannot distinguish from success, which is what makes the missing test load-bearing rather than merely absent. 125 chat prompt -- the cited span really is four bare parts.push() calls in the handler body (summary, active editor code, task, user request). Adding a fifth is a one-line edit with NO seam to assert against. That is why it is a PHI risk and not a style complaint: CLAUDE.md section 9 confines the assistant to code_only, and that confinement currently exists only as the ABSENCE of a parts.push of a message body. 129 runTest.ts:13 is exactly 'const extensionDevelopmentPath = path.resolve(__dirname, "../../");' so the suite loads the source tree, never the packaged artefact. 130 test_ide_artifacts.py contains exactly TWO tests, both HL7 media artifacts -- count and subject both right. Flagged as a CLEAN enumeration, because several counts elsewhere in this plan were not.
… monotonic (BACKLOG #1100) All ten mirror anchors resolved against the 33 function declarations in ide/media/stepsWebview.js. blockExtent:68 and captureBlock:83 were already exact; the rest drifted +1, +17, +18 or ~+22. The drift is MONOTONIC IN LINE NUMBER (+0, +0, +1, +1, +17, +17, +18, +18, +18, ~+22), which is the signature of insertions ABOVE rather than edits within. A single uniform offset would NOT have re-pointed these correctly, so each was resolved individually. Worth recording as a re-pointing method: check whether the offset is constant before applying one. The row's SUBSTANCE needed nothing -- it is already self-maintained, recording 'Yes, as of BACKLOG #233', the steps-mirror.test.ts jsdom parity suite, that both original grounds are spent, and the single live divergence that suite found (canDropRow accepting a read-only code row the webview refused) now closed. Also correcting myself: I first read the anchor as clipLabel:30 and diagnosed a dropped-digit transcription error. It is :309 -- MY OWN TRUNCATED PRINT cut the last digit, and I diagnosed from the truncation. Reading the full row dissolved it. Same byte-window mistake this sweep keeps finding in the plan, committed against the plan.
…R than stated (BACKLOG #1100) Row 65 CONFIRMED and the row UNDERSTATES its own finding. All 7 committed fixtures under ide/src/test/fixtures/lens/ lack 'suite', and they ALSO all lack 'label' and 'operand' -- not merely adt.json and IB_RADIOLOGY_SR.json as written. adt.json's complete key set is 13 keys (control, def_line, handler, handlers, kind, line_end, line_start, module, nesting, outbounds, recognized, rows, test_src) with none of the three at any depth, while messagefoundry/lens.py emits all three. Positive control: the same walker that reports them absent returns those 13 keys, so the absence is about the fixtures, not the probe. Anchor re-pointed: suite is stepsModel.ts:42-44, not :29-32 (which is now a row-KIND union). The comment at :42 confirms the drag/drop scoping role -- it greys an up/down at a suite edge so a reorder never crosses into or out of an if/for body -- and :552-553 consumes it. Row 67 CONFIRMED, all three anchors drifted. The real path filter is ci.yml:1007, grep -qE '^(ide/|\.github/workflows/ci\.yml)', so a PR touching messagefoundry/lens.py does not match and the leg never runs. The ide job is :818 and ci-gate's needs: is :2135-2141 without ide. Best evidence is the workflow's own comment at :820: 'ide is NOT a required check and ci-gate does NOT needs: ide'. The row's claim is written into the file it describes.
…the prior commit (BACKLOG #1100) 60 broke lines 65 and 67 -- 7 and 6 columns against a 5-column header. My replacement text contained bare | characters: a TypeScript union rendered as 'note | ... | route', and a grep -qE alternation quoted verbatim. Both are cell separators in a markdown table. Replaced both with prose that carries the same meaning and no pipes. THE GATE CAUGHT THIS AND I COMMITTED ANYWAY. I batched the column check and the commit into one command block, so the MISALIGNED lines printed and the commit ran regardless. That is the exact failure I hit early in this session and wrote a rule against: RUN THE GATE AS ITS OWN STEP AND READ IT BEFORE STAGING. Having the rule and having written it down did not help, because batching is what makes the mistake convenient. The information was on screen the whole time. It was not missing, it was unread -- which is worse, and is the same shape as several findings in the plan itself.
…ount (BACKLOG #1100)
I had ch01 down as out of scope because it has ZERO P0 rows. It has
THIRTEEN file:line citations, which is the sweep's ACTUAL subject.
'Chapters with P0 rows' and 'chapters with verifiable citations' are
different sets, and I had been prioritising by the wrong one all
session -- the same measure-one-thing-name-another error this sweep
keeps finding, now in my triage rather than my probes.
The chapter itself is in good shape. Checked:
__main__.py:98 --shard EXACT (serve.add_argument( at :98,
'--shard' at :99)
__main__.py:115 supervise exact
release.yml:477 release-harness EXACT
__main__.py:349 generate DRIFTED +1 -> :350
Re-pointed the one drift. The generate subparser is
'generate = sub.add_parser(' at :350 with the name on :351.
Worth recording how nearly I got that wrong: my first probe searched
for add_parser("generate" and returned ZERO, which reads as 'the
subcommand was removed'. It failed because the name is on the NEXT
line. A control (38 add_parser calls exist in the file) plus a broad
search found it immediately. Fourth misleading zero today from a
pattern-shaped probe, and the first one I caught BEFORE drawing the
conclusion rather than after.
…t (BACKLOG #1100)
ch07 cites the lens Steps backend at lens.py:270/285/1406/1423. :270
had drifted onto a BLANK LINE; the function is def _native_action_row(
at :271. Re-pointed.
Deliberately did NOT re-point the other three. They land on real code
-- :285 an assignment inside a params loop, :1406 a 'return (', :1423
an 'if field is not None:' -- but all three are MID-FUNCTION rather
than at a definition, and the row states no intent to check them
against. Marked NOT VERIFIED, ONLY NOT OBVIOUSLY WRONG.
That distinction is the whole limit of the blank-line scan and it is
worth carrying in the document rather than only in the handoff: the
scan finds anchors that drifted onto WHITESPACE and is blind to ones
that drifted onto PLAUSIBLE CODE. Silently 'fixing' the other three to
the nearest def would have manufactured precision I do not have.
One anchor rather than several, on purpose: ~8 minutes remained before
the projected window closed, and an uncommitted edit at cutoff is the
one state worth avoiding.
…1100) ch07 cites EnvRef decode and bounded casts at wiring.py:195/226. :195 had drifted onto a BLANK LINE between the end of the EnvRef dataclass and the factory below it. Re-pointed to :197, which is def env(key, *, default=_UNSET, cast=...) -> EnvRef -- the definition carrying the 'cast' this row names. EnvRef's own cast field is :194. :226 NOT CHECKED and deliberately untouched. It lands on code, and the row states no intent I can test it against, so re-pointing it would manufacture precision I do not have. Same call as the three lens.py anchors in the previous commit, and for the same reason: a confident wrong anchor is worse than a visibly stale one, because a spot-check reads it as fine. Two anchors now off the 66-item worklist. Both were the whitespace kind, which is the only kind the scan can find -- the plan's remaining exposure is anchors that drifted onto PLAUSIBLE code, and no cheap signal exists for those.
…ding row The BACKLOG #1100 audit's flagship withdrawn row (engine sharding CI coverage) cited ci.yml at :1348, :1551, :993, :1371, :1372, :1571 when written on 2026-08-15. ci.yml has grown roughly 490 lines underneath it since. Every anchor re-verified against the current file and re-pointed: :1836, :2039, :1407, :1859, :1860, :2059. The substantive claims (three named CI steps, gating on MEFOR_TEST_SQLSERVER/MEFOR_TEST_POSTGRES, the meta-gate in test_serverdb_ci_coverage.py) all still hold -- only the coordinates moved. Two of the six citations appear twice in the row (once in the clause-2 discussion, once in the evidence column); both occurrences of each are re-pointed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…KLOG #1100) Lander-authored per ADR 0165: the branch this landed from (stranded PR 433) had its own progress note at 394e2a3, but that commit is builder-authored ledger content, which the owner's 2026-08-13 ruling reserves to the Dispatcher or Lander. Re-authored here rather than cherry-picked, with the counts independently re-verified against the actual landed diff (18 files, +90/-75, matching the branch's own claim exactly) rather than carried forward unverified. The item stays OPEN: nobody has verified the nine sites it names are among the revised chapters, which the note says plainly. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part A of stranded PR #433 (
claude/hopeful-chaplygin-3158c6), per Cleaner's grading(
.git/mefor-coord/handoffs/CLEANER-2026-08-26-FOR-LANDER-stranded-pr-grading.md) and the owner's2026-08-26 ruling to disarm that PR's auto-merge and split it. This is the BACKLOG #1100 master-test-
plan audit -- the 64-commit doc correction pass, plus two Lander-added commits. Cherry-picked onto a
fresh branch off current main; the original ref's auto-merge is disarmed and never at risk from this.
The 64 commits landed as one clean range cherry-pick (
1e926ec9c^..c187411f6), zero conflicts,exactly matching Cleaner's own measurement (18 chapter files, +90/-75, 65 rewritten table rows).
Each corrects a specific false or stale claim in
docs/testing/master-test-plan/-- rows assertingsuites "run nowhere" or "are invoked by no leg" when they do run, drifted line-number anchors,
self-audited counting errors caught and fixed in later commits on the same branch.
Plus two Lander-authored commits, for two different reasons:
627b8dde1-- re-points sixci.ymlanchors in the ch17 engine-sharding row that decayed sincethe audit was written (2026-08-15 -> now, ~490 lines of ci.yml growth underneath it). The
substantive claims (three named CI steps gating on
MEFOR_TEST_SQLSERVER/MEFOR_TEST_POSTGRES,the
test_serverdb_ci_coverage.pymeta-gate) all still hold; only the line numbers moved. Caughtmy own first attempt at this leaving two of six citations half-fixed (they appear twice in the row,
once per column, and my first pass only replaced the first occurrence of each) before it was ever
committed -- redone and verified with an explicit before/after count for every citation.
0467580b6-- re-authors the branch's own progress note (originally394e2a32e) rather thancherry-picking it. That commit is builder-authored
docs/BACKLOG.mdcontent, which ADR 0165 andthe owner's 2026-08-13 ruling reserve to the Dispatcher or Lander. Same substance (item #1100
stays OPEN; the nine sites it names have not been verified as among the revised chapters), same
counts, independently re-verified against the actual landed diff rather than carried forward
unchecked -- 18 files, +90/-75, matching the original claim exactly.
Verified before pushing:
backlog_status_check.pyclean (602 items, one status each), the docs/link-resolution, docs-runbooks, backlog-status and backlog-citation test suites all pass (71 tests).
Does not touch
claude/hopeful-chaplygin-3158c6itself. Part B (the six-item engine payload,including a fix for a CI guard that's currently green and testing nothing) is PR #613.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com