Loctree Recipes — Validate a structural answer

What makes an answer useful?

A useful structural answer supports a named decision within a stated scope. Record:

Question: what relationship are you trying to understand?
Evidence: owner, definitions, edges, source locations and query identity.
Interpretation: what follows from those facts, and what is only a hypothesis?
Counterexample: which overlooked caller or registration would change the answer?
Decision: what can you choose now, and what still needs verification?

A process exiting successfully proves execution of that command. It does not prove the answer is correct.

Keep four boundaries visible

Boundary	What to retain
Repository	Effective root, revision, dirty state and snapshot identity when available.
Graph	Languages, recognized edge/reader classes and excluded runtime mechanisms.
Response	Emitted/total counts, filters, traversal depth and truncation/pagination.
Verification	Whether evidence is static, independently checked, tested or executed live.

Snapshot-backed does not automatically mean stale: some readers refresh on change. Record the actual freshness receipt. An inventory reader and an impact reader may have different freshness contracts.

Verify without flattening structure into search

Use focus, slice, impact, twins, event/contract surfaces and other relationship queries for discovery. Use find, occurrences and body to verify definitions, roles, aliases and edge claims. A literal match is not automatically a resolved dependency, and two Loctree commands agreeing is internal consistency rather than an independent oracle.

When consequences matter, use the source contract, build, integration test or actual runtime path as a separate verification step. Label that work separately from structural exploration.

Choose tests from the neighborhood

Start with represented test consumers and integration boundaries. Compare them with context recommendations; retain a direct relevant test even if it is absent from the suggested list. A broad heuristic test suggestion is not proof of relevance. Structural coverage does not measure executed line coverage.

Two different experiments

Capability trial: answer a coherent set of questions using Loctree for discovery, with explicit counterexamples. This isolates what its surfaces can provide.

Voluntary-use trial: allow the agent its usual tools, and observe when it chooses Loctree without enforcement. This measures whether the structural value is discoverable and worth the interaction cost. A mandatory Loctree-only trial cannot establish voluntary adoption.

For either trial, count questions rather than process invocations. Retries, JSON variants and pagination belong to the same question. Keep failures in the ledger.

A compact record

Question: What will a change to the session contract affect?
Repository / version / snapshot: recorded from actual receipts
Discovery: exact commands, working directory, duration, exit status
Evidence: direct consumers, transitive paths, relevant tests
Counterexample: generated native binding outside the import graph
Outcome: partial answer; raw material at the bridge boundary
Decision enabled: review represented consumers; defer removal judgment
Remaining verification: binding generator and native integration test

Use recipe, raw material or silence for usefulness. Record errors and ergonomic friction separately. State what would resolve an unknown instead of turning it into a pass.