multimodel-dev-os 2.0.1 → 2.6.0

package/docs/public/llms-full.txt

@@ -1,4 +1,4 @@
-# MultiModel Dev OS — Comprehensive AI Assistant Discoverability Guide (v2.0.1 Stable Release)
+# MultiModel Dev OS — Comprehensive AI Assistant Discoverability Guide (v2.6.0 Stable Release)
 
 MultiModel Dev OS is a repository-level porting specification designed to align context and instructions across diverse developer tools and AI models.
 
@@ -38,13 +38,43 @@ The protocol decouples the centralized workspace context from the individual too
 
 All compliant MultiModel Dev OS CLIs strictly enforce the following command contracts:
 - **`init`**: Scaffolds the standard `.ai/` context configuration directories. Supports `--template`, `--caveman`, `--adapter`, and dynamic registries mapping.
+- **`status`**: Displays a compact project intelligence dashboard summarizing package details, frameworks, memory freshness, feedback logs, improvement proposals, and audit execution metrics.
+- **`scan`**: Performs a read-only codebase scan to detect frameworks, package managers, MultiModel Dev OS configurations, and potential context-bloat or security risks.
+- **`onboard`**: Safely integrates MultiModel Dev OS into existing repositories. Subcommands:
+  - `analyze`: Scans repository structure, frameworks, languages, and risk markers. Read-only.
+  - `recommend`: Runs scanner diagnostics and recommendations for templates and adapters. Read-only.
+  - `plan`: Generates onboarding plan `.ai/intelligence/onboarding.plan.json` and report `.ai/intelligence/onboarding.report.md`. Read-only.
+  - `apply`: Copies configuration templates to target directory. Overwrites require `--force` and automatically generate backups.
+  - `status`: Show progress and completeness percentage dashboard.
+- **`adapter`**: Manage and sync rule/settings files for IDE adapters. Subcommands:
+  - `status`: Show rules files status and enable/disable states from config.
+  - `diff <adapter>`: Show rules diff between bundled template and target root file.
+  - `sync <adapter|all>`: Synchronizes rule files (requires `--approved`). Overwrites require `--force` and automatically generate backups.
+- **`memory`**: Compiles or reviews codebase hash-compressed memory. Subcommands:
+  - `build`: Scans target codebase and writes memory metadata to `.ai/intelligence/memory.hash.json` and `.ai/intelligence/memory.summary.md`.
+  - `refresh`: Incremental update comparing changed file hashes to update the memory files.
+  - `diff`: Prints added, removed, or changed files compared to `memory.hash.json` without executing writes.
+- **`feedback`**: Manage developer feedback loops. Subcommands:
+  - `add`: Logs raw developer feedback to `feedback-log.jsonl`.
+  - `list`: Lists logged feedback entries.
+  - `summarize`: Compiles feedback entries into `learning-rules.md`.
+- **`improve`**: Manage codebase self-improvement proposals. Subcommands:
+  - `propose`: Scans context and writes a proposal file under `.ai/proposals/`.
+  - `review`: Lists proposals and their active statuses.
+  - `status`: Shows aggregates of proposal statuses.
+  - `validate`: Validate proposal safety gates and operations block.
+  - `diff`: Preview proposed changes in unified diff format without modifying files.
+  - `apply`: Deterministically apply approved operations to the target codebase (requires `--approved`).
+  - `log`: Display Applied Proposals Audit Log execution history.
+- **`workflow`**: Orchestrate read-only development workflows (list, show, plan, run). Steps are restricted to safe, non-destructive CLI functions.
+- **`handoff`**: Compile token-compressed session context (build, show) at `.ai/intelligence/handoff.md` to transfer state to a new agent or model session.
 - **`verify`**: Automated release script that checks structure integrity.
 - **`templates`**: Lists built-in template profiles (supports overrides via `--registry <path>`).
 - **`validate`**: Strict Quality Gate checking the layout rules on disk (supports `--all-registries`).
 - **`validate-template`**: Scans a template registry entry and source directory structure for completeness.
 - **`validate-adapter`**: Audits an adapter config file and directory setup compliance.
 - **`validate-skill`**: Checks a custom skill file against standard Markdown headers.
-- **`doctor`**: Advisory checkup auditing ignored folders and token footprint (supports `--tokens` and `--release`).
+- **`doctor`**: Advisory checkup auditing ignored folders and token footprint (supports `--tokens`, `--release`, `--intelligence`, and `--onboarding`).
 
 ---
 

package/docs/public/llms.txt

@@ -1,10 +1,51 @@
-# MultiModel Dev OS (v2.0.1 Stable Release)
+# MultiModel Dev OS (v2.6.0 Stable Release)
 
 Portable, vendor-neutral workspace configuration standard for multi-agent AI pair-programming workflows.
 
-## Fast Setup (Stable npm @latest)
+## Fast Setup & Commands (Stable npm @latest)
 ```bash
+# Initialize workspace
 npx multimodel-dev-os@latest init
+
+# Scan codebase signals & check status
+npx multimodel-dev-os@latest scan
+npx multimodel-dev-os@latest status
+
+# Onboard existing repositories safely
+npx multimodel-dev-os@latest onboard analyze
+npx multimodel-dev-os@latest onboard recommend
+npx multimodel-dev-os@latest onboard plan
+npx multimodel-dev-os@latest onboard apply --approved
+npx multimodel-dev-os@latest onboard status
+
+# Manage and sync IDE adapter configuration files
+npx multimodel-dev-os@latest adapter status
+npx multimodel-dev-os@latest adapter diff cursor
+npx multimodel-dev-os@latest adapter sync cursor --approved
+
+# Build/refresh memory index
+npx multimodel-dev-os@latest memory build
+npx multimodel-dev-os@latest memory refresh
+
+# Run automated workflow cycles
+npx multimodel-dev-os@latest workflow run repo-health
+npx multimodel-dev-os@latest workflow list
+
+# Compile session handoff spec
+npx multimodel-dev-os@latest handoff build
+npx multimodel-dev-os@latest handoff show
+
+# Manage developer feedback loop
+npx multimodel-dev-os@latest feedback add "Avoid Tailwind CSS" --type preference
+npx multimodel-dev-os@latest feedback summarize
+
+# Draft, review, validate, and apply codebase improvement proposals
+npx multimodel-dev-os@latest improve propose --title "Fix config issues"
+npx multimodel-dev-os@latest improve review
+npx multimodel-dev-os@latest improve validate .ai/proposals/proposal-xxxx.md
+npx multimodel-dev-os@latest improve diff .ai/proposals/proposal-xxxx.md
+npx multimodel-dev-os@latest improve apply .ai/proposals/proposal-xxxx.md --approved
+npx multimodel-dev-os@latest improve log
 ```
 
 ## Supported Tools

package/docs/public/sitemap.xml

@@ -115,4 +115,34 @@
     <changefreq>weekly</changefreq>
     <priority>0.7</priority>
   </url>
+  <url>
+    <loc>https://rizvee.github.io/multimodel-dev-os/future-proof-architecture</loc>
+    <changefreq>weekly</changefreq>
+    <priority>0.7</priority>
+  </url>
+  <url>
+    <loc>https://rizvee.github.io/multimodel-dev-os/self-improving-codebase</loc>
+    <changefreq>weekly</changefreq>
+    <priority>0.7</priority>
+  </url>
+  <url>
+    <loc>https://rizvee.github.io/multimodel-dev-os/hash-compressed-memory</loc>
+    <changefreq>weekly</changefreq>
+    <priority>0.7</priority>
+  </url>
+  <url>
+    <loc>https://rizvee.github.io/multimodel-dev-os/feedback-learning</loc>
+    <changefreq>weekly</changefreq>
+    <priority>0.7</priority>
+  </url>
+  <url>
+    <loc>https://rizvee.github.io/multimodel-dev-os/capability-registry</loc>
+    <changefreq>weekly</changefreq>
+    <priority>0.7</priority>
+  </url>
+  <url>
+    <loc>https://rizvee.github.io/multimodel-dev-os/tool-registry</loc>
+    <changefreq>weekly</changefreq>
+    <priority>0.7</priority>
+  </url>
 </urlset>

package/docs/quickstart.md

@@ -73,7 +73,7 @@ npx multimodel-dev-os@latest init --target /path/to/your-project --template next
 
 ## Verify & Diagnose
 
-You can run our strict validation check or advisory doctor checkup to validate structural health:
+Validate structural health, run codebase scans, and build hash-compressed memory:
 
 ```bash
 # Strict directory schema validation
@@ -81,6 +81,12 @@ npx multimodel-dev-os validate
 
 # Advisory doctor workspace compatibility audit
 npx multimodel-dev-os doctor
+
+# Advisory codebase scanner
+npx multimodel-dev-os scan
+
+# Build codebase memory index
+npx multimodel-dev-os memory build
 ```
 
 Explore our canonical [Stable Protocol Specification](/stable-protocol) or [Upgrade & Migration Guide](/migration-guide) for details.

package/docs/real-repo-onboarding.md

@@ -0,0 +1,27 @@
+# Onboarding Existing Repositories
+
+MultiModel Dev OS provides a safe, step-by-step onboarding protocol to configure coding agents in any existing codebase without modifying application source files.
+
+## Onboarding Commands
+
+To onboard an existing repository, run the following commands:
+
+```bash
+# 1. Analyze the project structure, language, framework, and security signals
+npx multimodel-dev-os onboard analyze --target .
+
+# 2. Output template recommendations and suggested next steps
+npx multimodel-dev-os onboard recommend --target .
+
+# 3. Generate a structured onboarding plan and markdown report
+npx multimodel-dev-os onboard plan --target .
+
+# 4. Safely apply the onboarding plan to generate AI Dev OS scaffolding
+npx multimodel-dev-os onboard apply --target . --approved
+```
+
+## Security & Safety Guarantees
+
+* **Read-only Commands**: `analyze`, `recommend`, and `plan` are read-only and make no modifications.
+* **No Source Code Mutation**: `apply` only creates/updates MultiModel Dev OS configuration files (`.ai/`, `AGENTS.md`, `MEMORY.md`, etc.). It never touches your application source code.
+* **Backup Support**: If a file already exists, the onboard engine skips it. To overwrite, use `--force`, which creates a `.bak` backup file first.

package/docs/repository-command-center.md

@@ -0,0 +1,52 @@
+# Repository Command Center Guide
+
+The **Repository Command Center** introduced in `v2.5.0` provides a unified, read-only operational dashboard summarizing the entire repository intelligence status of a MultiModel Dev OS workspace.
+
+---
+
+## 1. Using the `status` Command
+
+The `status` command allows developers and AI agents to instantly check project health and progress.
+
+```bash
+npx multimodel-dev-os status
+```
+
+Or target a specific subdirectory:
+
+```bash
+npx multimodel-dev-os status --target ./some-subproject
+```
+
+### Dashboard View
+
+Running `status` prints a formatted, color-coded status summary:
+
+1.  **Project Info**: Displays the package name and package version from the root `package.json`.
+2.  **Framework & Dependency Signals**: Summarizes detected languages, framework engines (e.g. Next.js, Express, React), and package lockfiles (e.g. `package-lock.json`).
+3.  **Memory State**:
+    *   `CURRENT` (Green): Memory index is fully built and matches the filesystem.
+    *   `STALE` (Yellow): Modifications have been made. Lists number of added, removed, or modified files.
+    *   `MISSING` (Red): No memory files have been built yet.
+4.  **Feedback Loop & Rules**: Displays total count of developer feedback entries and whether compiled learning rules are active.
+5.  **Improvement Proposals**: Lists total optimization proposals, categorized by approval status (`pending`, `approved`, `rejected`).
+6.  **Apply Audit Log**: Counts applied proposal runs.
+7.  **Next Recommended Command**: Offers dynamic advice on what to execute next (e.g., refreshing memory, review proposals, running health checks).
+
+---
+
+## 2. Benefits for Multi-Agent Workflows
+
+*   **Context Discovery**: Instantly summarizes active templates, environment structures, and boundaries.
+*   **Zero-Dependency Parsing**: Fast initialization checks that don't load external libraries.
+*   **Actionable Next Steps**: Guides developers and AI models to the correct command sequence, preventing execution drift.
+
+## 3. Onboarding Status
+
+For uninitialized repositories, you can inspect the onboarding status directly:
+
+```bash
+npx multimodel-dev-os onboard status
+```
+
+This prints a checklist of crucial MultiModel Dev OS files and an overall completeness percentage score.

package/docs/self-improving-codebase.md

@@ -0,0 +1,46 @@
+# Self-Improving Codebase Operations
+
+MultiModel Dev OS supports codebase refactoring, styling, and structural optimizations through a secure, proposal-based self-improvement pipeline.
+
+---
+
+## 1. Safety Principles
+
+To guarantee repository integrity and prevent unintended changes, all self-improvement operations adhere to three core rules:
+1.  **Write-Protection**: The CLI binary, security guards, workflows, and core policies are read-only and cannot be modified by model proposals.
+2.  **Human-in-the-Loop (HITL)**: Models cannot write code directly to the workspace without explicit user verification.
+3.  **Diff-Validated Execution**: Every modification must pass local verification tests, with manual commit approval.
+
+---
+
+## 2. Proposal-Review Cycle
+
+The execution path follows two stages:
+
+### Stage A: Proposal Generation
+Before compiling a proposal, the agent scans the codebase using `mmdo scan` and builds the hash-compressed memory index via `mmdo memory build` to ensure the proposal is context-aware and token-efficient. The agent then identifies an optimization and saves a structured document under `.ai/proposals/proposal-YYYYMMDD-HHMMSS.md`. The proposal specifies the rationale, affected files list, risk level, test command, and rollback steps.
+
+### Stage B: Human Review
+The developer runs the review CLI command:
+```bash
+npx multimodel-dev-os improve review
+```
+This shows the proposed changes, affected files, risk levels, and verify commands.
+
+To view status:
+```bash
+npx multimodel-dev-os improve status
+```
+
+*Note: Starting in v2.4.1, automated proposal application is supported via the `improve apply` command, provided that a valid operations JSON block exists in the proposal file and the developer passes the `--approved` flag. Vague proposals or those targeting protected files/paths must still be executed manually.*
+
+For complete automated application details, please refer to the [Approved Proposal Application Guide](/approved-proposal-apply).
+
+---
+
+## Command Center Integration
+
+The [Repository Command Center](repository-command-center.md) serves as the unified dashboard for the self-improvement loop. Running `mmdo status` displays the counts of pending/approved/rejected proposals, memory state, and feedback logs. Developers can orchestrate the review cycle safely by executing the `proposal-review` workflow:
+```bash
+npx multimodel-dev-os workflow run proposal-review
+```

package/docs/template-recommendation.md

@@ -0,0 +1,22 @@
+# Template Recommendation Engine
+
+The recommendation engine matches existing codebases to the best-fit template profile.
+
+## Heuristics & Confidence Scores
+
+The engine assigns weights to file signatures and package dependencies:
+
+* **Next.js SaaS (`nextjs-saas`)**: Matches if `next.config.js` or `next.config.ts` is present (Weight: +0.6) or `package.json` contains `next` dependency (Weight: +0.4).
+* **Android Expo Mobile (`expo-react-native-android`)**: Matches if `app.json` or `eas.json` is present (Weight: +0.8).
+* **WordPress Theme/Plugin (`wordpress-theme-plugin`)**: Matches if `wp-content` directory or header-decorated PHP style files are found (Weight: +0.8).
+* **E-Commerce Store (`ecommerce-store`)**: Matches if Stripe, Shopify, or checkout-related dependencies are present (Weight: +0.4).
+* **SEO Landing Page (`seo-landing-page`)**: Matches if raw HTML files + Tailwind configs exist without framework elements (Weight: +0.5).
+* **General App (`general-app`)**: Serves as the fallback profile if no other template achieves a confidence score greater than 0.4.
+
+## Command
+
+To check template recommendations for your project:
+
+```bash
+npx multimodel-dev-os onboard recommend --target .
+```

package/docs/templates-guide.md

@@ -69,3 +69,14 @@ npx multimodel-dev-os init --target ../my-new-app --template nextjs-saas
 ## Template Quality Assurance
 
 To ensure all contributed templates meet our rigorous quality standards before packaging, refer to our [Template Quality Assurance Blueprint](/template-qa).
+
+## Template Recommendations for Existing Repos
+
+If you are onboarding an existing repository and unsure which template profile to use, the recommendation engine can automatically analyze your project files:
+
+```bash
+# Analyze framework and package signals, then output recommendation
+npx multimodel-dev-os onboard recommend --target .
+```
+
+For detailed heuristics and confidence weights, refer to the [Template Recommendation Engine docs](/template-recommendation).

package/docs/tool-registry.md

@@ -0,0 +1,21 @@
+# Tool & Protocol Registry
+
+The **Tool Registry** governs connection protocols, interfaces, and file associations for developer environments and AI agents.
+
+---
+
+## 1. Tool Mappings
+
+Tools configured in `.ai/registries/tools.yaml` are mapped by:
+*   **Interface Type**: `editor` (IDE plugins), `terminal` (CLI clients), or `assistant` (chat helpers).
+*   **Protocols**: Connection formats such as `stdin-stdout`, `mcp-jsonrpc` (Model Context Protocol), or custom config parameters.
+*   **Registry Keys**: Associated configuration files (e.g. `.cursorrules` for Cursor, `CLAUDE.md` for Claude Code).
+
+---
+
+## 2. Model Context Protocol (MCP) Integration
+
+MultiModel Dev OS leverages MCP to expose local resources to models:
+1.  **Server Bindings**: Developers declare local MCP servers (e.g. gcloud SDK MCP, Chrome DevTools MCP) under the tools registry.
+2.  **Capability Matching**: The Capability Registry checks if the selected model has `mcp-compliance: 1.0` before attempting native bindings.
+3.  **Unified Tool Access**: Exposes filesystem, browser automation, and deployment commands directly to agent execution loops securely.

package/docs/v2-roadmap.md

@@ -93,3 +93,23 @@ The `v2.0.0` release requires:
 1. 100% pass rate on all automated linter and verifier checks.
 2. Complete documentation updates across all guides and discovery indices.
 3. Explicit maintainer sign-off on local testing of the Android Expo template.
+
+---
+
+## 6. Future Stages: v2.1.0 to v3.0.0
+
+*   **v2.1.0 — Intelligence Core & Registries Foundation**
+    *   Design and document schemas (`memory.schema.json`, `feedback.schema.json`).
+    *   Introduce `.ai/registries/` configuration databases.
+    *   Implement CLI routing helper `mmdo capability route` and `mmdo memory build/refresh`.
+*   **v2.2.0 — Feedback Loops & Tool Integrations**
+    *   Add `mmdo learn` capability to append feedback metrics.
+    *   Define `.ai/registries/tools.yaml` with MCP protocol interfaces.
+*   **v2.3.0 — Proposal Engine & Safety Controls**
+    *   Deploy proposal structures under `.ai/proposals/`.
+    *   Implement CLI pipeline `mmdo improve propose/review/apply`.
+*   **v2.4.0 — Local/Offline Operations**
+    *   Integrate local model scoring (Llama.cpp, Ollama) and offline schema checks.
+*   **v3.0.0 — Unified Autonomous Co-Pilot Ecosystem**
+    *   Full multi-agent orchestration workflows with dynamic task handoffs.
+    *   Distributed registry syncing and cryptographically signed self-improvement proposals.

package/docs/workflow-orchestration.md

@@ -0,0 +1,59 @@
+# Workflow Orchestration
+
+MultiModel Dev OS `v2.5.0` features a built-in **Workflow Runner** designed to orchestrate codebase diagnostic pipelines safely.
+
+---
+
+## 1. CLI Commands
+
+Workflows are registered in [.ai/registries/workflows.yaml](file:///.ai/registries/workflows.yaml) and can be executed via the following subcommands:
+
+### List Registered Workflows
+Prints name, risk, and summary of all active workflows:
+```bash
+npx multimodel-dev-os workflow list
+```
+
+### Show Workflow Specifications
+Displays details, memory write permissions, code modification permissions, and individual logical steps:
+```bash
+npx multimodel-dev-os workflow show repo-health
+```
+
+### Plan Workflow Execution (Dry-Run)
+Prints the execution sequence, command lists, and expected outputs without executing any logic:
+```bash
+npx multimodel-dev-os workflow plan repo-health
+```
+
+### Run Workflow
+Executes the workflow steps sequentially:
+```bash
+npx multimodel-dev-os workflow run repo-health
+```
+
+---
+
+## 2. Standard Built-in Workflows
+
+MultiModel Dev OS defines 5 baseline workflows:
+
+1.  **`repo-health`** (Low Risk): Scans framework signals, performs advisory doctor audits, and verifies file structures.
+2.  **`memory-refresh`** (Medium Risk): Assesses memory differences and incremental refreshes.
+3.  **`feedback-review`** (Low Risk): Lists active developer logs and compiles rules to `learning-rules.md`.
+4.  **`proposal-review`** (Low Risk): Inspects codebase proposals, checks status counts, and displays audit apply logs.
+5.  **`release-check`** (Low Risk): Verifies codebase structures, executes release doctors, and runs package pack checks.
+
+---
+
+## 3. Strict Safety Gates
+
+The workflow engine enforces strict safety boundaries:
+
+*   **No File Modifications**: Allowed workflows only execute read-only checkups and incremental metadata updates (memory file compilation, feedback summaries).
+*   **No Shell Execution**: Shell command execution from `workflows.yaml` is prohibited. Steps map directly to internal Javascript CLI functions.
+*   **No Autonomy**: Any step requiring code changes (e.g. applying proposals) stops and outputs manual next-step instructions for the developer.
+
+## 4. Bundled Registry Fallback
+
+If the repository does not have a local `.ai/registries/workflows.yaml` registry file initialized yet, the workflow runner will automatically fall back to the bundled registry package templates and output a notice. This allows running read-only diagnostics prior to full project onboarding.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "multimodel-dev-os",
-  "version": "2.0.1",
+  "version": "2.6.0",
   "bin": {
     "multimodel-dev-os": "bin/multimodel-dev-os.js"
   },

package/scripts/install.ps1

@@ -11,7 +11,7 @@ param(
   [switch]$Help
 )
 
-$Version = "2.0.1"
+$Version = "2.6.0"
 $RepoUrl = "https://raw.githubusercontent.com/rizvee/multimodel-dev-os/main"
 
 if ($Help) {

package/scripts/install.sh

@@ -7,7 +7,7 @@ set -euo pipefail
 #        --all      (install all adapters)
 #        --dry-run  (show what would be created without creating)
 
-VERSION="2.0.1"
+VERSION="2.6.0"
 REPO_URL="https://raw.githubusercontent.com/rizvee/multimodel-dev-os/main"
 CAVEMAN=false
 DRY_RUN=false

package/scripts/verify.js

@@ -231,6 +231,21 @@ checkFile('docs/v2-migration.md');
 checkFile('docs/v2-release-checklist.md');
 checkFile('docs/package-safety.md');
 
+// --- v2.1.0 Intelligence Layer Documentation ---
+console.log('\nIntelligence Layer Documentation:');
+checkFile('docs/future-proof-architecture.md');
+checkFile('docs/self-improving-codebase.md');
+checkFile('docs/feedback-learning.md');
+checkFile('docs/hash-compressed-memory.md');
+checkFile('docs/capability-registry.md');
+checkFile('docs/tool-registry.md');
+checkFile('docs/improvement-proposals.md');
+checkFile('docs/learning-rules.md');
+checkFile('docs/approved-proposal-apply.md');
+checkFile('docs/repository-command-center.md');
+checkFile('docs/workflow-orchestration.md');
+checkFile('docs/agent-handoff.md');
+
 // --- Model & Adapter Registries ---
 console.log('\nModel & Adapter Registries:');
 checkFile('.ai/models/registry.yaml');
@@ -250,6 +265,28 @@ checkFile('.ai/schema/config.schema.json');
 checkFile('.ai/schema/template.schema.json');
 checkFile('.ai/schema/adapter.schema.json');
 
+// --- v2.1.0 Intelligence Layer (Schemas, Policies, Registries) ---
+console.log('\nIntelligence Layer Schemas:');
+checkFile('.ai/intelligence/memory.schema.json');
+checkFile('.ai/intelligence/feedback.schema.json');
+checkFile('.ai/intelligence/README.md');
+checkFile('.ai/intelligence/feedback-log.example.jsonl');
+checkFile('.ai/intelligence/learning-rules.example.md');
+checkFile('.ai/intelligence/improvement-proposal.schema.json');
+checkFile('.ai/intelligence/apply-log.schema.json');
+checkFile('.ai/proposals/README.md');
+checkFile('.ai/proposals/apply-operation.example.json');
+
+console.log('\nIntelligence Layer Policies:');
+checkFile('.ai/policies/self-improvement-policy.md');
+checkFile('.ai/policies/memory-policy.md');
+checkFile('.ai/policies/approval-gates.md');
+
+console.log('\nIntelligence Layer Registries:');
+checkFile('.ai/registries/capabilities.yaml');
+checkFile('.ai/registries/tools.yaml');
+checkFile('.ai/registries/workflows.yaml');
+
 // --- Test Blueprints ---
 console.log('\nTest Manuals:');
 checkFile('tests/README.md');
@@ -377,6 +414,9 @@ verifyRegistryParsed('.ai/models/routing-presets.yaml', 'presets');
 verifyRegistryParsed('.ai/models/local-models.yaml', 'local_engines');
 verifyRegistryParsed('.ai/adapters/registry.yaml', 'adapters');
 verifyRegistryParsed('.ai/templates/registry.yaml', 'templates');
+verifyRegistryParsed('.ai/registries/capabilities.yaml', 'capabilities');
+verifyRegistryParsed('.ai/registries/tools.yaml', 'tools');
+verifyRegistryParsed('.ai/registries/workflows.yaml', 'workflows');
 
 // --- CLI & Packaging Pre-Flight Tests ---
 console.log('\nRunning CLI & Packaging Pre-Flight Tests...');
@@ -408,11 +448,70 @@ try {
     console.log(`  ${GREEN}✓${NC} CLI help displays v${expectedVersion}`);
     pass++;
   }
+  
+  if (helpOutput.includes('scan') && helpOutput.includes('memory') && helpOutput.includes('status') && helpOutput.includes('workflow') && helpOutput.includes('handoff')) {
+    console.log(`  ${GREEN}✓${NC} CLI help includes scan, memory, status, workflow, and handoff commands`);
+    pass++;
+  } else {
+    console.error(`  ${RED}✗${NC} CLI help is missing scan, memory, status, workflow, or handoff commands`);
+    fail++;
+  }
 } catch (e) {
   console.error(`  ${RED}✗${NC} node bin/multimodel-dev-os.js --help failed: ${e.message}`);
   fail++;
 }
 
+// Verify docs mention memory build
+try {
+  const mdContent = readFileSync(join(projectRoot, 'docs', 'hash-compressed-memory.md'), 'utf8');
+  if (mdContent.includes('memory build')) {
+    console.log(`  ${GREEN}✓${NC} docs/hash-compressed-memory.md mentions 'memory build'`);
+    pass++;
+  } else {
+    console.error(`  ${RED}✗${NC} docs/hash-compressed-memory.md does not mention 'memory build'`);
+    fail++;
+  }
+} catch (e) {
+  console.error(`  ${RED}✗${NC} docs check failed: ${e.message}`);
+  fail++;
+}
+
+// Verify no generated memory or feedback logs or proposals are committed/tracked in git root/intelligence folder
+try {
+  const checkUntracked = (relPath) => {
+    if (existsSync(join(projectRoot, relPath))) {
+      console.error(`  ${RED}✗${NC} ${relPath} should not be tracked/committed!`);
+      fail++;
+    } else {
+      console.log(`  ${GREEN}✓${NC} ${relPath} is not tracked/committed`);
+      pass++;
+    }
+  };
+  checkUntracked('.ai/intelligence/memory.hash.json');
+  checkUntracked('.ai/intelligence/memory.summary.md');
+  checkUntracked('.ai/intelligence/feedback-log.jsonl');
+  checkUntracked('.ai/intelligence/learning-rules.md');
+  checkUntracked('.ai/intelligence/handoff.md');
+  checkUntracked('.ai/proposals/apply-log.jsonl');
+  
+  // also check if any proposal-*.md file exists directly in projectRoot/proposals (since it shouldn't be tracked)
+  const proposalsDir = join(projectRoot, '.ai', 'proposals');
+  if (existsSync(proposalsDir)) {
+    const files = readdirSync(proposalsDir);
+    const hasRuntimeProposals = files.some(f => f.startsWith('proposal-') && f !== 'proposal-template.md' && f.endsWith('.md'));
+    if (hasRuntimeProposals) {
+      console.error(`  ${RED}✗${NC} Runtime proposals should not be committed/tracked!`);
+      fail++;
+    } else {
+      console.log(`  ${GREEN}✓${NC} No runtime proposals committed`);
+      pass++;
+    }
+  }
+} catch (e) {
+  console.error(`  ${RED}✗${NC} Tracking verification of generated files failed: ${e.message}`);
+  fail++;
+}
+
 // Verify npm pack dry-run shows current version dynamically
 try {
   const packOutput = execSync('npm pack --dry-run', { cwd: projectRoot, encoding: 'utf8', stdio: ['ignore', 'pipe', 'pipe'] });
@@ -447,12 +546,17 @@ try {
 
 // --- Package Safety & Hygiene Checks ---
 console.log('\nPackage Safety & Hygiene Checks:');
-if (existsSync(join(projectRoot, '.npmrc'))) {
+if (existsSync(join(projectRoot, '.npmrc')) && process.env.MMDO_ALLOW_PUBLISH !== 'true') {
   console.error(`  ${RED}✗ .npmrc file exists in package root (security risk)${NC}`);
   fail++;
 } else {
-  console.log(`  ${GREEN}✓${NC} No .npmrc file present in package root`);
-  pass++;
+  if (existsSync(join(projectRoot, '.npmrc'))) {
+    console.log(`  ${YELLOW}!${NC} .npmrc file present in package root (allowed via MMDO_ALLOW_PUBLISH)`);
+    warn++;
+  } else {
+    console.log(`  ${GREEN}✓${NC} No .npmrc file present in package root`);
+    pass++;
+  }
 }
 
 const checkExamplesHygiene = (dir) => {