Hypothetical (validate pre-write) evaluation must be comprehensive — graph-backed checks are silently skipped

[EivMeyer]

Parent

Part of #243. Planned immediately before implementation against dev at 47d2b3f39c936d05ca546282e627a24f99ffe2893 after #246 and #209 merged.

Current truth

Hypothetical validation changes ValidationFileView reads but resolves one graph session from the real repository before before/after execution. Graph-backed checks therefore see the pre-edit persistent graph or are skipped with graph_unavailable; reportMode:"introduced" also reuses that same graph for both sides. This cannot equal the diagnostics produced after applying the proposal on disk.

#209 is complete in PR #255: Rust graph-core is now the sole Python import parser/resolver and Python import-dependent validation consumes its directed edges. #213 is complete in PR #224: validation file enumeration is lazy. Those are prerequisites and must be reused, not reimplemented.

The closed duplicate ticket is only a historical pointer to this issue and #209. No replacement issue is needed.

Contract

Make every selected graph-backed validation check evaluate one exact, immutable graph snapshot of the same file-view state that the check reads.

For a request with overlays:

1. Materialize the complete validation-visible before-state and after-state source universes into isolated temporary roots. Writes, deletes, renames (delete + write), new files, multi-file edits, project/package boundaries, source roots, and fix(python): share import resolution between validation and graph #209 Python import semantics must match ValidationFileView.
2. Build one graph snapshot per state, once, through the package-owned graph provider. All graph-backed checks for that state share the same query session and snapshot.
3. reportMode:"introduced" compares diagnostics from the before-state graph/file view with diagnostics from the after-state graph/file view. It must not reuse either graph for both sides.
4. The after-state result must equal running the same request/checks after materializing that proposed state on disk and building its graph. No graph-backed check may silently skip merely because overlays are present.
5. Keep graph-core the graph authority. Validation owns orchestration and file-view state; graph owns ephemeral snapshot materialization/build/query behavior. Shared integration types stay in packages/validation; package composition injects graph implementation without importing graph internals.
6. Ephemeral analysis must not mutate the target repository, its persistent .opcore/graph database, source files, config, lockfiles, environments, or caches. Temporary roots and graph artifacts are removed on success, policy findings, provider failures, malformed results, and thrown errors.
7. Build/query/materialization failures are visible non-pass results. Optional graph mode must not turn an overlay graph construction failure into a false clean pass.
8. Preserve non-overlay validation behavior and current package boundaries. Clone whole-repo indexing remains commit-time behavior and is not made a pre-edit co-authority.

Required implementation surfaces

• packages/validation: state-specific graph-session lifecycle tied to each ValidationFileView; injectable ephemeral snapshot seam; deterministic cleanup.
• packages/graph: bounded ephemeral source snapshot materialization using the supported graph source set (TS/TSX/JS/JSX, Python .py/.pyi, Rust .rs) and the existing graph-core build/query APIs.
• Opcore product and advanced validation composition, plus ASP check/evaluate composition: inject the same overlay graph behavior.
• Tests/fixtures: multi-file write/delete/rename, fix(python): share import resolution between validation and graph #209 Python imports across package/source-root boundaries, introduced before/after graph differences, optional/required provider failures, cleanup, target-repository immutability, and real on-disk parity.
• AGENTS.md: record the new graph/validation ownership and overlay-snapshot invariant if implementation establishes that pattern.

Acceptance evidence

• Focused unit/contract tests prove a graph session is built once per state, shared across checks, and always disposed.
• A real graph-core fixture proves an overlay that adds/removes/retargets Python imports changes IMPORTS_FROM diagnostics exactly as the equivalent materialized repository does.
• Multi-file write/delete and rename-style overlays have parity with the materialized after-state.
• Missing/stale baseline graph does not cause overlay graph-backed checks to skip when ephemeral construction succeeds.
• Forced materialization/build/query failures are non-pass and leave no temporary root.
• Hashes/listings prove the target repo .opcore/graph, source tree, config, lockfiles, and environments are unchanged.
• Existing validation runner, Python validation, graph conformance, ASP provider, package boundary, packlist, and installed-artifact tests pass.
• opcore check --changed --json passes for the scoped implementation with required tools available.
• zeroshot cmdproof check opcore-ci passes from the implementation worktree.
• PR targets dev, links this issue, has green GitHub checks, and contains no generated native/package/release churn outside a narrowly proven required surface.

Non-goals

• Daemons, sockets, persistent overlay graph databases, or latency optimization beyond existing hard caps.
• A second Python parser/resolver or TypeScript-side Python import fallback.
• Clone/SAST/security behavior, public schema version changes, new command groups, package versions, launch claims, or readiness receipts.
• Broad graph feature work unrelated to hypothetical parity.