@massu/core 1.13.1 → 1.15.0

package/CHANGELOG.md

@@ -4,6 +4,65 @@ All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
+## [1.15.0] - 2026-06-02
+
+**Enterprise auto-learning governance + signed audit export (`plan-2026-06-01-enterprise-governance-audit-export`)**. Generalizes the Phase-3 per-rule two-operator review into an org-level governance policy enforced at the server promotion chokepoint + role-aware RLS, and adds a cryptographically-signed compliance export. Enterprise orgs (`plan='cloud_enterprise'`) can now set a promotion policy — minimum promoter role (rank-compared, never lexicographic), N-of-M distinct-approver requirement, allowed destinations, and a tighten-only hardened-review flag — that `promoted_rule_upsert` enforces before any promotion applies; a promotion below threshold is held `pending` and excluded from every seat's pull cursor until enough distinct operators (each other than the promoter) approve it. The new signed audit export streams the org's full governance history (policy, approvals, promotions, revocations) as a single Ed25519-signed FLAT envelope (records carried as a `records_json` STRING so the signature covers every record — no nested-array forgery hole), verifiable offline against the bundled public key. The `audit-export` edge function is the SOLE signer (single-signer, CR-46) for both the programmatic `ms_live_` path (admin-scoped) and the dashboard path (which calls it server-side via a service-role bearer and holds no key). Backwards-compatible additive feature — off the Enterprise path, behavior is unchanged (`approval_state` defaults to `applied`) — minor per semver.
+
+### Added
+
+- **`packages/core/src/security/governance-export-verifier.ts`** — Ed25519 verifier for the signed `/audit-export` envelope; a one-line wrapper over the consolidated `verifyEd25519SignedEnvelope` core (third signed-envelope artifact, no copy-pasted crypto), NO transition mode. Bundled pubkey via `scripts/bundle-audit-export-pubkey.mjs` (+ `generate-audit-export-keypair.mjs`), wired into `prepublishOnly`.
+- **`packages/core/src/rule-candidate-hardened.ts`** — `validateGovernanceGate(policy, approvals)` (generalized N-of-M gate) + `roleRank()` ladder; `validateHardenedApplyGate` now delegates as the N=2 special case (CR-10: symbol + refs + exact messages preserved).
+- **`packages/core/src/auto-learning-entitlement.ts`** — `ENTERPRISE_GOVERNANCE_MIN_TIER` + `entitledForEnterpriseGovernance` (reuses the existing `tierLevel` + `PLAN_TO_TIER_MAP`; no parallel tier scheme).
+- **`/massu-rule approvals`** subcommand — surfaces the org policy + pending N-of-M approval state.
+- **pattern-scanner Check 37** + `governance-gate-invariant.test.ts` — the client-gate ↔ server-RPC ↔ RLS drift-guard (vitest ↔ scanner parity).
+- **Website (massu_prod + massu.ai)**: migration 049 (`org_promotion_policy` + `promotion_approvals` ledger + `promoted_rules.approval_state` + the `promoted_rule_upsert` governance branch + `promotion_approval_record`/`promotion_policy_reconcile` RPCs + role-aware RLS + widened `activity_feed` CHECK), the `audit-export` Enterprise-gated Ed25519-signing edge function (CR-58 `verify_jwt=false`), and the `/dashboard/governance` admin page (policy editor + approvals + signed-export download).
+
+### Changed
+
+- `promoted_rule_upsert` re-defined (CREATE OR REPLACE of the 045 body + governance branch); `/sync` recognizes the new `pending_approval` status; `/promoted-rules` excludes `approval_state='pending'` rows from the differential-pull cursor.
+
+## [1.14.0] - 2026-06-02
+
+**Curated Rule Packs — versioned, installable, actually-enforced (`plan-2026-06-01-curated-rule-packs`)**. Closes the inert-marketplace bug class: the rule-pack marketplace existed but enforced nothing — installing a pack flattened its rules into `org_rules`, which no core enforcement path ever read. Now an installed pack's rules materialize on the developer's machine as Ed25519-signed, provenance-tagged rule candidates that a human reviews and approves through `/massu-rule packs` (packs **propose**, humans **approve** — CR-39; no fake "active"/"enforced" state). Pack rules ride the existing `applyRuleCandidate()` chokepoint with the same Team-gated, signature-verified trust model as team-shared promotion (CR-54/55/57); executable destinations (`pattern-scanner`/`custom-destination`) route through the hardened two-operator review path and never auto-enforce. Ships the versioning + curation workflow (SemVer monotonicity, an immutable `rule_pack_versions` history, a `rule_pack_publish` SECURITY DEFINER RPC) the marketplace previously lacked. Backwards-compatible additive feature — new `/massu-rule packs` subcommand + `pack` provenance origin, zero breaking changes — minor per semver.
+
+### Added
+
+- **`packages/core/src/rule-pack-sync.ts`** — `pullInstalledPackRules(db)`: pulls the org's installed-pack rules from the `installed-rules` edge function, verifies the Ed25519 envelope (`verifyPromotionEnvelope`), org-matches against `getCachedOrgId()`, and materializes each rule as a provenance-tagged (`origin:'pack'`, `pack_slug`, `pack_version`) candidate sidecar. **Materialize-never-apply** invariant: imports none of the 7 applier-write symbols (drift-guarded by pattern-scanner Check 36 + `promotion-pull-skeleton-parity.test.ts`, the lockstep guard shared with `team-rule-sync.ts`).
+- **`packages/core/src/rule-pack-schema.ts`** — typed validator asserting every pack rule declares a real enforcement `destination` (imported from the `RuleDestination` SoT, `satisfies`-pinned), carries a deterministic enforcement body (no inert rules — CR-39), and flags executable destinations `requiresHardened`.
+- **`/massu-rule packs`** subcommand (`commands/rule.ts` + `massu-rule.md`) — Team-gated pack pull; `list`/`show` flag `FROM PACK <slug>@<version>`.
+- **pattern-scanner Check 36** — pins the rule-pack enforcement-bridge no-apply invariant; mirrored by `rule-pack-enforcement-bridge.test.ts`.
+- **Website (massu_prod + massu.ai)**: migration 047 (`rule_pack_versions` history + SemVer CHECK + `curation_status` + `rule_pack_update_status` view + `rule_pack_publish` RPC), migration 048 (re-seed the 6 curated packs into the destination-mapped enforced format, v1.1.0, snapshotted), the `installed-rules` Team-gated Ed25519-signed edge function (CR-58 `verify_jwt=false`), and marketplace version/update UX.
+
+### Changed
+
+- **`packages/core/src/rule-candidate-applier.ts`** — `RuleCandidateProvenance.origin` widened `'team'` → `'team' | 'pack'` (+ optional `pack_slug`/`pack_version`); the apply gate accepts `pack` candidates through the same tier/signature/destination checks as team origin.
+- **`website/src/__tests__/changelog-parse.test.ts:EXPECTED_COUNT`** bumped 43 → 44.
+
+### Fixed
+
+- **Destination fidelity (structural)** — `approve` previously re-derived a candidate's destination via `classifyCandidate()`, **discarding** the authored destination the publisher/pack stored on the sidecar (a pre-existing bug that also affected team origin: a `claude-md-cr` rule could be silently re-routed to `corrections-md`, or an executable rule downgraded off the hardened path). The applier now **structurally refuses** applying any provenance-bearing candidate to a destination other than its authored one (zero mutation on mismatch); `approve` uses the stored destination for `team`/`pack` origin.
+- **Rule-pack publish authz** — `rule_pack_publish` RPC no longer trusts a NULL `auth.uid()` (service-role) as a platform admin for global first-party packs; global packs are published via migration only (the RPC raises), org packs require owner/admin via a user-scoped client.
+
+## [1.13.1] - 2026-05-20
+
+**PreToolUse dispatcher SSOT promotion + hook docs drift closure**. Closes a customer-blocking regression introduced in 1.13.0: every fresh `npx -y @massu/core@1.13.0 init` wrote `npx -y @massu/core@1.13.0 hook-runner pre-tool-use-gate` into `.claude/settings.local.json` (the consolidated PreToolUse hook landed by P-E-019 in 1.12.0), but `commands/hook-runner.ts:HOOK_NAME_TO_FILE` was a hand-maintained map missing the entry. The dispatcher threw `Unknown hook: "pre-tool-use-gate"`, Claude Code interpreted the non-zero exit as a PreToolUse block, and Bash/Edit/Write were all gated — a catch-22 where the customer could not edit `settings.local.json` to repair the install because Edit itself was blocked. The existing 3-way parity tests (`hook-registry-parity.test.ts`) covered REGISTERED_HOOKS ↔ src/hooks/*.ts ↔ buildHooksConfig() but never asserted the 4th edge against the runtime dispatcher map.
+
+Structural fix per CR-46 / Rule 25: `HOOK_NAME_TO_FILE` is now derived from `REGISTERED_HOOKS` (`Object.fromEntries(REGISTERED_HOOKS.map(n => [n, `${n}.js`]))`) so every future hook landed in the registry automatically appears in the dispatcher. The bug class is structurally impossible by construction.
+
+### Fixed
+
+- **`packages/core/src/commands/hook-runner.ts:HOOK_NAME_TO_FILE`** — replaced the hand-maintained 16-entry map with a frozen derivation from `REGISTERED_HOOKS` (`lib/hook-registry.ts`). The dispatcher now exposes all 17 registered hooks including `pre-tool-use-gate`. Verified end-to-end: `node dist/cli.js hook-runner pre-tool-use-gate < /dev/null` → exit 0 (was exit 2 in 1.13.0 with "Unknown hook" stderr).
+
+### Added
+
+- **Three new parity-test cases** in `packages/core/src/__tests__/hook-registry-parity.test.ts`: (1) `HOOK_NAME_TO_FILE keys match REGISTERED_HOOKS (dispatcher parity)` — the 4th parity edge, asserts dispatcher cannot drift from the registry; (2) `HOOK_NAME_TO_FILE values match \`${name}.js\` for every registered hook` — pins the derivation shape contract; (3) `resolveHookFile() succeeds for every hook emitted by buildHooksConfig() (closes 1.13.0 regression)` — direct fire-time regression guard that every name the installer writes is dispatchable. Test count went 5 → 8 passing. Surrounding test surface (hook-runner + cli + init-hooks) unchanged at 78/78.
+- **Six previously-undocumented hook docs pages** in `website/content/docs/hooks/`: `pre-tool-use-gate.mdx`, `auto-learning-pipeline.mdx`, `fix-detector.mdx`, `classify-failure.mdx`, `incident-pipeline.mdx`, `rule-enforcement-pipeline.mdx`. The 1.13.0 dispatcher regression was able to ship in part because the consolidated `pre-tool-use-gate` hook (landed by P-E-019 in 1.12.0) had no documentation page — there was no /docs/hooks/pre-tool-use-gate URL to spot-check, and no reviewer was prompted to validate the runtime dispatch path. Closing the docs gap is part of the same structural close: every hook in `REGISTERED_HOOKS` now has a docs page.
+
+### Changed
+
+- **`website/content/docs/hooks/index.mdx`** — header "11 MCP lifecycle hooks" bumped to "17 MCP lifecycle hooks". The lifecycle table and detailed-documentation list both grew by 6 rows. The session-lifecycle ASCII diagram now includes the auto-learning pipeline chain (fix-detector → classify-failure → incident-pipeline → rule-enforcement-pipeline → auto-learning-pipeline at Stop).
+- **`website/src/__tests__/changelog-parse.test.ts:EXPECTED_COUNT`** bumped 42 → 43.
+
 ## [1.13.0] - 2026-05-20
 
 **v0.2 Interactive Rule-Approval (`plan-v0.2-interactive-rule-approval`)**. Closes the silent-self-attestation bug class in Massu's auto-learning system. v0.1 (`auto-learning.md:35-46`) was a protocol obligation the model self-enforces at `/massu-loop` end, audited post-hoc by `/massu-learning-audit`. v0.2 adds real-time correction detection (UserPromptSubmit hook, score-based threshold ≥60), side-channel rule-candidate funnel (`.massu/rule-candidates/<sha>.json`), explicit slash command `/massu-rule list|show|approve|dismiss|recurrence`, atomic write through `applyRuleCandidate()` helper with `audit_log` UNIQUE-INDEX idempotency, three-class rubric (`pattern-scanner | claude-md-cr | corrections-md`) + `autoLearning.customDestinations` config extension point. Three-layer structural enforcement: protocol gate (slash command + hook) + idempotency lock (`audit_log` UNIQUE INDEX) + drift-guard vitest (`rule-promotion-effectiveness.test.ts`). New canonical rule CR-53 codifies "auto-learned rules must be effective". Ships as `@massu/core@1.13.0` — new MCP-adjacent capability + new slash command + backwards-compatible `audit_log.event_type` CHECK extension (internal-process table, zero external schema consumers — minor justified per semver §7).
@@ -116,7 +175,7 @@ Phase 1.5 multi-perspective review surfaced 5 security + 7 architecture findings
 
 ### Added
 
-- **`scripts/check-claude-md-{size,structure}.sh`** (P-E-001) now resolve repo root via `git rev-parse --show-toplevel` instead of hardcoded `/Users/eko3/` paths — works for any operator regardless of `$USER`. Closes `wave2-pattern:F4`.
+- **`scripts/check-claude-md-{size,structure}.sh`** (P-E-001) now resolve repo root via `git rev-parse --show-toplevel` instead of hardcoded `/Users/<user>/` paths — works for any operator regardless of `$USER`. Closes `wave2-pattern:F4`.
 - **`scripts/kb-staleness-audit.sh`** (P-E-002) incident-count parser now uses awk-based context-aware count of `### Incident #N` entries under the `## Incidents` section, properly handles empty-template case. Closes `wave2-pattern:F5`.
 - **`scripts/massu-pattern-scanner.sh`** (P-E-003) adds `gawk` shim + replaces `\(` ERE escapes with `[(]` portable form. macOS BSD-awk noise reduced from ~80 lines to 0. Allow-directive bridging now persists through block-comment + blank lines (fixes false positive on `init.ts:655` yaml-parse directive at L650). Surfaced 2 real pre-existing violations (now also fixed below).
 - **`scripts/massu-pattern-scanner.sh`** (P-E-004) Check 10 replaced count-based check with per-file leak detection — matches `?.close()` and excludes comment-line references. Closes `wave1-mcp-tools:F-MCP-008` / `wave2-pattern:F8`.
@@ -136,7 +195,7 @@ Phase 1.5 multi-perspective review surfaced 5 security + 7 architecture findings
 ### Drift-guards (CR-46 compliance)
 
 - **`website/src/__tests__/eslint-warning-budget.test.ts`** (P-E-045) — ESLint budget pinned at 90 warnings + 0 errors. Future regressions FAIL the test. Reduction over time encouraged via budget DOWN-adjustment.
-- **`website/src/__tests__/generic-username-scripts.test.ts`** (P-E-046) — forbids `/Users/eko3`, `/Users/ekoultra`, and any `/home/<username>/` literal in any script under `scripts/`. Allowlist for leak-pattern scan targets.
+- **`website/src/__tests__/generic-username-scripts.test.ts`** (P-E-046) — forbids hardcoded operator home paths (`/Users/<user>/`, `/home/<username>/`) in any script under `scripts/`. Allowlist for leak-pattern scan targets.
 - **`website/src/__tests__/privacy-page-required-sections.test.ts`** (P-E-028 drift-guard) — 5 cases: GDPR present, CCPA present, "Do Not Sell or Share" disclosure, CCPA id anchor for deep-link, metadata description mentions both.
 - **`website/src/__tests__/logger-sanitize.test.ts`** (P-E-040 drift-guard) — 6 cases: ANSI CSI strip, OSC strip, CRLF replace, length truncate, non-string coercion, CRLF-injection attack returns single line.
 - **`website/src/__tests__/revenue-kill-switches.test.ts`** (P-E-042 drift-guard) — 17 cases (4 flags × 4 cases + 1 disabled-response shape) — default ON, explicit OFF values, fail-open on garbage, 503 response shape.

package/commands/_shared-preamble.md

@@ -80,29 +80,34 @@ Code Quality: PASS + Plan Coverage: FAIL = NOT COMPLETE.
 
 ALWAYS run VR-SCHEMA-PRE before using any column name.
 
-## MANDATORY 3-ENVIRONMENT SCHEMA SYNC (CR-36, Incident #27)
+## MANDATORY MULTI-ENVIRONMENT SCHEMA SYNC (CR-36, Incident #27)
 
-**ALL database migrations (ALTER TABLE, CREATE TABLE, DROP COLUMN, etc.) MUST be applied to ALL 3 environments in the SAME session.**
+**ALL database migrations (ALTER TABLE, CREATE TABLE, DROP COLUMN, etc.) MUST be applied to EVERY configured environment in the SAME session.**
 
-| Order | Environment | MCP Tool Prefix |
-|-------|-------------|-----------------|
-| 1 | NEW PROD | `mcp__supabase__NEW_PROD__execute_sql` |
-| 2 | DEV | `mcp__supabase__DEV__execute_sql` |
-| 3 | OLD PROD | `mcp__supabase__OLD_PROD__execute_sql` |
+Configure your Supabase MCP server(s) in `.mcp.json`; this command uses whatever
+environment aliases you define. Apply migrations to every environment you maintain,
+in a safe order (lower environments first, production last). The MCP tool names
+follow the form `mcp__supabase__<your-env-alias>__execute_sql`.
+
+| Order | Environment (your alias) | MCP Tool Prefix |
+|-------|--------------------------|-----------------|
+| 1 | `<dev>` | `mcp__supabase__<dev>__execute_sql` |
+| 2 | `<staging>` | `mcp__supabase__<staging>__execute_sql` |
+| N (last) | `<prod>` | `mcp__supabase__<prod>__execute_sql` |
 
 ### VR-SCHEMA-SYNC Protocol
 
-After applying ANY migration, verify all 3 environments match:
+After applying ANY migration, verify all environments match:
 
 ```sql
--- Run on ALL 3 environments:
+-- Run on EVERY configured environment:
 SELECT column_name, data_type, is_nullable, column_default
 FROM information_schema.columns
 WHERE table_schema = 'public' AND table_name = '[TABLE]'
 ORDER BY ordinal_position;
 ```
 
-**Column count MUST match across all 3 environments. If it doesn't, the migration is INCOMPLETE.**
+**Column count MUST match across all environments. If it doesn't, the migration is INCOMPLETE.**
 
 A migration applied to only 1 environment is NOT a completed migration. It is a schema drift time bomb.
 

package/commands/_shared-references/verification-table.md

@@ -44,9 +44,13 @@
 
 ## Database Environments
 
-| Environment | Description | MCP Tool Prefix |
-|-------------|-------------|-----------------|
-| DEV | Local development, testing | `mcp__supabase__DEV__` |
-| PROD | Production database | `mcp__supabase__PROD__` |
+Configure your Supabase MCP server(s) in `.mcp.json`; the commands use whatever
+environment aliases you define. The MCP tool names follow the form
+`mcp__supabase__<your-env-alias>__execute_sql`.
 
-> **Note**: Project-specific Supabase project IDs should be configured in the project's CLAUDE.md or `.env` file, not in shared references.
+| Environment (your alias) | Description | MCP Tool Prefix |
+|--------------------------|-------------|-----------------|
+| `<dev>` | Local development, testing | `mcp__supabase__<dev>__` |
+| `<prod>` | Production database | `mcp__supabase__<prod>__` |
+
+> **Note**: Project-specific Supabase project IDs and environment aliases should be configured in your `.mcp.json` (and optionally documented in the project's CLAUDE.md), not in shared references.

package/commands/massu-checkpoint.md

@@ -1,11 +1,19 @@
 ---
 name: massu-checkpoint
 description: "When user wants mid-implementation verification, says 'checkpoint', 'check progress', or needs a quality gate during a multi-phase plan"
-allowed-tools: Bash(*), Read(*), Write(*), Edit(*), Grep(*), Glob(*), mcp__supabase__DEV__*, mcp__supabase__NEW_PROD__*, mcp__supabase__OLD_PROD__*
+allowed-tools: Bash(*), Read(*), Write(*), Edit(*), Grep(*), Glob(*), mcp__supabase__*
 ---
 name: massu-checkpoint
 
-# Massu Checkpoint: Phase Boundary Audit Protocol
+## Tier requirement (Requires Pro)
+
+The mid-implementation checkpoint audit (multi-environment schema verification,
+subagent loop, plan-coverage gate) is a **Pro** feature. Confirm entitlement
+before running — this hard-fails for sub-Pro:
+
+```bash
+npx massu license check --min pro || exit 1
+```
 
 **Shared rules**: Read `.claude/commands/_shared-preamble.md` for POST-COMPACTION (CR-12), ENTERPRISE-GRADE (CR-14), AWS SECRETS (CR-5) rules.
 
@@ -77,7 +85,7 @@ Execute full 15-step checkpoint audit for current phase. Require ZERO gaps befor
 2. ALL steps executed - no shortcuts (includes Step 0: Plan Coverage)
 3. Proof required - show verification output
 4. Session state update mandatory - record checkpoint result
-5. All 3 DB environments verified (DEV, OLD PROD, NEW PROD)
+5. ALL configured DB environments verified (every alias in your `.mcp.json`)
 6. UI/UX verification required for UI changes
 7. Schema verification required - verify column names against real schema
 8. Plan Coverage required - ALL plan items verified at 100%
@@ -141,13 +149,21 @@ Read plan section for this phase. Extract requirements into checklist.
 
 ---
 
-### Step 2: QUERY Database (All 3 Environments)
+### Step 2: QUERY Database (Every Configured Environment)
+
+Query **whatever Supabase MCP server(s) you configure** in your `.mcp.json`. Use the
+environment aliases you define there; the MCP tool names follow the form
+`mcp__supabase__<your-env-alias>__execute_sql`. Verify EVERY environment you maintain
+so no environment drifts.
+
+| Environment (your alias) | MCP Tool Prefix |
+|--------------------------|-----------------|
+| `<dev>` | `mcp__supabase__<dev>__` |
+| `<staging>` | `mcp__supabase__<staging>__` |
+| `<prod>` | `mcp__supabase__<prod>__` |
 
-| Environment | Project ID | MCP Tool Prefix |
-|-------------|------------|-----------------|
-| DEV | `gwqkbjymbarkufwvdmar` | `mcp__supabase__DEV__` |
-| OLD PROD | `hwaxogapihsqleyzpqtj` | `mcp__supabase__OLD_PROD__` |
-| NEW PROD | `cnfxxvrhhvjefyvpoqlq` | `mcp__supabase__NEW_PROD__` |
+> Configure your Supabase MCP server(s) in `.mcp.json`; this command uses whatever
+> environment aliases you define.
 
 For EACH affected table, verify: table exists, columns match, RLS policies exist, grants present.
 
@@ -155,9 +171,9 @@ For EACH affected table, verify: table exists, columns match, RLS policies exist
 ### DB Verification: [TABLE]
 | Env | Exists | Columns | RLS | Grants | Status |
 |-----|--------|---------|-----|--------|--------|
-| DEV | YES | X/X | X policies | YES | PASS |
-| OLD PROD | YES | X/X | X policies | YES | PASS |
-| NEW PROD | YES | X/X | X policies | YES | PASS |
+| <dev> | YES | X/X | X policies | YES | PASS |
+| <staging> | YES | X/X | X policies | YES | PASS |
+| <prod> | YES | X/X | X policies | YES | PASS |
 ```
 
 ---
@@ -448,7 +464,7 @@ Re-run ENTIRE checkpoint from Step 1. Partial re-checks are NOT valid.
 | R-001 | [desc] | [VR-* proof] | VERIFIED |
 
 ### Summary
-- Database: DEV/OLD PROD/NEW PROD verified: PASS
+- Database: all configured environments verified: PASS
 - Pattern scanner exit 0: PASS
 - Build: PASS (Exit 0)
 - UI/UX: All checks passed
@@ -474,7 +490,7 @@ Verified:
 - Pattern scanner: PASS
 - Type check: 0 errors
 - Build: PASS
-- DB: DEV/OLD PROD/NEW PROD verified
+- DB: all configured environments verified
 
 Co-Authored-By: Claude <noreply@anthropic.com>
 EOF
@@ -503,7 +519,7 @@ After checkpoint, update `session-state/CURRENT.md`:
 | Pattern scanner | PASS |
 | Type check | 0 errors |
 | Build | PASS |
-| DB (DEV/OLD PROD/NEW PROD) | PASS |
+| DB (all configured environments) | PASS |
 
 ### Files Changed
 - [file1.ts]

package/commands/massu-data.md

@@ -1,12 +1,22 @@
 ---
 name: massu-data
 description: "When user asks about data trends, metrics, analytics, funnel analysis, cohort comparison, entity counts, storage usage, or 'what happened' questions about the database"
-allowed-tools: Bash(*), Read(*), Grep(*), Glob(*), mcp__supabase__DEV__*, mcp__supabase__NEW_PROD__*, mcp__supabase__OLD_PROD__*
+allowed-tools: Bash(*), Read(*), Grep(*), Glob(*), mcp__supabase__*
 ---
 
 # Data Analysis
 
-Structured data analysis and query library for Massu databases.
+Structured data analysis and query library for your project databases.
+
+## Tier requirement (Requires Pro)
+
+The data-analysis query library (multi-environment querying, funnel/cohort
+analytics) is a **Pro** feature. Confirm entitlement before running — this
+hard-fails for sub-Pro:
+
+```bash
+npx massu license check --min pro || exit 1
+```
 
 ## Skill Contents
 
@@ -24,20 +34,24 @@ This skill is a folder. The following files are available for reference:
 ## Process
 
 1. **Understand the question** — What data does the user need?
-2. **Identify target database** — DEV (testing), NEW PROD (live data), OLD PROD (historical)
+2. **Identify target database** — pick the matching environment alias from your `.mcp.json`
 3. **Check for pre-built query** — Review `scripts/` for a matching SQL template
 4. **Verify schema** — Run VR-SCHEMA-PRE before any custom query
-5. **Execute query** — Use MCP `execute_sql` tool
+5. **Execute query** — Use the `mcp__supabase__<your-env-alias>__execute_sql` MCP tool
 6. **Present results** — Format as table with clear labels
 
 ## Database Selection
 
-| User Says | Database |
-|-----------|----------|
-| "production", "live", "real data" | NEW PROD |
-| "dev", "test", "local" | DEV |
-| "old prod", "historical" | OLD PROD |
-| No qualifier | NEW PROD (default) |
+Configure your Supabase MCP server(s) in `.mcp.json`; this command uses whatever
+environment aliases you define (e.g. `dev`, `staging`, `prod`). Map the user's
+intent to your own aliases:
+
+| User Says | Database (your alias) |
+|-----------|-----------------------|
+| "production", "live", "real data" | your production alias (default) |
+| "dev", "test", "local" | your dev alias |
+| "staging", "historical" | your staging/secondary alias |
+| No qualifier | your production alias (default) |
 
 ## Key Tables
 

package/commands/massu-golden-path/references/phase-5.5-production-verify.md

@@ -83,7 +83,7 @@ Use Playwright MCP against production URL:
 - Verify data loads and mutations work
 
 ### Database Changes
-Query PROD (`mcp__supabase__PROD__execute_sql`):
+Query your production environment (`mcp__supabase__<your-prod-alias>__execute_sql` — use the alias you configure in `.mcp.json`):
 ```sql
 -- Verify data flows, not just schema
 SELECT COUNT(*), MAX(created_at) FROM [table]

package/commands/massu-production-verify.md

@@ -1,7 +1,7 @@
 ---
 name: massu-production-verify
 description: "When user says 'verify production', 'is it working', 'production check', or after a deploy to verify features are actually working in production — not just deployed"
-allowed-tools: Bash(*), Read(*), Grep(*), Glob(*), mcp__supabase__NEW_PROD__*, mcp__supabase__DEV__*, mcp__plugin_playwright_playwright__*, mcp__claude_ai_Vercel__get_deployment, mcp__claude_ai_Vercel__get_runtime_logs, mcp__claude_ai_Vercel__list_deployments, mcp__claude_ai_Vercel__web_fetch_vercel_url
+allowed-tools: Bash(*), Read(*), Grep(*), Glob(*), mcp__supabase__*, mcp__plugin_playwright_playwright__*, mcp__claude_ai_Vercel__get_deployment, mcp__claude_ai_Vercel__get_runtime_logs, mcp__claude_ai_Vercel__list_deployments, mcp__claude_ai_Vercel__web_fetch_vercel_url
 ---
 name: massu-production-verify
 
@@ -17,9 +17,14 @@ Code existing, builds passing, and deploys succeeding prove NOTHING about whethe
 
 ---
 
+> **Environment aliases**: Configure your Supabase MCP server(s) in `.mcp.json`; this
+> command uses whatever environment aliases you define. Below, "production" / "PROD"
+> means your configured production alias and "DEV" means your dev alias — substitute
+> your own (`mcp__supabase__<your-env-alias>__execute_sql`).
+
 ## NON-NEGOTIABLE RULES
 
-- **Proof from production, not dev** — queries must hit NEW PROD database, URLs must hit production deployment
+- **Proof from production, not dev** — queries must hit your PRODUCTION database, URLs must hit production deployment
 - **Data, not structure** — verifying a table exists is NOT the same as verifying data flows through it
 - **End-to-end, not component** — verify the full chain: trigger -> process -> store -> display
 - **Every feature, every deploy** — no exceptions for "simple" changes

package/commands/massu-rollback.md

@@ -1,13 +1,23 @@
 ---
 name: massu-rollback
 description: "When user says 'rollback', 'revert this', 'undo changes', 'go back', or needs to safely undo code or database changes with state preservation"
-allowed-tools: Bash(*), Read(*), Write(*), Edit(*), Grep(*), Glob(*), mcp__supabase__DEV__*, mcp__supabase__NEW_PROD__*, mcp__supabase__OLD_PROD__*
+allowed-tools: Bash(*), Read(*), Write(*), Edit(*), Grep(*), Glob(*), mcp__supabase__*
 disable-model-invocation: true
 ---
 name: massu-rollback
 
 > **Shared rules apply.** Read `.claude/commands/_shared-preamble.md` before proceeding. CR-14, CR-5, CR-12 enforced.
 
+## Tier requirement (Requires Pro)
+
+The safe rollback protocol (multi-environment schema/data rollback with state
+preservation and integrity verification) is a **Pro** feature. Confirm entitlement
+before running — this hard-fails for sub-Pro:
+
+```bash
+npx massu license check --min pro || exit 1
+```
+
 # Massu Rollback: Safe Rollback Protocol
 
 ## Objective
@@ -60,11 +70,19 @@ ROLLBACK VERIFICATION LOOP:
 
 ## SUPABASE ENVIRONMENTS
 
-| Environment | Project ID | MCP Tool Prefix |
-|-------------|------------|-----------------|
-| DEV | `gwqkbjymbarkufwvdmar` | `mcp__supabase__DEV__` |
-| OLD PROD | `hwaxogapihsqleyzpqtj` | `mcp__supabase__OLD_PROD__` |
-| NEW PROD | `cnfxxvrhhvjefyvpoqlq` | `mcp__supabase__NEW_PROD__` |
+Rollbacks run against **whatever Supabase MCP server(s) you configure** in your
+`.mcp.json`. Use the environment aliases you define there; the MCP tool names
+follow the form `mcp__supabase__<your-env-alias>__execute_sql`. Apply every
+rollback to EVERY environment you maintain so no environment drifts.
+
+| Environment (your alias) | MCP Tool Prefix |
+|--------------------------|-----------------|
+| `<dev>` | `mcp__supabase__<dev>__` |
+| `<staging>` | `mcp__supabase__<staging>__` |
+| `<prod>` | `mcp__supabase__<prod>__` |
+
+> Configure your Supabase MCP server(s) in `.mcp.json`; this command uses whatever
+> environment aliases you define.
 
 ---
 
@@ -345,7 +363,7 @@ ALTER TABLE [table] ALTER COLUMN [column] TYPE [old_type];
 ```
 
 ### 5.2 Apply Rollback Migration
-Apply to environments in order: DEV first, then OLD PROD, then NEW PROD
+Apply to environments in a safe order: lower environments first (e.g. dev), then staging, then production last — using your configured `.mcp.json` aliases.
 
 ```sql
 -- Always wrap in transaction
@@ -477,7 +495,7 @@ curl -I https://[production-url]/
 curl https://[production-url]/api/health
 
 # Monitor logs for errors
-# Use mcp__supabase__NEW_PROD__get_logs for each service
+# Use mcp__supabase__<your-prod-alias>__get_logs for each service
 ```
 
 ---

package/commands/massu-security.md

@@ -1,13 +1,23 @@
 ---
 name: massu-security
 description: "When user says 'security audit', 'check security', 'RLS audit', 'XSS check', or needs a focused security review covering auth, secrets, injection, and OWASP top 10"
-allowed-tools: Bash(*), Read(*), Grep(*), Glob(*), mcp__supabase__DEV__*, mcp__supabase__NEW_PROD__*, mcp__supabase__OLD_PROD__*
+allowed-tools: Bash(*), Read(*), Grep(*), Glob(*), mcp__supabase__*
 disable-model-invocation: true
 ---
 name: massu-security
 
 > **Shared rules apply.** Read `.claude/commands/_shared-preamble.md` before proceeding. CR-14, CR-5, CR-12 enforced.
 
+## Tier requirement (Requires Enterprise)
+
+The deep multi-environment security audit (RLS/grants across every configured
+Supabase environment, OWASP coverage, injection sweeps) is an **Enterprise**
+feature. Confirm entitlement before running — this hard-fails for sub-Enterprise:
+
+```bash
+npx massu license check --min enterprise || exit 1
+```
+
 # Massu Security: Comprehensive Security Audit
 
 ## Objective
@@ -71,11 +81,20 @@ SECURITY AUDIT LOOP:
 
 ## SUPABASE ENVIRONMENTS
 
-| Environment | Project ID | MCP Tool Prefix |
-|-------------|------------|-----------------|
-| DEV | `gwqkbjymbarkufwvdmar` | `mcp__supabase__DEV__` |
-| OLD PROD | `hwaxogapihsqleyzpqtj` | `mcp__supabase__OLD_PROD__` |
-| NEW PROD | `cnfxxvrhhvjefyvpoqlq` | `mcp__supabase__NEW_PROD__` |
+This audit runs against **whatever Supabase MCP server(s) you configure** in your
+`.mcp.json`. Use the environment aliases you define there — the audit covers every
+configured environment (e.g. dev / staging / prod). The MCP tool names follow the
+form `mcp__supabase__<your-env-alias>__execute_sql`; substitute your own aliases.
+
+| Environment (your alias) | MCP Tool Prefix |
+|--------------------------|-----------------|
+| `<dev>` | `mcp__supabase__<dev>__` |
+| `<staging>` | `mcp__supabase__<staging>__` |
+| `<prod>` | `mcp__supabase__<prod>__` |
+
+> Configure your Supabase MCP server(s) in `.mcp.json`; this command uses whatever
+> environment aliases you define. Run the RLS/grants checks below against EVERY
+> environment you maintain so no environment drifts.
 
 ---
 
@@ -470,9 +489,9 @@ npm audit --production --json | grep -i "critical\|high"
 ### Section 4: Database Security (RLS)
 | Environment | Tables with RLS | Policies | service_role Grants |
 |-------------|-----------------|----------|---------------------|
-| DEV | N/N | N | YES |
-| OLD PROD | N/N | N | YES |
-| NEW PROD | N/N | N | YES |
+| `<env-alias-1>` | N/N | N | YES |
+| `<env-alias-2>` | N/N | N | YES |
+| `<env-alias-N>` | N/N | N | YES |
 
 ### Section 5: Injection Prevention
 | Check | Result | Status |
@@ -558,7 +577,7 @@ After audit, update `session-state/CURRENT.md`:
 1. Run Section 1: Secrets & Credentials
 2. Run Section 2: Authentication
 3. Run Section 3: Authorization (tRPC)
-4. Run Section 4: Database Security (all 3 envs)
+4. Run Section 4: Database Security (every configured environment)
 5. Run Section 5: Injection Vulnerabilities
 6. Run Section 6: Data Exposure
 7. Run Section 7: Additional Checks