一句话定位

把多个编码 agent 的终端会话收敛到一个看板控制台上：发任务、并行跑、人肉审批，代码进分支前永远有人把关。

做这个东西的人

l-crispr（创始人评论自署 Lucas Mota），单人做的本地优先桌面应用。产品页有 6 个可交互的分步引导，写得比大多数同类产品认真。

判断：单人能把编排控制层做到这个深度，几乎可以确定是自用痛点的产物。但 HN 上两个提问—— 并行 agent 改同一文件怎么处理冲突、能不能看出哪些会话在跑什么——都没有回复，说明还没到有社区反馈、有迭代压力的阶段。

看板式任务编排 → 任务带描述、验收标准、图片、标签，走自定义列，按列路由到指定 agent
识别本机已装的 CLI → Claude Code、Codex、Grok、OpenCode、OpenAI 兼容端点，无需新账号
两种执行方式 → 复用 CLI 登录（不新增账单）或 BYOK（key 存 OS keyring），token 直接付给 provider，无 token 加价
并行与隔离 → 任务在隔离的 Git worktree 里并行跑，Team 档最多 16 个并发 run
四道人工闸门 → 提问、计划、diff、命令各带上下文，拒绝/通过都在一个决策面上
Rust 后端强制命令策略 → 不是前端提示，是后端策略
本地优先 → 默认离线，无账号；团队化时按工作区选择同步，仓库和凭据留在本机

它明确不做：不自动 push 或 merge，不做 token 中转，不接管你已经订阅的模型。

现在团队用编码 agent 的典型混乱：开发者开好几个终端会话，每个跑一个 agent，聊天记录散落各处。时间一长就出现"哪个会话在跑什么、跑到哪了、谁批准过"三问全答不上来；agent 改完的代码直接进分支，没人看过 diff；多 agent 并行改同一个仓库，改完合起来才知道撞了。

cadre 替代的是"终端会话即工作流"这个默认方式，把流程变成看得见的队列和审批门。HN 评论里两条提问恰好就是它的核心痛点：一个问并行 agent 改同一文件会不会检测冲突，另一个问 "哪个会话在跑什么"——这正是它要解决的问题本身。

本地桌面免费；Pro/Team 在线工作区付费（跨设备同步、工作区邀请、协作者），定价未公开（"Contact us"）。

判断："本地免费、协作付费"是本地优先工具的标准路径，难走的是中间那段——个人免费爽用，团队购买决策周期又长。token 不加价是刻意克制，也决定了它很难靠差价赚钱。

维度	结论
创始人-产品匹配度	单人全栈做到这个深度，几乎可以确定是自用痛点的产物
产品洞察力	"终端会话不是工作流"这个判断对，四道闸门的位置符合真实工程习惯
技术实现质量	Rust 后端 + OS keyring + 三平台 + 6 个可交互引导，完成度高于 5 points 的观感
市场时机	早半步——多数团队还在"单个 agent 跑得通"阶段，管理多个 agent 是下一阶段的问题

这是"给编码 agent 加一张工程看板"的本地优先版本，最聪明的一笔是承认自己不该碰模型层。

它不对 token 加价、不接管你的模型订阅、不引入自己的 agent，只做编排和审批。这个克制和 numbat 的"只观察不拦截"是同一种产品哲学：先不越权，等被信任。

可迁移的规律：编排工具的边界应该画在"决策"而不是"执行"。 cadre 的价值全在闸门—— 问什么、计划怎么批、diff 谁来看、命令谁放行——执行完全外包给用户已有的 CLI。这让它替换成本极低，也让它的护城河极浅：任何人都能抄。

风险也在这里。 5 points 意味着几乎没人看见它。编排层是最拥挤的赛道（Kiro Crew、各类 agent 编排平台都在打），单人项目在拿不到反馈时最容易死掉——尤其当它没有"worktree 冲突检测"这类硬技术问题时，只靠 UX 差异化很难守住。

① HN 那两个问题（worktree 冲突检测、会话可见性）有没有变成产品功能并在文档里回应 ② 在线工作区的定价数字什么时候公开——"Contact us"通常意味着还没人买 ③ 有没有公开案例或用户日志——证明有人在真实团队里用它

产品逻辑：如果你做的是工具型产品，照抄"边界画在决策层"——让用户继续用他已有的执行栈（模型、CLI、订阅），你只收编决策动作（审批、队列、可见性）。替换成本越低，越容易进门。

定价结构：本地免费 + 协作付费，token 零加价。定价未公开，暂无可拆。

方向对，人太少。 编排控制层是有真实需求的位置，但 5 points 的启动说明它还没被看见，而且这个位置竞争极其拥挤。先记下来，等它解决掉 worktree 冲突检测这类硬问题或拿到第一批用户再回头。