@tea-agent/loop-agent 0.43.0-next.1 → 0.43.0-next.11

package/skills/frontend-contract/references/contract-protocol.md

@@ -8,14 +8,16 @@
   source-fidelity ledger. Do not infer fragment IDs from prose.
 - Record observable outcomes, applicable UI states, runtime/environment constraints,
   non-goals, risks, and verification expectations without choosing implementation.
-- Classify each requirement as `explicit`, `repository-resolvable`, `assumption`, or
-  `blocking`. Blocking facts name their owner and evidence.
+- Runtime owns requirement text, source binding and disposition. Use typed questions
+  and constraints for uncertainties; blocked terminal facts name their owner.
 
 ## Evidence and handoff
 
 - Register static, behavior, Mock, and real-integration evidence expectations as
   required, optional, or not-applicable. The classification follows the source and
-  risk; it is not selected for model convenience.
+  risk; it is not selected for model convenience. These are source expectations
+  for the non-blocking frontend-test handoff, not implementation test gates.
+  This implementation workflow executes only npm run build.
 - Register a non-blocking frontend-test handoff for UI-visible or interactive work.
 - Preserve exact command labels and referenced paths. Do not invent evidence,
   connector results, APIs, or verification commands.
@@ -29,6 +31,22 @@ enumerate or downgrade them.
 
 ## Terminal
 
-Commit facts in small batches and call `finalize_contract` exactly once with
+Commit facts from the complete current scope, then `complete_contract_scope` only
+after its evidence, constraints and source-bound deliverables are recorded. Scope
+checkpoints survive interruption; confirming an ID alone is not completion.
+Call `finalize_contract` with
 `ready`, `ready-with-assumptions`, or `blocked`. If the task is too large for one
 bounded writer, record a split proposal instead of broadening the contract.
+
+A successful receipt means the fact was saved durably. Replays are idempotent;
+changed facts require explicit `replace:true`. Correct rejected calls and retry,
+but do not mutate after a successful terminal. Never drop tail conditions to fit.
+
+## Execution ownership
+
+`record_requirement` may include `execution:{groupId,kind,summary}`. Use `behavior`,
+`constraint`, or `exclusion`; reuse an existing group only when semantics agree.
+Keep permission, threshold and failure-path differences separate. Do not merge
+source IDs or independent acceptance conditions. Unclassified requirements remain
+independent. Later scopes receive the shared group index. A group is a planning
+proposal; independent design review must check every member's complete text.

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

@@ -9,36 +9,36 @@ references:
 
 # Frontend Design Review
 
-For frontend design review nodes. Read the checklist and the non-blocking contract
-capacity diagnostic first. Audit either the canonical contract or, when the
-diagnostic recommends indexed reading, its hash-bound field sections. Check the
-bound Mock strategy, task bounds, and traceable design evidence supplied by the
-upstream context. Do not rediscover task sources, search specification roots, or
-replace frozen evidence with nearby-code conventions. Use only exact, bound evidence
-paths when additional reading is necessary; never invent connector results.
+Audit the canonical contract or its hash-bound indexed sections, guided by the
+capacity diagnostic. Check Mock strategy, task bounds and exact bound evidence.
+Do not rediscover sources, search specification roots or invent connector results.
 
 ## Authoritative Terminal
 
-Complete the review with exactly one committed typed tool call:
+Submit findings one at a time with `record_design_finding` using stable IDs.
+Use `replace:true` for revisions. The terminal automatically includes saved findings;
+do not repeat their array. Correct rejected calls, then commit one successful terminal:
 
 - `approve_design` when no blocking design defect remains;
 - `request_design_changes` when a blocker exists. It must include a typed
-  `issueCategory`, at least one `evidenceRef`, and non-empty findings.
+  `issueCategory`, at least one `evidenceRef`, and non-empty findings (saved or supplied).
 
 The typed terminal is the only authoritative outcome. Do not require or emit a
 `VERDICT:` line, JSON verdict, revision patch, or a second final-design-review
-verdict. A requested design change ends this run; the recovery controller creates
-any bounded follow-up run from the appropriate phase.
+verdict. Requested changes end this run; recovery owns the bounded follow-up.
+
+Check every execution group against its members' complete outcomes. Permissions,
+thresholds and error paths remain independent ACs with corresponding planned implementation.
+The shared static build target checks buildability only.
 
 ## Blocking Conditions
 
-- Any criterion lacks implementation/verification; UI states lack reasons; a
+- Any criterion lacks planned implementation; UI states lack reasons; a
   dependency lacks permission; confirmed primitives/rules are ignored; design claims
   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.
+  write bounds; the frozen npm run build command is missing.
 - `MOCK_STRATEGY: blocked`; missing permitted target paths, endpoint/schema-to-fixture
-  mapping, fixed verification, or dev/test-only activation; a second Mock framework;
+  mapping 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.
 
@@ -48,7 +48,7 @@ conflict, or unresolved UI decisions.
 
 ## Method And Human-readable Output
 
-Map criteria to steps/files/states/checks, audit paths/evidence, classify Blocking
+Map criteria to planned steps/files/states, audit paths/evidence, classify Blocking
 or Advisory, and never edit files.
 
 ### Spec Evidence Rules
@@ -58,3 +58,9 @@ evidence paths bound in its upstream context. Successful paired reads are the on
 summaries do not substitute for them. A concise human-readable summary may list
 checked items and findings, but it is never a control protocol. Each requested
 change names its criterion/section, gap, and required plan change.
+
+## Implementation workflow boundary
+
+Plan lists what to implement and where. Only npm run build is executed. Missing
+unit tests, test frameworks, test plans, or behavior evidence never block this
+workflow. Existing tests are preserved; tests can be added later in frontend-test.

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

@@ -3,7 +3,7 @@
 ## Coverage
 
 - Route/component, non-goals, assumptions, and unresolved ambiguity are explicit.
-- Each acceptance criterion maps to steps, files, UI behavior, states, and verification.
+- Each acceptance criterion maps to planned steps, files, UI behavior, and states.
 - Success/error/loading/empty/disabled/permission/retry/stale/boundary states are handled or N/A.
 
 ## Project Fit
@@ -20,9 +20,9 @@
 
 ## Verification
 
-- Static/behavior commands are exact, frozen, discoverable, and deterministic.
-- Tests prove changed state and flows at supported levels; browser/visual only when task/gate requires.
-- Missing required verification is a blocker; optional gaps are disclosed risks.
+- The only frozen command is npm run build.
+- Do not require test plans, test files, a test framework, or behavior evidence.
+- Behavior correctness and all tests are deferred to frontend-test and non-blocking.
 
 ## Mock Safety
 
@@ -31,13 +31,13 @@
 - Prefer native mock; browser intercept only for existing e2e; request adapter only for reversible local preview.
 - Real request stays default; activation is explicit, reversible, local/test-only, and production-off.
 - Plans use only DAG-frozen shell entrypoints.
-- Mock strategies need default-real-path build with Mock off plus Mock-backed behavior evidence.
-- `not-needed` needs real/no-remote evidence, or default-auto skipped-Mock rationale with Real Integration Gap preserved when no project Mock capability exists.
+- Mock strategies keep production defaults off; Mock behavior tests are deferred.
+- `not-needed` records its rationale and preserves any Real Integration Gap.
 - Mock-backed checks prove frontend states only; real integration remains pending until actual backend evidence exists.
 
 ## Verdict Matrix
 
-- 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.
+- Request revision for coverage gaps, unsafe scope, unauthorized deps, unresolved required interaction, missing build entrypoint, skipped local specification fallback (`openspec/schemas/`, `openspec/project-specs/`, or `ai_workspace/`), unsafe/missing Mock strategy, or Mock evidence presented as real integration.
 - Request revision for component selection non-conformance: spec-defined components silently replaced or self-invented without a declared deviation, `uiComponentChoices` missing for UI-visible work, or a `uiComponentChoices` `specReference.path` not cited in the `openspec-citations` block / not actually read.
 - 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-plan/SKILL.md

@@ -4,7 +4,7 @@ description: Use only for the tool-only frontend decision planning node.
 references:
   - path: references/decision-contract.md
     required: true
-    maxChars: 5600
+    maxChars: 6800
   - path: references/design-decisions.md
     required: true
     maxChars: 3400
@@ -29,11 +29,30 @@ cite `evidencePath` of an existing file; greenfield is `decision=new`.
 Bind every file in the Contract-owned `requiredDeliverables` inventory. It records
 explicit source obligations, not every path mentioned by a requirement.
 
+Large UX work runs in bounded scopes against that shared registry. Complete every
+assigned requirement; preserve earlier scopes' shared bindings when correcting an
+entry. Ledger previews are incomplete. Use `read_plan_facts` to retrieve full
+fields, following `nextOffset` with `expectedRevision` pinned. For oversized
+strings use `stringOffset` and follow `nextStringOffset`; restart pagination when
+the revision changes. Never submit a truncated preview as a replacement payload.
+
 Cross-slice citations must close in the same session: when a requirement cites a
 verification target committed in another slice's session, re-commit that target
 here with the same id and `replace=true` (union backfill) before finalize. A
 `duplicate` receipt is a correction invitation, not a prohibition.
 
 The runtime owns protected skeleton fields, path/command validation, materialization,
-and final schema checks. Finish with exactly one `finalize_plan`; return no Markdown
+and final schema checks. Finish with one successful `finalize_plan` (correct rejected facts and retry); return no Markdown
 narrative. Record a genuine evidence gap when frozen facts are insufficient.
+
+## Implementation boundary
+
+Plan implementation actions and locations; this workflow runs only npm run build.
+Missing tests or test plans never block it. Preserve existing tests; add tests
+later in frontend-test.
+
+Submit `finalize_plan({implementationSteps: [{requirementIds, action}]})`.
+Cover every frozen ID, including constraints/exclusions (what to preserve/avoid).
+An action may cover related IDs and must describe changes within approved paths,
+not just repeat filenames or AC titles. Fix rejected missing/unknown/blank steps
+and retry. Runtime renders AC-linked canonical steps; no test plan is required.

package/skills/frontend-plan/references/decision-contract.md

@@ -6,24 +6,21 @@
   implementation paths and verification target IDs.
 - Record observable state and interaction behavior, including trigger and expected
   behavior. IDs and paths alone are not behavioral coverage.
-- One behavior target may cover multiple related requirements when one observable
-  test behavior proves them together.
-- Every non-static verification target `id` is the stable machine trace token and
-  must later appear in a real `describe` / `it` / `test` title. There is no free-form
-  `symbol` field.
+- Use a shared static build target for requirement coverage; build does not prove behavior.
+- Do not create behavior test targets, require test titles, or design tests.
 - Static targets are for project-wide commands and are traced by file and command
   only.
 
-### Behavior target shape (canonical example)
+### Build target mapping
 
-Each behavior target names the requirements it proves and declared UI states it
-exercises. Empty `requirementIds`, or empty `uiStates` when any state/interaction
-is declared, is rejected. Copy state names verbatim; never invent synonyms.
+Each static build target names the requirements mapped to its implementation file.
+Use the frozen build commandId. This mapping is not evidence of tested behavior.
 
 ```json
 {
-  "id": "VT-COUNTER-LOCAL-CONSTRAINTS",
-  "file": "src/App.test.tsx",
+  "id": "VT-BUILD",
+  "commandId": "<frozen-build-commandId>",
+  "file": "src/App.tsx",
   "requirementIds": ["AC-FE-001", "AC-FE-005"],
   "uiStates": ["disabled-minus", "default"]
 }
@@ -47,7 +44,7 @@ carries behavior, implementation targets, and verification target ids:
       "applicable": true,
       "expectedBehavior": "minus button disabled at count 0",
       "implementationTargets": ["src/components/SmokeCounter.tsx"],
-      "verificationTargetIds": ["VT-COUNTER-LOCAL-CONSTRAINTS"]
+      "verificationTargetIds": ["VT-BUILD"]
     }
   ],
   "interactions": [
@@ -56,7 +53,7 @@ carries behavior, implementation targets, and verification target ids:
       "trigger": "User clicks refresh",
       "expectedBehavior": "reloads runs",
       "implementationTargets": ["src/App.tsx"],
-      "verificationTargetIds": ["VT-SMOKE-COUNTER-BEHAVIOR"]
+      "verificationTargetIds": ["VT-BUILD"]
     }
   ]
 }
@@ -76,8 +73,7 @@ non-static verification target files to the writer writeSet separately.
     "src/App.tsx"
   ],
   "verificationTargetIds": [
-    "VT-SMOKE-COUNTER-BEHAVIOR",
-    "VT-COUNTER-LOCAL-CONSTRAINTS"
+    "VT-BUILD"
   ]
 }
 ```
@@ -95,9 +91,11 @@ facts".
 
 ## UX vocabulary (registry first)
 
-- Record `record_state_registry` BEFORE `record_state_flow`: one global vocabulary.
-  Coverage may slice by requirement; UX must not. Use stable kebab-case behavior
-  names, never AC-number-derived names or renamed committed concepts.
+- Record `record_state_registry` BEFORE any `record_state_flow`: one compact
+   global vocabulary of UI-state and interaction names. Details use complete execution
+   group scopes; reuse shared names across scopes, never one name per AC or a
+   rename of an already-recorded concept (kebab-case behavior-domain names, e.g.
+   `planner-task-edit`, `focus-queue-move`).
 - UI states use the contract's declared authoritative ids (`declaredUiStates`
   in the plan input) when the source declares a state table.
 - Retry slices see `committedUx` in the plan input: reuse those exact names.
@@ -111,9 +109,8 @@ One component choice may cover many states/interactions via `covers`.
 `reuse-existing` requires an existing-file `evidencePath`; greenfield uses `new`.
 
 For Mock/API, keep the real request path enabled by default. Select only a strategy
-allowed by the frozen task capability. Active Mock requires deterministic Mock-backed
-verification and production-default-off activation. `not-needed` requires positive
-real/no-remote evidence or records a real-integration gap.
+allowed by the frozen task capability. Active Mock requires production-default-off activation; Mock tests are deferred. `not-needed` records the reason Mock is unnecessary or skipped and any real-integration gap;
+no behavior test evidence is required here.
 
 Add dependencies only when authorized. Record unsupported dependency, path, API,
 design, or verification needs as blocking evidence gaps; never invent a command or
@@ -123,11 +120,33 @@ widen the write set.
 
 The runtime owns `schemaVersion`, `sourceBinding`, risk, canonical target files,
 `requiredDeliverables`, aliases, command allowlisting, path containment, and final
-validation. Submit only editable decision facts, then call `finalize_plan` exactly
-once. The deterministic design policy materializes the canonical implementation
+validation. Submit editable decision facts, then call `finalize_plan`; correct
+rejected facts and retry until one successful terminal commit. The deterministic design policy materializes the canonical implementation
 contract: every file in the Contract's explicit source-bound delivery inventory
 must be planned (`requiredDeliverables` gate). Permissions, prohibitions, examples
 and read-only references do not create delivery obligations. Plan receives this
 inventory as `requiredDeliverables`; it cannot add, remove or reinterpret it.
 Missing files and UX name collisions are reported by finalize_plan before commit
 and checked again by the policy shell.
+
+
+Use `record_plan_group_coverage` for a complete declared execution group with shared
+targets/VTs; runtime expands to all canonical members. Submit individual coverage
+for differences. Constraints/exclusions create no invented UI or tests; keep genuine
+source expectations for a non-blocking frontend-test handoff; do not require tests here.
+
+Submit Mock policy with `record_mock_api` and empty endpoints, then one endpoint per
+`record_mock_endpoint`. Use `replace:true` for revisions, plus `remove:true` to
+withdraw an endpoint. Use stable finding/fact identities; successful receipts mean
+durable commits. Resume missing work instead of regenerating full JSON or history.
+
+## Implementation steps submission
+
+Submit `finalize_plan` with `implementationSteps: [{requirementIds, action}]`.
+Each action says what to change and where within the approved implementation
+paths. Cover every frozen requirement ID, including constraints and exclusions
+(state what to preserve or avoid). One action may cover several related IDs.
+Do not merely repeat file names or AC titles. Missing, unknown or blank steps
+return a correctable receipt; fix the steps and call finalize_plan again.
+The runtime renders these into canonical `implementationSteps` strings with AC
+references. No test plan or new tests are required by this protocol.

package/skills/frontend-review/SKILL.md

@@ -9,46 +9,39 @@ references:
 
 # Frontend Review
 
-Use for `frontend-review-pi`; read the findings guide and capacity diagnostic first.
-Inputs are `contracts/frontend-review-context.json`, its hash-bound contract
-reference/index and diff fragments, and only source files named by that diff. Use
-indexed contract sections when recommended. Do not reopen task sources, plans,
-design-review prose, OpenSpec, or `ai_workspace/`; the bound context is authoritative.
+Use `contracts/frontend-review-context.json`, its hash-bound contract index and diff,
+and only files named by the diff. Read the findings guide and capacity diagnostic;
+use indexed sections when advised. Do not reopen task sources, plans, OpenSpec,
+design-review prose or `ai_workspace/`.
 
 ## Authoritative Terminal
 
-Complete the review with exactly one committed typed tool call:
+Submit findings one at a time with `record_review_finding` using stable IDs.
+Use `replace:true` for revisions. The terminal automatically includes saved findings;
+do not repeat their array. Correct rejected calls, then commit one successful terminal:
 
 - `approve_review` when no Critical/Important finding remains;
 - `request_review_changes` for a defect, missing required evidence, forbidden
   write, or unmet acceptance criterion. It must include a typed `issueCategory`,
-  at least one `evidenceRef`, and non-empty findings.
+  at least one `evidenceRef`, and non-empty findings (saved or supplied).
 
-The typed terminal is the only authoritative outcome. Do not require or emit a
-`VERDICT:` line or response-text JSON verdict. A request for review changes ends
-this run and is handled by the recovery controller rather than a same-run repair
-branch.
+Only the typed terminal controls the outcome; no `VERDICT:` line or JSON verdict.
+Requested changes end this run; the recovery controller owns follow-up.
 
 ## Review Scope
 
-- 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, design, responsive/a11y,
-  dependencies, 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.
-- 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.
-- Evaluate component/design claims against bound evidence; do not replace it with a
-  repository-wide search or connector query.
-- Treat shell exit status as authoritative. Do not edit files.
+- Map every requirement to corresponding implementation in the cumulative diff
+  and bound target files. Report missing implementation or altered requirements.
+- Check allowed paths, forbidden paths, approved dependencies and source-bound
+  design constraints. Preserve production Mock isolation and real-request defaults.
+- Inspect the archived npm run build result; it is the only required command.
+- Do not require unit tests, a test framework, test plans, lint, separate typecheck,
+  behavior evidence or Mock tests. Existing tests are preserved.
+- Behavior correctness, edge cases and regressions belong to the non-blocking
+  frontend-test handoff and may be tested later. Do not expand into a correctness audit.
+- Build success proves buildability only. Do not report tested behavior or real
+  integration without actual evidence. Treat shell exit status as authoritative.
+- Do not edit files or perform repository-wide rediscovery.
 
 ## Evidence And Output
 

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

@@ -1,49 +1,30 @@
 # Frontend Review Findings Guide
 
-## Severity
+## Scope and severity
 
-- **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.
+- **Critical/Important**: missing requirement implementation, unauthorized writes
+  or dependencies, production Mock isolation violation, altered source requirements,
+  failed/missing npm run build, or a false verification/integration claim.
+- **Advisory**: behavior correctness, edge cases, regression concerns and missing
+  tests. Record these for later frontend-test work; they do not block implementation.
 
 ## Evidence
 
-- 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. 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 the design evidence already bound in the canonical review context as the
-  source of truth. Do not launch a connector query or repository-wide OpenSpec/
-  `ai_workspace` search to replace frozen evidence; label a missing bound evidence
-  reference accurately instead.
-
-## Review Sequence
-
-1. Establish changed-file inventory and write boundaries.
-2. Compare the bound contract with the approved constraints and cumulative diff.
-3. Map each criterion to code, states, tests, and evidence.
-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, verification, production imports, and
-   the real-integration gap.
-6. Check bound design evidence, responsive/a11y behavior, dependencies, and maintenance.
-7. Classify findings and derive the verdict mechanically.
-
-```text
-- [Critical|Important|Minor] path:line — Problem; impact; required correction; evidence.
-```
-
-## 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/browser/visual/manual checks remain explicit risks.
+Cite the bound contract, actual cumulative diff, tight file locations and archived
+build result. Never substitute an implementation summary for the diff or invent
+verification results. Use only evidence supplied in the canonical review context.
+
+## Review sequence
+
+1. Establish changed files and authorized write boundaries.
+2. Map each requirement to corresponding implementation.
+3. Check source-bound design constraints, dependency permission and production Mock isolation.
+4. Confirm npm run build passed and classify findings within this scope.
+
+## Pass rules
+
+All requirements have corresponding implementation, changes stay authorized,
+production Mock safety is preserved, and npm run build passed. No blocking finding
+within this scope remains. Missing unit tests, test frameworks, test plans, lint,
+separate typecheck or behavior evidence are not blockers. Existing tests are kept.
+Behavior and real integration remain unverified unless separate evidence exists.

package/skills/frontend-scout/references/scout-evidence.md

@@ -21,3 +21,7 @@ the exact evidence. Do not recursively inspect unrelated directories.
 Commit `complete` only when the target surface is sufficiently proven for Plan to
 reuse without repository discovery. Otherwise commit `blocked` and list every
 unresolved path or ownership question. Do not shift discovery work into Plan.
+
+A successful typed receipt is durable. Reuse only facts bound to the same source
+and fresh file evidence; changed or missing evidence requires Scout refresh. Do
+not replay stale success or repeat complete discovery merely because a reply was lost.

package/dist/worker/console/static/assets/channel-DAS07MdS.js

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

package/dist/worker/console/static/assets/classDiagram-JCYQIIEL-Cwk-5jiW.js

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-GF5L2VYU-sF1AEy7T.js";import{_ as i}from"./mermaid.core-BUuGHmWO.js";import"./chunk-5VM5RSS4-D5J9PHC7.js";import"./chunk-XXDRQBXY-BEJi3iIs.js";import"./chunk-KBJHAD2P-BKJrPcJ6.js";import"./chunk-2GRJ4B5K-C0osm1Zf.js";import"./index-C0O48S_P.js";var n={parser:e,get db(){return new t},renderer:s,styles:a,init:i(r=>{r.class||(r.class={}),r.class.arrowMarkerAbsolute=r.arrowMarkerAbsolute},"init")};export{n as diagram};

package/dist/worker/console/static/assets/classDiagram-v2-OCEON4UE-Cwk-5jiW.js

@@ -1 +0,0 @@
-import{s as a,c as s,a as e,C as t}from"./chunk-GF5L2VYU-sF1AEy7T.js";import{_ as i}from"./mermaid.core-BUuGHmWO.js";import"./chunk-5VM5RSS4-D5J9PHC7.js";import"./chunk-XXDRQBXY-BEJi3iIs.js";import"./chunk-KBJHAD2P-BKJrPcJ6.js";import"./chunk-2GRJ4B5K-C0osm1Zf.js";import"./index-C0O48S_P.js";var n={parser:e,get db(){return new t},renderer:s,styles:a,init:i(r=>{r.class||(r.class={}),r.class.arrowMarkerAbsolute=r.arrowMarkerAbsolute},"init")};export{n as diagram};