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

feat: remove active knowledge support

Browse Source
This commit is contained in:
Hare
2026-07-16 07:30:00 +09:00
parent f2106407be
commit f786e01997
54 changed files with 197 additions and 1591 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/design/memory-knowledge.md
+9 -32
View File
@@ -1,38 +1,15 @@
# Memory and Knowledge
# Generated memory records
Yoi memory is generated context, not project authority.
Yoi keeps generated memory under `.yoi/memory/` for durable, low-volume context:
The authoritative record for work is still code, git history, work item files, tickets, session logs, and explicit user instruction. Memory helps the agent retrieve durable preferences and prior rationale, but it must not replace the records that made those facts true.
- `summary.md` is optional resident context.
- `decisions/*.md` capture durable decisions and rationale.
- `requests/*.md` capture durable user preferences or standing requests.
## Record types
Memory records are not workspace record authority for exact implementation state. Use tickets, objectives, repository files, git history, and session logs for exact current facts.
- `summary.md` is resident background context for normal Workers.
- `decisions/` stores durable decisions that are useful across turns.
- `requests/` stores durable user requests and preferences.
- `.yoi/knowledge/` stores curated Knowledge records when available.
- `_logs/` stores append-only audit observations.
- `_staging/` is generated candidate state before consolidation.
## Historical Knowledge records
Generated `.yoi/memory` is personal/generated state in this repository. Curated workflow/Knowledge assets may be tracked separately when intended.
Older workspaces may contain `.yoi/knowledge/`. Knowledge is no longer an active supported feature or workspace record authority. Current memory tooling ignores it; archive or inspect those files manually if needed.
## What memory should not do
Memory should not duplicate authoritative project records. Do not copy ticket threads, TODO lists, implementation reports, or full docs into memory merely to make them resident.
The useful memory is the small part that changes future behavior: a policy, a rationale, a user preference, or a durable conclusion that would otherwise be hard to find.
## Lookup policy
Agents should use memory and Knowledge when the request depends on prior decisions, historical rationale, project workflow, or durable preferences.
Agents should not query memory every turn. Local repository files, current user instructions, command output, and tickets are more authoritative for exact current state.
## Audit and mutation
Memory extraction/consolidation writes append-only observations under `_logs`. No-op and idle notices belong there rather than in user-facing UI.
Memory mutation should be explicit work or part of the configured memory maintenance path. Casual edits during unrelated tasks make memory harder to trust.
## Language
Memory follows configured memory language policy. Conversation prose follows the user's language unless configured otherwise.
Future Agent Skills are intentionally separate and are not implemented by this design note.