Skip to content

Feature specification

Goal and scope

Users, problem, non-goals and learning outcomes (LOs).

Interview traceability

Interview ID / approved equivalent-material ID -> requirement ID -> acceptance criteria ID -> test ID. Do not include real names.

Acceptance criteria

Given input, action, expected result, boundaries and failure paths. Each criterion must support executable verification.

Implementation and verification

Generate an approach -> have a human check its assumptions -> implement in the dedicated workspace described by Week 0 safety practices -> retain acceptance and regression evidence.

Before implementation, add two scope tables and one location note to the plan:

  1. Changed files: list every file with its relevant path:line (or new for a new file). Only the files in this table may be changed; update the table and obtain another scope check before adding a file.
  2. Tests to write: list each test separately and map it to exactly one acceptance case and its expected result. Every acceptance case must have a named test; a generic “run the suite” entry is not a substitute.
  3. Specification location and update: record where this specification, its plan and decision record live, and how a code change keeps those records and acceptance tests synchronized for the next session.

Risks and review

Data minimization, permission boundaries, unresolved questions and review results. Refer to existing PR or review evidence; do not submit a separate teaching-design form.

Change log

One entry per agreed change to an acceptance criterion: the date, the changed clause, the acceptance-case and test IDs it affects, the reason and who agreed. Update those tests' expected results from the new clause first, then the code; never edit a check only to make existing code pass.