MAESTRO 全機能カタログ & テストカバレッジ

Engine core

Highest-risk untested behaviors, ranked:

1. ENG-052 classifyPiece async path (NONE). Routing every task to a piece runs through this LLM call + fallback. Only the two pure helpers are tested; the wiring, the null-parse→default-piece fallback, and LLM-error handling have zero coverage. A regression here silently misroutes all tasks.
2. ENG-037 WAITING_HUMAN_BROWSER / WAITING_HUMAN_TOOL_REQUEST pauses (NONE). Two human-wait sentinel branches in piece-runner have no test. A break leaves jobs hung or, worse, falsely completed — same failure class as the documented context-overflow default_next trap.
3. ENG-039 Lessons injection + cap + lessons.jsonl (PARTIAL). Lessons appear in snapshot tests, but the core promise — accumulated lessons injected into the next movement's prompt and trimmed at 2000 chars — is not directly asserted, nor is writeLessonLog. Silent loss of cross-movement learning would be invisible.
4. ENG-053 loadAllPieceTriggers (NONE). Trigger/keyword loading feeds the classifier hint layer; the custom-dir precedence and skip-on-invalid-piece branches are uncovered.
5. ENG-033 cross-movement loop guard per-movement override + reset (PARTIAL) and ENG-013 mid-iteration cancel (PARTIAL). The default-revisit abort is tested, but per-movement max_consecutive_revisits and the counter-reset-on-movement-change branch are not — the exact knobs that prevent runaway loops. Likewise mid-work cancellation (vs pre-loop) is only covered via snapshot side effects.

Tools

1. ReadPPTX ZIP-bomb detection & PPTX size limit (TOOL-015) — NONE. office.ts:2124-2130 rejects total-uncompressed > 200MB and validateOfficeFile enforces the 50MB file cap, but office.test.ts contains no test that crafts an over-limit / high-compression-ratio PPTX. This is the only declared anti-DoS guard in the tools layer and it is completely unverified. A malformed/regressed check would silently allow a decompression bomb.
2. Office file-size-limit enforcement across ReadExcel/ReadDocx/ReadPdf (TOOL-012/013/014) — PARTIAL→NONE for the limit path. Tests thoroughly cover *format-mismatch* rejection (CFB/HTML/CSV/OOXML disguises) but never exercise stats.size > maxSize → warning emission. The resolveMaxSize config override (tools.office_*_max_size_mb) is also untested.
3. index.ts dispatch order, first-match-wins, and silent-skip-on-load-failure (XCUT-001) — NONE. A single test checks the SshConsole catalog. The core invariant — that a tool name resolves to exactly one module in a fixed precedence order, and that a module failing to import is skipped without crashing dispatch — has no test. A duplicate tool name or an import regression would pass CI.
4. index.ts runtime META_TOOLS injection (XCUT-002) — PARTIAL. The 20-name runtime META list in index.ts:411 (RequestTool, MissionUpdate, all UserFolder/AppDocs tools, etc.) is what actually makes these always-available regardless of a movement's allowed_tools, yet only the smaller tool-categories.ts SUBSET is asserted. The two lists can drift (they already differ by design); nothing tests that the runtime injection list matches expectations.
5. DownloadFile robustness (TOOL-009) — PARTIAL. Only source-vs-input routing is tested. No coverage for download size limits, redirect following, content-type handling, or failure modes — the same blast radius class as WebFetch but without WebFetch's SSRF/binary test depth.

Pieces

1. 8 of 15 pieces have ZERO direct test beyond the schema-load sweep (research-sub, brainstorming, sns-research, x-ai-digest, help) and several more are only name-fixtures (chat, slide, data-process, piece-builder). No test asserts their movement/rule/transition contract or their allowed_tools allowlist. A piece could be silently broken (wrong tool name, dropped movement, bad transition graph that still parses) and only loadPiece().not.toThrow() would catch it — which it won't, since those are semantic not schema errors. Highest-value targets: research-sub (spawned, complex 3-movement loop), brainstorming, sns-research, x-ai-digest.
2. No allowed_tools-vs-real-tool-registry consistency test. Pieces list tool names in allowed_tools as plain strings; nothing asserts every name in every piece resolves to an actual registered tool. A typo (or a renamed/removed tool) leaves a dead allowlist entry that silently never gets offered to the LLM — exactly the class of drift the maintenance-checklist warns about. This would be a cheap, high-leverage sweep test across all 15 pieces.
3. lint-pieces.mjs (PINFRA-004) has no test. The CI gate script (file collection, exit codes 0/1/2, YAML parse-error path) is entirely untested. Its core rule is mirrored by validatePieceDef (tested), but the script's own CLI behavior — including its parse-error exit(2) and multi-file argument handling — could regress without notice.
4. No transition-graph reachability / dangling-next validation for pieces. Validation only bans terminal values in rules[].next and (in the tool path) checks next ∈ movements∪WAIT_SUBTASKS. But file-backed loadPiece/validatePieceDef does NOT verify that every rules[].next points to an existing movement, nor that initial_movement exists, nor that every movement is reachable. A built-in YAML with a typo'd next: would load fine and only fail at runtime ("Movement not found"). No test guards this for the shipped pieces.
5. Per-user piece resolution propagation (PINFRA-017) is only partially tested. The known "no-auth 'local' fallback" / "custom-default separation" checklists call out worker, continue-job, scheduler, classifier, and pieces-api as all needing custom-dir threading. Only the worker load path and pieces-api authz have tests; the scheduler-spawn and continue-job (resume after ASK/subtasks) paths resolving the correct per-user custom piece are not directly asserted — a regression here would silently fall back to built-in pieces for custom-piece users.

Reflection

1. REFL-032 — applyOne per-change write-failure path (decision.code='failed'): when a memory write throws mid-loop, the applier records that single change as failed and continues. This distinct per-change failure branch (vs runner-level outcome='failed') is not clearly asserted. It is the only place a memory mutation can partially fail under the lock, so it directly affects partial/rejected outcome correctness.
2. REFL-056 — space authz negative path (canEditInSpace → 404): the reflection-api space-store resolution depends on canEditInSpace. Tests cover the space-principal happy path, but a space *member without edit rights* hitting history/revert (must 404, no leak) is not asserted as a distinct multiuser case — exactly the kind of cross-principal authz gap that whole-branch reviews catch but per-unit tests miss.
3. REFL-013 / REFL-044 / REFL-045 — runner snapshot-capture + non-fatal writeSnapshot failure: the runner's writeSnapshot-throws-but-record-metric-anyway branch, plus the before/after capture edge cases (remove-op uses merge_target for the before-file name; piece-YAML pre/post capture when customPath doesn't yet exist), are only lightly exercised. A torn snapshot here silently degrades the revert feature.
4. REFL-007 — reflection dispatch / gateway routing: worker.reflection-dispatch.test.ts is small (~2 cases). The gateway role-keyed routing (reflectionRoutingKey, roleFallback:'reflection') and the "send worker API key or gateway 401s" requirement are documented in code comments but not asserted end-to-end — a deploy-shaped risk (401 storms) that unit tests don't catch.
5. REFL-031 / REFL-037 — boundary branches in applier: the ">3 memory_changes truncated with WARN" hard cap and the decideOutcome empty-input fallback-to-abstained (distinct from an explicit abstain_reason) lack dedicated assertions. Both are silent-correctness branches: a regression would mis-drop changes or mislabel outcomes without any test going red.

Bridge core

1. APIC-016 GET /api/local/tasks/:taskId/stream (NONE) — The SSE event stream (tool-call/delta mapping, visibility gate, the toolBuf/event-name reconstruction logic around line 976) has zero direct tests. This is the live job-progress feed the UI depends on; a regression here is invisible to CI.
2. APIC-007 PUT /api/local/tasks/:taskId/mission (NONE) — Mission update route is completely untested: no authz (owner/admin vs viewer), no validation, no persistence assertion. Only superficial string match in an unrelated auth test.
3. APIC-020 office-preview HTTP route (PARTIAL) — The module is well tested, but the /files/office-preview endpoint wiring is not: section-enum 400, canViewTask gate, and the SofficeUnavailableError→503 mapping are unexercised end-to-end (only handleOfficePreviewError would do the 503).
4. APIC-045 subtask file 403 traversal branch (PARTIAL) — GET /subtasks/:jobId/files/* has the explicit resolved !== base && !startsWith(base+sep) → 403 escape guard, but no test drives a traversal payload to assert the 403. The containment helper is unit-tested (APIC-046) but the route-level enforcement is not.
5. APIC-011 regenerate-title (PARTIAL) — Only exercised inside the spaces test in an owner-happy context; the owner/admin-only authz denial path and the missing-generator branch are not asserted. (Secondary: APIC-041 trigger happy-path, APIC-008 comments read-gate, and APIC-037/043 GET-by-id view gates are similar PARTIAL thin spots.)

Bridge auth & spaces

Highest risk first (authorization-weighted):

1. APIS-038 Space tool-policy write under-tested (HIGH). PUT /:id/tool-policy gates by canManageSpace, but only 9 authz assertions and — per MEMORY (PR #653) — the Bash/sensitive-tool write path (buildPolicyPatch only walked categories, missing the SENSITIVE_TOOLS separate channel) was a real save-loss bug. The read/validate/render/write round-trip for sensitive tools across both delivery systems is not asserted end-to-end. A regression here silently grants/denies Bash/SSH/browser/MCP. Add an integration test that PUTs a sensitive-tool policy as a non-manager (expect 403) and as owner (expect persisted both-channels).
2. APIS-052 Gateway proxy auth boundary (HIGH). mountGateway proxies LLM traffic; classification and config-equivalence are well tested, but the authentication of proxied requests (Bearer/API-key acceptance/rejection, 401 on bad key) is not asserted in gateway-mount.test.ts. An unauthenticated path slipping through the gateway mount would expose backend LLM spend. Deploy-order note in MEMORY (gateway→client) hints this boundary is operationally fragile.
3. APIS-062 Dashboard API has no visible auth guard (MEDIUM-HIGH). createDashboardApi router shows no requireAuth/requireAdmin in its route definitions and the test asserts 0 authz cases. Worker/node (GPU) status may leak infra topology to unauthenticated/non-admin users. Confirm guard is applied at mount site (server.ts) and add an authz assertion.
4. APIS-019 Shared-subtask wildcard traversal (MEDIUM). GET /api/shared/:token/subtasks/:jobId/files/* is a public token route with a wildcard path segment; containment relies on isJobWithinWorkspace prefix guard. No direct test asserts path-traversal/prefix-collision rejection on this wildcard. This is exactly the class fixed previously (startsWith prefix collision) — add a traversal/escape test.
5. APIS-014 No-auth admin passthrough breadth (MEDIUM). When authActive=false, admin guards downgrade to passthrough (admin-api covered; branding adminGuard no-auth path not asserted). If a deployment runs no-auth on a shared network, branding upload/delete is fully open. Document/assert the no-auth posture for every admin route, not just user CRUD.

Lower-priority partials worth noting: APIS-018/APIS-027 (per-endpoint path-escape / non-member-on-public read not asserted), APIS-032 (calendar non-editor write rejection lighter than file gates), APIS-044 (noVNC proxy upgrade authz), APIS-056 (push send delivery).

Services & DB

1. Job recovery & resume helpers untested (DB-003, DB-032, SVC-019). recoverOrphanedJobs, recoverStuckRunningJobs, resumeMcpWaitingJobs, resumeToolRequestJob, and requeueParentJobIfAllSubtasksDone have no direct unit tests. These run on worker restart / subtask completion and directly affect whether jobs get stuck or double-run — exactly the class of bug seen in the config-rebuild double-execution incident. Highest-risk gap because failures are silent (stuck or duplicated jobs in prod).
2. Env override matrix only partially covered (CFG-004, CFG-016). Only OLLAMA_BASE_URL is asserted (in config.audit-regression). CONCURRENCY, WORKTREE_DIR, OLLAMA_MODEL, DB_PATH, and the AAO_* metrics vars have no test. Env overrides are a documented public interface and a known footgun (storage mirror precedence already bit the project in #368/#369).
3. answerSubtaskAsk / subtask ASK plumbing (SVC-019). The path where a parent worker answers a child subtask's ASK and the parent requeues on all-subtasks-done is untested end-to-end. This is core to the waiting_subtasks/waiting_human lifecycle and has tangled state.
4. addAuditLog not unit-tested (DB-027). Only one consumer (script run) is asserted indirectly. Audit log is a security/compliance surface; no test guards the row shape or that mutating ops actually write audit rows.
5. Comment injection lifecycle (DB-008). getUninjectedComments / markCommentsInjected / getLatestResultComment drive what the agent sees from user comments and what the user sees as the final result — no direct assertion of the inject→mark→re-query cycle, despite being on the hot path for continuation jobs.

UI

1. UI-055 FilePreview relative-image rewrite (resolveImageHref/resolvedHref, FilePreview.tsx ~L320) — core, user-visible (broken images in markdown), and currently untested. *Sandbox-testable IF the href-rewrite function is extracted to lib/ (pure string transform); today it's inline in a component so as-is it needs jsdom.*
2. UI-059 Settings forms (~45 *Form.tsx) — largest untested surface; only SettingsSidebar section logic + toolPolicy are covered. Per-form validation/round-trip is jsdom/e2e. Mitigation that IS sandbox-testable: extract each form's validation/serialization into pure helpers (the established pattern in this repo) and unit-test those.
3. UI-064 SSH UI (config/console/grants/audit/rotation) — large surface, only TS types tested, no behavior tests. Console session + websocket needs e2e; grant/audit list filtering + form validation are extractable to lib (sandbox-testable).
4. UI-049/UI-051/UI-052 untested pure libs (fileDnd, localDate, spaceColor) — immediately sandbox-testable, no extraction needed. localDate (tz math) is the highest regression risk of the three.
5. UI-026 toolPolicy Bash/sensitive-tools write-path — known real bug class (MEMORY: PR #653 fixed a save gap where buildPolicyPatch only walked categories and missed SENSITIVE_TOOLS/Bash). Test exists but should assert both the category system and the separate sensitiveTools array across read/validate/render/write. Sandbox-testable now (pure).