chore: updated plan

Co-authored-by: Copilot <copilot@github.com>

PLAN.md

@@ -1,6 +1,13 @@
 # bDS2 Plan
 
-This document tracks the current implementation state of bDS2 against the Allium specs and the old bDS application, with the remaining work now focused on batch 3 and batch 4 parity auditing.
+This document tracks the current implementation state of bDS2 against the Allium specs and the old bDS application.
+
+## Open Work Summary
+
+- Completed plan steps: 1, 2, 3, 4, 5, 6, 8.
+- Open plan steps: 7, 9, 10, 11, 12.
+- Next actionable step: 7. The batch-4 audit is already recorded in this file, so the next implementation work is the remaining chat editor parity pass.
+- Scheduled after the current parity pass: 10 menu editor parity, 11 desktop-side CLI mutation watching, 12 import execution/editor parity.
 
 ## Current State
 
@@ -18,17 +25,16 @@ The rewrite already implements most of the backend and compatibility-critical su
 
 ### Implemented But Not Yet At Parity
 
-- The main shell chrome and the existing dedicated editors are implemented, but they still need side-by-side parity checks against the old React/Electron UI for workflow details, edge-case state transitions, and styling fidelity.
+- The remaining implemented UI parity work is now concentrated in the chat route; the other implemented batch-3 surfaces have already been audited and scored.
-- AI gating, translation, image analysis, tag suggestions, and side-effect chains exist in backend services, but the exact old-app UI triggers, sequencing, and result presentation are not all proven yet.
+- The batch-4 backend and integration audit is recorded below; any further service work should now come only from proven drift, not from missing audit coverage.
-- Shared workbench/session state exists, but the richer cross-surface behaviors described in the UI data-flow specs still need explicit parity scoring route by route.
+- Shared workbench/session state exists, but any remaining UI-data-flow work should now be treated as a concrete parity gap only when it can be tied back to a proven old-app behavior.
-- The lower-risk service engines are broadly implemented and tested, but they still need a focused audit that ties each service contract back to the old engine behavior and the current editor/shell entry points.
 
 ### Missing Or Materially Incomplete
 
 - Import remains definition-only: stored import definitions exist, but the old WXR analysis/execution pipeline and its dedicated editor surface are not present.
 - Menu data exists, but the `menu_editor` route still lacks a dedicated editor surface comparable to the old app.
 - CLI sync notification persistence exists, but old-app parity for desktop-side watching/broadcasting of external DB mutations is not yet proven.
-- Full parity validation still needs to be written down per slice, with explicit green/yellow/red scoring and a concrete change backlog for any drift that is found.
+- The remaining parity write-up gap is now keeping the chat row and the final minimal backlog in sync with the current implementation.
 
 ## Spec Coverage Snapshot
 
@@ -45,7 +51,7 @@ Ordered from base contracts upward:
 
 ## Batch 3 And 4 Focus
 
-Only these two audit tracks matter for the current pass. Import and menu stay out of scope unless they block an audited flow.
+Only these two audit tracks matter for the current pass. The follow-on missing-feature tracks now sit explicitly after this pass as steps 10, 11, and 12.
 
 1. Lock compatibility contracts. Completed 2026-04-25.
    Schema, frontmatter, sidecars, template context, generation output, preview behavior, metadata diff, and rebuild behavior are now pinned against the Allium specs and the old bDS application with executable parity tests.
@@ -62,17 +68,26 @@ Only these two audit tracks matter for the current pass. Import and menu stay ou
 5. Audit batch 3: shell UI plus all dedicated editors already present. Completed 2026-04-28.
    Compared the old Electron/React shell and each dedicated editor route against the current LiveView shell, scored parity green/yellow/red, and reduced the proven batch-3 drift list to the remaining chat-surface gaps only.
 
-6. Audit batch 4: lower-risk backend and integration services behind those surfaces.
+6. Audit batch 4: lower-risk backend and integration services behind those surfaces. Completed 2026-04-29.
-   Tie each old engine contract to its bDS2 replacement, verify the executable proof set, probe the service through the owning UI/editor entry points where applicable, and emit only the behavior drifts that remain.
+   Tied each old engine contract to its bDS2 replacement, verified the executable proof set, probed the relevant owning UI/editor entry points, and recorded the batch-4 parity scores in the snapshot below.
 
-7. Restore chat editor parity on the implemented route.
+7. Restore remaining chat editor parity on the implemented route.
-   Bring the current chat tab up to old bDS for the implemented conversation UI: add model selection, streaming turn state, tool-call/result presentation, and A2UI surface rendering to the existing persisted-transcript editor without widening into unrelated AI features.
+   Use the old `ChatPanel` and chat surface code as the blueprint, refresh the chat parity row to the current implementation, and close only the remaining proven live-turn/UI drift without widening into unrelated AI features.
 
 8. Restore misc maintenance editor parity on the implemented routes. Completed 2026-04-28.
    Translation validation now uses the old dedicated validate-and-fix card surface again, and git diff now renders through the structured Monaco diff viewer while keeping the current metadata-diff, site-validation, and duplicate flows intact.
 
 9. Fix any remaining batch 3 and batch 4 parity gaps that the audit proves.
-   Do not widen into import/menu/release-packaging work unless one of those blocks a batch 3 or batch 4 parity scenario.
+   Do not widen step 9 into the later menu, CLI-mutation-watching, import, or release-packaging tracks unless one of those blocks a batch 3 or batch 4 parity scenario.
+
+10. Restore menu editor parity on the implemented data model.
+   Build the dedicated menu editor surface against the existing menu data using the old app as the blueprint for workflow, behavior, UI structure, and styling.
+
+11. Restore desktop-side CLI mutation watching parity.
+   Add the old desktop-side watching and invalidation behavior for external database mutations so CLI sync notifications propagate through the shell with the same timing and UX expectations as the old app.
+
+12. Restore import execution and editor parity.
+   Extend the existing stored import definitions into the old WXR analysis/execution pipeline and add the dedicated editor surface so import behavior, workflow, and look and feel match the old app.
 
 ## Batch 3 Audit Matrix
 
@@ -112,7 +127,7 @@ Current batch 3 parity scores for existing implemented UI/editor code only. Miss
 | Tags editor | green | `src/renderer/components/TagsView/TagsView.tsx` | `lib/bds/desktop/shell_live/tags_editor.ex`, `lib/bds/desktop/shell_live/tags_editor_html/*` | `mix test test/bds/desktop/shell_live_test.exs`; tags editor implementation compared | No material implemented-code parity drift found in the current create/edit/delete/merge flows, color handling, or post-template selection behavior. |
 | Script editor | green | `src/renderer/components/ScriptsView/ScriptsView.tsx` | `lib/bds/desktop/shell_live/code_entity_editor.ex`, `lib/bds/desktop/shell_live/code_entity_editor_html/script_editor.html.heex` | `mix test test/bds/desktop/shell_live_test.exs`; script editor implementation compared | No material implemented-code parity drift found in the current Monaco editor, metadata form, syntax check, run, save, delete, and entrypoint selection flow. |
 | Template editor | green | `src/renderer/components/TemplatesView/TemplatesView.tsx` | `lib/bds/desktop/shell_live/code_entity_editor.ex`, `lib/bds/desktop/shell_live/code_entity_editor_html/template_editor.html.heex` | `mix test test/bds/desktop/shell_live_test.exs`; template editor implementation compared | No material implemented-code parity drift found in the current Monaco editor, metadata form, validate, save, and delete flow. |
-| Chat editor | yellow | `src/renderer/components/ChatPanel/ChatPanel.tsx` | `lib/bds/desktop/shell_live/chat_editor.ex`, `lib/bds/desktop/shell_live/chat_editor_html/chat_editor.html.heex` | `mix test test/bds/desktop/shell_live_test.exs`; chat editor implementation compared | The current bDS2 chat route now covers the old model selector, welcome state, persisted transcript, airplane-mode gating, tool markers, and structured tool surfaces, but it is still materially thinner than old bDS in the live-turn path: no streaming state/stop flow, no markdown transcript rendering, no API-key-required screen, and no A2UI action surface dispatch yet. |
+| Chat editor | yellow | `src/renderer/components/ChatPanel/ChatPanel.tsx` | `lib/bds/desktop/shell_live/chat_editor.ex`, `lib/bds/desktop/shell_live/chat_editor_html/chat_editor.html.heex` | `mix test test/bds/desktop/shell_live_test.exs`; chat editor implementation compared | The current bDS2 chat route now covers the old model selector with provider grouping, welcome state, persisted transcript, airplane-mode gating, API-key-required state, assistant markdown rendering, tool markers, structured tool surfaces, assistant navigation actions, and the in-flight stop/abort flow. Step 7 remains open because the chat row still needs one fresh focused pass against the old live-turn surface to pin any remaining proven drift before it can be scored green. |
 | Misc maintenance editors | green | `src/renderer/components/SiteValidationView`, `TranslationValidationView`, `MetadataDiffPanel`, `DuplicatesView`, `GitDiffView` | `lib/bds/desktop/shell_live/misc_editor.ex`, `lib/bds/desktop/shell_live/misc_editor_html/misc_editor.html.heex` | `mix test test/bds/desktop/shell_live_test.exs`; misc editor implementation compared | No material implemented-code parity drift found in the current metadata diff, site validation, duplicate dismissal, translation validation, or working-tree git diff flows. Translation validation again uses dedicated issue cards with revalidate/fix actions, and git diff now uses the structured Monaco diff surface. |
 
 ## Batch 4 Audit Matrix
@@ -145,7 +160,7 @@ Current batch 3 parity scores for existing implemented UI/editor code only. Miss
 
 ## Batch 4 Audit Snapshot
 
-Current batch 4 parity scores for implemented backend code only, based on the proof commands already run and the owner-file comparison against old bDS. Missing or not-yet-implemented surfaces are not counted as parity failures in this table.
+Current batch 4 parity scores for implemented backend code only. This snapshot is the output of completed step 6. Missing or not-yet-implemented surfaces are not counted as parity failures in this table.
 
 | Service slice | Score | Old bDS anchor | bDS2 anchor | Owning shell/editor entry | Proof used | Existing-code parity result |
 | --- | --- | --- | --- | --- | --- | --- |