| name | full-chain-testing |
| description | 完整功能链路测试执行器（stack-agnostic / project-agnostic）。当多个 feature 已陆续收尾、 某条**跨多 feature 的端到端旅程（A→B→C）首次贯通**、需要为这条关键旅程织一张端到端安全网时使用： 与前三格根本不同——本格的被测对象**不是给定的，要先从系统结构里【挖掘】出来**。先从三源 （静态代码图 + 运行时 trace + spec 契约）挖出一份**跨多 feature 的通路清单（path inventory）**， 挑 P0 关键旅程，再端到端验证、固化成安全网。覆盖跨多 feature 且含非 UI 跳步（定时任务 / 异步 / 跨通道）的 完整链路；单 feature 内单切片归"局部前后端"第三格，不在这里。两个最独特点：① 被测对象要先被挖掘出来； ② 它是**安全网层**——少而精只盖 P0；**若 bug 首次在这层被发现，说明下层（单后端/单前端/局部前后端）漏测了， 应回补下层**。六步闭环：挖通路+选 P0 → 全系统编排+只 stub 外部边界 → 条件命中 → 两层落地 → RED→GREEN（禁 sleep， fake clock/手动触发定时任务/poll-retry 等最终态）→ 归档+拆栈+PR 人审。触发词：完整功能链路 / 端到端旅程 / 跨 feature 测试 / 通路挖掘 / path inventory / 关键旅程 / 安全网 / journey 测试 / full chain testing / e2e journey / 链路贯通测试。天然要最多代码才能跑、是最后才能执行的一格；代码未落地时只能"挖候选通路 + 写 RED E2E"不能跑。遵循 testing-system-blueprint 蓝本（风险分级 / 可追溯 / 发布门 / 三层节奏），受自愈护栏约束 （只写测试不改产品码、断言不可弱化、禁伪造修复、有界重试、产 PR 人审，发现真 bug 回交 superpowers TDD）。 被 test-routing-advisor 判定"完整功能链路"时调用，也可直接触发。兄弟：backend-testing（单后端）/ frontend-testing（单前端）/ fullstack-slice-testing（局部前后端）。 |
full-chain-testing · 完整功能链路测试执行器
这个 skill 解决什么
前三格各自盯一个给定的、范围明确的被测对象：backend-testing 验单后端的真实、frontend-testing
验单前端的渲染与交互契约、fullstack-slice-testing 在单个 feature 内把一条消费者↔提供者切片拉活对账。
它们的共同前提是——被测对象是已知的，边界由那个 feature 划好了。
完整功能链路是第四格，它解决的是另一类问题：当多个 feature 陆续完成后，一条"用户从 A feature 走到
B feature 再到 C feature"的端到端旅程会【首次贯通】。这条旅程跨多个 feature、常常含非 UI 的跳步
（定时任务触发、异步消息、跨通道投递），从来没有任何一格盯过它整条是否真的连得起来。
本格就是给这类跨多 feature 的关键旅程织一张端到端安全网。
本质一句话：完整功能链路 = 先从系统结构里挖出一条条跨多 feature 的端到端通路（path inventory）
→ 挑出 P0 关键旅程 → 端到端验证，作为安全网。 覆盖跨多 feature、且含非 UI 跳步
（定时任务 / 异步 / 跨通道）的完整链路。单 feature 内的单条切片归第三格"局部前后端"，不在这里。
遵循 testing-system-blueprint 蓝本（按名引用即可）：风险分级排序、可追溯 ID、发布门、三层节奏（本格落 L3）。
两个最独特点（务必先读懂——它们决定了本格与前三格的根本不同）
独特点 ①：被测对象要先被【挖掘】出来
前三格的被测对象是给定的（"测这个后端""测这个前端""测这条切片"）。本格不是——没有人会
直接告诉你"完整链路有哪几条"。一条跨多 feature 的旅程散落在多个 feature 的代码、配置、契约里，
它作为一个整体从未在任何一处被显式声明过。所以本格的第一项、也是最核心的工作，是把通路从
系统结构里挖出来（path inventory）。挖通路的方法论见下方 ⭐ 三源模型——这是本 skill 最核心、已实证的部分。
独特点 ②：它是"安全网层"，少而精只盖 P0
链路 E2E 慢且脆（蓝本 §三 L3）。本格不追覆盖率，只对挖出来的通路里风险最高的 P0 关键旅程
织网——"整条链路确实贯通"这件 L1/L2/前三格无法覆盖的事，才是它存在的唯一理由。由此引出一条铁律：
若某个 bug 是【首次】在本层（链路 E2E）被发现的，那是下层漏测的信号——说明它本该在单后端 /
单前端 / 局部前后端被更便宜地抓住，却漏了。此时除了让链路转绿，更要【回补下层】，把这个缺陷
在它本该被抓住的那一格补成回归。 链路层是"补网"，不是"首次发现 bug 的垃圾桶"（蓝本 §三 L3 心态）。
两条绝对约束（先读，贯穿全程）
- stack-agnostic（栈无关）：所有能力一律用"能力描述 + 按栈/场景实例化 lookup"表达，绝不把某一
工具写死成依赖或唯一答案。本文与
references/gaps.md 里出现的 glia / OpenLore / Pathfinder /
Tracetest / docker-compose / OpenTelemetry / AppMap / eBPF / gstack /qa 等，全部只是"某栈/某场景的
实例示例"，绝不是唯一解，更不是硬依赖。环境里没有某个工具，就回退到该能力的通用等价物。
- 特别提醒（glia）：glia 是非商业 license——可作"静态代码图"能力的示例提及，但商业产品不可用；
更重要的是本 skill 不绑定任何单一工具，静态图能力可由任意等价物实例化（OpenLore 式或该栈自带的
调用图 / 依赖分析）。
- gstack
/qa 不是硬依赖——它只是"diff-aware E2E"在某环境下的一个实例；没有它就回退通用 E2E。
本 skill 不写任何 gstack 安装步骤。
- project-agnostic（项目无关）：不出现任何业务名词，也不绑定任何具体框架或协议。所有项目专有的东西
——具体有哪些 cron / 定时任务、某跳步是不是流式（SSE / WebSocket / 长轮询）、具体接口形状、token / 鉴权
/ 一次性登录机制、跨通道用什么、项目里到底有没有 gstack——一律运行时现读、绝不写进 skill，也绝不预设。
一律写成条件式："若旅程含定时触发，则用 fake clock / 手动触发……"、"若某跳步是流式，则……"。
⭐ 通路挖掘 = 三源模型（本 skill 最核心、已实证的部分）
挖通路不能靠单一信息源——没有任何一个源能挖出整张图。本格的核心方法论是三源互补：每个源
只可靠地挖得动一类边，合起来才拼得出一条完整的跨 feature 通路。这是被两个真实项目 + 控制实验坐实的结论。
静态代码图（glia / OpenLore 式，按栈实例化） → 可靠挖出：后端路由 / 资源 / 调用图 / 共享依赖
（语法指纹清晰的边）
运行时 trace（分布式追踪 / AppMap 式） → 现代前端栈下【唯一可靠地】补：
FE↔BE 桥边 + 解耦边（HTTP / cron / 异步 / 跨通道）
spec 契约（项目自己的跨 feature 契约表 / AC） → 兜语义 + 代码未落地时的【唯一真理源】
三源各自的边界、能力、与已知失败模式（写进 skill 当"已知失败模式"，下次别再踩）：
源 A · 静态代码图（按栈实例化，glia / OpenLore 为示例，非依赖）
能挖：后端路由、资源、调用图、共享依赖——凡是语法指纹清晰的边（一个函数显式调另一个、一个
路由显式挂某 handler、多 feature 显式 import 同一个共享模块），静态图都挖得很准。
已知失败模式（两个真实项目 + 控制实验坐实，务必当成已知事实写入认知）：
- 静态图只挖得动"半张图"——只覆盖语法清晰的边。
- 挖不动"框架封装的跨服务请求边"：现代前端基本不写裸
fetch，只要请求经过框架封装
（AI-SDK / 自建 client / 模板 URL 拼接 等），FE↔BE 桥边就在静态图里断掉。这已在两个独立项目
各自复现，且控制实验证明 resolver 本身没坏（把同样的调用还原成裸 fetch 就能被挖到）——
即这不是工具 bug，而是"框架封装吃掉了语法指纹"的结构性边界。
→ 结论：FE↔BE 桥边必须靠源 B（运行时 trace）或源 C（spec 契约）补，不能指望静态图。
- cron / queue 这类解耦边：静态 resolver 的 corpus 稀疏（corpus-sparse）、命中不乐观。
→ 优先靠源 B（trace）/ 源 C（spec）补，别死磕静态图。
源 B · 运行时 trace（分布式追踪 / AppMap 为示例，非依赖）
唯一可靠地补静态图挖不动的两类边：① FE↔BE 桥边（框架封装吃掉语法指纹后，只有真跑一遍、
看 trace 才知道前端那次交互到底打了哪个后端端点）；② 解耦边（HTTP / cron / 异步消息 / 跨通道
投递——这些边在代码里是"发了就走、另一头另起炉灶"，静态连不起来，trace 能把同一条 trace-id /
correlation-id 串起来）。
实例化 lookup（非唯一解）：分布式追踪（OpenTelemetry 式）/ 执行轨迹录制（AppMap 式）/
内核级观测（eBPF 式）——按栈与可观测设施现读现选；环境没有就退到"加临时日志埋点 + 手动跑一遍串边"。
源 C · spec 契约（项目自己的跨 feature 契约表 / AC，不依赖任何工具）
兜两件事：① 语义——trace 能告诉你"A 之后真的调了 B"，但为什么调、这条边属于哪条业务旅程、
这条旅程的 P0 验收点是什么，要回到项目自己的 spec / 跨 feature 契约表 / AC 里读。② 代码未落地时的
唯一真理源——见下方时机说明。
已知失败模式：代码未落地时（链路只存在于 spec 里），静态工具与 trace 全瞎（没有代码可分析、
没有运行时可追）。→ 此时 spec 契约是唯一真理源，仍可据它"挖候选通路 + 写 RED E2E"（写好但还不能跑绿）。
三源合用的纪律：先用源 A 挖出后端骨架（半张图），再用源 B 把 FE↔BE 桥边和解耦边补齐成整张图，
全程用源 C 兜语义、定 P0、并在代码未落地时充当唯一真理源。任何一源缺位都拼不出完整跨 feature 通路。
工作流（六步闭环）
骨架与前三格同构，差异集中在步骤 0"挖通路"（独特点 ①）与"安全网层"心态（独特点 ②）。
步骤 0 · 挖通路（三源）+ 选 P0
- 三源挖通路（见上方 ⭐ 三源模型）：源 A 挖后端骨架 → 源 B 补 FE↔BE 桥边 + 解耦边 → 源 C 兜语义。
产出一份跨多 feature 的通路清单（path inventory）：每条通路记录它穿过哪些 feature、含哪些跳步
（UI 可走段 / 定时 / 异步 / 跨通道）。
- 选 P0 关键旅程（P0 = 风险/优先级四档 P0–P3 里最高档，P0 最高→P3 最低；完整判据见蓝本
risk-tiers.md）：按蓝本 §一 风险分级，从通路清单里只挑 P0（数据损坏 / 越权 / 资金额度错算 /
核心主流程不可用 / 不可撤销的对外投递 等"出事即不可逆 + 高频"的旅程）。安全网少而精——不要把通路清单里每条都织成 E2E。
- 确认"跨多 feature"：每条入选旅程必须真的跨多个 feature。若某条其实只在单 feature 内（哪怕含
前后端），它属第三格"局部前后端"，剔出本格，回交
fullstack-slice-testing。
挖不出明确的跨 feature 通路、或拿不到任何一源（栈不可分析 + 无可观测 + 无 spec）就停下来问，别假设。
步骤 1 · 全系统编排 + 外部边界 stub（本格"立地基"）
链路 E2E 要把整条旅程穿过的所有 feature + 它们依赖的中间件一起、可复现地拉活——比第三格"起两侧"
范围更大。这一步只做一件事：让整条 P0 旅程能一键、可复现地以真实形态起来，健康检查通过。
- 内部全真：旅程穿过的所有内部 feature / 服务 / 中间件（DB / 缓存 / 队列 / 调度器…，具体有哪些
运行时现读）一律以真实形态参与——这正是链路测试的价值，禁止把被测的内部 feature stub 掉
（stub 掉就退化、失去意义，见护栏）。
- 只 stub 外部第三方边界：仅对系统边界之外、不可控、贵或慢的第三方依赖打桩——典型如 LLM /
推送通道 / 支付。具体哪些是"外部边界"运行时现读，别预设。
- 复用项目里现成的编排定义（compose / 启动脚本 / CI service 段，运行时现读）；没有才按栈实例化最小编排。
- 冒烟验证地基可用：起栈后先打通一条最简单的真实旅程，证明整条链能动，再进入分层断言。
这一步绿之前，不写任何链路断言。
步骤 2 · 条件命中（每条 P0 旅程含哪些跳步）
对每条入选旅程，运行时确认它实际含哪些跳步类型，决定后面怎么驱动、怎么断言：
| 跳步类型 | 含义 | 落地方式（步骤 3/4 据此选） |
|---|
| UI 可走段 | 旅程里有用户在界面上真的点 / 输入的段 | 可选 diff-aware E2E（gstack /qa 为其一）或通用 E2E 驱动；非依赖，无则回退 |
| 定时触发 | 旅程靠 cron / scheduler 推进（非 UI 跳步） | 编排驱动：fake clock 控时 / 手动触发该定时任务，绝不真等到那个钟点 |
| 异步 | 旅程靠消息 / 队列 / 后台任务推进 | 编排驱动 + poll-retry 等最终态（有界重试，不固定 sleep） |
| 跨通道 | 旅程跨入站 / 出站通道（如经第三方通道再回） | 编排驱动 + 在外部边界 stub 处观测投递、断真实落点 |
"含非 UI 跳步"是本格区别于纯前端 E2E 的关键：一条完整链路常常是"用户点一下 → 定时任务半夜
生成 → 异步推送到某通道 → 用户在另一端收到"。非 UI 跳步用编排驱动（手动触发 / fake clock /
观测异步最终态），不能靠在 UI 上干等。
步骤 3 · 两层落地
对每条 P0 旅程，按"先黑盒贯通、再结构化断言"两层落地：
- 第一层 · 黑盒贯通：在已起好的全系统真栈上，把整条旅程端到端跑一遍，确认"A→B→C 整条确实通"。
- UI 可走段：若环境已有 diff-aware E2E 工具（gstack
/qa 为其一）优先用（聚焦改动相关的旅程、省时）；
没有就回退通用 E2E（Playwright / Cypress 或该栈等价物）。本 skill 不写其安装步骤。
- 非 UI 跳步：用编排驱动把旅程推过去（手动触发定时任务 / fake clock 推进 / 发一条真实消息 /
在 stub 边界观测投递）。
- 再次强调：E2E 工具只探测已跑的 localhost、不起栈——所以步骤 1 起栈必须已完成。
- 第二层 · 结构化链路断言：沿旅程的关键交接点逐点断言（A 的输出真的成了 B 的输入、B 的产物真的
触发了 C、跨通道投递真的落到正确终点、最终态真的达成且一致）。黑盒贯通只证"通了"，结构化断言才证
"每个交接点逐项对得上"——这才是把安全网固化成回归的部分。
具体工具与断言模式见 references/gaps.md，按步骤 0 挖通路时识别的栈 / 跳步类型取对应行。
步骤 4 · RED→GREEN（禁 sleep）+ 数据隔离
- 数据隔离先行：链路 E2E 跑在全系统真栈上、穿过多个 feature 的数据，必须有 seed / teardown
fixture 保证整条旅程的数据可控、互不污染、可重复（起一份已知数据 → 跑整条旅程 → 清掉）。
- 控时与等待的铁律（最易踩、护栏级）：
- 禁
sleep / waitForTimeout 假装就绪或假装到点——链路含定时 / 异步跳步时，固定睡眠既慢又脆且骗人。
- 定时跳步：用 fake clock 控时 或手动触发该定时任务，把旅程"快进"到目标时点。
- 异步 / 跨通道跳步：用 poll-retry 等最终态（有界重试轮询到目标状态），而非固定睡固定秒数。
- RED：先写会失败的链路断言，确认它因真实链路缺陷而红（某交接点对不上、解耦边没接上、最终态没达成），
而不是因为栈没起好 / 测试写错 / 睡眠不够而红。真红有理，才往下走。
- GREEN：让断言转绿。
- 若红暴露的是真实链路 bug——HALT，不要自己改产品码（见护栏），回交
superpowers:test-driven-development / superpowers:systematic-debugging 修，修完再回本 skill 固化回归。
- 并且（独特点 ②）：判断这个 bug 是不是"首次在链路层才被发现"——若是，说明下层漏测了，
同时提示回补下层（把它在单后端 / 单前端 / 局部前后端那一格补成回归，让它下次在更便宜的层被抓住）。
- 断言不可弱化：禁止为转绿放松断言（把交接点断言删掉、把最终态校验改宽、把时序断言注释掉、
把禁掉的 sleep 偷偷加回来）。
步骤 5 · 归档（进发布门、journey 级可追溯）+ 拆栈 + PR 人审
每条新增的链路安全网测试：
- 按
testing-system-blueprint 风险分级进发布门——P0 关键旅程进发布门硬阻断（链路断 = 核心
业务旅程不可用）。安全网只盖 P0，所以入选的基本都是发布门硬项。
- 挂 journey 级可追溯 ID——关联这条旅程穿过的多个 feature / 多个 AC / 含哪些跳步（比单 feature
的可追溯粒度更粗，但要能机械回答"这条跨 feature 旅程测了没"）。
- 对齐三层节奏：链路 E2E 属蓝本 L3（最慢、最脆），只放"验证整条链确实通"这一件 L1/L2/前三格
覆盖不了的事；不要把单元级 / 单 feature 级断言塞进链路 E2E。
- 拆栈（teardown）：CI 与本地节奏都是 起全系统栈 → 跑旅程 → 拆栈；测完把真栈与数据一并清理。
- 补测以 PR 形式交付，由人审核合并；PR 说明列出：挖出的通路清单摘要、入选的 P0 旅程及理由、
每条旅程含哪些跳步、用了哪三源挖到它、外部边界 stub 了哪些、以及——若发现 bug——它是否首次在链路层
被发现 + 已回补到下层哪一格。
时机说明（诚实写进 skill，别假装能提前跑）
full-chain 天然要最多代码才能跑——它要把整条跨多 feature 旅程穿过的所有 feature 都拉活。
因此它是最后才能真正执行的一格：必须等旅程穿过的那些 feature 都已落地。
- 代码未落地时（链路只存在于 spec 里）：源 A / 源 B 全瞎（无代码可析、无运行时可追），源 C（spec 契约）
是唯一真理源。此时仍能做、且应该做：用 spec 挖候选通路 + 写 RED E2E（断言写好、挂上可追溯，
但因代码没到而红 / 挂起，不能跑绿）。
- 方法论可先于代码建好：本 skill 是可复用资产——挖通路的三源模型、安全网选 P0 的判据、编排与控时
纪律，都可以在代码齐全之前先想清楚、先把候选通路与 RED E2E 落好。真验证（跑绿）跟着代码走。
关键区别于前三格（务必讲清）
| 前三格（后端 / 前端 / 局部前后端） | 本格（完整功能链路） |
|---|
| 被测对象 | 给定的（边界由那个 feature 划好） | 要先从三源挖出来（独特点 ①） |
| 范围 | 单 feature（前两格单侧，第三格单 feature 内单切片） | 跨多 feature + 含非 UI 跳步（定时 / 异步 / 跨通道） |
| 层级心态 | 各自盖各自的真实 / 接缝 | 安全网层，少而精只盖 P0；bug 首现于此 = 下层漏测，回补下层（独特点 ②） |
| 起栈范围 | 一侧 / 单 feature 两侧 | 整条旅程穿过的所有 feature + 中间件，只 stub 外部边界 |
| 执行时机 | feature 收尾即可 | 最后才能跑；代码未落地时只能挖候选通路 + 写 RED E2E |
自愈护栏（不可越过）
补测过程允许有界自动迭代（挖通路 → 起栈 → RED → GREEN → 拆栈），但受以下护栏约束（沿用 blueprint 的护栏）：
- 只写测试 / 编排配置，不改产品码——这是默认动作。本 skill 负责挖通路、起全系统栈、配编排、写链路断言，不修业务实现。
- 断言不可弱化——禁止为转绿放松断言（删交接点断言、放宽最终态校验、注释时序断言、缩小契约比对字段集）。
- 禁伪造修复——不得用
skip、固定 sleep / waitForTimeout 假装就绪或假装到点、把被测的内部
feature 偷偷 stub 掉、起假服务冒充真栈等手段伪装通过。本格一旦把被测的内部 feature stub 掉，
就退化成下层、失去全部意义（stub 只允许打在外部第三方边界上）。
- 有界重试升级——链路 E2E 天然脆（端口竞争、健康检查抖动、异步最终态未达、跨通道延迟）；自动迭代有
上限，连续失败达上限即停止并升级给人，绝不靠"再跑一次就好"或"再多睡几秒"掩盖真实的链路不稳定。
- 产 PR 人审——所有产物（通路清单 + 编排配置 + 链路安全网测试）以 PR 交付，人工审核后合并。
- 发现真 bug 要 HALT，回交 superpowers 修——本 skill 不自行改产品代码。RED 暴露真实链路缺陷时
停下来，回交
superpowers:test-driven-development / superpowers:systematic-debugging 走修复闭环，
修完再回本 skill 固化回归。并且：若该 bug 首次在链路层被发现，同时提示回补下层（独特点 ②）——
让它在本该被抓住的更便宜的那一格也补成回归。
护栏的目的：让链路安全网可以自动织，但任何"把被测内部 feature stub 回去""栈没真起就假装通过""靠 sleep
掩盖时序""越界改产品码"的捷径都被堵死。
与上下游的关系
- 上游：
test-routing-advisor 判定"完整功能链路"时调用本 skill（也可被用户直接触发）。杀手锏对接：
路由器从依赖图推导出"完成某 feature 后某条跨 feature 旅程 A→B→C 首次贯通"并提示"这条链路现在可以端到端
测了"——本 skill 正是接住这个提示、把那条旅程挖实并织成安全网的执行器。
- 蓝本：所有挖通路后的分级 / 可追溯 / 发布门 / 节奏遵循
testing-system-blueprint（按名引用，不复制其内容）；本格落 L3。
- 兄弟：
backend-testing（单后端）/ frontend-testing（单前端）/ fullstack-slice-testing（局部前后端，
单 feature 内单切片）——三者是"下层"；本格 bug 首现时回补的就是它们。
- 可参考（非依赖）：Pathfinder 的 journey→E2E 骨架生成思路、Tracetest 的 trace→断言思路——
作为"挖到通路后如何生成 E2E / 如何把 trace 转成链路断言"的实例参考，不绑定、环境没有就用通用等价物。
- 方法论复用：发现真链路缺陷的修复与调试复用
superpowers:test-driven-development 和
superpowers:systematic-debugging（本 skill HALT 后回交它们）。
- 边界：单 feature 内单切片属第三格
fullstack-slice-testing，不在本格。
配套实现：scripts/ 通路挖掘 + 可视化工具
本 skill 附带一套 clean-room 自研的参考实现（MIT，归用户所有），把"挖通路 → 合并三源 →
派生 journey → 生成 RED E2E → 可视化"这条流程做成可真跑的工具。stack-agnostic / project-agnostic：
按栈识别（读 pyproject/package.json）后处理，不写死任何业务名。反瞎编铁律：每条边都带 provenance
（文件:行号 或 trace span），指不出证据的边只标 candidate，绝不假装坐实。
中心产物 path-inventory.json（scripts/pathinv.py 定义 schema + 校验门）：
features / nodes / edges(每条带 source+status+provenance) / journeys。
| 文件 | 刀 | 语言 | 用途 |
|---|
scripts/pathinv.py | 共享 | Python | path-inventory schema + status 升级 + validate() 反瞎编门 |
scripts/knife1_spec.py | 刀1 源C | Python | 解析 spec-kit tasks.md 的 [依赖] Fn / [BE/FE/INT] / [FR 来源] → 跨 feature 候选边（candidate，证据=文件:行号） |
scripts/knife2_static.py | 刀2 源A | Python | AST(Python FastAPI 装饰器/import/redis key/scheduler) + 正则(Next route/import/fetch/redis) → code-confirmed；框架封装的 FE→BE（useObject/useChat）老实标 candidate |
scripts/knife3_trace.py | 刀3 源B | Python | 读 correlation-id 结构化事件日志 → trace-confirmed 边（证据=span/event） |
scripts/knife4_merge.py | 刀4 | Python | 三源合并去重、status 升级、标 spec-only 缺口、派生 journey、按风险启发式标 P0（注"需人确认"） |
scripts/knife5_e2e.py | 刀5 | Python | 选一条 journey → 生成 pytest/Playwright RED E2E 骨架（condition-based wait，禁 sleep） |
scripts/knife6_viewer.html | 刀6 | HTML/JS | 单文件自包含（纯 DOM+CSS，无重依赖）；给人看的"用户旅程清单"——每条 journey 一句话 summary + 步骤流芯片，按 status 着色（candidate=虚线灰 / code=蓝 / trace=绿），点步骤看 provenance 详情；技术散点图降级为"查看技术细节"折叠 |
scripts/view.sh | 一键开图 | bash | bash view.sh demo / bash view.sh alpha / bash view.sh out/xxx.json → 自动起本地服务 + 打开浏览器 + 数据已加载，无需拖拽 |
scripts/run_pipeline.sh | 编排 | bash | 起 demo → 注入 cid 跑旅程 → 刀2+刀3 → 刀4 合并 → 刀5 骨架，输出到 scripts/out/ |
demo-app/ | 验证靶 | Python(stdlib)+HTML | 小而全多 feature demo（A 前端按钮→B 接口写 kv+异步→C cron 读 kv+推送），含全部边类型，真能跑 |
使用流程（触发时机 + 自动产出 + 看图）
- 触发时机 —— 不是"全部 feature 开发完"才触发。是某条跨多 feature 的端到端旅程首次贯通时
触发(逐 journey,不是项目结尾)。
test-routing-advisor 的"杀手锏"就是从依赖图主动发现这种"首次贯通"
并提示——人最容易忘的就是这个。
- 自动产出 —— 触发后,按本 skill 步骤跑 spec 解析 → 静态扫码 → trace 采集 → 三源合并,自动产出
path-inventory.json。对 demo,bash scripts/run_pipeline.sh 一键真跑通;对真实项目,Claude 按 skill
读栈、按栈实例化、跑出等价产物到 scripts/out/。
- 一键看图 ——
bash scripts/view.sh demo(或 alpha / 任意 inventory 路径)→ 自动起本地服务 + 打开
浏览器 + 数据已加载,直接进酷炫"用户旅程清单"页面,无需拖拽。
(双击 knife6_viewer.html 后把 json 拖入页面投放区是 file:// 兜底用法,推荐用 view.sh。)
单点用法:对 spec 树跑 knife1_spec.py <specs/>、对真代码跑 knife2_static.py <repo/>,再
knife4_merge.py 合并、knife4b_narrate.py 补叙事——这一串其实就是步骤 2 的拆解。
