@jstn-sdk/ma 0.1.11 → 0.1.13

package/src/state-sync.js

@@ -1,15 +1,58 @@
-import { loadDecisionLog, updateDecisionStatuses } from "./decision-log.js";
-import { loadReleaseState, saveReleaseState } from "./release-state.js";
+import { loadDecisionLog } from "./decision-log.js";
+import { writeJson } from "./fs-utils.js";
+import { getRuntimeWritePath } from "./paths.js";
+import { allowedStatuses, loadReleaseStateOrDefault, saveReleaseState } from "./release-state.js";
+import { loadManagerRunRegistryOrDefault } from "./runtime/maestro-manager.js";
+import { guardLeaderMutation } from "./runtime/runtime-state.js";
 
-export async function syncStatusUpdates(statusUpdates) {
-  const release = await loadReleaseState();
+const publicStatusFields = new Set(Object.keys(allowedStatuses));
+
+function validatePublicStatusUpdates(statusUpdates) {
+  if (!statusUpdates || typeof statusUpdates !== "object" || Array.isArray(statusUpdates)) {
+    throw new Error("Status updates must be an object");
+  }
+
+  const invalidFields = Object.keys(statusUpdates).filter(
+    (field) => !publicStatusFields.has(field),
+  );
+  if (invalidFields.length > 0) {
+    throw new Error(`Unknown release status field(s): ${invalidFields.join(", ")}`);
+  }
+}
+
+export async function syncStatusUpdates(statusUpdates, options = {}) {
+  validatePublicStatusUpdates(statusUpdates);
+  const guard = await guardLeaderMutation({
+    actor: options.actor,
+    kind: "release-status-update",
+    payload: statusUpdates,
+  });
+  if (!guard.allowed) {
+    return { proposed: true, proposalPath: guard.proposalPath };
+  }
+
+  const [release, decisions] = await Promise.all([loadReleaseStateOrDefault(), loadDecisionLog()]);
   const nextRelease = { ...release, ...statusUpdates };
   await saveReleaseState(nextRelease);
-  await updateDecisionStatuses(statusUpdates);
-  return nextRelease;
+
+  try {
+    for (const [field, value] of Object.entries(statusUpdates)) {
+      decisions[field] = value;
+    }
+    await writeJson(getRuntimeWritePath("decisions.json"), decisions);
+  } catch (error) {
+    await saveReleaseState(release);
+    throw error;
+  }
+
+  return { proposed: false, proposalPath: null, release: nextRelease };
 }
 
 export async function loadCombinedState() {
-  const [release, decisions] = await Promise.all([loadReleaseState(), loadDecisionLog()]);
-  return { release, decisions };
+  const [release, decisions, managerRuns] = await Promise.all([
+    loadReleaseStateOrDefault(),
+    loadDecisionLog(),
+    loadManagerRunRegistryOrDefault(),
+  ]);
+  return { release, decisions, managerRuns };
 }

package/docs/qa/release-readiness-0.1.11.md

@@ -1,79 +0,0 @@
-# Release Readiness 0.1.11
-
-## Production bar
-
-`v0.1.11` is treated as production only when:
-- the package installs cleanly from the canonical public install command
-- the Codex-hosted runtime path works end to end
-- the helper flow remains valid for scripted verification
-- release docs, package metadata, and workflows all agree on `0.1.11`
-
-Target release state:
-- npm package: `@jstn-sdk/ma@0.1.11`
-- npm registry state: pending publish
-- publishability note: `0.1.10` is already published, so `0.1.11` is the next publishable package line
-- git tag: `v0.1.11`
-- GitHub release: pending publish for `v0.1.11`
-
-## Production checklist
-
-- skills-first product identity: PASS
-- package/plugin identity aligned to `@jstn-sdk/ma`: PASS
-- version/tag alignment `0.1.11` / `v0.1.11`: PASS
-- install/uninstall docs aligned: PASS
-- onboarding is concise and sequential: PASS
-- helper command documented as secondary: PASS
-- skills/prompts/manifests aligned: PASS
-- packaging includes required assets: PASS
-- tests pass: PASS
-- package dry-run passes: PASS
-- installed-package behavior passes: PASS
-- workflow/release/provenance docs aligned: PASS
-- no stale package names remain in tracked repo surfaces: PASS
-- no conflicting CLI-first product story remains in tracked product docs: PASS
-
-## Automated checks run
-
-```bash
-npm run release:check
-```
-
-That must cover:
-- skills manifest generation
-- skill validation
-- skill bundle packaging
-- repo checks
-- automated tests
-- npm package dry-run inspection
-
-## Manual/behavioral checks run
-
-Canonical launch:
-
-```bash
-ma --madmax --high
-```
-
-Helper-path validation:
-
-```bash
-ma setup
-ma idea "Build a demo app"
-ma run '$arch'
-ma run '$sage'
-ma run '$flow'
-ma run '$vet'
-ma run '$vibe'
-ma status
-ma run '$build'
-```
-
-Expected evidence:
-- `.ma/release.json` remains the source of truth
-- `.ma/decisions.json` records the helper-path activity
-- `$build` stays blocked until upstream gates are green, then becomes ready
-
-## Known limitations
-
-- interactive Codex conversation quality depends on the installed Codex host
-- release publication still depends on npm ownership/authorization for the target package name

package/plugins/meta-architect/skills/meta-architect/SKILL.md

@@ -1,32 +0,0 @@
----
-name: 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."
----
-
-# Meta-Architect
-
-## Overview
-
-Run the full Meta-Architect workflow inside Codex. Use this skill when the user wants the gated design-and-review sequence rather than a single specialist lane.
-
-## Workflow
-
-1. Start with `$arch` and turn the user's goal into a concrete architecture brief.
-2. Continue with `$sage` to validate core stack choices against official docs or approved repo-backed sources.
-3. Run `$flow` to map states, transitions, invariants, and blockers.
-4. Run `$vet` to review trust boundaries, auth, data handling, and abuse paths.
-5. Run `$vibe` to review developer and user experience quality.
-6. Finish with `$build` to decide whether implementation is ready, what remains blocked, and what the exact next execution step should be.
-
-## Rules
-
-- 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.
-- End each lane with a clear result shape: decision, evidence, blockers, and exact next trigger.
-
-## References
-
-- For release gates and branch policy, read `references/core-release-rules.md`.

package/plugins/meta-architect/skills/meta-architect/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "$meta-architect"
-  short_description: "Full Meta-Architect skill workflow"
-  default_prompt: "Use $meta-architect to run the full Meta-Architect workflow inside Codex, then route through $arch, $sage, $flow, $vet, $vibe, and $build as needed."

package/skills/meta-architect/SKILL.md

@@ -1,32 +0,0 @@
----
-name: 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."
----
-
-# Meta-Architect
-
-## Overview
-
-Run the full Meta-Architect workflow inside Codex. Use this skill when the user wants the gated design-and-review sequence rather than a single specialist lane.
-
-## Workflow
-
-1. Start with `$arch` and turn the user's goal into a concrete architecture brief.
-2. Continue with `$sage` to validate core stack choices against official docs or approved repo-backed sources.
-3. Run `$flow` to map states, transitions, invariants, and blockers.
-4. Run `$vet` to review trust boundaries, auth, data handling, and abuse paths.
-5. Run `$vibe` to review developer and user experience quality.
-6. Finish with `$build` to decide whether implementation is ready, what remains blocked, and what the exact next execution step should be.
-
-## Rules
-
-- 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.
-- End each lane with a clear result shape: decision, evidence, blockers, and exact next trigger.
-
-## References
-
-- For release gates and branch policy, read `references/core-release-rules.md`.

package/skills/meta-architect/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "$meta-architect"
-  short_description: "Full Meta-Architect skill workflow"
-  default_prompt: "Use $meta-architect to run the full Meta-Architect workflow inside Codex, then route through $arch, $sage, $flow, $vet, $vibe, and $build as needed."