cc-devflow 4.3.0 → 4.4.1

package/.claude/rules/rationalization-library.md

@@ -1,282 +0,0 @@
-# CC-DevFlow Rationalization Library
-
-> **Version**: 1.0.0
-> **Purpose**: Centralized defense against AI Agent rationalization attempts
-> **Source**: Extracted from superpowers TDD skill + CC-DevFlow operational experience
-
----
-
-## How to Use This Library
-
-When an agent is about to violate a Constitutional Article, they will often produce
-rationalizations. This library provides pre-crafted responses.
-
-**Pattern**:
-1. Agent produces excuse
-2. Lookup excuse in relevant Article section
-3. Respond with "Reality" column
-4. If not found, add new rationalization to library
-
----
-
-## Article I: Quality First - Rationalization Table
-
-### Iron Law
-```
-NO PARTIAL IMPLEMENTATION - COMPLETE OR NOTHING
-```
-
-### Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "This is simplified for now" | CONSTITUTIONAL VIOLATION. Complete it or don't ship it. |
-| "Will complete in v2" | Future versions don't exist. Implement fully now. |
-| "Core logic works, edge cases later" | Edge cases ARE the implementation. No later. |
-| "Time constraint" | Ship later, ship complete. Never ship incomplete. |
-| "MVP approach" | MVP = Minimum VIABLE. Viable means works completely. |
-| "Placeholder for now" | Placeholders = technical debt = future bugs. |
-| "I'll fix it before PR" | Fix it NOW. Not later. Now. |
-| "80% is good enough" | 80% = broken for 20% of users. Not good enough. |
-| "Works on my machine" | Production is not your machine. Test properly. |
-
----
-
-## Article II: Architectural Consistency - Rationalization Table
-
-### Iron Law
-```
-REUSE EXISTING CODE - NO DUPLICATION
-```
-
-### Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Faster to rewrite" | Faster now = slower forever. Find and reuse. |
-| "That code is messy" | Refactor it. Don't duplicate it. |
-| "Slightly different use case" | Extract common, parameterize difference. |
-| "I don't have time to search" | Searching takes 5 min. Maintaining duplicates takes forever. |
-| "The other code might change" | Good. Your copy will be outdated. Use shared version. |
-| "It's just a small function" | Small duplications compound. No exceptions. |
-| "I understand my version better" | Understand the shared version. That's your job. |
-
----
-
-## Article III: Security First - Rationalization Table
-
-### Iron Law
-```
-NO HARDCODED SECRETS - ENVIRONMENT VARIABLES ONLY
-```
-
-### Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "It's just for testing" | Commits are forever. Use env vars even for tests. |
-| "I'll remove it before commit" | You won't. You'll forget. Use env vars. |
-| "It's not a real secret" | Any credential is a real secret. Treat it as such. |
-| "Local development only" | Local becomes production. Start secure. |
-| "Nobody will see the repo" | Repos get shared. Git history is permanent. |
-| "I'll rotate it later" | Rotation doesn't erase history. Never commit secrets. |
-| "It's encrypted" | Encrypted secrets in code are still secrets in code. |
-
----
-
-## Article IV: Performance Accountability - Rationalization Table
-
-### Iron Law
-```
-NO RESOURCE LEAKS - ALWAYS CLEANUP
-```
-
-### Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Garbage collector will handle it" | GC doesn't close files/connections. Explicit cleanup. |
-| "Small leak, won't matter" | Small leaks become big crashes. Fix now. |
-| "It's a short-lived process" | Process lifetime is not your decision. Always cleanup. |
-| "I'll add cleanup later" | Later = never. Add cleanup with creation. |
-| "Framework handles it" | Verify that. Don't assume. |
-| "Only happens in edge case" | Edge cases run in production. Handle them. |
-
----
-
-## Article V: Maintainability - Rationalization Table
-
-### Iron Law
-```
-NO DEAD CODE - USE IT OR DELETE IT
-```
-
-### Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Might need it later" | Git history exists. Delete now, retrieve if needed. |
-| "It's just commented out" | Commented code = noise. Delete it. |
-| "Reference for future work" | Write docs. Don't keep dead code. |
-| "Someone else might need it" | They'll write their own. Delete yours. |
-| "Too risky to delete" | Tests exist. If tests pass after delete, it's safe. |
-| "I worked hard on this" | Sunk cost fallacy. Delete it. |
-
----
-
-## Article VI: Test-First Development - Rationalization Table
-
-### Iron Law
-```
-NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
-```
-
-### Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
-| "I'll test after" | Tests passing immediately prove nothing. |
-| "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
-| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
-| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. |
-| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
-| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
-| "Test hard = design unclear" | Listen to test. Hard to test = hard to use. |
-| "TDD slows me down" | TDD faster than debugging. Pragmatic = test-first. |
-| "This is different because..." | No. This is rationalization. Follow the law. |
-| "Spirit not letter" | Violating letter IS violating spirit. No loopholes. |
-| "I'm being pragmatic, not dogmatic" | TDD IS pragmatic. Shortcuts = debugging in production = slower. |
-| "Just this once" | No exceptions. Rules exist for this exact moment. |
-| "Existing code has no tests" | You're improving it. Add tests for existing code. |
-| "Manual test faster" | Manual doesn't prove edge cases. You'll re-test every change. |
-
----
-
-## Article VII: Simplicity Gate - Rationalization Table
-
-### Iron Law
-```
-MAXIMUM 3 PROJECTS - JUSTIFY ANY ADDITIONAL COMPLEXITY
-```
-
-### Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Microservices are better" | For your scale? Monolith is simpler. Start there. |
-| "Future scalability" | YAGNI. Scale when you need to. |
-| "Separation of concerns" | Modules separate concerns. Projects add overhead. |
-| "Team autonomy" | Autonomy ≠ architectural chaos. Coordinate. |
-| "Best practices say..." | Best practices assume scale you don't have. |
-| "We might need it" | Might ≠ do. Build for now, refactor when needed. |
-
----
-
-## Article VIII: Anti-Abstraction - Rationalization Table
-
-### Iron Law
-```
-USE FRAMEWORKS DIRECTLY - NO UNNECESSARY WRAPPERS
-```
-
-### Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Abstraction for future flexibility" | YAGNI. You won't switch frameworks. |
-| "Cleaner interface" | Framework interface IS clean. Learn it. |
-| "Hide implementation details" | Framework IS implementation. Don't hide it. |
-| "Consistent with other projects" | Consistency ≠ unnecessary abstraction. |
-| "Easier testing" | Mock the framework. Don't wrap it. |
-| "Best practice pattern" | Pattern ≠ always apply. Use judgment. |
-
----
-
-## Article IX: Integration-First Testing - Rationalization Table
-
-### Iron Law
-```
-CONTRACTS FIRST - REAL ENVIRONMENTS
-```
-
-### Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Unit tests are faster" | Fast wrong tests waste time. Integration tests catch real bugs. |
-| "Mocks are simpler" | Mocks hide integration issues. Real databases find them. |
-| "CI is slow" | CI is cheap. Production bugs are expensive. |
-| "Docker is complex" | Docker is simpler than debugging integration issues. |
-| "In-memory database works" | In-memory differs from production. Test with real DB. |
-
----
-
-## Article X: Requirement Boundary - Rationalization Table
-
-### Iron Law
-```
-IMPLEMENT WHAT'S REQUESTED, NOTHING MORE
-```
-
-### Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "User might need this later" | User didn't ask. Don't add. YAGNI. |
-| "It's just a small addition" | Small additions compound. Scope creep. |
-| "This is a natural extension" | Extensions require explicit request. |
-| "Would be nice to have" | Nice ≠ required. Focus on requirements. |
-| "While I'm here anyway" | Stay on task. Create separate requirement. |
-| "It's only 5 more lines" | 5 lines = testing + docs + maintenance. Not 5 lines. |
-| "User will thank me" | User will thank you for ON-TIME, IN-SCOPE delivery. |
-| "I'm being helpful" | Helpful = following spec. Unhelpful = scope creep. |
-| "It's best practice" | Best practice: implement what's requested. |
-| "Future-proofing" | Future-proofing = over-engineering = waste. |
-| "Obvious feature" | If obvious, it should be in spec. Not in spec = don't do. |
-
----
-
-## Cross-Article Rationalizations
-
-These excuses appear across multiple Articles:
-
-| Excuse | Reality | Articles |
-|--------|---------|----------|
-| "Just this once" | No exceptions. Rules exist for this exact moment. | All |
-| "I'm being pragmatic" | Pragmatic = following rules. Shortcuts = technical debt. | All |
-| "Time is tight" | Rushed work = bugs = more time spent debugging. | All |
-| "It's obvious it works" | Nothing is obvious. Prove with tests. | I, VI |
-| "Everyone does this" | Everyone is wrong. We do it right. | All |
-| "Senior says skip it" | Constitution > authority. No skipping. | All |
-| "Emergency situation" | Emergencies especially need rules. | III, VI |
-| "This is different" | It's not different. Follow the rules. | All |
-| "Spirit over letter" | Violating letter IS violating spirit. | VI |
-| "Being practical" | Practical = disciplined. Shortcuts = impractical. | All |
-
----
-
-## Adding New Rationalizations
-
-When you encounter a new excuse not in this library:
-
-1. **Capture verbatim** - Record exact words used
-2. **Identify Article** - Which Constitutional Article does it violate?
-3. **Craft Reality response** - Brief, direct, no compromise
-4. **Add to library** - PR to update this document
-5. **Update guardrails** - Add pattern to relevant skill if blocking needed
-
----
-
-## Integration Points
-
-This library is consumed by:
-- `.claude/rules/project-constitution.md` (inline tables per Article)
-- `.claude/agents/*.md` (relevant tables per agent role)
-- `.claude/skills/devflow-tdd-enforcer/SKILL.md`
-- `.claude/skills/constitution-guardian/SKILL.md`
-- `tests/pressure-scenarios/` (test scenarios)
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

package/.claude/schemas/constitution.schema.json

@@ -1,43 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "https://cc-devflow.claude/.claude/schemas/constitution.schema.json",
-  "title": "Devflow Constitution Tracking",
-  "type": "object",
-  "required": [
-    "articles"
-  ],
-  "properties": {
-    "articles": {
-      "type": "array",
-      "minItems": 1,
-      "items": {
-        "type": "object",
-        "required": [
-          "article",
-          "status"
-        ],
-        "properties": {
-          "article": {
-            "type": "string",
-            "minLength": 1
-          },
-          "status": {
-            "type": "string",
-            "enum": [
-              "pending",
-              "in_progress",
-              "approved",
-              "waived",
-              "rejected"
-            ]
-          },
-          "notes": {
-            "type": "string"
-          }
-        },
-        "additionalProperties": false
-      }
-    }
-  },
-  "additionalProperties": true
-}

package/.claude/scripts/.claude/commands/flow/export-openspec.md

@@ -1,221 +0,0 @@
----
-name: flow:export-openspec
-description: Export CC-DevFlow spec.md to OpenSpec format (pure requirements, no metadata)
----
-
-# /flow:export-openspec - OpenSpec 导出命令
-
-## Purpose
-
-将 CC-DevFlow 的 spec.md 导出为 OpenSpec 格式，移除 CC-DevFlow 特定的元数据和实现细节。
-
-## Usage
-
-```bash
-/flow:export-openspec "REQ-123" --output "<openspec-path>"
-```
-
-## Parameters
-
-- `REQ-123`: CC-DevFlow 需求 ID (必需)
-- `--output`: OpenSpec spec.md 输出路径 (必需)
-
-## Examples
-
-```bash
-# 导出到 OpenSpec 项目
-/flow:export-openspec "REQ-123" \
-  --output "/path/to/openspec/changes/add-auth/specs/auth/spec.md"
-
-# 导出到当前目录
-/flow:export-openspec "REQ-124" \
-  --output "./openspec-export/payments/spec.md"
-```
-
-## Workflow
-
-```
-1. 读取 devflow/requirements/{REQ-ID}/spec.md
-   ↓
-2. 解析 CC-DevFlow 格式
-   - 跳过 YAML frontmatter
-   - 提取 Purpose
-   - 提取 Requirements (with BDD scenarios)
-   - 忽略 Design / Tasks / Verification
-   ↓
-3. 转换为 OpenSpec 格式
-   - 移除所有元数据
-   - 移除 [NEEDS CLARIFICATION] 标记
-   - 保留纯 Requirements
-   ↓
-4. 写入 OpenSpec spec.md
-   ↓
-5. 输出转换结果
-```
-
-## CC-DevFlow Format (Input)
-
-```markdown
----
-req_id: "REQ-123"
-title: "用户认证系统"
-created_at: "2026-03-13T10:00:00Z"
-version: "1.0.0"
----
-
-# Authentication Module
-
-## Purpose
-Provides secure authentication.
-
-## Requirements
-
-### Requirement: User Login
-The system SHALL allow login.
-
-#### Scenario: Valid credentials
-- GIVEN a registered user
-- WHEN the user submits credentials
-- THEN a JWT token is issued
-
-## Design
-[NEEDS CLARIFICATION: Implementation details]
-
-## Tasks
-- [ ] T001 [TEST] User Login - 测试
-- [ ] T002 [IMPL] User Login - 实现
-```
-
-## OpenSpec Format (Output)
-
-```markdown
-# Authentication Module
-
-## Purpose
-Provides secure authentication.
-
-## Requirements
-
-### Requirement: User Login
-The system SHALL allow login.
-
-#### Scenario: Valid credentials
-- GIVEN a registered user
-- WHEN the user submits credentials
-- THEN a JWT token is issued
-```
-
-## What Gets Removed
-
-- ❌ YAML frontmatter (req_id, title, version, etc.)
-- ❌ `## Design` section
-- ❌ `## Tasks` section
-- ❌ `## Verification` section
-- ❌ `[NEEDS CLARIFICATION]` markers
-- ❌ TDD task annotations ([TEST], [IMPL])
-- ❌ CC-DevFlow specific metadata
-
-## What Gets Preserved
-
-- ✅ Module name (# heading)
-- ✅ `## Purpose` section
-- ✅ `## Requirements` section
-- ✅ Requirement names and descriptions
-- ✅ BDD scenarios (Given-When-Then)
-- ✅ RFC 2119 keywords (SHALL, MUST, SHOULD, MAY)
-
-## Error Handling
-
-```bash
-# REQ-ID 不存在
-Error: REQ-123 not found in devflow/requirements/
-
-# spec.md 不存在
-Error: spec.md not found for REQ-123
-
-# 输出目录不可写
-Error: Cannot write to /path/to/openspec/
-```
-
-## Output
-
-```json
-{
-  "success": true,
-  "outputPath": "/path/to/openspec/changes/add-auth/specs/auth/spec.md",
-  "requirementsCount": 3
-}
-```
-
-## Implementation
-
-```bash
-node .claude/scripts/export-openspec.js \
-  "devflow/requirements/<req-id>/spec.md" \
-  "<output-path>"
-```
-
-## Use Cases
-
-### 1. 贡献到 OpenSpec 项目
-
-```bash
-# 在 CC-DevFlow 中开发完成
-/flow:dev "REQ-123"
-/flow:verify "REQ-123"
-
-# 导出为 OpenSpec 格式
-/flow:export-openspec "REQ-123" \
-  --output "/path/to/openspec/changes/add-feature/specs/module/spec.md"
-
-# 提交到 OpenSpec 项目
-cd /path/to/openspec
-git add changes/add-feature/
-git commit -m "Add feature specification"
-```
-
-### 2. 共享需求规格
-
-```bash
-# 导出纯需求文档（无实现细节）
-/flow:export-openspec "REQ-124" \
-  --output "./shared-specs/payments.md"
-
-# 分享给产品团队或其他项目
-```
-
-### 3. 需求归档
-
-```bash
-# 导出为标准格式归档
-/flow:export-openspec "REQ-125" \
-  --output "./archive/specs/feature-v1.0.md"
-```
-
-## Round-Trip Compatibility
-
-OpenSpec ↔ CC-DevFlow 双向转换保持需求完整性：
-
-```bash
-# Import: OpenSpec → CC-DevFlow
-/flow:import-openspec "openspec/spec.md" --req-id "REQ-123" --title "Feature"
-  → 生成 spec.md + 自动补充 TDD 任务
-
-# Develop in CC-DevFlow
-/flow:spec "REQ-123"
-/flow:dev "REQ-123"
-
-# Export: CC-DevFlow → OpenSpec
-/flow:export-openspec "REQ-123" --output "openspec/spec.md"
-  → 移除实现细节，保留纯需求
-```
-
-## Related Commands
-
-- `/flow:import-openspec` - Import OpenSpec spec to CC-DevFlow
-- `/flow:spec` - Generate task-manifest from spec.md
-- `/flow:archive` - Archive completed requirements
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

package/.claude/scripts/.claude/commands/flow/import-openspec.md

@@ -1,171 +0,0 @@
----
-name: flow:import-openspec
-description: Import OpenSpec spec.md and convert to CC-DevFlow format with TDD tasks
----
-
-# /flow:import-openspec - OpenSpec 导入命令
-
-## Purpose
-
-从 OpenSpec 项目导入 spec.md 文件，转换为 CC-DevFlow 格式，自动补充 TDD 任务。
-
-## Usage
-
-```bash
-/flow:import-openspec "<openspec-path>" --req-id "REQ-123" --title "功能标题"
-```
-
-## Parameters
-
-- `<openspec-path>`: OpenSpec spec.md 文件的绝对路径或相对路径
-- `--req-id`: CC-DevFlow 需求 ID (必需)
-- `--title`: 需求标题 (必需)
-
-## Examples
-
-```bash
-# 导入 OpenSpec 认证模块
-/flow:import-openspec "/path/to/openspec/changes/add-auth/specs/auth/spec.md" \
-  --req-id "REQ-123" \
-  --title "用户认证系统"
-
-# 导入支付模块
-/flow:import-openspec "./openspec/specs/payments/spec.md" \
-  --req-id "REQ-124" \
-  --title "支付功能"
-```
-
-## Workflow
-
-```
-1. 读取 OpenSpec spec.md
-   ↓
-2. 解析 OpenSpec 格式
-   - Purpose
-   - Requirements (with BDD scenarios)
-   ↓
-3. 转换为 CC-DevFlow 格式
-   - 添加 YAML frontmatter
-   - 保留 Purpose + Requirements
-   - 添加 Design 部分 (标记 [NEEDS CLARIFICATION])
-   - 自动生成 TDD 任务 (TEST + IMPL)
-   - 生成 Verification 清单
-   ↓
-4. 写入 devflow/requirements/{REQ-ID}/spec.md
-   ↓
-5. 输出转换结果
-```
-
-## OpenSpec Format (Input)
-
-```markdown
-# Module Name
-
-## Purpose
-High-level description of the module.
-
-## Requirements
-
-### Requirement: Feature Name
-The system SHALL/MUST/SHOULD/MAY do something.
-
-#### Scenario: Case Name
-- GIVEN precondition
-- WHEN action
-- THEN expected result
-- AND additional assertion
-```
-
-## CC-DevFlow Format (Output)
-
-```markdown
----
-req_id: "REQ-123"
-title: "功能标题"
-created_at: "2026-03-13T10:00:00Z"
-updated_at: "2026-03-13T10:00:00Z"
-version: "1.0.0"
-status: "draft"
-source: "openspec"
----
-
-# Module Name
-
-## Purpose
-[Preserved from OpenSpec]
-
-## Requirements
-[Preserved from OpenSpec with BDD scenarios]
-
-## Design
-[NEEDS CLARIFICATION: 技术实现方案]
-
-## Tasks
-- [ ] T001 [TEST] Feature Name - 测试
-- [ ] T002 [IMPL] Feature Name - 实现 (dependsOn:T001)
-
-## Verification
-- [ ] Feature Name
-  - [ ] Scenario 1
-  - [ ] Scenario 2
-```
-
-## Auto-Generated TDD Tasks
-
-For each Requirement in OpenSpec:
-1. **TEST task** (T001, T003, T005...)
-2. **IMPL task** (T002, T004, T006...) with `dependsOn` to TEST
-
-This ensures Constitution Article VI compliance (Test-First Development).
-
-## Error Handling
-
-```bash
-# OpenSpec 文件不存在
-Error: OpenSpec file not found: /path/to/spec.md
-
-# REQ-ID 格式错误
-Error: Invalid REQ-ID format. Expected: REQ-\d+
-
-# REQ-ID 已存在
-Error: REQ-123 already exists in devflow/requirements/
-```
-
-## Output
-
-```json
-{
-  "success": true,
-  "outputPath": "devflow/requirements/REQ-123/spec.md",
-  "requirementsCount": 3,
-  "tasksCount": 6
-}
-```
-
-## Implementation
-
-```bash
-node .claude/scripts/import-openspec.js \
-  "<openspec-path>" \
-  "<req-id>" \
-  "<title>" \
-  "devflow/requirements/<req-id>/spec.md"
-```
-
-## Next Steps
-
-After import:
-1. Review generated spec.md
-2. Fill in `[NEEDS CLARIFICATION]` sections in Design
-3. Run `/flow:spec "REQ-123"` to generate task-manifest.json
-4. Proceed with `/flow:dev "REQ-123"`
-
-## Related Commands
-
-- `/flow:export-openspec` - Export CC-DevFlow spec to OpenSpec format
-- `/flow:spec` - Generate task-manifest from spec.md
-- `/flow:init` - Initialize new requirement (alternative to import)
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md