Quickstart — RENAR за 30 минут

Один сквозной пример: маленький проект «email/password sign-up». Проходим полный цикл RENAR с минимальным набором артефактов: ТЗ → ADAPT → BR → SR → SPEC → TC. Время: ~30 минут чтения + проб на бумаге; ~2-3 часа если делать вживую на substrate. Предпосылки: знакомство с RENAR Core (5 правил + ADAPT + 2 QG).

Что вы получите

После этого quickstart у вас будет:

  • Понимание полного цикла RENAR на одном маленьком примере.
  • Готовые YAML-шаблоны для каждого типа артефакта.
  • Опыт прохождения двух Quality Gates: QG-ADAPT-approve и QG-2 verified-by-TC.
  • Точка для масштабирования на реальный проект.

Предпосылки

Substrate — система хранения и версионирования артефактов. RENAR substrate-agnostic; для quickstart подойдёт любой substrate с capabilities V1-V6 (01-glossary §2.7):

  • git с PR-ревью (default для большинства проектов);
  • Raven (документная БД с встроенными подписями);
  • любая БД с историей и подписями.

Структура папок (default convention для git substrate):

my-project.req/
  tz/                   # immutable ТЗ от клиента
  adapt/                # ADAPT артефакты
  br/                   # Business Requirements
  sr/                   # System Requirements
  specs/                # SPEC-* семейство
    arch/  api/  data/  ui/  sec/  ai/  proc/  int/  ops/
  tests/                # TC и INT-TC

Для других substrate — эквивалентная организация по doc-types или namespaces.

Шаг 1. ТЗ (5 минут)

Клиент даёт небольшое ТЗ. Это договорной immutable документ — после подписания не редактируется.

tz/TZ-2026-001.md (фрагмент):

---
id: TZ-2026-001
title: "Регистрация пользователей через email"
signed-date: "2026-05-15"
signed-by-client: "Иванов И.И., PM, ClientCo"
---

# ТЗ-2026-001

## §1. Контекст
Создать систему регистрации пользователей по email.

## §2. Требования
- Пользователь может зарегистрироваться через email и пароль.
- После регистрации пользователь подтверждает email (получает письмо).
- После подтверждения — доступ в личный кабинет.

## §3. Ограничения
- Только web-приложение.
- Хранение в РФ (ФЗ-152).

ТЗ подписано клиентом → immutable. Все правки и интерпретации идут через ADAPT.

Шаг 2. Draft ADAPT (10 минут)

Создаём adapt/ADAPT-001-main.md. AI-агент или инженер заполняет Forward (как поняли) и Backward (что неясно).

---
id: ADAPT-001
title: "Адаптация ТЗ-2026-001 — Регистрация через email"
type: ADAPT
source-tz:
  id: TZ-2026-001
  signed-date: "2026-05-15"
  signed-by-client: "Иванов И.И., PM, ClientCo"
  document-ref: "<substrate-ref-pin>"
status: draft
created: "2026-05-16"
ai-provenance:
  generated-by: "anthropic-claude-opus-4-7@2026-05-16"
  prompt-template: "prompts/adapt-from-tz.md@v1.0"
  context-tokens: 1024
  output-tokens: 2048
  human-edits: false
---

2.1 Forward

## Forward §2 Требования

**Цитата:** «Пользователь может зарегистрироваться через email и пароль.
После регистрации пользователь подтверждает email. После подтверждения —
доступ в личный кабинет.»

**Интерпретация:** Регистрация — POST /auth/sign-up с {email, password}.
Создаётся User со status `unverified`. Отправляется email с verification
link. Клик по link → status `verified`. Только `verified` могут войти.

**Достроенные сценарии:**
- sign-up: создание User в `unverified`, отправка email
- email verification: подтверждение → перевод в `verified`
- первый вход: только `verified` → редирект в личный кабинет

**Scope:**
- Входит: email/password, email verification, доступ в личный кабинет.
- НЕ входит: OAuth (Google/Apple), SMS-верификация, 2FA, сброс пароля.

**Forward links** (auto-populated после approval): BR-01, SR-01, SR-02, SR-03.

2.2 Backward (3 записи)

## Backward

### B-001: gap — попытка входа неверифицированного

- **Категория:** gap
- **Статус:** open
- **Описание:** ТЗ не описывает поведение системы при попытке входа
  до верификации email.
- **Вопрос к клиенту:** показывать сообщение «подтвердите email» с кнопкой
  повторной отправки — или возвращать 401 без объяснения?

### B-002: regulatory — ФЗ-152 хранение в РФ

- **Категория:** regulatory
- **Статус:** open
- **Описание:** ТЗ §3 требует «хранение в РФ». Что конкретно: дата-центр,
  юрисдикция provider'а, отдельная инсталляция?
- **Вопрос к клиенту:** уточнить scope ФЗ-152 для проекта.

### B-003: gap — повторная отправка email

- **Категория:** gap
- **Статус:** open
- **Описание:** Что если verification email потерян? Можно ли отправить
  повторно, сколько раз, есть ли rate limit?
- **Вопрос к клиенту:** policy на повторную отправку email.

Шаг 3. Approved ADAPT (5 минут)

Клиент даёт ответы. Каждая backward запись проходит lifecycle:

open → asked-to-client → answered → resolved → frozen (после approval)

Резюме после ответов клиента:

### B-001: resolved
- **Asked-to-client:** 2026-05-17
- **Ответ клиента:** 2026-05-18, Иванов И.И.:
  «Показать сообщение + кнопку повторной отправки. 401 без объяснения — плохой UX.»
- **Resolution:** добавлен сценарий в Forward §2; создан SR-04.

### B-002: resolved
- **Ответ клиента:** 2026-05-18:
  «Дата-центр в РФ, юрисдикция РФ. Provider — выбирает исполнитель.»
- **Resolution:** добавлен пункт в Forward §2 о data-residency: ["RU"].

### B-003: resolved
- **Ответ клиента:** 2026-05-18:
  «Повторная отправка не чаще 1 раза в 5 минут, не больше 5 раз в сутки.»
- **Resolution:** добавлены rate-limit правила в Forward §2; SR-04 уточнён.

Все backward → resolved, open-questions-count = 0. ADAPT готов к approval.

QG-ADAPT-approve — все 6 пунктов passed:

status: approved
approval:
  client-signature:
    signed-by: "Иванов И.И."
    role: PM
    organization: "ClientCo"
    signed-at: "2026-05-18T15:30:00Z"
    signature-ref: "<substrate-native-ref>"
  architect-signature:
    signed-by: "Петров П.П."
    role: architect
    signed-at: "2026-05-18T16:00:00Z"
ai-provenance:
  human-edits: true   # архитектор отредактировал AI-draft
open-questions-count: 0
resolved-questions-count: 3

После approval ADAPT immutable (frozen). Все BR/SR/SPEC ссылаются на approved ADAPT, не на ТЗ напрямую.

Шаг 4. BR-01 (3 минуты)

br/BR-01-user-registration.md:

---
id: BR-01
title: "Регистрация пользователей через email"
type: BR
status: approved
priority: must
source:
  adapt: "ADAPT-001"
  adapt-section: "Forward §2"
  tz-section: "§2"
business-context:
  stakeholder: "Иванов И.И. (PM, ClientCo)"
  business-goal: "Дать пользователям возможность создать аккаунт и получить доступ к продукту"
business-outcome:
  measurement-type: kpi
  kpi-name: "registration-conversion-rate"
  measurement-method: "registered / visited_signup * 100%"
  baseline-value: 0
  target-value: 60
  target-met-by: "2026-09-01"
data-classification:
  contains-pii: true
  retention-days: 2555     # 7 лет по ФЗ-152
  data-residency: ["RU"]
compliance:
  - { standard: "ФЗ-152", article: "ст.6,12" }
ai-provenance:
  generated-by: "anthropic-claude-opus-4-7@2026-05-18"
  human-edits: true
---

# BR-01: Регистрация пользователей через email

Пользователь должен мочь самостоятельно создать аккаунт через email/password
и получить доступ к личному кабинету после подтверждения email.

Шаг 5. SR-01..SR-04 (3 минуты)

Декомпозируем BR на verifiable SR. Каждый SR ссылается на approved ADAPT.

sr/SR-01-sign-up.md (frontmatter):

---
id: SR-01
title: "Sign-up через email/password"
type: SR
status: approved
parent:
  id: BR-01
source:
  adapt: "ADAPT-001"
  adapt-section: "Forward §2"
constrained-by:
  - "SPEC-API-01"
  - "SPEC-DATA-01"
  - "SPEC-SEC-01"
quality-characteristic:
  - functional-suitability
  - security
---

Тело SR-01:

## Описание
POST /auth/sign-up принимает {email, password}.
- При валидных данных: создаёт User со status `unverified`, отправляет
  verification email, возвращает 201.
- При невалидном email (regex/format): возвращает 422 с указанием поля.
- При уже занятом email: возвращает 409.
- При слабом пароле (< 8 chars или попадает в blacklist): возвращает 422.

Аналогично создаются SR-02 (email verification), SR-03 (вход для verified), SR-04 (повторная отправка email, с rate limit из B-003 resolution).

Шаг 6. SPEC-* (3 минуты)

specs/api/SPEC-API-01-auth.md (фрагмент):

---
id: SPEC-API-01
title: "REST API аутентификации"
type: SPEC-API
status: approved
source:
  adapt: "ADAPT-001"
api-style: rest
api-version: "v1.0.0"
versioning-strategy: url-path
authentication: bearer-jwt
rate-limits:
  - { endpoint: "POST /auth/resend-email", limit: "1/5min/user; 5/24h/user" }
contract-file:
  format: openapi-3.1
  location: "contracts/auth-api.yaml"
depends-on:
  - "SPEC-DATA-01"
  - "SPEC-SEC-01"
referenced-by: ["SR-01", "SR-02", "SR-03", "SR-04"]   # auto-derived
---

Аналогично — SPEC-DATA-01 (схема User), SPEC-SEC-01 (auth model + ФЗ-152 controls).

Шаг 7. TC pos/neg парность (5 минут)

Каждый SR — минимум 1 позитивный + 1 негативный TC.

tests/TC-01-signup-success.md (позитивный для SR-01):

---
id: TC-01
title: "Sign-up: успешная регистрация"
type: system
status: ready
verifies:
  - id: SR-01
    requirement-version: "1.0"
negative: false
automation:
  status: automated
  location: "tests/auth/test_signup.py::test_signup_success"
  runner: pytest
---

## Given
- новый email (uniquely-generated@test.com)
- валидный password (длина ≥ 8, не в blacklist)

## When
POST /auth/sign-up {email, password}

## Then
- status 201
- response body содержит {"user_id": "<uuid>", "status": "unverified"}
- в БД создан User с status `unverified`
- отправлен verification email (mock)

tests/TC-02-signup-invalid-email.md (негативный для SR-01):

---
id: TC-02
title: "Sign-up: отклонить невалидный email"
type: system
status: ready
verifies:
  - id: SR-01
    requirement-version: "1.0"
negative: true
automation:
  status: automated
  location: "tests/auth/test_signup.py::test_signup_invalid_email"
  runner: pytest
---

## Given
- email "not-an-email" (без `@`)
- любой валидный password

## When
POST /auth/sign-up {email, password}

## Then
- status 422
- response body {"field": "email", "error": "invalid format"}
- User в БД НЕ создан
- email НЕ отправлен

Аналогично пары для SR-02, SR-03, SR-04. Дополнительно для SR-04 (с rate limit) — TC, проверяющий блок после 5-й попытки за 24 часа.

Шаг 8. Запустить TC и promote SR (2 минуты)

Substrate-нативный test runner запускает TC, обновляет last-run:

# tests/TC-01-signup-success.md (после прогона):
last-run:
  date: "2026-05-19T10:00:00Z"
  result: pass
  ci-run-url: "<substrate-native-ref>"
  agent-run-id: "test-runner-001"
  requirement-version: "1.0"

Когда все TC из SR-01.verified-by[] зелёные, проводится spot-check (Правило 5 Core) — инженер вручную запускает 1-2 случайных passing TC и сверяет результат с SR.

Если spot-check passed → QG-2 verified-by-TC passed → SR-01 переводится в verified:

# sr/SR-01-sign-up.md:
status: verified
verified-by:
  - "TC-01"
  - "TC-02"
verified-at: "2026-05-19T14:00:00Z"
verified-by-engineer: "Петров П.П."

Аналогично — SR-02, SR-03, SR-04 → verified. Когда все SR в BR-01 verified → QG-4 (BR ready for acceptance).

Trace chain

В любой момент можно восстановить происхождение любого артефакта:

TC-02 (negative)
  └─ verifies SR-01 (sign-up)
       └─ derived from ADAPT-001 §2 Forward (email/password)
             └─ interprets TZ-2026-001 §2 (immutable)
       └─ constrained-by SPEC-API-01 (REST contract)
                                 └─ depends-on SPEC-DATA-01, SPEC-SEC-01

При аудите через год: «откуда взялось требование возвращать 422 на невалидный email» — TC-02 → SR-01 → ADAPT-001 §2. Trace полный.

Что вы только что сделали

  • Создали immutable договорной артефакт (ТЗ).
  • Прошли двустороннюю интерпретацию через ADAPT с тремя backward findings → клиент дал ответы → approved.
  • Декомпозировали в BR + 4 SR, привязанные к approved ADAPT.
  • Описали 3 SPEC (API, DATA, SEC) как параллельную ось структуры.
  • Покрыли каждый SR pos+neg TC парой (минимум 8 TC).
  • Прошли два Quality Gates: QG-ADAPT-approve и QG-2 verified-by-TC.

Это полный цикл RENAR в минимальной форме. На реальном проекте scaling — больше BR/SR/SPEC, больше backward findings, делегирование на AI-агентов, дополнительные QG-3 (verification) и QG-4 (acceptance).

Что дальше

Хотите…Документ
Детальный walkthrough на полноразмерном примере (login + profile + permissions)01-walkthrough.md
Переход с legacy подхода (просто ТЗ → код) на RENAR02-transition-guide.md
Git как substrate (commit-policy, PR-ревью, hooks)03-tool-guide-git.md
Raven как substrate (документная БД, подписи через API)04-tool-guide-raven.md
Сравнение RENAR с SAFe / BABOK / ISO 2914805-safe-comparison.md
Compliance: GDPR, ФЗ-152, AI Act mapping06-compliance.md
Failure modes — типовые провалы и их паттерны07-failure-modes.md
Полная нормативная спецификация (15 глав)standard/
Схемы артефактов и validation rulesreference/02-schemas.md
Глоссарий и mapping на отраслевые стандартыreference/01-glossary.md

Quickstart RENAR 1.0-draft — renar.tech