spec-as-source-enforcement

Implementation completeness

An implementation is not complete until every file referenced by a [@test] annotation in the specs exists on disk.

Before declaring work done:

1. Read every spec.md in openspec/specs/.
2. Extract all [@test] paths.
3. Verify each file exists.
4. If any file is missing, create it or explicitly report the blocker.
5. Only when all files exist, proceed to work-review.

A missing [@test] is worse than a failing test: it is a requirement with no verification.

---

Target ownership

The targets field in a capability spec's frontmatter (openspec/specs/<capability>/spec.md) declares ownership: that spec is the authoritative source for those files.

Rules:

1. Every significant behaviour must be described in a spec.
2. Every requirement is identified by its free-text name in the ### Requirement: <name> header; names must be unique within a capability spec.
3. Every requirement must have at least one **Verified by**: [@test] <path> line, placed after its SHALL/MUST sentence (never as the first line of the block).
4. Every capability spec.md must declare its targets: in YAML frontmatter at the top of the file, before the # <Capability> Specification heading. A spec freshly created by openspec archive (no frontmatter yet) is not a violation by itself, but it must gain a targets: list before its first non-trivial edit.
5. Modifying a target file requires modifying its owning spec in the same commit or PR.
6. Generated target files must include a header: # GENERATED FROM SPEC: openspec/specs/<capability>/spec.md.
7. If spec, targets, and tests diverge, the CI must fail.

Do not add requirements not present in the spec. Do not declare work complete if tests are missing, targets are outdated, or requirements are unverifiable.