Skip to content

docs(revert-rescue): record file-only rescue scope for non-file schemes - #308

Merged
mtskf merged 1 commit into
mainfrom
fix/revert-rescue-non-file-schemes
Jul 31, 2026
Merged

docs(revert-rescue): record file-only rescue scope for non-file schemes#308
mtskf merged 1 commit into
mainfrom
fix/revert-rescue-non-file-schemes

Conversation

@mtskf

@mtskf mtskf commented Jul 31, 2026

Copy link
Copy Markdown
Owner

Summary

Investigation outcome for the round-2 review finding that the revert-rescue is skipped on editable non-file schemes. Records the file-only rescue scope with rationale (documentation route) rather than widening the gate. No runtime behavior change.

Changes

  • Expanded the RescueContext.canWrite / AliveRevertContext.canWrite gate doc in src/extension/surface/revert-rescue.ts to explain why the rescue is intentionally scoped to file: documents (unified with the reducer's canHostWrite write gate), not widened to every open-and-applyEdit-capable scheme.
  • Recorded the full investigation + written-decision + re-visit trigger in .claude/docs/LEARNING.md (local-only doc; .claude/ is git-ignored in this repo).

Rationale (why documentation, not widening)

  • The headline scenario (vscode-vfs / github.dev / remote virtual workspace) is unreachable: package.json declares capabilities.virtualWorkspaces.supported = false + untrustedWorkspaces.supported = false, so VS Code never activates Quoll in a virtual/untrusted workspace.
  • The quoll.editWith gate (canEditWith) already refuses non-file schemes; the only residual entry is a forced vscode.openWith / hot-exit restore in a trusted local workspace with a concurrently-open dirty text editor on a writable non-file FS — a corner of a corner.
  • Widening would fork the write-capability gate for a manifest-excluded case and create a "refuses normal writes but performs rescue writes" asymmetry on a security-sensitive write path, breaking the single-allowlist sync file-system.ts maintains between the command gate and the write gate.

Related

  • TODO: 🐛 [LOW] Investigate: revert-rescue skipped on editable non-file schemes (canHostWrite = file-only)

Test Plan

  • pnpm compile clean
  • pnpm test:unit green (composition already pinned: can-host-write.test.ts refuses vscode-vfs even when FS is writable; revert-rescue.test.ts pins canWrite:false → {rescue:false} on both decision paths)
  • pnpm lint clean on the changed file

The dispose-time / alive revert-rescue reuses the reducer's file-only
canHostWrite gate, so on a non-file scheme (vscode-vfs/remote reached via
a forced openWith or hot-exit restore) a close-revert is not rescued.
Investigation outcome: keep the gate file-only rather than widen it.

The headline virtual-workspace scenario is unreachable — package.json
declares capabilities.virtualWorkspaces/untrustedWorkspaces.supported =
false, so VS Code never activates Quoll there; canEditWith already blocks
non-file schemes on the normal open path. Widening would fork the
write-capability gate for a manifest-excluded corner and create a
'refuses normal writes yet performs rescue writes' asymmetry on a
security-sensitive write path. Documented at the RescueContext.canWrite
gate; full rationale + re-visit trigger in LEARNING.md. No behavior
change (composition already pinned by can-host-write + revert-rescue
suites).
@mtskf
mtskf merged commit bfaee7a into main Jul 31, 2026
1 check passed
@mtskf
mtskf deleted the fix/revert-rescue-non-file-schemes branch July 31, 2026 13:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant