@massa-ai/claude-plugin 1.61.0 → 1.63.0

package/skills/massa-ai/references/maestro/mcp.md

@@ -1,59 +0,0 @@
-# Maestro MCP Reference
-
-Use only when the task mentions Maestro MCP, agent/device automation through MCP tools, Maestro Viewer, or Cloud MCP tooling.
-
-## MCP Surface
-
-Maestro MCP ships inside the Maestro CLI and is started with:
-
-```bash
-maestro mcp
-```
-
-Agent configs generally use stdio with command `maestro` and args `["mcp"]`. If the agent launches from a minimal shell, use full binary path and explicit `JAVA_HOME` when needed.
-
-## Install Examples
-
-Codex CLI:
-
-```bash
-codex mcp add maestro -- maestro mcp
-```
-
-Manual config:
-
-```toml
-[mcp_servers.maestro]
-command = "maestro"
-args = ["mcp"]
-```
-
-Do not install or modify MCP config unless the user asks or the active workflow explicitly owns integration setup.
-
-## Tool Metadata
-
-Official docs list these MCP tools:
-
-- `list_devices`
-- `inspect_screen`
-- `take_screenshot`
-- `run`
-- `cheat_sheet`
-- `list_cloud_devices`
-- `run_on_cloud`
-- `get_cloud_run_status`
-- `open_maestro_viewer`
-
-`run` accepts exactly one execution shape: inline YAML, specific files, or directory with include/exclude tags. `list_cloud_devices`, `run_on_cloud`, and `get_cloud_run_status` require Maestro Cloud authentication.
-
-## Viewer
-
-Maestro Viewer embeds a device/browser surface for inspection and interaction. Use it as an optional runtime sensor when available; do not treat screenshot success alone as full product or Figma parity.
-
-## CLI Help Caveat
-
-Some installed Maestro versions may print `maestro mcp` usage while returning a non-zero code for `maestro mcp --help`. Record command, exit code, stdout, and stderr exactly. Use official MCP docs plus `maestro --help` for normative MCP availability unless subcommand help succeeds.
-
-## Boundary
-
-MCP can speed authoring and live verification, but it does not replace repository state, official docs, saved audit reports, or deterministic closure evidence. Record skipped reason when MCP is not configured.

package/skills/massa-ai/references/maestro/patterns.md

@@ -1,102 +0,0 @@
-# Maestro Workflow Patterns
-
-Use for stable suite design, setup/teardown strategy, validation assets, and workflow output contracts.
-
-## Stable Flow Design
-
-- Keep flows readable, short, and scoped to one user journey or smoke path.
-- Reuse subflows for login, onboarding, permissions, setup, teardown, and navigation.
-- Prefer deep links, API fixtures, or app state reset over long UI-only setup when the repo already supports them.
-- Prefer stable selectors and observable states over fixed waits, coordinates, images, and copy that changes often.
-- Keep setup and teardown explicit, idempotent, and isolated.
-- Preserve existing flows, subflows, fixtures, snapshots, baselines, and CI report consumers unless the scoped task explicitly changes them.
-
-## Suite Segmentation
-
-Common suite intents:
-
-- smoke
-- critical path
-- release-blocking
-- nightly
-- platform-specific
-- quarantined
-- device-farm-only
-- Cloud-only
-
-Use tags and config rather than duplicate flow logic when possible.
-
-## Setup And Cleanup
-
-Use the smallest deterministic setup:
-
-1. reset app state (`clearState`, launch options, fixture cleanup)
-2. set permissions and locale/timezone assumptions
-3. create test data through repo-approved fixture/API helpers
-4. navigate by deep link or reusable subflow
-5. verify initial state before exercising the journey
-6. clean up in `onFlowComplete` or explicit teardown
-
-If cleanup cannot be guaranteed, isolate test data and record residual risk.
-
-## Output Contracts
-
-`maestro` closure summary must include:
-
-- scenario source
-- changed flows/subflows/fixtures/setup/teardown
-- setup/teardown strategy
-- command
-- exit status
-- JUnit report path
-- artifact directory
-- device/platform/app build
-- skipped reason
-- validation assets protected
-- residual risk
-
-`maestro-audit` report must include:
-
-- flow inventory
-- scenario source matrix
-- Maestro run matrix
-- artifact evidence
-- `MST-*` findings or explicit no-finding evidence
-- execution handoff
-
-`maestro-fix` closure matrix must include:
-
-- selected `MST-*` IDs
-- status: `fixed`, `blocked`, `deferred`, or `skipped`
-- changed files
-- command/artifact evidence
-- skipped reason or `none`
-- JUnit/artifact paths — cite the **on-disk** JUnit report path and artifact directory the run actually produced, never a remembered or expected path
-- validation assets protected
-- residual risk
-
-## Discrimination Sensor (Flow Mutation)
-
-The Maestro instantiation of `references/discrimination-sensor.md`: mutate a **scratch copy** of the flow under the claim being verified — perturb a selector (point it at a wrong element) or an assertion (invert or change its expected value) — and confirm the run fails. A run that still passes with a perturbed selector/assertion is not discriminating for that behavior.
-
-Deviation from the generic tier table, stated on purpose: device-backed runs are expensive, so the sensor is a **single lightweight mutation only** — the ≥5-mutation P0 tier does not apply to Maestro flows. Record killed/survived and restore the scratch per the shared reference's isolation rules.
-
-## Routing Boundaries
-
-- Product bugs, missing test IDs, app architecture changes, backend data setup changes, or unclear requirements route to parent workflows.
-- `maestro-fix` may edit only Maestro flows, subflows, fixtures, setup/teardown, test data, or directly scoped Maestro CI/report wiring from a saved `MST-*` finding.
-- Passing Maestro flows do not prove full requirements coverage. Pair run evidence with scenario-source coverage when making all-clear claims.
-
-## Skipped Checks
-
-Allowed skipped/blocker reasons include:
-
-- Maestro CLI unavailable or cannot start
-- app binary/build unavailable
-- device/emulator/simulator unavailable
-- credentials/signing/backend unavailable
-- Cloud auth/plan unavailable
-- target report is stale or invalid
-- official docs or live help do not support requested flag/command
-
-Always state the strongest evidence still collected, such as static YAML validation, path inspection, config scan, or report artifact inspection.

package/skills/massa-ai/references/maestro/selectors.md

@@ -1,91 +0,0 @@
-# Maestro Selectors Reference
-
-Use when choosing or auditing selectors. Official selector index: https://docs.maestro.dev/reference/selectors.md.
-
-## Source Basis
-
-Maestro targets UI through the accessibility tree for mobile and through rendered browser UI for web. Stable selectors are a reliability contract, not a cosmetic choice.
-
-## Core Selectors
-
-| Selector | Use | Notes |
-|---|---|---|
-| `text` | Visible text or accessibility label | Regex by default; brittle under localization/copy churn. |
-| `id` | Android resource ID or iOS accessibility identifier | Preferred for dynamic content, icons, and localized apps. |
-| `index` | Specific occurrence among duplicates | 0-based; pair with stable selector to avoid list drift. |
-| `point` | Relative or absolute coordinates | Last resort when no accessibility target exists. |
-| `css` | Web-only DOM selector | Does not use the same regex behavior as text/id. |
-
-```yaml
-- tapOn:
-    id: login_button
-- assertVisible:
-    text: ".*Welcome.*"
-- tapOn:
-    id: buy_button
-    index: 2
-- tapOn:
-    point: "50%,50%"
-- assertVisible:
-    css: "#main-header"
-```
-
-## Relational Selectors
-
-Relational selectors identify elements by screen position or accessibility hierarchy:
-
-- `above`, `below`, `leftOf`, `rightOf`
-- `containsChild`, `childOf`, `containsDescendants`
-
-```yaml
-- tapOn:
-    text: Delete
-    childOf:
-      id: basket_container
-
-- assertVisible:
-    id: list_item
-    containsDescendants:
-      - text: Wireless Headphones
-      - text: "$99.99"
-```
-
-Position selectors use screen bounds; combine them with `id`, `text`, or state filters when possible.
-
-## Trait, State, And Dimension Filters
-
-Use trait, state, and dimension selectors only when they make an already stable selector more precise:
-
-- Traits: physical characteristics such as shape or long text when official docs support them for the command.
-- State: `enabled`, `checked`, `focused`, `selected`.
-- Dimensions: width/height matchers with tolerance when official docs support them.
-
-```yaml
-- tapOn:
-    id: terms_checkbox
-    checked: false
-
-- assertVisible:
-    id: submit_button
-    enabled: true
-```
-
-## Platform Caveats
-
-- Android Views: `id` maps to resource ID; text may include visible text or content descriptions.
-- Android Compose: configure semantics so test tags become resource IDs when ID selectors are required.
-- iOS UIKit/SwiftUI: `text` maps to accessibility label; `id` maps to accessibility identifier.
-- Flutter: prefer visible text, Semantics labels, or Semantics identifiers; internal Flutter keys are not enough.
-- Web: `css` is web-only; official docs mark web automation as beta and Chromium-based.
-
-## Selector Policy
-
-Prefer this order for new or fixed flows:
-
-1. Existing repo convention and stable test IDs/accessibility identifiers.
-2. Accessible visible labels that are low churn and localized deliberately.
-3. Relational selectors anchored to stable IDs/text.
-4. State/dimension filters to reduce ambiguity.
-5. Coordinates, images, screenshots, or index-only selectors only when no stronger target exists.
-
-If a needed stable selector is missing from production app code, stop and route app changes through `feature`, `debug`, or a parent implementation workflow. Do not modify production code inside `maestro-fix`.

package/skills/massa-ai/references/maestro/workspace-execution.md

@@ -1,81 +0,0 @@
-# Maestro Workspace And Execution Reference
-
-Use when discovering Maestro roots, config files, tags, execution order, suite isolation, and CI invocation.
-
-## Discovery
-
-Search current source for:
-
-- `.maestro/`, `maestro/`, `e2e/`, `flows/`
-- `*.yaml`, `*.yml`
-- `config.yaml`
-- CI or scripts that invoke `maestro`
-- Existing report/artifact paths
-
-Prefer the existing repository root, naming, tags, setup, teardown, fixtures, and artifact directories. If no Maestro workspace exists, ask for the target test root before creating one. If multiple roots exist, ask which root owns the app, platform, or suite.
-
-## `config.yaml`
-
-Official workspace configuration is structured around global workspace settings, execution/filtering, platform settings, and Cloud-only settings.
-
-Key fields:
-
-- `flows`: glob patterns for suite discovery; `*` covers root-level YAML, `**` covers recursive patterns.
-- `testOutputDir`: default artifact directory override for screenshots, logs, and metadata.
-- `includeTags` and `excludeTags`: global tag filters.
-- `executionOrder.continueOnFailure`: whether ordered execution stops after a failure.
-- `executionOrder.flowsOrder`: ordered flow names or filenames.
-- `platform.ios.snapshotKeyHonorModalViews`
-- `platform.ios.disableAnimations` and `platform.android.disableAnimations`: Cloud-only animation settings.
-- `baselineBranch` and `notifications`: Cloud-only configuration.
-
-Report generation is not configured in `config.yaml`; use CLI `--format` and `--output`.
-
-## Tags
-
-Tags live in individual Flow headers and can also be configured globally in `config.yaml`.
-
-```yaml
-appId: com.example.app
-tags:
-  - smoke
-  - checkout
----
-- launchApp
-```
-
-CLI `--include-tags` and `--exclude-tags` override global config filters. Multiple tags inside one include/exclude flag use OR logic. Combining include and exclude applies inclusion first, then exclusion.
-
-## Execution Order And Isolation
-
-Default execution order is non-deterministic so flows stay isolated. Use `executionOrder` only for goal-driven flows that truly need sequencing.
-
-Even ordered flows should be able to run on a reset device. Prefer `runFlow` hooks/subflows for setup rather than relying on previous flow side effects.
-
-```yaml
-executionOrder:
-  continueOnFailure: false
-  flowsOrder:
-    - signup_flow
-    - verify_email_flow
-```
-
-## Local And CI Execution
-
-Use repository wrappers when present. Otherwise prefer:
-
-```bash
-maestro test --format junit --output build/maestro/report.xml --test-output-dir build/maestro/artifacts .maestro
-```
-
-Add `--debug-output build/maestro/debug` when `maestro.log` or JavaScript logs matter. Add `--no-ansi` only when supported by current live help or repo convention.
-
-For local sharding, capture connected devices first. `--shards`, `--shard-all`, and `--shard-split` are local CLI options; do not claim exact device-count failure behavior without official docs, live run evidence, or repo convention.
-
-## Workspace Risks To Audit
-
-- Config discovery misses nested flows because `flows` lacks recursive patterns.
-- Tags configured in both Flow headers and CLI/config produce unexpected selection.
-- Ordered flows depend on prior side effects instead of explicit setup.
-- CI reports are stored in current directory because `--output` is omitted.
-- `testOutputDir`, `--test-output-dir`, and `--debug-output` are treated as the same location when they are not.

package/skills/massa-ai/references/maestro/yaml-commands.md

@@ -1,203 +0,0 @@
-# Maestro YAML Commands Reference
-
-Use when authoring or auditing Maestro flow commands. Official command inventory lives at https://docs.maestro.dev/reference/commands-available.md.
-
-## Flow Header
-
-Flow headers can define target identity and metadata before `---`:
-
-```yaml
-appId: com.example.app
-name: Login Smoke
-tags:
-  - smoke
-env:
-  USER_KIND: standard
-onFlowStart:
-  - runFlow: setup.yaml
-onFlowComplete:
-  - runFlow: cleanup.yaml
-properties:
-  testCaseId: TC-LOGIN-001
----
-- launchApp
-```
-
-For web flows, use `url` instead of `appId`.
-
-## Command Inventory
-
-Official command categories:
-
-- App/device state: `launchApp`, `stopApp`, `killApp`, `clearState`, `clearKeychain`, `setPermissions`, `setAirplaneMode`, `toggleAirplaneMode`, `setOrientation`, `setLocation`, `travel`, `addMedia`.
-- Interactions: `tapOn`, `doubleTapOn`, `longPressOn`, `swipe`, `scroll`, `scrollUntilVisible`, `pressKey`, `back`, `openLink`, `hideKeyboard`.
-- Input/clipboard: `inputText`, `eraseText`, `copyTextFrom`, `setClipboard`, `pasteText`.
-- Flow control: `runFlow`, `runScript`, `evalScript`, `repeat`, `retry`, `extendedWaitUntil`, `waitForAnimationToEnd`, `assertTrue`.
-- Assertions and media: `assertVisible`, `assertNotVisible`, `assertScreenshot`, `takeScreenshot`, `startRecording`, `stopRecording`.
-- AI commands: `assertWithAI`, `assertNoDefectsWithAI`, `extractTextWithAI`.
-
-## App Lifecycle Examples
-
-```yaml
-- launchApp:
-    appId: com.example.app
-    clearState: true
-    clearKeychain: true
-    stopApp: true
-    permissions:
-      camera: allow
-      location: allow
-
-- stopApp: com.example.app
-- killApp: com.example.app
-- clearState: com.example.app
-- clearKeychain
-```
-
-## Interaction Examples
-
-```yaml
-- tapOn:
-    id: submit_button
-    retryTapIfNoChange: true
-
-- tapOn:
-    text: Add to cart
-    rightOf: Product A
-    index: 0
-
-- tapOn:
-    point: "50%,50%"
-
-- tapOn:
-    id: increment_counter
-    repeat: 3
-    delay: 200
-
-- doubleTapOn:
-    id: hero_image
-
-- longPressOn:
-    text: Delete
-
-- swipe:
-    direction: LEFT
-    duration: 400
-```
-
-Use point/coordinate targeting only as a last resort when the element is not available in the accessibility tree.
-
-## Assertions And Waits
-
-```yaml
-- assertVisible:
-    id: login_success_banner
-    enabled: true
-    timeout: 10000
-
-- assertNotVisible:
-    text: Loading
-
-- extendedWaitUntil:
-    visible:
-      id: payment_confirmation
-    timeout: 15000
-
-- waitForAnimationToEnd:
-    timeout: 5000
-```
-
-Prefer observable state waits over fixed sleeps.
-
-## Input And Clipboard
-
-```yaml
-- inputText: "jane.doe@example.com"
-- eraseText: 50
-- copyTextFrom:
-    id: verification_code
-- setClipboard: "123456"
-- pasteText
-- hideKeyboard
-```
-
-## Flow Control
-
-```yaml
-- runFlow:
-    file: login.yaml
-    env:
-      USER_KIND: admin
-    when:
-      visible: Login
-
-- runScript:
-    file: setupUser.js
-    env:
-      role: admin
-
-- repeat:
-    times: 3
-    commands:
-      - tapOn: Add item
-
-- retry:
-    maxRetries: 2
-    commands:
-      - tapOn: Retry
-      - assertVisible: Success
-
-- assertTrue:
-    condition: ${output.total > 0}
-    label: total computed
-```
-
-Conditions commonly use visibility, absence, platform, or JavaScript expressions. Re-check command-specific docs before using uncommon fields.
-
-## Screenshots And Recording
-
-```yaml
-- takeScreenshot: checkout/confirmation
-- assertScreenshot:
-    path: checkout/confirmation
-    thresholdPercentage: 1
-- startRecording: checkout-run
-- stopRecording
-```
-
-When visual artifacts matter, record the artifact directory and whether screenshots/videos came from `--test-output-dir`, `--debug-output`, or `maestro record --local`.
-
-## Device/System Commands
-
-```yaml
-- setLocation:
-    latitude: 37.7749
-    longitude: -122.4194
-- setPermissions:
-    camera: allow
-    location: deny
-- setAirplaneMode: true
-- toggleAirplaneMode
-- setOrientation: LANDSCAPE
-- pressKey: Home
-- back
-- openLink: myapp://checkout
-- addMedia:
-    - ./fixtures/photo.png
-- travel:
-    days: 1
-```
-
-Verify platform support for each command before treating it as portable.
-
-## AI Commands
-
-AI test analysis and AI assertions are experimental and routed through Maestro Cloud infrastructure. Current official docs say users no longer provide their own AI model/key variables; authentication is through `maestro login` or `MAESTRO_CLOUD_API_KEY`.
-
-```yaml
-- assertWithAI: "Verify the success message is in Spanish"
-- assertNoDefectsWithAI
-- extractTextWithAI: "Extract the order number"
-```
-
-Do not add obsolete BYO AI env guidance. If AI is unavailable, mark the check blocked or skipped rather than replacing it with model self-evaluation.

package/skills/massa-ai/references/maestro.md

@@ -1,31 +0,0 @@
-# Maestro Reference Index
-
-Use this small index from `workflows/maestro/maestro.md`, `workflows/maestro/maestro-audit.md`, and `workflows/maestro/maestro-fix.md` to select the minimum focused Maestro reference for the current step. Not the full Maestro source of truth.
-
-## Source Policy
-
-Load `references/maestro/fact-ledger.md` before making any normative Maestro claim. Every Maestro claim must be tagged as `official-doc`, `live-help`, `repo-convention`, or `excluded/unverified`.
-
-Use a user-supplied coverage checklist, when the user provides one, only as a coverage checklist. If a checklist item is not supported by official Maestro docs, live CLI help, or repository convention, quarantine it as `excluded/unverified`.
-
-Official source anchors:
-
-- CLI commands/options: https://docs.maestro.dev/maestro-cli/maestro-cli-commands-and-options.md
-- Commands available: https://docs.maestro.dev/reference/commands-available.md
-- Selectors: https://docs.maestro.dev/reference/selectors.md
-- Workspace configuration: https://docs.maestro.dev/reference/workspace-configuration.md
-- Test reports/artifacts: https://docs.maestro.dev/maestro-flows/workspace-management/test-reports-and-artifacts.md
-- Cloud build requirements: https://docs.maestro.dev/maestro-cloud/build-your-app-for-the-cloud.md
-- Cloud limits: https://docs.maestro.dev/maestro-cloud/limits.md
-- Maestro MCP: https://docs.maestro.dev/get-started/maestro-mcp.md
-
-## Minimum Step Selection
-
-- Flow implementation: load `fact-ledger.md`, `cli-device.md`, then only the focused files for the flow surface being edited: commonly `yaml-commands.md`, `selectors.md`, `workspace-execution.md`, `config-env-output.md`, `js-scripting.md`, and `patterns.md`.
-- Audit: load `fact-ledger.md`, `cli-device.md`, `workspace-execution.md`, `artifacts-reports.md`, `patterns.md`, and `references/audit-report-io.md`.
-- Fix: load `fact-ledger.md`, `cli-device.md`, `artifacts-reports.md`, `patterns.md`, and whichever focused file owns the saved `MST-*` finding.
-- Cloud or MCP work: load `cloud.md` or `mcp.md` only when the requested flow, audit, fix, or CI wiring actually touches that surface.
-
-## Closure Reminder
-
-All Maestro workflow closures must report scenario source, changed flows, setup/teardown, command, exit status, JUnit path, artifact directory, device/platform, skipped reason, validation assets, and residual risk.

package/skills/massa-ai/workflows/general.md

@@ -1,88 +0,0 @@
----
-name: general
-description: "Final fallback workflow for coding, planning, review, or implementation work when no specialized massa-ai workflow is a better match."
-license: MIT
-metadata:
-  version: "1.3.0"
----
-
-### General Coding Workflow
-
-Use for coding, planning-before-coding, review, or implementation work when no specialized massa-ai workflow is a better match. Final fallback, not a replacement for explicit or specialized workflows.
-
-Load `references/project-context.md` (intake sweep) before the first substantive read.
-
-Before the first repository mutation, load `references/implementation-delivery.md` (delivery chain: worktree, atomic commits, PR, CI watch, merge gate) and `references/code-annotation.md` (doc blocks, rationale, test coverage). After two consecutive failed fixes on one symptom, stop editing and load `references/root-cause-scripts.md`.
-
-**Isolation Gate — before the first file edit:** execute `references/implementation-delivery.md` Stage 0–1 now (fetch base, create the worktree + branch, work inside it) and record the worktree path + branch — or one of Stage 1's two legal skip reasons, verbatim — before any repository mutation.
-
-1. Resolve or reuse `projectId` and a stable `workflowSessionId`: `general-[entity]`.
-**Reuse Scan — before writing new implementation code:** run the mandatory reuse scan per `references/code-reuse-scan.md` (separate read-only subagents; the reuse map's use/extend/new decisions are consumed before new code is planned or written) — or record its inline-fallback reason, verbatim.
-
-2. Run General fallback preflight before source work: name the specialized workflow considered, the exact rejected reason, and why fallback does not change verification, mutation behavior, or memory scope. Ask the user only when the rejected workflow would change those behaviors. One delivery authorization obtained here covers the fallback change's commits, push, and PR creation; force-push, deploy, or merge are separately gated (`references/implementation-delivery.md` Stage 3).
-3. Recall relevant durable context with `recall`. Treat recalled memory as a lead until current source confirms it. Confirm against current source before relying on it only when the change touches the enumerated risk-domain set: public API, data loss, auth/PII, migrations, or cross-service contracts. Otherwise trust recalled memory and cite it with a one-line source note. When recall returns no hit and the repository is otherwise unmapped on Standard+ fallback work, run the Minimum Bar sweep from `references/brownfield-mapping.md` first, writing only `CONCERNS.md` and `TESTING.md` into `.specs/project/onboarding/` before continuing.
-4. Create a Synapse session when planned related `search` calls >=2, following `references/synapse-policy.md`.
-5. Load confirmed project lessons through `references/lessons.md` when `.specs/lessons.json` exists:
-   `bun skills/massa-ai/scripts/lessons.ts --root . list --status confirmed`
-   Retrieve only the context required for the goal:
-   - begin with focused local inspection or the shared summary-search sequence
-   - deepen into enriched search, symbols, or exact files only when needed
-   - prefer `read_file` over native Read when symbol metadata + imports are useful (retrieval order per `references/mcp-tools.md`); use `symbol_snippet` for raw code snippets by file + line range
-   - prefer current repository truth over stale or conflicting memories
-6. Execute the requested work using existing repository conventions. Load `references/naming-standards.md` before introducing or renaming identifiers, screens, components, attributes, or implementation-facing names (English-conversion rule applies). Tie verification depth to the Verification Ladder tier table in `references/verification-ladder.md`, sizing the change with `bun skills/massa-ai/scripts/size_change.ts`: Quick runs static + file-integrity checks; Standard adds a named verification recipe and behavioral checks; Spec-driven escalates to `workflows/spec-driven.md`. Do not invent new thresholds; load specialized references only when the task needs their exact contracts.
-   - For analysis that benefits from running code (derived values, data inspection, bulk transforms), call `execute` with `language` and `code` or `batch_execute` with `commands`[] instead of loading raw data into context. Respect the local-dev-only trust model (no untrusted-client exposure).
-   - When the chosen approach leans on an external library's or API's exact behavior, resolve it through the 5-step chain in `references/knowledge-verification-chain.md` (codebase, project docs, Context7, web, flag-uncertain) before committing to that approach — the trigger is the dependence itself, not the task's Quick/Standard/Spec-driven tier.
-7. Use `compress` only when accumulated source or conversation context is reducing execution quality; preserve decisions, constraints, current state, and next steps rather than raw history.
-8. Before completion, if verification found a reusable signal, record it via `references/lessons.md`. Score potential memories using `references/decision-engine.md` when that guidance is not already loaded:
-   `bun skills/massa-ai/scripts/lessons.ts --root . add --feature "<slug>" --signal "<signal>" --source "<ref>" --text "<one terse lesson>"`
-    - remember verified decisions, reusable discoveries, recurring blockers, accepted constraints, and completed outcomes that will save future work
-    - if a recalled memory is stale or needs correction, call `memory_update` with `id` and the new `content` (re-embeds automatically); if a memory is obsolete, call `memory_delete` with `id` (hard-delete, severs graph edges)
-    - for usage insights (search/cache patterns, recent activity), call `analytics` with `type` and `projectId`
-    - skip transient details, raw logs, copied source, unverified hypotheses, and facts already captured in current non-stale memory
-
-**Screen work — before writing or judging any user-facing screen:** when this task creates or modifies a screen, the `massa-ai-designer` dispatch below is mandatory rather than discretionary, carved out of ordinary delegation gating by the Screen Implementation Exception in `references/agent-orchestration.md`. It does not fire when the task touches no screen surface.
-
-> **Dispatch: `massa-ai-designer`** (role: `designer`) — charter `skills/agents/designer/SKILL.md`
-> - scope: the screens, views, components, layouts, styles, and design tokens in this task's UI surface — never the whole repository
-> - permissions: write, scoped to UI-layer files only with a disjoint write set
-> - output: per-element conformance table (element, expected, actual, verdict, severity) plus the UI files written; a missing or unreachable design source is listed as a skipped sensor, never a silent pass
-
-> **Dispatch: `massa-ai-reviewer`** (role: `reviewer`) — charter `skills/agents/reviewer/SKILL.md`
-> - trigger: implementation complete, before the verification gate — never optional
-> - scope: the change's diff surface and its task/AC context
-> - permissions: read-only
-> - inputs: diff, acceptance context, recalled code-quality conventions
-> - sensors: bugs, regressions, missing edge cases, smells introduced by the diff
-> - output: ranked findings, blocking vs advisory; blocking findings become fix items before verification runs
-> - firewall: summarized findings only, never raw diff dumps
-> - memory: suggest-only; main agent persists
-
-> **Dispatch: `massa-ai-verification-agent`** (role: `verification-agent`) — charter `skills/agents/verification-agent/SKILL.md`
-> - trigger: fallback work reaching Standard+ on the Verification Ladder, or any Quick-sized change inside the risk-domain set named in step 3 (public API, data loss, auth/PII, migrations, cross-service) — the Independent Verification Mandate in `references/verification-ladder.md` applies at that gate even when file/LOC counts stay Quick
-> - scope: the fallback change's diff surface plus the acceptance evidence gathered while executing step 6
-> - inputs: diff, the General fallback preflight rationale, reviewer findings, recalled conventions
-> - sensors: independent outcome-vs-request re-check; discrimination sensor per `references/discrimination-sensor.md`, mutating the fallback change's own logic in scratch state
-> - output: PASS/FAIL verdict with per-check evidence recorded in `.specs/quick/NNN-slug/SUMMARY.md`
-> - firewall: summarized findings only, never raw diff dumps
-> - memory: suggest-only; main agent persists general-workflow verification outcomes
-> - fallback: if the subagent is unavailable, run a standalone fresh-eyes re-check of the change against its acceptance evidence and record the skipped-delegation reason
-
-9. At Standard+ size, persist `.specs/quick/NNN-slug/TASK.md` and `SUMMARY.md` using the templates in `references/artifact-persistence.md`, then run `bun skills/massa-ai/scripts/check_specs_delivered.ts <slug> --kind quick` before the Evidence Gate — a non-zero exit blocks completion. If no code-execution tool is available, run the same checks by reading the artifact (graceful degradation preserved).
-10. Complete the Evidence Gate from `references/evidence-gate.md` and report verification, changed artifacts, memory outcome, and residual risk.
-
-## Failure Handling
-
-On any tool/index/MCP failure, follow `references/graceful-degradation.md` (also `SKILL.md` Graceful Degradation).
-
-- `.specs/` directory missing or not writable: block quick-artifact and onboarding-doc writes per `references/artifact-persistence.md`'s unwritable-→-block rule; do not fall back to memory or chat.
-- Verifier fix→re-verify loop reaches the cap in `references/verification-ladder.md`'s Bounded Fix→Re-verify Loop: stop with `Blocked`, preserve the evidence collected, and ask the user for direction.
-
-## Output Contract
-
-- Goal and selected fallback workflow
-- General fallback preflight: considered workflow, rejected reason, and fallback validity
-- Relevant recalled context or explicit cold-start status
-- Work completed and source evidence
-- Verification performed and skipped checks
-- Memory written or intentionally skipped, with reason
-- Residual risk