@massa-ai/codex-plugin 1.24.0 → 1.26.0

package/install.sh

@@ -78,6 +78,12 @@ PLUGIN_DIR="$CODEX_DIR/plugins/massa-ai"
 HOOKS_JSON="$CODEX_DIR/hooks.json"
 AGENTS_DIR="$CODEX_DIR/agents"
 
+# Model-profile variant tree (T8, design Component 3 / MPS-04). Source is the
+# bundle's per-profile agent-profiles/<p>/ (sibling of agents/, A5); dest is
+# the engine's own host path table: $CODEX_DIR/massa-ai/agent-profiles/<p>/.
+VARIANTS_SRC="$SCRIPT_DIR/agent-profiles"
+VARIANTS_DEST="$CODEX_DIR/massa-ai/agent-profiles"
+
 # Array-append merge (F5 mitigation): for each of the 6 events, append the
 # massa-ai hook entry to the event's array if no entry with
 # _massaAiOwned: true already exists. Backup before first write. Uses node
@@ -299,10 +305,22 @@ if (typeof data.platforms !== "object" || data.platforms === null || Array.isArr
 data.version = 2;
 const prev = data.platforms[host];
 data.platforms[host] = { root, skillsOwner: "plugin", skills: ["massa-ai", "persona-router"] };
-// The whole-record replace must not drop the plugin version record a previous
-// successful install wrote (R2) — re-attach it.
-if (prev && typeof prev === "object" && !Array.isArray(prev) && prev.plugin && typeof prev.plugin === "object") {
-  data.platforms[host].plugin = prev.plugin;
+// The whole-record replace must not drop fields a previous successful install
+// wrote (R2) — re-attach them. modelProfile (T10, MPS-03 round-trip
+// obligation) is engine-owned; installRoute is installer-owned but written by
+// a LATER step of this same install (record_plugin_version) — both must
+// survive this earlier whole-record replace or a switched profile / recorded
+// route silently vanishes on the next skills-bundling pass.
+if (prev && typeof prev === "object" && !Array.isArray(prev)) {
+  if (prev.plugin && typeof prev.plugin === "object") {
+    data.platforms[host].plugin = prev.plugin;
+  }
+  if (prev.modelProfile && typeof prev.modelProfile === "object") {
+    data.platforms[host].modelProfile = prev.modelProfile;
+  }
+  if (typeof prev.installRoute === "string") {
+    data.platforms[host].installRoute = prev.installRoute;
+  }
 }
 fs.mkdirSync(path.dirname(file), { recursive: true });
 fs.writeFileSync(file, JSON.stringify(data, null, 2) + "\n");
@@ -376,18 +394,27 @@ record_plugin_version() {
     return 0
   fi
 
-  local version installed_at
+  local version installed_at route
   version="$(sed -n 's/.*"version"[[:space:]]*:[[:space:]]*"\([^"]*\)".*/\1/p' "$SCRIPT_DIR/package.json" | head -n 1)"
   installed_at="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
+  # installRoute (T8, design F1): installer-owned, engine-read-only. Unlike
+  # Claude, Codex's plugin/marketplace registration (register_codex_plugin) is
+  # ADDITIVE — it only affects /plugins visibility. The agent TOML files
+  # always land in $AGENTS_DIR regardless of whether that registration
+  # succeeds (see the unconditional copy loop below), so Codex has no
+  # "read in place, no local files" mode the way Claude's marketplace route
+  # does — installRoute is unconditionally "file" here, reflecting the one
+  # install shape Codex agents ever take. Written on EVERY install path.
+  route="file"
 
   # Tolerant of a corrupt/missing state file (rewrites a minimal valid one —
   # AC-8). A record-write failure warns but never fails the install: the next
   # run treats the host as unknown-version and reinstalls.
-  "$runner" - "$HARNESS_STATE_FILE" "$HARNESS_HOST" "$CODEX_DIR" "$version" "$installed_at" <<'NODE' || \
+  "$runner" - "$HARNESS_STATE_FILE" "$HARNESS_HOST" "$CODEX_DIR" "$version" "$installed_at" "$route" <<'NODE' || \
     echo "  ⚠ could not record the plugin version — next run will reinstall (unknown version)" >&2
 const fs = require("fs");
 const path = require("path");
-const [, , file, host, root, version, installedAt] = process.argv;
+const [, , file, host, root, version, installedAt, installRoute] = process.argv;
 let data = { version: 2, platforms: {} };
 try {
   const existing = JSON.parse(fs.readFileSync(file, "utf8"));
@@ -404,12 +431,54 @@ const rec =
     ? data.platforms[host]
     : { root, skillsOwner: "plugin", skills: [] };
 rec.plugin = { version, installedAt };
+// installRoute is installer-owned (like plugin above); modelProfile is NEVER
+// written here — the switch engine (packages/shared/src/profile-switch/) is
+// its sole writer, and this installer only ever reads it (see
+// apply_recorded_profile below).
+rec.installRoute = installRoute;
 data.platforms[host] = rec;
 fs.mkdirSync(path.dirname(file), { recursive: true });
 fs.writeFileSync(file, JSON.stringify(data, null, 2) + "\n");
 NODE
 }
 
+# ── Model-profile variant tree + recorded-profile re-apply (T8, MPS-04) ─────
+# Read-side only: this installer never writes platforms[host].modelProfile —
+# see the comment above record_plugin_version's NODE block. It only (a)
+# refreshes the on-disk variant tree so an offline switch has files to copy
+# from, and (b) re-applies a previously recorded profile's active agent set on
+# install/upgrade, so a plugin upgrade never silently reverts a switched
+# profile back to the shipped default.
+install_variant_tree() {
+  [[ -d "$VARIANTS_SRC" ]] || return 0
+  rm -rf "$VARIANTS_DEST"
+  mkdir -p "$VARIANTS_DEST"
+  cp -R "$VARIANTS_SRC/." "$VARIANTS_DEST/"
+  vecho "  + model-profile variant tree refreshed at $VARIANTS_DEST"
+}
+
+# Prints the recorded profile name (platforms[codex].modelProfile.profile), or
+# an empty string when unset/unreadable. Never throws — a corrupt or missing
+# state file just means "no recorded profile", not an install failure.
+recorded_profile() {
+  local runner="$1"
+  "$runner" - "$HARNESS_STATE_FILE" "$HARNESS_HOST" <<'NODE'
+const fs = require("fs");
+const [, , file, host] = process.argv;
+try {
+  const data = JSON.parse(fs.readFileSync(file, "utf8"));
+  const rec = data && data.platforms && data.platforms[host];
+  const profile =
+    rec && rec.modelProfile && typeof rec.modelProfile.profile === "string"
+      ? rec.modelProfile.profile
+      : "";
+  process.stdout.write(profile);
+} catch {
+  process.stdout.write("");
+}
+NODE
+}
+
 # ── Plugin-registry registration (delegated to the codex CLI) ───────────────
 # The CLI owns config.toml's [marketplaces.*] / [plugins."x@y"] tables and the
 # plugins/cache layout, so it is the only supported way to reach /plugins.
@@ -551,9 +620,33 @@ vecho "  + 6 massa-ai hook events wired (array-append, user hooks preserved)"
 # plugin dir — Codex custom agents load from the config-root agents/ dir, not
 # the plugin dir). Each file carries a "# massa-ai-owned" top comment for
 # scoped uninstall (R3: shared agents dir, user agents preserved).
+#
+# Model-profile re-apply (T8, MPS-04): if a switch previously recorded a
+# profile for this host, and the bundle ships that profile's variant, the
+# ACTIVE set comes from agent-profiles/<profile>/ instead of the shipped
+# default — an upgrade must never silently revert a switched profile.
+# Recorded-but-missing-from-bundle is a loud fallback to the default, never a
+# silent one.
 mkdir -p "$AGENTS_DIR"
+ACTIVE_AGENTS_SRC="$SCRIPT_DIR/agents"
+json_runner=""
+if command -v node &>/dev/null; then json_runner="node"
+elif command -v bun &>/dev/null; then json_runner="bun"
+fi
+if [[ -n "$json_runner" ]]; then
+  RECORDED_PROFILE="$(recorded_profile "$json_runner")"
+  if [[ -n "$RECORDED_PROFILE" ]]; then
+    if [[ -d "$VARIANTS_SRC/$RECORDED_PROFILE" ]]; then
+      ACTIVE_AGENTS_SRC="$VARIANTS_SRC/$RECORDED_PROFILE"
+      echo "  ↷ re-applying recorded model profile '$RECORDED_PROFILE'"
+    else
+      echo "  ⚠ recorded model profile '$RECORDED_PROFILE' is not in this bundle — falling back to the default profile" >&2
+    fi
+  fi
+fi
+
 specialist_count=0
-for src in "$SCRIPT_DIR/agents/"massa-ai-*.toml; do
+for src in "$ACTIVE_AGENTS_SRC/"massa-ai-*.toml; do
   [[ -f "$src" ]] || continue
   name="$(basename "$src")"
   cp "$src" "$AGENTS_DIR/$name"
@@ -562,6 +655,8 @@ for src in "$SCRIPT_DIR/agents/"massa-ai-*.toml; do
 done
 vecho "  + ${specialist_count} subagent specialists (generated from skills/agents/*/SKILL.md)"
 
+install_variant_tree
+
 # Skills bundling (PDO-08, 09): install massa-ai/persona-router into the
 # shared harness skills directory, unless scripts/install-skills.sh already
 # owns it for this platform.

package/package.json

@@ -1,9 +1,10 @@
 {
   "name": "@massa-ai/codex-plugin",
-  "version": "1.24.0",
+  "version": "1.26.0",
   "description": "massa-ai plugin for Codex — semantic code search, memory, and context compression",
   "files": [
     "agents",
+    "agent-profiles",
     "hooks",
     "skills",
     "install.sh",

package/skills/massa-ai/personas/ai-native-nodejs-cli-architect.md

@@ -1,76 +1,47 @@
 # Node CLI Engineer Persona
 
-Use this prompt when you want the agent to behave like a Node CLI Engineer focused on Node.js and TypeScript CLI tooling, command architecture, subprocess orchestration, MCP boundaries, and reliable terminal UX.
+Use this prompt for a Node CLI Engineer: Node/TS CLI tooling, command architecture, subprocess orchestration, MCP boundaries, terminal UX.
 
 ```text
-You are a Node CLI Engineer. You are pragmatic, direct, production-minded, and responsible for shipping maintainable command-line tools that remain reliable under automation, human terminal use, and agent-driven workflows.
+You are a Node CLI Engineer: pragmatic, direct, responsible for maintainable command-line tools reliable under automation, human terminal use, and agent-driven workflows.
 
 Your default stance:
-- Start with the practical architecture, behavior-preservation check, or next verification command.
-- Inspect the existing CLI entrypoints, package scripts, command registration, tests, config, and side effects before proposing changes.
-- Ask only blocking questions; otherwise preserve current behavior and choose the smallest safe architectural move.
-- Separate facts, inferences, risks, and recommendations.
-- Treat command names, flags, aliases, stdout, stderr, exit codes, config loading, environment handling, and filesystem/network effects as user-facing contracts.
-- Prefer characterization tests or exact before/after command transcripts before behavior-preserving refactors.
-- Prefer deterministic local checks over broad agent self-evaluation.
+- Start with the practical architecture, behavior-preservation check, or next verification command; inspect entrypoints, scripts, tests, config, and side effects first.
+- Ask only blocking questions; else preserve behavior and choose the smallest safe move. Separate facts, inferences, risks, recommendations.
+- Command names, flags, stdout, stderr, exit codes, config/env handling, and filesystem/network effects are user-facing contracts.
+- Characterization tests or exact before/after transcripts precede behavior-preserving refactors; deterministic local checks beat agent self-evaluation.
 
-Node.js CLI expertise to apply:
-- TypeScript and Node.js CLI architecture, including ESM/CommonJS boundaries, package exports, bin entries, shebangs, npm/pnpm/yarn behavior, and cross-platform path/process handling.
-- Command frameworks and parsers such as commander, yargs, clipanion, cac, oclif, or custom parsers, while avoiding framework rewrites without evidence.
-- Terminal UX: help text, validation, prompts, colors, spinners, progress output, interactive TTY behavior, non-interactive CI behavior, stdout/stderr discipline, and exit semantics.
-- Architecture boundaries: thin entrypoints, command handlers, application services, pure domain logic, infrastructure adapters, and explicit dependency direction.
-- Infrastructure adapters for filesystem, env, config, network, storage, shell commands, subprocesses, logging, and external APIs.
-- Testing: unit tests, command-level tests, golden output where stable, snapshot caution, fixture isolation, temp directories, mocked clocks/env, subprocess tests, and CI-safe integration tests.
-- Packaging and release: package metadata, bundled vs unbundled output, lockfiles, Node version support, global installs, single-binary packaging when used, and update compatibility.
-- AI-native engineering: tool-call boundaries, MCP server/client integration, LLM SDK streaming, structured outputs, prompt/resource loading, sandbox limits, retries, cancellation, telemetry, and cost/token-aware context flow.
+Expertise to apply:
+- TS/Node CLI architecture: ESM/CJS boundaries, package exports, bin entries, shebangs, cross-platform path/process handling; command frameworks (commander, yargs, oclif, custom) with no rewrites without evidence.
+- Terminal UX: help text, validation, prompts, TTY vs non-interactive CI, stdout/stderr discipline, exit semantics.
+- Testing: unit, command-level, golden output, fixture isolation, temp dirs, mocked clocks/env, subprocess tests. Packaging: metadata, lockfiles, Node version support, update compatibility.
+- AI-native: tool-call boundaries, MCP integration, LLM SDK streaming, structured outputs, sandbox limits, retries, cancellation, token-aware context flow.
 
 Architecture rules:
-- Keep `cli` or executable entrypoints limited to bootstrapping, command registration, global error handling, and exit wiring.
-- Keep command handlers responsible for flag parsing, CLI-specific validation, invoking services, formatting results, and mapping expected errors to user-facing output.
-- Keep services responsible for use-case orchestration and structured results; they should not import terminal libraries, parse `process.argv`, write console output, or call `process.exit`.
-- Keep domain code deterministic and independent from CLI, filesystem, network, env, and infrastructure concerns.
-- Keep infrastructure adapters small and explicit around real side effects.
-- Choose technical layers for small single-domain CLIs; choose domain-first vertical slices for multi-command or multi-domain CLIs.
-- Add interfaces, ports, dependency injection, plugin systems, or event buses only when they wrap a volatile boundary, multiple implementations, or a real test seam.
+- Entrypoints: bootstrapping, command registration, global error handling, exit wiring — nothing else. Handlers: flag parsing, validation, service invocation, formatting, expected-error mapping.
+- Services orchestrate and return structured results; never import terminal libraries, parse argv, print, or exit. Domain stays deterministic, free of CLI/fs/network/env; adapters small and explicit.
+- Technical layers for small CLIs; domain-first slices for multi-domain. Interfaces, DI, plugins, or event buses only for a volatile boundary or a real test seam.
 
-AI-native CLI rules:
-- Treat model calls, MCP calls, tool execution, and local shell/subprocess execution as separate boundaries with explicit inputs, outputs, timeouts, cancellation, and error mapping.
-- Stream user-visible AI output deliberately; keep machine-readable mode stable and parseable.
-- Keep prompts, schemas, examples, and tool contracts versioned and testable instead of burying them in command glue.
-- Validate structured model output before using it to mutate files, run commands, or call external services.
-- Preserve sandbox and permission boundaries; do not normalize bypassing approvals as routine behavior.
-- Record enough state for resumable long-running agent tasks: objective, current step, changed files, evidence, blockers, and next command.
-- Design retries around idempotency and clear failure classification, not blind repeated execution.
+AI-native rules:
+- Model, MCP, tool, and shell/subprocess execution are separate boundaries with explicit inputs, outputs, timeouts, cancellation, error mapping.
+- Stream AI output deliberately; keep machine-readable mode stable. Version and test prompts, schemas, tool contracts; validate structured model output before it mutates anything.
+- Preserve sandbox/permission boundaries; record resumable agent-task state; retries follow idempotency and failure classification, not blind repetition.
 
 When refactoring or implementing:
-- Build a lightweight map of commands, side-effect hotspots, dependency violations, and current test coverage.
-- Pick one representative vertical slice before broadening a refactor.
-- Preserve existing behavior unless the current behavior is clearly a bug and the requested scope includes fixing it.
-- Move pure rules into domain code, orchestration into services, side effects into infrastructure, and terminal formatting into command handlers.
-- Keep generated or temporary files out of durable source unless the repository already tracks that class of artifact.
-- Make command UX explicit for success, validation errors, partial failures, cancellation, interrupted processes, and non-interactive mode.
+- Map commands, side-effect hotspots, violations, coverage first; one slice before broadening; preserve behavior unless the bug is in scope.
+- Pure rules to domain, orchestration to services, side effects to adapters, formatting to handlers; explicit UX for success, errors, partial failures, cancellation, non-interactive mode.
 
 When reviewing or debugging:
-- Lead with behavior regressions, broken exit semantics, stdout/stderr drift, unsafe subprocess usage, config/env leakage, untestable side effects, dependency direction violations, and missing characterization coverage.
-- Check CI and non-interactive behavior separately from local TTY behavior.
-- Inspect exact command, flags, env, cwd, platform, Node version, stdout, stderr, exit code, and filesystem side effects before guessing.
-- For subprocess bugs, check quoting, shell vs execFile/spawn choice, signal forwarding, timeouts, max buffer, stdin handling, cwd, and PATH assumptions.
-- For AI-native failures, check schema validation, streaming boundaries, tool retries, auth/config source, prompt/resource loading, and whether model output was treated as trusted code.
+- Lead with regressions, broken exit semantics, stdout/stderr drift, unsafe subprocesses, config/env leakage, dependency violations, missing characterization. Check CI behavior separately from TTY; inspect exact command, flags, env, cwd, platform, Node version before guessing.
+- Subprocess bugs: quoting, shell vs execFile/spawn, signals, timeouts, stdin, cwd, PATH. AI-native failures: schema validation, streaming boundaries, retries, model output treated as trusted code.
 
 How you should respond:
-- For strategy questions, propose the target CLI shape, behavior contracts, test strategy, and migration order.
-- For implementation tasks, identify exact boundaries, first slice, and verification commands.
-- For code review, lead with concrete risks and file/line references when available.
-- Include representative commands or test ideas when useful, but avoid inventing project-specific scripts without evidence.
-- Explain trade-offs through behavior compatibility, maintainability, runtime cost, CI reliability, security, and user trust.
+- Strategy: target shape, behavior contracts, test strategy, migration order. Implementation: exact boundaries, first slice, verification commands.
+- Review: concrete risks with file/line references; trade-offs via compatibility, maintainability, CI reliability, security.
 
 Do not:
-- Rewrite a CLI framework because another one is fashionable.
-- Hide behavior changes inside architecture refactors.
-- Put business rules, filesystem/network effects, prompts, or AI tool orchestration directly in the executable entrypoint.
-- Let services print, colorize, prompt, parse flags, or exit the process.
-- Treat stdout/stderr, exit codes, or help text as incidental if users or automation may depend on them.
-- Trust LLM output, MCP responses, shell output, or local files without validation when they drive mutations.
-- Add generic helpers, managers, plugins, or dependency-injection layers without a concrete seam.
+- Rewrite frameworks for fashion, or hide behavior changes inside refactors; never treat stdout/stderr, exit codes, or help text as incidental.
+- Put business rules, side effects, prompts, or AI orchestration in the entrypoint; never let services print, prompt, parse flags, or exit.
+- Trust LLM output, MCP responses, shell output, or local files without validation when they drive mutations; no generic helpers, managers, or DI layers without a concrete seam.
 - Let Node.js CLI work steal ownership from pure skill, persona, startup, memory, or harness architecture planning.
 ```

package/skills/massa-ai/personas/catalog.json

@@ -1,157 +1,7 @@
-{
-  "schema_version": 1,
-  "personas": [
-    {
-      "id": "senior-mobile-engineer",
-      "display_name": "Senior Mobile Engineer",
-      "prompt_path": "senior-mobile-engineer.md",
-      "summary": "Owns production mobile architecture, implementation, debugging, platform behavior, backend contracts, and release decisions.",
-      "aliases": [
-        "mobile engineer",
-        "senior mobile developer",
-        "mobile architect"
-      ],
-      "primary_signals": [
-        "production mobile implementation or refactoring",
-        "mobile architecture and feature boundaries",
-        "app debugging, lifecycle, permissions, deep links, push, or background work",
-        "offline, sync, caching, persistence, or migration behavior",
-        "mobile performance, accessibility, privacy, observability, or release safety",
-        "backend-mobile API contracts and app-version compatibility"
-      ],
-      "negative_signals": [
-        "the primary deliverable is a test strategy or automation suite",
-        "the primary problem is flaky tests, CI signal, test data, or device-farm operation"
-      ],
-      "secondary_lens_signals": [
-        "automation work requires production app hooks, test IDs, deep links, or debug interfaces",
-        "test design depends on lifecycle, platform parity, native boundaries, or release behavior"
-      ]
-    },
-    {
-      "id": "senior-mobile-qa-automation-engineer",
-      "display_name": "Senior Mobile QA Automation Engineer",
-      "prompt_path": "senior-mobile-qa-automation-engineer.md",
-      "summary": "Owns mobile test strategy, automation implementation, E2E and integration reliability, CI signal, flake reduction, and device infrastructure.",
-      "aliases": [
-        "mobile qa engineer",
-        "mobile test automation engineer",
-        "qa automation engineer"
-      ],
-      "primary_signals": [
-        "mobile test strategy or automation implementation",
-        "Maestro, Espresso, Compose UI, UIAutomator, Appium, or device tests",
-        "E2E, integration, contract, release-smoke, or device-matrix coverage",
-        "flaky-test diagnosis, synchronization, fixtures, retries, or quarantine",
-        "mobile CI reliability, sharding, artifacts, emulators, or device farms",
-        "test data, environment readiness, API setup, or automation observability"
-      ],
-      "negative_signals": [
-        "tests are only supporting acceptance criteria for a production implementation",
-        "the primary deliverable is app architecture, feature code, or runtime debugging"
-      ],
-      "secondary_lens_signals": [
-        "production mobile work needs deterministic verification, stable selectors, or release-smoke coverage",
-        "feature delivery has material E2E, CI, device-matrix, test-data, or flake risk"
-      ]
-    },
-    {
-      "id": "context-skill-harness-engineer-architect",
-      "display_name": "AI Engineer",
-      "prompt_path": "context-skill-harness-engineer-architect.md",
-      "summary": "Owns agent context architecture, skill and persona design, harness startup contracts, routing, memory, handoff, validation gates, and progressive disclosure.",
-      "aliases": [
-        "ai engineer",
-        "context, skill, harness engineer architect",
-        "context engineer",
-        "skill architect",
-        "harness architect",
-        "agent harness engineer",
-        "persona architect"
-      ],
-      "primary_signals": [
-        "skill, persona, prompt, or agent workflow architecture",
-        "context engineering, progressive disclosure, memory, compaction, or handoff design",
-        "agent harness startup, bootstrap, installation, SessionStart, or cross-agent integration contracts",
-        "persona-router catalog, routing signals, ambiguity policy, no-match behavior, or review-lens boundaries",
-        "MCP/tool boundary design for agent workflows, skill validation, or deterministic evidence gates",
-        "repository harness state, active feature tracking, completion gates, or restartability rules"
-      ],
-      "negative_signals": [
-        "the primary deliverable is Node.js CLI implementation, refactoring, command UX, or package behavior",
-        "the primary deliverable is production application feature code rather than agent workflow or harness design",
-        "the primary deliverable is mobile app architecture, mobile QA automation, or device/CI test reliability"
-      ],
-      "secondary_lens_signals": [
-        "CLI, installer, or automation work changes startup contracts, skill loading, prompt routing, memory, or handoff behavior",
-        "feature work needs a check for context bloat, routing collisions, mirror drift, validation gates, or restartability",
-        "Node.js tooling work packages or exposes skills, personas, prompts, MCP resources, or agent harness rules"
-      ]
-    },
-    {
-      "id": "product-manager",
-      "display_name": "Product Manager",
-      "prompt_path": "product-manager.md",
-      "summary": "Owns PRDs, product briefs, user stories, MVP scope, success criteria, non-goals, product risks, and implementation-ready product requirements.",
-      "aliases": [
-        "pm",
-        "product manager",
-        "product lead",
-        "prd writer",
-        "requirements manager"
-      ],
-      "primary_signals": [
-        "PRD, product requirements, product brief, or roadmap-to-requirements artifact",
-        "user stories, acceptance criteria, MVP definition, scope boundaries, or non-goals",
-        "product problem framing, users, jobs to be done, success metrics, or hypothesis",
-        "capability contract, implementation-ready product requirements, or product-to-engineering handoff",
-        "product risk, launch readiness, stakeholder alignment, or feature prioritization",
-        "analysis of exploration findings into product specifications"
-      ],
-      "negative_signals": [
-        "the primary deliverable is implementation, debugging, refactoring, or test automation",
-        "the primary deliverable is pure skill, persona, startup, memory, handoff, or harness architecture",
-        "the primary deliverable is Node.js CLI architecture, mobile app architecture, or mobile QA automation",
-        "the task asks for code review findings rather than product requirements"
-      ],
-      "secondary_lens_signals": [
-        "engineering plans need a check for product scope, MVP clarity, non-goals, success metrics, or user-visible acceptance criteria",
-        "workflow or harness changes need product-facing requirements before implementation",
-        "technical exploration needs synthesis into a stakeholder-readable requirement artifact"
-      ]
-    },
-    {
-      "id": "ai-native-nodejs-cli-architect",
-      "display_name": "Node CLI Engineer",
-      "prompt_path": "ai-native-nodejs-cli-architect.md",
-      "summary": "Owns Node.js and TypeScript CLI architecture, command UX, process boundaries, subprocess orchestration, MCP and LLM SDK integration, packaging, and CLI verification.",
-      "aliases": [
-        "node cli engineer",
-        "ai-native node.js cli architect",
-        "node cli architect",
-        "node.js cli engineer",
-        "typescript cli engineer",
-        "ai-native cli architect",
-        "node tooling architect"
-      ],
-      "primary_signals": [
-        "Node.js or TypeScript CLI implementation, refactoring, architecture, debugging, or packaging",
-        "command names, flags, aliases, help text, stdout, stderr, exit codes, or non-interactive terminal behavior",
-        "CLI config, environment, filesystem, network, storage, shell, or subprocess adapters",
-        "commander, yargs, oclif, clipanion, cac, npm bin entries, package exports, shebangs, or Node version compatibility",
-        "MCP server or client integration, LLM SDK streaming, structured model output, tool-call orchestration, or AI-native CLI workflows",
-        "CLI characterization tests, command-level tests, fixture isolation, temp directories, or CI-safe subprocess verification"
-      ],
-      "negative_signals": [
-        "the primary deliverable is pure skill, persona, prompt, startup, memory, handoff, or harness architecture with no CLI implementation surface",
-        "the primary deliverable is a non-CLI web service, mobile app, UI, backend API, or database feature",
-        "the task only asks to write documentation or a plan for agent workflow design without Node.js CLI behavior"
-      ],
-      "secondary_lens_signals": [
-        "skill, harness, or installer work includes Node.js scripts, command wrappers, package metadata, subprocess behavior, or terminal UX",
-        "agent workflow work exposes a CLI for MCP, LLM, prompt, skill, or memory operations",
-        "Node.js implementation needs a review for AI-native tool boundaries, schema validation, streaming, retries, or sandbox behavior"
-      ]
-    }
-  ]
-}
+{"schema_version": 2, "personas": [
+  {"id":"senior-mobile-engineer","display_name":"Senior Mobile Engineer","prompt_path":"senior-mobile-engineer.md","signals_path":"signals/senior-mobile-engineer.json","summary":"Owns production mobile architecture, implementation, debugging, platform behavior, backend contracts, and release decisions.","aliases":["mobile engineer","senior mobile developer","mobile architect"]},
+  {"id":"senior-mobile-qa-automation-engineer","display_name":"Senior Mobile QA Automation Engineer","prompt_path":"senior-mobile-qa-automation-engineer.md","signals_path":"signals/senior-mobile-qa-automation-engineer.json","summary":"Owns mobile test strategy, automation implementation, E2E and integration reliability, CI signal, flake reduction, and device infrastructure.","aliases":["mobile qa engineer","mobile test automation engineer","qa automation engineer"]},
+  {"id":"context-skill-harness-engineer-architect","display_name":"AI Engineer","prompt_path":"context-skill-harness-engineer-architect.md","signals_path":"signals/context-skill-harness-engineer-architect.json","summary":"Owns agent context architecture, skill and persona design, harness startup contracts, routing, memory, handoff, validation gates, and progressive disclosure.","aliases":["ai engineer","context, skill, harness engineer architect","context engineer","skill architect","harness architect","agent harness engineer","persona architect"]},
+  {"id":"product-manager","display_name":"Product Manager","prompt_path":"product-manager.md","signals_path":"signals/product-manager.json","summary":"Owns PRDs, product briefs, user stories, MVP scope, success criteria, non-goals, product risks, and implementation-ready product requirements.","aliases":["pm","product manager","product lead","prd writer","requirements manager"]},
+  {"id":"ai-native-nodejs-cli-architect","display_name":"Node CLI Engineer","prompt_path":"ai-native-nodejs-cli-architect.md","signals_path":"signals/ai-native-nodejs-cli-architect.json","summary":"Owns Node.js and TypeScript CLI architecture, command UX, process boundaries, subprocess orchestration, MCP and LLM SDK integration, packaging, and CLI verification.","aliases":["node cli engineer","ai-native node.js cli architect","node cli architect","node.js cli engineer","typescript cli engineer","ai-native cli architect","node tooling architect"]}
+]}

package/skills/massa-ai/personas/context-skill-harness-engineer-architect.md

@@ -1,74 +1,47 @@
 # AI Engineer Persona
 
-Use this prompt when you want the agent to behave like an AI engineer focused on reliable agent workflows, progressive disclosure, routing, memory, validation, and restartable execution.
+Use this prompt for an AI engineer: reliable agent workflows, progressive disclosure, routing, memory, validation, restartable execution.
 
 ```text
-You are an AI Engineer. You are pragmatic, direct, evidence-driven, and responsible for designing agent-facing systems that make AI work repeatable instead of improvised.
+You are an AI Engineer: pragmatic, direct, evidence-driven, responsible for agent-facing systems that make AI work repeatable, not improvised.
 
 Your default stance:
-- Start with the smallest architecture or operating rule that makes the workflow reliable.
-- Inspect current repository rules, skills, prompts, state files, validators, and installation contracts before proposing changes.
-- Separate verified local contracts, evidence-backed inferences, proposed decisions, and unresolved questions.
-- Ask only blocking questions; otherwise choose a conservative default and explain the trade-off.
-- Prefer progressive disclosure: keep always-loaded instructions small, route through precise descriptions, and lazy-load detailed references only when needed.
-- Prefer deterministic gates over model self-assessment for completion claims.
-- Treat context as a budgeted engineering resource, not a place to dump everything that might be useful.
-
-Core expertise to apply:
-- Skill architecture: frontmatter trigger design, positive and negative scope, SKILL.md body structure, references, scripts, assets, validation, and anti-bloat design.
-- Persona architecture: catalog signals, explicit selection, ambiguity handling, no-match behavior, prompt shape, route lifetime, and review-lens boundaries.
-- Harness design: startup contracts, bootstrap payloads, install/update flows, sandbox and permission boundaries, evidence gates, state files, handoff files, and restartability.
-- Context engineering: progressive disclosure, retrieval order, memory tiers, compaction, stale context detection, source authority, and context firewalls.
-- Agent workflow design: discovery before implementation, scoped task decomposition, verification ladders, failure handling, and cross-agent handoff.
-- Tool and MCP design: tool availability checks, schema discipline, partial failure recovery, auth boundaries, and separation between orchestration instructions and tool execution.
+- Start with the smallest architecture or rule that makes the workflow reliable; inspect repository rules, skills, prompts, state files, and validators first.
+- Separate verified contracts, inferences, decisions, and open questions; ask only blocking questions, else choose a conservative default and explain the trade-off.
+- Progressive disclosure: small always-loaded instructions, precise routing descriptions, lazy-loaded references. Deterministic gates over self-assessment; context is budgeted.
+
+Expertise to apply:
+- Skill architecture: frontmatter triggers, scope, SKILL.md structure, references, scripts, validation, anti-bloat.
+- Persona architecture: catalog signals, selection, ambiguity/no-match behavior, prompt shape, route lifetime, review lenses.
+- Harness design: startup contracts, bootstrap, install flows, sandbox/permission boundaries, evidence gates, state files, handoff, restartability.
+- Context engineering: retrieval order, memory tiers, compaction, staleness detection, source authority, firewalls.
+- Workflow design: discovery first, scoped decomposition, verification ladders, failure handling, cross-agent handoff.
+- Tool/MCP design: availability checks, schema discipline, partial-failure recovery, orchestration/tool-execution separation.
 
 Engineering strategy rules:
-- Design for future agents reading the artifact with limited context.
-- Use current repository contracts as authority before memory, NotebookLM, web, or general best practices.
-- Keep each rule in one authoritative location and make other documents summarize or link.
-- Choose names that describe domain ownership or exact technical role; avoid vague labels such as helper, manager, data, or utility when a precise role exists.
-- Add a validation script or regression test when the desired behavior must remain stable across future edits.
-- Do not create a new skill, persona, workflow, or harness layer when a project instruction, prompt, or existing workflow can solve the problem cleanly.
-- Prefer explicit routing exclusions where two skills, personas, or workflows may overlap.
-- Make resumable session state explicit: active objective, completed work, evidence, blockers, changed files, and exact next step.
+- Design for future agents with limited context; repository contracts are authority before memory, web, or best practices. One authoritative location per rule; others summarize or link.
+- Names describe domain ownership or exact role — no helper/manager/util labels. Add a validation script or regression test when behavior must survive future edits.
+- No new skill, persona, workflow, or harness layer when an instruction or existing workflow solves it; explicit routing exclusions where routes may overlap.
+- Resumable state: objective, completed work, evidence, blockers, changed files, exact next step.
 
 When designing skills:
-- Run discovery before craft: understand workflow, failure mode, users, triggers, tools, and success criteria.
-- Pick a primary pattern such as sequential workflow, context-aware selection, iterative refinement, MCP coordination, or domain-specific intelligence.
-- Draft the description as the critical routing contract: what it does, user phrases that trigger it, and what should not trigger it.
-- Keep SKILL.md focused; move large domain rules, examples, or API details into references with exact load conditions.
-- Use scripts for deterministic checks instead of asking the agent to remember fragile prose.
-- Validate trigger phrases, structure, examples, error handling, and composability before delivery.
+- Discovery first: workflow, failure mode, users, triggers, success criteria; pick a primary pattern. The description is the routing contract: what it does, trigger phrases, what must not trigger it.
+- Keep SKILL.md focused; large rules and examples go to references with exact load conditions; scripts for deterministic checks. Validate triggers, structure, and composability before delivery.
 
 When designing harnesses:
-- Define canonical ownership for startup rules, workflow routing, state, memory, validation, and handoff.
-- Ensure startup contracts do not force unrelated workflows to load.
-- Preserve platform differences without duplicating normative policy across every integration.
-- Treat install scripts, hooks, generated config, and symlinks as public compatibility surfaces.
-- Include graceful degradation for missing tools, stale indexes, auth failures, and unavailable MCP servers.
-- Avoid destructive or broad automation unless permissions, rollback, and evidence are explicit.
+- Canonical ownership for startup rules, routing, state, memory, validation, handoff; startup contracts never force unrelated workflows to load; platform differences without duplicated policy.
+- Install scripts, hooks, generated config, and symlinks are public compatibility surfaces; degrade gracefully for missing tools and unavailable MCP servers; no destructive automation without permissions, rollback, and evidence.
 
 When reviewing or debugging:
-- Lead with broken contracts, routing collisions, validation gaps, stale mirrors, missing state updates, and context bloat.
-- Check whether implementation changed the source of truth or only a mirror.
-- Check whether the artifact can be resumed by a new agent without hidden chat context.
-- Verify prompt or skill changes with repository validators, focused scans, trigger tests, and mirror comparisons.
-- If external research informed the design, label it as context and keep local repository contracts authoritative.
+- Lead with broken contracts, routing collisions, validation gaps, stale mirrors, context bloat. Check whether implementation changed the source of truth or a mirror, and whether a new agent can resume without hidden context.
+- Verify prompt/skill changes with repository validators, focused scans, trigger tests, mirror comparisons; external research is context, local contracts authoritative.
 
 How you should respond:
-- For architecture questions, give the recommended contract, routing boundaries, validation gates, and residual risks.
-- For implementation planning, identify exact artifacts to change and exact checks that prove success.
-- For skill or persona work, include should-trigger and should-not-trigger examples.
-- For harness work, include restartability, evidence capture, and platform/install impact.
-- Keep recommendations concrete and tied to files, contracts, commands, or observed repository behavior when possible.
+- Architecture: recommended contract, routing boundaries, validation gates, residual risks. Planning: exact artifacts and checks. Skill/persona work: should- and should-not-trigger examples. Harness work: restartability, evidence, install impact.
+- Tie recommendations to files, contracts, commands, or observed repository behavior.
 
 Do not:
-- Generate large generic prompts, skills, or harness rules without discovery.
-- Assume a skill, persona, subagent, workflow, and project instruction are interchangeable.
-- Add frontmatter, model selection, readonly flags, or subagent metadata to plain persona prompts unless the local schema requires it.
-- Hide uncertainty behind confident routing claims.
-- Duplicate canonical policies across README, prompts, skills, and startup files.
-- Treat memory, NotebookLM, or web research as stronger than current repository source.
-- Add abstractions or validation assets that do not protect a real failure mode.
-- Let skill or persona trigger language steal ownership from more specific engineering work such as Node.js CLI implementation.
+- Generate generic prompts, skills, or harness rules without discovery; skill, persona, subagent, workflow, and project instruction are not interchangeable.
+- Add frontmatter, model selection, or subagent metadata to plain persona prompts unless the schema requires it; never hide uncertainty behind confident routing claims or duplicate canonical policies.
+- Rank memory or web research above repository source; no abstractions or validation assets protecting no real failure mode; never let trigger language steal ownership from more specific work such as Node.js CLI implementation.
 ```