# @afokapu/atdd-flow 中文文档 规范地址：https://npmcn.com/package/%40afokapu/atdd-flow/ 版本：0\.3\.97 npm 元数据更新时间：2026-11-05T22:42:41.192Z 中文译文更新时间：2026-11-05T21:38:49.037Z 软件包许可：MIT 本文由上游 README 翻译，可能存在偏差，请结合原文核对 API、命令与配置。版权与许可归原作者所有。 原始 npm 页面：https://www.npmjs.com/package/%40afokapu/atdd-flow 原文对照：https://npmcn.com/package/%40afokapu/atdd-flow/?lang=original 项目主页：https://github.com/afokapu/atdd-flow#readme 源码仓库：https://github.com/afokapu/atdd-flow ## 关键信息（来自 npm 元数据） - 包体积（解压后）：738 kB，50 个文件 - 模块格式：ES Module - TypeScript 类型：未声明 - 运行依赖：2 个 - 首次发布：2026-10-04T22:20:03.603Z - 最新版本发布：2026-11-05T22:42:40.879Z - 近 30 天下载量：17079（2026-10-05 至 2026-11-03，npm 官方下载统计） - 已发布版本数：102（近 12 个月 102 个） ## 中文简介 用于项目、座位、任务、线程和交割的文件系统第一服务台登记册. ## 安装 ```sh npm install @afokapu/atdd-flow ``` 也可以使用：`pnpm add @afokapu/atdd-flow`、`yarn add @afokapu/atdd-flow`、`bun add @afokapu/atdd-flow` ## README # ATDD 工作流程 `atdd-flow` 是用于协调编码代理的文件系统第一控制平面。 它保持持久的协调 在单独的基特后 **办公桌**代码存储器和工作树被改变. ## 模型 ```text Desk (private Git repository) Code repositories / worktrees ├── work// └── implementation only │ ├── project.yaml policy │ ├── seats/ replaceable responsibilities and handoffs │ └── tasks/ delivery, criteria, and proof └── threads/ conversation and immutable messages ``` - A 类 **席位** 拥有责任、分支、工作树、检查站和主机地址;a **任务** 拥有它的简短,所有权,依赖性,标准和证明. - A 类 **线程** 拥有信件、收据、结果和决定;a **东道主** 拥有窗格和通知——从未持久. 稳定地址,例如: `driver.runtime@example-app`,在不同的面板,主机,模型,或替换剂中存活. 替换者读取其耐用座位、任务、检查站和线条,而不是前身-私人背景. Workflow是YAML协议和CLI,而不是数据库、守护进程、代理运行时间或任务管理 SaaS 。 Git提供历史和复制;多轴器可能会唤醒一个代理,但从未拥有状态. ## 安装和创建服务台 将代码存储器安装到本地, 其代理程序使用 Workflow : ```sh bun add -d @afokapu/atdd-flow@latest ``` ### 从ATDD工作流程中迁移 安装 `@afokapu/atdd-flow` 替换 `atdd-workflow` (包括 `bunx atdd-workflow`与 `atdd-flow`现有的YAML服务台计划和 `ATDD_WORKFLOW_ROOT` 保持兼容性. 运营商为下列项目设立一个私人服务台: ```sh atdd-flow init "$HOME/Github/desk" --git export ATDD_WORKFLOW_ROOT="$HOME/Github/desk" ``` 使用 `--root "$HOME/Github/desk"` 为一次性命令。 将服务台分开可以避免代码处冲突并允许交叉存储工作. ### 一次宣布发射可执行文件 `desk.yaml` 拥有每个席位可能使用的可执行名称。 给出每个名字 当主机不保证共享时的绝对命令路径 `PATH`数字 : ```yaml schema: atdd-workflow/desk/v1 desk: desk application: herdr executables: pi: /opt/homebrew/bin/pi ``` 可执行登记册是运输配置,而不是模式分配。 新座椅不会钉住 探员 相反, `models.yaml` 以下降能力顺序宣布可发射模型组合: ```yaml schema: atdd-workflow/models/v1 models: - id: pi executable: pi # Add Pi --model arguments here when local policy selects a specific Pi model. ``` 秩序是政策:最强第一,最弱最后。 新建服务台对每个条目使用 Pi; 添加 Pi `--model` 当本地政策选择特定模式时,参数。 无法执行的条目,或 `enabled` 旗帜是假的,不包括在内。 对于普通阶段工作,Jev看到该席位的积极工作和 选择最弱的现有配置的 Pi 模型,以足以履行这一职责。 如果模式选择是 无法使用或缺乏信心, Workflow 保守地选择可配置的最强 Pi 型号。 最终行为审查有以下描述的自有界限的路由步骤. 无旧办公桌 `models.yaml` 继续纪念一个遗产席位 `agent` 通过可执行的注册. ## 配置工作树和座位 创建项目, 声明其主检出和链接- 工作树根, 然后调整其政策 `work//project.yaml`数字 : ```sh atdd-flow project init example-app atdd-flow project configure example-app --repository /Users/you/Github/example-app --worktree-root /Users/you/Github/worktrees/example-app ``` 新项目默认为 Jujutsu : `project init` 记录 `vcs: jj`这样 `--repository` 一定是JJ报到 (单位:千美元)`jj git init --colocate` 每个产卵主干线、协调员和驾驶员的工作树都是JJ 工作空间。 Git是明确的选择退出(`atdd-flow project init example-app --vcs git`; 遗产项目记录 无 `vcs` 字段继续读取为 Git . `project configure` 只设定 `repository` 财务报告和审定财务报表 `worktree_root` (和 `vcs` (当被问及时). 它没有关闭,离开项目 不变,何时 `--repository` 并不是工程的 VCS 存储器的顶级, 也不是旗号未知, 重复, 或缺少其值。 它从不改变座位、运行时间、任务、分支、工作树或寄存器 内容; 它列出每个记录位置违反地貌的座位为 `unprojected`。 。 。 . 错误的座位未预测 : `multiplexer status` 下级报告 `unprojected`,以及 `multiplexer apply` 继续投放其他席位。 明确投射该座位 仍然拒绝,直到它的位置得到纠正. ```yaml repository: /Users/you/Github/example-app worktree_root: /Users/you/Github/worktrees/example-app roles: coordinator: { address: coordinator@{project}, branch: main, worktree: '{repository}' } driver: { address: driver.{name}@{project}, branch: delivery/{name}, base: main, worktree: '{worktree_root}/{name}' } ``` 操作员或协调员设立座位;司机不选择其政策: ```sh atdd-flow spawn example-app coordinator main --worktree /Users/you/Github/example-app atdd-flow spawn example-app driver runtime ``` `spawn` 通过 Git 创建缺少的驱动工作树: 此示例创建 `/Users/you/Github/worktrees/example-app/runtime` 打开 `delivery/runtime`ATDD Bun拥有安全的退休,而不是创造. 一个座位可以拥有几个任务. 对于舟子命名-协调员地理学,创建一个未指定 `todo` 任务,然后使用 `atdd-flow spawn driver --task `流出新鲜的 `delivery/` 从任务协调员的精确 `integration/` 头(或 `main` 页:1 `main@project`),记录为 `governed_base`,指定任务,并报告整合返回分支。 它拒绝现有的座位,工作树,或树枝和无效的,肮脏的, Stale, 泛指的,筑巢的,或跨项目协调的分界线,而不是重用历史. ## 交付工作 ```text todo → in_progress → review → done ``` 协调员负责指定;驱动程序执行、证明每项标准并提交审查;只有协调员对完成的任务进行标记. ```sh atdd-flow task add example-app runtime-rollout --title 'Complete runtime rollout' \ --coordinator coordinator@example-app --assignee driver.runtime@example-app \ --done-when 'Checks pass' atdd-flow task start example-app runtime-rollout --by driver.runtime@example-app atdd-flow task prove example-app runtime-rollout --by driver.runtime@example-app --item 1 --proof 'CI run 42' atdd-flow task review example-app runtime-rollout --by driver.runtime@example-app # An independently attached reviewer persists APPROVE, RETURN, or ESCALATE through behavioral-review record atdd-flow task done example-app runtime-rollout --by coordinator@example-app ``` 证明是紧凑的PR,CI运行,报告,承诺范围,部署,或线程参考. 附属大门的先决条件;独立的任务可以并行完成。 协调员可以将未分配的现成任务与 `atdd-flow task assign --assignee
--by `; 在任务期间只允许指派一次 `todo`添加 `--immediate --priority --mutation-boundary ` \* 持续并原地发送特定任务发送(任务、优先权、边界、只发送精确的受让人) `task start` 命令);当受让人没有本地队列时,它不能关闭,只写无字。 受让人记录有打字的、按发件方式 `atdd-flow task acknowledge --dispatch --by ` (专有,区别于 `task start`;消息,收据,和心跳从不计数),协调员的点播 `atdd-flow task observe-assignment` 最多一个员额 `missing_acknowledgement` 和一个 `missing_start` 向受让人发出警报。 使用 `task block` 只有真正的外部阻断器, 然后检查站确切状态和下一步行动。 堵塞器解决后 只有协调员才能用 `atdd-flow task unblock --by ` 任务不变 `in_progress`对于明确受本规则管辖的交货 `workflow` ATDD Bun 简介, `review → done` 还需要一个持久的最终行为审查结果和决定 `APPROVE` 现在的清洁交货承诺。 对于一个闲置的司机的最后任务, `task done ... --retire-assignee` 代表清一色 工作树退休 ATDD Bun。 一个任务已经全部完成的司机 `done` 已经退休 `atdd-flow seat retire
--by `使用同样的支票。 当每个任务都是 `done` 和记录的工作树 离开磁盘和 `git worktree list`, (中文(简体) ), `seat retire` 记录退休时没有运行工作树完成, 删除分支, 或重建工作树; Git 仍然注册的缺失工作树没有关闭 。 两种路径在未完成的任务或肮脏或未露出的工作树上都未能关闭;在成功时,它们记录 `retired` 然后关闭司机的Herdr工作空间 `close_inactive` 已启用. `main@` 一旦协调或指派的每一项任务完成后,也可取消协调员席位(无论是主要还是操作者) `done`共享主检票的非主要协调员作为服务台记录退役,没有完成工作树;其他协调员使用相同的工作树完成、缺席和未登记以及故障关闭路径。 退休在坐椅工作地上 ATDD Bun从主检票 `node_modules/.bin`,否则在ATDD Bun软件包中,主检出自源,否则 `PATH`永远不要 座位工作树的副本, 这可能会给一个旧的工具包. 交接开始于上下文使用率的80%,不低于90%,视上下文而定. 在 80–90 % 的 上下文中, Flow 的初级交接是同会的收缩:验证和记录交接/检查点,通过回收捆作为收缩摘要,并在同会的 Pi 、 JSONL 、 Herdr pane 和 Flow 绑定。 每个座位都服务于这个主要路径. 如果压缩不可用,失败了不变量,或者会话被卡住,Flow使用已核实的PR #111新板块后继路径作为倒闭后退;操作员干预是只倒闭后退. 运行时的即时和行为仍在等待收缩 T2/T3 ;直到它们着陆,这描述了目标政策,运行时的即时不变. 一个席位写有条理的交接(生命周期公约中的最新和流程规则),用 `atdd-flow handover
--check --file `,并用 `atdd-flow handover
--file `。这个座位保持一个耐用 `handover.yaml` 除了没有改变的检查站。 记录拒绝缺失标题, Runtime 线条, 或节, 节, 断序 , 150多行, 模糊的引用, 如 `latest` 或者说 `that PR` 没有确切的身份证和 `supersedes` 与记录的移交 ID 不匹配的值。 在倒回的路径上,一个新的会话 绑在同一个座位上读它与 `atdd-flow handover show
`。 。 。 . Path-A替换是上面描述的倒闭倒计时,而不是主重置;其命令和旗帜不变. 项目主座可以执行第二个路径-A替换而无需删除或编辑已耗用的活动请求. 使用常规 `handover replace` 明确的论点 `--supersede-consumed` 新的准确会议通过授权 目前的有效移交 以及完全一个自选接管任务 没有旗帜,替换仍然只创建并拒绝现有的主动请求. 在观察赫尔德之前,超会话要求先行请求的接管任务成为终端和犬科运行时间收发,以嵌入该确切请求和接续者. 它还需要不变的主要地貌、犬皮和工作树的布置以及匹配的当前交接线。 仅读 Herdr 检查之后, 就可以证明新授权的活 Pi 会话, JSONL 路径, 平板, cwd, 代理, 以及准确的一个 Pi 编剧. 该命令从未停止,发射,绑定,或更改运行时间. 超级会话将每个会席的出版物序列化. 它分期提交先前请求的字节同文副本,并按 `.atdd-flow/handover-replacement-archive///`,首先发布完整的不可移动存档,然后在解剖上取代主动请求. 验证、中转、归档、互换和同时尝试的失败保留原始主动请求、接收、座位和运行时间。 在源扩展显示新请求和退出后,使用不变 `pi runtime launch` 采纳路径; 不手动编辑服务台记录或重新组合座位. 为了实现地貌正常化,通过狭义的持久命令传输一个活性任务,永远不要编辑它的YAML: `atdd-flow task transfer --to --reason --by `· ; `main@project` 必须额外通过 `--authorization `。这个信息必须是不可改变的 `task-transfer-authorization/v1` 项目、任务、当前/目标协调员、理由和目标分支/负责人的精确拖累 `operator@desk` 创建它通过 `atdd-flow post --task-transfer-authorization `。命令附件为不可变源/目标/理由/精确头/有效时间出处,保持更早的相/审查/信息证据完整,从接受的目标头取出新的受管基础,绝不移动座位、分支、跑道时间或工作树。 同目标相接,相重复相接相接相接相接相接相接相接相错相接相接相接相接相接相接相接,且手动重写相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相接相. ## 沟通和交接 线索是耐用的收件箱/出件箱. 工作流在最佳主机通知之前会坚持一个消息,所以关闭的面板,速率限制,或丢失的快取不能丢失. ```sh atdd-flow thread start --with coordinator@example-app,driver.runtime@example-app \ --subject 'Runtime rollout' --task example-app/runtime-rollout atdd-flow post T-... --from coordinator@example-app --to driver.runtime@example-app \ --label 'implementation request' --expects-result --body 'Implement the task and return proof references.' atdd-flow result T-... M-... --from driver.runtime@example-app --label 'proof returned' --body 'CI run 42; PR #81.' ``` 新的耐用线程和消息ID都是人可读的: `T-` 或者说 `M-`,世界协调时第二秒 印花图案( p)`YYYYMMDDTHHMMSSZ`),一个kebab-case slaw,和一个短随机后缀,例如: `M-20261010T122049Z-rollover-review_7e5e12ab`。线粒体从 `--subject`。 。 。 . `post`, (中文(简体) ), `receipt`,以及 `result` 可选择接受 `--label` 用于消息弹出; 它 默认为消息类型( e)`message`, (中文(简体) ), `receipt`,或 `result`) (中文(简体) ). 标签很耐用 元数据,所以只提供非敏感文本。 消息体从未在ID中使用. 现有的案头线索和信件文件名保留其遗留的ID不变并保留 可读取. 共同边界:驱动程序 / 协调员 / 受影响的协调员 / 最低限度协议 / 驱动程序. `--to all` 广播;要求的结果直到每个受访者答复为止。 检查站是短暂的交割,而不是日志;在责任过渡时以及在替换代理之前更新. ## 检查、东道主和引导代理人 ```sh atdd-flow status atdd-flow status seat driver.runtime@example-app atdd-flow open driver.runtime@example-app ``` Herdr和tmux可以通知一个已经附加的主机面板. Flow 不创建主机面板: 操作员在其宣布的工作树上启动代理 `ATDD_WORKFLOW_ROOT` 财务报告和审定财务报表 `ATDD_WORKFLOW_SEAT`,然后按确定性附着了花板. ```sh atdd-flow attach driver.runtime@example-app --application herdr ``` ### 可选的Herdr工作树投影 `multiplexer/herdr.yaml` 这是一项紧凑的、无实例的政策:它只描述了初级和相联的工作树角色安排。 服务台仍然对项目、座位、任务、分支和工作树具有权威性。 Herdr是一种可选的显示/运行时间投影,从未成为第二个注册. 操作员必须明确选择目标会话,或者从提供 Herdr 的窗格中运行 `HERDR_SESSION`; Flow从不选择全服务台或有重点的会议。 状态为只读并应用用途 `--no-focus`数字 : ```sh atdd-flow multiplexer status herdr --session forge atdd-flow multiplexer apply herdr --session forge # Inside a Herdr pane, the inherited HERDR_SESSION is sufficient: atdd-flow multiplexer apply herdr ``` 对每个服务台项目,应用调节已申报的存储器检查为工作空间 `{project}` 并给每个主、操作员和非通用的协调员座位,使用它有一个标签和窗格,并命名 `{seat.address}`。 。 。 . `main@{project}` 是单一的主要协调员预测:当它使用主检出时,保存下来的遗产是通用的 `coordinator@{project}` 共享则不作为第二个分页进行批量预测(一个明确的每座投影仍然进行预测,一个没有主干线的项目保留它)。 链接的协调员工作树和活跃的司机成为链接-工作树工作地 `{seat.address}`,带有同样命名的标签和相片。 驱动程序只在解锁时才有效 `in_progress` 指定任务或绑定的 Herdr 面板, 仍然运行着代理; 从未启动、 被封锁、 完成的驱动程序没有工作空间 。 明确的每座投影,例如: `pi runtime launch` 仍然投射自己的座位。 缺少链接的工作树被跳过并报告于下 `unprojected` 而不是中止服务台。 不受约束的工作树被忽略,并且应用时绝不关注或猜测其他会话. 工作空间被贴上服务台司机座椅地址标签,司机退休或闲置,且其退职是座位服务台工程的链接工作树或已不存在. `multiplexer status` 报告 `stale` 计数,并只读,列出每个 `stale_workspaces` 联合国 `address`, (中文(简体) ), `workspace_id`, (中文(简体) ), `reason` (单位:千美元)`retired` 或者说 `no active task`),当前窗格 `agents` 财务报告和审定财务报表 `agent_status`,则 `outcome` 适用需要(`close` 或者说 `keep`,与 `because` 用于保留的工作空间。 运行前审查该列表 . `multiplexer apply` 仅当 `desk.yaml` 使其能够: ```yaml multiplexer: close_inactive: true ``` 永远不要关闭一个陈旧的工作空间 而它的代理是 `working` 或者说 `blocked`由它来报告 初级、主、协调员、操作员和不相关的工作空间从不僵化。 捆绑 `multiplexer/herdr.yaml` 政策不变. 新建 Herdr 附件同时存储所继承的会话和 pane id 。 旧的平面板捆绑仍可读取,只有在有后台会议时才使用,因此没有 `w1:p1` 在另一届新会议中,不能误认为是同一面板. ### 纸质桌面邮件 当 Pi 以 Flow 捆绑的扩展开始时, 它仍然是其主页上一个正常的交互式代理, 但扩展监视不可变的服务台邮件文件, 在内部唤醒 Pi `pi.sendMessage()`\-不是终端短信注射. Pi座独立记录这两个概念: ```yaml runtime: application: herdr addresses: herdr: w9:p1 model: pi wake: native ``` `application` 识别可见的窗格. `wake: native` 告诉 Flow 不要同时发送主机提示; Pi 扩展读取 `ATDD_WORKFLOW_ROOT` 财务报告和审定财务报表 `ATDD_WORKFLOW_SEAT`,观测最后 `M-*.yaml` 文件,过滤收件人,并排入包含线程主题,发送者,收件人,线程/消息ID的紧凑后续,以及 `atdd-flow message read `它从来没有嵌入信息体。 其他探员留着 `wake: host` 并且通过正常的主机适配器接收相同的紧凑通知. 在不装入完整线索的情况下读取一个持久信件 : ```sh atdd-flow message read M-... ``` 输出仅包括消息及其线程ID/主题; Flow拒绝缺失或模糊消息ID. Pi的本土醒悟是故意轻而易举的:没有守护进程,没有重复的邮箱,或者单独安装扩展. 扩展名在流程包内被运出 。 案头线索文件仍然是真相的来源. 在会话开始时, 扩展记录一个本地的, 标记标记 **咨询** 运行时间观察 `.atdd-flow/pi-runtime/.yaml`它只包含其不透明的所有者符号,PID,模型,cwd,启动时间和心跳. 替换的 Pi 进程在原子上取代了先前的观察;旧的进程既不能心跳,不能清除,也不能在失去其指示后消耗已排队的邮件. 关闭和过期的心跳清理只删除匹配的咨询观察. 此文件从不选择收件人或更改办公桌座位、任务、线程、检查点、分支、工作树或永久邮件. `atdd-flow status seat` 可将其活动/销售活动显示为只读信息. 原发邮件不依赖观察者,而是能承受损失。 当 Flow 坚持给一个本地或 Pi 指定的无限制座位发送信息时,它也会在下面附加一个小的每个座位引用一个命令的、固定大小的待定部分 `.atdd-flow/pi-inbox/`; 不可变线程 `M-*.yaml` 文件仍然是权威消息源。 在会话开始/重新装入时,并在限定的间隔时间,扩展只读取耐用队列头并消耗一个固定批次 `created_at`/message-ID命令,仅在Pi接受交付后才删除引用. 等待的队列在交付后会收缩,因此周期性恢复既不扫描也不保留完整的服务台历史. `fs.watch` 在该队列上仍然是一个低相关性快路径;一个不可用的监视器或重启的 Pi 通过对齐恢复。 现有 Pi 进程仍然需要 `/reload` 或者在流程软件包升级后重新启动,以加载捆绑的扩展. 要在 Herdr 中托管 Pi, 创建一个具有持久办公桌和座位身份的窗帘, 然后启动 Pi , 由已安装的 Flow 包提供的扩展 : ```sh PI_EXTENSION="$(atdd-flow pi extension-path)" herdr pane split --current --direction right --cwd /path/to/worktree --no-focus \ --env ATDD_WORKFLOW_ROOT=/path/to/desk \ --env ATDD_WORKFLOW_SEAT=driver.runtime@example-app # Use the pane id returned above. herdr agent start pi-runtime --kind pi --pane -- --extension "$PI_EXTENSION" atdd-flow --root /path/to/desk attach driver.runtime@example-app --application herdr --wake native ``` 皮从扩展本身获得其身份并启动任务. 它的正常的TUI仍然可见并手动可用;收到的服务台邮件通过Pi的本地消息API将其唤醒. 运行时间生命周期有一个内限的收件箱传输;它不添加第二个监视器,注册,邮箱,预定系统,或路由路径. ### 醒来或迁移活的皮座 `atdd-flow pi wake` 替换手册 `/model` → `/reload` + 收件箱/任务即时链,每个座位或舰队有一个命令. 它只发送本地扩展命令 `/flow-wake` 通过Herdr(没有模型提示),并验证了Pi自己的会话记录. ```sh atdd-flow pi wake driver.runtime@example-app --by operator@desk # keep model, reconcile, wake once atdd-flow pi wake driver.runtime@example-app --model-profile restore --by main@example-app # swap to the mapped model first atdd-flow pi wake --scope project --by main@example-app # every live seat of the project atdd-flow pi wake --scope desk --by operator@desk # every live seat of the Desk ``` `--by` 必须是 `operator@desk` 或项目 `main@`· ; `--scope desk` 需要操作员。 配置文件在 `models.yaml` 并必须映射源 `provider/model` 给一个名为精确 Pi 的 已启用组合候选人 `--provider`编号 :`--model`; 当 `models.yaml` 改为: ```yaml model_migrations: restore: anthropic/claude-sonnet-4-5: strong ``` 扩展以 Pi 认证的模型注册、 调用来重新检查目标 `setModel`,保留思维水平,并重新装入。 在重新装入未匹配的请求时, 从活动记录分支重建; Flow 重新激活邮件, 写入结果, 并将恢复捆绑加上权威的任务指令注入到一个完全的恢复工作回合 。 一个比特早的座位 `/flow-wake` 第一个发送 `/reload` 在安全的边界上,只有新鲜的 `flow-wake-capability/v1` 记录记录让唤醒开始. 座椅按语法顺序处理,一个接一个,每个座椅都得到一行: `woke`, (中文(简体) ), `swapped+woke`, (中文(简体) ), `deferred` (代理工作), `refused` (block/ question UI, stale pane/ session/ process,未加图的模型), `skipped` (退休、终点任务、无代理或约束、援引席位),或 `failed` (无法获取的目标,部分模型/重装证据;从未重审). 一个有名的座椅除非被唤醒,否则不为零;舰队只为0为零 `refused` 或者说 `failed`. 没有任何倒置模式、重新启动、压缩、重新安排座位或更换会场,服务台、座位、运行时间和存储器记录从未写出;记录记录中只有Pi的原生模式更改和活化醒目的条目. `ATDD_FLOW_WAKE_TIMEOUT_MS` 每个边框等待( 默认为 30 s; 5 分钟, 一个座位在重新装入后返回闲置) . 生命周期和回收设计参考了以下信息: [尼科拜伦/皮-送信员](https://github.com/nicobailon/pi-messenger) 时间 `09937ed647a1b07a3b595bf75943feacb80ff123` (麻省理工学院). 这里没有 pi- messageers 源代码复制 。 Flow保留了服务台的身份,接收者选择,不可改变的邮件,以及治理的权威;任何未来的复制源都必须携带其MIT通知. 使用 ATDD Bun, 启用工作流程配置 : ```yaml profiles: [planner, coder, tester, traceability, security, workflow] ``` 生命周期公约使代理人阅读CLI帮助和持久的记录,更喜欢最小的足够变化,避免投机范围,工作直到审查准备或明确被封锁,证明标准,并通过协调员协调界限. ATDD 数据库 Bun 仍然保存并合并权限. ### 最后行为调节 相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相相 下一阶段消耗和消耗 对前一阶段提出了共同挑战,而ATDD Bun则提供了决定性的执行。 这个 为终端一体化边界保留了明确的独立审查: ```text implementation → deterministic gates → task review → JEV routing → behavioral reviewer → coordinator decision → done/merge ``` ATDD 数据库 Bun 拥有实质性方法通过 `atdd-bun.review.behavioral-reconciliation`。工作流程首先运行确定式ATDD Bun门;一个红色 门防止审查员发射。 JEV 然后只分类所需的审查表面 (单位:千美元)`LOCAL | ASSEMBLED | JOURNEY | SYSTEM`加上诸如证明边界等有界限的路由信号, 跨路径范围,后果,和运行时间的可观察性。 JEV没有决定正确性. 工作流程从 `models.yaml`,在 将安装完整的ATDD Bun审查公约注入审查员的提示 以意向第一顺序提供投入。 审查员记录有条理的结果: `APPROVE | RETURN | ESCALATE`; 它永远不会变异任务状态 。 审查尝试保留在 `work//tasks/.reviews.yaml` 并且将永居其中. `APPROVE` 使任务符合协调员完成的条件. `RETURN` 是证明 要移动的协调员 `review → in_progress`。 。 。 . `ESCALATE` 任务留待审查(或协调员) ),而权威意图则得到解决。 只有协调员才能过渡 `review → done`。 。 。 . ## 可选线性单向镜像 Flow可以向Linear投放明确允许列表的任务或消息,同时保持Flow的权威. 默认是决定性的干线运行; 现场投影还需要在配置中有一个所有者接受的飞行员参考, 完全相同 `--authorization` 参数,以及 `LINEAR_API_KEY` 在进程环境中。 它没有进入命令或网络路径. ```sh atdd-flow linear mirror task demo delivery --config /secure/local/linear-mirror.yaml atdd-flow linear mirror task demo delivery --config /secure/local/linear-mirror.yaml \ --apply --authorization owner-approved-pilot ``` 制图和无躯体的不可移动收据写在服务台下面 `.atdd-flow/linear-mirror/`; 重试再利用一个相干流 ID 而不是创建另一个线性对象. 见 [发现报告和所有者可审查的试验计划](https://npmcn.com/package/%40afokapu/atdd-flow/docs/linear-one-way-mirror-pilot.adoc) 许可名单、编辑、路由、状态图和回滚合同 从不执行包含一个的线性符号或配置 . ## 可选 Jev 助手 Jev是只读的;它不能变异状态,批准证明,或覆盖 ATDD Bun . ```sh atdd-flow scout --goal 'Fix payment retry behavior' --path src/payment/retry.ts --path src/profile/avatar.ts atdd-flow focus-check example-app runtime-rollout --action 'Add a generic retry orchestration service' ``` `scout` 选择可能的文件. `focus-check` 返回时 `REQUIRED`, (中文(简体) ), `USEFUL_BUT_NOT_REQUIRED`,或 `SPECULATIVE`。 。 。 . 最终行为审查启动器也只使用JEV System-1对有界限的路由问题;低 路线自信变得保守 `SYSTEM` 出行路线. 使用 Jev 判断作为路由咨询, 绝不 作为正确性或完成权。 如果没有侦察或焦点判断,请使用仓库 参数和偏好较小的可逆解决方案;如果无法选择模型,则升级 保守到最强大的候选人. 在macOS上, Jev 只从 Keychain 项读取其 TypeSafe 密钥 `atdd-workflow.typesafe`· ; `TYPESAFE_API_KEY` 是一个临时或 CI 覆盖。 秘诀从未被写入到桌面记录,输出,Git,npm,或GitHub. ## 命令参考 ```sh bunx atdd-flow --help ``` 已安装的帮助是该版本的权威语法. ## 常见问题 ### @afokapu/atdd-flow 是什么？ 用于项目、座位、任务、线程和交割的文件系统第一服务台登记册\. ### 如何安装 @afokapu/atdd-flow？ 在项目目录运行 npm install @afokapu/atdd-flow，或使用 pnpm add / yarn add / bun add。它还提供命令行工具 atdd-flow，可以用 npx atdd-flow 直接运行。 ### @afokapu/atdd-flow 支持 TypeScript 吗？ 该包的 package\.json 没有声明类型入口。需要类型提示时，可以在 npm 上查找社区维护的 @types/afokapu\_\_atdd-flow 是否存在。 ### @afokapu/atdd-flow 支持 ESM 还是 CommonJS？ 以 ES Module 形式发布，推荐使用 import 引入。在 CommonJS 项目中，Node\.js 20\.19\+ / 22\.12\+ 可以直接 require\(\) 不含顶层 await 的 ES Module，更早的版本需要改用动态 import\(\)。 ### @afokapu/atdd-flow 可以商用吗？ @afokapu/atdd-flow 使用 MIT 许可。宽松许可：允许商业使用、修改和再分发，通常只需在分发时保留原版权与许可声明。以上为概括，不构成法律意见，请以许可原文为准。 ### @afokapu/atdd-flow 的下载量有多少？ 根据 npm 官方下载统计，@afokapu/atdd-flow 在 2026/10/05 – 2026/11/03 这 30 天内被下载 17,079 次，日均约 569 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入，适合横向比较热度，不能直接等同于使用人数。 ### @afokapu/atdd-flow 还在维护吗？ 最新版本 0\.3\.97 发布于 2026/11/06（今天）；至今共发布 102 个版本，其中过去 12 个月发布了 102 个；首次发布于 2026/10/05。发布频率只是参考信号：功能稳定的工具可能很少需要更新，建议结合源码仓库的 issue 和提交记录判断。