Карта источников (source map) — таблица, в которую выписаны все документы, репозитории, переписки и разговоры, откуда берутся требования к задаче. Первый артефакт метода и самый недооценённый: выглядит как инвентаризация, работает как предохранитель. Разбор на сквозном кейсе: интеграция с платёжным провайдером, пять источников, две недели до старта разработки. Кейс учебный, провайдер вымышленный, расхождения типовые. Исходные данные S01. Документация вендора 2.1, 47 страниц. Внешний владелец, март 2026. Актуальна, базовый источник истины. S02. Страница в Confluence «Интеграция v1». Владелец ушёл из компании, апрель 2025. Устарела, описывает несуществующую версию. S03. Git-репозиторий прототипа. Команда бэкенда, май 2025. Устарел как реализация, полезен как ответ на «что уже пробовали». S04. Почтовый тред с поддержкой, пять писем. Ведёт аналитик, март 2026. Актуален, но контрактом не является. S05. Устная договорённость о сроках с продактом, 20 марта 2026. Нигде не зафиксирована. Четыре колонки из пяти аналитик заполняет механически. Последняя, «связи и противоречия», требует сопоставления и забирает основное время. Колонка противоречий Расхождения не видны при последовательном чтении. Каждый документ по отдельности выглядит связным. Увидеть их можно только тогда, когда два источника стоят рядом. Что дала эта колонка на кейсе: S01 против S02: auth token, customer_id и base URL расходятся в трёх местах. S01 против S04: время жизни токена, сутки в документации против четырёх часов в переписке. S01 против S03: прототип не реализует проверку подписи вебхуков. S04 в одиночку: ограничение в 100 запросов в минуту упомянуто только в письме поддержки. Последняя строка показывает отдельный класс проблем: утверждение существует ровно в одном источнике, и источник этот неформальный. Формально спора нет, опереться на цифру всё равно нельзя. Что попало в открытые вопросы Q01. Время жизни auth token: сутки или четыре часа? К поддержке вендора. Q02. Поле customer_id обязательно всегда или только для регулярных платежей? К поддержке вендора. Q03. Ограничение по частоте запросов — контракт или дефолт, который может измениться? К поддержке вендора. Q05. Дедлайн жёсткий или ориентир? К продакту, зафиксировать письменно. Q06. Кто отвечает за PCI compliance? Не покрыт ни одним источником. Четыре вопроса из шести адресованы наружу, ответ занимает от двух до пяти дней. Отправлять их нужно в день составления карты, иначе две недели до старта разработки уйдут в ожидание. Пробелы Отдельно от расхождений карта фиксирует темы, которых нет ни в одном источнике. Поведение при недоступности провайдера: сценарий отказа не описан нигде. Обработка возвратных платежей: ни в документации, ни в переписке. Требования регуляторики к логированию платежей. Параметры повторной отправки вебхуков: в документации сказано «экспоненциальная задержка», без единого числа. Ни одна не выглядит срочной в первый день. Все четыре всплывают на приёмке, когда менять архитектуру дороже всего. Цена вопроса 25 минут на карту, из них 15 на последнюю колонку. Последовательное чтение тех же пяти источников заняло бы день, и три расхождения из пяти остались бы незамеченными. Отложенный эффект важнее прямого. Каждое требование получает адрес, и через месяц на вопрос «почему это поле обязательное» вы отвечаете ссылкой за пятнадцать секунд. Куда ведёт дальше Карта источников открывает цепочку метода: source map → System Context Pack → Review Findings → Task Pack. System Context Pack — структурированный контекст проекта, где каждое утверждение подкреплено цитатой источника. Review Findings — собранные расхождения, пробелы и риски. Task Pack — заготовка постановки с открытыми вопросами и критериями готовности. Порядок здесь не декоративный. Пока карта не составлена, любой следующий артефакт наследует расхождения источников и делает их невидимыми. Шаблон Пустой шаблон в Markdown и CSV, заполненный пример на разобранном кейсе, чек-лист типовых ошибок: analystcraft.ru/coworker/templates