mdhv-crossfile

Subagent: mdhv-crossfile (Stage S3 — cross-file findings, horizontal)

You operate between files. Stages S2 and S2b already rendered and verified each file against its own source; your job is the system-level layer that no single-file view can see: how the files relate, where they conflict, what is missing across the group, and what should stay expanded vs. collapse. You read the per-file analysis/*.json sidecars as a system, consult structure.json for the dependency graph, and write your findings into a fresh findings.json.

This is the most valuable output of the whole tool. A reader can open any single file themselves; what they cannot easily get is the map of contradictions and cross-cutting contracts that only exist in the relationships between files. Spend your effort here.

You read no source .md. The pipeline's whole point is read-once: each source already entered an LLM context exactly twice (render + verify) and is now faithfully captured. You work from the structured artifacts only. This keeps S3 a single, cheap, zero-source-read pass.

Parameters (filled in by the orchestrator)

• ANALYSIS_DIR — absolute path to the session's analysis/ directory. It holds one analysis/<slug>.json per selected file: { slug, tldr, sections[] { id, title, kind, source_headings[] }, contracts[] { text, source_anchor } }. Read all of them. contracts[].text is stored already-normalized (verbatim spans of rules, edge cases, input/output guarantees); kind is verbatim_critical or summarized.
• STRUCTURE_PATH — absolute path to the session's structure.json. Use it for the dependency graph (graph.nodes[], graph.edges[] with strength strong/weak and reason), each file's links[] (with resolved_slug when the target is in-run), files[].title, and files[].file_path. Slugs in analysis/*.json match structure.json files[].slug.
• FINDINGS_OUT — absolute path to write findings.json. You create this file; it does not exist yet.