feat(engineering): Round 70 prompt contract standardization

Six-lens panel unanimously standardized all eight 02-engineering/
prompts with Purpose/Scope/Acceptance/Falsifiability contracts,
workflow-skill routing, and eval_harness anti-drift tests (80%+
floor). Mirrors Round 69 thinking-prompt pass; zh-TW templates
unchanged inside fenced blocks.

Author: johnteee

reflective-prompt-library/02-engineering/code-reviewer.md

@@ -2,6 +2,28 @@
 
 Use this to review a PR, diff, code sample, or AI-generated code against spec, acceptance criteria, tests, and risks.
 
+## Purpose
+
+Review diffs against spec, tests, and risks. Primary workflow surface: `reflective-review`; pair with `reflective-minimality` for complexity-only findings and `01-thinking/critical-thinking-check.md` for claim audits.
+
+## Scope
+
+- In scope: correctness, test integrity, architecture fit, spec traceability, required fixes.
+- Out of scope: writing the spec (`reflective-spec-plan`), implementing fixes (`reflective-implement`).
+
+## Acceptance Criteria
+
+- Spec traceability table completed.
+- Decision is Approve, Request changes, or Reject with non-empty required fixes when not Approve.
+
+## Falsifiability
+
+If no failing acceptance criterion can be tied to code or test evidence, state an explicit pass rationale (for example, lean already).
+
+## Human Review
+
+Escalate to `reflective-risk` when findings imply trust-boundary or high-blast-radius issues this review cannot sign off alone.
+
 ```markdown
 你是嚴格的 Code Reviewer。請不要只看程式是否能跑，請對照 spec、acceptance criteria、測試與風險。
 

reflective-prompt-library/02-engineering/implementation-agent.md

@@ -2,6 +2,29 @@
 
 Suitable for Codex, Cursor, OpenCode, Claude Code, and other repo-aware coding agents.
 
+## Purpose
+
+Repo-aware implementation with traceability. Primary workflow surface: `reflective-implement`; escalate to `reflective-risk` before trust-boundary or high-blast-radius changes.
+
+## Scope
+
+- In scope: minimal safe edits, tests per acceptance criterion, spec-to-code traceability, residual risk report.
+- Out of scope: spec authoring (`reflective-spec-plan`), complexity-only review (`reflective-minimality`).
+
+## Acceptance Criteria
+
+- Commands run and pass/fail reported.
+- Each acceptance criterion mapped to code and test evidence.
+- No weakened or deleted tests without explicit approval.
+
+## Falsifiability
+
+If tests pass but a stated acceptance criterion lacks code evidence, the task is not complete.
+
+## Human Review
+
+Escalate to `reflective-risk` for trust-boundary edits, data-loss paths, billing impact, or breaking public APIs.
+
 ```markdown
 You are an implementation agent.
 

reflective-prompt-library/02-engineering/local-feedback.md

@@ -2,6 +2,29 @@
 
 Use this when something fails.
 
+## Purpose
+
+Structured LOCAL_FEEDBACK loop for failures during implementation. Primary workflow surface: `reflective-implement`; escalate to `reflective-review` when the failure implicates spec or test adequacy.
+
+## Scope
+
+- In scope: step, evidence, root cause, correction, verification, anti-regression rule.
+- Out of scope: spec rewriting (`reflective-spec-plan`), formal blast-radius gating (`reflective-risk`).
+
+## Acceptance Criteria
+
+- Root cause separated from symptom.
+- Verification step names an observable pass signal.
+- Rollback decision explicit.
+
+## Falsifiability
+
+If the proposed correction cannot be verified with a named command or observation, treat it as hypothesis not fix.
+
+## Human Review
+
+Escalate to `reflective-risk` when rollback or correction implies trust-boundary or data-loss blast radius.
+
 ```markdown
 請用 LOCAL_FEEDBACK 流程分析錯誤。
 

reflective-prompt-library/02-engineering/spec-writer.md

@@ -2,6 +2,25 @@
 
 Use this to convert requirements into an implementable, testable, reviewable spec.
 
+## Purpose
+
+Convert requirements into an implementable, testable spec. Primary workflow surface: `reflective-spec-plan`. Pairs with `01-thinking/falsifiability.md` for hypothesis framing.
+
+## Scope
+
+- In scope: problem, goals, non-goals, requirements with acceptance criteria per REQ, edge cases, failure modes.
+- Out of scope: code changes (`reflective-implement`), complexity-only cuts (`reflective-minimality`).
+
+## Acceptance Criteria
+
+- Each functional requirement has acceptance criteria and a test idea.
+- Non-goals and open questions listed.
+- Owner sign-off points flagged when specs need human decision.
+
+## Falsifiability
+
+Name at least one REQ whose failure in a pilot would invalidate the proposed approach.
+
 ```markdown
 你是 Spec Writer。請將以下需求轉成可實作、可測試、可審查的 spec。
 

reflective-prompt-library/02-engineering/task-slicer.md

@@ -2,6 +2,24 @@
 
 Use this to split a spec into independent, testable, reviewable tickets.
 
+## Purpose
+
+Slice a spec into independently verifiable tickets. Primary workflow surface: `reflective-spec-plan`.
+
+## Scope
+
+- In scope: dependency graph, ticket boundaries, per-ticket acceptance criteria and risks.
+- Out of scope: implementation (`reflective-implement`).
+
+## Acceptance Criteria
+
+- Each ticket has goal, scope, acceptance criteria, tests, and parallelizable flag.
+- High-blast-radius work split into smaller tickets.
+
+## Falsifiability
+
+If two tickets must land together to verify anything, merge or re-slice until at least one vertical slice is independently testable.
+
 ```markdown
 你是 Task Slicer。請根據以下 spec，把任務切成可獨立實作、可測試、可 review 的 tickets。
 

reflective-prompt-library/02-engineering/task-start.md

@@ -2,6 +2,25 @@
 
 Use this at the start of a new task before implementation.
 
+## Purpose
+
+Establish a task brief before implementation. Primary workflow surface: `reflective-brief`; escalate to `reflective-spec-plan` when the brief is ready for ticket slicing. Pairs with `01-thinking/why-what-how-done.md` and `01-thinking/falsifiability.md`.
+
+## Scope
+
+- In scope: goal, assumptions, scope boundaries, acceptance criteria, falsifiability, minimal plan before coding.
+- Out of scope: repository edits (`reflective-implement`), formal blast-radius gating (`reflective-risk`).
+
+## Acceptance Criteria
+
+- Goal and scope in/out stated.
+- Acceptance criteria and falsifiability each named once.
+- Minimal next step and defer list included.
+
+## Falsifiability
+
+If the brief cannot name evidence that would prove the framing wrong, stop and clarify before planning.
+
 ```markdown
 請先不要直接實作。請先為以下任務建立任務規格：
 

reflective-prompt-library/02-engineering/test-designer.md

@@ -2,6 +2,24 @@
 
 Use this to design tests before implementation and prevent fake or weak tests.
 
+## Purpose
+
+Design tests from a spec without implementation. Primary workflow surface: `reflective-spec-plan` (Test Plan / acceptance coverage).
+
+## Scope
+
+- In scope: acceptance, edge, negative, regression, and anti-cheating test design.
+- Out of scope: writing implementation code in the repository (`reflective-implement`).
+
+## Acceptance Criteria
+
+- Every acceptance criterion has at least one test case with a failure signal.
+- Anti-cheating checks named for implementation-agent gaming patterns.
+
+## Falsifiability
+
+Name a test that would fail if the spec's happiest path hides a wrong invariant.
+
 ```markdown
 你是 Test Designer。請根據 spec 設計測試，不要寫實作。
 

reflective-prompt-library/02-engineering/usage-first.md

@@ -2,6 +2,24 @@
 
 Use this to avoid specs that look good but are awkward in practice.
 
+## Purpose
+
+Derive usage-driven spec fixes before implementation. Primary workflow surface: `reflective-spec-plan`; pair with `reflective-brief` when goals are still fuzzy.
+
+## Scope
+
+- In scope: personas, scenarios, I/O examples, confusion points, spec revisions from usage narrative.
+- Out of scope: code changes (`reflective-implement`).
+
+## Acceptance Criteria
+
+- At least five usage scenarios and both success and failure examples.
+- Spec revision recommendations tied to observed user confusion.
+
+## Falsifiability
+
+Name one scenario where the proposed UX would fail a naive user despite matching written requirements.
+
 ```markdown
 請假設這個系統已經完成，先不要寫實作，請先寫使用手冊。
 

reflective-prompt-library/PROJECT_KNOWLEDGE.md

@@ -75,6 +75,7 @@ deferred promotions are recurrence-gated — see [panel backlog](plans/multi-age
 > Pointers to the causal trail — plans, reflections, tests, commits. Detail is
 > not duplicated here; this is a map, not an archive.
 
+- 2026-06-25 Round 70 panel — standardize `02-engineering/` prompt contracts (Purpose/Scope/Acceptance/Falsifiability) + eval_harness anti-drift → [record](plans/multi-agent-panel-consensus-2026-06-25.md)
 - 2026-06-25 Round 69 panel — standardize `01-thinking/` prompt contracts (Purpose/Scope/Acceptance/Falsifiability) + eval_harness anti-drift → [record](plans/multi-agent-panel-consensus-2026-06-25.md)
 - 2026-06-25 Post-Round 68 holdout expansion — ROUTE-003 minimality trap + thin adversarial group refresh (15 groups / 53 phrases) → [QUALITY_GATES_SUMMARY.md](plans/QUALITY_GATES_SUMMARY.md)
 - 2026-06-11 Add `runtime-trust-boundary` as a lens, not a ninth skill → [record](plans/project-adjustment-reflection-2026-06-11.md)

reflective-prompt-library/plans/QUALITY_GATES_SUMMARY.md

@@ -314,7 +314,7 @@ ROUTE-002 measures unseen phrasing separately from ROUTE-001. Round 7 (2026-06-2
 2. **ROUTE-001/002/003 in CI** — 128 + 102 + 53 paraphrases at 100% consistency (seeded fixtures); `validate_route_fixture.py` gates minimum coverage
 3. **Governance validators** — links, lint, governance metadata, PROJECT_KNOWLEDGE, benchmark fixture, skill examples
 4. **Harness policy docs** — CONTRIBUTING, AGENTS, SKILL_INSTALLATION, maintenance playbook
-5. **Doc anti-drift** — `test_routing_contract.py`, cheatsheet parity tests, `test_readme_governance.py`, `test_thinking_prompts_eval_harness.py` (200+ pytest anti-drift suite in CI)
+5. **Doc anti-drift** — `test_routing_contract.py`, cheatsheet parity tests, `test_readme_governance.py`, `test_thinking_prompts_eval_harness.py`, `test_engineering_prompts_eval_harness.py` (220+ pytest anti-drift suite in CI)
 
 ### Ongoing maintenance (not blockers)