Evidence and open questions
Dated origins, observed strengths and revalidation boundaries for the catalog.
Where this catalog comes from
These guides distill the 26 September 2026 Loctree recipes round and the 14 October 2026 structural trials. They preserve questions, useful workflows and falsifiers rather than presenting historical output as a current benchmark.
| Round | Recorded tool build | Scope | What it establishes |
|---|---|---|---|
| September recipes | 0.14.5+g3678b992 | 14 repositories across Rust, Python, web, shell and native language boundaries | Historical recipes, trapped facts and questions without an answering surface. |
| October structural trials | 0.15.0-dev+gc0eaacb3.dirty | Reported CLI trials, selected CLI/HTTP comparisons and focused freshness fixtures | Later output behavior and counterexamples on the exercised cases. |
The original September catalog was named LOCTREE_VIBECRAFTED_RECIPES.md. It asked whether a result enabled a decision, kept literal tools as verification, and classified each answer as recipe, raw material or silence. This public catalog is an editorial adaptation; private transcripts, filesystem paths and raw configuration are not publication artifacts.
The follow-up implementation introduced a 55-probe before/after harness and later fixture probes. Those source changes are part of the development history. Their presence does not certify the installed binary, every downstream repository or every historical finding. This documentation update does not rerun that benchmark.
Observed strengths
- File and directory neighborhoods expose consumers and dependencies beyond a flat list of names.
- Definition/re-export lookup can separate implementations from public facades.
- Domain maps can connect code with contracts, scripts and supporting documents.
- Impact traversal can identify represented downstream work.
- Classified suppression inventories support focused review.
- Bounded source bodies can make a map's interpretation checkable.
Raw material and open questions
The following are verification targets, not blanket claims that every installed version lacks the capability.
| Question | Evidence needed to close it | Relevant recipe |
|---|---|---|
| Which consumers use this exact symbol rather than its file? | Resolved identity through aliases/re-exports and caller evidence. | Identity, impact |
| Is a native export live across FFI? | Export, generated/header binding, caller and registration chain. | Dead code |
| Does a script with zero imports participate in the product? | Make/CI/installer/plist dispatch with resolved target identity. | Ownership |
| Do client requests match mounted routes? | HTTP method, prefixes, dynamic URL construction and handler registration. | Contracts |
| Does one configuration source override another? | Shared execution scope and a demonstrated precedence relationship. | Environment |
| Which tests validate a selected owner? | Direct test relationships and integration relevance, distinguished from guesses. | Validation |
| Do transports preserve the same evidence? | Equal facts plus emitted/total/truncated and coverage metadata. | Impact |
| Is a zero trustworthy? | Applicable detector family, searched universe and freshness. | Validation |
Revalidation record
To update a recipe, retain the date, exact tool build, repository revision and scope, command, decisive output, counterexample and resulting decision. Mark a formerly open question closed only for the surface and scenario actually verified. Keep the historical observation dated rather than silently rewriting it into a present-tense guarantee.
A good outcome is an agent that can explain the system and choose a justified next action. More commands, larger JSON and a green exit code are not substitutes for that outcome.