Skip to content

Структура ClickUp и принципы организации

Структура ClickUp отражает операционную логику работы, а не заменяет архитектуру экосистемы. Пространства, папки и списки помогают распределять текущие задачи; канонические определения и классификация находятся в Knowledge Substrate согласно политике метаданных и документационной архитектуре.

Правило разделения источников:

  • Knowledge Substrate хранит публичные определения, принципы, устойчивую архитектуру и связи;
  • ClickUp хранит внутреннее операционное состояние: задачи, ответственных, сроки, рабочие решения и журналы;
  • расположение задачи в ClickUp помогает навигации, но само по себе не меняет каноническую классификацию сущности.

Цветовой стандарт сущностей

Цвета пространств и папок используются как навигационные маркеры. Они не создают иерархию и не заменяют поля classification.scope, classification.context, classification.layer и classification.function в Knowledge Substrate.

После выделения Infrastructure и Tools в самостоятельные Spaces прежняя цветовая схема папок внутри Operations больше не описывает актуальную структуру.

Пространства (Spaces): архитектура и лимит

В текущей рабочей конфигурации используются пять Spaces. Каждый Space отвечает за отдельный тип операционной работы.

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

Space Назначение Статус
Management Layer Сквозная координация, архитектурная согласованность, governance- и management-процессы Активно
Infrastructure Работа над общими инфраструктурными контурами экосистемы: Home Ψ Lab, внешними серверами и Knowledge Substrate Активно
Projects Конкретные продуктовые, технические и редакционно-технологические проекты с собственным производственным циклом Активно
Tools Эксплуатация и развитие отдельных рабочих инструментов экосистемы Активно
Onboarding Вход новых участников, ознакомительные материалы, welcome-задачи и передача ответственности Активно

Внутренняя схема Space Projects

Внутри Projects сохраняется собственная визуальная классификация по эшелонам. Она помогает быстро понять основную роль проекта в текущем портфеле, но не является главной осью архитектуры экосистемы и не заменяет канонические metadata проекта.

Маркер Эшелон Роль Текущие примеры
🔵 E1-Core Проекты, создающие прямую пользовательскую и психологическую ценность Francis Galton, Psykhḗ AI
🟡 E2-Brand Проекты, усиливающие узнаваемость, коммуникацию, контент и публичные поверхности Psychology in Quotes, Sites, Storytelling, Telegram, VK, News Agent
🟣 E3-Infra Технические проекты, создающие общую runtime-, data- и automation-основу ecosystem-runtime, gpt_prompt_engine, U.L.I.
🔬 R&D Активная разработка самостоятельных гипотез и прототипов, которые ещё не стали устойчивыми проектами Экспериментальные инициативы
💭 Idea Lab Свободные идеи и наблюдения без собственного производственного контура Элементы «Ещё мысль»

Цвет папки проекта соответствует его текущему эшелону: синий — E1, жёлтый — E2, фиолетовый — E3, серый — R&D и идеи. Изменение эшелона является портфельным решением; оно не требует переименования репозитория и не превращает техническую классификацию в отдельный тип продукта.

Space Infrastructure

Публичное определение инфраструктуры находится в разделе Infrastructure. В ClickUp этот Space является внутренним операционным представлением сквозного инфраструктурного процесса.

Текущие основные папки:

Папка Операционная роль Публичная опора
🏠 Home Ψ Lab Установка и развитие собственного физического вычислительного пространства DETai Home Ψ Lab
🌍 Серверы Арендованные и внешние серверы, их состояние и эксплуатационные задачи Серверы
📦 Knowledge Substrate Задачи по базе знаний, её сборке, runtime и связанным данным Knowledge Substrate runtime

Папка STORYTELLING (TimeOS) для текстов является операционным входом в процесс подготовки текстов и будущую рабочую среду TimeOS. Её нахождение в Space Infrastructure не классифицирует Storytelling как инфраструктуру. Каноническое определение проекта находится на странице Storytelling, а кодовая реализация — в его owning repository.

Принцип создания нового Space

Все пять рабочих Spaces уже используются. Новый Space не создаётся только «для удобства»: его появление требует пересмотра существующей структуры и осознанного архитектурного решения.

Новое пространство создаётся только в том случае, если появляется функциональная область, которая:

  1. Требует полной изоляции от текущих процессов (например, секретный проект, работа с внешним подрядчиком, которому не нужен доступ к Operations).
  2. Имеет принципиально иную логику работы, набор статусов или типов задач, которые будут «шуметь» в общем пространстве.
  3. Представляет самостоятельный сквозной процесс или кластер, который дорос до собственной операционной среды.

Решение о создании нового Space принимается коллегиально и фиксируется в этом стандарте.

Сначала проверяется возможность разместить работу в существующем Space или папке. Если это искажает границы ответственности, решение поднимается на Management Layer и после принятия синхронизируется с Knowledge Substrate.