A defect audit built on controls and evidence grades

Question: How can defect candidates in file lifecycle, graph lifecycle, and editing UI be reduced to refutable evidence rather than a list of suspicions?

Observation: Paired bug and control arms on a green baseline retained 14 of 45 candidates, but the complete decision ledger for the other 31 was not preserved.

Decision: Publish the 14 with their evidence grades, audit-time severity, and reproductions, without presenting them as the current backlog or as work by 14 human reviewers.

The 45→14 reduction is an evidence-retention ledger, not a performance funnel.

1. Define what counts as a defect before looking for one

The base commit was 96aaf8e6; the executable audit record landed in 523dd576. At the start, 982 frontend tests across 85 files and 1,010 Rust backend tests all passed. Only a new failing assertion on top of that green baseline was treated as defect evidence.

Each candidate needed at least two conditions. The bug arm exercised the suspected input or state; the control arm exercised an adjacent condition where the same code should behave normally. Without both, the audit could not distinguish a product defect from intended behavior, mistranscribed test logic, or a machine-specific effect. Its unit of analysis was an independent defect claim, not a user session or an occurrence rate.

Baseline suite	n · unit · condition	Result
Frontend	982 tests · 85 files · audit-start checkout	0 failures
Rust backend	1,010 tests · cargo test --lib · audit-start checkout	0 failures

2. Every conclusion carried an evidence grade

Grade	What the evidence executed	What it cannot establish
T1 · live UI	Real App.tsx in Chromium with the user action reproduced	Other operating systems or long-run frequency
T2 · live logic	Shipped function called directly, or private logic transcribed and checked against source	Integration effects outside transcribed logic
T3 · deductive trace	Exhaustive call-graph trace plus a guarded sibling path	Runtime frequency
F · live forensics	Read-only measurement of one real 1.2 GB database and vault	Generalization to other users or installations

Evidence grade and severity answer different questions. The grade records how a claim was checked; severity records the harm if it fires. Neither is a numeric proxy for the other.

3. What the 45→14 reduction actually preserved

The primary record reports 45 candidates triaged and challenged until 14 remained. What survives is the ID, audit-time severity, evidence grade, reproduction narrative, and selected rejected hypotheses for those findings. It does not preserve a complete 45-candidate manifest, one decision for each of the 31 dropped candidates, or reviewer-level raw logs. The evidence therefore does not support saying that all 31 received independent experiments or that 14 people each reviewed one finding.

ID	Severity on 2026-07-31	Evidence	Preserved defect claim
C1	critical	T1	Partial listings inferred deletion and closed a dirty tab without its guard
C2	high	T1 + T2	Folder operations matched open tabs only by exact path
C3	high	T2	Only one caller cascaded path changes
C4	high	T2	Cut–paste into the same folder changed the file name
M1	medium	T2	Case-only rename failed
M2	medium	T2	Graph rekey retained the destination and merged two documents
M3	medium	T2	Moving a vault folder lost and overwrote user verdicts
M4	medium	transcribed T2	Rewind resurrected a renamed file at its old path
M5	medium	T1 + vitest	Table-widget write-back was lossy
M6	medium	F, partial	Workspace switching destroyed a graph-store cache
M7	medium	T3	Extraction after workspace close could overwrite graph.nq
L1	low	F + T2	Notifications remained for a deleted note
L2	low	vitest	A frontmatter vertical bar rendered as a destructively editable table
L3	low	vitest	Table-cell selection ranges drifted

These are post-challenge severities recorded on 31 July, not initial candidate labels. C3 and M3, for example, moved from critical to high and medium. Correcting severity, rather than increasing the confirmed count, was the practical output of refutation.

4. Executable artefacts must be read with assertion direction

At the audit commit, the record counted 11 Rust probes, 10 frontend assertions, two e2e specs, and a six-arm permanent regression spec for C1. Those are a historical inventory pinned to 523dd576, not a claim about the current number of test functions.

Artefact	Audit-time assertion	Signal when the defect exists
src-tauri/src/audit_probe.rs	Directly asserts buggy behavior	Pass
tests/unit/audit_*.test.ts	Asserts correct table round-trip behavior	Fail
tests/e2e/audit_*.spec.ts	Labels bug or fixed behavior per arm	Interpret with its label
tests/e2e/tabLifecycle.spec.ts	Asserts correct post-fix tab lifecycle	Six arms failed before the fix

A green test is not self-explanatory. A reproduction that asserts the bug should fail after the fix; a regression test that asserts the desired behavior should pass. Promoting one without reversing its assertion direction can leave a meaningless test that remains green after repair.

5. The contribution is a refutable structure, not the defect count

The 14 findings collapsed into six boundary failures: missing cascades for path changes; a reconciler whose observation scope did not match its deletion authority; exact-path-only tab guards; collision handling that did not recognize the source as a possible destination; reuse of display normalization in table write-back; and state transitions that destroyed a cache before claiming synchronization.

The audit also retained rejected proposals. The claim that workspace switching forced full paid re-extraction was rejected when 1,727 of 1,727 body hashes matched disk; the claim that notifications survived indefinitely was rejected by the 30-day retention and 2,000-row trim. These examples are useful do-not-repropose records, but they do not reconstruct the complete ledger for all 31 rejected candidates.

6. Separate audit-time observations from current state

This record describes the discovery process on 31 July 2026, not the current backlog. Later commits changed several implementations and tests, so it cannot honestly say that all 14 remain open, that the Rust file still contains 11 probes, or that two e2e cases are still unresolved. Current status requires a separate check of each fix commit and the latest test suite.

The audit reproduced existence, not real-world frequency. Its live forensics came from one machine and one user’s installation; UI runs were tied to that environment. The live counterfactual analysis of rewind graph scope was performed on 1 August with a different method and conclusion, and is therefore a separate record.

7. Reproducibility and evidence boundary

Evidence	Preserved observation and condition	Missing or non-generalizable evidence	Primary source
Green baseline	Frontend 982/85 files and backend 1,010, all with 0 failures · based on 96aaf8e6	Current test counts and status	docs/details/lifecycle-usability-audit-2026-07-31.md:9-17
Evidence grades	T1, T2, T3, and F definitions attached to conclusions	A probabilistic conversion between grades	docs/details/lifecycle-usability-audit-2026-07-31.md:19-25
Fourteen findings	Titles, severities, and evidence for C1–C4, M1–M7, L1–L3	Complete 45-candidate manifest and one decision for each of the 31 dropped	docs/details/lifecycle-usability-audit-2026-07-31.md:60-264
Refutation stage	Primary record says 14 independent challenge passes occurred	Identity of 14 humans, per-review logs, or complete independence	docs/details/lifecycle-usability-audit-2026-07-31.md:3-5
Executable artefacts	Audit-time probes, assertions, e2e specs, and six-arm regression	Current artefact count and unresolved status after later fixes	docs/details/lifecycle-usability-audit-2026-07-31.md:27-37
Selected rejections	Representative rebuttals including 1,727/1,727 hashes and retention controls	Full mapping for all 31 rejected candidates	docs/details/lifecycle-usability-audit-2026-07-31.md:701-725