(end of Codex stuff)

#gabion , as a tool, is a linter that decomposes structure and treats the structure as a parsing problem, then uses the forest it built from that decomposition to reason about what it decomposed.

To start with, that forest is used to point out where your code has implied objects and grouped behaviors that would be clearer if you reified them explicitly (or at least documented them).

That grew into managing its own test suite, including tracking what tests were proving and tracking redundancy.

And now that's grown into tracking what code is doing that hasn't been documented. All because it can reason generically over a parse forest fed arbitrary input structure.

This. Is. Cool.

#gabion

**Interpretation: where the “real work” is happening**
1. **Core analysis engine surface**
- `dataflow_audit.py` dominates both `decision_surface` and `function_site`.
- This aligns with your recent refactors (deadline, forest/suite semantics, projections, evidence).
- This is *not* abandoned; it’s the primary WIP/active direction.

2. **Evidence + governance pipeline**
- `test_obsolescence.py`, `test_evidence_suggestions.py`, `ambiguity_delta.py`, `forest_spec.py`.
- Indicates governance/analysis work is being exercised by tests but not bound into docflow.
- This looks like **WIP governance path**, not legacy/abandoned.

3. **Interface boundaries**
- `cli.py`, `server.py`, `lsp_client.py` show up, meaning our integration surfaces are being actively exercised.
- These are often **implementation scaffolds** that need doc anchoring, or explicitly treated as “out‑of‑scope” for docflow.

4. **Test‑level call footprints/clusters**
- `call_footprint` and `call_cluster` are almost entirely test‑scaffold evidence (e.g., CLI tests, server tests).
- That suggests we should either:
- explicitly treat test‑level call evidence as **out‑of‑scope** for docflow, or
- create a “test surface” doc that **covers** it intentionally.

**Why this matters for “calcifying abandoned direction”**
- Right now the excess evidence mostly reflects **active, tested code paths** that are simply not attached to docflow cover invariants.
- So the risk is not “abandoned direction being calcified,” it’s **active direction not being documented**, and therefore not being tracked by governance.

#gabion Highlights from the report:

Here’s a clean, system‑level read of the **excess evidence** signal and what it implies about WIP vs abandoned direction.

**What the excess evidence actually is right now**
- `excess = 368` because **all cover invariants are still `status: proposed`** in `docs/coverage_semantics.md`, so no evidence can be “covered” yet.
- So “excess” is **not** automatically “abandoned”; it currently means: *tested evidence exists, but we have not bound it to docflow cover invariants*.

**Breakdown of excess evidence by kind**
- `decision_surface`: 192
- `function_site`: 150
- `call_footprint`: 22
- `call_cluster`: 4

**Dominant source files (excess evidence)**
- `dataflow_audit.py` — 143
- `type_fingerprints.py` — 22
- `cli.py` — 22
- `server.py` — 14
- `evidence_keys.py` — 10
- `test_evidence_suggestions.py` — 10
- `config.py` — 9
- `engine.py` — 8
- `timeout_context.py` — 7
- `ambiguity_delta.py` — 6
- `forest_spec.py` — 6
- `test_obsolescence.py` — 6
- others smaller