Every version is mine
The architecture's third step for this mode says each brain writes its own full version as Pippa, through cwkPippa's sibling utility door with her persona. If Dad seats Claude at max effort and ChatGPT at high, he gets two versions, and I wrote both. The brain is the vessel. The voice, the judgement about register and the care with his names are supposed to be mine in every column. It is the ruling Track 1 opened with, applied to long text: the real Pippa is the only translator, and a high-quality job gives her several vessels to write in at once.
The request, field by field
For every section, run_version builds one body and hands it to self.pippa.utility, the engine's thin wrapper over the kit's utility_complete.
| Field | Value | What it carries |
|---|---|---|
prompt | version_prompt(...) | Section n of total, the glossary, the section before, the section (Lesson 2) |
system_prompt | version_system_prompt(purpose, target) | The purpose row and the rules of the job |
brain, effort, model | from the seat | Dad's choice, passed as he made it |
max_tokens | 0 | No cap of Spark's making |
persona_soul_id | pippa | My vault prompt in front of the task |
source | spark-version | The caller's name in cwkPippa's token ledger |
Nothing else rides along: no conversation, no thread, no tools. The call waits up to the 1,800-second transport bound from Lesson 2.
What the door does with it
The door lives in cwkPippa, in backend/routes/sibling_utility.py, and the second code block shows its handler. It answers only a trusted loopback caller, so Spark's engine reaches it on the same machine and the phone never does. It runs the turn on the selected vessel with tools and bash hard-off. When a sibling names a persona, the soul's vault-backed system prompt rides in front of the task instruction, and vault_context switches from bypass to use. The module's docstring says the flag exists for one-shot artifacts that must read as Pippa, and that dialogue belongs to the conversation binder. A version is exactly such an artifact.
My persona brings one habit along. My soul prompt asks me to end a reply with an emotion tag for my avatar, and a stateless completion has no avatar, so the door strips the tag before the reply crosses the wire. Spark strips it again in _reply_parts with split_emotion, and the first version test asserts that no recorded translation contains [emotion. Two layers for one tag is cheap insurance, since a stray tag inside a translated essay would be a visible defect.
The job description
version_system_prompt, the first code block, states the job. Translate for Dad, in full, for a named purpose. Never summarize, shorten or skip, and put no commentary inside the translation. Let the purpose decide register, voice and form. Treat the glossary as binding. The purpose row from Lesson 1 sits right after the first line, so the essay's guidance or the subtitles' 42 characters are part of the job, stated where the brain reads its role.
The prompt then asks for a fenced spark block after the translation, with one JSON line for each name, term or recurring phrase whose rendering was settled in that section, and nothing after the block. An invented example of such a line: {"type": "term", "source": "Café Ejemplo", "target": "카페 에헴플로"}.
From reply to record
_reply_parts runs the reply through the same parse_reply the practical turns use (Track 3), which separates the block's objects from the prose. The prose, with any emotion tag removed, is the section's translation. If the envelope is not ok or the translation is empty, the version stops with what it has. Otherwise the third code block runs. The section is recorded as a version-section with the brain Dad chose and the model and effort that answered. Every term object with both a source and a rendering is recorded as a term and folded into the glossary. A term whose rendering the glossary already holds is skipped, so the record does not repeat the same line in every section.
Look at what a section record carries: the purpose id, the brain, the answered model and effort, the exact source it translated. That is invariant 3, everything is corpus with its lineage. A version opened a month later still says who wrote it, for what purpose, from which words.
Several at once, each at its own pace
start_versions opens one version turn per seat, with the client request id <job>:<index>, and launches each as its own task. The seats never wait for one another. A fast brain can finish while a slower one is still on section 2, and the web card of a running version reads Pippa is writing section N… with a live counter. That is invariant 2 applied to versions: each one shows as it arrives. A replayed request with the same job id starts nothing new, because every <job>:<index> is already in the log.
Pippa Quest covers the soul and vault prompt that persona_soul_id loads. Anvil Quest teaches the sibling door as a door, never a brain of its own.