Record the TTS engine decision and what it still depends on

Qwen3-TTS as modified on the audio node, kept. Quality over time is the principle that
settles it, and the engine already in use is the one worth keeping.

The modifications are on the audio node and unknown here, so the speak work function
cannot be written blind. Listed what is needed: what changed and why, whether it is a fork
or a carryable patch, the input contract, and whether it loads a model and how large -
which decides whether node 238 can run it at all.

Parallel synthesis is a requirement, not an optimisation. The mechanism exists already
(submit_children and the decompose route), which means the work-function protocol has to
be designed for decomposition rather than have parallelism retrofitted into it.

docs/plan-translation-pipeline.md

@@ -153,4 +153,42 @@ exactly how a heterogeneous fleet ends up silently failing work it cannot perfor
   CPU that does not exist (`Ryzen 9 3900X`, faults on AVX2), which is now detected and
   reported rather than believed.
 - 525 tests pass. Two live defects: gate **G2** (the application connects as table owner)
-  and `VIEWS` in `web/assets/admin.js` omitting `projects`.
+  and `VIEWS` in `web/assets/admin.js` omitting `projects`.
+---
+
+## Decisions recorded 2026-10-03
+
+### TTS engine: Qwen3-TTS, as modified on the audio node
+
+Not a choice to be made here. The audio node already runs a **modified Qwen3-TTS**, and
+principle 1 of the specification — *quality is more important than time* — settles the
+question that was put to the owner about it. The engine in use stays.
+
+**What is not yet known:** what the modifications are. They live on the audio node, not in
+this repository, so a work function built here would be written blind. Before A2 is built,
+this needs to come back from the audio node:
+
+- what was changed and why,
+- whether it is a fork with its own history, or a patch that can be carried,
+- what the input contract is (text, voice, language, speed),
+- whether it loads a model, and how large.
+
+That last one decides whether node 238 can run it at all: 47 GiB of RAM, no GPU, and a
+hypervisor that faults on AVX2.
+
+### Parallel TTS on node 238
+
+Twelve cores and 47 GiB will run several synthesis processes at once, and this is a
+requirement rather than an optimisation. The mechanism already exists: `submit_children`
+and `POST /api/node/jobs/{id}/decompose` split one job into many, each claimed
+independently.
+
+So the work-function protocol (A1) has to be designed for decomposition from the start. A
+translation episode is thousands of lines; one job per line is thousands of jobs, and they
+claim concurrently. A `speak` function that cannot express "one job, many children" would
+force the parallelism into a hand-written loop on the node, which is exactly where it
+cannot be observed.
+
+The parent job must then wait for its children and refuse to complete early — otherwise the
+episode is assembled from whatever happened to finish, which is a race with a
+plausible-looking result.