docs(brainstorm-with-docs): уточнены границы артефактов по внешнему ревью

- Зачем:
  - внешнее ревью выявило риск двойной записи решений (spec/ADR) и
    терминологическую путаницу; правки документные, поведение не меняют.
- Что:
  - adr.md и spec.md: добавлен lifetime-критерий ADR vs spec (ADR — для
    решений, переживающих спеку; локальные остаются в спеке).
  - spec.md: разведены Options considered (до выбора) и Decisions (после).
  - SKILL.md: блок <validation> переименован в <self_review>, чтобы не
    путать с секцией ## Validation в spec.md.
  - README.md: честнее описано авто-срабатывание на Codex.
  - SKILL.md: у SEAM зафиксирован TODO(F1) про строку дивергенции
    (отложена ради чистого baseline на обкатке).
- Проверка:
  - python3 yaml-парс frontmatter; нет висячих ссылок на <validation>.
This commit is contained in:
ddadmin committed 2026-06-02 23:43:09 +03:00
1 parent 50640d8cb5
commit f24b342123
4 files changed
+37 -10

No files matched your search

@@ -33,7 +33,10 @@ Invoke manually:
On **Claude Code** the skill is manual-only (`disable-model-invocation: true`) —
it never auto-triggers; you always call it. On **Codex** that field is ignored
(Codex reads only `name` + `description`), so it may auto-trigger on matching
design tasks; the negative triggers in the description keep that disciplined.
design tasks. The negative triggers in the description discourage that, but the
description's positive surface is broad (architecture / DevOps / research), so
expect it to fire more eagerly on Codex than on Claude. If that gets noisy,
narrow the description.
## Layout
@@ -143,9 +143,16 @@ in [artifacts/context.md](artifacts/context.md) — don't batch them.
## 5. Synthesize options
<!-- SEAM: v2 will prepend a divergence phase (idea-generation toolkit +
"at least one option the user didn't already imply") before this
convergence step. Keep this step self-contained so it can be split. -->
<!-- SEAM / TODO(v2): prepend a divergence phase before this convergence step.
Full version = idea-generation toolkit (axis of variation, archetype
stances, inversion, steal-from-adjacent-domain, cost-shifting, pre-mortem,
constraint relaxation, null option).
TODO(F1): cheap pre-step — add one <core_rule>: "among the options, at least
one must be something the user did not already imply." Deliberately deferred
now to keep the v1 live-test baseline clean (we want to see how badly pure
convergence collapses into variations of one idea). Reconsider landing this
single line right after the first live test, before the full toolkit.
Keep this step self-contained so it can be split. -->
Present 2-3 viable approaches. For each: short description, when it fits,
benefits, trade-offs, risks, operational implications, documentation impact, and
@@ -178,7 +185,7 @@ Otherwise use the conventional homes — `CONTEXT.md` at the repo root, ADRs in
`docs/runbooks/`). If the location isn't obvious, propose a path and confirm it
as part of step 6 rather than guessing. Create directories lazily.
Then go to `<validation>` and `<stop_condition>`.
Then go to `<self_review>` and `<stop_condition>`.
</how_to_do_it>
@@ -198,7 +205,10 @@ runbook. If it's a validation rule for this work → the spec.
</shared_project_language>
<validation>
<self_review>
This is a review of the document itself — distinct from a spec's `## Validation`
section, which lists acceptance criteria for the implementation.
Before presenting the final artifact, review it for: unclear terms, missing
constraints, hidden assumptions, contradictions with existing docs, unnecessary
@@ -209,7 +219,7 @@ runbook, and context that does (or does not) belong in `CONTEXT.md`.
If it's too large, propose splitting it. If it's too vague, continue the
interview.
</validation>
</self_review>
<stop_condition>
@@ -18,6 +18,12 @@ If any of the three is missing, skip it. Easy to reverse → you'll just reverse
it. Not surprising → nobody will wonder. No real alternative → nothing to record
beyond "we did the obvious thing". Do not create an ADR for every small choice.
**Lifetime test (ADR vs spec).** A spec is transient — it describes what's being
built now and goes stale once the work is done. An ADR is durable — it outlives
the spec. So record a decision in an ADR only when it stays relevant *after* the
spec that introduced it is obsolete. Decisions local to the current work belong
in the spec's "Decisions and rejected alternatives" section, not here.
## Template
```markdown
@@ -40,6 +40,13 @@ add nothing for this particular problem — an empty section is noise.
## Notes on key sections
**Options considered vs Decisions.** Keep these two sections doing different jobs
so the rejected options aren't written twice. *Options considered* is the
landscape *before* the choice — the candidates and their trade-offs as they
stood. *Decisions and rejected alternatives* is the outcome *after* the choice —
what was picked and why each alternative was rejected. Frame in the first, judge
in the second.
**Decisions and rejected alternatives** is the highest-value section. Capture:
- accepted decisions and the reason behind each
@@ -48,9 +55,10 @@ add nothing for this particular problem — an empty section is noise.
- sequencing decisions
- assumptions future agents must not silently re-derive
Do not turn this section into an ADR dump. Promote a decision to its own ADR
(`artifacts/adr.md`) only when it is durable, surprising, and the result of a
real trade-off.
Do not turn this section into an ADR dump. Keep decisions that are local to this
work here; promote a decision to its own ADR (`artifacts/adr.md`) only when it is
durable, surprising, the result of a real trade-off, and will still matter after
this spec is obsolete (see the lifetime test in `artifacts/adr.md`).
**Validation** describes how we will know the implementation is correct — tests,
checks, acceptance criteria. It belongs here, not in `CONTEXT.md`.