@jstn-sdk/ma 0.1.11 → 0.1.13

package/skills/diagnose/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: diagnose
+description: "Use when the user needs failure triage, blocked-lane diagnosis, or root-cause decomposition before the next gate can move."
+---
+
+# Diagnose
+
+Use this skill inside Codex when a lane is blocked, a symptom is vague, or the next useful move is to decompose the failure before editing code. `diagnose` is a non-gating helper skill.
+
+## Output
+
+Produce:
+- observed symptom
+- likely failure slices
+- missing evidence or missing reproduction steps
+- smallest next probe
+- exact next trigger, usually the owning lane or `$maestro`
+
+## Rules
+
+- Decompose the problem before proposing broad fixes.
+- Prefer the smallest reproducible boundary that can confirm or kill a hypothesis.
+- Keep release-state ownership with the gated lane that is blocked.
+- Escalate assumptions clearly when evidence is still incomplete.

package/skills/diagnose/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "$diagnose"
+  short_description: "Blocked-lane diagnosis and failure triage"
+  default_prompt: "Use $diagnose to break a vague failure into concrete hypotheses, probes, and the smallest next debugging step without changing gate ownership."

package/skills/flow/SKILL.md

@@ -10,7 +10,9 @@ Use this skill inside Codex to pressure-test how the system behaves, not just ho
 ## Output
 
 Produce:
+- `decision`, `status`, `evidence`, `blockers`, `next_allowed_triggers`
 - key actors and system states
+- state map and failure flows
 - main flows and failure flows
 - invariants and state transitions
 - race conditions, dead ends, and consistency risks

package/skills/index.json

@@ -1,6 +1,11 @@
 {
   "schemaVersion": "0.1.0",
   "skills": [
+    {
+      "name": "align",
+      "path": "skills/align",
+      "description": "Use when the user needs scope alignment, shared language, or docs clarity before or between gated lanes."
+    },
     {
       "name": "arch",
       "path": "skills/arch",
@@ -11,6 +16,16 @@
       "path": "skills/build",
       "description": "Use when the user wants to decide whether implementation is ready, what remains blocked, and what the exact next build step should be."
     },
+    {
+      "name": "cleanup",
+      "path": "skills/cleanup",
+      "description": "Use when the user wants contract-preserving simplification, anti-slop cleanup, or a final-pass polish after the main decision is made."
+    },
+    {
+      "name": "diagnose",
+      "path": "skills/diagnose",
+      "description": "Use when the user needs failure triage, blocked-lane diagnosis, or root-cause decomposition before the next gate can move."
+    },
     {
       "name": "flow",
       "path": "skills/flow",
@@ -19,18 +34,18 @@
     {
       "name": "maestro",
       "path": "skills/maestro",
-      "description": "Use when the user wants Meta-Architect to choose the best next workflow step, explain why, and recommend the right lane or assignment."
-    },
-    {
-      "name": "meta-architect",
-      "path": "skills/meta-architect",
-      "description": "Use when the user wants the full Meta-Architect workflow inside Codex: architecture-first planning, evidence-backed OSS selection, logic review, security review, DX/UX review, and build readiness without leaving the Codex session."
+      "description": "Use when the user wants the singular Meta-Architect in-session autonomous manager: choose the best next workflow step, manage the fixed gated workflow, and route bounded helper handoffs inside Codex."
     },
     {
       "name": "sage",
       "path": "skills/sage",
       "description": "Use when the user wants evidence-backed technology choices, OSS evaluation, and source-grounded validation of the stack proposed in `$arch`."
     },
+    {
+      "name": "tdd",
+      "path": "skills/tdd",
+      "description": "Use when the user wants regression-first or test-first scaffolding before implementation work expands."
+    },
     {
       "name": "vet",
       "path": "skills/vet",

package/skills/maestro/SKILL.md

@@ -1,11 +1,34 @@
 ---
 name: maestro
-description: "Use when the user wants Meta-Architect to choose the best next workflow step, explain why, and recommend the right lane or assignment."
+description: "Use when the user wants the singular Meta-Architect in-session autonomous manager: choose the best next workflow step, manage the fixed gated workflow, and route bounded helper handoffs inside Codex."
 ---
 
 # Maestro
 
-Use this skill inside Codex when you want Meta-Architect to act like a workflow manager.
+## Overview
+
+Use this skill inside Codex as the singular Meta-Architect umbrella surface and bounded autonomous manager. It inspects workflow state, chooses the smallest safe next step, manages the fixed gated design-and-review sequence one lane at a time, and routes helper handoffs when they are enough. There is no separate shipped `$meta-architect` skill.
+
+## Workflow
+
+1. Inspect the current gate state, active evidence, and current blockers.
+2. Choose the smallest safe next step and decide whether the next move is:
+   - a direct advisory result
+   - a helper-skill handoff
+   - a gated-lane handoff
+3. When the issue is alignment, diagnosis, regression-first execution, or final-pass cleanup, hand work to the publishable but non-gating helper skills:
+   - `$align`
+   - `$diagnose`
+   - `$tdd`
+   - `$cleanup`
+4. When the user wants the full Meta-Architect workflow, manage the fixed gated sequence without inventing new gates or skipping lane ownership:
+   - `$arch`
+   - `$sage`
+   - `$flow`
+   - `$vet`
+   - `$vibe`
+   - `$build`
+5. End with a clear result shape: decision, evidence, blockers, the lane assignment if any, and the exact next trigger.
 
 ## Output
 
@@ -22,4 +45,14 @@ Produce:
 - Prefer the smallest next step that moves the workflow forward safely.
 - Respect current gate state before recommending implementation or release work.
 - Be explicit when more evidence, planning, or validation is still needed.
-- Route to the in-session skill flow first; use helper commands only when they are the clearest support path.
+- Treat the in-session skill flow as primary. Use `ma ...` terminal helpers only when repo-local setup, inspection, or scripted state automation is explicitly the better support path.
+- Keep `$maestro` as the only umbrella surface. It owns next-step management and bounded handoff decisions, but it does not replace the outputs owned by the gated lanes.
+- Helper skills are publishable mirrors, but they are non-gating. They support a lane and then hand control back to `$maestro` or the fixed gated sequence.
+- Do not expand the release-gated sequence for this release. Gate ownership stays with `$arch -> $sage -> $flow -> $vet -> $vibe -> $build`.
+- Stay inside Codex unless the user explicitly asks for repo-local helper commands.
+- Keep the workflow architecture-first. Do not jump into code before the architecture and review lanes are grounded.
+- Use approved discovery accelerators such as Ossium, Trendshift, Dev Hunt, Libraries.io, Open Hub, and Open-source Projects when you need faster OSS candidate discovery, then validate any promising project through upstream repos and official docs.
+- Keep the `$sage` order explicit: known upstream sources first, discovery accelerators second, exact repo mapping third, approval only after upstream verification.
+- Prefer official docs, upstream repos, and repo-configured GitMCP sources when validating tooling choices.
+- For release gates and branch policy, read `references/core-release-rules.md`.
+- For the native helper-family contract and pattern classification, read `references/native-ingest-map.md`.

package/skills/maestro/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "$maestro"
-  short_description: "Best next step and lane orchestration"
-  default_prompt: "Use $maestro to inspect the current Meta-Architect workflow state, choose the best next step, explain why it is next, and recommend the right lane or assignment."
+  short_description: "Bounded autonomous manager for the gated workflow and helper handoffs"
+  default_prompt: "Use $maestro as the singular Meta-Architect in-session autonomous manager: inspect workflow state, choose the smallest safe next step, hand work to $align, $diagnose, $tdd, or $cleanup when a publishable non-gating helper is enough, and manage the fixed gated sequence at $arch, $sage, $flow, $vet, $vibe, and $build without inventing new gates."

package/skills/maestro/references/native-ingest-map.md

@@ -0,0 +1,44 @@
+# Native Ingest Map
+
+Meta-Architect absorbs new pattern families as native product guidance without turning them into new umbrella brands or new release gates.
+
+## Publishable helper skills
+
+- `align`
+  - purpose: scope alignment, shared language, and docs clarity
+  - gate effect: none
+- `diagnose`
+  - purpose: failure decomposition, blocked-lane triage, and root-cause framing
+  - gate effect: none
+- `tdd`
+  - purpose: regression-first and test-first execution scaffolds
+  - gate effect: none
+- `cleanup`
+  - purpose: anti-slop cleanup, prose humanization, and final-pass polish
+  - gate effect: none
+
+## Existing-lane absorption
+
+- `$sage`
+  - owns source selection, upstream validation order, and evidence quality
+  - uses curated native reference packs instead of raw catalog browsing as the product surface
+- `$vet`
+  - owns security/trust-boundary review and security playbook application
+  - absorbs security playbook patterns without creating a second security umbrella
+- `$maestro`
+  - remains the only umbrella surface and bounded autonomous manager
+  - owns next-step recommendation, helper handoff decisions, and fixed-sequence management
+  - does not create new gate states and does not replace the outputs owned by gated lanes
+
+## Fixed gated sequence
+
+The release-owned sequence does not change in this ingest:
+
+1. `$arch`
+2. `$sage`
+3. `$flow`
+4. `$vet`
+5. `$vibe`
+6. `$build`
+
+Helper skills remain publishable but non-gating. They can prepare, unblock, or clean up work around those lanes, but they do not create new gate states and they do not own release-state transitions.

package/skills/sage/SKILL.md

@@ -5,14 +5,16 @@ description: "Use when the user wants evidence-backed technology choices, OSS ev
 
 # Sage
 
-Use this skill inside Codex to verify or challenge stack choices with real sources.
+Use this skill inside Codex to verify or challenge stack choices with real sources. `$sage` remains the evidence gate even as Meta-Architect absorbs more native curation and reference packs.
 
 ## Output
 
 Produce:
 - candidate tools, libraries, or services
+- `decision`, `status`, `evidence`, `blockers`, `next_allowed_triggers`
 - why each option fits or fails the architecture
 - source-backed evidence from official docs, upstream repos, or approved GitMCP sources
+- evidence grade and exact upstream mapping
 - recommendation with tradeoffs
 - unresolved gaps or missing evidence
 - exact next trigger, usually `$flow`
@@ -24,6 +26,7 @@ Produce:
   - use discovery accelerators to find or narrow candidates
   - map the selected candidate back to an exact upstream repo
   - verify against upstream repos and official docs before approving it
+- Use `references/source-selection.md` when you need the native source-selection contract, evidence ladder, or packaged discovery rules.
 - Use approved discovery accelerators when you need faster OSS candidate discovery:
   - Ossium (`https://ossium.live/home`) for trending, curated, YC-backed, and GSoC-linked OSS discovery
   - Trendshift (`https://trendshift.io/`) for rising GitHub engagement and topic momentum
@@ -31,6 +34,7 @@ Produce:
   - Libraries.io (`https://libraries.io/`) for package/dependency metadata, with caution because its public data is scraped and not validated/curated for accuracy
   - Open Hub (`https://openhub.net/`) for project activity, contributor, and comparison signals
   - Open-source Projects (`https://www.opensourceprojects.dev/`) for curated OSS discovery and detailed project writeups
+- Discovery accelerators are candidate-finding tools, not approval surfaces. The user-facing Meta-Architect product stays native even when evidence sources are external.
 - Do not invent package capabilities or maturity claims.
 - Prefer primary sources over summaries when validating technical details.
 - Do not treat discovery listings alone as VERIFIED evidence; promote candidates to upstream repos and official docs before approving them.

package/skills/sage/references/source-selection.md

@@ -0,0 +1,36 @@
+# Source Selection
+
+Use this reference pack inside `$sage` when the repo needs evidence-backed selection without turning raw catalogs into the product surface.
+
+## Evidence order
+
+1. Known upstream repo and official docs
+2. Discovery accelerator to find or narrow candidates
+3. Exact upstream repo mapping for the shortlisted candidate
+4. Upstream repo plus official-doc verification before approval
+
+## Discovery accelerator rules
+
+- Use accelerators to reduce search time, not to replace validation.
+- Treat listings, rankings, and trend signals as hints.
+- Promote any serious candidate to an exact upstream repo before calling it VERIFIED.
+- Keep user-facing guidance in Meta-Architect language rather than echoing catalog branding as if it were a first-class product surface.
+
+## Minimum approval bar
+
+- Exact upstream repo identified
+- Official docs available when relevant
+- Claimed capability verified from a primary source
+- Maturity caveats called out when evidence is weak
+
+## Evidence grades
+
+- `VERIFIED`: exact upstream mapping plus primary-source confirmation
+- `PARTIAL`: candidate is mapped, but live proof or maturity proof is incomplete
+- `MISSING`: no trustworthy exact upstream mapping yet
+
+Always expose the evidence grade and the exact upstream mapping in user-facing `$sage` output.
+
+## Native posture
+
+Meta-Architect ships curated guidance and playbooks. It does not ship a raw mirror of external catalogs. External sources remain evidence inputs, not user-facing skill identities.

package/skills/tdd/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: tdd
+description: "Use when the user wants regression-first or test-first scaffolding before implementation work expands."
+---
+
+# TDD
+
+Use this skill inside Codex when implementation should start by locking behavior with tests. `tdd` is a non-gating helper skill that supports execution once the relevant lane is ready.
+
+## Output
+
+Produce:
+- behavior to lock
+- minimal regression or failing test shape
+- implementation boundary
+- proof that the test belongs to the requested change
+- exact next trigger, usually the implementation lane or `$cleanup`
+
+## Rules
+
+- Prefer the smallest failing test that proves the requested behavior.
+- Lock current behavior before cleanup or refactor work when behavior is not already protected.
+- Do not treat `tdd` as a replacement for the build gate.
+- Keep test intent explicit so the next implementation step stays narrow.

package/skills/tdd/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "$tdd"
+  short_description: "Regression-first and test-first helper"
+  default_prompt: "Use $tdd to define the smallest test that locks the requested behavior before implementation expands."

package/skills/vet/SKILL.md

@@ -5,21 +5,25 @@ description: "Use when the user wants a security and trust-boundary review of th
 
 # Vet
 
-Use this skill inside Codex to review security posture before the build lane.
+Use this skill inside Codex to review security posture before the build lane. `$vet` remains the sole security gate even as Meta-Architect ships deeper native security playbooks.
 
 ## Output
 
 Produce:
+- `decision`, `status`, `evidence`, `blockers`, `next_allowed_triggers`
 - trust boundaries
 - authn/authz expectations
 - sensitive data paths
 - abuse cases and likely failure modes
 - concrete mitigations
+- accepted risks
 - release blockers vs acceptable risks
 - exact next trigger, usually `$vibe`
 
 ## Rules
 
 - Prioritize material risks over exhaustive but low-value checklists.
+- Use `references/security-playbooks.md` when you need the native security playbook set for common trust-boundary reviews.
+- Keep security guidance product-owned and lane-aware. Do not introduce a second umbrella or a separate security release gate.
 - Call out missing assumptions that affect security posture.
 - Distinguish between must-fix blockers and documented accepted risk.

package/skills/vet/references/security-playbooks.md

@@ -0,0 +1,30 @@
+# Security Playbooks
+
+Use this reference pack inside `$vet` for repeatable trust-boundary reviews that stay native to Meta-Architect.
+
+## Core review slices
+
+- identity and session boundaries
+- authorization and tenancy boundaries
+- secret handling and key rotation assumptions
+- dependency and supply-chain trust
+- inbound data validation and outbound data exposure
+- operational abuse cases and failure modes
+
+## How to use the playbooks
+
+- Start with the architecture and evidence already approved by `$arch` and `$sage`.
+- Focus on the highest-risk boundary first.
+- Distinguish blockers from accepted risk.
+- Route remediation back to the owning lane rather than creating a parallel security workflow.
+
+## Adversarial hardening
+
+- For higher-risk changes, run a bounded adversarial hardening pass before final approval.
+- Keep the hardening work inside the private scratchpad/runtime layer.
+- Return structured findings, not direct gate mutations.
+- If the hardening pass cannot resolve or clearly classify the risk, keep `$vet` in a non-terminal state instead of over-approving.
+
+## Product boundary
+
+This pack deepens `$vet`; it does not create a new security skill family. Security patterns are packaged as Meta-Architect guidance, not as mirrored external catalogs or branded upstream surfaces.

package/skills/vibe/SKILL.md

@@ -10,8 +10,10 @@ Use this skill inside Codex to review whether the system will feel coherent for
 ## Output
 
 Produce:
+- `decision`, `status`, `evidence`, `blockers`, `next_allowed_triggers`
 - developer workflow risks
 - user workflow risks
+- operator friction and user friction
 - complexity hotspots
 - onboarding or operability friction
 - simplifications that improve clarity

package/src/bootstrap.js

@@ -2,8 +2,15 @@ import { spawnSync } from "node:child_process";
 import fs from "node:fs/promises";
 import os from "node:os";
 import path from "node:path";
-import { loadMcpServers } from "./mcp-config.js";
-import { getRepoRoot, getRuntimeWritePath, packageRoot } from "./paths.js";
+import { loadDecisionLog } from "./decision-log.js";
+import {
+  runLocalCapabilityReadinessChecks,
+  validateLocalCapabilities,
+  validateMcpServers,
+} from "./mcp-config.js";
+import { getMcpRootPath, getRepoRoot, getRuntimeWritePath, packageRoot } from "./paths.js";
+import { loadReleaseState } from "./release-state.js";
+import { loadLeaderAuthority, loadRuntimeSnapshot } from "./runtime/runtime-state.js";
 import {
   areSkillsInstalled,
   ensureSkillsInstalled,
@@ -32,21 +39,23 @@ function runCommand(command, args) {
 function inspectCodex() {
   const command = resolveCodexCommand();
   const result = runCommand(command, ["--version"]);
-  if (result.error || result.status !== 0) {
-    const detail = result.error?.message ?? result.stderr.trim() ?? result.stdout.trim();
+  const version = result.stdout.trim();
+  if (result.status === 0) {
     return {
-      ok: false,
+      ok: true,
       command,
-      detail: detail || "Codex command failed",
-      version: "",
+      detail: result.error?.message ?? "",
+      version,
     };
   }
 
   return {
-    ok: true,
+    ok: false,
     command,
-    detail: "",
-    version: result.stdout.trim(),
+    detail:
+      (result.error?.message ?? result.stderr.trim() ?? result.stdout.trim()) ||
+      "Codex command failed",
+    version: "",
   };
 }
 
@@ -141,7 +150,36 @@ async function inspectLocalScaffold() {
   const requiredFiles = [
     getRuntimeWritePath("decisions.json"),
     getRuntimeWritePath("release.json"),
-    path.join(getRepoRoot(), "mcp", "servers.json"),
+    getRuntimeWritePath("guidance", "merged.json"),
+    getRuntimeWritePath("guidance", "include-graph.json"),
+    getRuntimeWritePath("context", "active-autonomy-core.json"),
+    getRuntimeWritePath("context", "capability-composition.json"),
+    getRuntimeWritePath("context", "code-graph-rehearse.json"),
+    getRuntimeWritePath("context", "core-source-ingest.json"),
+    getRuntimeWritePath("context", "learning-loop-core.json"),
+    getRuntimeWritePath("context", "obsidian-bridge.json"),
+    getRuntimeWritePath("context", "obsidian-vault-index.json"),
+    getRuntimeWritePath("context", "obsidian-vault-operations.json"),
+    getRuntimeWritePath("context", "prompt-strategy-core.json"),
+    getRuntimeWritePath("context", "recording-core.json"),
+    getRuntimeWritePath("context", "skills-registry-export.json"),
+    getRuntimeWritePath("context", "workspace-virtualizer.json"),
+    getRuntimeWritePath("context", "workspace-context-pack.json"),
+    getRuntimeWritePath("context", "workspace-effectiveness.json"),
+    getRuntimeWritePath("memory", "notes.md"),
+    getRuntimeWritePath("memory", "index.json"),
+    getRuntimeWritePath("hooks", "config.json"),
+    getRuntimeWritePath("hooks", "audit.log"),
+    getRuntimeWritePath("tasks", "registry.json"),
+    getRuntimeWritePath("tasks", "mailbox"),
+    getRuntimeWritePath("tasks", "locks"),
+    getRuntimeWritePath("workspaces", "index.json"),
+    getRuntimeWritePath("state", "manager-runs.json"),
+    getRuntimeWritePath("state", "maestro-state.json"),
+    getRuntimeWritePath("evidence", "semantic-receipts.json"),
+    path.join(getRepoRoot(), "docs", "qa", "release-issue-gates-0.1.13.json"),
+    path.join(getMcpRootPath(), "servers.json"),
+    path.join(getMcpRootPath(), "local-capabilities.json"),
   ];
 
   for (const file of requiredFiles) {
@@ -152,33 +190,55 @@ async function inspectLocalScaffold() {
     }
   }
 
+  try {
+    await loadReleaseState();
+    await loadDecisionLog();
+    const authority = await loadLeaderAuthority();
+    if (authority.state === "invalid") {
+      return false;
+    }
+    const snapshot = await loadRuntimeSnapshot();
+    if (snapshot.missingArtifacts.length > 0 || snapshot.invalidArtifacts.length > 0) {
+      return false;
+    }
+  } catch {
+    return false;
+  }
+
   return true;
 }
 
 async function seedStarterMcpConfig() {
   const files = ["servers.json", "collections.json", "fallback.json"];
   for (const file of files) {
-    await fs.copyFile(path.join(packageRoot, "mcp", file), path.join(getRepoRoot(), "mcp", file));
+    await fs.copyFile(path.join(packageRoot, "mcp", file), path.join(getMcpRootPath(), file));
   }
 }
 
-async function inspectMcpState({ fix, initMcp }) {
+async function seedLocalCapabilityManifest() {
+  await fs.copyFile(
+    path.join(packageRoot, "mcp", "local-capabilities.json"),
+    path.join(getMcpRootPath(), "local-capabilities.json"),
+  );
+}
+
+async function inspectGitMcpState({ fix, initMcp }) {
   try {
-    const servers = await loadMcpServers();
+    const servers = await validateMcpServers();
     if (servers.servers.length === 0) {
       if (fix && initMcp) {
         await seedStarterMcpConfig();
-        const seededServers = await loadMcpServers();
+        const seededServers = await validateMcpServers();
         return makeStatus(
           "FIXED",
-          "starter MCP sources were seeded into mcp/servers.json",
+          "repo-owned GitMCP evidence sources were seeded into mcp/servers.json",
           `${seededServers.servers.length} configured source(s)`,
         );
       }
 
       return makeStatus(
         "WARN",
-        "mcp/servers.json exists but contains no approved repo-backed sources",
+        "repo-owned mcp/servers.json contains no approved GitMCP evidence sources",
         initMcp
           ? "Run `ma bootstrap --init-mcp` to seed starter sources, or add exact upstream GitMCP repo endpoints manually."
           : "Add exact upstream GitMCP repo endpoints before claiming VERIFIED evidence.",
@@ -187,21 +247,74 @@ async function inspectMcpState({ fix, initMcp }) {
 
     return makeStatus(
       "OK",
-      "mcp/servers.json has approved starter sources",
+      "repo-owned mcp/servers.json is ready for GitMCP evidence binding",
       `${servers.servers.length} configured source(s)`,
     );
   } catch (error) {
     if (fix && initMcp) {
       await seedStarterMcpConfig();
-      const seededServers = await loadMcpServers();
+      const seededServers = await validateMcpServers();
       return makeStatus(
         "FIXED",
-        "starter MCP sources replaced an invalid MCP configuration",
+        "repo-owned mcp/servers.json was reseeded with starter GitMCP evidence sources",
         `${seededServers.servers.length} configured source(s)`,
       );
     }
 
-    return makeStatus("WARN", "mcp/servers.json is not ready for evidence binding", error.message);
+    return makeStatus(
+      "WARN",
+      "repo-owned mcp/servers.json is not ready for GitMCP evidence binding",
+      error.message,
+    );
+  }
+}
+
+async function inspectLocalCapabilityState({ fix }) {
+  function summarizeReadiness(readiness) {
+    const notReady = readiness.filter((item) => !item.ready);
+    const allReady = notReady.length === 0;
+    return {
+      allReady,
+      detail: allReady
+        ? readiness.map((item) => item.capability).join(", ")
+        : notReady.map((item) => `${item.capability}: ${item.detail}`).join("; "),
+    };
+  }
+
+  try {
+    await validateLocalCapabilities();
+    const summary = summarizeReadiness(await runLocalCapabilityReadinessChecks());
+    if (!summary.allReady) {
+      return makeStatus(
+        "WARN",
+        "package-owned mcp/local-capabilities.json is valid but some local capabilities are not ready",
+        summary.detail,
+      );
+    }
+
+    return makeStatus(
+      "OK",
+      "package-owned mcp/local-capabilities.json is ready for first-party capabilities",
+      summary.detail,
+    );
+  } catch (error) {
+    if (fix) {
+      await seedLocalCapabilityManifest();
+      const summary = summarizeReadiness(await runLocalCapabilityReadinessChecks());
+      return makeStatus(
+        summary.allReady ? "FIXED" : "WARN",
+        summary.allReady
+          ? "package-owned mcp/local-capabilities.json was reseeded from the bundled SDK"
+          : "package-owned mcp/local-capabilities.json was reseeded but some local capabilities are not ready",
+        summary.detail,
+      );
+    }
+
+    return makeStatus(
+      "WARN",
+      "package-owned mcp/local-capabilities.json is not ready for first-party capabilities",
+      error.message,
+    );
   }
 }
 
@@ -268,10 +381,13 @@ async function runEnvironmentFlow({ fix, initMcp }) {
 
   if (fix) {
     await runInit();
+    const scaffoldReady = await inspectLocalScaffold();
     statuses.push(
       makeStatus(
-        "FIXED",
-        "local Meta-Architect scaffold is ready",
+        scaffoldReady ? "FIXED" : "WARN",
+        scaffoldReady
+          ? "local Meta-Architect scaffold is ready"
+          : "local Meta-Architect scaffold still has invalid runtime artifacts",
         path.join(getRepoRoot(), ".ma"),
       ),
     );
@@ -285,7 +401,8 @@ async function runEnvironmentFlow({ fix, initMcp }) {
     );
   }
 
-  statuses.push(await inspectMcpState({ fix, initMcp }));
+  statuses.push(await inspectGitMcpState({ fix, initMcp }));
+  statuses.push(await inspectLocalCapabilityState({ fix }));
   return statuses;
 }
 

package/src/build-gate.js

@@ -26,10 +26,10 @@ export function evaluateBuildGate(releaseState) {
     });
   }
 
-  if (!["LOCKED", "READY"].includes(releaseState.build_status)) {
+  if (!["LOCKED", "READY", "RUNNING"].includes(releaseState.build_status)) {
     blockers.push({
       field: "build_status",
-      expected: "LOCKED or READY",
+      expected: "LOCKED, READY, or RUNNING",
       actual: releaseState.build_status,
       trigger: "$build",
     });