feat(workflows): enforce research checkpoints across development phases

This commit is contained in:
Julian lechner committed 2026-10-08 14:38:05 +02:00
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.