npm - @tea-agent/loop-agent - Versions diffs - 0.39.0-next.3 → 0.39.0-next.31 - Mend

@tea-agent/loop-agent 0.39.0-next.3 → 0.39.0-next.31

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (238) hide show

package/skills/improve-codebase-architecture/html-report.md ADDED Viewed

@@ -0,0 +1,123 @@
+# HTML Report Format
+The architectural review is rendered as a single self-contained HTML file in the OS temp directory. Tailwind and Mermaid both come from CDNs. Mermaid handles graph-shaped diagrams reliably; hand-built divs and inline SVG handle the more editorial visuals (mass diagrams, cross-sections). Mix the two — don't lean on Mermaid for everything, it'll start to look generic.
+## Scaffold
+```html
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8" />
+    <title>Architecture review — {{repo name}}</title>
+    <script src="https://cdn.tailwindcss.com"></script>
+    <script type="module">
+      import mermaid from "https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs";
+      mermaid.initialize({ startOnLoad: true, theme: "neutral", securityLevel: "loose" });
+    </script>
+    <style>
+      /* small custom layer for things Tailwind doesn't cover cleanly:
+         dashed seam lines, hand-drawn-feeling arrow heads, etc. */
+      .seam { stroke-dasharray: 4 4; }
+      .leak { stroke: #dc2626; }
+      .deep { background: linear-gradient(135deg, #0f172a, #1e293b); }
+    </style>
+  </head>
+  <body class="bg-stone-50 text-slate-900 font-sans">
+    <main class="max-w-5xl mx-auto px-6 py-12 space-y-12">
+      <header>...</header>
+      <section id="candidates" class="space-y-10">...</section>
+      <section id="top-recommendation">...</section>
+    </main>
+  </body>
+</html>
+```
+## Header
+Repo name, date, and a compact legend: solid box = module, dashed line = seam, red arrow = leakage, thick dark box = deep module. No introduction paragraph — straight into the candidates.
+## Candidate card
+The diagrams carry the weight. Prose is sparse, plain, and uses the glossary terms ([language.md](language.md)) without ceremony.
+Each candidate is one `<article>`:
+- **Title** — short, names the deepening (e.g. "Collapse the Order intake pipeline").
+- **Badge row** — recommendation strength (`Strong` = emerald, `Worth exploring` = amber, `Speculative` = slate), plus a tag for the dependency category (`in-process`, `local-substitutable`, `ports & adapters`, `mock`).
+- **Files** — monospaced list, `font-mono text-sm`.
+- **Before / After diagram** — the centrepiece. Two columns, side by side. See patterns below.
+- **Problem** — one sentence. What hurts.
+- **Solution** — one sentence. What changes.
+- **Wins** — bullets, ≤6 words each. e.g. "Tests hit one interface", "Pricing logic stops leaking", "Delete 4 shallow wrappers".
+- **ADR callout** (if applicable) — one line in an amber-tinted box.
+No paragraphs of explanation. If the diagram needs a paragraph to be understood, redraw the diagram.
+## Diagram patterns
+Pick the pattern that fits the candidate. Mix them. Don't make every diagram look the same — variety is part of the point.
+### Mermaid graph (the workhorse for dependencies / call flow)
+Use a Mermaid `flowchart` or `graph` when the point is "X calls Y calls Z, and look at the mess." Wrap it in a Tailwind-styled card so it doesn't feel parachuted in. Style with classDef to colour leakage edges red and the deep module dark. Sequence diagrams work well for "before: 6 round-trips; after: 1."
+```html
+<div class="rounded-lg border border-slate-200 bg-white p-4">
+  <pre class="mermaid">
+    flowchart LR
+      A[OrderHandler] --> B[OrderValidator]
+      B --> C[OrderRepo]
+      C -.leak.-> D[PricingClient]
+      classDef leak stroke:#dc2626,stroke-width:2px;
+      class C,D leak
+  </pre>
+</div>
+```
+### Hand-built boxes-and-arrows (when Mermaid's layout fights you)
+Modules as `<div>`s with borders and labels. Arrows as inline SVG `<line>` or `<path>` elements positioned absolutely over a relative container. Reach for this when you want the "after" diagram to feel like one thick-bordered deep module with greyed-out internals — Mermaid won't render that with the right weight.
+### Cross-section (good for layered shallowness)
+Stack horizontal bands (`h-12 border-l-4`) to show layers a call passes through. Before: 6 thin layers each doing nothing. After: 1 thick band labelled with the consolidated responsibility.
+### Mass diagram (good for "interface as wide as implementation")
+Two rectangles per module — one for interface surface area, one for implementation. Before: interface rectangle is nearly as tall as the implementation rectangle (shallow). After: interface rectangle is short, implementation rectangle is tall (deep).
+### Call-graph collapse
+Before: a tree of function calls rendered as nested boxes. After: the same tree collapsed into one box, with the now-internal calls shown faded inside it.
+## Style guidance
+- Lean editorial, not corporate-dashboard. Generous whitespace. Serif optional for headings (`font-serif` works well with stone/slate).
+- Colour sparingly: one accent (emerald or indigo) plus red for leakage and amber for warnings.
+- Keep diagrams ~320px tall so before/after sits comfortably side by side without scrolling.
+- Use `text-xs uppercase tracking-wider` for module labels inside diagrams — they should read as schematic, not as UI.
+- The only scripts are the Tailwind CDN and the Mermaid ESM import. The report is otherwise static — no app code, no interactivity beyond Mermaid's own rendering.
+## Top recommendation section
+One larger card. Candidate name, one sentence on why, anchor link to its card. That's it.
+## Tone
+Plain English, concise — but the architectural nouns and verbs come straight from [language.md](language.md). Concision is not an excuse to drift.
+**Use exactly:** module, interface, implementation, depth, deep, shallow, seam, adapter, leverage, locality.
+**Never substitute:** component, service, unit (for module) · API, signature (for interface) · boundary (for seam) · layer, wrapper (for module, when you mean module).
+**Phrasings that fit the style:**
+- "Order intake module is shallow — interface nearly matches the implementation."
+- "Pricing leaks across the seam."
+- "Deepen: one interface, one place to test."
+- "Two adapters justify the seam: HTTP in prod, in-memory in tests."
+**Wins bullets** name the gain in glossary terms: *"locality: bugs concentrate in one module"*, *"leverage: one interface, N call sites"*, *"interface shrinks; implementation absorbs the wrappers"*. Don't write *"easier to maintain"* or *"cleaner code"* — those terms aren't in the glossary and don't earn their place.
+No hedging, no throat-clearing, no "it's worth noting that…". If a sentence could be a bullet, make it a bullet. If a bullet could be cut, cut it. If a term isn't in [language.md](language.md), reach for one that is before inventing a new one.

package/skills/improve-codebase-architecture/interface-design.md ADDED Viewed

@@ -0,0 +1,44 @@
+# Interface Design
+When the user wants to explore alternative interfaces for a chosen deepening candidate, use this parallel sub-agent pattern. Based on "Design It Twice" (Ousterhout) — your first idea is unlikely to be the best.
+Uses the vocabulary in [language.md](language.md) — **module**, **interface**, **seam**, **adapter**, **leverage**.
+## Process
+### 1. Frame the problem space
+Before spawning sub-agents, write a user-facing explanation of the problem space for the chosen candidate:
+- The constraints any new interface would need to satisfy
+- The dependencies it would rely on, and which category they fall into (see [deepening.md](deepening.md))
+- A rough illustrative code sketch to ground the constraints — not a proposal, just a way to make the constraints concrete
+Show this to the user, then immediately proceed to Step 2. The user reads and thinks while the sub-agents work in parallel.
+### 2. Spawn sub-agents
+Spawn 3+ sub-agents in parallel using the Agent tool. Each must produce a **radically different** interface for the deepened module.
+Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [deepening.md](deepening.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
+- Agent 1: "Minimize the interface — aim for 1–3 entry points max. Maximise leverage per entry point."
+- Agent 2: "Maximise flexibility — support many use cases and extension."
+- Agent 3: "Optimise for the most common caller — make the default case trivial."
+- Agent 4 (if applicable): "Design around ports & adapters for cross-seam dependencies."
+Include both [language.md](language.md) vocabulary and CONTEXT.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
+Each sub-agent outputs:
+1. Interface (types, methods, params — plus invariants, ordering, error modes)
+2. Usage example showing how callers use it
+3. What the implementation hides behind the seam
+4. Dependency strategy and adapters (see [deepening.md](deepening.md))
+5. Trade-offs — where leverage is high, where it's thin
+### 3. Present and compare
+Present designs sequentially so the user can absorb each one, then compare them in prose. Contrast by **depth** (leverage at the interface), **locality** (where change concentrates), and **seam placement**.
+After comparing, give your own recommendation: which design you think is strongest and why. If elements from different designs would combine well, propose a hybrid. Be opinionated — the user wants a strong read, not a menu.

package/skills/improve-codebase-architecture/language.md ADDED Viewed

@@ -0,0 +1,53 @@
+# Language
+Shared vocabulary for every suggestion this skill makes. Use these terms exactly — don't substitute "component," "service," "API," or "boundary." Consistent language is the whole point.
+## Terms
+**Module**
+Anything with an interface and an implementation. Deliberately scale-agnostic — applies equally to a function, class, package, or tier-spanning slice.
+_Avoid_: unit, component, service.
+**Interface**
+Everything a caller must know to use the module correctly. Includes the type signature, but also invariants, ordering constraints, error modes, required configuration, and performance characteristics.
+_Avoid_: API, signature (too narrow — those refer only to the type-level surface).
+**Implementation**
+What's inside a module — its body of code. Distinct from **Adapter**: a thing can be a small adapter with a large implementation (a Postgres repo) or a large adapter with a small implementation (an in-memory fake). Reach for "adapter" when the seam is the topic; "implementation" otherwise.
+**Depth**
+Leverage at the interface — the amount of behaviour a caller (or test) can exercise per unit of interface they have to learn. A module is **deep** when a large amount of behaviour sits behind a small interface. A module is **shallow** when the interface is nearly as complex as the implementation.
+**Seam** _(from Michael Feathers)_
+A place where you can alter behaviour without editing in that place. The *location* at which a module's interface lives. Choosing where to put the seam is its own design decision, distinct from what goes behind it.
+_Avoid_: boundary (overloaded with DDD's bounded context).
+**Adapter**
+A concrete thing that satisfies an interface at a seam. Describes *role* (what slot it fills), not substance (what's inside).
+**Leverage**
+What callers get from depth. More capability per unit of interface they have to learn. One implementation pays back across N call sites and M tests.
+**Locality**
+What maintainers get from depth. Change, bugs, knowledge, and verification concentrate at one place rather than spreading across callers. Fix once, fixed everywhere.
+## Principles
+- **Depth is a property of the interface, not the implementation.** A deep module can be internally composed of small, mockable, swappable parts — they just aren't part of the interface. A module can have **internal seams** (private to its implementation, used by its own tests) as well as the **external seam** at its interface.
+- **The deletion test.** Imagine deleting the module. If complexity vanishes, the module wasn't hiding anything (it was a pass-through). If complexity reappears across N callers, the module was earning its keep.
+- **The interface is the test surface.** Callers and tests cross the same seam. If you want to test *past* the interface, the module is probably the wrong shape.
+- **One adapter means a hypothetical seam. Two adapters means a real one.** Don't introduce a seam unless something actually varies across it.
+## Relationships
+- A **Module** has exactly one **Interface** (the surface it presents to callers and tests).
+- **Depth** is a property of a **Module**, measured against its **Interface**.
+- A **Seam** is where a **Module**'s **Interface** lives.
+- An **Adapter** sits at a **Seam** and satisfies the **Interface**.
+- **Depth** produces **Leverage** for callers and **Locality** for maintainers.
+## Rejected framings
+- **Depth as ratio of implementation-lines to interface-lines** (Ousterhout): rewards padding the implementation. We use depth-as-leverage instead.
+- **"Interface" as the TypeScript `interface` keyword or a class's public methods**: too narrow — interface here includes every fact a caller must know.
+- **"Boundary"**: overloaded with DDD's bounded context. Say **seam** or **interface**.

package/skills/loop-agent/references/command-reference.md CHANGED Viewed

@@ -100,6 +100,8 @@ loop-agent --help
 ```bash
 loop-agent inspect                                           # 当前 repo（自动检测）
 loop-agent --repo-root /path/to/target-repo inspect           # 指定 repo
+loop-agent inspect next                                      # 当前 npm next 绑定（version / SHA / unpublished commits）
+loop-agent inspect next --json
 ```
 ### 健康检查
@@ -132,13 +134,18 @@ SDK 回归或 SDK 可选依赖不可用时用 `cli-only` 诊断。CLI fallback
 ```bash
 loop-agent init instructions --repo-root <target-repo>
+loop-agent init model-catalog --repo-root <target-repo> --json
 loop-agent init --repo-root <target-repo> --profile full --merge \
-  --provider deepseek --model deepseek/deepseek-v4-flash
+  --low-model deepseek/deepseek-chat \
+  --med-model deepseek/deepseek-v4-flash \
+  --high-model deepseek/deepseek-v4-pro
 loop-agent init doctor --repo-root <target-repo>
 loop-agent init check-update --repo-root <target-repo> --json
 loop-agent init check-update --repo-root <target-repo> --markdown
 loop-agent init update --repo-root <target-repo> --bootstrap-surface
 loop-agent init update --repo-root <target-repo> --apply-safe
+loop-agent init update --repo-root <target-repo> --apply-safe \
+  --low-model <current-or-selected> --med-model <current-or-selected> --high-model <current-or-selected>
 loop-agent init reconcile --repo-root <target-repo> [--json|--markdown]  # compatibility low-level diagnostic
 loop-agent init upgrade --repo-root <target-repo> --json
 loop-agent init upgrade --repo-root <target-repo> --run-id <run-id> --status --json
@@ -146,13 +153,13 @@ loop-agent init upgrade --repo-root <target-repo> --run-id <run-id> --continue -
 loop-agent init upgrade --repo-root <target-repo> --run-id <run-id> --report --markdown
 ```
-fresh init 将精确引用写到 `executors.pi.LOW/MED/HIGH`。fresh `loop-agent init` 会将合格且完整的 `provider/model` 引用投影到 `executors.pi.LOW/MED/HIGH`，即 `executors.pi.LOW`、`executors.pi.MED` 和 `executors.pi.HIGH`。三个 tier 齐全时不会写入 `defaultModel`，也不会恢复或建议旧顶层 routing 字段。
+fresh init 将精确引用写到 `executors.pi.LOW/MED/HIGH`。模型先运行只读 `init model-catalog`：Pi SDK runtime 与 OpenCode 非 verbose 列表由代码确定性发现，只向模型暴露 provider/model、能力/成本/窗口元数据、Pi setup、兼容性与 credential-ready 布尔值，不暴露原始配置和凭据。已有档位仍存在于 Pi 时原样保留，只重选失效/缺失档位；代码在 update 时拒绝替换仍有效档位。Pi 无定义时先向用户补齐必要模型元数据并帮助字段级配置 `models.json`；只有认证缺失时保留 harness 并修复认证。三个 tier 齐全时不会写入 `defaultModel`，也不会恢复旧顶层 routing 字段。
 `init check-update` 是只读升级报告，用于发现目标项目是否落后于当前包内初始化 surface。输出会区分 deterministic actions、model merge tasks、human decisions 和 recommended next。`--markdown` 会渲染可直接交给模型执行的合并指引，包含 `allowedPaths`、`forbiddenPaths`、`mergeRules` 和 `verification`。
-`init update --bootstrap-surface` 为旧项目写入 `.harness/init-surface.json` 的 `inferred-baseline`，不伪装成历史 recorded baseline。`init update --apply-safe` 只执行确定性安全动作：补缺失文件、创建目录、刷新 managed block；已有但无法确认与当前包一致的文件会进入 model merge tasks，不会被覆盖。模型 merge 只会自动展开不含 tier 或其他旧字段的唯一、完整且可证明等价的旧 `defaultModel: "provider/model"`；顶层 `model`、`models`、`modelProfiles`、`modelRouting`、`verify`、`sequentialWorkflowRole`、部分/对象 tier、bare model、冲突 provider 或未知语义均 fail closed，并保留原始 `harness.json`。
+`init update --bootstrap-surface` 为旧项目写入 `.harness/init-surface.json` 的 `inferred-baseline`，不伪装成历史 recorded baseline。`init update --apply-safe` 只执行确定性安全动作：补缺失文件、创建目录、刷新 managed block；`harness.json` 永不走整文件 `refresh-owned-file`，即使它仍与旧 recorded hash 一致，也只允许字段级确定性迁移或 bounded merge。带完整三档参数的 update 只替换 catalog 已判定失效的档位，仍有效档位的对象形态与 thinking 配置保持不变。模型 merge 只会自动展开不含 tier 或其他旧字段的唯一、完整且可证明等价的旧 `defaultModel: "provider/model"`；其他歧义均 fail closed 并保留原文件。
-`init upgrade` 是写入型升级入口：首次运行冻结 controller identity、检查 npm latest、扫描 surface、自动执行安全动作，并把 run facts 持久化到 `.harness/init-upgrades/<run-id>/`。`--status` 与 `--report` 严格只读；`--continue` 会重新核验 identity、当前 hash 与不变量。版本选择、无法判定冲突、凭据、破坏性删除或 active writer 才进入 human decision。普通语义冲突返回具体单文件 `allowedPaths` merge task，主会话必须合并后继续，不能把 `needs-model-merge` 作为完成。默认管理项目级 OpenCode/Pi recovery 与 `.pi/settings.json` nested merge，保留显式 disabled，Pi trust 后才加载；默认不读写 `~/.pi/agent/settings.json`。旧 `init reconcile` 保留为兼容低层诊断。
+`init upgrade` 是写入型升级入口：首次运行冻结 controller identity 与脱敏模型目录，检查 npm latest，并用一次 surface scan 形成完整计划。固定投影按 recorded bytes 确定性增删改；recorded `harness.json` 按属性树增删字段并保留项目值、同步 schema；项目自适应内容由模型决定。多个语义合并在同一计划中串行排队，每次仍只开放一个文件的 `allowedPaths`；接受后直接激活下一项，不重复版本发现/规划，队列清空后只跑一次最终验证。确定性收敛最多两轮。完成态的 verification/report 均有 controller hash anchor，`--status`、`--report` 和已完成 run 的幂等 `--continue` 只读持久化证据，不重新跑项目校验。默认管理项目级 OpenCode/Pi recovery 与 `.pi/settings.json` nested merge，默认不读写 `~/.pi/agent/settings.json`。旧 `init reconcile` 保留为兼容低层诊断。
 升级在 managed block 收敛后生成只读 gitignore 迁移评估（`.harness/init-upgrades/<run-id>/gitignore-migration.json`）：inventory 已跟踪的 `.harness/**` 与 `.agents/**`，建议 index-only 命令 `git rm -r --cached --ignore-unmatch .harness` / `.agents`（只改 index、保留工作区文件；`scripts/**` 与 `ai_workspace/loop-agent/**` 永不出现）。`.agents` 已跟踪内容会触发 human-decision 暂停等待审查；非 Git 仓库、git 查询失败或存在 staged 条目时 `status: blocked` 且无命令建议。controller 不自动修改 Git index。

package/skills/playwright-cli/SKILL.md CHANGED Viewed

@@ -25,6 +25,7 @@ close
 goto
 snapshot
 find
+find-unique
 click
 dblclick
 fill
@@ -71,6 +72,16 @@ playwright-cli close
 普通交互和控制台输出均不能单独取得 passed authority。通过的 case 还需要同一 child 的有序
 controller receipts：successful `open` → successful `find` → successful post-execution cleanup。
+### 唯一性断言优先用 find-unique
+当语义要求「全页恰好一个」时，用 `playwright-cli find-unique "字面"` 代替人工数命中数：它内部
+执行 find 并在解析命中数 ≠ 1 时以非零退出码失败（零命中/多命中/输出不可解析均 fail），错误
+信息直接给出 `expected exactly 1 match, got N`。它只接受一个文本字面量、不接受 `--regex` 等
+flag。台账中标注 `==1` 的锚点、以及「唯一命中」类 AC 应优先用它；`>=N` 存在性断言仍用
+`find`（find-unique 会拒绝多命中）。controller 会解析两类命令的命中数写入 receipt，finalize
+时用 case 文档声明的 `find "字面" >=N / ==N` 对照 receipt 复核，缺失或不满足会把 passed
+降级为 blocked（assertion-not-receipt-backed），因此声明的断言必须真的执行。
 ## 受限证据采集
 - UI 状态：先 `snapshot`，完成交互后以成功 `find` 证明用户可见结果。
@@ -91,3 +102,14 @@ controller receipts：successful `open` → successful `find` → successful pos
 当环境、数据、权限、时序、异常路径或响应内容无法用 RAG、已验证 context URL 和 runtime allowlist 证明时，
 写入 `blocked` evidence，并提供具体 `blockedReason`。不要引入替代执行路径，也不要把隐藏状态或
 未观察到的网络结果当作通过证据。
+### 唯一控件早停（unique-control-unavailable）
+- 适用：AC 点名的具体控件在到达目标状态后的**首个 post-navigation snapshot** 中缺失，且页面没有
+  setup-required 门（如「需先完成 Pi setup」）。
+- 判定：用 case 给出的字面做**单次** `find`；返回 0 命中即为充分证据，直接写
+  `status=blocked`、`blockedReason=unique-control-unavailable`，在 execution.md 中引用该次 find 结果。
+- 禁止：换字面重试、反复 snapshot、绕路导航、多轮探索或请求 rerun。这些都产生无放大的 token
+  成本且不改变结论（Wave 3 教训：反复探测不存在控件耗掉约 717k input tokens）。
+- 若 snapshot 显示存在 setup-required 门或状态前置未满足，按其对应 blockedReason 记录
+  （环境/状态类），不属于本早停。

package/skills/playwright-cli-case-generator/SKILL.md CHANGED Viewed

@@ -14,11 +14,21 @@ description: 根据 FE-test RAG 知识包生成可由受限 playwright_cli runti
 ## 输入与边界
 - 只读取 `testcase/frontend/rag/context.md`、`coverage-map.md` 与已有 `testcase/frontend/cases/`。
+- 若存在 `testcase/frontend/rag/ui-anchors.md` 锚点台账，必须一并读取并作为 UI 断言的唯一事实源；台账缺失时按 RAG 知识包生成，但不得引用台账外的具体控件字面（缺失信息标 `blocked`）。
 - 只写 `testcase/frontend/cases/**`；不得回读 PRD、读取 `.harness/`，或写
   `testcase/frontend/evidence/**`。
 - 所有 API、字段限制、状态流转、数据来源、SLA、URL 与账号要求必须能在 RAG 知识包中追溯。
   缺失信息标记 `blocked` 或“需人工确认”，不得猜测。
+### 锚点台账规则（存在 ui-anchors.md 时）
+- case 中每条拟通过的 `find "<字面>"` 断言必须能在台账对应「页面 × 状态」节找到
+  状态为 `有效` 的行；台账 `不可断言` / `失效` 行的字面**禁止**作为通过断言。
+- AC 点名的控件在台账对应状态节缺失（0 命中或无行）时，该 AC 的 case 生成
+  `blocked` 语义说明（或从本批剔除该 AC），`blockedReason` 用
+  `unique-control-unavailable`，不得生成探测性步骤反复 find。
+- 台账行备注中的替代断言方案（如拆节点后的短字面二选一）按备注执行。
 ## 输出
 - 写 `index.md`、`manifest.draft.json`（生成阶段；materialize 会写成 `manifest.json`）与独立 case 文件
@@ -51,7 +61,16 @@ description: 根据 FE-test RAG 知识包生成可由受限 playwright_cli runti
    占位符仅表示从紧邻其前、最新一次 `snapshot` 输出解析出的真实 `eNN` ref。生成的 case 必须在每次
    引用元素前写明 fresh snapshot；`eX`/`eY` 不是可传给 structured tool 的 literal ref，新的 snapshot
    会使旧 ref 失效，不得复用 stale ref。
-5. 明确的 UI/API 预期与数据清理结果；无法满足的环境或数据依赖必须写为 `blocked`。
+5. **期望命中数不得内联进命令行（硬约束）**：如需声明 find 期望命中数，写在「预期结果」区或
+   列表项的说明文字中（如 “预期唯一命中”）；命令行只写纯命令 `playwright-cli find "<字面>"`。
+   禁止 `find "<字面>">=N`、`≥N`、`（≥N）` 等计数后缀内联进命令 token。
+6. **唯一性断言优先 find-unique**：台账或 AC 标注 `==1`/「唯一命中」的锚点，生成
+   `playwright-cli find-unique "<字面>"`（仅一个文本字面量，无 flag；多命中/零命中即命令失败）；
+   `>=N` 存在性断言仍用 `find`。finalize 会用 case 文档中 `find "字面" >=N / ==N` 声明对照
+   controller receipt 的解析命中数复核，声明的断言未真正执行或命中数不满足会把 passed 降级为
+   blocked（assertion-not-receipt-backed）——因此「测试点」里声明的每个 find 断言都必须在步骤中
+   真实执行且字面完全一致。
+7. 明确的 UI/API 预期与数据清理结果；无法满足的环境或数据依赖必须写为 `blocked`。
 所有文件型输出均由 controller 绑定到执行节点提供的
 `testcase/frontend/evidence/<case-id>/` 工作目录。截图一律使用 canonical 语法

package/dist/worker/console/static/assets/channel-DLVz9TYW.js DELETED Viewed

	@@ -1 +0,0 @@
1	- import{ag as o,ah as n}from"./mermaid.core-DWGK9kwP.js";const t=(a,r)=>o.lang.round(n.parse(a)[r]);export{t as c};

package/dist/worker/console/static/assets/classDiagram-JCYQIIEL-BeAuGcO9.js DELETED Viewed

@@ -1 +0,0 @@

- import{s as a,c as s,a as e,C as t}from"./chunk-GF5L2VYU-B-uGFIg2.js";import{_ as i}from"./mermaid.core-DWGK9kwP.js";import"./chunk-5VM5RSS4-D_ch2aaI.js";import"./chunk-XXDRQBXY-Bbfe3UJG.js";import"./chunk-KBJHAD2P-BjAUAfcT.js";import"./chunk-2GRJ4B5K-WTEKTxin.js";import"./index-DQxiso1w.js";var n={parser:e,get db(){return new t},renderer:s,styles:a,init:i(r=>{r.class||(r.class={}),r.class.arrowMarkerAbsolute=r.arrowMarkerAbsolute},"init")};export{n as diagram};

package/dist/worker/console/static/assets/classDiagram-v2-OCEON4UE-BeAuGcO9.js DELETED Viewed

@@ -1 +0,0 @@