@massa-ai/cursor-plugin 1.60.1 → 1.62.0

package/skills/massa-ai/references/audit-report-io.md

@@ -21,12 +21,11 @@ audits/tests/2026-06-15 tests-audit.md
 audits/bugs/2026-06-15 bugs-audit.md
 ```
 
-Parent implementation audits, mobile Figma audits, and Maestro audits use dedicated paths:
+Parent implementation audits and mobile Figma audits use dedicated paths:
 
 ```text
 audits/implementation/<YYYY-MM-DD implementation-audit.md>
 audits/mobile-figma/<YYYY-MM-DD mobile-figma-audit.md>
-audits/maestro/<YYYY-MM-DD maestro-audit.md>
 ```
 
 Judge-with-debate evaluation reports use their own family (no `-audit` suffix — recorded
@@ -333,81 +332,6 @@ Verification Suggestion: <deterministic sensor and optional Maestro reproduction
 
 Only `MISMATCH` comparison rows become `MFM-*` findings. `CONSTRAINT DEVIATION` and `NOT EVALUATED` rows are never silently promoted to executable findings.
 
-## Maestro Audit Report Contract
-
-```md
-# Maestro Audit
-
-Date: <YYYY-MM-DD>
-Workflow: maestro-audit
-ProjectId: <projectId>
-WorkflowSessionId: <maestro-audit-[entity]>
-Target: <Maestro target>
-Target Focus: <flow root, suite, tag, app/module, platform, commit range, branch comparison, or modified files>
-Scope: <scope type from audit-scope.md>
-Git Base: <sha/ref or n/a>
-Git Head: <sha/ref, working-tree, or n/a>
-Source Evidence Timestamp: <YYYY-MM-DD HH:MM local time, or unavailable>
-Scenario Source: <Jira/Confluence, local file, prompt text, explored/inferred behavior, or n/a>
-Maestro CLI: <version/help result or unavailable with reason>
-Device/Emulator Readiness: <command/result or unavailable with reason>
-
-## Flow Inventory
-
-| Flow ID | Path | Suite/Tag | Platform | Setup/Teardown | Scenario Source | Status |
-|---|---|---|---|---|---|---|
-
-## Maestro Run Matrix
-
-| Flow ID | Command | Exit Status | Result | JUnit Report | Artifact Directory | Device/Platform | Skipped-Check Reason |
-|---|---|---|---|---|---|---|---|
-
-## Scenario Coverage Matrix
-
-| Scenario ID | Source | Expected Behavior | Covered Flow ID | Evidence | Gap |
-|---|---|---|---|---|---|
-
-## Findings
-
-### MST-<N>: <short title>
-
-Severity: critical | high | medium | low
-Confidence: high | medium | low
-Flow/Subflow: <flow ID and path>
-Scenario Source: <source identifier>
-Location: <path:line or module>
-Evidence: <concrete source, report, or artifact evidence>
-Impacted Journey: <user journey or release smoke path>
-Flake Or Coverage Risk: <risk class and impact>
-Simplest Fix Direction: <smallest sufficient Maestro flow, fixture, setup, teardown, or test-data change>
-Verification Suggestion: <Maestro command, JUnit report check, artifact inspection, or static check>
-
-## Ruled-Out Candidates
-
-<Plausible candidates disproved by evidence, or "None">
-
-## Scope And Evidence
-
-<Flow roots, scenario sources, commands/searches, exit statuses, JUnit reports, artifact directories, skipped checks, validation assets, and residual risk>
-
-## Verification/Test Fidelity Checklist
-
-| Item | Evidence |
-|---|---|
-| Deterministic sensor | <Maestro command, JUnit report, artifact inspection, static YAML/config scan, or not available with reason> |
-| Result | <pass, fail, not run, or not applicable> |
-| Coverage target | <MST ID, no-finding claim, scenario, flow, behavior, file, or validation asset> |
-| Validation assets protected | <flows, subflows, fixtures, setup/teardown, test data, snapshots, CI report consumers, or none> |
-| Skipped-check reason | <none or allowed skipped-check reason> |
-| Execution handoff | <verification command/artifact and validation assets for every actionable MST finding> |
-
-## Execution Handoff
-
-<Ordered MST IDs, dependencies, likely files, protected validation assets, verification commands, artifact expectations, and cautions>
-```
-
-Only executable flow, fixture, setup/teardown, test-data, or directly scoped Maestro CI/report issues become `MST-*` findings. App bugs, product behavior gaps, backend defects, and unclear requirements must route to `debug`, `feature`, or `requirements-audit` instead of `maestro-fix`.
-
 ## Judge With Debate Report Contracts
 
 Reports produced by `workflows/judge-with-debate.md`. This family is **evaluation-scored, not
@@ -439,7 +363,7 @@ Model Requested: <slot pin: deepseek-v4-pro | minimax-m3 | GLM-5.2>
 Model Note: <fallback state or n/a>
 
 ## Evaluation Specification
-<meta-judge YAML, embedded verbatim once>
+<spec-author YAML, embedded verbatim once>
 
 ## Criterion Scores
 ### <criterion id> — <score>/<scale.max> (weight <w>)
@@ -520,7 +444,6 @@ All findings require severity, confidence, location, concrete evidence, impact,
 | Tests | `Impacted Behavior`, `Regression Risk`, `Simplest Test Direction`, `Deterministic Sensor` |
 | Bugs | `Bug Class`, `Impacted Flow`, `Trigger or Repro Path`, `Root Cause Hypothesis`, `Regression Risk` |
 | Mobile Figma | `Surface ID`, `UI Stack`, `Module/Source Set`, `Element/State`, `Property/Constraint`, `Figma Value`, `Resolved Implementation Value`, `Runtime Evidence`, `Evidence Class`, `Platform Configuration` |
-| Maestro | `Flow/Subflow`, `Scenario Source`, `Impacted Journey`, `Flake Or Coverage Risk` |
 
 If a required field is unknown, write `Unknown` and explain the evidence gap. Execution treats unknown required fields as a stop condition unless the user explicitly accepts the risk after revalidation.
 
@@ -528,7 +451,7 @@ If a required field is unknown, write `Unknown` and explain the evidence gap. Ex
 
 Every report must include project, workflow, target, target focus, scope, git base/head or `n/a`, source evidence timestamp, material files/evidence, commands/searches, skipped checks, and residual risk.
 
-Implementation reports must preserve the exact parent scope packet and source-qualified findings. Mobile Figma reports must also preserve repository classification, Target Surface Matrix, Figma identity/mappings/timestamp, per-surface platform configurations, capability matrix, complete comparison matrix, and optional Maestro reproduction metadata. Maestro reports must preserve scenario source, flow inventory, Maestro run matrix, JUnit report path, artifact directory, device/emulator readiness, and execution handoff for `MST-*` findings.
+Implementation reports must preserve the exact parent scope packet and source-qualified findings. Mobile Figma reports must also preserve repository classification, Target Surface Matrix, Figma identity/mappings/timestamp, per-surface platform configurations, capability matrix, complete comparison matrix, and optional Maestro reproduction metadata.
 
 When implementation-audit uses SonarQube MCP, preserve the MCP availability result, project key or skipped-check reason, quality gate status when available, tool names used, and summarized issue/security-hotspot/measure evidence in Scope And Evidence. Sonar-derived findings are executable only after they are normalized to existing source-qualified IDs for Architecture, Correctness/Bugs, Code Quality, Security, or Tests; unmapped SonarQube output remains evidence only and does not enter Execution Handoff.
 
@@ -540,7 +463,7 @@ Every `*-fix` workflow persists its closure evidence as a Fix Closure Report, a
 audits/<family>/<YYYY-MM-DD <family>-fix-closure>.md
 ```
 
-`<family>` is the source report's directory (`architecture`, `bugs`, `code-quality`, `security`, `requirements`, `tests`, `maestro`, `mobile-figma`, `implementation`). Same local-date and same-day suffix rules as audit reports. Closure reports are output artifacts, **never** audit-report input: any filename containing `-fix-closure` is excluded from latest-report selection.
+`<family>` is the source report's directory (`architecture`, `bugs`, `code-quality`, `security`, `requirements`, `tests`, `mobile-figma`, `implementation`). Same local-date and same-day suffix rules as audit reports. Closure reports are output artifacts, **never** audit-report input: any filename containing `-fix-closure` is excluded from latest-report selection.
 
 Required header lines (same metadata style as audit reports):
 
@@ -574,7 +497,7 @@ Row rules:
 - **Independent Verifier**: verdict plus dispatch-or-fallback record per the verification-ladder Independent Verification Mandate.
 - **Next Step**: required for `blocked` and `deferred` rows.
 
-Family-specific extras (extra columns, parsed by header name, appended after the standard set): requirements adds `Linked .specs/ Requirement ID`; maestro and mobile-figma add `JUnit Report`, `Artifact Directory`, and `Device/Platform`.
+Family-specific extras (extra columns, parsed by header name, appended after the standard set): requirements adds `Linked .specs/ Requirement ID`; mobile-figma adds `JUnit Report`, `Artifact Directory`, and `Device/Platform`.
 
 Deterministic backing (run it, do not eyeball it): `bun skills/massa-ai/scripts/check_fix_closure.ts <closure.md> --family <family>` — a non-zero exit blocks Propose and the Evidence Gate. If no code-execution tool is available, run the same checks by reading the artifact (graceful degradation preserved).
 
@@ -600,7 +523,6 @@ Specialized selection rules:
 
 - `implementation-fix` selects only `audits/implementation/* implementation-audit.md` with `Workflow: implementation-audit`.
 - `mobile-figma-fix` selects only `audits/mobile-figma/* mobile-figma-audit.md` with `Workflow: mobile-figma-audit`.
-- `maestro-fix` selects only `audits/maestro/* maestro-audit.md` with `Workflow: maestro-audit`.
 - Single-lens execution selects only its matching workflow directory and metadata.
 
 Before editing:
@@ -626,13 +548,12 @@ bun skills/massa-ai/scripts/validate_audit_report.ts <path-to-report.md> --famil
 ```
 
 `--family` is one of `architecture`, `bugs`, `code-quality`, `security`,
-`requirements`, `tests`, `maestro`, `mobile-figma`, or `implementation`
+`requirements`, `tests`, `mobile-figma`, or `implementation`
 (auto-detected from the report's `Workflow:` field when omitted). It checks:
 
 - required freshness-header metadata fields for that family (common fields
   plus family-specific extras — `Requirements Source` for single-lens and
-  implementation reports; `Scenario Source`/`Maestro CLI`/`Device/Emulator
-  Readiness` for Maestro; the mobile Figma identity fields for Mobile Figma)
+  implementation reports; the mobile Figma identity fields for Mobile Figma)
 - finding-ID format (`PREFIX-N`, or `<Area>/<PREFIX>-N` for the
   implementation composite family)
 - Area<->Prefix table membership for implementation reports (rejects an
@@ -642,5 +563,5 @@ bun skills/massa-ai/scripts/validate_audit_report.ts <path-to-report.md> --famil
 
 A non-zero exit blocks editing. The script does **not** re-check drift
 against current source, table-structure presence (Target Surface Matrix,
-Maestro Run Matrix, etc.), or Figma-node freshness — those stay a manual
+etc.), or Figma-node freshness — those stay a manual
 step per the "Before editing" list above.

package/skills/massa-ai/references/code-reuse-scan.md

@@ -30,7 +30,7 @@ The scan covers existing:
 Run the scan in one or more separate read-only subagents before new
 implementation code is planned or written:
 
-> **Dispatch: `massa-ai-investigator`** (role: `investigator`) — charter `skills/agents/investigator/SKILL.md`
+> **Dispatch: `code-explorer`** (role: `code-explorer`, mode: `trace`) — charter `skills/agents/code-explorer/SKILL.md`
 > - trigger: planning or writing new implementation code in any of the 16 implementation workflows — mandatory, not optional
 > - scope: the target feature/module area — candidate existing components, helpers, classes, use cases, repositories, and business logic that could satisfy or overlap the new work
 > - permissions: read-only

package/skills/massa-ai/references/{adr-authoring.md → create-adr.md}

@@ -1,10 +1,10 @@
 # ADR Authoring
 
-Use from `workflows/adr.md`. Defines how massa-ai creates Architecture Decision Records without delegating orchestration to another ADR skill.
+Use from `workflows/create-adr.md`. Defines how massa-ai creates Architecture Decision Records without delegating orchestration to another ADR skill.
 
 ## Core Rule
 
-An ADR records a significant architecture decision that is already made or being finalized. If the user is still choosing among options, route to `workflows/rfc.md`. If the user needs implementation design after the decision, route to `workflows/tdd.md`.
+An ADR records a significant architecture decision that is already made or being finalized. If the user is still choosing among options, route to `workflows/create-rfc.md`. If the user needs implementation design after the decision, route to `workflows/create-tdd.md`.
 
 Route matrix:
 
@@ -26,7 +26,7 @@ Prefer sources in this order:
 1. User prompt and explicitly provided Markdown files.
 2. ADR template from Markdown or Atlassian MCP. If absent, ask fallback ADR format/status/supersession questions.
 3. PRD from Markdown or Atlassian MCP when provided. If needed but absent, ask for missing context instead of inventing.
-4. RFC from Markdown or Atlassian MCP when provided. If needed but absent, ask for missing context instead of inventing. If the user does not know, assume the decision is not made and route to `workflows/rfc.md`.
+4. RFC from Markdown or Atlassian MCP when provided. If needed but absent, ask for missing context instead of inventing. If the user does not know, assume the decision is not made and route to `workflows/create-rfc.md`.
 5. Complementary ADR from Markdown or Atlassian MCP when provided. Use it as factual context only for cross-stack constraints, contracts, dependencies, risks, and links.
 6. Same-Stack Example ADR from Markdown or Atlassian MCP when provided. Use it only for format, structure, tone, naming, metadata, and placement conventions; do not use its decision context, rationale, constraints, consequences, or claims as facts for the new ADR.
 7. UI/UX context from Figma MCP when provided and relevant. If Figma is absent, use PRD, RFC, or NotebookLM context. If none exists, ignore UI/UX.

package/skills/massa-ai/references/{rfc → create-rfc}/discovery-and-sizing.md

@@ -8,7 +8,7 @@ Load before source investigation, RFC classification, impact selection, or clari
 - Use ADR when a significant architecture decision is finalized or being formally recorded.
 - Use TDD when the direction is settled and implementation architecture, contracts, rollout, and verification remain.
 - Use spec-driven when the request spans requirements, design, task planning, and implementation.
-- Use a feature, refactor, debug, or general workflow when a durable stakeholder proposal would add no decision value.
+- Use a feature, refactor, or debug workflow when a durable stakeholder proposal would add no decision value.
 
 Route matrix:
 

package/skills/massa-ai/references/{tdd → create-tdd}/calibrated-examples.md

@@ -2,7 +2,7 @@
 
 The values below are starting reference values, not requirements. They are calibration anchors, not mandates. Treat every number as a starting-point reference to be confirmed against the project's own SLOs, load profile, and regulatory scope; override per project and record the override in the TDD. None of these tables restore a prescriptive count schema or a fixed section-count mandate.
 
-Load only when the TDD's conditional concerns (rollback, rollout, latency, compliance) apply and the team needs a concrete starting point. It complements `references/tdd/document-contract.md` (which owns the Conditional Concerns trigger table) by giving example budgets; it does not replace project-verified SLOs or legal obligations.
+Load only when the TDD's conditional concerns (rollback, rollout, latency, compliance) apply and the team needs a concrete starting point. It complements `references/create-tdd/document-contract.md` (which owns the Conditional Concerns trigger table) by giving example budgets; it does not replace project-verified SLOs or legal obligations.
 
 ## Rollback-Trigger Table
 
@@ -16,7 +16,7 @@ Calibration anchors, not mandates. Each row is a starting-point signal that typi
 | Latency regression | p95 latency exceeds 1.5x the pre-rollout p95 for the affected route | rollback (or documented forward-recovery) |
 | Failed dependency | a critical dependency the rollout relies on is confirmed down | rollback (or pause rollout and contain) |
 
-Rollback is not always technically possible; where it is not, the TDD must document forward recovery, containment, restore, or compensating actions instead of falsely promising reversibility (see `references/tdd/document-contract.md`).
+Rollback is not always technically possible; where it is not, the TDD must document forward recovery, containment, restore, or compensating actions instead of falsely promising reversibility (see `references/create-tdd/document-contract.md`).
 
 ## Rollout Percentages Reference
 
@@ -51,4 +51,4 @@ Calibration anchors, not mandates, and not legal advice. Verify applicability pe
 | PCI-DSS | cardholder-data protection, access control, logging, segmentation, vulnerability management | applicability depends on storing, processing, or transmitting cardholder data; confirm scope with security owner |
 | LGPD | legal basis, data-subject rights, purpose limitation, international transfer, DPO accountability | applicability depends on processing Brazil personal data; confirm scope with privacy owner |
 
-This matrix is a starting-point index, not a compliance attestation. Per `references/tdd/document-contract.md`, do not claim compliance from generic controls; identify each applicable obligation as verified, proposed, or unresolved.
+This matrix is a starting-point index, not a compliance attestation. Per `references/create-tdd/document-contract.md`, do not claim compliance from generic controls; identify each applicable obligation as verified, proposed, or unresolved.

package/skills/massa-ai/references/{tdd → create-tdd}/discovery-and-sizing.md

@@ -40,7 +40,7 @@ Never convert an inference or example into a project fact. Omit optional metadat
 - Use RFC when stakeholders still need options compared or the primary direction approved.
 - Use ADR when one significant decision and its consequences need recording without a full implementation blueprint.
 - Use spec-driven when the request spans requirements, design, tasks, and implementation or needs staged approval across those phases.
-- Use feature, refactor, debug, or general for localized work that does not need a durable design artifact.
+- Use feature, refactor, or debug for localized work that does not need a durable design artifact.
 
 TDD readiness checklist:
 

package/skills/massa-ai/references/{tdd → create-tdd}/quality-and-lifecycle.md

@@ -19,7 +19,7 @@ The document is decision-complete only when an implementer can proceed without i
 - Implementation task tables use the exact columns `Order`, `PR Group`, `Layer`, `PR Size`, `Included Work`, `Dependencies`, `Verification Gate`, and `Jira Key` when implementation work is planned.
 - PR groups are independently buildable and testable. Small PRs are preferred, Medium PRs have a dependency or coherence reason, and Large PRs include split, stacked PR, feature-flag, or containment rationale.
 - Non-breaking implementation groups are ordered Data, Domain, then Presentation/Navigation, or the TDD explicitly maps those labels to the repository's actual boundaries.
-- Jira creation remains delegated to `workflows/ticket.md`; `Jira Key` contains only confirmed keys, `Not requested`, `Unavailable`, or `Pending`.
+- Jira creation remains delegated to `workflows/create-ticket.md`; `Jira Key` contains only confirmed keys, `Not requested`, `Unavailable`, or `Pending`.
 - UI/UX-affecting symbol changes include a parallel rendering surfaces and mappers checklist, or explicitly state why none apply.
 - A `Strings Audit` is present when scoped mappers branch on a type and call `stringResource`, or the TDD records evidence that the audit was not applicable.
 - `Decisions Revised During Implementation` is present for living implementation updates.

package/skills/massa-ai/references/{ticket → create-ticket}/intake-and-sources.md

@@ -1,6 +1,6 @@
 # Ticket Intake And Sources
 
-Use from `workflows/ticket.md` before drafting. Gather only missing decisions, keep source roles explicit, and avoid repository-derived ticket conventions.
+Use from `workflows/create-ticket.md` before drafting. Gather only missing decisions, keep source roles explicit, and avoid repository-derived ticket conventions.
 
 ## Ordered Intake
 

package/skills/massa-ai/references/figma-pre-analysis.md

@@ -19,7 +19,7 @@ pass reads one coherent slice.
 
 ## Stage 1 — Pre-Analysis (always first, exactly one subagent)
 
-Dispatch one read-only subagent (investigator-class; Figma MCP — Model Context
+Dispatch one read-only subagent (`code-explorer`, `trace` mode; Figma MCP — Model Context
 Protocol — access, no repository mutation) over the user-provided Figma links.
 Its job: understanding, **not** extraction:
 

package/skills/massa-ai/references/furps/analyst-role.md

@@ -1,4 +1,4 @@
-# Role: furps-analyst
+# Role: product-manager (`furps` mode)
 
 Reusable sub-agent role for `workflows/refinement/furps-refinement.md`. Charter follows `references/subagent-design.md`. Registered in `references/agent-orchestration.md`.
 
@@ -6,7 +6,7 @@ Purpose: analyze exactly one FURPS+ dimension (F, U, R, P, S, or X) of a PRD/ADR
 
 Trigger description:
 - Use when the `furps-refinement` workflow fans out per-dimension analysis and needs isolated context plus independent verification per dimension.
-- Do not use when the work is a one-off local check, needs full conversation history, requires writes, or overlaps another role (use `plan-critic` for The Fool, `investigator`/`verifier` for code claims).
+- Do not use when the work is a one-off local check, needs full conversation history, requires writes, or overlaps another role (use `judge` in `plan-critique` mode for The Fool, `code-explorer`/`code-reviewer` for code claims).
 
 Permissions:
 - Default: read-only.
@@ -15,7 +15,7 @@ Permissions:
 Context inputs:
 - exact `projectId`
 - exact parent `workflowSessionId` and a child session tag; an ephemeral Synapse session only if the role performs >=2 `search` calls
-- workflow name (`furps-refinement`) and role name (`furps-analyst`)
+- workflow name (`furps-refinement`) and role name (`product-manager`, `mode: furps`)
 - assigned dimension letter and its `references/furps/checklist.md` section
 - bounded document packet (sections/summaries, DoR, recalled facts, Fool summary)
 - exclusions: other dimensions (flag, do not expand), sibling-workflow targets

package/skills/massa-ai/references/furps/checklist.md

@@ -1,6 +1,6 @@
 # FURPS+ Refinement Checklist
 
-Use from `workflows/refinement/furps-refinement.md` when analyzing a PRD and/or ADR against the FURPS+ quality model. One `furps-analyst` sub-agent loads only its assigned dimension section; the main agent loads the full file only when synthesizing or when no dimension split is used.
+Use from `workflows/refinement/furps-refinement.md` when analyzing a PRD and/or ADR against the FURPS+ quality model. One `product-manager` sub-agent in `furps` mode loads only its assigned dimension section; the main agent loads the full file only when synthesizing or when no dimension split is used.
 
 ## Source
 
@@ -89,4 +89,4 @@ Non-functional requirements beyond the five core ("+").
 
 ## Cross-dimension note
 
-Some concerns span dimensions (e.g., error flows touch F3+R2+U1; components touch F2+S2). A `furps-analyst` may flag a cross-dimension concern in its findings, but must not expand its scope into another dimension. The main agent deduplicates and reconciles cross-dimension concerns during synthesis.
+Some concerns span dimensions (e.g., error flows touch F3+R2+U1; components touch F2+S2). A `product-manager` dispatch may flag a cross-dimension concern in its findings, but must not expand its scope into another dimension. The main agent deduplicates and reconciles cross-dimension concerns during synthesis.

package/skills/massa-ai/references/furps/intake.md

@@ -18,7 +18,7 @@ A run may combine sources (e.g., a Jira PRD epic + a Confluence ADR). Record eve
 
 ## Atlassian MCP (read-only capability discovery)
 
-This workflow only reads from Atlassian; it never creates issues or pages. Reuse the capability-discovery pattern from `references/ticket/atlassian-fix.md`:
+This workflow only reads from Atlassian; it never creates issues or pages. Reuse the capability-discovery pattern from `references/create-ticket/atlassian-fix.md`:
 
 1. Inspect currently callable tools.
 2. Identify Atlassian MCP operations by capability and schema, not by provider-specific function name. Needed capabilities: Jira issue retrieval and Confluence page retrieval.
@@ -68,9 +68,9 @@ The main agent builds one packet reused across sub-agents:
 
 ## Sub-agent packet contracts
 
-### plan-critic (The Fool) — evidence_audit
+### judge `plan-critique` (The Fool) — evidence_audit
 
-- role: `plan-critic`; mode: `evidence_audit`
+- role: `judge`; mode: `plan-critique`; depth: `full`; fool_mode: `evidence_audit`
 - purpose: grade whether the PRD/ADR claims are source-backed, complete, falsifiable
 - scope: the document as the challenged thesis
 - permissions: read-only
@@ -80,9 +80,9 @@ The main agent builds one packet reused across sub-agents:
 - firewall: summarize the document; no raw dumps
 - memory: suggest only
 
-### plan-critic (The Fool) — pre_mortem
+### judge `plan-critique` (The Fool) — pre_mortem
 
-- role: `plan-critic`; mode: `pre_mortem`
+- role: `judge`; mode: `plan-critique`; depth: `full`; fool_mode: `pre_mortem`
 - purpose: anticipate execution-phase failures of the proposed solution
 - inputs: document packet, DoR, recalled facts, AND the evidence_audit summary
 - output: Fool critique contract, focused on failure narratives
@@ -90,9 +90,9 @@ The main agent builds one packet reused across sub-agents:
 
 Dispatch `pre_mortem` after `evidence_audit` returns, so it can build on identified gaps.
 
-### furps-analyst — one per dimension (F, U, R, P, S, X)
+### product-manager `furps` — one per dimension (F, U, R, P, S, X)
 
-- role: `furps-analyst`; dimension: `<letter>`
+- role: `product-manager`; mode: `furps`; dimension: `<letter>`
 - purpose: analyze one FURPS+ dimension against its checklist section
 - scope: the assigned dimension's check items only
 - permissions: read-only

package/skills/massa-ai/references/hook-enforcement.md

@@ -64,7 +64,6 @@ absent, it falls back to the flat evidence matrix (graceful degradation).
 | `bugs-fix` | verification-fix gate |
 | `code-quality-fix` | verification-fix gate |
 | `implementation-fix` | verification-fix gate |
-| `maestro-fix` | verification-fix gate |
 | `mobile-figma-fix` | verification-fix gate |
 | `requirements-fix` | verification-fix gate |
 | `security-fix` | verification-fix gate |
@@ -78,23 +77,20 @@ absent, it falls back to the flat evidence matrix (graceful degradation).
 | `bugs-audit` | flat evidence matrix |
 | `code-quality-audit` | flat evidence matrix |
 | `implementation-audit` | flat evidence matrix |
-| `maestro-audit` | flat evidence matrix |
 | `mobile-figma-audit` | flat evidence matrix |
 | `requirements-audit` | flat evidence matrix |
 | `security-audit` | flat evidence matrix |
 | `tests-audit` | flat evidence matrix |
 | `furps-refinement` | flat evidence matrix (findings-only; report written + DoR coverage gaps listed) |
-| `adr` | flat evidence matrix |
+| `create-adr` | flat evidence matrix |
 | `commit` | flat evidence matrix |
 | `design` | flat evidence matrix |
-| `general` | flat evidence matrix |
 | `long-session` | flat evidence matrix |
-| `maestro` | flat evidence matrix |
 | `onboarding` | flat evidence matrix |
-| `rfc` | flat evidence matrix |
-| `tdd` | flat evidence matrix |
+| `create-rfc` | flat evidence matrix |
+| `create-tdd` | flat evidence matrix |
 | `the-fool` | flat evidence matrix |
-| `ticket` | flat evidence matrix |
+| `create-ticket` | flat evidence matrix |
 
 ## massa-ai Dual-Write / Tag Contract
 

package/skills/massa-ai/references/implementation-delivery.md

@@ -65,14 +65,14 @@ worktree was never provisioned is an environment failure; say so rather than
 reporting it as a code failure.
 
 **Phased work — one branch per Phase/Wave.** When the work is phased (sourced
-from `workflows/ticket.md`, a spec-driven `tasks.md` with Phases/Waves, a TDD
+from `workflows/create-ticket.md`, a spec-driven `tasks.md` with Phases/Waves, a TDD
 PR-group table, or a `references/pr-task-fix.md` PR-group split), create
 **one branch per Phase/Wave**, not one branch per task
 and not one branch for the whole feature. All Phases/PR groups of one feature
 share that feature's single Stage 3 delivery authorization — one go-ahead
 covers every group's commits, pushes, and PR creation. Name the branch with the phase's Jira
 Task key, e.g. `feat/<PHASE-KEY>-<slug>` (so `feat/SA-100-phase-1-search-split`
-for phase SA-100). The phase key comes from `workflows/ticket.md` or the user.
+for phase SA-100). The phase key comes from `workflows/create-ticket.md` or the user.
 Each Task inside the phase is then one atomic commit on that branch, prefixed
 with its own sub-task key — the commit contract is owned by
 `workflows/commit.md`; do not restate it here. Non-phased work keeps the

package/skills/massa-ai/references/knowledge-verification-chain.md

@@ -22,4 +22,3 @@ Step 2 reads whatever project documentation the target repository actually has;
 ## Family Instantiations
 
 - **Requirements family:** the audit report's cited Requirement Source may be treated as Step 0 — the authoritative anchor the rest of the chain verifies implementation facts against. Step 0 answers *what was required*; Steps 1-5 still govern *how the code behaves*.
-- **Maestro:** `references/maestro/fact-ledger.md`'s Authority Order is the Maestro instantiation of this chain (official-doc → live-help → repo-convention → excluded/unverified). Do not layer the generic chain on top of it.

package/skills/massa-ai/references/mobile-context.md

@@ -7,9 +7,6 @@ Mobile is a context modifier, not a primary workflow. Keep the selected workflow
 - New capability -> `workflows/feature.md`
 - Behavior-preserving structure change -> `workflows/refactor.md`
 - Broken behavior, crashes, regressions, or device-specific failures -> `workflows/debug.md` plus `references/mobile-diagnosis.md`
-- New Maestro mobile E2E flow implementation -> `workflows/maestro/maestro.md`
-- Findings-only Maestro mobile E2E audit -> `workflows/maestro/maestro-audit.md`
-- Child-only fix for saved Maestro audit findings -> `workflows/maestro/maestro-fix.md`
 - Findings-only test coverage review -> `workflows/tests/tests-audit.md`
 - Fix findings from a tests audit report -> `workflows/tests/tests-fix.md`
 - Direct Android Views/Compose, UIKit/SwiftUI, or KMP Compose Multiplatform implementation from Figma or screenshot context -> `workflows/design.md`
@@ -19,11 +16,11 @@ Mobile is a context modifier, not a primary workflow. Keep the selected workflow
 - Fix findings from a security audit report -> `workflows/security/security-fix.md`
 - Broad, cross-boundary, unclear, or multi-platform implementation -> `workflows/spec-driven.md`
 
-Maestro is a first-class mobile E2E workflow family when the primary target is flow implementation, existing-flow audit, or saved `MST-*` remediation. Generic test coverage, assertion quality, or regression-risk review still belongs to `workflows/tests/tests-audit.md` or `workflows/tests/tests-fix.md` when the target is not Maestro-specific.
+Mobile E2E test coverage, assertion quality, flakiness, or regression-risk review belongs to `workflows/tests/tests-audit.md` or `workflows/tests/tests-fix.md`, whatever the E2E tool.
 
 ## Design-Source Intake Gate
 
-Use this gate for `feature`, `spec-driven`, `rfc`, `adr`, and `tdd` workflows when the target is Android, iOS, KMP Compose Multiplatform UI, or plausibly mobile UI. Clear backend, CLI, docs, infrastructure, or non-UI work skips the gate entirely.
+Use this gate for `feature`, `spec-driven`, `create-rfc`, `create-adr`, and `create-tdd` workflows when the target is Android, iOS, KMP Compose Multiplatform UI, or plausibly mobile UI. Clear backend, CLI, docs, infrastructure, or non-UI work skips the gate entirely.
 
 - Ask once for one or more Figma links, node IDs, a readable desktop selection, supplied screenshots, or explicit `none`. Treat `none` as a first-class answer: record `Figma Source: none by user choice` and do not re-ask unless the mobile UI scope changes.
 - When Figma sources or screenshots are supplied for supported Android, iOS, or KMP Compose Multiplatform UI implementation/update work, keep the parent workflow as the lifecycle owner and invoke `workflows/design.md` only for the affected UI slice or visual feasibility context. Preserve mobile Figma routing by intent: compare/audit wording uses `workflows/mobile-figma/mobile-figma-audit.md`; saved `MFM-*` findings use `workflows/mobile-figma/mobile-figma-fix.md`.

package/skills/massa-ai/references/pr-task-fix.md

@@ -44,7 +44,7 @@ If stacked branching is declined, unavailable, or not applicable, continue seque
 
 ## Jira-Key Stacked Branches
 
-After the PR groups are stable, inspect their Jira keys. Offer stacked branch automation only when every PR group has a confirmed Jira key. Do not create Jira tickets from this reference; ticket creation remains owned by `workflows/ticket.md`.
+After the PR groups are stable, inspect their Jira keys. Offer stacked branch automation only when every PR group has a confirmed Jira key. Do not create Jira tickets from this reference; ticket creation remains owned by `workflows/create-ticket.md`.
 
 If every group has a Jira key, ask whether the user wants to automatically create separate stacked branches for each Jira task. If the user accepts, ask for:
 

package/skills/massa-ai/references/spec-driven/sub-agents.md

@@ -178,7 +178,7 @@ When sub-agents are unavailable (a single agent executing the full feature), use
 
 **Applies only if the harness can assign a model per sub-agent.** If it cannot, ignore this section and run everything on the default model — the workflow is correct either way. The point is to spend high-reasoning capacity where ambiguity and consequence are high, and a faster tier where the work is mechanical, instead of paying top-tier cost uniformly.
 
-massa-ai resolves the actual model per agent through `metadata.model_tier` (`light` / `standard` / `deep`) in each sub-agent's charter (`skills/agents/<name>/SKILL.md`), combined with the host and the active profile in `skills/model-profiles.json` (see `CLAUDE.md` § Agent-harness surface). This section maps role/work characteristics onto that mechanism — it is not a separate free-floating table.
+massa-ai resolves the actual model per agent through the active profile in `skills/model-profiles.json` (see `CLAUDE.md` § Agent-harness surface). Most agents use the profile's per-tool default; some carry per-agent overrides. This section maps role/work characteristics onto that decision framework — it is not a separate free-floating table.
 
 Judge the tier by the work in front of the role, not by the role's title:
 
@@ -189,13 +189,13 @@ Judge the tier by the work in front of the role, not by the role's title:
 | Batch worker — mechanical phase | Entities, DTOs, config, wiring, straightforward CRUD against a settled pattern | `light` / `standard` |
 | Verifier | Adversarial reasoning: designs mutations, re-derives coverage, judges outcome precision | `deep` (always — per the Rules of thumb below) |
 | Specify / Tasks authoring | Structured but judgment-heavy | `standard` / `deep` |
-| Read-only specialist (audit-specialist, context-curator, furps-analyst, investigator, mobile-specialist, navigator, requirements-analyst, reviewer) | No write access — findings, investigation, or review quality is the entire deliverable, with no implementation pass downstream to catch a missed nuance | `deep` (always — per the Rules of thumb below) |
-| Scoped writer (designer, documentation-agent, judge, test-engineer) | `permission: write`, narrowed by the charter's own Restrictions to one file class — UI-layer / doc / the agent's own report / test files — each with a disjoint write set. Not read-only, so the deep-tier rule below does **not** reach them | per the work, not per the permission |
+| Read-only specialist (code-explorer, code-reviewer, product-manager) | No write access — findings, investigation, or review quality is the entire deliverable, with no implementation pass downstream to catch a missed nuance | `deep` (always — per the Rules of thumb below) |
+| Scoped writer (designer, judge, test-engineer) | `permission: write`, narrowed by the charter's own Restrictions to one file class — UI-layer / the agent's own report / test files — each with a disjoint write set. Not read-only, so the deep-tier rule below does **not** reach them | per the work, not per the permission |
 
 **Rules of thumb:**
 
 - When unsure, size up, not down. An under-powered worker on ambiguous logic produces gaps the Verifier then has to catch — more expensive than paying for reasoning once.
-- **The Verifier always runs on the deepest tier** — per project rule, `skills/agents/verification-agent/SKILL.md` pins `metadata.model_tier: deep`, structurally, not just as advisory guidance here. A weak Verifier defeats the author ≠ verifier gate.
-- **Read-only specialists always run on the deepest tier** — this generalizes the Verifier rule: every findings-only or investigation-only charter (`permission: read-only`) pins `metadata.model_tier: deep` structurally, because there is no later implementation pass to catch what a weaker read-only pass missed.
+- **The Verifier always runs on the deepest tier** — in built-in profiles, `code-reviewer` (whose `verify` mode is the Verifier) carries no per-agent override and resolves to the profile's strongest model. A weak Verifier defeats the author ≠ verifier gate.
+- **Read-only specialists always run on the deepest tier** — this generalizes the Verifier rule: in built-in profiles, every findings-only or investigation-only charter (`permission: read-only`) carries no per-agent override and resolves to the profile's strongest model, because there is no later implementation pass to catch what a weaker read-only pass missed. **Accepted risk:** user overlays via the Web UI Model Catalog can choose a weaker default; the UI help text documents this convention.
 - Set the tier per batch, from that batch's phases. A feature can mix tiers across batches.
 - Outside the Verifier's and read-only specialists' structural pins, this table is advisory metadata only — no gate, commit, or verification step depends on it.

package/skills/massa-ai/references/spec-driven/validate.md

@@ -180,7 +180,7 @@ Fix tasks follow the same format as regular tasks and can be executed with the i
 
 After all checks complete, the Verifier MUST:
 
-1. **Write the persisted report** to `.specs/features/<slug>/validation.md` (see template below). This file is the evidence artifact — it survives the session and can be referenced by CI, reviewers, or future agents. Record in `.specs/project/STATE.md` (Decisions) that validation evidence is available at that path.
+1. **Write the persisted report** to `.specs/features/<slug>/validation.md` (see template below). This file is the evidence artifact — it survives the session and can be referenced by CI, reviewers, or future agents. It is the only file the Verifier writes (the `code-reviewer` `verify` carve-out); the orchestrator records in `.specs/project/STATE.md` (Decisions) that validation evidence is available at that path.
 2. **Return a compact summary in chat** to the orchestrator (see Compact Chat Summary section below). The orchestrator surfaces it to the user and routes any ranked gaps to fix tasks.
 
 **Deterministic backing (run it, do not eyeball it):** after writing the report, run `bun skills/massa-ai/scripts/validate_state.ts <feature> [--root .]`. It confirms the report is real — present, verdict filled to PASS, and backed by at least one `file:line` evidence citation — so a missing, hollow, placeholder, or FAIL report cannot slip through as done. A non-zero exit means the feature is NOT done: repair the report or route the FAIL gaps to fix tasks, then re-run. This is the closing gate of Execute and runs automatically, the same way the lessons layer runs at distillation — never a manual step. If no code-execution tool is available, run the same checks by reading the artifact (graceful degradation preserved).

package/skills/massa-ai/references/subagent-design.md

@@ -81,6 +81,9 @@ Output contract:
 - Risks and skipped checks
 - Exact next step
 
+Modes (only when the role owns more than one output contract):
+- One `### Mode: <name>` section per contract (the name in backticks), holding that mode's own output; the packet `mode` field selects it.
+
 Validation sensors:
 - [tests, build, typecheck, lint, static search, artifact inspection, or source-location proof]
 
@@ -97,24 +100,18 @@ sets drift into three diverging shapes before the canonical section existed. Whe
 workflow dispatches a reusable role, send that canonical packet, not a loose
 instruction.
 
-The one field this reference still names on its own is `persona`, because a
-persona-agent-boundary guard (`.specs/features/persona-agent-boundary/spec.md`)
-checks its clause byte-for-byte in every packet-defining file, this one included:
-
-`persona`: optional. The cataloged persona id in effect for the parent conversation, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions. Pass the id alone, never the persona prompt.
-
 Design-time additions this reference owns: a new role's charter must be expressible
 as that packet (if a role needs fields the canonical list cannot carry, the role is
 mis-scoped — split it or fix the charter, do not grow a bespoke packet silently), and
-any deliberate bespoke specialization (judge panel, FURPS analyst, phase-batch
-worker) must declare itself a specialization in its own workflow file and map its
+any deliberate bespoke specialization (judge panel, FURPS `product-manager` fan-out,
+phase-batch worker) must declare itself a specialization in its own workflow file and map its
 fields onto the canonical ones from `agent-orchestration.md`.
 
 ## Quality Checklist
 
 Before adding or revising a reusable role:
 
-- One responsibility; no generic "helper" roles.
+- One responsibility; no generic "helper" roles. A role that absorbs another keeps every former output contract behind its own `Mode:` section rather than dropping one.
 - Trigger description names when to use it and when not to use it.
 - Scope can be represented as a bounded capability packet.
 - Read-only by default; write permissions require disjoint ownership and verification.

package/skills/massa-ai/references/synapse-policy.md

@@ -44,7 +44,7 @@ Config knobs (env, read by the server, not by the agent):
 |---|---|---|
 | `SYNAPSE_ENABLED` | `true` | Master kill switch; `false` bypasses the whole pipeline, and `search` behaves statelessly even when a `sessionId` is passed. |
 | `SYNAPSE_ATTENTION_ENABLED` | `false` | Multi-signal attention re-ranker. **Off by default** — do not attribute re-ranking to Synapse unless it is on. |
-| `LOG_LEVEL` | `info` | `debug` emits one pipeline log line per query (see Reading Pipeline Output). |
+| `MASSA_AI_LOG_LEVEL` | `info` | `debug` emits one pipeline log line per query (see Reading Pipeline Output). |
 
 ## MCP-First Lifecycle
 
@@ -103,7 +103,7 @@ optional. REST prefetch requires `filePath` and may include `symbols`, `chains`,
 
 ## Reading Pipeline Output
 
-With `LOG_LEVEL=debug`, the server emits one structured line per Synapse-scoped
+With `MASSA_AI_LOG_LEVEL=debug`, the server emits one structured line per Synapse-scoped
 query. Use it to decide whether Synapse is helping or whether the query needs
 refining — not as evidence about the codebase.
 

package/skills/massa-ai/references/verification-ladder.md

@@ -50,10 +50,10 @@ Every `*-fix` workflow must execute this gate for each selected finding or coher
 
 ### Independent Verification Mandate (author ≠ verifier)
 
-- At **Standard+ or Spec-driven size, or for any high/critical-severity finding**, dispatching `massa-ai-verification-agent` is **mandatory** before closure — the author must not be the sole verifier of their own work. At Quick size, the subagent hop may be skipped, but the check itself is never skipped: run a standalone fresh-eyes re-check (re-read the finding/ACs, changed files, tests, and diff from scratch) against the same output contract.
+- At **Standard+ or Spec-driven size, or for any high/critical-severity finding**, dispatching `code-reviewer` in `verify` mode is **mandatory** before closure — the author must not be the sole verifier of their own work. At Quick size, the subagent hop may be skipped, but the check itself is never skipped: run a standalone fresh-eyes re-check (re-read the finding/ACs, changed files, tests, and diff from scratch) against the same output contract.
 - **Exception — `security-fix` dispatches the verifier unconditionally** for every finding closed `fixed`, at every tier.
 - Fallback discipline: when the subagent is unavailable (not registered, spawning forbidden), run the standalone fresh-eyes re-check from scratch and record the skipped-delegation reason in closure evidence.
-- Reviewer + verifier both dispatching at Standard+ is intentional cost, mirroring spec-driven's always-on pair — not accidental duplication.
+- `code-reviewer` in `review` and in `verify` mode both dispatching at Standard+ is intentional cost, mirroring spec-driven's always-on pair — not accidental duplication.
 
 ### Discrimination Sensor