@jstn-sdk/ma 0.1.11 → 0.1.12

package/docs/getting-started.md

@@ -20,9 +20,27 @@ By the end of this guide you should be able to:
 - an MCP-capable runtime
 - network access if you want live `$sage` verification against a real GitMCP server
 
-## 1. Canonical install and launch
+## 1. Default install and launch
 
-Canonical public install:
+Debian-family install:
+
+```bash
+sudo apt install ./meta-architect_<version>_all.deb
+```
+
+Arch-family install:
+
+```bash
+sudo pacman -U ./meta-architect-<version>-1-any.pkg.tar.xz
+```
+
+Fedora/openSUSE install:
+
+```bash
+sudo dnf install ./meta-architect-<version>-1.noarch.rpm
+```
+
+Default supported npm fallback:
 
 ```bash
 # Install
@@ -38,11 +56,11 @@ npm uninstall -g @jstn-sdk/ma
 npm uninstall -g @jstn-sdk/ma @openai/codex
 ```
 
-That is the default product path. The product experience is 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.
+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.
 
 ## 2. Real usage workflow
 
-Start with the structured `$arch` prompt:
+Start with `$maestro` when you want the bounded autonomous manager to inspect the workflow state and choose the next step. Start with the structured `$arch` prompt when you already know architecture is the next gated lane:
 
 ```text
 $arch I want to build: [PROJECT IDEA]
@@ -74,7 +92,7 @@ Required output:
 5. Data model and storage choices
 6. Auth/security considerations
 7. DX/UX considerations
-8. Delivery plan for v0.1.11
+8. Delivery plan for v0.1.12
 9. Risks and trade-offs
 10. Decision log
 11. Exact next trigger to run after this
@@ -92,6 +110,17 @@ $build
 
 Use the full prompt blocks from [example/usage-workflow.md](../example/usage-workflow.md) when you want the exact handoff format between lanes.
 
+Optional helper skills around that path:
+
+```text
+$align
+$diagnose
+$tdd
+$cleanup
+```
+
+These helpers are publishable skills, but they do not change gate ownership, move release states, or replace the fixed release sequence.
+
 ## 3. Contributor clone and link
 
 ```bash
@@ -150,6 +179,8 @@ Meta-Architect works in two simple ways:
 - terminal commands
 - in-session skills
 
+The umbrella in-session entry point is `$maestro`. The package does not ship a separate `$meta-architect` skill surface.
+
 Terminal commands are normal shell commands:
 
 ```bash
@@ -170,12 +201,22 @@ $flow
 $vet
 $vibe
 $build
+$align
+$diagnose
+$tdd
+$cleanup
 ```
 
 Easy rule:
 - `ma ...` = terminal helper command
 - `$...` = in-session skill
 
+Contract split:
+- terminal helper commands support setup, local state, and scripted verification
+- in-session skills are the product workflow surface
+- `$maestro` is the only umbrella surface inside the session
+- `$align`, `$diagnose`, `$tdd`, and `$cleanup` stay publishable but non-gating
+
 `ma setup` and `ma init` currently do the same thing:
 - they create local `.ma/` support files
 - they prepare context, specs, plans, evidence, and runbook files
@@ -205,16 +246,16 @@ Minimum live example:
 
 ```json
 {
-  "category": "meta-list",
-  "repo": "sindresorhus/awesome",
-  "endpoint": "https://gitmcp.io/sindresorhus/awesome"
+  "category": "candidate",
+  "repo": "owner/repo",
+  "endpoint": "https://gitmcp.io/owner/repo"
 }
 ```
 
-Recommended first set:
-- `sindresorhus/awesome`
-- `dzharii/awesome-typescript`
-- `sbilly/awesome-security`
+Recommended source-selection posture:
+- use the packaged native references to narrow candidate families first
+- map serious candidates to exact upstream GitMCP repo endpoints
+- verify final choices against upstream repos and official docs before treating them as approved evidence
 
 Core discovery standard:
 - use `https://ossium.live/home` to find trending OSS, curated repos, YC-backed repos, GSoC orgs, and contribution leads faster than browsing GitHub directly
@@ -225,6 +266,11 @@ Core discovery standard:
 - use `https://www.opensourceprojects.dev/` to inspect curated OSS selections and detailed project writeups
 - move any promising discovery result into `mcp/servers.json` as an exact upstream GitMCP repo endpoint before treating it as VERIFIED evidence
 
+Useful native reference packs:
+- `skills/maestro/references/native-ingest-map.md`
+- `skills/sage/references/source-selection.md`
+- `skills/vet/references/security-playbooks.md`
+
 Canonical `$sage` order:
 - known upstream repo/docs first
 - discovery accelerators second
@@ -249,7 +295,7 @@ If this fails:
 
 ## 7. Run the helper skill sequence
 
-### 5.0 Workflow manager
+### 5.0 Autonomous manager
 
 ```bash
 ma run '$maestro'
@@ -257,7 +303,10 @@ ma run '$maestro'
 
 Expected effects:
 - reads the current gate state
-- recommends the best next step
+- acts as the bounded umbrella in-session workflow manager
+- recommends the best next step or lane assignment
+- can hand work to a publishable non-gating helper skill when that is enough
+- does not move release gates by itself
 - writes `.ma/plans/maestro.md`
 - records an advisory decision entry
 
@@ -265,6 +314,12 @@ Generated or updated:
 - `.ma/decisions.json`
 - `.ma/plans/maestro.md`
 
+Optional non-gating helper skills that can run before or between gated lanes:
+- `$align` for scope/language cleanup
+- `$diagnose` for blocked-lane triage
+- `$tdd` for regression-first execution setup
+- `$cleanup` for simplification and final-pass polish
+
 ### 5.1 Architecture
 
 ```bash
@@ -395,11 +450,11 @@ Expected output shape:
 ```text
 Build gate is green.
 Suggested branches:
-- feature/ui
-- feature/api
+- feature/implementation
+- feature/verification
 Optional worktree commands:
-git worktree add ../ui feature/ui
-git worktree add ../api feature/api
+git worktree add ../implementation feature/implementation
+git worktree add ../verification feature/verification
 ```
 
 If `$build` fails:
@@ -430,7 +485,7 @@ What should happen:
 - `$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/ui` and `feature/api`
+- `$build` suggests bounded concerns like `feature/implementation` and `feature/verification`
 
 Related mission:
 - [missions/collaborative-whiteboard/mission.md](../missions/collaborative-whiteboard/mission.md)

package/docs/installed-sdk.md

@@ -7,6 +7,8 @@ Meta-Architect installs two things into the active Codex home:
 
 The support bundle exists so skills and helper paths can use relevant packaged files without guessing where they live.
 
+The singular umbrella in-session skill is `maestro`. It is the bounded autonomous manager for the in-session workflow, and the installed skill set does not include a separate `meta-architect` skill folder.
+
 ## Canonical support bundle path
 
 Default:
@@ -30,12 +32,15 @@ ma sdk-path
 ## What is installed there
 
 - `mcp/`
+- `mcp/native-playbooks.json`
+- `mcp/local/playbooks.js`
 - `sprint/`
 - `prompts/`
 - `scripts/`
 - `plugins/meta-architect/`
 - `templates/`
 - `docs/README.md`
+- `docs/reference/` when packaged native reference packs are present
 - `asset-manifest.json`
 
 ## Why this exists
@@ -51,10 +56,28 @@ When Meta-Architect needs packaged support files, prefer the installed support b
 
 Examples:
 - MCP starter files -> `meta-architect-sdk/mcp/`
+- native playbooks manifest -> `meta-architect-sdk/mcp/native-playbooks.json`
+- read-only playbooks capability module -> `meta-architect-sdk/mcp/local/playbooks.js`
 - sprint references -> `meta-architect-sdk/sprint/`
 - Codex prompt assets -> `meta-architect-sdk/prompts/`
 - helper scripts -> `meta-architect-sdk/scripts/`
 - plugin metadata -> `meta-architect-sdk/plugins/meta-architect/`
 - templates -> `meta-architect-sdk/templates/`
+- bundled reference packs -> `meta-architect-sdk/docs/reference/`
 
 The in-session skill flow is still primary. This bundle only standardizes packaged asset access.
+
+Surface split:
+- in-session skills consume these packaged assets as product workflow inputs
+- terminal helper commands may inspect or scaffold against the same bundle, but they remain secondary support tooling
+- helper skills remain publishable and installable, but they do not own release-gate transitions
+
+## Playbooks contract
+
+`playbooks` is a first-party read-only local capability. Its packaged inputs live in the support bundle:
+
+- `mcp/native-playbooks.json` is the repo-owned curation manifest
+- `mcp/local/playbooks.js` is the packaged read-only resource surface
+- `docs/reference/` is where bundled native reference packs land when the release includes them
+
+Readiness should treat those assets as package-owned bundle contents, not as repo-local user setup steps or upstream mirrors.

package/docs/mcp-setup.md

@@ -3,7 +3,29 @@
 1. Use approved discovery accelerators when you need to find OSS candidates faster than browsing GitHub directly.
 2. Add repo-specific GitMCP endpoints in `mcp/servers.json` for any project you want to treat as approved evidence.
 3. Confirm categories in `mcp/collections.json`.
-4. Use `https://gitmcp.io/docs` only when no approved exact endpoint exists.
+4. Do not add `https://gitmcp.io/docs` to `mcp/servers.json`; verified evidence requires exact repo-form GitMCP endpoints only.
+
+## First-party local capabilities
+
+`mcp/local-capabilities.json` is separate from `mcp/servers.json`. It is the allowlist for Meta-Architect's packaged local capabilities:
+
+- `_state`
+- `memory`
+- `trace`
+- `team_run`
+- `code_intel`
+- `playbooks`
+
+`playbooks` is a read-only packaged capability. It does not point at external MCP servers and it does not repurpose `mcp/collections.json`.
+
+Its contract for this release is:
+
+- manifest: `mcp/native-playbooks.json`
+- module: `mcp/local/playbooks.js`
+- transport: `inproc`
+- behavior: packaged resource reads only, no mutating local tools
+
+If bootstrap or doctor reports a `playbooks` readiness warning, repair the packaged support bundle inputs rather than adding more GitMCP sources.
 
 ## Discovery vs verification
 
@@ -46,3 +68,10 @@ To move from discovery to VERIFIED evidence:
 - identify the upstream GitHub repository or official package/docs source from the discovery surface
 - 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`
+
+## 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

package/docs/qa/{release-readiness-0.1.11.md → release-readiness-0.1.12.md}

@@ -1,30 +1,35 @@
-# Release Readiness 0.1.11
+# Release Readiness 0.1.12
 
 ## Production bar
 
-`v0.1.11` is treated as production only when:
+`v0.1.12` 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`
+- the singular `$maestro` umbrella and helper-skill contract stay coherent
+- release docs, package metadata, and workflows all agree on `0.1.12`
 
 Target release state:
-- npm package: `@jstn-sdk/ma@0.1.11`
+- npm package: `@jstn-sdk/ma@0.1.12`
 - 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`
+- publishability note: this branch is prepared for the next publishable package line, `0.1.12`
+- git tag: `v0.1.12`
+- GitHub release: pending publish for `v0.1.12`
 
 ## 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
+- version/tag alignment `0.1.12` / `v0.1.12`: 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
+- Linux native package release lane wired: PASS
+- singular `$maestro` umbrella surface: PASS
+- helper skill family shipped but non-gating: PASS
+- native playbooks and support-bundle reference assets aligned: PASS
 - tests pass: PASS
 - package dry-run passes: PASS
 - installed-package behavior passes: PASS
@@ -46,6 +51,20 @@ That must cover:
 - automated tests
 - npm package dry-run inspection
 
+Linux-native release lane:
+
+```bash
+npm run linux:packages:build
+npm run linux:packages:smoke
+npm run release:assets
+```
+
+That should prove:
+- the Debian-family, Arch-family, and Fedora/openSUSE-style package artifacts are produced
+- the extracted package payload exposes a working `ma` command
+- the GitHub release asset set is complete
+- the packaged support bundle contains the playbooks and reference assets expected by the runtime
+
 ## Manual/behavioral checks run
 
 Canonical launch:
@@ -71,6 +90,8 @@ ma run '$build'
 Expected evidence:
 - `.ma/release.json` remains the source of truth
 - `.ma/decisions.json` records the helper-path activity
+- `$maestro` remains the only umbrella surface
+- helper skills remain non-gating
 - `$build` stays blocked until upstream gates are green, then becomes ready
 
 ## Known limitations

package/docs/reference/native-engineering-patterns.md

@@ -0,0 +1,35 @@
+# Native Engineering Patterns
+
+Meta-Architect internalizes recurring engineering patterns as native product guidance rather than shipping upstream catalogs as first-class surfaces.
+
+## Helper-skill mapping
+
+- `align`
+  - shared language
+  - ambiguity reduction
+  - documentation clarity
+- `diagnose`
+  - failure slicing
+  - blocked-lane triage
+  - root-cause decomposition
+- `tdd`
+  - regression-first execution
+  - failing-test-first loops
+  - behavior locking
+- `cleanup`
+  - anti-slop cleanup
+  - prose tightening
+  - behavior-preserving simplification
+
+## Gated-lane mapping
+
+- `$maestro`
+  - umbrella routing and next-step synthesis
+- `$sage`
+  - evidence-backed selection and source quality
+- `$vet`
+  - security and trust-boundary playbooks
+
+## Product rule
+
+These patterns are Meta-Architect-native. They are not exposed as raw upstream repo identities or mirror-style catalogs.

package/docs/reference/native-security-playbooks.md

@@ -0,0 +1,21 @@
+# Native Security Playbooks
+
+Security-oriented external patterns are absorbed into Meta-Architect as `$vet` guidance and packaged playbooks.
+
+## Review slices
+
+- identity and session boundaries
+- authorization and tenancy
+- secret handling
+- dependency and supply-chain risk
+- input validation and output exposure
+- abuse cases and operational failure modes
+
+## Routing
+
+- `$vet` remains the only security gate
+- playbooks deepen `$vet`; they do not create a second security umbrella
+
+## Product rule
+
+Meta-Architect can absorb security arsenal patterns aggressively while still presenting them only as native guidance and packaged references.

package/docs/reference/native-source-selection.md

@@ -0,0 +1,21 @@
+# Native Source Selection
+
+Meta-Architect uses external discovery surfaces as inputs to native source-selection guidance, not as first-class product faces.
+
+## Evidence ladder
+
+1. known upstream repo and official docs
+2. discovery accelerators for narrowing candidates
+3. exact upstream repo mapping
+4. upstream and official-doc verification before approval
+
+## Product rule
+
+- discovery lists help candidate selection
+- verification still depends on primary sources
+- packaged references should explain the selection posture in Meta-Architect language
+
+## Routing
+
+- `$sage` owns source selection and evidence quality
+- helper skills can support preparation, but they do not replace `$sage`

package/docs/reference/native-style-and-deslop.md

@@ -0,0 +1,20 @@
+# Native Style And Deslop
+
+Meta-Architect treats prose cleanup and anti-slop work as helper behavior, not as a separate umbrella workflow.
+
+## Core rules
+
+- prefer deletion over addition
+- preserve behavior while simplifying
+- remove generic AI filler from user-facing docs
+- keep naming concise and Meta-Architect-native
+- lock behavior with tests before cleanup when code paths are involved
+
+## Routing
+
+- use `$cleanup` for final-pass simplification and prose cleanup
+- return to `$maestro` or the owning gated lane after cleanup decisions are made
+
+## Non-goal
+
+Do not ship raw third-party “humanizer” or “stop-slop” identities as first-class product surfaces.

package/docs/release-spec.md

@@ -1,13 +1,13 @@
-# v0.1.11 Requirements & Rules
+# v0.1.12 Requirements & Rules
 
 ## Production definition
 
-Meta-Architect `v0.1.11` is production only when:
+Meta-Architect `v0.1.12` is production only when:
 1. the package/install surface works
 2. the in-session skill workflow from `$arch` through `$build` works
 3. the release evidence matches the actual package and git tag
 
-## What `v0.1.11` must have
+## What `v0.1.12` must have
 
 ### 1. Canonical package/runtime path
 
@@ -49,12 +49,18 @@ Canonical state files:
 
 ### 4. Required release evidence
 
-- `package.json` version `0.1.11`
-- git tag `v0.1.11`
+- `package.json` version `0.1.12`
+- git tag `v0.1.12`
 - `RELEASE.md`
 - `CHANGELOG.md`
-- `docs/qa/release-readiness-0.1.11.md`
+- `docs/qa/release-readiness-0.1.12.md`
 - green `npm run release:check`
+- GitHub release asset `meta-architect_0.1.12_all.deb`
+- GitHub release asset `meta-architect-0.1.12-1-any.pkg.tar.xz`
+- GitHub release asset `meta-architect-0.1.12-1.noarch.rpm`
+- green `npm run linux:packages:build`
+- green `npm run linux:packages:smoke`
+- green `npm run release:assets`
 
 ### 5. Dist-tag discipline
 
@@ -72,12 +78,17 @@ Canonical state files:
 4. Update `docs/qa/release-readiness-<version>.md`
 5. Run `npm run release:verify`
 6. Run `npm run release:check`
-7. Create and push tag `v<version>`
-8. Preferred publish path: publish from `.github/workflows/npm-publish.yml` on a supported cloud runner so provenance can be generated
-9. Local shell fallback when not publishing from GitHub Actions or GitLab CI/CD:
+7. Build and smoke-check the Linux native packages on Linux:
+   - `npm run linux:packages:build`
+   - `npm run linux:packages:smoke`
+   - `npm run release:assets`
+8. Create and push tag `v<version>`
+9. Preferred publish path: publish from `.github/workflows/npm-publish.yml` on a supported cloud runner so provenance can be generated
+10. Local shell fallback when not publishing from GitHub Actions or GitLab CI/CD:
    - Stable publish: `npm publish --access public`
    - Prerelease publish: `npm publish --access public --tag <lane>`
-10. Verify dist-tags with `npm view @jstn-sdk/ma version dist-tags time --json`
+11. Verify dist-tags with `npm view @jstn-sdk/ma version dist-tags time --json`
+12. Verify the GitHub release contains `dist/meta-architect-skills.tgz`, `meta-architect_<version>_all.deb`, `meta-architect-<version>-1-any.pkg.tar.xz`, and `meta-architect-<version>-1.noarch.rpm`
 
 ### 6.1 Release automation
 

package/docs/skills-publishing.md

@@ -26,6 +26,16 @@ Purpose:
 
 Do not confuse these two layers. The repo publishes `skills/`, not `.ma/`.
 
+## Published surface types
+
+The publishable `skills/` surface contains:
+- one umbrella autonomous manager: `$maestro`
+- fixed gated lanes: `$arch`, `$sage`, `$flow`, `$vet`, `$vibe`, `$build`
+- non-gating helper skills: `$align`, `$diagnose`, `$tdd`, `$cleanup`
+
+Only `$maestro` is the umbrella surface. Helper skills are intentionally publishable but non-gating.
+The `ma` terminal helper command is part of the npm package surface, not the publishable skill contract.
+
 ## Canonical packaging flow
 
 ### Generate manifest
@@ -80,13 +90,19 @@ npm run skills:install -- --path ./dist/installed-skills
 Expected effect:
 - all publishable skill folders are copied to the target install path
 - install target should contain:
-  - `meta-architect`
+  - `align`
+  - `maestro`
   - `arch`
   - `sage`
   - `flow`
+  - `diagnose`
+  - `tdd`
+  - `cleanup`
   - `vet`
   - `vibe`
   - `build`
+- install target should not contain:
+  - `meta-architect`
 
 ## Expected outputs
 
@@ -97,6 +113,8 @@ Should contain:
 - skill names
 - repo-local path mapping
 - descriptions
+- only native Meta-Architect skill identities
+- a `maestro` description that matches the bounded autonomous-manager contract
 
 ### `dist/meta-architect-skills.tgz`
 
@@ -174,6 +192,9 @@ Relationship:
 - both should remain aligned in behavior and version intent
 - `.agents/plugins/marketplace.json` advertises the local plugin source for discovery
 - `plugins/meta-architect/.codex-plugin/plugin.json` is the plugin contract entrypoint
+- the umbrella in-session entry point is `$maestro`; there is no separately shipped `$meta-architect` skill
+- `$maestro` is the bounded autonomous manager, not a second terminal runtime
+- helper skills remain publishable mirrors, but they do not add release gates or alternate umbrella entry points
 
 If a skill contract changes:
 1. update `skills/`
@@ -212,6 +233,9 @@ npm run pack:inspect
 Before a release is considered real:
 - `skills/index.json` must be current
 - `dist/meta-architect-skills.tgz` must exist
+- `dist/meta-architect_<version>_all.deb` must exist for the Debian-family release lane
+- `dist/meta-architect-<version>-1-any.pkg.tar.xz` must exist for the Arch-family release lane
+- `dist/meta-architect-<version>-1.noarch.rpm` must exist for the Fedora/openSUSE-style release lane
 - install smoke test must pass
 - package inspection must be sane
 - docs must match the published behavior

package/docs/skills.md

@@ -1,13 +1,12 @@
 # Skills
 
-Meta-Architect’s canonical Codex runtime surface is:
-- `$maestro`
-- `$arch`
-- `$sage`
-- `$flow`
-- `$vet`
-- `$vibe`
-- `$build`
+Meta-Architect ships three in-session skill layers:
+
+- umbrella autonomous manager: `$maestro`
+- fixed gated lanes: `$arch`, `$sage`, `$flow`, `$vet`, `$vibe`, `$build`
+- non-gating helper skills: `$align`, `$diagnose`, `$tdd`, `$cleanup`
+
+The package does not ship a separate `$meta-architect` in-session skill. `$maestro` is the umbrella contract for next-step management, bounded lane handoff, and fixed-sequence supervision.
 
 ## Real usage path
 
@@ -28,11 +27,12 @@ npm uninstall -g @jstn-sdk/ma @openai/codex
 ```
 
 Then inside the Codex session:
-1. Start with `$maestro` when you want Meta-Architect to choose the best next step
+1. Start with `$maestro` when you want Meta-Architect to act as the bounded autonomous manager for the workflow
 2. Or start with `$arch` when you already know the architecture lane is next
 3. Continue through `$sage -> $flow -> $vet -> $vibe -> $build`
+4. Use `$align`, `$diagnose`, `$tdd`, or `$cleanup` only as publishable non-gating helper skills around that gated path
 
-## Simple difference
+## Two surfaces
 
 Meta-Architect has two surfaces:
 
@@ -59,6 +59,10 @@ $flow
 $vet
 $vibe
 $build
+$align
+$diagnose
+$tdd
+$cleanup
 ```
 
 Short rule:
@@ -70,6 +74,11 @@ Important:
 - they only create local support files
 - they do not replace the in-session skill flow
 
+Manager contract:
+- `$maestro` is the only umbrella in-session surface
+- `$maestro` manages the next allowed step, but gated outputs still belong to `$arch -> $sage -> $flow -> $vet -> $vibe -> $build`
+- helper skills are publishable mirrors that can assist a lane, but they do not move release gates
+
 ## Installed support bundle
 
 Meta-Architect also installs a standard packaged support bundle for relevant files.
@@ -95,6 +104,7 @@ Relevant packaged assets there include:
 - `scripts/`
 - `plugins/meta-architect/`
 - `templates/`
+- native skill references such as `skills/maestro/references/`, `skills/sage/references/`, `skills/vet/references/`, `skills/align/references/`, and `skills/cleanup/references/`
 
 This exists so Meta-Architect can use relevant packaged files without guessing paths.
 
@@ -109,7 +119,7 @@ Every skill result must include:
 
 ## Status ownership
 
-- `$maestro` -> next-step recommendation
+- `$maestro` -> umbrella workflow management, next-step recommendation, and bounded helper/gate handoff
 - project brief -> architecture input
 - `$arch` -> `architecture_status`
 - `$sage` -> `evidence_status`
@@ -118,6 +128,8 @@ Every skill result must include:
 - `$vibe` -> `experience_status`
 - `$build` -> `build_status`
 
+Helper skills do not own release-state fields. They are publishable but non-gating, so they support the current lane and then hand work back to `$maestro` or the gated lane that owns the decision.
+
 ## Operator note
 
-The in-session skill surface is primary. The `ma` helper commands only exist to start Codex context and to provide repo-local state automation when scripted verification is needed.
+The in-session skill surface is primary. The `ma` terminal helper commands only exist to start Codex context and to provide repo-local state automation when scripted verification is needed.