Skip to content

Latest commit

 

History

History
265 lines (201 loc) · 15.5 KB

File metadata and controls

265 lines (201 loc) · 15.5 KB

Статус реалізації і TODO для memory-system

Status note (2026-04-28)

v1 foundation завершено. Pilot-інсталяції на Курсова-2 і Курсова-К показали фундаментальну проблему: документи створюються коректно за схемою, але граф розпадається на ізольовані зірки — лінки односторонні, sparse (2-4 на документ), кластери проєктів не з'єднані з core memory.

Проєкт переходить у фазу v2: Connected Memory Graph. Архітектура зафіксована у architecture-v2.md. Активний план робіт — секції "v2 Graph Evolution" у implementation-todo.md.

v1-блоки нижче залишаються як історія завершених робіт.

Summary

Станом на зараз проєкт уже перейшов від сирої ідеї до розширеного v1-foundation пакета. Є:

  • первинна концепція;
  • детальний аналіз ідеї;
  • практичний план розробки;
  • формальна schema v1;
  • початковий Memory Core контракт;
  • структура memory/;
  • перші canonical memory docs;
  • шаблони документів;
  • перші skill-и для Codex і Claude;
  • базовий vault-index;
  • shared adapter contract;
  • validator/indexer specs;
  • working Python CLI for validate/index;
  • installer/bootstrap workflow for target repos;
  • README і readiness checklist;
  • ініціалізований Git-репозиторій з origin.

Водночас система ще не є повноцінно робочим memory engine. Наразі реалізовані contract/spec рівень, стартовий knowledge graph, базовий tooling layer і installer, але ще не зроблено pilot usage на зовнішніх проєктах.

Що вже зроблено

1. Концепція, аналіз і roadmap

  • Додано idea.md як вихідну концепцію.
  • Додано system-analysis.md з критичним аналізом і архітектурною рамкою.
  • Додано development-plan.md як операційний план реалізації.

2. Foundation і Memory Core

  • Зафіксовано типи memory-документів: concept, decision, context, entity, task, note, index.
  • Зафіксовано merge vs create через write gate.
  • Зафіксовано canonical policy.
  • Зафіксовано lifecycle/status model.
  • Зафіксовано базову retrieval policy.
  • Зафіксовано consolidation policy.
  • Зафіксовано naming convention для id і файлів.
  • Додано формальну schema-v1.
  • Зафіксовано schema_version, links, provenance і task status model.
  • Створено skills/core/mem-entity-memory-core.md як v1-опис Memory Core.

3. Vault layout

  • Створено директорії:
    • memory/concepts/
    • memory/contexts/
    • memory/decisions/
    • memory/entities/
    • memory/indexes/
    • memory/notes/
    • memory/summaries/
    • memory/tasks/
  • Створено memory/indexes/mem-index-vault.md.
  • Створено початковий запис у vault-index для Memory Core.
  • Створено canonical concept, decision, context, task і cluster index.
  • vault-index розширено реальними canonical nodes.

4. Templates and standards

5. Adapter layer

6. Validation and indexing spec

  • Додано validator-spec.
  • Додано indexer-spec.
  • Реалізовано Python CLI memory_tool з командами validate та index.
  • Додано unittest-покриття для validator/indexer сценаріїв.

7. Repo entry and v1 readiness

8. Packaging and installer

  • Додано installer як memory_tool install.
  • Додано installer assets у memory_tool/install/.
  • Реалізовано clean і examples install modes.
  • Додано wrapper scripts/memory-tool для target repos.
  • Додано install-manifest.json.
  • Додано post-install verification через validate і index.

9. Governance and verification

10. Git bootstrap

  • Репозиторій ініціалізовано локально.
  • Основна гілка встановлена як main.
  • Додано origin:
    • git@github.com:Long-as-Python/Agent_memory_system.git
  • Комітів до цього моменту не було.

Аналіз стану по фазах

Фаза Статус Що реально є Чого ще бракує
Phase 0. Concept and docs done idea.md, system-analysis.md, development-plan.md, README.md Немає
Phase 1. Foundation done Memory Core, schema v1, lifecycle, write gate, naming, schema_version Немає
Phase 2. Vault Layout done директорії memory/*, mem-index-vault.md, canonical concept/decision/context/task/index docs Потрібно лише подальше розширення graph
Phase 3. Templates and standards done шаблони, anti-patterns, migration rules, example docs для core/entity/note Немає
Phase 4. Retrieval Layer partial retrieval описаний у core, decision doc, adapter contract і перевірений на current cluster Немає practical fallback testing на зовнішніх проєктах
Phase 5. Write and Consolidation done write gate, anti-patterns, consolidation boundary, consolidation checklist, rollback policy Немає лише pilot pressure на реальному проєкті
Phase 6. Validation and Indexing done validator spec, indexer spec, Python CLI, orphan/duplicate detection, tests Немає лише broader runtime use outside current repo
Phase 7. Adapter Layer done skill-и для Codex і Claude, shared contract, difference rules, index update rules, verification note Немає лише runtime verification на реальних задачах
Phase 8. Installer and Packaging done memory_tool install, install assets, clean/examples modes, wrapper, manifest, bootstrap updates Немає лише upgrade path beyond fresh install
Phase 9. Pilot Usage partial є readiness checklist і метрики успіху Немає вибраного проєкту і фактичного pilot pass

Pilot v1 results (2026-04-24 / 2026-04-25)

Pilot-інсталяції завершено на двох курсових проєктах:

  • /home/forg/github/Курсова-2/ (cinema, MS Access) — 7 canonical документів, режим examples.
  • /home/forg/github/Курсова-К/ (auto-parking, MS Access) — 11 canonical документів у vault-index, режим examples.

Що працює:

  • schema v1 і всі required поля заповнюються коректно агентами;
  • write gate реально стримує дублікати на одному проєкті;
  • vault-index підтримується обома адаптерами;
  • validator/indexer проходять без помилок.

Що не працює:

  • кожен документ має лише 2-4 outbound links;
  • inbound traversal неможливий — немає backlinks;
  • Курсова-2 і Курсова-К мають ідентичні decision-документи але не пов'язані між собою;
  • агент не може відповісти "що залежить від цього context-а?";
  • BFS depth=2 від vault-index не покриває весь граф навіть в одному проєкті;
  • три connected components (core, kursova-2, kursova-k) фактично ізольовані.

Висновок: формальний контракт v1 правильний, але щільність і двонаправленість графа недостатні для агентного retrieval. Потрібен v2 — див. architecture-v2.md.

Головні прогалини прямо зараз

Critical (v2)

  • Розширити schema для incoming_links і similar_to.
  • Реалізувати memory_tool index --graph і --rebuild-backlinks.
  • Оновити adapter contract під v2 retrieval/write flow.
  • Прогнати v2 pilot на Курсова-2 і Курсова-К.

Important

  • Додати practical examples для retrieval conflict resolution.
  • Перевірити vault-index upkeep на кількох послідовних write scenarios.

Tooling

  • Підготувати validator spec.
  • Підготувати lightweight indexer spec.
  • Реалізувати validator для frontmatter і required fields.
  • Реалізувати lightweight indexer для побудови карти вузлів.
  • Реалізувати orphan detection.
  • Реалізувати duplicate detection.
  • Підготувати installer/bootstrap workflow для встановлення системи в target repos.
  • Підготувати bootstrap-скрипт або чіткий workflow для створення нового memory-документа з шаблону всередині вже встановленої системи.

Packaging and installer

  • Додати memory_tool install.
  • Додати clean/examples content modes.
  • Додати wrapper script для target repos.
  • Додати install manifest.
  • Додати post-install verification.
  • Спроєктувати upgrade path beyond fresh-install only.

Adapters

  • Винести спільний adapter contract у окремий документ або checklist.
  • Описати різницю поведінки між Codex і Claude там, де вона справді потрібна.
  • Зафіксувати, як адаптер оновлює mem-index-vault.md.
  • Визначити межу між автоматичним write і рекомендацією зробити consolidation.
  • Перевірити adapter flow на стартовому knowledge cluster.
  • Перевірити adapter flow на реальних сценаріях задач.

Pilot and metrics

  • Визначити 1-2 реальні проєкти для пілоту.
  • Зафіксувати acceptance metrics:
    • retrieval hit-rate;
    • кількість дублікатів;
    • кількість сирітських документів;
    • частка stale docs;
    • обсяг ручних правок після агентів.
  • Провести перший pilot pass і зафіксувати результати в окремому документі.

TODO list по пріоритету

Next now (v2 Phase A)

  • Розширити schema-v1.md полем incoming_links, типом similar_to і hard-minimum 2 outbound links.
  • Реалізувати memory_tool index --graph і --rebuild-backlinks.
  • Згенерувати перший mem-index-graph.md для core memory.

Next after that (v2 Phase B-C)

  • Оновити adapter contract і обидва skill-и під v2 sequence.
  • Додати link-first write gate у Phase 2 write pipeline.
  • Реалізувати cross-project bridge detection в installer.

Later (v2 Phase D-F)

  • Перевстановити memory-system у Курсова-2 і Курсова-К з v2 правилами.
  • Прогнати v2 pilot scenarios і заміряти graph density before/after.
  • Знайти третій pilot project для свіжої v2 інсталяції.
  • Написати pilot-report-v2.md.
  • Спроєктувати installer upgrade path beyond fresh install.

Рекомендований порядок наступної роботи

  1. Закрити Phase A: schema + tools.
  2. Згенерувати graph index і перевірити що він коректно описує core memory.
  3. Оновити adapter-и і прогнати v2 retrieval scenarios на core.
  4. Реалізувати cross-project bridges і протестувати на парі курсових.
  5. Зробити v2 pilot pass і зафіксувати метрики.
  6. На основі результатів вирішити чи потрібна v3 (embeddings, ambient links, summaries).

Висновок

v1 foundation — стабільний і завершений. Pilot показав що архітектурна модель правильна, але щільність графа і двонаправленість лінків недостатні для агентного retrieval.

Наступний фокус — v2 Connected Memory Graph:

  • computed backlinks через incoming_links;
  • hard-minimum 2 outbound links на документ;
  • mem-index-graph.md як машинний знімок графа;
  • cross-project bridges через similar_to;
  • hub-aware retrieval з підвищеним лімітом traversal.

Філософія залишається тією ж: docs-first, schema-driven, agent-oriented. Жодних ambient wikilinks і embeddings у v2 — лише щільніший і двонаправлений explicit граф.