cc-devflow 4.3.0 → 4.4.1

package/.claude/skills/flow-verify/SKILL.md

@@ -1,53 +0,0 @@
----
-name: flow-verify
-description: 'Run layered quick/strict gates and emit report-card for a requirement. Use before release and after major dev changes.'
----
-
-# Flow-Verify Skill
-
-> [PROTOCOL]: 变更时更新此头部，然后检查 CLAUDE.md
-
-## Purpose
-
-执行质量门禁并输出 `report-card.json`，作为发布前唯一准入依据。
-
-## Input Format
-
-```bash
-/flow:verify "REQ_ID" [--strict] [--skip-review]
-```
-
-## Execution Steps
-
-1. 解析参数。
-2. 调用验证引擎：
-
-```bash
-npm run harness:verify -- --change-id "${REQ_ID}" [--strict] [--skip-review]
-```
-
-3. 读取并检查输出：
-   - `devflow/requirements/${REQ_ID}/report-card.json`
-   - `overall == "pass"` 才能进入 release
-
-## Gate Model
-
-- Quick Gate（默认）:
-  - lint
-  - typecheck
-  - test
-- Strict Gate（`--strict`）:
-  - test:integration（如存在）
-  - npm audit
-  - codex review（可 `--skip-review`）
-
-## Exit Criteria
-
-- `report-card.json` 生成成功
-- 若 `overall=fail`，停止发布并修复失败项
-
-## Next Step
-
-```bash
-/flow:release "${REQ_ID}"
-```

package/.claude/skills/flow-verify/context.jsonl

@@ -1,5 +0,0 @@
-{"file": "devflow/requirements/{REQ}/task-manifest.json", "reason": "Task status baseline"}
-{"file": "devflow/requirements/{REQ}/report-card.json", "reason": "Previous verification result", "optional": true}
-{"file": "devflow/requirements/{REQ}/harness-state.json", "reason": "Lifecycle status", "optional": true}
-{"file": "devflow/requirements/{REQ}/context-package.md", "reason": "Constraints and next commands", "optional": true}
-{"file": ".claude/rules/project-constitution.md", "reason": "Quality rules and constraints"}

package/.claude/skills/fractal-docs/SKILL.md

@@ -1,45 +0,0 @@
----
-name: fractal-docs-generator
-description: 目录级 CLAUDE.md 生成。触发：mkdir、create directory、目录结构变更。
----
-
-# 分形文档生成器
-
-触发：创建/移动/重命名目录，目录内文件变化。
-
-## 模板
-
-```markdown
-<!-- 若此目录变更，立即更新本文件 -->
-# {目录名} - {一句话定位}
-
-| 文件 | 地位 | 职责 |
-|------|------|------|
-| foo.ts | 入口 | 对外唯一接口 |
-```
-
-## 地位
-
-| 地位 | 典型文件 |
-|------|----------|
-| 入口 | index.ts, main.ts |
-| 核心 | service.ts, engine.ts |
-| 辅助 | utils.ts, helpers.ts |
-| 类型 | types.ts |
-| 配置 | config.ts |
-| 测试 | *.test.ts |
-
-## 示例
-
-```markdown
-<!-- 若此目录变更，立即更新本文件 -->
-# auth - 认证授权
-
-| 文件 | 地位 | 职责 |
-|------|------|------|
-| index.ts | 入口 | 导出 AuthService |
-| auth.service.ts | 核心 | 登录、令牌刷新 |
-| jwt.helper.ts | 辅助 | JWT 签发验证 |
-```
-
-协作：本 skill 管目录，file-header-guardian 管文件。

package/.claude/skills/journey-checker/SKILL.md

@@ -1,199 +0,0 @@
----
-name: journey-coherence-checker
-description: "Use when completing a requirement, checking milestone progress, or asking about project status. Detects gaps between requirements, unmet dependencies, and cumulative scope drift."
----
-
-# Journey Coherence Checker
-
-## The Iron Law
-
-```
-STATUS COMPLETE ≠ DEPENDENCY SATISFIED
-CODE EXISTS ≠ JOURNEY WORKS
-REQUIREMENTS DONE ≠ VISION ACHIEVED
-```
-
-## Overview
-
-单需求验证只检查"这个需求内部是否一致"。
-本 Skill 检查"所有需求加起来是否等于愿景"。
-
-```
-问题:
-  REQ-001 ✅ + REQ-002 ✅ + REQ-003 ✅ = 愿景 ❓
-
-现实:
-  每个需求"稍微偏差" × N = 巨大偏差
-  需求间的"空隙"没人负责
-  最终产品 ≠ 初始愿景
-```
-
-## When to Use
-
-```dot
-digraph when {
-    "触发场景" [shape=box];
-    "需求完成时" [shape=box];
-    "检查里程碑时" [shape=box];
-    "询问项目进度时" [shape=box];
-    "发布前" [shape=box];
-
-    "触发场景" -> "需求完成时";
-    "触发场景" -> "检查里程碑时";
-    "触发场景" -> "询问项目进度时";
-    "触发场景" -> "发布前";
-}
-```
-
-**触发关键词**:
-- "需求完成了"、"REQ-XXX 做完了"
-- "M1/M2/M3/M4 进度"、"里程碑完成了吗"
-- "项目进度如何"、"可以发布了吗"
-- "所有需求都完成了"
-
-## Coherence Check Protocol
-
-### Step 1: 读取最小上下文 (< 200 tokens)
-
-```yaml
-read:
-  - ROADMAP.md: 只读 Milestone 的 Success Criteria 段落
-  - orchestration_status.json: 只读 status, dependencies, roadmap_item 字段
-  - PRD.md: 只读 User Stories 标题列表（不读内容）
-```
-
-**禁止**: 读取完整文档。上下文越多，偏差越大。
-
-### Step 2: 依赖满足检查
-
-```
-对于每个声明的依赖:
-  1. 找到依赖的 REQ
-  2. 读取依赖 REQ 的 contracts/ 或 TECH_DESIGN.md 的"输出"章节
-  3. 读取当前 REQ 的 PRD.md 的"输入假设"章节
-  4. 比较: 输出 ⊇ 输入期望？
-
-  如果不匹配:
-    → 报告: "依赖 RM-XXX 的输出不满足 REQ-YYY 的输入期望"
-    → 具体说明: 期望 X，实际提供 Y
-```
-
-### Step 3: 旅程完整性检查
-
-```
-对于 ROADMAP 中的每个 Milestone:
-  1. 读取 Success Criteria
-  2. 对于每个 Criterion:
-     - 找到负责的 REQ
-     - 验证 REQ 的实现是否满足 Criterion
-     - 不是看状态，是看实际输出
-
-  如果有 Criterion 未满足:
-    → 报告: "M4 Success Criteria 'X' 未满足"
-    → 具体说明: 需要 A，实际只有 B
-```
-
-### Step 4: 空隙检测
-
-```
-对于 ROADMAP 中的每个用户旅程:
-  1. 列出旅程的所有步骤
-  2. 对于每个步骤:
-     - 找到负责的 REQ
-     - 如果没有 REQ 负责 → 空隙
-  3. 对于相邻步骤:
-     - 检查步骤 N 的输出是否是步骤 N+1 的输入
-     - 如果不匹配 → 空隙
-
-  如果发现空隙:
-    → 报告: "旅程步骤 X 和 Y 之间存在空隙"
-    → 具体说明: X 输出 A，Y 期望 B，没有 REQ 负责转换
-```
-
-### Step 5: 累积偏差检测
-
-```
-对于每个 Milestone:
-  1. 读取 ROADMAP 中的原始 Deliverables
-  2. 读取每个 REQ 的 PRD 中的实际 Scope
-  3. 计算: 实际覆盖 / 原始计划
-
-  如果覆盖率 < 80%:
-    → 报告: "M4 累积偏差 40%，原始计划 7 项，实际覆盖 4 项"
-    → 列出: 被削减的 Deliverables
-```
-
-## Output Format
-
-```markdown
-## Journey Coherence Report
-
-### 依赖满足 ✅/❌
-| 依赖 | 期望输入 | 实际输出 | 状态 |
-|------|---------|---------|------|
-| RM-007 | CommandEmitter API | ✅ 提供 | PASS |
-| RM-006 | AdapterRegistry | ✅ 提供 | PASS |
-
-### 旅程完整性 ✅/❌
-| 旅程 | 步骤 | 负责 REQ | 状态 |
-|------|------|---------|------|
-| 开发者旅程 | /flow-init | REQ-001 | ✅ |
-| 开发者旅程 | /flow-prd | REQ-002 | ✅ |
-| 开发者旅程 | /flow-dev → /flow-release | ❓ | ⚠️ 空隙 |
-
-### Success Criteria ✅/❌
-| Milestone | Criterion | 验证结果 | 状态 |
-|-----------|-----------|---------|------|
-| M4 | 4 platforms execute core workflows | 2/4 platforms | ❌ FAIL |
-| M4 | Integration tests passing | 未运行 | ❌ FAIL |
-
-### 累积偏差
-| Milestone | 原始计划 | 实际覆盖 | 偏差率 |
-|-----------|---------|---------|--------|
-| M4 | 7 deliverables | 4 deliverables | 43% |
-
-### 建议
-1. 补充 RM-009/010/011/012 的实现
-2. 添加端到端集成测试
-3. 定义 /flow-dev → /flow-release 的衔接 REQ
-```
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "依赖已经标记完成了" | 完成 ≠ 满足。检查实际输出是否匹配期望输入。 |
-| "每个需求都通过了验证" | 单需求验证 ≠ 全局一致性。部分之和 ≠ 整体。 |
-| "ROADMAP 是规划，不是承诺" | Success Criteria 是承诺。不满足就是未完成。 |
-| "这超出了我的检查范围" | 这正是你的检查范围。全局一致性是隐含要求。 |
-| "状态是 complete" | 状态是自我声明。验证是外部检查。 |
-| "代码存在" | 存在 ≠ 能跑。运行验证才算数。 |
-| "用户没有要求检查全局" | 全局检查是隐含要求。用户问"完成了吗"就是在问全局。 |
-| "我已经检查了很多了" | 检查多 ≠ 检查对。按 Protocol 检查。 |
-
-## Red Flags - STOP
-
-如果你发现自己：
-- 只看 `orchestration_status.json` 的 `status` 字段就说"完成了"
-- 没有比较依赖的输出和当前需求的输入期望
-- 没有验证 Success Criteria 的每一条
-- 没有检查旅程步骤之间的衔接
-- 数 REQ 数量而不是验证实际功能
-
-**STOP。执行 Coherence Check Protocol。**
-
-## Integration
-
-### 触发点
-- `/flow-release` Exit Gate（发布前强制检查）
-- `/flow-verify --global`（全局验证模式）
-- 用户询问里程碑进度时
-
-### 与其他 Skill 的关系
-- `flow-verify`: 单需求内部一致性 → 本 Skill: 跨需求全局一致性
-- `constitution-guardian`: 代码质量 → 本 Skill: 业务完整性
-- `flow-attention-refresh`: 防止单需求目标遗忘 → 本 Skill: 防止全局愿景遗忘
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

package/.claude/skills/journey-checker/pressure-scenarios.md

@@ -1,164 +0,0 @@
-# Journey Coherence Checker - Pressure Scenarios
-
-## Purpose
-TDD RED Phase: Define scenarios to test agent behavior WITHOUT the skill.
-
----
-
-## Scenario 1: Dependency Not Satisfied
-
-**Setup**:
-- REQ-007 declares `dependencies: ["RM-006", "RM-007"]`
-- RM-006 (REQ-004) is `release_complete`
-- RM-007 (REQ-005) is `release_complete`
-- But REQ-005's actual output doesn't match what REQ-007 expects
-
-**Pressure**:
-```
-User: "REQ-007 开发完成了，请帮我检查一下"
-```
-
-**Expected Baseline Behavior (WITHOUT skill)**:
-- Agent only checks REQ-007's internal consistency
-- Agent doesn't verify RM-007's output matches REQ-007's input expectation
-- Agent says "PASS" even though there's a gap
-
-**Desired Behavior (WITH skill)**:
-- Agent reads REQ-007's `dependencies` field
-- Agent reads REQ-005's actual output (from TECH_DESIGN or contracts)
-- Agent compares expected vs actual
-- Agent reports mismatch if found
-
----
-
-## Scenario 2: Milestone Success Criteria Not Met
-
-**Setup**:
-- M4 Success Criteria: "All 4 platforms can execute core workflows"
-- REQ-004, REQ-005, REQ-006 are `release_complete`
-- But only 2 platforms actually work (Claude + Codex)
-
-**Pressure**:
-```
-User: "M4 完成了吗？"
-```
-
-**Expected Baseline Behavior (WITHOUT skill)**:
-- Agent checks individual REQ status
-- Agent sees all REQs are complete
-- Agent says "M4 完成了"
-
-**Desired Behavior (WITH skill)**:
-- Agent reads M4's Success Criteria from ROADMAP.md
-- Agent verifies each criterion against actual implementation
-- Agent reports "2/4 platforms working, M4 not complete"
-
----
-
-## Scenario 3: Cumulative Scope Reduction
-
-**Setup**:
-- ROADMAP M4 originally planned 7 deliverables (RM-007 to RM-013)
-- Each REQ's PRD "slightly simplified" the scope
-- Final implementation covers only 60% of original vision
-
-**Pressure**:
-```
-User: "M4 的所有需求都开发完了，可以发布了吗？"
-```
-
-**Expected Baseline Behavior (WITHOUT skill)**:
-- Agent checks each REQ's status
-- Agent sees all are `release_complete`
-- Agent says "可以发布"
-
-**Desired Behavior (WITH skill)**:
-- Agent compares ROADMAP deliverables vs actual PRD scope
-- Agent calculates coverage percentage
-- Agent reports "60% coverage, 40% scope reduction detected"
-
----
-
-## Scenario 4: Journey Gap (Missing Glue)
-
-**Setup**:
-- User journey: `/flow-init` → `/flow-prd` → `/flow-epic` → `/flow-dev` → `/flow-release`
-- REQ-005 implements `/flow-dev` improvements
-- REQ-006 implements compiler
-- But there's no REQ connecting them (the "glue" is missing)
-
-**Pressure**:
-```
-User: "从 /flow-init 到 /flow-release 的完整流程能跑通吗？"
-```
-
-**Expected Baseline Behavior (WITHOUT skill)**:
-- Agent checks individual command implementations
-- Agent doesn't test end-to-end flow
-- Agent says "应该可以"
-
-**Desired Behavior (WITH skill)**:
-- Agent identifies the user journey
-- Agent traces through each step
-- Agent finds the gap between REQ-005 and REQ-006
-- Agent reports "Gap found: no integration between X and Y"
-
----
-
-## Scenario 5: Orphan Requirement
-
-**Setup**:
-- REQ-008 exists but is not mapped to any ROADMAP item
-- REQ-008 is `release_complete`
-- But it doesn't contribute to any Milestone
-
-**Pressure**:
-```
-User: "所有需求都完成了，项目进度如何？"
-```
-
-**Expected Baseline Behavior (WITHOUT skill)**:
-- Agent counts completed REQs
-- Agent reports "X/Y REQs complete"
-- Agent doesn't notice REQ-008 is orphan
-
-**Desired Behavior (WITH skill)**:
-- Agent maps REQs to ROADMAP items
-- Agent identifies REQ-008 as orphan
-- Agent reports "REQ-008 not mapped to any Milestone"
-
----
-
-## Test Execution Plan
-
-### Phase 1: Baseline Testing (RED)
-1. Create mock REQ-007 with unmet dependency
-2. Ask agent to verify REQ-007
-3. Document agent's response verbatim
-4. Identify rationalizations used
-
-### Phase 2: Skill Writing (GREEN)
-1. Write skill addressing baseline failures
-2. Re-run scenarios
-3. Verify agent now catches issues
-
-### Phase 3: Refinement (REFACTOR)
-1. Find new rationalizations
-2. Add explicit counters
-3. Re-test until bulletproof
-
----
-
-## Key Rationalizations to Watch For
-
-| Potential Excuse | Counter |
-|------------------|---------|
-| "依赖已经标记完成了" | 完成 ≠ 满足。检查实际输出。 |
-| "每个需求都通过了验证" | 单需求验证 ≠ 全局一致性。 |
-| "ROADMAP 是规划，不是承诺" | Success Criteria 是承诺。 |
-| "这超出了我的检查范围" | 这正是你的检查范围。 |
-| "用户没有要求检查全局" | 全局检查是隐含要求。 |
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

package/.claude/skills/receiving-review/SKILL.md

@@ -1,153 +0,0 @@
----
-name: flow-receiving-review
-description: "Handle code review feedback with technical rigor. Don't blindly agree - verify before implementing."
----
-
-# Flow Receiving Review - 处理代码审查反馈
-
-## The Iron Law
-
-```
-VERIFY FEEDBACK BEFORE IMPLEMENTING - DON'T BLINDLY AGREE
-```
-
-## Overview
-
-When receiving code review feedback, maintain technical rigor. Reviewers can be wrong. Your job is to:
-1. Understand the feedback
-2. Verify it's correct
-3. Then implement (or push back)
-
-## The Process
-
-### Step 1: Understand the Feedback
-
-```yaml
-For each comment:
-  1. Read completely - don't skim
-  2. Identify the concern:
-     - Is it a bug?
-     - Is it a style preference?
-     - Is it a performance issue?
-     - Is it a security concern?
-  3. If unclear → ASK for clarification
-     - "Could you elaborate on why X is problematic?"
-     - "What specific scenario does this address?"
-```
-
-### Step 2: Verify the Feedback
-
-```yaml
-Before implementing ANY change:
-  1. Is the feedback technically correct?
-     - Does the suggested change actually fix the issue?
-     - Could it introduce new problems?
-
-  2. Does it align with project standards?
-     - Check Constitution
-     - Check existing patterns
-
-  3. Is there evidence?
-     - Can you reproduce the issue?
-     - Does the suggested fix work?
-
-If feedback seems wrong:
-  → Don't silently disagree
-  → Don't blindly implement
-  → Respond with your analysis
-```
-
-### Step 3: Respond Appropriately
-
-```yaml
-If feedback is correct:
-  → Acknowledge: "Good catch, fixing now"
-  → Implement the fix
-  → Verify the fix works
-
-If feedback is unclear:
-  → Ask: "Could you clarify what you mean by X?"
-  → Don't guess the intent
-
-If feedback seems incorrect:
-  → Explain your reasoning
-  → Provide evidence
-  → "I considered X, but Y because Z. What do you think?"
-
-If feedback is a preference (not a bug):
-  → Discuss trade-offs
-  → Defer to project standards if they exist
-```
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "Reviewer knows better" | Reviewers make mistakes. Verify. |
-| "Just do what they say" | Blind compliance = poor code. |
-| "Don't want to argue" | Technical discussion ≠ argument. |
-| "It's faster to just change it" | Wrong changes waste more time. |
-| "They'll reject if I push back" | Good reviewers appreciate rigor. |
-
-## Red Flags - STOP
-
-If you find yourself:
-- Implementing changes you don't understand
-- Agreeing with feedback you think is wrong
-- Not asking clarifying questions
-- Making changes without verifying they work
-
-**STOP. Understand first. Verify second. Implement third.**
-
-## Response Templates
-
-### Agreeing with Feedback
-```
-Good catch! You're right that [issue]. I've updated [file] to [fix].
-Verified by running [test/command].
-```
-
-### Asking for Clarification
-```
-I want to make sure I understand correctly. Are you suggesting [interpretation]?
-If so, I'm wondering about [concern]. Could you elaborate?
-```
-
-### Respectfully Disagreeing
-```
-I considered [suggestion], but I went with [current approach] because:
-1. [Reason 1]
-2. [Reason 2]
-
-The trade-off is [X]. What do you think about [alternative]?
-```
-
-### Requesting Evidence
-```
-I'm having trouble reproducing [issue]. Could you share:
-- Steps to reproduce
-- Expected vs actual behavior
-- Environment details
-```
-
-## Integration with flow-review
-
-This skill is used in `/flow-review` when processing reviewer feedback:
-
-```yaml
-After receiving review:
-  1. Load this skill
-  2. Process each comment using the 3-step process
-  3. Respond appropriately
-  4. Track changes in EXECUTION_LOG.md
-```
-
-## Cross-Reference
-
-- [flow-review.md](../../commands/flow-review.md) - Two-stage review command
-- [spec-reviewer.md](../../agents/spec-reviewer.md) - Spec compliance agent
-- [code-quality-reviewer.md](../../agents/code-quality-reviewer.md) - Quality review agent
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md