Make overwrite more robust

Author: alex-rawlings-yyc

src/__tests__/components/modals/ProjectModals.test.tsx

@@ -578,6 +578,36 @@ describe('ProjectModals', () => {
       expect(setModal).toHaveBeenCalledWith('none');
     });
 
+    it('reconciles the overwritten project metadata with the draft config', async () => {
+      const draftWithConfig: DraftProject = {
+        sourceProjectId: 'source-proj',
+        analysisLanguages: ['sw', 'fr'],
+        targetProjectId: 'tgt-9',
+        analysis: emptyAnalysis(),
+        dirty: true,
+      };
+      render(
+        <ProjectModals
+          {...buildProps({ modal: 'saveAs', getDraftSnapshot: () => draftWithConfig })}
+        />,
+      );
+
+      await userEvent.click(screen.getByTestId('saveas-overwrite'));
+
+      // The project keeps its own name ('My Project') / description (undefined) but adopts the
+      // draft's analysis languages and alignment target so its metadata matches the stored glosses.
+      await waitFor(() =>
+        expect(papi.commands.sendCommand).toHaveBeenCalledWith(
+          'interlinearizer.updateProjectMetadata',
+          'proj-1',
+          'My Project',
+          undefined,
+          ['sw', 'fr'],
+          'tgt-9',
+        ),
+      );
+    });
+
     it('does not crash when overwriting rejects', async () => {
       jest.mocked(papi.commands.sendCommand).mockRejectedValueOnce(new Error('boom'));
       const markSynced = jest.fn();

src/components/modals/ProjectModals.tsx

@@ -295,8 +295,10 @@ export default function ProjectModals({
 
   /**
    * Overwrites an existing project with the current draft: writes the draft's analysis into the
-   * chosen project, makes it the active Save target, and clears the dirty flag. The backend
-   * surfaces its own error notification; here we only log.
+   * chosen project, reconciles the project's declared config (analysis languages / alignment
+   * target) with the draft so the metadata matches the glosses now stored in it, makes it the
+   * active Save target, and clears the dirty flag. The backend surfaces its own error notification;
+   * here we only log.
    *
    * @param project - The existing project to overwrite.
    * @returns A promise that resolves once the overwrite completes or the failure has been handled.
@@ -312,7 +314,25 @@ export default function ProjectModals({
           project.id,
           JSON.stringify(snapshot.analysis),
         );
-        setActiveProject(project);
+        // Push the draft's analysis languages / alignment target onto the project so its declared
+        // metadata stays consistent with the glosses just written (mirroring how Save As → New
+        // carries the draft's config into the created project). The project's name and description
+        // are intentionally preserved — overwriting keeps the target's identity.
+        await papi.commands.sendCommand(
+          'interlinearizer.updateProjectMetadata',
+          project.id,
+          project.name,
+          project.description,
+          snapshot.analysisLanguages,
+          snapshot.targetProjectId,
+        );
+        setActiveProject({
+          ...project,
+          analysisLanguages: snapshot.analysisLanguages,
+          // Assign explicitly (rather than a conditional spread) so a target binding on the
+          // overwritten project is cleared when the draft has none, matching what was persisted.
+          targetProjectId: snapshot.targetProjectId,
+        });
         markSynced(snapshot.analysis);
         setModal('none');
       } catch (e) {

user-questions.md

@@ -60,3 +60,20 @@ Decisions made during development that we'd like reviewed:
    Save target, so a subsequent Save still writes the (now empty) draft to it. "Wipe Current Book"
    stays flagged as unsaved, since it is a partial edit the user will usually want to save. Is this
    split right, or should both wipes behave the same?
+
+9. **Save As → Overwrite and the target's metadata.** "Save As → Overwrite an existing project"
+   replaces that project's analysis with the draft's. The draft's _config_ (analysis languages and
+   alignment target) can differ from the chosen project's — e.g. you Open project A (languages
+   `[en]`), then Save As → Overwrite project B (languages `[fr]`). We currently push the draft's
+   analysis languages and alignment target onto the overwritten project so its declared metadata
+   matches the glosses now stored in it, while keeping the project's existing **name and
+   description** (overwriting an existing named project keeps its identity). This mirrors how
+   Save As → New carries the draft's config into the newly created project. Is this the right split?
+   Options to review:
+   - Should overwrite also adopt the draft's **name/description** (i.e. fully replace the target),
+     or keep the target's identity as it does now?
+   - Should overwrite instead be **analysis-only**, leaving the target's languages/target untouched
+     (accepting that the stored glosses may then be tagged with languages the project doesn't
+     declare)?
+   - Should the Overwrite confirmation surface when the draft's languages differ from the target's,
+     so the user is aware their language tags are about to change?