vibe-coding-master 0.3.1 → 0.3.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -4,7 +4,7 @@
4
4
  <meta charset="UTF-8" />
5
5
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
6
6
  <title>VibeCodingMaster</title>
7
- <script type="module" crossorigin src="/assets/index-BavJjWQY.js"></script>
7
+ <script type="module" crossorigin src="/assets/index-OPkFuHRf.js"></script>
8
8
  <link rel="stylesheet" crossorigin href="/assets/index-CR1EOe-w.css">
9
9
  </head>
10
10
  <body>
@@ -904,6 +904,7 @@ Handoff artifact schemas:
904
904
  ## Architecture Summary
905
905
  ## Task Classification
906
906
  ## Required Role Route
907
+ ## Scaffold Manifest
907
908
  ## Modules / Files
908
909
  ## File Responsibilities
909
910
  ## Public Surface Contract
@@ -0,0 +1,618 @@
1
+ # Codex Translation Plan
2
+
3
+ ## 1. Purpose
4
+
5
+ VCM currently has API-backed conversation translation for terminal output,
6
+ gateway messages, and user prompts. That mode is useful for short interactive
7
+ messages, but it does not have enough project context for high-quality
8
+ translation when terminology depends on the repository, prior task discussion,
9
+ or long documents.
10
+
11
+ Translation should use a long-lived Codex translation role instead of stateless
12
+ translation API calls where quality depends on context. The goal is to let one
13
+ Codex session build and reuse project-level translation context: terminology,
14
+ style, prior decisions, existing translated files, source-document structure,
15
+ and interactive conversation conventions.
16
+
17
+ The existing role-console translation panel should remain the main UI for
18
+ conversation translation. The backend source of translated text changes from an
19
+ API provider to Codex Translator.
20
+
21
+ ## 2. Core Direction
22
+
23
+ Add a new Codex role:
24
+
25
+ ```text
26
+ codex-translator
27
+ ```
28
+
29
+ The role is responsible for both project-level file translation and task-level
30
+ conversation translation. It should:
31
+
32
+ - read the target source file and relevant project context
33
+ - maintain durable translation memory files
34
+ - translate directly into output files under `<baseRepoRoot>/.ai/vcm`
35
+ - record file metadata so unchanged files are not translated repeatedly
36
+ - support resume/retry after interruption
37
+ - produce a translation report with coverage and consistency checks
38
+ - translate short conversation items sent by VCM and return the translated text
39
+ through Codex hook completion metadata
40
+
41
+ Codex Translator is not part of the Claude Code PM/architect/coder/reviewer
42
+ workflow. It is a project utility role, like Codex Reviewer in terminal shape,
43
+ but with different permissions, output paths, and task semantics.
44
+
45
+ ## 3. Why Codex Session Translation
46
+
47
+ API translation has two weaknesses for long technical documents:
48
+
49
+ - Each call sees only a small slice of context unless VCM manually injects a
50
+ large context block.
51
+ - Translation memory is usually implicit in the prompt, so terminology and
52
+ project-specific meanings drift across calls.
53
+
54
+ Codex session translation improves this because:
55
+
56
+ - the session can inspect the whole repository and the whole source document
57
+ - Codex can keep a long conversation state and use its normal context
58
+ compaction behavior
59
+ - durable memory files can preserve decisions across session compaction,
60
+ restarts, and future translation jobs
61
+ - translation output can be written to files instead of returned through one
62
+ very large API response
63
+
64
+ The product should not rely only on chat context. The Codex session is useful,
65
+ but durable translation memory is the source of truth for project-level
66
+ conventions.
67
+
68
+ ## 4. Storage Layout
69
+
70
+ VCM must keep two translation lifecycles separate:
71
+
72
+ | Translation type | Purpose | Root | Lifecycle | Cleanup |
73
+ | --- | --- | --- | --- | --- |
74
+ | File translation | Project documents, whitepapers, specs, long-form artifacts | `<baseRepoRoot>/.ai/vcm/file-translations/` | Long-term project-local state | Survives task cleanup and worktree deletion |
75
+ | Conversation translation | Role console output, user prompt translation, gateway replies | `<taskRepoRoot>/.ai/vcm/translation/<task>/...` | Temporary task runtime cache | Removed with task runtime state |
76
+
77
+ File translation state is project-level, not task-level. It lives under the
78
+ connected base repository:
79
+
80
+ ```text
81
+ <baseRepoRoot>/.ai/vcm/file-translations/
82
+ index.json
83
+ memory/
84
+ glossary.md
85
+ style-guide.md
86
+ project-context.md
87
+ decisions.md
88
+ jobs/
89
+ <translation-id>/
90
+ request.json
91
+ progress.json
92
+ output.md
93
+ report.md
94
+ checkpoints/
95
+ ```
96
+
97
+ This path is intentionally under `<baseRepoRoot>`, not `<taskRepoRoot>`, because
98
+ file translation is a project asset that should survive task cleanup. In
99
+ worktree-backed tasks, `<taskRepoRoot>` points at
100
+ `<baseRepoRoot>/.claude/worktrees/<task>` and may be deleted when the task is
101
+ closed. File translation must never be stored there.
102
+
103
+ The existing console translation cache remains separate:
104
+
105
+ ```text
106
+ <taskRepoRoot>/.ai/vcm/translation/<task>/<role>/<session-id>.jsonl
107
+ ```
108
+
109
+ Conversation translation request state, if persisted, must stay under the same
110
+ task runtime translation root, for example:
111
+
112
+ ```text
113
+ <taskRepoRoot>/.ai/vcm/translation/<task>/codex-translator/
114
+ requests/
115
+ <translation-id>.json
116
+ results/
117
+ <translation-id>.json
118
+ ```
119
+
120
+ This state is temporary. It exists only to coordinate in-flight requests,
121
+ retries, panel rendering, and debugging for the current task.
122
+
123
+ `file-translations/` must never be deleted by task cleanup. It is local VCM
124
+ state and is normally ignored by git through `.ai/vcm/`. If the user wants a
125
+ translated file committed to the project, VCM should provide an explicit export
126
+ or copy step.
127
+
128
+ Inline tasks are the only case where `<baseRepoRoot>` and `<taskRepoRoot>` are
129
+ the same directory. Even then, cleanup must remove only task-scoped paths such
130
+ as `.ai/vcm/translation/<task>/`, sessions, messages, orchestration, handoffs,
131
+ and task Codex review state. Cleanup must not remove
132
+ `.ai/vcm/file-translations/`.
133
+
134
+ Implementation rule: file translation services must resolve and persist through
135
+ the connected project base root. They must not use `getTaskRuntimeRepoRoot()` or
136
+ any task worktree root when computing file translation paths.
137
+
138
+ ## 5. Translation Memory
139
+
140
+ Translation memory should be explicit files, not just model memory.
141
+
142
+ Recommended files:
143
+
144
+ - `memory/glossary.md`: approved translations for project terms, product names,
145
+ protocol names, module names, acronyms, and phrases.
146
+ - `memory/style-guide.md`: tone, target language variant, formatting rules,
147
+ how to handle headings, code identifiers, tables, examples, and citations.
148
+ - `memory/project-context.md`: durable project background useful for
149
+ translation accuracy.
150
+ - `memory/decisions.md`: dated translation decisions and exceptions.
151
+
152
+ Codex Translator must read these files before each file translation job and may
153
+ use them for conversation translation. It may update them only when it discovers
154
+ a stable convention that should affect future translations. It must not store
155
+ transient task chatter, progress notes, or failed attempts in memory files.
156
+
157
+ Progress belongs in `jobs/<translation-id>/progress.json`; diagnostic notes
158
+ belong in `jobs/<translation-id>/report.md`.
159
+
160
+ ## 6. File Index And De-duplication
161
+
162
+ `index.json` prevents duplicate translation and supports resume.
163
+
164
+ Suggested schema shape:
165
+
166
+ ```json
167
+ {
168
+ "version": 1,
169
+ "updatedAt": "2026-06-14T00:00:00.000Z",
170
+ "jobs": [
171
+ {
172
+ "id": "whitepaper-v0-8-zh-20260614-001",
173
+ "sourcePath": "docs/whitepaper-v0.8.md",
174
+ "baseRepoRoot": "/absolute/base/repo/root",
175
+ "taskRepoRoot": null,
176
+ "sourceHash": "sha256:...",
177
+ "sourceBytes": 449958,
178
+ "sourceMtimeMs": 1790000000000,
179
+ "targetLanguage": "zh-CN",
180
+ "translationProfile": "default-technical-whitepaper",
181
+ "memoryHash": "sha256:...",
182
+ "dedupeKey": "sha256:<sourceHash>|zh-CN|default-technical-whitepaper",
183
+ "status": "completed",
184
+ "codexSessionId": "...",
185
+ "model": "gpt-5.5",
186
+ "effort": "xhigh",
187
+ "resultPath": ".ai/vcm/file-translations/jobs/whitepaper-v0-8-zh-20260614-001/output.md",
188
+ "reportPath": ".ai/vcm/file-translations/jobs/whitepaper-v0-8-zh-20260614-001/report.md",
189
+ "createdAt": "2026-06-14T00:00:00.000Z",
190
+ "updatedAt": "2026-06-14T00:00:00.000Z",
191
+ "completedAt": "2026-06-14T00:00:00.000Z"
192
+ }
193
+ ]
194
+ }
195
+ ```
196
+
197
+ `sourcePath`, `resultPath`, and `reportPath` are relative to `<baseRepoRoot>`.
198
+ They are not relative to a task worktree.
199
+
200
+ De-duplication rules:
201
+
202
+ - If the same `dedupeKey` has a completed job, VCM should show the existing
203
+ translation instead of starting a new one.
204
+ - If the source hash changed, VCM must create a new job.
205
+ - If the same file is translated from a task worktree, VCM should normalize the
206
+ source path back to the base repo path when possible; the long-term job still
207
+ belongs to `<baseRepoRoot>/.ai/vcm/file-translations/`.
208
+ - If only memory files changed, VCM should ask whether to reuse the old
209
+ translation, re-run consistency review, or retranslate.
210
+ - Failed or interrupted jobs can be resumed when `progress.json` has enough
211
+ section state.
212
+ - Force retranslate should create a new job id and preserve the old result.
213
+
214
+ ## 7. Codex Translator Role
215
+
216
+ Codex Translator needs its own durable instructions, separate from Codex
217
+ Reviewer. Recommended harness path:
218
+
219
+ ```text
220
+ <baseRepoRoot>/.ai/codex-translator/
221
+ AGENTS.md
222
+ config.toml
223
+ .codex/
224
+ config.toml
225
+ hooks.json
226
+ ```
227
+
228
+ The role should start from `.ai/codex-translator` so Codex loads the translator
229
+ `AGENTS.md`. It should reuse the existing Codex embedded terminal/session
230
+ management pattern:
231
+
232
+ - start/resume/restart/stop terminal controls
233
+ - model and effort selectors
234
+ - hook-based running/idle state
235
+ - persisted Codex session id
236
+ - long-lived terminal session for follow-up discussion
237
+
238
+ The role must not use Codex Reviewer prompts or permissions.
239
+
240
+ Codex Translator should have durable instructions for both modes:
241
+
242
+ - file translation: write long results to files and report coverage
243
+ - conversation translation: return only the requested translated text unless VCM
244
+ explicitly asks for notes or diagnostics
245
+ - memory usage: respect glossary, style guide, and project context without
246
+ adding task-local chatter to memory files
247
+
248
+ ## 8. Permissions
249
+
250
+ Default permissions should be conservative:
251
+
252
+ - read: `<baseRepoRoot>`
253
+ - write: `<baseRepoRoot>/.ai/vcm/file-translations/`
254
+ - deny: secrets such as `**/*.env`
255
+ - network: disabled except normal Codex model access controlled by Codex CLI
256
+
257
+ Codex Translator should not edit production code, existing docs, role files, or
258
+ source documents by default. Exporting a translated file into the project tree
259
+ should be a separate explicit user action.
260
+
261
+ ## 9. Hook Result Contract
262
+
263
+ VCM should use Codex hooks, not terminal text scraping, to track conversation
264
+ translation completion.
265
+
266
+ Observed Codex hook payload shape:
267
+
268
+ ```text
269
+ UserPromptSubmit:
270
+ - session_id
271
+ - turn_id
272
+ - transcript_path
273
+ - cwd
274
+ - hook_event_name = UserPromptSubmit
275
+ - model
276
+ - permission_mode
277
+ - prompt
278
+
279
+ Stop:
280
+ - session_id
281
+ - turn_id
282
+ - transcript_path
283
+ - cwd
284
+ - hook_event_name = Stop
285
+ - model
286
+ - permission_mode
287
+ - stop_hook_active
288
+ - last_assistant_message
289
+ ```
290
+
291
+ Output contract:
292
+
293
+ - `Stop.last_assistant_message` is the primary translated-text source for
294
+ conversation translation.
295
+ - `transcript_path` is persisted as the debug and recovery source.
296
+ - The transcript JSONL can also be parsed for `event_msg.agent_message.message`
297
+ or `task_complete.last_agent_message` when the stop hook did not deliver a
298
+ usable `last_assistant_message`.
299
+ - VCM must not parse the embedded Codex terminal's raw PTY output. It contains
300
+ ANSI control sequences and UI redraw text, so it is not a reliable data
301
+ channel.
302
+
303
+ Trust constraint:
304
+
305
+ - Codex project-local `.codex/hooks.json` is loaded only for trusted project
306
+ roots. `--dangerously-bypass-hook-trust` allows enabled hook commands to run
307
+ without per-command review, but it does not make an untrusted directory load
308
+ project-local hooks.
309
+ - VCM should run Codex Translator from the harness-managed, trusted project path
310
+ and treat hook registration as part of harness setup.
311
+
312
+ ## 10. File Translation Workflow
313
+
314
+ Recommended flow:
315
+
316
+ ```text
317
+ User selects source file and target language
318
+ -> VCM computes file metadata and source hash
319
+ -> VCM checks file-translations/index.json
320
+ -> if completed duplicate exists, show existing result
321
+ -> else create translation job
322
+ -> VCM starts or resumes Codex Translator
323
+ -> VCM sends job prompt to Codex Translator
324
+ -> Codex reads source, memory, and project context
325
+ -> Codex writes output.md and progress.json
326
+ -> Codex writes report.md
327
+ -> VCM marks job completed / failed / interrupted
328
+ ```
329
+
330
+ The translation prompt should tell Codex:
331
+
332
+ - do not print the whole translation to the terminal
333
+ - write the translated document directly to `output.md`
334
+ - preserve Markdown structure, code blocks, links, tables, heading hierarchy,
335
+ front matter, and identifiers
336
+ - use glossary and style guide consistently
337
+ - update progress after each completed section
338
+ - write a final report with source coverage, skipped content, glossary updates,
339
+ and QA findings
340
+
341
+ ## 11. Conversation Translation Workflow
342
+
343
+ Conversation translation reuses the existing translation panel. The panel should
344
+ not know whether the translated text came from an API provider or from Codex.
345
+
346
+ Recommended flow:
347
+
348
+ ```text
349
+ VCM filters translatable content
350
+ -> VCM checks whether Codex Translator is currently translating
351
+ -> if busy, queue the request
352
+ -> if idle, send a compact translation prompt to Codex Translator
353
+ -> Codex translates using AGENTS.md plus current session memory
354
+ -> UserPromptSubmit hook marks translator busy
355
+ -> Stop hook returns last_assistant_message
356
+ -> VCM writes the translated text to the existing translation panel cache
357
+ -> VCM starts the next queued request, if any
358
+ ```
359
+
360
+ Prompt shape should stay minimal because the durable translation rules live in
361
+ `AGENTS.md` and memory files. VCM should send the source text, direction, target
362
+ language, and any immediate local context needed to avoid ambiguity. It should
363
+ not rebuild a large translation policy prompt for every item.
364
+
365
+ Concurrency rules:
366
+
367
+ - Allow only one in-flight Codex Translator request per task/session.
368
+ - Queue new conversation translation requests while the translator is running.
369
+ - Use hook state, not terminal silence, to decide whether the translator is
370
+ busy.
371
+ - If Codex execution fails, VCM should expose retry / skip / fallback handling
372
+ to the user.
373
+
374
+ Result handling:
375
+
376
+ - For normal conversation translation, the Codex response should be the
377
+ translated text only.
378
+ - VCM stores that text in the existing temporary translation cache under
379
+ `<taskRepoRoot>/.ai/vcm/translation/<task>/...`.
380
+ - VCM should keep the `session_id`, `turn_id`, `transcript_path`, source text
381
+ hash, and timestamp with each request result for retry and debugging.
382
+ - For long or structured text that may exceed a comfortable assistant message,
383
+ VCM should switch to the file-translation flow and ask Codex to write a result
384
+ file instead.
385
+
386
+ ## 12. File Translation Strategy
387
+
388
+ For files that fit comfortably in a large context window, Codex Translator
389
+ should read the whole source file before translating. That preserves global
390
+ context and improves terminology choices.
391
+
392
+ Output still should not be one huge terminal response. Codex should write the
393
+ target file directly and may translate section by section inside the same
394
+ session.
395
+
396
+ Suggested internal sequence:
397
+
398
+ 1. Read source file and memory files.
399
+ 2. Build a section map.
400
+ 3. Identify or update glossary candidates.
401
+ 4. Translate into `output.md` by section.
402
+ 5. Update `progress.json` after each section.
403
+ 6. Run a structure check against the source.
404
+ 7. Run a terminology consistency check.
405
+ 8. Write `report.md`.
406
+
407
+ This keeps the quality advantage of whole-file context without depending on one
408
+ single model response to return the entire translated file.
409
+
410
+ ## 13. Progress And Resume
411
+
412
+ `progress.json` should include:
413
+
414
+ ```json
415
+ {
416
+ "status": "in_progress",
417
+ "sourcePath": "docs/whitepaper-v0.8.md",
418
+ "targetLanguage": "zh-CN",
419
+ "sections": [
420
+ {
421
+ "id": "abstract",
422
+ "heading": "Abstract",
423
+ "sourceStartLine": 7,
424
+ "sourceEndLine": 20,
425
+ "status": "completed",
426
+ "outputStartLine": 7,
427
+ "outputEndLine": 22
428
+ }
429
+ ],
430
+ "currentSectionId": "architecture",
431
+ "lastUpdatedAt": "2026-06-14T00:00:00.000Z"
432
+ }
433
+ ```
434
+
435
+ Resume behavior:
436
+
437
+ - If Codex session is still available, continue in the same session.
438
+ - If the terminal was stopped, resume the Codex session id when possible.
439
+ - If the session cannot resume, start a new Codex Translator session and reload
440
+ memory plus `request.json`, `progress.json`, and partial `output.md`.
441
+ - Never overwrite a completed output unless the job is explicitly marked as
442
+ force-retranslate.
443
+
444
+ ## 14. UI Shape
445
+
446
+ Add a project-level file translation surface, not a task role gate.
447
+
448
+ Recommended UI:
449
+
450
+ - Sidebar group: `File Translation`
451
+ - Controls:
452
+ - source file picker or path input
453
+ - target language
454
+ - translation profile
455
+ - model
456
+ - effort
457
+ - `Translate`
458
+ - `Resume`
459
+ - `Open result`
460
+ - `Force retranslate`
461
+ - Status:
462
+ - current Codex Translator session
463
+ - active job
464
+ - completed sections
465
+ - output path
466
+ - report path
467
+
468
+ When a file translation job exists, the workspace should expose a `Codex
469
+ Translator` embedded terminal role so the user can discuss terminology, challenge
470
+ translation choices, or ask for focused revisions after the automated pass.
471
+
472
+ For conversation translation, keep the existing split translation panel. The
473
+ visible behavior should remain:
474
+
475
+ - source appears immediately
476
+ - status shows queued/translating/error/translated
477
+ - translated text replaces or accompanies the source according to the existing
478
+ panel behavior
479
+ - retry operates on the temporary translation entry
480
+
481
+ The panel should not parse Codex terminal output. It receives translated entries
482
+ from the backend after the Codex `Stop` hook.
483
+
484
+ ## 15. Backend Services
485
+
486
+ New backend pieces:
487
+
488
+ - `codex-translation-service`
489
+ - create job
490
+ - compute source hash
491
+ - resolve base repo root and reject task-worktree output paths
492
+ - load/update index
493
+ - start/resume Codex Translator
494
+ - send job prompt
495
+ - queue and send conversation translation prompts
496
+ - consume `Stop.last_assistant_message` for conversation translation results
497
+ - monitor completion
498
+ - `codex-translation-routes`
499
+ - list jobs
500
+ - create job
501
+ - get job status
502
+ - read result/report
503
+ - resume/retry/force retranslate
504
+ - get conversation translation request status when needed for debugging
505
+ - translator hook service
506
+ - same running/idle tracking pattern as Codex Reviewer
507
+ - persist `session_id`, `turn_id`, `transcript_path`, and
508
+ `last_assistant_message`
509
+ - separate endpoint names, for example:
510
+
511
+ ```text
512
+ POST /api/hooks/codex-translator
513
+ POST /api/hooks/codex-translator/stop
514
+ ```
515
+
516
+ The existing Codex Reviewer services should not be overloaded with translation
517
+ logic. Shared utility code is fine, but role state, directories, prompts, and
518
+ permissions should remain separate.
519
+
520
+ ## 16. Relationship To Existing Translation
521
+
522
+ Keep the current translation UI surfaces:
523
+
524
+ - gateway Chinese-to-English / English-to-Chinese
525
+ - role-console output translation
526
+ - user input translation
527
+
528
+ Those are interactive-message translation features. Under this plan, VCM can
529
+ route their translation work to Codex Translator so terminology and style benefit
530
+ from the long-lived session and memory files.
531
+
532
+ Codex file translation is a document-production feature. It produces durable
533
+ project-local files and uses Codex session context plus translation memory.
534
+
535
+ Conversation translation and file translation may share translation settings UI
536
+ concepts such as target language and style, but they must not share runtime
537
+ caches. Conversation results stay task-temporary; file results stay
538
+ project-durable.
539
+
540
+ ## 17. Implementation Phases
541
+
542
+ ### Phase 1: Design And Harness
543
+
544
+ - Add translator role docs and prompts.
545
+ - Add `.ai/codex-translator` harness files.
546
+ - Add `file-translations/` directory contract.
547
+ - Define index, request, progress, and report schemas.
548
+ - Define Codex hook result contract for `last_assistant_message` and
549
+ `transcript_path`.
550
+
551
+ ### Phase 2: Backend Job Model
552
+
553
+ - Implement source hash and de-duplication.
554
+ - Implement job create/list/read/resume.
555
+ - Persist output under `<baseRepoRoot>/.ai/vcm/file-translations/`.
556
+ - Preserve file translation state during task cleanup, including inline-task
557
+ cleanup where `<baseRepoRoot>` equals `<taskRepoRoot>`.
558
+ - Ensure conversation translation cleanup still removes only
559
+ `<taskRepoRoot>/.ai/vcm/translation/<task>/`.
560
+
561
+ ### Phase 3: Codex Session Integration
562
+
563
+ - Add `codex-translator` role/session support.
564
+ - Reuse Codex embedded terminal startup with model/effort selectors.
565
+ - Add hook endpoints and running/idle tracking.
566
+ - Send translation job prompts into the long-lived Codex session.
567
+ - Capture conversation translation output from `Stop.last_assistant_message`.
568
+ - Persist `transcript_path` for debugging and fallback parsing.
569
+
570
+ ### Phase 4: UI
571
+
572
+ - Add sidebar `File Translation` group.
573
+ - Add job list/status/result/report views.
574
+ - Add Codex Translator terminal surface.
575
+ - Add duplicate detection and force retranslate UX.
576
+ - Reuse the existing role-console translation panel for conversation
577
+ translation results.
578
+
579
+ ### Phase 5: QA And Recovery
580
+
581
+ - Add Markdown structure checks.
582
+ - Add glossary consistency checks.
583
+ - Add missing-section detection.
584
+ - Add resume tests with partial output.
585
+ - Test with `docs/whitepaper-v0.8.md` scale files.
586
+
587
+ ## 18. Open Questions
588
+
589
+ - Should the default output remain only under `.ai/vcm/file-translations/`, or
590
+ should VCM also offer an optional export path beside the source document?
591
+ - Should there be one Codex Translator session per project, or one per
592
+ target-language/profile pair?
593
+ - Should memory updates require user approval, or can Codex update glossary and
594
+ style-guide files automatically with a report entry?
595
+ - Should completed translations be considered local VCM state only, or should
596
+ VCM offer a "promote to repo doc" workflow for commit-ready translations?
597
+ - Should conversation translation keep API translation as a user-selectable
598
+ fallback, or should Codex Translator be the only provider once enabled?
599
+
600
+ ## 19. Recommended Defaults
601
+
602
+ - One Codex Translator session per base repository and target language.
603
+ - Store all job outputs under `.ai/vcm/file-translations/` by default.
604
+ - Resolve that path from `<baseRepoRoot>`, never from a task worktree.
605
+ - Keep conversation translation under `<taskRepoRoot>/.ai/vcm/translation/`
606
+ because it is temporary task runtime state.
607
+ - Use `Stop.last_assistant_message` as the normal result channel for
608
+ conversation translation.
609
+ - Persist `transcript_path` on every Codex Translator turn for recovery and
610
+ debugging.
611
+ - Never parse raw Codex embedded terminal output for translation content.
612
+ - Do not edit source documents or project docs during translation.
613
+ - Require explicit user action to export or promote a translation into the
614
+ normal repository tree.
615
+ - Let Codex update `memory/glossary.md` and `memory/decisions.md`, but require
616
+ every update to be summarized in `report.md`.
617
+ - Prefer whole-file reading plus section-by-section file writes in one long-lived
618
+ Codex session.