@massa-ai/codex-plugin 1.30.0 → 1.32.0

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "massa-ai",
-  "version": "1.30.0",
+  "version": "1.32.0",
   "description": "massa-ai — semantic code search, memory, and context compression for Codex",
   "author": {
     "name": "Luiz Massa",

package/agent-profiles/balanced/massa-ai-audit-specialist.toml

@@ -33,12 +33,13 @@ The `lens` field in the capability packet selects the audit behavior:
 | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
 | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
 | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
+| `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
 
 All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
 
 ## Inputs
 - `scope`: the target area, diff, or module to audit.
-- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
+- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
 - `inputs`: recalled facts, existing audit reports, source pointers.
 - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
 

package/agent-profiles/balanced/massa-ai-test-engineer.toml

@@ -7,12 +7,13 @@ sandbox_mode = "workspace-write"
 developer_instructions = """# Test Engineer Agent Skill
 
 ## Mission
-Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
+Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
 
 ## Responsibilities
 - Define unit test cases for core logic.
 - Define integration test cases for boundaries.
 - Identify edge cases and negative scenarios.
+- Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
 - Produce a test plan aligned with acceptance criteria.
 - Ensure acceptance coverage maps to spec criteria.
 

package/agent-profiles/cheap/massa-ai-audit-specialist.toml

@@ -33,12 +33,13 @@ The `lens` field in the capability packet selects the audit behavior:
 | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
 | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
 | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
+| `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
 
 All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
 
 ## Inputs
 - `scope`: the target area, diff, or module to audit.
-- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
+- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
 - `inputs`: recalled facts, existing audit reports, source pointers.
 - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
 

package/agent-profiles/cheap/massa-ai-test-engineer.toml

@@ -7,12 +7,13 @@ sandbox_mode = "workspace-write"
 developer_instructions = """# Test Engineer Agent Skill
 
 ## Mission
-Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
+Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
 
 ## Responsibilities
 - Define unit test cases for core logic.
 - Define integration test cases for boundaries.
 - Identify edge cases and negative scenarios.
+- Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
 - Produce a test plan aligned with acceptance criteria.
 - Ensure acceptance coverage maps to spec criteria.
 

package/agent-profiles/heavy/massa-ai-audit-specialist.toml

@@ -33,12 +33,13 @@ The `lens` field in the capability packet selects the audit behavior:
 | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
 | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
 | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
+| `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
 
 All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
 
 ## Inputs
 - `scope`: the target area, diff, or module to audit.
-- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
+- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
 - `inputs`: recalled facts, existing audit reports, source pointers.
 - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
 

package/agent-profiles/heavy/massa-ai-test-engineer.toml

@@ -7,12 +7,13 @@ sandbox_mode = "workspace-write"
 developer_instructions = """# Test Engineer Agent Skill
 
 ## Mission
-Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
+Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
 
 ## Responsibilities
 - Define unit test cases for core logic.
 - Define integration test cases for boundaries.
 - Identify edge cases and negative scenarios.
+- Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
 - Produce a test plan aligned with acceptance criteria.
 - Ensure acceptance coverage maps to spec criteria.
 

package/agent-profiles/home/massa-ai-audit-specialist.toml

@@ -33,12 +33,13 @@ The `lens` field in the capability packet selects the audit behavior:
 | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
 | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
 | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
+| `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
 
 All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
 
 ## Inputs
 - `scope`: the target area, diff, or module to audit.
-- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
+- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
 - `inputs`: recalled facts, existing audit reports, source pointers.
 - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
 

package/agent-profiles/home/massa-ai-test-engineer.toml

@@ -7,12 +7,13 @@ sandbox_mode = "workspace-write"
 developer_instructions = """# Test Engineer Agent Skill
 
 ## Mission
-Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
+Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
 
 ## Responsibilities
 - Define unit test cases for core logic.
 - Define integration test cases for boundaries.
 - Identify edge cases and negative scenarios.
+- Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
 - Produce a test plan aligned with acceptance criteria.
 - Ensure acceptance coverage maps to spec criteria.
 

package/agent-profiles/work/massa-ai-audit-specialist.toml

@@ -33,12 +33,13 @@ The `lens` field in the capability packet selects the audit behavior:
 | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
 | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
 | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
+| `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
 
 All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
 
 ## Inputs
 - `scope`: the target area, diff, or module to audit.
-- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
+- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
 - `inputs`: recalled facts, existing audit reports, source pointers.
 - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
 

package/agent-profiles/work/massa-ai-test-engineer.toml

@@ -7,12 +7,13 @@ sandbox_mode = "workspace-write"
 developer_instructions = """# Test Engineer Agent Skill
 
 ## Mission
-Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
+Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
 
 ## Responsibilities
 - Define unit test cases for core logic.
 - Define integration test cases for boundaries.
 - Identify edge cases and negative scenarios.
+- Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
 - Produce a test plan aligned with acceptance criteria.
 - Ensure acceptance coverage maps to spec criteria.
 

package/agents/massa-ai-audit-specialist.toml

@@ -33,12 +33,13 @@ The `lens` field in the capability packet selects the audit behavior:
 | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
 | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
 | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
+| `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
 
 All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
 
 ## Inputs
 - `scope`: the target area, diff, or module to audit.
-- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
+- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
 - `inputs`: recalled facts, existing audit reports, source pointers.
 - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
 

package/agents/massa-ai-test-engineer.toml

@@ -7,12 +7,13 @@ sandbox_mode = "workspace-write"
 developer_instructions = """# Test Engineer Agent Skill
 
 ## Mission
-Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
+Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
 
 ## Responsibilities
 - Define unit test cases for core logic.
 - Define integration test cases for boundaries.
 - Identify edge cases and negative scenarios.
+- Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
 - Produce a test plan aligned with acceptance criteria.
 - Ensure acceptance coverage maps to spec criteria.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@massa-ai/codex-plugin",
-  "version": "1.30.0",
+  "version": "1.32.0",
   "description": "massa-ai plugin for Codex — semantic code search, memory, and context compression",
   "files": [
     "agents",

package/skills/agents/audit-specialist/SKILL.md

@@ -38,12 +38,13 @@ The `lens` field in the capability packet selects the audit behavior:
 | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
 | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
 | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
+| `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
 
 All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
 
 ## Inputs
 - `scope`: the target area, diff, or module to audit.
-- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
+- `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
 - `inputs`: recalled facts, existing audit reports, source pointers.
 - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
 

package/skills/agents/test-engineer/SKILL.md

@@ -12,12 +12,13 @@ metadata:
 # Test Engineer Agent Skill
 
 ## Mission
-Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
+Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
 
 ## Responsibilities
 - Define unit test cases for core logic.
 - Define integration test cases for boundaries.
 - Identify edge cases and negative scenarios.
+- Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
 - Produce a test plan aligned with acceptance criteria.
 - Ensure acceptance coverage maps to spec criteria.
 

package/skills/massa-ai/SKILL.md

@@ -167,6 +167,7 @@ current context already contains it.
 | `the-fool` | direct challenge, red-team, pre-mortem, evidence audit | `workflows/the-fool.md` |
 | `judge-with-debate` | standalone multi-judge debate evaluation of user-supplied artifacts | `workflows/judge-with-debate.md` |
 | `pr-review` | review a hosted GitHub PR / GitLab MR and post findings via `gh`/`glab` | `workflows/pr-review.md` |
+| `discovery` | product brainstorming / problem-space thinking partner | `workflows/discovery.md` |
 | `to-prd` | turn the current conversation into a PRD without a new interview | `workflows/to-prd.md` |
 | `skill-architect` | design and build a new skill through structured conversation | `workflows/skill-architect.md` |
 | `furps-refinement` | FURPS+ refinement of a PRD and/or ADR before implementation, with The Fool pre-validation and DoR coverage | `workflows/refinement/furps-refinement.md` |
@@ -183,7 +184,7 @@ Deterministic routing precedence, first match wins:
 1. **Explicit route:** user names a massa-ai workflow, report family, saved finding type, or asks for a direct challenge.
 2. **Requested artifact:** ADR, RFC, TDD, Jira ticket, commit, session guide, audit report, implementation audit report, mobile Figma report, FURPS refinement report, PRD synthesized from the current conversation -> `to-prd` (explicit request only; refining an existing PRD stays `furps-refinement`), or new SKILL.md / skill design -> `skill-architect`.
 3. **Target type:** broken behavior/error -> `debug`; hosted PR/MR reference (number or URL) to review with posted findings -> `pr-review` (local working diff stays with audit routes); saved audit finding -> matching `*-fix`; implementation scope review -> `implementation-audit`; Maestro E2E/device automation target -> `maestro`, `maestro-audit`, or child-only `maestro-fix` before generic tests workflows; security/privacy/auth finding -> security workflow; tests/flakes/coverage finding -> tests workflow; supplied Figma/screenshot mobile UI design -> `design`; mobile Figma compare/audit -> `mobile-figma-audit`; saved `MFM-*` findings -> `mobile-figma-fix`.
-4. **Primary verb:** create/add/implement -> `feature` unless the concrete target is new Maestro flow work, which routes to `maestro`; restructure without behavior change -> `refactor`; inspect/understand only -> `exploration`; record selected decision -> `adr`; compare open options -> `rfc`; design settled implementation -> `tdd`; refine/quality-check an existing PRD or ADR document (not implementation auditing) -> `furps-refinement`.
+4. **Primary verb:** create/add/implement -> `feature` unless the concrete target is new Maestro flow work, which routes to `maestro`; restructure without behavior change -> `refactor`; inspect/understand only -> `exploration`; brainstorm/explore a product problem, idea, or direction with no concrete code target -> `discovery`; record selected decision -> `adr`; compare open options -> `rfc`; design settled implementation -> `tdd`; refine/quality-check an existing PRD or ADR document (not implementation auditing) -> `furps-refinement`.
 5. **Risk domain escalation:** migrations, irreversible operations, auth/privacy, cross-service contracts, public compatibility, or work over 10 files routes to `spec-driven` unless the user explicitly requests a narrower workflow and accepts the containment.
 6. **General fallback:** use `general` only after a one-line General fallback preflight names the specialized workflow considered, rejected reason, and why fallback does not change verification or mutation behavior.
 

package/skills/massa-ai/references/coding-guidelines.md

@@ -65,3 +65,12 @@ For multi-step tasks, state a brief plan:
 ```
 
 Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
+
+## 5. File Shape for Agent Readers
+
+**Read mechanics, not module depth.**
+
+- A one-subject file up to ~500 lines is fine — a single agent read stays coherent, cheap in tokens, and a coding agent can hold the whole file in context with headroom for the rest of the task.
+- A file over ~600 lines must be flagged for splitting — even one-subject, it crowds out the rest of the working context and pushes reads toward pagination.
+- Splitting one subject across many files does not reduce read cost — it multiplies it: one subject spread over N files costs N reads, and each file boundary loses context (per-hop navigation cost).
+- This guidance derives from agent read mechanics, not from module depth. Depth is a separate concept, and this section makes no depth claim: depth is NOT a lines-of-code ratio (`references/architecture-deepening-lens.md` Rejected Framings) — a deep module can be tiny and a shallow wrapper can be long. Do not phrase file-size guidance as a depth metric; it is scoped to single-agent read cost only.

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

@@ -111,6 +111,7 @@ report:
 - the PR URL,
 - the check names that passed,
 - what is still unverified (skipped jobs, absent checks),
+- the change's category trust status (`bun skills/massa-ai/scripts/lessons.ts --root . trust status --category <kebab>`) as advisory reading-depth context — it never substitutes for the approval decision below,
 
 then stop and ask. If the user approves, merge with the repository's configured
 strategy and delete the branch. If the repository auto-releases on merge, say so

package/skills/massa-ai/references/lessons.md

@@ -66,6 +66,58 @@ bun skills/massa-ai/scripts/lessons.ts --root . list --status confirmed [--scope
 | `quarantined` | A confirmed lesson penalized ≥`quarantine_threshold` times (failed when applied) |
 | **pruned** | A `candidate` that never recurred within `window_days` (default 45) |
 
+## Trust Ramp and Quality-Metric Trend (Advisory)
+
+Two additional append-only record kinds accumulate in `.specs/lessons.json` beside
+lessons: reviewer-feedback records (`data.reviews`) and quality-metric snapshots
+(`data.metrics`). Both are derived state — `lessons.ts` computes streaks, trusted
+flags, and trend verdicts at read time from the event log; there is no cached
+`streak`/`trusted` flag anywhere in the store, so there is no invalidation step,
+and demotion is emergent: a `major` record simply caps the trailing streak window
+the next time the log is read.
+
+### Categories
+
+A review category is a free-form kebab-case label supplied at record time (e.g.
+`installer`, `admin-ui`) — the same convention as the existing `--scope` flag.
+There is no fixed taxonomy; the label is whatever the recording agent or user
+chooses.
+
+### Feedback levels
+
+- `none` — no reviewer feedback; extends the category's streak.
+- `minor` — a small correction; also extends the streak.
+- `major` — resets the category's streak to 0 and demotes a trusted category
+  back to untrusted.
+
+### Trust threshold
+
+`trust_threshold` (default 30) is the number of consecutive `none`/`minor`
+records a category needs before `trust status` marks it `trusted`. The
+comparison is `>=`: a streak sitting exactly at the threshold is trusted.
+
+### Advisory-only scope
+
+Trust status governs reading depth only — how closely a human scrutinizes a
+diff before approving it. It never governs, gates, or substitutes for per-PR
+merge approval: `references/implementation-delivery.md`'s "Approval for one PR
+does not carry to the next" clause is unaffected by any trust state.
+
+### Commands
+
+```bash
+bun skills/massa-ai/scripts/lessons.ts --root . review add --category <kebab> --feedback none|minor|major --source <ref>
+bun skills/massa-ai/scripts/lessons.ts --root . trust status [--category <kebab>]
+bun skills/massa-ai/scripts/lessons.ts --root . metrics add --feature <slug> --result PASS|FAIL --fix-iterations <n> --surviving-mutants <n> --acs-total <n> --acs-covered <n>
+bun skills/massa-ai/scripts/lessons.ts --root . metrics trend
+```
+
+`trust status` with no `--category` lists every category with its streak,
+total review count, and trusted state; an empty store reports
+`(no review records)`, exit 0. `metrics trend` prints every snapshot
+oldest-first followed by `trend: improving|stable|degrading`, or
+`trend: insufficient data` when fewer than two snapshots exist — both exit 0.
+
 ## No-Script Fallback
 
 If `lessons.ts` is unavailable or cannot run, record `Lessons: skipped - script unavailable` in the validation report or evidence gate, keep the raw signal in the report, and do not hand-edit `lessons.json`. A future run with the script can import the validated signal.

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

@@ -218,6 +218,16 @@ The script enforces grounding (mandatory `--source`) and owns all bookkeeping. A
 
 Persist durable memory for verified outcomes worth reusing via `remember` with tags `workflow:spec-driven`, `entity:<slug>`, and `memory:episodic|procedural` as appropriate.
 
+### 11. Record Metric Snapshot (MANDATORY)
+
+Immediately after validation completes, record this run's quality-metric snapshot so "is the harness improving or degrading" is answerable from data, not memory:
+
+```bash
+bun skills/massa-ai/scripts/lessons.ts --root . metrics add --feature <slug> --result PASS|FAIL --fix-iterations <n> --surviving-mutants <n> --acs-total <n> --acs-covered <n>
+```
+
+Derive the flags from this validation's own evidence: `--result` from the Verdict, `--acs-total`/`--acs-covered` from the Spec-Anchored Acceptance Criteria check, `--surviving-mutants` from the Discrimination Sensor's survived count, and `--fix-iterations` from the fix-loop iteration count used this run.
+
 ---
 
 ## Verdicts