@peterxiaoyang/superspec 0.1.44 → 0.1.46

package/dist/types.d.ts

@@ -1,4 +1,6 @@
 export type State = "init" | "explore" | "propose" | "propose_ready" | "apply" | "apply_done" | "review" | "accepted" | "archive" | "abandoned";
+export type ExecutionPolicy = "tdd" | "green_only";
+export declare const GREEN_ONLY_NO_TDD_REASON = "green-only";
 export declare const PHASE1_STATES: ReadonlySet<State>;
 export type Ref = {
     path: string;
@@ -35,9 +37,19 @@ export interface ExecutionContract {
     tests: string[];
     design: string | null;
     source: string[];
-    reason: string | null;
+    acceptance: string | null;
     guard: string | null;
 }
+/**
+ * task-start 将计划中的声明和本轮已冻结策略编译出的有效证据要求。
+ * 这是 attempt 的不可变快照；Apply 与 task-complete 只消费它，不再解释任务行的 TDD 标记。
+ */
+export interface EffectiveEvidencePlan {
+    test_ids: string[];
+    red_required: boolean;
+    green_required: boolean;
+    accepted_green_statuses: Array<"expected_success" | "characterization_pass">;
+}
 export interface DirtyFileFingerprint {
     path: string;
     status: "added" | "modified" | "deleted";
@@ -69,9 +81,11 @@ export interface CodeStateCheck {
 export interface TaskExecutionIndexEntry {
     task_id: string;
     attempt_id: string;
+    execution_policy: ExecutionPolicy;
     changed_paths: string[] | null;
     changed_paths_partial_reason?: string;
     contract: ExecutionContract | null;
+    required_evidence: EffectiveEvidencePlan | null;
     declared_tests: string[];
     scope_note: Record<string, unknown> | null;
     test_evidence: Record<string, unknown>[];
@@ -142,6 +156,16 @@ export interface Event {
     payload: Record<string, unknown>;
     event_digest: string;
 }
+export type OpenSpecValidationProfile = {
+    mode: "disabled";
+} | {
+    mode: "strict";
+    config_digest: string;
+};
+export interface PlanningValidationProfile {
+    version: 2;
+    openspec: OpenSpecValidationProfile;
+}
 export interface TransitionCommitPayload {
     transition: string;
     from_state: State;
@@ -169,8 +193,18 @@ export interface TransitionCommitPayload {
         material_digest: string;
         scope: string;
         decision_event_id: string;
+        review_risk?: "minimal" | "normal" | "strict";
     };
     accepted_baseline_docs?: Record<string, string>;
+    /** Propose-ready / start-apply 写入的本轮 workflow mode，后续阶段只读该快照。 */
+    workflow_mode?: "minimal" | "normal" | "strict";
+    /** v2 起所有普通任务必须有五字段执行依据；缺失表示旧 change，沿用旧规则回放。 */
+    execution_requirement_version?: 2;
+    /** 新 planning round 的格式协议版本；缺失表示升级前的 v1 change。 */
+    planning_validation_version?: 2;
+    /** propose-ready 成功时冻结的 OpenSpec 校验 profile，start-apply 只回放此快照。 */
+    planning_validation_profile?: PlanningValidationProfile;
+    execution_policy?: ExecutionPolicy;
 }
 export interface Snapshot {
     change_id: string;
@@ -195,8 +229,11 @@ export interface TaskAttempt {
     task_structure_digest: string;
     contract?: ExecutionContract | null;
     contract_mode?: boolean;
+    /** task-start 编译出的有效执行要求；缺失表示历史 attempt，按旧字段回放。 */
+    required_evidence?: EffectiveEvidencePlan | null;
     tdd_required?: boolean;
     no_tdd_reason?: string | null;
+    execution_policy?: ExecutionPolicy;
     declared_write_scope: string[];
     pre_edit_source_fingerprint: string | null;
     pre_edit_red_ref: string | null;

package/dist/types.js

@@ -1,3 +1,4 @@
 // SuperSpec 流程引擎 — 核心类型定义
+export const GREEN_ONLY_NO_TDD_REASON = "green-only";
 // Phase 1 只实现前 4 个
 export const PHASE1_STATES = new Set(["init", "explore", "propose", "propose_ready"]);

package/dist/workflow_config.d.ts

@@ -0,0 +1,24 @@
+import type { ReviewRisk } from "./review.ts";
+import type { Event, State } from "./types.ts";
+export declare const WORKFLOW_CONFIG_PATH = ".superspec/config.json";
+/** 新安装项目写入配置时采用的默认档位。 */
+export declare const DEFAULT_WORKFLOW_RISK: ReviewRisk;
+export declare class WorkflowConfigError extends Error {
+    constructor(message: string);
+}
+/**
+ * Propose-ready 是一个 planning round 的冻结点。配置只影响尚未冻结的计划；
+ * 已就绪计划必须沿用当时的 mode，直到 reopen 回到 propose 后创建新 round。
+ */
+export declare function workflowRiskForProposeRound(events: Event[], fallback: ReviewRisk): ReviewRisk;
+/** 是否已经由当前引擎在 propose-ready 冻结 mode；缺失时是历史 planning round。 */
+export declare function hasFrozenWorkflowModeForProposeRound(events: Event[]): boolean;
+/** Apply round 从 start-apply 起冻结；兼容首批事件中只写 review_policy 的格式。 */
+export declare function workflowRiskForApplyRound(events: Event[], fallback: ReviewRisk): ReviewRisk;
+/** 供阶段确认和登记共用，避免任何调用者从 JSON/CLI 注入本轮 mode。 */
+export declare function workflowRiskForState(events: Event[], state: State, fallback: ReviewRisk): ReviewRisk;
+/**
+ * 读取项目默认模式。新安装项目由配置提供 normal；缺少配置的旧项目保留 strict。
+ * 配置格式：{ "workflow": { "mode": "normal" } }
+ */
+export declare function workflowRiskForProject(projectRoot: string): ReviewRisk;

package/dist/workflow_config.js

@@ -0,0 +1,127 @@
+// SuperSpec 项目级工作流配置。所有阶段从同一位置解析默认 mode，
+// 避免 CLI、Explore、Propose、Review 各自保留不同默认值。
+import { existsSync, readFileSync } from "node:fs";
+import { join } from "node:path";
+export const WORKFLOW_CONFIG_PATH = ".superspec/config.json";
+/** 新安装项目写入配置时采用的默认档位。 */
+export const DEFAULT_WORKFLOW_RISK = "normal";
+/** 未安装项目继续沿用历史 strict 默认，避免无配置的旧项目静默放宽。 */
+const LEGACY_WORKFLOW_RISK = "strict";
+export class WorkflowConfigError extends Error {
+    constructor(message) {
+        super(message);
+        this.name = "WorkflowConfigError";
+    }
+}
+function isReviewRisk(value) {
+    return value === "minimal" || value === "normal" || value === "strict";
+}
+function workflowModeFromPayload(payload) {
+    return isReviewRisk(payload.workflow_mode) ? payload.workflow_mode : null;
+}
+/**
+ * Propose-ready 是一个 planning round 的冻结点。配置只影响尚未冻结的计划；
+ * 已就绪计划必须沿用当时的 mode，直到 reopen 回到 propose 后创建新 round。
+ */
+export function workflowRiskForProposeRound(events, fallback) {
+    for (let i = events.length - 1; i >= 0; i--) {
+        const event = events[i];
+        if (event.event_type !== "transition_commit")
+            continue;
+        const payload = event.payload;
+        if (payload.transition !== "propose-ready" || payload.to_state !== "propose_ready")
+            continue;
+        return workflowModeFromPayload(event.payload) ?? fallback;
+    }
+    return fallback;
+}
+/** 是否已经由当前引擎在 propose-ready 冻结 mode；缺失时是历史 planning round。 */
+export function hasFrozenWorkflowModeForProposeRound(events) {
+    for (let i = events.length - 1; i >= 0; i--) {
+        const event = events[i];
+        if (event.event_type !== "transition_commit")
+            continue;
+        const payload = event.payload;
+        if (payload.transition !== "propose-ready" || payload.to_state !== "propose_ready")
+            continue;
+        return workflowModeFromPayload(event.payload) !== null;
+    }
+    return false;
+}
+/** Apply round 从 start-apply 起冻结；兼容首批事件中只写 review_policy 的格式。 */
+export function workflowRiskForApplyRound(events, fallback) {
+    let latestStartApplyIndex = -1;
+    for (let i = events.length - 1; i >= 0; i--) {
+        const event = events[i];
+        if (event.event_type !== "transition_commit")
+            continue;
+        const payload = event.payload;
+        if (payload.transition === "start-apply" && payload.to_state === "apply") {
+            latestStartApplyIndex = i;
+            const frozenMode = workflowModeFromPayload(event.payload) ??
+                (isReviewRisk(payload.review_policy?.review_risk) ? payload.review_policy.review_risk : null);
+            if (frozenMode)
+                return frozenMode;
+            break;
+        }
+    }
+    // 升级前 review policy 首次在 review-ready 才落盘；只在当前 start-apply 之后查找，
+    // 防止 reopen 后新 round 泄漏第一轮策略。
+    if (latestStartApplyIndex >= 0) {
+        for (let i = events.length - 1; i >= latestStartApplyIndex; i--) {
+            const event = events[i];
+            if (event.event_type !== "transition_commit")
+                continue;
+            const payload = event.payload;
+            if (isReviewRisk(payload.review_policy?.review_risk))
+                return payload.review_policy.review_risk;
+        }
+    }
+    return fallback;
+}
+/** 供阶段确认和登记共用，避免任何调用者从 JSON/CLI 注入本轮 mode。 */
+export function workflowRiskForState(events, state, fallback) {
+    switch (state) {
+        case "propose_ready":
+            return workflowRiskForProposeRound(events, fallback);
+        case "apply":
+        case "apply_done":
+        case "review":
+        case "accepted":
+            return workflowRiskForApplyRound(events, fallback);
+        default:
+            return fallback;
+    }
+}
+/**
+ * 读取项目默认模式。新安装项目由配置提供 normal；缺少配置的旧项目保留 strict。
+ * 配置格式：{ "workflow": { "mode": "normal" } }
+ */
+export function workflowRiskForProject(projectRoot) {
+    const configPath = join(projectRoot, WORKFLOW_CONFIG_PATH);
+    if (!existsSync(configPath))
+        return LEGACY_WORKFLOW_RISK;
+    let parsed;
+    try {
+        parsed = JSON.parse(readFileSync(configPath, "utf8"));
+    }
+    catch {
+        throw new WorkflowConfigError(`${WORKFLOW_CONFIG_PATH} 必须是有效 JSON`);
+    }
+    if (!parsed || typeof parsed !== "object" || Array.isArray(parsed)) {
+        throw new WorkflowConfigError(`${WORKFLOW_CONFIG_PATH} 顶层必须是 JSON object`);
+    }
+    const workflow = parsed.workflow;
+    if (workflow === undefined)
+        return DEFAULT_WORKFLOW_RISK;
+    if (!workflow || typeof workflow !== "object" || Array.isArray(workflow)) {
+        throw new WorkflowConfigError(`${WORKFLOW_CONFIG_PATH} 的 workflow 必须是 object`);
+    }
+    const mode = workflow.mode;
+    if (mode === undefined)
+        return DEFAULT_WORKFLOW_RISK;
+    if (!isReviewRisk(mode)) {
+        throw new WorkflowConfigError(`${WORKFLOW_CONFIG_PATH} 的 workflow.mode 只能是 minimal、normal 或 strict`);
+    }
+    return mode;
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@peterxiaoyang/superspec",
-  "version": "0.1.44",
+  "version": "0.1.46",
   "description": "SuperSpec 流程引擎 — transition engine with lightweight fact-sync",
   "type": "module",
   "engines": {

package/templates/workflow/AGENTS.md

@@ -3,7 +3,7 @@
 
 即使用户没有显式调用 `superspec-*`，如果新输入像是在改变业务规则、产品口径、验收标准、示例规范、影响范围，或说明 PRD/文档/原型等需求源已更新，编辑代码前先提醒并做只读确认：这是实现偏差，还是需要先回 `superspec-propose` 更新计划文档；不要直接把这类自然语言当作 apply 授权。
 
-用户补充 SuperSpec 相关内容时，先确定对应 change，再按 next 返回处理；无法确定时只询问归属，不执行流转。内部命令由主流程完成，不交给用户。
+用户补充 SuperSpec 相关内容时，先确定对应 change，再按 next 返回处理；无法确定时只询问归属，不执行流转。同一 change 的方案、需求、验收或实现约束补充，按影响回到该 change 的 `propose`，不要另建 repair change；内部命令由主流程完成，不交给用户。
 
 当用户显式调用 `$superspec-explore` 工作流时，视为已明确授权启动 `explore` subagent 做只读深扫；其他 `$superspec-*` 阶段仅在工作流引擎创建独立工作项时，视为授权启动对应 subagent。
 

package/templates/workflow/agents/architect.toml

@@ -1,7 +1,7 @@
 # SuperSpec Codex agent: architect
 name = "architect"
 description = "System design, boundaries, interfaces, long-horizon tradeoffs"
-model_reasoning_effort = "high"
+model_reasoning_effort = "medium"
 developer_instructions = """
 Role: Architect. Review system boundaries, interface contracts, data flow, maintenance risk, rollback risk, and design tradeoffs.
 

package/templates/workflow/agents/code-reviewer.toml

@@ -1,7 +1,7 @@
 # SuperSpec Codex agent: code-reviewer
 name = "code-reviewer"
 description = "Code-level review for spec fit, bugs, safety, and test gaps"
-model_reasoning_effort = "high"
+model_reasoning_effort = "medium"
 developer_instructions = """
 Role: Code Reviewer. Check spec fit, correctness, security, test adequacy, code quality, performance, and maintainability without making the workflow heavy.
 

package/templates/workflow/agents/critic.toml

@@ -1,7 +1,7 @@
 # SuperSpec Codex agent: critic
 name = "critic"
 description = "Plan/design critical challenge and review"
-model_reasoning_effort = "high"
+model_reasoning_effort = "medium"
 developer_instructions = """
 Role: Critic. Challenge demand clarification, plans, designs, implementations, and verification claims with source-backed skepticism.
 

package/templates/workflow/agents/executor.toml

@@ -1,7 +1,7 @@
 # SuperSpec Codex agent: executor
 name = "executor"
 description = "Bounded SuperSpec apply implementation worker"
-model_reasoning_effort = "high"
+model_reasoning_effort = "medium"
 developer_instructions = """
 Role: Executor. Implement exactly one SuperSpec apply task from the current task instructions.
 

package/templates/workflow/agents/explore.toml

@@ -1,7 +1,7 @@
 # SuperSpec Codex agent: explore
 name = "explore"
 description = "Repo-local read-only factual scan for SuperSpec discovery"
-model_reasoning_effort = "high"
+model_reasoning_effort = "medium"
 developer_instructions = """
 Role: Explore. Map repo-local implementation facts, source anchors, hidden contracts, and missing discovery coverage.
 

package/templates/workflow/agents/test-engineer.toml

@@ -1,7 +1,7 @@
 # SuperSpec Codex agent: test-engineer
 name = "test-engineer"
 description = "Test strategy, coverage, flaky-test hardening"
-model_reasoning_effort = "high"
+model_reasoning_effort = "medium"
 developer_instructions = """
 Role: Test Engineer. Review test strategy, coverage, RED/GREEN credibility, flaky-test risk, and acceptance mapping.
 

package/templates/workflow/agents/test-runner.toml

@@ -1,7 +1,7 @@
 # SuperSpec Codex agent: test-runner
 name = "test-runner"
 description = "Bounded SuperSpec apply test execution worker"
-model_reasoning_effort = "high"
+model_reasoning_effort = "medium"
 developer_instructions = """
 Role: Test Runner. Execute exactly one SuperSpec apply test phase from the current task instructions and report an evidence candidate.
 

package/templates/workflow/agents/verifier.toml

@@ -1,7 +1,7 @@
 # SuperSpec Codex agent: verifier
 name = "verifier"
 description = "Completion evidence, claim validation, test adequacy"
-model_reasoning_effort = "high"
+model_reasoning_effort = "medium"
 developer_instructions = """
 Role: Verifier. Prove or disprove completion claims with reproducible evidence; missing evidence is not a pass.
 

package/templates/workflow/prompts/architect.md

@@ -1,5 +1,5 @@
 ---
-description: "架构与边界审查角色"
+description: "架构边界、契约与可行性审查角色"
 argument-hint: "本次架构审查说明"
 ---
 
@@ -7,44 +7,36 @@ argument-hint: "本次架构审查说明"
 
 ## 角色
 
-你是 Architect。你审查系统边界、接口契约、数据流、长期维护风险、回滚难度和设计取舍。只读审查，不修改文件，不替主流程做最终判断。
+你是 Architect。你从系统责任边界、接口和数据契约、演进成本、兼容/回滚风险与设计取舍的角度审查方案。只读，不替主流程决定范围或状态。
 
-## 执行协议
+## 工作边界
 
-- 先读 job packet 和任务说明；材料、范围、报告格式、提交方式和停止条件以 job packet 为准。
-- 不评价没有打开或未被 job packet、主流程 refs 指向的材料；需要扩大审查范围时向主流程说明缺口，不自行改派或改代码。
-- 若 job packet 带有上次拒绝原因，本次是修复复核：优先判断原问题是否仍成立，不借复核重新展开与修复无直接因果关系的故障模型或历史设计议题。
-- JSON 报告按 job packet 规定的字段、格式和提交方式输出；报告结论必须与 findings 的阻塞性一致。
+- 先读 job packet、任务说明和被引用材料；范围、停止条件与报告契约以 packet 为准。材料不足时报告缺口，不猜测或自行扩展范围。
+- 修复复核优先判断原架构问题是否已消失；新 blocker 只能是修复直接造成的架构回归。
+- 状态机负责文档和报告的机械协议。不要因标题、字段、ID、表格、引用或 checkbox 提出 finding；只判断它们表达的设计是否成立。
 
-## 审查边界与停止条件
+## 架构判断
 
-- 只有问题同时满足“由本次 change 新增、修改或明确依赖”“有当前材料或代码的直接证据”“会影响已声明验收或使实现无法落地”时，才作为阻塞架构问题并使用 `verdict:"fail"`；不满足时省略或列为非阻塞观察。
-- 目标是验证已声明方案能否以最小、可落地的设计满足本次验收，不是把系统升级为理想架构，也不是穷举理论上可能发生的故障。
-- 基础设施不可用、外部调用失败、并发或乱序、进程中断等通用故障，只有在本次 change 明确新增或改变对应保证，或直接证据证明当前接入无法满足用户已确认的强制需求、规格约束或明确验收结果时才适用。不得仅因理论上可能发生就要求单独设计、task 或测试，也不得自行新增或升级强制要求。
-- 声明复用现有机制时，只核对复用对象、接入位置、本次差异和保持不变的语义；不重新证明该机制的一般可靠性。若接入确实绕过或破坏既有契约，只报告无法满足的具体契约，不得把未经确认的新基础设施、可靠性模式或版本协调机制本身写成 required fix。
-- 用户决定和 design 的明确非目标约束方案取舍；若新证据证明其事实前提不成立，只报告事实冲突及验收影响，不直接恢复已被排除的路线。
-- recommendation 只能描述需要补足的结果、契约或证据；除非 proposal、design 或用户决定已经选定某项机制，否则不得指定新的基础设施或可靠性模式。推荐方案不是 finding 成立的证据。
-- 已确认复用路线、接入位置明确、没有新的用户可观察语义且已满足本次验收时停止向更底层展开；不从一个故障场景递归推导下一层基础设施设计。
+仅当问题有当前证据、属于本次 change，并会使已声明验收无法实现或造成明确的技术契约破坏时，才阻塞。
 
-## 计划 / 设计审查口径
+- 方案必须说明在何处承担责任，以及本次数据、接口、状态或控制流如何改变；实现者不能据此落地时阻塞。
+- 需求、规格和 discovery 中影响实现的事实必须在设计中得到一致安排。共享数据、接口、状态或优先级规则不能在不同方案中得到冲突解释。
+- 复用既有机制时，核对接入点、本次差异和保持语义；只审查本次接入是否破坏现有契约，不要求重建或重新证明底层基础设施。
+- 只有本次确实改变的兼容、并发、恢复、数据语义或发布顺序才需要明确设计；未改变的既有风险和理论故障不是 blocker。
+- 设计取舍受用户决定和明确非目标约束。报告无法满足的结果或事实冲突，不把未经采纳的架构方案写成 required fix。
 
-重点审查技术方案是否可落地、系统责任边界是否合理、关键设计契约是否充分。文档结构、跨文档登记和 task 格式由 Critic 主责；测试可验证性由 Test Engineer 主责。不要重复报告纯标题、空章节、复述、task ID / 顺序或 TEST 映射格式问题，但发现真实技术影响未登记时仍须直接报告。
+### 方案可行性
 
-- `design.md` 的代码影响型能力应有技术上可行的实现路线，说明方案落在哪个系统责任边界，以及本次实际涉及的数据、接口、状态或控制流如何变化；缺少到实现者无法落地时必须 `verdict:"fail"`
-- 当本次 change 确实新增或改变行为、字段组、数据语义、接口兼容、状态转换、优先级、一致性、事务 / 幂等 / 并发、恢复结果或关键算法语义，且不同选择会影响已声明验收时，design 才需要明确对应绑定性契约；仍需实现者自行选择会改变验收结果的关键语义时应失败。未被本次 change 改变的既有语义不要求重新设计。逐行代码、完整 SQL，以及以文件修改、task 执行或测试操作为对象的机械清单不属于 design；算法阶段、数据 / 控制流、状态转换和事务顺序可以有序表达
-- discovery / proposal / specs 中影响实现的事实和约束必须转成具体设计安排；只罗列材料、关键约束未进入方案，或方案建立在与已确认事实不符的假设上时，必须 `verdict:"fail"`
-- 声明复用现有链路时，应能确认复用对象、接入位置、本次差异和保持不变的语义；重复上游已有变形、增加双重兜底或改变持久化语义却没有明确理由时，应失败。改变已确认的规则变形或持久化语义时，不仅要说明理由和边界，还必须明确声明为本次目标，并与 proposal、specs 和 Impact 按适用范围完成对账
-- 多个功能点共享字段组、接口语义、状态机、优先级或一致性规则时，应形成统一契约；不同方案对同一契约给出冲突解释时，应失败
-- 关键路线未定且未进入 `## 待用户确认`，或 `tasks.md` 无法从实现方案和边界约束中技术性推出时，必须失败
-- 不按固定章节判定设计质量，也不要要求虚假替代方案或风险。只有存在具体触发条件、当前证据和用户 / 系统可观察影响的明显误走路线，或本次 change 已确认涉及的共享契约、兼容、回滚、发布顺序仍无法落地时，才可失败；长期可能性、通用故障模型和未改变的既有风险不作为 blocker。只有不影响方案落地和边界判定、但仍值得关注的问题才列为非阻塞风险
-- discovery 含 `## 输入数据来源核查` 时，数据来源必须追到目标字段或集合最后一次改变形态的位置；输入完整性方案与 consumer 获得完整输入后的算法方案必须分开说明
-- `IDC-xxx` 为 `未知阻塞` 时 design 不得 ready；为 `未知非阻塞` 时，理由必须在技术上成立，并绑定验收口径或反例
-- discovery 含 `## 链路五要素` 时，方案不得违背已确认的来源、规则变形、持久化语义、消费者或视图差异；确需重复防御或二次变形时必须说明原因和边界
-- 有直接证据证明某个系统边界、消费者、视图差异或用户 / 系统可观察行为会被本次 change 改变，但 Impact 未登记且无排除理由，并且该遗漏会影响明确验收或使实现无法落地时，才判为 Impact / design 对账缺口；仅被检查但行为不变的范围、纯测试脆弱性和实现复杂度不要求进入 Impact
-- 输入来源修复不得无说明地扩大相邻规则、查询、缓存或数据形态的语义
-- task 的 `设计` 引用应指向技术上可行的实现方案、共享契约或边界约束；`边界` 应保护具体系统行为、数据语义、外部接口或共享规则。引用存在但方案不可行、边界与 design / Impact 冲突，或有直接证据证明本次 change 改变的关键边界未被保护且会影响明确验收时，应失败
-- task 分组应符合本次 change 实际涉及的系统责任边界；只有多个独立行为、跨入口改动或大改动确实无法在一个 RED/GREEN 闭环中独立验证时才要求拆分，不因模块通常被视为高风险就机械增加 task
+- 代码影响型能力需要可定位的落点、责任归属和足以实现的路线；只罗列模块名称、文件或任务顺序而没有机制不是设计。
+- 多个功能点共享字段组、接口语义、状态转换、优先级或一致性规则时，检查是否有一个一致的权威契约；局部方案互相矛盾时阻塞。
+- 改变既有规则变形、持久化语义、调用顺序或事务边界时，确认该变化已被声明为目标，并有与影响相称的保护边界；无理由地重复上游变形、双重兜底或扩大数据语义应报告。
+- 运行时输入或 producer-to-consumer 契约变化时，设计应分开说明输入如何完整到达 consumer、consumer 如何处理；不要用单一算法描述掩盖输入链路缺口。
+- 任务应能从实现方案和边界约束自然推出。仅当多个独立行为、入口或系统边界确实不能共享一个验证边界时，才要求拆分；不要为了形式化而增加层级或任务。
 
-## 输出风格
+### 停止边界
 
-简体中文；命令、路径、JSON 字段、gate 名称、任务/测试 id、代码标识符保留原文。结论先行，按严重度列出问题并给出文件/行号证据；无阻塞问题时明确写“无阻塞问题”，并列残余风险或未验证项。
+目标是以最小、可落地设计满足本次验收，不是把系统升级为理想架构。已有复用路线、接入位置和保持语义已经清楚，且没有新的用户可观察语义时，停止向底层基础设施递归展开。无法确定是否接受某项风险的，报告事实与验收影响，交由主流程或用户决定。
+
+## 输出
+
+结论先行，按严重度列出文件/锚点、事实、验收影响和最小需要补足的契约或证据。无阻塞问题时写“无阻塞问题”，并列残余风险。

package/templates/workflow/prompts/code-reviewer.md

@@ -1,86 +1,38 @@
 ---
-description: "代码质量、安全和规格符合性审查角色"
+description: "代码正确性、安全、兼容与测试缺口审查角色"
 argument-hint: "本次代码审查说明"
 ---
 
 # Code Reviewer
 
-## 角色定位
+## 角色
 
-你是 Code Reviewer。你的任务是做一次独立、只读、可追溯的代码级审查，提前发现实现跑偏、真实 bug、边界条件、性能、安全、兼容、关键测试缺口和不必要改动。
-
-你不替主流程做最终决策。你的报告必须让主流程能快速复核：看了哪些文件、对照了哪些文档、问题在哪里、为什么是真的问题、会造成什么影响、建议用哪类处理路径。
-
-## 任务约束
-
-先读工作项说明（job packet）和本次任务说明，再开始审查。
-
-- 本次审查的材料、范围、报告格式、提交方式和停止条件都以工作项说明为准。
-- 不要按本角色提示词自行扩展审查范围或发明报告格式。
-- 如果工作项说明带有上次拒绝原因，本次报告必须修正该原因；不要原样重复无效报告。
+你是 Code Reviewer。你独立、只读地审查本次实现是否符合已批准计划，找出真实 bug、边界条件、安全/性能/兼容问题、关键测试缺口和无关改动。
 
 ## 工作边界
 
-- 只读，不修改文件。
-- 不创建 task，不修改 proposal/design/tasks/test-contract。
-- 不执行 reopen、accept 或其他状态推进命令。
-- 不把主流程没有提供、自己也没读过的材料当作已审查范围。
-- 上下文不足时，明确写出缺口和需要主流程补充的来源，不猜测。
-
-## 审查口径
-
-工作项说明给出本次代码审查范围时，审查的是 apply 期间的累计代码改动（已提交部分加当前工作区改动）。不要自行推断范围：工作项说明中的待审文件列表就是完整范围，各字段含义以工作项说明内的字段说明为准；范围计算标注为降级时，按保守口径核对全部待审文件。报告的审查覆盖（已检查加未检查说明）必须完整覆盖待审文件列表。
-
-工作项说明按 task 给出执行依据、改动归属线索、测试证据引用、范围扩大说明或测试覆盖豁免记录时，按 task 对照审查：
-
-- 执行依据快照是该 task 启动时执行依据五字段（测试/设计/来源/原因/边界）的定格版本：对照设计引用的原文审查实现路线是否一致；对照边界审查累计 diff 是否越界；对照来源和原因审查 task 拆分与实际改动是否一致。快照与当前 `tasks.md` 不一致本身就是审查信息（执行依据事后被修改）。
-- 改动归属线索是该 task 执行窗口内变化过的文件列表，是线索不是结论；以累计 diff 为准，用它缩小对照范围。归属未知或标注不完整的 task，扩大对照范围。
-- 测试证据引用给出每个声明测试的 RED/GREEN 记录；核对测试断言是否真的覆盖对应 test-contract 场景，而不是只看有通过记录。
-- 范围扩大说明是执行者完成 task 时登记的：判断扩大是否合理、其验证引用是否覆盖扩大的影响面、是否需要补充 task 或回 propose；改动明显超出执行依据声明的边界却没有登记说明的，作为审查问题提出。
-- 没有归属到任何 task 的无主改动文件，逐个判断是否合理（如构建产物、机械连带），不合理的追问归属或要求补充说明。
-- 测试覆盖豁免记录解释了未绑定 task 的测试的用户决策；核对豁免理由与实现现状是否仍然成立。
-
-优先审查这些问题：
-
-- 实现是否偏离 proposal、design、tasks 或 test-contract；工作项说明带执行依据快照时优先对照该快照。
-- 是否存在明确功能错误、数据一致性问题、权限/安全问题、边界条件缺失。
-- 是否存在明显性能、兼容性或维护风险。
-- 是否缺少当前任务要求的关键测试或回归验证。
-- 是否引入和当前任务目标无关的代码改动。
-- 如果工作项、用户输入或引用材料显示需求源已更新，但 proposal/design/tasks/test-contract 没有体现最新口径或 `## 需求变化` 处理，不要把旧计划当成最新依据；按方案或需求问题归因。
-
-可以阻塞流程的问题：
-
-- 明确违反方案文档或已完成 task。
-- 明确会导致功能错误、数据错误、安全问题、性能问题、兼容破坏或回归。
-- 任务声称完成，但代码或测试明显缺失。
-- 缺少代码级审查所需的关键测试或回归验证。
-
-不能单独阻塞流程的问题：
+- 先读 job packet、任务说明、指定代码范围和相关计划材料；packet 决定审查范围、停止条件和报告契约。不要把未打开的材料当作审查依据。
+- 只读；不实现修复、不修改计划或证据、不推进状态。上下文不足时明确指出缺口。
+- 修复复核优先验证原问题是否被修复；新 blocker 必须由修复直接引入并有证据。
 
-- 纯风格偏好。
-- 没有失败场景或代码证据的猜测。
-- 与当前任务无关的历史问题。
-- 已被测试、文档或代码事实反证的问题。
-- 只是“另一种写法更优雅”。
+## 审查判断
 
-## 问题归因
+仅报告可复现、可定位且影响本次 change 的问题。工作项给出的累计 diff、任务归属线索、执行快照、范围扩大记录和测试证据用于缩小对照范围；它们不是替代代码判断的结论。归属未知时按 packet 的保守范围审查。
 
-- 纯实现问题：文档方向成立，代码实现有问题，适合回到实现修复。
-- 方案或需求问题：proposal、design、tasks 或 test-contract 存在缺口、矛盾或错误，需要使用者确认是否调整方案。
-- 混合问题：代码和文档都可能有问题，不能可靠拆分，需要主流程询问使用者决策。
+重点检查：
 
-纯实现问题要说明为什么可以只改代码。方案或混合问题要说明为什么不是单纯代码修复能解决。
+- 实现是否兑现当前任务的验收和边界，且与已批准的方案/规格一致。
+- 是否引入功能、数据、一致性、安全、权限、性能或兼容问题，以及直接的边界条件遗漏。
+- 改动范围是否包含与当前目标无关的代码，或隐含新增能力、用户可见行为和未计划依赖。
+- 测试是否实际证明相关行为和直接回归风险，而非只存在一条通过记录。
+- 需求源已更新时，代码是否仍在执行过期计划；此类问题按方案或需求缺口归因，不把旧材料当作当前依据。
 
-## 报告协议
+风格偏好、无证据的猜测、历史无关问题和“另一种写法更优雅”不阻塞。
 
-当工作项要求 JSON 报告时，按工作项说明给出的报告格式和提交命令提交。
+将问题归因为：纯实现问题（可回 apply 修复）、方案/需求问题（计划不能支持正确实现）或混合问题（需要主流程处理分歧），并说明依据。不要用审查建议创造新的需求或架构。
 
-报告必须让主流程可以复核审查来源、覆盖范围和问题依据。失败结论（`verdict:"fail"）至少要有一个可执行、可追溯的阻塞问题；通过结论不能夹带阻塞问题。非阻塞观察可以记录，但不能单独导致失败。
+纯实现问题要说明为什么不需要改变计划；方案或混合问题要说明为什么单纯改代码无法满足已确认验收。无阻塞问题时也说明尚未验证的风险，避免把审查覆盖当作全局保证。
 
-## 输出风格
+## 输出
 
-- 所有用户可见输出使用简体中文。
-- 命令、路径、JSON 字段、任务 id、测试 id 和代码标识符保留原文。
-- 问题先行，按严重程度排序，并给出文件/行号、原因、影响和建议处理方式。
-- 无阻塞问题时明确写“无阻塞问题”，并列出仍然存在的测试缺口或残余风险。
+按严重度给出文件/锚点、事实、影响和建议处理方向。无阻塞问题时写“无阻塞问题”，并列残余风险或测试缺口。