План расширения Atlas¶
English · Русский · Аудит покрытия · Карта обучения
Дата плана: 2026-10-05. Это backlog реализации исследовательского и учебного расширения в рамках общей дорожной карты и методологии. Приоритеты отражают зависимости и ценность, не обещанные сроки. Исходный P0 расширен до всего выявленного содержательного объёма: исправлений источников, вопросов при допустимом происхождении, ответов, первичного чтения и чеклистов объяснений/кейсов. Python-упражнения, исполняемые лабораторные, реализация проекта и AI-оценщик отложены сопровождающим. Новых схем и CLI нет.
Канонические треки остаются Engineering и Leadership. Предметные маршруты, ветки ответственности и оригинальные учебные кейсы не становятся новыми треками и не увеличивают банк вопросов. Опубликованным вопросам по-прежнему нужны свидетельства интервью, созданным по радару — существующий контракт происхождения. Редакционное упражнение не становится ни тем, ни другим от появления в руководстве.
P0 — сделать решения и практику проверяемыми¶
Статус: документы и навигация реализованы. Исходные критерии ниже остаются контрактом ревью; текущий этап содержания описан в P1–P3 и дополнении аудита. Независимое ревью и финальные проверки — отдельные критерии, не заявление о публикации или успешных испытаниях на учащихся.
| Задача | Результат и приёмка | Зависимость / свидетельства |
|---|---|---|
| P0.1 — воспроизводимый аудит | Общий отчёт с числами снимка, scope и ограничениями; Leadership-аудит со смысловой проверкой всех вопросов и ограниченной проверкой источников 20 вопросов | YAML, точные ID, отдельные приватные рабочие свидетельства. Верно считать пересечение; различать 70 Leadership-приоритетов и 89 записей с ответами |
| P0.2 — Engineering в пределах источников | Отчёт: 30 пунктов Hello Interview, доступные фрагменты, Premium и два недоступных текста; карта без установленного источника отделена от независимых свидетельств | Открытые guide и roadmap плюс первичные проверки провайдера, OWASP и MCP. Не копировать платные объяснения и переданные изображения |
| P0.3 — маршруты Engineering | Четыре недели кодинга и восемь недель сервиса: вход, нагрузка, оригинальные результаты, отказы и отложенные критерии | P0.2 и стабильные anchors. Семь семейств алгоритмов; контракты, evals, поиск, инструменты, эксплуатация и полномочия. Без обещания исполняемого кода или оценщика |
| P0.4 — практика Leadership | Восемь недель с Product, EM/Platform, Head/Director и TPM/Delivery; реальные истории отделены от вымышленных решений | P0.1. Бюджет/портфель и организация явно редакционные; PM/EM и Senior Staff+ не повышаются автоматически до свидетельств Director/TPM |
| P0.5 — навигация и языковое соответствие | Карта обучения, EN/RU-зеркала и ссылки с генерируемых страниц/меню; сохранить нынешнюю восьминедельную базу | P0.1–4. Не править генерируемые файлы вручную; проверить ссылки, anchors, сроки, пороги и ограничения на обоих языках |
| P0.6 — независимое ревью и проверки | Отдельное flagship-ревью от каждого автора/редактора; существенные замечания устранены или явно открыты. Обязательные проверки кода, генерации, strict site и приватности пройдены до передачи | Все P0-файлы проверенной ревизии; прежние записи об авторах/ревью сохраняются. Успешные проверки не публикуют сайт или книги |
P1 — исправить содержание и уточнить критерии практики¶
Содержание реализовано; финальное независимое ревью — отдельный критерий. Исходные приоритеты сохранены как согласованная последовательность. P1.1 исправляет три адаптации источников, оставляя недоступный Meta-отчёт нерешённым; P1.2–3 дают Leadership-кейсы и coding-объяснения с критериями ошибок. P1.4 — редакционная проверка согласованности, не эмпирическая калибровка на учащихся. Критерии ниже описывают требования к изменениям.
| Задача | Критерий приёмки | Зависимость / причина |
|---|---|---|
| P1.1 — адаптации источников | Перечитать источники lead-low-performance, lead-disruptive-star и lead-reorganisation-retention; согласовать формулировку/тип или раскрыть адаптацию с сохранением ID и EN/RU. Перепроверить prog-cross-team-delivery только через разрешённый публичный доступ; при недоступности оставить нерешённый статус |
Leadership-аудит выявил различия гипотетического/поведенческого режима, сценария и один недоступный отчёт. Нужны YAML-правки, ревью и регенерация |
| P1.2 — Leadership-дополнение и критерии | Уточнить кейсы P0 для Product, EM/Platform, Head/Director и TPM/Delivery: входные данные, полномочия, ожидаемый артефакт, условия провала и критерии 0–3. Отделить гипотетическую работу от реального опыта | P0.1 и P0.4. Портфель, бюджет и организация остаются редакционными; ограничения источников видимы. До сборки пакетов кейсов нужно независимое ревью спецификаций |
| P1.3 — метод AI-ассистированного кодинга | Описать наблюдаемый процесс: знакомство, ограниченный контекст, декомпозиция, выбор алгоритма, проверка, ревью PR и защита. Для каждого шага дать критерий и содержательный пример провала; сохранить ограниченный и разрешённый режимы AI | P0.2 и P0.3. Оригинальные задания и карта семи семейств вместо реконструкции платных задач; не выводить универсальное разрешение работодателей |
| P1.4 — согласованность оценки | Независимые проверяющие разбирают примеры гипотетических артефактов; уточняют неоднозначные инструкции и пороги. До реализации лабораторной описать, что устанавливают тесты, источники и человеческое суждение | P1.2–3. Это проверка спецификаций, не испытание на учащихся и не валидация прогноза найма |
P2 — две локальные лабораторные, production-проект и проверяемые кейсы¶
P2.1–3 и P2.5 отложены сопровождающим. Критерии сохранены как будущий scope, не текущие задания учащемуся. При возобновлении две лабораторные должны быть локальными упражнениями на Python без API-ключей; детерминированные фикстуры и заглушки обеспечивают приёмку без модели. P2.4 относится только к разрешённому содержательному дополнению кейсов и не зависит от реализации лабораторных.
| Задача | Критерий приёмки | Зависимость / причина |
|---|---|---|
| P2.1 — локальная Python-лабораторная 1: исправление и ограниченная функция | Реализовать оригинальное задание граничного бага/пакета с baseline, контрактом и содержательными тестами. Покрыть границы срока, пустой вход, дубли ID и порядок. Запускать в чистом локальном окружении без API-ключей | P1.3–4. Маленький синтетический или подходяще лицензированный репозиторий; проверить приватность каждого файла. Независимое ревью задания и решения; описать ручной, ограниченный и разрешённый AI-режимы |
| P2.2 — локальная Python-лабораторная 2: алгоритм и ревью PR | Дать небольшое оригинальное изменение с нарушением инварианта или проверки доступа. Потребовать обоснованный алгоритм, контрпример, регрессионный тест и решение ревью. Синтетические фикстуры и локальные тесты без API-ключей | P1.3–4. Содержательные неверные решения, пределы памяти/времени и отложенный вариант; без реконструкции платной задачи и обязательного внешнего модельного сервиса |
| P2.3 — проект прикладной AI-инженерии | Реализовать итоговый синтетический каталог: baseline, контракты, оценка, поиск по доступу, ограниченные инструменты, эксплуатация и защита релиза. Дать детерминированные заглушки модели/сервисов и воспроизводимый путь без ключей | P0.3 и P1.4. Тесты выявляют неверные ID оснований, запрет, таймаут после действия, дубли исполнения и остановку по бюджету. Отложенные кейсы не используются для настройки. Проверки управления отделены от качества живой модели и устойчивости к инъекциям; без реальных внешних действий |
| P2.4 — проверяемые Leadership-кейсы | Подготовить пакеты для четырёх веток: синтетические входы, ограничения решений, проверяемая арифметика, ожидаемые артефакты и примеры обратной связи. Включить портфель/бюджет, build/buy, оргизменения и перепланирование | P1.2 и P1.4. Принимать обоснованные альтернативы вместо единственного модельного ответа; задать критические ошибки, остановку, правдивость и отложенный вариант |
| P2.5 — пилот и калибровка | Небольшой пилот двух лабораторных, проекта и выбранных кейсов с согласием участников: время, неясные инструкции, ошибки артефактов и разногласия независимых проверяющих. Уточнить нагрузку и критерии | P2.1–4. Материалы участников приватны; публиковать только неидентифицирующие выводы. Для необязательных живых моделей фиксировать конфигурацию, повторы и неопределённость; пилот удобства не валидирует найм |
P3 — расширение практики, чтения и независимых свидетельств¶
Текущий содержательный этап закрывает выявленные пробелы чтения и выбранные ответы P3.2. P3.1 использует дополнительные концептуальные вопросы, проверки отказов и Leadership-кейсы; новые лабораторные отложены. P3.3 фиксирует поиск свидетельств и нерешённые ограничения: техническое чтение не подтверждает компании независимо. P3.4 остаётся отдельным решением о книгах/экспорте.
| Задача | Приёмка до использования | Зависимость / причина |
|---|---|---|
| P3.1 — расширенная практика | Текущее содержание добавляет концептуальные уточнения, контрпримеры и критерии кейсов. Для новых исполняемых лабораторных нужен новый scope; сохранять карту компетенций, проверки отказов, примеры отзывов и EN/RU | Текущий аудит источников/покрытия; дальнейший пилот может уточнить изменения. Избегать близких дублей; редакционные примеры отличимы от банка интервью |
| P3.2 — оставшееся чтение и ответы | Заполнены исходные пробелы чтения всего банка, включая 37 Leadership-записей; добавлены 18 EN/RU-ответов к выбранным приоритетам. Чтение есть у всех текущих вопросов; остальные записи только с планом остаются кандидатами дальнейшего расширения ответов | Исправления P1 и проверка соответствия источников; содержание не зависит от отложенных лабораторных. Чтение укрепляет обучение, не атрибуцию; не выдумывать профессиональную историю, результат или уровень |
| P3.3 — независимое подтверждение компаний | Искать официальные материалы интервью и датированные рассказы участников, особенно Head/Director и AI TPM. Фиксировать роль, полномочия/scope, дату, доступ и независимость; перечитывать сконцентрированные или стареющие утверждения | Пробелы аудита и существующая проверка свежести. Вакансия не доказывает вопрос; две страницы одного издателя не независимы. Записывать отсутствие и недоступность вместо заявления о покрытии |
| P3.4 — печатное расширение | Решить, включать ли новые руководства и проверенную практику в книги; регенерировать после content review, проверить извлечённый текст и каждую страницу | Стабильное проверенное содержимое и PDF workflow. Локальные артефакты не релиз; публикация — отдельное решение |
Необязательный AI-оценщик остаётся за пределами текущей итерации и не требуется для P1 или P2. Перед его рассмотрением нужны проверенные людьми примеры, проверки разногласий и критических ошибок, возможность оспорить отзыв, границы хранения, стоимости и prompt injection. Балл модели не становится hire/no-hire или подтверждённым уровнем. Экспорт упражнений, новые схемы/CLI и интерфейс прогресса также требуют доказанной потребности и отдельного scope; ручной маршрут работает без них.
Распределение работы и ревью¶
Для дальнейшего расширения использовать gpt-6.1-sol для инженерной реализации и обычных проверок кода, gpt-6-astra для сложной публичной прозы, смыслового аудита и независимого финального content review, gpt-6-luna для ограниченного извлечения и механических проверок. Это назначения задач, не сравнение цен или benchmark-возможностей. Одновременно не более четырёх агентов; параллельны только непересекающиеся файлы или чтение. Зависимости и интеграция выполняются последовательно.
Финальный reviewer содержимого работает в отдельной сессии от каждого автора/редактора проверяемой прозы. Самопроверка или новая метка той же сессии не подходят. Соблюдайте flagship-требование активной среды; отсутствие нужной модели блокирует задачу, а не переименовывается. Сохраняйте прежние записи Claude и других авторов. Реальные модели/сессии, проверки источников и свидетельства ревью хранятся в приватных рабочих записях, без выдуманного публичного авторства.
Каждая передача реализации проходит проверки CONTRIBUTING: lint/format, тесты, проверку генерации, strict site и приватность worktree/index/history. Добавлять в staging только явные пути. Изменения scope, пробелы источников и проваленные критерии остаются видимыми. Публикацию или релиз проверенного результата сопровождающий решает отдельно.