@zhixuan92/multi-model-agent 4.3.1 → 4.5.0

package/dist/http/handlers/tools/verify.js

@@ -1,53 +0,0 @@
-import * as verify from '@zhixuan92/multi-model-agent-core/tools/verify/schema';
-import { executeTask } from '@zhixuan92/multi-model-agent-core/lifecycle/task-executor';
-import { toolConfig } from '@zhixuan92/multi-model-agent-core/tools/verify/tool-config';
-import { sendError, sendJson } from '../../errors.js';
-import { asyncDispatch } from '../../async-dispatch.js';
-import { emitRequestReceived } from '../../request-observability.js';
-export function buildVerifyHandler(deps) {
-    return async (_req, res, _params, ctx) => {
-        const parsed = verify.inputSchema.safeParse(ctx.body);
-        if (!parsed.success) {
-            sendError(res, 400, 'invalid_request', 'Request body validation failed', {
-                fieldErrors: parsed.error.flatten(),
-            });
-            return;
-        }
-        const input = parsed.data;
-        const cwd = ctx.cwd;
-        const reserveResult = deps.projectRegistry.reserveProject(cwd);
-        if (!reserveResult.ok) {
-            sendError(res, 503, reserveResult.error, reserveResult.message);
-            return;
-        }
-        const pc = reserveResult.projectContext;
-        pc.lastActivityAt = Date.now();
-        deps.projectRegistry.cancelReservation(cwd);
-        const blockIds = input.contextBlockIds ?? [];
-        const { batchId, statusUrl } = asyncDispatch({
-            tool: 'verify',
-            projectCwd: cwd,
-            blockIds,
-            batchRegistry: deps.batchRegistry,
-            projectContext: pc,
-            deps,
-            caller: { client: ctx.callerClient, mainModel: ctx.mainModel },
-            executor: async (executionCtx) => {
-                const callExecutor = () => executeTask(toolConfig, executionCtx, input);
-                if (deps.routeDispatcher) {
-                    const result = await deps.routeDispatcher.dispatch({
-                        route: 'verify',
-                        toolCategory: 'read_only',
-                        rawRequest: input,
-                        executor: () => callExecutor(),
-                    });
-                    return result.body;
-                }
-                return callExecutor();
-            },
-        });
-        await emitRequestReceived({ config: deps.config, batchId, route: _req.url ?? '', parsed: input });
-        sendJson(res, 202, { batchId, statusUrl });
-    };
-}
-//# sourceMappingURL=verify.js.map

package/dist/http/handlers/tools/verify.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"verify.js","sourceRoot":"","sources":["../../../../src/http/handlers/tools/verify.ts"],"names":[],"mappings":"AAGA,OAAO,KAAK,MAAM,MAAM,uDAAuD,CAAC;AAChF,OAAO,EAAE,WAAW,EAAE,MAAM,2DAA2D,CAAC;AACxF,OAAO,EAAE,UAAU,EAAE,MAAM,4DAA4D,CAAC;AACxF,OAAO,EAAE,SAAS,EAAE,QAAQ,EAAE,MAAM,iBAAiB,CAAC;AACtD,OAAO,EAAE,aAAa,EAAE,MAAM,yBAAyB,CAAC;AAExD,OAAO,EAAE,mBAAmB,EAAE,MAAM,gCAAgC,CAAC;AAErE,MAAM,UAAU,kBAAkB,CAAC,IAAiB;IAClD,OAAO,KAAK,EAAE,IAAqB,EAAE,GAAmB,EAAE,OAA+B,EAAE,GAAG,EAAE,EAAE;QAChG,MAAM,MAAM,GAAG,MAAM,CAAC,WAAW,CAAC,SAAS,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;QACtD,IAAI,CAAC,MAAM,CAAC,OAAO,EAAE,CAAC;YACpB,SAAS,CAAC,GAAG,EAAE,GAAG,EAAE,iBAAiB,EAAE,gCAAgC,EAAE;gBACvE,WAAW,EAAE,MAAM,CAAC,KAAK,CAAC,OAAO,EAAE;aACpC,CAAC,CAAC;YACH,OAAO;QACT,CAAC;QAED,MAAM,KAAK,GAAG,MAAM,CAAC,IAAI,CAAC;QAC1B,MAAM,GAAG,GAAG,GAAG,CAAC,GAAI,CAAC;QAErB,MAAM,aAAa,GAAG,IAAI,CAAC,eAAe,CAAC,cAAc,CAAC,GAAG,CAAC,CAAC;QAC/D,IAAI,CAAC,aAAa,CAAC,EAAE,EAAE,CAAC;YACtB,SAAS,CAAC,GAAG,EAAE,GAAG,EAAE,aAAa,CAAC,KAAK,EAAE,aAAa,CAAC,OAAO,CAAC,CAAC;YAChE,OAAO;QACT,CAAC;QACD,MAAM,EAAE,GAAG,aAAa,CAAC,cAAc,CAAC;QACxC,EAAE,CAAC,cAAc,GAAG,IAAI,CAAC,GAAG,EAAE,CAAC;QAC/B,IAAI,CAAC,eAAe,CAAC,iBAAiB,CAAC,GAAG,CAAC,CAAC;QAE5C,MAAM,QAAQ,GAAG,KAAK,CAAC,eAAe,IAAI,EAAE,CAAC;QAC7C,MAAM,EAAE,OAAO,EAAE,SAAS,EAAE,GAAG,aAAa,CAAC;YAC3C,IAAI,EAAE,QAAQ;YACd,UAAU,EAAE,GAAG;YACf,QAAQ;YACR,aAAa,EAAE,IAAI,CAAC,aAAa;YACjC,cAAc,EAAE,EAAE;YAClB,IAAI;YACJ,MAAM,EAAE,EAAE,MAAM,EAAE,GAAG,CAAC,YAAY,EAAE,SAAS,EAAE,GAAG,CAAC,SAAS,EAAE;YAC9D,QAAQ,EAAE,KAAK,EAAE,YAAY,EAAE,EAAE;gBAC/B,MAAM,YAAY,GAAG,GAAG,EAAE,CAAC,WAAW,CAAC,UAAU,EAAE,YAAY,EAAE,KAAK,CAAC,CAAC;gBACxE,IAAI,IAAI,CAAC,eAAe,EAAE,CAAC;oBACzB,MAAM,MAAM,GAAG,MAAM,IAAI,CAAC,eAAe,CAAC,QAAQ,CAAC;wBACjD,KAAK,EAAE,QAAQ;wBACf,YAAY,EAAE,WAAW;wBACzB,UAAU,EAAE,KAAK;wBACjB,QAAQ,EAAE,GAAG,EAAE,CAAC,YAAY,EAAE;qBAC/B,CAAC,CAAC;oBACH,OAAO,MAAM,CAAC,IAAI,CAAC;gBACrB,CAAC;gBACD,OAAO,YAAY,EAAE,CAAC;YACxB,CAAC;SACF,CAAC,CAAC;QAEH,MAAM,mBAAmB,CAAC,EAAE,MAAM,EAAE,IAAI,CAAC,MAAM,EAAE,OAAO,EAAE,KAAK,EAAE,IAAI,CAAC,GAAG,IAAI,EAAE,EAAE,MAAM,EAAE,KAAK,EAAE,CAAC,CAAC;QAElG,QAAQ,CAAC,GAAG,EAAE,GAAG,EAAE,EAAE,OAAO,EAAE,SAAS,EAAE,CAAC,CAAC;IAC7C,CAAC,CAAC;AACJ,CAAC"}

package/dist/skills/mma-verify/SKILL.md

@@ -1,155 +0,0 @@
----
-name: mma-verify
-description: >-
-  Use when work is "complete" and you need to confirm acceptance criteria are
-  actually met before claiming so to the user — each checklist item verified
-  independently against the work
-when_to_use: >-
-  The user (or a methodology skill like
-  superpowers:verification-before-completion) needs acceptance-criteria checked
-  against implemented work BEFORE claiming success. Delegate so each checklist
-  item gets independent evidence-gathering on a worker. Use this BEFORE saying
-  "done" — never after.
-version: 4.3.1
----
-
-# mma-verify
-
-## Overview
-
-Submit work product and a checklist to workers for independent verification. Each checklist item is verified in parallel; results are index-aligned with the input.
-
-**Core principle:** Self-verification ("I read the files; they look correct") has no external validation. Workers check independently and return evidence (or absence of it) per item.
-
-## When to Use
-
-**Use when:**
-- You're about to claim a task is "done" and need evidence per acceptance item
-- A methodology skill (superpowers:verification-before-completion) routed here
-- The user gave a checklist and asked you to confirm each item
-
-**Don't use when:**
-- The "checklist" is one item — read inline, faster than dispatch
-- You don't have explicit acceptance criteria — write them first, then dispatch
-- The work hasn't been done yet — verification is a post-condition, not a pre-condition
-
-## Endpoint
-
-`POST /verify?cwd=<abs-path>`
-
-@include _shared/auth.md
-
-## Request body
-
-```json
-{
-  "work": "inline description of the work (optional if filePaths given)",
-  "checklist": [
-    "All public functions have JSDoc comments",
-    "No console.log statements remain",
-    "Unit tests cover the happy path and at least one error case"
-  ],
-  "filePaths": ["/project/src/utils.ts"],
-  "contextBlockIds": []
-}
-```
-
-| Field | Type | Required | Notes |
-|---|---|---|---|
-| `work` | string | no | Inline work-product description (e.g. summary of what changed) |
-| `checklist` | string[] | yes | At least one item — each item verified by its own worker |
-| `filePaths` | string[] | no | Files to verify against (workers can read them) |
-| `contextBlockIds` | string[] | no | IDs from `mma-context-blocks` (e.g. the spec the work was supposed to satisfy) |
-
-> Worker tier for `mma-verify` is hardcoded to `complex` and is not caller-configurable. Sending `agentType` is rejected with HTTP 400.
-
-## Full example
-
-```bash
-BATCH=$(curl -f --show-error -s -X POST \
-  -H "X-MMA-Client: $MMA_CLIENT" \
-  -H "Authorization: Bearer $TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{"checklist":["Error handler exists","Tests pass"],"filePaths":["/project/src/handler.ts"]}' \
-  "http://localhost:$PORT/verify?cwd=/project")
-BATCH_ID=$(echo "$BATCH" | jq -r '.batchId')
-```
-
-@include _shared/polling.md
-
-@include _shared/response-shape.md
-
-## Reading the findings (3.10.5+)
-
-The terminal envelope's `results[N].annotatedFindings` is a list of structured
-findings the reviewer extracted and scored from the implementer's narrative.
-Every finding has the same shape:
-
-| Field | Type | Notes |
-|---|---|---|
-| `id` | string | Reviewer-assigned, e.g. `F1`, `F2`. |
-| `severity` | `'critical' \| 'high' \| 'medium' \| 'low'` | 4-tier. |
-| `claim` | string | One-sentence summary. |
-| `evidence` | string ≥20 chars | Quoted from worker output when grounded. |
-| `suggestion?` | string | Optional fix recommendation. |
-| `annotatorConfidence` | `number \| null` | 0–100 from the reviewer; `null` when emitted via deterministic fallback. |
-| `evidenceGrounded` | boolean | True when `evidence` is a verbatim substring of worker output. |
-
-### Verdict states (`qualityReviewVerdict`)
-
-- `'annotated'` — every finding is structured. May be reviewer-emitted (with
-  numeric `annotatorConfidence`) or deterministic-fallback (with
-  `annotatorConfidence: null`). The route ALWAYS reaches `'annotated'` unless
-  the reviewer call itself fails transport.
-- `'error'` — only when the reviewer call fails transport (network / 5xx).
-
-### Recommended rendering by the main agent
-
-1. Show ALL findings — never silently drop. Confidence and grounding are
-   soft signals, not gates.
-2. Default sort: severity (critical → low) then `annotatorConfidence` desc
-   (nulls last).
-3. `severity` is the reviewer's authoritative final value — use it directly.
-4. Mark findings with `evidenceGrounded: false` or
-   `annotatorConfidence < 70` as "lower-trust" (collapsed section, lighter
-   color, or `(low confidence)` annotation). User decides what to do.
-5. Severity-tier counts feed the dashboard via V3 `findingsBySeverity`.
-
-@include _shared/budget-defaults.md
-
-## Best practices
-
-This skill is one step in the larger flow described in `multi-model-agent` → "Best practices". Recipes that involve `mma-verify`:
-
-- **Recipe B — Debug-fix-verify.** `mma-debug` → `mma-delegate` (fix) → `mma-verify`. Verify checks acceptance criteria against the implemented work. Reuse the context block registered for the debug call.
-
-Anti-pattern alert: **`parallel-rounds-same-target`** (AP1, verify analog). Two parallel `mma-verify` calls on the unchanged checklist re-flag the same gaps. Run verify → fix → re-verify sequentially instead.
-
-## Common pitfalls
-
-❌ **Vague checklist items**
-> "Code is good"
-
-The worker can't gather evidence for "good". **Fix:** specific, falsifiable criteria — `"Function parseConfig has at least 3 unit tests covering: missing field, malformed JSON, empty file"`.
-
-❌ **Verifying without `filePaths`**
-Worker has nothing to read; verdict is speculative. **Fix:** always pass the file(s) the work landed in.
-
-❌ **Treating verify as the implementation step**
-Verify CHECKS work; it doesn't DO work. If a checklist item fails, dispatch `mma-delegate` to fix it, then re-verify.
-
-❌ **Skipping verify because "tests pass"**
-Tests verify the test cases that exist. Verify checks the acceptance criteria — which often include things tests don't (docs updated, no debug-print left, etc.).
-
-## Terminal context block
-
-Every completed task automatically registers a terminal markdown context block containing the full task report (headline, checklist item verdicts, and annotated findings). The `blockId` is returned in each task result as `terminalBlockId`. This block is immutable, lives for the session duration, and counts against the project's `maxEntries` quota (default 500).
-
-**Use cases:**
-- Pass verification results to a downstream `mma-delegate` fix step
-- Feed verify findings into a re-verify round after fixes are applied
-- Accumulate evidence across iterative verify-fix-verify cycles
-
-The block is registered server-side at task completion; no caller action is needed to create it. Delete it explicitly via `DELETE /context-blocks/:id` when no longer needed, or let it expire on session teardown.
-
-@include _shared/error-handling.md