@jstn-sdk/ma 0.1.12 → 0.1.13

package/data/clone-data.proof.json

@@ -0,0 +1,50 @@
+{
+  "schemaVersion": "1.0.0",
+  "record_type": "clone_data_proof",
+  "product": "Meta-Architect",
+  "package": "@jstn-sdk/ma",
+  "release_version": "0.1.13",
+  "records_as": "production_evidence",
+  "build_evidence": true,
+  "subject": "clone data install and package proof contract",
+  "claims": [
+    {
+      "id": "jsdelivr_posix_installer",
+      "claim": "The recommended POSIX CLI install path is backed by a repository script addressable through jsDelivr.",
+      "evidence": [
+        "scripts/install.sh",
+        "README.md",
+        "docs/getting-started.md",
+        "docs/onboarding.md",
+        "docs/skills.md",
+        "plugins/meta-architect/README.md",
+        "docs/release-spec.md"
+      ]
+    },
+    {
+      "id": "clone_data_artifacts",
+      "claim": "Clone-data proof, ledger, and RVF artifacts exist as package-visible data files.",
+      "evidence": [
+        "data/clone-data.proof.json",
+        "data/clone-data.ledger.json",
+        "data/clone-data.rvf",
+        "package.json files includes data/"
+      ]
+    },
+    {
+      "id": "release_gate_contract",
+      "claim": "Release verification must preserve the jsDelivr installer and canonical npm install command in public install docs.",
+      "evidence": ["scripts/release-verify.js", "npm run release:check"]
+    }
+  ],
+  "verification_commands": [
+    "sh -n scripts/install.sh",
+    "node scripts/release-verify.js",
+    "node --test test/clone-data-artifacts.test.js",
+    "npm run release:check"
+  ],
+  "authority_boundary": {
+    "may_mutate_release_state": false,
+    "authoritative_changes_return_through": "$maestro_or_owning_lane"
+  }
+}

package/data/clone-data.rvf

@@ -0,0 +1,37 @@
+# Clone Data RVF
+
+schemaVersion: 1.0.0
+record_type: clone_data_runtime_verification_file
+product: Meta-Architect
+package: @jstn-sdk/ma
+release_version: 0.1.13
+
+## Purpose
+
+This RVF defines the pass criteria for the clone-data proof and ledger artifacts.
+
+## Required Artifacts
+
+- `data/clone-data.proof.json`
+- `data/clone-data.ledger.json`
+- `data/clone-data.rvf`
+
+## Pass Criteria
+
+- Proof JSON has `record_type: clone_data_proof`.
+- Ledger JSON has `record_type: clone_data_ledger`.
+- Both JSON files use `schemaVersion: 1.0.0`.
+- Both JSON files record as `production_evidence`.
+- Ledger entries reference all required clone-data artifacts.
+- `package.json` includes `data/` so clone-data artifacts are visible in package dry-runs.
+- `scripts/install.sh` remains POSIX-shell syntax valid.
+- Public install docs preserve the jsDelivr one-line installer.
+
+## Verification Commands
+
+```bash
+sh -n scripts/install.sh
+node scripts/release-verify.js
+node --test test/clone-data-artifacts.test.js
+npm run release:check
+```

package/docs/README.md

@@ -5,6 +5,8 @@ Meta-Architect documentation is organized by operator task.
 ## Start here
 
 - [Getting Started](./getting-started.md)
+- [Production Demo Guide](../DEMO.md)
+- [Coverage Matrix](../COVERAGE.md)
 - [Release Spec](./release-spec.md)
 - [Skills Reference](./skills.md)
 - umbrella, gated lanes, and helper skill distinctions live in the Skills Reference
@@ -20,7 +22,8 @@ Meta-Architect documentation is organized by operator task.
 
 ## QA and readiness
 
-- [Release Readiness 0.1.12](./qa/release-readiness-0.1.12.md)
+- [Release Readiness 0.1.13](./qa/release-readiness-0.1.13.md)
+- [Release Issue Gates 0.1.13](./qa/release-issue-gates-0.1.13.json)
 
 ## Repo structure references
 

package/docs/getting-started.md

@@ -22,6 +22,15 @@ By the end of this guide you should be able to:
 
 ## 1. Default install and launch
 
+Recommended CLI install for macOS, Linux, WSL, and Git-Bash:
+
+```bash
+# One-line install (POSIX shells only; use WSL/Git-Bash on Windows)
+curl -fsSL https://cdn.jsdelivr.net/gh/JustineDevs/meta-architect@main/scripts/install.sh | sh
+```
+
+The jsDelivr installer runs `npm i -g @openai/codex@latest @jstn-sdk/ma@latest`, then `ma setup`.
+
 Debian-family install:
 
 ```bash
@@ -56,7 +65,7 @@ npm uninstall -g @jstn-sdk/ma
 npm uninstall -g @jstn-sdk/ma @openai/codex
 ```
 
-Linux-native distro packages are the default install surface. The npm path remains a supported fallback. The product experience is still the in-session skill workflow in [example/usage-workflow.md](../example/usage-workflow.md). The `ma` command is only a helper for starting or supporting that flow.
+The jsDelivr CLI installer is the recommended quick-start path for POSIX shells. Linux-native distro packages remain supported release assets, and the npm path remains the canonical package install underneath the installer. The product experience is still the in-session skill workflow in [example/usage-workflow.md](../example/usage-workflow.md). The `ma` command is only a helper for starting or supporting that flow.
 
 ## 2. Real usage workflow
 
@@ -92,7 +101,7 @@ Required output:
 5. Data model and storage choices
 6. Auth/security considerations
 7. DX/UX considerations
-8. Delivery plan for v0.1.12
+8. Delivery plan for v0.1.13
 9. Risks and trade-offs
 10. Decision log
 11. Exact next trigger to run after this
@@ -282,7 +291,7 @@ See [docs/mcp-setup.md](./mcp-setup.md) for endpoint policy and evidence semanti
 ## 6. Secondary helper flow
 
 ```bash
-ma idea "Build a real-time collaborative whiteboard for product teams"
+ma idea "Prepare Meta-Architect v0.1.13 for a production package release with real install docs, Obsidian brain-context support, learning-loop reliability, and package proof artifacts."
 ```
 
 Expected effects:
@@ -295,7 +304,7 @@ If this fails:
 
 ## 7. Run the helper skill sequence
 
-### 5.0 Autonomous manager
+### 7.1 Autonomous manager
 
 ```bash
 ma run '$maestro'
@@ -320,7 +329,7 @@ Optional non-gating helper skills that can run before or between gated lanes:
 - `$tdd` for regression-first execution setup
 - `$cleanup` for simplification and final-pass polish
 
-### 5.1 Architecture
+### 7.2 Architecture
 
 ```bash
 ma run '$arch'
@@ -337,7 +346,7 @@ Generated or updated:
 - `.ma/specs/architecture.md`
 - `.ma/plans/implementation.md`
 
-### 5.2 Evidence
+### 7.3 Evidence
 
 ```bash
 ma run '$sage'
@@ -366,7 +375,7 @@ If this fails:
 - verify network access
 - rerun after correcting the endpoint or environment
 
-### 5.3 Logic
+### 7.4 Logic
 
 ```bash
 ma run '$flow'
@@ -380,7 +389,7 @@ Expected effects:
 Generated or updated:
 - `.ma/specs/logic.md`
 
-### 5.4 Security
+### 7.5 Security
 
 ```bash
 ma run '$vet'
@@ -394,7 +403,7 @@ Expected effects:
 Generated or updated:
 - `.ma/specs/security.md`
 
-### 5.5 Experience
+### 7.6 Experience
 
 ```bash
 ma run '$vibe'
@@ -463,11 +472,11 @@ If `$build` fails:
 - fix the corresponding upstream lane
 - rerun that lane, then rerun `$build`
 
-## 10. Example walkthrough: collaborative whiteboard
+## 10. Example walkthrough: MA release hardening
 
 ```bash
 ma setup
-ma idea "Build a collaborative whiteboard with live cursors and shared boards"
+ma idea "Prepare Meta-Architect v0.1.13 for a production package release with real install docs, Obsidian brain-context support, learning-loop reliability, and package proof artifacts."
 ma run '$arch'
 ma run '$sage'
 ma run '$flow'
@@ -480,17 +489,17 @@ ma run '$build'
 If you want an interactive Codex session during the walkthrough, start it separately with `ma`.
 
 What should happen:
-- `$arch` records a structured first-pass blueprint
-- `$sage` binds major choices to configured GitMCP-backed sources
-- `$flow` records the kernel’s baseline state review for the mission
-- `$vet` records a baseline security review
-- `$vibe` records baseline DX/UX guidance
-- `$build` suggests bounded concerns like `feature/implementation` and `feature/verification`
+- `$arch` records the architecture and release-hardening blueprint
+- `$sage` binds package, Obsidian, prompt-strategy, and MCP choices to configured evidence sources
+- `$flow` records state-transition and gate-order review
+- `$vet` records security, package exposure, and provider-bound context review
+- `$vibe` records operator/demo/docs usability guidance
+- `$build` suggests bounded implementation and verification branches after gates pass
 
-Related mission:
-- [missions/collaborative-whiteboard/mission.md](../missions/collaborative-whiteboard/mission.md)
+Canonical demo reference:
+- [DEMO.md](../DEMO.md)
 
-## 9. Merge and release path
+## 11. Merge and release path
 
 After implementation work is complete:
 
@@ -507,7 +516,7 @@ Expected effects:
   - `merge_status = MERGED_TO_DEVELOPMENT`
   - `release_status = SHIPPED_TO_PROD`
 
-## 10. Files generated or updated during a normal run
+## 12. Files generated or updated during a normal run
 
 - `.ma/decisions.json`
 - `.ma/release.json`
@@ -516,6 +525,13 @@ Expected effects:
 - `.ma/evidence/cves.json`
 - `.ma/evidence/outcomes.json`
 - `.ma/context/project.md`
+- `.ma/context/recording-core.json`
+- `.ma/context/learning-loop-core.json`
+- `.ma/context/workspace-context-pack.json`
+- `.ma/context/workspace-effectiveness.json`
+- `.ma/context/prompt-strategy-core.json`
+- `.ma/context/context-economy-core.json`
+- `.ma/context/obsidian-bridge.json`
 - `.ma/specs/architecture.md`
 - `.ma/specs/evidence.md`
 - `.ma/specs/logic.md`
@@ -527,7 +543,7 @@ Expected effects:
 
 These are local product artifacts created by the runtime. They are not a reason to bypass gate logic manually.
 
-## 11. If a gate fails
+## 13. If a gate fails
 
 Rule:
 - do not edit statuses manually

package/docs/mcp-setup.md

@@ -69,9 +69,44 @@ To move from discovery to VERIFIED evidence:
 - map that repo to an exact `https://gitmcp.io/{owner}/{repo}` endpoint in `mcp/servers.json`
 - validate the choice against the upstream repo and official docs through `$sage`
 
+## Remote MCP transport
+
+`$sage` opens configured GitMCP endpoints as live MCP servers. Some remote MCP hosts reject direct SSE probes with HTTP 405 and require a host-supported remote MCP bridge. Meta-Architect treats that as a transport blocker, not as verified evidence.
+
+To enable bridge-backed live verification, configure a trusted local bridge command:
+
+```bash
+export MA_MCP_REMOTE_BRIDGE_CMD="mcp-remote {url}"
+```
+
+The `{url}` placeholder is replaced with the exact repo endpoint from `mcp/servers.json`. Use a preinstalled, trusted bridge binary or wrapper; do not depend on automatic package downloads in production verification.
+
+When no bridge is configured:
+- direct-SSE-compatible MCP servers can still verify normally
+- GitMCP 405 responses are recorded as bridge-required blockers
+- `evidence_status` remains `PARTIAL`, so `$flow` and `$build` stay locked
+
 ## Separation of concerns
 
 - `mcp/servers.json` remains for repo-specific GitMCP evidence sources
 - `mcp/collections.json` remains GitMCP-oriented evidence categorization for this release
 - `mcp/local-capabilities.json` is the first-party in-process capability registry
 - `mcp/native-playbooks.json` is internal native curation metadata, not an upstream mirror or user-edited evidence source list
+
+## Current semantic source routing
+
+`mcp/collections.json` maps configured repository evidence into MA lanes.
+The current release intentionally includes both broad discovery lists and core-specific upstream sources.
+
+| Collection | Why it exists | Typical lanes |
+| --- | --- | --- |
+| `meta-list` and language collections | broad OSS candidate discovery before exact upstream selection | `$arch`, `$sage` |
+| `system-design` | architecture and flow reasoning references | `$arch`, `$sage`, `$flow`, `$build` |
+| `security` | trust-boundary and security review evidence | `$vet` |
+| `obsidian-api-docs` | Obsidian API evidence for vault, metadata, workspace, and plugin behavior | `$arch`, `$sage`, `$vibe` |
+| `obsidian-plugin-scaffold` | compatibility reference for MA's in-app Obsidian plugin surface | `$arch`, `$sage` |
+| `context-economy` | context-budget and terse-output source evidence | `$sage`, `$vet`, `$vibe`, `$build` |
+| `prompt-techniques` | prompt strategy source evidence for MA-owned prompt policies | `$arch`, `$sage`, `$flow`, `$vet`, `$vibe`, `$build` |
+
+Obsidian-derived notes remain `vault_context`.
+They do not count as `build_evidence` unless `$sage`, `$vet`, or another owning lane promotes a specific claim with source-backed proof.

package/docs/onboarding.md

@@ -12,6 +12,15 @@ This is the shortest entrypoint for the real first-run Meta-Architect path.
 
 ## Canonical install and start
 
+Recommended CLI install for macOS, Linux, WSL, and Git-Bash:
+
+```bash
+# One-line install (POSIX shells only; use WSL/Git-Bash on Windows)
+curl -fsSL https://cdn.jsdelivr.net/gh/JustineDevs/meta-architect@main/scripts/install.sh | sh
+```
+
+The installer uses jsDelivr to fetch this repo's POSIX install script and runs the canonical npm install path.
+
 ```bash
 # Install
 npm i -g @openai/codex@latest @jstn-sdk/ma@latest
@@ -28,7 +37,13 @@ npm uninstall -g @jstn-sdk/ma @openai/codex
 
 ## First runtime action
 
-Start with the structured `$arch` prompt from [example/usage-workflow.md](../example/usage-workflow.md):
+Start with `$maestro` when you want MA to choose and drive the next safe lane:
+
+```text
+$maestro
+```
+
+Use the structured `$arch` prompt from [example/usage-workflow.md](../example/usage-workflow.md) when you already know the project brief and want to begin directly with architecture:
 
 ```text
 $arch I want to build: [PROJECT IDEA]
@@ -48,7 +63,8 @@ Only use this when you need local repo scaffolding or scripted validation:
 ```bash
 ma setup
 ma
-ma idea "..."
+ma idea "Prepare Meta-Architect v0.1.13 for a production package release with real install docs, Obsidian brain-context support, learning-loop reliability, and package proof artifacts."
+ma run '$maestro'
 ma run '$arch'
 ma run '$sage'
 ma run '$flow'

package/docs/prompt-guidance-contract.md

@@ -0,0 +1,17 @@
+# Prompt Guidance Contract
+
+Meta-Architect prompt surfaces must preserve the Active Autonomy Core contract.
+
+## Required Patterns
+
+1. `AUTO-CONTINUE` and `ASK` must be named explicitly.
+2. The `ASK` list is closed: destructive, irreversible, credential-gated, external-production, materially scope-changing, or missing authority.
+3. Permission-handoff phrasing is banned on AUTO-CONTINUE branches.
+4. Skills and role prompts must describe completion as a loop with explicit stop conditions.
+5. Workflow terminal replies must name an outcome: `finished`, `blocked`, `failed`, `cancelled`, or `askuserQuestion`.
+6. Completion claims require fresh verification evidence or an explicit validation gap.
+7. Runtime hook policy must include stall-pattern coverage for passive permission handoffs.
+
+## Contributor Rule
+
+Do not weaken the anti-passive contract when editing prompts, skills, hooks, or exported host payloads. If a prompt surface cannot execute safely, it must name the exact closed-list ASK reason instead of asking a vague permission question.

package/docs/prompt-guidance-fragments/active-autonomy-core.md

@@ -0,0 +1,7 @@
+<!-- ACTIVE AUTONOMY CORE - DO NOT REMOVE -->
+- AUTO-CONTINUE: clear, already-requested, local/workspace-scoped, low-risk, reversible, non-destructive work with an available verification path. Continue executing, inspecting, editing, testing, and verifying without permission handoff.
+- ASK only for destructive, irreversible, credential-gated, external-production, materially scope-changing actions, or when missing authority blocks progress.
+- On AUTO-CONTINUE branches, do not say "Should I proceed?", "Would you like me to continue?", "If you want, I can ...", or equivalent permission-handoff phrasing. State the next action or evidence-backed result.
+- Do not instruct humans to perform ordinary safe reversible workspace actions; execute them through MA/runtime tools and report evidence.
+- Completion requires a terminal outcome (`finished`, `blocked`, `failed`, `cancelled`, or `askuserQuestion`) plus fresh verification evidence or an explicit validation gap.
+<!-- END ACTIVE AUTONOMY CORE -->