Illustrative workflow, not a live workspace result.
Decision
Members can edit their own profile
Acceptance criterion
Changes remain after reload
Missing reference
Persistence test
Next step
Add the test result
Requirements
Turn the brief into something a reviewer can check.
The decision, its acceptance criterion, the references behind it and the evidence it still needs, kept in one record instead of scattered through a conversation.
INT-142
Members can edit their own profile
AcceptanceChanges remain after reload
EvidencePersistence test
Referenceprofile/save.ts
StateUnverified
Next stepAdd the test result
Example requirement record. Your records hold your own decisions.
Why use Requirements?
When the requirement lives in a conversation, a reviewer has to reconstruct what was agreed. Keep the decision and its acceptance criteria in a record the next person can inspect.
Catch conflicting decisions
Find requirements that disagree before they become competing implementations.
Make review specific
Give a reviewer an observable behavior to check, rather than a broad instruction to make it work.
Keep changes accountable
Retain the decision history and references that explain why a requirement exists.
How Requirements fits your work
01
Describe the decision
Supply the accepted intent, constraints, and acceptance criteria.
02
Add the references
Include the implementation and evidence references relevant to the requirement.
03
Resolve the findings
Review conflicts, drift, and missing links before handing off the next task.
What to know before you start
The analysis uses the record you supply. It cannot establish behavior that has not been observed.