Strix: remediation evidence must fail closed when apply_patch misses target workspace

[seonghobae]

Finding

LineageWeave Strix run 34746057545 / job 103694153476 completed SUCCESS and produced a valid Medium CWE-862 finding, but its final report also states that the immediate fix was “already applied in backend/app/main.py” and “syntax-verified”. The execution log contradicts that claim.

At 2026-09-13 13:14:30 UTC the Strix agent invoked apply_patch and the tool failed with:

WorkspaceReadNotFoundError: file not found: /workspace/backend/app/main.py
...
agents.sandbox.errors.ApplyPatchFileNotFoundError: apply_patch missing file: backend/app/main.py

The scanned repository workspace for this workflow lives under the Strix runtime/materialized target path, not /workspace. The product PR head ContextualWisdomLab/LineageWeave#1055@50c4935eef1029467595f7004818643598b737c9 remains unchanged and independently still contains the vulnerable call site. Therefore the report's “already applied” remediation statement is false evidence even though the vulnerability finding itself is valid.

Artifact: LineageWeave strix-reports id 10318318320, digest sha256:45c82c7f1f044185a4795b4b4db37d2ce30346e44e516ce027f2bf53fe89581e. Relevant files: strix.log, vulnerabilities.json, penetration_test_report.md.

Why this matters

A security gate may legitimately complete SUCCESS while returning findings, but it must not claim a remediation was applied when the edit tool failed. That breaks provenance, can mislead maintainers into treating a finding as already repaired, and prevents exact-head RED→fix→GREEN accounting.

Acceptance

• target workspace path passed to Strix remediation/edit tools is the exact materialized PR workspace, not an unrelated /workspace default;
• any apply_patch / edit / syntax-validation failure is preserved as a first-class remediation failure and cannot be summarized as “fix applied”;
• report schema distinguishes finding_confirmed, fix_proposed, fix_applied_in_scan_workspace, fix_validated, and fix_committed_to_source (or equivalent states) instead of collapsing them;
• a fix is never marked applied unless the changed bytes are re-read from the exact scan workspace and the expected diff is present;
• no report may imply source-repository mutation unless a source commit SHA/repository receipt exists; isolated sandbox mutation must be labeled as such;
• add a regression that intentionally points apply_patch at a missing target and proves the final report fails closed rather than emitting “already applied”;
• downstream SARIF/Markdown/JSON carry the same remediation state and immutable evidence.

Do not solve this by suppressing tool errors or by making Strix commit directly to target repositories. Source writes remain a separate owner-controlled action.