R1.1: Tasks 5

Spec-gate — это “ворота”, через которые описание может быть повышено до спецификации в FPF по E.10.D2.

Идея простая: не всякий подробный документ является спецификацией. Документ можно назвать …Spec только если он уже не просто объясняет, а задает проверяемые правила, по которым можно сказать: “прошло / не прошло”.

В E.10.D2 Spec-gate требует четыре вещи:

  1. F >= F4
    Текст выражен достаточно строго: ключевые утверждения можно прочитать как явные предикаты, условия, инварианты или ограничения. Не просто “делай хорошо”, а проверяемое “если X, то Y; запрещено Z; допустимо только при A/B/C”.

  2. Проверяемые инварианты
    Есть правила, которые можно falsify/check: например, “каждое интервью должно содержать минимум 5 past-event anchored answers” или “interviewer talk time <= 25%”.

  3. Acceptance harness
    Есть связанный механизм проверки: чеклист, SCR/RSCR матрица, тестовый протокол, audit sheet, evaluator rubric — что-то, что применяет эти правила к конкретному случаю.

  4. Явный U.BoundedContext
    Спецификация локальна: понятно, в каком контексте эти правила действуют. Например: FPF_AI_CEO_JTBD_Research_Context, а не “вообще для всех интервью”.

Поэтому твой документ сейчас — сильный MethodDescription: он объясняет метод и дает хорошие критерии. Но он еще не MethodSpec, потому что критерии не оформлены как полный набор обязательных проверяемых инвариантов с приемочным механизмом.

Пример перехода:

MethodDescription: “Интервьюер должен говорить мало и вытаскивать past-event evidence.” MethodSpec: Invariant MS-01: interviewer_talk_time_ratio <= 0.25. Invariant MS-02: count(past_event_anchored_answers) >= 5. Invariant MS-03: count(unredirected_hypothetical_answers) = 0. Acceptance harness: PostInterviewAuditSheet v1 applies MS-01..MS-03 to each interview transcript.

Вот это уже проходит Spec-gate, если контекст явно назван и формальность достаточна.

◇ ctx: 43K | 157K left | 22% | ●

11:39

поясни эти понятия: инвариант, SCR/RSCR матрица Давай сделаем из этого описания спецификацию. Что нам надо добавить?

11:41

Инвариант
Инвариант — это правило, которое должно оставаться истинным для объекта в заданном контексте.

Не “хорошая рекомендация”, а проверяемое условие.

Примеры для интервью:

INV-01: Длительность интервью должна быть в диапазоне 45-60 минут. INV-02: Доля речи интервьюера должна быть <= 25% времени. INV-03: В каждом интервью должно быть извлечено >= 5 ответов, привязанных к прошлым событиям. INV-04: Неперенаправленных гипотетических ответов должно быть 0. INV-05: Вопросы о цене не должны раскрывать целевую цену продукта.

Если после интервью мы можем взять запись/транскрипт/analysis sheet и сказать “pass/fail”, это хороший инвариант.

SCR / RSCR Матрица
SCR — static conformance review: проверка, соответствует ли конкретный объект спецификации прямо сейчас.

Для твоего случая: проверяем один проведенный interview run или один interview script перед использованием.

Пример SCR:

ID Rule Evidence Pass/Fail
SCR-01 Script has past-event anchor opener Script section 1 Pass
SCR-02 Script includes no pitch/demo language Opener Pass
SCR-03 Post-interview sheet captures persona evidence Analysis section Pass

RSCR — regression/static conformance review: повторная проверка после изменений, чтобы не сломать уже достигнутые свойства.

Для твоего случая: если ты меняешь script после 3 интервью, RSCR проверяет, что новая версия не потеряла важные guards.

Пример RSCR:

ID Regression Risk Check
RSCR-01 Новый script стал pitch-heavy В opener по-прежнему нет demo/pitch
RSCR-02 Убрали past-event anchoring В каждом блоке остались past-event probes
RSCR-03 Persona split стал навязанным James/Michael language остается listen-for, not prompt

Что Надо Добавить
Чтобы превратить описание в MethodSpec, нужно добавить 6 вещей:

  1. Named Context
    Например:

Context: UC_AI_CEO_JTBD_Research_2026 Method: CEO_AI_JTBDInterview Object kind: U.MethodSpec

  1. Spec Scope
    Что именно специфицируется:

This specification governs founder-led JTBD/persona-validation interviews with CEOs of operating companies for AI adoption/product discovery.

  1. Formal Invariants
    Переписать ключевые рекомендации как обязательные проверяемые правила: duration, recruitment, talk ratio, past-event count, redirect rules, analysis fields, intro commitment.

  2. Acceptance Harness
    Добавить проверочный артефакт: PostInterviewAuditSheet.

Минимальные поля:

interview_id persona_guess_before_call actual_persona_match interviewer_talk_ratio past_event_anchored_answers_count unredirected_compliments_count unredirected_hypotheticals_count prior_spend_evidence abandoned_solution 90_day_trigger commitment_obtained verdict: pass | fail | needs_repair

  1. SCR Matrix
    Проверка самого script и каждого interview run: прошел ли он правила.

  2. RSCR Matrix
    Проверка после изменений версии script: не потеряли ли мы discipline Mom Test / JTBD / persona validation.

Самая короткая версия перехода:

Description: “Вот как проводить интервью.” Spec: “Интервью считается conformant только если выполнены INV-01..INV-12, проверенные через PostInterviewAuditSheet v1; изменения script должны пройти RSCR-01..RSCR-08.”

Главная добавка: не больше текста, а проверяемость. Нужно, чтобы любой третий человек мог взять запись интервью и audit sheet и независимо сказать: “это интервью прошло спецификацию” или “нет”.