# Bootstrap

## Purpose

Use this domain for the 0 -> 1 move: a project that has no coding-agent harness
yet needs its first navigation, specification, validation, and risk routes. It
describes the shape of the artifacts a team should establish first; it does not
own instruction taxonomy, verification runtime, or repeated-work owner
selection.

## Best-Practice Baseline

An agent fails at the start of a task far more often than at the end of one. The
usual cause is not a weak model but an underspecified request: no scope, no data
contract, no rule ids, no acceptance boundary. Bootstrap therefore treats the
specification as the first harness asset, ahead of any tooling.

A specification is agent-executable when an implementer never has to guess. Each
behavior carries a stable id, each exception names the surfaced message and the
error code behind it, and each acceptance criterion states an observable
`Given / When / Then` a reviewer can run. Prefer one complete specification for
a narrow scope over a broad document that leaves every third decision open.

## Load When

- The user explicitly asks for initial coding-agent project guidance and the
  project has no established navigation, validation, or risk route.
- A requirement is about to enter implementation and its written form is not yet
  complete enough for an agent to build against.
- A team disagrees about what "the spec is done" means, or reviews keep
  rediscovering the same missing sections.
- A specification exists for one delivery surface and a second surface is being
  added.

## Owns

- `spec-structure.md`: the required specification sections, stable `BR-*`,
  `E-*`, and `AC-*` id schemes, per-surface repetition, traceability rules,
  completeness gates, and anti-patterns.
- `examples/README.md`: stack-specific calibration examples for a backend
  service, a frontend web console, and a mobile application.

## Does Not Own

- Agent instruction files, host asset taxonomy, or instruction quality; use
  `../agent-customize/routing.md` and `../agent-customize/agents-md-review.md`.
- Verification harness design, acceptance controls, observability, or recovery
  evidence; use `../project-harness/` and
  `../project-harness/agent-verify-loop.md`.
- Durable owner selection for repeated work; use `../loop-engineering/`.
- Support-track selection, finding eligibility, severity, or report authority.
  Those stay with the Better Harness skill and its findings gates.
- Design documents that describe an existing system. A specification states the
  intended behavior of a change; use `../project-harness/design-md-contract.md`
  for durable system design.

## Read Next

- Start with `spec-structure.md` whenever the question is what a complete
  specification must contain.
- Use `examples/README.md` after the contract is understood and a concrete
  section needs calibration against a comparable stack.
- Continue to `../agent-customize/routing.md` once the specification shape is
  settled and the project needs its instruction and asset owners.
- Continue to `../project-harness/agent-verify-loop.md` when acceptance criteria
  need an executable verification path rather than a written boundary.