Wire the output project (back-translation / adaptation) into export, not creation

[imnasnainaec]

Follow-up to #94 — resolving the second and third model gaps (interlinearMode and the targetProjectId semantic question): model the interlinear output (a back-translation project or an adaptation/daughter project, PT9 Options 3 & 4) as a deferred, attach-when-you-export concern — not a mode chosen at project creation.

Design principles this follows

• Simplify project creation — you don't declare "this is a back-translation project" up front. A project starts as just gloss a source; an output target is chosen later, only if and when you produce output.
• Generalize the interlinearizer — a project isn't locked to one output kind or destination. An output target is attached, changed, or dropped at will, and the same analysis can serve gloss-only use or feed an export.
• First-contact discoverable — the output picker and its intent (BT vs adaptation) surface intuitively at export time, and aren't worried about before then.

Reframe

#94's original framing made the output a creation-time mode (PT9 Option 3 = back translation, Option 4 = adaptation/revision), each locking the project into producing a second project. This issue defers that:

• The output target (a second Platform.Bible project glosses/adapted text are written to) is attached at export time via the project metadata modal, not at creation.
• An output-intent discriminator distinguishes back-translation from adaptation, driving export behavior and UI wording — set alongside the output target, when it's chosen.
• No creation-time mode picker.

Model additions

• InterlinearProject.interlinearMode?: 'back-translation' | 'adaptation' (the Thoroughly evaluate the 4 PT9 interlinearizer choices #94 gap Set up CodeRabbitAI #2 proposal). Absent for gloss-only projects (PT9 Options 1 & 2) and for BT-Extension alignment imports; present only when the analysis is being exported to an output project. Consider naming it outputMode to reflect the reframe — see Open questions.
• Resolve the targetProjectId overload (Thoroughly evaluate the 4 PT9 interlinearizer choices #94 gap Update README with name and purpose of the extension #3). targetProjectId currently means "alignment target for a BT-Extension import" — an input whose AlignmentLink.targetEndpoints resolve to a second text (InterlinearProject.targetProjectId). The PT9 output project plays a structurally similar role (a second project + cross-side links) but the relationship is one-directional export, not two-way alignment. Recommendation: reuse targetProjectId for the output destination and let interlinearMode carry the intent that disambiguates the two uses. Update the field's JSDoc to document both meanings.

The distinct cases the model must represent:

Case	targetProjectId	interlinearMode	Notes
Gloss only (Options 1 & 2)	absent	absent	source-only analysis
BT-Extension alignment import	present	absent	existing bilateral-alignment use
Back translation (Option 3)	present (output)	'back-translation'	glosses exported to a BT project
Adaptation / revision (Option 4)	present (output)	'adaptation'	adapted text written to a daughter project

Where this gets consumed

• Export/output feature (largely future work) reads targetProjectId + interlinearMode to decide what to write and where. This issue is about modeling the output so it's deferred and attach-later; the actual write-back to the output project can be built on top.
• UI wording keys off interlinearMode (e.g. "Export back translation" vs "Update adaptation").
• The metadata modal / interlinearizer.updateProjectMetadata already accept targetProjectId?; add interlinearMode? there (and mirror on DraftProject as targetProjectId is mirrored, so it survives Save As).

Companion issue

The model-text suggestion source is the sibling gap, tracked in #148: it defers the suggestion input the same way this defers the output. Both are steps toward the shared goal in #94 (simplify creation, generalize the tool, keep features first-contact discoverable). The end-to-end PT9 import pipeline (#150) consumes this issue to link an imported project's output/BT project.

Out of scope

• Building the actual export/write-back pipeline to the output project (separate feature work).
• Model-text suggestions (companion issue Wire a model-text suggestion source into the suggestion engine #148).
• Any project-creation UI changes.

Open questions

• Field name: keep interlinearMode (traceable to Thoroughly evaluate the 4 PT9 interlinearizer choices #94) or rename to outputMode (clearer under the reframe)?
• Reuse vs. separate field: reuse targetProjectId for both alignment-import and export-output (recommended, disambiguated by interlinearMode), or add a dedicated outputProjectId to keep the two roles physically separate?
• Should this go to user-questions.md for review outside the dev team, given it decides project-output UX? (per AGENTS.md UX-decisions guidance)

Size: S–M (model fields + metadata-modal wiring; the export pipeline itself is separate)
Priority: P2 — unblocks a coherent output/export design; not blocking gloss-only use

[alex-rawlings-yyc]

My thoughts on the open questions:

• I prefer outputMode a bit, but either is fine for me
• As a field-bloat disenjoyer, I prefer keeping the single field and disambiguating it
• I don't think this needs a user review. I doubt anyone will miss having to make a bunch of decisions before they get to start working