@tea-agent/loop-agent 0.21.0 → 0.23.1

package/skills/agent-worker/SKILL.md

@@ -16,7 +16,7 @@ references:
 - **允许**：`agent-worker` / `loop-agent` CLI；只读 `pool doctor`、`observe`、status/report；冻结 controller identity；选择 Ready 工作与 recovery 命令。
 - **禁止**：绕过 CLI 直接 Edit 业务实现；Worker/DAG 失败后主会话「救火改文件」。
 - **失败时只允许**：保留 evidence → `task retry` / `task reconcile` / `pool mark-failed` / human gate → 再经 CLI 重跑；实现写入仍只经 published `loop-agent` DAG。
-- **Official vs Compatibility**：`agent-worker console serve` 是 Official 本地控制面；openCode 等主会话仍是 Compatibility Assist，二者**不是**同等保证。Console 与 Observe 分进程；深链依赖 Observe health match，Console 不 proxy Observe。
+- **Official vs Compatibility**：`agent-worker console serve` 是 Official 本地控制面（同进程提供 Operate + Inspect，Inspect 路径 `/inspect/#/...`）；openCode 等主会话仍是 Compatibility Assist，二者**不是**同等保证。原 `observe serve` 为兼容期只读入口（启动时输出 `OBSERVE_SERVE_DEPRECATED`，stdout 仍只输出 URL），功能等价于 Console 的 Inspect 面。
 
 ## Route the Work
 

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

@@ -11,10 +11,10 @@ references:
 
 For frontend design review nodes. Read the checklist; audit contract, scout, Mock
 strategy, effective plan, task bounds, and traceable design evidence.
-Knowledge base and `openspec/` are parallel specification sources. Query the
-knowledge-base connector when available; regardless of result, also search and
-read `<repoRoot>/openspec/**` before accepting repository conventions. The
-connector format is TODO: never invent results.
+Knowledge base, OpenSpec, and `ai_workspace/` are parallel sources. Query the
+knowledge-base connector when available; always search/read `openspec/schemas/**`,
+`openspec/project-specs/**`, and `ai_workspace/**` before accepting conventions.
+Connector format is TODO: never invent results.
 
 ## Verdict Contract
 
@@ -39,16 +39,17 @@ output fails closed.
 
 - 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.
+  lack knowledge-base or required openspec specification 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 read and
-applied. Block skipped fallback, unresolved conflict, or unresolved UI decisions.
+Knowledge-base absence is advisory if relevant rules from either openspec
+specification directory were read and applied. Block skipped fallback, unresolved
+conflict, or unresolved UI decisions.
 
 ## Method And Output
 
@@ -59,7 +60,8 @@ or Advisory, and never edit files.
 
 Run `grep`/`find`, then explicit `read` calls for applicable specs/checklist. Only
 successful paired reads count as “已读取规范文件”; summaries do not. List each path/
-section in `Checked Items`; search/read `openspec/` before accepting conventions.
+section in `Checked Items`; search/read both openspec specification directories
+before accepting conventions.
 
 ```markdown
 VERDICT: pass

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

@@ -9,8 +9,8 @@
 ## Project Fit
 
 - Reuse components, hooks, API helpers, mocks, schemas, router patterns, tokens, and theme rules.
-- Cite knowledge base and `openspec/` as parallel sources; failed or empty
-  knowledge queries must still search `<repoRoot>/openspec/**`.
+- Cite knowledge base, `openspec/schemas/`, `openspec/project-specs/`, and `ai_workspace/` as parallel sources; failed or empty
+  knowledge queries must still search `<repoRoot>/openspec/schemas/`, `<repoRoot>/openspec/project-specs/`, and `<repoRoot>/ai_workspace/`.
 - Record source status, query terms, paths/headings, conflicts, authorized deps, and allowed paths for both.
 
 ## Interaction / Quality
@@ -36,6 +36,6 @@
 
 ## Verdict Matrix
 
-- Request revision for coverage gaps, unsafe scope, unauthorized deps, unresolved required interaction, missing required verification, skipped `openspec/` fallback, unsafe/missing Mock strategy, or Mock evidence presented as real integration.
-- Knowledge-base unavailable but relevant `openspec/` rules applied is advisory only.
+- Request revision for coverage gaps, unsafe scope, unauthorized deps, unresolved required interaction, missing required verification, skipped local specification fallback (`openspec/schemas/`, `openspec/project-specs/`, or `ai_workspace/`), unsafe/missing Mock strategy, or Mock evidence presented as real integration.
+- Knowledge-base unavailable but relevant OpenSpec or `ai_workspace/` rules applied is advisory only.
 - Optional cleanup that cannot affect acceptance is advisory.

package/skills/frontend-implementation/SKILL.md

@@ -23,8 +23,8 @@ 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,
+query the knowledge base when available and always inspect `openspec/schemas/`,
+`openspec/project-specs/`, and `ai_workspace/`; then use repo evidence. Cite tight paths/symbols, 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.

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

@@ -1,9 +1,10 @@
 # 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.
+tests, manifests, and generated types. Regardless of knowledge-base results,
+applicable `openspec/schemas/`, `openspec/project-specs/`, and `ai_workspace/` rules are normative.
+Preferences are not rules, and docs do not override installed APIs without an
+explicit compatibility decision.
 
 ## Discover And Cite
 

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

@@ -2,22 +2,22 @@
 
 ## Required Source Sequence
 
-Knowledge base and `openspec/` are parallel specification sources:
+Knowledge base, OpenSpec, and `ai_workspace/` are parallel specification sources:
 
 1. Attempt the configured component/design knowledge-base query first when a
    connector is available in the execution environment.
 2. Regardless of knowledge-base success, failure, timeout, no match, or no
-   configuration, also recursively search the project root's exact `openspec/`
-   directory for index files and task-relevant specification content.
+   configuration, also recursively search `openspec/schemas/`,
+   `openspec/project-specs/`, and `ai_workspace/` for index files and relevant content.
 3. Treat relevant matches from both sources 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, even when a
-knowledge-base query returned results. Report source conflicts instead of
-combining them. Explicit task requirements remain the contract; flag conflicts
-with knowledge-base or `openspec/` rules.
+Never skip local OpenSpec or `ai_workspace/` sources for neighboring-code
+conventions, even when a knowledge-base query returned results. Report source
+conflicts instead of combining them. Explicit task requirements remain the
+contract; flag conflicts with knowledge-base or openspec specification rules.
 
 ## Knowledge Base Connection — TODO
 
@@ -25,15 +25,19 @@ Request format is undecided. TODO: define connector/owner, namespaces, secret-fr
 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.
+record `not-configured` and run the openspec fallback; never invent a connection.
 
-## `openspec/` Fallback Procedure
+## 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.
+- Inspect `<repoRoot>/openspec/schemas/`, `<repoRoot>/openspec/project-specs/`,
+  and `<repoRoot>/ai_workspace/` when present; enumerate supported 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.
+- Record search terms, inspected/matched paths, headings or tight line ranges,
+  applied rules, and conflicts.
+- If both directories or relevant rules are absent, record that fact before using
+  repository fallback.
 
 ## Retrieval Evidence
 
@@ -50,5 +54,6 @@ and conflicts. `openspec fallback` includes terms, paths/headings/lines, rules,
 
 - 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.
+- Cite knowledge-base or openspec specification evidence for component/token
+  choices; label weaker repository fallback.
 - Make deviations and unresolved gaps explicit.

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

@@ -5,7 +5,7 @@ Pre-write nodes are read-only. Preserve IDs, labels, commands, language, require
 ## Core nodes
 
 - **`frontend-contract-pi`**: `Scope`, `Non-goals`, `Acceptance Criteria`, `UI States`, `Target Runtime Environment`, `Risks`, `Verification Expectations`. No guessed requirements.
-- **`frontend-scout-pi`**: routes, components, tokens, data/API/Mock, scripts, tests, assets. Fact vs inference vs gap. Knowledge base first; else search+read `<repoRoot>/openspec/**` before repo fallback. Output stack, routes, components, styling, conventions, state/data, test entry points, reuse, risks.
+- **`frontend-scout-pi`**: routes, components, tokens, data/API/Mock, scripts, tests, assets. Fact vs inference vs gap. Query the knowledge base when available and always search+read `openspec/schemas/`, `openspec/project-specs/`, and `ai_workspace/` before repo fallback. Output stack, routes, components, styling, conventions, state/data, test entry points, reuse, risks.
 - **`frontend-plan-pi` + conditional design loop**: AC → steps, in-bound files, UI states, reuse, deps, Mock/API strategy, activation/rollback, frozen verify entrypoints, real-integration gap, and exactly one `frontend-implementation-contract-v1` JSON object. Prefer native Mock; browser intercept only with existing e2e; request-adapter only for a reversible seam. `auto` may select `not-needed` when no project Mock capability exists, while keeping real requests default and recording the gap; `required` cannot. Initial design pass uses the original plan; only exact `request-revision` runs read-only revision plus final review. Small-risk runs one design review only.
 - **`frontend-prewrite-gate-shell`**: the sole write authorization. Resolve effective plan/review, require exact pass, retain every REQ/BR/AC id, enforce Mock policy, validate schema/source binding, and materialize `contracts/frontend-implementation-contract.json`. Fallback is allowed only when a conditional primary is absent; an existing malformed primary fails closed. Generation-time blocked Mock produces one deterministic blocking shell node and no writer.
 - **`frontend-implement-pi`**: sole exclusive writer. Stay in `writeSet`; real requests default-on; Mock reversible, dev/test-only, production-off. Atomic handler/intercept/adapter with consumer+tests. Stop on forbidden paths or guesses. Output changed files, behavior, UI states, styling notes, verification attempted, residual risks. Optional mock-verify when frozen; static+behavior always; behavior must prove page consumption. Skipped-Mock `not-needed` keeps real integration pending unless the real backend path has fresh evidence.
@@ -22,4 +22,4 @@ Only `eligible=true` runs `frontend-repair-pi` (same writeSet as implement; no r
 
 ## Risk & capability (M4–M6)
 
-Deterministic risk (no model); high-risk beats small; supervised never small. Standard/high-risk contain 15 top-level nodes; small contains 13 by omitting revision and final review. Capability seed injects adapters; openspec/task sources outrank. A11y: static/component tools only when present; Browser a11y always not-run.
+Deterministic risk (no model); high-risk beats small; supervised never small. Standard/high-risk contain 15 top-level nodes; small contains 13 by omitting revision and final review. Capability seed injects adapters; openspec specs and task sources outrank adapter guidance. A11y: static/component tools only when present; Browser a11y always not-run.

package/skills/frontend-review/SKILL.md

@@ -12,9 +12,8 @@ references:
 Use for `frontend-review-pi`; read the findings guide first. Required inputs are
 original task/reference material, effective plan/design branch, implementation summary,
 and `contracts/frontend-review-context.json`. That canonical context binds the validated
-implementation contract, effective initial-or-post-repair verification trace, repair
-assessment, and run-owned actual diff. Treat its diff as authoritative; never invent a
-diff from an implementation summary alone.
+implementation contract, effective verification trace, repair assessment, optional
+`frontend-lint-assessment-v1`, and run-owned diff. The diff is authoritative.
 
 ## Verdict Contract
 
@@ -27,42 +26,30 @@ required check, forbidden write, or unmet acceptance criterion forces revision.
 - Compare intent, contract, plan, diff, and evidence; report altered requirements.
 - 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.
+- Review state/data flow, validation, async/error behavior, design, responsive/a11y,
+  dependencies, maintenance, and regression risk when applicable.
 - Inspect static, behavior, and available Mock-specific artifacts directly. For Mock
   strategies, compare the endpoint matrix, handler/fixture/adapter and consumer diff;
   require the real request as default, contract-aligned fixtures, production isolation,
   and no false real-integration claim. `not-needed` needs applicable real/no-remote
   evidence, or an explicit default-auto skipped-Mock rationale with the Real
   Integration Gap preserved when no project Mock capability is confirmed.
-- Component/design claims require traceable evidence from two parallel sources:
-  knowledge base and `<repoRoot>/openspec/**`. Query the knowledge-base connector
-  when available; regardless of result, also read `<repoRoot>/openspec/**`.
-  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.
+- Inspect lint assessment directly. `baseline-debt` requires intact evidence, only
+  baseline-matched diagnostics on unchanged files, and none on writer-changed files.
+  Report debt, never `lint passed`; `failed`/`unavailable` blocks. Typecheck, build,
+  and test still require successful final exits.
+- Component/design claims need both knowledge-base and local openspec evidence. Query
+  the connector when available and always read task-relevant files under
+  `<repoRoot>/openspec/schemas/`, `<repoRoot>/openspec/project-specs/`, and `<repoRoot>/ai_workspace/`.
+  Connector format is TODO; never invent evidence. Only successful `read` calls are
+  observable as "已读取规范文件".
 - Treat shell exit status as authoritative. Do not edit files.
 
 ## Evidence And Output
 
 Findings cite a tight file location, exact command/result, or named DAG artifact.
-Separate confirmed defects, missing evidence, and residual risks.
-
-```markdown
-VERDICT: request-revision
-
-## Findings
-- [Important] `path:line` — issue, impact, and required correction.
-
-## Verification Assessment
-- ...
-
-## UX Assessment
-- ...
-
-## Residual Risks
-- ...
-```
+Separate confirmed defects, missing evidence, and residual risks using Findings,
+Verification Assessment, UX Assessment, and Residual Risks headings.
 
 A pass requires no Critical/Important findings and all required shell checks passed.
 Still report knowledge-source status and optional browser/manual gaps.

package/skills/frontend-review/references/review-findings.md

@@ -2,7 +2,7 @@
 
 ## Severity
 
-- **Critical**: blocks primary flow, corrupts data, violates security/privacy, writes forbidden paths, or bypasses required verification.
+- **Critical**: blocks primary flow, corrupts data, violates security/privacy, writes forbidden paths, bypasses required verification.
 - **Important**: acceptance/state/validation gap, material convention drift, missing behavior tests, unauthorized dependency, unsafe mock activation/import, mock-contract drift, misleading real-integration claim, or failed/missing required verification.
 - **Minor**: non-blocking maintainability, copy, layout, or cleanup issue.
 
@@ -10,43 +10,41 @@
 
 - Cite tight file locations, exact commands/results, or named DAG artifacts.
 - Never invent evidence; name the missing check. An implementation summary is not the actual diff.
-- Failed required static/behavior verification is at least Important unless proven unrelated.
-- Treat the knowledge base and `openspec/` as parallel sources. Record
-  connector/query, source ID/version, and retrieval time for knowledge-base
-  claims. Regardless of that result, evidence must show
-  `<repoRoot>/openspec/**` search terms and matched paths/headings; label
-  `openspec`, `repository fallback`, or `unavailable` accurately.
+- Failed required static/behavior verification is at least Important. Lint may be
+  `baseline-debt` only with a valid `frontend-lint-assessment-v1`; this is not a
+  passed lint result. A changed-file lint diagnostic, new unmatched diagnostic,
+  command drift, missing baseline, timeout, or unparseable output is Important.
+- Treat knowledge base, `openspec/schemas/`, `openspec/project-specs/`, and `ai_workspace/` as
+  parallel sources. Record connector/query/source/time plus openspec search terms and
+  matched paths/headings; label fallback or unavailable accurately.
 
 ## Review Sequence
 
 1. Establish changed-file inventory and write boundaries.
 2. Compare original requirement with derived contract/constraints.
 3. Map each criterion to code, states, tests, and evidence.
-4. Inspect interactions, state/data/API behavior, failure paths, and regression risk.
+4. Inspect interactions, state/data/API behavior, failure paths, and regressions.
 5. Check mock selection, contract-to-fixture mapping, activation/default path,
-   handler/fixture/adapter and consumer diff, optional Mock-specific verification,
-   production imports, evidence scope, and the documented real-integration gap.
-6. Check component/design evidence, responsive/accessibility behavior, dependencies, and maintenance fit when applicable.
+   handler/fixture/adapter and consumer diff, verification, production imports, and
+   the real-integration gap.
+6. Check design evidence, responsive/a11y behavior, dependencies, and maintenance.
 7. Classify findings and derive the verdict mechanically.
 
-Skipping the required `openspec/` search after knowledge-base failure is Important
-when component/design compliance affects acceptance or implementation choices.
-
-Use one issue per finding:
+Skipping either directory is Important when design compliance affects acceptance.
 
 ```text
 - [Critical|Important|Minor] path:line — Problem; impact; required correction; evidence.
 ```
 
-Avoid vague advice. When no source location exists, cite the command or artifact.
-
 ## Pass Rules
 
 - No Critical or Important findings remain.
 - Required static and behavior nodes ran and passed.
+- Lint is `passed` or evidence-backed `baseline-debt`; typecheck, build, and test are
+  passed. Any debt count and affected unchanged files remain disclosed.
 - Changed files are authorized.
 - Criteria and applicable states have implementation and evidence.
 - Required Mock-backed behavior passed; any generated Mock-specific verification also
   passed; Mock is not enabled by default in production. For default-auto skipped
   Mock, the real request remains default and the Real Integration Gap is preserved.
-- Optional unavailable knowledge-base, browser, visual, or manual checks remain explicit risks.
+- Optional unavailable knowledge/browser/visual/manual checks remain explicit risks.

package/skills/frontend-verification/SKILL.md

@@ -17,18 +17,22 @@ verdict/findings, and required browser, visual, manual, or knowledge evidence.
 
 ## Evidence Rules
 
-- Static evidence covers type/lint/build/schema; behavior evidence must exercise the flow.
+- Static evidence covers type/build/schema; behavior evidence must exercise the flow.
+  Lint has its own assessment status: `passed`, `baseline-debt`, `failed`, or
+  `unavailable`.
 - Shell exit status is authoritative. Classify as `passed`, `failed`, `not-run`,
   `blocked`, or `unavailable`; only passed satisfies a required check.
 - Never use static success as behavior proof, or tests as visual/browser proof they did not exercise.
 - Mock-backed behavior proves frontend rendering and state transitions only. It never
   proves backend readiness, transport compatibility, or real API integration.
 - Unavailable commands remain gaps.
-- Resolve design evidence from two parallel sources: query the execution environment's
-  knowledge base connector when available; regardless of result, also read
-  `<repoRoot>/openspec/**` for index and task-relevant specification content.
-  The connector format remains TODO; never invent it. Applied `openspec` rules
-  from successful reads are available project evidence.
+- `baseline-debt` is not lint passed. It requires
+  `frontend-lint-assessment-v1` proving only pre-writer diagnostics on unchanged
+  files. Report debt count, changed files, and raw evidence. Typecheck/build/test do
+  not support debt.
+- Resolve design evidence from parallel sources: query the available knowledge
+  connector and always read task-relevant `<repoRoot>/openspec/schemas/`,
+  `<repoRoot>/openspec/project-specs/`, and `<repoRoot>/ai_workspace/`. Connector format is TODO; never invent it.
 - Separate Mock service/handler checks from page consumption and record the
   dev/test-only boundary; handler tests alone do not prove page use.
 
@@ -40,18 +44,17 @@ only proven changes.
 Return Markdown headings:
 
 - `Changes`: changed behavior and areas.
-- `Mock Decision`, `Mock Files`, `Mock Verification`, `Production Boundary`: status is `passed`, `failed`, `not-required`, `blocked`, or `unavailable`.
+- `Mock Decision`, `Mock Files`, `Mock Verification`, `Production Boundary`.
 - `Verification Evidence`: table of check, command/source, status, and artifact/result.
+  Keep lint `baseline-debt` verbatim rather than converting it to `passed`.
 - `Review Result`: exact review verdict and findings.
 - `Known Risks`: missing optional checks and environment caveats.
 - `Follow-up`: concrete work or `None`.
 
-When the backend remains unavailable but required mock-backed checks pass, state
-`Frontend status: mock-validated` and `Real integration: pending`. When default
-`auto` skipped Mock and no real API evidence passed, state
-`Frontend status: locally-validated` and `Real integration: pending`. Use a completed
-`<task-id>-real-api-integration-verify` task before changing the latter to complete;
-the follow-up is explicit, not auto-created or auto-executed.
+With only Mock evidence, state `Frontend status: mock-validated`; when default `auto`
+skipped Mock without real API evidence, state `Frontend status: locally-validated`.
+Both require `Real integration: pending` and explicit
+`<task-id>-real-api-integration-verify` follow-up; it is not auto-created/executed.
 
 Do not edit files. Do not claim complete when review is not pass or a required check
 is failed, not-run, blocked, unavailable, stale, or contradicted.

package/skills/frontend-verification/references/verification-checklist.md

@@ -3,19 +3,26 @@
 ## Static And Behavior Evidence
 
 - Required type/compile, lint/format, build, schema/client, browser/e2e/manual checks ran.
+- Lint is recorded as `passed | baseline-debt | failed | unavailable`.
+  `baseline-debt` cites `frontend-lint-baseline-v1` and
+  `frontend-lint-assessment-v1`, writer changed files, tolerated diagnostic count,
+  command identity, and raw output hashes; it is never labeled passed.
+- Every remaining lint diagnostic is on an unchanged file and matches the
+  writer-preceding baseline. Changed-file diagnostics, new unmatched diagnostics,
+  command drift, timeout, worktree mutation, or unparseable output fail closed.
+- Typecheck, build, and test are fully passed; none accepts baseline debt.
 - Generated output was authorized; tests cover changed logic, flows, and regressions.
-- Fixed DAG entrypoints prove selected-strategy behavior and applicable loading/empty/error/success/disabled/permission/retry/boundary states.
+- Fixed entrypoints prove selected-strategy behavior and applicable UI states.
 - Mock-specific checks cover service/handler/schema/fixtures; behavior evidence separately proves page consumption.
 - Mock activation is explicit/non-production; a default-real-path build with Mock off proves the real request remains default.
-- `not-needed` has real/no-remote evidence, or default-auto skipped-Mock rationale with Real Integration Gap preserved when no project Mock capability exists.
+- `not-needed` has real/no-remote evidence or a default-auto skipped-Mock rationale.
 - Mock-backed evidence is frontend-only and never satisfies real API integration.
 
 ## Design And Component Evidence
 
-- Claims cite two parallel sources: knowledge-base retrieval and
-  `<repoRoot>/openspec/**`.
-- Evidence records query/source/time for knowledge base plus openspec search terms, paths, headings, and applied rules for both.
-- Relevant `openspec/` matches satisfy source availability; missing both sources blocks explicit compliance or required design decisions.
+- Claims cite knowledge-base, OpenSpec, and `<repoRoot>/ai_workspace/` sources.
+- Evidence records query/source/time, local-spec terms, paths, headings, and rules.
+- OpenSpec or `ai_workspace/` matches satisfy source availability; none blocks required design decisions.
 
 ## Status
 
@@ -25,7 +32,8 @@
 - `blocked`: a prerequisite prevented execution.
 - `unavailable`: tool, environment, connector, or source was absent.
 
-Only passed satisfies a required check. Other optional statuses remain disclosed risks.
+Only passed satisfies a required check. For lint alone, evidence-backed
+`baseline-debt` may continue as explicit debt; it replaces no other check.
 
 ## Closeout Checks
 
@@ -35,26 +43,6 @@ Only passed satisfies a required check. Other optional statuses remain disclosed
 - If only Mock evidence exists, report `Frontend status: mock-validated` and `Real integration: pending`, with actual API verification follow-up.
 - If default `auto` skipped Mock and no real API evidence exists, report `Frontend status: locally-validated` and `Real integration: pending`.
 
-```markdown
-## Changes
-- ...
-
-## Verification Evidence
-| Check | Command or source | Status | Evidence |
-|---|---|---|---|
-| ... | ... | passed | ... |
-
-## Mock Decision / Mock Files / Mock Verification / Production Boundary
-- Status: `passed | failed | not-required | blocked | unavailable`
-
-## Review Result
-- Verdict: `VERDICT: pass`
-
-## Known Risks
-- ...
-
-## Follow-up
-- None.
-```
-
-If review is not pass or a required check is not passed, describe the task as incomplete and list concrete follow-up.
+Output uses Changes, Verification Evidence, Mock Decision/Files/Verification,
+Production Boundary, Review Result, Known Risks, and Follow-up headings. If review is
+not pass or a required check fails, describe the task as incomplete with follow-up.

package/skills/grill-with-docs/SKILL.md

@@ -1,88 +1,80 @@
 ---
 name: grill-with-docs
-description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
+description: >-
+  Grilling session that challenges a plan against the existing domain model,
+  sharpens terminology, and proposes CONTEXT.md / ADR updates as decisions
+  crystallise. Use when the user wants to stress-test a plan against project
+  language and documented decisions. Explicit interactive operator skill only —
+  not a default DAG role.
+references:
+  - path: context-format.md
+    required: true
+  - path: adr-format.md
+    required: true
 ---
 
-<what-to-do>
+# Grill With Docs
 
-Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+显式交互式 operator skill。用于压力测试计划与术语；**不**加入默认 planner / reviewer / implementer role mapping，避免普通 DAG 被问答阻塞。
 
-Ask the questions one at a time, waiting for feedback on each question before continuing.
+## What to do
 
-If a question can be answered by exploring the codebase, explore the codebase instead.
-
-</what-to-do>
-
-<supporting-info>
-
-## Domain awareness
+Interview the user relentlessly about every aspect of the plan until shared understanding. Walk each design branch, resolve decision dependencies one-by-one. For each question, provide a recommended answer.
 
-During codebase exploration, also look for existing documentation:
+Ask questions one at a time; wait for feedback before continuing.
 
-### File structure
-
-Most repos have a single context:
+If a question can be answered by exploring the codebase, explore the codebase instead.
 
-```
-/
-├── CONTEXT.md
-├── ai_workspace/loop-agent/
-│   └── adr/
-│       ├── 0001-event-sourced-orders.md
-│       └── 0002-postgres-for-write-model.md
-└── src/
-```
+## Path resolution
 
-If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+1. Read `harness.json.governanceRoot`（缺省时常见为源码仓库 `docs`，目标项目 `ai_workspace/loop-agent`）。
+2. Decisions 目录 = `${governanceRoot}/decisions/`（本仓库即 `docs/decisions/`）。
+3. Glossary = 仓库根 `CONTEXT.md`（多 context 时见 `CONTEXT-MAP.md`）。
+4. **禁止**硬编码平行 `adr/` 目录树；只用 `${governanceRoot}/decisions/`。
 
-```
-/
-├── CONTEXT-MAP.md
-├── ai_workspace/loop-agent/
-│   └── adr/                          ← system-wide decisions
-├── src/
-│   ├── ordering/
-│   │   ├── CONTEXT.md
-│   │   └── ai_workspace/loop-agent/adr/                 ← context-specific decisions
-│   └── billing/
-│       ├── CONTEXT.md
-│       └── ai_workspace/loop-agent/adr/
-```
+## Write boundary
 
-Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `ai_workspace/loop-agent/adr/` exists, create it when the first ADR is needed.
+- Inline 更新 `CONTEXT.md` / ADR **必须**服从当前 task `allowedPaths` 与 DAG `writeSet`。
+- 无写权限时：只返回建议与待确认 patch，**不得**越界写文档。
+- 不得绕过 human gate、write guard 或 shell completion authority。
 
 ## During the session
 
 ### Challenge against the glossary
 
-When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
+术语与 `CONTEXT.md` 冲突时立即指出。
 
 ### Sharpen fuzzy language
 
-When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
+模糊或过载词要提出规范术语。
 
 ### Discuss concrete scenarios
 
-When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
+用具体场景压力测试边界。
 
 ### Cross-reference with code
 
-When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
+声称与代码不符时立即表面矛盾。
 
-### Update CONTEXT.md inline
+### Update CONTEXT.md only when allowed
 
-When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [context-format.md](./context-format.md).
+术语敲定后，若有写权限则按 `context-format.md` 立刻更新；否则只给出建议 patch。
 
-`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
+`CONTEXT.md` 是 glossary 且仅是 glossary：不含实现细节、规格草稿、计划状态或架构决策。
 
 ### Offer ADRs sparingly
 
-Only offer to create an ADR when all three are true:
+仅当三条同时成立才提议 ADR：
+
+1. **Hard to reverse** — 改变成本可观
+2. **Surprising without context** — 未来读者会追问 why
+3. **Real trade-off** — 曾有合理备选并基于具体理由选择
+
+缺一则跳过。格式遵循目标仓库已有模板（见 `adr-format.md`），本仓库使用完整 `docs/templates/adr.md` 字段，不用单段极简 ADR 覆盖本地约定。
 
-1. **Hard to reverse** — the cost of changing your mind later is meaningful
-2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
-3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+## Supporting formats
 
-If any of the three is missing, skip the ADR. Use the format in [adr-format.md](./adr-format.md).
+Required references（已进入 skill snapshot）：
 
-</supporting-info>
+- `context-format.md`
+- `adr-format.md`