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

package/skills/frontend-implementation/SKILL.md

@@ -3,9 +3,9 @@ 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/node-contracts.md
+    required: true
+    maxChars: 3200
   - path: references/design-spec.md
     required: true
     maxChars: 3000
@@ -16,36 +16,39 @@ references:
 
 # Frontend Implementation
 
-Use for `frontend-contract-pi`, `frontend-scout-pi`, `frontend-plan-pi`, and
-`frontend-implement-pi`. Read every required reference before acting.
+For `frontend-contract-pi`, `frontend-scout-pi`, `frontend-plan-pi`, and
+`frontend-implement-pi`. Read all required references first.
 
 ## 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.
+Use task sources/references, constraints, then `task.json`. Resolve design rules in
+`design-spec.md` order: query the knowledge base; if unavailable, failed, or empty,
+search `<repoRoot>/openSpec/**`; only then use other repository evidence.
+
+- Cite paths/symbols or tight lines; label assumptions, questions, and missing evidence.
+- Never invent conventions, APIs, tokens, commands, or knowledge-base results.
+- Record `knowledge-base`, `openSpec fallback`, `repository fallback`, or `unavailable`, plus evidence/conflicts.
+
+### Observable Spec Retrieval
 
-- 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.
+Scout/planner nodes must `grep`/`find` relevant `openSpec/**` and skill references,
+then explicitly `read` every consulted spec (`SKILL.md`, `design-spec.md`,
+`code-standards.md`, etc.). Observe derives evidence from session tool events: only
+successful paired `read` calls count as “已读取规范文件”; summaries do not. If the
+knowledge base is unavailable, record `openSpec/**` search hits before repo fallback.
 
 ## 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.
+- Project specs and repo-local skills are authoritative within scope.
+- Reuse confirmed components, tokens, helpers, APIs, mocks, schemas, and tests.
+- Add dependencies only when task and approved plan allow them.
+- Cover success/error/loading/empty/disabled/permission/boundary states; justify N/A.
+- Keep state/validation testable. Writers stay in `writeSet`, preserve unrelated behavior, and update tests.
+- Never relax lint/type/test/build config 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.
+- Follow `node-contracts.md` headings exactly. Read-only nodes return Markdown and never edit files.
+- Missing input blocks work when proceeding would guess behavior, compliance, write bounds, or verification.
+- Preserve protocol tokens, commands, paths, identifiers, and output language.
+- Attempted checks may be reported; completion needs fresh downstream shell evidence.

package/skills/frontend-implementation/references/node-contracts.md

@@ -1,32 +1,63 @@
 # Frontend Node Contracts
 
+Pre-implementation nodes are read-only. Preserve IDs, protocol tokens, source
+labels, language, and named output headings.
+
 ## `frontend-contract-pi`
 
-- Read task source, constraints, `task.json`, and explicit references; do not edit.
-- Define scope, non-goals, routes/components, runtime, user flows, acceptance criteria, states, risks, and verification expectations.
-- Preserve requirement IDs and language; never turn an implementation guess into a requirement.
-- For every standard UI state, specify behavior or mark it not applicable with a reason.
-- Output: `Scope`, `Non-goals`, `Acceptance Criteria`, `UI States`, `Target Runtime Environment`, `Risks`, `Verification Expectations`.
+Read task sources, constraints, config, and references. Define scope, non-goals,
+routes/components, runtime, flows, criteria, states, risks, and verification. Never
+turn a guess into a requirement. Output: `Scope`,
+`Non-goals`, `Acceptance Criteria`, `UI States`, `Target Runtime Environment`,
+`Risks`, `Verification Expectations`.
 
 ## `frontend-scout-pi`
 
-- Inspect routes, pages, components, styles/tokens, state/data flow, API/mocks, scripts, tests, and reusable assets; do not edit.
-- Separate confirmed facts, inferred conventions, and missing information.
-- Attempt knowledge-base first. If absent, failed, or unmatched, recursively inspect `<repoRoot>/openSpec/**` before other repo conventions.
-- Record source as `knowledge-base`, `openSpec fallback`, `repository fallback`, or `unavailable`, with query/search terms and matched paths.
-- Output: `Frontend Stack`, `Routes`, `Components`, `Styling System`, `Existing Design Conventions`, `State / Data Flow`, `Test Entry Points`, `Reuse Opportunities`, `Risks`.
+Inspect routes, components, styles/tokens, state/data, APIs/mocks, scripts, tests,
+and assets. Separate facts, inferences, and gaps. Query knowledge-base;
+if absent/failed/unmatched, search and read `<repoRoot>/openSpec/**` before repo
+conventions. Record source, query/terms, and paths. Output: `Frontend Stack`,
+`Routes`, `Components`, `Styling System`, `Existing Design Conventions`,
+`State / Data Flow`, `Test Entry Points`, `Reuse Opportunities`, `Risks`.
 
 ## `frontend-plan-pi`
 
-- Map every acceptance criterion to ordered implementation and verification steps.
-- Name target files and reasons; keep them within allowed paths and expected `writeSet`.
-- Define states, component/styling reuse, interaction behavior, dependency policy, and exact static/behavior commands.
-- Knowledge-base failure is not approval: apply relevant `openSpec/` matches as current-project rules. Request clarification only when neither source resolves required compliance or they conflict materially.
-- Output: `Implementation Steps`, `Target Files`, `UI State Handling`, `Styling / Component Strategy`, `Interaction Notes`, `Dependency Policy`, `Verification Plan`, `Residual Risks`.
+Map each criterion to implementation and verification. Name in-bound files; define
+states, reuse, interactions, dependencies, and commands. Apply `openSpec/` rules
+when knowledge-base fails; ask only for material conflicts. Output: `Implementation Steps`, `Target
+Files`, `UI State Handling`, `Styling / Component Strategy`, `Interaction Notes`,
+`Dependency Policy`, `Verification Plan`, `Residual Risks`.
+
+## First design protocol gate
+
+`frontend-first-design-gate-shell` reads `frontend-design-gate-pi`'s first
+non-empty line. It accepts only `VERDICT: pass` or `VERDICT: request-revision` and
+blocks malformed output. It never authorizes writes; request-revision enters plan
+revision. Line mode: `first-verdict-line`.
+
+## `frontend-plan-revision-pi`
+
+Consume the original plan and first review findings. On first-gate pass, output
+`PASS_NO_REVISION_NEEDED`; on request-revision, address every Required Plan
+Correction in a complete plan with the plan headings above. Always `read-only`;
+never edit code, docs, or artifacts.
+
+## Final design review and gate
+
+`frontend-final-design-review-pi` rechecks the original plan for
+`PASS_NO_REVISION_NEEDED`, otherwise verifies every correction and rejects any
+remaining/new gap. Its first non-empty line is exactly `VERDICT: pass` or
+`VERDICT: request-revision`.
+
+`frontend-final-design-gate-shell` reads that verdict and accepts only
+`VERDICT: pass`. It is the sole write authorization. Failure routes to
+`ContractMismatch` / `frontend-plan-revision-and-rerun`, never `ProductBug` /
+`dev-fix`. Line mode: `first-verdict-line`.
 
 ## `frontend-implement-pi`
 
-- Run only after design gate pass and implement only the approved plan inside `writeSet`.
-- Re-read current files; stop instead of crossing forbidden paths or guessing a blocking decision.
-- Reuse confirmed project primitives and update tests. Do not claim knowledge-base or downstream verification without evidence.
-- Output: `Changed Files`, `Implemented Behavior`, `UI States Covered`, `Styling / Component Notes`, `Verification Attempted`, `Residual Risks`.
+Depends directly on final gate, revision plan, and final review. After pass, re-read
+current files and implement only the approved plan inside `writeSet`; stop on
+forbidden paths or blocking guesses. Reuse primitives and update tests. Output:
+`Changed Files`, `Implemented Behavior`, `UI States Covered`, `Styling / Component
+Notes`, `Verification Attempted`, `Residual Risks`.

package/skills/frontend-review/SKILL.md

@@ -25,7 +25,7 @@ required check, forbidden write, or unmet acceptance criterion forces revision.
 - Inspect every changed file against allowed, forbidden, and approved write scope.
 - Map criteria to behavior, applicable UI states, tests, and shell evidence.
 - Review state/data flow, validation, async/error behavior, components/design, responsive behavior, accessibility, dependencies, maintenance, and regression risk when applicable.
-- Component/design claims require traceable knowledge-base evidence or, after connection/query failure or no match, relevant `<repoRoot>/openSpec/**` evidence. The connector format is TODO; never claim a query or fallback search without evidence.
+- Component/design claims require traceable knowledge-base evidence or, after connection/query failure or no match, relevant `<repoRoot>/openSpec/**` evidence. The connector format is TODO; never claim a query or fallback search without evidence. Execute explicit `grep`/`find` to locate spec files and `read` to load them before referencing their rules. Only successful `read` tool calls are observable as "已读取规范文件" in the spec-evidence inspector.
 - Treat shell exit status as authoritative. Do not edit files.
 
 ## Evidence And Output

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

@@ -392,6 +392,7 @@ agent-worker report metrics --repo <repo-root> --month <YYYY-MM> [--json]
 agent-worker task draft-followup <task-id> --worker-run-id <id> --feature-dir <feature-dir> --repo <repo-root> [--json]
 agent-worker feature approve-followup --feature-dir <feature-dir> --followup-id <id> --repo <repo-root> --owner <owner> [--dry-run] [--json]
 agent-worker task retry <task-id> --repo <repo-root> [--reason "<已修复的原因>"]
+agent-worker batch plan-ready --feature-dir <feature-dir> --repo <repo-root> [--limit <count>] [--json]
 agent-worker batch run-ready \
   --feature-dir <feature-dir> \                   # 含 tasks/task-graph.yaml
   --repo <repo-root> \                            # 目标 repo