@tea-agent/loop-agent 0.12.0 → 0.13.0-beta.0

package/skills/code-review-core/SKILL.md

@@ -1,20 +1,20 @@
----
-name: code-review-core
-description: 用于只读 code review 节点，产出带文件与行号引用的优先级 findings。
----
-
-# Code Review Core
-
-本 skill 用于 reviewer 节点。
-
-## Review 重点
-
-- 优先关注 correctness、行为回归、security、数据丢失与缺失验证。
-- findings 须 grounded 在具体文件与行号。
-- 区分 blocking findings 与次要 maintainability 备注。
-- 检查测试是否证明变更行为，文档是否与面向用户的变更一致。
-- 若无 findings，明确说明，并指出 residual test gap（如有）。
-
-## Output
-
-按 severity 排序列出 findings。仅当无 blocking findings 时，才写 `VERDICT: pass`。
+---
+name: code-review-core
+description: 用于只读 code review 节点，产出带文件与行号引用的优先级 findings。
+---
+
+# Code Review Core
+
+本 skill 用于 reviewer 节点。
+
+## Review 重点
+
+- 优先关注 correctness、行为回归、security、数据丢失与缺失验证。
+- findings 须 grounded 在具体文件与行号。
+- 区分 blocking findings 与次要 maintainability 备注。
+- 检查测试是否证明变更行为，文档是否与面向用户的变更一致。
+- 若无 findings，明确说明，并指出 residual test gap（如有）。
+
+## Output
+
+按 severity 排序列出 findings。仅当无 blocking findings 时，才写 `VERDICT: pass`。

package/skills/codebase-scout/SKILL.md

@@ -1,19 +1,19 @@
----
-name: codebase-scout
-description: 用于只读 scout 节点，在实现前定位现有代码、测试、文档与集成点。
----
-
-# Codebase Scout
-
-本 skill 用于 scout 节点。
-
-## 规则
-
-- 从 repo 指令、task source 与邻近测试入手。
-- 可用时优先 CodeGraph；否则用 `rg` 与聚焦文件阅读。
-- 在提议新抽象前，识别现有 helper 与 ownership 边界。
-- 只返回事实，不做编辑。
-
-## Output
-
-列出相关文件、现有模式、风险，以及实现所需的最小 write surface。
+---
+name: codebase-scout
+description: 用于只读 scout 节点，在实现前定位现有代码、测试、文档与集成点。
+---
+
+# Codebase Scout
+
+本 skill 用于 scout 节点。
+
+## 规则
+
+- 从 repo 指令、task source 与邻近测试入手。
+- 可用时优先 CodeGraph；否则用 `rg` 与聚焦文件阅读。
+- 在提议新抽象前，识别现有 helper 与 ownership 边界。
+- 只返回事实，不做编辑。
+
+## Output
+
+列出相关文件、现有模式、风险，以及实现所需的最小 write surface。

package/skills/frontend-design-review/SKILL.md

@@ -1,59 +1,66 @@
----
-name: frontend-design-review
-description: Use for the frontend plan design gate before any writer runs.
-references:
-  - path: references/review-checklist.md
-    required: true
----
-
-# Frontend Design Review
-
-Use for `frontend-design-gate-pi`. Read the required checklist first. Review the
-contract, scout report, plan, task source/constraints, `task.json` boundaries, and
-traceable component/design evidence. The connector format is TODO; never fabricate
-a result. When knowledge-base access is absent, failed, or unmatched, require evidence
-that `<repoRoot>/openSpec/**` was searched before accepting other repo conventions.
-
-## Verdict Contract
-
-The first non-empty line must be exactly:
-
-- `VERDICT: pass`
-- `VERDICT: request-revision`
-
-Use request-revision for any blocker. The shell gate reads this line exactly.
-
-## Blocking Conditions
-
-- An acceptance criterion lacks implementation or verification coverage.
-- Applicable UI states are missing without a reason.
-- A dependency is not explicitly permitted.
-- Confirmed project primitives/rules are ignored, or a claim has neither knowledge-base nor required `openSpec/` fallback evidence.
-- Planned paths exceed allowed/write scope or touch forbidden/generated paths.
-- Required static or behavior commands are missing or non-deterministic.
-- Interaction, responsive, accessibility, data, or failure behavior is ambiguous enough to require guessing.
-
-Knowledge-base unavailability alone is advisory when relevant `openSpec/` rules were
-searched and applied. Block when that fallback was skipped, sources conflict without
-resolution, or no source resolves a required user-visible decision.
-
-## Method And Output
-
-Map each criterion to steps, files, states, and checks; audit paths; verify evidence;
-then classify findings as Blocking or Advisory. Do not edit files.
-
-```markdown
-VERDICT: pass
-
-## Findings
-- None blocking.
-
-## Required Plan Corrections
-- None.
-
-## Checked Items
-- ...
-```
-
-For revisions, every correction names the criterion/section, missing evidence or
-decision, and exact plan change required.
+---
+name: frontend-design-review
+description: Use for the frontend plan design gate before any writer runs.
+references:
+  - path: references/review-checklist.md
+    required: true
+    maxChars: 3600
+---
+
+# Frontend Design Review
+
+For first/final design review nodes. Read the checklist, then audit contract, scout,
+mock strategy, plan/revision, task constraints/bounds, and traceable design evidence. The knowledge-
+base connector is TODO: never invent results. If absent/failed/unmatched, require
+`<repoRoot>/openSpec/**` search/read evidence before repo conventions.
+
+## Verdict Contract
+
+First non-empty line: exactly `VERDICT: pass` or `VERDICT: request-revision`.
+Any blocker requires request-revision; the shell gate reads this line exactly.
+
+For `frontend-final-design-review-pi`: recheck the original plan when output is
+`PASS_NO_REVISION_NEEDED`; otherwise verify every Required Plan Correction. Reject
+remaining, incomplete, or newly introduced gaps.
+
+## Blocking Conditions
+
+- Any criterion lacks implementation/verification; UI states lack reasons; a
+  dependency lacks permission; confirmed primitives/rules are ignored; design claims
+  lack knowledge-base or required `openSpec/` evidence; paths cross write bounds;
+  commands are missing/non-deterministic; or interaction, responsive, accessibility,
+  data, or failure behavior requires guessing.
+- `MOCK_STRATEGY: blocked`; missing permitted target paths, endpoint/schema-to-fixture
+  mapping, fixed verification, or dev/test-only activation; a second Mock framework;
+  inline fake data; commented real requests; Mock-on production defaults; test-only
+  production imports; or Mock evidence reported as real integration.
+
+Knowledge-base absence is advisory if relevant `openSpec/` rules were searched/read
+and applied. Block skipped fallback, unresolved conflict, or unresolved UI decisions.
+
+## Method And Output
+
+Map criteria to steps/files/states/checks, audit paths/evidence, classify Blocking or
+Advisory, and never edit files.
+
+### Spec Evidence Rules
+
+Run `grep`/`find`, then explicit `read` calls for applicable specs and checklist.
+Only successful paired reads count as “已读取规范文件”; summaries do not. List each
+read path/section in `Checked Items`. If the connector is unavailable, search/read
+`openSpec/` before accepting repository conventions.
+
+```markdown
+VERDICT: pass
+
+## Findings
+- None blocking.
+
+## Required Plan Corrections
+- None.
+
+## Checked Items
+- ...
+```
+
+Each correction names its criterion/section, gap, and exact plan change.

package/skills/frontend-design-review/references/review-checklist.md

@@ -1,37 +1,58 @@
-# Frontend Design Review Checklist
-
-## Requirement And State Coverage
-
-- Target route/page/component and non-goals are clear.
-- Every acceptance criterion maps to steps, files, UI behavior, and verification.
-- Assumptions and unresolved ambiguity are explicit.
-- Success, error/validation, loading, empty, disabled, permission, retry, repeated-action, stale-response, and boundary states are handled or marked not applicable.
-
-## Project And Knowledge Fit
-
-- Existing components, hooks, API helpers, mocks, schemas, router patterns, templates, tokens, and theme rules were considered.
-- Component/design choices cite a knowledge-base result or relevant `openSpec/` rule.
-- If knowledge-base setup/query failed or returned no match, `<repoRoot>/openSpec/**` was recursively searched before other repo evidence.
-- Source is `knowledge-base`, `openSpec fallback`, `repository fallback`, or `unavailable`; evidence includes query/search terms, matched paths/headings, and conflicts.
-- Dependencies are authorized; paths fit allowed/write scope and avoid forbidden/generated files.
-
-## Interaction And Quality
-
-- Actions, feedback, validation timing, navigation, persistence, and recovery are unambiguous.
-- Responsive and overflow behavior covers target environments.
-- Keyboard, focus, semantics, contrast, reduced motion, data lifecycle, cancellation, and error recovery are addressed when applicable.
-
-## Verification
-
-- Static and behavior commands are exact, discoverable, and deterministic.
-- Tests prove changed state logic and flows at repository-supported levels.
-- Browser/visual checks are required only by task intent or existing gates.
-- Every missing verification path is a blocker or disclosed risk.
-
-## Verdict Matrix
-
-- Coverage gap, unsafe scope, unauthorized dependency, unresolved required interaction, or missing required verification: request revision.
-- Missing knowledge-base evidence and skipped `openSpec/` fallback: request revision.
-- No relevant knowledge-base or `openSpec/` rule for a required decision: request revision.
-- Knowledge-base unavailable but relevant `openSpec/` rules were applied: advisory connection gap, not a specification gap.
-- Optional cleanup that cannot affect acceptance: advisory.
+# Frontend Design Review Checklist
+
+## Requirement And State Coverage
+
+- Target route/page/component and non-goals are clear.
+- Every acceptance criterion maps to steps, files, UI behavior, and verification.
+- Assumptions and unresolved ambiguity are explicit.
+- Applicable success, error, loading, empty, disabled, permission, retry, stale-response, and boundary states are handled or marked N/A.
+
+## Project And Knowledge Fit
+
+- Existing components, hooks, API helpers, mocks, schemas, router patterns, templates, tokens, and theme rules were considered.
+- Component/design choices cite knowledge-base or `openSpec/`; failed/empty knowledge-base queries recurse through `<repoRoot>/openSpec/**` first.
+- Evidence records source status, query terms, paths/headings, and conflicts.
+- Dependencies are authorized; paths fit allowed/write scope and avoid forbidden/generated files.
+- A required Mock-backed strategy reuses native support when proven, otherwise an
+  existing browser-intercept/request-adapter seam; it maps endpoint/states to fixtures,
+  stays in writer scope, and is off in production. `not-needed` adds none.
+
+## Interaction And Quality
+
+- Actions, feedback, validation timing, navigation, persistence, and recovery are unambiguous.
+- Responsive and overflow behavior covers target environments.
+- Keyboard, focus, semantics, contrast, reduced motion, data lifecycle, cancellation, and error recovery are addressed when applicable.
+
+## Verification
+
+- Static and behavior commands are exact, discoverable, and deterministic.
+- Tests prove changed state logic and flows at repository-supported levels.
+- Browser/visual checks are required only by task intent or existing gates.
+- Every missing verification path is a blocker or disclosed risk.
+- Verification entrypoints are frozen; any Mock-specific command is generated only
+  from trusted sources, and behavior separately proves page consumption.
+
+## Mock Strategy Safety
+
+- The strategy protocol is valid and not `MOCK_STRATEGY: blocked`.
+- For Mock strategies, API fields and fixture states trace to contract evidence; gaps are explicit.
+- Selection follows repository capability: native mock first, browser interception
+  for existing e2e, request adapter/injection for local preview.
+- The real request remains enabled by default; activation is explicit, reversible,
+  local/test-only, and excluded from production behavior.
+- Verification uses only shell entrypoints fixed when the DAG was generated; the
+  plan does not invent commands that shell nodes cannot execute.
+- Mock strategies include a production/default-real-path build with Mock off and
+  Mock-backed behavior evidence. `not-needed` instead needs applicable real or
+  no-remote behavior evidence.
+- Mock-backed checks prove frontend states only. Real integration remains pending
+  until the actual backend path has fresh evidence.
+
+## Verdict Matrix
+
+- Coverage gap, unsafe scope, unauthorized dependency, unresolved required interaction, or missing required verification: request revision.
+- Missing knowledge-base evidence and skipped `openSpec/` fallback: request revision.
+- No relevant knowledge-base or `openSpec/` rule for a required decision: request revision.
+- Unsafe/missing mock strategy or mock evidence presented as real integration: request revision.
+- Knowledge-base unavailable but relevant `openSpec/` rules were applied: advisory connection gap, not a specification gap.
+- Optional cleanup that cannot affect acceptance: advisory.

package/skills/frontend-implementation/SKILL.md

@@ -1,51 +1,47 @@
----
-name: frontend-implementation
-description: >-
-  Use for frontend contract, scout, plan, and implementation DAG nodes.
-references:
-  - path: references/node-contracts.md
-    required: true
-    maxChars: 3000
-  - path: references/design-spec.md
-    required: true
-    maxChars: 3000
-  - path: references/code-standards.md
-    required: true
-    maxChars: 3000
----
-
-# Frontend Implementation
-
-Use for `frontend-contract-pi`, `frontend-scout-pi`, `frontend-plan-pi`, and
-`frontend-implement-pi`. Read every required reference before acting.
-
-## Source And Evidence Rules
-
-Use task source and references first, then constraints and `task.json`. Resolve
-component/design rules by the required sequence in `design-spec.md`: connect/query
-the knowledge base first; when it is not configured, connection/query fails, or no
-relevant result exists, search `<repoRoot>/openSpec/**` and treat matching rules as
-the current project's specification. Use other repository evidence only afterward.
-
-- Cite repository findings with paths and symbols or tight line ranges.
-- Label assumptions, unresolved questions, and unavailable evidence.
-- Never invent conventions, component APIs, tokens, commands, or knowledge-base results.
-- Record the selected source as `knowledge-base`, `openSpec fallback`, `repository fallback`, or `unavailable`, with evidence and conflicts.
-
-## Implementation Discipline
-
-- Treat explicit project specs and repo-local skills as authoritative within their stated scope.
-- Reuse confirmed components, tokens, helpers, APIs, mocks, schemas, and test patterns.
-- Do not add dependencies unless the task allows them and the approved plan justifies them.
-- Cover applicable success, error, loading, empty, disabled, permission, and boundary states; mark non-applicable states with reasons.
-- Keep state and validation logic testable where project conventions support it.
-- Writer nodes stay inside `writeSet`, preserve unrelated behavior, and update tests with behavior.
-- Never relax lint/type/test/build configuration or write unauthorized generated output.
-
-## Output And Failure Rules
-
-- Follow the node-specific headings in `node-contracts.md` exactly.
-- Read-only nodes return Markdown and never edit repository files.
-- Missing input blocks a node when proceeding would guess behavior, design compliance, write boundaries, or verification.
-- Keep protocol tokens, commands, paths, identifiers, and configured output language unchanged.
-- Implementation may report attempted checks, but completion requires fresh downstream shell evidence.
+---
+name: frontend-implementation
+description: >-
+  Use for frontend contract, scout, mock strategy, plan, and implementation DAG nodes.
+references:
+  - path: references/node-contracts.md
+    required: true
+    maxChars: 4800
+  - path: references/design-spec.md
+    required: true
+    maxChars: 3000
+  - path: references/code-standards.md
+    required: true
+    maxChars: 3000
+---
+
+# Frontend Implementation
+
+Read all required references before running any listed frontend node.
+
+## Source And Evidence Rules
+
+Use task sources/references, constraints, then `task.json`. Follow `design-spec.md`:
+knowledge base; `<repoRoot>/openSpec/**` after unavailable/failed/empty; then repo
+evidence. Cite tight paths/symbols, label gaps/conflicts, and never invent APIs,
+rules, commands, or retrievals. Scout/planners locate and explicitly read applicable
+specs; only successful paired reads count. Lockfile-only, fixture-only, or unread
+search hits do not prove a reusable Mock service.
+
+## Implementation Discipline
+
+- Reuse confirmed specs, components, tokens, helpers, APIs, mocks, schemas, and tests.
+- Keep real requests enabled by default; never comment them out for a mock.
+- Prefer native Mock support; otherwise use existing browser interception for e2e or
+  a reversible request adapter/DI seam for local preview.
+- Trace fixtures to API/schema evidence. Activation is explicit, dev/test-only,
+  production-off; Mock evidence never proves real API integration.
+- Add dependencies only when approved. Cover applicable success/loading/empty/error/
+  permission/boundary states and justify N/A.
+- Keep state testable. Stay in `writeSet`, preserve behavior, and update tests.
+- Never relax lint/type/test/build config or write unauthorized generated output.
+
+## Output And Failure Rules
+
+- Follow `node-contracts.md`; read-only nodes never edit. Missing input blocks work
+  when proceeding would guess behavior, bounds, or verification.
+- Preserve tokens, commands, paths, IDs, and language. Completion needs fresh shell evidence.

package/skills/frontend-implementation/references/code-standards.md

@@ -1,34 +1,32 @@
-# Frontend Code Standards
-
-Discover project rules from task constraints, the component/design source sequence
-in `design-spec.md`, configuration, source, tests, manifests, and generated types.
-When knowledge-base access is unavailable, relevant `<repoRoot>/openSpec/**` rules
-are normative for the current project. Generic style preferences are not rules, and
-documentation never overrides an installed API without an explicit compatibility decision.
-
-## Discover And Cite
-
-- Routing, server/client boundaries, state, forms, data fetching, cache/invalidation, and error boundaries.
-- API, mock, page, component, hook, utility, schema, template, and test directories.
-- Component, hook, route, mock, utility, and test naming.
-- Unit, component, integration, browser/e2e, fixture, and mock expectations.
-- Approved/forbidden dependencies and human-approval rules.
-
-Cite a representative file or configuration for every convention. When neighboring
-code conflicts, describe the alternatives rather than silently choosing one.
-
-## Plan And Implement
-
-- Map each acceptance criterion to code and verification.
-- Determine component placement, state ownership, request lifecycle, validation, error handling, API/schema compatibility, mocks, and fixtures.
-- Prefer existing helpers and public APIs; preserve behavior outside the contract.
-- Keep rendering, transitions, validation, and side effects separable where the project pattern supports it.
-- Handle cancellation, stale responses, repeated actions, and boundary inputs when applicable.
-- Update tests at repository-supported levels; update relevant existing tests before adding duplicates.
-- Keep writes inside `writeSet`; generated output requires explicit authorization.
-
-## Prohibited
-
-- Do not relax lint/type/test configuration.
-- Do not add dependencies, a parallel component library, styling system, or state framework without permission.
-- Do not describe an unexecuted command or unavailable browser/knowledge-base flow as verified.
+# Frontend Code Standards
+
+Discover rules from task constraints, `design-spec.md` source order, config, code,
+tests, manifests, and generated types. After knowledge-base failure, applicable
+`<repoRoot>/openSpec/**` rules are normative. Preferences are not rules, and docs do
+not override installed APIs without an explicit compatibility decision.
+
+## Discover And Cite
+
+- Find routing and server/client boundaries; state, forms, data/cache, and errors;
+  API/mock/UI/schema/test locations and naming; supported tests; dependency rules.
+
+Cite representative files/config for each convention. Describe conflicts instead of
+silently selecting one.
+
+## Plan And Implement
+
+- Map criteria to code and checks. Define placement, state ownership, request
+  lifecycle, validation/failures, API compatibility, mocks, and fixtures.
+- Trace fixtures to API evidence; label gaps. Prefer native mocks, then browser
+  interception for existing e2e, then a reversible request adapter/DI preview seam.
+- Real API stays default; mock activation is explicit, local/test-only,
+  non-production, and removable.
+- Reuse helpers/public APIs and preserve out-of-contract behavior. Keep rendering,
+  transitions, validation, and side effects testable; cover lifecycle races/bounds
+  when relevant. Update supported tests; stay in `writeSet`.
+
+## Prohibited
+
+- Do not relax checks, add unapproved dependencies, comment real requests, hardcode
+  fixtures in production UI, import test mocks into production, store fixture
+  secrets, equate mock evidence with real integration, or report unrun checks as verified.

package/skills/frontend-implementation/references/design-spec.md

@@ -1,46 +1,46 @@
-# Frontend Design And Component Specification
-
-## Required Source Sequence
-
-1. Attempt the configured component/design knowledge-base query first.
-2. If unavailable, failed, timed out, or unmatched, recursively search the project root's exact `openSpec/` directory.
-3. Treat relevant matches as the current project's specification for this run.
-4. Only then use component source, tokens, stories, tests, and pages as non-normative repository fallback.
-
-Never skip `openSpec/` directly to neighboring-code conventions. Report source
-conflicts instead of combining them. Explicit task requirements remain the contract;
-flag conflicts with knowledge-base or `openSpec/` rules.
-
-## Knowledge Base Connection — TODO
-
-Request format is undecided. TODO: define connector/owner, namespaces, secret-free
-auth, query fields, result identity/version/time, and failure behavior.
-
-Attempt only a connector actually available in the execution environment. Otherwise
-record `not-configured` and run the `openSpec/` fallback; never invent a connection.
-
-## `openSpec/` Fallback Procedure
-
-- Confirm whether `<repoRoot>/openSpec/` exists and enumerate its files recursively.
-- Read indexes first, then search names/content using task, route, component, interaction, theme, token, and state terms.
-- Read relevant matches in context; do not treat a filename-only hit as a rule.
-- Record search terms, inspected/matched paths, headings or tight line ranges, applied rules, and conflicts.
-- If the directory or relevant rules are absent, record that fact before using repository fallback.
-
-## Retrieval Evidence
-
-Record source as `knowledge-base`, `openSpec fallback`, `repository fallback`, or
-`unavailable`. Knowledge-base evidence includes query, source ID/version/time, rules,
-and conflicts. `openSpec fallback` includes terms, paths/headings/lines, rules, and conflicts.
-
-## Rules To Retrieve Or Discover
-
-- Components, variants, props, composition, accessibility, deprecations, placement, forms, overlays, navigation, and state patterns.
-- Tokens, typography, color, layout, breakpoints, motion, focus/keyboard/contrast, exceptions, design debt, and forbidden patterns.
-
-## Gate Expectations
-
-- Reuse confirmed primitives unless a new pattern is authorized.
-- Define applicable states and responsive behavior before implementation.
-- Cite knowledge-base or `openSpec/` evidence for component/token choices; label weaker repository fallback.
-- Make deviations and unresolved gaps explicit.
+# Frontend Design And Component Specification
+
+## Required Source Sequence
+
+1. Attempt the configured component/design knowledge-base query first.
+2. If unavailable, failed, timed out, or unmatched, recursively search the project root's exact `openSpec/` directory.
+3. Treat relevant matches as the current project's specification for this run.
+4. Only then use component source, tokens, stories, tests, and pages as non-normative repository fallback.
+
+Never skip `openSpec/` directly to neighboring-code conventions. Report source
+conflicts instead of combining them. Explicit task requirements remain the contract;
+flag conflicts with knowledge-base or `openSpec/` rules.
+
+## Knowledge Base Connection — TODO
+
+Request format is undecided. TODO: define connector/owner, namespaces, secret-free
+auth, query fields, result identity/version/time, and failure behavior.
+
+Attempt only a connector actually available in the execution environment. Otherwise
+record `not-configured` and run the `openSpec/` fallback; never invent a connection.
+
+## `openSpec/` Fallback Procedure
+
+- Confirm whether `<repoRoot>/openSpec/` exists and enumerate its files recursively.
+- Read indexes first, then search names/content using task, route, component, interaction, theme, token, and state terms.
+- Read relevant matches in context; do not treat a filename-only hit as a rule.
+- Record search terms, inspected/matched paths, headings or tight line ranges, applied rules, and conflicts.
+- If the directory or relevant rules are absent, record that fact before using repository fallback.
+
+## Retrieval Evidence
+
+Record source as `knowledge-base`, `openSpec fallback`, `repository fallback`, or
+`unavailable`. Knowledge-base evidence includes query, source ID/version/time, rules,
+and conflicts. `openSpec fallback` includes terms, paths/headings/lines, rules, and conflicts.
+
+## Rules To Retrieve Or Discover
+
+- Components, variants, props, composition, accessibility, deprecations, placement, forms, overlays, navigation, and state patterns.
+- Tokens, typography, color, layout, breakpoints, motion, focus/keyboard/contrast, exceptions, design debt, and forbidden patterns.
+
+## Gate Expectations
+
+- Reuse confirmed primitives unless a new pattern is authorized.
+- Define applicable states and responsive behavior before implementation.
+- Cite knowledge-base or `openSpec/` evidence for component/token choices; label weaker repository fallback.
+- Make deviations and unresolved gaps explicit.