@devcxl/opencode-cabbage 0.1.0

package/assets/skills/flow-design/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: flow-design
+description: 技术方案设计 → 方案文档 + ADR 输出
+---
+
+# flow-design
+
+基于 PRD 进行技术方案设计，输出方案文档和 ADR。
+
+## Prerequisites
+- `/requirements` 已完成 → `docs/prd/<title>.md` + Parent Issue 存在
+- 阅读 `../CONTEXT.md` 了解领域术语
+
+## Workflow
+
+### 1. 阅读上下文
+- 阅读 PRD：`docs/prd/<title>.md`
+- 阅读已有 ADR：`docs/adr/`（确保设计不与已有架构决策冲突）
+- 阅读 `docs/dev/out-of-scope.md`（了解已排除范围）
+
+### 2. 技术方案设计
+输出到 `docs/dev/specs/<title>.md`，包含：
+- 技术选型与理由
+- 架构与数据流
+- API / 数据模型
+- 与已有的 ADR 的兼容性检查
+
+### 3. 记录 ADR
+为每个关键决策记录 ADR 到 `docs/adr/<YYYY-MM-DD>-<slug>.md`。
+ADR 格式参考 `../_prompts/adr-format`。
+
+ADR 至少记录：
+- 技术选型决策
+- 架构模式决策
+- 任何可能有争议的方案选择
+
+### 4. 附到 GitHub Issue
+```bash
+mkdir -p docs/dev/handoff
+cat > docs/dev/handoff/design-comment.md << 'EOF'
+## 技术方案
+
+...（摘要）
+
+## ADR
+
+...（ADR 列表）
+
+完整文档：docs/dev/specs/<title>.md
+EOF
+gh issue comment <issue-number> --body-file docs/dev/handoff/design-comment.md
+```
+
+### 5. 提交文档
+设计文档和 ADR 是设计阶段产物，直接提交到 main，确保后续 worktree 创建时能读取：
+
+```bash
+git add docs/dev/specs/<title>.md docs/adr/<date>-<slug>.md
+git commit -m "docs: <title> — 技术方案 + ADR"
+git push origin main
+```
+
+## Output
+- `docs/dev/specs/<title>.md` — 技术方案
+- `docs/adr/<date>-<slug>.md` — ADR 决议
+- Parent Issue 收到设计评论
+- 文档已提交到 main
+
+## 后续
+- **/tasks** — 基于设计方案拆解为 DAG 任务

package/assets/skills/flow-handoff/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: flow-handoff
+description: 打包上下文，跨会话传递进度
+---
+
+# flow-handoff
+
+当上下文窗口压力过大或需要跨会话传递进度时使用。
+
+## 何时使用
+- 上下文窗口接近极限（约 80k+ tokens）
+- 需要切换到另一个任务再回来
+- 当前阶段等待外部输入无法继续
+
+## Workflow
+
+### 1. 打包当前状态
+创建 handoff 文档，记录：
+
+```markdown
+# Handoff: <流程/阶段名>
+
+## 上下文
+- 项目: <项目名>
+- 当前阶段: <stage>
+- 已完成的工作: <列表>
+- 未完成的决策: <列表>
+
+## 关键产出
+- <已产出的文件/Issue/PR 列表>
+
+## 下一步
+1. <下一步行动>
+2. <需要用户输入的问题>
+
+## 待办
+- [ ] <待完成任务>
+```
+
+### 2. 保存 Handoff 文件
+保存到 `docs/dev/handoff-<YYYY-MM-DD>.md`。
+
+### 3. 指示用户
+告知用户：在下次会话中可以直接引用该 handoff 文件以恢复上下文。
+
+## Output
+- `docs/dev/handoff-<date>.md`

package/assets/skills/flow-release/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: flow-release
+description: 版本 → Changelog → Release → npm publish（仅人工）
+---
+
+# flow-release
+
+版本号更新 → tag 推送 → Release 草稿 → 人工审核发布 → 自动 npm publish。
+
+## Prerequisites
+- main 分支最新，所有 PR 已合并
+- CI 通过
+
+## Workflow
+
+### 1. 确认版本号
+从 conventional commits 自动确定 semver bump：
+```bash
+git log $(git describe --tags --abbrev=0)..HEAD --oneline
+```
+- `fix:` → patch | `feat:` → minor | `BREAKING:` → major
+
+### 2. 更新版本号 → 打 tag → 推送
+```bash
+npm version <major|minor|patch> --no-git-tag-version
+# 更新 CHANGELOG.md
+git commit -m "chore(release): v<version>"
+git tag v<version>
+git push origin main --tags
+```
+
+### 3. Release 草稿（自动）
+tag 推送触发 `.github/workflows/release-draft.yml`：
+- 构建 + 测试
+- 生成 Release 草稿（含自动 release notes）
+
+### 4. 人工审核发布
+GitHub Releases 页面 → 检查 Release 草稿 → 点击 **Publish release**。
+
+发布触发 `.github/workflows/release-publish.yml`：
+- 自动 `npm publish`（需要 `NPM_TOKEN` 仓库 Secret）
+
+## Output
+- 版本已更新
+- tag 已推送
+- Release 草稿已创建（待人工发布）
+- 发布后自动推送 npm
+
+## 后续
+无需后续阶段。Flow 完成。

package/assets/skills/flow-requirements/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: flow-requirements
+description: 需求访谈 → PRD 输出 → GitHub Issue 创建
+---
+
+# flow-requirements
+
+通过采访式对话澄清需求，输出 PRD 文档并创建 GitHub Issue。
+
+## Prerequisites
+- `/setup` 已完成（gh CLI 可用）
+
+## Workflow
+
+### 1. 需求访谈
+按参考文档 `references/interview-guide.md` 进行深度盘问，澄清：
+- 用户故事与业务价值
+- 边界条件
+- 验收标准
+- 技术约束
+- 排除范围（记录到 out-of-scope）
+
+### 2. 输出 PRD
+整理为 PRD 文档保存到 `docs/prd/<title>.md`。
+
+参考 `_prompts/prd-format` 中的格式要求。
+
+### 3. 记录 Out-of-Scope
+将在访谈中明确排除的需求记入 `docs/dev/out-of-scope.md`：
+- 便于后续回顾为什么某些功能不做
+- 避免重复讨论
+
+### 4. 创建 Parent GitHub Issue
+```bash
+mkdir -p tmp
+gh issue create \
+  --title "<PRD Title>" \
+  --label "enhancement" \
+  --body-file docs/prd/<title>.md
+```
+
+## Output
+- `docs/prd/<title>.md` — PRD 文档
+- `docs/dev/out-of-scope.md` — 排除范围记录
+- GitHub Parent Issue 已创建
+
+## 下一阶段
+- **/design** — 基于此 PRD 进行技术设计

package/assets/skills/flow-requirements/references/interview-guide.md

@@ -0,0 +1,35 @@
+# 需求访谈指南
+
+## 必问维度
+
+### 用户与场景
+- 谁是最终用户？
+- 他们在什么场景下使用？
+- 解决了什么痛点？
+
+### 业务价值
+- 不做会怎样？
+- 如何衡量成功？（指标）
+- 优先级：P0（必须） / P1（重要） / P2（锦上添花）
+
+### 范围
+- **In Scope**: 精确描述包含的功能边界
+- **Out of Scope**: 明确排除什么，为什么
+
+### 验收标准
+- "怎样才算做完？" 追问到可验证的程度
+- 避免模糊描述（"用户体验好"→ 追问具体标准）
+
+### 技术约束
+- 语言/框架版本限制
+- 部署环境
+- 性能要求（QPS、P99 延迟）
+- 安全/合规要求
+
+## 追问技巧
+
+1. **"然后呢？"** — 当用户给出一个答案后追问，通常前 2 个回答只是表面
+2. **"如果不做这个会怎样？"** — 验证真实优先级
+3. **"谁来判断这个做对了？"** — 明确决策者/验收人
+4. **"和现有功能的关系？"** — 发现依赖/冲突
+5. **OOPS 追问**：当用户说"这个简单"或"这个以后再说"时，记录到 out-of-scope

package/assets/skills/flow-review/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: flow-review
+description: 双轴审查（规范 + 规格）→ 自动合并
+---
+
+# flow-review
+
+沿两条轴线审查 PR 代码：规范（是否符合编码标准）和规格（是否实现了原始需求）。
+
+## Prerequisites
+- PR 已创建
+- 可选的 `/test` 已完成
+
+## Workflow
+
+### 1. 获取审查材料
+```bash
+gh pr diff <pr-number>
+gh pr view <pr-number> --json title,body,files
+```
+
+### 2. 阅读约束来源
+- 检查相关 ADR（`docs/adr/`）— 确认代码是否遵循架构决策
+- 确认规格来源：commit 消息中的 Issue 引用或 `docs/prd/` / `docs/dev/specs/`
+
+### 3. 文档同步确认
+确认 PR 中是否包含文档同步：
+- 检查 PR body 是否列出已同步的文档
+- 检查 `docs/guides/` 和 `docs/dev/guides/` 是否有相应变更
+- 如涉及配置/API 变更但文档未同步 → 标记为阻断性问题
+
+### 4. 双轴审查
+并行检查两个维度：
+
+**规范轴（Normative）** — 代码是否符合文档化的编码标准？
+参考 `references/smell-baseline.md` 中的代码气味基线。
+
+**规格轴（Specification）** — 代码是否忠实实现了需求？
+对照 PRD（`docs/prd/`）和设计方案（`docs/dev/specs/`）验证。
+- 如发现实现与设计偏差 → 追加到 `docs/dev/changelog/<YYYY-MM-DD-NNN-slug>.md`
+
+### 5. 合并前检查
+在合并前确认以下项：
+- 文档同步已完成（`docs/guides/` 已更新或无需更新）
+- changelog 已记录偏差（如有）
+- CI 已通过
+
+### 6. 发表审查意见
+发现阻断性问题：
+```bash
+gh pr review <pr-number> --request-changes --body "..."
+```
+无问题或非阻断性建议：
+```bash
+gh pr review <pr-number> --approve --body "..."
+```
+
+### 7. 等待 CI + 自动合并
+```bash
+gh pr checks <pr-number> --watch
+gh pr merge <pr-number> --squash --delete-branch
+```
+
+### 8. 关闭关联 Sub Issue
+如果 PR body 未包含 `Closes #<num>`（或 PR 合并后 GitHub 未自动关闭），手动关闭：
+```bash
+gh issue close <issue-num> --comment "已完成，已合并至 main"
+```
+
+### 9. 清理 Worktree
+PR 合并后，清理对应的 worktree 和分支：
+
+```bash
+# 从主仓库执行
+git worktree remove .worktree/<task-slug> --force
+git branch -D feat/<task-slug>
+```
+
+> 清理时机：PR 合并后立即执行。`--force` 确保即使 worktree 有未提交变更也能清理（代码已合并到 main，worktree 内变更已无意义）。如清理失败（如进程占用），记录警告但不阻塞流程。
+
+## Output
+- PR 已审查
+- PR 已合并（条件满足时）
+- 关联 Sub Issue 已关闭
+- changelog 已记录偏差（如有）
+
+## 后续
+- **/release** — 发布（如所有 PR 已合并）

package/assets/skills/flow-review/references/smell-baseline.md

@@ -0,0 +1,18 @@
+# 代码气味基线
+
+参考 Fowler《重构》第 3 章。这些气味仅在审查 diff 中出现时报告；跳过工具已强制执行的部分。
+
+## 气味清单
+
+| 气味 | 表现 | 建议修复 |
+|---|---|---|
+| 神秘命名 | 变量/函数名无法表达意图 | 重命名，让名字自解释 |
+| 重复代码 | 相同逻辑出现在多处 | 提取函数/类 |
+| 特性依恋 | 一个方法过度使用其他类的数据 | 将逻辑移到数据所属的类 |
+| 数据泥团 | 相同的数据项组合反复出现 | 提取为值对象 |
+| 基本类型偏执 | 用 string/number 表示领域概念 | 创建值类型/枚举 |
+| 霰弹式修改 | 一个改动需要改多处 | 用 Move Method/Field 集中职责 |
+| 发散式变更 | 一个类因不同原因频繁修改 | 拆分类，分离关注点 |
+| 臆测通用性 | 为不存在的未来需求做的抽象 | YAGNI — 删除 |
+| 消息链 | a.b().c().d() 式的长链调用 | 隐藏委托 |
+| 中间人 | 类的主要工作是委托给其他类 | 删除中间层 |

package/assets/skills/flow-setup/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: flow-setup
+description: 初始化项目文档结构，验证开发环境
+---
+
+# flow-setup
+
+初始化项目文档结构，验证开发环境。
+
+## Workflow
+
+### 1. 创建文档目录
+确保以下目录结构存在：
+```
+docs/
+├── prd/              # 产品需求文档
+├── adr/              # 架构决策记录
+└── dev/
+    ├── specs/        # 技术方案
+    ├── tasks/        # DAG 任务定义
+    ├── api/          # API 设计文档
+    ├── db/           # 数据库设计
+    ├── guides/       # 开发指南
+    └── handoff/      # 上下文交接
+```
+
+### 2. 验证环境
+```bash
+gh auth status
+git remote get-url origin
+```
+确保 gh CLI 已认证、项目已关联 GitHub 远程。
+
+### 3. 完成标记
+```bash
+mkdir -p .opencode/opencode-cabbage
+echo "setup-complete" > .opencode/opencode-cabbage/setup-complete
+```
+
+## Output
+- `docs/` 目录已就绪
+- 开发环境已验证
+- 可开始 `/requirements`

package/assets/skills/flow-tasks/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: flow-tasks
+description: DAG 任务拆解 → Sub Issues 创建
+---
+
+# flow-tasks
+
+将设计方案拆解为 DAG（有向无环图）任务，创建 GitHub Sub Issues。
+
+## Prerequisites
+- `/design` 已完成 → `docs/dev/specs/<title>.md` 存在
+- Parent GitHub Issue 存在
+
+## Workflow
+
+### 1. DAG 拆解
+将设计拆解为最小可执行单元，识别并行/串行关系。
+
+拆解原则：
+- 每个任务应在 1-2 小时内完成实现
+- 无依赖的任务标记为可并行
+- 任务粒度以"一个人可独立完成"为标准
+
+DAG 使用 Mermaid 语法绘制，示例：
+
+```mermaid
+graph TD
+  A["Task A（无依赖）"] --> B["Task B（依赖 A）"]
+  A --> C["Task C（依赖 A）"]
+  D["Task D（无依赖）"]
+```
+
+保存为 `docs/dev/tasks/<YYYY-MM-DD-NNN-slug>/DAG.md`。
+
+### 2. 创建任务文件
+每个任务 `docs/dev/tasks/<task-name>.md`：
+
+```markdown
+---
+name: "<task-name>"
+depends_on: ["<前置任务>"]
+labels: ["backend"]
+worktree_root: ".worktree/<task-name>/"
+---
+
+## 目标
+
+## 实现要点
+
+## 验收标准
+
+## Worktree
+- 路径: `.worktree/<task-name>/`
+- 分支: `feat/<task-name>`
+- 创建时机: `/code` 阶段首次执行时自动创建
+- 清理时机: PR 合并后自动删除
+```
+
+### 3. 创建 Sub Issues
+
+```bash
+mkdir -p docs/dev/handoff
+cat > docs/dev/handoff/task-issue-body.md << 'EOF'
+## 依赖
+前置任务: <列表>
+
+## Worktree
+- 路径: `.worktree/<task-name>/`
+- 分支: `feat/<task-name>`
+
+## 描述
+...
+EOF
+gh issue create \
+  --title "<task-name>" \
+  --label "task" \
+  --parent <parent-number> \
+  --body-file docs/dev/handoff/task-issue-body.md
+```
+
+### 4. 提交任务文件
+任务定义文件是设计阶段产物，直接提交到 main，确保后续 worktree 创建时能读取：
+
+```bash
+git add docs/dev/tasks/<YYYY-MM-DD-NNN-slug>/
+git commit -m "docs: <title> — 任务定义"
+git push origin main
+```
+
+## Output
+- `docs/dev/tasks/*.md` — 独立任务文件
+- GitHub Sub Issues 已创建（依赖关系在 body 中声明）
+- 任务文件已提交到 main
+
+## Sub Issue 关闭时机
+Sub Issue 不在 `/tasks` 阶段关闭，而是在对应 PR 合并后自动关闭：
+
+| 阶段 | 动作 |
+|------|------|
+| `/code` | PR body 含 `Closes #<issue-num>`，合并后 GitHub 自动关闭 |
+| `/review` | 如 PR 未自动关闭 Sub Issue，reviewer 手动 `gh issue close <num>` |
+
+## 后续
+- **/code** — 认领 Sub Issue 开始编码

package/assets/skills/flow-test/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: flow-test
+description: 触发 CI → 监控 → 测试结果汇报
+---
+
+# flow-test
+
+触发 CI 运行 E2E 测试，监控结果并汇报。
+
+## Prerequisites
+- PR 已创建
+
+## Workflow
+
+### 1. 确认 CI 配置
+检查 `.github/workflows/`。如缺失，引导用户创建：
+
+```yaml
+name: E2E
+on: [pull_request]
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - run: npm ci
+      - run: npm run test:e2e
+```
+
+### 2. 触发并监控
+```bash
+gh pr checks <pr-number> --watch
+```
+
+### 3. 结果汇报
+- **全部通过** ✅ → 继续
+- **失败** ❌ → 分析原因，建议修复
+- **超时/异常** ⚠️ → 检查 CI 配置
+
+## Output
+- CI 结果汇报给用户
+
+## 后续
+- **/review** — 审查 PR

package/assets/templates/gitignore

@@ -0,0 +1,5 @@
+node_modules/
+dist/
+
+# OpenCode plugin — parallel development worktrees
+.worktree/

package/dist/flowrun/audit.d.ts

@@ -0,0 +1,5 @@
+import type { FlowRun, FlowStage, TaskState } from "./types.js";
+export declare function postAuditComment(issueNumber: number, body: string): Promise<boolean>;
+export declare function postPRComment(prNumber: number, body: string): Promise<boolean>;
+export declare function buildStageAudit(flowRun: FlowRun, stage: FlowStage): string;
+export declare function buildMergeAudit(task: TaskState): string;

package/dist/flowrun/audit.js

@@ -0,0 +1,67 @@
+import { gh } from "../util/gh.js";
+import { escapeShellArg } from "../util/shell.js";
+export async function postAuditComment(issueNumber, body) {
+    try {
+        const escaped = escapeShellArg(body);
+        await gh(`issue comment ${issueNumber} --body '${escaped}'`);
+        return true;
+    }
+    catch {
+        return false;
+    }
+}
+export async function postPRComment(prNumber, body) {
+    try {
+        const escaped = escapeShellArg(body);
+        await gh(`pr comment ${prNumber} --body '${escaped}'`);
+        return true;
+    }
+    catch {
+        return false;
+    }
+}
+export function buildStageAudit(flowRun, stage) {
+    const s = flowRun.stages[stage];
+    if (!s)
+        return `Stage "${stage}" not found`;
+    const lines = [
+        `### Stage: ${stage}`,
+        `Status: ${s.status}`,
+        `Completed: ${s.completedAt ?? "not yet"}`,
+    ];
+    if (s.checks.length > 0) {
+        lines.push("", "**Checks:**");
+        for (const check of s.checks) {
+            lines.push(`- ${check.name}: ${check.status}`);
+            for (const ev of check.evidence) {
+                lines.push(`  - \`${ev.command}\` → exit ${ev.exitCode}: ${ev.summary}`);
+            }
+        }
+    }
+    return lines.join("\n");
+}
+export function buildMergeAudit(task) {
+    const lines = [
+        `### Task: ${task.id}`,
+        `PR: #${task.prNumber}`,
+        `Status: ${task.status}`,
+        "",
+        "**Merge Checkpoints:**",
+    ];
+    if (task.prCheckpoints) {
+        const cp = task.prCheckpoints;
+        const gates = {
+            localChecks: cp.localChecks.status,
+            ciChecks: cp.ciChecks.status,
+            reviewerApproval: cp.reviewerApproval.status,
+            goalVerification: cp.goalVerification.status,
+            branchProtection: cp.branchProtection.status,
+            mergeResult: cp.mergeResult.status,
+        };
+        for (const [name, status] of Object.entries(gates)) {
+            lines.push(`- ${name}: ${status}`);
+        }
+    }
+    return lines.join("\n");
+}
+//# sourceMappingURL=audit.js.map

package/dist/flowrun/audit.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"audit.js","sourceRoot":"","sources":["../../src/flowrun/audit.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,EAAE,EAAE,MAAM,eAAe,CAAA;AAClC,OAAO,EAAE,cAAc,EAAE,MAAM,kBAAkB,CAAA;AAEjD,MAAM,CAAC,KAAK,UAAU,gBAAgB,CAAC,WAAmB,EAAE,IAAY;IACtE,IAAI,CAAC;QACH,MAAM,OAAO,GAAG,cAAc,CAAC,IAAI,CAAC,CAAA;QACpC,MAAM,EAAE,CAAC,iBAAiB,WAAW,YAAY,OAAO,GAAG,CAAC,CAAA;QAC5D,OAAO,IAAI,CAAA;IACb,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,KAAK,CAAA;IACd,CAAC;AACH,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,aAAa,CAAC,QAAgB,EAAE,IAAY;IAChE,IAAI,CAAC;QACH,MAAM,OAAO,GAAG,cAAc,CAAC,IAAI,CAAC,CAAA;QACpC,MAAM,EAAE,CAAC,cAAc,QAAQ,YAAY,OAAO,GAAG,CAAC,CAAA;QACtD,OAAO,IAAI,CAAA;IACb,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,KAAK,CAAA;IACd,CAAC;AACH,CAAC;AAED,MAAM,UAAU,eAAe,CAAC,OAAgB,EAAE,KAAgB;IAChE,MAAM,CAAC,GAAG,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,CAAA;IAC/B,IAAI,CAAC,CAAC;QAAE,OAAO,UAAU,KAAK,aAAa,CAAA;IAE3C,MAAM,KAAK,GAAa;QACtB,cAAc,KAAK,EAAE;QACrB,WAAW,CAAC,CAAC,MAAM,EAAE;QACrB,cAAc,CAAC,CAAC,WAAW,IAAI,SAAS,EAAE;KAC3C,CAAA;IAED,IAAI,CAAC,CAAC,MAAM,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QACxB,KAAK,CAAC,IAAI,CAAC,EAAE,EAAE,aAAa,CAAC,CAAA;QAC7B,KAAK,MAAM,KAAK,IAAI,CAAC,CAAC,MAAM,EAAE,CAAC;YAC7B,KAAK,CAAC,IAAI,CAAC,KAAK,KAAK,CAAC,IAAI,KAAK,KAAK,CAAC,MAAM,EAAE,CAAC,CAAA;YAC9C,KAAK,MAAM,EAAE,IAAI,KAAK,CAAC,QAAQ,EAAE,CAAC;gBAChC,KAAK,CAAC,IAAI,CAAC,SAAS,EAAE,CAAC,OAAO,aAAa,EAAE,CAAC,QAAQ,KAAK,EAAE,CAAC,OAAO,EAAE,CAAC,CAAA;YAC1E,CAAC;QACH,CAAC;IACH,CAAC;IAED,OAAO,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,CAAA;AACzB,CAAC;AAED,MAAM,UAAU,eAAe,CAAC,IAAe;IAC7C,MAAM,KAAK,GAAa;QACtB,aAAa,IAAI,CAAC,EAAE,EAAE;QACtB,QAAQ,IAAI,CAAC,QAAQ,EAAE;QACvB,WAAW,IAAI,CAAC,MAAM,EAAE;QACxB,EAAE;QACF,wBAAwB;KACzB,CAAA;IAED,IAAI,IAAI,CAAC,aAAa,EAAE,CAAC;QACvB,MAAM,EAAE,GAAG,IAAI,CAAC,aAAa,CAAA;QAC7B,MAAM,KAAK,GAA2B;YACpC,WAAW,EAAE,EAAE,CAAC,WAAW,CAAC,MAAM;YAClC,QAAQ,EAAE,EAAE,CAAC,QAAQ,CAAC,MAAM;YAC5B,gBAAgB,EAAE,EAAE,CAAC,gBAAgB,CAAC,MAAM;YAC5C,gBAAgB,EAAE,EAAE,CAAC,gBAAgB,CAAC,MAAM;YAC5C,gBAAgB,EAAE,EAAE,CAAC,gBAAgB,CAAC,MAAM;YAC5C,WAAW,EAAE,EAAE,CAAC,WAAW,CAAC,MAAM;SACnC,CAAA;QACD,KAAK,MAAM,CAAC,IAAI,EAAE,MAAM,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,EAAE,CAAC;YACnD,KAAK,CAAC,IAAI,CAAC,KAAK,IAAI,KAAK,MAAM,EAAE,CAAC,CAAA;QACpC,CAAC;IACH,CAAC;IAED,OAAO,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,CAAA;AACzB,CAAC"}

package/dist/flowrun/gate.d.ts

@@ -0,0 +1,18 @@
+import { type FlowRun, type FlowStage, type TaskState } from "./types.js";
+export interface GateResult {
+    allowed: boolean;
+    reason?: string;
+    missing: string[];
+    failedChecks: string[];
+}
+export declare function canStartStage(flowRun: FlowRun, stage: FlowStage): GateResult;
+export declare function canCompleteStage(flowRun: FlowRun, stage: FlowStage): GateResult;
+export declare function canStartTask(flowRun: FlowRun, taskId: string): GateResult;
+export declare function canCompleteTask(flowRun: FlowRun, taskId: string): GateResult;
+export declare function canMerge(flowRun: FlowRun): GateResult;
+export declare function allTasksComplete(flowRun: FlowRun): boolean;
+export declare function getReadyTasks(flowRun: FlowRun): TaskState[];
+export declare function determineNextStage(flowRun: FlowRun): {
+    stage: FlowStage | null;
+    reason: string;
+};