scip-query 0.20.0 → 0.21.0

package/skills/_shared/SKILL.md

@@ -1,101 +0,0 @@
----
-name: _shared
-description: Load only as reference material from within another scip-* workflow skill when that skill's own shortlist is insufficient — never invoke _shared directly as the owning workflow for a task.
-disable-model-invocation: true
----
-
-## Purpose
-
-`_shared` is the catalog every other scip-* skill draws its command vocabulary and correctness rules from: freshness/lookup mechanics, the full command-family list, detector precision tiers, postcheck rules, the event ledger, and the subagent evidence-boundary contract. It is not a workflow — no task should end with "I invoked `_shared`". Come here mid-task from another skill when that skill's own shortlist runs out.
-
-A SCIP index is the compiler-derived map of a repository: source files, symbols, references, imports, calls, dependencies. It differs from text search because it records what the language toolchain actually resolved, so a claim backed by it can name definitions and consumers rather than matching strings. A **graph fact** is anything produced from that index — a definition line, a reference site, a caller, a dependency, a reverse dependency, an affected consumer.
-
-**Match evidence to the claim.** Native search and file reads are valid for literal text, exact local source, and unambiguous local logic (e.g. a helper defined two lines down in the same file is not a resolution claim). Use scip-query whenever the claim depends on compiler-resolved identity or on a relationship set being complete — definitions, references, callers, dependencies, consumers, affected units, public surface. Many scip-query commands return a bounded/capped sample rather than an exhaustive set; say so explicitly rather than treating a bounded result as proof of completeness.
-
-## Triage table
-
-| Need | Where |
-|---|---|
-| Human-oriented command vocabulary and when-to-use notes | `references/command-catalog.md` |
-| Descriptor-owned questions, returned units, and default coverage for every command | `references/agent-contract-catalog.md` |
-| Detector precision tiers, diff-gate's ten checks, root-cause groups, event ledger, effectiveness | `references/detector-precision-and-diffgate.md` |
-| Subagent evidence-boundary contract, dead-code reference-counting status and residual gap | `references/evidence-and-dead-code.md` |
-| The edit-to-postcheck table (which postcheck to run after which kind of edit) | `scip-verify` skill — authoritative, do not duplicate it here |
-
-## Freshness gate
-
-Before the first SCIP graph fact in a work session, run `scip-query status --capabilities` once. If the reported generation is fresh, reuse it until source changes; do not repeat capability checks between commands against that same generation.
-
-After source changes, let an active watcher refresh the index. If status says the watcher is indexing, debouncing, cooling down, or already has a pending/claimed refresh request, wait for that work to finish and check once more instead of starting a competing refresh. Run `scip-query reindex` only when freshness is `stale`, `missing`, or `unknown` and the watcher is disabled, unavailable, or has failed to refresh. Re-check status once after that fallback completes.
-
-## Symbol lookup fallback ladder
-
-Look symbols up by partial name, no parentheses: `scip-query code parseConfig`, `scip-query trace loadSettings`. If a lookup is ambiguous or comes back empty:
-1. Retry with a shorter symbol name.
-2. If still unresolved, run `scip-query outline <file>` to get a tree of that file's symbols with line ranges.
-3. If outline doesn't resolve it, run `scip-query trace <name>` (definition plus every reference).
-4. Last resort, once you already know the file and line range: `scip-query code 'path/to/file.ts:START-END'`.
-
-`scip-query files <pattern>` is the step before step 1 when you have a name fragment but no path — feed its result into outline or the lookup ladder. `scip-query stats` gives index statistics; reach for it when validating that a reindex actually populated the index (e.g. during setup/calibration, not mid-exploration).
-
-## Reading a symbol once located
-
-- `scip-query members <symbol>` — every child of a symbol (methods, fields, nested types). Use once `hierarchy` or `by-kind` has identified a class/type, to see its full surface before editing or removing it.
-- `scip-query hierarchy <symbol>` — a method's ancestry chain up to its class and module. Use before editing a method, to understand the containing type's contract.
-- `scip-query by-kind <kind>` — every symbol of a SCIP kind (class, interface, enum, function…). Use after `scip-query kind-counts` (a histogram of kinds in the codebase) narrows down which kind is worth a systematic sweep.
-- `scip-query refs <symbol>` — every file referencing a symbol. This is the strong-signal confirmation step: whenever a dead-code or "is this used" claim needs checking, run `refs` before asserting it.
-
-## Structural surveys before a change
-
-- `scip-query system <module>` — full module map (files, symbols, deps in/out). Use to onboard to an unfamiliar module or produce a module-level briefing.
-- `scip-query surface <module>` — the symbols consumers actually use from a module. Compare against its declared exports to see whether public API can be pruned.
-- `scip-query imports <file>` — what a file imports. Use to audit a file's dependency footprint before moving or refactoring it.
-- `scip-query deps <file>` — internal files this file depends on (upstream blast radius).
-- `scip-query rdeps <file>` — files that depend on this file/module (downstream blast radius: who breaks if it changes).
-
-## Deeper semantics
-
-- `scip-query dataflow <symbol>` — reference-level dataflow: definition sites, usage sites, producers, consumers. Use when debugging or planning a change and location alone (`refs`) isn't enough — you need to know how data moves through the symbol.
-- `scip-query slice <symbol>` — a reference-level program slice, backward (what affects this symbol) or forward (what this symbol affects). Use to scope the minimum code touched by a targeted refactor.
-
-## Dead code and duplication
-
-- `scip-query dead [scope]` — repository-dead code, file-internal symbols, implicit-usage signals. Cross-check any hit with `refs` before deleting; see `references/evidence-and-dead-code.md` for the one residual false-dead gap (ambiguous leaf name reached only through a re-exporting barrel in a workspace package).
-- `scip-query isolated` — completely orphaned symbols with no references at all; the stricter sibling of `dead`, same reference-counting layer, same residual gap caveat.
-- `scip-query similar [symbol] [other]` — heuristic function-similarity candidates from callee fingerprints. Good-with-review signal: read the code before treating a hit as a real duplicate.
-- `scip-query similar-files [file]` — heuristic similar-file candidates from dependency profiles. Use before writing a new file, to check whether a sibling already does the job; review before acting.
-
-## Coupling and architecture health
-
-- `scip-query fan-in [symbol]` — how many files reference an exact symbol. Use to gauge a symbol's criticality/blast-radius before changing its signature.
-- `scip-query fan-out [file]` — how many external symbols a file uses (or the top-fan-out list across the codebase). Use to gauge a file's coupling debt before deciding whether to split it.
-- `scip-query coupling [file1] [file2]` — coupling between two named files, or the top coupled pairs codebase-wide. Use when a specific pair is suspected of hidden coupling, or when scanning for the worst offenders.
-- `scip-query cycles` — circular dependency chains between files. Use when investigating why files resist clean layering or isolated testing.
-- `scip-query bottlenecks` — symbols/files with high fan-in *and* high fan-out (coupling hubs). Use to prioritize a maintainability review.
-- `scip-query architecture` — evaluates project-owned architectural boundaries and dependency rules. Its baseline is what diff-gate's `architecture` check reads from directly (see `references/detector-precision-and-diffgate.md`).
-
-## History
-
-- `scip-query co-change [file]` — files that change together in git history without a dependency edge: hidden-coupling candidates the graph misses. Good-with-review signal. Use before splitting a file to check whether its historical co-change partner also needs updating.
-
-## Governance: config, suppression, effectiveness
-
-1. `scip-query init` — creates `.scipquery.json` for a project. Run once, at bootstrap, before any config-dependent command.
-2. `scip-query config-validate` — validates `.scipquery.json`, including structured suppressions and declared coupling groups. Run after hand-editing either.
-3. `scip-query suppress <id>` — records an accepted finding as a file under `.scipquery/suppressions/` with a required reason, the moment you decide a finding is a false positive or an accepted risk. This is what feeds the "suppressed" count in effectiveness.
-4. `scip-query effectiveness [--since 30d] [--check <check>]` — per-check history from the committed outcome ledger: findings caught, comparison-verified fixed, suppressed, still open, "moved" (rename noise), legacy/non-comparable "unverified" resolutions, precision (verified-fixed ÷ (verified-fixed + suppressed)), and median days-to-fix. Run this periodically, or the moment diff-gate feels noisy, to see which checks are earning their keep — then either tune that check's config, suppress the standing findings with reasons, or consciously accept the noise. Do not let unresolved findings accumulate as wallpaper.
-
-Standalone detector commands (outside diff-gate) are not outcome-tracked in this ledger until they expose complete-scan evidence. A pre-commit rerun of diff-gate reuses the same comparison base directly; after HEAD advances, a clean diff-gate run automatically replays the stored comparison commit. A dirty or unavailable replay leaves the effectiveness finding pending rather than manufacturing a fix result.
-
-## Postcheck
-
-At final verification for a coherent diff, run `scip-query status --capabilities` once and `scip-query diff-gate`. Repeat them only if the diff changes afterward. Fix each finding, or record a specific acceptance reason for each one left unresolved (findings marked `(advisory)` never block — treat them as context, not obligations). Do not report success while a diff-gate finding is unexplained. The authoritative table of *which* postcheck to run for *which* kind of edit lives in `scip-verify`; invoke that skill rather than re-deriving it here.
-
-## Subagent evidence boundary
-
-When a subagent gathers scip-query evidence, its prompt must carry these rules verbatim:
-- Use scip-query for any compiler-resolved-identity or completeness claim; native search/file reads are valid only for literal source content and unambiguous local logic (e.g. a helper defined in the same file).
-- The trigger is resolution or completeness, not whether execution crosses a call boundary: asserting what `handler(x)` does without resolving what `handler` is requires scip-query evidence; reading a helper defined two lines down in the same file does not.
-- Cite the evidence source appropriate to each claim, and state plainly when neither source establishes a claim completely.
-
-Reject a subagent's finding if it sources a resolution or completeness claim from text search alone. Do not reject a literal-content claim merely for citing a file read as its evidence.

package/skills/_shared/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SCIP Shared Reference"
-  short_description: "Reference only - not a workflow"
-  default_prompt: "Load $_shared only from inside another SCIP skill when its own command shortlist is insufficient."

package/skills/_shared/references/agent-contract-catalog.md

@@ -1,105 +0,0 @@
-# Descriptor-owned command contracts
-
-Use this catalog when choosing between commands or deciding whether a result
-can support a complete claim. Each row is generated from the CLI descriptor
-that also drives help and JSON metadata. “Default coverage” describes the
-normal invocation; the actual JSON result remains authoritative when options,
-scope, runtime capability, or pagination change it.
-
-<!-- BEGIN GENERATED AGENT CONTRACT CATALOG -->
-| Command | Questions it answers | Returns | Default coverage |
-| --- | --- | --- | --- |
-| `scip-query reindex` | Can the repository index be refreshed, and which language shards succeeded? | index generation, shard statuses, reuse diagnostics, and failures | `complete` |
-| `scip-query augment-sources` | Can source files omitted by upstream indexers be added to the index? | added document counts and augmentation status | `complete` |
-| `scip-query augment-vue` | Can Vue SFC references be compiler-resolved and added to the index? | Vue augmentation counts, project, and diagnostics | `complete` |
-| `scip-query stats` | How large and fresh is the current index? | document, symbol, definition, reference, size, and build-time totals | `complete` |
-| `scip-query files <pattern>` | Which indexed files match this text pattern? | matching file paths | `complete` |
-| `scip-query methods <className>` | Which methods belong to this class? | method names and line ranges | `complete` |
-| `scip-query refs <symbol>` | Which files reference this symbol?; Is this symbol used anywhere, or only defined? | referencing file paths; reference line numbers grouped by file | `bounded` |
-| `scip-query trace <symbol>` | Where is this symbol defined, and everywhere is it referenced? | definition sites with source and signature; referencing files with line numbers | `bounded` |
-| `scip-query deps <file>` | Which internal files does this file depend on? | dependency file paths | `complete` |
-| `scip-query rdeps <file>` | Which internal files depend on this file? | reverse-dependency file paths | `complete` |
-| `scip-query system <module>` | What is in this module?; What does this module depend on, and what depends on it? | module file paths; exported symbols with line ranges; internal dependencies; reverse dependencies | `complete` |
-| `scip-query surface <module>` | Which exported symbols do external consumers actually use? | consumer paths and consumed symbol identities | `complete` |
-| `scip-query dead [scope]` | Which symbols have no repository use or only file-internal use? | symbol identities, ranges, liveness classes, and evidence | `bounded` |
-| `scip-query hotspots` | Which symbols are the largest reference choke points? | ranked symbol identities with reference and file counts | `bounded` |
-| `scip-query imports <file>` | Which symbols does this file import? | imported symbol identities and source files | `bounded` |
-| `scip-query imported-by <symbol>` | Which files import this symbol? | importing file paths | `complete` |
-| `scip-query unused-imports <file>` | Which imports in this file are unused? | import symbol identities and source ranges | `bounded` |
-| `scip-query outline <file>` | What symbols and nesting exist in this file? | symbol names, nesting, and line ranges | `complete` |
-| `scip-query members <symbol>` | Which members or nested symbols belong to this symbol? | child symbol identities, kinds, and ranges | `complete` |
-| `scip-query fan-in [symbol]` | How many files reference this symbol, or which symbols have highest fan-in? | exact symbols with referencing-file counts | `bounded` |
-| `scip-query fan-out [file]` | How many external symbols does this file use, or which files have highest fan-out? | files with external-symbol counts | `bounded` |
-| `scip-query coupling [file1] [file2]` | How strongly are these files coupled, or which pairs are most coupled? | file pairs with coupling evidence and scores | `bounded` |
-| `scip-query cycles` | Which file dependency cycles exist? | dependency-cycle file chains | `bounded` |
-| `scip-query architecture` | Does the repository obey its declared architecture boundaries? | boundary coverage and dependency-rule violations | `complete` |
-| `scip-query bottlenecks` | Which files are high-connectivity coupling hubs? | ranked files with fan-in and fan-out counts | `bounded` |
-| `scip-query isolated` | Which symbols are disconnected from the repository reference graph? | isolated symbol identities and files | `bounded` |
-| `scip-query by-kind <kind>` | Which symbols have this SCIP kind? | symbol identities, kinds, files, and ranges | `bounded` |
-| `scip-query kind-counts` | How many indexed symbols exist for each kind? | symbol-kind counts | `complete` |
-| `scip-query deep-chains` | Which dependency chains are deepest and riskiest? | ranked component chains with depth, risk, and recommendation | `bounded` |
-| `scip-query hierarchy <symbol>` | What lexical ownership chain contains this symbol? | ancestor symbol identities and depths | `complete` |
-| `scip-query call-graph <symbol>` | Who calls this symbol and what does it call? | caller and callee symbol identities with files | `bounded` |
-| `scip-query similar [symbol] [other]` | Which callable resembles this one, or how similar are these two? | symbol pairs, similarity scores, and shared evidence | `bounded` |
-| `scip-query similar-files [file]` | Which files have similar callable structure? | file pairs with similarity scores and shared symbols | `bounded` |
-| `scip-query react-component-duplicates [file]` | Which React components appear to duplicate one another? | component pairs with structural similarity evidence | `bounded` |
-| `scip-query react-hook-candidates [file]` | Which repeated React logic could become a custom hook? | component groups and shared hook-shaped behavior | `bounded` |
-| `scip-query react-large-component-pressure [file]` | Which React components have evidence of being too large or overloaded? | component identities with size and responsibility pressure | `bounded` |
-| `scip-query vue-component-duplicates [file]` | Which Vue components appear to duplicate one another? | component pairs with structural similarity evidence | `bounded` |
-| `scip-query vue-composable-candidates [file]` | Which repeated Vue logic could become a composable? | component groups and shared composable-shaped behavior | `bounded` |
-| `scip-query vue-large-view-pressure [file]` | Which Vue views have evidence of being too large or overloaded? | view identities with size and responsibility pressure | `bounded` |
-| `scip-query similar-chains` | Which transitive chains of similar symbols suggest repeated designs? | similarity-connected symbol chains and scores | `bounded` |
-| `scip-query extract-candidates` | Which cohesive code regions are strong extraction candidates? | symbol identities with cohesion, reuse, and extraction evidence | `bounded` |
-| `scip-query locality-candidates [symbol-or-file]` | Which definitions live far from most of their consumers? | symbols, current homes, consumer locality, and suggested homes | `bounded` |
-| `scip-query affected <symbol>` | Which downstream symbols could break if this symbol changes? | affected symbol identities, files, and traversal depths | `bounded` |
-| `scip-query change-surface <file>` | What public surface and consumers make this file risky to change? | defined symbols, external consumer counts, and risk levels | `bounded` |
-| `scip-query cleanup-plan` | What code can be deleted safely, and in what dependency order? | ordered cleanup batches, evidence, and optional verification outcomes | `bounded` |
-| `scip-query cleanup-apply` | Can a compiler-verified cleanup batch be applied to this working tree? | applied files, deletions, verification, and refusal reasons | `bounded` |
-| `scip-query co-change [file]` | Which files repeatedly change together without a declared dependency? | file pairs, co-change counts, confidence, and history context | `bounded` |
-| `scip-query recent-duplicates` | Did recent code reimplement established code? | recent and established symbol pairs with similarity evidence | `bounded` |
-| `scip-query doc-drift [doc]` | Which documentation may be stale relative to changing code? | document paths, coupled code subjects, and history evidence | `bounded` |
-| `scip-query unused-params` | Which trailing parameters are never read by their bodies? | candidate parameters with callable and file identities | `bounded` |
-| `scip-query diff-gate` | Does my current diff introduce something this repo blocks on?; What must I fix or explicitly accept before reporting the work done? | blocking findings with check id, message, and remediation; advisory findings; root-cause groups; changed file and symbol counts; process exit status (1 when blocking findings exist) | `bounded` |
-| `scip-query incomplete-migration` | Did this diff leave a helper extraction only partly migrated? | new helpers and similar unmigrated call sites | `bounded` |
-| `scip-query tla <operation> [spec]` | Does this TLA+ model and code mapping agree, or can the requested model artifact be generated? | checker status, conformance findings, trace coverage, or generated artifact paths | `bounded` |
-| `scip-query plan-context <target>` | What must I know before editing this target?; Who consumes it, and what breaks if I change it?; Has this target historically changed together with anything else? | definitions and references; callers and callees; dataflow producers and consumers; backward and forward slices; affected symbols; change-surface risk; dependencies and reverse dependencies; module files and exports; external surface use; complexity; churn; co-change partners; active suppressions | `bounded` |
-| `scip-query diff-impact` | Which symbols changed in this diff and which downstream consumers are affected? | changed symbols, downstream consumer identities, and impact paths | `bounded` |
-| `scip-query drift [module]` | Where has a module or abstraction drifted across parallel implementations? | drifted symbol families, files, and evidence | `bounded` |
-| `scip-query wrapper-candidates` | Which callables are unnecessary forwarding wrappers? | wrapper identities, targets, and forwarding evidence | `bounded` |
-| `scip-query passthrough-candidates` | Which parameters are passed through layers without local use? | parameter paths across call chains | `bounded` |
-| `scip-query stale-abstractions` | Which abstractions no longer earn their indirection? | abstraction identities with usage, change, and replacement evidence | `bounded` |
-| `scip-query complexity-hotspots` | Which symbols combine high complexity with high change pressure? | ranked symbols with complexity and churn evidence | `bounded` |
-| `scip-query self-audit` | How accurate are the fast evidence paths on a sample? | sample coverage, agreement scores, and disagreements | `sampled` |
-| `scip-query health` | What are the highest-priority verified health problems in this codebase? | health score, findings, priorities, baselines, and coverage notes | `bounded` |
-| `scip-query bench` | How fast are indexing and selected commands under this benchmark matrix? | timings, command outcomes, environment, and optional profiles | `sampled` |
-| `scip-query work-audit <profile>` | Which repeated computations in this profile waste the most measured time? | ranked repeated-work groups, counts, and avoidable duration | `bounded` |
-| `scip-query convergence <symbol1> <symbol2>` | How should these two similar symbols converge? | deprecated alias result for a two-symbol similarity plan | `bounded` |
-| `scip-query code <symbol>` | What is the compiler-resolved definition source for this symbol? | definition identity, source, and line range | `complete` |
-| `scip-query complexity <symbol>` | How structurally complex and connected is this symbol? | LOC, branch, complexity, callee, fan-in, and fan-out counts | `bounded` |
-| `scip-query dataflow <symbol>` | What defines, uses, produces, and consumes this symbol? | definition sites, usage sites, producer symbols, and consumer symbols | `bounded` |
-| `scip-query slice <symbol>` | What transitively affects this symbol, or what does it affect? | connected symbols with relationship and depth | `bounded` |
-| `scip-query install-skills` | Which scip-query skills were installed, updated, skipped, or conflicted? | skill target paths and install outcomes | `complete` |
-| `scip-query setup-hooks` | Were project-local agent hooks installed or removed safely? | hook config targets, changes, skips, and warnings | `complete` |
-| `scip-query check-deps` | Which scip-query and language-indexer dependencies are runnable? | dependency readiness statuses and remediation | `complete` |
-| `scip-query capabilities` | Which evidence and verification capabilities are available here? | capability matrix with availability and reasons | `complete` |
-| `scip-query capability-matrix` | Which evidence and verification capabilities are available here? | deprecated alias of the capability matrix | `complete` |
-| `scip-query redundant-reexports` | Which re-exports add no useful API boundary? | re-export sites, original definitions, and consumer evidence | `bounded` |
-| `scip-query duplicate-bodies` | Which callable bodies are exact duplicates? | callable groups with exact normalized-body identity | `bounded` |
-| `scip-query twin-drift` | Which same-concept twin implementations have drifted? | twin symbol pairs, history, and divergence evidence | `bounded` |
-| `scip-query twin-ab <symbolA> <symbolB>` | How do these two twin implementations differ in structure and behavior? | side-by-side symbol evidence and divergence classification | `complete` |
-| `scip-query not-implemented` | Which callables are placeholders rather than real implementations? | callable identities and placeholder evidence | `bounded` |
-| `scip-query decorative-checkers` | Which validation checks cannot meaningfully fail? | checker identities, call sites, and decorative behavior evidence | `bounded` |
-| `scip-query test-quality` | Which tests have weak assertions or poor production-code reach? | test identities with assertion and reachability evidence | `bounded` |
-| `scip-query similar-signatures` | Which callables have suspiciously similar signatures? | callable pairs with signature similarity evidence | `bounded` |
-| `scip-query init` | Can a starter scip-query configuration be created for this project? | configuration path and creation outcome | `complete` |
-| `scip-query config-validate` | Is this project configuration valid and internally consistent? | validation diagnostics with config paths | `complete` |
-| `scip-query suppress <id>` | Can this accepted finding be recorded with an auditable reason? | suppression identity, path, scope, and expiry | `complete` |
-| `scip-query effectiveness` | What handling outcomes has diff-gate observed, and what authority produced those observations? | per-check caught, fixed, suppressed, unresolved, provenance, and resolution-vs-suppression telemetry | `complete` |
-| `scip-query doctor` | Why is scip-query unhealthy or unavailable in this project? | config, freshness, dependency, and capability diagnostics | `complete` |
-| `scip-query setup` | Can scip-query be bootstrapped end to end in this project? | setup step outcomes, files, capabilities, smoke tests, and warnings | `complete` |
-| `scip-query setup-agent` | Can project agent guidance and optional git enforcement be seeded? | written, unchanged, and skipped agent files or hooks | `complete` |
-| `scip-query setup-ci` | Can a CI workflow enforce reindex and diff-gate on pull requests? | workflow path, rendered content, and write outcome | `complete` |
-| `scip-query uninstall` | Which scip-query-owned integrations can be removed without touching user-owned files? | removed, retained, skipped, and dry-run targets | `complete` |
-| `scip-query watch` | What is the watcher doing, or can its background service be started or stopped? | watcher/service state, generation, activity, and errors | `complete` |
-| `scip-query status` | Is the index fresh, complete, and usable for this project? | freshness, generation, language shards, watcher, and optional capabilities | `complete` |
-<!-- END GENERATED AGENT CONTRACT CATALOG -->

package/skills/_shared/references/command-catalog.md

@@ -1,118 +0,0 @@
-# Full command-family vocabulary
-
-Every command the scip-query CLI exposes. Commands marked ★ have a usage scenario in `SKILL.md` — treat this table as the index, not the reasoning. The catalog itself is generated from the CLI's command descriptors, not hand-maintained prose; if a command here looks stale, regenerate rather than hand-edit.
-
-## Index lifecycle
-- `reindex` ★ — indexes the codebase and converts it to SQLite.
-- `augment-sources` — adds source files skipped by upstream SCIP indexers to the documents table.
-- `augment-vue` — adds compiler-resolved Vue SFC references to the index using Volar.
-- `status` ★ — index status for this project (freshness, capabilities).
-- `stats` ★ — index statistics.
-- `watch` — watches in the foreground, or manages the per-project background refresh service.
-
-## Lookup and reading
-- `files <pattern>` ★ — find files matching a pattern.
-- `methods <className>` — list methods of a class with line ranges.
-- `refs <symbol>` ★ — find all files referencing a symbol.
-- `trace <symbol>` ★ — a symbol's definition plus all references.
-- `outline <file>` ★ — tree view of a file's symbols with line ranges.
-- `members <symbol>` ★ — every child of a symbol (methods, fields, nested types).
-- `by-kind <kind>` ★ — find symbols by SCIP kind.
-- `kind-counts` ★ — histogram of symbol kinds in the codebase.
-- `hierarchy <symbol>` ★ — a symbol's ancestry chain, method to class to module.
-- `code <symbol>` ★ — read the source for a symbol, bounded to its definition range.
-- `imports <file>` ★ — what symbols a file imports.
-- `imported-by <symbol>` — which files import this symbol.
-
-## Semantics and structure
-- `dataflow <symbol>` ★ — reference-level dataflow: definitions, usages, producers, consumers.
-- `slice <symbol>` ★ — reference-level program slice, backward or forward.
-- `deps <file>` ★ — files this file depends on (internal).
-- `rdeps <file>` ★ — files that depend on this file/module.
-- `system <module>` ★ — full module map: files, symbols, deps in/out.
-- `surface <module>` ★ — symbols consumers actually use from a module.
-
-## Dead code, duplication, and cleanup heuristics
-- `dead [scope]` ★ — repository-dead code, file-internal symbols, implicit-usage signals.
-- `unused-imports <file>` — imports not referenced in the same file.
-- `isolated` ★ — completely orphaned symbols with no references at all.
-- `similar [symbol] [other]` ★ — heuristic function similarity from callee fingerprints.
-- `similar-files [file]` ★ — heuristic similar-file candidates from dependency profiles.
-- `similar-chains` — heuristic similar-chain candidates from dependency flows.
-- `extract-candidates` — heuristic extraction candidates from isolated callee clusters.
-- `locality-candidates [symbol-or-file]` — directory-locality/ancestry candidates from consumer ownership.
-- `cleanup-plan` — ordered, batched deletion plan: graph-fact dead code plus cascade candidates it unlocks.
-- `cleanup-apply` — applies a compiler-verified cleanup-plan batch to the working tree.
-- `recent-duplicates` — directional duplicate candidates: recent code re-implementing established code.
-- `doc-drift [doc]` — stale-doc candidates: cited code, or co-changed code that kept changing after the doc stopped.
-- `unused-params` — speculative-generality candidates: trailing parameters no body uses (TS/JS).
-- `drift [module]` — unused imports and declared architecture violations; pass `--architecture` for boundary context.
-- `wrapper-candidates` — heuristic wrapper candidates called by one consumer. **Exploration only** — see precision tiers.
-- `passthrough-candidates` — heuristic passthrough candidates that forward to one callee.
-- `stale-abstractions` — heuristic candidates with 0-1 consumers. **Exploration only** — see precision tiers.
-- `complexity-hotspots` — heuristic complexity hotspots from LOC × fan-in × fan-out. Strong signal, ~90% precision.
-- `convergence <s1> <s2>` — **deprecated**, alias for `similar <s1> <s2> --plan`; prefer the latter.
-- `redundant-reexports` — barrel re-exports nobody imports through.
-- `duplicate-bodies` — exact duplicate small-body candidates across files.
-- `twin-drift` — same-name (or near-name) functions across files with diverged bodies.
-- `twin-ab <symbolA> <symbolB>` — generates a behavioral A/B vitest scaffold comparing two same-concept twins; a ready-to-fill file, not an auto-executor.
-- `not-implemented` — reachable placeholder stubs (throw-stub, TODO+return-default, empty body) with a real production caller; an unreachable stub belongs to `dead` instead.
-- `decorative-checkers` — validate*/verify*/check*/assert*/is*/has* callables with no reachable failure exit.
-- `test-quality` — assertion-free test bodies, a skipped-test ledger with git-blame age, mock-echo tests.
-- `similar-signatures` — functions with near-identical type signatures.
-
-## React / Vue heuristics
-- `react-component-duplicates [file]` — duplicated JSX structure candidates (tags, props, events, bindings).
-- `react-hook-candidates [file]` — hook-extraction candidates from shared state/effects/requests/handlers.
-- `react-large-component-pressure [file]` — large-component-pressure candidates from lines, JSX structure, hooks.
-- `vue-component-duplicates [file]` — duplicated template structure candidates (tags, bindings, slots, directives).
-- `vue-composable-candidates [file]` — composable-extraction candidates from shared state/effects/requests/bindings.
-- `vue-large-view-pressure [file]` — large-view-pressure candidates from template/script/style/external line counts.
-
-## Coupling, architecture, impact
-- `hotspots` — most-referenced symbols in the codebase (choke points).
-- `fan-in [symbol]` ★ — files referencing an exact symbol; top JSON rows include exact symbol identity.
-- `fan-out [file]` ★ — external symbols a file uses, or top fan-out codebase-wide.
-- `coupling [file1] [file2]` ★ — coupling between two files, or top coupled pairs codebase-wide.
-- `cycles` ★ — circular dependency chains between files.
-- `architecture` ★ — evaluates project-owned architectural boundaries and dependency rules.
-- `bottlenecks` ★ — high fan-in AND high fan-out symbols/files.
-- `deep-chains` — longest condensed dependency-component chains.
-- `call-graph <symbol>` — incoming callers and outgoing callees for a symbol.
-- `affected <symbol>` — transitive closure of symbols that could break if this symbol changes.
-- `change-surface <file>` — pre-change briefing: exports, consumers, blast-radius risk.
-- `co-change [file]` ★ — files that change together in git history without a dependency edge.
-
-## Diff, migration, formal modeling
-- `diff-gate` — gates the current diff; see `detector-precision-and-diffgate.md` for its ten checks.
-- `incomplete-migration` — partially-completed extraction candidates left un-migrated at similar sites.
-- `diff-impact` — changed symbols and downstream consumers from the current git diff.
-- `tla <operation> [spec]` — TLA+ workflow: verify a model/mapping contract, scaffold a draft model, generate a trace recorder, or check a recorded trace against the next-state relation.
-- `plan-context <target>` — pre-edit planning context for a symbol, file, or module.
-
-## Health, complexity, performance
-- `self-audit` — scores cheap evidence paths against the best available semantic/source oracle on sampled symbols.
-- `health` — composite codebase health report with a prioritized action list.
-- `complexity <symbol>` — per-symbol complexity: branches, cyclomatic estimate, fan-in/out, callees.
-- `bench` — benchmarks indexing and command runtimes for the repository.
-- `work-audit <profile>` — ranks exact repeated computations in a profiling JSONL file by measured avoidable time.
-
-## Setup, config, governance
-- `install-skills` — installs the nine bundled router, workflow, and shared-reference skills into Claude Code, Codex, and shared agent roots.
-- `setup-hooks` — installs or refreshes project-local Codex and Claude Code lifecycle hooks.
-- `check-deps` — checks whether scip-query and detected language indexers are actually runnable.
-- `capabilities` — reports which evidence/verification capabilities are available in this project.
-- `capability-matrix` — **deprecated**, alias for `capabilities --matrix`; prefer the latter.
-- `init` ★ — creates `.scipquery.json` for this project.
-- `config-validate` ★ — validates `.scipquery.json`, including suppressions and declared coupling groups.
-- `suppress <id>` ★ — records an accepted finding under `.scipquery/suppressions/` with a required reason.
-- `effectiveness` ★ — per-check effectiveness from the committed outcome ledger.
-- `doctor` — diagnoses config, index freshness, dependency readiness, project capabilities.
-- `setup` — bootstraps a project: automatic indexing, agent skills, index refresh, capability check, health report.
-- `setup-agent` — seeds an AGENTS.md/CLAUDE.md block pointing agents at the scip-query skills and diff gate, plus an optional git pre-commit backstop.
-- `setup-ci` — writes a GitHub Actions workflow running `reindex` and `diff-gate` on pull requests.
-- `uninstall` — removes scip-query-owned skill links, project hooks, and managed agent setup blocks.
-
-## General rule on coverage
-
-Each command's returned set is either complete (exhaustive) or bounded (capped/sampled). Where that isn't stated explicitly for a given command, assume bounded and say so before treating the result as proof of completeness — a bounded result narrows, it does not exonerate.

package/skills/_shared/references/detector-precision-and-diffgate.md

@@ -1,59 +0,0 @@
-# Detector precision, diff-gate, and the event ledger
-
-## Weight findings by measured precision, not volume
-
-Detector precision was calibrated against two external production repos on 2026-07-01 (`docs/validation/2026-07-01-external-calibration-*.md`). Use that calibration to decide how much a finding is worth acting on alone versus needing corroboration.
-
-**Strong signal — act on directly:**
-- `complexity-hotspots` (~90% precision)
-- `recent-duplicates` (~75% precision)
-- Graph facts from `refs`, `trace`, `deps`
-- Compiler-verified `cleanup-plan --verify` output
-
-**Good with review — read the cited code before acting:**
-- `duplicate-bodies`, `similar`, `co-change`, `doc-drift`, `twin-drift` (post-retune defaults)
-
-**Exploration only — near-zero precision on codebases with intentional layering or ambient types:**
-- `wrapper-candidates`, `stale-abstractions`, `drift --patterns`
-
-Never file a finding from an exploration-only detector without reading the cited code first. `convergence <s1> <s2>` and `capability-matrix` are deprecated aliases (`similar <s1> <s2> --plan` and `capabilities --matrix` respectively) — prefer the modern form.
-
-## diff-gate
-
-`diff-gate` gates the current diff for architecture regressions plus echo, migration, coordination, doc-drift, unused-param, and new-dead candidates, and exits 1 on blocking findings. It recognizes ten checks, any of which can be skipped individually with `--skip <check>`:
-
-| Check | Flags |
-|---|---|
-| `echo` | recent-duplicate-style echoes in the diff |
-| `incomplete-migration` | partially-completed extractions left in the diff |
-| `co-change-partner` | a missing historically-paired file |
-| `twin-partner` | an unedited same-name twin — **advisory**, never blocks |
-| `coverage-contract` | a configured `coverageContracts` enumeration drifted from ground truth (see `scip-setup`) |
-| `architecture` | a declared boundary violation absent from the shared baseline |
-| `doc-reference` | an uncited or stale doc claim |
-| `unused-params` | trailing parameters no body uses |
-| `new-dead` | dead code introduced by this diff |
-| `baseline` | only active with `--baseline`; compares all non-architecture health identities against `.scipquery-baseline.json` — distinct from `health --baseline` |
-
-The `architecture` check runs by default only when enforceable architecture rules and a baseline exist, and it reads that baseline file directly without running the full health suite.
-
-**Reading grouped output:** findings print grouped under a `Root-cause groups (N):` header before the flat list. A root-cause group's remediation usually clears every finding under it. The same remediation may repeat afterward in the flat list below the groups — that repetition is expected, not a separate issue.
-
-**actionTier** on baseline-backed findings tells you how directly to act:
-- `direct` — act on this finding alone.
-- `signal` — corroborating evidence; read before acting.
-- `support` — context only.
-
-Findings marked `(advisory)` never block; treat them as context, not obligations. Fix every finding, or record a specific acceptance reason for each one left unresolved — never report success while a finding is unexplained.
-
-## Event ledger
-
-Every completed diff-gate run — including JSON and hook mode — writes each caught/resolved/suppressed transition to its own committed `.scipquery/events/*.json` file. Independent branches should add independent event files rather than editing a shared log, and commit them with the corresponding change. Legacy `.scipquery/ledger/events.jsonl` records remain readable and migrate automatically on the next gate write.
-
-## Effectiveness
-
-`scip-query effectiveness [--since 30d] [--check <check>]` reports, per check: findings caught, comparison-verified fixed, suppressed, still open, "moved" (rename noise), legacy/non-comparable "unverified" resolutions, precision (verified-fixed ÷ (verified-fixed + suppressed)), and median days-to-fix.
-
-A pre-commit rerun of diff-gate reuses the same comparison base directly. After HEAD advances, a clean diff-gate run automatically replays the stored comparison commit. A dirty or unavailable replay leaves the effectiveness finding pending instead of manufacturing a fix result. Standalone detector commands (outside diff-gate) are not outcome-tracked in this ledger until they expose complete-scan evidence.
-
-When `diff-gate --hook` reports that a check is rarely acted on in this repo: tune that check's config, suppress the standing findings with reasons, or consciously accept the noise. Do not let unresolved findings accumulate as wallpaper.

package/skills/_shared/references/evidence-and-dead-code.md

@@ -1,25 +0,0 @@
-# Subagent evidence boundary and dead-code resolution status
-
-## Subagent evidence boundary
-
-When a subagent is used to gather scip-query evidence, its prompt must include these rules verbatim:
-- Use scip-query for compiler-resolved identity and completeness claims.
-- Native search/file reads are valid for literal source content and local logic, including an unambiguous helper visible in the same file.
-- Cite the evidence source appropriate to each claim.
-- State explicitly when neither source establishes a claim completely.
-
-The trigger for requiring scip-query evidence is **resolution or completeness, not whether execution crosses a call boundary.** Asserting what `handler(x)` does without resolving what `handler` is constitutes a resolution claim and requires scip-query evidence. Reading a helper defined two lines down in the same file is not a resolution claim and does not require it.
-
-Reject a subagent's finding if it sources a resolution or completeness claim from text search alone. Do not reject a literal-content claim merely for citing a file read as its evidence.
-
-## Dead-code reference-counting status (as of the 2026-07-02 remediation, `docs/plans/2026-07-02-followups.md` items 1-3)
-
-The shared reference-counting layer used by `dead`, `isolated`, `new-dead`, and `stale-abstractions` correctly resolves as consumers:
-- import type-only consumers, including tsconfig paths-aliased specifiers;
-- pnpm/npm/yarn workspace cross-package consumers, including unbuilt `dist/` exports-map consumers.
-
-Vue `<script setup>` composable consumers were already correctly resolved before this remediation — verified live, no code change needed.
-
-**One residual gap remains:** a symbol with an ambiguous leaf name (a same-named definition exists elsewhere in the project) reached only through a re-exporting barrel file in a workspace package can still be misattributed as dead. For that case, `new-dead` labels the finding `unconfirmed (cross-package ambiguous-name resolution gap)` with evidence `heuristic` and lowered confidence, instead of asserting dead — treat it as "verify manually," not fact.
-
-Outside that one residual gap, dead-code findings in this class are normal graph-fact dead claims: confirm with `refs` when in doubt, same as any other finding.

package/skills/scip-audit/SKILL.md

@@ -1,77 +0,0 @@
----
-name: scip-audit
-description: Use to find and confirm problems WITHOUT editing: is this implementation real (decorative checkers, not-implemented, lying metrics), is a status word derived or merely asserted, are cleanup findings worth acting on, has a same-name twin silently drifted, have the living docs (AGENTS.md, standards, command docs) drifted from the code, and are there hidden policies, scattered concepts, accidental variation or weak boundaries — including React/Vue component and directory-locality pressure. Proactive: needs no reported symptom. Hand confirmed findings to scip-improve. Distinct from `complexity-cleanup` and `principal-maintainability-review`: those reason about a specific symbol's complexity or a reviewer's judgement; this one runs detectors across the repo and ranks confirmed findings by evidence.
-commands:
-  - template: "scip-query health"
-    when: "Orient to the repository-wide finding inventory before confirming candidates."
-  - template: "scip-query decorative-checkers --full"
-    when: "Audit whether validation-shaped code has a reachable failure exit."
-  - template: "scip-query doc-drift --full"
-    when: "Find current-guidance documents whose cited or coupled code moved."
----
-
-# scip-audit
-
-Read-only evidence audits. Every audit here classifies something —
-real-vs-decorative, derived-vs-asserted, confirmed-vs-noise, drifted-vs-stable
-— and ends in a ranked, evidenced verdict. None of them edit code or docs.
-When a finding needs a fix, hand it to `scip-improve`; do not apply it here.
-
-Load shared mechanics (evidence freshness, lookup, the full command
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Commands for this skill
-
-| Command | Purpose | Returns | Coverage | When |
-| --- | --- | --- | --- | --- |
-| `scip-query health` | Composite codebase health report with prioritized action list | health score, findings, priorities, baselines, and coverage notes | `bounded` | Orient to the repository-wide finding inventory before confirming candidates. |
-| `scip-query decorative-checkers --full` | Decorative checker candidates: validate*/verify*/check*/assert*/is*/has* callables with no reachable failure exit anywhere in their body | checker identities, call sites, and decorative behavior evidence | `bounded` | Audit whether validation-shaped code has a reachable failure exit. |
-| `scip-query doc-drift --full` | Stale-doc candidates: code the doc references or co-changed with kept changing after the doc stopped | document paths, coupled code subjects, and history evidence | `bounded` | Find current-guidance documents whose cited or coupled code moved. |
-
-Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
-<!-- END GENERATED SKILL COMMANDS -->
-catalogue) from `../_shared/SKILL.md` — each reference file below carries its
-own shortlist first and only defers to `_shared` when that shortlist runs
-out. Apply `_shared`'s freshness gate once before the first graph fact; let
-an active watcher refresh after source changes, and use manual reindex only
-as its documented fallback.
-
-## Triage
-
-| Situation | Open | Core commands |
-|---|---|---|
-| A checker/verifier/metric/feature might be decorative, half-built, or a fallback might be masking a dead primary path | [`references/integrity.md`](references/integrity.md) | `decorative-checkers`, `not-implemented`, `twin-ab`, `test-quality`, `refs`, `code`, `call-graph` |
-| A status word ("available", "verified", "safe", "PASS", "complete") needs classifying as derived, hedged, or asserted | [`references/claims.md`](references/claims.md) | `files`, `refs`, `code`, `trace`, `capabilities` |
-| Turning a health report, de-bloat report, AI-residue sweep, or raw detector output into a confirmed cleanup queue | [`references/cleanup.md`](references/cleanup.md) | `health`, `cleanup-plan`, `duplicate-bodies`, `recent-duplicates`, `incomplete-migration`, `doc-drift`, `unused-params`, `passthrough-candidates`, `dead`, `isolated`, `cycles`, `co-change` |
-| Same-name or near-name functions across files whose bodies have silently diverged | [`references/twin-drift.md`](references/twin-drift.md) | `twin-drift`, `duplicate-bodies`, `code`, `refs`, `diff-gate` |
-| Hidden policy, scattered concepts, accidental variation, weak boundaries — general structural/maintainability pressure | [`references/maintainability.md`](references/maintainability.md) | `stats`, `system`, `surface`, `change-surface`, `affected`, `drift`, `health`, `similar*`, `extract-candidates`, `wrapper-candidates`, `stale-abstractions`, `cycles` |
-| React or Vue component/hook/composable duplication, or large-component/view pressure | [`references/frontend.md`](references/frontend.md) | `react-component-duplicates`, `react-hook-candidates`, `react-large-component-pressure`, `vue-component-duplicates`, `vue-composable-candidates`, `vue-large-view-pressure`, `augment-vue`, `recent-duplicates`, `similar`, `health` |
-| Folder structure, ownership boundaries, locality config, a messy or AI-generated layout, safe move slices | [`references/directory.md`](references/directory.md) | `system`, `locality-candidates`, `similar-files`, `cycles`, `architecture`, `drift`, `co-change`, `config-validate`, `diff-gate`, `health` |
-
-Rows are not exclusive. A "does this actually work" investigation that turns
-up structural mess routes that mess to `references/maintainability.md`
-instead of forcing it into the integrity verdict — real-but-messy is a
-different failure mode than fake-but-green. A twin-drift finding that
-surfaces on your own diff (via `diff-gate`) is a live instance of that defect
-class, not just a gate finding — open `references/twin-drift.md`.
-
-## Cross-cutting rules
-
-- **Classify, don't just list.** Every audit in this skill assigns each item
-  in scope to exactly one label from its taxonomy (real/decorative,
-  derived/hedged/asserted, confirmed/intentional/false-positive/blocked,
-  intentional-variation/drifted-policy/one-sided-fix, mature/emerging/
-  accidental). A count that doesn't sum to the scope size is an unfinished
-  audit.
-- **Ground every claim in evidence**, not opinion or a variable's name — a
-  variable called `verified` that nothing ever checked is still asserted.
-  Name concrete files/symbols before naming a smell.
-- **Preserve essential variation.** Difference that reflects real behavior,
-  domain facts, runtime constraints, or external contracts is not a defect;
-  consolidating it away is a false abstraction. Any merge/consolidate
-  recommendation must carry the single trait that makes the cited sites one
-  concept — if that trait can't be stated, they aren't one concept.
-- **A clean run is itself a claim.** A suspect scope that produces zero
-  findings needs a stated reason the suspicion was wrong, not silence.
-- **This skill never edits.** Findings, evidence, and a fix direction are the
-  deliverable; route action to `scip-improve`.

package/skills/scip-audit/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SCIP Audit"
-  short_description: "Find and confirm real problems without editing"
-  default_prompt: "Use $scip-audit to proactively find and confirm real problems in this codebase without changing any code."

package/skills/scip-audit/references/claims.md

@@ -1,98 +0,0 @@
-# Claims: derived, hedged, or asserted?
-
-Classify whether an "available", "verified", "safe", "PASS", or "complete"
-status word is derived from a real check, hedged as a candidate, or merely
-asserted without being probed.
-
-Command shortlist: `files <pattern>` (inventory), `refs <symbol>` /
-`code <symbol>` / `trace <symbol>` (classify), `capabilities --matrix --json`
-(spot-check against a known-good derived surface).
-
-## Taxonomy
-
-- **Derived** — the producer computes the value from a real probe, scan, or
-  computation (a compiler run, a runtime capability probe, a graph
-  traversal).
-- **Hedged** — the code or its label already says it is a candidate,
-  heuristic, or unverified. Hedged is not a finding — the label already
-  discloses the uncertainty.
-- **Asserted** — the value is a constant, a hardcoded table entry, or a
-  string literal presented with the same confidence as a derived value but
-  backed by nothing the code actually checked at that call site.
-
-Asserted status words that are agent-facing and trust-bearing — an agent
-would route a decision ("use this evidence", "skip this check", "delete
-this") based on the word — are the highest-severity class this audit exists
-to find.
-
-Ground every claim in the producing function's source, not its label or
-variable name alone: a variable named `verified` that is never checked
-against a real result is still asserted. Every status word in scope gets
-exactly one of the three labels.
-
-## Severity rubric
-
-Asserted + agent-facing + trust-bearing = high. Asserted + internal-only or
-low-consequence = low. Hedged is not a finding.
-
-A status that used to be asserted and now calls a real probe is fixed — say
-so and move on, do not re-report it.
-
-## Step 1 — Inventory
-
-Grep the target scope (a file, module, or command family) for user-visible
-or JSON-facing status words (`available`, `unavailable`, `partial`,
-`verified`, `safe`, `PASS`, `FAIL`, `complete`, `derived`, `asserted`),
-noting the file:line and the renderer or JSON field surfacing each hit. Use
-`scip-query files <target-file-or-pattern>` to locate the renderer or
-status-producing module for a claim.
-
-**Complete when:** every status-bearing string or field in scope is listed
-with its surface (human output, `--json` field, or both).
-
-## Step 2 — Classify
-
-For each status word's producing function, run `refs`, `code`, and `trace`,
-read the function body, and classify it as derived (computed from a probe,
-scan, spawn result, file check, or graph query performed at or near that
-call site), hedged, or asserted.
-
-**Complete when:** every producer has one of the three labels with the one
-line of source evidence that justifies it.
-
-Use `scip-query capabilities --matrix` as a spot-check: an
-already-known example of a fixed derived-status surface, useful for
-calibrating what "derived" looks like in this codebase before judging
-ambiguous cases.
-
-## Step 3 — File and fix
-
-File findings as a table, not prose. Finding format:
-
-- **Claim** — the status word and where it appears.
-- **Producer** — file:line, function name.
-- **Classification** — asserted.
-- **Severity** — high or low (per the rubric above).
-- **Fix** — probe it (name the real check to add), generate it (derive from
-  a registry/config that is itself kept honest), or soften the language
-  (hedge the label to match what is actually known).
-
-**Complete when:** every asserted status in scope has a filed finding with a
-fix direction, and every derived/hedged status is confirmed correct (not
-silently asserted behind a computed-looking name).
-
-## Report
-
-Write the audit report under `docs/scip-query/` unless the user asked only
-for a conversational answer. Template:
-
-- Scope
-- Status words inventoried: N
-- Classified: `<d>` derived / `<h>` hedged / `<a>` asserted — must sum to N;
-  a gap is an unfinished audit
-- Claim table: Claim, Producer, Classification, Fix
-- "Fixed since last audit" — claims now derived that were previously
-  reported asserted
-
-The audit is complete only when every status word in scope is classified and
-every asserted, trust-bearing claim has a filed finding.