Degrade a partial window to possibly_present instead of refusing it

[lamemustafa]

Stacked on #294 (base claude/voucher-presence), like #308. It is one commit.

The problem

BookWindow::observed refused construction unless read == WindowRead::Complete, so a window that could not be proven complete produced no verdict at all. The adapter has no source-side control total for a nonempty window, so every nonempty window is Partial — which meant the voucher_presence tool refused every real window that held vouchers, returning presence_window_incomplete instead of answering.

That placement was right about the hazard and wrong about its blast radius. Only one of the three verdicts ever needed a complete window:

verdict	needs a proven-complete window?
Present	no — an identity match names a row in hand
PossiblyPresent	no — it authorises nothing
Absent	yes — "I did not find it" means "it is not there" only if you saw everything

The change

The gate moves from window construction to the sole PresenceStatus::Absent production site. BookWindow retains its WindowRead and exposes read(); both states construct. decide checks it last among the existing withholdings — after RemoteIdEvidenceUnavailable, ManualNumberNotSupplied and the party outcomes — and degrades a Partial window's would-be Absent to PossiblyPresent(UndecidedReason::WindowNotProvenComplete). Present and PossiblyPresent are produced from a Partial window exactly as before.

PresenceError::WindowIncomplete is deleted rather than deprecated; nothing produced or consumed it afterwards.

This is the fourth instance of an idiom already in that function, not a new mechanism.

What this does not claim

• The safety property is unchanged. The duplicate-invoice risk lives entirely in the Absent → "safe to post" path, and Absent is still only reachable from a window proven complete. This narrows what is withheld, not what is guaranteed.
• No source-completeness evidence now exists. The adapter still cannot prove a nonempty window complete. An empty window is the narrow case the existing emptiness control can still corroborate Complete, and it remains the only shape from which absent is reachable.
• No cardinality mechanism was found. CMPINFO/VOUCHER is a company-level counter, not window cardinality.

A bug found while documenting it

The voucher_presence description advertised the reason as presence_window_not_proven_complete. That is safe_reason_code's error-path spelling, and this flow no longer errors. UndecidedReason serialises through rename_all = "snake_case", so an item's reason field carries window_not_proven_complete — an agent matching the documented string would have matched nothing, silently, with no error anywhere.

The test meant to catch it was description.contains("presence_window_not_proven_complete"), which verified the documentation against itself and could not fail for the right reason. It is now anchored to reason `window_not_proven_complete` with a negative assertion on the prefixed form, so the two surfaces cannot drift back together silently. Driven to failure and restored byte-identical to confirm it discriminates.

ADR 0017

Updated to match: §2 now states the completeness gate at Absent's production keyed off read() rather than at construction, §4's Absent row requires a window proven read whole, and the three Consequences passages asserting construction-time refusal describe verdict-time degradation. The measured analysis is untouched — the source-side control total remains the only route to nonempty qualification, and the widened re-read stays rejected at a measured 1.95x for a detector that licenses nothing.

docs/adr/0017 is not a pinned compatibility-surface file. The three pinned Rust files that changed are resealed here.

Verification

Run locally under the pinned 1.96.0 toolchain, in CI's order:

check	result
cargo fmt --all --check (src-tauri)	clean
cargo test --workspace (src-tauri)	1500 passed, 0 failed, 1 ignored
cargo test --workspace --doc (src-tauri)	2 passed, 0 failed
cargo test --workspace (tools)	52 passed, 0 failed
cargo clippy --workspace --all-targets -D warnings (src-tauri)	clean
cargo clippy --workspace --all-targets -D warnings (tools)	clean
bridge-tally-compatibility gate	compatibility_gate_passed:unknown_claims=11:evidenced_claims=0

Zero warning:/error: lines across the whole log. The one ignored test is replay_the_twenty_invoice_engagement, a manual owner-authorized live read that needs the lab reachable.

The invariant is proven by a mirror pair — identical window contents and proposal, Partial withholds Absent, Complete yields it. Without the second, the first could pass because absence had broken generally. Two pre-existing tests encoded the old contract directly and were renamed and inverted rather than deleted.

Not run: frontend/JS tests and the feature-gated protocol and live-read variants CI runs separately, which this change does not touch.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[lamemustafa]

Evidence behind "no cardinality mechanism was found"

Recording the measurements so that claim in the description rests on data rather than assertion. All from today; the offline parts are reproducible from the captures under 50-projects/audit-sprint-2026-09-14/snap/akash/raw/agentfetch/ in the private vault.

CMPINFO/VOUCHER is not window cardinality

Across 53 captured windows of one book:

DISTINCT CMPINFO/VOUCHER across 53 windows: [458]
actual voucher-tag counts range: 0 .. 304

Exactly one distinct value while actual rows range 0–304 — including an empty day that still reports 458. A company-level counter, invariant to the requested window.

AlterID does not delimit a date range

Present and well-formed: 212 vouchers across 31 daily windows carry 212 ALTERID values, all distinct, range 16778–20873. AGENT_VOUCHER_FETCH requests it explicitly and the tool surfaces it as alter_id.

But it cannot bound a date window. Per 10-domains/11-tally/alterid-locality-decides-corpus-validity.md (verified 2026-07-31), AlterID rises as vouchers are entered, so a date window maps to a compact AlterID band only in a book entered in date order. A bulk-loaded book has no such locality — one day spans the whole range. Correlation is a property of the individual book, not of the protocol, so no AlterID bound generalises.

state: complete from the vouchers tool is a different claim

Verified live against a master build (13514994) on a populated window:

Shape Lab 2025-04-01..04-30 -> isError: False  state: complete  total: 13  963,188 bytes

That complete means the read finished without truncation. It is not the presence adapter's WindowRead::Complete, which means cardinality independently established. agent_presence.rs states the distinction directly: "a well-formed bounded response cannot be promoted to Complete merely because it contains rows." Conflating the two would look like a route to completeness and is not one.

Consequence

A nonempty window cannot be proven complete by any mechanism currently known, which is why the old construction-time refusal made the capability permanently unusable rather than temporarily limited. This change is the complete answer, not a stopgap.

Scope of these measurements

The 53-window and 212-voucher figures are from one book's captures under the fetch lists those reads used. They do not prove Tally exposes no count under some request shape nobody has tried — TDL collection functions in a compute position remain unprobed. They do establish that none of the three candidates actually available to Bridge today serves the purpose.

Two of my own earlier readings of these captures were wrong before this one: a regex using ASCII patterns against BOM-less UTF-16LE, then a bare <ALTERID> tag against a wire form carrying TYPE="Number" and a leading space. Both produced confident zeros. The figures above are from the corrected passes.