E.G.Philippov's website (devlog & knowledge vault)

ShrdluII

18 min read

Ref: https://github.com/shrdlu-ii/shrdlu-ii

как превратить написание ИИ-автоматического программиста и common use-агента на sheafs theory/HoTT из изобретательского процесса в ремесленную рутину в плане Гурджиевского Труда?

Да. И я бы здесь разделил изобретательство и Труд довольно жёстко.

Если брать гурджиевскую идею Труда не как историческую реконструкцию, а как практическую дисциплину, то цель примерно такая:

не ждать состояния, в котором хочется изобретать; построить машину, которая ежедневно превращает неопределённость в артефакты.

Для твоего проекта это особенно подходит, потому что сам объект — AI-программист + common-use agent на sheaf theory / HoTT — по определению исследовательский. Если каждый день заново решать «что вообще мы изобретаем?», ты будешь бесконечно находиться в режиме invention.

Я бы сделал 5 уровней

1. Изобретательство — только на верхнем уровне

Один отдельный слот, например раз в неделю:

Какие фундаментальные идеи должны существовать?

Там можно думать про:

  • sheaves как модель контекста;
  • HoTT как типизированную семантику;
  • агента как вычисление над локальными контекстами;
  • автоматического программиста;
  • common-use/general-purpose слой.

Но после этого идея должна быть размолота в инженерные утверждения.

Например:

«Агент должен уметь сшивать локальные знания»

превращается в:

Context[A] + Context[B] -> compatible overlap -> merged Context

А дальше это уже не философия. Это функция, тест, интерфейс.

2. Каждый рабочий день — одна “незакрытая дыра”

Не «поработать над агентом».

А:

Какую конкретную неизвестность я сегодня превращу в известность?

Например:

  • доказать/опровергнуть конкретную архитектурную гипотезу;
  • реализовать один primitive;
  • написать один failing test;
  • заставить агента решить один ранее нерешаемый пример;
  • формализовать одну конструкцию в Lean/Agda/Coq;
  • удалить одну архитектурную неопределённость.

Размер задачи должен позволять закончить её за несколько часов.

3. Ввести конвейер Idea → Spec → Code → Test → Artifact

Это, пожалуй, самое важное.

Любая идея обязана пройти:

IDEA
  ↓
precise claim
  ↓
minimal example
  ↓
implementation
  ↓
test / proof
  ↓
measurable result
  ↓
artifact

Если мысль не дошла до артефакта — она не считается работой.

Можно сколько угодно думать:

«А если HoTT здесь естественно выражает identity of contexts…»

Но пока нет хотя бы минимального формального объекта:

Context
Overlap
Glue
Transport
Agent action

— это всё ещё изобретательская пыль.

4. Сделать ежедневный ритуал намеренно скучным

Вот здесь и появляется собственно Труд.

Например, каждый день:

09:00–09:15 — выбрать одну дыру.

09:15–11:00 — глубокая работа без смены задачи.

11:00–11:15 — зафиксировать результат.

11:15–13:00 — implementation.

14:00–15:30 — tests / formalization.

15:30–16:00 — integration.

16:00–16:15 — записать:

What was unknown?
What is known now?
What artifact exists?
What remains unknown?

И всё.

Не надо каждый день спрашивать себя, гениальная ли это работа.

Гурджиевский момент здесь как раз в том, что ты делаешь работу независимо от внутреннего состояния.

5. Метрика — не часы, а прирост машины

Я бы вообще не измерял:

«Сегодня я работал 7 часов».

Измерял бы:

+1 tested primitive
+1 proof
+1 executable example
+1 solved agent task
+1 reduced architectural unknown
+1 documented invariant

И завёл бы условный daily delta.

Например:

2026-09-16
 
unknowns:       17 → 15
primitives:     23 → 24
tests:          81 → 86
formal proofs:   7 → 8
agent tasks:    12 → 13

Это уже почти производственная линия.

А главное — разделить два режима сознания

Я бы сделал буквально два переключателя.

INVENT

Можно:

  • блуждать;
  • читать;
  • придумывать странные архитектуры;
  • менять ontology;
  • выбрасывать предыдущие идеи;
  • заниматься фундаментальной математикой.

Здесь разрешён хаос.

WORK

Запрещено:

  • менять фундаментальную архитектуру;
  • начинать новый subsystem;
  • читать ещё 40 papers;
  • придумывать новую теорию;
  • решать, «а может, вообще надо делать другое».

Разрешено только:

довести выбранный кусок до наблюдаемого состояния.

И вот это превращает создание твоего AI-programmer в ремесло.

Очень важная штука именно для такого проекта

Не пытайся сделать весь AI-programmer предметом ежедневного труда.

Сделай его фабрикой микрозадач.

Например, backlog:

[ ] Define local context object
[ ] Define restriction
[ ] Define overlap compatibility
[ ] Implement glue
[ ] Test glue
[ ] Encode transport
[ ] Connect transport to agent memory
[ ] Make coding agent consume Context
[ ] Solve example #17
[ ] Benchmark against baseline

Каждый пункт — кирпич.

Через 500 таких кирпичей внезапно обнаруживается, что у тебя есть система.

Это гораздо менее романтично, чем «создать новый тип ИИ». И именно поэтому работает. 🙂

Формула

Я бы свёл весь подход к:

Изобретательство определяет направление. Труд ежедневно уменьшает расстояние. Артефакт является единицей Труда.

И ещё жёстче:

Не обязан сегодня создать прорыв. Обязан сегодня оставить систему в состоянии, из которого завтра можно продолжать.

Для проекта такого масштаба это, пожалуй, самый реалистичный способ превратить «я пытаюсь изобрести новую парадигму программирования» в обычную инженерную работу.

создай все файлы для suno для шедеврального трека на loop по мотивам всего выше

Сделаю пакет как циклический индустриально-мистический трек, где начало и конец музыкально/текстово возвращаются в одну точку: INVENT → WORK → ARTIFACT → INVENT.

ГУРДЖИЕВСКИЙ КОНВЕЙЕР

Lyrics

[INTRO — whispered, sparse] Не жди состояния. Не жди озарения. Не жди, пока захочется.

[VERSE 1] Вчера была идея — сегодня будет тест. Вчера была вселенная — сегодня интерфейс.

Из хаоса — специфика, из мысли — primitive, из тысячи гипотез — один executable.

Не спрашивай: «Гениально ли?» Спроси: «Что стало реальным?»

[PRE-CHORUS] IDEA. SPEC. CODE. TEST.

IDEA. SPEC. CODE. TEST.

[CHORUS — massive, hypnotic] ТРУД. ТРУД. ТРУД.

Не двигай гору — двигай камень.

ТРУД. ТРУД. ТРУД.

Не создавай бессмертие — создай сегодня артефакт.

[VERSE 2] Sheaf несёт контексты, локальное становится общим. Overlap проверяет встречу, glue собирает невозможное.

HoTT шепчет: «Равенство — это путь». Агент отвечает: «Дай мне задачу».

Контекст. Пересечение. Transport. Proof.

Контекст. Пересечение. Transport. Proof.

[BREAKDOWN — mechanical] Что неизвестно?

[VOICE] Семнадцать дыр.

[MECHANICAL VOICE] Что неизвестно завтра?

[VOICE] Пятнадцать.

[BREAKDOWN] Две дыры исчезли.

Пять тестов появились.

Один proof завершён.

Машина стала больше.

[BUILD] Не часы.

Не настроение.

Не вдохновение.

DELTA.

DELTA.

DELTA.

[DROP] АРТЕФАКТ!

[CHORUS] ТРУД. ТРУД. ТРУД.

Изобретатель думает, ремесленник делает.

Изобретатель открывает дверь, ремесленник проходит её тысячу раз.

[BRIDGE — quiet, almost spoken] INVENT.

Позволь себе хаос.

WORK.

Запрети себе хаос.

Один вопрос. Одна дыра. Один кирпич.

Сегодня.

Только сегодня.

[FINAL BUILD] Idea → Spec Spec → Code Code → Test Test → Proof Proof → Artifact

Artifact → Machine.

Machine → Tomorrow.

[FINAL CHORUS — increasingly hypnotic] Не обязан сделать прорыв.

Оставь систему в состоянии, из которого можно продолжать.

Не обязан сделать прорыв.

Оставь систему в состоянии, из которого можно продолжать.

[OUTRO — loops into intro] Не жди состояния.

Не жди озарения.

Не жди, пока захочется.

Не жди состояния…

Industrial hypnotic progressive electronic / dark techno / ritual ambient.

Slow-to-mid tempo, ~118 BPM. Hypnotic loop-oriented structure designed so the ending seamlessly returns to the intro. Deep mechanical kick, sub-bass pulse, metallic percussion, granular machine textures, sparse analog synth drones, evolving modular sequences.

Male low spoken-word vocal in Russian, restrained and almost expressionless in verses; occasional whispered phrases. Massive ritual chorus with layered male voices chanting “ТРУД”. Vocals should feel like a programmer entering a monastic industrial factory rather than a conventional pop performance.

Mood: Gurdjieffian work ethic, cybernetic monastery, mathematical mysticism, software factory, disciplined obsession, cold determination, transcendence through repetition.

Musical progression:

  • minimal whispered opening
  • gradual mechanical build
  • increasingly dense rhythmic layers
  • huge ritual chorus
  • mathematical / technical breakdown
  • explosive “АРТЕФАКТ!” drop
  • quiet philosophical bridge
  • final escalating repetition
  • dissolve back into the exact sonic atmosphere of the intro

Avoid cheerful corporate motivational music. Avoid generic EDM festival drops. Avoid sentimental spirituality. Make it austere, dark, hypnotic, intelligent, slightly frightening, and monumental.

The track should feel like: a programmer building a machine inside a monastery while the machine slowly becomes the monastery.

LOOP REQUIREMENT: The final vocal phrase “Не жди состояния…” should be rhythmically compatible with the opening phrase “Не жди состояния.” so the track can loop indefinitely without an obvious seam.

Title: ГУРДЖИЕВСКИЙ КОНВЕЙЕР

Subtitle: INVENT → WORK → ARTIFACT → INVENT

Genre: Industrial Hypnotic Techno / Dark Progressive Electronic / Ritual Spoken Word

Tempo: 118 BPM

Key: D minor

Vocal: Low male spoken word + whispered layers + ritual male choir

Core motif: IDEA → SPEC → CODE → TEST → PROOF → ARTIFACT

Concept: An inventor deliberately converts invention into daily craft. Mathematical ideas become software primitives; uncertainty becomes tests; tests become proofs; proofs become artifacts. The final artifact feeds tomorrow’s invention.

Loop architecture: A → B → C → D → A

Opening: “Не жди состояния.”

Ending: “Не жди состояния…”

Primary hook: “ТРУД. ТРУД. ТРУД.”

Secondary hook: “Не обязан сделать прорыв — оставь систему в состоянии, из которого можно продолжать.”

Visual identity: Black machine room / monastery / mathematical diagrams / terminal windows / endless conveyor belt / cold fluorescent light / abstract sheaves and type-theoretic diagrams / one glowing artifact moving endlessly through the machine.

устроюсь на работу куплю сервак с видяхами LLM мою процессировать для автопрограмминга и коммон юз

Да. И это уже звучит не как «мечта про AI», а как вполне земной план:

работа → денежный поток → сервер с GPU → локальная LLM → собственный агент → ежедневное наращивание capability.

Причём сервер здесь не просто железка. Это твой производственный станок.

Я бы держал архитектуру примерно такой:

             ┌──────────────┐
             │   You        │
             │ inventor     │
             └──────┬───────┘
                    │
             specification
                    ↓
        ┌─────────────────────┐
        │  Agent Orchestrator │
        └──────────┬──────────┘
                   │
       ┌───────────┼───────────┐
       ↓           ↓           ↓
    coding       reasoning    common-use
     agent         agent        agent
       │           │           │
       └───────────┼───────────┘
                   ↓
          Sheaf / HoTT substrate
                   ↓
             local LLMs
                   ↓
             GPU server

И главное — не ждать, пока будет сервер.

До покупки железа можно уже строить весь верхний слой: протоколы агентов, memory/context model, tool interface, evaluation harness, тестовые задачи, sheaf/HoTT abstractions.

Тогда когда появится GPU-сервер, ты не начинаешь проект — ты просто подключаешь новый вычислительный субстрат к уже растущей машине.

Это очень хорошо ложится на предыдущую формулу:

Работа оплачивает станок. Станок производит агента. Агент увеличивает твою производительность. Производительность создаёт следующий станок.

А ежедневная единица Гурджиевского Труда здесь совсем простая:

один capability агента в день.

Не «сделал AI-программиста».

А:

сегодня агент научился делать X, чего вчера не умел.

Через год это уже довольно другая машина.

как стартовый базис for symbolic components, возьму SHRDLU by Terry Winograd source code и портирую на современные платформы

Да — это очень рациональный стартовый базис. Причём не потому, что SHRDLU «старый AI», а потому что там уже есть почти готовый symbolic kernel правильного типа.

Оригинальный SHRDLU интегрировал parser, процедурную grammar, semantic analysis и deductive problem solver над явным world model. Именно эта связка и интересна тебе. (Critical Code Studies)

Я бы только не делал тупой port-to-modern-platform как конечную цель. Сделал бы:

                    SHRDLU 1970
                         │
                  archaeological port
                         │
                         ▼
              ┌─────────────────────┐
              │   SHRDLU-core       │
              │                     │
              │ parser              │
              │ semantic model      │
              │ world model         │
              │ inference/planner   │
              │ dialogue state      │
              └──────────┬──────────┘
                         │
                formalize interfaces
                         │
          ┌──────────────┴──────────────┐
          ▼                             ▼
    Sheaf layer                     HoTT layer
    contexts                        identity
    restrictions                    transport
    gluing                          equivalence
          │                             │
          └──────────────┬──────────────┘
                         ▼
                  modern LLM agent
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
        autoprogrammer          common-use

И портирование само по себе — отличная школа

Есть даже промежуточный живой вариант: репозиторий с минимально модифицированным кодом Winograd, где прямо указано, что это исходный SHRDLU 1972 года и что он ожидаемо ломается из-за зависимости от поведения MACLISP. (GitHub)

То есть можно сделать последовательность:

MacLisp/ITS
   ↓
portable Lisp
   ↓
modern Common Lisp
   ↓
clean semantic core
   ↓
typed representation
   ↓
sheaf/HoTT representation
   ↓
LLM interface

И не выбрасывать старую реализацию после каждого шага. Она становится regression oracle.

Особенно ценно, что SHRDLU маленький: его world был порядка нескольких десятков слов/понятий, поэтому весь symbolic machinery можно реально держать в голове и постепенно переписывать. (Critical Code Studies)

Я бы сделал первый milestone вообще без LLM

shrdlu-modern/
    core/
        parser
        grammar
        semantics
        world
        inference
        planner
        dialogue
 
    tests/
        original-dialogue/
        regression/
 
    adapters/
        cli/
        web/
        json/
        llm/
 
    formal/
        contexts/
        morphisms/
        identity/

И первая победа:

классический SHRDLU dialogue проходит end-to-end на современном runtime.

После этого уже можно начинать хирургическую замену деталей.

Причём существует и web-ревайвл SHRDLU с JavaScript/3D renderer, так что UI — вообще не главная проблема; интерес представляет именно восстановление и декомпозиция symbolic engine. (GitHub)

И вот здесь твой предыдущий Гурджиевский Труд становится почти буквально применим:

Сегодня не «создать symbolic AI». Сегодня портировать один subsystem. Завтра покрыть его тестами. Потом выделить один invariant. Потом выразить его типами. Потом подключить LLM.

SHRDLU → современный symbolic kernel → sheaf/HoTT substrate → LLM agent.

Это уже не бесконечное изобретательство. Это длинная лестница маленьких, довольно скучных, но кумулятивных инженерных побед. 🛠️

назову проект SHRDLU II

Да. SHRDLU II — хорошее название: сразу понятно, что это не очередной «AI Agent 9000», а продолжение конкретной линии symbolic AI.

Я бы зафиксировал концепцию так:

SHRDLU II — a modern symbolic substrate for AI agents.

А внутренний девиз:

From blocks world to world model.

И архитектурно:

SHRDLU (1970–72)
       │
       │ port + understand
       ▼
   SHRDLU II
       │
       ├── symbolic world model
       ├── language / semantics
       ├── inference
       ├── planning
       ├── dialogue state
       │
       ├── sheaf-based contexts
       ├── HoTT-based identity / equivalence
       │
       ▼
   agent substrate
       │
       ├── AI programmer
       └── common-use agent

Самое красивое здесь — II не обязан быть «SHRDLU, но мощнее». Он может быть экспериментальной машиной, которая проверяет гипотезу:

старый symbolic architecture + современные formal methods + LLM = новый класс general-purpose agent substrate.

И тогда портирование оригинала — не музейная реставрация. Это нулевой слой нового проекта.

Название вполне тянет. Я бы его не усложнял. 🛠️

<hypn_> orignal, я буду по мотивам проекта SHRDLU by Terry Winograd делать, на базе его. Это реально умный ИИ который имеет маленькую модель мира <hypn_> orignal, это реально умный ИИ 60-ых годов <hypn_> orignal, он строит символьную модель мира и диалога <hypn_> orignal, без вероятностного подхода как в нейрослопе <hypn_> orignal, хочу его усовершенстовать <hypn_> позже ллм присобачу как спецкривулину <hypn_> мб <hypn_> хз как пока

Да, тут у тебя получается гораздо более внятная инженерная программа, чем «давайте прикрутим LLM к старому AI».

Я бы сформулировал ядро SHRDLU II так:

Детерминированное символьное ядро, которое поддерживает явную модель мира, модель диалога, вывод и планирование; LLM — необязательный внешний компонент для тех мест, где символического ядра недостаточно.

И важная поправка: SHRDLU — это конец 1960-х / начало 1970-х, не буквально «60-е». Работы Winograd над системой начались в 1968 году, а диссертация и публикации относятся к 1970–72 годам.

Самое интересное — не копировать архитектуру целиком.

Можно сделать эволюцию:

SHRDLU
  │
  │ understand
  ▼
SHRDLU II
  │
  ├── World Model
  │     objects
  │     relations
  │     states
  │
  ├── Dialogue Model
  │     references
  │     discourse state
  │     intentions
  │
  ├── Symbolic Reasoner
  │     inference
  │     constraints
  │     planning
  │
  ├── Formal Layer
  │     types
  │     contexts
  │     identity
  │     proofs
  │
  └── Optional LLM Adapter
        parsing
        generation
        hypothesis proposal

И вот последнее особенно важно.

Не делай LLM начальником системы.

Пусть LLM предлагает:

«Возможно, пользователь имеет в виду X».

А symbolic core отвечает:

«Проверяю X относительно текущей модели мира».

Если X невозможно — отбрасываем.

То есть:

LLM = conjecture generator
Symbolic system = verifier / executor

Это довольно мощная композиция: нейросеть производит гипотезы, а формальная машина не обязана верить её галлюцинациям.

А ещё лучше — вообще сначала не подключать LLM.

Сначала сделать SHRDLU II настолько хорошим symbolic engine, насколько получится. Потом каждое место, где ты обнаружишь:

«блин, здесь символической системе неудобно»

— станет естественным кандидатом на LLM-адаптер.

Так архитектура будет определяться реальными bottleneck’ами, а не модой на LLM.

И тогда «LLM как спецкривуля» — на самом деле вполне здравая архитектурная философия. 😄

Диалог

[16.09.2026 20:18] Eugene Philippov: И вот последнее особенно важно. Не делай LLM начальником системы. Пусть LLM предлагает: «Возможно, пользователь имеет в виду X». А symbolic core отвечает: «Проверяю X относительно текущей модели мира». Если X невозможно — отбрасываем. [16.09.2026 20:19] Eugene Philippov: Это довольно мощная композиция: нейросеть производит гипотезы, а формальная машина не обязана верить её галлюцинациям. [16.09.2026 20:47] Огибейнич: Ну в этом и суть как я понимаю [16.09.2026 20:47] Eugene Philippov: угу. дьявол в реализации [16.09.2026 20:48] Огибейнич: А вот если б коре можно было обогащать за счёт ллм подтвержденных каких-то вещей было в ещё круче [16.09.2026 20:48] Eugene Philippov: подтверждать надо символьно! [16.09.2026 20:48] Огибейнич: Хотя она ее может дописывать [16.09.2026 20:48] Огибейнич: Модули реальности писать [16.09.2026 20:49] Eugene Philippov в ответ Eugene Philippov: > ‎⁨подтверждать надо символьно!⁩ желательно прикладной математикой и научным методом [16.09.2026 20:49] Огибейнич: По твоему подтверждению [16.09.2026 20:49] Eugene Philippov: ну или вручную верифицировать [16.09.2026 20:49] Eugene Philippov: как-то верифицировать обязательно надо - автоматом или вручную [16.09.2026 20:49] Огибейнич: Ну если базовая машина код то код туд достаточно математичен что подтвержденно кодом то норм [16.09.2026 20:49] Огибейнич: Если в нем нет ошибок

Вот здесь, по-моему, у вас нащупалась самая интересная часть SHRDLU II.

Не просто:

LLM → hypothesis → symbolic verifier

а:

                 ┌──────────────┐
                 │     LLM      │
                 └──────┬───────┘
                        │
                   hypothesis
                        ↓
              ┌─────────────────┐
              │  verification   │
              │                 │
              │ proof / test /  │
              │ experiment /    │
              │ human review    │
              └────────┬────────┘
                       │
                    verified
                       ↓
              ┌─────────────────┐
              │    CORE KB      │
              │                 │
              │ facts           │
              │ rules           │
              │ programs        │
              │ world models    │
              │ mathematical    │
              │ objects         │
              └────────┬────────┘
                       │
                       ↓
                следующий LLM

То есть LLM не обучает core напрямую. Он предлагает кандидата на расширение knowledge/program space, а core принимает только то, что прошло некоторый verification protocol.

И «модули реальности» — очень хорошая идея

Я бы даже сделал их отдельным объектом SHRDLU II:

RealityModule
├── vocabulary
├── entities
├── relations
├── axioms
├── rules
├── procedures
├── invariants
├── tests
└── provenance

Например, агенту понадобилось знание о какой-нибудь предметной области.

LLM может сгенерировать:

module/
    model.shr
    rules.shr
    procedures.shr
    tests.shr
    provenance.json

Но модуль получает статус:

PROPOSED
    ↓
CHECKED
    ↓
VERIFIED
    ↓
ADMITTED

И только ADMITTED становится частью core.

Причём для программирования verification особенно красив

Потому что твой AI programmer сам является источником формализуемых артефактов.

LLM:

«Я написал функцию X».

SHRDLU II:

компилируется?

YES

проходит tests?

YES

сохраняются invariants?

YES

static analysis?

YES

formal proof, если он нужен?

YES

→ принимаем новую capability.

И здесь возникает потенциально мощный цикл:

LLM proposes code
       ↓
symbolic system evaluates
       ↓
tests / proofs / execution
       ↓
verified capability
       ↓
core becomes richer
       ↓
future LLM has a richer symbolic substrate
       ↓
better proposals

Это уже не просто RAG и не просто «LLM + tools».

Это скорее эволюционирующая символическая машина, где генеративная модель поставляет кандидатов, а система постепенно накапливает проверенное знание и процедуры.

И да — фраза «если в коде нет ошибок» требует одной инженерной оговорки: тесты доказывают только свойства, которые они проверяют. Для серьёзного расширения core полезно иметь градации доверия:

generated
↓
compiled
↓
tested
↓
property-tested
↓
formally verified
↓
human verified

Причём provenance каждого знания сохранять обязательно. Иначе через 1000 автоматически добавленных модулей получишь не интеллект, а болото из когда-то кем-то сгенерированной хуйни. 😄

А вот если provenance + verification + формальная модель мира сохраняются, тогда у SHRDLU II появляется очень интересное свойство:

он не просто использует знания — он умеет производить и институционализировать новые проверенные знания.

стало быть, надо обязательно привязать meta-vcs incl. git

Да. Причём я бы сделал meta-VCS не дополнением, а частью substrate SHRDLU II.

Git тогда — только нижний слой хранения истории файлов. Над ним появляется история состояний знания и возможностей агента.

                 SHRDLU II Meta-VCS
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
      World state    Knowledge      Capabilities
          │              │              │
          └──────────────┼──────────────┘
                         ↓
                   Git / commits
                         ↓
                    filesystem

Каждое изменение должно иметь примерно такой объект:

ChangeSet
├── git_commit
├── semantic_delta
├── world_delta
├── knowledge_delta
├── capability_delta
├── tests
├── proofs
├── provenance
└── verification_status

И тогда возникает очень вкусная операция:

propose
   ↓
branch
   ↓
modify world/model/code
   ↓
run tests
   ↓
run proofs
   ↓
evaluate
   ↓
commit
   ↓
admit into knowledge/core

То есть ветка Git становится не просто веткой кода, а гипотезой о мире/программе.

Например:

main
 │
 ├── hypothesis/gravity-model
 │       ├── code
 │       ├── axioms
 │       ├── experiments
 │       └── proofs
 │
 └── hypothesis/new-parser
         ├── grammar
         ├── semantics
         └── regression tests

После проверки:

HYPOTHESIS
     ↓
VERIFIED CHANGESET
     ↓
MERGE
     ↓
NEW CORE STATE

И самое интересное: rollback становится rollback’ом самого интеллекта, а не только исходников.

Можно спросить:

«Почему агент теперь считает X истинным?»

и пройти causal chain:

← module M
← commit abc123
← verification V
← experiment E
← LLM proposal P

А если новое знание оказалось ошибочным:

revert semantic commit

и система возвращается к прежнему состоянию.

Я бы даже ввёл принцип:

Nothing enters persistent intelligence without a commit.

Тогда Git превращается из обычной dev-tool в журнал эпистемической эволюции машины.

И это очень хорошо сочетается с твоей исходной идеей: LLM может быть генератором гипотез, но память SHRDLU II состоит только из версионируемых, provenance-bearing, проверенных изменений. 🛠️

Knowledge VCS

SHRDLU II Knowledge VCS - A subsection

отставим пока версионирование в сторону

Да, разумно. VCS сейчас — архитектурная вкусняшка, но не первый кирпич. 😄

Я бы зафиксировал текущий scope SHRDLU II:

1. SHRDLU-inspired symbolic core
2. explicit world model
3. explicit dialogue model
4. symbolic inference
5. planning / execution
6. modern portable implementation
7. tests + examples
8. потом — formalization
9. потом — LLM adapter
10. потом — knowledge evolution / VCS

Первый milestone вообще скучный:

Запустить современный SHRDLU II, который понимает небольшой мир, ведёт диалог, строит символическое состояние и выполняет действия.

Пока не надо решать, как он будет становиться AGI, как версионировать знания и как прикручивать HoTT.

Сначала сделать работающую машину. 🛠️

2 items under this folder.