@massa-ai/codex-plugin 1.61.0 → 1.62.0

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.

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.