Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity
a987250cd3
yoi/.yoi/tickets/open/20260608-032911-separate-ticket-record-language-from-worker-language/thread.md

13 KiB
Raw Blame History

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.