Тема отвечает на вопрос, где должно жить знание команды, чтобы его не уносили уходящие люди и не пересказывали на каждой встрече.
Ключевая мысль: знание переезжает из голов и переписки в репозиторий, где у каждой строки есть источник и дата. В PAF такой узел знания называют нексусом — это папка с файлами об одном объекте: системе, контракте, смежной команде, с указанием, кто сказал и когда проверяли. Качество нексуса меряют спелостью контекста: насколько полно он заполнен и как давно его актуализировали. Знание, которое давно не проверяли, «увядает» и автоматически снижает уверенность в обещаниях, которые на нём стоят.
Git здесь не ради моды. Автор и дата коммита дают провенанс, история файла — историю уверенности, а в общем репозитории владелец узла единственный, кто может его повышать. Правило старта простое: узел заводят, только когда из-за его отсутствия уже приняли плохое решение. Три-четыре узла в первом квартале — норма; нексус, в который никто не смотрит, хуже отсутствующего, потому что создаёт ложное чувство, что знание есть.
Как читать материалы:
- Product Architecture Framework (PAF) — короткое знакомство с фреймворком, откуда взята идея единого контекста.
- Атомарные исследования — как хранить знание отдельными фактами с источником и датой. Возьмите оттуда шаблоны факта, инсайта и решения и уровни доказательности: это та же логика, что у узлов знания, только для исследований.
Как этот контекст подготовить для ИИ-агентов, разобрано в теме «Контекст для агентов»; место репозитория в общей модели — в области «Операционная модель».