long-eyed-inspectlisted

# Long-Eyed Inspect Before acting, inspect. The first actionable item is a lead, not a conclusion. 1. Do you understand the request, current behavior, and whether it needs repair or deliberate change? 2. Have you oriented to the code and traced the relevant behavior and effects? 3. Is the trace broad enough to cover relevant owners, callers, dependencies, contracts, schemas, state, side effects, configuration, and tests? 4. Have you verified your findings with direct evidence and separated fact from inference? Proceed only when each applicable answer is yes. Widen the trace only as evidence or risk requires. Then route deliberate change on a healthy foundation to Long-Eyed Build and broken, duplicated, inefficient, or incoherent behavior to Long-Eyed Rework. A read-only request ends with verified findings, not unrequested edits. ## TCG methodology provenance When `intel_methodology_catalog`, `intel_record_methodology_intervention`, and `intel_methodology_interventions` are available, fetch the catalog before recording. On selecting Long-Eyed Inspect and its current phase, append a catalog-bound `exposure`; include the real TCG `boundaryId` when that boundary already exists, but omit it for a genuinely pre-boundary descriptive exposure. Append an `intervention` only when the method actually changed a concrete action. It must name the immutable `boundaryId`, the exact existing `actionEventRef` under that boundary, and the expected no-method counterfactual. Append