virgo777/buddyme/autonomous-loops

#!/bin/bash
# daily-dev.sh — 功能分支的顺序流水线
 
set -e
 
# 第 1 步：实现功能
claude -p "阅读 docs/auth-spec.md 中的规约。在 src/auth/ 中实现 OAuth2 登录。先写测试 (TDD)。不要创建任何新的文档文件。"
 
# 第 2 步：去杂质 (De-sloppify, 清理环节)
claude -p "检查上一次提交更改的所有文件。删除任何不必要的类型测试、过度防御性的检查或对语言特性的测试（例如，测试 TypeScript 泛型是否工作）。保留真实的业务逻辑测试。清理后运行测试套件。"
 
# 第 3 步：验证
claude -p "运行完整的构建、代码检查（lint）、类型检查和测试套件。修复任何失败。不要添加新功能。"
 
# 第 4 步：提交
claude -p "为所有暂存的更改创建一个约定式提交（conventional commit）。使用 'feat: add OAuth2 login flow' 作为消息。"

# 使用 Opus 进行调研（深度推理）
claude -p --model opus "分析代码库架构并编写添加缓存的计划..."
 
# 使用 Sonnet 进行实现（快速且强大）
claude -p "根据 docs/caching-plan.md 中的计划实现缓存层..."
 
# 使用 Opus 进行审查（彻底）
claude -p --model opus "检查所有更改是否存在安全问题、竞态条件和边界情况..."

# 通过文件传递上下文，而不是增加提示词长度
echo "重点领域：auth 模块，API 速率限制" > .claude-context.md
claude -p "阅读 .claude-context.md 获取优先级信息。按顺序处理它们。"
rm .claude-context.md

# 只读分析阶段
claude -p --allowedTools "Read,Grep,Glob" "审计此代码库的安全漏洞..."
 
# 只写实现阶段
claude -p --allowedTools "Read,Write,Edit,Bash" "实现 security-audit.md 中的修复方案..."

# 启动默认会话
node scripts/claw.js
 
# 带有技能上下文的命名会话
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js

提示词 1 (编排器 Orchestrator)              提示词 2 (子智能体 Sub-Agents)
┌─────────────────────┐             ┌──────────────────────┐
│ 解析规约文件         │             │ 接收完整上下文        │
│ 扫描输出目录         │    部署     │ 读取分配的编号        │
│ 计划迭代             │────────────│ 严格遵守规约          │
│ 分配创意方向         │  N 个智能体 │ 生成唯一的输出        │
│ 管理波次             │             │ 保存到输出目录        │
└─────────────────────┘             └──────────────────────┘

从 $ARGUMENTS 解析以下参数：
1.spec_file — 规约 markdown 的路径
2.output_dir — 保存迭代结果的位置
3.count — 整数 1-N 或 "infinite"
 
阶段 1：阅读并深度理解规约。
阶段 2：列出 output_dir，找到最高的迭代编号。从 N+1 开始。
阶段 3：计划创意方向 — 每个智能体获得不同的主题/方法。
阶段 4：并行部署子智能体（Task 工具）。每个子智能体接收：
  -完整规约文本
  -当前目录快照
  -分配给他们的迭代编号
  -他们唯一的创意方向
阶段 5 (无限模式)：以 3-5 个为一波次循环，直到上下文过低。

/project:infinite specs/component-spec.md src/ 5
/project:infinite specs/component-spec.md src/ infinite

┌─────────────────────────────────────────────────────┐
│  持续 CLAUDE 迭代 (CONTINUOUS CLAUDE ITERATION)     │
│                                                     │
│  1. 创建分支 (continuous-claude/iteration-N)        │
│  2. 使用增强提示词运行 claude -p                    │
│  3. (可选) 审查者阶段 — 独立的 claude -p             │
│  4. 提交更改 (Claude 生成提交消息)                  │
│  5. 推送并创建 PR (gh pr create)                    │
│  6. 等待 CI 检查 (轮询 gh pr checks)                │
│  7. CI 失败？ → 自动修复阶段 (claude -p)            │
│  8. 合并 PR (squash/merge/rebase)                   │
│  9. 返回 main 分支 → 重复                           │
│                                                     │
│  限制条件：--max-runs N | --max-cost $X             │
│            --max-duration 2h | 完成信号             │
└─────────────────────────────────────────────────────┘

curl -fsSL https://raw.githubusercontent.com/AnandChowdhary/continuous-claude/HEAD/install.sh | bash

# 基础：10 次迭代
continuous-claude --prompt "为所有未测试的函数添加单元测试" --max-runs 10
 
# 限制成本
continuous-claude --prompt "修复所有 linter 错误" --max-cost 5.00
 
# 限制时间
continuous-claude --prompt "提高测试覆盖率" --max-duration 8h
 
# 带有代码审查阶段
continuous-claude \
  --prompt "添加身份验证功能" \
  --max-runs 10 \
  --review-prompt "运行 npm test && npm run lint，修复任何失败"
 
# 通过工作树 (worktrees) 并行运行
continuous-claude --prompt "添加测试" --max-runs 5 --worktree tests-worker &
continuous-claude --prompt "重构代码" --max-runs 5 --worktree refactor-worker &
wait

## 进度
-[x] 为 auth 模块添加了测试 (迭代 1)
-[x] 修复了 token 刷新的边界情况 (迭代 2)
-[ ] 仍需：速率限制测试，错误边界测试
 
## 下一步
-下一步专注于速率限制模块
-tests/helpers.ts 中的 mock 设置可以复用

continuous-claude \
  --prompt "修复问题跟踪器中的所有 bug" \
  --completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
  --completion-threshold 3  # 连续 3 次信号后停止

# 第 1 步：实现（让它彻底发挥）
claude -p "通过完整的 TDD 实现该功能。测试要彻底。"
 
# 第 2 步：去杂质 (独立的上下文，专注的清理)
claude -p "审查工作树中的所有更改。删除：
- 验证语言/框架行为而不是业务逻辑的测试
- 类型系统已经强制执行的冗余类型检查
- 对不可能状态的过度防御性错误处理
- Console.log 语句
- 被注释掉的代码
 
保留所有业务逻辑测试。清理后运行测试套件以确保没有破坏任何功能。"

for feature in "${features[@]}"; do
  # 实现
  claude -p "通过 TDD 实现 $feature。"
 
  # 去杂质
  claude -p "清理阶段：审查更改，删除测试/代码杂质，运行测试。"
 
  # 验证
  claude -p "运行构建 + lint + 测试。修复任何失败。"
 
  # 提交
  claude -p "提交并附带消息：feat: add $feature"
done

RFC/PRD 文档
       │
       ▼
  分解 DECOMPOSITION (AI)
  将 RFC 分解为具有依赖 DAG 的工作单元
       │
       ▼
┌──────────────────────────────────────────────────────┐
│  RALPH 循环 (最多 3 次迭代)                          │
│                                                      │
│  对于每个 DAG 层（按依赖关系顺序执行）：             │
│                                                      │
│  ┌── 质量流水线 (单元之间并行运行) ───────────────┐  │
│  │  每个单元在自己的工作树中：                     │  │
│  │  调研 → 计划 → 实现 → 测试 → 审查              │  │
│  │  (深度根据复杂度层级而异)                      │  │
│  └────────────────────────────────────────────────┘  │
│                                                      │
│  ┌── 合并队列 Merge Queue ────────────────────────┐  │
│  │  变基到 main → 运行测试 → 落地或剔除 (Evict)    │  │
│  │  被剔除的单元带着冲突上下文重新进入循环         │  │
│  └────────────────────────────────────────────────┘  │
│                                                      │
└──────────────────────────────────────────────────────┘

interface WorkUnit {
  id: string;              // kebab-case 标识符
  name: string;            // 人类可读的名称
  rfcSections: string[];   // 该单元处理哪些 RFC 章节
  description: string;     // 详细描述
  deps: string[];          // 依赖项（其他单元 ID）
  acceptance: string[];    // 具体的验收标准
  tier: "trivial" | "small" | "medium" | "large"; // 复杂度层级
}

第 0 层: [unit-a, unit-b]     ← 无依赖，并行运行
第 1 层: [unit-c]             ← 依赖于 unit-a
第 2 层: [unit-d, unit-e]     ← 依赖于 unit-c

单元分支
    │
    ├─ 变基 (Rebase) 到 main
    │   └─ 冲突？ → 剔除 (EVICT)（捕获冲突上下文）
    │
    ├─ 运行构建 + 测试
    │   └─ 失败？ → 剔除 (EVICT)（捕获测试输出）
    │
    └─ 通过 → 快进 (Fast-forward) main，推送，删除分支

## 合并冲突 — 在下次落地前解决
 
你之前的实现与先落地的另一个单元冲突。
请重构你的更改，以避开下面的冲突文件/行。
 
{带有 diff 的完整剔除上下文}

research.contextFilePath ──────────────────→ plan
plan.implementationSteps ──────────────────→ implement
implement.{filesCreated, whatWasDone} ─────→ test, reviews
test.failingSummary ───────────────────────→ reviews, implement (下一次迭代)
reviews.{feedback, issues} ────────────────→ review-fix → implement (下一次迭代)
final-review.reasoning ────────────────────→ implement (下一次迭代)
evictionContext ───────────────────────────→ implement (合并冲突后)