objective: align memory records with skills direction
This commit is contained in:
parent
e0f14d402e
commit
149497b823
|
|
@ -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 は後続段階で扱う。
|
||||
|
|
|
|||
|
|
@ -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 が両立している。
|
||||
|
||||
|
|
|
|||
|
|
@ -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>/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 は解決しない。
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user