@bcelep/capint 0.4.2 → 0.6.5

package/skills/docx/scripts/schemas/microsoft/wml-cex-2018.xsd

@@ -0,0 +1,20 @@
+ <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" xmlns:s="http://schemas.openxmlformats.org/officeDocument/2006/sharedTypes" xmlns:w16="http://schemas.microsoft.com/office/word/2018/wordml" elementFormDefault="qualified" attributeFormDefault="qualified" blockDefault="#all" xmlns="http://schemas.microsoft.com/office/word/2018/wordml/cex" targetNamespace="http://schemas.microsoft.com/office/word/2018/wordml/cex">
+   <xsd:import id="w16" namespace="http://schemas.microsoft.com/office/word/2018/wordml" schemaLocation="wml-2018.xsd"/>
+   <xsd:import id="w" namespace="http://schemas.openxmlformats.org/wordprocessingml/2006/main" schemaLocation="../ISO-IEC29500-4_2016/wml.xsd"/>
+   <xsd:import id="s" namespace="http://schemas.openxmlformats.org/officeDocument/2006/sharedTypes" schemaLocation="../ISO-IEC29500-4_2016/shared-commonSimpleTypes.xsd"/>
+   <xsd:complexType name="CT_CommentsExtensible">
+     <xsd:sequence>
+       <xsd:element name="commentExtensible" type="CT_CommentExtensible" minOccurs="0" maxOccurs="unbounded"/>
+       <xsd:element name="extLst" type="w16:CT_ExtensionList" minOccurs="0" maxOccurs="1"/>
+     </xsd:sequence>
+   </xsd:complexType>
+   <xsd:complexType name="CT_CommentExtensible">
+     <xsd:sequence>
+       <xsd:element name="extLst" type="w16:CT_ExtensionList" minOccurs="0" maxOccurs="1"/>
+     </xsd:sequence>
+     <xsd:attribute name="durableId" type="w:ST_LongHexNumber" use="required"/>
+     <xsd:attribute name="dateUtc" type="w:ST_DateTime" use="optional"/>
+     <xsd:attribute name="intelligentPlaceholder" type="s:ST_OnOff" use="optional"/>
+   </xsd:complexType>
+   <xsd:element name="commentsExtensible" type="CT_CommentsExtensible"/>
+ </xsd:schema>

package/skills/docx/scripts/schemas/microsoft/wml-cid-2016.xsd

@@ -0,0 +1,13 @@
+ <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:w12="http://schemas.openxmlformats.org/wordprocessingml/2006/main" elementFormDefault="qualified" attributeFormDefault="qualified" blockDefault="#all" xmlns="http://schemas.microsoft.com/office/word/2016/wordml/cid" targetNamespace="http://schemas.microsoft.com/office/word/2016/wordml/cid">
+   <xsd:import id="w12" namespace="http://schemas.openxmlformats.org/wordprocessingml/2006/main" schemaLocation="../ISO-IEC29500-4_2016/wml.xsd"/>
+   <xsd:complexType name="CT_CommentsIds">
+     <xsd:sequence>
+       <xsd:element name="commentId" type="CT_CommentId" minOccurs="0" maxOccurs="unbounded"/>
+     </xsd:sequence>
+   </xsd:complexType>
+   <xsd:complexType name="CT_CommentId">
+     <xsd:attribute name="paraId" type="w12:ST_LongHexNumber" use="required"/>
+     <xsd:attribute name="durableId" type="w12:ST_LongHexNumber" use="required"/>
+   </xsd:complexType>
+   <xsd:element name="commentsIds" type="CT_CommentsIds"/>
+ </xsd:schema>

package/skills/docx/scripts/schemas/microsoft/wml-sdtdatahash-2020.xsd

@@ -0,0 +1,4 @@
+ <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:w12="http://schemas.openxmlformats.org/wordprocessingml/2006/main" elementFormDefault="qualified" attributeFormDefault="qualified" blockDefault="#all" xmlns="http://schemas.microsoft.com/office/word/2020/wordml/sdtdatahash" targetNamespace="http://schemas.microsoft.com/office/word/2020/wordml/sdtdatahash">
+   <xsd:import id="w12" namespace="http://schemas.openxmlformats.org/wordprocessingml/2006/main" schemaLocation="../ISO-IEC29500-4_2016/wml.xsd"/>
+   <xsd:attribute name="storeItemChecksum" type="w12:ST_String"/>
+ </xsd:schema>

package/skills/docx/scripts/schemas/microsoft/wml-symex-2015.xsd

@@ -0,0 +1,8 @@
+ <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:w12="http://schemas.openxmlformats.org/wordprocessingml/2006/main" elementFormDefault="qualified" attributeFormDefault="qualified" blockDefault="#all" xmlns="http://schemas.microsoft.com/office/word/2015/wordml/symex" targetNamespace="http://schemas.microsoft.com/office/word/2015/wordml/symex">
+   <xsd:import id="w12" namespace="http://schemas.openxmlformats.org/wordprocessingml/2006/main" schemaLocation="../ISO-IEC29500-4_2016/wml.xsd"/>
+   <xsd:complexType name="CT_SymEx">
+     <xsd:attribute name="font" type="w12:ST_String"/>
+     <xsd:attribute name="char" type="w12:ST_LongHexNumber"/>
+   </xsd:complexType>
+   <xsd:element name="symEx" type="CT_SymEx"/>
+ </xsd:schema>

package/skills/doubt-driven-development/SKILL.md

@@ -0,0 +1,243 @@
+---
+name: doubt-driven-development
+description: Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later.
+---
+
+# Doubt-Driven Development
+
+## Overview
+
+A confident answer is not a correct one. Long sessions accumulate context that quietly turns assumptions into "facts" without anyone noticing. Doubt-driven development is the discipline of materializing a fresh-context reviewer — biased to **disprove**, not approve — before any non-trivial output stands.
+
+This is not `/review`. `/review` is a verdict on a finished artifact. This is an in-flight posture: non-trivial decisions get cross-examined while course-correction is still cheap.
+
+## When to Use
+
+A decision is **non-trivial** when at least one of these is true:
+
+- It introduces or modifies branching logic
+- It crosses a module or service boundary
+- It asserts a property the type system or compiler cannot verify (thread safety, idempotence, ordering, invariants)
+- Its correctness depends on context the future reader cannot see
+- Its blast radius is irreversible (production deploy, data migration, public API change)
+
+Apply the skill when:
+
+- About to make an architectural decision under uncertainty
+- About to commit non-trivial code
+- About to claim a non-obvious fact ("this is safe", "this scales", "this matches the spec")
+- Working in code you don't fully understand
+
+**When NOT to use:**
+
+- Mechanical operations (renaming, formatting, file moves)
+- Following a clear, unambiguous user instruction
+- Reading or summarizing existing code
+- One-line changes with obvious correctness
+- Pure tooling operations (running tests, listing files)
+- The user has explicitly asked for speed over verification
+
+If you doubt every keystroke, you ship nothing. The skill applies only to non-trivial decisions as defined above.
+
+## Loading Constraints
+
+This skill is designed for the **main-session orchestrator**, where Step 3 (DOUBT, detailed below) can spawn a fresh-context reviewer.
+
+- **Do NOT add this skill to a persona's `skills:` frontmatter.** A persona that follows Step 3 would spawn another persona — the orchestration anti-pattern explicitly forbidden by `references/orchestration-patterns.md` ("personas do not invoke other personas").
+- **If you find yourself applying this skill from inside a subagent context** (where Claude Code prevents nested subagent spawn): the preferred path is to surface to the user that doubt-driven cannot run nested and let the main session handle it. As a last resort only, a degraded self-questioning fallback exists — rewrite ARTIFACT + CONTRACT as a fresh self-prompt with a hard mental separator from your prior reasoning, and walk Steps 1–5. This is **not fresh-context review** (you carry your own context with you), so flag the result as degraded and prefer escalation whenever the user is reachable.
+
+## The Process
+
+Copy this checklist when applying the skill:
+
+```
+Doubt cycle:
+- [ ] Step 1: CLAIM — wrote the claim + why-it-matters
+- [ ] Step 2: EXTRACT — isolated artifact + contract, stripped reasoning
+- [ ] Step 3: DOUBT — invoked fresh-context reviewer with adversarial prompt
+- [ ] Step 4: RECONCILE — classified every finding against the artifact text
+- [ ] Step 5: STOP — met stop condition (trivial findings, 3 cycles, or user override)
+```
+
+### Step 1: CLAIM — Surface what stands
+
+Name the decision in two or three lines:
+
+```
+CLAIM: "The new caching layer is thread-safe under the
+        read-heavy workload described in the spec."
+WHY THIS MATTERS: a race here corrupts user data and is
+                  hard to detect in QA.
+```
+
+If you can't write the claim that compactly, you have a vibe, not a decision. Surface it before scrutinizing it.
+
+### Step 2: EXTRACT — Smallest reviewable unit
+
+A fresh-context reviewer needs the **artifact** and the **contract**, not the journey.
+
+- Code: the diff or the function — not the whole file
+- Decision: the proposal in 3–5 sentences plus the constraints it has to satisfy
+- Assertion: the claim plus the evidence that supposedly supports it (kept distinct from the Step 1 CLAIM block, which is the orchestrator's hypothesis under scrutiny)
+
+Strip your reasoning. If you hand over conclusions, you'll get back validation of your conclusions. The unit must be small enough that a reviewer can hold it in mind in one read — if it's a 500-line PR, decompose first.
+
+### Step 3: DOUBT — Invoke the fresh-context reviewer
+
+The reviewer's prompt **must be adversarial**. Framing decides the answer.
+
+```
+Adversarial review. Find what is wrong with this artifact.
+Assume the author is overconfident. Look for:
+- Unstated assumptions
+- Edge cases not handled
+- Hidden coupling or shared state
+- Ways the contract could be violated
+- Existing conventions this might break
+- Failure modes under unexpected input
+
+Do NOT validate. Do NOT summarize. Find issues, or state
+explicitly that you cannot find any after thorough examination.
+
+ARTIFACT: <paste artifact>
+CONTRACT: <paste contract>
+```
+
+**Pass ARTIFACT + CONTRACT only. Do NOT pass the CLAIM.** Handing the reviewer your conclusion biases it toward agreement. The reviewer must independently determine whether the artifact satisfies the contract.
+
+In Claude Code, the role-based reviewers in `agents/` start with isolated context by design and are usable here — see `agents/` for the roster and per-domain match.
+
+**The adversarial prompt above takes precedence over the persona's default response shape.** Personas like `code-reviewer` are written to produce balanced verdicts with both strengths and weaknesses; doubt-driven needs issues-only output. Paste the adversarial prompt verbatim into the invocation so it overrides the persona's default. If a persona's response shape can't be overridden cleanly, fall back to a generic subagent with the adversarial prompt.
+
+#### Cross-model escalation
+
+A single-model reviewer shares blind spots with the original author — a colder, different-architecture model catches them. Doubt-driven is already opt-in for non-trivial decisions, so within that scope offering cross-model is part of the skill's value, not optional friction.
+
+**Interactive sessions: always offer. Never silently skip.**
+
+**Step 1: Ask the user**
+
+After the single-model review in Step 3 above, but before RECONCILE, pause and ask:
+
+> *"Single-model review complete. Want a cross-model second opinion? Options: Gemini CLI, Codex CLI, manual external review (you paste it elsewhere), or skip."*
+
+This question is mandatory in every interactive doubt cycle — even on artifacts that feel low-stakes. The user — not the agent — decides whether the cost is worth it. The agent's job is to surface the choice.
+
+**Step 2: If the user picks a CLI — verify, then invoke**
+
+1. Check the tool is in PATH (`which gemini`, `which codex`).
+2. Test it works (`gemini --version` or equivalent) before passing the full prompt — a stale or broken binary may pass `which` but fail on real input.
+3. Confirm the exact invocation with the user, including required flags, auth, and env vars (e.g., API keys). Implementations vary; never assume.
+4. Pass ARTIFACT + CONTRACT + the adversarial prompt **only**. No session context, no CLAIM.
+5. Mind shell escaping. If the artifact contains quotes, `$(...)`, or backticks, prefer stdin (`echo … | gemini`) or a heredoc over inline `-p "…"`. When in doubt, ask the user to confirm the invocation before running it.
+6. Take the output into Step 4 (RECONCILE).
+
+**Never interpolate the artifact into a shell-quoted argument.** Code, markdown, and review prompts routinely contain backticks, `$(...)`, and quote characters that will either truncate the prompt or execute embedded shell. Write the full prompt to a file and pipe it through stdin.
+
+Example shapes (verify flags against your installed tool — syntax differs across implementations and versions):
+
+```bash
+# Write the adversarial prompt + ARTIFACT + CONTRACT to a temp file first.
+# Then pipe via stdin so shell metacharacters in the artifact stay inert.
+
+# Codex (read-only sandbox keeps the CLI from writing to your workspace):
+codex exec --sandbox read-only -C <repo-path> - < /tmp/doubt-prompt.md
+
+# Gemini ('--approval-mode plan' is read-only; '-p ""' triggers non-interactive
+# mode and the prompt is read from stdin):
+gemini --approval-mode plan -p "" < /tmp/doubt-prompt.md
+```
+
+A read-only sandbox is the load-bearing detail: a doubt artifact may itself contain instructions (intentional or accidental prompt injection) that the cross-model CLI would otherwise execute against your workspace.
+
+**Step 3: If the CLI is unavailable or fails**
+
+Surface the failure explicitly. Offer: run it manually, try a different tool, or skip. Do not silently fall back to single-model — the user should know cross-model didn't happen.
+
+**Step 4: If the user skips**
+
+Acknowledge the skip in the output (*"Proceeding with single-model findings only"*) and continue to RECONCILE. Skipping is fine; silent skipping is not.
+
+**Non-interactive contexts** (CI, `/loop`, autonomous-loop, scheduled runs):
+
+- Cross-model is **skipped**, and the skip must be **announced** in the output: *"Cross-model skipped: non-interactive context."*
+- **Never invoke an external CLI without explicit user authorization** — this is a load-bearing safety property.
+
+Cross-model adds cost, latency, and tool fragility. The agent surfaces the choice every cycle; the user decides whether this artifact warrants it.
+
+### Step 4: RECONCILE — Fold findings back
+
+The reviewer's output is data, not verdict. **You are still the orchestrator.** Re-read the artifact text against each finding before classifying — rubber-stamping the reviewer is the same failure mode as ignoring it.
+
+For each finding, classify in this **precedence order** (first matching class wins):
+
+1. **Contract misread** — reviewer flagged something specifically because the CONTRACT you provided was unclear or incomplete. Fix the contract first, re-classify on the next cycle.
+2. **Valid + actionable** — real issue requiring a change to the artifact. Change it, re-loop.
+3. **Valid trade-off** — issue is real but cost of fixing exceeds cost of accepting. Document the trade-off explicitly so the user sees it.
+4. **Noise** — reviewer flagged something that's actually correct under context the reviewer didn't have. Note it, move on, and ask: would adding that context to the contract have prevented the false flag?
+
+A fresh reviewer can be wrong because it lacks context. Don't defer just because it's "fresh."
+
+### Step 5: STOP — Bounded loop, not recursion
+
+Stop when:
+
+- Next iteration returns only trivial or already-considered findings, **or**
+- 3 cycles completed (escalate to user, don't grind a fourth alone), **or**
+- User explicitly says "ship it"
+
+If after 3 cycles the reviewer still surfaces substantive issues, the artifact may not be ready. Surface this to the user — three unresolved cycles is information about the artifact, not a reason to keep looping.
+
+If 3 cycles is "obviously insufficient" because the artifact is large: the artifact is too big — return to Step 2 and decompose. Do not lift the bound.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "I'm confident, skip the doubt step" | Confidence correlates poorly with correctness on novel problems. Moments of certainty are exactly when blind spots hide. |
+| "Spawning a reviewer is expensive" | Debugging a wrong commit in production is more expensive. The check is bounded; the bug isn't. |
+| "The reviewer will just nitpick" | Only if unscoped. Constrain the prompt to "issues that would make this fail under the contract." |
+| "I'll do doubt at the end with `/review`" | `/review` is a final gate. Doubt-driven catches wrong directions early when course-correction is cheap. By PR time it's too late. |
+| "If I doubt every step I'll never ship" | The skill applies to non-trivial decisions, not every keystroke. Re-read "When NOT to Use." |
+| "Two opinions are always better than one" | Not when the second has less context and produces noise. Reconcile, don't defer. |
+| "The reviewer disagreed so I was wrong" | The reviewer lacks your context — disagreement is information, not verdict. Re-read the artifact, classify, then decide. |
+| "Cross-model is always better" | Cross-model catches blind spots a single model shares with itself, but it adds cost and tool fragility. Offer it every interactive doubt cycle — the user decides whether the artifact warrants it. The agent's job is to surface the choice, not to gate it. |
+| "User said yes once, so I can keep invoking the CLI" | Each invocation is its own authorization. The artifact, the prompt, and the flags change between calls — re-confirm the exact command with the user before every run. |
+
+## Red Flags
+
+- Spawning a fresh-context reviewer for a one-line rename or formatting change
+- Treating reviewer output as authoritative without re-reading the artifact text
+- Looping >3 cycles without escalating to the user
+- Prompting the reviewer with "is this good?" instead of "find issues"
+- Skipping doubt under time pressure on a high-stakes decision
+- Re-spawning fresh-context on an unchanged artifact (you'll get the same findings; you're stalling)
+- **Doubt theater (checkable signal)**: across 2 or more cycles where the reviewer surfaced substantive findings, zero findings were classified as actionable. You are validating, not doubting. Stop and escalate.
+- Doubting only after committing — that's `/review`, not doubt-driven development
+- Hardcoding an external CLI invocation without confirming with the user that the tool exists, is configured, and accepts that exact syntax
+- **Silently skipping cross-model in an interactive doubt cycle.** Even when not recommending it, the offer must be visible. Skipping is fine; silent skipping is not.
+- Falling back silently when an external CLI errors or is missing — surface the failure and let the user redirect
+- Stripping the contract from the reviewer's input
+- Passing the CLAIM to the reviewer (biases toward agreement)
+
+## Interaction with Other Skills
+
+- **`code-review-and-quality` / `/review`**: complementary. `/review` is post-hoc PR verdict; doubt-driven is in-flight per-decision. Use both.
+- **`source-driven-development`**: SDD verifies *facts about frameworks* against official docs. Doubt-driven verifies *your reasoning about the artifact*. SDD checks the API exists; doubt-driven checks you used it correctly under the contract.
+- **`test-driven-development`**: TDD's RED step is doubt made concrete — a failing test is a disproof attempt. When TDD applies, that failing test *is* the doubt step for behavioral claims.
+- **`debugging-and-error-recovery`**: when the reviewer surfaces a real failure mode, drop into the debugging skill to localize and fix.
+- **Repo orchestration rules** (`references/orchestration-patterns.md`): this skill orchestrates from the main session. A persona calling another persona is anti-pattern B — see Loading Constraints above.
+
+## Verification
+
+After applying doubt-driven development:
+
+- [ ] Every non-trivial decision (per the definition above) was named explicitly as a CLAIM before standing
+- [ ] At least one fresh-context review per non-trivial artifact (a failing test produced by TDD's RED step satisfies this for behavioral claims, per Interaction with Other Skills)
+- [ ] The reviewer received ARTIFACT + CONTRACT — NOT the CLAIM, NOT your reasoning
+- [ ] The reviewer's prompt was adversarial ("find issues"), not validating ("is it good")
+- [ ] Findings were classified against the artifact text (not rubber-stamped) using the precedence: contract misread / actionable / trade-off / noise
+- [ ] A stop condition was met (trivial findings, 3 cycles, or user override)
+- [ ] In interactive mode, cross-model was **explicitly offered** to the user (regardless of artifact stakes) and the response was acknowledged in the output
+- [ ] In non-interactive mode, cross-model was skipped and the skip was announced
+- [ ] Any external CLI invocation was preceded by a PATH check, a working-binary test, syntax confirmation with the user, and explicit authorization to run

package/skills/e2e-testing-guide/SKILL.md

@@ -0,0 +1,204 @@
+---
+name: e2e-testing-guide
+description: 为依赖浏览器或页面交互的任务生成真实用户视角的 E2E 验证清单，并在具备浏览器自动化能力且用户授权时执行页面验证、收集证据。
+---
+
+# E2E Testing Guide
+
+> "不要测试组件存在，要测试用户能不能完成事情。"
+
+你是 **E2E 验证编排者**。你的任务不是写一份空泛的测试建议，而是把需求、任务和页面行为转成可执行的真实用户验证路径：进入网站，按用户会做的顺序操作，观察页面反馈，覆盖关键状态，并留下能复核的证据。
+
+---
+
+## 触发条件
+
+当任务满足任一条件时使用本 skill：
+
+- `TASKS.md` 的验证类型包含 **E2E测试** 或 **手动验证**。
+- 改动影响浏览器页面、导航、表单、登录态、支付/提交/发布等用户流程。
+- 需求验收依赖真实页面状态，而不是单元测试或接口测试即可证明。
+- 用户明确要求“像真实用户一样测试”“进网站跑一遍”“浏览器验证”“截图验证”。
+
+---
+
+## 硬约束
+
+- **真实用户优先**：测试步骤必须围绕用户目标组织，不要按组件或代码文件罗列。
+- **不假装已测**：没有实际打开页面、执行操作、观察结果，就只能写 `未执行`，不能写 `通过`。
+- **证据闭环**：每个已执行场景必须记录 URL、环境、账号/角色（若适用）、关键截图或可复现观察。
+- **先授权再操作**：需要登录、访问外部站点、提交数据、删除/发布/支付等有副作用动作时，先向用户确认。
+- **不碰不可逆动作**：删除、付款、发送真实通知、发布到生产等动作默认停在确认页；除非用户明确授权。
+- **失败也算结果**：失败要记录实际现象、期望现象、复现步骤和疑似原因，不要把失败折叠成“需进一步测试”。
+
+---
+
+## 工作流程
+
+### 1. 读取上下文
+
+优先读取这些材料：
+
+1. 当前任务说明或 `TASKS.md` 中对应任务。
+2. 相关 PRD / 验收标准 / 用户故事。
+3. 影响的页面、路由、组件、接口和状态管理代码。
+4. 已有测试、seed 数据、开发启动方式、环境变量说明。
+
+如果缺少页面 URL、启动命令、测试账号或目标用户角色，先列为阻塞项并向用户询问。
+
+### 2. 建立用户旅程清单
+
+按用户目标产出测试清单，每条都必须能被浏览器操作验证：
+
+```text
+Journey J1: 用户完成核心目标
+  角色: 未登录访客 / 普通用户 / 管理员 / 其他
+  起点: URL 或入口页面
+  目标: 用户想完成的事情
+  数据: 需要输入或预置的数据
+  步骤: 真实点击、输入、等待、确认顺序
+  期望: 页面可见反馈、URL 变化、状态变化、数据持久化
+  证据: 截图 / URL / 控制台 / 网络请求 / 数据库观察
+```
+
+至少覆盖：
+
+- **核心成功路径**：用户能完成最主要的业务目标。
+- **首次进入路径**：空状态、未登录、无数据、默认配置。
+- **错误路径**：无效输入、权限不足、网络/API 失败、服务端校验错误。
+- **边界路径**：最小/最大输入、重复提交、刷新页面、返回上一页、多标签或重复操作。
+- **响应式路径**：桌面宽度和一个移动宽度；如果产品只支持桌面，要明确写出。
+- **可访问性基本路径**：键盘可达、焦点可见、按钮/表单有可理解名称。
+
+### 3. 生成执行计划
+
+在执行前输出一份短计划：
+
+```markdown
+## E2E Plan
+
+- Target: <站点 URL / 本地地址>
+- Environment: <dev/staging/prod-like>
+- Browser: <浏览器/设备尺寸>
+- Roles: <用户角色>
+- Data Setup: <需要准备的数据>
+- Journeys: J1, J2, J3...
+- Side Effects: <是否会创建/修改/删除数据>
+- Blockers: <缺失信息>
+```
+
+若具备浏览器自动化工具且没有阻塞项，询问或确认用户授权后再执行。若没有浏览器工具，交付测试指南并标注 `Execution: Not run - no browser automation available`。
+
+### 4. 浏览器执行协议
+
+执行时要像真实用户一样操作：
+
+1. 打开目标 URL，记录初始页面和环境。
+2. 从页面可见入口开始，不要直接调用内部 API 伪造状态。
+3. 点击真实按钮/链接，填写真实表单，等待页面反馈。
+4. 每次页面结构变化后重新观察页面，再继续下一步。
+5. 同时关注：
+  - URL / 路由是否符合预期。
+  - 页面文案和视觉状态是否让用户知道发生了什么。
+  - 表单校验是否清晰。
+  - 加载、空状态、错误状态是否可恢复。
+  - 控制台是否出现错误。
+  - 关键网络请求是否成功，失败时 UI 是否正确处理。
+6. 对高风险动作停在确认步骤，记录“未执行原因”和用户授权需求。
+
+### 5. 结果判定
+
+每个 Journey 只能使用这些状态：
+
+- `PASS`：实际执行，结果符合预期，并有证据。
+- `FAIL`：实际执行，结果不符合预期，并有复现步骤。
+- `BLOCKED`：因登录、权限、缺数据、环境不可用或需人工授权无法执行。
+- `NOT RUN`：未执行。必须说明原因，不能混同为通过。
+
+---
+
+## 输出格式
+
+最终输出必须包含：
+
+```markdown
+## E2E Verification
+
+### Scope
+- Target:
+- Environment:
+- Browser / Viewport:
+- User Role:
+- Build / Commit:
+
+### Checklist
+| ID | User Journey | Status | Evidence | Notes |
+|---|---|---|---|---|
+| J1 | <用户目标> | PASS/FAIL/BLOCKED/NOT RUN | <截图/URL/日志> | <关键观察> |
+
+### Findings
+- [HIGH/MEDIUM/LOW] <问题标题>
+  - Expected:
+  - Actual:
+  - Repro:
+  - Evidence:
+  - Suggested Fix:
+
+### Coverage Gaps
+- <未覆盖路径及原因>
+
+### Recommendation
+- <是否可以合并/发布/需要修复后重测>
+```
+
+如果没有发现问题，也要明确写：
+
+```text
+No E2E issues found in executed journeys. Remaining risk: <未覆盖范围>.
+```
+
+---
+
+## 常用 Journey 模板
+
+### 登录/认证
+
+- 访客进入受保护页面会被引导登录。
+- 正确账号能登录并回到原目标页。
+- 错误密码、空字段、过期会话有清晰提示。
+- 刷新页面后登录态保持或按设计失效。
+- 退出登录后不能通过返回按钮看到受保护内容。
+
+### 表单/提交
+
+- 用户能从入口找到表单并完成提交。
+- 必填、格式、长度、重复提交都有反馈。
+- 提交成功后页面给出明确结果，并能继续下一步。
+- 提交失败时用户输入不应无故丢失。
+
+### 列表/搜索/筛选
+
+- 空状态、加载状态、有数据状态都可理解。
+- 搜索、筛选、排序、分页能组合使用。
+- 刷新或复制 URL 后关键查询状态按设计保留。
+- 没有结果时提供恢复路径。
+
+### 创建/编辑/删除
+
+- 创建后能在列表或详情页看到新数据。
+- 编辑后数据持久化，刷新后仍正确。
+- 删除类动作必须有确认；未授权时停在确认前。
+- 取消操作不会产生副作用。
+
+### 导航/布局
+
+- 主要入口可发现，面包屑/返回路径合理。
+- 深链可直接打开。
+- 浏览器返回/前进不破坏状态。
+- 桌面和移动视口下关键操作不被遮挡。
+
+---
+
+## 质量标准
+
+好的 E2E 指南看起来应该像一名认真测试人员的操作记录：有目标、有路径、有证据、有判断。坏的指南只会写“测试登录、测试提交、测试页面显示”。那种不行。