Add failure-first design review

Author: Redwarx008

.agents/skills/design/SKILL.md

@@ -27,12 +27,13 @@ Read [references/user-facing-decision-cards.md](references/user-facing-decision-
 6. For affected production integration/call paths, interfaces/contracts, data structures/state, and data ownership/flow, obtain the user's confirmation or explicit delegation. Repository evidence constrains a proposal but does not replace that choice.
 7. For every affected architecture, data structure, or data flow, distinguish inspected current-state evidence from target proposals. Put target trees/flow trees and illustrative code under the recommended or alternative option that they describe. After selection, write only the selected artifacts into Design. Keep uniquely determined or reversible detail to the shortest wording that preserves the decision; give irreversible boundaries, contracts, ownership, and flow the required artifacts.
 8. After each resolution, update the selected final Design section. Do not preserve internal IDs, question history, discarded approaches, user-authorization state, or a duplicate execution record.
+9. After the selected architecture, integration, interfaces, data structures, and flow are coherent, run one evidence-grounded failure-first review before the Ready gate. Inspect the real project areas most likely to fail, choices likely to accumulate technical debt, contracts that must remain stable, internals that must remain replaceable, implementation principles needed to preserve the design, and tempting shortcuts that must be prohibited. For each material conclusion establish `project evidence -> causal failure mechanism -> consequence -> preventive design constraint`. Do not invent generic risks or create headings merely to complete a checklist. If prevention requires a non-unique choice, use one normal decision card; otherwise integrate only the selected constraint or guardrail into its relevant Design section. Do not retain the raw pre-mortem, rejected shortcuts, or resolved speculation.
 
 Design decisions include architecture, components, production wiring, interfaces, data structures, state transitions, ownership, data flow, failure behavior, compatibility, and validation. Act may choose only mechanical execution order. Reject unrelated refactors and speculative requirements. For a visual question, follow [references/visual-companion.md](references/visual-companion.md) and obtain consent before starting it.
 
 ## Ready gate
 
-Run the Design contract. Do not become Ready while a material decision is awaiting the user, a repository fact needed to evaluate a material decision is missing, or an implementation-shaping question remains. Do not fill gaps with assumptions.
+Run the Design contract. Do not become Ready while a material decision is awaiting the user, a repository fact needed to evaluate a material decision is missing, an implementation-shaping question remains, or a project-grounded failure/debt risk lacks a selected prevention. Do not fill gaps with assumptions.
 
 When the gates pass:
 

.agents/skills/design/assets/design.md

@@ -6,7 +6,9 @@
 
 <!-- State the problem, observable success criteria, included work, and non-goals. -->
 
-## Constraints
+## Constraints and Implementation Guardrails
+
+<!-- Keep only applicable, project-evidence-backed constraints: contracts that must remain stable, internals that must remain replaceable, implementation principles, and prohibited shortcuts. State the failure mechanism when a guardrail would otherwise appear arbitrary. -->
 
 ## Selected Design
 

.agents/skills/design/references/design-contract.md

@@ -6,11 +6,14 @@ Keep:
 
 - problem, success criteria, scope, non-goals, and constraints;
 - the selected architecture, boundaries, components, integration path, interfaces, data structures, data flow, failure/compatibility behavior, and validation that actually apply;
+- project-evidence-backed implementation principles and prohibited shortcuts that materially protect the selected design, with a compact failure mechanism where the guardrail would otherwise appear arbitrary;
 - required selected trees, flow trees, and illustrative code;
 - a compact rationale only where the selected choice would otherwise be surprising or hard to reverse.
 
 For each new or materially changed component, make its boundary inspectable: purpose, consumers, owned data/state, dependency direction, stable contract, and which internals may change without breaking consumers. Scale each affected section to decision impact: write uniquely determined or reversible detail in the shortest sufficient form, while retaining required trees, flow trees, and illustrative code for architecture, data structures, and data flow.
 
+Before readiness, review the coherent selected design from the failure side. Ground every material conclusion in the current project's production paths, ownership, lifecycle, compatibility, resource, migration, or other relevant evidence. Trace `evidence -> causal failure mechanism -> consequence -> prevention`; then keep only the prevention that shapes the final design. Do not preserve a generic risk checklist, speculative hazards, or rejected shortcuts.
+
 Do not keep empty or `N/A` headings, internal IDs, question history, coverage/impact tables, raw research notes, authorization state, amendments, or discarded approaches. A rejected option belongs only in an ADR when its rejected rationale is durable context under the project's ADR rules.
 
 ## Readiness check
@@ -19,6 +22,7 @@ Design is ready for user review only when:
 
 - it describes one coherent selected design with no implementation-shaping ambiguity;
 - every affected architecture, data structure, and data flow is inspectable through the required selected artifacts;
+- material project-grounded failure and debt risks have selected prevention, with stable contracts distinguished from deliberately replaceable internals;
 - success criteria and validation evidence are observable;
 - all headings carry final, relevant content; and
 - it contains no placeholder, contradictory statement, process ledger, or discarded option.

.claude-plugin/marketplace.json

@@ -4,13 +4,13 @@
     "name": "Redwarx008"
   },
   "description": "Agent Workflow Kit marketplace for Claude Code.",
-  "version": "0.3.0+codex.20260715093430",
+  "version": "0.3.0+codex.20260717050706",
   "plugins": [
     {
       "name": "agent-workflow-kit",
       "source": "./",
       "description": "A decision-complete Design, adaptive Act, and independent Review workflow for coding agents.",
-      "version": "0.3.0+codex.20260715093430",
+      "version": "0.3.0+codex.20260717050706",
       "author": {
         "name": "Redwarx008"
       }

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-workflow-kit",
-  "version": "0.3.0+codex.20260715093430",
+  "version": "0.3.0+codex.20260717050706",
   "description": "A decision-complete Design, adaptive Act, and independent Review workflow for coding agents.",
   "author": {
     "name": "Redwarx008",

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-workflow-kit",
-  "version": "0.3.0+codex.20260715093430",
+  "version": "0.3.0+codex.20260717050706",
   "description": "A decision-complete Design, adaptive Act, and independent Review workflow for coding agents.",
   "author": {
     "name": "Redwarx008",

docs/reference-lessons.md

@@ -20,4 +20,5 @@ Visual Companion 保留上游已加固的 session key、同源 WebSocket、路
 
 - Review 必须读取共享工作区，不能因隔离而错过未提交实现。
 - 验证按任务类型选择，尤其不能用普通单元测试替代 GPU/视觉证据。
+- Design 在方案成形后执行一次基于项目证据的逆向失败审视：从真实调用链和所有权推导失败机制、技术债、稳定契约、可替换内部、实现原则与禁止捷径。最终 Design 只保留会约束实现的预防措施，不保存通用风险清单或推演过程。
 - 通用工作流应提供门禁和模板，但项目自己的领域规则、资源版本控制和用户明确要求始终优先。