Simplify defensive diagnostics and tests to match the security model #958

Story

Authors receive useful diagnostics, and maintainers can remove defensive machinery and tests whose only justification is an attack outside the project's security model.

An ordinary absolute project path can appear in a diagnostic unless identified as sensitive. A malformed JSON result still needs validation where its owning API interprets it. Deliberately malicious getters or Proxies supplied by trusted native code do not establish a security requirement.

Current gap

#954 records the approved model, but existing source, architecture detail and conformance clauses still include blanket path/platform-error suppression and hostile-native-object requirements. Tests written around those requirements can preserve complexity without establishing a supported consequence.

Initial review targets include Files diagnostics and failure handling (packages/core/src/files.ts, packages/core/tests/files-fatal.test.ts), document-request and pre-root completion handling (packages/core/src/document-request.ts, packages/core/tests/execution-protocol.test.ts), and their language-specification clauses, including FF11–FF14 and DP27/DP29.

Contract and acceptance

• For each targeted defense and adversarial test, identify the external input or supported API path it protects and the concrete consequence. Classify it as necessary validation/security, reliability/compatibility, or outside-model hardening.
• Simplify or remove defenses justified only by malicious trusted native code. Validate real service, file and journal data at the owning interpretation boundary; internal code may rely on the validated contract.
• Remove blanket secrecy claims for all paths and ordinary error details. Protect credentials and explicitly identified secrets, and preserve relative-path formats where portability or compatibility requires them. A format change with an independent public contract receives its own explicit decision.
• Keep history format/version/run/effect consistency, generated-evaluation restrictions, correct replay, duplicate-effect prevention, fatal persistence fencing, transaction ownership and cancellation cleanup. Deliberate coherent rewriting of the local database has no authenticity guarantee.
• Change specifications, architecture detail, source and tests together for each bounded cleanup. The records explain the supported consequence for retained defenses; obsolete conformance assertions do not remain as hidden requirements.
• Reuse the hook adapter where it replaces a protection already covered by its contract. Avoid parallel changes to the same expansion/bound-command internals while their hook migration is active.

Evidence and completion

Use focused regressions for the actual diff, beginning with the Files failure and execution-protocol suites when those boundaries change. Demonstrate a useful ordinary diagnostic and an identified secret that is still protected, plus malformed external data that is still refused. Include the relevant existing replay, generated-evaluation, persistence and cancellation controls for any touched boundary.

Freeze finite evidence around distinct consequential failure paths. Do not replace removed permutations with another speculative matrix or delete tests merely to meet a size target. Completion is the merged, coherent cleanup and a disposition for every targeted clause/defense/test; unrelated findings are linked follow-ups.

Dependencies and related work

Uses #954's security model. Specification/necessity assessment can proceed in parallel with #956 and #957. Changes to overlapping runtime code follow #956's hook migration and the relevant API contract decisions from #957.

#303 separately covers installer practices, token operations and public security documentation; those operational tasks are outside this issue. #491 covers the broader ownership audit, and #435 covers review process. Preserve their active contracts.