From 149497b823a16f3e8afeb24625fda1b44af04635 Mon Sep 17 00:00:00 2001 From: Hare Date: Thu, 16 Jul 2026 07:34:24 +0900 Subject: [PATCH] objective: align memory records with skills direction --- .yoi/objectives/00001KTR7MZWH/item.md | 24 ++++++------- .yoi/objectives/00001KVJPT2PP/item.md | 49 ++++++++++++++------------- .yoi/objectives/00001KVJSMQXZ/item.md | 28 +++++++-------- 3 files changed, 51 insertions(+), 50 deletions(-) diff --git a/.yoi/objectives/00001KTR7MZWH/item.md b/.yoi/objectives/00001KTR7MZWH/item.md index 5231446b..19abb4e8 100644 --- a/.yoi/objectives/00001KTR7MZWH/item.md +++ b/.yoi/objectives/00001KTR7MZWH/item.md @@ -2,15 +2,15 @@ title: "ネイティブGUIアプリケーション" state: "active" created_at: "2026-06-10T07:41:18Z" -updated_at: "2026-06-10T07:41:18Z" +updated_at: "2026-07-15T21:18:00Z" linked_tickets: [] --- ## Goal -Yoi の Pod / Ticket / Orchestrator / workflow 操作を、TUI だけでなくネイティブ GUI から扱えるようにする。 +Yoi の Pod / Ticket / Orchestrator / Skill・prompt resource 操作を、TUI だけでなくネイティブ GUI から扱えるようにする。 -最初の到達点は、既存の runtime / Ticket backend / Pod protocol / Profile / workflow authority を再実装せずに、workspace の状態を視覚的に把握し、選択した Pod・Ticket・role action に対して安全に操作できる desktop GUI client を持つこと。GUI は core authority ではなく client surface とし、既存 CLI/TUI と同じ durable state・同じ protocol・同じ permission/prompt/workflow 境界を使う。 +最初の到達点は、既存の runtime / Ticket backend / Pod protocol / Profile / Skill/prompt resource authority を再実装せずに、workspace の状態を視覚的に把握し、選択した Pod・Ticket・role action に対して安全に操作できる desktop GUI client を持つこと。GUI は core authority ではなく client surface とし、既存 CLI/TUI と同じ durable state・同じ protocol・同じ permission/prompt/resource 境界を使う。 ## Motivation / background @@ -24,12 +24,12 @@ Yoi の Pod / Ticket / Orchestrator / workflow 操作を、TUI だけでなく - long-running orchestration の通知、状態変化、失敗診断の視覚化。 - 将来的な review / merge-ready dossier / plan board / settings editor の専用 UI。 -一方で、GUI を理由に runtime authority を分散させたり、Ticket/Pod state を独自 DB として二重管理したり、prompt/workflow 文字列を GUI code に直書きしたりしてはいけない。 +一方で、GUI を理由に runtime authority を分散させたり、Ticket/Pod state を独自 DB として二重管理したり、prompt/resource 文字列を GUI code に直書きしたりしてはいけない。 ## Strategy / design direction - GUI は Yoi core の上に乗る client として作る。 - - Pod lifecycle、session/history、Ticket storage、Profile resolution、workflow/prompt authority は既存 core を正とする。 + - Pod lifecycle、session/history、Ticket storage、Profile resolution、resource/prompt authority は既存 core を正とする。 - GUI 固有 state は selection、layout、local UI preference などに限定する。 - 最初に toolkit / architecture の小さな spike を置く。 - 評価軸は Rust code reuse、async/runtime 統合、native packaging、Linux dogfooding しやすさ、testability、accessibility、long-running log/output 表示、将来の cross-platform 余地。 @@ -41,10 +41,10 @@ Yoi の Pod / Ticket / Orchestrator / workflow 操作を、TUI だけでなく 4. Ticket body/thread/artifacts、Pod output、validation evidence、review report を閲覧しやすくする。 5. 必要に応じて settings/profile/config editor や merge-ready dossier UI を追加する。 - TUI は廃止前提にしない。 - - GUI 導入後も CLI/TUI は fallback / automation / terminal-first workflow として維持する。 + - GUI 導入後も CLI/TUI は fallback / automation / terminal-first operation flow として維持する。 - GUI で見つかった state model の改善は、TUI と共有できる pure data model / client API に寄せる。 -- Prompt / workflow / role guidance は GUI code に直書きしない。 - - LLM-facing prompt は `resources/prompts` または `.yoi/workflow` / configured resources を正とする。 +- Prompt / resource / role guidance は GUI code に直書きしない。 + - LLM-facing prompt は `resources/prompts` または `.yoi/skills` / configured resources を正とする。 - GUI は prompt 文言を所有せず、選択・起動・runtime context の入力面を担当する。 - Security / privacy / authority boundary を保つ。 - secret-like data は UI diagnostics / logs / model context に漏らさない。 @@ -57,17 +57,17 @@ Yoi の Pod / Ticket / Orchestrator / workflow 操作を、TUI だけでなく - GUI は既存 workspace config、Profile、Ticket backend、Pod registry/protocol を使い、独自の authority store を持たない。 - 最小 dashboard で live/stored Pod、Ticket lane/state、Orchestrator/role session の概況を確認できる。 - GUI から少なくとも attach/restore/open 相当の安全な Pod 操作ができる。 -- GUI から Ticket Intake または既存 role launcher を使った role action を実行でき、既存の prompt/workflow/resource 境界を壊さない。 +- GUI から Ticket Intake または既存 role launcher を使った role action を実行でき、既存の prompt/resource 境界を壊さない。 - Pod output / Ticket body/thread/artifacts を、TUI より見通しよく閲覧できる最小 UI がある。 - GUI 固有 state と core durable state の境界が文書化されている。 - toolkit / architecture 選定理由、採用しなかった選択肢、packaging 方針が Ticket artifact または design note として残っている。 - GUI で使う state transformation / action eligibility は pure model として test 可能で、主要な selection/action state の unit test がある。 -- GUI 実装は CLI/TUI の既存 workflow を破壊せず、必要な targeted validation が定義されている。 +- GUI 実装は CLI/TUI の既存 operation flow を破壊せず、必要な targeted validation が定義されている。 ## Decision context - この Objective は中長期の方向性・判断軸を保持する。具体的な toolkit 選定、crate 構成、初期 dashboard 実装、role action 実装、packaging は個別 Ticket に分ける。 - GUI は TUI の単純な置換ではなく、複数 Pod / Ticket / Orchestrator を扱う workspace cockpit として設計する。 -- authority は既存 core に残す。GUI は client/view/controller surface であり、Pod/Ticket/workflow/prompt の正本を所有しない。 -- Prompt 直書き禁止方針を守る。GUI 実装中に LLM-facing 文言が必要になった場合は、`resources/prompts` または workflow/resource 側に置く。 +- authority は既存 core に残す。GUI は client/view/controller surface であり、Pod/Ticket/resource/prompt の正本を所有しない。 +- Prompt 直書き禁止方針を守る。GUI 実装中に LLM-facing 文言が必要になった場合は、`resources/prompts` または Skill/resource 側に置く。 - 初期 target は dogfooding しやすい desktop GUI とし、public release / cross-platform polish / installer は後続段階で扱う。 diff --git a/.yoi/objectives/00001KVJPT2PP/item.md b/.yoi/objectives/00001KVJPT2PP/item.md index a6693aa8..13724bb8 100644 --- a/.yoi/objectives/00001KVJPT2PP/item.md +++ b/.yoi/objectives/00001KVJPT2PP/item.md @@ -2,7 +2,7 @@ title: "Team workspace control plane and runtime architecture" state: "active" created_at: "2026-06-20T14:26:29Z" -updated_at: "2026-07-07T12:40:00Z" +updated_at: "2026-07-15T21:18:00Z" linked_tickets: ["00001KVMFFYVX", "00001KWMBAA6V"] --- @@ -10,15 +10,15 @@ linked_tickets: ["00001KVMFFYVX", "00001KWMBAA6V"] Yoi を、単一のローカル開発ディレクトリで動くエージェント実行ツールから、チームで作業・判断・実行結果を管理できるワークスペース基盤へ発展させる。 -この Objective の中心は、Web から扱える管理システムを作り、その管理システムにローカル Runtime・リモート Runtime・将来のクラウド Runtime を接続できるようにすることである。管理システムは Ticket、Objective、Memory、Knowledge、Artifact、Policy、Actor、Repository、Runtime state の正本を持つ。Runtime はその管理システムから Worker launch request / config bundle / repository target / authority を受け取り、作業環境を用意して Worker を実行し、結果・イベント・証跡を返す。 +この Objective の中心は、Web から扱える管理システムを作り、その管理システムにローカル Runtime・リモート Runtime・将来のクラウド Runtime を接続できるようにすることである。管理システムは Ticket、Objective、Memory、Skill catalog、Artifact、Policy、Actor、Repository、Runtime state の正本を持つ。Runtime はその管理システムから Worker launch request / config bundle / repository target / authority を受け取り、作業環境を用意して Worker を実行し、結果・イベント・証跡を返す。 -この Objective は Git ホスティングサービスを作るものではない。Git は重要な Repository provider として扱うが、Yoi の Workspace は Git Repository root と同じものにしない。Yoi が作るべきものは、コード・ドキュメント・データ・成果物などの Repository と Runtime を接続しながら、人間とエージェントの作業、Ticket lifecycle、Memory/Knowledge、検証証跡、実行環境配置を管理するチームワークスペースである。 +この Objective は Git ホスティングサービスを作るものではない。Git は重要な Repository provider として扱うが、Yoi の Workspace は Git Repository root と同じものにしない。Yoi が作るべきものは、コード・ドキュメント・データ・成果物などの Repository と Runtime を接続しながら、人間とエージェントの作業、Ticket lifecycle、Memory、Skill catalog、検証証跡、実行環境配置を管理するチームワークスペースである。 ## Glossary この Objective では、以下の語をこの意味で使う。 -- Workspace: チームまたはプロジェクトの管理単位。Ticket、Objective、Memory、Knowledge、Artifact、Policy、Actor、Repository、Runtime state を持つ。Git Repository root ではない。 +- Workspace: チームまたはプロジェクトの管理単位。Ticket、Objective、Memory、Skill catalog、Artifact、Policy、Actor、Repository、Runtime state を持つ。Git Repository root ではない。 - Control plane: Workspace の正本を持ち、Web UI / API / CLI から操作される管理システム。 - Runtime: Worker 群を束ねる実行基盤。Worker lifecycle、sandbox、mount、cache、checkout/worktree/container filesystem などの working directory materialization、event/control plane を管理する。将来的には 1 つの Runtime が複数 Workspace / Repository の Worker を抱えられる。 - Worker: Runtime が管理する 1 つの agent/session/process。Runtime が用意した working directory と authority の中で動く。 @@ -32,7 +32,7 @@ Yoi を、単一のローカル開発ディレクトリで動くエージェン - Objective: 複数の Ticket を束ねる長期目標や設計方針。 - Artifact: Ticket や Worker 実行に紐づく成果物や証跡。diff、log、validation result、review result、report など。 - Memory: エージェントやユーザーが再利用するための要約された文脈。Ticket や Artifact の正本ではない。 -- Knowledge: 保守された知識や設計判断。Memory より人間が維持する資料に近い。 +- Skill catalog: `.yoi/skills` / builtin skills から Workspace backend が解決する procedural guidance catalog。外部状態 authority は持たず、Ticket / Worker / workdir などの操作は typed feature/tool surface が担う。 - Actor: 人間、エージェント、システム、外部サービスなど、Workspace 上で操作や発言を行う主体。 ## Motivation / background @@ -44,7 +44,7 @@ Yoi を、単一のローカル開発ディレクトリで動くエージェン - Ticket をローカル作業メモではなく、チームの作業調整 record にする。 - 実行証跡は Ticket thread、Artifact、WorkerRef snapshot、Runtime event として扱い、独立した実行単位概念を先に増やさない。 - 管理システムと Runtime を分ける。 -- まず Web から Ticket、Objective、Memory、Knowledge、Artifact、Runtime / Worker state を見られるようにする。 +- まず Web から Ticket、Objective、Memory、Skill catalog、Artifact、Runtime / Worker state を見られるようにする。 - 最初はローカル Runtime を使い、後でリモート Runtime、クラウド Runtime、runtime pool、resource allocation、quota、billing、sandboxing に拡張する。 - Git ホスティング機能を取り込むのではなく、Git Repository / worktree / clone は Repository provider と working directory materialization の手段として扱う。 @@ -56,7 +56,7 @@ OSS として Control plane、Runtime、Web frontend、protocol を公開しつ Team Workspace の正本は server-side control plane に置く。`.yoi` は local backend、single-user/self-hosted compatibility、offline/export/import、local projection、migration bridge として残せるが、multi-user SaaS の正本とはみなさない。 -Control plane は Ticket、Objective、Memory、Knowledge、Artifact、Actor、Permission、Audit、Repository、Runtime / Worker state を管理する。Web UI、CLI、TUI、将来の desktop client は、この Control plane を操作する client であり、別の正本 store を持たない。 +Control plane は Ticket、Objective、Memory、Skill catalog、Artifact、Actor、Permission、Audit、Repository、Runtime / Worker state を管理する。Web UI、CLI、TUI、将来の desktop client は、この Control plane を操作する client であり、別の正本 store を持たない。 ### 2. Workspace と Repository を同一視しない @@ -126,20 +126,21 @@ Ticket には次の概念が必要になる。 - Board / queue / planning / review / done / archived views. - Conflict handling and concurrent editing policy. -### 4. Memory / Knowledge の本格再設計は後回しにする +### 4. Memory / Skill catalog の本格再設計は後回しにする -Memory / Knowledge は Ticket / Artifact のコピーではない。再利用可能な文脈、方針、学習された制約、保守された知識として扱う。ただし、Memory の意味論・抽出・承認・検索・staleness 処理を今この Objective で先に作り込まない。 +Memory は Ticket / Artifact のコピーではない。再利用可能な文脈、方針、学習された制約を扱うが、Ticket や Artifact の authority を置き換えない。Skill catalog は procedural guidance の catalog であり、外部状態 authority を持たない。Knowledge record kind は削除方針なので、この Objective では separate Knowledge storage を新しい control plane entity として増やさない。 -理由は、Memory の正しい設計が Workspace control plane の record model、Actor / visibility / permission、Ticket、Artifact / evidence、RepositoryPoint、Runtime に渡す context の監査方法に依存するためである。これらが固まる前に Memory schema だけを作ると、local `.yoi` 前提や現行 agent runtime 前提に引っ張られ、後で再設計が必要になる。 +理由は、Memory と Skill catalog の正しい設計が Workspace control plane の record model、Actor / visibility / permission、Ticket、Artifact / evidence、RepositoryPoint、Runtime に渡す context の監査方法に依存するためである。これらが固まる前に Memory schema や Skill API だけを作ると、local `.yoi` 前提や現行 agent runtime 前提に引っ張られ、後で再設計が必要になる。 -この Objective では、Memory / Knowledge について以下の platform contract だけを維持する。 +この Objective では、Memory / Skill catalog について以下の platform contract だけを維持する。 -- Memory / Knowledge は Control plane が扱う record だが、Ticket / Artifact の authority を置き換えない。 -- 将来、Memory / Knowledge の canonical storage は Workspace control plane 側に置く。 -- local `.yoi` memory は compatibility、offline/export/import、local projection、migration bridge として扱う。 -- Personal Memory、Workspace Memory、Worker Summary、Maintained Knowledge は分離が必要である。 +- Memory は Control plane が扱う record だが、Ticket / Artifact の authority を置き換えない。 +- Skill catalog は Workspace backend が扱う prompt/resource catalog だが、Ticket / Worker / workdir / queue の authority を持たない。 +- 将来、Memory と Skill catalog の canonical storage / API は Workspace control plane 側に置く。 +- local `.yoi` memory と `.yoi/skills` は compatibility、offline/export/import、local projection、migration bridge として扱う。 +- Personal Memory、Workspace Memory、Worker Summary、Skill catalog は分離が必要である。 - Generated Memory には provenance、visibility、approval、audit が必要である。 -- Runtime / Worker に渡した Memory/Knowledge context は、将来 ContextPack などとして Artifact/evidence に記録できる必要がある。 +- Runtime / Worker に渡した Memory / Skill context は、将来 ContextPack などとして Artifact/evidence に記録できる必要がある。 本格的な Memory 再設計は、Memory の保存先を Workspace backend / control plane record に移すタイミングで回収する。それまでは低リスクな観察、問題例の収集、既存 local memory の互換維持に留める。 @@ -200,7 +201,7 @@ Desktop app は対応コストが高いので、まず Web frontend を primary - TUI/local panel: fallback、dogfooding surface。 - Future desktop: Web/control-plane model が安定した後に検討する optional client。 -Web UI は Ticket、Objective、Memory、Knowledge、Runtime、Worker、Artifact を扱う。UI の都合で正本を二重化しない。 +Web UI は Ticket、Objective、Memory、Skill catalog、Runtime、Worker、Artifact を扱う。UI の都合で正本を二重化しない。 ### 7. 多重起動コストと runtime placement を見直す @@ -226,17 +227,17 @@ Worker の一元管理、データ永続化、アーカイブは将来的には ## Initial phases / candidate tickets 1. **Vocabulary / architecture record** - - Workspace / RepositoryId / RepositorySelector / RepositoryPoint / working directory / Runtime / Worker / Control Plane / Ticket / Memory / Knowledge の用語と境界を固める。 + - Workspace / RepositoryId / RepositorySelector / RepositoryPoint / working directory / Runtime / Worker / Control Plane / Ticket / Memory の用語と境界を固める。 2. **Team-space canonical data model** - - Ticket / Objective / Target / Artifact / Actor / Permission / Audit / Memory / Knowledge の entity/event model を設計する。 + - Ticket / Objective / Target / Artifact / Actor / Permission / Audit / Memory の entity/event model を設計する。 3. **Ticket evidence model** - Ticket lifecycle、WorkerRef、Artifact、validation evidence、review evidence、Ticket thread の責務を明確化する。 4. **Memory storage migration boundary** - - Memory / Knowledge の本格再設計は後回しにし、まずは Workspace backend に移す時の platform contract、compatibility/cache/export 方針、将来の provenance / visibility / approval 要件だけを固定する。 + - Memory の本格再設計は後回しにし、まずは Workspace backend に移す時の platform contract、compatibility/cache/export 方針、将来の provenance / visibility / approval 要件だけを固定する。 5. **Control plane backend architecture** - local `.yoi` backend と server-side canonical backend の境界、migration/export/import、compatibility mode を設計する。 6. **Web control plane MVP design** - - read-only Ticket / Objective / Memory / Knowledge / Runtime / Worker state UI/API の範囲を決める。 + - read-only Ticket / Objective / Memory / Runtime / Worker state UI/API の範囲を決める。 7. **Local Runtime protocol design** - Web/control plane から local Runtime に安全な操作を送り、Runtime が Worker lifecycle と working directory materialization を担う protocol と authority boundary を設計する。 8. **Repository and working directory materialization model** @@ -258,16 +259,16 @@ Worker の一元管理、データ永続化、アーカイブは将来的には ## Success criteria / exit conditions -- Workspace / RepositoryId / RepositorySelector / RepositoryPoint / working directory / Runtime / Worker / Control Plane / Ticket / Memory / Knowledge の境界が文書化されている。 +- Workspace / RepositoryId / RepositorySelector / RepositoryPoint / working directory / Runtime / Worker / Control Plane / Ticket / Memory の境界が文書化されている。 - Ticket が team coordination record として、target selector / Artifact / Actor / Permission / Audit と分離された model を持つ。 - `.yoi` local backend は compatibility/local backend として整理され、server-side canonical backend の設計を阻害しない。 -- Web UI/API が Ticket / Objective / Runtime / Worker state を中心とした read-only view を提供できる設計または MVP を持つ。Memory / Knowledge は既存 record の表示または将来 placeholder に留め、本格再設計をこの段階の必須条件にしない。 +- Web UI/API が Ticket / Objective / Runtime / Worker state を中心とした read-only view を提供できる設計または MVP を持つ。Memory は既存 record の表示または将来 placeholder に留め、本格再設計をこの段階の必須条件にしない。 - Control plane から local Runtime に対して、現在のローカル管理画面相当の安全な操作を実行できる design/protocol がある。 - Runtime は single Workspace / Git repository root 専用 process ではなく、sandbox/authority が成立すれば複数 Workspace / Repository の Worker を抱えられる execution substrate として設計されている。 - Git Repository root に依存しない Workspace model があり、Git Repository は Repository provider の一種として扱われている。 - Ticket と Objective は Workspace 配下に平たく存在し、Repository への所属ではなく RepositoryId / RepositorySelector / path scope / intent で対象を表現する。 - Git worktree 相当は working directory materialization strategy として扱われ、Artifact/evidence が concrete RepositoryPoint を記録する。 -- Memory / Knowledge は Ticket / Artifact の authority を置き換えない record として platform contract だけを持つ。本格的な意味論・抽出・承認・検索・staleness 処理は、Memory の保存先を Workspace backend / control plane record に移すタイミングで回収する。 +- Memory は Ticket / Artifact の authority を置き換えない record として platform contract だけを持つ。本格的な意味論・抽出・承認・検索・staleness 処理は、Memory の保存先を Workspace backend / control plane record に移すタイミングで回収する。 - Hosted Runtime / resource allocation / SaaS offering に進むための後続 Ticket が切れる状態になっている。 - 既存 local dogfooding runtime を壊さず、local use と remote-capable architecture が両立している。 diff --git a/.yoi/objectives/00001KVJSMQXZ/item.md b/.yoi/objectives/00001KVJSMQXZ/item.md index 38a460ff..770c198e 100644 --- a/.yoi/objectives/00001KVJSMQXZ/item.md +++ b/.yoi/objectives/00001KVJSMQXZ/item.md @@ -2,13 +2,13 @@ title: "効果的な Memory システム設計・検証" state: "active" created_at: "2026-06-20T15:16:00Z" -updated_at: "2026-06-20T15:16:00Z" +updated_at: "2026-07-15T21:18:00Z" linked_tickets: ["00001KSKBPHRG", "00001KT02TCCG", "00001KTGCAFXG", "00001KSKBPTHR"] --- ## Goal -Yoi の Memory / Knowledge / generated memory / resident context / retrieval / usage metrics を、実際の開発・設計・レビュー・オーケストレーションに効く sensemaking substrate として再設計・検証する。 +Yoi の Memory / generated memory / resident context / retrieval / usage metrics を、実際の開発・設計・レビュー・オーケストレーションに効く sensemaking substrate として再設計・検証する。Knowledge は separate record kind として削除する方針であり、この Objective では Memory と authority record / Skill / docs の境界を再整理する。 この Objective でいう「効果的な Memory システム」は、単に多く保存する仕組みではなく、作業中の問いに対して relevant material を集め、根拠を検証可能にし、再表現・仮説形成・反証探索・意思決定・成果物への反映を低コストにする仕組みである。 @@ -41,9 +41,9 @@ Yoi の現行 Memory は、この流れのうち「保存」と「一部の検 - Ticket / task / question ごとの shoebox がない。 - shoebox から evidence snippets を切り出し、source / provenance / applicability / confidence と共に扱う evidence file がない。 -- `summary`, `decision`, `request`, `knowledge` は storage taxonomy であり、sensemaking 用 schema としては粗い。 +- `summary`, `decision`, `request` は durable memory storage taxonomy であり、sensemaking 用 schema としては粗い。Knowledge record kind は削除方針なので、再利用可能な手順は Skill、保守された設計資料は docs / Ticket decisions に寄せる。 - decision は残るが、hypothesis space、alternative、rejected reason、disconfirming evidence が残りにくい。 -- reviewer / orchestrator が confirmation bias を避けるための反証探索導線が弱い。 +- reviewer / orchestrator が confirmation bias を避けるための反証探索導線が弱い。関連する手順誘導は旧 Workflow ではなく Skill と role prompt / typed tools へ寄せる。 - resident exposure と explicit retrieval は観測できても、Memory が product に効いたかは測りにくい。 この Objective は、Memory 関連の設計・検証・検討・考察を一元化し、個別 Ticket がばらばらに storage、prompt、retrieval、metrics を改善して再び墓場を増やすことを防ぐための判断背景である。 @@ -115,15 +115,15 @@ Memory が prompt に入った、または query されたことは成功では - Ticket routing 用 Memory shoebox artifact を試作する。 - evidence snippet schema / source resolver を設計する。 - hypothesis / rejected alternative / disconfirming evidence の表現を追加する。 -- Reviewer workflow に反証探索を入れる。 +- Reviewer Skill / review process に反証探索を入れる。 - Memory usage metrics を product impact oriented に拡張する。 - stale / contradiction / renewal の検出・表示を設計する。 ## Success criteria / exit conditions -- Memory システムの目的が「保存」ではなく「sensemaking loop 支援」として project records / docs / prompts / workflows で一貫して説明されている。 +- Memory システムの目的が「保存」ではなく「sensemaking loop 支援」として project records / docs / prompts / Skills で一貫して説明されている。 - Pirolli & Card の `shoebox -> evidence file -> schema -> hypotheses -> product` に対応する Yoi 内の責務と非責務が整理されている。 -- Ticket / Objective / docs / session logs / Memory / Knowledge の authority boundary が明確で、Memory が authority を僭称しない。 +- Ticket / Objective / docs / session logs / Memory / Skills の authority boundary が明確で、Memory が authority を僭称せず、Skill は手順資源として外部状態 authority を持たない。 - 少なくとも一つの実作業 routing / review / design analysis で、task-bound shoebox または evidence file が生成・利用され、作業品質にどう効いたかが確認されている。 - Memory records または関連 artifacts が source / provenance / applicability / staleness / supports-or-refutes のいずれかを扱えるようになっている。 - Reviewer / Orchestrator が supporting evidence だけでなく、contradicting evidence / stale assumptions / rejected alternatives を探す導線を持っている。 @@ -131,7 +131,7 @@ Memory が prompt に入った、または query されたことは成功では - 古い Memory が放置されるのではなく、stale / superseded / contradicted / needs-review として扱える方針がある。 - 後続の実装 Ticket が concrete slice として分割され、Objective が Ticket dependency や進捗 container として使われていない。 -この Objective は、Memory が少なくとも一つの中規模設計・実装・レビュー作業で「関連情報を見つける」「根拠を確認する」「代替案/反証を検討する」「成果物へ反映する」流れを実証し、その設計方針が docs / workflows / metrics に反映された時点で `done` を検討できる。 +この Objective は、Memory が少なくとも一つの中規模設計・実装・レビュー作業で「関連情報を見つける」「根拠を確認する」「代替案/反証を検討する」「成果物へ反映する」流れを実証し、その設計方針が docs / Skills / metrics に反映された時点で `done` を検討できる。 ## Decision context @@ -141,8 +141,8 @@ Memory が prompt に入った、または query されたことは成功では - Memory は durable project authority ではない。Ticket、docs、git history、session logs、明示 user instruction の代替として使わない。 - Objective context は判断背景であり、個別実装の authority は各 Ticket body/thread/artifacts と明示的な Ticket relations / OrchestrationPlan records にある。 - `history` に残らない context-only injection を改善案にしない。新しい context input は history に commit する原則を守る。 -- Knowledge は単なる長期保存ではなく、再利用可能な schema / model / procedure / invariant として再検討する余地がある。 -- Generated memory / curated Knowledge / Ticket / docs / report の境界を再定義する場合は、authority boundary と migration/staleness を明示する。 +- Knowledge record kind は削除方針。再利用可能な手順・作法は Agent Skills (`.yoi/skills//SKILL.md`) へ、durable policy/rationale は Memory decisions / maintained docs / Ticket decisions へ、外部状態 authority は typed feature/tool surface へ分ける。 +- Generated memory / Ticket / docs / report / Skill の境界を再定義する場合は、authority boundary と migration/staleness を明示する。 - 関連する既存 Ticket: - `00001KSKBPHRG` — Prompt / Workflow 評価メトリクスと改善 Offer - `00001KT02TCCG` — Memory prompt: conditional guidance and proactive lookup @@ -183,9 +183,9 @@ Yoi 初期設計では、これを参考に以下を意図していた。 - activity token 閾値で extract を発火する。 - compact より前に session log range を抽出する。 - extract は `decisions`, `discussions`, `attempts`, `requests` などの候補を staging に保存する。 -- 抽出時点では Knowledge 化せず、純粋な「起きたこと」に寄せる。 -- consolidation が summary / decisions / requests / knowledge candidates を整理する。 -- consolidation 入力に linter warnings / usage metrics / Knowledge 化候補を含める。 +- 抽出時点では durable policy / Skill / docs へ早期分類せず、純粋な「起きたこと」に寄せる。 +- consolidation が summary / decisions / requests と、必要に応じた docs / Skill / Ticket decision 更新候補を整理する。 +- consolidation 入力に linter warnings / usage metrics / stale cleanup 候補を含める。 - stale / superseded / unused / noisy な情報を整理する。 この Objective での再解釈: @@ -224,7 +224,7 @@ HermesAgent で特に重要だった点: この Objective での再解釈: -- HermesAgent の `MEMORY.md` / `USER.md` / `skills` の分離は、Yoi の Knowledge / Workflow / prompt resource / docs / Ticket decision / generated memory の責務再整理に使える。 +- HermesAgent の `MEMORY.md` / `USER.md` / `skills` の分離は、Yoi の Memory / Skills / prompt resources / docs / Ticket decision / generated memory の責務再整理に使える。 - reusable procedure, reviewer focus, orchestration tactic, project preference, user preference, design invariant を同じ Memory bucket に入れると墓場化しやすい。 - `Nothing to save.` / empty extraction allowed は重要だが、保存抑制だけでは効果的な Memory にはならない。保存されたものが task-bound shoebox / evidence / schema / hypothesis / product に接続される必要がある。 - frozen snapshot / prompt cache 配慮は Yoi の history/context 加工原則と整合するが、それだけでは retrieval / resurfacing / disconfirmation は解決しない。