Phase 5 (#234): vscode-free domain + shared/editor adapter

[pajoma]

Follow-up to #234 (package-by-feature restructure, Phases 1–4 merged via #235–#238).

Goal

Make the per-feature domain/ logic VS Code-free: domain returns data/paths, and a single shared/editor/ adapter performs all vscode.TextDocument open/show/save. This is the highest-testability payoff of the restructure and was always slated as its own issue (per the #234 plan + maintainer review).

Why separate

The change in return types (removing vscode.TextDocument from Reader/Writer/Inject) is a semantic shift that deserves its own focus and verification cycle, not bundled into a file move.

Scope

1. Introduce shared/editor/ — an adapter owning open / show / save of vscode.TextDocument (wraps the bits currently in Dialogues/Writer).
2. Change features/*/ domain code (reader.ts, writer.ts, inject.ts) to return paths/data instead of vscode.TextDocument; commands call the editor adapter.
3. Add pure-node unit tests for the domain logic (no Extension Host needed).

Prerequisite — remove remaining cross-feature edges (#234 acceptance #5)

Three edges remain after Phase 4; clean these as part of (or just before) this work:

• entries → notes — LoadNotes dispatch inside loadPageForInput.
• navigation → entries — prev/next commands extend the shared AbstractLoadEntryForDateCommand (move base command to shared/ or a neutral location).
• smart-input → entries — Dialogues uses ScanEntries (move Dialogues/ScanEntries placement so neither feature imports the other).

Acceptance

• grep -r "vscode" src/features/*/**/domain* (and the reader/writer/inject files) → no vscode import.
• All vscode.TextDocument handling flows through shared/editor/.
• New node-only domain unit tests pass.
• No cross-feature internal imports remain (grep/lint verifiable).
• Full suite green.

Also pending from #234

• Docs pass: AGENTS.md "Architecture" section + docs/PLAN.md still describe the pre-restructure layout. (Tracked separately / may land first.)

[pajoma]

Spec + plan committed to develop:

• docs/specs/2026-06-02-239-vscode-free-domain.md
• docs/plans/2026-06-02-239-vscode-free-domain.md

5 staged steps: (1) remove the 3 cross-feature edges, (2) shared/editor adapter, (3) Writer/Reader return data, (4) Inject split (pure compute vs editor apply), (5) node-only unit tests. Honest scope: isolates the editor surface to shared/editor and makes the pure parts node-testable — Inject's apply half stays editor-bound by nature.

[pajoma]

Critical Review: Spec & Plan for #239 (Vscode-free Domain)

The goal to pull editor I/O behind an \IEditor\ seam is the correct architectural move to enable pure Node.js unit tests (Phase 5 of #234).

Strengths:

1. Honest Scope: The decision to split \Inject\ into a pure computation half and an impure application half (rather than chasing 100% purity everywhere) is pragmatic and limits unnecessary complexity.
2. Staged Execution: The 5-step plan is highly sequential and safe. Resolving the 3 remaining cross-feature edges first clears the dependency graph before tackling the editor abstractions.
3. Data Return Types: Transitioning \Reader\ and \Writer\ to return plain data (e.g., { path, created }) instead of \�scode.TextDocument\ is a textbook application of the Hexagonal Architecture pattern.

Observations & Recommendations:

• Step 1 (entries → notes): Instead of registering a generic
  oteLoader\ callback, consider pushing the note branch directly into the \ShowEntryForInputCommand. The command layer is the appropriate place to orchestrate between features based on the \Input\ type.
• Step 4 (Inject split): The \IEditor.applyEdit(doc, edits)\ method is a great seam. Ensure the \edits\ array uses a plain data structure (e.g., { range: { start: { line, char }, end: { line, char } }, text }) to avoid leaking \�scode.TextEdit\ into the pure domain.
• Node-only tests: Ensure that \src/test/unit\ explicitly excludes \�scode\ from its test environment setup to prevent accidental re-coupling.

Approval: Approved. The spec and plan are technically rigorous and will yield a massive testability improvement. Proceed with Step 1.

[pajoma]

Folded the 3 review recs into the plan (develop):

• Step 1 entries→notes: dispatch NoteInput in ShowEntryForInputCommand (command-layer orchestration) — dropped the noteLoader callback idea.
• Step 2/4: IEditor.applyEdit takes plain-data edits {range:{start:{line,character},end:{...}},text}; adapter converts to WorkspaceEdit internally — no vscode.TextEdit/Range/Position in the domain.
• Step 5: src/test/unit excludes vscode (guarded) so accidental re-coupling fails the node run.

Plan ready. Will start Step 1 on your go.

[pajoma]

Approved, develop in branch 239-phase-5-234-vscode-free-domain-sharededitor-adapter