Администрирование

Оргструктура, пользователи и политики

Дерево подразделений, роли и гранты, проекты и видимость. Политики Org Policies — все измерения, наследование и effective-политика запуска.

Три слоя доступа в Temporality работают вместе: кто человек (пользователь, роль, должность), где он стоит (оргструктура, подразделения, проекты) и что ему разрешено (политики на подразделениях). Управление — страница Организация (/org, admin) и Пользователи (/users, admin).

#Оргструктура

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

Узел (OrgUnit) — подразделение: корень или ребёнок другого узла, у каждого есть стабильный id и тип (kind — отдел, команда, направление).
Руководитель узла (head) — явная грань «начальник»: цель эскалаций и адресат по умолчанию для командных запросов. Руководитель наследуется снизу вверх: узел без своего руководителя берёт ближайшего от предка.
Проект привязывается к узлу — наследует его политики и входит в его область видимости. Один проект — одна привязка; через неё действуют политики подразделения.
Пользователь принадлежит одному узлу (org_unit_id). Пустой узел = «вне структуры»: видит больше (переходная семантика на время раскатки — назначьте узлы, чтобы сузить).

Историческая деталь: знания и доступы команд настраиваются именно структурой — при росте компании вы переносите людей по дереву, а не переписываете списки.

#Пользователи и роли

Страница Пользователи (/users): создание, роль, должность, узел, bearer-токены, пароль, каналы уведомлений, тумблер активности.

Поле	Значение
Роль	Платформенные права: `reader < writer < operator < admin` (алиас `viewer` = `reader`)
Должность	Функция человека («Инженер тестирования») — естественный адрес для групповых вопросов, см. Должности и группы
Узел	Положение в оргструктуре — ведёт к политикам подразделения
Проекты	Область видимости: только разрешённые проекты (или все при `*`)

Роль	Может
reader	Читать: дашборд, трассы, знания, таймлайн
writer	Запускать задачи, создавать ресурсы проекта
operator	Подтверждения, reconcile неопределённых операций, invalidation знаний
admin	Пользователи, провайдеры, каналы, оргструктура, всё остальное

Гранты ролей на подразделении (org_unit_role) повышают роль человека локально: грант operator на узле действует на узле и всём его поддереве, не меняя глобальную роль. Так «старший инженер своего отдела» получает права оператора только в своей части структуры.

Аутентификация — пароль-first (форма «Пароль | API-токен»), токен — для сервисных аккаунтов и скриптов; внешний SSO (OIDC) с JIT-провижинингом — Администрирование → Внешняя аутентификация.

#Политики (Org Policies)

Политика — набор ограничений, висящих на узле оргструктуры (или на установке целиком, если узел не указан). Наследование сверху вниз: на запуск действует слияние всех политик позиции — глобальной, узлов проекта и узла инициатора — по принципу «только сужает». Дочерняя политика не может ослабить ограничение предка.

Измерение	Что ограничивает
`allowed_models`	Какие модели может использовать агент (список имён; пусто — любые)
`allowed_mcp`	Какие MCP-серверы доступны
`max_tokens`, `max_budget_usd`, `timeout_seconds`	Потолок одного запуска: токены, доллары, время
`network_mode: deny`	Полностью отключает сеть песочницы
`sandbox_mode: read_only`	Песочница только на чтение
`approval_mode: tools`	Значимые инструменты требуют подтверждения человека (+ поведенческий мониторинг)
`egress_allowlist`	Базовый список внешних адресов (объединяется со списком агента — политика расширяет базу)
`intake_mode: deny`	Запрещает канальные задачи для поддерева
`filesystem: read / write / deny`	Области файловой системы: чтение, запись (запись всегда внутри чтения), абсолютный запрет — см. ниже

#Файловые правила

filesystem задаётся glob-масками над путями проекта:

{
  "filesystem": {
    "read":  ["**"],
    "write": ["src/**", "tests/**", "docs/**"],
    "deny":  ["secrets/**", "deploy/production/**"]
  }
}

read / write — разрешённые области; запись никогда не бывает без чтения: область записи — пересечение write и read.
deny — абсолютный запрет на чтение и запись; объединяется по уровням слияния (запрет предка не отменяется дочерней политикой).
Пустое/неуказанное значение = без ограничений. Маски: **, a/b/**, *, ?, [...] — нормализованные относительные пути через /.
Ограничения работают на уровне исполнения: встроенные файловые инструменты ядра и команды в песочнице (Landlock) получают одну и ту же политику — обойти через run_command нельзя.

#Effective-политика запуска

Политика фиксируется при старте запуска и не меняется по ходу: изменения политик не повышают полномочий уже работающего процесса (новые запуски берут актуальную). В журнале запуска сохраняется версия снимка (policy_version) — по ней видно, какими правилами был авторизован ран.

Делегирование не расширяет доступ: дочерние запуски получают security context инициатора — вся ветка дерева делегирования работает полномочиями человека, который запустил работу, независимо от ролей Lead/Coder/Reviewer у агентов.

Автоматические запуски (webhook, расписание, триггеры) работают от имени execution identity — сервисной идентичности со своими разрешёнными списками и перепроверяемыми на каждом критическом шаге целями-людьми (human_targets). Политики для них считаются от позиции идентичности.

#Как это выглядит в интерфейсе

Организация (/org): дерево, пользователи на узлах, политики на узлах, гранты ролей. У политики — карточка с источниками: видно, какой уровень что ограничил.
Организация → Effective-политика: итоговое слияние для узла со всеми вкладами предков.

См. также: Персонализация — как знания агентов учитывают людей; внутренняя детали — docs/org-structure.md.