multimodel-dev-os 2.8.1 → 2.9.1

package/docs/registry-security.md

@@ -0,0 +1,67 @@
+# Registry Security Model
+
+MultiModel Dev OS is designed with a **zero-trust architecture** for remote registries and plugins. Because plugins configure coding guidelines, workflows, and prompts for AI coding agents, securing the distribution channel is critical.
+
+This document describes the threat model, safety boundaries, and mitigation strategies implemented in `v3.0.0`.
+
+---
+
+## Threat Model & Mitigations
+
+```
+Threat: Malicious Remote Registry
+   |--> Arbitrary Code Execution (Mitigated: Declarative-only YAML)
+   |--> Path Traversal / Overwrite (Mitigated: Resolve path bounds + Blacklist)
+   |--> Dependency Poisoning (Mitigated: No automated package installation)
+```
+
+### 1. Arbitrary Code Execution
+* **Threat:** A remote registry delivers a plugin containing malicious scripts (`shell`, `javascript`, etc.) that execute on the developer's machine.
+* **Mitigation:**
+  * **Declarative-only manifests:** Plugins are purely declarative YAML manifests defining workflows, skills, and checks.
+  * **No runtime scripts:** Plugins cannot contain JavaScript files, shell scripts, or binary assets.
+  * **No eval/exec:** The CLI parser reads manifests using a custom regex-based parser, strictly avoiding `eval` or dynamic JS execution.
+
+### 2. Path Traversal & Unauthorized Overwrites
+* **Threat:** A plugin manifest contains destination paths like `../../.ssh/authorized_keys` or `/etc/hosts` to write files outside the workspace.
+* **Mitigation:**
+  * **Allowed Write Roots:** The policy engine enforces that all destination paths must resolve within whitelisted directories (defaulting to `.ai/` and `adapters/`).
+  * **Path Resolution Checks:** The installer uses `path.resolve` and `path.relative` to ensure destinations do not escape the target root or cache root.
+  * **Blocked Paths Blacklist:** Sensitive files (e.g. `.env`, `.npmrc`, `.git/`, `package.json`) are blacklisted and cannot be overwritten under any circumstances.
+
+### 3. Dependency Poisoning
+* **Threat:** A synced plugin runs `npm install` to inject malicious dependencies into the project.
+* **Mitigation:**
+  * **Zero dependency installer:** The installation process does not interact with the npm registry, execute package managers, or modify `node_modules`.
+  * **Ignored package files:** The blacklist blocks writes to `package.json`, `package-lock.json`, `pnpm-lock.yaml`, and `yarn.lock`.
+
+### 4. Cache Poisoning / Tampering
+* **Threat:** An attacker modifies cached remote files on disk to bypass verification.
+* **Mitigation:**
+  * **In-process verification:** The `registry verify` command performs SHA256 checksum checks against the manifest.
+  * **ReadOnly Dashboard:** The interactive TUI Dashboard is completely read-only for registry and plugin operations, preventing UI-driven privilege escalation.
+
+---
+
+## Safety Boundaries Matrix
+
+The following table summarizes the enforcement gates for different registry types:
+
+| Capability | Local Bundled | Verified Remote | Community Remote |
+|---|---|---|---|
+| **Requires Approved Flag** | Yes | Yes | Yes |
+| **Integrity Check** | Yes (Built-in) | Yes (SHA256 Manifest) | Yes (SHA256 Manifest) |
+| **Write Directory Restricted** | Yes (`.ai/`, `adapters/`) | Yes (`.ai/`, `adapters/`) | Yes (`.ai/`, `adapters/`) |
+| **Size Limit Enforced** | No | Yes (max 100KB) | Yes (max 100KB) |
+| **File Limit Enforced** | No | Yes (max 20 files) | Yes (max 20 files) |
+| **Allowed Extensions Only** | Yes | Yes | Yes |
+| **Automatic Activation** | No | No | No |
+
+---
+
+## Best Practices for Enterprise
+
+For teams deploying MultiModel Dev OS in sensitive environments, we recommend:
+1. Keeping `allow_remote_registries: false` (the default) if no third-party plugins are needed.
+2. If remote plugins are required, set `allow_untrusted_install: false` to only permit plugins from official, signed corporate registries.
+3. Commit `.ai/policies/registry-policy.yaml` to version control to enforce uniform governance across all developer machines.

package/docs/registry-sync.md

@@ -0,0 +1,106 @@
+# Registry Synchronization Guide
+
+This guide explains how to configure, synchronize, and manage remote registries in MultiModel Dev OS.
+
+## Overview
+
+MultiModel Dev OS uses a local-first registry system. By default, all remote capabilities are disabled. When enabled, the sync system allows you to fetch remote catalog indexes and verify their integrity before installing any plugin assets.
+
+> [!IMPORTANT]
+> **Zero Trust Security Model**
+> * Remote sync does **not** download or run arbitrary binary code.
+> * Synced assets are placed strictly in the gitignored `.ai/registry-cache/` directory.
+> * Files are verified using SHA256 checksums defined in the publisher's signed manifest.
+
+---
+
+## Commands Reference
+
+The `registry` command suite provides the following operations:
+
+| Command | Safety Level | Description |
+|---|---|---|
+| `registry list` | Read-only | List all configured registry sources |
+| `registry status` | Read-only | View sync status, timestamps, and cache health |
+| `registry show <name>` | Read-only | View configuration details of a specific source |
+| `registry verify <name>` | Read-only | Audit SHA256 checksums of cached registry files |
+| `registry add <name> <url> --approved` | Write | Add a new remote registry source |
+| `registry sync <name> --approved` | Network + Write | Download and cache remote catalog and manifest |
+| `registry remove <name> --approved` | Write | Remove a registry source and clear its cache |
+| `registry cache clear --approved` | Write | Clear all cached registry files |
+
+---
+
+## Synchronization Workflow
+
+To synchronize a remote registry, follow these steps:
+
+### 1. Enable Remote Registries in Policy
+
+Open `.ai/policies/registry-policy.yaml` and set `allow_remote_registries: true`:
+
+```yaml
+allow_remote_registries: true
+```
+
+### 2. Configure a Remote Registry Source
+
+Run the `registry add` command with the `--approved` flag to define a new registry source:
+
+```bash
+npx multimodel-dev-os registry add partner-registry https://registry.example.com/catalog.yaml --approved
+```
+
+### 3. Synchronize Registry Data
+
+To fetch the remote catalog, run `registry sync`. Executing without the approval flag displays a safety audit preview:
+
+```bash
+npx multimodel-dev-os registry sync partner-registry
+```
+
+Once reviewed, run with `--approved`:
+
+```bash
+npx multimodel-dev-os registry sync partner-registry --approved
+```
+
+This performs the following actions:
+1. Downloads `catalog.yaml` and `manifest.json` from the registry source.
+2. Resolves and downloads all individual plugin manifests and assets listed in the manifest's `files_hashes`.
+3. Verifies every file against its expected SHA256 checksum.
+4. Generates a local `checksums.json` index in the cache.
+
+### 4. Browse and Install Synced Plugins
+
+Browse cached plugins from the registry using:
+
+```bash
+npx multimodel-dev-os catalog list --source remote:partner-registry
+```
+
+Install a cached plugin via:
+
+```bash
+npx multimodel-dev-os catalog install <plugin-slug> --approved
+```
+
+---
+
+## Cache Directory Layout
+
+All cached data is written to `.ai/registry-cache/<registry-name>/`:
+
+```
+.ai/registry-cache/
+└── partner-registry/
+    ├── catalog.yaml          # Cached plugin index
+    ├── manifest.json         # Provenance metadata
+    ├── checksums.json        # Verified SHA256 local database
+    └── catalog/
+        └── custom-plugin.yaml # Cached manifest for individual plugin
+```
+
+> [!TIP]
+> Clear all cached data at any time without affecting installed plugins:
+> `npx multimodel-dev-os registry cache clear --approved`

package/docs/remote-catalog-authoring.md

@@ -0,0 +1,139 @@
+# Remote Catalog Authoring Guide
+
+This guide explains how to create, package, and publish a remote catalog registry for MultiModel Dev OS.
+
+## Registry Directory Structure
+
+A registry is a web-accessible directory containing a catalog index, a provenance manifest, and individual plugin manifest files with their assets:
+
+```
+my-registry/
+├── catalog.yaml          # Registry index file
+├── manifest.json         # Integrity manifest containing file hashes
+└── catalog/
+    ├── nextjs-helper.yaml # Plugin manifest for 'nextjs-helper'
+    └── .ai/              # Plugin asset folder
+        └── skills/
+            └── nextjs-skills.md
+```
+
+---
+
+## 1. Creating the Catalog Index (`catalog.yaml`)
+
+The `catalog.yaml` file lists all available plugins in the registry. It matches the structure of the bundled catalog:
+
+```yaml
+# catalog.yaml
+catalog:
+  version: "1.0.0"
+  description: "Custom team-specific workflows and guidelines"
+  plugins:
+    - slug: nextjs-helper
+      name: "NextJS Component Helper"
+      version: "1.2.0"
+      description: "Standards-compliant NextJS boilerplates and structure checks."
+      category: "nextjs"
+      tags:
+        - nextjs
+        - react
+      safety_level: "sandboxed"
+      install_scope: "declarative"
+      recommended_for: "NextJS React projects"
+      files_preview:
+        - dest: ".ai/plugins/nextjs-helper.yaml"
+        - dest: ".ai/skills/nextjs-skills.md"
+```
+
+---
+
+## 2. Packaging Plugin Files
+
+Create the plugin YAML manifest in `catalog/<slug>.yaml`. This file defines the actual workflows and the files to copy:
+
+```yaml
+# catalog/nextjs-helper.yaml
+name: "NextJS Component Helper"
+slug: "nextjs-helper"
+version: "1.2.0"
+description: "Standards-compliant NextJS boilerplates and structure checks."
+allowed_file_patterns:
+  - .ai/skills/nextjs-skills.md
+workflows:
+  route-check:
+    name: "Check App Router Routes"
+    steps:
+      - run: "npx multimodel-dev-os validate"
+```
+
+Then create the corresponding asset files (e.g. `catalog/.ai/skills/nextjs-skills.md`) in the correct subdirectories.
+
+---
+
+## 3. Generating the Manifest (`manifest.json`)
+
+To make the registry verified, you must generate a `manifest.json` file. This file contains metadata and SHA256 checksums of all files in the registry.
+
+Below is an example Node script you can run from your registry's root folder to generate the manifest:
+
+```javascript
+// generate-manifest.js
+const fs = require('fs');
+const path = require('path');
+const crypto = require('crypto');
+
+const registryName = 'custom-registry';
+const publisher = 'My Team';
+const version = '1.0.0';
+
+function computeSHA256(filePath) {
+  const content = fs.readFileSync(filePath);
+  return 'sha256:' + crypto.createHash('sha256').update(content).digest('hex');
+}
+
+const filesHashes = {};
+const walk = (dir) => {
+  const list = fs.readdirSync(dir);
+  list.forEach(file => {
+    const fullPath = path.join(dir, file);
+    const stat = fs.statSync(fullPath);
+    if (stat && stat.isDirectory()) {
+      walk(fullPath);
+    } else {
+      const relPath = path.relative(__dirname, fullPath).replace(/\\/g, '/');
+      if (relPath !== 'manifest.json' && relPath !== 'generate-manifest.js') {
+        filesHashes[relPath] = computeSHA256(fullPath);
+      }
+    }
+  });
+};
+
+walk(__dirname);
+
+const manifest = {
+  registry_name: registryName,
+  publisher: publisher,
+  version: version,
+  generated_at: new Date().toISOString(),
+  catalog_hash: filesHashes['catalog.yaml'],
+  files_hashes: filesHashes,
+  minimum_mmdo_version: "3.0.0",
+  safety_policy_version: "1.0",
+  signature: null
+};
+
+fs.writeFileSync('manifest.json', JSON.stringify(manifest, null, 2), 'utf8');
+console.log('manifest.json generated successfully!');
+```
+
+---
+
+## 4. Publishing the Registry
+
+1. Upload all files (preserving structure) to any static HTTPS file host (e.g. GitHub Pages, AWS S3, Cloudflare Pages).
+2. Share the URL to `catalog.yaml` with your team.
+3. Users can add and sync the registry via:
+   ```bash
+   npx multimodel-dev-os registry add my-team-registry https://example.com/my-registry/catalog.yaml --approved
+   npx multimodel-dev-os registry sync my-team-registry --approved
+   ```

package/docs/repository-command-center.md

@@ -65,4 +65,6 @@ npx multimodel-dev-os dashboard
 npx multimodel-dev-os ui
 ```
 
+*   **Workflow Marketplace Catalog Integration**: The dashboard provides a curated marketplace lookup menu under `Workflow Marketplace Catalog...` to list, search, and recommend plugins for the workspace.
+
 For detailed controls, menu hierarchies, and automated CI safety fallbacks, refer to the [Interactive TUI Dashboard Guide](file:///f:/multimodel-dev-os/docs/dashboard.md).

package/docs/trusted-registries.md

@@ -0,0 +1,77 @@
+# Trusted Registries & Provenance
+
+MultiModel Dev OS uses a structured trust model to verify the origin and integrity of third-party plugins before they are permitted to run workflows or write configurations.
+
+## The Trust Hierarchy
+
+Every registry source defined in `.ai/registries/sources.yaml` is assigned a `trust_level`. This level controls whether plugins from that registry are allowed to install and what security policies apply.
+
+```mermaid
+graph TD
+    TRUSTED["Trusted (First-Party / Bundled)"] --> VERIFIED["Verified (Official / Partner)"]
+    VERIFIED --> COMM["Community (Self-hosted / HTTPS)"]
+    COMM --> UNTRUST["Untrusted (Unverified Sources)"]
+```
+
+### 1. Trusted
+* **Source:** Local filesystem, bundled directly in the npm package.
+* **Verification:** Built-in verification suites.
+* **Safety:** Sandboxed, pre-validated declarative configs.
+* **Installation:** Approved by default.
+
+### 2. Verified
+* **Source:** Official MultiModel Dev OS registries or verified enterprise partners.
+* **Verification:** Signed manifests and SHA256 checksum chains.
+* **Safety:** Reviewed schemas with strict write directories.
+* **Installation:** Installs cleanly if remote registries are allowed in policy.
+
+### 3. Community
+* **Source:** User-added HTTPS endpoints or public git repositories.
+* **Verification:** Basic SHA256 checksum verification.
+* **Safety:** Sandboxed logic, restricted file paths.
+* **Installation:** Refused unless `allow_untrusted_install: true` is configured in `.ai/policies/registry-policy.yaml`.
+
+### 4. Untrusted
+* **Source:** Unknown or flagged endpoints.
+* **Verification:** None.
+* **Safety:** High risk.
+* **Installation:** Blocked in all standard configurations.
+
+---
+
+## Provenance Verification Mechanism
+
+To guarantee that remote catalogs have not been tampered with in transit, the registry sync system enforces a cryptographic verification chain.
+
+```
+[Registry Provider]                      [Local Client]
+  catalog.yaml    ---(SHA256 Hash)--->  manifest.json
+  manifest.json   ---(Signature)----->  registry verify
+```
+
+1. **Manifest File (`manifest.json`):** Every verified remote registry publishes a manifest file containing a map of all relative files in the catalog and their expected SHA256 checksums.
+2. **SHA256 Verification:** During `registry sync`, the client downloads the manifest and computes the SHA256 hash of all retrieved assets.
+3. **Local Audit:** The computed hashes are written to `checksums.json` in the cache directory.
+4. **Signature Verification (v3.0.0 Placeholder):** The `signature` field in the manifest provides a placeholder for future asymmetric public-key signature verification.
+
+---
+
+## Integrity Check Command
+
+To manually audit the cache integrity and check if any files have been modified or corrupted, run the `registry verify` command:
+
+```bash
+npx multimodel-dev-os registry verify partner-registry
+```
+
+Example Output:
+```
+🔍 Verifying Registry: partner-registry
+==================================================
+  ✓ catalog.yaml: VERIFIED
+  ✓ manifest.json: VERIFIED
+  ✓ catalog/nextjs-workflows.yaml: VERIFIED
+  ✓ catalog/.ai/skills/nextjs-builder.md: VERIFIED
+
+✔ Registry 'partner-registry' verification passed.
+```

package/docs/v2-roadmap.md

@@ -7,7 +7,7 @@ This document outlines the development path, completed milestones, and future pl
 ## 1. Current Status
 
 > [!IMPORTANT]
-> **v2.8.1 is the active stable release** on the public npm registry. All features below marked ✅ are shipped and production-ready.
+> **v2.9.0 is the active stable release** on the public npm registry. All features below marked ✅ are shipped and production-ready.
 
 ---
 
@@ -66,6 +66,13 @@ This document outlines the development path, completed milestones, and future pl
 - **Headless Fallback & CI Polish**: Polish dry-run outputs and added `--list-actions` parameter to prevent TUI hangs in CI.
 - **Path Traversal Hardening**: Enforce alphanumeric slug checks (`/^[a-z0-9-_]+$/i`) and pattern validation bounds to block traversal vectors.
 
+### v2.9.0 — Local Workflow Marketplace & Plugin Catalog ✅
+- **Workflow Marketplace**: Curated index catalog (`catalog.yaml` and `.ai/plugins/catalog/`) packaging 6 first-party plugins for Git, SEO, WordPress, Next.js, E-commerce, and releases.
+- **Catalog CLI Commands**: Added `catalog list`, `catalog search`, `catalog show`, `catalog categories`, `catalog recommend`, `catalog install`, and `catalog status` to the zero-dependency CLI.
+- **Recommendation Engine**: Automatically ranks and recommends marketplace plugins using package scripts, frameworks, languages, and repo type heuristics.
+- **TUI Dashboard Integration**: Integrated read-only catalog actions (list, search, recommend, status) directly into the interactive command center.
+- **Robust Safety Boundaries**: Reuses the plugin installer validations (traversal protection, whitelist directories, backup overwrites, and exit code 1 gates).
+
 ---
 
 ## 3. Publishing Workflow
@@ -83,10 +90,12 @@ All releases follow this strict publishing checklist:
 
 ---
 
-## 4. Upcoming: v2.9.0 — Auto-Detection & Custom Adaptors
+## 4. Upcoming: v3.0.0 — Unified Autonomous Co-Pilot Ecosystem
 
-*   **Adapter Auto-Detection**: Detect installed tools and automatically recommend adapter setup.
-*   **Custom Adapter Hookups**: Programmatic hooks allowing plugins to register physical adapter configurations dynamically.
+*   **Full Multi-Agent Orchestration**: Dynamic task handoffs between specialized agents.
+*   **Distributed Registry Syncing**: Team-wide configuration synchronization.
+*   **Cryptographic Proposal Signing**: Tamper-proof improvement proposals.
+*   **Real-Time Collaboration**: Live workspace state sharing between agents and developers.
 
 ---
 

package/docs/workflow-marketplace.md

@@ -0,0 +1,22 @@
+# Workflow Marketplace Guide
+
+The local Workflow Marketplace allows you to extend the capabilities of your AI agents by injecting domain-specific coding standards (skills), quality checks, and workflows.
+
+## How it Works
+
+1. **Discovery:**
+   Search or recommend plugins suitable for your project stack:
+   ```bash
+   npx multimodel-dev-os catalog recommend
+   ```
+2. **Installation:**
+   Installing a catalog plugin copies its manifest YAML and declarative files (skills/checks) to the target `.ai/` directory:
+   ```bash
+   npx multimodel-dev-os catalog install nextjs-workflows --approved
+   ```
+3. **Execution:**
+   Once installed, the workflows declared in the plugin become available for execution:
+   ```bash
+   # Run workflow step
+   npx multimodel-dev-os workflow run nextjs-action-check
+   ```

package/docs/workflow-orchestration.md

@@ -60,3 +60,9 @@ The workflow engine enforces strict safety boundaries:
 ## 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.
+
+---
+
+## Curated Workflow Packs
+
+You can extend the available workflows in your repository by installing specialized plugin packs from the [Workflow Marketplace Catalog](/workflow-marketplace) (e.g. `npx multimodel-dev-os catalog install git-workflows --approved`).

package/package.json

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