GSD Core — Discuss-Plan-Execute-Verify Loop

# GSD core — methodology baseline

A four-step loop applied one phase at a time. The loop is the unit of
coordination between the human and the agent across multi-week work.

## The four steps

1. **Discuss** — clarify the scope of the upcoming phase. Surface every
 open question. Resolve each one into a written decision or an
 explicitly deferred ticket. Discussion ends only when the next step
 is unambiguous.
2. **Plan** — translate the discussed scope into ordered tasks. Each
 task names the files it touches, the verification it expects, and
 the requirement IDs it satisfies. Plans live in version control.
3. **Execute** — implement the plan, one task at a time, in the order
 the plan specifies. Each task ends with an atomic commit whose
 message names the phase and the task. Skipping ahead is a phase
 violation.
4. **Verify** — run the gates the phase declared at plan time. Build,
 test, type-check, content scan, sitemap diff. The phase is not done
 until every gate passes. Failures route back into discuss for the
 next phase, not silently into the current one.

## Locked decisions

Inside a phase, certain decisions are marked locked. A locked decision
is not negotiable for the duration of the phase. If the agent or the
human notices a reason to revisit it mid-phase, the reason gets
captured as a ticket for the next discuss step, not absorbed into the
current execution.

The locked-decisions list lives at the top of the phase context
document. Re-reading it before every task is the cheapest defence
against scope creep.

## REQ-ID traceability

Every requirement carries an identifier of the form `<DOMAIN>-NN` —
`AUTH-01`, `SKILL-04`, `UX-12`. Each ID maps to exactly one row in
the requirements document, and that row names the phase that ships it.
This is the chain that lets a six-month project still answer "where
does this live" in one search.

When a plan is authored, its frontmatter lists the requirements it
satisfies. When a phase ships, the requirement rows for those IDs flip
to done. Orphaned requirements — IDs without a phase — are visible
because the document highlights them.

## Deferred items have a home

Any idea that surfaces mid-phase but does not belong to the current
phase goes into `deferred-items.md` at the phase root. Not into chat,
not into a comment in the source, not into the agent's memory. The
file is part of the discuss input for the next phase.

Deferral is a first-class outcome, not a soft skip. The act of writing
the deferred item is what protects the phase from absorbing it.

## Banned-phrase scan

Every shipped artefact — generated rules file, prompt template, MDX
content, README — passes a substring scan that rejects vague phrasing:
`good practice` style language adds no information, dilutes the page
for SEO, and trains the agent to mimic the same vagueness back. The
scan runs in CI and fails the build deterministically.

## Goal-backward must-haves

Each plan opens with three goal-backward fields:

- **truths** — invariants that must be true after the phase ships.
- **artifacts** — files that must exist, with their minimum line counts
and required contents.
- **key links** — cross-references the new files must establish.

These are how the verify step distinguishes a phase that shipped from
a phase that compiled.