yoi/.yoi/tickets/00001KTJMDWTR/thread.md

24 KiB

Created

Created by LocalTicketBackend create.


Decision

Intake readiness classification: implementation_ready for routing, with needs_preflight: true.

Rationale: the Ticket already defines the product boundary between worker.language and durable Ticket record language, names the expected config shape ([ticket].language preferred), preserves absent-config behavior, and lists observable acceptance criteria. Preflight is still required before implementation because the work touches Ticket config, role launch prompts, typed tool/backend generated text, profile/worker language boundaries, and generated durable records.

Risk flags: config, profile-boundary, workflow-prompts, tool-generated-records, backward-compatibility, localization-policy.

Implementation latitude: implementers may choose the minimal practical set of generation paths for the first change as long as they document the policy, preserve existing behavior when ticket.language is absent, avoid rewriting existing Tickets, and escalate before changing public/authority semantics beyond Ticket record language selection.


Intake summary

Existing Ticket refined and marked ready for Orchestrator routing. Scope: add explicit Ticket record language configuration separate from Pod/worker response language; expose it to role launch prompts and typed Ticket-generated record paths where practical; preserve absent-config behavior and avoid translating existing records or protocol literals. Readiness: implementation_ready for routing, with preflight recommended/required because the work touches config, profile/worker language boundaries, workflow prompts, and generated durable Ticket records. Risk flags: config, profile-boundary, workflow-prompts, tool-generated-records, backward-compatibility, localization-policy.


State changed

Intake completed; Ticket has enough requirements, acceptance criteria, invariants, validation expectations, and escalation conditions for Orchestrator routing. Do not start implementation automatically; the next human/panel action is ready -> queued.


State changed

Ticket queued for Orchestrator routing.


Decision

Routing decision: preflight_needed

Reason:

  • This Ticket touches the boundary between worker response language, durable Ticket record language, role launch prompts, Ticket tools/workflows, memory policy, and public/operator-facing project records.
  • The desired behavior is clear at a high level, but the exact source of truth for Ticket record language and how it is propagated into role launch/tool/workflow contexts needs a binding design note before coder delegation.
  • Without preflight, implementation could accidentally conflate user-facing conversation language with durable Ticket record language, or create hidden context-only language instructions that conflict with history/prompt-cache policy.

Evidence checked:

  • Ticket body and thread, including latest ready -> queued event.
  • Workspace state: no matching branch/worktree exists; active worktrees for direct/delegation authority and panel close are separate.
  • Code/prompt context: this crosses Ticket backend/tool wording, role launch prompt generation, workflow templates, profile/worker language handling, and memory language policy.
  • Ticket doctor: 0 errors; existing warnings are unrelated legacy closed-Ticket diagnostics.

Next action:

  • Run ticket-preflight-workflow before implementation delegation.
  • Preflight should record: canonical config key/source for Ticket record language, fallback/default behavior, relationship to [worker].language and [memory].language, which Ticket tools/workflows/role launch prompts must use record language, whether existing Tickets are left as-is, how mixed-language user input is handled, tests/fixtures, and explicit non-use of hidden context-only language injection.
  • Leave this Ticket queued for now; do not transition queued -> inprogress, create .worktree/separate-ticket-record-language-from-worker-language, or spawn coder/reviewer Pods until preflight records implementation readiness.

Escalate if:

  • Ticket record language requires a migration of existing Ticket content.
  • The design would make worker response language override durable Ticket record language.
  • Language guidance would need to be injected into LLM context without being represented in committed history/tool/workflow prompts.
  • The implementation would blur Ticket record authority with memory-language generation rules.

Decision

Routing decision: implementation_ready

Correction:

  • The previous preflight_needed decision was too conservative for the current Ticket state. The Ticket body and Intake summary already fix the product boundary: worker.language controls conversational prose, while ticket.language controls durable Ticket records and generated Ticket event/resolution/scaffold text.
  • Remaining uncertainty is bounded implementation policy and test coverage, not a human-blocking design question.

Reason:

  • The canonical config shape is already selected by the Ticket as [ticket].language, with explicit instruction not to overload [worker].language or Profile settings.
  • Backward compatibility is clear: absence of ticket.language preserves current/default behavior.
  • The non-migration rule is clear: existing Tickets are not bulk-translated or rewritten.
  • The language boundary is explicit enough for coder/reviewer: do not translate protocol literals, file paths, commands, logs, identifiers, or quoted external text merely because Ticket language is set.
  • Role-launch prompt exposure and typed generated-record coverage can be implemented incrementally where practical, as long as the policy is documented and tests cover representative paths.

Evidence checked:

  • Ticket body and thread, including Intake readiness and prior routing note.
  • Workspace state: no matching branch/worktree exists; active allow-spawnpod-child-workspace-cwd and shutdown-intake-pod-after-ready-idle worktrees are separate and touch different code paths.
  • Code map search for Ticket config/scaffold, worker/memory language handling, Ticket role launch prompt/context, typed Ticket generated events/resolutions, and Panel close deterministic resolution paths.
  • Ticket doctor: 0 errors; existing warnings are unrelated legacy closed-Ticket diagnostics.

IntentPacket:

Intent:

  • Add explicit Ticket record language configuration and propagate it to durable Ticket record generation and role guidance without changing normal worker response language.

Binding decisions / invariants:

  • worker.language remains conversation/prose response language for Pods.
  • memory.language remains memory/Knowledge generation language.
  • New ticket.language is durable Ticket record language for Ticket item/thread/resolution generated text and role guidance where Ticket records are written.
  • Preferred config shape is [ticket].language in .yoi/ticket.config.toml.
  • Absence of ticket.language preserves current/default behavior.
  • Existing Tickets are not bulk-translated or rewritten.
  • Do not translate protocol literals, file paths, commands, logs, identifiers, or quoted external text merely because Ticket language is configured.
  • Do not implement hidden context-only language injection. Language guidance must come from committed config/tool/workflow/launch-prompt paths.
  • Do not make worker response language override durable Ticket record language.

Requirements / acceptance criteria:

  • Extend Ticket config parser/scaffold to support optional [ticket].language.
  • Update this project's .yoi/ticket.config.toml to set the desired Ticket record language.
  • Expose Ticket record language to Ticket role launch prompt/context so Intake/Orchestrator/Coder/Reviewer know which language to use for Ticket comments/reviews/decisions.
  • Make typed Ticket-generated text consult configured Ticket record language where practical, at minimum for scaffold/default generated bodies or prominent generated event/resolution paths selected by coder.
  • Preserve current behavior when ticket.language is absent.
  • Document/encode the policy clearly enough that reviewer can distinguish implemented paths from future localization work.
  • Add tests for config parsing/scaffold/default behavior and at least one role prompt or generated record path.

Implementation latitude:

  • Coder may choose minimal practical first coverage for generated text paths, but must report which generated paths consult ticket.language and which remain future work.
  • Coder may use simple language labels/instructions rather than full translation infrastructure.
  • Coder may leave existing Ticket bodies/threads/resolutions untouched.
  • Coder may update maintained workflow/prompt guidance if it directly tells agents what language to use for Ticket records.

Escalate if:

  • Implementing ticket.language requires migrating existing Tickets.
  • Typed Ticket backend localization would require broad translation catalogs rather than a minimal policy/instruction pass-through.
  • Role launch prompt language guidance cannot be passed through committed prompt/history/tool paths.
  • Any path would conflate Ticket record language with memory extraction language or normal worker prose language.

Validation:

  • Ticket config parser/scaffold tests.
  • Role launch prompt/context tests verifying Ticket record language is included independently from worker language.
  • Focused generated-record test for at least one configured-language path.
  • cargo test -p ticket ... / cargo test -p client ... / cargo test -p yoi ... focused equivalents selected by coder.
  • cargo fmt --check.
  • git diff --check.
  • cargo run -q -p yoi -- ticket doctor.
  • Because config/scaffold/runtime prompt behavior may change, final merge-completion should include nix build .#yoi.

Current code map:

  • crates/ticket/src/config.rs and Ticket config scaffold helpers.
  • crates/yoi/src/ticket_cli.rs: yoi ticket init scaffold tests and CLI examples.
  • crates/client/src/ticket_role.rs: TicketRoleLaunchContext, role prompt rendering, launch prompt construction.
  • crates/tui/src/multi_pod.rs and workspace_panel.rs: role launch/context construction and Panel generated resolution paths.
  • crates/ticket/src/lib.rs: typed Ticket generated events, default bodies, close behavior.
  • .yoi/ticket.config.toml: project-local desired Ticket record language.
  • resources/prompts / maintained workflow files only if they contain active role guidance that should mention Ticket record language.

Critical risks / reviewer focus:

  • ticket.language must remain independent from worker.language.
  • Existing absent-config behavior must not regress.
  • Role prompt guidance must be durable/committed, not hidden context injection.
  • Existing records must not be bulk rewritten.
  • Generated text coverage must be explicit; partial coverage is acceptable only if policy/future-work boundary is clear.

State changed

Accepted queued implementation after user confirmation and routing IntentPacket were recorded. This acceptance precedes worktree creation and coder/reviewer Pod spawning.


Plan

Implementation routing accepted and worktree created.

Worktree plan:

  • Branch: separate-ticket-record-language-from-worker-language
  • Worktree: .worktree/separate-ticket-record-language-from-worker-language
  • Base: 17ac5b0 ticket: route ticket record language implementation
  • Scope: add optional Ticket record language config and propagate it to role guidance/generated Ticket-record paths where practical.

Delegation plan:

  • Spawn sibling coder Pod with write scope limited to .worktree/separate-ticket-record-language-from-worker-language.
  • Coder must run Bash commands from the child worktree, not from the main workspace.
  • Coder must not edit main-workspace .yoi / Ticket / workflow / docs records, and must not create generated memory/local/runtime/secret-like files.
  • Reviewer will be spawned read-only after coder reports diff/commits and validation evidence.

Concurrency note:

  • allow-spawnpod-child-workspace-cwd and shutdown-intake-pod-after-ready-idle are active in separate worktrees. This language-policy implementation must remain isolated and should not depend on those unmerged branches.

Stop/completion policy:

  • Because the human authorized cleanup after completion, this Orchestrator will proceed through reviewer approval, merge-completion validation, Ticket close, Pod stop, worktree removal, and branch deletion if the branch is approved and merge authority remains clear.

Implementation report

Coder completed and reviewer delegated.

Coder result:

  • Pod: coder-ticket-record-language
  • Commit: fb261bb feat: add ticket record language config
  • Worktree status: clean after commit.
  • Diff against develop: 9 files changed, 310 insertions, 28 deletions.

Files touched by coder:

  • .yoi/ticket.config.toml
  • crates/ticket/src/config.rs
  • crates/ticket/src/lib.rs
  • crates/ticket/src/tool.rs
  • crates/client/src/ticket_role.rs
  • crates/pod/src/feature/builtin/ticket.rs
  • crates/tui/src/workspace_panel.rs
  • crates/tui/src/multi_pod.rs
  • crates/yoi/src/ticket_cli.rs

Coder reported implementation:

  • Added optional [ticket].language parsing with blank-string rejection and a commented scaffold example in yoi ticket init output.
  • Set this repository's .yoi/ticket.config.toml to [ticket] language = "Japanese".
  • Added ticket_record_language to TicketRoleLaunchContext and role launch prompt guidance, independent from worker/memory language.
  • Added LocalTicketBackend::with_record_language() / record_language() and propagates config language through CLI, built-in Ticket feature, and Panel backend construction.
  • Added minimal generated-text coverage for configured Japanese: create default item body, initial create thread event, queue/status/close generated events, TicketIntakeReady default body, and workspace Panel auto-close resolution.
  • No existing Tickets were bulk-translated or rewritten.
  • Arbitrary language names flow to role prompt/context; typed backend generated strings use explicit Japanese handling and otherwise fall back to default English rather than pretending to be a full localization catalog.

Coder reported validation:

  • cargo test -p ticket config::tests --lib
  • cargo test -p ticket create_uses_configured_japanese_record_language_for_generated_defaults --lib
  • cargo test -p client configured_ticket_record_language_is_included_in_role_prompt --lib
  • cargo test -p yoi ticket_cli_init_writes_explicit_ticket_config_scaffold
  • cargo check -p pod -p tui
  • cargo test -p ticket --lib
  • cargo test -p client ticket_role --lib
  • cargo fmt --check
  • git diff --check
  • cargo run -q -p yoi -- ticket doctor
  • nix build .#yoi

Reviewer delegation:

  • Spawned sibling reviewer Pod: reviewer-ticket-record-language.
  • Reviewer scope: read-only child worktree plus non-recursive parent-root read required by current launch cwd behavior.
  • Reviewer was instructed to judge against the recorded Ticket requirements and binding decisions.

Pending:

  • Await reviewer verdict before merge-ready dossier / merge-completion.
  • No merge, close, final approval, or cleanup has occurred for this Ticket.

Implementation report

Merge-ready dossier: Ticket record language policy

Ticket id/slug:

  • 20260608-032911-separate-ticket-record-language-from-worker-language / separate-ticket-record-language-from-worker-language

Branch/worktree:

  • Branch: separate-ticket-record-language-from-worker-language
  • Worktree: .worktree/separate-ticket-record-language-from-worker-language
  • Current branch commit:
    • fb261bb feat: add ticket record language config

Intent / invariant check:

  • worker.language remains conversational response language.
  • memory.language remains memory/Knowledge generation language.
  • New ticket.language config controls durable Ticket record language and role guidance where Ticket records are written.
  • Existing Tickets were not bulk-translated or rewritten by the implementation commit.
  • Role prompt guidance is committed launch input, not hidden context-only injection.
  • Non-translateable literals such as paths, commands, logs, identifiers, and quoted text remain outside language conversion policy.

Implementation summary:

  • Added optional [ticket].language config parsing and blank-string validation.
  • Added scaffold/example support for yoi ticket init.
  • Set this repository's .yoi/ticket.config.toml to [ticket] language = "Japanese".
  • Added Ticket record language to TicketRoleLaunchContext and role launch prompt guidance independent from worker/memory language.
  • Added LocalTicketBackend::with_record_language() / record_language() and propagated configured language through CLI, built-in Ticket feature, and Panel backend construction.
  • Added minimal generated-text coverage for Japanese, including create default body/thread, prominent state/close/intake-ready generated events, and Panel auto-close resolution.
  • Preserved default behavior when config is absent and falls back to English/default generated text for unsupported backend generated languages.

Files touched:

  • .yoi/ticket.config.toml
  • crates/ticket/src/config.rs
  • crates/ticket/src/lib.rs
  • crates/ticket/src/tool.rs
  • crates/client/src/ticket_role.rs
  • crates/pod/src/feature/builtin/ticket.rs
  • crates/tui/src/workspace_panel.rs
  • crates/tui/src/multi_pod.rs
  • crates/yoi/src/ticket_cli.rs

Coder / reviewer Pods:

  • Coder: coder-ticket-record-language
  • Reviewer: reviewer-ticket-record-language

Review evidence:

  • Reviewer verdict: approve.
  • Reviewer confirmed config parsing/scaffold/default/blank rejection, role prompt propagation independent from worker/memory language, durable prompt input path rather than hidden context injection, config propagation through CLI/feature/Panel backends, and no implementation-commit bulk rewrite of existing Tickets.

Validation performed by coder and/or reviewer:

  • cargo test -p ticket config::tests --lib
  • cargo test -p ticket create_uses_configured_japanese_record_language_for_generated_defaults --lib
  • cargo test -p client configured_ticket_record_language_is_included_in_role_prompt --lib
  • cargo test -p yoi ticket_cli_init_writes_explicit_ticket_config_scaffold
  • cargo test -p client ticket_role --lib
  • cargo test -p ticket --lib
  • cargo check -p pod -p tui
  • cargo fmt --check
  • git diff --check
  • cargo run -q -p yoi -- ticket doctor
  • nix build .#yoi

Blockers fixed or rejected findings:

  • No reviewer blockers.

Residual risks:

  • Japanese generated-text coverage is intentionally minimal, not full localization. Generic thread headings, some Panel/Defer decision bodies, and tool success output may remain English unless separately localized later.
  • Japanese handling helpers are duplicated between Ticket crate and TUI for now; centralization may be useful if supported languages or generated paths expand.
  • Branch was reviewed before later main merges that touched crates/client/src/ticket_role.rs; merge-completion must preserve both this Ticket's language guidance and later cwd/intake role guidance.

Dirty state:

  • Child worktree is clean at fb261bb.
  • Main workspace has unrelated Ticket-record edits for queued/intake work; they are outside this branch's core implementation paths and are understood.

Parent/human decision needs:

  • User has authorized merge-completion and cleanup after approved work. Proceeding to merge-completion unless merge conflict or post-merge validation fails.

Review: approve

Final merge-completion approval after merge to develop and post-merge validation.

Evidence:

  • Merged branch separate-ticket-record-language-from-worker-language with --no-ff.
  • Reviewer reviewer-ticket-record-language approved the branch-local implementation.
  • Post-merge validation passed: focused Ticket config/generated-text tests, focused role prompt/scaffold tests, cargo test -p client ticket_role --lib, cargo test -p ticket --lib, cargo check -p pod -p tui, cargo fmt --check, git diff --check, cargo run -q -p yoi -- ticket doctor, and nix build .#yoi.
  • Coder/reviewer Pods stopped and delegated scope reclaimed.
  • Merged worktree removed and branch deleted.

This approval is for the merged main-branch result, not merely the branch-local reviewer verdict.


State changed

Merged to develop, post-merge validation passed, final merge-completion approval recorded, and Ticket-language branch/worktree/Pods cleaned up.


Closed

Merged and completed the Ticket record language split.

Summary:

  • Added optional [ticket].language support to Ticket config, independent from worker.language and memory.language.
  • Set this repository's .yoi/ticket.config.toml to language = "Japanese" under [ticket].
  • Added scaffold support and validation for the new setting.
  • Propagated configured Ticket record language through Ticket CLI/backend construction, built-in Ticket feature backend construction, Panel backend construction, and Ticket role launch context/prompt guidance.
  • Added minimal generated-text support for configured Japanese on prominent generated Ticket record paths while preserving English/default behavior when absent or unsupported.
  • Existing Tickets were not bulk-translated or rewritten.

Merged branch/worktree:

  • Branch: separate-ticket-record-language-from-worker-language
  • Commit: fb261bb feat: add ticket record language config
  • Merge commit on develop: a74e315 merge: separate ticket record language

Validation passed after merge:

  • cargo test -p ticket config::tests --lib
  • cargo test -p ticket create_uses_configured_japanese_record_language_for_generated_defaults --lib
  • cargo test -p client configured_ticket_record_language_is_included_in_role_prompt --lib
  • cargo test -p yoi ticket_cli_init_writes_explicit_ticket_config_scaffold
  • cargo test -p client ticket_role --lib
  • cargo test -p ticket --lib
  • cargo check -p pod -p tui
  • cargo fmt --check
  • git diff --check
  • cargo run -q -p yoi -- ticket doctor
  • nix build .#yoi

Cleanup completed:

  • Stopped coder/reviewer Pods and reclaimed scope.
  • Removed .worktree/separate-ticket-record-language-from-worker-language.
  • Deleted branch separate-ticket-record-language-from-worker-language.

Residual notes:

  • This is not full localization infrastructure. Some generated Ticket-related messages may remain English unless separately localized later.
  • Japanese generation coverage is intentionally scoped to prominent configured record paths and role guidance.