@massa-ai/codex-plugin 1.61.0 → 1.62.0

package/skills/massa-ai/references/agent-orchestration.md

@@ -75,19 +75,19 @@ Keep local when any are true:
 
 ## Plan Challenge Exception
 
-Plan Challenge `plan-critic` is a standing policy exception to the normal dispatch triggers after a concrete plan exists. Always attempt a read-only `massa-ai-plan-critic` for both `depth: lite` and `depth: full` when subagent tooling is available and platform policy permits spawning. Normal base requirements still matter for packet quality: the critique must be bounded, read-only, and concrete, but it does not need to satisfy the ordinary dispatch triggers such as file count, module count, or explicit user delegation.
+The Plan Challenge `judge` dispatch in `plan-critique` mode is a standing policy exception to the normal dispatch triggers after a concrete plan exists. Always attempt it for both `depth: lite` and `depth: full` when subagent tooling is available and platform policy permits spawning. Normal base requirements still matter for packet quality: the critique must be bounded, write nothing, and be concrete, but it does not need to satisfy the ordinary dispatch triggers such as file count, module count, or explicit user delegation.
 
 For all other roles, preserve the normal delegation gates above.
 
 ## Independent Verification Exception (fix workflows + Standard+ light-workflow tiers)
 
-The Independent Verification Mandate in `references/verification-ladder.md` is a second standing policy exception, parallel to the Plan Challenge one: when a `*-fix` workflow closes a finding, or a light workflow (`debug`, `feature`, `general`, `refactor`) completes Standard+ work, always attempt the `massa-ai-verification-agent` dispatch when subagent tooling is available and platform policy permits spawning — it does not need to satisfy the ordinary dispatch triggers (file count, module count, explicit user delegation). Base packet-quality requirements still apply, and the mandate's own tier gates, security-fix unconditional rule, and fresh-eyes fallback live in that ladder section, not here.
+The Independent Verification Mandate in `references/verification-ladder.md` is a second standing policy exception, parallel to the Plan Challenge one: when a `*-fix` workflow closes a finding, or a light workflow (`debug`, `feature`, `refactor`) completes Standard+ work, always attempt the `code-reviewer` dispatch in `verify` mode when subagent tooling is available and platform policy permits spawning — it does not need to satisfy the ordinary dispatch triggers (file count, module count, explicit user delegation). Base packet-quality requirements still apply, and the mandate's own tier gates, security-fix unconditional rule, and fresh-eyes fallback live in that ladder section, not here.
 
 ## Screen Implementation Exception (any workflow that can produce a screen)
 
-A third standing policy exception, parallel to the two above: **when a task creates or modifies a user-facing screen, always attempt the `massa-ai-designer` dispatch** while subagent tooling is available and platform policy permits spawning. Once that condition holds the dispatch is not subject to the ordinary dispatch triggers — not file count, not module count, not explicit user delegation.
+A third standing policy exception, parallel to the two above: **when a task creates or modifies a user-facing screen, always attempt the `designer` dispatch** while subagent tooling is available and platform policy permits spawning. Once that condition holds the dispatch is not subject to the ordinary dispatch triggers — not file count, not module count, not explicit user delegation.
 
-The condition is the whole gate. On a task with no screen surface the dispatch does not fire at all, which is why the seven dispatching workflows can carry it without firing it on every task. "Creates or modifies a user-facing screen" means a change to a screen, view, page, component, layout, style, theme, or design-token file, or any change whose acceptance criteria describe what a user sees.
+The condition is the whole gate. On a task with no screen surface the dispatch does not fire at all, which is why the dispatching workflows can carry it without firing it on every task. The `design`, `mobile-figma-audit`, and `mobile-figma-fix` workflows dispatch it unconditionally, because every task there is screen work. "Creates or modifies a user-facing screen" means a change to a screen, view, page, component, layout, style, theme, or design-token file, or any change whose acceptance criteria describe what a user sees.
 
 Two shape rules follow from the roles involved:
 
@@ -98,16 +98,25 @@ Base packet-quality requirements still apply, and the no-agent fallback below ap
 
 ## Name Resolution
 
-Charters live at `skills/agents/<role>/SKILL.md`. Hosts register every charter
-under the prefixed name `massa-ai-<role>` (Claude, Codex, Cursor, OpenCode all
-use that prefix; `scripts/generate-subagent-artifacts.ts` emits it).
-
-- **Dispatch under the prefixed host name**, never the bare role name. A bare
-  `subagent_type` does not resolve on any supported host.
-- The bare role name is the registry key: use it in memory tags, capability
-  packets, and prose.
-- Every dispatch block in a workflow carries the prefixed name inline so
-  dispatch never depends on this file being loaded.
+Charters live at `skills/agents/<role>/SKILL.md`. Every host registers each
+charter under its bare role name (`scripts/generate-subagent-artifacts.ts` emits
+`<role>.md` / `<role>.toml` with `name: <role>`). Installers tell massa-ai's
+agent files apart from a user's by the `massa-ai-owned` content marker, never
+by name, and never overwrite a same-named agent the user owns.
+
+- **Claude plugin route: dispatch `massa-ai:<role>`.** Plugin agents live in the
+  plugin namespace (the agent list shows them as `massa-ai:<role>`), so the
+  qualified name reaches massa-ai's agent even when the user or the project
+  defines an agent with the same bare name. The always-loaded router states this
+  rule, so dispatch never depends on this file being loaded.
+- **Claude file route, Codex, Cursor, OpenCode: dispatch the bare `<role>`.**
+  These hosts have no agent namespace. Accepted risk: when an installer skipped
+  a same-named agent the user owns (it warns at install time), that user agent
+  receives the dispatch.
+- Dispatch blocks and prose name the bare role; it is also the registry key in
+  memory tags and capability packets.
+- The pre-rename `massa-ai-<role>` names are retired: installers prune them on
+  upgrade, and no workflow dispatches them.
 
 If the named agent is unavailable for any reason — not registered, plugin not
 installed, spawning forbidden by platform policy, or the host returns an unknown
@@ -118,10 +127,10 @@ delegation with its reason in the Evidence Gate.
 ## Model Diversity Fallback
 
 Applies to any charter whose dispatching workflow requests per-invocation model diversity
-at dispatch time (e.g. `judge` — 3 parallel slots; `meta-judge` — one slot).
+at dispatch time (e.g. `judge` in `scorer` mode — 3 parallel slots; `judge` in `spec-author` mode — one slot).
 
-- Read-only agents (judge, meta-judge, audit-specialist, navigator, and others) carry no
-  per-agent model override in the profile and resolve to the profile's per-tool default.
+- Agents without a per-agent model override in the built-in profiles (`code-explorer`,
+  `code-reviewer`, `judge`, `product-manager`) resolve to the profile's per-tool default.
   By convention, the default is the profile's strongest model.
 - The dispatching workflow (e.g. `workflows/judge-with-debate.md`) is the single source
   for the current slot/model assignment, not the charter file.
@@ -138,7 +147,7 @@ Before adding a new reusable role, load `references/subagent-design.md` and writ
 
 **The roster lives in one place: the Agent Table of `skills/AGENTS.md`**, which names
 every shipped specialist with its purpose, trigger, permission, and charter path. Do not
-restate it here. A second roster in this file is what let `judge` and `meta-judge` go
+restate it here. A second roster in this file is what once let the two debate-panel charters go
 undocumented for a whole release with every gate green — the guard checked that the
 charter paths *mentioned* here resolve, which a charter that is never mentioned cannot
 fail.
@@ -149,22 +158,22 @@ resolves to a current agent.
 
 | Legacy role | Current agent | Note |
 |---|---|---|
-| `implementer` | `massa-ai-builder` | renamed |
-| `verifier` | `massa-ai-verification-agent` | renamed; also centralizes the Verification Ladder |
-| `domain-mapper` | `massa-ai-architecture-specialist` | folded in; `lens: domain` |
-| `coupling-auditor` | `massa-ai-architecture-specialist` | folded in; `lens: coupling` |
-| `deepening-architect` | `massa-ai-architecture-specialist` | folded in; `lens: deepening` |
+| `implementer` | `builder` | renamed |
+| `verifier` | `code-reviewer` | folded in; `mode: verify`, which centralizes the Verification Ladder |
+| `domain-mapper` | `code-reviewer` | folded in; `mode: audit`, `lens: architecture`, `sub-mode: domain` (packet field defined in the `code-reviewer` charter Inputs) |
+| `coupling-auditor` | `code-reviewer` | folded in; `mode: audit`, `lens: architecture`, `sub-mode: coupling` |
+| `deepening-architect` | `code-reviewer` | folded in; `mode: audit`, `lens: architecture`, `sub-mode: deepening` |
 
-`investigator`, `plan-critic` and `furps-analyst` kept their own names; every other
-specialist is new and never had a legacy one. Workflows dispatch the current
-`massa-ai-<role>` name through a named dispatch block — the legacy column is traceability
-only, never a dispatch target.
+The charter names retired by the roster consolidation map to current agents in the
+single old→new table of `skills/AGENTS.md`; this file does not repeat it. Workflows
+dispatch the current `<role>` name through a named dispatch block — the legacy column
+is traceability only, never a dispatch target.
 
 ## Capability Packet
 
-**This section is the sole canonical Capability Packet definition.** `references/subagent-design.md` mirrors this list and the root `skills/AGENTS.md` registry points here without restating it. Bespoke packets (judge panel, FURPS analyst, phase-batch worker) are declared specializations that map onto these fields in their own workflow files.
+**This section is the sole canonical Capability Packet definition.** `references/subagent-design.md` mirrors this list and the root `skills/AGENTS.md` registry points here without restating it. Bespoke packets (judge panel, `product-manager` FURPS dispatch, phase-batch worker) are declared specializations that map onto these fields in their own workflow files.
 
-**A subagent inherits nothing from the parent session** — no skills, no personas, no loaded references, no conversation history. Everything the subagent needs is named explicitly in the packet, including the exact reference file paths it must read itself.
+**A subagent inherits nothing from the parent session** — no skills, no loaded references, no conversation history. Everything the subagent needs is named explicitly in the packet, including the exact reference file paths it must read itself.
 
 When dispatching a subagent, send a compact capability packet rather than a loose instruction. Include:
 
@@ -178,11 +187,11 @@ When dispatching a subagent, send a compact capability packet rather than a loos
 - `output`: the exact output contract
 - `firewall`: raw logs, diffs, snapshots, reports, or research that must be summarized
 - `memory`: whether the subagent may suggest memories and who persists them
-- `persona`: optional. The active route's 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. Omit the field when no persona is routed.
 - `next_use`: what the main agent will do with the result
-- `lens`: conditional — `audit-specialist` dispatches only. One of `bugs | architecture | security | requirements | code-quality | performance`.
+- `mode`: conditional — for a charter that declares modes (`code-explorer`, `code-reviewer`, `designer`, `judge`, `product-manager`, `test-engineer`), the `Mode:` section of the charter this dispatch runs.
+- `lens`: conditional — `code-reviewer` `audit` dispatches only. One of `bugs | architecture | security | code-quality | performance`; the requirements lens is `product-manager` `audit` mode and the tests lens is `test-engineer` `audit` mode.
 
-The named dispatch block that workflows embed (the quoted block whose header carries the prefixed agent name and role) is the block projection of this packet: `role` and `purpose` live in the block's header line, and `next_use` defaults to "the main agent synthesizes and continues the workflow" when absent. The remaining eight fields — `trigger, scope, permissions, inputs, sensors, output, firewall, memory` — appear as the block's body lines, except where Role Defaults below already fix a field's value.
+The named dispatch block that workflows embed (the quoted block whose header carries the agent name, role, and mode) is the block projection of this packet: `role`, `mode`, and `purpose` live in the block's header line, and `next_use` defaults to "the main agent synthesizes and continues the workflow" when absent. The remaining eight fields — `trigger, scope, permissions, inputs, sensors, output, firewall, memory` — appear as the block's body lines, except where Role Defaults below already fix a field's value.
 
 ### Role Defaults
 
@@ -196,24 +205,19 @@ Reading a workflow's dispatch block therefore means reading this section beside
 it. That is the trade: the block stops being self-contained in exchange for
 having exactly one place a shared value can be wrong.
 
-**Every role, every dispatch**
+**`code-reviewer`** (every mode)
 
-- `persona` — as defined in the Capability Packet list above. It is never written
-  in a dispatch block; it applies to all of them.
+- `permissions`: read-only
 
-**`massa-ai-reviewer`**
+**`code-reviewer`, `mode: review`**
 
 - `fallback`: if the subagent is unavailable, run a standalone fresh-eyes review against this output contract and record the skipped-delegation reason
 
-**`massa-ai-verification-agent`**
-
-- `permissions`: read-only
-
-**`massa-ai-designer`** — its dispatch is mandatory-on-condition, so its trigger is
+**`designer`** — its dispatch is mandatory-on-condition, so its trigger is
 fixed here rather than per workflow; a block that reworded it would silently make
 the dispatch advisory in that one file.
 
-- `trigger`: the task creates or modifies a user-facing screen — mandatory once that condition holds, per the Screen Implementation Exception in `references/agent-orchestration.md`; it does not fire when no screen surface is touched
+- `trigger`: the task creates or modifies a user-facing screen — mandatory once that condition holds, per the Screen Implementation Exception in `references/agent-orchestration.md`; it does not fire when no screen surface is touched, and the `design`, `mobile-figma-audit`, and `mobile-figma-fix` workflows dispatch it unconditionally
 - `sensors`: Figma MCP read when a design source exists; per-element expected-vs-actual comparison; the UI module's own build/lint; the states a design under-specifies — empty, loading, error, long text, small and large sizes
 - `inputs`: exact `projectId`, parent `workflowSessionId`, Figma links/node ids or screenshots when supplied, acceptance criteria, the repository's existing UI conventions and design tokens, recalled screen patterns
 - `firewall`: summarized design-source evidence and `path:line` pointers only, never raw Figma node dumps or full file bodies
@@ -283,16 +287,16 @@ Example:
 
 ### Model/Effort Announcement
 
-Every dispatch of any of the 18 massa-ai roster specialists names the agent, its model,
+Every dispatch of any of the 7 massa-ai roster specialists names the agent, its model,
 and its effort in the `Agent Started` line above, inside that line's existing 1-2 line
 budget. No exemption: this covers the three standing dispatch exceptions
-(`plan-critic`, `verification-agent`, `designer`) and spec-driven batch workers exactly
+(`judge` in `plan-critique` mode, `code-reviewer` in `verify` mode, `designer`) and spec-driven batch workers exactly
 like every other dispatch.
 
 - **Source**: the *installed* agent file for the active host — never
   `skills/model-profiles.json`. The installed file reports what the host will actually
   load, including any local profile-switch overlay the registry cannot see.
-- **Read once per session**, for all 18 agents, and cache the result — not once per
+- **Read once per session**, for all 7 agents, and cache the result — not once per
   dispatch.
 - Absent `effort` in the installed file announces `effort: inherit`. Absent `model`, or
   `model: inherit`, announces `model: inherit`.
@@ -300,33 +304,33 @@ like every other dispatch.
   exact attempted path, and the dispatch proceeds — the read never blocks a dispatch.
 
 ```md
-🤖 [Agent Started] Investigator — model opus, effort high. Scope: the four emitters.
+🤖 [Agent Started] Code-explorer — model opus, effort high. Scope: the four emitters.
 🤖 [Agent Started] Designer — model/effort unknown (no installed agent file at
-   <liveRoot>/agents/massa-ai-designer.md). Dispatching anyway.
+   <liveRoot>/agents/designer.md). Dispatching anyway.
 ```
 
 That second line is a measured case, not a hypothetical: on a machine with plugin
-bundle `1.48.0` installed, `massa-ai-designer.md` is absent because `designer` shipped
+bundle `1.48.0` installed, `designer.md` is absent because `designer` shipped
 in `1.50.0` — a live instance of the degraded path above.
 
 Per-host installed-agent path, matching `resolveHostLayout` in
 `packages/shared/src/profile-switch/hosts.ts` — a sensor executes that resolver against
 this table so the two cannot drift silently:
 
-| Host | Installed agents directory | Glob | Model / effort keys |
+| Host | Installed agents directory | Owned files | Model / effort keys |
 | --- | --- | --- | --- |
-| Claude — marketplace route | `<marketplaceRoot>/agents`, where `<marketplaceRoot>` is `resolveClaudeMarketplaceInstall`'s live root: for a **directory-source** marketplace the host loads the plugin LIVE from the source bundle — e.g. `<repo>/apps/claude-plugin/agents`; for any other kind it is the *versioned* cache snapshot, e.g. `~/.claude/plugins/cache/massa-ai/massa-ai/1.48.0/agents` (a stale-able snapshot — never hardcode it; read `profile_list`'s `liveRoot`) | `massa-ai-*.md` | `model:` / `effort:` |
-| Claude — file route | `~/.claude/agents` | `massa-ai-*.md` | `model:` / `effort:` |
-| Codex | `~/.codex/agents` | `massa-ai-*.toml` | `model` / `model_reasoning_effort` |
-| OpenCode | `~/.config/opencode/agents` | `massa-ai-*.md` | `model:` / `reasoningEffort:` |
+| Claude — marketplace route | `<marketplaceRoot>/agents`, where `<marketplaceRoot>` is `resolveClaudeMarketplaceInstall`'s live root: for a **directory-source** marketplace the host loads the plugin LIVE from the source bundle — e.g. `<repo>/apps/claude-plugin/agents`; for any other kind it is the *versioned* cache snapshot, e.g. `~/.claude/plugins/cache/massa-ai/massa-ai/1.48.0/agents` (a stale-able snapshot — never hardcode it; read `profile_list`'s `liveRoot`) | `*.md` whose first body line is `<!-- massa-ai-owned: true -->` | `model:` / `effort:` |
+| Claude — file route | `~/.claude/agents` | `*.md` whose first body line is `<!-- massa-ai-owned: true -->` | `model:` / `effort:` |
+| Codex | `~/.codex/agents` | `*.toml` whose first line is `# massa-ai-owned` | `model` / `model_reasoning_effort` |
+| OpenCode | `~/.config/opencode/agents` | `*.md` symlinks into the massa-ai bundle | `model:` / `reasoningEffort:` |
 | Cursor | no lookup — `resolveHostLayout` returns route `skip` | — | announce `model: inherit, effort: inherit` for every agent; Cursor publishes no resolvable model IDs |
 
 Claude's active route (`marketplace` vs `file`) comes from `install-state.json`'s
 per-platform `installRoute` field, never guessed from directory presence.
 
-## Plan-Critic Contract
+## Plan-Critique Contract
 
-Dispatch `massa-ai-plan-critic` only after a concrete plan exists. Dispatch it with the capability packet above and the standard output contract. The subagent receives the plan, scope, constraints, compact recalled facts/evidence, selected depth, selected The Fool mode only for full gates, known risks, verification recipe, parent identifiers, and context-firewall limits. It never receives full conversation context.
+Dispatch `judge` with `mode: plan-critique` only after a concrete plan exists. Dispatch it with the capability packet above and the standard output contract. The subagent receives the plan, scope, constraints, compact recalled facts/evidence, selected depth, `fool_mode` (the selected The Fool mode: `pre_mortem`, `red_team`, `evidence_audit`, `socratic`, or `dialectic`; distinct from the packet `mode`, which stays `plan-critique`) only for full gates, known risks, verification recipe, parent identifiers, and context-firewall limits. It never receives full conversation context.
 
 For `depth: lite`, the packet uses the low-risk checklist and does not include The Fool mode references. It returns:
 
@@ -337,9 +341,9 @@ For `depth: lite`, the packet uses the low-risk checklist and does not include T
 - `escalate_to_full: true|false`
 - escalation reason
 
-For `depth: full`, or after lite escalation, the main agent selects the mode, loads the relevant The Fool references, and dispatches a full packet. It returns:
+For `depth: full`, or after lite escalation, the main agent selects the The Fool mode, loads the relevant The Fool references, and dispatches a full packet carrying it as `fool_mode`. It returns:
 
-- selected mode
+- selected `fool_mode`
 - steelmanned thesis
 - 3-5 strongest challenges
 - severity: `critical`, `high`, `medium`, or `low`
@@ -357,7 +361,7 @@ whose single source is `skills/AGENTS.md` in the product repo.
 
 - Main agent persists durable conclusions after synthesis.
 - Subagents may suggest memory content but should not create broad project memories unless explicitly assigned.
-- Use tags such as `agent:verifier` or `agent:domain-mapper` only when they improve retrieval.
+- Use tags such as `agent:code-reviewer` or `agent:code-explorer` only when they improve retrieval.
 - Do not persist one-off subagent chatter.
 
 ## Synapse Isolation

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.