feat(workflows): enforce research checkpoints across development phases
This commit is contained in:
1 parent
fe7a4d7a25
commit
3586245408
12 files changed
+19
-10
No files matched your search
@@ -10,7 +10,7 @@ Use when an answer, report, or implementation decision depends on claims that ne
|
||||
## Workflow
|
||||
|
||||
1. Break the statement into atomic claims that can be checked independently.
|
||||
2. Choose evidence suited to each claim: current source, executable output, authoritative documentation, primary research, or direct measurement.
|
||||
2. Choose evidence suited to each claim: current source, executable output, authoritative documentation, primary research, or direct measurement. For external technology claims, MUST apply the verification checkpoint in `technical-research`, inspecting matching evidence or resolving gaps through its Context7-first workflow.
|
||||
3. Prefer the source closest to the fact. Check dates, versions, and applicability when the claim can change over time.
|
||||
4. Compare conflicting evidence and explain any difference in scope or version rather than silently selecting one.
|
||||
5. Label the result as confirmed, contradicted, inferred, or unknown. Keep confidence proportional to evidence quality.
|
||||
|
||||
@@ -10,7 +10,7 @@ Use when deciding whether a completed change satisfies a defined work item or re
|
||||
## Workflow
|
||||
|
||||
1. Read the objective, scope boundaries, acceptance criteria, and material constraints.
|
||||
2. Map each criterion to direct evidence: changed files, observable behavior, command output, test result, or user-confirmed outcome.
|
||||
2. Map each criterion to direct evidence: changed files, observable behavior, command output, test result, or user-confirmed outcome. For criteria relying on external technology behavior, MUST apply the verification checkpoint in `technical-research`; check the actual supporting sources and version against the implementation, not merely whether a lookup occurred.
|
||||
3. Mark each criterion as met, unmet, or unverified. Do not treat a successful build as proof of unrelated behavioral criteria.
|
||||
4. Confirm the implementation stayed within scope and did not leave generated output, documentation, or consumers inconsistent.
|
||||
5. Record known limitations, unresolved decisions, and checks that could not run.
|
||||
|
||||
Reference in new issue
Block a user