Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

ticket: record cwd workspace followups

Browse Source
This commit is contained in:
Keisuke Hirata 2026-06-12 01:05:29 +09:00
parent 7eff9301b9
commit a111a91c83
No known key found for this signature in database
13 changed files with 528 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

171
.yoi/tickets/00001KTJXS31R/item.md
View File

@ -1,127 +1,120 @@
--- ---
title: "Prevent idle starvation in Ticket orchestration planning" title: "Orchestrator Idle 時の queued Ticket 見落としを防ぐ"
state: 'ready' state: 'ready'
created_at: "2026-06-08T06:12:35Z" created_at: "2026-06-08T06:12:35Z"
updated_at: '2026-06-09T11:35:29Z' updated_at: '2026-06-11T14:51:19Z'
--- ---
## Background ## 背景
The current Panel Queue automation mostly handles the transition-time event: 現在の Panel Queue automation は、主に次の遷移タイミングのイベントを扱っている。
```text ```text
ready -> queued ready -> queued
-> notify workspace Orchestrator -> workspace Orchestrator に通知
``` ```
That is not enough for robust orchestration. Queued Tickets can remain after missed notifications, Orchestrator restarts, planning returns, capacity limits, or multi-ticket coordination. The Orchestrator also needs a lightweight way to remember planned queued work across turns without relying only on session memory. これだけでは、安定した orchestration には足りない。通知漏れ、Orchestrator restore/spawn、planning への差し戻し、capacity 制限、複数 Ticket の調整などにより、`queued` Ticket が残り続けることがある。
There is an existing related Ticket: ただし、この Ticket は常時 polling する scheduler を作るものではない。目的は、実行可能な queued work があり、Orchestrator Pod の state が `Idle` で、`active_inprogress` が導出されていないときにだけ、bounded な work set を渡して starvation を防ぐことである。
- `ticket-orchestration-plan-tool` ## ゴール
That Ticket asks for a TaskStore-like surface for Ticket ordering/dependency/conflict/capacity/accepted-plan records. This Ticket folds that need together with queued-backlog re-kick semantics into a narrower operational requirement: Orchestrator が `queued` work を見落とさず、かつ `active_inprogress` が導出されている間に無駄な re-kick を繰り返さないための **session-lifetime work set discovery / re-kick policy** を実装する。
> If runnable queued work exists and the Orchestrator is otherwise idle, the system should not wait indefinitely for another user instruction. The Orchestrator should be kicked with a bounded work set so it can either incorporate new queued work into the plan or start the next planned queued Ticket. Orchestrator Pod の state が `Idle` で、進められる work が存在する場合は、bounded attention により次の inspection または acceptance/routing に進める。一方で、implementation side effects は必ず `queued -> inprogress` acceptance の記録後に限定し、blind spawn や duplicate start を起こさない。
This is starvation prevention and explicit work-set planning, not a constant background scheduler loop. runtime 側で kick 可能かを見る判定は、Orchestrator Pod の state が `Idle` であることに限定する。re-kick を抑制するかどうかは、session-lifetime work set、role/session claims、visible Pod/worktree state から `active_inprogress` の有無として導出する。
## Goal ## 現在の前提
Implement an Orchestrator attention/re-kick policy and planning store for active Ticket work: distinguish new queued work from planned queued work and accepted in-progress work, persist the plan, and kick the Orchestrator only when work can progress and no active Orchestrator-managed operation is already being waited on. - authoritative な Ticket lifecycle は frontmatter の `state` で表す。
- `new_queued` / `planned_queued` / `active_inprogress` は新しい core Ticket state ではなく、現在の Ticket `state`、session-lifetime work set、role/session claims、visible Pod/worktree state から導出する分類として扱う。
- work set は Task と同じく session-lifetime の runtime state として扱い、Ticket ごとの durable artifact log として積まない。
- work set が失われた場合でも、Ticket `state = queued` から `new_queued` として再検出できればよい。失われた session-level ordering / waiting reason は再 inspection で作り直す。
- Panel / lifecycle hook は Orchestrator に attention / kick を与えてよいが、unattended scheduler loop や常時 polling にはしない。
- `queued` は Orchestrator が routing / start-if-unblocked を検討できる状態であり、実装・Pod spawn・worktree 作成などの side effect は `queued -> inprogress` 記録後に限る。
## Planning model ## Work-set classification
The OrchestrationPlan store should distinguish at least: 実装上は少なくとも次の区別を導出できるようにする。
- `new_queued`: Tickets with `workflow_state = queued` that have not yet been incorporated into the OrchestrationPlan. - `new_queued`: Ticket `state = queued` だが、現在の Orchestrator session work set にまだ取り込まれていない Ticket。
- `planned_queued`: queued Tickets that the Orchestrator has considered and placed into an explicit plan/order/waiting set, but has not yet accepted as `inprogress`. - `planned_queued`: Orchestrator が確認し、session work set の order / waiting set に置いたが、まだ `inprogress` として acceptance していない queued Ticket。
- `inprogress`: Tickets accepted by the Orchestrator and currently awaiting worktree/coder/reviewer/planning-sync/merge/cleanup progress. - `active_inprogress`: Orchestrator が acceptance 済みで、coder/reviewer/planning-sync/merge/cleanup などの delegated step の完了待ちとして記録・観測できる Ticket。
- `actionable_inprogress`: `inprogress` だが、次の action が delegated step の完了待ちではなく、Orchestrator の routing/判断/記録を必要とする Ticket。
The names do not need to become final public API names, but the state distinction is required. この分類の名前は内部実装名として固定しなくてよいが、意味上の区別は必要である。
## Requirements ## 要件
### Active work set discovery / re-kick ### Work set discovery / re-kick
- Provide a mechanism to identify Tickets that need Orchestrator attention, including at least: - Orchestrator attention が必要な Ticket を、少なくとも次の情報から導出する。
- `workflow_state = queued` Tickets not yet present in the OrchestrationPlan (`new_queued`); - Ticket frontmatter の `state`。
- planned queued Tickets that are not blocked/capacity-limited and can be started when there is no active in-progress work; - Orchestrator session-lifetime work set。
- `workflow_state = inprogress` Tickets accepted by Orchestrator whose next action is not merely waiting for an active coder/reviewer/planning-sync/merge step; - role/session claims。
- queued Tickets left behind after Orchestrator restart, missed notification, or previous capacity stop. - visible Pod/worktree state。
- On Panel open/Orchestrator restore/spawn, or explicit user action, surface a bounded work list to the Orchestrator when there is actionable work. - Panel open、Orchestrator restore/spawn、明示的な user action などの境界で、actionable work がある場合に bounded work list を Orchestrator へ提示できるようにする。
- Avoid unbounded background polling. Prefer explicit events, Panel lifecycle kick, and explicit user/Orchestrator actions. - 無制限な background polling は避ける。明示イベント、Panel lifecycle kick、明示 user/Orchestrator action を優先する。
- Prevent duplicate starts: re-kick should prompt inspection/planning or acceptance of the next planned item, not blindly start coder Pods. - duplicate start を防ぐ。re-kick は inspection または次の planned item の acceptance を促すものであり、coder Pod を blind spawn しない。
### Re-kick / starvation-prevention semantics ### Re-kick / starvation-prevention semantics
- If `new_queued` work exists and the Orchestrator is idle/not occupied by an active in-progress operation, kick or notify the Orchestrator so it can incorporate those Tickets into the plan. - `new_queued` work が存在し、Orchestrator Pod の state が `Idle` の場合、Orchestrator に kick/notify して inspection と session work set への取り込みを促す。
- If no active `inprogress` work exists and runnable `planned_queued` work exists, kick or notify the Orchestrator so it can accept/start the next planned Ticket rather than waiting indefinitely for user instruction. - `active_inprogress` が導出されず、Orchestrator Pod の state が `Idle` で、unblocked かつ capacity/policy 上開始可能な `planned_queued` work がある場合、Orchestrator に kick/notify して次の Ticket の acceptance/routing に進める。
- If active `inprogress` work exists and the next expected event is coder/reviewer/planning-sync/merge completion, do not re-kick merely because queued/planned queued work also exists. - `active_inprogress` が導出されている場合、queued/planned queued work が存在するだけでは re-kick しない。
- If planned queued work is blocked, dependency-waiting, conflict-waiting, or capacity-limited, record the reason so the Panel/user can see why nothing starts. - `planned_queued` work を開始しない理由が dependency / conflict / dirty workspace / capacity / human gate 等で説明できる場合は、session work set 上の bounded waiting/blocking reason として保持する。
- A re-kick is an attention signal plus bounded context, not authority to bypass `queued -> inprogress` acceptance or spawn implementation Pods without inspection. - re-kick は attention signal と bounded context であり、`queued -> inprogress` acceptance や inspection を迂回する authority ではない。
### Orchestration plan record ### Session work set semantics
- Provide or define a TaskStore-like but Ticket-domain planning surface for Orchestrator use. Orchestrator は、意味のある routing 境界で session work set を更新する。
- The plan should be scoped to Ticket orchestration and support records such as:
- current active target set;
- state bucket: `new_queued` / `planned_queued` / `inprogress` or equivalent;
- ordering: Ticket A before Ticket B;
- dependency/blocker: A blocks B / B blocked by A;
- conflict: do not run A and B in parallel;
- capacity/waiting notes;
- accepted work plan: worktree/branch/coder/reviewer plan;
- current next action for each target.
- Distinguish durable project-relevant routing decisions from local runtime/session claims.
- Project-relevant decisions should live in Ticket records/thread/artifacts or a typed Ticket orchestration record under project authority.
- Local Pod/session claims remain in the local role session registry.
- Records should survive compaction and be queryable by Ticket id/slug and relation kind.
- Keep the first version lightweight; do not implement a full scheduler/graph solver.
### Plan update semantics - new queued work を確認し、session work set に取り込んだとき。
- `queued -> inprogress` acceptance を記録したとき。
- `inprogress` Ticket の次の action が delegated step 待ちか、Orchestrator action かを判断したとき。
- capacity stop により planned queued / waiting と reason を残すとき。
- merge-ready / done に到達し、`active_inprogress` が導出されなくなったため次の planned queued Ticket を検討するとき。
- The Orchestrator should update the plan at meaningful routing boundaries: session work set は bounded で、Orchestrator の現在 session における判断補助として扱う。
- new queued work incorporated into the plan;
- queued -> inprogress acceptance;
- inprogress -> blocked/waiting/planning/done;
- capacity stop -> leave planned queued/waiting with reason;
- merge-ready/done -> mark complete and consider the next planned queued Ticket if no active work remains.
- Each update should produce a bounded, inspectable record of:
- what was considered;
- what was incorporated into the plan;
- what was accepted/started;
- what was blocked/deferred/returned to planning;
- what remains planned queued/waiting.
- Re-kick should use the current plan/work set so the Orchestrator does not forget leftover queued Tickets between turns.
### Relationship to existing work - 何を取り込んだか。
- 次に acceptance / routing すべき候補は何か。
- 何を waiting としたか。
- waiting の理由は何か。
- `active_inprogress` として re-kick を抑制する対象は何か。
- This Ticket should either subsume or update `ticket-orchestration-plan-tool` so there is one coherent plan/re-kick design. これらは project-level の永続ログではなく、Task と同様に session lifetime の状態でよい。ユーザー判断や Ticket lifecycle に残すべき内容が生じた場合だけ、Ticket comment / state transition / resolution など既存の durable surface に記録する。
- It should coordinate with:
- `replace-intake-state-with-planning` as a prerequisite that defines the planning lane before this plan/re-kick layer builds on it;
- `panel-close-done-tickets` for done -> closed handling;
- local role session registry for active Pod/session ownership;
- direct/delegation authority work for actual child Pod spawning.
## Non-requirements ## 非目標
- Do not turn the Panel itself into the scheduler. - Panel 自体を scheduler にすること。
- Do not auto-start unqueued Tickets. - `queued` になっていない Ticket を自動開始すること。
- Do not re-kick continuously while active coder/reviewer/planning-sync/merge work is already in progress. - `active_inprogress` が導出されている間に継続的な re-kick を行うこと。
- Do not blindly spawn coder Pods from re-kick without Orchestrator inspection and `queued -> inprogress` acceptance. - Orchestrator の inspection と `queued -> inprogress` acceptance なしに coder/reviewer Pod を spawn すること。
- Do not implement a full dependency graph solver in the first version. - full dependency graph solver を最初の実装で作ること。
- `new_queued` / `planned_queued` / `active_inprogress` を core Ticket state として追加すること。
- volatile な orchestration work set を Ticket ごとの durable artifact log として保存すること。
## Acceptance criteria ## 受け入れ条件
- The system can distinguish new queued work, planned queued work, and accepted in-progress work. - Orchestrator Pod の state が `Idle` のとき、`new_queued` work を検出して bounded work-list attention または session work set への取り込みに進める。
- New queued Tickets are not left unnoticed while the Orchestrator is otherwise idle. - `active_inprogress` が導出されず、Orchestrator Pod の state が `Idle` で、`planned_queued` work が unblocked かつ capacity/policy 上開始可能なとき、Orchestrator が次の acceptance/routing を行える。
- Runnable planned queued Tickets are not left unstarted when there is no active in-progress work and capacity/policy allows progress. - `active_inprogress` が導出されている間は、queued/planned work の存在だけで re-kick しない。
- The system does not re-kick merely because queued/planned work exists while Orchestrator-managed in-progress work is waiting on coder/reviewer/planning-sync/merge completion. - 開始しない `planned_queued` work には、session work set 上でユーザーに提示できる bounded waiting/blocking reason が残る。
- Missed/stale queued Tickets can be surfaced to the Orchestrator without requiring the user to manually requeue each one. - 既存の human gate、`queued -> inprogress` acceptance step、dirty-workspace/dependency/conflict/capacity checks を迂回しない。
- The Orchestrator can record and query a lightweight Ticket orchestration plan covering active targets, order/dependency/conflict/capacity, state bucket, and next actions. - Ticket state、session work set、role/session claims、visible Pod/worktree state を確認し、duplicate Orchestrator/coder/reviewer/worktree start を起こさない。
- Plan records survive compaction and do not rely solely on session-lifetime TaskStore state. - missed/stale queued Tickets を、ユーザーが手で再 queue しなくても Orchestrator に提示できる。
- Re-kick/plan updates leave an auditable record of what was incorporated, started, blocked, returned to planning, or left waiting. - Orchestrator session work set を失っても、`queued` Ticket を再検出して安全に再 inspection できる。
- Duplicate implementation starts are prevented by consulting current Ticket state, local role/session claims, and plan records.
- Relevant workflows/prompts/docs are updated. ## 検証
- Focused tests, `target/debug/yoi ticket doctor`, `cargo fmt --check`, and `git diff --check` pass.
- `nix build .#yoi` を通す。
- Ticket / panel / orchestrator routing 周辺の既存テストまたは追加テストで、少なくとも次の主要分岐を確認する。
- Orchestrator Pod `Idle` state での queued detection。
- `active_inprogress` 導出時の re-kick suppression。
- session work set 上の waiting reason 保持。
- duplicate-start prevention。
- session work set が空でも `queued` Ticket から再検出できること。
- 実装報告では、work-set classification に使った情報と、implementation side effects が `queued -> inprogress` 後に限定されていることを明示する。

0
.yoi/tickets/00001KTVJFT6F/artifacts/.gitkeep Normal file
View File

81
.yoi/tickets/00001KTVJFT6F/item.md Normal file
View File

@ -0,0 +1,81 @@
---
title: 'Workspace panel の focus model を composer target と row selection に整理する'
state: 'ready'
created_at: '2026-06-11T14:48:26Z'
updated_at: '2026-06-11T14:48:31Z'
assignee: null
readiness: 'implementation_ready'
risk_flags: ['tui-ux', 'input-safety']
---
## Background
`yoi panel` の現行 focus 表示は `global composer` / `selected row` / `item action` の3状態だが、実際の操作モデルは composer 入力状態と selected row に強く依存している。
特に `item action focus` は Enter の挙動を実質的に変えないため、ユーザーには「focus が移った」ように見える一方で、何が変わったのか分かりづらい。Panel の主な操作対象は composer target と selected row であり、focus 概念がそれ以上に増えることで UX が不明瞭になっている。
関連する broad design Ticket として `00001KSKBPPMR`「TUI: navigation mode / block focus の設計」があるが、本 Ticket は `yoi panel` の現行 focus UX を具体的に整理する実装単位とする。
## Requirements
- `yoi panel` の user-visible focus model を縮小し、composer target と row selection を中心に整理する。
- composer target は focus ではなく、送信先表示として扱う。
- selected row は、composer が空のときの navigation / Enter 対象として扱う。
- `item action focus` は廃止するか、少なくとも user-visible focus として表示しない。
- `Right action focus` / `Left` の段階的 focus 移動は、必要性を再評価して簡略化する。
- status line / actionbar / key hints が、実際の Enter・矢印・Esc・Tab の挙動と一致するようにする。
- composer に入力済みのテキストを誤って壊したり、暗黙に row action へ送ったりしない。
- Ticket action / Pod open / Companion composer / Ticket Intake target の既存 authority と明示操作は維持する。
- single-Pod TUI の transcript / block navigation はこの Ticket では扱わない。
## Acceptance criteria
- Panel 上で composer target と selected row の意味が分かりやすく表示される。
- `global composer` / `selected row` / `item action` のような user-visible focus 表示が、実際の操作以上に状態を増やして見せない。
- 空 composer と非空 composer で Enter が何をするか、actionbar/status から誤解しにくい。
- `↑/↓`, `Left`, `Right`, `Esc`, `Tab`, `Enter` の key hints が実装と一致している。
- `Right action focus` が残る場合は user-visible focus ではなく、実際に意味のある操作として説明される。不要なら削除・無効化される。
- composer 入力保護が維持される。
- 既存の Ticket action dispatch / Pod open / Intake launch / Companion send の安全性を落とさない。
## Binding decisions / invariants
- `yoi panel` の改善に限定する。
- 通常の single-Pod TUI transcript / block focus navigation は範囲外。
- composer に文字が入っている状態では、通常入力を最優先で保護する。
- composer target は focus ではなく送信先である。
- row selection は、空 composer 時の navigation / Enter 対象である。
- `item action focus` を user-visible focus model から外す。
- Panel は durable state authority にならず、既存の Ticket / Pod authority を維持する。
- Ticket の `ready -> queued` などの明示 user action semantics は変更しない。
## Implementation latitude
- `PanelFocus` の状態名・数・遷移は変更してよい。
- `ItemAction` 相当の状態は削除してよい。
- `Right` / `Left` の扱いは、実装後の単純な model に合わせて削除・no-op・案内表示のいずれかにしてよい。
- `Esc` の詳細挙動は input safety を満たす範囲で調整してよい。
- status line / actionbar / row hints の文言は、実装後の挙動に合わせて整理してよい。
- UX 改善は最小実装でよく、フル navigation mode や vim-like 操作体系は不要。
## Readiness
- readiness: implementation_ready
- risk_flags: [tui-ux, input-safety]
## Escalation conditions
- composer 入力保護と row navigation のどちらを優先するかについて、現行 invariant を超える判断が必要になった場合。
- Ticket lifecycle action の明示性や authority boundary を変える必要が出た場合。
- Panel だけでなく single-Pod TUI の navigation model 変更が必要だと判明した場合。
## Validation
- `crates/tui/src/multi_pod.rs` 周辺の focused tests を追加・更新する。
- focus/key handling/status/actionbar の unit tests を通す。
- `cargo test -p tui multi_` またはより focused な同等テストを通す。
- TUI 変更なので完了時に `nix build .#yoi` も確認する。
## Related work
- `00001KSKBPPMR` — TUI: navigation mode / block focus の設計

23
.yoi/tickets/00001KTVJFT6F/thread.md Normal file
View File

@ -0,0 +1,23 @@
<!-- event: create author: LocalTicketBackend at: 2026-06-11T14:48:26Z -->
## 作成
LocalTicketBackend によって作成されました。
---
<!-- event: intake_summary author: intake at: 2026-06-11T14:48:31Z -->
## Intake summary
Panel focus UX の不満を `yoi panel` 専用の concrete Ticket として整理した。合意済み方針は、user-visible focus model を増やさず、composer target を送信先、selected row を空 composer 時の navigation / Enter 対象として扱い、`item action focus` を user-visible focus から外すこと。既存 Ticket / Pod authority と composer 入力保護は維持する。
---
<!-- event: state_changed author: intake at: 2026-06-11T14:48:31Z from: planning to: ready reason: intake_ready field: state -->
## State changed
Intake clarified the panel focus request and recorded an implementation-ready concrete Ticket. Human can queue it from the panel when ready.
---

0
.yoi/tickets/00001KTVJGC0Y/artifacts/.gitkeep Normal file
View File

82
.yoi/tickets/00001KTVJGC0Y/item.md Normal file
View File

@ -0,0 +1,82 @@
---
title: 'Ticket language guidance must apply to all Ticket tool users'
state: 'ready'
created_at: '2026-06-11T14:48:44Z'
updated_at: '2026-06-11T14:48:50Z'
assignee: null
readiness: 'implementation_ready'
risk_flags: ['prompt-context', 'tool-description', 'feature-boundary', 'ticket-language', 'companion']
---
## Background
`ticket.language` は durable Ticket record の言語設定であり、Ticket を書くすべての Pod に適用されるべき情報である。
現状の実装では、Ticket record language guidance が主に Ticket role launch prompt に入っている。しかし Companion など Ticket role ではない Pod も Ticket tools を受け取り、Ticket の `item.md` / `thread.md` / `resolution.md` や Ticket tool body を書く可能性がある。
そのため、Ticket record language guidance を Ticket role 専用の launch prompt に置くだけでは不十分である。
## Requirements
- Ticket-writing tools を使える Pod には、Ticket role かどうかに関係なく、configured `ticket.language` に従って durable Ticket record / Ticket tool body を書く guidance が model-visible になること。
- Companion など non-Ticket-role Pod が Ticket tools を扱う場合にも同じ guidance が届くこと。
- 既存の言語境界を維持すること。
- `worker.language`: 通常の会話 prose。
- `memory.language`: memory / Knowledge generation。
- `ticket.language`: durable Ticket records / Ticket tool bodies。
- `ticket.language` が設定されていても、protocol literals、file paths、commands、logs、identifiers、quoted external text は不要に翻訳しないこと。
- prompt-context principle を守ること。モデルの挙動根拠が history / prompt / tool surface に残らない hidden context-only injection を作らないこと。
- Ticket role prompt だけを唯一の伝達経路にしないこと。
## Acceptance criteria
- Ticket tools を持つ non-Ticket-role Pod、特に Companion-style context でも、Ticket tool bodies を configured `ticket.language` で書く guidance が model-visible になる。
- Ticket role Pods でも同等の guidance が引き続き届き、既存挙動が退行しない。
- guidance の source は universal な Ticket capability / tool surface、または feature-scoped system prompt path に置かれ、Ticket role launch prompt 専用ではない。
- `worker.language` が `ticket.language` を override しない。
- 既存 Ticket records は翻訳・一括 rewrite しない。
- focused test または snapshot-style verification で、Ticket role と generic / Companion-style Ticket-capable context の両方に guidance が届くことを確認する。
- runtime prompt / tool behavior に関わるため、完了前に `nix build .#yoi` を通す。
## Binding decisions / invariants
- `ticket.language` は Ticket record writing の policy であり、Ticket role 固有の policy ではない。
- Companion や他の non-role Pods が、conversation language から Ticket record language を推測する状態にしてはならない。
- `worker.language` / `memory.language` / `ticket.language` の責務を混同しない。
- hidden context-only language injection を実装しない。
## Implementation latitude
実装方式は coder がよりきれいな architecture を選んでよい。
候補:
- `ticket.language` が設定されている場合に Ticket tool descriptions / schema text へ language instruction を入れる。
- Ticket capability / feature が有効な Pod に対して、feature-scoped system prompt guidance を追加する。
どちらの場合も、guidance は Ticket tools を扱うすべての model context に durable / model-visible な形で届く必要がある。
## Readiness
- readiness: implementation_ready
- risk_flags: [prompt-context, tool-description, feature-boundary, ticket-language, companion]
## Escalation conditions
- Tool descriptions が現在の構造では configured Ticket language に依存できず、広い ToolRegistry redesign が必要になる場合。
- feature-scoped prompt guidance が history に残らない context mutation を必要とする場合。
- Companion の Ticket capability path から Ticket config にアクセスできない場合。
- 提案実装が Ticket record language と worker response language を混同する場合。
## Validation
- Ticket role prompt / context の focused test。
- generic / Companion-style Ticket-capable context の guidance を確認する focused test または snapshot-style test。
- relevant focused `cargo test`。
- `cargo fmt --check`。
- `git diff --check`。
- `nix build .#yoi`。
## Related work
- `00001KTJMDWTR` — Separate Ticket record language from worker response language

23
.yoi/tickets/00001KTVJGC0Y/thread.md Normal file
View File

@ -0,0 +1,23 @@
<!-- event: create author: LocalTicketBackend at: 2026-06-11T14:48:44Z -->
## 作成
LocalTicketBackend によって作成されました。
---
<!-- event: intake_summary author: intake at: 2026-06-11T14:48:50Z -->
## Intake summary
`ticket.language` guidance が Ticket role launch prompt に偏っており、Companion など non-Ticket-role Pod が Ticket tools を使う場合に durable Ticket record / Ticket tool body の言語指示が届かない問題を concrete implementation Ticket として整理した。要件は、Ticket role に依存せず universal Ticket capability / tool surface または feature-scoped system prompt path から model-visible guidance を届けること。
---
<!-- event: state_changed author: intake at: 2026-06-11T14:48:50Z from: planning to: ready reason: planning_ready field: state -->
## State changed
要件・受け入れ条件・binding decisions・実装余地・escalation conditions・validation が揃っているため、Orchestrator routing 可能な ready Ticket とする。
---

0
.yoi/tickets/00001KTVNQKRP/artifacts/.gitkeep Normal file
View File

36
.yoi/tickets/00001KTVNQKRP/item.md Normal file
View File

@ -0,0 +1,36 @@
---
title: 'runtime workspace と process cwd を分離する'
state: 'done'
created_at: '2026-06-11T15:45:07Z'
updated_at: '2026-06-11T15:59:55Z'
assignee: null
queued_by: 'yoi ticket'
queued_at: '2026-06-11T15:45:53Z'
---
## 背景
Ticket role Pod、とくに workspace Orchestrator は、runtime workspace として original workspace を使い続けながら、Bash / file tool の default cwd だけ dedicated orchestration worktree にしたい。
直前の調査で `--workspace` を dedicated worktree に寄せたり、`--tool-cwd` のような追加 CLI surface を作る方向は不適切だと確認した。`--workspace` は runtime workspace / project context の基準であり、process cwd は通常の current directory として扱えばよい。
また、コード内で `pwd` と `cwd` に明確な意味差がない箇所は `cwd` に統一し、用語混乱を減らす。
## 要件
- `--workspace` は runtime workspace / project context の基準として維持する。
- process current directory は Pod の tool default cwd として起動時に snapshot する。
- Ticket role Orchestrator は `--workspace = original workspace` のまま、process cwd を dedicated orchestration worktree にして起動・restore される。
- `--tool-cwd` のような追加 CLI surface は作らない。
- `SpawnConfig` など host-side launch config で必要なら `cwd` を内部値として持ち、child process の `Command::current_dir` にだけ使う。
- `pwd` と `cwd` に意図的な意味差がない runtime field / helper / local 変数は `cwd` に統一する。
- cwd は authority ではないため、scope / delegation / workspace identity の基準として扱わない。
## 受け入れ条件
- Orchestrator role launch/restore が original workspace を runtime workspace として使い、dedicated orchestration worktree を process cwd として使う。
- child Pod へ `.worktree` 配下を delegate できる authority は original workspace profile/scope に基づいて評価される。
- `--tool-cwd` などの新しい CLI argument が残らない。
- `pwd` / `cwd` の命名が混在していた主要 runtime path は `cwd` に統一される。
- 既存の `SpawnPod.cwd` semantics は「child process cwd を指定する」で維持され、runtime workspace を変更しない。
- `nix build .#yoi` が通る。

84
.yoi/tickets/00001KTVNQKRP/thread.md Normal file
View File

@ -0,0 +1,84 @@
<!-- event: create author: "yoi ticket" at: 2026-06-11T15:45:07Z -->
## 作成
LocalTicketBackend によって作成されました。
---
<!-- event: intake_summary author: hare at: 2026-06-11T15:45:52Z -->
## Intake summary
Marked ready by `yoi ticket state`.
---
<!-- event: state_changed author: "yoi ticket" at: 2026-06-11T15:45:52Z from: planning to: ready reason: cli_state field: state -->
## State changed
Marked ready by `yoi ticket state`.
---
<!-- event: state_changed author: "yoi ticket" at: 2026-06-11T15:45:53Z from: ready to: queued reason: queued field: state -->
## State changed
Ticket を `yoi ticket` が queued にしました。
---
<!-- event: state_changed author: "yoi ticket" at: 2026-06-11T15:45:53Z from: queued to: inprogress reason: cli_state field: state -->
## State changed
State changed to `inprogress`.
---
<!-- event: implementation_report author: hare at: 2026-06-11T15:59:55Z -->
## Implementation report
runtime workspace と process cwd を分離する実装を行った。
- `--workspace` は runtime workspace / project context の基準として維持し、child process の current directory とは分離した。
- `SpawnConfig` / Ticket role launch plan は内部値として `cwd` を持ち、CLI argument にはせず `Command::current_dir` にのみ使うようにした。
- Panel Orchestrator launch/restore は `workspace_root = original workspace`、`cwd = dedicated orchestration worktree` として起動する。
- `SpawnPod.cwd` は child process cwd 指定として扱い、`--workspace` は spawner の runtime workspace を渡すままにした。
- Pod entrypoint は process cwd を起動時に snapshot し、workspace root とは別に Pod construction へ渡す。`--tool-cwd` は作らない。
- `pwd` と `cwd` の意図的な意味差がない主要 runtime path は `cwd` に統一した。
- metadata snapshot restore では、現在の launch manifest の scope/delegation scope を復元後 manifest に反映できるようにした。
検証:
- `cargo check`
- `cargo test -p client`
- `cargo test -p pod entrypoint::tests:: -- --nocapture`
- `cargo test -p pod spawn_pod_launches_runtime_in_workspace_and_process_cwd -- --nocapture`
- `cargo test -p pod spawn_pod_omitted_cwd_preserves_spawner_cwd -- --nocapture`
- `cargo fmt --check`
- `git diff --check`
- `yoi ticket doctor`
- `nix build .#yoi`
補足:
- `cargo test -p tools` は doctest の既存不整合 (`core_builtin_tools` の引数数) で失敗したため、この実装の検証対象からは外した。通常 unit/integration tests は通っている。
---
<!-- event: state_changed author: "yoi ticket" at: 2026-06-11T15:59:55Z from: inprogress to: done reason: cli_state field: state -->
## State changed
State changed to `done`.
---

0
.yoi/tickets/00001KTVPS6K3/artifacts/.gitkeep Normal file
View File

94
.yoi/tickets/00001KTVPS6K3/item.md Normal file
View File

@ -0,0 +1,94 @@
---
title: 'Ticket role launch inputを短縮し、role behaviorをInstruction/Workflowへ分離する'
state: 'ready'
created_at: '2026-06-11T16:03:28Z'
updated_at: '2026-06-11T16:03:33Z'
assignee: null
risk_flags: ['prompt-context', 'workflow-boundary', 'role-launch']
---
## Background
Ticket role Pod launch 時の初回 user message に、role の振る舞いや手順説明が長く含まれている。これを整理し、model-visible な情報の所管を明確にする。
合意済みの分類:
- Instruction: role behavior、恒常的な環境情報、language、workspace_root / cwd など Pod の動作に必要な環境情報。
- Workflow: 手続き、手順、routing / implementation / review / close の flow。
- Submit: 対象 Ticket 指定、ユーザー入力または system-generated action instruction、今回の操作対象として明示する path / worktree / branch / validation / report expectations。
- Control-plane only: profile selector、workflow slug、launch_prompt ref、pod name など。原則として初回 user message には出さない。
関連する既存 Ticket:
- `00001KTRKZ14C`: Project workflowsをpublic builtinとdogfood運用に分離する。closed。
- `00001KTGFMW70`: Builtin Workflow and Knowledge resources。closed。
- `00001KTR6YVDB`: LLM向けプロンプト直書きを廃止してresources/promptsへ集約する。closed。
## Requirements
- Ticket role launch の generated first-run user message から、role behavior / procedural guidance / launch metadata の長文説明を削除する。
- `Profile selector`、`Workflow`、`Configured launch_prompt ref` のような control-plane metadata は、初回 user message に含めない。
- role としての振る舞いは builtin role Profile が選ぶ `worker.instruction` に移す。
- 手続き・手順は Workflow に置く。
- Submit に残す情報は、対象 Ticket id、ユーザー入力または launcher-generated action instruction、今回の操作対象として必要な per-launch context に限定する。
- `language` は Instruction の環境情報として扱う。
- `workspace_root` / `cwd` は Instruction/system 側の環境情報として扱う。ただし Git 操作や worktree 操作の対象として明示が必要な path は、重複しても Submit に書いてよい。
- `resources/prompts/ticket_role/*.md` に残っている role-specific 長文 fragment を削除、縮小、または Instruction/Workflow 側へ移す。
- `TicketRoleLaunchContext.user_instruction` は実態に合わせ、必要なら `action_instruction` / `launch_instruction` などへ rename する。user-authored text と launcher-generated instruction が混ざっていることを表現できる名前にする。
- 既存の workflow invocation、workspace/user prompt override、Ticket role launch、Panel Intake / Orchestrator launch の動作を壊さない。
## Acceptance criteria
- Ticket role launch の first-run `Segment::Text` が短くなり、対象 Ticket / action instruction / per-launch context だけを含む。
- role behavior は builtin role instruction prompt から供給される。
- procedural guidance は Workflow に残る、または Workflow に移されている。
- control-plane metadata は prompt text ではなく launch plan / diagnostics / trace に留まる。
- Ticket record language guidance は初回 user message ではなく Instruction 側の環境情報として扱われる。
- Orchestrator launch で必要な workspace/cwd/topology 情報は、Pod 環境情報と per-operation Submit 情報に分離され、Git/worktree 操作対象として必要なものは Submit 内で明示される。
- 関連する unit tests が新しい出力方針を検証している。
- `nix build .#yoi` が通る。
## Binding decisions / invariants
- Instruction: 振る舞い、恒常的な環境情報。
- Workflow: 手続き、手順。
- Submit: 対象チケットの指定、ユーザー入力または system-generated action instruction、今回の操作対象。
- `workflow slug` と `profile selector` は初回 user message には不要。
- `language` は Instruction 所管。
- `workspace_root` / `cwd` は Instruction/system 側に置く。ただし今回の Git/worktree 操作対象として必要な path は Submit に重複記載してよい。
- Ticket config に role-level `system_instruction` / `instruction` field は追加しない。builtin role Profile が `worker.instruction` を選ぶ。
- launch context template 化は行わない。過剰なテンプレート化ではなく、Rust 側の短い Submit 組み立てに留める。
## Implementation latitude
- builtin role instruction prompt のファイル名・配置は実装者が既存 prompt resource conventions に合わせて決めてよい。
- `resources/prompts/ticket_role` の既存 fragment は、不要なら削除してよい。
- `user_instruction` rename は、変更範囲が大きすぎる場合は別名追加や段階的移行でもよい。ただし model-visible label は `User/action instruction` より正確な名前にする。
- Workflow 側に移す文言は public builtin workflow と workspace dogfood workflow の責務差を保つ。
## Readiness
- readiness: implementation_ready
- risk_flags: [prompt-context, workflow-boundary, role-launch]
## Escalation conditions
- Instruction / Workflow / Submit の境界に収まらない新しい model-visible 情報が見つかった場合は、実装前に判断を戻す。
- Ticket role launch の dynamic data を Instruction minijinja context に入れたくなる場合は、処理対象データを system prompt に入れていないか確認して判断を戻す。
- Ticket config schema に新しい instruction field を追加したくなる場合は判断を戻す。
## Validation
- Ticket role launch prompt 出力を検証する unit tests。
- builtin role Profile が instruction prompt を解決できることの検証。
- relevant cargo tests。
- `nix build .#yoi`。
## Related work
- `resources/prompts/ticket_role/*.md`
- `resources/profiles/{intake,orchestrator,coder,reviewer}.lua`
- `resources/workflows/*`
- `.yoi/workflow/*`
- `crates/client/src/ticket_role.rs`
- `crates/pod/src/prompt/system.rs`

23
.yoi/tickets/00001KTVPS6K3/thread.md Normal file
View File

@ -0,0 +1,23 @@
<!-- event: create author: LocalTicketBackend at: 2026-06-11T16:03:28Z -->
## 作成
LocalTicketBackend によって作成されました。
---
<!-- event: intake_summary author: intake at: 2026-06-11T16:03:33Z -->
## Intake summary
Ticket role launch の初回 user message を短縮し、情報所管を Instruction / Workflow / Submit / control-plane に分離する方針で合意済み。language と workspace_root/cwd は Instruction 側の環境情報、Git/worktree 操作対象として必要な path は Submit に重複記載可。workflow slug/profile selector は初回 user message に含めない。
---
<!-- event: state_changed author: intake at: 2026-06-11T16:03:33Z from: planning to: ready reason: planning_ready field: state -->
## State changed
要件・受け入れ条件・境界判断が揃ったため、Orchestrator routing 可能。実装はユーザーが panel で queue した後に開始する。
---