Talomnia Workforce
Первый продукт Talomnia: профессиональные цифровые специалисты (Digital Professionals) и команды для B2B-задач — исследования, разработка, технический и продуктовый анализ, AI-first консалтинг и смежные работы, которые уже умеет выполнять существующая система.
Что можно заказать
Категории работ для клиента: какую задачу вы передаёте, что получаете в результате, кто выполняет и как это оценивается. Каждая категория ссылается на способности, которыми выполняется.
Рыночные и конкурентные исследования
Задача: Понять рынок, конкурентов, цены и поведение покупателей до того, как принято решение — о продукте, входе в нишу или позиционировании. Открыть результат, команду, оценку и доказательстваЧто вы получаете
- Исследовательский отчёт с методологией, источниками и ограничениями
- Карта конкурентов и смежных альтернатив со сравнительной таблицей
- Ценовые бенчмарки по нише
- Рекомендация с обоснованием и границами применимости
Типовой состав команды: Исследователь-аналитик, рецензент, аудитор источников.
Как оценивается: Time & Materials с заранее согласованным Budget Limit; состав работ фиксируется до старта.
Какими способностями выполняется:
Разработка программного обеспечения
Задача: Спроектировать и реализовать сервис, модуль или интеграцию — с тестами, документацией и проверяемой историей исполнения. Открыть результат, команду, оценку и доказательстваЧто вы получаете
- Работающий код в репозитории с историей изменений
- Автоматические тесты, воспроизводимо зелёные
- Техническая документация по принятой таксономии
- Отчёт об исполнении со стоимостью и затраченным временем
Типовой состав команды: Разработчик, ревьюер кода, QA-инженер.
Как оценивается: Time & Materials с заранее согласованным Budget Limit; состав работ фиксируется до старта.
Какими способностями выполняется:
Архитектура и технические исследования
Задача: Выбрать технологию или архитектуру обоснованно — сравнить варианты, зафиксировать решение и его цену, не полагаясь на вкус. Открыть результат, команду, оценку и доказательстваЧто вы получаете
- Архитектурное решение, оформленное как ADR с рассмотренными альтернативами
- Сравнение технологий с критериями и замерами
- Схемы и описание границ системы
- План внедрения с рисками и точками отката
Типовой состав команды: Архитектор, технический исследователь, рецензент.
Как оценивается: Time & Materials с заранее согласованным Budget Limit; состав работ фиксируется до старта.
Какими способностями выполняется:
Продуктовый анализ
Задача: Разобраться, что происходит с продуктом: где теряются пользователи или деньги, какие гипотезы проверять и как измерить результат. Открыть результат, команду, оценку и доказательстваЧто вы получаете
- Аналитический отчёт с данными и методологией
- Список проверяемых гипотез с критериями успеха
- Приоритизация с обоснованием
- Метрики для контроля после изменений
Типовой состав команды: Продуктовый аналитик, рецензент, аудитор данных.
Как оценивается: Time & Materials с заранее согласованным Budget Limit; состав работ фиксируется до старта.
Какими способностями выполняется:
DevOps и инфраструктура
Задача: Настроить надёжную поставку и эксплуатацию: CI/CD, миграции, наблюдаемость, развёртывания без ручных правок на серверах. Открыть результат, команду, оценку и доказательстваЧто вы получаете
- Работающий конвейер сборки и развёртывания
- Миграции базы данных с проверенным откатом
- Мониторинг с проверяемыми оповещениями
- Операционный runbook
Типовой состав команды: DevOps-инженер, ревьюер, дежурный по проверке восстановления.
Как оценивается: Time & Materials с заранее согласованным Budget Limit; состав работ фиксируется до старта.
Какими способностями выполняется:
AI-first трансформация
Задача: Понять, какие процессы вашего бизнеса можно передать цифровым специалистам, с чего начать и как проверять результат — на вашем материале, а не в теории. Открыть результат, команду, оценку и доказательстваЧто вы получаете
- Карта процессов с оценкой пригодности к передаче
- Пилотный план с критериями приёмки
- Рекомендации по контролю качества и границам автономии
- Отчёт по итогам консультации
Типовой состав команды: Консультант по AI-first процессам, аналитик, рецензент.
Как оценивается: Отдельная услуга-консультация; объём и Budget Limit согласовываются до старта.
Какими способностями выполняется:
Документация и инженерия знаний
Задача: Превратить разрозненное знание команды в структурированную документацию, которой пользуются: справочники, руководства, базы знаний. Открыть результат, команду, оценку и доказательстваЧто вы получаете
- Документация по четырёхчастной таксономии (руководства, справочники, объяснения, обучение)
- Структура базы знаний с правилами её ведения
- Перенесённый и выверенный контент
- Правила поддержания актуальности
Типовой состав команды: Инженер знаний, технический писатель, рецензент.
Как оценивается: Time & Materials с заранее согласованным Budget Limit; состав работ фиксируется до старта.
Какими способностями выполняется:
Индивидуальная профессиональная работа
Задача: Задача, которая не укладывается в категории выше. Опишите её — мы честно ответим, можем ли её выполнить, чем докажем результат и сколько это будет стоить. Открыть результат, команду, оценку и доказательстваЧто вы получаете
- Оценка выполнимости с обоснованием
- Состав работ и критерии приёмки до старта
- Результат с доказательствами исполнения
- Отчёт со стоимостью и затраченным временем
Типовой состав команды: Состав подбирается под задачу из доступных ролей и способностей.
Как оценивается: Time & Materials с заранее согласованным Budget Limit; для enterprise — индивидуальные договоры.
Какими способностями выполняется:
Модель оплаты
- Time & Materials: заранее согласовываются состав специалистов, ставки, примерный estimate и Budget Limit — максимально разрешённый бюджет. Списывается фактически выполненная работа.
- Для enterprise — индивидуальные договоры, постоплата, акты.
- Публичного прайса ставок пока нет: ставки согласовываются в рамках конкретного заказа.
Как устроен заказ
Каждая задача проходит один и тот же путь: описание задачи, подбор ролей и знаний, фиксация экономики до исполнения, выполнение, сдача с доказательствами, приёмка.
Как выполняется эта работа
Категории выше выполняются способностями из Capability Atlas — публичного каталога способностей, применённых в реальных задачах. Это не маркетинговый список: каждая строка связана с исполнением.
- навыки
- 43
- блюпринты
- 16
- другие типы способностей
- 8
-
component-library
Семнадцать независимых от фреймворка спецификаций покрывают все поверхности сайта — от кнопок и навигации до несущего доказательного набора. Editorial Evidence Signature даёт Workflow, Research и Atlas единую типизированную раннюю рамку доверия, не превращая завершение, публикацию или sanitization в заявление о валидации. Для всех компонентов обязательны токены дизайн-системы, i18n, серверный рендеринг, видимый фокус и приёмка в обеих темах и на мобильных экранах.
-
design-system-atlas
Поэтапный путь, превращающий дизайн-исследование с зафиксированными дайджестами в принудительно исполняемую дизайн-систему: токены, типографика, отступы, навигация, изображения, таблицы и двуязычная дисциплина оформляются версионируемыми артефактами знаний, потребляются сборкой сайта и охраняются измеримыми проверками, способными провалиться. Исследование идёт первым и переносится как провенанс; система живёт переиспользуемыми публикуемыми артефактами, а не разовыми стилевыми решениями.
-
design-to-code-loop
Упорядоченный цикл со шлюзами, который доводит принятые дизайн-решения до проверяемого кода продукта: замороженная проекция контекста, исследование, зафиксированное дайджестом, несколько направлений, независимый выбор, направление визуальных активов, RED-контракт реализации, вертикальный срез кода, критика «скриншот / видение», тесты взаимодействия и доступности, ограниченный цикл исправлений и точная привязка доказательств к коммиту и релизу потребителя. Обеспечивает разделение автора и рецензента и возвращает материальные изменения в исходный артефакт-источник.
-
editorial-evidence-atlas
Переиспользуемый доказательный блюпринт длинной страницы с семантическими реестрами локалей, каркасом доказательств, условной навигацией по главам, полосами рисунков и провенансом.
-
evidence-bearing-verification
Шаблон построения проверок, результат которых считается свидетельством, а не утверждением. Проверка сначала обязана показать, что умеет падать (мутация кода или негативная фикстура), и лишь потом её зелёный результат принимается как доказательство. Каждый запуск фиксируется неизменяемой записью с дайджестом и провенансом, а интерпретация «прошло или нет» отделена от самого наблюдения. Исполнитель не вправе подтверждать собственный результат, а успех без полного комплекта свидетельств считается неустановленным.
-
evidence-spine
Определяет утверждение, способность, свидетельство исполнения и свидетельство проверки как связанные переиспользуемые типы с честными состояниями отсутствия и цели.
-
knowledge-evolution
Шаблон пересмотра существующего артефакта знаний, когда дефект подтверждён свидетельствами: одной неудачной попытки недостаточно, а при неоднозначной атрибуции фиксируется нерешённая причина и преемник не создаётся вовсе. Новая ревизия сохраняет логическую идентичность, получает собственный идентификатор и дайджест содержимого и явно указывает предшественника. Прежние байты и выданные по ним контракты никогда не переписываются; преемник заново проходит валидацию и утверждение и влияет только на будущие выборки.
-
knowledge-expansion
Шаблон добавления нового артефакта знаний, когда зафиксированный пробел доказывает, что ни один существующий артефакт не покрывает требование; вкус или слабый кандидат отправной точкой не являются. Кандидат получает новую логическую идентичность и находится в карантине, вне выборок, пока не пройдёт доказательную верификацию и явное утверждение; самоаттестация его продвинуть не может. Публикация идёт по политике жизненного цикла, публичная проекция обязана пройти ограничение санитизации, а ранее выданные контракты сохраняют свои закреплённые зависимости.
-
knowledge-repo-bootstrap
Повторяемая процедура развёртывания приватного репозитория знаний для продуктового слоя: адресное чтение требований, изучение принятых форматов по реальным образцам, архитектурное решение, каркас с артефактами жизненного цикла и санитизации и файлами политики безопасности, посев первыми настоящими артефактами — теми, что породил сам бутстрап. Путь индексации описывается по документации самого сервиса, а не выдумывается; проверка идёт по чек-листу приёмки, пункт за пунктом, с зафиксированными свидетельствами. Отработана на запуске Talomnia (TALO-0002).
-
lane-handoff
Шаблон замены работающей агентской линии свежей сессией без потери того, что линия успела установить. Трудность не в остановке сессии, а в том, чтобы преемник смог продолжить: передаются бриф, уже принятые решения вместе с приведшими к ним рассуждениями, отвергнутые варианты и причины отказа, артефакты и pull request'ы в работе и — прежде всего — запись проверок: что проверено, какой командой, с каким результатом. Передача, потерявшая запись проверок, превращает измеренную приёмку в пересказ: преемник либо принимает работу на веру, либо переделывает уже пройденное. Каждое перенесённое утверждение помечается как проверенное или предполагаемое, а скоропортящиеся преемник подтверждает заново.
-
long-form-document
Тип страницы для документа, который читают, а не просматривают: исследование, white paper, длинная аргументация с таблицами, градуированными утверждениями и перечнем источников. Это не структурный тип страницы — аргументации на 111 КБ с двадцатью одним разделом нужны собственная навигация по содержанию и возврат из любой точки, мера чтения, заданная в символах, а не шириной контейнера, таблицы, которым разрешено выходить за меру, но не за страницу, перечень источников, длинные адреса которого могут переноситься, и ритм чтения, в котором единицей является раздел. Для шаблона зафиксировано: что читатель должен мочь сделать на 320px, что документ делает, когда его собственная длина работает против него, и какие проверки могут покраснеть. Запись про исследования в blueprint-page-templates сужена и указывает сюда.
-
page-templates
Четырнадцать шаблонов, покрывающих все разделы talomnia.com: от главной и страниц кейсов исполнения до инвесторской комнаты, цен и форм. Каждый шаблон фиксирует последовательность блоков, используемые компоненты и источник данных в базе: повторяющееся содержимое всегда рендерится из данных, а не из зашитого текста. Элементы честности — статусные блоки, оговорки, штампы происхождения — заложены в структуру шаблонов, а мобильное поведение и паритет русской и английской версий описаны для каждого шаблона отдельно.
-
payment-provider-adapter
Изолирует платёжную логику за единым интерфейсом PaymentProvider с тестовой реализацией на Stripe, закрытой флагом, выключенным по умолчанию. Пока флаг выключен, кнопки на странице цен собирают только заявки о намерении: ни сетевых вызовов, ни списаний. При включённом флаге адаптер принимает исключительно тестовый ключ: боевой ключ в конфигурации считается ошибкой, а не путём к запуску. Включение реальных платежей остаётся явным решением оператора, а провайдера можно заменить, не трогая логику страницы цен.
-
projection-pipeline
Односторонний воспроизводимый конвейер из Git-репозитория знаний в базу сайта и Атлас способностей. Изменения рождаются только в Git; загрузчик — чистая функция дерева, пересборка даёт идентичный результат, а у рантайма сайта лишь права на чтение, так что обратная запись — это отказ в доступе, а не обещание на код-ревью. Двухслойный гейт жизненного цикла физически не пропускает непубличные артефакты в проекцию, санитайзер прерывает загрузку при любой внутренней детали, и у каждого инварианта есть мутационный тест, который реально был красным.
-
repo-provisioning-sanitized
Порядок создания публичного репозитория-витрины и приватных репозиториев сайта и бэкенда с дисциплиной санитизации, встроенной с первого коммита. Витрина несёт явную оговорку: это санитизированный след исполнения, а не рабочий продакшн-репозиторий; её CI-гейт блокирующий и доказан мутацией, красный и зелёный прогоны записаны как свидетельство. Приватные репозитории получают файлы политики безопасности экосистемы, коммиты идут от проверенной сервисной учётной записи, а реальные пути, хосты и адреса в публичный контур не попадают.
-
task-to-contract
Шаблон превращения намерения задачи в выданный контракт знаний за пять стадий: предложение, валидация, отбор, сборка и выдача, поверх закреплённого снимка репозитория. Каждая ссылка в контракте закреплена ревизией и дайджестом содержимого, допустимость решают шесть условий совместимости, а по каждой резолюции, удачной или нет, замораживается квитанция. Если совместимого набора нет, итогом становится зафиксированный пробел, а не ослабленный контракт; сборка и выдача остаются раздельными актами, и сам шаблон никаких разрешений не даёт.
-
bilingual-content
Способность создавать и поддерживать русский и английский контент с полным паритетом смысла и единой терминологией, закреплённой глоссарием, на сайте, в White Paper, питч-деке и на исследовательских страницах. Расхождение терминологии между языками или между документами считается дефектом. Подтверждается двуязычными материалами, которые тот же контентный стек уже публикует в экосистеме; для запуска требуется высший уровень: сквозная согласованность документов на обоих языках.
-
data-modeling-projection
Способность спроектировать слой данных Talomnia: минимальный набор сущностей для процессов, исследований, Атласа и заявок с двуязычными полями и графовыми связями вместо дерева; минимизацию данных заявок с Support Center как источником истины; одностороннюю воспроизводимую проекцию из Git через поисковый индекс в базу данных и на сайт, пропускающую на публичную поверхность только санитизированные артефакты. Высший уровень требует мутационного доказательства: удаление исходной записи заметно меняет страницу.
-
design-systems
Способность исследовать, определить и выпустить дизайн-систему: концепцию, стайл-гайд, набор компонентов, шаблоны страниц, мобильную адаптацию и критерии доступности, оформленные как сущности репозитория знаний, проецируемые в Атлас способностей, а не просто файлы в репозитории сайта. Запись честно фиксирует пробел: системного дизайн-артефакта в экосистеме прежде не существовало, поэтому компетенция вошла в статусе черновика и валидировалась поставкой дизайн-системы Talomnia.
-
devops-operations
Способность развернуть и эксплуатировать производственный контур talomnia.com: DNS и Cloudflare с TLS и сбросом кэша, версионируемая конфигурация веб-сервера, CI/CD с подтверждением боевых деплоев оператором, разделённые контуры staging и production, секреты только через хранилище секретов экосистемы, резервные копии с проверенным восстановлением и мониторинг, чьи оповещения доказуемо доходят до читаемого канала. Высший уровень требует доказанной, а не предполагаемой устойчивости.
-
integration-engineering
Способность соединять два сервиса по принципу «контракт прежде кода», отработанная на связке форм Talomnia с Arcanada Support Center: нативный интерфейс без iframe, синхронизация статусов через вебхуки или опрос, повторы с ключами идемпотентности, журнал аудита, связывание заявок по идентификатору и контрактные тесты между сторонами, блокирующие релиз при несовместимости. Опирается на кодифицированные паттерны внутренних HTTP-интеграций экосистемы и на Support Center, уже работающий в продакшене.
-
market-research
Способность проводить исследование рынка уровня принятия решений: портрет клиента, боли, конкурентный ландшафт, ценовые точки, альтернативы и первая продаваемая услуга, с опорой на проверяемые внешние источники, с методологией, списком источников, ограничениями и версионированием. Каждый результат несёт пометку предкоммерческой валидации на собственном применении, а гипотезы остаются помеченными как гипотезы. Высший уровень: ценовая рекомендация, которую можно защитить перед оператором или инвестором.
-
technical-research-adr
Способность вести цикл от исследования к решению при выборе технологий: инвентаризовать то, что экосистема уже использует, предпочитать существующий поддерживаемый вариант, пока он удовлетворяет требованиям, взвешивать альтернативы и фиксировать решение в архитектурной записи (ADR) до начала реализации. Новая технологическая зависимость не вводится без доказанной необходимости. Высший уровень: согласованное разрешение взаимосвязанных выборов, когда стек, база данных и аналитика образуют единый набор.
-
web-fullstack-delivery
Способность поставить производственный двуязычный сайт на базе данных от начала до конца: страницы, где повторяющийся контент собирается из базы, полный паритет RU/EN, тёмная и светлая темы без вспышки неверной темы, вёрстка mobile-first, доступность WCAG 2.1 AA, поисковые метаданные и кэширование публичных страниц в Cloudflare при некэшируемых формах. Подтверждается действующими производственными сайтами экосистемы, построенными и обслуживаемыми тем же агентным стеком.
-
acceptance-by-pr-decision
Процедура, завершающая каждую поставку зафиксированным решением по запросу на слияние. Каждый критерий приёмки из исходной задачи проверяется по поставке проверкой, способной провалиться, и наблюдаемый результат фиксируется по пунктам. Если все критерии выполнены, запрос сливается, и коммит слияния служит записью о приёмке; если хоть один провален, запрашиваются изменения с указанием критерия и наблюдаемого результата. Правка поставки ради прохождения критерия отвергается, а решение заносится в журнал работ.
-
accessible-evidence-diagrams
Восстанавливает рисунки из источников как типизированный семантический HTML с безопасным SVG, стабильными ID, локализованными альтернативами, видимыми подробными описаниями, провенансом и проверками.
-
admissibility-check
Процедура, решающая, может ли набор кандидатов войти в контракт знаний: шесть условий совместимости оцениваются полностью, включая правомочность, покрытие, отсутствие конфликтов исключения, замыкание зависимостей, выполнимость ограничений и действующие полномочия отбора. Вердикт содержит результат по каждому условию и точный код недопустимого состояния для каждого провала. Недопустимый набор отклоняется, а не чинится на месте; неизвестная выполнимость не считается истинной, а непроверяемые полномочия трактуются как отказ.
-
adr-authoring
Порядок написания архитектурного решения (ADR) до начала реализации: решение фиксируется заранее, а не оправдывается задним числом. Сначала проводится инвентаризация того, что уже работает в экосистеме, затем дословно выписываются требования и перечисляются реальные варианты с их пригодностью, эксплуатационной ценой и путём отхода. Запись должна существовать до первого коммита реализации и называть способ отмены решения; эскалация вместо решения допустима лишь при нескольких по-настоящему разных вариантах с серьёзными архитектурными последствиями.
-
ai-quality
Пять рабочих дисциплин разработки с ИИ: декомпозиция на методы не длиннее пятидесяти строк, тесты до кода с подменой только внешних границ, согласованный каркас архитектуры до реализации, работа над одним методом за раз и осознанное управление контекстом. Навык предполагает собранные требования и явные критерии готовности до начала работы. После неё остаются заранее написанные тесты, отдельный тест на каждый пункт критерия успеха и чистый прогон линтера после каждого цикла.
-
context-window-lifecycle
Управляет контекстным окном оркестрируемой линии как свойством качества, а не как ёмкостью. Занятость работающей линии считывается из её собственной записи об использовании — точной независимо от того, занята линия или простаивает, — а не с поверхности терминала, где значение отображается только в простое. Превышение объявленного порога трактуется как дефект результата, а не как ограничение планирования: переполненное окно не падает громко, а выдаёт правдоподобно неверную работу. Три средства различаются по цене и по тому, что каждое теряет: уплотнение, передача свежей сессии и завершение текущей единицы работы перед тем и другим.
-
customer-narrative
Метод написания клиентских текстов для коммерческих поверхностей. Каждое предложение оформляется как категория работ для клиента: передаваемая задача, конкретный список результатов, типовой состав команды, способ оценки, доказательные ссылки в Capability Atlas и один призыв к действию. Клиентский язык открывает текст раньше продуктовой механики и технологических терминов; внутренние сущности понижаются до доказательного уровня, а не удаляются; инварианты честности наследуются из политики презентации (без выдуманных кейсов, сравнений без бенчмарка, ставок и обещаний коммерческой политики в изъявительном наклонении); соблюдается паритет русской и английской версий; текст поставляется как проецируемые данные, и его наличие проверяется мутацией.
-
datarim-doctor
Диагностирует и переводит операционные файлы задач на строгую машиночитаемую схему: тонкие однострочные индексы, отдельный файл описания на задачу с закрытым набором из двенадцати полей и канонические архивные документы. Каждый исправляющий запуск обёрнут в контракт защиты от потери данных: полная резервная копия до изменений, инвариант числа записей с восстановлением копии при любой потере и повторная проверка, доказывающая ноль замечаний и отсутствие изменений при втором запуске.
-
datarim-system
Всегда загружаемый свод базовых правил Datarim: где живёт состояние, как формируются идентификаторы задач, почему операционные файлы остаются машиночитаемыми однострочными реестрами с отдельным файлом описания на задачу и в каком порядке разрешаются конфликты между указаниями оператора, навыками и поведением по умолчанию. Свод требует инициализированного каталога состояния до любой записи и отсылает частные вопросы к профильным фрагментам. Соответствие видно по указательным строкам индексов и зафиксированному исходу каждой закрытой задачи.
-
db-migration-execution
Процедура, приводящая целевую базу данных ровно к состоянию зафиксированной цепочки миграций. Миграции применяются по порядку под ролью владельца, схема никогда не правится на сервере вручную, а права доступа едут внутри самой цепочки и падают громко, а не чинятся на ходу. Домены записи между проекционными таблицами и операционной зоной соблюдаются, паритет после применения подтверждается пустым диффом схемы, а список применённых миграций и результат паритета попадают в отчёт. Учётные данные не покидают хост и не попадают в репозиторий.
-
deploy-broker-operation
Процедура выпуска релиза через деплой-брокер, единственный канал, которому разрешено менять хост. Бандл проверяется до любых изменений, деплой выполняет атомарное и обратимое переключение релиза с записью предыдущего, а проверка здоровья по локальной петле трактует любой сбойный ответ как провал деплоя. При провале здоровья или проверки содержимого выполняется откат с повторной проверкой; изменения граничной конфигурации тоже идут через репозиторий и брокер. Продакшен разворачивается только после зелёного стейджинга, а вывод брокера и HTTP-пробы сохраняются как свидетельства.
-
design-direction-exploration
Создаёт от трёх до пяти существенно различающихся направлений, сравнивает их по единой доказательной матрице, фиксирует возражения и причины отказа и до реализации замораживает независимо проверенный выбор по идентификатору и дайджесту.
-
design-research
Метод обоснования дизайн-работы проверяемыми внешними свидетельствами до первого визуального решения. Действующие продуктовые и инвесторские сайты и признанные дизайн-руководства разбираются по фиксированной структуре извлечения, а результатом становится исследовательская записка, в которой каждое утверждение ведёт к загруженному источнику с датой обращения, а опорные источники зафиксированы снапшотами с дайджестами. Последующие дизайн-артефакты используют записку как провенанс: этап дизайна открывается цитируемым исследованием, а не вкусом.
-
diataxis-docs
Закрепляет таксономию Diátaxis для каждого репозитория и сайта под управлением фреймворка: документация делится ровно на четыре категории по намерению читателя — учебные материалы, практические инструкции, справочник и объяснения — по закрытой таблице соответствий, без пятых разделов вроде FAQ. Новые репозитории получают структуру при создании; существующие проходят мягкий аудит с предупреждениями без блокировки сборки. Соответствие подтверждают четыре каталога с обязательными заглушками и решение о категории для каждого типа содержимого.
-
digest-pinning
Процедура, превращающая любую ссылку в закрытую неизменяемую привязку. Ссылка обязана разрешаться ровно в одну ревизию закреплённого снимка; изменяемые формы (имена веток, теги, диапазоны версий, живые URL) отвергаются сразу. Полезная нагрузка ревизии канонизируется, вычисляется дайджест содержимого, привязка записывается как ревизия плюс дайджест с точным предикатом версии и перепроверяется пересчётом по каноническим байтам. Все прямые и транзитивные зависимости закрепляются так же, поэтому результат разрешается без сети и изменяемых имён.
-
explanatory-affordance
Как поверхность Talomnia объясняет собственный словарь там, где он используется. Доказательная поверхность, называющая величину — wall, active, использование, стоимость человека, — обязана дать читателю её смысл на месте, а не на другой странице: отправлять человека в глоссарий за значением заголовка столбца — значит обесценивать саму страницу. Подсказка работает указателем, касанием и клавиатурой, объявляется вспомогательным технологиям, следует языку страницы, а не браузера, и рендерится из ТОГО ЖЕ спроецированного определения, что и глоссарий, потому что две поддерживаемые вручную копии определения расходятся. Она не может закрывать данные, которые объясняет, не может двигать вёрстку и не может срабатывать оттого, что указатель прошёл мимо. Атрибут title не удовлетворяет ничему из этого и отклонён.
-
factcheck
Проверяет текст перед публикацией, не переписывая его. Каждое проверяемое утверждение попадает в таблицу с оценкой важности, затем сверяется с авторитетными источниками в порядке значимости — для ключевых утверждений не менее трёх независимых источников — и получает явный вердикт со степенью уверенности. Правки минимальны, сохраняют голос и язык автора, каждая снабжена ссылкой на источник. Оригинал меняется только после одобрения автора, при созданных резервных копиях и с итоговым отчётом о проверке.
-
frontend-ui
Контрольный лист для любых правок HTML, CSS, шаблонов и визуальных компонентов. Требует светлую тему по умолчанию с тёмной как переопределением по классу, проверку скриншотами обеих тем на мобильных, планшетных и настольных разрешениях, паритет языковых версий на многоязычных сайтах и базовые проверки доступности, быстродействия и метаданных для соцсетей. Успешный ответ сервера не считается доказательством корректного вида страницы: на этапе проверки автоматический прогон в браузере оставляет скриншоты, а эстетическую оценку выносит человек.
-
human-summary
Завершает этапы проверки и архивации пересказом, понятным человеку без подготовки: что просили и что сделано, что удалось, что осталось открытым и что дальше — от 150 до 400 слов в жёсткой форме из четырёх разделов с идентификатором задачи в заголовке, чтобы пересказ читался сам по себе. Простоту языка обеспечивает проверка по словарям разрешённых и запрещённых слов с ограниченной вставкой дословных цитат и шкалой строгости, способной отклонить пересказ целиком. Критерии, проверенные один раз без автоматической защиты, обязательно раскрываются.
-
immutability
Контракт, удерживающий артефакты конвейера честными: требования, планы, проектные решения, тесты, контрольные листы и визуальные эталоны нельзя ослаблять ради прохождения несостоявшегося результата, а каждый критерий проверки обязан быть опровержимым. Если артефакт действительно невыполним, исполнитель до любого изменения фиксирует запись возврата к источнику — исходный текст, причину, предлагаемую правку, — передаёт решение оператору и направляет работу на этап, владеющий артефактом. Изменения происходят формальным замещением, а не тихой правкой.
-
infra-automation
Практики безопасной работы с парком серверов: проверенные ключи узлов и проверка достижимости сети до любого пакетного запуска, неинтерактивный SSH с быстрым отказом, пробный прогон на одном сервере перед всем парком и запрет пакетных разрушительных команд. Сюда входят отладка сбоев от сети к приложению, инвентаризация данных на уровне самих движков перед миграцией или выводом узла и правило: серверный артефакт, который читает проверочный гейт, сначала попадает под контроль версий. Результаты проверок и вывод операций пишутся в журнал как след аудита.
-
long-form-typesetting
Определяет, как авторская проза становится свёрстанным HTML на поверхностях Talomnia, чего до сих пор не описывал ни один артефакт: закрытое подмножество строчной разметки, которое конвертирует рендерер; дисциплина заголовков и подписей, сохраняющая читаемую структуру документа; оформление списков, таблиц, цитат, кода, ссылок и сносок; русские и английские конвенции тире и кавычек; запись чисел и валют в каждом языке; и мера — ширина колонки для длительного чтения. Решающий пункт — про НЕОЖИДАННУЮ разметку: поведение рендерера на разметке вне подмножества определено здесь, а не оставлено случаю — сначала экранирование, затем конвертация закрытого набора, всё остальное выводится буквально, а гейт на входе и обход опубликованных поверхностей отказывают громко. Разметка, видимая читателю, — дефект корректности, а не оформления.
-
motion-design
Управляет любым движением на поверхностях Talomnia, кроме смены темы: объявленные easing и длительность, ограничение каскада, честное исполнение запроса на пониженную анимацию — отключением, а не замедлением, — и, что решает больше случаев, чем параметры, когда движение просто неуместно. Движение допустимо, только если несёт смысл, недоступный статичному кадру: ориентацию, непрерывность или отклик на действие читателя. Украшение основанием не является. Фоновый слой держится строже, чем интерфейсная анимация: он должен быть незаметен при чтении, полностью отключаться при reduce, никогда не оказываться выше контента, не иметь возможности ухудшить измеренный контраст текста и деградировать до статичного фона, когда JavaScript или устройство его не тянут. Движение, которое нельзя проверить, находится вне контракта.
-
nginx-version-compat
Чек-лист планирования для задач, меняющих конфигурацию nginx. До написания первой директивы процедура опрашивает работающий сервер: точная версия и собранные модули, затем синтаксис HTTP/2 и HTTP/3 подбирается под именно эту версию, поскольку форма директив менялась между релизами, а дистрибутивы держат старые ветки. В план записывается измеренная версия, настройки TLS задаются явно, а перезагрузка допускается только после успешной проверки конфигурации.
-
node-bundle-assembly
Процедура сборки автономного релизного бандла Node из зафиксированного состояния репозитория с замороженным lock-файлом; расхождение lock-файла прерывает сборку. Зависимости ставятся строго по нему, проект компилируется, юнит-тесты обязаны пройти, а зависящие от окружения наборы пропускаются громко, но не молча. В бандл входят скомпилированный код, статические ресурсы и только производственные зависимости; инструменты разработки, тесты, данные системы контроля версий и секреты туда не попадают. Перед отправкой бандл сам проверяется на приёмочный минимум деплой-брокера.
-
playwright-qa
Контракт QA, добавляющий фронтенд-задачам доказательства из реального браузера. Проверка срабатывает, только когда изменённые файлы затрагивают разметку или стили; инструмент выбирается по фиксированной цепочке (переопределение оператора, CLI, MCP-сервер, браузер из окружения), а параллельные прогоны сериализуются блокировкой по задаче. Каждый прогон оставляет каталог со скриншотом, трейсом, логом и сводкой, на которую ссылается отчёт QA. Отсутствие инструментов фиксируется как замечание, а не как провал.
-
pre-ledger-accounting-reconstruction
Процедура восстановления учёта работы, которая выполнялась до того, как её начали измерять, без выдумывания замеров. Восстановление фиксирует только то, что подтверждается сохранившимися свидетельствами, помечает каждую восстановленную цифру как восстановленную с указанием основания, а всё остальное оставляет явно неизмеренным, а не нулевым. Основание — это счётное свойство сохранившегося артефакта, а не предполагаемая ставка, применённая к суррогату; там, где допущение неизбежно, оно объявляется допущением, чтобы читатель мог с ним спорить. Вклад человека фиксируется во времени даже тогда, когда защитимой денежной ставки нет, потому что неоценённый вклад — всё ещё вклад, а ноль его стирает.
-
research-workflow
Структурная методика изучения внешнего контекста перед планированием и по ходу реализации. Глубина зависит от уровня задачи: десять пунктов для новых систем, пять для доработок, ноль для быстрых правок. Проверяются версии, ломающие изменения, практики, совместимость, известные уязвимости и собственная кодовая база; допущения плана сверяются с живым состоянием до написания кода, а контракты сторонних сервисов подтверждаются реальными пробными запросами. Итоги ложатся в документ инсайтов, где каждый вывод снабжён источником, а непроверенное знание помечено.
-
resolution-receipt
Процедура, замораживающая неизменяемую квитанцию по каждой резолюции, включая неудачные. В квитанции фиксируются нормализованное намерение задачи, дайджест снимка, конфигурация резолвера и каждый рассмотренный кандидат, а у каждого отклонения есть машиночитаемый код причины: отказ прозой квитанцией не является. Конфликты, неоднозначность и полнота поиска записываются явно, с указанием сработавшей границы при раннем останове. Квитанция канонизируется и замораживается дайджестом, её идентичность отлична от контракта и выдачи, и она не меняется: исправление — новая квитанция со ссылкой на старую.
-
sanitization-gate
Превращает правила санитизации в автоматическую блокирующую проверку CI на каждом пути публикации. Работают два слоя детекторов: закреплённый по версии сканер секретов и проектный запретный список внутренних идентификаторов, который попадает в CI в виде шаблонов, а не значений. Проверка отказывает при любом срабатывании, исключение требует обоснования со сроком действия, а сам гейт доказан мутацией: подсаженный запрещённый токен обязан сделать CI красным, потому что гейт, который никогда не был красным, ничего не доказывает.
-
security-baseline
Канонический минимум безопасности для поставляемых артефактов: одиннадцать кластеров правил, от гигиены shell и Python, секретов и цепочки поставки до документации как кода, CI-гейтов, запрета прямых слияний в защищённые ветки и гейта на границе недоверенного контента. Каждый кластер закрыт обязательной CI-проверкой, блокирующей слияние; граница, где недоверенные байты попадают в контекст модели, дополнительно требует отдельного состязательного ревью, поскольку зелёный CI не моделирует prompt-инъекции. Каждое подавление регистрируется с причиной, сроком и ревьюером.
-
semantic-editorial-composition
Строит детерминированные длинные документы для каждой локали из стабильных авторских ключей, с редакционным ритмом и семантическим, а не попиксельным паритетом.
-
seo-hreflang
Как выстроить поисковую поверхность двуязычного сайта с языковыми префиксами так, чтобы русское и английское деревья не конкурировали в выдаче. Теги canonical, hreflang и Open Graph каждая страница получает из одной функции макета, поэтому неполный набор невозможен; sitemap строится из той же таблицы маршрутов и слагов базы данных, что и сами страницы, и живой адрес вне sitemap — ошибка по построению. Проверки сформулированы так, чтобы могли упасть: удаление строки в базе обязано убрать соответствующий адрес из sitemap.
-
success-criterion-measurement
Процедура, решающая критерий успеха строго по свидетельствам. Критерий обязан объявлять наблюдаемый предикат и версию оценки; каждый требуемый элемент свидетельств должен присутствовать, быть привязан дайджестом и нести провенанс с условиями сбора. Если хоть один элемент отсутствует, исход записывается как неустановленный, то есть ни пройденный, ни проваленный, а заявление исполнителя о собственном успехе отклоняется как утверждение и в оценку предиката не попадает. Результат замораживается в записи измерения, связывающей ревизию критерия, дайджесты свидетельств, итог предиката и оценщика.
-
systematic-debugging
Четырёхфазная дисциплина отладки, запрещающая предлагать исправления до понимания первопричины. Первая фаза: полностью прочитать ошибку, воспроизвести сбой и поставить диагностику на границах компонентов, чтобы увидеть, где ломается поток данных. Вторая: сравнить с работающим примером. Третья: проверить одну письменно сформулированную гипотезу минимальным изменением. Четвёртая: создать падающий тест, внести одно исправление у источника и проверить результат. После трёх неудачных попыток процедура требует остановиться и пересмотреть архитектуру, а не пробовать четвёртую заплатку.
-
tech-stack
Метод выбора технологического стека для новых проектов, сервисов и модулей. Классификатор триггеров отделяет рутинную работу в знакомом домене, где действует стандартная рекомендация, от случаев, требующих полного предложения: новый каркас, компонент из другого домена, миграция или прямой запрос оператора. Предложение содержит два-три кандидата, оценённых по десяти факторам, от соответствия домену до лёгкости ухода; выбирает оператор, решение фиксируется заметкой в плане и защищено контрактом неизменности. Версии зависимостей сверяются с живыми реестрами, а не с памятью модели.
-
testing
Тестовый контракт для реализации и QA: пирамида, где преобладают модульные тесты, и гейты против ложно-зелёных прогонов. Тесты обязаны проходить реальный производственный путь: сырые фикстуры через настоящий маппер, имитация сериализации драйвера, вышестоящие слои в режиме passthrough. Мутационная проверка должна краснеть при сломанном страже, пропуск из-за отсутствующей инфраструктуры обязан назвать зависимость, а число тестов в отчётах извлекается механически из деклараций раннера. Детальные гейты подгружаются фрагментами только под активную ситуацию.
-
theming-anti-fouc
Реализация тёмной и светлой темы и запоминания языка без единого кадра с неправильной темой при загрузке. Синхронный встроенный скрипт в самом начале head разрешает сохранённый выбор, затем системную настройку — до отрисовки стилей; состояние клиентского фреймворка может лишь отражать это решение, но не принимать его. Паттерн сохраняет кэширование на CDN, обходясь без cookie в кэшируемых ответах, покрывает пользователей без JavaScript через медиазапрос и проверяется матрицей скриншотов первого кадра во всех сочетаниях темы.
-
ui-source-selection
Решает до написания компонента, взять ли его из доверенного источника, адаптировать или писать самим, и фиксирует решение вместе с обосновывающими свидетельствами. Первый вопрос — не качество, а устанавливаемость: библиотека компонентов, предполагающая клиентский фреймворк, которого в продукте нет, не дешёвый вариант, а другая архитектура, и попытка сэкономить таким образом втаскивает рантайм, от которого продукт сознательно отказался. Источник допустим, только когда зафиксирована его лицензия, целевая поверхность удовлетворяет его требованиям к рантайму, а доступность и движение можно проверить нашими контрактами, а не принять на веру. Распространение копированием в репозиторий предпочтительнее рантайм-зависимости, потому что оставляет код проверяемым и правимым; своим он от этого не становится, и провенанс переживает копирование.
-
utilities
Указатель нативных шелл-рецептов для типовых операций: даты и часовые пояса, хеши и случайные значения, кодирование, преобразование регистра, валидация, работа с JSON и YAML, форматирование, удалённое выполнение по SSH, восстановление файлов и соглашения шелл-скриптинга. Агент сначала загружает короткую маршрутную запись, а затем только один нужный фрагмент, экономя контекст. Все рецепты опираются на инструменты, доступные по умолчанию в macOS и Linux (bash, python3, openssl, jq), поэтому внешние серверы и лишние зависимости не подключаются.
-
verification-before-completion
Гейт, запрещающий объявлять работу завершённой, исправленной или проходящей без свежего подтверждения рядом с самим заявлением. Перед любым отчётом о статусе, коммитом или pull request процедура определяет команду, доказывающую утверждение, выполняет её целиком, читает весь вывод и код возврата и лишь затем формулирует результат вместе с доказательством. Регрессионный тест обязан показать цикл «красный-зелёный», отчёты делегированных агентов сверяются с фактическим диффом, а в общем рабочем дереве проверка идёт по закоммиченному состоянию ветки задачи, а не по чужому checkout.
-
visual-asset-direction
Инвентаризирует канонические ассеты и концепты, затем фиксирует ровно одно честное решение — reuse/adapt/generate/reject — для каждой необходимой визуализации: сохраняет ревизию источника, дайджест, лицензию и провенанс; механически различает происхождение и раскрывает его, когда это влияет на интерпретацию читателя; выпускает доступные локализованные брифы, адаптивные варианты, обязательства по alt и подробным описаниям и проверки композиции; запрещает сток, типовое заполнение, фальшивое извлечение, выдуманные свидетельства и некачественные синтетические диаграммы.
-
visual-design-critique
Как агент оценивает отрисованную поверхность, а не таблицу стилей, и делает это одинаково дважды. Несёт машиночитаемый реестр правил, исполняемый раннером на отрисованной странице, поэтому критика — это набор находок с идентичностями правил и измеренными значениями, а не мнение прозой. Каждое правило объявляет, enforced оно или advisory, что измеряет и как падает; правило, которое не может упасть, в реестр не принимается. Реестр намеренно покрывает то, чего не видит проверка токенов, — иерархию, ритм, плотность и композицию, — потому что дефект, о котором сообщил заказчик, состоял в том, что страница читается как документация, а на такой странице ни одно значение токена не является неверным.