audit: prove every permanent-refusal, plugin and generation coverage state #72

New issue

Closed

opened 2026-08-18 12:34:17 +02:00 by buildagent · 1 comment

buildagent commented

2026-08-18 12:34:17 +02:00

Member

I034 fixed a freshness barrier that read an ABSENT row as proof of exclusion, permanently bricking changed_symbols and review_diff. The fix taught the WALKER stage to prove exclusion.

I040 found two more doors onto the same brick, both live in production, neither filed:

Door	Symptom	Closed
Walk — skip dirs, hidden, ignore files	tracked file under `dist/` bricked both diff tools	I034
Extension — no plugin / not text-eligible / plugin-EXCLUDED	`*.Designer.cs` reported `index_stale: true` FOREVER; the barrier waited for a row that can never exist	I040
Content — non-UTF-8 code, binary text, undecodable text	a tracked Latin-1 `.rs` denied `changed_symbols` on EVERY call, burning 1.24 s of bounded wait each time and hiding the fresh data in the same diff	I040, after review

The pattern is identical every time: "will this file ever be indexed?" is answered in stages, and a prover was built for one stage while the later stages kept refusing files silently. walker::Coverage models the walk; index::path_eligibility now models the extension gate; index::content_eligibility now models the content gates.

Ask

Audit for any REMAINING stage that can permanently refuse a file, and check each is modelled:

the writer — can it reject a parsed file after classify_walked accepted it?
parse errors — a file that parses to an error gets a row with parse_error set, so it is not this class, but confirm the barrier treats it as settled rather than pending
the size cap re-check between walk and read (index.rs has a TOCTOU guard) — a file that grows past the cap mid-walk
text-only files that grow past the cap between walk and read
anything platform-specific (Windows sharing violations, EACCES) that is TRANSIENT and must therefore stay pending, not become never — the failure mode in this direction is the opposite one and equally bad

The generalisation worth writing down

A three-state disclosure needs every state audited, not just the alarming one. I040's review found pending — the state nobody was worried about — was a promise ("retry, the watcher will get it") that eight classes of path could never keep. never was carefully proved; pending was assumed safe because it sounded neutral.

Runtime-plugin architecture expansion

#75 adds new refusal and waiting stages, so this audit becomes a prerequisite to #78/#80 rather than a one-time walker review.

Additional doors to model:

package requested but not installed;
package installed but digest/ABI invalid;
capability approval absent;
grammar/query/extractor rejected;
worker timeout/crash/quarantine;
claim conflict/precedence rejection;
pending generation build or validation;
failed activation with previous generation still active;
contribution-level refusal in a mixed-language file;
package removal returning a path to text-only/unclaimed;
linked projects using different plugin sets.

Each state must answer two independent questions:

Can the active generation answer now?
Can the requested state converge without user action?

pending is valid only for state that can progress automatically. not_installed, approval_required, rejected and quarantined require explicit action and must never carry “retry in a moment.” A failed pending generation must not hide usable results from the previous active generation.

Acceptance now includes a registry-style stage matrix covering walk, extension/claim, content, plugin host, fact validator, generation and writer. Every terminal state has a proving component and stable reason; every transient state has a tested convergence mechanism.

I034 fixed a freshness barrier that read an ABSENT row as proof of exclusion, permanently bricking `changed_symbols` and `review_diff`. The fix taught the WALKER stage to prove exclusion. I040 found **two more doors onto the same brick, both live in production, neither filed:** | Door | Symptom | Closed | |---|---|---| | **Walk** — skip dirs, hidden, ignore files | tracked file under `dist/` bricked both diff tools | I034 | | **Extension** — no plugin / not text-eligible / plugin-EXCLUDED | `*.Designer.cs` reported `index_stale: true` FOREVER; the barrier waited for a row that can never exist | I040 | | **Content** — non-UTF-8 code, binary text, undecodable text | a tracked Latin-1 `.rs` denied `changed_symbols` on EVERY call, burning 1.24 s of bounded wait each time and hiding the fresh data in the same diff | I040, after review | The pattern is identical every time: **"will this file ever be indexed?" is answered in stages, and a prover was built for one stage while the later stages kept refusing files silently.** `walker::Coverage` models the walk; `index::path_eligibility` now models the extension gate; `index::content_eligibility` now models the content gates. ## Ask Audit for any REMAINING stage that can permanently refuse a file, and check each is modelled: - the writer — can it reject a parsed file after `classify_walked` accepted it? - parse errors — a file that parses to an error gets a row with `parse_error` set, so it is not this class, but confirm the barrier treats it as settled rather than pending - the size cap re-check between walk and read (`index.rs` has a TOCTOU guard) — a file that grows past the cap mid-walk - text-only files that grow past the cap between walk and read - anything platform-specific (Windows sharing violations, EACCES) that is TRANSIENT and must therefore stay pending, not become `never` — the failure mode in this direction is the opposite one and equally bad ## The generalisation worth writing down A three-state disclosure needs **every** state audited, not just the alarming one. I040's review found `pending` — the state nobody was worried about — was a *promise* ("retry, the watcher will get it") that eight classes of path could never keep. `never` was carefully proved; `pending` was assumed safe because it sounded neutral. ## Runtime-plugin architecture expansion #75 adds new refusal and waiting stages, so this audit becomes a prerequisite to #78/#80 rather than a one-time walker review. Additional doors to model: - package requested but not installed; - package installed but digest/ABI invalid; - capability approval absent; - grammar/query/extractor rejected; - worker timeout/crash/quarantine; - claim conflict/precedence rejection; - pending generation build or validation; - failed activation with previous generation still active; - contribution-level refusal in a mixed-language file; - package removal returning a path to text-only/unclaimed; - linked projects using different plugin sets. Each state must answer two independent questions: 1. Can the active generation answer now? 2. Can the requested state converge without user action? pending is valid only for state that can progress automatically. not_installed, approval_required, rejected and quarantined require explicit action and must never carry “retry in a moment.” A failed pending generation must not hide usable results from the previous active generation. Acceptance now includes a registry-style stage matrix covering walk, extension/claim, content, plugin host, fact validator, generation and writer. Every terminal state has a proving component and stable reason; every transient state has a tested convergence mechanism.

buildagent added the

labels