@massa-ai/claude-plugin 1.60.1 → 1.62.0

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

package/skills/massa-ai/workflows/maestro/maestro-audit.md

@@ -1,64 +0,0 @@
----
-name: maestro-audit
-description: "Findings-only audit of existing Maestro mobile E2E flows, fixtures, setup/teardown, reports, selector stability, flake risk, and scenario coverage; does not edit code."
-license: MIT
-metadata:
-  version: "1.1.0"
----
-
-### Maestro Audit
-
-Findings-only audit of existing Maestro mobile E2E flows, fixtures, setup/teardown, reports, artifacts, CI invocation, selector stability, flake risk, and scenario coverage.
-
-Load `references/project-context.md` (intake sweep) before the first substantive read.
-
-Do not edit code or flows in this workflow. Not for new flow implementation — route to `workflows/maestro/maestro.md`. Do not fix findings directly; invoke `workflows/maestro/maestro-fix.md` as a bounded child workflow only after a saved audit report or audit handoff exists.
-
-1. Resolve/reuse `workflowSessionId`: `maestro-audit-[entity]`.
-2. Load shared references:
-   - `references/maestro.md` as the index before choosing focused Maestro references.
-   - `references/maestro/fact-ledger.md` before making any Maestro claim; tag facts as `official-doc`, `live-help`, `repo-convention`, or `excluded/unverified`.
-   - `references/maestro/cli-device.md` before CLI checks, device/platform readiness, local sharding, or executable runs.
-   - `references/maestro/workspace-execution.md` before discovering flows, tags, config, CI commands, execution order, or suite isolation.
-   - `references/maestro/artifacts-reports.md` before report/artifact/debug-output, screenshot, video, recording, or AI report claims.
-   - `references/maestro/selectors.md` before selector stability findings.
-   - `references/maestro/config-env-output.md` before env/config/report-output findings.
-   - `references/maestro/cloud.md` only when Cloud execution, Cloud devices, auth/plan, or Cloud artifact evidence is in scope.
-   - `references/maestro/mcp.md` only when Maestro MCP or Viewer evidence is in scope.
-   - `references/maestro/patterns.md` before flake, setup/teardown, coverage, and execution-handoff judgments.
-   - `references/audit-report-io.md` before producing the report.
-   - `references/mobile-context.md` for platform scope, parity, and device/emulator assumptions.
-   - `references/audit-scope.md` for scope packet, budgets, skipped depth checks, and freshness.
-   - `references/context-firewall.md` before large logs, screenshots, videos, JUnit XML, generated artifacts, or broad search output.
-   - `references/synapse-policy.md` when repeated massa-ai searches are expected.
-   - `references/agent-orchestration.md` only for large scopes, explicit parallel/subagent requests, or independent verification of high-impact findings.
-3. Run the mandatory Maestro CLI transcript gate from `references/maestro/cli-device.md` and `references/maestro/fact-ledger.md`: `command -v maestro`, `maestro --version` or `maestro --help`, and relevant subcommand help with command, exit code, stdout, and stderr. If missing or failing, block executable audit runs and produce only a blocked static-readiness report when source inspection is still useful.
-4. Establish the audit target:
-   - Explicit Maestro root, suite, flow file, tag, app/module, platform, branch comparison, commit range, modified files, or whole Maestro workspace.
-   - For omitted target, discover all developed Maestro flows and ask before whole-workspace audit if multiple roots exist.
-5. Resolve expected behavior sources in scenario input order: Jira/Confluence via Atlassian MCP, attached/local file, prompt text, then explored/inferred repository behavior. If no requirements source exists, run `workflows/exploration.md` before comparing behavior and label inferred expectations as inference.
-6. Discover all in-scope Maestro flows, subflows, fixtures, setup/teardown, config, tags, CI commands, report paths, and artifact paths.
-7. Run every existing in-scope Maestro flow when the CLI, app build, device/emulator, credentials, and backend dependencies are available. Use deterministic output:
-   - `maestro test --format junit --output <report.xml> --test-output-dir <artifact-dir> <flow-or-directory>`.
-   - Capture command, exit code, JUnit report, artifact directory, platform/device, app build/flavor, environment, and skipped-check reason.
-8. Compare current flows and run results against supplied or discovered expected behavior:
-   - Scenario coverage and acceptance criteria.
-   - Setup/teardown completeness, data isolation, feature flags, permissions, locale/timezone, cleanup, and app state reset.
-   - Selector/test-ID stability, synchronization, fixed sleeps, coordinates, screenshot/image coupling, brittle text, and flow ordering.
-   - CI report/artifact retention, runtime cost, device assumptions, retry/quarantine behavior, and flake diagnostics.
-9. Produce findings first, ordered by severity. IDs: `MST-<N>`.
-   - Each finding must include severity, confidence, flow/subflow/file location, scenario source, concrete evidence, impacted journey, flake or coverage risk, simplest sufficient fix, and Verification Suggestion.
-   - If no findings are found, say that clearly and list flows, scenarios, commands/artifacts, and skipped checks.
-   - Include the Verification/Test Fidelity Checklist from `references/audit-report-io.md`; tie every `MST-*` finding or no-finding claim to deterministic sensors, commands/artifacts, validation assets, skipped-check reasons, and runtime artifacts. Model judgment alone cannot satisfy verification/testing all-clear.
-10. Save or propose `audits/maestro/<YYYY-MM-DD maestro-audit.md>` using the report contract in `references/audit-report-io.md`. The enriched report must preserve flow inventory, run matrix, scenario coverage, JUnit report path, artifact directory, device/emulator readiness, validation assets, and execution handoff.
-11. Invoke `workflows/maestro/maestro-fix.md` only as a bounded child workflow for failed executable `MST-*` findings when requested or when the parent audit explicitly includes auto-fix handoff. The child may edit only Maestro flows, subflows, fixtures, setup/teardown, and test data.
-12. Persist only durable Maestro conventions, flake classes, selector/test-ID policy, device matrix constraints, or reusable verification recipes after Importance Calibration. Use `workflow:maestro-audit` and required memory tags.
-13. Complete the Evidence Gate from `references/evidence-gate.md`.
-
-## Examples
-
-User asks: "Run a Maestro audit for the checkout suite."
-
-1. Scope to the checkout Maestro root or tag, run CLI/device preflight, and discover expected behavior.
-2. Execute in-scope flows with JUnit report and artifact output when dependencies are available.
-3. Save `audits/maestro/<YYYY-MM-DD maestro-audit.md>` with `MST-*` findings and execution handoff.