@massa-ai/cursor-plugin 1.61.0 → 1.62.0

package/skills/massa-ai/references/maestro/config-env-output.md

@@ -1,76 +0,0 @@
-# Maestro Config, Env, And Output Boundaries
-
-Use when deciding whether a fact belongs in a Flow header, `config.yaml`, CLI invocation, report metadata, or artifact output.
-
-## Boundary Matrix
-
-| Surface | Owns | Does not own |
-|---|---|---|
-| Flow header | `appId` or `url`, `name`, `tags`, `env`, hooks, JUnit `properties` | Workspace discovery policy for all flows |
-| `config.yaml` | `flows`, `testOutputDir`, global tags, `executionOrder`, platform config, Cloud notifications/baseline | JUnit/HTML report generation |
-| CLI flags | `--env`, `--config`, `--format`, `--output`, `--test-output-dir`, `--debug-output`, tag overrides, device/platform | Persistent source truth |
-| Report file | JUnit/HTML result selected by `--format` and `--output` | Screenshots/videos/debug logs by default |
-| Artifact dirs | screenshots, videos, `commands-*.json`, AI reports, and optionally `maestro.log` | Test result XML unless explicitly written there by `--output` |
-
-## Flow Header Fields
-
-```yaml
-appId: com.example.app
-name: Checkout Critical Path
-tags:
-  - smoke
-env:
-  REGION: us
-onFlowStart:
-  - runFlow: setup/user.yaml
-onFlowComplete:
-  - runFlow: cleanup/user.yaml
-properties:
-  junitId: TC-CHECKOUT-001
-  junitClassname: com.example.CheckoutE2E
----
-- launchApp
-```
-
-Use `properties` for JUnit metadata. `junitId` and `junitClassname` are reserved report attributes; other properties are emitted as JUnit properties.
-
-## Env Injection
-
-Pass runtime values through CLI or flow/subflow/script env:
-
-```bash
-maestro test -e APP_ID=com.example.android -e USER_KIND=admin flows/login.yaml
-```
-
-```yaml
-- runFlow:
-    file: login.yaml
-    env:
-      USER_KIND: admin
-- runScript:
-    file: setupUser.js
-    env:
-      role: admin
-```
-
-Do not hardcode secrets in YAML. Use repo-approved secret injection, Maestro Cloud secrets, or CI environment variables.
-
-## Output Rules
-
-- `--format junit --output <path>` creates CI-readable JUnit XML.
-- `--format html` or `--format html-detailed` creates HTML reports.
-- `--test-output-dir` stores screenshots, videos, `commands-*.json`, and AI reports.
-- `--debug-output` stores `maestro.log`; when same as `--test-output-dir`, outputs consolidate.
-- config.yaml cannot configure report generation; it can configure `testOutputDir`.
-
-## Closure Evidence
-
-Every Maestro closure should include:
-
-- command and exit status
-- report format and report path
-- `--test-output-dir`
-- `--debug-output` when used or skipped reason
-- app/platform/device
-- environment source, with secrets redacted
-- validation assets protected

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

@@ -1,73 +0,0 @@
-# Maestro Fact Ledger
-
-Use before making Maestro claims. Defines source authority, fact tags, local transcript requirements, and quarantine rules for unsupported checklist items.
-
-## Authority Order
-
-1. `official-doc`: current official Maestro documentation, preferably `.md` pages under `https://docs.maestro.dev/`.
-2. `live-help`: successful local CLI transcript from the installed Maestro binary, including command, exit code, stdout, and stderr.
-3. `repo-convention`: current repository flows, config, CI, scripts, report paths, and existing naming/tag patterns.
-4. `excluded/unverified`: NotebookLM answers, a user-supplied coverage checklist, blog posts, memory, or assumptions that are not confirmed by the first three sources.
-
-If sources conflict, prefer `official-doc` for product behavior and `live-help` for installed CLI syntax. Mention version drift when `live-help` differs from docs.
-
-This Authority Order is the Maestro instantiation of `references/knowledge-verification-chain.md` — `live-help` supersedes generic lookup for installed CLI facts; do not layer the generic chain on top of it.
-
-## Fact Tag Rules
-
-Every normative statement in Maestro workflows, reports, or implementation notes must carry a source class in the agent's working notes:
-
-- `official-doc`: cite the page URL or title.
-- `live-help`: include command, exit code, stdout summary, stderr summary, and Maestro version when available.
-- `repo-convention`: cite local path or command evidence.
-- `excluded/unverified`: name the unsupported claim and do not use it as a requirement, fix direction, or verification gate.
-
-Do not copy long transcripts into final reports. Summarize exact evidence and keep raw logs behind context-firewall boundaries.
-
-## Required Live CLI Transcript Gate
-
-Before using a live CLI fact, capture:
-
-| Probe | Required evidence |
-|---|---|
-| `command -v maestro` | command, exit code, stdout path, stderr |
-| `maestro --version` | command, exit code, stdout version, stderr |
-| `maestro --help` | command, exit code, stdout subcommand/global option summary, stderr |
-| Relevant subcommand help | command, exit code, stdout option summary, stderr |
-
-Run relevant subcommand help for the surface in use: `maestro test --help`, `maestro cloud --help`, `maestro record --help`, `maestro mcp` or supported MCP help shape, and any repo-specific command wrapper.
-
-If PATH cannot resolve `maestro`, mark local CLI validation blocked. If the binary exists but cannot start, record the failure and avoid claiming executable readiness. Do not install Maestro automatically.
-
-## Coverage Checklist Handling
-
-When the user supplies a coverage checklist, use it to ask "did we cover this surface?" Never cite it as source truth, and never assume one exists — if the user supplied none, this section imposes no requirement.
-
-Checklist-only facts that must stay non-normative unless independently verified:
-
-- `maestro query` as a CLI subcommand.
-- Dashboard polling URL or API response shape not found in official docs or Maestro MCP tool metadata.
-- Unsupported flags such as `--flavor`, singular `--shard`, generic `--debug`, or non-web `--headless` when current docs/live help do not support them.
-- Obsolete BYO AI guidance such as `MAESTRO_CLI_AI_KEY` or `MAESTRO_CLI_AI_MODEL`.
-- WSL-specific caveats unless official docs or repo convention explicitly establish them for the target project.
-
-## Current Source Anchors
-
-Use these pages first:
-
-- CLI command matrix: https://docs.maestro.dev/maestro-cli/maestro-cli-commands-and-options.md
-- YAML commands: https://docs.maestro.dev/reference/commands-available.md
-- Selectors: https://docs.maestro.dev/reference/selectors.md
-- Workspace config: https://docs.maestro.dev/reference/workspace-configuration.md
-- Reports/artifacts: https://docs.maestro.dev/maestro-flows/workspace-management/test-reports-and-artifacts.md
-- JavaScript: https://docs.maestro.dev/maestro-flows/javascript/run-and-debug-javascript.md
-- Cloud build: https://docs.maestro.dev/maestro-cloud/build-your-app-for-the-cloud.md
-- Cloud limits: https://docs.maestro.dev/maestro-cloud/limits.md
-- MCP: https://docs.maestro.dev/get-started/maestro-mcp.md
-
-## Failure Handling
-
-- Missing official page: use the docs query interface or `llms.txt`; otherwise tag the fact `excluded/unverified`.
-- Live help blocked by sandbox or permissions: retry only when allowed, then record blocked reason and proceed with official-doc facts only.
-- Repo has no Maestro flows: ask for the target test root before creating one.
-- Repo convention conflicts with official docs: preserve repo behavior for existing suites, but do not generalize it beyond that repository without a source tag.

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

@@ -1,70 +0,0 @@
-# Maestro JavaScript Reference
-
-Use for `evalScript`, `runScript`, inline expressions, generated data, shared state, and JavaScript logging.
-
-## Execution Methods
-
-Maestro supports three JavaScript paths:
-
-1. Inline `${...}` expressions inside YAML command values.
-2. `evalScript` for short logic-only steps.
-3. `runScript` for external `.js` files with reusable or complex logic.
-
-```yaml
-- inputText: ${'User_' + faker.name().firstName()}
-- evalScript: ${output.timestamp = new Date().getTime()}
-- runScript:
-    file: setupUser.js
-    env:
-      role: admin
-```
-
-## Shared State
-
-Use `output` for data shared between scripts and later flow steps.
-
-```yaml
-- evalScript: ${output.email = 'qa_' + Date.now() + '@example.com'}
-- inputText: ${output.email}
-```
-
-Keep output values small and non-secret. Do not put tokens, raw PII, or credentials into logs or artifact reports.
-
-## Script Env
-
-```yaml
-- runScript:
-    file: setupUser.js
-    env:
-      userRole: admin
-```
-
-```javascript
-const role = userRole;
-console.log('Setting up role: ' + role);
-```
-
-## Logging
-
-`console.log` output is captured in `maestro.log` with a JavaScript console prefix. `maestro.log` belongs to `--debug-output`, not `--test-output-dir`, unless both flags point at the same directory.
-
-Limitations from official docs:
-
-- Multiple `console.log` arguments are not supported; concatenate or use template literals in external files.
-- Template literals do not work inside `evalScript` the way they do in external `.js` files because `evalScript` already uses `${...}` syntax.
-
-```yaml
-- evalScript: '${console.log("Value: " + output.email)}'
-```
-
-## When To Use JS
-
-Use JS for:
-
-- generated test data
-- lightweight derived values
-- setup/teardown API calls when the repo already permits them
-- assertions via `assertTrue`
-- reusable selector constants when the repository has that convention
-
-Avoid JS when a native Maestro command is clearer. Keep helpers deterministic and committed with the flow when they are part of the test contract.

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.