diff --git a/CHANGELOG.md b/CHANGELOG.md
index 29d2e0f4..380deb68 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -32,6 +32,7 @@ All notable changes to this project will be documented in this file.
 - Module source relocation to bundle namespaces with compatibility shims: legacy `specfact_cli.modules.*` imports now re-export from `specfact_<bundle>.*` namespaces during migration.
 - Official module install output now explicitly confirms verification status (`Verified: official (nold-ai)`).
 - Documentation updates across getting-started, docs landing page, module categories, marketplace guides, layout navigation, and root README to reflect marketplace-distributed official bundles.
+- Full docs alignment audit for the lean-core plus modules-repo architecture (OpenSpec change `docs-01-core-modules-docs-alignment`, issue [#348](https://github.com/nold-ai/specfact-cli/issues/348)): README, docs landing pages, reference pages, tutorials, and publishing/signing guidance were reviewed and corrected so command examples use grouped command paths, bundle ownership is attributed to `specfact-cli-modules`, and temporary-in-core module docs are explicitly marked for future migration.
 - Core help/registry behavior now mounts category groups only for installed bundles, preventing non-installed groups from appearing at top level.
 - Marketplace package loader now resolves namespaced command entrypoints (`src/<package>/<command>/app.py`) for installed modules.
 - Installed bundle detection now infers `specfact-*` bundle IDs from namespaced module names when manifest `bundle` metadata is absent.
diff --git a/README.md b/README.md
index 976520ee..e445ed23 100644
--- a/README.md
+++ b/README.md
@@ -170,13 +170,12 @@ Start with:
 
 ## Modules and Capabilities
 
-**Core modules**
+**Core runtime**
 
-- **Analyze**: Extract specs and plans from existing code.
-- **Validate**: Enforce contracts, run reproducible checks, and block regressions.
-- **Report**: CI/CD summaries and evidence outputs.
+- **Permanent commands**: `init`, `module`, `upgrade`
+- **Core responsibilities**: lifecycle, registry, trust, contracts, orchestration, shared runtime utilities
 
-**Agile DevOps modules**
+**Marketplace-installed bundles**
 
 - **Backlog**: Refinement, dependency analysis, sprint summaries, risk rollups.
 - **Ceremony**: Standup, refinement, and planning entry points.
@@ -199,7 +198,8 @@ For technical architecture details (module lifecycle, registry internals, adapte
 
 SpecFact ships official bundle packages via the dedicated marketplace registry repository
 `nold-ai/specfact-cli-modules`.
-Bundle/module docs now live in the modules repository docs site:
+Bundle-specific docs are still temporarily hosted in this docs set while the long-term
+bundle docs home is prepared in the modules repository docs site:
 `https://nold-ai.github.io/specfact-cli-modules/`.
 
 Install examples:
@@ -225,6 +225,10 @@ auto-install dependencies:
 - `nold-ai/specfact-spec` pulls `nold-ai/specfact-project`
 - `nold-ai/specfact-govern` pulls `nold-ai/specfact-project`
 
+Use this repo's docs for the current CLI/runtime release branch. Module-specific guides
+will move to `specfact-cli-modules` so future bundle-only changes do not require ongoing
+docs maintenance in long-lived `specfact-cli` release branches.
+
 ---
 
 ## Where SpecFact Fits
diff --git a/docs/README.md b/docs/README.md
index 7473a485..3da7bb3e 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -22,8 +22,8 @@ Most tools help **either** coders **or** agile teams. SpecFact does both:
 Recommended command entrypoints:
 - `specfact backlog ceremony standup ...`
 - `specfact backlog ceremony refinement ...`
-- `specfact policy validate ...`
-- `specfact policy suggest ...`
+- `specfact backlog policy validate ...`
+- `specfact backlog policy suggest ...`
 
 What the Policy Engine does in practice:
 - Converts team working agreements (DoR, DoD, flow/PI readiness) into deterministic checks.
@@ -31,9 +31,9 @@ What the Policy Engine does in practice:
 - Produces patch-ready suggestions so teams can remediate quickly.
 
 Start with:
-- `specfact policy init --template scrum`
-- `specfact policy validate --group-by-item`
-- `specfact policy suggest --group-by-item --limit 5`
+- `specfact backlog policy init --template scrum`
+- `specfact backlog policy validate --group-by-item`
+- `specfact backlog policy suggest --group-by-item --limit 5`
 
 **Try it now**
 
@@ -55,13 +55,12 @@ Start with:
 
 ## Modules and Capabilities
 
-**Core modules**
+**Core runtime**
 
-- **Analyze**: Extract specs and plans from existing code.
-- **Validate**: Enforce contracts, run reproducible checks, and block regressions.
-- **Report**: CI/CD summaries and evidence outputs.
+- **Permanent commands**: `init`, `module`, `upgrade`
+- **Core responsibilities**: lifecycle, registry, trust, contracts, orchestration, shared runtime utilities
 
-**Agile DevOps modules**
+**Marketplace-installed bundles**
 
 - **Backlog**: Refinement, dependency analysis, sprint summaries, risk rollups.
 - **Ceremony**: Standup, refinement, and planning entry points.
@@ -85,12 +84,16 @@ SpecFact CLI uses a lifecycle-managed module system:
 
 This is the baseline for marketplace-driven module lifecycle and future community module distribution.
 
+Module-specific guides are still temporarily hosted in this docs set while the long-term
+bundle docs home is prepared in `nold-ai/specfact-cli-modules`.
+
 ### Why the Module System Is the Foundation
 
 This architecture intentionally separates the CLI core from feature modules:
 
 - Core provides lifecycle, registry, contracts, and orchestration.
-- Modules provide feature-specific command logic and integrations.
+- Official workflow bundles are authored and released from `nold-ai/specfact-cli-modules`.
+- This docs set still hosts bundle-specific guidance temporarily for the `0.40.x` release line.
 - Compatibility shims preserve legacy import paths during migration windows.
 
 Practical outcomes:
diff --git a/docs/_layouts/default.html b/docs/_layouts/default.html
index 35c33bcc..956a31cd 100644
--- a/docs/_layouts/default.html
+++ b/docs/_layouts/default.html
@@ -142,6 +142,9 @@ <h2 class="docs-sidebar-title">
 
               <p class="docs-nav-section">Guides</p>
               <ul>
+                <li><a href="{{ '/guides/installing-modules/' | relative_url }}">Installing Modules</a></li>
+                <li><a href="{{ '/guides/module-marketplace/' | relative_url }}">Module Marketplace</a></li>
+                <li><a href="{{ '/guides/marketplace/' | relative_url }}">Marketplace Bundles</a></li>
                 <li><a href="{{ '/guides/command-chains/' | relative_url }}">Command Chains</a></li>
                 <li><a href="{{ '/guides/agile-scrum-workflows/' | relative_url }}">Agile/Scrum Workflows</a></li>
                 <li><a href="{{ '/guides/policy-engine-commands/' | relative_url }}">Policy Engine Commands</a></li>
@@ -149,9 +152,6 @@ <h2 class="docs-sidebar-title">
                 <li><a href="{{ '/guides/module-development/' | relative_url }}">Module Development</a></li>
                 <li><a href="{{ '/guides/adapter-development/' | relative_url }}">Adapter Development</a></li>
                 <li><a href="{{ '/guides/extending-projectbundle/' | relative_url }}">Extending ProjectBundle</a></li>
-                <li><a href="{{ '/guides/installing-modules/' | relative_url }}">Installing Modules</a></li>
-                <li><a href="{{ '/guides/module-marketplace/' | relative_url }}">Module Marketplace</a></li>
-                <li><a href="{{ '/guides/marketplace/' | relative_url }}">Marketplace Bundles</a></li>
                 <li><a href="{{ '/guides/module-signing-and-key-rotation/' | relative_url }}">Module Signing and Key Rotation</a></li>
                 <li><a href="{{ '/guides/using-module-security-and-extensions/' | relative_url }}">Using Module Security and Extensions</a></li>
                 <li><a href="{{ '/guides/brownfield-engineer/' | relative_url }}">Working With Existing Code</a></li>
@@ -181,6 +181,7 @@ <h2 class="docs-sidebar-title">
               <ul>
                 <li><a href="{{ '/reference/' | relative_url }}">Reference Documentation</a></li>
                 <li><a href="{{ '/reference/commands/' | relative_url }}">Command Reference</a></li>
+                <li><a href="{{ '/reference/module-categories/' | relative_url }}">Module Categories</a></li>
                 <li><a href="{{ '/reference/thorough-codebase-validation/' | relative_url }}">Thorough Codebase Validation</a></li>
                 <li><a href="{{ '/reference/authentication/' | relative_url }}">Authentication</a></li>
                 <li><a href="{{ '/reference/architecture/' | relative_url }}">Architecture</a></li>
@@ -191,7 +192,6 @@ <h2 class="docs-sidebar-title">
                 <li><a href="{{ '/reference/projectbundle-schema/' | relative_url }}">ProjectBundle Schema</a></li>
                 <li><a href="{{ '/reference/module-contracts/' | relative_url }}">Module Contracts</a></li>
                 <li><a href="{{ '/reference/module-security/' | relative_url }}">Module Security</a></li>
-                <li><a href="{{ '/reference/module-categories/' | relative_url }}">Module Categories</a></li>
                 <li><a href="{{ '/reference/bridge-registry/' | relative_url }}">Bridge Registry</a></li>
                 <li><a href="{{ '/guides/integrations-overview/' | relative_url }}">Integrations Overview</a></li>
               </ul>
diff --git a/docs/adapters/azuredevops.md b/docs/adapters/azuredevops.md
index 2009cf73..1648bc7b 100644
--- a/docs/adapters/azuredevops.md
+++ b/docs/adapters/azuredevops.md
@@ -6,6 +6,10 @@ permalink: /adapters/azuredevops/
 
 # Azure DevOps Adapter
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 The Azure DevOps adapter provides bidirectional synchronization between OpenSpec change proposals and Azure DevOps work items, enabling agile DevOps-driven workflow support for enterprise teams.
 
 ## Overview
@@ -64,7 +68,7 @@ The adapter automatically derives work item type from your project's process tem
 You can override with `--ado-work-item-type`:
 
 ```bash
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org \
   --ado-project your-project \
   --ado-work-item-type "Bug" \
@@ -446,7 +450,7 @@ This handles cases where:
 
 ```bash
 # Export OpenSpec change proposals to Azure DevOps work items
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org \
   --ado-project your-project \
   --repo /path/to/openspec-repo
@@ -456,7 +460,7 @@ specfact sync bridge --adapter ado --mode export-only \
 
 ```bash
 # Import work items AND export proposals
-specfact sync bridge --adapter ado --bidirectional \
+specfact project sync bridge --adapter ado --bidirectional \
   --ado-org your-org \
   --ado-project your-project \
   --repo /path/to/openspec-repo
@@ -466,7 +470,7 @@ specfact sync bridge --adapter ado --bidirectional \
 
 ```bash
 # Import specific work items into bundle
-specfact sync bridge --adapter ado --mode bidirectional \
+specfact project sync bridge --adapter ado --mode bidirectional \
   --ado-org your-org \
   --ado-project your-project \
   --bundle main \
@@ -478,7 +482,7 @@ specfact sync bridge --adapter ado --mode bidirectional \
 
 ```bash
 # Update existing work item with latest proposal content
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org \
   --ado-project your-project \
   --change-ids add-feature-x \
@@ -490,7 +494,7 @@ specfact sync bridge --adapter ado --mode export-only \
 
 ```bash
 # Detect code changes and add progress comments
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org \
   --ado-project your-project \
   --track-code-changes \
@@ -502,7 +506,7 @@ specfact sync bridge --adapter ado --mode export-only \
 
 ```bash
 # Export from bundle to ADO (uses stored lossless content)
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org \
   --ado-project your-project \
   --bundle main \
diff --git a/docs/adapters/github.md b/docs/adapters/github.md
index c1b28b3f..f936c84a 100644
--- a/docs/adapters/github.md
+++ b/docs/adapters/github.md
@@ -6,6 +6,10 @@ permalink: /adapters/github/
 
 # GitHub Adapter
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 The GitHub adapter provides bidirectional synchronization between OpenSpec change proposals and GitHub Issues, enabling agile DevOps-driven workflow support.
 
 ## Overview
@@ -334,14 +338,14 @@ To create a GitHub issue from an OpenSpec change and have the issue number/URL w
 
 ```bash
 # Export one or more changes; creates issues and updates proposal.md Source Tracking
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo . \
   --repo-owner nold-ai \
   --repo-name specfact-cli \
   --change-ids <change-id>
 
 # Example: export backlog-scrum-05-summarize-markdown-output
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo . \
   --repo-owner nold-ai \
   --repo-name specfact-cli \
@@ -362,7 +366,7 @@ When you improve comment logic or branch detection, use `--include-archived` to
 
 ```bash
 # Update all archived proposals with new comment logic
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --include-archived \
@@ -370,7 +374,7 @@ specfact sync bridge --adapter github --mode export-only \
   --repo /path/to/openspec-repo
 
 # Update specific archived proposal
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --change-ids add-code-change-tracking \
diff --git a/docs/examples/brownfield-data-pipeline.md b/docs/examples/brownfield-data-pipeline.md
index e3b18886..998fd289 100644
--- a/docs/examples/brownfield-data-pipeline.md
+++ b/docs/examples/brownfield-data-pipeline.md
@@ -29,7 +29,7 @@ You inherited a 5-year-old Python data pipeline with:
 
 ```bash
 # Analyze the legacy data pipeline
-specfact import from-code customer-etl \
+specfact project import from-code customer-etl \
   --repo ./legacy-etl-pipeline \
   --language python
 
@@ -81,7 +81,7 @@ After extracting the plan, create a hard SDD manifest:
 
 ```bash
 # Create SDD manifest from the extracted plan
-specfact plan harden customer-etl
+specfact project plan harden customer-etl
 ```
 
 ### Output
@@ -109,7 +109,7 @@ Validate that your SDD manifest matches your plan:
 
 ```bash
 # Validate SDD manifest against plan
-specfact enforce sdd customer-etl
+specfact govern enforce sdd customer-etl
 ```
 
 ### Output
@@ -131,7 +131,7 @@ Promote your plan to "review" stage (requires valid SDD):
 
 ```bash
 # Promote plan to review stage
-specfact plan promote customer-etl --stage review
+specfact project plan promote customer-etl --stage review
 ```
 
 **Why this matters**: Plan promotion enforces SDD presence, ensuring you have a hard spec before starting modernization work.
@@ -211,7 +211,7 @@ def transform_order(raw_order: Dict[str, Any]) -> Dict[str, Any]:
 After adding contracts, re-validate your SDD:
 
 ```bash
-specfact enforce sdd customer-etl
+specfact govern enforce sdd customer-etl
 ```
 
 ---
@@ -338,7 +338,7 @@ def transform_order(raw_order: Dict[str, Any]) -> Dict[str, Any]:
 
 **Solution:**
 
-1. Ran `specfact import from-code` → 47 features extracted in 12 seconds
+1. Ran `specfact project import from-code` → 47 features extracted in 12 seconds
 2. Added contracts to 23 critical data transformation functions
 3. CrossHair discovered 6 edge cases in legacy validation logic
 4. Enforced contracts during migration, blocked 11 regressions
diff --git a/docs/examples/brownfield-django-modernization.md b/docs/examples/brownfield-django-modernization.md
index d2045653..70fabb0b 100644
--- a/docs/examples/brownfield-django-modernization.md
+++ b/docs/examples/brownfield-django-modernization.md
@@ -29,7 +29,7 @@ You inherited a 3-year-old Django app with:
 
 ```bash
 # Analyze the legacy Django app
-specfact import from-code customer-portal \
+specfact project import from-code customer-portal \
   --repo ./legacy-django-app \
   --language python
 
@@ -85,7 +85,7 @@ After extracting the plan, create a hard SDD (Spec-Driven Development) manifest
 
 ```bash
 # Create SDD manifest from the extracted plan
-specfact plan harden customer-portal
+specfact project plan harden customer-portal
 ```
 
 ### Output
@@ -127,7 +127,7 @@ Before starting modernization, validate that your SDD manifest matches your plan
 
 ```bash
 # Validate SDD manifest against plan
-specfact enforce sdd customer-portal
+specfact govern enforce sdd customer-portal
 ```
 
 ### Output
@@ -161,7 +161,7 @@ specfact enforce sdd customer-portal
    - 2 medium severity deviations
    - Fix: Add contracts to stories or adjust thresholds
 
-💡 Run 'specfact plan harden' to update SDD manifest
+💡 Run 'specfact project plan harden' to update SDD manifest
 ```
 
 ---
@@ -172,7 +172,7 @@ Review your plan to identify ambiguities and ensure SDD compliance:
 
 ```bash
 # Review plan (automatically checks SDD, bundle name as positional argument)
-specfact plan review customer-portal --max-questions 5
+specfact project plan review customer-portal --max-questions 5
 ```
 
 ### Output
@@ -193,7 +193,7 @@ specfact plan review customer-portal --max-questions 5
    ...
 
 ✅ Review complete: 5 questions identified
-💡 Run 'specfact plan review --answers answers.json' to resolve in bulk
+💡 Run 'specfact project plan review --answers answers.json' to resolve in bulk
 ```
 
 **SDD integration**: The review command automatically checks for SDD presence and validates coverage thresholds, warning you if thresholds aren't met.
@@ -206,7 +206,7 @@ Before starting modernization, promote your plan to "review" stage. This require
 
 ```bash
 # Promote plan to review stage (requires SDD, bundle name as positional argument)
-specfact plan promote customer-portal --stage review
+specfact project plan promote customer-portal --stage review
 ```
 
 ### Output (Success)
@@ -231,7 +231,7 @@ specfact plan promote customer-portal --stage review
 
 ```text
 ❌ SDD manifest is required for promotion to 'review' or higher stages
-💡 Run 'specfact plan harden' to create SDD manifest
+💡 Run 'specfact project plan harden' to create SDD manifest
 ```
 
 **Why this matters**: Plan promotion now enforces SDD presence, ensuring you have a hard spec before starting modernization work. This prevents drift and ensures coverage thresholds are met.
@@ -246,7 +246,7 @@ Review the extracted plan to identify high-risk functions:
 
 ```bash
 # Review extracted plan using CLI commands
-specfact plan review customer-portal
+specfact project plan review customer-portal
 
 ```
 
@@ -318,7 +318,7 @@ After adding contracts, re-validate your SDD to ensure coverage thresholds are m
 
 ```bash
 # Re-validate SDD after adding contracts
-specfact enforce sdd customer-portal
+specfact govern enforce sdd customer-portal
 ```
 
 This ensures your SDD manifest reflects the current state of your codebase and that coverage thresholds are maintained.
diff --git a/docs/examples/brownfield-flask-api.md b/docs/examples/brownfield-flask-api.md
index 30797c00..601d143a 100644
--- a/docs/examples/brownfield-flask-api.md
+++ b/docs/examples/brownfield-flask-api.md
@@ -27,7 +27,7 @@ You inherited a 2-year-old Flask REST API with:
 
 ```bash
 # Analyze the legacy Flask API
-specfact import from-code customer-api \
+specfact project import from-code customer-api \
   --repo ./legacy-flask-api \
   --language python
 
@@ -80,7 +80,7 @@ After extracting the plan, create a hard SDD manifest:
 
 ```bash
 # Create SDD manifest from the extracted plan
-specfact plan harden customer-api
+specfact project plan harden customer-api
 ```
 
 ### Output
@@ -108,7 +108,7 @@ Validate that your SDD manifest matches your plan:
 
 ```bash
 # Validate SDD manifest against plan
-specfact enforce sdd customer-api
+specfact govern enforce sdd customer-api
 ```
 
 ### Output
@@ -130,7 +130,7 @@ Promote your plan to "review" stage (requires valid SDD):
 
 ```bash
 # Promote plan to review stage
-specfact plan promote customer-api --stage review
+specfact project plan promote customer-api --stage review
 ```
 
 **Why this matters**: Plan promotion enforces SDD presence, ensuring you have a hard spec before starting modernization work.
@@ -212,7 +212,7 @@ def create_order():
 After adding contracts, re-validate your SDD:
 
 ```bash
-specfact enforce sdd customer-api
+specfact govern enforce sdd customer-api
 ```
 
 ---
diff --git a/docs/examples/dogfooding-specfact-cli.md b/docs/examples/dogfooding-specfact-cli.md
index 83d638d4..264995f5 100644
--- a/docs/examples/dogfooding-specfact-cli.md
+++ b/docs/examples/dogfooding-specfact-cli.md
@@ -25,7 +25,7 @@ We built SpecFact CLI and wanted to validate that it actually works in the real
 First, we analyzed the existing codebase to see what features it discovered:
 
 ```bash
-specfact import from-code specfact-cli --repo . --confidence 0.5
+specfact project import from-code specfact-cli --repo . --confidence 0.5
 ```
 
 **Output**:
@@ -89,7 +89,7 @@ Here's what the analyzer extracted from our `EnforcementConfig` class:
 Next, we configured quality gates to block HIGH severity violations:
 
 ```bash
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 ```
 
 **Output**:
@@ -156,7 +156,7 @@ features:
 Now comes the magic - compare the manual plan against what's actually implemented:
 
 ```bash
-specfact plan compare
+specfact project plan compare
 ```
 
 ### Results
@@ -248,8 +248,8 @@ Fix the blocking deviations or adjust enforcement config
 Let's try again with **minimal enforcement** (never blocks):
 
 ```bash
-specfact enforce stage --preset minimal
-specfact plan compare
+specfact govern enforce stage --preset minimal
+specfact project plan compare
 ```
 
 ### New Enforcement Report
@@ -291,7 +291,7 @@ After validating the brownfield analysis workflow, we took it a step further: **
 First, we generated a structured prompt for our AI IDE (Cursor) to enhance the telemetry module:
 
 ```bash
-specfact generate contracts-prompt src/specfact_cli/telemetry.py --bundle specfact-cli-test --apply all-contracts --no-interactive
+specfact spec generate contracts-prompt src/specfact_cli/telemetry.py --bundle specfact-cli-test --apply all-contracts --no-interactive
 ```
 
 **Output**:
@@ -335,7 +335,7 @@ We copied the prompt to Cursor (our AI IDE), which:
 The AI IDE ran SpecFact CLI validation on the enhanced code:
 
 ```bash
-specfact generate contracts-apply enhanced_telemetry.py --original src/specfact_cli/telemetry.py
+specfact spec generate contracts-apply enhanced_telemetry.py --original src/specfact_cli/telemetry.py
 ```
 
 ### Validation Results
@@ -440,7 +440,7 @@ This demonstrates **real production use**:
 
 ```bash
 # 1. Generate prompt (1 second)
-specfact generate contracts-prompt src/specfact_cli/telemetry.py \
+specfact spec generate contracts-prompt src/specfact_cli/telemetry.py \
   --bundle specfact-cli-test \
   --apply all-contracts \
   --no-interactive
@@ -452,7 +452,7 @@ specfact generate contracts-prompt src/specfact_cli/telemetry.py \
 # - AI IDE writes to enhanced_telemetry.py
 
 # 3. Validate and apply (10 seconds)
-specfact generate contracts-apply enhanced_telemetry.py \
+specfact spec generate contracts-apply enhanced_telemetry.py \
   --original src/specfact_cli/telemetry.py
 # ✅ 7-step validation passed
 # ✅ All tests passed (10/10)
@@ -546,15 +546,15 @@ These are **actual questions** that need answers, not false positives!
 
 ```bash
 # 1. Analyze existing codebase (3 seconds)
-specfact import from-code specfact-cli --repo . --confidence 0.5
+specfact project import from-code specfact-cli --repo . --confidence 0.5
 # ✅ Discovers 19 features, 49 stories
 
 # 2. Set quality gates (1 second)
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 # ✅ BLOCK HIGH, WARN MEDIUM, LOG LOW
 
 # 3. Compare plans (5 seconds) - uses active plan or default bundle
-specfact plan compare
+specfact project plan compare
 # ✅ Finds 24 deviations
 # ❌ BLOCKS execution (2 HIGH violations)
 
diff --git a/docs/examples/integration-showcases/integration-showcases-testing-guide.md b/docs/examples/integration-showcases/integration-showcases-testing-guide.md
index 79dade6e..1109b214 100644
--- a/docs/examples/integration-showcases/integration-showcases-testing-guide.md
+++ b/docs/examples/integration-showcases/integration-showcases-testing-guide.md
@@ -159,7 +159,7 @@ def process_payment(request):
       - **Suggested plan name for Example 1**: `Payment Processing` or `Legacy Payment View`
    3. **CLI Execution**: The AI will:
       - Sanitize the name (lowercase, remove spaces/special chars)
-      - Run `specfact import from-code <sanitized-name> --repo <workspace> --confidence 0.5`
+      - Run `specfact project import from-code <sanitized-name> --repo <workspace> --confidence 0.5`
       - Capture CLI output and create a project bundle
    4. **CLI Output Summary**: The AI will present a summary showing:
       - Bundle name used
@@ -193,7 +193,7 @@ def process_payment(request):
    3. **Apply Enrichment**: The AI will run:
 
       ```bash
-      specfact import from-code <name> --repo <workspace> --enrichment .specfact/projects/<name>/reports/enrichment/<name>-<timestamp>.enrichment.md --confidence 0.5
+      specfact project import from-code <name> --repo <workspace> --enrichment .specfact/projects/<name>/reports/enrichment/<name>-<timestamp>.enrichment.md --confidence 0.5
       ```
 
    4. **Enriched Project Bundle**: The CLI will update:
@@ -229,7 +229,7 @@ uvx specfact-cli@latest --no-banner import from-code --repo . --output-format ya
 - **Important**: `--no-banner` is a global parameter and must come **before** the subcommand, not after
   - ✅ Correct: `specfact --no-banner enforce stage --preset balanced`
   - ✅ Correct: `uvx specfact-cli@latest --no-banner import from-code --repo . --output-format yaml`
-  - ❌ Wrong: `specfact enforce stage --preset balanced --no-banner`
+  - ❌ Wrong: `specfact govern enforce stage --preset balanced --no-banner`
   - ❌ Wrong: `uvx specfact-cli@latest import from-code --repo . --output-format yaml --no-banner`
 
 **Note**: The `import from-code` command analyzes the entire repository/directory, not individual files. It will automatically detect and analyze all Python files in the current directory.
@@ -238,7 +238,7 @@ uvx specfact-cli@latest --no-banner import from-code --repo . --output-format ya
 
 **CLI vs Interactive Mode**:
 
-- **CLI-only** (`uvx specfact-cli@latest import from-code` or `specfact import from-code`): Uses AST-based analyzer (CI/CD mode)
+- **CLI-only** (`uvx specfact-cli@latest import from-code` or `specfact project import from-code`): Uses AST-based analyzer (CI/CD mode)
   - May show "0 features" for minimal test cases
   - Limited to AST pattern matching
   - Works but may not detect all features in simple examples
@@ -1040,7 +1040,7 @@ Report written to: .specfact/projects/<bundle-name>/reports/enforcement/report-<
   - Type checking (basedpyright) - type annotations and type safety
 
 - **Conditionally runs** (only if present):
-  - Contract exploration (CrossHair) - only if `[tool.crosshair]` config exists in `pyproject.toml` (use `specfact repro setup` to generate) and `src/` directory exists (symbolic execution to find counterexamples, not runtime contract validation)
+  - Contract exploration (CrossHair) - only if `[tool.crosshair]` config exists in `pyproject.toml` (use `specfact code repro setup` to generate) and `src/` directory exists (symbolic execution to find counterexamples, not runtime contract validation)
   - Semgrep async patterns - only if `tools/semgrep/async.yml` exists (requires semgrep installed)
   - Property tests (pytest) - only if `tests/contracts/` directory exists
   - Smoke tests (pytest) - only if `tests/smoke/` directory exists
@@ -1048,7 +1048,7 @@ Report written to: .specfact/projects/<bundle-name>/reports/enforcement/report-<
 **CrossHair Setup**: Before running `repro` for the first time, set up CrossHair configuration:
 
 ```bash
-specfact repro setup
+specfact code repro setup
 ```
 This automatically generates `[tool.crosshair]` configuration in `pyproject.toml` to enable contract exploration.
 
@@ -1061,7 +1061,7 @@ This automatically generates `[tool.crosshair]` configuration in `pyproject.toml
 1. ✅ Created plan bundle from code (`import from-code`)
 2. ✅ Enriched plan with semantic understanding (if using interactive mode)
 3. ✅ Configured enforcement (balanced preset)
-4. ✅ Ran validation suite (`specfact repro`)
+4. ✅ Ran validation suite (`specfact code repro`)
 5. ✅ Validation checks executed (linting, type checking, contract exploration)
 
 **Expected Test Results**:
@@ -1078,7 +1078,7 @@ This automatically generates `[tool.crosshair]` configuration in `pyproject.toml
 - ✅ **Type Safety**: Type checking detects mismatches before merge
 - ✅ **PR Blocking**: Workflow fails (exit code 1) when violations are found
 
-**Validation Status**: Example 3 is **fully validated** in production CI/CD. The GitHub Actions workflow runs `specfact repro` in the specfact-cli repository and successfully:
+**Validation Status**: Example 3 is **fully validated** in production CI/CD. The GitHub Actions workflow runs `specfact code repro` in the specfact-cli repository and successfully:
 
 - ✅ Runs linting (ruff) checks
 - ✅ Runs async pattern detection (Semgrep)
@@ -1650,12 +1650,12 @@ rm -rf specfact-integration-tests
 
 ### Example 3: GitHub Actions Integration - ✅ **FULLY VALIDATED**
 
-**Status**: Fully validated in production CI/CD - workflow runs `specfact repro` in GitHub Actions and successfully blocks PRs when validation fails
+**Status**: Fully validated in production CI/CD - workflow runs `specfact code repro` in GitHub Actions and successfully blocks PRs when validation fails
 
 **What's Validated**:
 
-- ✅ GitHub Actions workflow configuration (uses `pip install specfact-cli`, includes `specfact repro`)
-- ✅ `specfact repro` command execution in CI/CD environment
+- ✅ GitHub Actions workflow configuration (uses `pip install specfact-cli`, includes `specfact code repro`)
+- ✅ `specfact code repro` command execution in CI/CD environment
 - ✅ Validation checks execution (linting, type checking, Semgrep, CrossHair)
 - ✅ Type checking error detection (basedpyright detects type mismatches)
 - ✅ PR blocking when validation fails (exit code 1 blocks merge)
@@ -1674,7 +1674,7 @@ rm -rf specfact-integration-tests
 - Type checking (basedpyright): ✗ FAILED (detects type errors correctly)
 - Contract exploration (CrossHair): ⊘ SKIPPED (signature analysis limitation, non-blocking)
 
-**Conclusion**: Example 3 is **fully validated** in production CI/CD. The GitHub Actions workflow successfully runs `specfact repro` and blocks PRs when validation fails. The workflow demonstrates how SpecFact integrates into CI/CD pipelines to prevent bad code from merging.
+**Conclusion**: Example 3 is **fully validated** in production CI/CD. The GitHub Actions workflow successfully runs `specfact code repro` and blocks PRs when validation fails. The workflow demonstrates how SpecFact integrates into CI/CD pipelines to prevent bad code from merging.
 
 ### Example 5: Agentic Workflows - ⏳ **PENDING VALIDATION**
 
diff --git a/docs/examples/integration-showcases/integration-showcases.md b/docs/examples/integration-showcases/integration-showcases.md
index 072289a4..9b904809 100644
--- a/docs/examples/integration-showcases/integration-showcases.md
+++ b/docs/examples/integration-showcases/integration-showcases.md
@@ -220,7 +220,7 @@ jobs:
 **What This Does**:
 
 1. **Configure Enforcement**: Sets enforcement mode to `balanced` (blocks HIGH severity violations, warns on MEDIUM)
-2. **Run Validation**: Executes `specfact repro` which runs validation checks:
+2. **Run Validation**: Executes `specfact code repro` which runs validation checks:
 
    **Always runs**:
    - Linting (ruff) - checks code style and common Python issues
diff --git a/docs/examples/quick-examples.md b/docs/examples/quick-examples.md
index 7a71fe6b..a92c2936 100644
--- a/docs/examples/quick-examples.md
+++ b/docs/examples/quick-examples.md
@@ -30,13 +30,13 @@ pip install specfact-cli
 
 ```bash
 # Starting a new project?
-specfact plan init my-project --interactive
+specfact project plan init my-project --interactive
 
 # Have existing code?
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 
 # Using GitHub Spec-Kit?
-specfact import from-bridge --adapter speckit --repo ./my-project --dry-run
+specfact project import from-bridge --adapter speckit --repo ./my-project --dry-run
 
 ```
 
@@ -44,10 +44,10 @@ specfact import from-bridge --adapter speckit --repo ./my-project --dry-run
 
 ```bash
 # Preview migration
-specfact import from-bridge --adapter speckit --repo ./spec-kit-project --dry-run
+specfact project import from-bridge --adapter speckit --repo ./spec-kit-project --dry-run
 
 # Execute migration
-specfact import from-bridge --adapter speckit --repo ./spec-kit-project --write
+specfact project import from-bridge --adapter speckit --repo ./spec-kit-project --write
 
 ```
 
@@ -55,30 +55,30 @@ specfact import from-bridge --adapter speckit --repo ./spec-kit-project --write
 
 ```bash
 # Basic import (bundle name as positional argument)
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 
 # With confidence threshold
-specfact import from-code my-project --repo . --confidence 0.7
+specfact project import from-code my-project --repo . --confidence 0.7
 
 # Shadow mode (observe only)
-specfact import from-code my-project --repo . --shadow-only
+specfact project import from-code my-project --repo . --shadow-only
 
 # CoPilot mode (enhanced prompts)
 specfact --mode copilot import from-code my-project --repo . --confidence 0.7
 
 # Re-validate existing features (force re-analysis)
-specfact import from-code my-project --repo . --revalidate-features
+specfact project import from-code my-project --repo . --revalidate-features
 
 # Resume interrupted import (features saved early as checkpoint)
 # If import is cancelled, just run the same command again
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 
 # Partial analysis (analyze specific subdirectory only)
-specfact import from-code my-project --repo . --entry-point src/core
+specfact project import from-code my-project --repo . --entry-point src/core
 
 # Large codebase with progress reporting
 # Progress bars show: feature analysis, source linking, contract extraction
-specfact import from-code large-project --repo . --confidence 0.5
+specfact project import from-code large-project --repo . --confidence 0.5
 
 ```
 
@@ -86,30 +86,30 @@ specfact import from-code large-project --repo . --confidence 0.5
 
 ```bash
 # Initialize plan (bundle name as positional argument)
-specfact plan init my-project --interactive
+specfact project plan init my-project --interactive
 
 # Add feature (bundle name via --bundle option)
-specfact plan add-feature \
+specfact project plan add-feature \
   --bundle my-project \
   --key FEATURE-001 \
   --title "User Authentication" \
   --outcomes "Users can login securely"
 
 # Add story (bundle name via --bundle option)
-specfact plan add-story \
+specfact project plan add-story \
   --bundle my-project \
   --feature FEATURE-001 \
   --title "As a user, I can login with email and password" \
   --acceptance "Login form validates input"
 
 # Create hard SDD manifest (required for promotion)
-specfact plan harden my-project
+specfact project plan harden my-project
 
 # Review plan (checks SDD automatically, bundle name as positional argument)
-specfact plan review my-project --max-questions 5
+specfact project plan review my-project --max-questions 5
 
 # Promote plan (requires SDD for review+ stages)
-specfact plan promote my-project --stage review
+specfact project plan promote my-project --stage review
 
 ```
 
@@ -117,15 +117,15 @@ specfact plan promote my-project --stage review
 
 ```bash
 # Quick comparison (auto-detects plans)
-specfact plan compare --repo .
+specfact project plan compare --repo .
 
 # Explicit comparison (bundle directory paths)
-specfact plan compare \
+specfact project plan compare \
   --manual .specfact/projects/manual-plan \
   --auto .specfact/projects/auto-derived
 
 # Code vs plan comparison
-specfact plan compare --code-vs-plan --repo .
+specfact project plan compare --code-vs-plan --repo .
 
 ```
 
@@ -133,16 +133,16 @@ specfact plan compare --code-vs-plan --repo .
 
 ```bash
 # One-time Spec-Kit sync (via bridge adapter)
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
 
 # Watch mode (continuous sync)
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
 
 # Repository sync
-specfact sync repository --repo . --target .specfact
+specfact project sync repository --repo . --target .specfact
 
 # Repository watch mode
-specfact sync repository --repo . --watch --interval 5
+specfact project sync repository --repo . --watch --interval 5
 
 ```
 
@@ -150,38 +150,38 @@ specfact sync repository --repo . --watch --interval 5
 
 ```bash
 # Create hard SDD manifest from plan
-specfact plan harden
+specfact project plan harden
 
 # Validate SDD manifest against plan
-specfact enforce sdd
+specfact govern enforce sdd
 
 # Validate SDD with custom output format
-specfact enforce sdd --output-format json --out validation-report.json
+specfact govern enforce sdd --output-format json --out validation-report.json
 
 # Review plan (automatically checks SDD)
-specfact plan review --max-questions 5
+specfact project plan review --max-questions 5
 
 # Promote plan (requires SDD for review+ stages)
-specfact plan promote --stage review
+specfact project plan promote --stage review
 
 # Force promotion despite SDD validation failures
-specfact plan promote --stage review --force
+specfact project plan promote --stage review --force
 ```
 
 ## Enforcement
 
 ```bash
 # Shadow mode (observe only)
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 
 # Balanced mode (block HIGH, warn MEDIUM)
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # Strict mode (block everything)
-specfact enforce stage --preset strict
+specfact govern enforce stage --preset strict
 
 # Enforce SDD validation
-specfact enforce sdd
+specfact govern enforce sdd
 
 ```
 
@@ -189,19 +189,19 @@ specfact enforce sdd
 
 ```bash
 # First-time setup: Configure CrossHair for contract exploration
-specfact repro setup
+specfact code repro setup
 
 # Quick validation
-specfact repro
+specfact code repro
 
 # Verbose validation
-specfact repro --verbose
+specfact code repro --verbose
 
 # With budget
-specfact repro --verbose --budget 120
+specfact code repro --verbose --budget 120
 
 # Apply auto-fixes
-specfact repro --fix --budget 120
+specfact code repro --fix --budget 120
 
 ```
 
@@ -223,7 +223,7 @@ specfact init ide --ide cursor --force
 
 ```bash
 # Auto-detect mode (default)
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 
 # Force CI/CD mode
 specfact --mode cicd import from-code my-project --repo .
@@ -233,7 +233,7 @@ specfact --mode copilot import from-code my-project --repo .
 
 # Set via environment variable
 export SPECFACT_MODE=copilot
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 ```
 
 ## Common Workflows
@@ -242,15 +242,15 @@ specfact import from-code my-project --repo .
 
 ```bash
 # Morning: Check status
-specfact repro --verbose
-specfact plan compare --repo .
+specfact code repro --verbose
+specfact project plan compare --repo .
 
 # During development: Watch mode
-specfact sync repository --repo . --watch --interval 5
+specfact project sync repository --repo . --watch --interval 5
 
 # Before committing: Validate
-specfact repro
-specfact plan compare --repo .
+specfact code repro
+specfact project plan compare --repo .
 
 ```
 
@@ -258,25 +258,25 @@ specfact plan compare --repo .
 
 ```bash
 # Step 1: Extract specs from legacy code
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 
 # Step 2: Create hard SDD manifest
-specfact plan harden my-project
+specfact project plan harden my-project
 
 # Step 3: Validate SDD before starting work
-specfact enforce sdd my-project
+specfact govern enforce sdd my-project
 
 # Step 4: Review plan (checks SDD automatically)
-specfact plan review my-project --max-questions 5
+specfact project plan review my-project --max-questions 5
 
 # Step 5: Promote plan (requires SDD for review+ stages)
-specfact plan promote my-project --stage review
+specfact project plan promote my-project --stage review
 
 # Step 6: Add contracts to critical paths
 # ... (add @icontract decorators to code)
 
 # Step 7: Re-validate SDD after adding contracts
-specfact enforce sdd my-project
+specfact govern enforce sdd my-project
 
 # Step 8: Continue modernization with SDD safety net
 ```
@@ -285,16 +285,16 @@ specfact enforce sdd my-project
 
 ```bash
 # Step 1: Preview
-specfact import from-bridge --adapter speckit --repo . --dry-run
+specfact project import from-bridge --adapter speckit --repo . --dry-run
 
 # Step 2: Execute
-specfact import from-bridge --adapter speckit --repo . --write
+specfact project import from-bridge --adapter speckit --repo . --write
 
 # Step 3: Set up sync
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
 
 # Step 4: Enable enforcement
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 
 ```
 
@@ -302,16 +302,16 @@ specfact enforce stage --preset minimal
 
 ```bash
 # Step 1: Analyze code
-specfact import from-code my-project --repo . --confidence 0.7
+specfact project import from-code my-project --repo . --confidence 0.7
 
 # Step 2: Review plan using CLI commands
-specfact plan review my-project
+specfact project plan review my-project
 
 # Step 3: Compare with manual plan
-specfact plan compare --repo .
+specfact project plan compare --repo .
 
 # Step 4: Set up watch mode
-specfact sync repository --repo . --watch --interval 5
+specfact project sync repository --repo . --watch --interval 5
 ```
 
 ## Advanced Examples
@@ -320,18 +320,18 @@ specfact sync repository --repo . --watch --interval 5
 
 ```bash
 # Bundle name is a positional argument (not --name option)
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 
 ```
 
 ### Custom Report
 
 ```bash
-specfact import from-code \
+specfact project import from-code \
   --repo . \
   --report analysis-report.md
 
-specfact plan compare \
+specfact project plan compare \
   --repo . \
   --out comparison-report.md
 
@@ -341,10 +341,10 @@ specfact plan compare \
 
 ```bash
 # Classname format (default for auto-derived)
-specfact import from-code my-project --repo . --key-format classname
+specfact project import from-code my-project --repo . --key-format classname
 
 # Sequential format (for manual plans)
-specfact import from-code my-project --repo . --key-format sequential
+specfact project import from-code my-project --repo . --key-format sequential
 
 ```
 
@@ -352,10 +352,10 @@ specfact import from-code my-project --repo . --key-format sequential
 
 ```bash
 # Lower threshold (more features, lower confidence)
-specfact import from-code my-project --repo . --confidence 0.3
+specfact project import from-code my-project --repo . --confidence 0.3
 
 # Higher threshold (fewer features, higher confidence)
-specfact import from-code my-project --repo . --confidence 0.8
+specfact project import from-code my-project --repo . --confidence 0.8
 ```
 
 ## Integration Examples
diff --git a/docs/getting-started/README.md b/docs/getting-started/README.md
index 7417f8ee..16a48f38 100644
--- a/docs/getting-started/README.md
+++ b/docs/getting-started/README.md
@@ -48,8 +48,8 @@ uvx specfact-cli@latest project plan init my-project --interactive
 Flat root commands were removed. Use grouped command forms:
 
 - `specfact validate ...` -> `specfact code validate ...`
-- `specfact plan ...` -> `specfact project plan ...`
-- `specfact policy ...` -> `specfact backlog policy ...`
+- `specfact project plan ...` -> `specfact project plan ...`
+- `specfact backlog policy ...` -> `specfact backlog policy ...`
 
 First-run bundle selection examples:
 
@@ -80,7 +80,7 @@ Some bundles install dependencies automatically:
 
 - 📖 **[Installation Guide](installation.md)** - Install SpecFact CLI
 - 📖 **[First Steps](first-steps.md)** - Step-by-step first commands
-- 📖 **[Module Bootstrap Checklist](module-bootstrap-checklist.md)** - Verify bundled modules are installed in user/project scope
+- 📖 **[Module Bootstrap Checklist](module-bootstrap-checklist.md)** - Verify official bundles are installed in user/project scope
 - 📖 **[Tutorial: Using SpecFact with OpenSpec or Spec-Kit](tutorial-openspec-speckit.md)** ⭐ **NEW** - Complete beginner-friendly tutorial
 - 📖 **[DevOps Backlog Integration](../guides/devops-adapter-integration.md)** 🆕 **NEW FEATURE** - Integrate SpecFact into agile DevOps workflows
 - 📖 **[Backlog Refinement](../guides/backlog-refinement.md)** 🆕 **NEW FEATURE** - AI-assisted template-driven refinement for standardizing work items
diff --git a/docs/getting-started/first-steps.md b/docs/getting-started/first-steps.md
index bd4a6a16..ca06af00 100644
--- a/docs/getting-started/first-steps.md
+++ b/docs/getting-started/first-steps.md
@@ -108,7 +108,7 @@ Review the auto-generated plan to understand what SpecFact discovered about your
 **💡 Tip**: If you plan to sync with Spec-Kit later, the import command will suggest generating a bootstrap constitution. You can also run it manually:
 
 ```bash
-specfact sdd constitution bootstrap --repo .
+specfact spec sdd constitution bootstrap --repo .
 ```
 
 ### Step 3: Find and Fix Gaps
@@ -132,10 +132,10 @@ specfact code repro --verbose
 
 ```bash
 # Generate AI-ready prompt to fix a specific gap
-specfact generate fix-prompt GAP-001 --bundle my-project
+specfact spec generate fix-prompt GAP-001 --bundle my-project
 
 # Generate AI-ready prompt to add tests
-specfact generate test-prompt src/auth/login.py
+specfact spec generate test-prompt src/auth/login.py
 ```
 
 **What happens**:
@@ -149,10 +149,10 @@ specfact generate test-prompt src/auth/login.py
 
 ```bash
 # Start in shadow mode (observe only)
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 
 # Validate the codebase
-specfact enforce sdd --bundle my-project
+specfact govern enforce sdd --bundle my-project
 ```
 
 See [Brownfield Engineer Guide](../guides/brownfield-engineer.md) for complete workflow.
@@ -168,7 +168,7 @@ See [Brownfield Engineer Guide](../guides/brownfield-engineer.md) for complete w
 ### Step 1: Initialize a Plan
 
 ```bash
-specfact plan init my-project --interactive
+specfact project plan init my-project --interactive
 ```
 
 **What happens**:
@@ -193,7 +193,7 @@ Enter project description: A project to demonstrate SpecFact CLI
 ### Step 2: Add Your First Feature
 
 ```bash
-specfact plan add-feature \
+specfact project plan add-feature \
   --bundle my-project \
   --key FEATURE-001 \
   --title "User Authentication" \
@@ -209,7 +209,7 @@ specfact plan add-feature \
 ### Step 3: Add Stories to the Feature
 
 ```bash
-specfact plan add-story \
+specfact project plan add-story \
   --bundle my-project \
   --feature FEATURE-001 \
   --title "As a user, I can login with email and password" \
@@ -226,7 +226,7 @@ specfact plan add-story \
 ### Step 4: Validate the Plan
 
 ```bash
-specfact repro
+specfact code repro
 ```
 
 **What happens**:
@@ -260,7 +260,7 @@ specfact repro
 ### Step 1: Preview Migration
 
 ```bash
-specfact import from-bridge \
+specfact project import from-bridge \
   --repo ./my-speckit-project \
   --adapter speckit \
   --dry-run
@@ -295,7 +295,7 @@ specfact import from-bridge \
 ### Step 2: Execute Migration
 
 ```bash
-specfact import from-bridge \
+specfact project import from-bridge \
   --repo ./my-speckit-project \
   --adapter speckit \
   --write
@@ -313,10 +313,10 @@ specfact import from-bridge \
 
 ```bash
 # Review the imported bundle
-specfact plan review <bundle-name>
+specfact project plan review <bundle-name>
 
 # Check bundle status
-specfact plan select
+specfact project plan select
 ```
 
 **What was created**:
@@ -333,13 +333,13 @@ Keep Spec-Kit and SpecFact synchronized:
 
 ```bash
 # Generate constitution if missing (auto-suggested during sync)
-specfact sdd constitution bootstrap --repo .
+specfact spec sdd constitution bootstrap --repo .
 
 # One-time bidirectional sync
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
 
 # Continuous watch mode
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
 ```
 
 **What happens**:
@@ -354,13 +354,13 @@ specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirec
 
 ```bash
 # Start in shadow mode (observe only)
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 
 # After stabilization, enable warnings
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # For production, enable strict mode
-specfact enforce stage --preset strict
+specfact govern enforce stage --preset strict
 ```
 
 **What happens**:
diff --git a/docs/getting-started/installation.md b/docs/getting-started/installation.md
index 97d8b6d7..c4c9cfcd 100644
--- a/docs/getting-started/installation.md
+++ b/docs/getting-started/installation.md
@@ -142,10 +142,10 @@ jobs:
         run: pip install specfact-cli
 
       - name: Set up CrossHair Configuration
-        run: specfact repro setup
+        run: specfact code repro setup
 
       - name: Run Contract Validation
-        run: specfact repro --verbose --budget 90
+        run: specfact code repro --verbose --budget 90
 
       - name: Generate PR Comment
         if: github.event_name == 'pull_request'
@@ -234,7 +234,7 @@ specfact init --install all
 Start a new contract-driven project:
 
 ```bash
-specfact plan init --interactive
+specfact project plan init --interactive
 ```
 
 This will guide you through creating:
@@ -278,16 +278,16 @@ Convert an existing GitHub Spec-Kit project:
 
 ```bash
 # Preview what will be migrated
-specfact import from-bridge --adapter speckit --repo ./my-speckit-project --dry-run
+specfact project import from-bridge --adapter speckit --repo ./my-speckit-project --dry-run
 
 # Execute migration (one-time import)
-specfact import from-bridge \
+specfact project import from-bridge \
   --adapter speckit \
   --repo ./my-speckit-project \
   --write
 
 # Ongoing bidirectional sync (after migration)
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
 ```
 
 **Bidirectional Sync:**
@@ -296,13 +296,13 @@ Keep Spec-Kit and SpecFact artifacts synchronized:
 
 ```bash
 # One-time sync
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
 
 # Continuous watch mode
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
 ```
 
-**Note**: SpecFact CLI uses a plugin-based adapter registry pattern. All adapters (Spec-Kit, OpenSpec, GitHub, etc.) are registered in `AdapterRegistry` and accessed via `specfact sync bridge --adapter <adapter-name>`, making the architecture extensible for future tool integrations.
+**Note**: SpecFact CLI uses a plugin-based adapter registry pattern. All adapters (Spec-Kit, OpenSpec, GitHub, etc.) are registered in `AdapterRegistry` and accessed via `specfact project sync bridge --adapter <adapter-name>`, making the architecture extensible for future tool integrations.
 
 ### For Brownfield Projects
 
@@ -339,7 +339,7 @@ specfact init
 
 ```bash
 # Analyze repository (CI/CD mode - fast)
-specfact import from-code my-project \
+specfact project import from-code my-project \
   --repo ./my-project \
   --shadow-only \
   --report analysis.md
@@ -364,10 +364,10 @@ Keep plan artifacts updated as code changes:
 
 ```bash
 # One-time sync
-specfact sync repository --repo . --target .specfact
+specfact project sync repository --repo . --target .specfact
 
 # Continuous watch mode
-specfact sync repository --repo . --watch
+specfact project sync repository --repo . --watch
 ```
 
 ## Next Steps
@@ -390,7 +390,7 @@ specfact sync repository --repo . --watch
 - **Global flags**: Place `--no-banner` before the command: `specfact --no-banner <command>`
 - **Bridge adapter sync**: Use `sync bridge --adapter <adapter-name>` for external tool integration (Spec-Kit, OpenSpec, GitHub, etc.)
 - **Repository sync**: Use `sync repository` for code change tracking
-- **Semgrep (optional)**: Install `pip install semgrep` for async pattern detection in `specfact repro`
+- **Semgrep (optional)**: Install `pip install semgrep` for async pattern detection in `specfact code repro`
 
 ---
 
@@ -458,19 +458,19 @@ SpecFact CLI automatically detects source directories:
 ```bash
 # Hatch project
 cd /path/to/hatch-project
-specfact repro --repo .  # Automatically uses "hatch run" for tools
+specfact code repro --repo .  # Automatically uses "hatch run" for tools
 
 # Poetry project
 cd /path/to/poetry-project
-specfact repro --repo .  # Automatically uses "poetry run" for tools
+specfact code repro --repo .  # Automatically uses "poetry run" for tools
 
 # UV project
 cd /path/to/uv-project
-specfact repro --repo .  # Automatically uses "uv run" for tools
+specfact code repro --repo .  # Automatically uses "uv run" for tools
 
 # Pip project
 cd /path/to/pip-project
-specfact repro --repo .  # Uses direct tool invocation
+specfact code repro --repo .  # Uses direct tool invocation
 ```
 
 ### External Repository Support
@@ -501,16 +501,16 @@ specfact --help
 specfact <command> --help
 
 # Initialize plan (bundle name as positional argument)
-specfact plan init my-project --interactive
+specfact project plan init my-project --interactive
 
 # Add feature
-specfact plan add-feature --key FEATURE-001 --title "My Feature"
+specfact project plan add-feature --key FEATURE-001 --title "My Feature"
 
 # Validate everything
-specfact repro
+specfact code repro
 
 # Set enforcement level
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 ```
 
 ## Getting Help
diff --git a/docs/getting-started/module-bootstrap-checklist.md b/docs/getting-started/module-bootstrap-checklist.md
index f3735a5c..3727fc77 100644
--- a/docs/getting-started/module-bootstrap-checklist.md
+++ b/docs/getting-started/module-bootstrap-checklist.md
@@ -2,15 +2,19 @@
 layout: default
 title: Module Bootstrap Checklist
 permalink: /getting-started/module-bootstrap-checklist/
-description: Quick checklist to verify bundled modules are installed and discoverable in user/project scope.
+description: Quick checklist to verify official workflow bundles are installed and discoverable in user/project scope.
 ---
 
 # Module Bootstrap Checklist
 
-Use this checklist right after installing or upgrading SpecFact CLI to ensure bundled modules are installed and discoverable.
+Use this checklist right after installing or upgrading SpecFact CLI to ensure official workflow bundles are installed and discoverable.
 Use plain `specfact ...` commands below (not `hatch run specfact ...`) so the steps work for pipx, pip, uv tool installs, and packaged environments.
 
-## 1. Initialize Bundled Modules
+Core ships the bootstrap/runtime needed to install bundles. The official bundle source of truth is
+the marketplace registry in `nold-ai/specfact-cli-modules`, even when `specfact module init`
+seeds bundled copies for the current CLI release line.
+
+## 1. Initialize Bundled Bundle Copies
 
 ### User scope (default)
 
@@ -18,7 +22,7 @@ Use plain `specfact ...` commands below (not `hatch run specfact ...`) so the st
 specfact module init
 ```
 
-This seeds bundled modules into `~/.specfact/modules`.
+This seeds bundled copies of the official bundles into `~/.specfact/modules`.
 
 ### Project scope (optional)
 
@@ -26,7 +30,7 @@ This seeds bundled modules into `~/.specfact/modules`.
 specfact module init --scope project --repo .
 ```
 
-This seeds bundled modules into `<repo>/.specfact/modules`.
+This seeds bundled copies of the official bundles into `<repo>/.specfact/modules`.
 
 Use project scope when modules should apply only to a specific codebase/customer repository.
 
@@ -36,7 +40,7 @@ Use project scope when modules should apply only to a specific codebase/customer
 specfact module list
 ```
 
-If bundled modules are still available but not installed, you'll see a hint to run:
+If bundled bundle copies are still available but not installed, you'll see a hint to run:
 
 ```bash
 specfact module list --show-bundled-available
@@ -55,13 +59,13 @@ This prints a separate bundled table plus install guidance.
 Install from bundled sources only:
 
 ```bash
-specfact module install backlog-core --source bundled
+specfact module install backlog --source bundled
 ```
 
 Install from marketplace only:
 
 ```bash
-specfact module install specfact/backlog --source marketplace
+specfact module install nold-ai/specfact-backlog --source marketplace
 ```
 
 Install with automatic source resolution (`bundled` first, then marketplace):
@@ -73,9 +77,9 @@ specfact module install backlog
 ## 5. Scope-Safe Uninstall
 
 ```bash
-specfact module uninstall backlog-core --scope user
+specfact module uninstall backlog --scope user
 # or
-specfact module uninstall backlog-core --scope project --repo .
+specfact module uninstall backlog --scope project --repo .
 ```
 
 If the same module exists in both user and project scope, SpecFact requires explicit `--scope` to prevent accidental removal.
diff --git a/docs/getting-started/tutorial-backlog-quickstart-demo.md b/docs/getting-started/tutorial-backlog-quickstart-demo.md
index 8d200cf8..e38ca2ce 100644
--- a/docs/getting-started/tutorial-backlog-quickstart-demo.md
+++ b/docs/getting-started/tutorial-backlog-quickstart-demo.md
@@ -7,6 +7,10 @@ permalink: /getting-started/tutorial-backlog-quickstart-demo/
 
 # Tutorial: Backlog Quickstart Demo (GitHub + ADO)
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 This is a short, copy/paste-friendly demo for new users covering:
 
 1. `specfact backlog init-config`
diff --git a/docs/getting-started/tutorial-backlog-refine-ai-ide.md b/docs/getting-started/tutorial-backlog-refine-ai-ide.md
index 7335eab6..9b379ce2 100644
--- a/docs/getting-started/tutorial-backlog-refine-ai-ide.md
+++ b/docs/getting-started/tutorial-backlog-refine-ai-ide.md
@@ -7,6 +7,10 @@ permalink: /getting-started/tutorial-backlog-refine-ai-ide/
 
 # Tutorial: Backlog Refine with Your AI IDE (Agile DevOps Teams)
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 This tutorial walks agile DevOps teams through integrating SpecFact CLI backlog refinement with their AI IDE (Cursor, VS Code + Copilot, Claude Code, etc.) using the interactive slash prompt. You will improve backlog story quality, make informed decisions about underspecification, split stories when too big, fix ambiguities, respect Definition of Ready (DoR), and optionally use custom template mapping for advanced teams.
 
 Preferred command path is `specfact backlog ceremony refinement ...`. The legacy `specfact backlog refine ...` path remains supported for compatibility.
diff --git a/docs/getting-started/tutorial-daily-standup-sprint-review.md b/docs/getting-started/tutorial-daily-standup-sprint-review.md
index 1ec97464..c2d7b002 100644
--- a/docs/getting-started/tutorial-daily-standup-sprint-review.md
+++ b/docs/getting-started/tutorial-daily-standup-sprint-review.md
@@ -7,6 +7,10 @@ permalink: /getting-started/tutorial-daily-standup-sprint-review/
 
 # Tutorial: Daily Standup and Sprint Review with SpecFact CLI
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 This tutorial walks you through a complete **daily standup and sprint review** workflow using SpecFact CLI: view your backlog items, optionally post standup comments to issues, use interactive step-through and Copilot export—with **no need to pass org/repo or org/project** when you run from your cloned repo.
 
 Preferred command path is `specfact backlog ceremony standup ...`. The legacy `specfact backlog daily ...` path remains supported for compatibility.
diff --git a/docs/getting-started/tutorial-openspec-speckit.md b/docs/getting-started/tutorial-openspec-speckit.md
index 8d63468b..b7075e6e 100644
--- a/docs/getting-started/tutorial-openspec-speckit.md
+++ b/docs/getting-started/tutorial-openspec-speckit.md
@@ -122,7 +122,7 @@ openspec init
 ```bash
 # Analyze legacy codebase
 cd /path/to/your-openspec-project
-specfact import from-code legacy-api --repo .
+specfact project import from-code legacy-api --repo .
 
 # Expected output:
 # 🔍 Analyzing codebase...
@@ -143,7 +143,7 @@ specfact import from-code legacy-api --repo .
 **Note**: If using `hatch run specfact`, run from the specfact-cli directory:
 ```bash
 cd /path/to/specfact-cli
-hatch run specfact import from-code legacy-api --repo /path/to/your-openspec-project
+hatch run specfact project import from-code legacy-api --repo /path/to/your-openspec-project
 ```
 
 ### Step 4: Create an OpenSpec Change Proposal
@@ -188,7 +188,7 @@ EOF
 
 ```bash
 # Export OpenSpec change proposal to GitHub Issues
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --repo /path/to/openspec-repo
@@ -217,7 +217,7 @@ git commit -m "feat: modernize-api - refactor endpoints [change:modernize-api]"
 
 # Track progress (detects commits and adds comments to GitHub Issue)
 cd /path/to/openspec-repo
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --track-code-changes \
@@ -238,7 +238,7 @@ specfact sync bridge --adapter github --mode export-only \
 ```bash
 # Sync OpenSpec change proposals to SpecFact (read-only)
 cd /path/to/openspec-repo
-specfact sync bridge --adapter openspec --mode read-only \
+specfact project sync bridge --adapter openspec --mode read-only \
   --bundle legacy-api \
   --repo .
 
@@ -264,7 +264,7 @@ specfact sync bridge --adapter openspec --mode read-only \
 ```bash
 # Configure enforcement (global setting, no --bundle or --repo needed)
 cd /path/to/your-project
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # Expected output:
 # Setting enforcement mode: balanced
@@ -351,7 +351,7 @@ ls specs/
 
 ```bash
 # Preview import
-specfact import from-bridge --adapter speckit --repo ./my-speckit-project --dry-run
+specfact project import from-bridge --adapter speckit --repo ./my-speckit-project --dry-run
 
 # Expected output:
 # 🔍 Analyzing Spec-Kit project via bridge adapter...
@@ -377,7 +377,7 @@ specfact import from-bridge --adapter speckit --repo ./my-speckit-project --dry-
 
 ```bash
 # Execute import
-specfact import from-bridge \
+specfact project import from-bridge \
   --adapter speckit \
   --repo ./my-speckit-project \
   --write
@@ -404,7 +404,7 @@ specfact import from-bridge \
 # Review plan bundle (bundle name is positional argument, not --bundle)
 # IMPORTANT: Must be in the project directory where .specfact/ exists
 cd /path/to/your-speckit-project
-specfact plan review <bundle-name>
+specfact project plan review <bundle-name>
 
 # Note: Bundle name is typically "main" for Spec-Kit imports
 # Check actual bundle name: ls .specfact/projects/
@@ -427,10 +427,10 @@ specfact plan review <bundle-name>
 ```bash
 # One-time sync (bundle name is typically "main" for Spec-Kit imports)
 cd /path/to/my-speckit-project
-specfact sync bridge --adapter speckit --bundle main --repo . --bidirectional
+specfact project sync bridge --adapter speckit --bundle main --repo . --bidirectional
 
 # Continuous watch mode (recommended for team collaboration)
-specfact sync bridge --adapter speckit --bundle main --repo . --bidirectional --watch --interval 5
+specfact project sync bridge --adapter speckit --bundle main --repo . --bidirectional --watch --interval 5
 
 # Expected output:
 # ✅ Detected speckit repository
@@ -473,7 +473,7 @@ specfact sync bridge --adapter speckit --bundle main --repo . --bidirectional --
 ```bash
 # Configure enforcement (global setting, no --bundle or --repo needed)
 cd /path/to/my-speckit-project
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # Expected output:
 # Setting enforcement mode: balanced
@@ -497,7 +497,7 @@ specfact enforce stage --preset balanced
 # Compare code vs plan (use --bundle to specify bundle name)
 # IMPORTANT: Must be in the project directory where .specfact/ exists
 cd /path/to/my-speckit-project
-specfact plan compare --code-vs-plan --bundle <bundle-name>
+specfact project plan compare --code-vs-plan --bundle <bundle-name>
 
 # Note: Bundle name is typically "main" for Spec-Kit imports
 # Check actual bundle name: ls .specfact/projects/
@@ -539,10 +539,10 @@ Bridge adapters are plugin-based connectors that sync between SpecFact and exter
 
 ```bash
 # View available adapters (shown in help text)
-specfact sync bridge --help
+specfact project sync bridge --help
 
 # Use an adapter
-specfact sync bridge --adapter <adapter-name> --mode <mode> --bundle <bundle-name> --repo .
+specfact project sync bridge --adapter <adapter-name> --mode <mode> --bundle <bundle-name> --repo .
 ```
 
 **Note**: Adapters are listed in the help text. There's no `--list-adapters` option, but adapters are shown when you use `--help` or when an adapter is not found (error message shows available adapters).
@@ -572,7 +572,7 @@ specfact sync bridge --adapter <adapter-name> --mode <mode> --bundle <bundle-nam
 
 ```bash
 # View available adapters in help text
-specfact sync bridge --help
+specfact project sync bridge --help
 
 # Or check error message when adapter is not found (shows available adapters)
 # Should show: openspec, speckit, github, generic-markdown
diff --git a/docs/guides/agile-scrum-workflows.md b/docs/guides/agile-scrum-workflows.md
index 9532d0f3..7577acc7 100644
--- a/docs/guides/agile-scrum-workflows.md
+++ b/docs/guides/agile-scrum-workflows.md
@@ -6,6 +6,10 @@ permalink: /guides/agile-scrum-workflows/
 
 # Agile/Scrum Workflows with SpecFact CLI
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 This guide explains how to use SpecFact CLI for agile/scrum workflows, including backlog management, sprint planning, dependency tracking, and Definition of Ready (DoR) validation.
 
 Preferred command paths are `specfact backlog ceremony standup ...` and `specfact backlog ceremony refinement ...`. Legacy `backlog daily`/`backlog refine` remain available for compatibility.
@@ -115,10 +119,10 @@ Use the `policy` command group to run deterministic readiness checks before spri
 
 ```bash
 # Validate configured policy rules against a snapshot
-specfact policy validate --repo . --format both
+specfact backlog policy validate --repo . --format both
 
 # Generate confidence-scored, patch-ready suggestions (no automatic writes)
-specfact policy suggest --repo .
+specfact backlog policy suggest --repo .
 ```
 
 Policy configuration is loaded from `.specfact/policy.yaml` and supports Scrum (`dor_required_fields`,
diff --git a/docs/guides/ai-ide-workflow.md b/docs/guides/ai-ide-workflow.md
index 8ff73c71..3c1d2cfc 100644
--- a/docs/guides/ai-ide-workflow.md
+++ b/docs/guides/ai-ide-workflow.md
@@ -62,20 +62,20 @@ Once initialized, the following slash commands are available in your IDE:
 
 | Slash Command | Purpose | Equivalent CLI Command |
 |---------------|---------|------------------------|
-| `/specfact.01-import` | Import from codebase | `specfact import from-code` |
-| `/specfact.02-plan` | Plan management | `specfact plan init/add-feature/add-story` |
-| `/specfact.03-review` | Review plan | `specfact plan review` |
-| `/specfact.04-sdd` | Create SDD manifest | `specfact enforce sdd` |
-| `/specfact.05-enforce` | SDD enforcement | `specfact enforce sdd` |
-| `/specfact.06-sync` | Sync operations | `specfact sync bridge` |
-| `/specfact.07-contracts` | Contract management | `specfact generate contracts-prompt` |
+| `/specfact.01-import` | Import from codebase | `specfact project import from-code` |
+| `/specfact.02-plan` | Plan management | `specfact project plan init/add-feature/add-story` |
+| `/specfact.03-review` | Review plan | `specfact project plan review` |
+| `/specfact.04-sdd` | Create SDD manifest | `specfact govern enforce sdd` |
+| `/specfact.05-enforce` | SDD enforcement | `specfact govern enforce sdd` |
+| `/specfact.06-sync` | Sync operations | `specfact project sync bridge` |
+| `/specfact.07-contracts` | Contract management | `specfact spec generate contracts-prompt` |
 
 ### Advanced Commands
 
 | Slash Command | Purpose | Equivalent CLI Command |
 |---------------|---------|------------------------|
-| `/specfact.compare` | Compare plans | `specfact plan compare` |
-| `/specfact.validate` | Validation suite | `specfact repro` |
+| `/specfact.compare` | Compare plans | `specfact project plan compare` |
+| `/specfact.validate` | Validation suite | `specfact code repro` |
 | `/specfact.backlog-refine` | Backlog refinement (AI IDE interactive loop) | `specfact backlog refine github \| ado` |
 
 For an end-to-end tutorial on backlog refine with your AI IDE (story quality, underspecification, DoR, custom templates), see **[Tutorial: Backlog Refine with AI IDE](../getting-started/tutorial-backlog-refine-ai-ide.md)**.
@@ -104,23 +104,23 @@ graph TD
 
 ```bash
 # Import from codebase
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 
 # Run validation to find gaps
-specfact repro --verbose
+specfact code repro --verbose
 ```
 
 #### 2. Generate AI-Ready Prompt
 
 ```bash
 # Generate fix prompt for a specific gap
-specfact generate fix-prompt GAP-001 --bundle my-project
+specfact spec generate fix-prompt GAP-001 --bundle my-project
 
 # Or generate contract prompt
-specfact generate contracts-prompt --bundle my-project --feature FEATURE-001
+specfact spec generate contracts-prompt --bundle my-project --feature FEATURE-001
 
 # Or generate test prompt
-specfact generate test-prompt src/auth/login.py --bundle my-project
+specfact spec generate test-prompt src/auth/login.py --bundle my-project
 ```
 
 #### 3. Use AI IDE to Apply Fixes
@@ -148,13 +148,13 @@ cat .specfact/prompts/fix-prompt-GAP-001.md
 
 ```bash
 # Check contract coverage
-specfact contract coverage --bundle my-project
+specfact spec contract coverage --bundle my-project
 
 # Run validation
-specfact repro --verbose
+specfact code repro --verbose
 
 # Enforce SDD compliance
-specfact enforce sdd --bundle my-project
+specfact govern enforce sdd --bundle my-project
 ```
 
 #### 5. Iterate if Needed
@@ -193,13 +193,13 @@ The AI IDE workflow integrates with several command chains:
 
 ```bash
 # 1. Analyze codebase
-specfact import from-code legacy-api --repo .
+specfact project import from-code legacy-api --repo .
 
 # 2. Find gaps
-specfact repro --verbose
+specfact code repro --verbose
 
 # 3. Generate contract prompt
-specfact generate contracts-prompt --bundle legacy-api --feature FEATURE-001
+specfact spec generate contracts-prompt --bundle legacy-api --feature FEATURE-001
 
 # 4. [In AI IDE] Use slash command or paste prompt
 # /specfact.generate-contracts-prompt legacy-api FEATURE-001
@@ -207,9 +207,9 @@ specfact generate contracts-prompt --bundle legacy-api --feature FEATURE-001
 # Apply contracts to code
 
 # 5. Validate
-specfact contract coverage --bundle legacy-api
-specfact repro --verbose
-specfact enforce sdd --bundle legacy-api
+specfact spec contract coverage --bundle legacy-api
+specfact code repro --verbose
+specfact govern enforce sdd --bundle legacy-api
 ```
 
 ---
diff --git a/docs/guides/backlog-delta-commands.md b/docs/guides/backlog-delta-commands.md
index 8850509e..9f88069a 100644
--- a/docs/guides/backlog-delta-commands.md
+++ b/docs/guides/backlog-delta-commands.md
@@ -6,6 +6,10 @@ permalink: /guides/backlog-delta-commands/
 
 # Backlog Delta Commands
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 `delta` commands are grouped under backlog because they describe backlog graph drift and impact, not source-code diffs.
 
 ## Command Group
diff --git a/docs/guides/backlog-dependency-analysis.md b/docs/guides/backlog-dependency-analysis.md
index 9c1d7623..ea68febc 100644
--- a/docs/guides/backlog-dependency-analysis.md
+++ b/docs/guides/backlog-dependency-analysis.md
@@ -6,6 +6,10 @@ permalink: /guides/backlog-dependency-analysis/
 
 # Backlog Dependency Analysis
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 Use SpecFact to build a provider-agnostic dependency graph from backlog tools and analyze execution risk before delivery.
 
 ## Commands
diff --git a/docs/guides/backlog-refinement.md b/docs/guides/backlog-refinement.md
index c96f45ce..5824cb93 100644
--- a/docs/guides/backlog-refinement.md
+++ b/docs/guides/backlog-refinement.md
@@ -6,6 +6,10 @@ permalink: /guides/backlog-refinement/
 
 # Backlog Refinement Guide
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 > **🆕 NEW FEATURE: AI-Assisted Template-Driven Backlog Refinement**  
 > Transform arbitrary DevOps backlog input into structured, template-compliant work items using AI-assisted refinement with template detection and validation.
 
@@ -553,7 +557,7 @@ The most common workflow is to refine backlog items and then sync them to extern
 **Workflow**: `backlog ceremony refinement` → `sync bridge`
 
 1. **Refine Backlog Items**: Use `specfact backlog ceremony refinement` to standardize backlog items with templates
-2. **Sync to External Tools**: Use `specfact sync bridge` to sync refined items back to backlog tools (GitHub, ADO, etc.)
+2. **Sync to External Tools**: Use `specfact project sync bridge` to sync refined items back to backlog tools (GitHub, ADO, etc.)
 
 ```bash
 # Complete command chaining workflow
@@ -565,7 +569,7 @@ specfact backlog ceremony refinement github \
   --state open
 
 # 2. Sync refined items to external tool (same or different adapter)
-specfact sync bridge --adapter github \
+specfact project sync bridge --adapter github \
   --repo-owner my-org --repo-name my-repo \
   --backlog-ids 123,456 \
   --mode export-only
@@ -576,7 +580,7 @@ specfact backlog ceremony refinement github \
   --write \
   --labels feature
 
-specfact sync bridge --adapter ado \
+specfact project sync bridge --adapter ado \
   --ado-org my-org --ado-project my-project \
   --backlog-ids 123,456 \
   --mode export-only
@@ -612,12 +616,12 @@ When syncing backlog items between different adapters (e.g., GitHub ↔ ADO), Sp
 
 ```bash
 # 1. Import closed GitHub issues into bundle (state "closed" is preserved)
-specfact sync bridge --adapter github --mode bidirectional \
+specfact project sync bridge --adapter github --mode bidirectional \
   --repo-owner nold-ai --repo-name specfact-cli \
   --backlog-ids 110,122
 
 # 2. Export to ADO (state is automatically mapped: closed → Closed)
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org dominikusnold --ado-project "SpecFact CLI" \
   --bundle cross-sync-test --change-ids add-ado-backlog-adapter,add-template-driven-backlog-refinement
 
@@ -644,14 +648,14 @@ specfact sync bridge --adapter ado --mode export-only \
 
 Backlog refinement works seamlessly with the [DevOps Adapter Integration](../guides/devops-adapter-integration.md):
 
-1. **Import Backlog Items**: Use `specfact sync bridge` to import backlog items as OpenSpec proposals
+1. **Import Backlog Items**: Use `specfact project sync bridge` to import backlog items as OpenSpec proposals
 2. **Refine Items**: Use `specfact backlog ceremony refinement` to standardize imported items
-3. **Export Refined Items**: Use `specfact sync bridge` to export refined proposals back to backlog tools
+3. **Export Refined Items**: Use `specfact project sync bridge` to export refined proposals back to backlog tools
 
 ```bash
 # Complete workflow
 # 1. Import GitHub issues as OpenSpec proposals
-specfact sync bridge --adapter github --mode bidirectional \
+specfact project sync bridge --adapter github --mode bidirectional \
   --repo-owner my-org --repo-name my-repo \
   --backlog-ids 123,456
 
@@ -660,7 +664,7 @@ specfact backlog ceremony refinement github --bundle my-project --auto-bundle \
   --search "is:open"
 
 # 3. Export refined proposals back to GitHub
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --bundle my-project --change-ids <refined-change-id>
 ```
 
@@ -936,11 +940,11 @@ If adapter search methods are not available:
 # "Note: GitHub issue fetching requires adapter.search_issues() implementation"
 ```
 
-**Workaround**: Use `specfact sync bridge` to import backlog items first, then refine:
+**Workaround**: Use `specfact project sync bridge` to import backlog items first, then refine:
 
 ```bash
 # 1. Import backlog items
-specfact sync bridge --adapter github --mode bidirectional \
+specfact project sync bridge --adapter github --mode bidirectional \
   --backlog-ids 123,456
 
 # 2. Refine imported items from bundle
diff --git a/docs/guides/brownfield-engineer.md b/docs/guides/brownfield-engineer.md
index 105bc002..146daf06 100644
--- a/docs/guides/brownfield-engineer.md
+++ b/docs/guides/brownfield-engineer.md
@@ -43,11 +43,11 @@ SpecFact CLI is designed specifically for your situation. It provides:
 
 ```bash
 # Analyze your legacy codebase
-specfact import from-code legacy-api --repo ./legacy-app
+specfact project import from-code legacy-api --repo ./legacy-app
 
 # For large codebases or multi-project repos, analyze specific modules:
-specfact import from-code core-module --repo ./legacy-app --entry-point src/core
-specfact import from-code api-module --repo ./legacy-app --entry-point src/api
+specfact project import from-code core-module --repo ./legacy-app --entry-point src/core
+specfact project import from-code api-module --repo ./legacy-app --entry-point src/api
 ```
 
 **What you get:**
@@ -81,10 +81,10 @@ For large codebases or monorepos with multiple projects, you can analyze specifi
 
 ```bash
 # Analyze only the core module
-specfact import from-code core-module --repo . --entry-point src/core
+specfact project import from-code core-module --repo . --entry-point src/core
 
 # Analyze only the API service
-specfact import from-code api-service --repo . --entry-point projects/api-service
+specfact project import from-code api-service --repo . --entry-point projects/api-service
 ```
 
 This enables:
@@ -99,7 +99,7 @@ This enables:
 ```bash
 # If suggested, accept to auto-generate
 # Or run manually:
-specfact sdd constitution bootstrap --repo .
+specfact spec sdd constitution bootstrap --repo .
 ```
 
 This is especially useful if you plan to sync with Spec-Kit later.
@@ -227,7 +227,7 @@ You inherited a 3-year-old Django app with:
 
 ```bash
 # Step 1: Extract specs
-specfact import from-code customer-portal --repo ./legacy-django-app
+specfact project import from-code customer-portal --repo ./legacy-django-app
 
 # Output:
 ✅ Analyzed 47 Python files
@@ -289,7 +289,7 @@ SpecFact CLI integrates seamlessly with your existing tools:
 Begin in shadow mode to observe without blocking:
 
 ```bash
-specfact import from-code legacy-api --repo . --shadow-only
+specfact project import from-code legacy-api --repo . --shadow-only
 ```
 
 ### 2. Add Contracts Incrementally
diff --git a/docs/guides/brownfield-faq.md b/docs/guides/brownfield-faq.md
index 40e2d534..77870b5f 100644
--- a/docs/guides/brownfield-faq.md
+++ b/docs/guides/brownfield-faq.md
@@ -164,7 +164,7 @@ For large codebases, run CrossHair on critical functions first, then expand.
 
 **Recommended workflow:**
 
-1. **Extract specs** (`specfact import from-code`)
+1. **Extract specs** (`specfact project import from-code`)
 2. **Add contracts** to 3-5 critical functions
 3. **Run CrossHair** to discover edge cases
 4. **Refactor incrementally** (one function at a time)
@@ -254,7 +254,7 @@ See [Spec-Kit Comparison Guide](speckit-comparison.md) for details.
 - **GitHub Actions:** PR annotations, contract validation
 - **GitLab CI:** Pipeline integration
 - **Jenkins:** Plugin support (planned)
-- **Local CI:** Run `specfact enforce` in your pipeline
+- **Local CI:** Run `specfact govern enforce` in your pipeline
 
 Contracts can block merges if violations are detected (configurable).
 
diff --git a/docs/guides/brownfield-journey.md b/docs/guides/brownfield-journey.md
index b68d8b9a..46534d4f 100644
--- a/docs/guides/brownfield-journey.md
+++ b/docs/guides/brownfield-journey.md
@@ -35,7 +35,7 @@ This guide walks you through the complete brownfield modernization journey:
 
 ```bash
 # Analyze your legacy codebase
-specfact import from-code legacy-api --repo ./legacy-app
+specfact project import from-code legacy-api --repo ./legacy-app
 ```
 
 **What happens:**
@@ -61,7 +61,7 @@ specfact import from-code legacy-api --repo ./legacy-app
 ```bash
 # If suggested, accept to auto-generate
 # Or run manually:
-specfact sdd constitution bootstrap --repo .
+specfact spec sdd constitution bootstrap --repo .
 ```
 
 This is especially useful if you plan to sync with Spec-Kit later.
@@ -70,7 +70,7 @@ This is especially useful if you plan to sync with Spec-Kit later.
 
 ```bash
 # Review the extracted plan using CLI commands
-specfact plan review legacy-api
+specfact project plan review legacy-api
 ```
 
 **What to look for:**
@@ -84,7 +84,7 @@ specfact plan review legacy-api
 
 ```bash
 # Compare extracted plan to your understanding (bundle directory paths)
-specfact plan compare \
+specfact project plan compare \
   --manual .specfact/projects/manual-plan \
   --auto .specfact/projects/your-project
 ```
@@ -112,7 +112,7 @@ specfact plan compare \
 
 ```bash
 # Review plan using CLI commands
-specfact plan review legacy-api
+specfact project plan review legacy-api
 ```
 
 ### Step 2.2: Add Contracts Incrementally
@@ -143,7 +143,7 @@ def process_payment(user_id, amount, currency):
 
 ```bash
 # Run in shadow mode (observe only)
-specfact enforce --mode shadow
+specfact govern enforce --mode shadow
 ```
 
 **Benefits:**
@@ -265,7 +265,7 @@ process_payment(user_id=-1, amount=-50, currency="XYZ")
 hatch run contract-test-full
 
 # Check for violations
-specfact enforce --mode block
+specfact govern enforce --mode block
 ```
 
 **Success criteria:**
@@ -328,7 +328,7 @@ Legacy Django app:
 
 #### Week 1: Understand
 
-- Ran `specfact import from-code legacy-api --repo .` → 23 features extracted in 8 seconds
+- Ran `specfact project import from-code legacy-api --repo .` → 23 features extracted in 8 seconds
 - Reviewed extracted plan → Identified 5 critical features
 - Time: 2 hours (vs. 60 hours manual)
 
diff --git a/docs/guides/brownfield-roi.md b/docs/guides/brownfield-roi.md
index a40944c9..9ad8b8f2 100644
--- a/docs/guides/brownfield-roi.md
+++ b/docs/guides/brownfield-roi.md
@@ -150,7 +150,7 @@ SpecFact's code2spec provides similar automation:
 
 **Solution:**
 
-1. Ran `specfact import from-code` → 47 features extracted in 12 seconds
+1. Ran `specfact project import from-code` → 47 features extracted in 12 seconds
 2. Added contracts to 23 critical data transformation functions
 3. CrossHair discovered 6 edge cases in legacy validation logic
 4. Enforced contracts during migration, blocked 11 regressions
@@ -199,7 +199,7 @@ Calculate your ROI:
 1. **Run code2spec** on your legacy codebase:
 
    ```bash
-   specfact import from-code legacy-api --repo ./your-legacy-app
+   specfact project import from-code legacy-api --repo ./your-legacy-app
    ```
 
 2. **Time the extraction** (typically < 10 seconds)
diff --git a/docs/guides/command-chains.md b/docs/guides/command-chains.md
index 3a065144..815b17b7 100644
--- a/docs/guides/command-chains.md
+++ b/docs/guides/command-chains.md
@@ -83,19 +83,19 @@ Start: What do you want to accomplish?
 
 ```bash
 # Step 1: Extract specifications from legacy code
-specfact import from-code legacy-api --repo .
+specfact project import from-code legacy-api --repo .
 
 # Step 2: Review the extracted plan
-specfact plan review legacy-api
+specfact project plan review legacy-api
 
 # Step 3: Update features based on review findings
-specfact plan update-feature --bundle legacy-api --feature <feature-id>
+specfact project plan update-feature --bundle legacy-api --feature <feature-id>
 
 # Step 4: Enforce SDD (Spec-Driven Development) compliance
-specfact enforce sdd --bundle legacy-api
+specfact govern enforce sdd --bundle legacy-api
 
 # Step 5: Run full validation suite
-specfact repro --verbose
+specfact code repro --verbose
 ```
 
 **Workflow Diagram**:
@@ -144,25 +144,25 @@ graph TD
 
 ```bash
 # Step 1: Initialize a new plan bundle
-specfact plan init new-feature --interactive
+specfact project plan init new-feature --interactive
 
 # Step 2: Add features to the plan
-specfact plan add-feature --bundle new-feature --name "User Authentication"
+specfact project plan add-feature --bundle new-feature --name "User Authentication"
 
 # Step 3: Add user stories to features
-specfact plan add-story --bundle new-feature --feature <feature-id> --story "As a user, I want to log in"
+specfact project plan add-story --bundle new-feature --feature <feature-id> --story "As a user, I want to log in"
 
 # Step 4: Review the plan for completeness
-specfact plan review new-feature
+specfact project plan review new-feature
 
 # Step 5: Harden the plan (finalize before implementation)
-specfact plan harden --bundle new-feature
+specfact project plan harden --bundle new-feature
 
 # Step 6: Generate contracts from the plan
-specfact generate contracts --bundle new-feature
+specfact spec generate contracts --bundle new-feature
 
 # Step 7: Enforce SDD compliance
-specfact enforce sdd --bundle new-feature
+specfact govern enforce sdd --bundle new-feature
 ```
 
 **Workflow Diagram**:
@@ -210,26 +210,26 @@ graph TD
 ```bash
 # For Code/Spec Adapters (Spec-Kit, OpenSpec, generic-markdown):
 # Step 1: Import from external tool via bridge adapter
-specfact import from-bridge --repo . --adapter speckit --write
+specfact project import from-bridge --repo . --adapter speckit --write
 
 # Step 2: Review the imported plan
-specfact plan review <bundle-name>
+specfact project plan review <bundle-name>
 
 # Step 3: Set up bidirectional sync (optional)
-specfact sync bridge --adapter speckit --bundle <bundle-name> --bidirectional --watch
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --bidirectional --watch
 
 # Step 4: Enforce SDD compliance
-specfact enforce sdd --bundle <bundle-name>
+specfact govern enforce sdd --bundle <bundle-name>
 
 # For Backlog Adapters (GitHub Issues, ADO, Linear, Jira) - NEW FEATURE:
 # Step 1: Export OpenSpec change proposals to GitHub Issues
-specfact sync bridge --adapter github --bidirectional --repo-owner owner --repo-name repo
+specfact project sync bridge --adapter github --bidirectional --repo-owner owner --repo-name repo
 
 # Step 2: Import GitHub Issues as change proposals (if needed)
 # (Automatic when using --bidirectional)
 
 # Step 3: Track code changes automatically
-specfact sync bridge --adapter github --track-code-changes --repo-owner owner --repo-name repo
+specfact project sync bridge --adapter github --track-code-changes --repo-owner owner --repo-name repo
 ```
 
 **Workflow Diagram**:
@@ -289,7 +289,7 @@ specfact spec generate-tests --spec openapi.yaml --output tests/
 specfact spec mock --spec openapi.yaml --port 8080
 
 # Step 5: Verify contracts at runtime
-specfact contract verify --bundle api-bundle
+specfact spec contract verify --bundle api-bundle
 ```
 
 **Workflow Diagram**:
@@ -335,10 +335,10 @@ graph TD
 
 ```bash
 # Step 1: Initialize sidecar workspace
-specfact validate sidecar init <bundle-name> <repo-path>
+specfact code validate sidecar init <bundle-name> <repo-path>
 
 # Step 2: Run sidecar validation workflow
-specfact validate sidecar run <bundle-name> <repo-path>
+specfact code validate sidecar run <bundle-name> <repo-path>
 
 # Step 3: Review validation results
 # Results are saved to .specfact/projects/<bundle>/reports/sidecar/
@@ -393,13 +393,13 @@ graph TD
 
 ```bash
 # Step 1: Review the plan before promotion
-specfact plan review <bundle-name>
+specfact project plan review <bundle-name>
 
 # Step 2: Enforce SDD compliance
-specfact enforce sdd --bundle <bundle-name>
+specfact govern enforce sdd --bundle <bundle-name>
 
 # Step 3: Promote the plan to next stage
-specfact plan promote --bundle <bundle-name> --stage <next-stage>
+specfact project plan promote --bundle <bundle-name> --stage <next-stage>
 
 # Step 4: Bump version when releasing
 specfact project version bump --bundle <bundle-name> --type <major|minor|patch>
@@ -444,16 +444,16 @@ graph LR
 
 ```bash
 # Step 1: Import current code state
-specfact import from-code current-state --repo .
+specfact project import from-code current-state --repo .
 
 # Step 2: Compare code against plan
-specfact plan compare --bundle <plan-bundle> --code-vs-plan
+specfact project plan compare --bundle <plan-bundle> --code-vs-plan
 
 # Step 3: Detect drift
-specfact drift detect --bundle <bundle-name>
+specfact code drift detect --bundle <bundle-name>
 
 # Step 4: Sync repository (if drift found)
-specfact sync repository --bundle <bundle-name> --direction <code-to-plan|plan-to-code>
+specfact project sync repository --bundle <bundle-name> --direction <code-to-plan|plan-to-code>
 ```
 
 **Workflow Diagram**:
@@ -497,16 +497,16 @@ graph TD
 
 ```bash
 # Step 1: Generate contract prompt for AI IDE
-specfact generate contracts-prompt --bundle <bundle-name> --feature <feature-id>
+specfact spec generate contracts-prompt --bundle <bundle-name> --feature <feature-id>
 
 # Step 2: [In AI IDE] Use slash command to apply contracts
 # /specfact-cli/contracts-apply <prompt-file>
 
 # Step 3: Check contract coverage
-specfact contract coverage --bundle <bundle-name>
+specfact spec contract coverage --bundle <bundle-name>
 
 # Step 4: Run validation
-specfact repro --verbose
+specfact code repro --verbose
 ```
 
 **Workflow Diagram**:
@@ -548,7 +548,7 @@ graph TD
 
 ```bash
 # Step 1: Generate test prompt for AI IDE
-specfact generate test-prompt --bundle <bundle-name> --feature <feature-id>
+specfact spec generate test-prompt --bundle <bundle-name> --feature <feature-id>
 
 # Step 2: [In AI IDE] Use slash command to generate tests
 # /specfact-cli/test-generate <prompt-file>
@@ -601,16 +601,16 @@ graph TD
 
 ```bash
 # Step 1: Run validation with verbose output
-specfact repro --verbose
+specfact code repro --verbose
 
 # Step 2: Generate fix prompt for discovered gaps
-specfact generate fix-prompt --bundle <bundle-name> --gap <gap-id>
+specfact spec generate fix-prompt --bundle <bundle-name> --gap <gap-id>
 
 # Step 3: [In AI IDE] Use slash command to apply fixes
 # /specfact-cli/fix-apply <prompt-file>
 
 # Step 4: Enforce SDD compliance
-specfact enforce sdd --bundle <bundle-name>
+specfact govern enforce sdd --bundle <bundle-name>
 ```
 
 **Workflow Diagram**:
@@ -653,16 +653,16 @@ graph TD
 
 ```bash
 # Step 1: Bootstrap constitution from repository
-specfact sdd constitution bootstrap --repo .
+specfact spec sdd constitution bootstrap --repo .
 
 # Step 2: Enrich constitution with repository context
-specfact sdd constitution enrich --repo .
+specfact spec sdd constitution enrich --repo .
 
 # Step 3: Validate constitution completeness
-specfact sdd constitution validate
+specfact spec sdd constitution validate
 
 # Step 4: List SDD manifests
-specfact sdd list
+specfact spec sdd list
 ```
 
 **Workflow Diagram**:
diff --git a/docs/guides/common-tasks.md b/docs/guides/common-tasks.md
index 1d8f24d6..22d97534 100644
--- a/docs/guides/common-tasks.md
+++ b/docs/guides/common-tasks.md
@@ -29,7 +29,7 @@ This guide maps common user goals to recommended SpecFact CLI commands or comman
 **Quick Example**:
 
 ```bash
-specfact import from-code legacy-api --repo .
+specfact project import from-code legacy-api --repo .
 ```
 
 **Detailed Guide**: [Brownfield Engineer Guide](brownfield-engineer.md)
@@ -45,9 +45,9 @@ specfact import from-code legacy-api --repo .
 **Quick Example**:
 
 ```bash
-specfact plan init new-feature --interactive
-specfact plan add-feature --bundle new-feature --name "User Authentication"
-specfact plan add-story --bundle new-feature --feature <feature-id> --story "As a user, I want to log in"
+specfact project plan init new-feature --interactive
+specfact project plan add-feature --bundle new-feature --name "User Authentication"
+specfact project plan add-story --bundle new-feature --feature <feature-id> --story "As a user, I want to log in"
 ```
 
 **Detailed Guide**: [Agile/Scrum Workflows](agile-scrum-workflows.md)
@@ -63,8 +63,8 @@ specfact plan add-story --bundle new-feature --feature <feature-id> --story "As
 **Quick Example**:
 
 ```bash
-specfact import from-bridge --repo . --adapter speckit --write
-specfact sync bridge --adapter speckit --bundle <bundle-name> --bidirectional --watch
+specfact project import from-bridge --repo . --adapter speckit --write
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --bidirectional --watch
 ```
 
 **Detailed Guide**: [Spec-Kit Journey](speckit-journey.md) | [OpenSpec Journey](openspec-journey.md)
@@ -80,7 +80,7 @@ specfact sync bridge --adapter speckit --bundle <bundle-name> --bidirectional --
 **Quick Example**:
 
 ```bash
-specfact import from-code legacy-api --repo ./legacy-app
+specfact project import from-code legacy-api --repo ./legacy-app
 ```
 
 **Detailed Guide**: [Brownfield Engineer Guide](brownfield-engineer.md#step-1-understand-what-you-have)
@@ -94,8 +94,8 @@ specfact import from-code legacy-api --repo ./legacy-app
 **Quick Example**:
 
 ```bash
-specfact plan review legacy-api
-specfact plan update-feature --bundle legacy-api --feature <feature-id>
+specfact project plan review legacy-api
+specfact project plan update-feature --bundle legacy-api --feature <feature-id>
 ```
 
 **Detailed Guide**: [Brownfield Engineer Guide](brownfield-engineer.md#step-2-refine-your-plan)
@@ -111,9 +111,9 @@ specfact plan update-feature --bundle legacy-api --feature <feature-id>
 **Quick Example**:
 
 ```bash
-specfact import from-code current-state --repo .
-specfact plan compare --bundle <plan-bundle> --code-vs-plan
-specfact drift detect --bundle <bundle-name>
+specfact project import from-code current-state --repo .
+specfact project plan compare --bundle <plan-bundle> --code-vs-plan
+specfact code drift detect --bundle <bundle-name>
 ```
 
 **Detailed Guide**: [Drift Detection](../reference/commands.md#drift-detect)
@@ -129,9 +129,9 @@ specfact drift detect --bundle <bundle-name>
 **Quick Example**:
 
 ```bash
-specfact generate contracts-prompt --bundle <bundle-name> --feature <feature-id>
+specfact spec generate contracts-prompt --bundle <bundle-name> --feature <feature-id>
 # Then use AI IDE slash command: /specfact-cli/contracts-apply <prompt-file>
-specfact contract coverage --bundle <bundle-name>
+specfact spec contract coverage --bundle <bundle-name>
 ```
 
 **Detailed Guide**: [AI IDE Workflow](ai-ide-workflow.md)
@@ -167,10 +167,10 @@ specfact spec backward-compat --spec openapi.yaml --previous-spec openapi-v1.yam
 
 ```bash
 # Initialize sidecar workspace
-specfact validate sidecar init legacy-api /path/to/django-project
+specfact code validate sidecar init legacy-api /path/to/django-project
 
 # Run validation workflow
-specfact validate sidecar run legacy-api /path/to/django-project
+specfact code validate sidecar run legacy-api /path/to/django-project
 ```
 
 **What it does**:
@@ -278,9 +278,9 @@ specfact project version bump --bundle <bundle-name> --type minor
 **Quick Example**:
 
 ```bash
-specfact plan review <bundle-name>
-specfact enforce sdd --bundle <bundle-name>
-specfact plan promote --bundle <bundle-name> --stage approved
+specfact project plan review <bundle-name>
+specfact govern enforce sdd --bundle <bundle-name>
+specfact project plan promote --bundle <bundle-name> --stage approved
 ```
 
 **Detailed Guide**: [Agile/Scrum Workflows](agile-scrum-workflows.md)
@@ -294,7 +294,7 @@ specfact plan promote --bundle <bundle-name> --stage approved
 **Quick Example**:
 
 ```bash
-specfact plan compare --bundle plan-v1 plan-v2
+specfact project plan compare --bundle plan-v1 plan-v2
 ```
 
 **Detailed Guide**: [Plan Comparison](../reference/commands.md#plan-compare)
@@ -310,7 +310,7 @@ specfact plan compare --bundle plan-v1 plan-v2
 **Quick Example**:
 
 ```bash
-specfact repro --verbose
+specfact code repro --verbose
 ```
 
 **Detailed Guide**: [Validation Workflow](brownfield-engineer.md#step-3-validate-everything)
@@ -324,7 +324,7 @@ specfact repro --verbose
 **Quick Example**:
 
 ```bash
-specfact enforce sdd --bundle <bundle-name>
+specfact govern enforce sdd --bundle <bundle-name>
 ```
 
 **Detailed Guide**: [SDD Enforcement](../reference/commands.md#enforce-sdd)
@@ -340,8 +340,8 @@ specfact enforce sdd --bundle <bundle-name>
 **Quick Example**:
 
 ```bash
-specfact repro --verbose
-specfact generate fix-prompt --bundle <bundle-name> --gap <gap-id>
+specfact code repro --verbose
+specfact spec generate fix-prompt --bundle <bundle-name> --gap <gap-id>
 # Then use AI IDE to apply fixes
 ```
 
@@ -374,7 +374,7 @@ specfact init ide --ide cursor
 **Quick Example**:
 
 ```bash
-specfact generate test-prompt --bundle <bundle-name> --feature <feature-id>
+specfact spec generate test-prompt --bundle <bundle-name> --feature <feature-id>
 # Then use AI IDE slash command: /specfact-cli/test-generate <prompt-file>
 specfact spec generate-tests --spec <spec-file> --output tests/
 ```
@@ -395,12 +395,12 @@ specfact spec generate-tests --spec <spec-file> --output tests/
 
 ```bash
 # Export OpenSpec change proposals to GitHub Issues
-specfact sync bridge --adapter github --bidirectional \
+specfact project sync bridge --adapter github --bidirectional \
   --repo-owner your-org --repo-name your-repo
 
 # Import GitHub Issues as change proposals (automatic with --bidirectional)
 # Track code changes automatically
-specfact sync bridge --adapter github --track-code-changes \
+specfact project sync bridge --adapter github --track-code-changes \
   --repo-owner your-org --repo-name your-repo
 ```
 
@@ -514,15 +514,15 @@ rules:
 
 ```bash
 # Bidirectional sync (export AND import)
-specfact sync bridge --adapter github --bidirectional \
+specfact project sync bridge --adapter github --bidirectional \
   --repo-owner your-org --repo-name your-repo
 
 # Export-only (one-way: OpenSpec → GitHub)
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org --repo-name your-repo
 
 # Update existing issue (when proposal already linked to issue)
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org --repo-name your-repo \
   --change-ids your-change-id \
   --update-existing
@@ -547,7 +547,7 @@ specfact sync bridge --adapter github --mode export-only \
 
 ```bash
 # Update issue #105 for change proposal 'implement-adapter-enhancement-recommendations'
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner nold-ai \
   --repo-name specfact-cli \
   --change-ids implement-adapter-enhancement-recommendations \
@@ -575,7 +575,7 @@ specfact sync bridge --adapter github --mode export-only \
 **Quick Example**:
 
 ```bash
-specfact sync bridge --adapter github --mode export-only --project "SpecFact CLI Development Board"
+specfact project sync bridge --adapter github --mode export-only --project "SpecFact CLI Development Board"
 ```
 
 **Detailed Guide**: [DevOps Adapter Integration](devops-adapter-integration.md)
@@ -610,10 +610,10 @@ specfact --version
 
 ```bash
 # Run validation with verbose output
-specfact repro --verbose
+specfact code repro --verbose
 
 # Check plan for issues
-specfact plan review <bundle-name>
+specfact project plan review <bundle-name>
 ```
 
 **Detailed Guide**: [Troubleshooting](troubleshooting.md)
diff --git a/docs/guides/competitive-analysis.md b/docs/guides/competitive-analysis.md
index 061e3e19..76c0d5e4 100644
--- a/docs/guides/competitive-analysis.md
+++ b/docs/guides/competitive-analysis.md
@@ -75,12 +75,12 @@ SpecFact CLI **complements Spec-Kit** by adding automation and enforcement:
 
 ```bash
 # Read-only sync from OpenSpec to SpecFact (v0.22.0+)
-specfact sync bridge --adapter openspec --mode read-only \
+specfact project sync bridge --adapter openspec --mode read-only \
   --bundle my-project \
   --repo /path/to/openspec-repo
 
 # Export OpenSpec change proposals to GitHub Issues
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --repo /path/to/openspec-repo
@@ -93,7 +93,7 @@ specfact sync bridge --adapter github --mode export-only \
 Already using Spec-Kit? SpecFact CLI **imports your work** in one command:
 
 ```bash
-specfact import from-bridge --adapter speckit --repo ./my-speckit-project --write
+specfact project import from-bridge --adapter speckit --repo ./my-speckit-project --write
 ```
 
 **Result**: Your Spec-Kit artifacts (spec.md, plan.md, tasks.md) become production-ready contracts with zero manual work.
@@ -102,24 +102,24 @@ specfact import from-bridge --adapter speckit --repo ./my-speckit-project --writ
 
 ```bash
 # Enable bidirectional sync (bridge-based, adapter-agnostic)
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
 ```
 
 **Best of both worlds**: Interactive authoring (Spec-Kit) + Automated enforcement (SpecFact)
 
-**Note**: SpecFact CLI uses a plugin-based adapter registry pattern. All adapters (Spec-Kit, OpenSpec, GitHub, etc.) are registered in `AdapterRegistry` and accessed via `specfact sync bridge --adapter <adapter-name>`, making the architecture extensible for future tool integrations.
+**Note**: SpecFact CLI uses a plugin-based adapter registry pattern. All adapters (Spec-Kit, OpenSpec, GitHub, etc.) are registered in `AdapterRegistry` and accessed via `specfact project sync bridge --adapter <adapter-name>`, making the architecture extensible for future tool integrations.
 
 **Team collaboration**: **Shared structured plans** enable multiple developers to work on the same plan with automated deviation detection. Unlike Spec-Kit's manual markdown sharing, SpecFact provides automated bidirectional sync that keeps plans synchronized across team members:
 
 ```bash
 # Enable bidirectional sync for team collaboration
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
 # → Automatically syncs Spec-Kit artifacts ↔ SpecFact project bundles
 # → Multiple developers can work on the same plan with automated synchronization
 # → No manual markdown sharing required
 
 # Detect code vs plan drift automatically
-specfact plan compare --bundle legacy-api --code-vs-plan
+specfact project plan compare --bundle legacy-api --code-vs-plan
 # → Compares intended design (manual plan = what you planned) vs actual implementation (code-derived plan = what's in your code)
 # → Auto-derived plans come from `import from-code` (code analysis), so comparison IS "code vs plan drift"
 # → Identifies deviations automatically (not just artifact consistency like Spec-Kit's /speckit.analyze)
@@ -209,7 +209,7 @@ transitions:
 
 ```bash
 # PR includes reproducible evidence
-specfact repro --budget 120 --report evidence.md
+specfact code repro --budget 120 --report evidence.md
 ```
 
 ### 3. Brownfield-First ⭐ PRIMARY
@@ -222,11 +222,11 @@ specfact repro --budget 120 --report evidence.md
 
 ```bash
 # Primary use case: Analyze legacy code
-specfact import from-code legacy-api --repo ./legacy-app
+specfact project import from-code legacy-api --repo ./legacy-app
 
 # Extract specs from existing code in < 10 seconds
 # Then enforce contracts to prevent regressions
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 ```
 
 **How it complements Spec-Kit**: Spec-Kit focuses on new feature authoring (greenfield); SpecFact CLI's **primary focus** is brownfield code modernization with runtime enforcement.
@@ -241,7 +241,7 @@ specfact enforce stage --preset balanced
 
 ```bash
 # Detect code vs plan drift automatically
-specfact plan compare --bundle legacy-api --code-vs-plan
+specfact project plan compare --bundle legacy-api --code-vs-plan
 # → Compares intended design (manual plan = what you planned) vs actual implementation (code-derived plan = what's in your code)
 # → Auto-derived plans come from `import from-code` (code analysis), so comparison IS "code vs plan drift"
 # → Identifies deviations automatically (not just artifact consistency like Spec-Kit's /speckit.analyze)
@@ -259,7 +259,7 @@ specfact plan compare --bundle legacy-api --code-vs-plan
 
 ```bash
 # Generate reproducible evidence
-specfact repro --report evidence.md
+specfact code repro --report evidence.md
 ```
 
 ### 6. Offline-First
@@ -307,7 +307,7 @@ uvx specfact-cli@latest plan init --interactive
 
 ```bash
 # Primary use case: Analyze legacy codebase
-specfact import from-code legacy-api --repo ./legacy-app
+specfact project import from-code legacy-api --repo ./legacy-app
 ```
 
 See [Use Cases: Brownfield Modernization](use-cases.md#use-case-1-brownfield-code-modernization-primary) ⭐
@@ -317,7 +317,7 @@ See [Use Cases: Brownfield Modernization](use-cases.md#use-case-1-brownfield-cod
 **One-command import**:
 
 ```bash
-specfact import from-bridge --adapter speckit --repo . --write
+specfact project import from-bridge --adapter speckit --repo . --write
 ```
 
 See [Use Cases: Spec-Kit Migration](use-cases.md#use-case-2-github-spec-kit-migration-secondary)
@@ -327,9 +327,9 @@ See [Use Cases: Spec-Kit Migration](use-cases.md#use-case-2-github-spec-kit-migr
 **Add validation layer**:
 
 1. Let AI generate code as usual
-2. Run `specfact import from-code --repo .` (auto-detects CoPilot mode)
+2. Run `specfact project import from-code --repo .` (auto-detects CoPilot mode)
 3. Review auto-generated plan
-4. Enable `specfact enforce stage --preset balanced`
+4. Enable `specfact govern enforce stage --preset balanced`
 
 **With CoPilot Integration:**
 
@@ -351,7 +351,7 @@ SpecFact CLI automatically detects CoPilot and switches to enhanced mode.
 
 **Greenfield approach**:
 
-1. `specfact plan init legacy-api --interactive`
+1. `specfact project plan init legacy-api --interactive`
 2. Add features and stories
 3. Enable strict enforcement
 4. Let SpecFact guide development
diff --git a/docs/guides/contract-testing-workflow.md b/docs/guides/contract-testing-workflow.md
index 471d29aa..640bd84d 100644
--- a/docs/guides/contract-testing-workflow.md
+++ b/docs/guides/contract-testing-workflow.md
@@ -1,15 +1,19 @@
 # Contract Testing Workflow - Simple Guide for Developers
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 ## Quick Start: Verify Your Contract
 
 The easiest way to verify your OpenAPI contract works is with a single command:
 
 ```bash
 # Verify a specific contract
-specfact contract verify --bundle my-api --feature FEATURE-001
+specfact spec contract verify --bundle my-api --feature FEATURE-001
 
 # Verify all contracts in a bundle
-specfact contract verify --bundle my-api
+specfact spec contract verify --bundle my-api
 ```
 
 **What this does:**
@@ -28,7 +32,7 @@ specfact contract verify --bundle my-api
 Use `contract verify` to ensure your contract is correct:
 
 ```bash
-specfact contract verify --bundle my-api --feature FEATURE-001
+specfact spec contract verify --bundle my-api --feature FEATURE-001
 ```
 
 **Output:**
@@ -63,10 +67,10 @@ Start a mock server that generates responses from your contract:
 
 ```bash
 # Start mock server with examples
-specfact contract serve --bundle my-api --feature FEATURE-001 --examples
+specfact spec contract serve --bundle my-api --feature FEATURE-001 --examples
 
 # Or use the verify command (starts mock server automatically)
-specfact contract verify --bundle my-api --feature FEATURE-001
+specfact spec contract verify --bundle my-api --feature FEATURE-001
 ```
 
 **Use cases:**
@@ -81,10 +85,10 @@ Validate that your contract schema is correct:
 
 ```bash
 # Validate a specific contract
-specfact contract validate --bundle my-api --feature FEATURE-001
+specfact spec contract validate --bundle my-api --feature FEATURE-001
 
 # Check coverage across all contracts
-specfact contract coverage --bundle my-api
+specfact spec contract coverage --bundle my-api
 ```
 
 ## Complete Workflow Examples
@@ -93,13 +97,13 @@ specfact contract coverage --bundle my-api
 
 ```bash
 # 1. Create a new contract
-specfact contract init --bundle my-api --feature FEATURE-001
+specfact spec contract init --bundle my-api --feature FEATURE-001
 
 # 2. Edit the contract file
 # Edit: .specfact/projects/my-api/contracts/FEATURE-001.openapi.yaml
 
 # 3. Verify everything works
-specfact contract verify --bundle my-api --feature FEATURE-001
+specfact spec contract verify --bundle my-api --feature FEATURE-001
 
 # 4. Test your client code against the mock server
 curl http://localhost:9000/api/endpoint
@@ -109,20 +113,20 @@ curl http://localhost:9000/api/endpoint
 
 ```bash
 # Validate contracts without starting mock server
-specfact contract verify --bundle my-api --skip-mock --no-interactive
+specfact spec contract verify --bundle my-api --skip-mock --no-interactive
 
 # Or just validate
-specfact contract validate --bundle my-api --no-interactive
+specfact spec contract validate --bundle my-api --no-interactive
 ```
 
 ### Example 3: Multiple Contracts
 
 ```bash
 # Verify all contracts in a bundle
-specfact contract verify --bundle my-api
+specfact spec contract verify --bundle my-api
 
 # Check coverage
-specfact contract coverage --bundle my-api
+specfact spec contract coverage --bundle my-api
 ```
 
 ## What Requires a Real API
@@ -148,7 +152,7 @@ specmatic test \
 
 ```bash
 # 1. Generate test files
-specfact contract test --bundle my-api --feature FEATURE-001
+specfact spec contract test --bundle my-api --feature FEATURE-001
 
 # 2. Start your real API
 python -m uvicorn main:app --port 8000
@@ -166,7 +170,7 @@ specmatic test \
 The simplest way to verify your contract:
 
 ```bash
-specfact contract verify [OPTIONS]
+specfact spec contract verify [OPTIONS]
 
 Options:
   --bundle TEXT          Project bundle name
@@ -186,7 +190,7 @@ Options:
 ### `contract validate` - Schema Validation
 
 ```bash
-specfact contract validate --bundle my-api --feature FEATURE-001
+specfact spec contract validate --bundle my-api --feature FEATURE-001
 ```
 
 Validates the OpenAPI schema structure.
@@ -194,7 +198,7 @@ Validates the OpenAPI schema structure.
 ### `contract serve` - Mock Server
 
 ```bash
-specfact contract serve --bundle my-api --feature FEATURE-001 --examples
+specfact spec contract serve --bundle my-api --feature FEATURE-001 --examples
 ```
 
 Starts a mock server that generates responses from your contract.
@@ -202,7 +206,7 @@ Starts a mock server that generates responses from your contract.
 ### `contract coverage` - Coverage Report
 
 ```bash
-specfact contract coverage --bundle my-api
+specfact spec contract coverage --bundle my-api
 ```
 
 Shows contract coverage metrics across all features.
@@ -210,7 +214,7 @@ Shows contract coverage metrics across all features.
 ### `contract test` - Generate Tests
 
 ```bash
-specfact contract test --bundle my-api --feature FEATURE-001
+specfact spec contract test --bundle my-api --feature FEATURE-001
 ```
 
 Generates test files that can be run against a real API.
@@ -244,7 +248,7 @@ npm install -g @specmatic/specmatic
 cat .specfact/projects/my-api/contracts/FEATURE-001.openapi.yaml
 
 # Validate manually
-specfact contract validate --bundle my-api --feature FEATURE-001
+specfact spec contract validate --bundle my-api --feature FEATURE-001
 ```
 
 ### Examples Not Generated
diff --git a/docs/guides/copilot-mode.md b/docs/guides/copilot-mode.md
index 5a5a3992..32ae0c99 100644
--- a/docs/guides/copilot-mode.md
+++ b/docs/guides/copilot-mode.md
@@ -31,7 +31,7 @@ Mode is auto-detected based on environment, or you can explicitly set it with `-
 specfact --mode copilot import from-code legacy-api --repo . --confidence 0.7
 
 # Mode is auto-detected based on environment (IDE integration, CoPilot API availability)
-specfact import from-code legacy-api --repo . --confidence 0.7  # Auto-detects CoPilot if available
+specfact project import from-code legacy-api --repo . --confidence 0.7  # Auto-detects CoPilot if available
 ```
 
 ### What You Get with CoPilot Mode
diff --git a/docs/guides/custom-field-mapping.md b/docs/guides/custom-field-mapping.md
index 89fa7d25..d7d610e1 100644
--- a/docs/guides/custom-field-mapping.md
+++ b/docs/guides/custom-field-mapping.md
@@ -6,6 +6,10 @@ permalink: /guides/custom-field-mapping/
 
 # Custom Field Mapping Guide
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 > **Customize ADO field mappings** for your specific Azure DevOps process templates and agile frameworks.
 
 This guide explains how to create and use custom field mapping configurations to adapt SpecFact CLI to your organization's specific Azure DevOps field names and work item types.
diff --git a/docs/guides/custom-registries.md b/docs/guides/custom-registries.md
index c4431716..5fceccd4 100644
--- a/docs/guides/custom-registries.md
+++ b/docs/guides/custom-registries.md
@@ -53,7 +53,7 @@ Choose `always` for fully controlled internal registries; use `prompt` for unkno
 
 ## Priority
 
-When multiple registries are configured, they are queried in order: official first, then custom registries by ascending priority number. Search and install use this order; the first matching module id wins. Use priority to prefer an internal registry over the official one for overlapping names (e.g. `specfact/backlog` from your mirror).
+When multiple registries are configured, they are queried in order: official first, then custom registries by ascending priority number. Search and install use this order; the first matching module id wins. Use priority to prefer an internal registry over the official one for overlapping names (e.g. `nold-ai/specfact-backlog` from your mirror).
 
 ## Search across registries
 
diff --git a/docs/guides/devops-adapter-integration.md b/docs/guides/devops-adapter-integration.md
index 54809214..01bd38e9 100644
--- a/docs/guides/devops-adapter-integration.md
+++ b/docs/guides/devops-adapter-integration.md
@@ -6,6 +6,10 @@ permalink: /guides/devops-adapter-integration/
 
 # DevOps Adapter Integration Guide
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 > **🆕 NEW FEATURE: Integrate SpecFact into Agile DevOps Workflows**  
 > Bidirectional synchronization between OpenSpec change proposals and DevOps backlog tools enables seamless integration of specification-driven development into your existing agile workflows.
 
@@ -18,10 +22,10 @@ your backlog system:
 
 ```bash
 # Deterministic policy validation with JSON + Markdown output
-specfact policy validate --repo . --format both
+specfact backlog policy validate --repo . --format both
 
 # AI-assisted suggestions with confidence scores and patch-ready output
-specfact policy suggest --repo .
+specfact backlog policy suggest --repo .
 ```
 
 Both commands read `.specfact/policy.yaml`. `policy suggest` never writes changes automatically; it emits
@@ -113,7 +117,7 @@ EOF
 Export the change proposal to create a GitHub issue:
 
 ```bash
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --repo /path/to/openspec-repo
@@ -128,7 +132,7 @@ As you implement the feature, track progress automatically:
 git commit -m "feat: implement add-feature-x - initial API design"
 
 # Track progress (detects commits and adds comments)
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --track-code-changes \
@@ -174,7 +178,7 @@ specfact backlog auth github --client-id YOUR_CLIENT_ID
 
 ```bash
 # Uses gh auth token automatically
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --use-gh-cli
@@ -184,7 +188,7 @@ specfact sync bridge --adapter github --mode export-only \
 
 ```bash
 export GITHUB_TOKEN=ghp_your_token_here
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo
 ```
@@ -192,7 +196,7 @@ specfact sync bridge --adapter github --mode export-only \
 **Option 4: Command Line Flag**
 
 ```bash
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --github-token ghp_your_token_here
@@ -204,7 +208,7 @@ specfact sync bridge --adapter github --mode export-only \
 
 ```bash
 # Export all active proposals to GitHub Issues
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --repo /path/to/openspec-repo
@@ -214,7 +218,7 @@ specfact sync bridge --adapter github --mode export-only \
 
 ```bash
 # Detect code changes and add progress comments
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --track-code-changes \
@@ -225,7 +229,7 @@ specfact sync bridge --adapter github --mode export-only \
 
 ```bash
 # Export only specific change proposals
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --change-ids add-feature-x,update-api \
@@ -280,7 +284,7 @@ ado:
 
 So after authenticating once, **running from the repo root is enough** for both GitHub and ADO—org/repo or org/project are detected automatically from the git remote.
 
-Applies to all backlog commands: `specfact backlog daily`, `specfact backlog refine`, `specfact sync bridge`, etc.
+Applies to all backlog commands: `specfact backlog daily`, `specfact backlog refine`, `specfact project sync bridge`, etc.
 
 ---
 
@@ -298,7 +302,7 @@ Applies to all backlog commands: `specfact backlog daily`, `specfact backlog ref
 
 ```bash
 # ✅ CORRECT: Direct export from OpenSpec to GitHub
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --change-ids add-feature-x \
@@ -328,7 +332,7 @@ specfact sync bridge --adapter github --mode export-only \
 
 ```bash
 # Step 1: Import GitHub issue into bundle (stores lossless content)
-specfact sync bridge --adapter github --mode bidirectional \
+specfact project sync bridge --adapter github --mode bidirectional \
   --repo-owner your-org --repo-name your-repo \
   --bundle migration-bundle \
   --backlog-ids 123
@@ -337,7 +341,7 @@ specfact sync bridge --adapter github --mode bidirectional \
 # Note the change_id from output
 
 # Step 2: Export from bundle to ADO (uses stored content)
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org --ado-project your-project \
   --bundle migration-bundle \
   --change-ids add-feature-x  # Use change_id from Step 1
@@ -361,7 +365,7 @@ specfact sync bridge --adapter ado --mode export-only \
 
 ```bash
 # ❌ WRONG: This will show "0 backlog items exported"
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org --repo-name your-repo \
   --bundle some-bundle \
   --change-ids add-feature-x \
@@ -374,7 +378,7 @@ specfact sync bridge --adapter github --mode export-only \
 
 ```bash
 # ✅ CORRECT: Direct export (no --bundle)
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org --repo-name your-repo \
   --change-ids add-feature-x \
   --repo /path/to/openspec-repo
@@ -413,13 +417,13 @@ When your OpenSpec change proposals are in a different repository than your sour
 # Source code in specfact-cli
 
 # Step 1: Create issue from proposal
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner nold-ai \
   --repo-name specfact-cli-internal \
   --repo /path/to/specfact-cli-internal
 
 # Step 2: Track code changes from source code repo
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner nold-ai \
   --repo-name specfact-cli-internal \
   --track-code-changes \
@@ -463,7 +467,7 @@ When exporting to public repositories, use content sanitization to protect inter
 
 ```bash
 # Public repository: sanitize content
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name public-repo \
   --sanitize \
@@ -471,7 +475,7 @@ specfact sync bridge --adapter github --mode export-only \
   --repo /path/to/openspec-repo
 
 # Internal repository: use full content
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name internal-repo \
   --no-sanitize \
@@ -571,7 +575,7 @@ When `--sanitize` is enabled, progress comments are sanitized:
 2. **Export to GitHub**:
 
    ```bash
-   specfact sync bridge --adapter github --mode export-only \
+   specfact project sync bridge --adapter github --mode export-only \
      --repo-owner your-org \
      --repo-name your-repo \
      --repo /path/to/openspec-repo
@@ -594,7 +598,7 @@ When `--sanitize` is enabled, progress comments are sanitized:
 2. **Track Progress**:
 
    ```bash
-   specfact sync bridge --adapter github --mode export-only \
+   specfact project sync bridge --adapter github --mode export-only \
      --repo-owner your-org \
      --repo-name your-repo \
      --track-code-changes \
@@ -613,7 +617,7 @@ When `--sanitize` is enabled, progress comments are sanitized:
 Add manual progress comments without code change detection:
 
 ```bash
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --add-progress-comment \
@@ -638,7 +642,7 @@ SpecFact supports more than exporting and updating backlog items:
 Example: Import selected GitHub issues into a bundle and keep them in sync:
 
 ```bash
-specfact sync bridge --adapter github --mode bidirectional \
+specfact project sync bridge --adapter github --mode bidirectional \
   --repo-owner your-org --repo-name your-repo \
   --bundle main \
   --backlog-ids 111,112
@@ -672,7 +676,7 @@ Migrate a GitHub issue to Azure DevOps while preserving all content:
 ```bash
 # Step 1: Import GitHub issue into bundle (stores lossless content)
 # This creates a change proposal in the bundle and stores raw content
-specfact sync bridge --adapter github --mode bidirectional \
+specfact project sync bridge --adapter github --mode bidirectional \
   --repo-owner your-org --repo-name your-repo \
   --bundle main \
   --backlog-ids 123
@@ -692,7 +696,7 @@ ls /path/to/openspec-repo/openspec/changes/
 
 # Step 3: Export from bundle to ADO (uses stored lossless content)
 # Replace <change-id> with the actual change_id from Step 1
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org --ado-project your-project \
   --bundle main \
   --change-ids add-feature-x  # Use the actual change_id from Step 1
@@ -751,7 +755,7 @@ Keep proposals in sync across GitHub (public) and ADO (internal):
 ```bash
 # Day 1: Create proposal in OpenSpec, export to GitHub (public)
 # Assume change_id is "add-feature-x" (from openspec/changes/add-feature-x/proposal.md)
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org --repo-name public-repo \
   --sanitize \
   --repo /path/to/openspec-repo \
@@ -762,7 +766,7 @@ specfact sync bridge --adapter github --mode export-only \
 
 # Day 2: Import GitHub issue into bundle (for internal team)
 # This stores lossless content in the bundle
-specfact sync bridge --adapter github --mode bidirectional \
+specfact project sync bridge --adapter github --mode bidirectional \
   --repo-owner your-org --repo-name public-repo \
   --bundle internal \
   --backlog-ids 123
@@ -772,7 +776,7 @@ specfact sync bridge --adapter github --mode bidirectional \
 
 # Day 3: Export to ADO for internal tracking (full content, no sanitization)
 # Uses the change_id from Day 2
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org --ado-project internal-project \
   --bundle internal \
   --change-ids add-feature-x
@@ -782,7 +786,7 @@ specfact sync bridge --adapter ado --mode export-only \
 
 # Day 4: Update in ADO, sync back to GitHub (status sync)
 # Import ADO work item to update bundle with latest status
-specfact sync bridge --adapter ado --mode bidirectional \
+specfact project sync bridge --adapter ado --mode bidirectional \
   --ado-org your-org --ado-project internal-project \
   --bundle internal \
   --backlog-ids 456
@@ -791,7 +795,7 @@ specfact sync bridge --adapter ado --mode bidirectional \
 # Bundle now has latest status from ADO
 
 # Then sync status back to GitHub
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org --repo-name public-repo \
   --update-existing \
   --repo /path/to/openspec-repo \
@@ -853,7 +857,7 @@ export AZURE_DEVOPS_TOKEN='your-ado-token'
 
 # Step 1: Import GitHub issue into bundle
 # This stores the issue in a bundle with lossless content preservation
-specfact sync bridge --adapter github --mode bidirectional \
+specfact project sync bridge --adapter github --mode bidirectional \
   --repo-owner your-org --repo-name your-repo \
   --bundle migration-bundle \
   --backlog-ids 123
@@ -869,7 +873,7 @@ ls .specfact/projects/migration-bundle/change_tracking/proposals/
 
 # Step 3: Export to Azure DevOps
 # Use the change_id from Step 1
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org --ado-project your-project \
   --bundle migration-bundle \
   --change-ids add-feature-x
@@ -884,13 +888,13 @@ specfact sync bridge --adapter ado --mode export-only \
 # Content should match exactly (Why, What Changes sections, formatting)
 
 # Step 5: Optional - Round-trip back to GitHub to verify
-specfact sync bridge --adapter ado --mode bidirectional \
+specfact project sync bridge --adapter ado --mode bidirectional \
   --ado-org your-org --ado-project your-project \
   --bundle migration-bundle \
   --backlog-ids 456
 
 # Then export back to GitHub
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org --repo-name your-repo \
   --bundle migration-bundle \
   --change-ids add-feature-x \
@@ -922,7 +926,7 @@ export AZURE_DEVOPS_TOKEN='your-ado-token'
 # Import GitHub issue #110 into bundle 'cross-sync-test'
 # Note: Bundle will be auto-created if it doesn't exist
 # This stores lossless content in the bundle
-specfact sync bridge --adapter github --mode bidirectional \
+specfact project sync bridge --adapter github --mode bidirectional \
   --repo-owner nold-ai --repo-name specfact-cli \
   --bundle cross-sync-test \
   --backlog-ids 110
@@ -943,7 +947,7 @@ ls /path/to/openspec-repo/openspec/changes/
 # ============================================================
 # Export the proposal to ADO using the change_id from Step 1
 # Replace <change-id> with the actual change_id from Step 1
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org --ado-project your-project \
   --bundle cross-sync-test \
   --change-ids <change-id>
@@ -959,7 +963,7 @@ specfact sync bridge --adapter ado --mode export-only \
 # Import the ADO work item back into the bundle
 # This updates the bundle with ADO's version of the content
 # Replace <ado-work-item-id> with the ID from Step 2
-specfact sync bridge --adapter ado --mode bidirectional \
+specfact project sync bridge --adapter ado --mode bidirectional \
   --ado-org your-org --ado-project your-project \
   --bundle cross-sync-test \
   --backlog-ids <ado-work-item-id>
@@ -973,7 +977,7 @@ specfact sync bridge --adapter ado --mode bidirectional \
 # ============================================================
 # Export back to GitHub to complete the round-trip
 # This updates the original GitHub issue with any changes from ADO
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner nold-ai --repo-name specfact-cli \
   --bundle cross-sync-test \
   --change-ids <change-id> \
@@ -1057,7 +1061,7 @@ The change proposal must have `source_tracking` metadata linking it to the GitHu
 To update a specific change proposal's linked issue:
 
 ```bash
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --change-ids your-change-id \
@@ -1070,7 +1074,7 @@ specfact sync bridge --adapter github --mode export-only \
 ```bash
 cd /path/to/openspec-repo
 
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner nold-ai \
   --repo-name specfact-cli \
   --change-ids implement-adapter-enhancement-recommendations \
@@ -1083,7 +1087,7 @@ specfact sync bridge --adapter github --mode export-only \
 To update all change proposals that have linked GitHub issues:
 
 ```bash
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --update-existing \
@@ -1134,7 +1138,7 @@ By default, archived change proposals (in `openspec/changes/archive/`) are exclu
 
 ```bash
 # Update all archived proposals with new comment logic
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --include-archived \
@@ -1142,7 +1146,7 @@ specfact sync bridge --adapter github --mode export-only \
   --repo /path/to/openspec-repo
 
 # Update specific archived proposal
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --change-ids add-code-change-tracking \
@@ -1164,7 +1168,7 @@ When `--include-archived` is used with `--update-existing`:
 
 ```bash
 # Update issue #107 with improved branch detection
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner nold-ai \
   --repo-name specfact-cli \
   --change-ids add-code-change-tracking \
@@ -1252,7 +1256,7 @@ Verify `openspec/changes/<change-id>/proposal.md` was updated:
 
    ```bash
    # ❌ WRONG: Using --bundle when exporting from OpenSpec
-   specfact sync bridge --adapter github --mode export-only \
+   specfact project sync bridge --adapter github --mode export-only \
      --repo-owner your-org --repo-name your-repo \
      --bundle some-bundle \
      --change-ids add-feature-x \
@@ -1270,7 +1274,7 @@ Verify `openspec/changes/<change-id>/proposal.md` was updated:
 
   ```bash
   # ✅ CORRECT: Direct export from OpenSpec
-  specfact sync bridge --adapter github --mode export-only \
+  specfact project sync bridge --adapter github --mode export-only \
     --repo-owner your-org --repo-name your-repo \
     --change-ids add-feature-x \
     --repo /path/to/openspec-repo
@@ -1280,13 +1284,13 @@ Verify `openspec/changes/<change-id>/proposal.md` was updated:
 
   ```bash
   # Step 1: Import from backlog into bundle
-  specfact sync bridge --adapter github --mode bidirectional \
+  specfact project sync bridge --adapter github --mode bidirectional \
     --repo-owner your-org --repo-name your-repo \
     --bundle your-bundle \
     --backlog-ids 123
   
   # Step 2: Export from bundle (now it will work)
-  specfact sync bridge --adapter ado --mode export-only \
+  specfact project sync bridge --adapter ado --mode export-only \
     --ado-org your-org --ado-project your-project \
     --bundle your-bundle \
     --change-ids <change-id-from-step-1>
@@ -1447,13 +1451,13 @@ specfact backlog auth azure-devops
 
 # Option 2: Environment Variable
 export AZURE_DEVOPS_TOKEN=your_pat_token
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org \
   --ado-project your-project \
   --repo /path/to/openspec-repo
 
 # Option 3: Command Line Flag
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org \
   --ado-project your-project \
   --ado-token your_pat_token \
@@ -1464,26 +1468,26 @@ specfact sync bridge --adapter ado --mode export-only \
 
 ```bash
 # Bidirectional sync (import work items AND export proposals)
-specfact sync bridge --adapter ado --bidirectional \
+specfact project sync bridge --adapter ado --bidirectional \
   --ado-org your-org \
   --ado-project your-project \
   --repo /path/to/openspec-repo
 
 # Export-only (one-way: OpenSpec → ADO)
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org \
   --ado-project your-project \
   --repo /path/to/openspec-repo
 
 # Export with explicit work item type
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org \
   --ado-project your-project \
   --ado-work-item-type "User Story" \
   --repo /path/to/openspec-repo
 
 # Track code changes and add progress comments
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org \
   --ado-project your-project \
   --track-code-changes \
@@ -1502,7 +1506,7 @@ The ADO adapter automatically derives work item type from your project's process
 You can override with `--ado-work-item-type`:
 
 ```bash
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org \
   --ado-project your-project \
   --ado-work-item-type "Bug" \
diff --git a/docs/guides/dual-stack-enrichment.md b/docs/guides/dual-stack-enrichment.md
index be52231e..2f83e8eb 100644
--- a/docs/guides/dual-stack-enrichment.md
+++ b/docs/guides/dual-stack-enrichment.md
@@ -1,5 +1,9 @@
 # Dual-Stack Enrichment Pattern
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 **Status**: ✅ **AVAILABLE** (v0.13.0+)  
 **Last Updated**: 2025-12-23  
 **Version**: v0.20.4 (enrichment parser improvements: story merging, format validation)
@@ -186,7 +190,7 @@ The enrichment parser expects a specific Markdown format. Follow this structure
 
 ```bash
 # Use enrichment to update plan via CLI
-specfact import from-code [<bundle-name>] --repo <path> --enrichment <enrichment-report> --no-interactive
+specfact project import from-code [<bundle-name>] --repo <path> --enrichment <enrichment-report> --no-interactive
 ```
 
 **Result**: Final artifacts are CLI-generated with validated enrichments
@@ -250,7 +254,7 @@ This is a real example of the validation loop pattern in action:
 ### Step 1: Generate Prompt
 
 ```bash
-specfact generate contracts-prompt src/auth/login.py --apply beartype,icontract --bundle legacy-api
+specfact spec generate contracts-prompt src/auth/login.py --apply beartype,icontract --bundle legacy-api
 ```
 
 **Result**: Prompt saved to `.specfact/projects/legacy-api/prompts/enhance-login-beartype-icontract.md`
@@ -266,7 +270,7 @@ specfact generate contracts-prompt src/auth/login.py --apply beartype,icontract
 ### Step 3: Validate and Apply
 
 ```bash
-specfact generate contracts-apply enhanced_login.py --original src/auth/login.py
+specfact spec generate contracts-apply enhanced_login.py --original src/auth/login.py
 ```
 
 **Validation includes**:
@@ -321,15 +325,15 @@ specfact generate contracts-apply enhanced_login.py --original src/auth/login.py
 
 ## Available CLI Commands
 
-- `specfact plan init <bundle-name>` - Initialize project bundle
-- `specfact plan select <bundle-name>` - Set active plan (used as default for other commands)
-- `specfact import from-code [<bundle-name>] --repo <path>` - Import from codebase (uses active plan if bundle not specified)
-- `specfact plan review [<bundle-name>]` - Review plan (uses active plan if bundle not specified)
-- `specfact plan harden [<bundle-name>]` - Create SDD manifest (uses active plan if bundle not specified)
-- `specfact enforce sdd [<bundle-name>]` - Validate SDD (uses active plan if bundle not specified)
-- `specfact generate contracts-prompt <file> --apply <contracts>` - Generate contract enhancement prompt
-- `specfact generate contracts-apply <enhanced-file> --original <original-file>` - Validate and apply enhanced code
-- `specfact sync bridge --adapter <adapter> --repo <path>` - Sync with external tools
+- `specfact project plan init <bundle-name>` - Initialize project bundle
+- `specfact project plan select <bundle-name>` - Set active plan (used as default for other commands)
+- `specfact project import from-code [<bundle-name>] --repo <path>` - Import from codebase (uses active plan if bundle not specified)
+- `specfact project plan review [<bundle-name>]` - Review plan (uses active plan if bundle not specified)
+- `specfact project plan harden [<bundle-name>]` - Create SDD manifest (uses active plan if bundle not specified)
+- `specfact govern enforce sdd [<bundle-name>]` - Validate SDD (uses active plan if bundle not specified)
+- `specfact spec generate contracts-prompt <file> --apply <contracts>` - Generate contract enhancement prompt
+- `specfact spec generate contracts-apply <enhanced-file> --original <original-file>` - Validate and apply enhanced code
+- `specfact project sync bridge --adapter <adapter> --repo <path>` - Sync with external tools
 - See [Command Reference](../reference/commands.md) for full list
 
 **Note**: Most commands now support active plan fallback. If `--bundle` is not specified, commands automatically use the active plan set via `plan select`. This improves workflow efficiency in AI IDE environments.
diff --git a/docs/guides/ide-integration.md b/docs/guides/ide-integration.md
index 1f490c32..c3530acf 100644
--- a/docs/guides/ide-integration.md
+++ b/docs/guides/ide-integration.md
@@ -161,21 +161,21 @@ Detailed instructions for the AI assistant...
 
 | Command | Description | CLI Equivalent |
 |---------|-------------|----------------|
-| `/specfact.01-import` | Import codebase into plan bundle | `specfact import from-code <bundle-name>` |
-| `/specfact.02-plan` | Plan management (init, add-feature, add-story, update-idea, update-feature, update-story) | `specfact plan <operation> <bundle-name>` |
-| `/specfact.03-review` | Review plan and promote through stages | `specfact plan review <bundle-name>`, `specfact plan promote <bundle-name>` |
-| `/specfact.04-sdd` | Create SDD manifest from plan | `specfact plan harden <bundle-name>` |
-| `/specfact.05-enforce` | Validate SDD and contracts | `specfact enforce sdd <bundle-name>` |
-| `/specfact.06-sync` | Sync with external tools or repository | `specfact sync bridge --adapter <adapter>` |
-| `/specfact.07-contracts` | Contract enhancement workflow: analyze → generate prompts → apply sequentially | `specfact analyze contracts`, `specfact generate contracts-prompt`, `specfact generate contracts-apply` |
+| `/specfact.01-import` | Import codebase into plan bundle | `specfact project import from-code <bundle-name>` |
+| `/specfact.02-plan` | Plan management (init, add-feature, add-story, update-idea, update-feature, update-story) | `specfact project plan <operation> <bundle-name>` |
+| `/specfact.03-review` | Review plan and promote through stages | `specfact project plan review <bundle-name>`, `specfact project plan promote <bundle-name>` |
+| `/specfact.04-sdd` | Create SDD manifest from plan | `specfact project plan harden <bundle-name>` |
+| `/specfact.05-enforce` | Validate SDD and contracts | `specfact govern enforce sdd <bundle-name>` |
+| `/specfact.06-sync` | Sync with external tools or repository | `specfact project sync bridge --adapter <adapter>` |
+| `/specfact.07-contracts` | Contract enhancement workflow: analyze → generate prompts → apply sequentially | `specfact code analyze contracts`, `specfact spec generate contracts-prompt`, `specfact spec generate contracts-apply` |
 
 **Advanced Commands** (no numbering):
 
 | Command | Description | CLI Equivalent |
 |---------|-------------|----------------|
-| `/specfact.compare` | Compare manual vs auto plans | `specfact plan compare` |
-| `/specfact.validate` | Run validation suite | `specfact repro` |
-| `/specfact.generate-contracts-prompt` | Generate AI IDE prompt for adding contracts | `specfact generate contracts-prompt <file> --apply <contracts>` |
+| `/specfact.compare` | Compare manual vs auto plans | `specfact project plan compare` |
+| `/specfact.validate` | Run validation suite | `specfact code repro` |
+| `/specfact.generate-contracts-prompt` | Generate AI IDE prompt for adding contracts | `specfact spec generate contracts-prompt <file> --apply <contracts>` |
 
 ---
 
diff --git a/docs/guides/import-features.md b/docs/guides/import-features.md
index d7a06f23..b74d1e1a 100644
--- a/docs/guides/import-features.md
+++ b/docs/guides/import-features.md
@@ -6,6 +6,10 @@ permalink: /guides/import-features/
 
 # Import Command Features
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 This guide covers advanced features and optimizations in the `import from-code` command.
 
 ## Overview
@@ -60,10 +64,10 @@ When you restart an import on an existing bundle, the command automatically vali
 
 ```bash
 # First import
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 
 # Later, restart import (validates existing features automatically)
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 ```
 
 ### Validation Results
@@ -112,7 +116,7 @@ Features are saved immediately after the initial codebase analysis, before expen
 
 ```bash
 # Start import
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 
 # Output shows:
 # ✓ Found 3156 features
@@ -120,7 +124,7 @@ specfact import from-code my-project --repo .
 # ✓ Features saved (can resume if interrupted)
 
 # If you press Ctrl+C during source linking, you can restart:
-specfact import from-code my-project --repo .
+specfact project import from-code my-project --repo .
 # The command will detect existing features and resume from checkpoint
 ```
 
@@ -165,7 +169,7 @@ Use `--revalidate-features` to force re-analysis even if source files haven't ch
 
 ```bash
 # Re-analyze all features even if files unchanged
-specfact import from-code my-project --repo . --revalidate-features
+specfact project import from-code my-project --repo . --revalidate-features
 
 # Output shows:
 # ⚠ --revalidate-features enabled: Will re-analyze features even if files unchanged
diff --git a/docs/guides/installing-modules.md b/docs/guides/installing-modules.md
index fff869b7..de23df95 100644
--- a/docs/guides/installing-modules.md
+++ b/docs/guides/installing-modules.md
@@ -14,9 +14,9 @@ Use plain `specfact ...` commands in this guide (not `hatch run specfact ...`) s
 
 ```bash
 # Marketplace id format
-specfact module install specfact/backlog
+specfact module install nold-ai/specfact-backlog
 
-# Bare names are accepted and normalized to specfact/<name>
+# Bare names are accepted and resolved through the configured source policy
 specfact module install backlog
 
 # Install into project scope instead of user scope
@@ -28,7 +28,7 @@ specfact module install backlog --source marketplace
 specfact module install backlog --source marketplace --trust-non-official
 
 # Install a specific version
-specfact module install specfact/backlog --version 0.35.0
+specfact module install nold-ai/specfact-backlog --version 0.40.0
 ```
 
 Notes:
@@ -46,13 +46,13 @@ Before installing a marketplace module, SpecFact resolves its dependencies (othe
 
 ```bash
 # Install with dependency resolution (default)
-specfact module install specfact/backlog
+specfact module install nold-ai/specfact-backlog
 
 # Skip dependency resolution (install only the requested module)
-specfact module install specfact/backlog --skip-deps
+specfact module install nold-ai/specfact-backlog --skip-deps
 
 # Force install despite dependency conflicts (use with care)
-specfact module install specfact/backlog --force
+specfact module install nold-ai/specfact-backlog --force
 ```
 
 - Use `--skip-deps` when you want to install a single module without pulling its dependencies or when you manage dependencies yourself.
@@ -155,7 +155,7 @@ Use `--force` to allow dependency-aware cascades when required.
 
 ```bash
 specfact module uninstall backlog
-specfact module uninstall specfact/backlog
+specfact module uninstall nold-ai/specfact-backlog
 specfact module uninstall backlog --scope project --repo /path/to/repo
 ```
 
@@ -179,3 +179,6 @@ specfact module upgrade --all
 ```
 
 Upgrade applies only to modules with origin `marketplace`.
+
+> Temporary docs note: module-specific install and bundle behavior docs remain hosted in this
+> core docs set for the current release line and are planned to migrate to `specfact-cli-modules`.
diff --git a/docs/guides/marketplace.md b/docs/guides/marketplace.md
index b544ff98..4a34ec95 100644
--- a/docs/guides/marketplace.md
+++ b/docs/guides/marketplace.md
@@ -15,7 +15,7 @@ SpecFact publishes official workflow bundles in the dedicated modules repository
 
 ## Official Bundles
 
-These bundles are the primary installation path for workflow commands. Fresh installs start with lean core commands only (`init`, `auth`, `module`, `upgrade`).
+These bundles are the primary installation path for workflow commands. Fresh installs start with lean core commands only (`init`, `module`, `upgrade`).
 
 Install commands:
 
@@ -29,11 +29,11 @@ specfact module install nold-ai/specfact-govern
 
 Bundle overview:
 
-- `nold-ai/specfact-project`: project lifecycle commands (`project`, `plan`, `import`, `sync`, `migrate`)
-- `nold-ai/specfact-backlog`: backlog and policy workflows (`backlog`, `policy`)
-- `nold-ai/specfact-codebase`: codebase analysis and validation (`analyze`, `drift`, `validate`, `repro`)
-- `nold-ai/specfact-spec`: API/spec workflows (`contract`, `api`, `sdd`, `generate`)
-- `nold-ai/specfact-govern`: governance and patch workflows (`enforce`, `patch`)
+- `nold-ai/specfact-project`: grouped project workflows (`project`, `plan`, `import`, `sync`, `migrate`)
+- `nold-ai/specfact-backlog`: grouped backlog workflows (`backlog`, `policy`, `backlog auth`)
+- `nold-ai/specfact-codebase`: grouped code workflows (`analyze`, `drift`, `validate`, `repro`)
+- `nold-ai/specfact-spec`: grouped spec workflows (`contract`, `api`, `sdd`, `generate`)
+- `nold-ai/specfact-govern`: grouped governance workflows (`enforce`, `patch`)
 
 ## Trust Tiers
 
@@ -81,3 +81,6 @@ specfact module init
 - [Module Marketplace](module-marketplace.md)
 - [Installing Modules](installing-modules.md)
 - [Module Categories](../reference/module-categories.md)
+
+> Temporary docs note: bundle-specific marketplace guidance remains hosted in this core docs set
+> for the current release line and is planned to migrate to `specfact-cli-modules`.
diff --git a/docs/guides/migration-0.16-to-0.19.md b/docs/guides/migration-0.16-to-0.19.md
index 646196ef..8f789e3e 100644
--- a/docs/guides/migration-0.16-to-0.19.md
+++ b/docs/guides/migration-0.16-to-0.19.md
@@ -35,16 +35,16 @@ Use the new bridge commands instead:
 
 ```bash
 # Set up CrossHair for contract exploration (one-time setup, only available since v0.20.1)
-specfact repro setup
+specfact code repro setup
 
 # Analyze and validate your codebase
-specfact repro --verbose
+specfact code repro --verbose
 
 # Generate AI-ready prompt to fix a gap
-specfact generate fix-prompt GAP-001 --bundle my-bundle
+specfact spec generate fix-prompt GAP-001 --bundle my-bundle
 
 # Generate AI-ready prompt to add tests
-specfact generate test-prompt src/auth/login.py --bundle my-bundle
+specfact spec generate test-prompt src/auth/login.py --bundle my-bundle
 ```
 
 ### `run idea-to-ship` Removed
@@ -63,10 +63,10 @@ New commands that generate AI-ready prompts for your IDE:
 
 ```bash
 # Generate fix prompt for a gap
-specfact generate fix-prompt GAP-001
+specfact spec generate fix-prompt GAP-001
 
 # Generate test prompt for a file
-specfact generate test-prompt src/module.py --type unit
+specfact spec generate test-prompt src/module.py --type unit
 ```
 
 ### Version Management (v0.17.0)
@@ -119,7 +119,7 @@ If you were using `implement tasks` or `run idea-to-ship`, migrate to bridge com
 
 ```bash
 # REMOVED in v0.22.0 - Use Spec-Kit, OpenSpec, or other SDD tools instead
-# specfact generate tasks --bundle my-bundle
+# specfact spec generate tasks --bundle my-bundle
 # specfact implement tasks .specfact/projects/my-bundle/tasks.yaml
 ```
 
@@ -127,15 +127,15 @@ If you were using `implement tasks` or `run idea-to-ship`, migrate to bridge com
 
 ```bash
 # 1. Analyze and validate your codebase
-specfact repro --verbose
+specfact code repro --verbose
 
 # 2. Generate AI prompts for each gap
-specfact generate fix-prompt GAP-001 --bundle my-bundle
+specfact spec generate fix-prompt GAP-001 --bundle my-bundle
 
 # 3. Copy prompt to AI IDE, get fix, apply
 
 # 4. Validate
-specfact enforce sdd --bundle my-bundle
+specfact govern enforce sdd --bundle my-bundle
 ```
 
 ### Step 4: Update CI/CD (Optional)
diff --git a/docs/guides/migration-cli-reorganization.md b/docs/guides/migration-cli-reorganization.md
index 2dca6431..afd77acb 100644
--- a/docs/guides/migration-cli-reorganization.md
+++ b/docs/guides/migration-cli-reorganization.md
@@ -42,17 +42,17 @@ The CLI reorganization includes:
 **Before**:
 
 ```bash
-specfact generate contracts --base-path .
-specfact plan compare --bundle legacy-api --format json --out report.json
-specfact enforce sdd legacy-api --non-interactive
+specfact spec generate contracts --base-path .
+specfact project plan compare --bundle legacy-api --format json --out report.json
+specfact govern enforce sdd legacy-api --non-interactive
 ```
 
 **After**:
 
 ```bash
-specfact generate contracts --repo .
-specfact plan compare --bundle legacy-api --output-format json --out report.json
-specfact enforce sdd legacy-api --no-interactive
+specfact spec generate contracts --repo .
+specfact project plan compare --bundle legacy-api --output-format json --out report.json
+specfact govern enforce sdd legacy-api --no-interactive
 ```
 
 ---
@@ -122,15 +122,15 @@ The new numbered commands follow natural workflow progression:
 **Before** (positional argument):
 
 ```bash
-specfact plan init legacy-api
-specfact plan review legacy-api
+specfact project plan init legacy-api
+specfact project plan review legacy-api
 ```
 
 **After** (named parameter):
 
 ```bash
-specfact plan init legacy-api
-specfact plan review legacy-api
+specfact project plan init legacy-api
+specfact project plan review legacy-api
 ```
 
 ### Path Resolution Changes
@@ -199,7 +199,7 @@ Example: 'specfact constitution bootstrap' → 'specfact sdd constitution bootst
 ```bash
 specfact import from-code legacy-api --repo .
 specfact sdd constitution bootstrap --repo .
-specfact sync bridge --adapter speckit
+specfact project sync bridge --adapter speckit
 ```
 
 ### Constitution Management Workflow
diff --git a/docs/guides/migration-guide.md b/docs/guides/migration-guide.md
index aeb8e9e0..28b3d71a 100644
--- a/docs/guides/migration-guide.md
+++ b/docs/guides/migration-guide.md
@@ -122,7 +122,7 @@ Start: What do you need to migrate?
 specfact project export --bundle old-bundle --persona <persona>
 
 # Create new bundle
-specfact plan init new-bundle
+specfact project plan init new-bundle
 
 # Import to new bundle (manual editing may be required)
 specfact project import --bundle new-bundle --persona <persona> --source exported.md
@@ -142,10 +142,10 @@ specfact project import --bundle new-bundle --persona <persona> --source exporte
 
 ```bash
 # Upgrade all bundles
-specfact plan upgrade --all
+specfact project plan upgrade --all
 
 # Upgrade specific bundle
-specfact plan upgrade --bundle <bundle-name>
+specfact project plan upgrade --bundle <bundle-name>
 ```
 
 **Benefits**:
@@ -173,10 +173,10 @@ specfact --version
 pip install --upgrade specfact-cli
 
 # 4. Upgrade plan bundles
-specfact plan upgrade --all
+specfact project plan upgrade --all
 
 # 5. Test commands
-specfact plan select --last 5
+specfact project plan select --last 5
 ```
 
 ---
@@ -188,13 +188,13 @@ specfact plan select --last 5
 specfact import from-bridge --repo . --adapter speckit --write
 
 # 2. Review imported plan
-specfact plan review <bundle-name>
+specfact project plan review <bundle-name>
 
 # 3. Set up bidirectional sync (optional)
-specfact sync bridge --adapter speckit --bundle <bundle-name> --bidirectional --watch
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --bidirectional --watch
 
 # 4. Enforce SDD compliance
-specfact enforce sdd --bundle <bundle-name>
+specfact govern enforce sdd --bundle <bundle-name>
 ```
 
 **Related**: [Spec-Kit Journey Guide](speckit-journey.md)
@@ -211,10 +211,10 @@ specfact enforce sdd --bundle <bundle-name>
 
 ```bash
 # Check bundle schema version
-specfact plan select --bundle <bundle-name> --json | jq '.schema_version'
+specfact project plan select --bundle <bundle-name> --json | jq '.schema_version'
 
 # Manual upgrade if needed
-specfact plan upgrade --bundle <bundle-name> --force
+specfact project plan upgrade --bundle <bundle-name> --force
 ```
 
 **Issue**: Imported plans have missing data
diff --git a/docs/guides/module-development.md b/docs/guides/module-development.md
index 24b15340..b527c2e1 100644
--- a/docs/guides/module-development.md
+++ b/docs/guides/module-development.md
@@ -9,26 +9,44 @@ description: How to build and package SpecFact CLI modules.
 
 This guide defines the required structure and contracts for authoring SpecFact modules.
 
+> Temporary docs note: module-authoring guidance is still hosted in this core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
+Official workflow bundle implementation now lives in the dedicated `nold-ai/specfact-cli-modules`
+repository. `specfact-cli` owns the lean runtime, registry, marketplace lifecycle, shared
+contracts, and bundle loading/orchestration surfaces consumed by installed bundles.
+
 ## Required structure
 
 ```text
-src/specfact_cli/modules/<module-name>/
-  module-package.yaml
-  src/
-    __init__.py
-    app.py
-    commands.py
+specfact-cli-modules/
+  packages/<bundle-package>/
+    pyproject.toml
+    src/<bundle_namespace>/<command_or_feature>/
+      __init__.py
+      app.py
+      commands.py
+
+specfact-cli/
+  src/specfact_cli/
+    registry/
+    groups/
+    common/
+    adapters/
+    models/
 ```
 
-For workspace-level modules, keep the same structure under the configured modules root.
+For local/project-scoped modules discovered by the CLI, keep the configured module root structure
+under `<repo>/.specfact/modules` or `~/.specfact/modules` and ensure marketplace metadata remains
+compatible with the runtime loader.
 
 ## `module-package.yaml` schema
 
 Required fields:
 
-- `name`: module identifier
+- `name`: module or bundle identifier
 - `version`: semantic version string
-- `commands`: top-level command names provided by this module
+- `commands`: command names provided by this module or package entrypoint
 
 Common optional fields:
 
@@ -63,10 +81,11 @@ Extension/security fields:
 
 ## Integration checklist
 
-1. Add `module-package.yaml`.
-2. Implement `src/app.py` and `src/commands.py`.
-3. Ensure loader/import path works with registry discovery.
-4. Run format/type-check/lint/contract checks.
+1. Add or update the package/module manifest (`module-package.yaml`) and package metadata in the modules repository.
+2. Implement command entrypoints in the bundle package namespace.
+3. Ensure runtime loader/import paths remain compatible with `specfact-cli` registry discovery and bundle grouping.
+4. Run format/type-check/lint/contract/signature checks in the owning repository.
+5. Keep core-only docs and runtime contracts in `specfact-cli`; keep bundle behavior/docs with the modules repo whenever possible.
 
 ## Related docs
 
diff --git a/docs/guides/module-marketplace.md b/docs/guides/module-marketplace.md
index fdafceba..620b2d45 100644
--- a/docs/guides/module-marketplace.md
+++ b/docs/guides/module-marketplace.md
@@ -15,7 +15,7 @@ For the curated official bundle list and trust/dependency quick reference, see
 ## Registry Overview
 
 - **Official registry**: <https://github.com/nold-ai/specfact-cli-modules> (index: `registry/index.json`)
-- **Marketplace module id format**: `namespace/name` (e.g. `specfact/backlog`). Marketplace modules must use this format; flat names are allowed only for custom/local modules with a warning.
+- **Marketplace module id format**: `namespace/name` (e.g. `nold-ai/specfact-backlog`). Marketplace modules must use this format; bare names are accepted only for local normalization and explicit source selection flows.
 - **Custom registries**: You can add private or third-party registries. See [Custom registries](custom-registries.md) for adding, listing, removing, trust levels, and priority.
 
 ## Custom registries and search
@@ -65,7 +65,7 @@ Checksum mismatch blocks installation.
 
 **Namespace enforcement**:
 
-- Modules installed from the marketplace must use the `namespace/name` format (e.g. `specfact/backlog`). Invalid format is rejected.
+- Modules installed from the marketplace must use the `namespace/name` format (for example `nold-ai/specfact-backlog`). Invalid format is rejected.
 - If a module with the same logical name is already installed from a different source or namespace, install reports a collision and suggests using an alias or uninstalling the existing module.
 
 Additional local hardening:
@@ -114,3 +114,6 @@ Scope boundary:
 - Module metadata (publisher, license, trust, origin, compatibility)
 - Full command tree, including subcommands
 - Short command descriptions derived from Typer command registration
+
+> Temporary docs note: marketplace and bundle-specific docs remain hosted in this core docs set
+> for the current release line and are planned to migrate to `specfact-cli-modules`.
diff --git a/docs/guides/module-signing-and-key-rotation.md b/docs/guides/module-signing-and-key-rotation.md
index c27248be..a0e47884 100644
--- a/docs/guides/module-signing-and-key-rotation.md
+++ b/docs/guides/module-signing-and-key-rotation.md
@@ -2,12 +2,15 @@
 layout: default
 title: Module Signing and Key Rotation
 permalink: /guides/module-signing-and-key-rotation/
-description: Runbook for signing bundled modules, placing public keys, rotating keys, and revoking compromised keys.
+description: Runbook for signing official workflow bundles, placing public keys, rotating keys, and revoking compromised keys.
 ---
 
 # Module Signing and Key Rotation
 
-This runbook defines the repeatable process for signing bundled modules and verifying signatures in SpecFact CLI.
+This runbook defines the repeatable process for signing official workflow bundles and verifying signatures in SpecFact CLI.
+
+> Temporary docs note: module signing guidance is still hosted in this core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
 
 ## Key Placement
 
@@ -39,7 +42,7 @@ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out module-signing
 openssl pkey -in module-signing-private.pem -pubout -out module-signing-public.pem
 ```
 
-## Sign Bundled Modules
+## Sign Official Bundles
 
 Preferred (strict, with private key):
 
@@ -49,21 +52,21 @@ Preferred (strict, with private key):
 ```bash
 KEY_FILE="${SPECFACT_MODULE_PRIVATE_SIGN_KEY_FILE:-.specfact/sign-keys/module-signing-private.pem}"
 python scripts/sign-modules.py --key-file "$KEY_FILE" src/specfact_cli/modules/*/module-package.yaml
-python scripts/sign-modules.py --key-file "$KEY_FILE" modules/*/module-package.yaml
+python scripts/sign-modules.py --key-file "$KEY_FILE" packages/*/module-package.yaml
 ```
 
 Encrypted private key options:
 
 ```bash
 # Prompt interactively for passphrase (TTY)
-python scripts/sign-modules.py --key-file "$KEY_FILE" modules/backlog-core/module-package.yaml
+python scripts/sign-modules.py --key-file "$KEY_FILE" packages/specfact-backlog/module-package.yaml
 
 # Explicit passphrase flag (avoid shell history when possible)
-python scripts/sign-modules.py --key-file "$KEY_FILE" --passphrase '***' modules/backlog-core/module-package.yaml
+python scripts/sign-modules.py --key-file "$KEY_FILE" --passphrase '***' packages/specfact-backlog/module-package.yaml
 
 # Passphrase over stdin (CI-safe pattern)
-printf '%s' "$SPECFACT_MODULE_PRIVATE_SIGN_KEY_PASSPHRASE" | \
-  python scripts/sign-modules.py --key-file "$KEY_FILE" --passphrase-stdin modules/backlog-core/module-package.yaml
+  printf '%s' "$SPECFACT_MODULE_PRIVATE_SIGN_KEY_PASSPHRASE" | \
+  python scripts/sign-modules.py --key-file "$KEY_FILE" --passphrase-stdin packages/specfact-backlog/module-package.yaml
 ```
 
 Versioning guard:
@@ -90,16 +93,16 @@ hatch run python scripts/verify-modules-signature.py --require-signature --enfor
 Wrapper for single manifest:
 
 ```bash
-bash scripts/sign-module.sh --key-file "$KEY_FILE" modules/backlog-core/module-package.yaml
+bash scripts/sign-module.sh --key-file "$KEY_FILE" packages/specfact-backlog/module-package.yaml
 # stdin passphrase:
 printf '%s' "$SPECFACT_MODULE_PRIVATE_SIGN_KEY_PASSPHRASE" | \
-  bash scripts/sign-module.sh --key-file "$KEY_FILE" --passphrase-stdin modules/backlog-core/module-package.yaml
+  bash scripts/sign-module.sh --key-file "$KEY_FILE" --passphrase-stdin packages/specfact-backlog/module-package.yaml
 ```
 
 Local test-only unsigned mode:
 
 ```bash
-python scripts/sign-modules.py --allow-unsigned modules/backlog-core/module-package.yaml
+python scripts/sign-modules.py --allow-unsigned packages/specfact-backlog/module-package.yaml
 ```
 
 ## Verify Signatures Locally
@@ -129,7 +132,7 @@ This runs on PR/push for `dev` and `main` and fails the pipeline if module signa
 
 1. Generate new keypair in secure environment.
 2. Replace `resources/keys/module-signing-public.pem` with new public key.
-3. Re-sign all bundled module manifests with the new private key.
+3. Re-sign all official bundle manifests with the new private key.
 4. Run verifier locally: `python scripts/verify-modules-signature.py --require-signature`.
 5. Commit public key + re-signed manifests in one change.
 6. Merge to `dev`, then `main` after CI passes.
@@ -141,7 +144,7 @@ If a private key is compromised:
 1. Treat all signatures from that key as untrusted.
 2. Generate new keypair immediately.
 3. Replace public key file in repo.
-4. Re-sign all bundled modules with new private key.
+4. Re-sign all official bundles with new private key.
 5. Merge emergency fix branch and invalidate prior release artifacts operationally.
 
 Current limitation:
diff --git a/docs/guides/openspec-journey.md b/docs/guides/openspec-journey.md
index 1c03ce46..7cf64125 100644
--- a/docs/guides/openspec-journey.md
+++ b/docs/guides/openspec-journey.md
@@ -144,7 +144,7 @@ Add new feature X to improve user experience.
 EOF
 
 # Step 2: Export to GitHub Issues
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --repo /path/to/openspec-repo
@@ -167,7 +167,7 @@ sequenceDiagram
     participant GH as GitHub Issues
     
     Dev->>OS: Create change proposal<br/>openspec/changes/add-feature-x/
-    Dev->>SF: specfact sync bridge --adapter github
+    Dev->>SF: specfact project sync bridge --adapter github
     SF->>OS: Read proposal.md
     SF->>GH: Create issue from proposal
     GH-->>SF: Issue #123 created
@@ -176,7 +176,7 @@ sequenceDiagram
     Note over Dev,GH: Implementation Phase
     
     Dev->>Dev: Make commits with change ID
-    Dev->>SF: specfact sync bridge --track-code-changes
+    Dev->>SF: specfact project sync bridge --track-code-changes
     SF->>SF: Detect commits mentioning<br/>change ID
     SF->>GH: Add progress comment<br/>to issue #123
     GH-->>Dev: Progress visible in issue
@@ -208,7 +208,7 @@ Read-only sync from OpenSpec to SpecFact for change proposal tracking:
 
 ```bash
 # Sync OpenSpec change proposals to SpecFact
-specfact sync bridge --adapter openspec --mode read-only \
+specfact project sync bridge --adapter openspec --mode read-only \
   --bundle my-project \
   --repo /path/to/openspec-repo
 
@@ -264,7 +264,7 @@ Full bidirectional sync between OpenSpec and SpecFact:
 
 ```bash
 # Bidirectional sync (future)
-specfact sync bridge --adapter openspec --bidirectional \
+specfact project sync bridge --adapter openspec --bidirectional \
   --bundle my-project \
   --repo /path/to/openspec-repo \
   --watch
@@ -312,7 +312,7 @@ Here's how to use both tools together for legacy code modernization:
 
 ```bash
 # Step 1: Analyze legacy code with SpecFact
-specfact import from-code legacy-api --repo ./legacy-app
+specfact project import from-code legacy-api --repo ./legacy-app
 # → Extracts features from existing code
 # → Creates SpecFact bundle: .specfact/projects/legacy-api/
 
@@ -335,7 +335,7 @@ Legacy API needs modernization for better performance and maintainability.
 EOF
 
 # Step 3: Export proposal to GitHub Issues ✅ IMPLEMENTED
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --repo /path/to/openspec-repo
@@ -344,7 +344,7 @@ specfact sync bridge --adapter github --mode export-only \
 git commit -m "feat: modernize-api - refactor endpoints"
 
 # Step 5: Track progress ✅ IMPLEMENTED
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --track-code-changes \
@@ -352,14 +352,14 @@ specfact sync bridge --adapter github --mode export-only \
   --code-repo /path/to/source-code-repo
 
 # Step 6: Sync OpenSpec change proposals ✅ AVAILABLE
-specfact sync bridge --adapter openspec --mode read-only \
+specfact project sync bridge --adapter openspec --mode read-only \
   --bundle legacy-api \
   --repo /path/to/openspec-repo
 # → Generates alignment report
 # → Shows gaps between OpenSpec specs and code
 
 # Step 7: Add runtime contracts
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # Step 8: Archive completed change
 openspec archive modernize-api
diff --git a/docs/guides/policy-engine-commands.md b/docs/guides/policy-engine-commands.md
index eea9a3ab..3c800dfd 100644
--- a/docs/guides/policy-engine-commands.md
+++ b/docs/guides/policy-engine-commands.md
@@ -6,15 +6,19 @@ permalink: /guides/policy-engine-commands/
 
 # Policy Engine Commands
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 Use SpecFact policy commands to scaffold, validate, and improve policy configuration for common frameworks.
 
 ## Overview
 
 The policy engine currently supports:
 
-- `specfact policy init` to scaffold `.specfact/policy.yaml` from a built-in template.
-- `specfact policy validate` to evaluate configured rules deterministically against policy input artifacts.
-- `specfact policy suggest` to generate confidence-scored, patch-ready recommendations (no automatic writes).
+- `specfact backlog policy init` to scaffold `.specfact/policy.yaml` from a built-in template.
+- `specfact backlog policy validate` to evaluate configured rules deterministically against policy input artifacts.
+- `specfact backlog policy suggest` to generate confidence-scored, patch-ready recommendations (no automatic writes).
 
 ## Commands
 
@@ -23,7 +27,7 @@ The policy engine currently supports:
 Create a starter policy configuration file:
 
 ```bash
-specfact policy init --repo . --template scrum
+specfact backlog policy init --repo . --template scrum
 ```
 
 Supported templates:
@@ -36,7 +40,7 @@ Supported templates:
 Interactive mode (template prompt):
 
 ```bash
-specfact policy init --repo .
+specfact backlog policy init --repo .
 ```
 
 The command writes `.specfact/policy.yaml`. Use `--force` to overwrite an existing file.
@@ -46,7 +50,7 @@ The command writes `.specfact/policy.yaml`. Use `--force` to overwrite an existi
 Run policy checks with deterministic output:
 
 ```bash
-specfact policy validate --repo . --format both
+specfact backlog policy validate --repo . --format both
 ```
 
 Artifact resolution order when `--snapshot` is omitted:
@@ -57,20 +61,20 @@ Artifact resolution order when `--snapshot` is omitted:
 You can still override with an explicit path:
 
 ```bash
-specfact policy validate --repo . --snapshot ./snapshot.json --format both
+specfact backlog policy validate --repo . --snapshot ./snapshot.json --format both
 ```
 
 Filter and scope output:
 
 ```bash
 # only one rule family, max 20 findings
-specfact policy validate --repo . --rule scrum.dor --limit 20 --format json
+specfact backlog policy validate --repo . --rule scrum.dor --limit 20 --format json
 
 # item-centric grouped output
-specfact policy validate --repo . --group-by-item --format both
+specfact backlog policy validate --repo . --group-by-item --format both
 
 # in grouped mode, --limit applies to item groups
-specfact policy validate --repo . --group-by-item --limit 4 --format json
+specfact backlog policy validate --repo . --group-by-item --limit 4 --format json
 ```
 
 Output formats:
@@ -86,20 +90,20 @@ When config is missing or invalid, the command prints a docs hint pointing back
 Generate suggestions from validation findings:
 
 ```bash
-specfact policy suggest --repo .
+specfact backlog policy suggest --repo .
 ```
 
 Suggestion shaping options:
 
 ```bash
 # suggestions for one rule family, limited output
-specfact policy suggest --repo . --rule scrum.dod --limit 10
+specfact backlog policy suggest --repo . --rule scrum.dod --limit 10
 
 # grouped suggestions by backlog item index
-specfact policy suggest --repo . --group-by-item
+specfact backlog policy suggest --repo . --group-by-item
 
 # grouped mode limits item groups, not per-item fields
-specfact policy suggest --repo . --group-by-item --limit 4
+specfact backlog policy suggest --repo . --group-by-item --limit 4
 ```
 
 Suggestions include confidence scores and patch-ready structure, but no file is modified automatically.
diff --git a/docs/guides/project-devops-flow.md b/docs/guides/project-devops-flow.md
index 40172103..73a79e68 100644
--- a/docs/guides/project-devops-flow.md
+++ b/docs/guides/project-devops-flow.md
@@ -6,6 +6,10 @@ permalink: /guides/project-devops-flow/
 
 # Project DevOps Flow
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 Use `specfact project devops-flow` to run an integrated lifecycle against a linked backlog provider.
 
 ## Prerequisite
diff --git a/docs/guides/publishing-modules.md b/docs/guides/publishing-modules.md
index 622ab6d1..d09b6811 100644
--- a/docs/guides/publishing-modules.md
+++ b/docs/guides/publishing-modules.md
@@ -7,7 +7,17 @@ description: Package and publish SpecFact modules to a registry (tarball, checks
 
 # Publishing modules
 
-This guide describes how to package a SpecFact module for registry publishing: validate structure, create a tarball and checksum, optionally sign the manifest, and automate via CI.
+This guide describes how to package a SpecFact module for registry publishing: validate structure, create a tarball and checksum, optionally sign the manifest, and automate publishing in the dedicated modules repository.
+
+> Temporary docs note: module publishing guidance is still hosted in this core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
+## Repository ownership
+
+- `specfact-cli` owns the lean runtime, registry, and shared contracts.
+- `specfact-cli-modules` owns official workflow bundle payloads, registry artifacts, and publish automation.
+
+If you are publishing an official bundle, work from `nold-ai/specfact-cli-modules`.
 
 ## Module structure
 
@@ -66,12 +76,28 @@ For runtime verification, sign the manifest so the tarball includes integrity me
 
 ## GitHub Actions workflow
 
-Repository workflow `.github/workflows/publish-modules.yml`:
+Official bundle publishing now runs in `nold-ai/specfact-cli-modules` via
+`.github/workflows/publish-modules.yml`:
+
+- **Triggers**: Push to `dev` and `main`, plus manual `workflow_dispatch`.
+- **Branch behavior**:
+  - Push to `dev` prepares registry updates for the `dev` line.
+  - Push to `main` prepares registry updates for the `main` line.
+  - Protected branches are respected: the workflow opens an automated registry PR instead of pushing directly.
+- **Steps**: Detect changed bundle packages → run `publish-module.py` prechecks → package bundle tarballs → update `registry/index.json` and signatures → open a PR with registry changes when needed.
+
+Optional signing in CI: add repository secrets such as
+`SPECFACT_MODULE_PRIVATE_SIGN_KEY` and `SPECFACT_MODULE_PRIVATE_SIGN_KEY_PASSPHRASE`.
+Signing must happen before publish so the generated registry artifacts contain current integrity
+metadata.
 
-- **Triggers**: Push to tags matching `*-v*` (e.g. `backlog-v0.29.0`) or manual `workflow_dispatch` with input `module_path`.
-- **Steps**: Checkout → resolve module path from tag → optional **Sign module manifest** (when secrets are set) → run `publish-module.py` → upload `dist/*.tar.gz` and `dist/*.sha256` as artifacts.
+## Release flow summary
 
-Optional signing in CI: Add repository secrets `SPECFACT_MODULE_PRIVATE_SIGN_KEY` and `SPECFACT_MODULE_PRIVATE_SIGN_KEY_PASSPHRASE`. The workflow signs the manifest before packaging when the key secret is present.
+1. Bump the changed bundle version in `module-package.yaml`.
+2. Re-sign the changed manifest(s).
+3. Verify signatures locally and in CI.
+4. Merge bundle changes to `dev` or `main` in `specfact-cli-modules`.
+5. Let `publish-modules.yml` prepare the registry update PR for the matching branch line.
 
 ## Best practices
 
diff --git a/docs/guides/sidecar-validation.md b/docs/guides/sidecar-validation.md
index 729e5aa5..9749b54b 100644
--- a/docs/guides/sidecar-validation.md
+++ b/docs/guides/sidecar-validation.md
@@ -6,6 +6,10 @@ permalink: /guides/sidecar-validation/
 
 # Sidecar Validation Guide
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 Complete guide for using sidecar validation to validate external codebases without modifying source code.
 
 ## Overview
@@ -22,13 +26,13 @@ Sidecar validation enables contract-based validation of external codebases (libr
 ### 1. Initialize Sidecar Workspace
 
 ```bash
-specfact validate sidecar init <bundle-name> <repo-path>
+specfact code validate sidecar init <bundle-name> <repo-path>
 ```
 
 **Example:**
 
 ```bash
-specfact validate sidecar init legacy-api /path/to/django-project
+specfact code validate sidecar init legacy-api /path/to/django-project
 ```
 
 This will:
@@ -42,20 +46,20 @@ This will:
 ### 2. Run Validation
 
 ```bash
-specfact validate sidecar run <bundle-name> <repo-path>
+specfact code validate sidecar run <bundle-name> <repo-path>
 ```
 
 **Example:**
 
 ```bash
 # Run full validation (CrossHair + Specmatic)
-specfact validate sidecar run legacy-api /path/to/django-project
+specfact code validate sidecar run legacy-api /path/to/django-project
 
 # Run only CrossHair analysis
-specfact validate sidecar run legacy-api /path/to/django-project --no-run-specmatic
+specfact code validate sidecar run legacy-api /path/to/django-project --no-run-specmatic
 
 # Run only Specmatic validation
-specfact validate sidecar run legacy-api /path/to/django-project --no-run-crosshair
+specfact code validate sidecar run legacy-api /path/to/django-project --no-run-crosshair
 ```
 
 ## Workflow
@@ -122,8 +126,8 @@ Validation tools are executed:
 **Example:**
 
 ```bash
-specfact validate sidecar init django-app /path/to/django-project
-specfact validate sidecar run django-app /path/to/django-project
+specfact code validate sidecar init django-app /path/to/django-project
+specfact code validate sidecar run django-app /path/to/django-project
 ```
 
 ### FastAPI
@@ -141,8 +145,8 @@ specfact validate sidecar run django-app /path/to/django-project
 **Example:**
 
 ```bash
-specfact validate sidecar init fastapi-app /path/to/fastapi-project
-specfact validate sidecar run fastapi-app /path/to/fastapi-project
+specfact code validate sidecar init fastapi-app /path/to/fastapi-project
+specfact code validate sidecar run fastapi-app /path/to/fastapi-project
 ```
 
 ### Django REST Framework (DRF)
@@ -160,8 +164,8 @@ specfact validate sidecar run fastapi-app /path/to/fastapi-project
 **Example:**
 
 ```bash
-specfact validate sidecar init drf-api /path/to/drf-project
-specfact validate sidecar run drf-api /path/to/drf-project
+specfact code validate sidecar init drf-api /path/to/drf-project
+specfact code validate sidecar run drf-api /path/to/drf-project
 ```
 
 ### Flask
@@ -183,8 +187,8 @@ specfact validate sidecar run drf-api /path/to/drf-project
 **Example:**
 
 ```bash
-specfact validate sidecar init flask-app /path/to/flask-project
-specfact validate sidecar run flask-app /path/to/flask-project
+specfact code validate sidecar init flask-app /path/to/flask-project
+specfact code validate sidecar run flask-app /path/to/flask-project
 ```
 
 **Dependency Installation:**
@@ -216,8 +220,8 @@ Flask applications automatically have dependencies installed in an isolated venv
 **Example:**
 
 ```bash
-specfact validate sidecar init python-lib /path/to/python-library
-specfact validate sidecar run python-lib /path/to/python-library
+specfact code validate sidecar init python-lib /path/to/python-library
+specfact code validate sidecar run python-lib /path/to/python-library
 ```
 
 ## Configuration
@@ -302,7 +306,7 @@ You can force Specmatic to run even without service configuration using the `--r
 
 ```bash
 # Force Specmatic to run (may fail if no service available)
-specfact validate sidecar run legacy-api /path/to/repo --run-specmatic
+specfact code validate sidecar run legacy-api /path/to/repo --run-specmatic
 ```
 
 **Configuration:**
@@ -422,13 +426,13 @@ Specmatic requires a service endpoint to test against. If no service configurati
 3. **Re-run with Specmatic enabled**:
 
    ```bash
-   specfact validate sidecar run legacy-api /path/to/repo --run-specmatic
+   specfact code validate sidecar run legacy-api /path/to/repo --run-specmatic
    ```
 
 4. **Skip Specmatic explicitly** (if you only need CrossHair):
 
    ```bash
-   specfact validate sidecar run legacy-api /path/to/repo --no-run-specmatic
+   specfact code validate sidecar run legacy-api /path/to/repo --no-run-specmatic
    ```
 
 ### Module Resolution Errors
@@ -467,23 +471,23 @@ Specmatic requires a service endpoint to test against. If no service configurati
 
 ```bash
 # Initialize
-specfact validate sidecar init django-blog /path/to/django-blog
+specfact code validate sidecar init django-blog /path/to/django-blog
 
 # Run validation
-specfact validate sidecar run django-blog /path/to/django-blog
+specfact code validate sidecar run django-blog /path/to/django-blog
 ```
 
 ### Example 2: FastAPI API
 
 ```bash
 # Initialize
-specfact validate sidecar init fastapi-api /path/to/fastapi-api
+specfact code validate sidecar init fastapi-api /path/to/fastapi-api
 
 # Run only CrossHair (no HTTP endpoints - Specmatic auto-skipped)
-specfact validate sidecar run fastapi-api /path/to/fastapi-api --no-run-specmatic
+specfact code validate sidecar run fastapi-api /path/to/fastapi-api --no-run-specmatic
 
 # Or let auto-skip handle it (Specmatic will be skipped automatically)
-specfact validate sidecar run fastapi-api /path/to/fastapi-api
+specfact code validate sidecar run fastapi-api /path/to/fastapi-api
 ```
 
 **Note**: In this example, Specmatic is automatically skipped because no service configuration is provided. The validation will focus on CrossHair analysis only.
@@ -492,10 +496,10 @@ specfact validate sidecar run fastapi-api /path/to/fastapi-api
 
 ```bash
 # Initialize
-specfact validate sidecar init flask-app /path/to/flask-project
+specfact code validate sidecar init flask-app /path/to/flask-project
 
 # Run validation (dependencies automatically installed in isolated venv)
-specfact validate sidecar run flask-app /path/to/flask-project --no-run-specmatic
+specfact code validate sidecar run flask-app /path/to/flask-project --no-run-specmatic
 ```
 
 **Note**: Flask applications automatically have dependencies installed in `.specfact/venv/` during initialization. All HTTP methods are captured (e.g., routes with `methods=['GET','POST']` generate separate routes for each method).
@@ -504,21 +508,21 @@ specfact validate sidecar run flask-app /path/to/flask-project --no-run-specmati
 
 ```bash
 # Initialize
-specfact validate sidecar init python-lib /path/to/python-library
+specfact code validate sidecar init python-lib /path/to/python-library
 
 # Run validation
-specfact validate sidecar run python-lib /path/to/python-library
+specfact code validate sidecar run python-lib /path/to/python-library
 ```
 
 ## Repro Integration
 
-Sidecar validation can be integrated into the `specfact repro` command for validating unannotated code as part of the reproducibility suite.
+Sidecar validation can be integrated into the `specfact code repro` command for validating unannotated code as part of the reproducibility suite.
 
 ### Using Sidecar with Repro
 
 ```bash
 # Run repro with sidecar validation for unannotated code
-specfact repro --sidecar --sidecar-bundle legacy-api --repo /path/to/repo
+specfact code repro --sidecar --sidecar-bundle legacy-api --repo /path/to/repo
 ```
 
 **What it does:**
@@ -531,7 +535,7 @@ specfact repro --sidecar --sidecar-bundle legacy-api --repo /path/to/repo
 
 **Safe Defaults for Repro Mode:**
 
-When used with `specfact repro --sidecar`, sidecar validation automatically applies safe defaults:
+When used with `specfact code repro --sidecar`, sidecar validation automatically applies safe defaults:
 
 - **CrossHair timeout**: 30 seconds (vs 60 default)
 - **Per-path timeout**: 5 seconds
@@ -542,10 +546,10 @@ When used with `specfact repro --sidecar`, sidecar validation automatically appl
 
 ```bash
 # Initialize sidecar workspace first
-specfact validate sidecar init legacy-api /path/to/repo
+specfact code validate sidecar init legacy-api /path/to/repo
 
 # Then run repro with sidecar validation
-specfact repro --sidecar --sidecar-bundle legacy-api --repo /path/to/repo --verbose
+specfact code repro --sidecar --sidecar-bundle legacy-api --repo /path/to/repo --verbose
 ```
 
 **Output:**
diff --git a/docs/guides/speckit-comparison.md b/docs/guides/speckit-comparison.md
index 12251ad8..afd83085 100644
--- a/docs/guides/speckit-comparison.md
+++ b/docs/guides/speckit-comparison.md
@@ -213,16 +213,16 @@ permalink: /guides/speckit-comparison/
 # (Interactive slash commands in GitHub)
 
 # Step 2: Import Spec-Kit artifacts into SpecFact (via bridge adapter)
-specfact import from-bridge --adapter speckit --repo ./my-project
+specfact project import from-bridge --adapter speckit --repo ./my-project
 
 # Step 3: Add runtime contracts to critical Python paths
 # (SpecFact contract decorators)
 
 # Step 4: Keep both in sync (using adapter registry pattern)
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
 ```
 
-**Note**: SpecFact CLI uses a plugin-based adapter registry pattern. All adapters (Spec-Kit, OpenSpec, GitHub, etc.) are registered in `AdapterRegistry` and accessed via `specfact sync bridge --adapter <adapter-name>`, making the architecture extensible for future tool integrations.
+**Note**: SpecFact CLI uses a plugin-based adapter registry pattern. All adapters (Spec-Kit, OpenSpec, GitHub, etc.) are registered in `AdapterRegistry` and accessed via `specfact project sync bridge --adapter <adapter-name>`, making the architecture extensible for future tool integrations.
 
 ---
 
@@ -294,14 +294,14 @@ Use both together for best results.
 - **GitHub Issues** - Export change proposals to DevOps backlogs
 - **Future**: Linear, Jira, Azure DevOps, and more
 
-All adapters are registered in `AdapterRegistry` and accessed via `specfact sync bridge --adapter <adapter-name>`, making the architecture extensible for future tool integrations.
+All adapters are registered in `AdapterRegistry` and accessed via `specfact project sync bridge --adapter <adapter-name>`, making the architecture extensible for future tool integrations.
 
 ### Can I migrate from Spec-Kit to SpecFact?
 
 **Yes.** SpecFact can import Spec-Kit artifacts:
 
 ```bash
-specfact import from-bridge --adapter speckit --repo ./my-project
+specfact project import from-bridge --adapter speckit --repo ./my-project
 ```
 
 You can also keep using both tools with bidirectional sync via the adapter registry pattern.
@@ -312,7 +312,7 @@ You can also keep using both tools with bidirectional sync via the adapter regis
 
 ```bash
 # Read-only sync from OpenSpec to SpecFact
-specfact sync bridge --adapter openspec --mode read-only \
+specfact project sync bridge --adapter openspec --mode read-only \
   --bundle my-project \
   --repo /path/to/openspec-repo
 ```
diff --git a/docs/guides/speckit-journey.md b/docs/guides/speckit-journey.md
index 53acacfb..4d3244d8 100644
--- a/docs/guides/speckit-journey.md
+++ b/docs/guides/speckit-journey.md
@@ -79,7 +79,7 @@ When modernizing legacy code, you can use **both tools together** for maximum va
 
 ```bash
 # Step 1: Use SpecFact to extract specs from legacy code
-specfact import from-code customer-portal --repo ./legacy-app
+specfact project import from-code customer-portal --repo ./legacy-app
 
 # Output: Auto-generated project bundle from existing code
 # ✅ Analyzed 47 Python files
@@ -99,7 +99,7 @@ specfact import from-code customer-portal --repo ./legacy-app
 # Refactor knowing contracts will catch regressions
 
 # Step 5: Keep both in sync
-specfact sync bridge --adapter speckit --bundle customer-portal --repo . --bidirectional --watch
+specfact project sync bridge --adapter speckit --bundle customer-portal --repo . --bidirectional --watch
 ```
 
 ### **Why This Works**
@@ -155,13 +155,13 @@ Import your Spec-Kit project to see what SpecFact adds:
 
 ```bash
 # 1. Preview what will be imported
-specfact import from-bridge --adapter speckit --repo ./my-speckit-project --dry-run
+specfact project import from-bridge --adapter speckit --repo ./my-speckit-project --dry-run
 
 # 2. Execute import (one command) - bundle name will be auto-detected or you can specify with --bundle
-specfact import from-bridge --adapter speckit --repo ./my-speckit-project --write
+specfact project import from-bridge --adapter speckit --repo ./my-speckit-project --write
 
 # 3. Review generated bundle using CLI commands
-specfact plan review <bundle-name>
+specfact project plan review <bundle-name>
 ```
 
 **What was created**:
@@ -191,7 +191,7 @@ Keep using Spec-Kit interactively, sync automatically with SpecFact:
 
 ```bash
 # Enable bidirectional sync (bridge-based, adapter-agnostic)
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
 ```
 
 **Workflow**:
@@ -209,13 +209,13 @@ specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirec
 # → Enables shared plans for team collaboration
 
 # 3. Detect code vs plan drift automatically
-specfact plan compare --code-vs-plan
+specfact project plan compare --code-vs-plan
 # → Compares intended design (manual plan = what you planned) vs actual implementation (code-derived plan = what's in your code)
 # → Identifies deviations automatically (not just artifact consistency like Spec-Kit's /speckit.analyze)
 # → Auto-derived plans come from `import from-code` (code analysis), so comparison IS "code vs plan drift"
 
 # 4. Enable automated enforcement
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # 5. CI/CD automatically validates (GitHub Action)
 # → Runs on every PR
@@ -244,10 +244,10 @@ specfact enforce stage --preset balanced
 
 ```bash
 # Import existing Spec-Kit project
-specfact import from-bridge --adapter speckit --repo . --write
+specfact project import from-bridge --adapter speckit --repo . --write
 
 # Enable bidirectional sync (bridge-based, adapter-agnostic)
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
 ```
 
 **Result**: Both tools working together seamlessly.
@@ -256,16 +256,16 @@ specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirec
 
 ```bash
 # Start in shadow mode (observe only)
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 
 # Set up CrossHair for contract exploration
-specfact repro setup
+specfact code repro setup
 
 # Review what would be blocked
-specfact repro --verbose
+specfact code repro --verbose
 
 # Apply auto-fixes for violations (if available)
-specfact repro --fix --verbose
+specfact code repro --fix --verbose
 ```
 
 **Result**: See what SpecFact would catch, no blocking yet. Auto-fixes can be applied for Semgrep violations.
@@ -274,15 +274,15 @@ specfact repro --fix --verbose
 
 ```bash
 # Enable balanced mode (block HIGH, warn MEDIUM)
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # Test with real PR
 git checkout -b test-enforcement
 # Make a change that violates contracts
-specfact repro  # Should block HIGH issues
+specfact code repro  # Should block HIGH issues
 
 # Or apply auto-fixes first
-specfact repro --fix  # Apply Semgrep auto-fixes, then validate
+specfact code repro --fix  # Apply Semgrep auto-fixes, then validate
 ```
 
 **Result**: Automated enforcement catching critical issues. Auto-fixes can be applied before validation.
@@ -291,11 +291,11 @@ specfact repro --fix  # Apply Semgrep auto-fixes, then validate
 
 ```bash
 # Enable strict enforcement
-specfact enforce stage --preset strict
+specfact govern enforce stage --preset strict
 
 # Full automation (CI/CD, brownfield analysis, etc.)
 # (CrossHair setup already done in Week 3)
-specfact repro --budget 120 --verbose
+specfact code repro --budget 120 --verbose
 ```
 
 **Result**: Complete SpecFact workflow - or keep using both tools together!
@@ -308,7 +308,7 @@ specfact repro --budget 120 --verbose
 
 ```bash
 # See what will be imported (safe - no changes)
-specfact import from-bridge --adapter speckit --repo ./my-speckit-project --dry-run
+specfact project import from-bridge --adapter speckit --repo ./my-speckit-project --dry-run
 ```
 
 **Expected Output**:
@@ -321,7 +321,7 @@ specfact import from-bridge --adapter speckit --repo ./my-speckit-project --dry-
 ✅ Found specs/001-user-authentication/tasks.md
 ✅ Found .specify/memory/constitution.md
 
-**💡 Tip**: If constitution is missing or minimal, run `specfact sdd constitution bootstrap --repo .` to auto-generate from repository analysis.
+**💡 Tip**: If constitution is missing or minimal, run `specfact spec sdd constitution bootstrap --repo .` to auto-generate from repository analysis.
 
 📊 Migration Preview:
   - Will create: .specfact/projects/<bundle-name>/ (modular project bundle)
@@ -337,7 +337,7 @@ specfact import from-bridge --adapter speckit --repo ./my-speckit-project --dry-
 
 ```bash
 # Execute migration (creates SpecFact artifacts)
-specfact import from-bridge \
+specfact project import from-bridge \
   --adapter speckit \
   --repo ./my-speckit-project \
   --write \
@@ -365,10 +365,10 @@ specfact import from-bridge \
 
 ```bash
 # Review plan bundle using CLI commands
-specfact plan review <bundle-name>
+specfact project plan review <bundle-name>
 
 # Review enforcement config using CLI commands
-specfact enforce show-config
+specfact govern enforce show-config
 
 # Review migration report
 cat migration-report.md
@@ -389,10 +389,10 @@ cat migration-report.md
 
 ```bash
 # One-time sync
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
 
 # Continuous watch mode (recommended for team collaboration)
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
 ```
 
 **What it syncs**:
@@ -409,23 +409,23 @@ specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirec
 
 ```bash
 # Week 1-2: Shadow mode (observe only)
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 
 # Week 3-4: Balanced mode (block HIGH, warn MEDIUM)
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # Week 5+: Strict mode (block MEDIUM+)
-specfact enforce stage --preset strict
+specfact govern enforce stage --preset strict
 ```
 
 ### **Step 6: Validate**
 
 ```bash
 # Set up CrossHair for contract exploration (one-time setup)
-specfact repro setup
+specfact code repro setup
 
 # Run all checks
-specfact repro --verbose
+specfact code repro --verbose
 
 # Check CI/CD integration
 git push origin feat/specfact-migration
@@ -441,8 +441,8 @@ git push origin feat/specfact-migration
 
 ```bash
 # Always start with shadow mode (no blocking)
-specfact enforce stage --preset minimal
-specfact repro
+specfact govern enforce stage --preset minimal
+specfact code repro
 ```
 
 **Why**: See what SpecFact would catch before enabling blocking.
@@ -451,7 +451,7 @@ specfact repro
 
 ```bash
 # Enable bidirectional sync for team collaboration
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch
 ```
 
 **Why**: **Shared structured plans** enable team collaboration with automated bidirectional sync. Unlike Spec-Kit's manual markdown sharing, SpecFact automatically keeps plans synchronized across team members. Continue using Spec-Kit interactively, get SpecFact automation automatically.
@@ -460,13 +460,13 @@ specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirec
 
 ```bash
 # Week 1: Shadow (observe)
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 
 # Week 2-3: Balanced (block HIGH)
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # Week 4+: Strict (block MEDIUM+)
-specfact enforce stage --preset strict
+specfact govern enforce stage --preset strict
 ```
 
 **Why**: Gradual adoption reduces disruption and builds team confidence.
@@ -537,10 +537,10 @@ specfact enforce stage --preset strict
 
 **Next Steps**:
 
-1. **Try it**: `specfact import from-bridge --adapter speckit --repo . --dry-run`
-2. **Import**: `specfact import from-bridge --adapter speckit --repo . --write`
-3. **Sync**: `specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch`
-4. **Enforce**: `specfact enforce stage --preset minimal` (start shadow mode)
+1. **Try it**: `specfact project import from-bridge --adapter speckit --repo . --dry-run`
+2. **Import**: `specfact project import from-bridge --adapter speckit --repo . --write`
+3. **Sync**: `specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch`
+4. **Enforce**: `specfact govern enforce stage --preset minimal` (start shadow mode)
 
 ---
 
diff --git a/docs/guides/specmatic-integration.md b/docs/guides/specmatic-integration.md
index 346d0170..d49d7d8f 100644
--- a/docs/guides/specmatic-integration.md
+++ b/docs/guides/specmatic-integration.md
@@ -115,7 +115,7 @@ specfact spec validate --bundle legacy-api
 specfact spec validate --bundle legacy-api --no-interactive
 ```
 
-**CLI-First Pattern**: The command uses the active plan (from `specfact plan select`) as default, or you can specify `--bundle`. Never requires direct `.specfact` paths - always use the CLI interface.
+**CLI-First Pattern**: The command uses the active plan (from `specfact project plan select`) as default, or you can specify `--bundle`. Never requires direct `.specfact` paths - always use the CLI interface.
 
 **What it checks:**
 
@@ -248,7 +248,7 @@ Here's a full workflow from contract to tested implementation:
 
 ```bash
 # 1. Import existing code and extract contracts
-specfact import from-code user-api --repo .
+specfact project import from-code user-api --repo .
 
 # 2. Validate contracts are correct
 specfact spec validate --bundle user-api
@@ -422,7 +422,7 @@ When importing code, SpecFact auto-detects and validates OpenAPI/AsyncAPI specs:
 
 ```bash
 # Import with bundle (uses active plan if --bundle not specified)
-specfact import from-code legacy-api --repo .
+specfact project import from-code legacy-api --repo .
 
 # Automatically validates:
 # - Repo-level OpenAPI/AsyncAPI specs (openapi.yaml, asyncapi.yaml)
@@ -436,7 +436,7 @@ SDD enforcement includes Specmatic validation for all contracts referenced in th
 
 ```bash
 # Enforce SDD (uses active plan if --bundle not specified)
-specfact enforce sdd --bundle legacy-api
+specfact govern enforce sdd --bundle legacy-api
 
 # Automatically validates:
 # - All contract files referenced in bundle features
@@ -450,7 +450,7 @@ Repository sync validates specs before synchronization:
 
 ```bash
 # Sync bridge (uses active plan if --bundle not specified)
-specfact sync bridge --bundle legacy-api --repo .
+specfact project sync bridge --bundle legacy-api --repo .
 
 # Automatically validates:
 # - OpenAPI/AsyncAPI specs before sync operation
@@ -500,7 +500,7 @@ SpecFact calls Specmatic via subprocess:
 
 ```bash
 # Project has openapi.yaml
-specfact import from-code api-service --repo .
+specfact project import from-code api-service --repo .
 
 # Output:
 # ✓ Import complete!
@@ -528,7 +528,7 @@ specfact spec backward-compat api/v1/openapi.yaml api/v2/openapi.yaml
 
 ```bash
 # 1. Set active bundle
-specfact plan select api-service
+specfact project plan select api-service
 
 # 2. Validate all contracts in bundle (interactive selection)
 specfact spec validate
diff --git a/docs/guides/testing-terminal-output.md b/docs/guides/testing-terminal-output.md
index e1cdbcaa..e68b7cb4 100644
--- a/docs/guides/testing-terminal-output.md
+++ b/docs/guides/testing-terminal-output.md
@@ -20,7 +20,7 @@ NO_COLOR=1 specfact --help
 
 # Or export for the entire session
 export NO_COLOR=1
-specfact import from-code my-bundle
+specfact project import from-code my-bundle
 unset NO_COLOR  # Re-enable colors
 ```
 
@@ -33,7 +33,7 @@ Simulate a CI/CD pipeline (BASIC mode):
 CI=true specfact --help
 
 # Or simulate GitHub Actions
-GITHUB_ACTIONS=true specfact import from-code my-bundle
+GITHUB_ACTIONS=true specfact project import from-code my-bundle
 ```
 
 ### Method 3: Use Dumb Terminal Type
diff --git a/docs/guides/troubleshooting.md b/docs/guides/troubleshooting.md
index f8d53faf..6c48399d 100644
--- a/docs/guides/troubleshooting.md
+++ b/docs/guides/troubleshooting.md
@@ -30,7 +30,7 @@ Common issues and solutions for SpecFact CLI.
 
 ## Plan Select Command is Slow
 
-**Symptom**: `specfact plan select` takes a long time (5+ seconds) to list plans.
+**Symptom**: `specfact project plan select` takes a long time (5+ seconds) to list plans.
 
 **Cause**: Plan bundles may be missing summary metadata (older schema version 1.0).
 
@@ -38,10 +38,10 @@ Common issues and solutions for SpecFact CLI.
 
 ```bash
 # Upgrade all plan bundles to latest schema (adds summary metadata)
-specfact plan upgrade --all
+specfact project plan upgrade --all
 
 # Verify upgrade worked
-specfact plan select --last 5
+specfact project plan select --last 5
 ```
 
 **Performance Improvement**: After upgrade, `plan select` is 44% faster (3.6s vs 6.5s) and scales better with large plan bundles.
@@ -103,7 +103,7 @@ specfact plan select --last 5
 3. **Use explicit path**:
 
    ```bash
-   specfact import from-bridge --adapter speckit --repo /path/to/speckit-project
+   specfact project import from-bridge --adapter speckit --repo /path/to/speckit-project
    ```
 
 ### Code Analysis Fails (Brownfield) ⭐
@@ -115,13 +115,13 @@ specfact plan select --last 5
 1. **Check repository path**:
 
    ```bash
-   specfact import from-code legacy-api --repo . --verbose
+   specfact project import from-code legacy-api --repo . --verbose
    ```
 
 2. **Lower confidence threshold** (for legacy code with less structure):
 
    ```bash
-   specfact import from-code legacy-api --repo . --confidence 0.3
+   specfact project import from-code legacy-api --repo . --confidence 0.3
    ```
 
 3. **Check file structure**:
@@ -139,7 +139,7 @@ specfact plan select --last 5
 5. **For legacy codebases**, start with minimal confidence and review extracted features:
 
    ```bash
-   specfact import from-code legacy-api --repo . --confidence 0.2
+   specfact project import from-code legacy-api --repo . --confidence 0.2
    ```
 
 ---
@@ -155,7 +155,7 @@ specfact plan select --last 5
 1. **Check repository path**:
 
    ```bash
-   specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --watch --interval 5 --verbose
+   specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --watch --interval 5 --verbose
    ```
 
 2. **Verify directory exists**:
@@ -174,7 +174,7 @@ specfact plan select --last 5
 4. **Try one-time sync first**:
 
    ```bash
-   specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
+   specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
    ```
 
 ### Bidirectional Sync Conflicts
@@ -199,7 +199,7 @@ specfact plan select --last 5
 
    ```bash
    # Spec-Kit → SpecFact only
-   specfact sync bridge --adapter speckit --bundle <bundle-name> --repo .
+   specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo .
 
    # SpecFact → Spec-Kit only (manual)
    # Edit Spec-Kit files manually
@@ -218,19 +218,19 @@ specfact plan select --last 5
 1. **Check enforcement configuration** (use CLI commands):
 
    ```bash
-   specfact enforce show-config
+   specfact govern enforce show-config
    ```
 
 2. **Verify enforcement mode**:
 
    ```bash
-   specfact enforce stage --preset balanced
+   specfact govern enforce stage --preset balanced
    ```
 
 3. **Run validation**:
 
    ```bash
-   specfact repro --verbose
+   specfact code repro --verbose
    ```
 
 4. **Check severity levels**:
@@ -248,25 +248,25 @@ specfact plan select --last 5
 1. **Review violation details**:
 
    ```bash
-   specfact repro --verbose
+   specfact code repro --verbose
    ```
 
 2. **Adjust confidence threshold**:
 
    ```bash
-   specfact import from-code legacy-api --repo . --confidence 0.7
+   specfact project import from-code legacy-api --repo . --confidence 0.7
    ```
 
 3. **Check enforcement rules** (use CLI commands):
 
    ```bash
-   specfact enforce show-config
+   specfact govern enforce show-config
    ```
 
 4. **Use minimal mode** (observe only):
 
    ```bash
-   specfact enforce stage --preset minimal
+   specfact govern enforce stage --preset minimal
    ```
 
 ---
@@ -282,7 +282,7 @@ specfact plan select --last 5
 1. **Auto-generate bootstrap constitution** (recommended for brownfield):
 
    ```bash
-   specfact sdd constitution bootstrap --repo .
+   specfact spec sdd constitution bootstrap --repo .
    ```
 
    This analyzes your repository (README.md, pyproject.toml, .cursor/rules/, docs/rules/) and generates a bootstrap constitution.
@@ -290,7 +290,7 @@ specfact plan select --last 5
 2. **Enrich existing minimal constitution**:
 
    ```bash
-   specfact sdd constitution enrich --repo .
+   specfact spec sdd constitution enrich --repo .
    ```
 
    This fills placeholders in an existing constitution with repository context.
@@ -298,7 +298,7 @@ specfact plan select --last 5
 3. **Validate constitution completeness**:
 
    ```bash
-   specfact sdd constitution validate
+   specfact spec sdd constitution validate
    ```
 
    This checks if the constitution is complete and ready for use.
@@ -316,7 +316,7 @@ specfact plan select --last 5
 
 ### Constitution Validation Fails
 
-**Issue**: `specfact sdd constitution validate` reports issues
+**Issue**: `specfact spec sdd constitution validate` reports issues
 
 **Solutions**:
 
@@ -329,13 +329,13 @@ specfact plan select --last 5
 2. **Run enrichment**:
 
    ```bash
-   specfact sdd constitution enrich --repo .
+   specfact spec sdd constitution enrich --repo .
    ```
 
 3. **Review validation output**:
 
    ```bash
-   specfact sdd constitution validate --constitution .specify/memory/constitution.md
+   specfact spec sdd constitution validate --constitution .specify/memory/constitution.md
    ```
 
    The output will list specific issues (missing sections, placeholders, etc.).
@@ -343,7 +343,7 @@ specfact plan select --last 5
 4. **Fix issues manually** or re-run bootstrap:
 
    ```bash
-   specfact sdd constitution bootstrap --repo . --overwrite
+   specfact spec sdd constitution bootstrap --repo . --overwrite
    ```
 
 ---
@@ -366,7 +366,7 @@ specfact plan select --last 5
 2. **Use explicit paths** (bundle directory paths):
 
    ```bash
-   specfact plan compare \
+   specfact project plan compare \
      --manual .specfact/projects/manual-plan \
      --auto .specfact/projects/auto-derived
    ```
@@ -374,7 +374,7 @@ specfact plan select --last 5
 3. **Generate auto-derived plan first**:
 
    ```bash
-   specfact import from-code legacy-api --repo .
+   specfact project import from-code legacy-api --repo .
    ```
 
 ### No Deviations Found (Expected Some)
@@ -391,13 +391,13 @@ specfact plan select --last 5
 2. **Verify plan contents** (use CLI commands):
 
    ```bash
-   specfact plan review <bundle-name>
+   specfact project plan review <bundle-name>
    ```
 
 3. **Use verbose mode**:
 
    ```bash
-   specfact plan compare --bundle legacy-api --verbose
+   specfact project plan compare --bundle legacy-api --verbose
    ```
 
 ---
@@ -481,7 +481,7 @@ specfact plan select --last 5
 
    ```bash
    export SPECFACT_MODE=copilot
-   specfact import from-code legacy-api --repo .
+   specfact project import from-code legacy-api --repo .
    ```
 
 4. **See [Operational Modes](../reference/modes.md)** for details
@@ -505,14 +505,14 @@ specfact plan select --last 5
 2. **Increase confidence threshold** (fewer features):
 
    ```bash
-   specfact import from-code legacy-api --repo . --confidence 0.8
+   specfact project import from-code legacy-api --repo . --confidence 0.8
    ```
 
 3. **Exclude directories**:
 
    ```bash
    # Use .gitignore or exclude patterns
-   specfact import from-code legacy-api --repo . --exclude "tests/"
+   specfact project import from-code legacy-api --repo . --exclude "tests/"
    ```
 
 ### Watch Mode High CPU
@@ -524,13 +524,13 @@ specfact plan select --last 5
 1. **Increase interval**:
 
    ```bash
-   specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --watch --interval 10
+   specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --watch --interval 10
    ```
 
 2. **Use one-time sync**:
 
    ```bash
-   specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
+   specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
    ```
 
 3. **Check file system events**:
@@ -588,17 +588,17 @@ You can override auto-detection using standard environment variables:
 
 ```bash
 # Auto-detection (default behavior)
-specfact import from-code my-bundle
+specfact project import from-code my-bundle
 # → Automatically detects terminal and uses appropriate mode
 
 # Manual override: Disable colors
-NO_COLOR=1 specfact import from-code my-bundle
+NO_COLOR=1 specfact project import from-code my-bundle
 
 # Manual override: Force colors in CI/CD
-FORCE_COLOR=1 specfact sync bridge
+FORCE_COLOR=1 specfact project sync bridge
 
 # Manual override: Explicit CI/CD mode
-CI=true specfact import from-code my-bundle
+CI=true specfact project import from-code my-bundle
 ```
 
 ### No Progress Visible in Embedded Terminals
@@ -631,7 +631,7 @@ CI=true specfact import from-code my-bundle
 
    ```bash
    # Force basic mode
-   CI=true specfact import from-code my-bundle
+   CI=true specfact project import from-code my-bundle
    ```
 
 ### Colors Not Working in CI/CD
@@ -643,7 +643,7 @@ CI=true specfact import from-code my-bundle
 **Solution**: This is expected behavior. CI/CD logs are more readable without colors. To force colors:
 
 ```bash
-FORCE_COLOR=1 specfact import from-code my-bundle
+FORCE_COLOR=1 specfact project import from-code my-bundle
 ```
 
 ---
@@ -811,7 +811,7 @@ When a PR or push runs the **PR Orchestrator** workflow, test and repro output a
    | `type-check-logs`    | Type Checking (basedpyright) | Full basedpyright type-check output.                              |
    | `lint-logs`          | Linting (ruff, pylint) | Full lint run output.                                                   |
    | `quality-gates-logs`| Quality Gates (Advisory) | Coverage percentage and advisory message.                          |
-   | `repro-logs`         | Contract-First CI | Full stdout/stderr of `specfact repro` (`logs/repro/`).                   |
+   | `repro-logs`         | Contract-First CI | Full stdout/stderr of `specfact code repro` (`logs/repro/`).                   |
    | `repro-reports`      | Contract-First CI | Repro report YAMLs from `.specfact/reports/enforcement/`.                |
 
 3. **How to use them**
@@ -833,7 +833,7 @@ If you're still experiencing issues:
 
    ```bash
    specfact --debug <command> <args>   # Writes to ~/.specfact/logs/specfact-debug.log
-   specfact repro --verbose 2>&1 | tee debug.log
+   specfact code repro --verbose 2>&1 | tee debug.log
    ```
 
 2. **Search documentation**:
diff --git a/docs/guides/use-cases.md b/docs/guides/use-cases.md
index e4c6cb16..b2db5bd7 100644
--- a/docs/guides/use-cases.md
+++ b/docs/guides/use-cases.md
@@ -29,14 +29,14 @@ Detailed use cases and examples for SpecFact CLI.
 
 ```bash
 # CI/CD mode (fast, deterministic) - Full repository
-specfact import from-code \
+specfact project import from-code \
   --repo . \
   --shadow-only \
   --confidence 0.7 \
   --report analysis.md
 
 # Partial analysis (large codebases or monorepos)
-specfact import from-code \
+specfact project import from-code \
   --repo . \
   --entry-point src/core \
   --confidence 0.7 \
@@ -105,10 +105,10 @@ Keep plan artifacts updated as code changes:
 
 ```bash
 # One-time sync
-specfact sync repository --repo . --target .specfact
+specfact project sync repository --repo . --target .specfact
 
 # Continuous watch mode
-specfact sync repository --repo . --watch --interval 5
+specfact project sync repository --repo . --watch --interval 5
 ```
 
 **What it tracks:**
@@ -120,7 +120,7 @@ specfact sync repository --repo . --watch --interval 5
 #### 4. Compare with Manual Plan (if exists)
 
 ```bash
-specfact plan compare \
+specfact project plan compare \
   --manual .specfact/projects/manual-plan \
   --auto .specfact/projects/auto-derived \
   --output-format markdown \
@@ -180,13 +180,13 @@ Focus on:
 
 ```bash
 # Week 1-2: Shadow mode (observe)
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 
 # Week 3-4: Balanced mode (warn on medium, block high)
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # Week 5+: Strict mode (block medium+)
-specfact enforce stage --preset strict
+specfact govern enforce stage --preset strict
 ```
 
 ### Expected Timeline (Brownfield Modernization)
@@ -210,7 +210,7 @@ specfact enforce stage --preset strict
 #### 1. Preview Migration
 
 ```bash
-specfact import from-bridge --adapter speckit --repo ./spec-kit-project --dry-run
+specfact project import from-bridge --adapter speckit --repo ./spec-kit-project --dry-run
 ```
 
 **Expected Output:**
@@ -236,7 +236,7 @@ specfact import from-bridge --adapter speckit --repo ./spec-kit-project --dry-ru
 #### 2. Execute Migration
 
 ```bash
-specfact import from-bridge \
+specfact project import from-bridge \
   --adapter speckit \
   --repo ./spec-kit-project \
   --write \
@@ -247,7 +247,7 @@ specfact import from-bridge \
 
 ```bash
 # Review using CLI commands
-specfact plan review <bundle-name>
+specfact project plan review <bundle-name>
 ```
 
 Review:
@@ -264,13 +264,13 @@ Before syncing, ensure you have a valid constitution:
 
 ```bash
 # Auto-generate from repository analysis (recommended for brownfield)
-specfact sdd constitution bootstrap --repo .
+specfact spec sdd constitution bootstrap --repo .
 
 # Validate completeness
-specfact sdd constitution validate
+specfact spec sdd constitution validate
 
 # Or enrich existing minimal constitution
-specfact sdd constitution enrich --repo .
+specfact spec sdd constitution enrich --repo .
 ```
 
 **Note**: The `sync bridge --adapter speckit` command will detect if the constitution is missing or minimal and suggest bootstrap automatically.
@@ -281,10 +281,10 @@ Keep Spec-Kit and SpecFact synchronized:
 
 ```bash
 # One-time bidirectional sync
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
 
 # Continuous watch mode
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
 ```
 
 **What it syncs:**
@@ -299,23 +299,23 @@ specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirec
 
 ```bash
 # Start in shadow mode (observe only)
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 
 # After stabilization, enable warnings
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # For production, enable strict mode
-specfact enforce stage --preset strict
+specfact govern enforce stage --preset strict
 ```
 
 #### 7. Validate
 
 ```bash
 # First-time setup: Configure CrossHair for contract exploration
-specfact repro setup
+specfact code repro setup
 
 # Run validation
-specfact repro --verbose
+specfact code repro --verbose
 ```
 
 ### Expected Timeline (Spec-Kit Migration)
@@ -340,7 +340,7 @@ specfact repro --verbose
 
 ```bash
 # Standard interactive mode
-specfact plan init --interactive
+specfact project plan init --interactive
 
 # CoPilot mode (enhanced prompts)
 specfact --mode copilot plan init --interactive
@@ -381,7 +381,7 @@ What are the release objectives? (comma-separated)
 
 ```bash
 # Add feature
-specfact plan add-feature \
+specfact project plan add-feature \
   --key FEATURE-001 \
   --title "WebSocket Server" \
   --outcomes "Handle 1000 concurrent connections" \
@@ -389,7 +389,7 @@ specfact plan add-feature \
   --acceptance "Given client connection, When message sent, Then delivered within 100ms"
 
 # Add story
-specfact plan add-story \
+specfact project plan add-story \
   --feature FEATURE-001 \
   --key STORY-001 \
   --title "Connection handling" \
@@ -439,20 +439,20 @@ transitions:
 #### 4. Enable Strict Enforcement
 
 ```bash
-specfact enforce stage --preset strict
+specfact govern enforce stage --preset strict
 ```
 
 #### 5. Validate Continuously
 
 ```bash
 # First-time setup: Configure CrossHair for contract exploration
-specfact repro setup
+specfact code repro setup
 
 # During development
-specfact repro
+specfact code repro
 
 # In CI/CD
-specfact repro --budget 120 --verbose
+specfact code repro --budget 120 --verbose
 ```
 
 ### Expected Timeline (Greenfield Development)
@@ -516,10 +516,10 @@ jobs:
         run: pip install specfact-cli
 
       - name: Set up CrossHair Configuration
-        run: specfact repro setup
+        run: specfact code repro setup
 
       - name: Run Contract Validation
-        run: specfact repro --verbose --budget 90
+        run: specfact code repro --verbose --budget 90
 
       - name: Generate PR Comment
         if: github.event_name == 'pull_request'
@@ -562,15 +562,15 @@ analysis:
 
 ```bash
 # Before pushing
-specfact repro --verbose
+specfact code repro --verbose
 
 # Apply auto-fixes for violations
-specfact repro --fix --verbose
+specfact code repro --fix --verbose
 
 # If issues found
-specfact enforce stage --preset minimal  # Temporarily allow
+specfact govern enforce stage --preset minimal  # Temporarily allow
 # Fix issues
-specfact enforce stage --preset balanced  # Re-enable
+specfact govern enforce stage --preset balanced  # Re-enable
 ```
 
 #### 4. Monitor PR Checks
@@ -605,10 +605,10 @@ In a shared repository:
 
 ```bash
 # Create shared plan
-specfact plan init --interactive
+specfact project plan init --interactive
 
 # Add common features
-specfact plan add-feature \
+specfact project plan add-feature \
   --key FEATURE-COMMON-001 \
   --title "API Standards" \
   --outcomes "Consistent REST patterns" \
@@ -629,7 +629,7 @@ cp ../shared-contracts/plan.bundle.yaml contracts/shared/
 
 ```bash
 # In each service
-specfact plan compare \
+specfact project plan compare \
   --manual contracts/shared/plan.bundle.yaml \
   --auto contracts/service/plan.bundle.yaml \
   --output-format markdown
@@ -639,11 +639,11 @@ specfact plan compare \
 
 ```bash
 # First-time setup: Configure CrossHair for contract exploration
-specfact repro setup
+specfact code repro setup
 
 # Add to CI
-specfact repro
-specfact plan compare --manual contracts/shared/plan.bundle.yaml --auto .
+specfact code repro
+specfact project plan compare --manual contracts/shared/plan.bundle.yaml --auto .
 ```
 
 ### Expected Benefits
diff --git a/docs/guides/using-module-security-and-extensions.md b/docs/guides/using-module-security-and-extensions.md
index 7b941da2..5f32844c 100644
--- a/docs/guides/using-module-security-and-extensions.md
+++ b/docs/guides/using-module-security-and-extensions.md
@@ -64,7 +64,7 @@ You don’t run a separate “verify” command; verification happens automatica
 
    ```yaml
    module_dependencies_versioned:
-     - name: backlog-core
+     - name: nold-ai/specfact-backlog
        version_specifier: ">=0.2.0"
    pip_dependencies_versioned:
      - name: requests
@@ -90,7 +90,7 @@ Several commands already read or write extension data on `ProjectBundle` (and it
   specfact project health-check --bundle my-bundle
   ```
 
-Any command that loads a bundle (e.g. `specfact plan ...`, `specfact sync ...`, `specfact spec ...`) loads the full bundle including `extensions`; round-trip save keeps extension data. So you don’t need a special “extensions” command to benefit from them—they’re part of the bundle.
+Any command that loads a bundle (e.g. `specfact project plan ...`, `specfact project sync ...`, `specfact spec ...`) loads the full bundle including `extensions`; round-trip save keeps extension data. So you don’t need a special “extensions” command to benefit from them—they’re part of the bundle.
 
 **Introspecting registered extensions (programmatic):** There is no `specfact extensions list` CLI yet. From Python you can call:
 
diff --git a/docs/guides/ux-features.md b/docs/guides/ux-features.md
index 3d0cd467..5544dc2a 100644
--- a/docs/guides/ux-features.md
+++ b/docs/guides/ux-features.md
@@ -17,7 +17,7 @@ SpecFact CLI uses progressive disclosure to show the most important options firs
 By default, `--help` shows only the most commonly used options:
 
 ```bash
-specfact import from-code --help
+specfact project import from-code --help
 ```
 
 This displays:
@@ -32,7 +32,7 @@ This displays:
 To see all options including advanced configuration, use `--help-advanced` (alias: `-ha`):
 
 ```bash
-specfact import from-code --help-advanced
+specfact project import from-code --help-advanced
 ```
 
 This reveals:
@@ -88,10 +88,10 @@ The following options are hidden by default across commands:
 
 ```bash
 # This works even though --confidence is hidden in regular help:
-specfact import from-code my-bundle --confidence 0.7 --key-format sequential
+specfact project import from-code my-bundle --confidence 0.7 --key-format sequential
 
 # To see all options in help:
-specfact import from-code --help-advanced  # or -ha
+specfact project import from-code --help-advanced  # or -ha
 ```
 
 ## Context Detection
@@ -117,7 +117,7 @@ Based on detected context, SpecFact provides intelligent defaults:
 specfact spec validate --bundle <auto-detected>
 
 # If low contract coverage detected, suggests analysis
-specfact analyze --bundle <auto-detected>
+specfact code analyze --bundle <auto-detected>
 ```
 
 ### Explicit Context
@@ -126,7 +126,7 @@ You can also explicitly check your project context:
 
 ```bash
 # Context detection is automatic, but you can verify
-specfact import from-code my-bundle --repo .
+specfact project import from-code my-bundle --repo .
 # CLI automatically detects Python, FastAPI, existing specs, etc.
 ```
 
@@ -139,13 +139,13 @@ SpecFact provides context-aware suggestions to guide your workflow.
 After running commands, SpecFact suggests logical next steps:
 
 ```bash
-$ specfact import from-code legacy-api
+$ specfact project import from-code legacy-api
 ✓ Import complete
 
 💡 Suggested next steps:
-  • specfact analyze --bundle legacy-api  # Analyze contract coverage
-  • specfact enforce sdd --bundle legacy-api  # Enforce quality gates
-  • specfact sync intelligent --bundle legacy-api  # Sync code and specs
+  • specfact code analyze --bundle legacy-api  # Analyze contract coverage
+  • specfact govern enforce sdd --bundle legacy-api  # Enforce quality gates
+  • specfact project sync intelligent --bundle legacy-api  # Sync code and specs
 ```
 
 ### Error Fixes
@@ -153,12 +153,12 @@ $ specfact import from-code legacy-api
 When errors occur, SpecFact suggests specific fixes:
 
 ```bash
-$ specfact analyze --bundle missing-bundle
+$ specfact code analyze --bundle missing-bundle
 ✗ Error: Bundle 'missing-bundle' not found
 
 💡 Suggested fixes:
-  • specfact plan select  # Select an active plan bundle
-  • specfact import from-code missing-bundle  # Create a new bundle
+  • specfact project plan select  # Select an active plan bundle
+  • specfact project import from-code missing-bundle  # Create a new bundle
 ```
 
 ### Improvements
@@ -166,12 +166,12 @@ $ specfact analyze --bundle missing-bundle
 Based on analysis, SpecFact suggests improvements:
 
 ```bash
-$ specfact analyze --bundle legacy-api
+$ specfact code analyze --bundle legacy-api
 ⚠ Low contract coverage detected (30%)
 
 💡 Suggested improvements:
-  • specfact analyze --bundle legacy-api  # Identify missing contracts
-  • specfact import from-code legacy-api  # Extract contracts from code
+  • specfact code analyze --bundle legacy-api  # Identify missing contracts
+  • specfact project import from-code legacy-api  # Extract contracts from code
 ```
 
 ## Template-Driven Quality
@@ -214,7 +214,7 @@ Watch mode has been enhanced with intelligent change detection.
 Watch mode only processes files that actually changed:
 
 ```bash
-specfact sync intelligent --bundle my-bundle --watch
+specfact project sync intelligent --bundle my-bundle --watch
 ```
 
 **Features**:
diff --git a/docs/guides/workflows.md b/docs/guides/workflows.md
index deff9178..b2b95d9c 100644
--- a/docs/guides/workflows.md
+++ b/docs/guides/workflows.md
@@ -29,21 +29,21 @@ Reverse engineer existing code and enforce contracts incrementally.
 
 ```bash
 # Full repository analysis
-specfact import from-code legacy-api --repo .
+specfact project import from-code legacy-api --repo .
 
 # For large codebases, analyze specific modules:
-specfact import from-code core-module --repo . --entry-point src/core
-specfact import from-code api-module --repo . --entry-point src/api
+specfact project import from-code core-module --repo . --entry-point src/core
+specfact project import from-code api-module --repo . --entry-point src/api
 ```
 
 ### Step 2: Review Extracted Specs
 
 ```bash
 # Review bundle to understand extracted specs
-specfact plan review legacy-api
+specfact project plan review legacy-api
 
 # Or get structured findings for analysis
-specfact plan review legacy-api --list-findings --findings-format json
+specfact project plan review legacy-api --list-findings --findings-format json
 ```
 
 **Note**: Use CLI commands to interact with bundles. The bundle structure (`.specfact/projects/<bundle-name>/`) is managed by SpecFact CLI - use commands like `plan review`, `plan add-feature`, `plan update-feature` to modify bundles, not direct file editing.
@@ -52,7 +52,7 @@ specfact plan review legacy-api --list-findings --findings-format json
 
 ```bash
 # Start in shadow mode
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 ```
 
 See [Brownfield Journey Guide](brownfield-journey.md) for complete workflow.
@@ -63,13 +63,13 @@ For large codebases or monorepos with multiple projects, use `--entry-point` to
 
 ```bash
 # Analyze individual projects in a monorepo
-specfact import from-code api-service --repo . --entry-point projects/api-service
-specfact import from-code web-app --repo . --entry-point projects/web-app
-specfact import from-code mobile-app --repo . --entry-point projects/mobile-app
+specfact project import from-code api-service --repo . --entry-point projects/api-service
+specfact project import from-code web-app --repo . --entry-point projects/web-app
+specfact project import from-code mobile-app --repo . --entry-point projects/mobile-app
 
 # Analyze specific modules for incremental modernization
-specfact import from-code core-module --repo . --entry-point src/core
-specfact import from-code integrations-module --repo . --entry-point src/integrations
+specfact project import from-code core-module --repo . --entry-point src/core
+specfact project import from-code integrations-module --repo . --entry-point src/integrations
 ```
 
 **Benefits:**
@@ -79,7 +79,7 @@ specfact import from-code integrations-module --repo . --entry-point src/integra
 - **Multi-bundle support** - Create separate project bundles for different projects/modules
 - **Better organization** - Keep bundles organized by project boundaries
 
-**Note:** When using `--entry-point`, each analysis creates a separate project bundle. Use `specfact plan compare` to compare different bundles.
+**Note:** When using `--entry-point`, each analysis creates a separate project bundle. Use `specfact project plan compare` to compare different bundles.
 
 ---
 
@@ -94,7 +94,7 @@ Keep SpecFact synchronized with external tools (Spec-Kit, OpenSpec, GitHub Issue
 - **GitHub Issues** (`--adapter github`) - Export change proposals to DevOps backlogs
 - **Future**: Linear, Jira, Azure DevOps, and more
 
-**Note**: SpecFact CLI uses a plugin-based adapter registry pattern. All adapters are registered in `AdapterRegistry` and accessed via `specfact sync bridge --adapter <adapter-name>`, making the architecture extensible for future tool integrations.
+**Note**: SpecFact CLI uses a plugin-based adapter registry pattern. All adapters are registered in `AdapterRegistry` and accessed via `specfact project sync bridge --adapter <adapter-name>`, making the architecture extensible for future tool integrations.
 
 ### Spec-Kit Bidirectional Sync
 
@@ -103,7 +103,7 @@ Keep Spec-Kit and SpecFact synchronized automatically.
 #### One-Time Sync
 
 ```bash
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
 ```
 
 **What it does**:
@@ -121,7 +121,7 @@ specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirec
 #### Watch Mode (Continuous Sync)
 
 ```bash
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
 ```
 
 **What it does**:
@@ -140,7 +140,7 @@ specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirec
 
 ```bash
 # Terminal 1: Start watch mode
-specfact sync bridge --adapter speckit --bundle my-project --repo . --bidirectional --watch --interval 5
+specfact project sync bridge --adapter speckit --bundle my-project --repo . --bidirectional --watch --interval 5
 
 # Terminal 2: Make changes in Spec-Kit
 echo "# New Feature" >> specs/002-new-feature/spec.md
@@ -165,7 +165,7 @@ Sync OpenSpec change proposals to SpecFact (v0.22.0+):
 
 ```bash
 # Read-only sync from OpenSpec to SpecFact
-specfact sync bridge --adapter openspec --mode read-only \
+specfact project sync bridge --adapter openspec --mode read-only \
   --bundle my-project \
   --repo /path/to/openspec-repo
 ```
@@ -193,7 +193,7 @@ Keep plan artifacts updated as code changes.
 ### One-Time Repository Sync
 
 ```bash
-specfact sync repository --repo . --target .specfact
+specfact project sync repository --repo . --target .specfact
 ```
 
 **What it does**:
@@ -211,7 +211,7 @@ specfact sync repository --repo . --target .specfact
 ### Repository Watch Mode (Continuous Sync)
 
 ```bash
-specfact sync repository --repo . --watch --interval 5
+specfact project sync repository --repo . --watch --interval 5
 ```
 
 **What it does**:
@@ -230,7 +230,7 @@ specfact sync repository --repo . --watch --interval 5
 
 ```bash
 # Terminal 1: Start watch mode
-specfact sync repository --repo . --watch --interval 5
+specfact project sync repository --repo . --watch --interval 5
 
 # Terminal 2: Make code changes
 echo "class NewService:" >> src/new_service.py
@@ -248,7 +248,7 @@ Progressive enforcement from observation to blocking.
 ### Step 1: Shadow Mode (Observe Only)
 
 ```bash
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 ```
 
 **What it does**:
@@ -266,7 +266,7 @@ specfact enforce stage --preset minimal
 ### Step 2: Balanced Mode (Warn on Issues)
 
 ```bash
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 ```
 
 **What it does**:
@@ -284,7 +284,7 @@ specfact enforce stage --preset balanced
 ### Step 3: Strict Mode (Block Everything)
 
 ```bash
-specfact enforce stage --preset strict
+specfact govern enforce stage --preset strict
 ```
 
 **What it does**:
@@ -303,16 +303,16 @@ specfact enforce stage --preset strict
 
 ```bash
 # First-time setup: Configure CrossHair for contract exploration
-specfact repro setup
+specfact code repro setup
 
 # Quick validation
-specfact repro
+specfact code repro
 
 # Verbose validation with budget
-specfact repro --verbose --budget 120
+specfact code repro --verbose --budget 120
 
 # Apply auto-fixes
-specfact repro --fix --budget 120
+specfact code repro --fix --budget 120
 ```
 
 **What it does**:
@@ -333,7 +333,7 @@ Compare manual plans vs auto-derived plans to detect deviations.
 ### Quick Comparison
 
 ```bash
-specfact plan compare --bundle legacy-api
+specfact project plan compare --bundle legacy-api
 ```
 
 **What it does**:
@@ -351,7 +351,7 @@ specfact plan compare --bundle legacy-api
 ### Detailed Comparison
 
 ```bash
-specfact plan compare \
+specfact project plan compare \
   --manual .specfact/projects/manual-plan \
   --auto .specfact/projects/auto-derived \
   --out comparison-report.md
@@ -374,7 +374,7 @@ specfact plan compare \
 ### Code vs Plan Comparison
 
 ```bash
-specfact plan compare --bundle legacy-api --code-vs-plan
+specfact project plan compare --bundle legacy-api --code-vs-plan
 ```
 
 **What it does**:
@@ -399,10 +399,10 @@ Typical workflow for daily development.
 
 ```bash
 # Validate everything
-specfact repro --verbose
+specfact code repro --verbose
 
 # Compare plans
-specfact plan compare --bundle legacy-api
+specfact project plan compare --bundle legacy-api
 ```
 
 **What it does**:
@@ -415,7 +415,7 @@ specfact plan compare --bundle legacy-api
 
 ```bash
 # Start watch mode for repository sync
-specfact sync repository --repo . --watch --interval 5
+specfact project sync repository --repo . --watch --interval 5
 ```
 
 **What it does**:
@@ -428,10 +428,10 @@ specfact sync repository --repo . --watch --interval 5
 
 ```bash
 # Run validation
-specfact repro
+specfact code repro
 
 # Compare plans
-specfact plan compare --bundle legacy-api
+specfact project plan compare --bundle legacy-api
 ```
 
 **What it does**:
@@ -444,7 +444,7 @@ specfact plan compare --bundle legacy-api
 
 ```bash
 # CI/CD pipeline runs
-specfact repro --verbose --budget 120
+specfact code repro --verbose --budget 120
 ```
 
 **What it does**:
@@ -464,7 +464,7 @@ Complete workflow for migrating from Spec-Kit or OpenSpec.
 #### Step 1: Preview
 
 ```bash
-specfact import from-bridge --adapter speckit --repo . --dry-run
+specfact project import from-bridge --adapter speckit --repo . --dry-run
 ```
 
 **What it does**:
@@ -476,7 +476,7 @@ specfact import from-bridge --adapter speckit --repo . --dry-run
 #### Step 2: Execute
 
 ```bash
-specfact import from-bridge --adapter speckit --repo . --write
+specfact project import from-bridge --adapter speckit --repo . --write
 ```
 
 **What it does**:
@@ -488,7 +488,7 @@ specfact import from-bridge --adapter speckit --repo . --write
 #### Step 3: Set Up Sync
 
 ```bash
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
 ```
 
 **What it does**:
@@ -503,12 +503,12 @@ Sync with OpenSpec change proposals (v0.22.0+):
 
 ```bash
 # Read-only sync from OpenSpec to SpecFact
-specfact sync bridge --adapter openspec --mode read-only \
+specfact project sync bridge --adapter openspec --mode read-only \
   --bundle my-project \
   --repo /path/to/openspec-repo
 
 # Export OpenSpec change proposals to GitHub Issues
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org \
   --repo-name your-repo \
   --repo /path/to/openspec-repo
@@ -526,13 +526,13 @@ See [OpenSpec Journey Guide](openspec-journey.md) for complete integration workf
 
 ```bash
 # Start in shadow mode
-specfact enforce stage --preset minimal
+specfact govern enforce stage --preset minimal
 
 # After stabilization, enable warnings
-specfact enforce stage --preset balanced
+specfact govern enforce stage --preset balanced
 
 # For production, enable strict mode
-specfact enforce stage --preset strict
+specfact govern enforce stage --preset strict
 ```
 
 **What it does**:
diff --git a/docs/index.md b/docs/index.md
index 35b3795a..9291ec44 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -54,7 +54,7 @@ specfact backlog daily ado --ado-org <org> --ado-project "<project>" --state any
 specfact backlog refine ado --ado-org <org> --ado-project "<project>" --id <work-item-id> --preview
 
 # 3) Validate drift before implementation
-specfact policy validate --group-by-item
+specfact backlog policy validate --group-by-item
 ```
 
 GitHub variant:
@@ -69,7 +69,7 @@ Deep dive:
 
 1. **[Installation](getting-started/installation.md)** - Get started in 60 seconds
 2. **[First Steps](getting-started/first-steps.md)** - Run your first command
-3. **[Module Bootstrap Checklist](getting-started/module-bootstrap-checklist.md)** - Quickly verify bundled modules are installed for user/project scope
+3. **[Module Bootstrap Checklist](getting-started/module-bootstrap-checklist.md)** - Quickly verify official bundles are installed for user/project scope
 4. **[Tutorial: Backlog Refine with AI IDE](getting-started/tutorial-backlog-refine-ai-ide.md)** - Integrate backlog refinement with your AI IDE (agile DevOps)
 5. **[Tutorial: Daily Standup and Sprint Review](getting-started/tutorial-daily-standup-sprint-review.md)** - Daily standup view, post comments, and Copilot export (GitHub/ADO)
 6. **[Working With Existing Code](guides/brownfield-engineer.md)** ⭐ **PRIMARY** - Legacy-first guide
@@ -85,16 +85,17 @@ Deep dive:
 
 ## Module System Foundation
 
-SpecFact now uses a module-first architecture to reduce hard-wired command coupling.
+SpecFact now uses a lean-core plus bundle architecture to reduce hard-wired command coupling.
 
-- Core runtime handles lifecycle, registry, contracts, and orchestration.
-- Feature behavior lives in module-local command implementations.
+- Core runtime (`specfact-cli`) handles lifecycle, registry, contracts, and orchestration.
+- Official workflow behavior lives in installable bundle packages from `nold-ai/specfact-cli-modules`.
 - Flat command-path shims were removed; use workflow command groups.
 
-Implementation layout:
+Implementation ownership:
 
-- Primary module commands: `src/specfact_cli/modules/<module>/src/commands.py`
-- Legacy compatibility shims: `src/specfact_cli/commands/*.py` (only `app` re-export is guaranteed)
+- Runtime and registry: `specfact-cli`
+- Official bundles and registry artifacts: `specfact-cli-modules`
+- Legacy compatibility shims in core: `src/specfact_cli/commands/*.py` (only `app` re-export is guaranteed)
 
 Why this matters:
 
@@ -149,7 +150,8 @@ Official bundles are now marketplace-distributed as `nold-ai/specfact-*` modules
 - `nold-ai/specfact-spec`
 - `nold-ai/specfact-govern`
 
-Bundle/module documentation ownership has moved to `nold-ai/specfact-cli-modules`:
+Bundle-specific documentation is still temporarily hosted in this docs set while the
+long-term bundle docs home is prepared in `nold-ai/specfact-cli-modules`:
 `https://nold-ai.github.io/specfact-cli-modules/`.
 
 - **[Installing Modules](guides/installing-modules.md)** - Install, list, uninstall, and upgrade modules
@@ -165,7 +167,7 @@ Module lifecycle note: use `specfact module` (`init`, `install`, `list`, `show`,
 
 - **[Command Chains](guides/command-chains.md)** ⭐ **NEW** - Complete workflows from start to finish
 - **[Agile/Scrum Workflows](guides/agile-scrum-workflows.md)** - Persona-based collaboration for teams
-- **[Policy Engine Commands](guides/policy-engine-commands.md)** - Scaffold policy config templates and run `policy init|validate|suggest`
+- **[Policy Engine Commands](guides/policy-engine-commands.md)** - Scaffold policy config templates and run `backlog policy init|validate|suggest`
 - **[DevOps Backlog Integration](guides/devops-adapter-integration.md)** 🆕 **NEW FEATURE** - Integrate SpecFact into agile DevOps workflows with bidirectional backlog sync
 - **[Backlog Refinement](guides/backlog-refinement.md)** 🆕 **NEW FEATURE** - AI-assisted template-driven backlog refinement for standardizing work items
 - **[Backlog Dependency Analysis](guides/backlog-dependency-analysis.md)** - Analyze critical path, cycles, orphans, and dependency impact from backlog graph data
@@ -216,17 +218,17 @@ Module lifecycle note: use `specfact module` (`init`, `install`, `list`, `show`,
 
 ```bash
 # Export OpenSpec proposals to GitHub Issues
-specfact sync bridge --adapter github --mode export-only \
+specfact project sync bridge --adapter github --mode export-only \
   --repo-owner your-org --repo-name your-repo
 
 # Export to Azure DevOps work items
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --ado-org your-org --ado-project your-project
 
 # Cross-adapter sync: GitHub -> ADO (lossless round-trip)
-specfact sync bridge --adapter github --mode bidirectional \
+specfact project sync bridge --adapter github --mode bidirectional \
   --bundle main --backlog-ids 123
-specfact sync bridge --adapter ado --mode export-only \
+specfact project sync bridge --adapter ado --mode export-only \
   --bundle main --change-ids <change-id>
 ```
 
diff --git a/docs/plans/ci-pr-orchestrator-log-artifacts.md b/docs/plans/ci-pr-orchestrator-log-artifacts.md
index 069a260b..fc9cbf25 100644
--- a/docs/plans/ci-pr-orchestrator-log-artifacts.md
+++ b/docs/plans/ci-pr-orchestrator-log-artifacts.md
@@ -8,7 +8,7 @@ Improve the GitHub Action runner (`.github/workflows/pr-orchestrator.yml`) so th
 
 1. **Full test output is available on failure** — Today we often copy-paste from the UI, error details are truncated or only snippets, and we must re-run locally to find all issues. The goal is to run `smart-test-full` (or equivalent) so that log files are generated and attached to each CI run so we can download them when a run fails.
 
-2. **Repro test logs are captured and attached** — For the `specfact repro` step (contract-first-ci job), collect logs and the repro report directory (e.g. `.specfact/reports/enforcement`) and upload them as artifacts so we can download on error.
+2. **Repro test logs are captured and attached** — For the `specfact code repro` step (contract-first-ci job), collect logs and the repro report directory (e.g. `.specfact/reports/enforcement`) and upload them as artifacts so we can download on error.
 
 3. **Shift full execution validation to CI** — By having full logs and repro artifacts attached, we can rely on CI for full validation before merging to `dev` and avoid redundant local full runs.
 
@@ -16,13 +16,13 @@ Improve the GitHub Action runner (`.github/workflows/pr-orchestrator.yml`) so th
 
 - **pr-orchestrator.yml** runs contract-first test layers (contract-test-contracts, contract-test-exploration, contract-test-scenarios, contract-test-e2e) but does **not** use `smart-test-full`; it does not write test output to log files that are then uploaded.
 - Only **coverage.xml** is uploaded (in Tests job); no raw test logs or repro logs.
-- The **contract-first-ci** job runs `hatch run specfact repro --verbose --crosshair-required --budget 120` with `|| echo "SpecFact repro found issues"`, so the job does not fail hard and repro stdout/stderr and reports are not uploaded as artifacts.
+- The **contract-first-ci** job runs `hatch run specfact code repro --verbose --crosshair-required --budget 120` with `|| echo "SpecFact repro found issues"`, so the job does not fail hard and repro stdout/stderr and reports are not uploaded as artifacts.
 - Error details in the GitHub Actions UI are limited to step output (snippets); full logs are not downloadable.
 
 ## What Changes
 
 - **Tests job**: Switch to (or add) running `hatch run smart-test-full` so that the smart-test script writes logs under `logs/tests/` (e.g. `full_test_run_*.log`, `full_coverage_*.log`). Upload the contents of `logs/tests/` (and existing `logs/tests/coverage/coverage.xml`) as workflow artifacts so they are available for download on every run (or on failure only to save space/retention).
-- **Contract-first-ci job (repro)**: After running `specfact repro`, collect (1) repro stdout/stderr (e.g. by redirecting to a file or using a wrapper that writes to `logs/repro/`), and (2) `.specfact/reports/enforcement/` (repro reports). Upload these as artifacts (e.g. `repro-logs` and `repro-reports`), so on failure we can download full repro output and reports.
+- **Contract-first-ci job (repro)**: After running `specfact code repro`, collect (1) repro stdout/stderr (e.g. by redirecting to a file or using a wrapper that writes to `logs/repro/`), and (2) `.specfact/reports/enforcement/` (repro reports). Upload these as artifacts (e.g. `repro-logs` and `repro-reports`), so on failure we can download full repro output and reports.
 - **Artifact upload strategy**: Use `actions/upload-artifact@v4` with a consistent naming scheme (e.g. `test-logs-<job>`, `repro-logs`, `repro-reports`). Optionally use `if: failure()` or `if: always()` so artifacts are retained for failed runs or all runs per project policy.
 - **Documentation**: Update docs (e.g. contributing, troubleshooting, or reference) to mention that CI produces downloadable test and repro log artifacts and how to use them.
 
@@ -35,7 +35,7 @@ Improve the GitHub Action runner (`.github/workflows/pr-orchestrator.yml`) so th
 ## Success Metrics
 
 - Every PR/push run that executes tests produces downloadable artifacts containing full test log files when using smart-test-full.
-- Every run that executes `specfact repro` produces downloadable artifacts containing repro stdout/stderr and repro report files.
+- Every run that executes `specfact code repro` produces downloadable artifacts containing repro stdout/stderr and repro report files.
 - Contributors can diagnose failures from downloaded artifacts without needing to re-run the full suite locally.
 
 ## Dependencies
diff --git a/docs/prompts/PROMPT_VALIDATION_CHECKLIST.md b/docs/prompts/PROMPT_VALIDATION_CHECKLIST.md
index b1787413..43fa76ee 100644
--- a/docs/prompts/PROMPT_VALIDATION_CHECKLIST.md
+++ b/docs/prompts/PROMPT_VALIDATION_CHECKLIST.md
@@ -62,7 +62,7 @@ The validator checks:
 - [ ] **Command examples**: Examples show actual CLI usage with correct flags
 - [ ] **Flag documentation**: All flags are documented with defaults and descriptions
 - [ ] **Filter options documented** (for `plan select`): `--current`, `--stages`, `--last`, `--no-interactive` flags are documented with use cases and examples
-- [ ] **Positional vs option arguments**: Correctly distinguishes between positional arguments and `--option` flags (e.g., `specfact plan select 20` not `specfact plan select --plan 20`)
+- [ ] **Positional vs option arguments**: Correctly distinguishes between positional arguments and `--option` flags (e.g., `specfact project plan select 20` not `specfact project plan select --plan 20`)
 - [ ] **Boolean flags documented correctly**: Boolean flags use `--flag/--no-flag` syntax, not `--flag true/false`
   - ❌ **WRONG**: `--draft true` or `--draft false` (Typer boolean flags don't accept values)
   - ✅ **CORRECT**: `--draft` (sets True) or `--no-draft` (sets False) or omit (leaves unchanged)
@@ -112,7 +112,7 @@ The validator checks:
     - [ ] Review feature titles and descriptions for semantic similarity
     - [ ] Identify features that represent the same functionality with different names
     - [ ] Suggest consolidation when multiple features cover the same code/functionality
-    - [ ] Use `specfact plan update-feature` or `specfact plan add-feature` to consolidate
+    - [ ] Use `specfact project plan update-feature` or `specfact project plan add-feature` to consolidate
   - [ ] **Deduplication output**: CLI shows "✓ Removed N duplicate features" - LLM should acknowledge this
   - [ ] **Post-deduplication review**: LLM should review remaining features for semantic duplicates
 - [ ] **Execution steps**: Clear, sequential steps
@@ -189,7 +189,7 @@ For each prompt, test the following scenarios:
 
 1. Invoke `/specfact.03-review legacy-api` with a plan bundle
 2. Verify the LLM:
-   - ✅ Executes `specfact plan review` CLI command
+   - ✅ Executes `specfact project plan review` CLI command
    - ✅ Parses CLI output for ambiguity findings
    - ✅ Waits for user input when questions are asked
    - ✅ Does NOT create clarifications directly in YAML
@@ -202,13 +202,13 @@ For each prompt, test the following scenarios:
 2. Verify the LLM:
    - ✅ **Detects need for enrichment**: Recognizes vague patterns ("is implemented", "System MUST Helper class", generic tasks)
    - ✅ **Suggests or uses `--auto-enrich`**: Either suggests using `--auto-enrich` flag or automatically uses it based on plan quality indicators
-   - ✅ **Executes enrichment**: Runs `specfact plan review <bundle-name> --auto-enrich`
+   - ✅ **Executes enrichment**: Runs `specfact project plan review <bundle-name> --auto-enrich`
    - ✅ **Parses enrichment results**: Captures enrichment summary (features updated, stories updated, acceptance criteria enhanced, etc.)
    - ✅ **Analyzes enrichment quality**: Uses LLM reasoning to review what was enhanced
    - ✅ **Identifies generic patterns**: Finds placeholder text like "interact with the system" that needs refinement
    - ✅ **Proposes specific refinements**: Suggests domain-specific improvements using CLI commands
-   - ✅ **Executes refinements**: Uses `specfact plan update-feature --bundle <bundle-name>` to refine generic improvements
-   - ✅ **Re-runs review**: Executes `specfact plan review` again to verify improvements
+   - ✅ **Executes refinements**: Uses `specfact project plan update-feature --bundle <bundle-name>` to refine generic improvements
+   - ✅ **Re-runs review**: Executes `specfact project plan review` again to verify improvements
 3. Test with explicit enrichment request (e.g., "enrich the plan"):
    - ✅ Uses `--auto-enrich` flag immediately
    - ✅ Reviews enrichment results
@@ -216,9 +216,9 @@ For each prompt, test the following scenarios:
 
 #### Scenario 5: Plan Selection Workflow (for plan-select)
 
-1. Invoke `/specfact.02-plan select` (or use CLI: `specfact plan select`)
+1. Invoke `/specfact.02-plan select` (or use CLI: `specfact project plan select`)
 2. Verify the LLM:
-   - ✅ Executes `specfact plan select` CLI command
+   - ✅ Executes `specfact project plan select` CLI command
    - ✅ Formats plan list as copilot-friendly Markdown table (not Rich table)
    - ✅ Provides selection options (number, "number details", "q" to quit)
    - ✅ Waits for user response with `[WAIT FOR USER RESPONSE - DO NOT CONTINUE]`
@@ -228,16 +228,16 @@ For each prompt, test the following scenarios:
    - ✅ Asks if user wants to select the plan
    - ✅ Waits for user confirmation
 4. Select a plan (e.g., "20" or "y" after details):
-   - ✅ Uses **positional argument** syntax: `specfact plan select 20` (NOT `--plan 20`)
+   - ✅ Uses **positional argument** syntax: `specfact project plan select 20` (NOT `--plan 20`)
    - ✅ Confirms selection with CLI output
    - ✅ Does NOT create config.yaml directly
 5. Test filter options:
-   - ✅ Uses `--current` flag to show only active plan: `specfact plan select --current`
-   - ✅ Uses `--stages` flag to filter by stages: `specfact plan select --stages draft,review`
-   - ✅ Uses `--last N` flag to show recent plans: `specfact plan select --last 5`
+   - ✅ Uses `--current` flag to show only active plan: `specfact project plan select --current`
+   - ✅ Uses `--stages` flag to filter by stages: `specfact project plan select --stages draft,review`
+   - ✅ Uses `--last N` flag to show recent plans: `specfact project plan select --last 5`
 6. Test non-interactive mode (CI/CD):
-   - ✅ Uses `--no-interactive` flag with `--current`: `specfact plan select --no-interactive --current`
-   - ✅ Uses `--no-interactive` flag with `--last 1`: `specfact plan select --no-interactive --last 1`
+   - ✅ Uses `--no-interactive` flag with `--current`: `specfact project plan select --no-interactive --current`
+   - ✅ Uses `--no-interactive` flag with `--last 1`: `specfact project plan select --no-interactive --last 1`
    - ✅ Handles error when multiple plans match filters in non-interactive mode
    - ✅ Does NOT prompt for input when `--no-interactive` is used
 
@@ -245,14 +245,14 @@ For each prompt, test the following scenarios:
 
 1. Invoke `/specfact-plan-promote` with a plan that has missing critical categories
 2. Verify the LLM:
-   - ✅ Executes `specfact plan promote --stage review --validate` CLI command
+   - ✅ Executes `specfact project plan promote --stage review --validate` CLI command
    - ✅ Parses CLI output showing coverage validation errors
    - ✅ Shows which critical categories are Missing
-   - ✅ Suggests running `specfact plan review` to resolve ambiguities
+   - ✅ Suggests running `specfact project plan review` to resolve ambiguities
    - ✅ Does NOT attempt to bypass validation by creating artifacts directly
    - ✅ Waits for user decision (use `--force` or run `plan review` first)
 3. Invoke promotion with `--force` flag:
-   - ✅ Uses `--force` flag correctly: `specfact plan promote --stage review --force`
+   - ✅ Uses `--force` flag correctly: `specfact project plan promote --stage review --force`
    - ✅ Explains that `--force` bypasses validation (not recommended)
    - ✅ Does NOT create plan bundle directly
 
@@ -336,14 +336,14 @@ After testing, review:
 
 ### ❌ Wrong Argument Format (Positional vs Option)
 
-**Symptom**: LLM uses `--option` flag when command expects positional argument (e.g., `specfact plan select --plan 20` instead of `specfact plan select 20`)
+**Symptom**: LLM uses `--option` flag when command expects positional argument (e.g., `specfact project plan select --plan 20` instead of `specfact project plan select 20`)
 
 **Fix**:
 
 - Verify actual CLI command signature (use `specfact <command> --help`)
 - Update prompt to explicitly state positional vs option arguments
 - Add examples showing correct syntax
-- Add warning about common mistakes (e.g., "NOT `specfact plan select --plan 20` (this will fail)")
+- Add warning about common mistakes (e.g., "NOT `specfact project plan select --plan 20` (this will fail)")
 
 ### ❌ Wrong Boolean Flag Usage
 
diff --git a/docs/prompts/README.md b/docs/prompts/README.md
index fab5119e..8f874108 100644
--- a/docs/prompts/README.md
+++ b/docs/prompts/README.md
@@ -34,7 +34,7 @@ SpecFact CLI provides slash commands that work with AI-assisted IDEs (Cursor, VS
 
 **Purpose**: Import from codebase (brownfield modernization)
 
-**Equivalent CLI**: `specfact import from-code`
+**Equivalent CLI**: `specfact project import from-code`
 
 **Example**:
 
@@ -50,7 +50,7 @@ SpecFact CLI provides slash commands that work with AI-assisted IDEs (Cursor, VS
 
 **Purpose**: Plan management (init, add-feature, add-story, update-idea, update-feature, update-story)
 
-**Equivalent CLI**: `specfact plan init/add-feature/add-story/update-idea/update-feature/update-story`
+**Equivalent CLI**: `specfact project plan init/add-feature/add-story/update-idea/update-feature/update-story`
 
 **Example**:
 
@@ -67,7 +67,7 @@ SpecFact CLI provides slash commands that work with AI-assisted IDEs (Cursor, VS
 
 **Purpose**: Review plan and promote
 
-**Equivalent CLI**: `specfact plan review`
+**Equivalent CLI**: `specfact project plan review`
 
 **Example**:
 
@@ -83,7 +83,7 @@ SpecFact CLI provides slash commands that work with AI-assisted IDEs (Cursor, VS
 
 **Purpose**: Create SDD manifest
 
-**Equivalent CLI**: `specfact enforce sdd`
+**Equivalent CLI**: `specfact govern enforce sdd`
 
 **Example**:
 
@@ -99,7 +99,7 @@ SpecFact CLI provides slash commands that work with AI-assisted IDEs (Cursor, VS
 
 **Purpose**: SDD enforcement
 
-**Equivalent CLI**: `specfact enforce sdd`
+**Equivalent CLI**: `specfact govern enforce sdd`
 
 **Example**:
 
@@ -115,7 +115,7 @@ SpecFact CLI provides slash commands that work with AI-assisted IDEs (Cursor, VS
 
 **Purpose**: Sync operations
 
-**Equivalent CLI**: `specfact sync bridge`
+**Equivalent CLI**: `specfact project sync bridge`
 
 **Example**:
 
@@ -131,7 +131,7 @@ SpecFact CLI provides slash commands that work with AI-assisted IDEs (Cursor, VS
 
 **Purpose**: Contract management (analyze, generate prompts, apply contracts sequentially)
 
-**Equivalent CLI**: `specfact generate contracts-prompt`
+**Equivalent CLI**: `specfact spec generate contracts-prompt`
 
 **Example**:
 
@@ -149,7 +149,7 @@ SpecFact CLI provides slash commands that work with AI-assisted IDEs (Cursor, VS
 
 **Purpose**: Compare plans
 
-**Equivalent CLI**: `specfact plan compare`
+**Equivalent CLI**: `specfact project plan compare`
 
 **Example**:
 
@@ -165,7 +165,7 @@ SpecFact CLI provides slash commands that work with AI-assisted IDEs (Cursor, VS
 
 **Purpose**: Validation suite
 
-**Equivalent CLI**: `specfact repro`
+**Equivalent CLI**: `specfact code repro`
 
 **Example**:
 
diff --git a/docs/reference/README.md b/docs/reference/README.md
index 2d3289d3..237ce21d 100644
--- a/docs/reference/README.md
+++ b/docs/reference/README.md
@@ -30,18 +30,18 @@ Complete technical reference for SpecFact CLI.
 
 ### Commands
 
-- `specfact import from-bridge --adapter speckit` - Import from external tools via bridge adapter
-- `specfact import from-code <bundle-name>` - Reverse-engineer plans from code
-- `specfact plan init <bundle-name>` - Initialize new development plan
-- `specfact plan compare` - Compare manual vs auto plans
-- `specfact enforce stage` - Configure quality gates
-- `specfact repro` - Run full validation suite
-- `specfact sync bridge --adapter <adapter> --bundle <bundle-name>` - Sync with external tools via bridge adapter
+- `specfact project import from-bridge --adapter speckit` - Import from external tools via bridge adapter
+- `specfact project import from-code <bundle-name>` - Reverse-engineer plans from code
+- `specfact project plan init <bundle-name>` - Initialize new development plan
+- `specfact project plan compare` - Compare manual vs auto plans
+- `specfact govern enforce stage` - Configure quality gates
+- `specfact code repro` - Run full validation suite
+- `specfact project sync bridge --adapter <adapter> --bundle <bundle-name>` - Sync with external tools via bridge adapter
 - `specfact spec validate [--bundle <name>]` - Validate OpenAPI/AsyncAPI specifications
 - `specfact spec generate-tests [--bundle <name>]` - Generate contract tests from specifications
 - `specfact spec mock [--bundle <name>]` - Launch mock server for development
 - `specfact init ide --ide <cursor|vscode|copilot|...>` - Initialize IDE integration explicitly
-- `specfact module install <name|namespace/name> [--scope user|project] [--source auto|bundled|marketplace] [--repo PATH]` - Install modules with scope and source control (bare names normalize to `specfact/<name>`)
+- `specfact module install <name|namespace/name> [--scope user|project] [--source auto|bundled|marketplace] [--repo PATH]` - Install modules with scope and source control (bare names resolve through the configured source policy)
 - `specfact module list [--source ...] [--show-origin] [--show-bundled-available]` - List modules with trust/publisher, optional origin details, and optional bundled-not-installed section
 - `specfact module show <name>` - Show detailed module metadata and full command tree with short descriptions
 - `specfact module search <query>` - Search marketplace and installed modules
@@ -60,9 +60,9 @@ Complete technical reference for SpecFact CLI.
 ## Technical Details
 
 - **Architecture**: See [Architecture](architecture.md)
-- **Module Structure**: See [Architecture - Module Structure](architecture.md#module-structure)
+- **Command Registry and Module System**: See [Architecture - Command Registry and Module System](architecture.md#command-registry-and-module-system)
 - **Operational Modes**: See [Architecture - Operational Modes](architecture.md#operational-modes)
-- **Agent Modes**: See [Architecture - Agent Modes](architecture.md#agent-modes)
+- **Ownership Boundary**: See [Architecture - Core vs modules-repo ownership boundary](architecture.md#core-vs-modules-repo-ownership-boundary)
 
 ## Related Documentation
 
diff --git a/docs/reference/architecture.md b/docs/reference/architecture.md
index a8aa8de9..da2ec213 100644
--- a/docs/reference/architecture.md
+++ b/docs/reference/architecture.md
@@ -69,7 +69,7 @@ See also:
 After module extraction and core slimming (module-migration-02, migration-03), the ownership boundary is:
 
 - **specfact-cli (core)**: Owns runtime, lifecycle, bootstrap, registry, adapters, shared models (`ProjectBundle`, `PlanBundle`, etc.), and the three permanent core modules (`init`, `module_registry`, `upgrade`). Core must **not** import from bundle packages (`backlog_core`, `bundle_mapper`, etc.).
-- **specfact-cli-modules (bundles)**: Owns bundle implementations (backlog-core, bundle-mapper, etc.). Bundles import from `specfact_cli` (adapters, models, utils, registry, contracts) as pip dependencies. Core provides interfaces; bundles implement and consume them.
+- **specfact-cli-modules (bundles)**: Owns official bundle implementations (`specfact-backlog`, `specfact-project`, etc.). Bundles import from `specfact_cli` (adapters, models, utils, registry, contracts) as pip dependencies. Core provides interfaces; bundles implement and consume them.
 
 Boundary regression tests (`test_core_does_not_import_from_bundle_packages`) enforce that core remains decoupled from bundle implementation details.
 
diff --git a/docs/reference/authentication.md b/docs/reference/authentication.md
index 7d12546c..2a051718 100644
--- a/docs/reference/authentication.md
+++ b/docs/reference/authentication.md
@@ -6,6 +6,10 @@ permalink: /reference/authentication/
 
 # Authentication
 
+
+> Temporary docs note: this bundle-focused page remains hosted in the core docs set for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
+
 SpecFact CLI supports device code authentication flows for GitHub and Azure DevOps to keep credentials out of scripts and CI logs.
 When the backlog bundle is installed, authentication commands are available under `specfact backlog auth`.
 
diff --git a/docs/reference/command-syntax-policy.md b/docs/reference/command-syntax-policy.md
index 2639d282..a75796d9 100644
--- a/docs/reference/command-syntax-policy.md
+++ b/docs/reference/command-syntax-policy.md
@@ -19,9 +19,9 @@ Always document commands exactly as implemented by `specfact <command> --help` i
 ## Bundle Argument Conventions (v0.30.x baseline)
 
 - Positional bundle argument:
-  - `specfact import from-code [BUNDLE]`
-  - `specfact plan init BUNDLE`
-  - `specfact plan review [BUNDLE]`
+  - `specfact project import from-code [BUNDLE]`
+  - `specfact project plan init BUNDLE`
+  - `specfact project plan review [BUNDLE]`
 - `--bundle` option:
   - Supported by many plan mutation commands (for example `plan add-feature`, `plan add-story`, `plan update-feature`)
   - Not universally supported across all commands
@@ -43,9 +43,9 @@ Before merging command docs updates:
 ## Quick Verification Commands
 
 ```bash
-hatch run specfact import from-code --help
-hatch run specfact plan init --help
-hatch run specfact plan review --help
-hatch run specfact plan add-feature --help
+hatch run specfact project import from-code --help
+hatch run specfact project plan init --help
+hatch run specfact project plan review --help
+hatch run specfact project plan add-feature --help
 ```
 
diff --git a/docs/reference/commands.md b/docs/reference/commands.md
index 0806c40c..951e30f6 100644
--- a/docs/reference/commands.md
+++ b/docs/reference/commands.md
@@ -14,7 +14,6 @@ Flat root-level compatibility shims were removed in `0.40.0`; use category-group
 Root command surface includes core commands and installed category groups only:
 
 - `specfact init`
-- `specfact auth`
 - `specfact module`
 - `specfact upgrade`
 - `specfact code ...`
@@ -39,11 +38,11 @@ After bundle install, command groups are mounted by category:
 
 | Bundle ID | Group | Main command families |
 |---|---|---|
-| `nold-ai/specfact-project` | `project` | `project`, `plan`, `import`, `sync`, `migrate` |
-| `nold-ai/specfact-backlog` | `backlog` | `backlog`, `policy` |
-| `nold-ai/specfact-codebase` | `code` | `analyze`, `drift`, `validate`, `repro` |
-| `nold-ai/specfact-spec` | `spec` | `contract`, `api`, `sdd`, `generate` |
-| `nold-ai/specfact-govern` | `govern` | `enforce`, `patch` |
+| `nold-ai/specfact-project` | `project` | `project ...`, `project plan ...`, `project import ...`, `project sync ...`, `project migrate ...` |
+| `nold-ai/specfact-backlog` | `backlog` | `backlog ...`, `backlog policy ...`, `backlog auth ...` |
+| `nold-ai/specfact-codebase` | `code` | `code analyze ...`, `code drift ...`, `code validate ...`, `code repro ...` |
+| `nold-ai/specfact-spec` | `spec` | `spec contract ...`, `spec api ...`, `spec sdd ...`, `spec generate ...` |
+| `nold-ai/specfact-govern` | `govern` | `govern enforce ...`, `govern patch ...` |
 
 ## Migration: Removed Flat Commands
 
@@ -94,3 +93,6 @@ specfact backlog ceremony refinement --help
 - [Module Categories](module-categories.md)
 - [Marketplace Bundles](../guides/marketplace.md)
 - [Installing Modules](../guides/installing-modules.md)
+
+> Temporary docs note: bundle-specific command details are still hosted in this core docs set
+> for the current release line and are planned to migrate to `specfact-cli-modules`.
diff --git a/docs/reference/dependency-resolution.md b/docs/reference/dependency-resolution.md
index 9dc4edf9..f2c6ba46 100644
--- a/docs/reference/dependency-resolution.md
+++ b/docs/reference/dependency-resolution.md
@@ -13,12 +13,12 @@ SpecFact resolves dependencies for marketplace modules before installing. This r
 
 When you run `specfact module install <module-id>` (without `--skip-deps`), the CLI:
 
-1. Discovers all currently available modules (bundled + already installed) plus the module being installed.
+1. Discovers all currently available modules (installed modules plus any bundled candidates available to the current CLI release) and the module being installed.
 2. Reads each module’s `module_dependencies` and `pip_dependencies` from their manifests.
 3. Runs the dependency resolver to compute a consistent set of versions.
 4. If conflicts are found, install fails unless you pass `--force`.
 
-Resolution is used only for **marketplace** installs. Bundled and custom modules do not go through this resolution step for their dependencies.
+Resolution is used only for **marketplace** installs. Bundled bootstrap copies and custom/local modules do not go through the marketplace dependency resolver for their dependencies.
 
 ## Resolver behavior
 
@@ -38,8 +38,8 @@ Resolution is used only for **marketplace** installs. Bundled and custom modules
 
 ## Bypass options
 
-- **Skip resolution**: `specfact module install specfact/backlog --skip-deps` installs only `specfact/backlog` and does not pull or check its `pip_dependencies` / `module_dependencies`.
-- **Override conflicts**: `specfact module install specfact/backlog --force` proceeds even when the resolver reports conflicts. Enable/disable and dependency-aware cascades may still use `--force` where applicable.
+- **Skip resolution**: `specfact module install nold-ai/specfact-backlog --skip-deps` installs only `nold-ai/specfact-backlog` and does not pull or check its `pip_dependencies` / `module_dependencies`.
+- **Override conflicts**: `specfact module install nold-ai/specfact-backlog --force` proceeds even when the resolver reports conflicts. Enable/disable and dependency-aware cascades may still use `--force` where applicable.
 
 ## See also
 
diff --git a/docs/reference/directory-structure.md b/docs/reference/directory-structure.md
index d88c10a3..8997137d 100644
--- a/docs/reference/directory-structure.md
+++ b/docs/reference/directory-structure.md
@@ -8,6 +8,16 @@ permalink: /directory-structure/
 
 This document defines the canonical directory structure for SpecFact CLI artifacts.
 
+This page covers runtime and workspace artifact layout under `.specfact/`.
+Source-repository ownership is now split:
+
+- `specfact-cli`: lean runtime, registry, shared contracts, adapters, docs site
+- `specfact-cli-modules`: official workflow bundle source packages and registry publishing automation
+
+Use this document for repository-local artifact placement. Use
+[Module Development](../guides/module-development.md) and
+[Publishing modules](../guides/publishing-modules.md) for source/package layout.
+
 > **Primary Use Case**: SpecFact CLI is designed for **brownfield code modernization** - reverse-engineering existing codebases into documented specs with runtime contract enforcement. The directory structure reflects this brownfield-first approach.
 
 **CLI-First Approach**: SpecFact works offline, requires no account, and integrates with your existing workflow. Works with VS Code, Cursor, GitHub Actions, pre-commit hooks, or any IDE. No platform to learn, no vendor lock-in.
@@ -42,7 +52,30 @@ All SpecFact artifacts are stored under `.specfact/` in the repository root. Thi
 - SpecFact does **not** auto-discover `<repo>/modules` to avoid assuming ownership of non-`.specfact` repository paths.
 - In repository context, `<repo>/.specfact/modules` has higher discovery precedence than `<user-home>/.specfact/modules`.
 
-For how the CLI discovers and loads commands from module packages (registry, module-package.yaml, lazy loading), see [Architecture – Modules design](architecture.md#modules-design).
+For how the CLI discovers and loads commands from module packages (registry, module-package.yaml, lazy loading), see [Architecture – Command Registry and Module System](architecture.md#command-registry-and-module-system).
+
+## Source repository layout
+
+Post-migration, implementation is split across two repositories:
+
+```text
+specfact-cli/
+  src/specfact_cli/
+  docs/
+  openspec/
+  tests/
+
+specfact-cli-modules/
+  packages/specfact-project/
+  packages/specfact-backlog/
+  packages/specfact-codebase/
+  packages/specfact-spec/
+  packages/specfact-govern/
+  registry/
+```
+
+The runtime loads bundle packages through manifests and registry metadata; it does not treat the
+source repositories themselves as runtime module roots.
 
 ## Canonical Structure
 
@@ -205,17 +238,17 @@ Plan bundles version 1.1 and later include summary metadata in the `metadata.sum
 
 **Upgrading Plan Bundles:**
 
-Use `specfact plan upgrade` to migrate older plan bundles to the latest schema:
+Use `specfact project plan upgrade` to migrate older plan bundles to the latest schema:
 
 ```bash
 # Upgrade active plan
-specfact plan upgrade
+specfact project plan upgrade
 
 # Upgrade all plans
-specfact plan upgrade --all
+specfact project plan upgrade --all
 
 # Preview upgrades
-specfact plan upgrade --dry-run
+specfact project plan upgrade --dry-run
 ```
 
 See [`plan upgrade`](../reference/commands.md#plan-upgrade) for details.
@@ -288,7 +321,7 @@ See [`plan upgrade`](../reference/commands.md#plan-upgrade) for details.
 - **Tasks**: `.specfact/projects/<bundle-name>/tasks.yaml` (versioned)
 - **Logs**: `.specfact/projects/<bundle-name>/logs/` (gitignored)
 
-**Migration**: Use `specfact migrate artifacts` to move existing artifacts from global locations to bundle-specific folders.
+**Migration**: Use `specfact project migrate artifacts` to move existing artifacts from global locations to bundle-specific folders.
 
 **Example**:
 
@@ -321,7 +354,7 @@ See [`plan upgrade`](../reference/commands.md#plan-upgrade) for details.
 - ❌ `.specfact/sdd/` - Removed (SDD manifests are bundle-specific)
 - ❌ `.specfact/tasks/` - Removed (task files are bundle-specific)
 
-**Migration**: Use `specfact migrate cleanup-legacy` to remove empty legacy directories, and `specfact migrate artifacts` to migrate existing artifacts to bundle-specific locations.
+**Migration**: Use `specfact project migrate cleanup-legacy` to remove empty legacy directories, and `specfact project migrate artifacts` to migrate existing artifacts to bundle-specific locations.
 
 ### `.specfact/gates/` (Versioned)
 
@@ -355,13 +388,13 @@ See [`plan upgrade`](../reference/commands.md#plan-upgrade) for details.
 
 ## Default Command Paths
 
-### `specfact import from-code` ⭐ PRIMARY
+### `specfact project import from-code` ⭐ PRIMARY
 
 **Primary use case**: Reverse-engineer existing codebases into project bundles.
 
 ```bash
 # Command syntax
-specfact import from-code <bundle-name> --repo . [OPTIONS]
+specfact project import from-code <bundle-name> --repo . [OPTIONS]
 
 # Creates modular bundle at:
 .specfact/projects/<bundle-name>/
@@ -382,7 +415,7 @@ specfact import from-code <bundle-name> --repo . [OPTIONS]
 
 ```bash
 # Analyze legacy codebase
-specfact import from-code legacy-api --repo . --confidence 0.7
+specfact project import from-code legacy-api --repo . --confidence 0.7
 
 # Creates:
 # - .specfact/projects/legacy-api/bundle.manifest.yaml (versioned)
@@ -391,13 +424,13 @@ specfact import from-code legacy-api --repo . --confidence 0.7
 # - .specfact/reports/brownfield/analysis-2025-10-31T14-30-00.md (gitignored)
 ```
 
-### `specfact plan init` (Alternative)
+### `specfact project plan init` (Alternative)
 
 **Alternative use case**: Create new project bundles for greenfield projects.
 
 ```bash
 # Command syntax
-specfact plan init <bundle-name> [OPTIONS]
+specfact project plan init <bundle-name> [OPTIONS]
 
 # Creates modular bundle at:
 .specfact/projects/<bundle-name>/
@@ -410,11 +443,11 @@ specfact plan init <bundle-name> [OPTIONS]
 .specfact/config.yaml
 ```
 
-### `specfact plan compare`
+### `specfact project plan compare`
 
 ```bash
 # Compare two bundles (explicit paths to bundle directories)
-specfact plan compare \
+specfact project plan compare \
   --manual .specfact/projects/manual-plan \
   --auto .specfact/projects/auto-derived \
   --out .specfact/reports/comparison/report-*.md
@@ -422,31 +455,31 @@ specfact plan compare \
 # Note: Commands accept bundle directory paths, not individual files
 ```
 
-### `specfact sync bridge`
+### `specfact project sync bridge`
 
 ```bash
 # Sync with external tools (Spec-Kit, Linear, Jira, etc.)
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional
 
 # Watch mode
-specfact sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --repo . --bidirectional --watch --interval 5
 
 # Sync files are tracked in .specfact/reports/sync/
 ```
 
-### `specfact sync repository`
+### `specfact project sync repository`
 
 ```bash
 # Sync code changes
-specfact sync repository --repo . --target .specfact
+specfact project sync repository --repo . --target .specfact
 
 # Watch mode
-specfact sync repository --repo . --watch --interval 5
+specfact project sync repository --repo . --watch --interval 5
 
 # Sync reports in .specfact/reports/sync/
 ```
 
-### `specfact enforce stage`
+### `specfact govern enforce stage`
 
 ```bash
 # Reads/writes
@@ -463,7 +496,7 @@ specfact init
 
 # Canonical lifecycle commands
 specfact module list
-specfact module install specfact/backlog
+specfact module install nold-ai/specfact-backlog
 specfact module uninstall backlog
 ```
 
@@ -665,7 +698,7 @@ If you have existing artifacts in other locations:
 # Migration
 mkdir -p .specfact/projects/my-project .specfact/reports/brownfield
 # Convert monolithic bundle to modular bundle structure
-# (Use 'specfact plan upgrade' or manual conversion)
+# (Use 'specfact project plan upgrade' or manual conversion)
 mv reports/analysis.md .specfact/reports/brownfield/
 ```
 
@@ -713,17 +746,17 @@ SpecFact supports multiple plan bundles for:
 
 ```bash
 # Step 1: Reverse-engineer legacy codebase
-specfact import from-code legacy-api \
+specfact project import from-code legacy-api \
   --repo src/legacy-api \
   --confidence 0.7
 
 # Step 2: Compare legacy vs modernized (use bundle directories, not files)
-specfact plan compare \
+specfact project plan compare \
   --manual .specfact/projects/legacy-api \
   --auto .specfact/projects/modernized-api
 
 # Step 3: Analyze specific legacy component
-specfact import from-code legacy-payment \
+specfact project import from-code legacy-payment \
   --repo src/legacy-payment \
   --confidence 0.7
 ```
diff --git a/docs/reference/feature-keys.md b/docs/reference/feature-keys.md
index c97005c2..21d3aeeb 100644
--- a/docs/reference/feature-keys.md
+++ b/docs/reference/feature-keys.md
@@ -19,7 +19,7 @@ SpecFact CLI supports multiple feature key formats to accommodate different use
 **Generation**:
 
 ```bash
-specfact import from-code --key-format classname
+specfact project import from-code --key-format classname
 ```
 
 ### 2. Sequential Format
@@ -33,13 +33,13 @@ specfact import from-code --key-format classname
 **Generation**:
 
 ```bash
-specfact import from-code --key-format sequential
+specfact project import from-code --key-format sequential
 ```
 
 **Manual creation**: When creating plans interactively, use `FEATURE-001` format:
 
 ```bash
-specfact plan init
+specfact project plan init
 # Enter feature key: FEATURE-001
 ```
 
@@ -86,7 +86,7 @@ normalize_feature_key("FEATURE-001")
 The `plan compare` command automatically normalizes keys:
 
 ```bash
-specfact plan compare --manual main.bundle.yaml --auto auto-derived.yaml
+specfact project plan compare --manual main.bundle.yaml --auto auto-derived.yaml
 ```
 
 **Behavior**: Features with different key formats but the same normalized key are matched correctly.
@@ -96,7 +96,7 @@ specfact plan compare --manual main.bundle.yaml --auto auto-derived.yaml
 When merging plans (e.g., via `sync bridge --adapter speckit`), normalization ensures features are matched correctly:
 
 ```bash
-specfact sync bridge --adapter speckit --bundle <bundle-name> --bidirectional
+specfact project sync bridge --adapter speckit --bundle <bundle-name> --bidirectional
 ```
 
 **Behavior**: Features are matched by normalized key, not exact key format.
@@ -125,7 +125,7 @@ A `plan normalize` command may be added in the future to convert existing plans:
 
 ```bash
 # (Future) Convert plan to sequential format
-specfact plan normalize --from main.bundle.yaml --to main-sequential.yaml --output-format sequential
+specfact project plan normalize --from main.bundle.yaml --to main-sequential.yaml --output-format sequential
 ```
 
 ## Best Practices
@@ -159,7 +159,7 @@ specfact plan normalize --from main.bundle.yaml --to main-sequential.yaml --outp
 When creating plans manually or interactively:
 
 ```bash
-specfact plan init
+specfact project plan init
 # Enter feature key: FEATURE-001  # ← Use sequential format
 # Enter feature title: User Authentication
 ```
@@ -171,7 +171,7 @@ specfact plan init
 When analyzing existing codebases:
 
 ```bash
-specfact import from-code --key-format classname  # ← Default, explicit for clarity
+specfact project import from-code --key-format classname  # ← Default, explicit for clarity
 ```
 
 **Why**: Classname format directly maps to codebase structure, making it easy to trace features back to classes.
diff --git a/docs/reference/modes.md b/docs/reference/modes.md
index 5c324133..945105db 100644
--- a/docs/reference/modes.md
+++ b/docs/reference/modes.md
@@ -223,7 +223,7 @@ print(f'Execution mode: {result.execution_mode}')
 # In GitHub Actions or CI/CD
 # No environment variables set
 # Should auto-detect CI/CD mode (bundle name as positional argument)
-hatch run specfact import from-code my-project --repo . --confidence 0.7
+hatch run specfact project import from-code my-project --repo . --confidence 0.7
 
 # Expected: Mode: CI/CD (direct execution)
 ```
@@ -234,7 +234,7 @@ hatch run specfact import from-code my-project --repo . --confidence 0.7
 # Developer running in VS Code/Cursor with CoPilot enabled
 # IDE environment variables automatically set
 # Should auto-detect CoPilot mode (bundle name as positional argument)
-hatch run specfact import from-code my-project --repo . --confidence 0.7
+hatch run specfact project import from-code my-project --repo . --confidence 0.7
 
 # Expected: Mode: CoPilot (agent routing)
 ```
diff --git a/docs/reference/module-categories.md b/docs/reference/module-categories.md
index 0ccb74aa..a0cf9105 100644
--- a/docs/reference/module-categories.md
+++ b/docs/reference/module-categories.md
@@ -12,7 +12,6 @@ SpecFact groups feature modules into workflow-oriented command families.
 Core commands remain top-level:
 
 - `specfact init`
-- `specfact backlog auth`
 - `specfact module`
 - `specfact upgrade`
 
@@ -29,7 +28,6 @@ Category command groups:
 | Module | Category | Bundle | Group Command | Sub-command |
 |---|---|---|---|---|
 | `init` | `core` | — | — | `init` |
-| `auth` | `core` | — | — | `auth` |
 | `module_registry` | `core` | — | — | `module` |
 | `upgrade` | `core` | — | — | `upgrade` |
 | `project` | `project` | `specfact-project` | `project` | `project` |
@@ -76,6 +74,10 @@ Namespace mapping:
 Compatibility note:
 
 - Flat top-level command shims were removed. Use category groups (`project`, `backlog`, `code`, `spec`, `govern`).
+- `specfact backlog auth ...` is provided by the backlog bundle, not by the permanent core command surface.
+
+> Temporary docs note: this bundle/category reference remains hosted in `specfact-cli` for the
+> current release line and is planned to migrate to `specfact-cli-modules`.
 
 ## First-Run Profiles
 
diff --git a/docs/reference/module-contracts.md b/docs/reference/module-contracts.md
index fdb37666..9323aa8b 100644
--- a/docs/reference/module-contracts.md
+++ b/docs/reference/module-contracts.md
@@ -9,6 +9,9 @@ description: ModuleIOContract protocol, validation output model, and isolation r
 
 SpecFact modules integrate through a protocol-first interface and inversion-of-control loading.
 
+> Temporary docs note: bundle-specific contract guidance remains hosted in this core docs set for
+> the current release line and is planned to migrate to `specfact-cli-modules`.
+
 ## ModuleIOContract
 
 `ModuleIOContract` defines four operations:
@@ -30,10 +33,14 @@ Implementations should use runtime contracts (`@icontract`) and runtime type val
 
 ## Inversion of Control
 
-Core code must not import module code directly.
+Core runtime must not import external bundle package namespaces directly.
 
-- Allowed: core -> `CommandRegistry`
-- Forbidden: core -> `specfact_cli.modules.*`
+- Allowed:
+  - core runtime -> `CommandRegistry`
+  - bundle packages -> `specfact_cli` shared contracts, adapters, models, utils
+- Forbidden:
+  - core runtime -> `specfact_backlog.*`, `specfact_project.*`, `specfact_codebase.*`, or other external bundle package namespaces
+  - bundle packages reaching back into unpublished/private core internals outside supported contracts
 
 Module discovery and loading are done through registry-driven lazy loading.
 
@@ -41,10 +48,11 @@ Module discovery and loading are done through registry-driven lazy loading.
 
 During the migration from hard-wired command paths:
 
-- New feature logic belongs in `src/specfact_cli/modules/<module>/src/commands.py`.
+- Official workflow bundle logic now belongs in `nold-ai/specfact-cli-modules`.
 - Legacy files under `src/specfact_cli/commands/*.py` are shims for backward compatibility.
 - Only `app` re-export behavior is guaranteed from shim modules.
-- New code should import from module-local command paths, not shim paths.
+- Lean-core runtime code in `specfact-cli` should depend on shared contracts and loader interfaces, not on bundle implementation modules.
+- Bundle packages should import stable runtime surfaces from `specfact_cli` and expose their own entrypoints from package-local namespaces.
 
 This enables module-level evolution while keeping core interfaces stable.
 
@@ -64,3 +72,5 @@ def import_to_bundle(source: Path, config: dict[str, Any]) -> ProjectBundle:
 - Implement as many protocol operations as your module supports.
 - Declare `schema_version` when you depend on a specific bundle IO schema.
 - Keep module logic isolated from core; rely on registry entrypoints.
+- Follow the same ownership split used by `specfact-cli-modules`: bundle behavior lives outside
+  the core runtime repository whenever possible.
diff --git a/docs/reference/module-security.md b/docs/reference/module-security.md
index 1a6da1ae..0022423e 100644
--- a/docs/reference/module-security.md
+++ b/docs/reference/module-security.md
@@ -9,6 +9,9 @@ description: Trust model, checksum and signature verification, and integrity lif
 
 Module packages carry **publisher** and **integrity** metadata so installation, bootstrap, and runtime discovery verify trust before enabling a module.
 
+> Temporary docs note: bundle-specific security guidance remains hosted in this core docs set for
+> the current release line and is planned to migrate to `specfact-cli-modules`.
+
 ## Trust model
 
 - **Manifest metadata**: `module-package.yaml` may include `publisher` (name, email, attributes) and `integrity` (checksum, optional signature).
diff --git a/docs/reference/telemetry.md b/docs/reference/telemetry.md
index 410a6261..4306c17f 100644
--- a/docs/reference/telemetry.md
+++ b/docs/reference/telemetry.md
@@ -477,7 +477,7 @@ No. We buffer metrics in-memory and write to disk at the end of each command. Wh
 Yes. Point `SPECFACT_TELEMETRY_ENDPOINT` to an internal collector. Nothing leaves your network unless you decide to forward it. All data is stored locally in `~/.specfact/telemetry.log` by default.
 
 **Can I prove contracts are preventing bugs?**  
-Absolutely. We surface `violations_detected` from commands like `specfact repro` so you can compare "bugs caught by contracts" vs. "bugs caught by legacy tests" over time, and we aggregate the ratios (anonymously) to showcase SpecFact's brownfield impact publicly.
+Absolutely. We surface `violations_detected` from commands like `specfact code repro` so you can compare "bugs caught by contracts" vs. "bugs caught by legacy tests" over time, and we aggregate the ratios (anonymously) to showcase SpecFact's brownfield impact publicly.
 
 **What happens if the collector is unavailable?**  
 Telemetry gracefully degrades - events are still written to local storage (`~/.specfact/telemetry.log`), and export failures are logged but don't affect your CLI commands. You can retry exports later by processing the local log file.
@@ -488,7 +488,7 @@ Only if you explicitly opt in. We recommend enabling telemetry in CI/CD to track
 **How do I verify telemetry is working?**
 
 1. Enable debug mode: `export SPECFACT_TELEMETRY_DEBUG=true`
-2. Run a command: `specfact import from-code --repo .`
+2. Run a command: `specfact project import from-code --repo .`
 3. Check local log: `tail -f ~/.specfact/telemetry.log`
 4. Verify events appear in your OTLP collector (if configured)
 
diff --git a/docs/reference/thorough-codebase-validation.md b/docs/reference/thorough-codebase-validation.md
index 91501fec..df8fd1e2 100644
--- a/docs/reference/thorough-codebase-validation.md
+++ b/docs/reference/thorough-codebase-validation.md
@@ -13,28 +13,28 @@ This reference describes how to run thorough in-depth validation in different mo
 
 | Mode | When to use | Primary command(s) |
 |------|-------------|---------------------|
-| **Quick check** | Fast local/CI gate (lint, type-check, CrossHair with default budget) | `specfact repro --repo <path>` |
+| **Quick check** | Fast local/CI gate (lint, type-check, CrossHair with default budget) | `specfact code repro --repo <path>` |
 | **Thorough (contract-decorated)** | Repo already uses `@icontract` / `@beartype`; run full contract stack | `hatch run contract-test-full` |
-| **Sidecar (unmodified code)** | Third-party or legacy repo; no edits to target source | `specfact repro --repo <path> --sidecar --sidecar-bundle <bundle>` |
-| **Dogfooding** | Validate the specfact-cli repo with the same pipeline | `specfact repro --repo .` + `hatch run contract-test-full` (optional sidecar) |
+| **Sidecar (unmodified code)** | Third-party or legacy repo; no edits to target source | `specfact code repro --repo <path> --sidecar --sidecar-bundle <bundle>` |
+| **Dogfooding** | Validate the specfact-cli repo with the same pipeline | `specfact code repro --repo .` + `hatch run contract-test-full` (optional sidecar) |
 
-## 1. Quick check (`specfact repro`)
+## 1. Quick check (`specfact code repro`)
 
 Run the standard reproducibility suite (ruff, semgrep if config exists, basedpyright, CrossHair, optional pytest contracts/smoke):
 
 ```bash
-specfact repro --repo .
-specfact repro --repo /path/to/external/repo --verbose
+specfact code repro --repo .
+specfact code repro --repo /path/to/external/repo --verbose
 ```
 
 - **Time budget**: Default 120s; use `--budget N` (advanced) to change.
 - **Deep CrossHair**: To increase per-path timeout for CrossHair (e.g. for critical modules), use `--crosshair-per-path-timeout N` (seconds; N must be positive). Default behavior is unchanged when not set.
 
 ```bash
-specfact repro --repo . --crosshair-per-path-timeout 60
+specfact code repro --repo . --crosshair-per-path-timeout 60
 ```
 
-Required env: none. Optional: `[tool.crosshair]` in `pyproject.toml` (e.g. from `specfact repro setup`).
+Required env: none. Optional: `[tool.crosshair]` in `pyproject.toml` (e.g. from `specfact code repro setup`).
 
 ## 2. Thorough validation for contract-decorated codebases
 
@@ -63,7 +63,7 @@ Document this as the recommended thorough path for contract-decorated code; CI c
 For repositories you cannot or do not want to modify (no contract decorators added):
 
 ```bash
-specfact repro --repo <path> --sidecar --sidecar-bundle <bundle-name>
+specfact code repro --repo <path> --sidecar --sidecar-bundle <bundle-name>
 ```
 
 - Main repro checks run first (lint, semgrep, type-check, CrossHair if available).
@@ -79,14 +79,14 @@ Maintainers can validate the specfact-cli repository with the same pipeline:
 1. **Repro + contract-test-full** (recommended minimum):
 
    ```bash
-   specfact repro --repo .
+   specfact code repro --repo .
    hatch run contract-test-full
    ```
 
 2. **Optional sidecar** (to cover unannotated code in specfact-cli):
 
    ```bash
-   specfact repro --repo . --sidecar --sidecar-bundle <bundle-name>
+   specfact code repro --repo . --sidecar --sidecar-bundle <bundle-name>
    ```
 
 Use the same commands in a CI job or release checklist so specfact-cli validates itself before release. No repo-specific code is required beyond existing repro and contract-test tooling.
@@ -95,10 +95,10 @@ Use the same commands in a CI job or release checklist so specfact-cli validates
 
 | Goal | Commands |
 |------|----------|
-| Quick gate | `specfact repro --repo .` |
-| Deep CrossHair (repro) | `specfact repro --repo . --crosshair-per-path-timeout 60` |
+| Quick gate | `specfact code repro --repo .` |
+| Deep CrossHair (repro) | `specfact code repro --repo . --crosshair-per-path-timeout 60` |
 | Full contract stack | `hatch run contract-test-full` |
-| Unmodified repo | `specfact repro --repo <path> --sidecar --sidecar-bundle <name>` |
-| Dogfooding | `specfact repro --repo .` then `hatch run contract-test-full`; optionally add `--sidecar --sidecar-bundle <name>` to repro |
+| Unmodified repo | `specfact code repro --repo <path> --sidecar --sidecar-bundle <name>` |
+| Dogfooding | `specfact code repro --repo .` then `hatch run contract-test-full`; optionally add `--sidecar --sidecar-bundle <name>` to repro |
 
 Required env/config: optional `[tool.crosshair]` in `pyproject.toml`; for sidecar, a valid sidecar bundle and CrossHair installed when sidecar CrossHair is used.
diff --git a/docs/technical/code2spec-analysis-logic.md b/docs/technical/code2spec-analysis-logic.md
index 51a6ebba..d6716f1c 100644
--- a/docs/technical/code2spec-analysis-logic.md
+++ b/docs/technical/code2spec-analysis-logic.md
@@ -15,7 +15,7 @@ Uses **AI IDE's native LLM** for semantic understanding via pragmatic integratio
 **Workflow**:
 
 1. **AI IDE's LLM** understands codebase semantically (via slash command prompt)
-2. **AI calls SpecFact CLI** (`specfact import from-code <bundle-name>`) for structured analysis
+2. **AI calls SpecFact CLI** (`specfact project import from-code <bundle-name>`) for structured analysis
 3. **AI enhances results** with semantic understanding (priorities, constraints, unknowns)
 4. **CLI handles structured work** (file I/O, YAML generation, validation)
 
@@ -66,7 +66,7 @@ Uses **Python's AST + Semgrep pattern matching** for comprehensive structural an
 
 ```mermaid
 flowchart TD
-    A["code2spec Command<br/>specfact import from-code my-project --repo . --confidence 0.5"] --> B{Operational Mode}
+    A["code2spec Command<br/>specfact project import from-code my-project --repo . --confidence 0.5"] --> B{Operational Mode}
     
     B -->|CoPilot Mode| C["AnalyzeAgent (AI-First)<br/>• LLM semantic understanding<br/>• Multi-language support<br/>• Semantic extraction (priorities, constraints, unknowns)<br/>• High-quality Spec-Kit artifacts"]
     
diff --git a/docs/validation-integration.md b/docs/validation-integration.md
index a0821944..c5a6b478 100644
--- a/docs/validation-integration.md
+++ b/docs/validation-integration.md
@@ -153,7 +153,7 @@ When `external_base_path` is set:
 
 ```bash
 # In repository with OpenSpec
-specfact validate sidecar run my-bundle /path/to/repo
+specfact code validate sidecar run my-bundle /path/to/repo
 
 # System automatically:
 # 1. Detects OpenSpec repository
@@ -168,7 +168,7 @@ specfact validate sidecar run my-bundle /path/to/repo
 
 ```bash
 # With bridge_config.yaml specifying external_base_path
-specfact validate sidecar run my-bundle /path/to/repo --bridge-config bridge_config.yaml
+specfact code validate sidecar run my-bundle /path/to/repo --bridge-config bridge_config.yaml
 
 # System loads OpenSpec from external repository
 ```
diff --git a/openspec/CHANGE_ORDER.md b/openspec/CHANGE_ORDER.md
index 501a3e1a..e4958055 100644
--- a/openspec/CHANGE_ORDER.md
+++ b/openspec/CHANGE_ORDER.md
@@ -77,7 +77,7 @@ These are derived extensions of the same 2026-02-15 plan and are required to ope
 
 | Module | Order | Change folder | GitHub # | Blocked by |
 |--------|-------|---------------|----------|------------|
-| docs | 01 | docs-01-core-modules-docs-alignment | TBD | module-migration-01 ✅; module-migration-02 ✅; module-migration-03 ✅; module-migration-05 ✅; module-migration-06/07 outputs inform residual cleanup wording |
+| docs | 01 | docs-01-core-modules-docs-alignment | [#348](https://github.com/nold-ai/specfact-cli/issues/348) | module-migration-01 ✅; module-migration-02 ✅; module-migration-03 ✅; module-migration-05 ✅; module-migration-06/07 outputs inform residual cleanup wording |
 
 ### Marketplace (module distribution)
 
@@ -207,6 +207,13 @@ These are derived extensions of the same 2026-02-15 plan and are required to ope
 | ai-integration | 01 | ai-integration-01-agent-skill | [#251](https://github.com/nold-ai/specfact-cli/issues/251) | #241 (validation-02) |
 | ai-integration | 02 | ai-integration-02-mcp-server | [#252](https://github.com/nold-ai/specfact-cli/issues/252) | #241 (validation-02) |
 | ai-integration | 03 | ai-integration-03-instruction-files | [#253](https://github.com/nold-ai/specfact-cli/issues/253) | #251 (ai-integration-01) |
+| ai-integration | 04 | ai-integration-04-intent-skills | [#349](https://github.com/nold-ai/specfact-cli/issues/349) | #251 (ai-integration-01); #239 (requirements-02) |
+
+### OpenSpec bridge integration (intent engineering plan, 2026-03-05)
+
+| Module | Order | Change folder | GitHub # | Blocked by |
+|--------|-------|---------------|----------|------------|
+| openspec | 01 | openspec-01-intent-trace | [#350](https://github.com/nold-ai/specfact-cli/issues/350) | #238 (requirements-01); #239 (requirements-02) |
 
 ### CLI end-user validation (validation gap plan, 2026-02-19)
 
@@ -265,6 +272,8 @@ Set these in GitHub so issue dependencies are explicit. Optional dependencies ar
 | [#251](https://github.com/nold-ai/specfact-cli/issues/251) | ai-integration-01 agent skill | #241 |
 | [#252](https://github.com/nold-ai/specfact-cli/issues/252) | ai-integration-02 mcp server | #241 |
 | [#253](https://github.com/nold-ai/specfact-cli/issues/253) | ai-integration-03 instruction files | #251 |
+| [#349](https://github.com/nold-ai/specfact-cli/issues/349) | ai-integration-04 intent skills | #251, #239 |
+| [#350](https://github.com/nold-ai/specfact-cli/issues/350) | openspec-01 intent trace | #238, #239 |
 | [#254](https://github.com/nold-ai/specfact-cli/issues/254) | integration-01 cross-change contracts | #237, #239, #240, #241, #246 |
 | [#255](https://github.com/nold-ai/specfact-cli/issues/255) | dogfooding-01 full-chain e2e proof | #239, #240, #241, #242, #247 |
 
@@ -382,6 +391,10 @@ Dependencies flow left-to-right; a wave may start once all its hard blockers are
   - ai-integration-02 (#252) (after validation-02 #241)
   - ai-integration-03 (#253) (after ai-integration-01 #251)
 
+- **Wave 8 additions — Intent engineering layer (intent engineering plan, 2026-03-05)**:
+  - ai-integration-04 (#349) (after ai-integration-01 #251 + requirements-02 #239)
+  - openspec-01 (#350) (after requirements-01 #238 + requirements-02 #239; aligns with Wave 5/6)
+
 - **Wave 9 — Integration contract and product proof**:
   - integration-01 (#254) (after profile-01 #237 + requirements-02 #239 + architecture-01 #240 + validation-02 #241 + policy-02 #246)
   - dogfooding-01 (#255) (after requirements-02 #239 + architecture-01 #240 + validation-02 #241 + traceability-01 #242 + governance-01 #247)
diff --git a/openspec/changes/docs-01-core-modules-docs-alignment/.openspec.yaml b/openspec/changes/ai-integration-04-intent-skills/.openspec.yaml
similarity index 100%
rename from openspec/changes/docs-01-core-modules-docs-alignment/.openspec.yaml
rename to openspec/changes/ai-integration-04-intent-skills/.openspec.yaml
diff --git a/openspec/changes/ai-integration-04-intent-skills/CHANGE_VALIDATION.md b/openspec/changes/ai-integration-04-intent-skills/CHANGE_VALIDATION.md
new file mode 100644
index 00000000..ff72ee1c
--- /dev/null
+++ b/openspec/changes/ai-integration-04-intent-skills/CHANGE_VALIDATION.md
@@ -0,0 +1,97 @@
+# Change Validation Report: ai-integration-04-intent-skills
+
+**Validation Date**: 2026-03-05
+**Change Proposal**: [proposal.md](./proposal.md)
+**Validation Method**: Dry-run simulation in temporary workspace `/tmp/specfact-validation-ai-integration-04-<timestamp>`
+**Source Plan**: `specfact-cli-internal/docs/internal/implementation/2026-03-05-CLAUDE-RESEARCH-INTENT-DRIVEN-DEVELOPMENT.md`
+
+## Executive Summary
+
+- Breaking Changes: 0 detected
+- Dependent Files: 0 affected (all interfaces are new — ai-integration-01 not yet implemented)
+- Impact Level: Low (new files and backwards-compatible CLI extension)
+- Validation Result: **Pass**
+- User Decision: N/A
+
+## Breaking Changes Detected
+
+None. `specfact ide skill install` and the `skills/` directory do not yet exist in the codebase — they are being created by `ai-integration-01-agent-skill` (#251, pending). The `--type` option is a new optional parameter with a backwards-compatible default (`"spec"`), posing no breaking risk on any existing callers.
+
+## Dependencies Affected
+
+### Critical (hard blockers — must land before implementation)
+
+| Dependency | Issue | Status |
+|---|---|---|
+| `ai-integration-01-agent-skill` | [#251](https://github.com/nold-ai/specfact-cli/issues/251) | PENDING (Wave 8) |
+| `requirements-01-data-model` | [#238](https://github.com/nold-ai/specfact-cli/issues/238) | PENDING (Wave 5) |
+| `requirements-02-module-commands` | [#239](https://github.com/nold-ai/specfact-cli/issues/239) | PENDING (Wave 5/6) |
+
+All three are expected — this is a Wave 8 change by design.
+
+### Recommended Updates
+
+None.
+
+## Impact Assessment
+
+- **Code Impact**: Low — 6 new Markdown skill files + 1 new `--type` CLI option (optional, backwards-compatible). No existing Python code modified.
+- **Test Impact**: Low — new test files only (`test_intent_skills_install.py`, `test_intent_skills_content.py`). No existing test modifications.
+- **Documentation Impact**: Medium — new guide `docs/guides/intent-capture-workflow.md`; update `docs/guides/ai-ide-workflow.md`. Sidebar navigation update required.
+- **Release Impact**: Minor version bump (new feature, no breaking changes).
+
+## Format Validation
+
+- **proposal.md Format**: Pass
+  - `# Change:` title ✓
+  - `## Why`, `## What Changes`, `## Capabilities`, `## Impact` sections ✓
+  - NEW/EXTEND markers in What Changes ✓
+  - Capabilities linked to spec files ✓
+  - Source Tracking section ✓
+- **tasks.md Format**: Pass
+  - Hierarchical `## 1.`, `## 2.`… structure ✓
+  - Task 1 = git worktree creation ✓
+  - Task 9 = PR creation (last) ✓
+  - Post-merge cleanup section ✓
+  - TDD / SDD order section at top ✓
+  - Tests before implementation (Task 2 tests before Task 3-4 implementation) ✓
+  - `TDD_EVIDENCE.md` recording tasks ✓
+  - Quality gate tasks (format, type-check, lint, yaml-lint, contract-test, smart-test) ✓
+  - Module signing verification task ✓
+  - Version and changelog task ✓
+  - GitHub issue creation task ✓
+- **specs Format**: Pass
+  - `####` for all scenario headers ✓
+  - `## ADDED Requirements` / `## MODIFIED Requirements` delta format ✓
+  - Given/When/Then with THEN/AND format ✓
+  - Every requirement has ≥1 scenario ✓
+- **Config.yaml Compliance**: Pass
+  - Contract decorator tasks included ✓
+  - Documentation research task included ✓
+  - 2-hour max chunk guidance followed ✓
+
+## OpenSpec Validation
+
+- **Status**: Pass
+- **Command**: `openspec validate ai-integration-04-intent-skills --strict`
+- **Output**: `Change 'ai-integration-04-intent-skills' is valid`
+- **Issues Found/Fixed**: 0
+
+## Validation Artifacts
+
+- Temporary workspace: `/tmp/specfact-validation-ai-integration-04-<timestamp>`
+- Interface scaffolds created: none (no existing interfaces to compare against)
+
+## Ownership Notes
+
+- **New skill files** (`skills/specfact-intent*/SKILL.md`): owned exclusively by this change
+- **`specfact ide skill install` `--type` option**: this change extends the interface defined by `ai-integration-01`; no ownership conflict (ai-integration-01 does not define `--type`)
+- **`specfact ide skill list`**: delta extension; ai-integration-01 owns the base command, this change adds intent-type entries
+
+## Wave/Sequencing Confirmation
+
+Wave 8, blocked by:
+- ai-integration-01 (#251) — skill install infrastructure
+- requirements-01 (#238) + requirements-02 (#239) — skills invoke `specfact requirements capture/validate/trace`
+
+Do not start implementation until all three blockers are archived.
diff --git a/openspec/changes/ai-integration-04-intent-skills/design.md b/openspec/changes/ai-integration-04-intent-skills/design.md
new file mode 100644
index 00000000..3422510b
--- /dev/null
+++ b/openspec/changes/ai-integration-04-intent-skills/design.md
@@ -0,0 +1,61 @@
+# Design: Intent Engineering Skills — SQUER Workflow for AI IDEs
+
+## Context
+
+`ai-integration-01-agent-skill` ships spec-validation skills that teach AI IDEs when to invoke SpecFact validation after code is written. This change extends SpecFact's skills surface upstream — into the intent-capture and requirements-decomposition phase that happens before a spec is written. The SQUER intent interview model (7 standard questions) provides a well-defined, machine-parseable interview protocol that maps directly to SpecFact's `BusinessOutcome` and `BusinessRule` schemas (defined by requirements-01-data-model). The open Agent Skills standard (YAML frontmatter + Markdown instructions) provides the integration surface for 26+ AI IDE platforms without platform-specific code.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Ship 6 skill files covering the full intent engineering workflow (capture → decompose → architecture → trace-validate → evidence-check)
+- Extend `specfact ide skill install` with `--type intent` to install intent skills alongside or separately from spec skills
+- Keep each skill file self-contained and composable (an agent can invoke one or all)
+- Follow SQUER's 7-question interview exactly — this is the scholarly grounding for the intent capture pattern
+
+**Non-Goals:**
+- Building a new CLI command group for intent — the skills invoke existing `specfact requirements`, `specfact architecture`, and `specfact validate` commands
+- IDE-specific integrations — the open skills standard handles 26+ platforms without per-IDE code
+- Replacing `ai-integration-01` — this change extends the skills surface, not replaces it
+
+## Decisions
+
+### D1: Separate skill files per workflow step vs. monolithic intent skill
+
+**Decision**: Separate skill files (`specfact-intent-capture`, `specfact-intent-decompose`, etc.)
+**Rationale**: Composability. An agent doing only architecture derivation should not load the full 15,000-token intent workflow. Small skills (~2,000-3,000 tokens each) allow agents to load exactly what they need. The umbrella `specfact-intent/SKILL.md` (~80 tokens) acts as a router.
+**Alternative rejected**: Single monolithic skill — exceeds context budgets for lightweight agents; forces full load for partial workflows.
+
+### D2: Skills invoke existing CLI commands vs. new intent-specific commands
+
+**Decision**: Skills invoke existing `specfact requirements capture/validate/trace`, `specfact architecture derive`, `specfact validate --full-chain`
+**Rationale**: No new command surface means skills work immediately when requirements-01/02 and architecture-01 land. The skills are documentation and prompt patterns, not CLI extensions. The only new CLI change is the `--type intent` flag on `specfact ide skill install`.
+**Alternative rejected**: New `specfact intent capture` top-level command — premature; can be added later if workflows warrant a dedicated entry point.
+
+### D3: SQUER 7-question interview as the canonical intent capture protocol
+
+**Decision**: Follow SQUER's 7 standard questions exactly as the structured elicitation in `specfact-intent-capture/SKILL.md`
+**Rationale**: SQUER's Intent Engineer model is the scholarly foundation for this work. The 7 questions (What problem? Who has it? What happens today? What should change? How will we know? What must not break? What's the priority?) map directly to `BusinessOutcome` fields and produce YAML-serializable intent artifacts. Using a standard protocol means skills are teachable and reproducible.
+**Alignment**: IntentSpec.org's 5-field schema (Objective, User Goal, Outcomes, Edge Cases, Verification) is compatible — SQUER's 7 questions produce all 5 IntentSpec fields as a superset.
+
+### D4: Skill installation via `specfact ide skill install --type intent`
+
+**Decision**: Extend existing install command with `--type {spec,intent,all}` (default: `spec` for backwards compatibility)
+**Rationale**: The `--type` selector keeps the install surface minimal and composable. Teams that only need spec validation don't need intent skills cluttering their IDE context. `--type all` future-proofs for additional skill types (e.g., `governance`, `ceremony`).
+
+## Risks / Trade-offs
+
+- **[Risk] CLI dependency ordering** — Intent skills that invoke `specfact requirements capture` will silently fail if requirements-01/02 are not installed. Mitigation: each skill MUST include a prerequisite check step that runs `specfact --version` and `specfact requirements --help`; if missing, it directs the agent to install the requirements module.
+- **[Risk] SQUER question fidelity** — If the 7 questions are paraphrased imprecisely, the resulting intent artifacts diverge from the schema. Mitigation: the skill file pins the exact question text; the decompose skill validates output against the `BusinessOutcome` JSON schema before writing `.req.yaml`.
+- **[Trade-off] Skill file maintenance** — Each skill file is a standalone Markdown artifact. When CLI commands evolve (requirements-02, architecture-01), skill files need updating. Mitigation: skill files reference CLI commands by flag signature, not by output format; they tolerate CLI version drift as long as exit codes remain stable.
+
+## Migration Plan
+
+1. Land requirements-01-data-model (#238) and requirements-02-module-commands (#239) first — intent skills invoke these commands.
+2. Land ai-integration-01-agent-skill (#251) first — skill install infrastructure must exist.
+3. Implement `--type` flag on `specfact ide skill install` (small, backwards-compatible addition).
+4. Write and test all 6 skill files against Claude Code, Cursor, and Copilot (minimum 3 agents per config.yaml Minimum Evidence Bar).
+5. Run `specfact ide skill install --type intent` in SpecFact's own dev environment as dogfood proof.
+
+## Open Questions
+
+- None currently blocking implementation.
diff --git a/openspec/changes/ai-integration-04-intent-skills/proposal.md b/openspec/changes/ai-integration-04-intent-skills/proposal.md
new file mode 100644
index 00000000..e1099523
--- /dev/null
+++ b/openspec/changes/ai-integration-04-intent-skills/proposal.md
@@ -0,0 +1,47 @@
+# Change: Intent Engineering Skills — SQUER Workflow for AI IDEs
+
+## Why
+
+AI IDEs generate requirements, architecture, and code but have no structured intent-capture workflow. The result is "green specs, wrong product" — every contract passes but the shipped feature misses the business outcome because no tool validated the upstream intent. `ai-integration-01-agent-skill` ships general spec-validation skills; it does not provide the upstream intent-engineering workflow (7-question business interview, requirements decomposition, architecture derivation, trace validation). A dedicated intent skills set — following the SQUER intent interview model and the open Agent Skills standard — closes this gap by making persona-outcome capture and traceability validation available as first-class IDE slash commands across all 26+ AI IDE platforms.
+
+## What Changes
+
+- **NEW**: Intent-engineering Agent Skills at `skills/specfact-intent/`:
+  - `skills/specfact-intent/SKILL.md` — umbrella intent skills entrypoint; ~80 tokens at rest, full instructions on activation
+  - `skills/specfact-intent-capture/SKILL.md` — SQUER 7-question intent interview: What problem? Who has it? What happens today? What should change? How will we know? What must not break? What's the priority? Captures to `.specfact/requirements/{id}.req.yaml`
+  - `skills/specfact-intent-decompose/SKILL.md` — Takes captured BusinessOutcome, decomposes into BusinessRules (Given/When/Then) and ArchitecturalConstraints
+  - `skills/specfact-intent-architecture/SKILL.md` — Generates Architecture Decision Records from requirements context using `specfact architecture derive`
+  - `skills/specfact-intent-trace-validate/SKILL.md` — Validates full traceability chain (outcome → code), reports gaps with fix prompts
+  - `skills/specfact-intent-evidence-check/SKILL.md` — Checks evidence completeness for all artifacts in the chain
+- **NEW**: `specfact ide skill install --type intent` — copies intent skills to the correct location for the active AI IDE
+- **NEW**: Prompt-validate-feedback loop documentation: pattern for using intent skills with `specfact validate --full-chain` in a 3-phase cycle (prompt → validate → feedback)
+- **EXTEND**: `specfact ide skill install` — adds `--type intent` option alongside existing `--type spec` (ai-integration-01)
+- **EXTEND**: Skills discovery: intent skills listed by `specfact ide skill list`
+
+## Capabilities
+
+### New Capabilities
+
+- `agent-skill-intent-workflow`: SQUER 7-question intent capture skill (~80 tokens at rest), BusinessRule G/W/T decomposition skill, architecture derivation skill, traceability validation skill, and evidence-check skill — all following the open Agent Skills standard for 26+ AI IDE platforms. Installed via `specfact ide skill install --type intent`.
+
+### Modified Capabilities
+
+- `agent-skill-spec-intelligence`: Extended skill discovery and install CLI to support `--type` selector (spec vs intent); `specfact ide skill list` enumerates both skill types.
+
+## Impact
+
+- New directory: `skills/specfact-intent*/` (6 skill files, ~2,000-3,000 tokens each)
+- CLI change: `specfact ide skill install --type {spec,intent}` (new `--type` option, backwards-compatible default `spec`)
+- Depends on: `ai-integration-01-agent-skill` (#251) — must land first; `requirements-01-data-model` (#238) — intent skills invoke `specfact requirements capture`; `requirements-02-module-commands` (#239) — skills call `specfact requirements validate` and `specfact requirements trace`
+- Wave 8 — blocked by ai-integration-01 (#251) and requirements-02 (#239)
+- Docs: new guide `docs/guides/intent-capture-workflow.md`; update `docs/guides/ai-ide-workflow.md` to include intent skills
+
+---
+
+## Source Tracking
+
+<!-- source_repo: nold-ai/specfact-cli -->
+- **GitHub Issue**: #349
+- **Issue URL**: <https://github.com/nold-ai/specfact-cli/issues/349>
+- **Repository**: nold-ai/specfact-cli
+- **Last Synced Status**: proposed
diff --git a/openspec/changes/ai-integration-04-intent-skills/specs/agent-skill-intent-workflow/spec.md b/openspec/changes/ai-integration-04-intent-skills/specs/agent-skill-intent-workflow/spec.md
new file mode 100644
index 00000000..6b95ab81
--- /dev/null
+++ b/openspec/changes/ai-integration-04-intent-skills/specs/agent-skill-intent-workflow/spec.md
@@ -0,0 +1,93 @@
+## ADDED Requirements
+
+### Requirement: Intent Capture Skill
+The system SHALL provide a SQUER-based intent capture Agent Skill at `skills/specfact-intent-capture/SKILL.md` that guides AI agents through a 7-question business intent interview and persists the result to `.specfact/requirements/{id}.req.yaml`.
+
+#### Scenario: Intent capture skill performs SQUER 7-question interview
+- **GIVEN** an AI IDE agent with the `specfact-intent-capture` skill installed
+- **WHEN** the agent activates the intent capture skill
+- **THEN** the skill prompts the user with the 7 SQUER questions in sequence: What problem? Who has it? What happens today? What should change? How will we know? What must not break? What's the priority?
+- **AND** answers are mapped to `BusinessOutcome` fields (description, persona, current_state, target_state, success_criteria, constraints, priority)
+
+#### Scenario: Intent capture produces valid requirement artifact
+- **GIVEN** the SQUER interview is complete with all 7 answers
+- **WHEN** the skill invokes `specfact requirements capture`
+- **THEN** a `.specfact/requirements/{id}.req.yaml` file is created
+- **AND** the artifact validates against the `BusinessOutcome` schema without errors
+
+#### Scenario: Intent capture skill verifies CLI prerequisites
+- **GIVEN** a fresh IDE session before the skill is activated
+- **WHEN** the skill checks prerequisites
+- **THEN** it runs `specfact requirements --help` to verify the requirements module is installed
+- **AND** if the module is missing it directs the agent to install it before proceeding
+
+### Requirement: Requirements Decomposition Skill
+The system SHALL provide a decomposition Agent Skill at `skills/specfact-intent-decompose/SKILL.md` that takes a captured `BusinessOutcome` and decomposes it into `BusinessRule` (Given/When/Then) and `ArchitecturalConstraint` artifacts via `specfact requirements validate`.
+
+#### Scenario: Decomposition skill generates G/W/T business rules
+- **GIVEN** a `.specfact/requirements/{id}.req.yaml` file containing a `BusinessOutcome`
+- **WHEN** the agent activates the intent decompose skill
+- **THEN** the skill prompts the agent to derive at least one `BusinessRule` per success criterion
+- **AND** each rule is expressed in Given/When/Then format and assigned a stable rule ID (BR-NNN)
+
+#### Scenario: Decomposition skill identifies architectural constraints
+- **GIVEN** a decomposition session with at least one business rule defined
+- **WHEN** the skill processes the rules
+- **THEN** it prompts the agent to identify at least one `ArchitecturalConstraint` derived from the constraints field of the `BusinessOutcome`
+- **AND** each constraint is assigned a stable ID (AC-NNN) and linked to the parent `BusinessOutcome`
+
+### Requirement: Architecture Derivation Skill
+The system SHALL provide an architecture derivation Agent Skill at `skills/specfact-intent-architecture/SKILL.md` that invokes `specfact architecture derive` to generate ADRs from captured requirements context.
+
+#### Scenario: Architecture skill generates ADR from requirements
+- **GIVEN** at least one `BusinessRule` and one `ArchitecturalConstraint` in `.specfact/requirements/`
+- **WHEN** the agent activates the architecture derive skill
+- **THEN** the skill invokes `specfact architecture derive --requirement {id}`
+- **AND** an Architecture Decision Record is produced with Context, Decision, and Consequences sections
+- **AND** the ADR includes an explicit link to the `BusinessOutcome` ID and at least one `ArchitecturalConstraint` ID
+
+### Requirement: Trace Validation Skill
+The system SHALL provide a trace validation Agent Skill at `skills/specfact-intent-trace-validate/SKILL.md` that validates the full traceability chain (outcome → rule → constraint → spec → code) and reports gaps with structured fix prompts.
+
+#### Scenario: Trace validation reports complete chain
+- **GIVEN** a project with requirements, specs, and code present
+- **WHEN** the agent activates the trace-validate skill
+- **THEN** the skill invokes `specfact validate --full-chain`
+- **AND** a gap report is produced listing any orphaned artifacts (requirements with no spec link, specs with no test, etc.)
+
+#### Scenario: Trace validation generates fix prompts for gaps
+- **GIVEN** the trace validation finds at least one gap
+- **WHEN** the skill processes the gap report
+- **THEN** it generates a structured fix prompt for each gap type (missing spec, missing test binding, missing requirement link)
+- **AND** the fix prompt references the specific artifact IDs involved
+
+### Requirement: Evidence Check Skill
+The system SHALL provide an evidence-check Agent Skill at `skills/specfact-intent-evidence-check/SKILL.md` that checks evidence completeness for all artifacts in the intent-to-code chain.
+
+#### Scenario: Evidence check reports missing evidence envelopes
+- **GIVEN** a project where some artifacts lack evidence JSON files
+- **WHEN** the agent activates the evidence-check skill
+- **THEN** the skill invokes `specfact validate --full-chain --evidence-dir .specfact/evidence/`
+- **AND** a report lists all artifacts missing evidence envelopes with their IDs and types
+- **AND** the exit code is non-zero if any required evidence is missing in strict mode
+
+### Requirement: Intent Skills Installation
+The system SHALL extend `specfact ide skill install` with a `--type` option so intent skills can be installed independently of spec-validation skills.
+
+#### Scenario: Intent skills installed via CLI
+- **GIVEN** the `specfact ide skill install` command is available (from ai-integration-01)
+- **WHEN** the user runs `specfact ide skill install --type intent`
+- **THEN** all 6 intent skill files are copied to the IDE-appropriate location
+- **AND** the command confirms each skill file was installed successfully
+
+#### Scenario: Existing spec skill install is backwards-compatible
+- **GIVEN** a user running `specfact ide skill install` without the `--type` flag
+- **WHEN** the command executes
+- **THEN** it behaves identically to the pre-change behavior (installs spec skills only)
+- **AND** no error or deprecation warning is emitted
+
+#### Scenario: All skill types installed with --type all
+- **GIVEN** the `--type all` option is used
+- **WHEN** the command executes
+- **THEN** both spec skills (from ai-integration-01) and intent skills are installed
+- **AND** no file is overwritten without a confirmation prompt if conflicts exist
diff --git a/openspec/changes/ai-integration-04-intent-skills/specs/agent-skill-spec-intelligence/spec.md b/openspec/changes/ai-integration-04-intent-skills/specs/agent-skill-spec-intelligence/spec.md
new file mode 100644
index 00000000..5387b879
--- /dev/null
+++ b/openspec/changes/ai-integration-04-intent-skills/specs/agent-skill-spec-intelligence/spec.md
@@ -0,0 +1,16 @@
+## MODIFIED Requirements
+
+### Requirement: Agent Skill Installation
+The system SHALL provide `specfact ide skill install` with a `--type {spec,intent,all}` option to install skill files to the IDE-appropriate location (modified to support skill type selection).
+
+#### Scenario: Spec skill install without --type flag (backwards compatible)
+- **GIVEN** a project with an active AI IDE configuration
+- **WHEN** the user runs `specfact ide skill install` without a `--type` flag
+- **THEN** spec-validation skills (from ai-integration-01) are installed as before
+- **AND** no breaking change occurs to the existing install flow
+
+#### Scenario: Skill list enumerates all available skill types
+- **GIVEN** both spec skills (ai-integration-01) and intent skills (ai-integration-04) are available
+- **WHEN** the user runs `specfact ide skill list`
+- **THEN** both `spec` and `intent` skill types are listed with their descriptions
+- **AND** each skill entry shows its installation status (installed / not installed)
diff --git a/openspec/changes/ai-integration-04-intent-skills/tasks.md b/openspec/changes/ai-integration-04-intent-skills/tasks.md
new file mode 100644
index 00000000..70e05c13
--- /dev/null
+++ b/openspec/changes/ai-integration-04-intent-skills/tasks.md
@@ -0,0 +1,135 @@
+# Tasks: Intent Engineering Skills — SQUER Workflow for AI IDEs
+
+## TDD / SDD order (enforced)
+
+Per `openspec/config.yaml`, tests MUST precede production code for any behavior-changing task.
+
+Order:
+1. Spec deltas (already in `specs/`)
+2. Tests derived from spec scenarios — run and expect failure
+3. Production code — implement until tests pass
+
+Do not implement production code until tests exist and have been run (expecting failure).
+
+---
+
+## 1. Create git worktree for this change
+
+- [ ] 1.1 Fetch latest and create a worktree with a new branch from `origin/dev`.
+  - [ ] 1.1.1 `git fetch origin`
+  - [ ] 1.1.2 `git worktree add ../specfact-cli-worktrees/feature/ai-integration-04-intent-skills -b feature/ai-integration-04-intent-skills origin/dev`
+  - [ ] 1.1.3 `cd ../specfact-cli-worktrees/feature/ai-integration-04-intent-skills`
+  - [ ] 1.1.4 `python -m venv .venv && source .venv/bin/activate && pip install -e ".[dev]"`
+  - [ ] 1.1.5 `git branch --show-current` (verify `feature/ai-integration-04-intent-skills`)
+
+## 2. Write tests for intent skills installation (TDD — expect failure)
+
+- [ ] 2.1 Review `tests/unit/specfact_cli/` for existing ide skill install test patterns
+- [ ] 2.2 Add `tests/unit/specfact_cli/test_intent_skills_install.py`:
+  - [ ] 2.2.1 Test `specfact ide skill install --type intent` installs all 6 skill files
+  - [ ] 2.2.2 Test `specfact ide skill install` (no `--type`) unchanged behaviour
+  - [ ] 2.2.3 Test `specfact ide skill install --type all` installs both spec + intent skills
+  - [ ] 2.2.4 Test `specfact ide skill list` shows both `spec` and `intent` types
+- [ ] 2.3 Add `tests/unit/specfact_cli/test_intent_skills_content.py`:
+  - [ ] 2.3.1 Test each skill file exists in the skills/ directory after install
+  - [ ] 2.3.2 Test each skill file has valid YAML frontmatter (name, description, allowed-tools)
+- [ ] 2.4 Run tests — expect failure: `hatch test -- tests/unit/specfact_cli/test_intent_skills*.py -v`
+- [ ] 2.5 Record failing test evidence in `TDD_EVIDENCE.md`
+
+## 3. Implement intent skill files
+
+- [ ] 3.1 Create `skills/specfact-intent/SKILL.md` — umbrella router skill (~80 tokens at rest)
+  - [ ] 3.1.1 YAML frontmatter: `name: specfact-intent`, `description`, `allowed-tools: [bash, terminal]`
+  - [ ] 3.1.2 Brief activation instructions: detect intent-related tasks, load appropriate sub-skill
+- [ ] 3.2 Create `skills/specfact-intent-capture/SKILL.md` — SQUER 7-question interview
+  - [ ] 3.2.1 YAML frontmatter with activation description
+  - [ ] 3.2.2 Exact SQUER 7 questions: What problem? Who has it? What happens today? What should change? How will we know? What must not break? What's the priority?
+  - [ ] 3.2.3 Mapping table: each question → `BusinessOutcome` field
+  - [ ] 3.2.4 CLI invocation: `specfact requirements capture` with YAML output path
+  - [ ] 3.2.5 Prerequisite check block (verify `specfact requirements --help` succeeds)
+- [ ] 3.3 Create `skills/specfact-intent-decompose/SKILL.md` — G/W/T decomposition
+  - [ ] 3.3.1 YAML frontmatter
+  - [ ] 3.3.2 Instructions: take BusinessOutcome → derive BusinessRules (BR-NNN, G/W/T) + ArchitecturalConstraints (AC-NNN)
+  - [ ] 3.3.3 CLI invocation: `specfact requirements validate` for schema check
+- [ ] 3.4 Create `skills/specfact-intent-architecture/SKILL.md` — ADR generation
+  - [ ] 3.4.1 YAML frontmatter
+  - [ ] 3.4.2 Instructions: invoke `specfact architecture derive --requirement {id}`, produce ADR with BO/AC links
+- [ ] 3.5 Create `skills/specfact-intent-trace-validate/SKILL.md` — traceability gap validation
+  - [ ] 3.5.1 YAML frontmatter
+  - [ ] 3.5.2 Instructions: invoke `specfact validate --full-chain`, parse gap report, generate fix prompts per gap type
+- [ ] 3.6 Create `skills/specfact-intent-evidence-check/SKILL.md` — evidence completeness check
+  - [ ] 3.6.1 YAML frontmatter
+  - [ ] 3.6.2 Instructions: invoke `specfact validate --full-chain --evidence-dir .specfact/evidence/`, report missing envelopes
+
+## 4. Implement `--type` flag on `specfact ide skill install`
+
+- [ ] 4.1 Locate `specfact ide skill install` command (from ai-integration-01 module)
+- [ ] 4.2 Add `--type` option: `Literal["spec", "intent", "all"]`, default `"spec"`
+- [ ] 4.3 Implement intent skill install path: copy `skills/specfact-intent*/SKILL.md` to IDE location
+- [ ] 4.4 Add `@require` contract: type must be one of the valid values; `@beartype` on all new params
+- [ ] 4.5 Update `specfact ide skill list` to enumerate all skill types with install status
+
+## 5. Passing tests and quality gates
+
+- [ ] 5.1 Run tests — expect passing: `hatch test -- tests/unit/specfact_cli/test_intent_skills*.py -v`
+- [ ] 5.2 Record passing test evidence in `TDD_EVIDENCE.md`
+- [ ] 5.3 `hatch run format`
+- [ ] 5.4 `hatch run type-check`
+- [ ] 5.5 `hatch run lint`
+- [ ] 5.6 `hatch run yaml-lint`
+- [ ] 5.7 `hatch run contract-test`
+- [ ] 5.8 `hatch run smart-test`
+- [ ] 5.9 Module signing: `hatch run ./scripts/verify-modules-signature.py --require-signature`; re-sign if any module changed
+
+## 6. Documentation
+
+- [ ] 6.1 Create `docs/guides/intent-capture-workflow.md`:
+  - [ ] 6.1.1 Jekyll front-matter (layout, title, permalink, description, nav_order, parent)
+  - [ ] 6.1.2 Sections: Overview, Prerequisites, SQUER interview pattern, Installing intent skills, Workflow walkthrough, Prompt-validate-feedback loop
+- [ ] 6.2 Update `docs/guides/ai-ide-workflow.md` — add Intent Skills section linking to new guide
+- [ ] 6.3 Update `docs/_layouts/default.html` sidebar navigation — add `intent-capture-workflow` under Guides
+
+## 7. Version and changelog
+
+- [ ] 7.1 Bump minor version in `pyproject.toml`, `setup.py`, `src/__init__.py`, `src/specfact_cli/__init__.py`
+- [ ] 7.2 Add CHANGELOG.md entry under new `[X.Y.Z] - 2026-XX-XX` with Added section
+
+## 8. GitHub issue creation
+
+- [ ] 8.1 Create GitHub issue:
+  ```bash
+  gh issue create \
+    --repo nold-ai/specfact-cli \
+    --title "[Change] Intent Engineering Skills — SQUER Workflow for AI IDEs" \
+    --body-file /tmp/github-issue-ai-integration-04.md \
+    --label "enhancement" \
+    --label "change-proposal"
+  ```
+- [ ] 8.2 Link issue to project: `gh project item-add 1 --owner nold-ai --url <ISSUE_URL>`
+- [ ] 8.3 Update `proposal.md` Source Tracking section with issue number and URL
+- [ ] 8.4 Link branch to issue: `gh issue develop <issue-number> --repo nold-ai/specfact-cli --name feature/ai-integration-04-intent-skills`
+
+## 9. Pull request
+
+- [ ] 9.1 `git add` all changed files; commit with `feat: add SQUER intent engineering skills for AI IDEs`
+- [ ] 9.2 `git push -u origin feature/ai-integration-04-intent-skills`
+- [ ] 9.3 Create PR:
+  ```bash
+  gh pr create \
+    --repo nold-ai/specfact-cli \
+    --base dev \
+    --head feature/ai-integration-04-intent-skills \
+    --title "feat: SQUER intent engineering skills for AI IDEs" \
+    --body-file /tmp/pr-body-ai-integration-04.md
+  ```
+- [ ] 9.4 Link PR to project: `gh project item-add 1 --owner nold-ai --url <PR_URL>`
+- [ ] 9.5 Set project status to "In Progress"
+
+## Post-merge cleanup (after PR is merged)
+
+- [ ] Return to primary checkout: `cd .../specfact-cli`
+- [ ] `git fetch origin`
+- [ ] `git worktree remove ../specfact-cli-worktrees/feature/ai-integration-04-intent-skills`
+- [ ] `git branch -d feature/ai-integration-04-intent-skills`
+- [ ] `git worktree prune`
+- [ ] (Optional) `git push origin --delete feature/ai-integration-04-intent-skills`
diff --git a/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/.openspec.yaml b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/.openspec.yaml
new file mode 100644
index 00000000..8f0b8699
--- /dev/null
+++ b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-03-05
diff --git a/openspec/changes/docs-01-core-modules-docs-alignment/CHANGE_VALIDATION.md b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/CHANGE_VALIDATION.md
similarity index 55%
rename from openspec/changes/docs-01-core-modules-docs-alignment/CHANGE_VALIDATION.md
rename to openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/CHANGE_VALIDATION.md
index 8c1f010e..5b6aacde 100644
--- a/openspec/changes/docs-01-core-modules-docs-alignment/CHANGE_VALIDATION.md
+++ b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/CHANGE_VALIDATION.md
@@ -43,6 +43,29 @@ Results:
 - `openspec status` => all required artifacts complete
 - `openspec validate ... --strict` => **Change 'docs-01-core-modules-docs-alignment' is valid**
 
+## Implementation Validation
+
+Commands executed:
+
+```bash
+/bin/bash -lc 'HATCH_DATA_DIR=/tmp/hatch-data HATCH_CACHE_DIR=/tmp/hatch-cache VIRTUALENV_OVERRIDE_APP_DATA=/tmp/virtualenv-appdata hatch run pytest tests/unit/docs/test_release_docs_parity.py -q'
+/bin/bash -lc 'HATCH_DATA_DIR=/tmp/hatch-data HATCH_CACHE_DIR=/tmp/hatch-cache VIRTUALENV_OVERRIDE_APP_DATA=/tmp/virtualenv-appdata hatch run yaml-lint'
+```
+
+Results:
+
+- `pytest tests/unit/docs/test_release_docs_parity.py -q` => **7 passed**
+- `pytest tests/unit/scripts/test_pre_commit_smart_checks_docs.py -q` => **3 passed**
+- `hatch run yaml-lint` => **pass**
+
+## Implementation Notes
+
+- A full live-docs inventory was recorded in `DOCS_AUDIT_INVENTORY.md`.
+- Command examples across live Markdown were normalized to grouped command paths while keeping intentional migration-history pages intact.
+- Entry-point docs, marketplace/install/publish docs, architecture/reference docs, and bundle-specific guides were aligned to the lean-core plus `specfact-cli-modules` ownership model.
+- `scripts/pre-commit-smart-checks.sh` now runs `markdownlint --fix` (or `npx markdownlint-cli --fix`) before the existing markdown lint gate and re-stages changed Markdown files automatically.
+- The markdown auto-fix path now fails fast when a staged Markdown file also has unstaged hunks, preserving partial staging boundaries instead of broadening the commit.
+
 ## Outcome
 
-The change is apply-ready. Implementation can proceed with a full Markdown inventory, spec-first docs alignment, and final validation of navigation and docs parity.
+The change implementation is complete and validated locally. It is ready for PR review and later archive once repo workflow expectations are satisfied.
diff --git a/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/DOCS_AUDIT_INVENTORY.md b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/DOCS_AUDIT_INVENTORY.md
new file mode 100644
index 00000000..50a94010
--- /dev/null
+++ b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/DOCS_AUDIT_INVENTORY.md
@@ -0,0 +1,135 @@
+# Docs Audit Inventory
+
+Live first-party Markdown reviewed for `docs-01-core-modules-docs-alignment`.
+
+## Excluded From Live Audit
+
+- `docs/_site/**` (generated site output)
+- `docs/vendor/**` (vendored third-party content)
+- `openspec/changes/archive/**` (historical OpenSpec records)
+
+## Reviewed Files (121)
+
+| Path | Classification | Notes |
+|---|---|---|
+| `README.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/LICENSE.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/README.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/TRADEMARKS.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/adapters/azuredevops.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/adapters/backlog-adapter-patterns.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/adapters/github.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/architecture/README.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/architecture/adr/0001-module-first-architecture.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/architecture/adr/README.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/architecture/adr/template.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/architecture/component-graph.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/architecture/data-flow.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/architecture/discrepancies-report.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/architecture/implementation-status.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/architecture/interface-contracts.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/architecture/module-system.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/architecture/state-machines.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/contributing/github-project-gh-cli.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/examples/README.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/examples/brownfield-data-pipeline.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/examples/brownfield-django-modernization.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/examples/brownfield-flask-api.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/examples/dogfooding-specfact-cli.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/examples/integration-showcases/README.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/examples/integration-showcases/integration-showcases-quick-reference.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/examples/integration-showcases/integration-showcases-testing-guide.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/examples/integration-showcases/integration-showcases.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/examples/quick-examples.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/getting-started/README.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/getting-started/first-steps.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/getting-started/installation.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/getting-started/module-bootstrap-checklist.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/getting-started/tutorial-backlog-quickstart-demo.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/getting-started/tutorial-backlog-refine-ai-ide.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/getting-started/tutorial-daily-standup-sprint-review.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/getting-started/tutorial-openspec-speckit.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/README.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/guides/adapter-development.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/agile-scrum-workflows.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/ai-ide-workflow.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/backlog-delta-commands.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/guides/backlog-dependency-analysis.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/guides/backlog-refinement.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/guides/brownfield-engineer.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/brownfield-faq.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/brownfield-journey.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/brownfield-roi.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/command-chains.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/common-tasks.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/competitive-analysis.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/contract-testing-workflow.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/guides/copilot-mode.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/creating-custom-bridges.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/custom-field-mapping.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/guides/custom-registries.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/devops-adapter-integration.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/guides/dual-stack-enrichment.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/guides/extending-projectbundle.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/ide-integration.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/import-features.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/guides/installation.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/installing-modules.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/guides/integrations-overview.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/marketplace.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/guides/migration-0.16-to-0.19.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/guides/migration-cli-reorganization.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/guides/migration-guide.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/guides/module-development.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/guides/module-marketplace.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/guides/module-signing-and-key-rotation.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/openspec-journey.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/policy-engine-commands.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/guides/project-devops-flow.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/guides/publishing-modules.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/guides/sidecar-validation.md` | `module-owned-temporary` | Bundle-specific workflow guidance still hosted in core docs until migration to specfact-cli-modules. |
+| `docs/guides/speckit-comparison.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/speckit-journey.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/specmatic-integration.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/team-collaboration-workflow.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/template-customization.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/testing-terminal-output.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/troubleshooting.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/use-cases.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/using-module-security-and-extensions.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/ux-features.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/guides/workflows.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/index.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/installation/enhanced-analysis-dependencies.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/openspec-opsx-migration.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/plans/ci-pr-orchestrator-log-artifacts.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/project-plans/speckit-test/architect.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/project-plans/speckit-test/developer.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/project-plans/speckit-test/product-owner.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/prompts/PROMPT_VALIDATION_CHECKLIST.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/prompts/README.md` | `historical-or-example` | Historical, example, or supporting material reviewed for command drift but not primary runtime reference. |
+| `docs/reference/README.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/reference/architecture.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/reference/authentication.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/reference/bridge-registry.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/reference/command-syntax-policy.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/reference/commands.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/reference/debug-logging.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/reference/dependency-resolution.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/reference/directory-structure.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/reference/feature-keys.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/reference/modes.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/reference/module-categories.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/reference/module-contracts.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/reference/module-security.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/reference/parameter-standard.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/reference/projectbundle-schema.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/reference/schema-versioning.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/reference/specmatic.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/reference/telemetry.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/reference/thorough-codebase-validation.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/technical/README.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
+| `docs/technical/code2spec-analysis-logic.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/technical/dual-stack-pattern.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/technical/testing.md` | `shared` | Shared reference, architecture, or supporting docs reviewed for architecture and command alignment. |
+| `docs/validation-integration.md` | `core-owned` | Entry, lifecycle, marketplace, architecture, and shared runtime guidance owned by specfact-cli core. |
diff --git a/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/IMPLEMENTATION_SUMMARY.md b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/IMPLEMENTATION_SUMMARY.md
new file mode 100644
index 00000000..2871454e
--- /dev/null
+++ b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/IMPLEMENTATION_SUMMARY.md
@@ -0,0 +1,23 @@
+# Implementation Summary: docs-01-core-modules-docs-alignment
+
+## Audited coverage
+
+- Root entrypoints: `README.md`, `docs/index.md`, `docs/README.md`
+- Navigation and information architecture: `docs/_layouts/default.html`, command/reference landing pages
+- Marketplace and lifecycle docs: install, marketplace, publishing, signing, trust, dependency resolution
+- Architecture and ownership docs: architecture reference, implementation status, directory structure, module contracts
+- Bundle-focused guides/tutorials/adapters: backlog, DevOps, ADO/GitHub, policy, refinement, sidecar, contract workflow
+
+## Notable corrections
+
+- Replaced stale flat-command examples across live docs with grouped command paths (`project`, `backlog`, `code`, `spec`, `govern`) while preserving explicit migration tables that intentionally document removed commands.
+- Added/standardized temporary-hosting notes on bundle-specific pages still published from the core docs site.
+- Corrected post-migration ownership language so official workflow bundle implementation and publishing point to `nold-ai/specfact-cli-modules`.
+- Updated publishing docs to describe the current protected-branch-safe `publish-modules.yml` behavior in the modules repository.
+- Corrected invalid config/path examples introduced during earlier bulk edits (for example `.specfact/backlog-config.yaml`, `.specfact/backlog.yaml`, `.specfact/backlog-baseline.json`).
+- Added lightweight docs parity tests for the post-migration command surface and docs-hosting expectations.
+
+## Follow-up items
+
+- Move bundle-specific guides from the core docs set to the future `specfact-cli-modules` docs site once that site becomes the canonical bundle-docs home.
+- Mirror the final corrected pages from `specfact-cli` into `specfact-cli-modules` where the modules repo already carries temporary docs copies.
diff --git a/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/TDD_EVIDENCE.md b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/TDD_EVIDENCE.md
new file mode 100644
index 00000000..76d299dc
--- /dev/null
+++ b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/TDD_EVIDENCE.md
@@ -0,0 +1,77 @@
+# TDD Evidence: docs-01-core-modules-docs-alignment
+
+## Pre-implementation failing run
+
+- Timestamp: 2026-03-05
+- Command:
+
+```bash
+/bin/bash -lc 'HATCH_DATA_DIR=/tmp/hatch-data HATCH_CACHE_DIR=/tmp/hatch-cache VIRTUALENV_OVERRIDE_APP_DATA=/tmp/virtualenv-appdata hatch run pytest tests/unit/docs/test_release_docs_parity.py -q'
+```
+
+- Result: failed (`3 failed, 4 passed`)
+- Failure summary:
+  - `docs/getting-started/module-bootstrap-checklist.md` still used stale `backlog-core` install/uninstall examples.
+  - `docs/guides/publishing-modules.md` still described the old tag-driven publish flow instead of the decoupled `specfact-cli-modules` branch workflow.
+  - `docs/reference/module-contracts.md` still described the pre-migration ownership boundary and module location.
+
+## Post-implementation passing run
+
+- Timestamp: 2026-03-05
+- Command:
+
+```bash
+/bin/bash -lc 'HATCH_DATA_DIR=/tmp/hatch-data HATCH_CACHE_DIR=/tmp/hatch-cache VIRTUALENV_OVERRIDE_APP_DATA=/tmp/virtualenv-appdata hatch run pytest tests/unit/docs/test_release_docs_parity.py -q'
+```
+
+- Result: passed (`7 passed`)
+
+## Pre-implementation failing run: markdown auto-fix hook regression
+
+- Timestamp: 2026-03-05
+- Command:
+
+```bash
+/bin/bash -lc 'HATCH_DATA_DIR=/tmp/hatch-data HATCH_CACHE_DIR=/tmp/hatch-cache VIRTUALENV_OVERRIDE_APP_DATA=/tmp/virtualenv-appdata hatch run pytest tests/unit/scripts/test_pre_commit_smart_checks_docs.py -q'
+```
+
+- Result: failed (`2 failed`)
+- Failure summary:
+  - `scripts/pre-commit-smart-checks.sh` did not run a markdown auto-fix stage before `markdownlint`.
+  - The hook did not re-stage Markdown files after auto-fix changes.
+
+## Post-implementation passing run: markdown auto-fix hook regression
+
+- Timestamp: 2026-03-05
+- Command:
+
+```bash
+/bin/bash -lc 'HATCH_DATA_DIR=/tmp/hatch-data HATCH_CACHE_DIR=/tmp/hatch-cache VIRTUALENV_OVERRIDE_APP_DATA=/tmp/virtualenv-appdata hatch run pytest tests/unit/scripts/test_pre_commit_smart_checks_docs.py -q'
+```
+
+- Result: passed (`2 passed`)
+
+## Pre-implementation failing run: markdown partial-staging safeguard
+
+- Timestamp: 2026-03-06
+- Command:
+
+```bash
+/bin/bash -lc 'HATCH_DATA_DIR=/tmp/hatch-data HATCH_CACHE_DIR=/tmp/hatch-cache VIRTUALENV_OVERRIDE_APP_DATA=/tmp/virtualenv-appdata hatch run pytest tests/unit/scripts/test_pre_commit_smart_checks_docs.py -q'
+```
+
+- Result: failed (`1 failed, 2 passed`)
+- Failure summary:
+  - `scripts/pre-commit-smart-checks.sh` re-staged Markdown after auto-fix without checking for unstaged hunks in the same file.
+  - This could silently collapse partial staging and include unintended Markdown edits in the commit.
+
+## Post-implementation passing run: markdown partial-staging safeguard
+
+- Timestamp: 2026-03-06
+- Command:
+
+```bash
+/bin/bash -lc 'HATCH_DATA_DIR=/tmp/hatch-data HATCH_CACHE_DIR=/tmp/hatch-cache VIRTUALENV_OVERRIDE_APP_DATA=/tmp/virtualenv-appdata hatch run pytest tests/unit/scripts/test_pre_commit_smart_checks_docs.py -q'
+```
+
+- Result: passed (`3 passed`)
diff --git a/openspec/changes/docs-01-core-modules-docs-alignment/design.md b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/design.md
similarity index 100%
rename from openspec/changes/docs-01-core-modules-docs-alignment/design.md
rename to openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/design.md
diff --git a/openspec/changes/docs-01-core-modules-docs-alignment/proposal.md b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/proposal.md
similarity index 97%
rename from openspec/changes/docs-01-core-modules-docs-alignment/proposal.md
rename to openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/proposal.md
index 63dd3620..7dc56f75 100644
--- a/openspec/changes/docs-01-core-modules-docs-alignment/proposal.md
+++ b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/proposal.md
@@ -35,7 +35,8 @@ The documentation set still carries drift from the pre-modularized CLI: some pag
 ## Source Tracking
 
 <!-- source_repo: nold-ai/specfact-cli -->
-- **GitHub Issue**: TBD
+- **GitHub Issue**: #348
+- **Issue URL**: <https://github.com/nold-ai/specfact-cli/issues/348>
 - **Repository**: nold-ai/specfact-cli
-- **Last Synced Status**: local-change-created
+- **Last Synced Status**: proposed
 - **Sanitized**: false
diff --git a/openspec/changes/docs-01-core-modules-docs-alignment/specs/documentation-alignment/spec.md b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/specs/documentation-alignment/spec.md
similarity index 75%
rename from openspec/changes/docs-01-core-modules-docs-alignment/specs/documentation-alignment/spec.md
rename to openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/specs/documentation-alignment/spec.md
index ffa71c0a..5f9f2279 100644
--- a/openspec/changes/docs-01-core-modules-docs-alignment/specs/documentation-alignment/spec.md
+++ b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/specs/documentation-alignment/spec.md
@@ -25,3 +25,12 @@ The command reference documentation SHALL distinguish permanent core commands fr
 - **THEN** the reference identifies which commands belong to core and which are provided by installed bundles
 - **AND** bundle command coverage is grouped by category or package boundary
 - **AND** readers can navigate from command docs to the relevant marketplace/module docs without ambiguity
+
+### Requirement: Markdown quality workflow auto-fixes low-risk issues before enforcement
+The documentation workflow SHALL automatically fix low-risk Markdown issues during pre-commit checks before enforcing markdown lint failures for non-fixable or higher-risk issues.
+
+#### Scenario: Contributor stages Markdown changes with trivial spacing issues
+- **WHEN** a contributor stages Markdown files and runs the repository pre-commit checks
+- **THEN** the workflow attempts safe markdown auto-fixes first using the configured markdown lint tooling
+- **AND** any auto-fixed Markdown files are re-staged automatically
+- **AND** markdown lint still runs afterward to fail on remaining non-fixable issues
diff --git a/openspec/changes/docs-01-core-modules-docs-alignment/specs/implementation-status-docs/spec.md b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/specs/implementation-status-docs/spec.md
similarity index 100%
rename from openspec/changes/docs-01-core-modules-docs-alignment/specs/implementation-status-docs/spec.md
rename to openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/specs/implementation-status-docs/spec.md
diff --git a/openspec/changes/docs-01-core-modules-docs-alignment/specs/module-development-guide/spec.md b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/specs/module-development-guide/spec.md
similarity index 100%
rename from openspec/changes/docs-01-core-modules-docs-alignment/specs/module-development-guide/spec.md
rename to openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/specs/module-development-guide/spec.md
diff --git a/openspec/changes/docs-01-core-modules-docs-alignment/specs/module-docs-ownership/spec.md b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/specs/module-docs-ownership/spec.md
similarity index 100%
rename from openspec/changes/docs-01-core-modules-docs-alignment/specs/module-docs-ownership/spec.md
rename to openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/specs/module-docs-ownership/spec.md
diff --git a/openspec/changes/docs-01-core-modules-docs-alignment/tasks.md b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/tasks.md
similarity index 57%
rename from openspec/changes/docs-01-core-modules-docs-alignment/tasks.md
rename to openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/tasks.md
index 4b4527d0..b73eef0c 100644
--- a/openspec/changes/docs-01-core-modules-docs-alignment/tasks.md
+++ b/openspec/changes/archive/2026-03-05-docs-01-core-modules-docs-alignment/tasks.md
@@ -1,40 +1,41 @@
 ## 1. Scope Inventory and Audit Baseline
 
-- [ ] 1.1 Create a complete inventory of live first-party Markdown docs to review (`README.md` and `docs/**`), explicitly excluding generated `_site`, vendored content, and archived OpenSpec artifacts.
-- [ ] 1.2 Classify each reviewed document as core-owned, module-owned-but-temporarily-hosted, shared, historical, or out-of-scope generated/vendor content.
-- [ ] 1.3 Record the audit baseline and target file groups in a working artifact within this change folder.
-- [ ] 1.4 Update `openspec/CHANGE_ORDER.md` with this new docs alignment change in the appropriate table/wave section.
+- [x] 1.1 Create a complete inventory of live first-party Markdown docs to review (`README.md` and `docs/**`), explicitly excluding generated `_site`, vendored content, and archived OpenSpec artifacts.
+- [x] 1.2 Classify each reviewed document as core-owned, module-owned-but-temporarily-hosted, shared, historical, or out-of-scope generated/vendor content.
+- [x] 1.3 Record the audit baseline and target file groups in a working artifact within this change folder.
+- [x] 1.4 Update `openspec/CHANGE_ORDER.md` with this new docs alignment change in the appropriate table/wave section.
 
 ## 2. Entry Points and Information Architecture
 
-- [ ] 2.1 Review and update `README.md` so the top-level product story, install flow, and command examples reflect lean core plus marketplace-installed bundles.
-- [ ] 2.2 Review and update `docs/index.md` and `docs/README.md` so landing-page guidance matches the current core/module architecture.
-- [ ] 2.3 Add consistent docs-ownership language explaining that module-specific docs are temporarily hosted in core and will migrate to `specfact-cli-modules`.
-- [ ] 2.4 Update navigation/cross-links in `docs/_layouts/default.html` and affected page links so marketplace, module categories, and command-reference pages are discoverable.
+- [x] 2.1 Review and update `README.md` so the top-level product story, install flow, and command examples reflect lean core plus marketplace-installed bundles.
+- [x] 2.2 Review and update `docs/index.md` and `docs/README.md` so landing-page guidance matches the current core/module architecture.
+- [x] 2.3 Add consistent docs-ownership language explaining that module-specific docs are temporarily hosted in core and will migrate to `specfact-cli-modules`.
+- [x] 2.4 Update navigation/cross-links in `docs/_layouts/default.html` and affected page links so marketplace, module categories, and command-reference pages are discoverable.
 
 ## 3. Command and Marketplace Documentation Alignment
 
-- [ ] 3.1 Review and update command reference docs so core commands are separated from marketplace-delivered bundle commands.
-- [ ] 3.2 Review and update marketplace/install/publish/trust/signing docs for consistency across guides and reference pages.
-- [ ] 3.3 Review and update getting-started and tutorial docs so command examples use current grouped command paths and installation expectations.
-- [ ] 3.4 Review and update module category, module contract, and module security docs to reflect current bundle/package boundaries and ownership.
+- [x] 3.1 Review and update command reference docs so core commands are separated from marketplace-delivered bundle commands.
+- [x] 3.2 Review and update marketplace/install/publish/trust/signing docs for consistency across guides and reference pages.
+- [x] 3.3 Review and update getting-started and tutorial docs so command examples use current grouped command paths and installation expectations.
+- [x] 3.4 Review and update module category, module contract, and module security docs to reflect current bundle/package boundaries and ownership.
 
 ## 4. Architecture, Directory, and Dependency Documentation Alignment
 
-- [ ] 4.1 Review and update architecture pages to describe the lean core, dedicated modules repository, and current ownership split accurately.
-- [ ] 4.2 Review and update `docs/reference/directory-structure.md` and related structure docs to reflect the post-migration repository layout.
-- [ ] 4.3 Review and update `docs/reference/dependency-resolution.md` and related dependency docs to match marketplace-installed official bundle behavior.
-- [ ] 4.4 Review and update module development guidance so contributors are directed to the correct repository and documentation ownership model.
+- [x] 4.1 Review and update architecture pages to describe the lean core, dedicated modules repository, and current ownership split accurately.
+- [x] 4.2 Review and update `docs/reference/directory-structure.md` and related structure docs to reflect the post-migration repository layout.
+- [x] 4.3 Review and update `docs/reference/dependency-resolution.md` and related dependency docs to match marketplace-installed official bundle behavior.
+- [x] 4.4 Review and update module development guidance so contributors are directed to the correct repository and documentation ownership model.
 
 ## 5. Module-Specific Guides and Adapter Docs
 
-- [ ] 5.1 Review all module-focused guides, adapters, and workflow/tutorial pages for stale flat-command instructions or wrong ownership assumptions.
-- [ ] 5.2 Add or standardize temporary-hosting migration notes on pages that are bundle-specific but still live in the core docs set.
-- [ ] 5.3 Remove or rewrite duplicate command inventories so package/category-specific docs point to the correct canonical pages.
+- [x] 5.1 Review all module-focused guides, adapters, and workflow/tutorial pages for stale flat-command instructions or wrong ownership assumptions.
+- [x] 5.2 Add or standardize temporary-hosting migration notes on pages that are bundle-specific but still live in the core docs set.
+- [x] 5.3 Remove or rewrite duplicate command inventories so package/category-specific docs point to the correct canonical pages.
 
 ## 6. Validation and Closeout
 
-- [ ] 6.1 Add or update lightweight docs parity validation/tests where practical for command-surface and ownership-note expectations.
-- [ ] 6.2 Run required validation for the docs set (`openspec validate ... --strict`, markdown/yaml/docs checks, and any targeted tests) and capture results in `CHANGE_VALIDATION.md` and `TDD_EVIDENCE.md` where applicable.
-- [ ] 6.3 Update `CHANGELOG.md` if the documentation reorganization materially changes user guidance for the pending `0.40.0` release notes.
-- [ ] 6.4 Prepare PR-ready summary notes describing audited coverage, notable doc corrections, and remaining follow-up items for eventual docs migration to `specfact-cli-modules`.
+- [x] 6.1 Add or update lightweight docs parity validation/tests where practical for command-surface and ownership-note expectations.
+- [x] 6.2 Run required validation for the docs set (`openspec validate ... --strict`, markdown/yaml/docs checks, and any targeted tests) and capture results in `CHANGE_VALIDATION.md` and `TDD_EVIDENCE.md` where applicable.
+- [x] 6.3 Update `CHANGELOG.md` if the documentation reorganization materially changes user guidance for the pending `0.40.0` release notes.
+- [x] 6.4 Prepare PR-ready summary notes describing audited coverage, notable doc corrections, and remaining follow-up items for eventual docs migration to `specfact-cli-modules`.
+- [x] 6.5 Update the pre-commit Markdown workflow so low-risk issues are auto-fixed and re-staged before markdown lint enforcement, with regression coverage for the hook behavior.
diff --git a/openspec/changes/governance-01-evidence-output/specs/governance-evidence-output/oscal-trace-delta.md b/openspec/changes/governance-01-evidence-output/specs/governance-evidence-output/oscal-trace-delta.md
new file mode 100644
index 00000000..89a5ea4a
--- /dev/null
+++ b/openspec/changes/governance-01-evidence-output/specs/governance-evidence-output/oscal-trace-delta.md
@@ -0,0 +1,33 @@
+## ADDED Requirements
+
+### Requirement: OSCAL-Aligned Evidence Envelope with Trace Fields
+The system SHALL extend the governance evidence JSON envelope to include a `trace` object with `upstream` and `downstream` arrays, aligned with OSCAL Assessment Results model patterns, enabling bidirectional artifact navigation from any evidence record.
+
+#### Scenario: Evidence envelope contains trace links for requirement-level artifacts
+- **GIVEN** a `BusinessRule` artifact that was validated by SpecFact
+- **WHEN** the governance evidence envelope is generated for that artifact
+- **THEN** the evidence JSON includes a `trace` object:
+  - `trace.upstream` contains the parent `BusinessOutcome` ID(s)
+  - `trace.downstream` contains at least one of: spec ID, contract ID, or test ID linked to the rule
+- **AND** the envelope validates against the updated evidence schema
+
+#### Scenario: Evidence envelope captures per-check results
+- **GIVEN** a validation run that checks schema_conformance, gwt_parseable, example_bound, and outcome_linked
+- **WHEN** the evidence envelope is emitted
+- **THEN** the `validation.checks` array contains one entry per check with `name`, `result` (pass/fail/error), and optional metadata fields (e.g., `test_id`, `outcome_id`)
+- **AND** the overall `verdict` field is derivable from the check results without re-running validation
+
+#### Scenario: OSCAL-aligned structure for compliance consumers
+- **GIVEN** a governance evidence JSON file produced by SpecFact
+- **WHEN** it is consumed by an OSCAL Assessment Results reader
+- **THEN** the `validation.verdict` field maps to OSCAL's `finding.target.status` (pass/fail/not-applicable)
+- **AND** the `artifact.hash` field provides the `subject.resource-id` equivalent for audit traceability
+
+### Requirement: Artifact Hash in Evidence Envelope
+The system SHALL include a SHA-256 hash of the validated artifact in every evidence envelope, enabling immutable audit trail construction.
+
+#### Scenario: Artifact hash computed and included in evidence
+- **GIVEN** a requirement artifact file at `.specfact/requirements/BR-001.req.yaml`
+- **WHEN** `specfact validate --full-chain --evidence-dir .specfact/evidence/` runs
+- **THEN** the evidence envelope for BR-001 includes `artifact.hash: "sha256:<hex>"`
+- **AND** the hash is computed from the file contents at the time of validation (not from a prior snapshot)
diff --git a/openspec/changes/openspec-01-intent-trace/.openspec.yaml b/openspec/changes/openspec-01-intent-trace/.openspec.yaml
new file mode 100644
index 00000000..8f0b8699
--- /dev/null
+++ b/openspec/changes/openspec-01-intent-trace/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-03-05
diff --git a/openspec/changes/openspec-01-intent-trace/CHANGE_VALIDATION.md b/openspec/changes/openspec-01-intent-trace/CHANGE_VALIDATION.md
new file mode 100644
index 00000000..52126942
--- /dev/null
+++ b/openspec/changes/openspec-01-intent-trace/CHANGE_VALIDATION.md
@@ -0,0 +1,110 @@
+# Change Validation Report: openspec-01-intent-trace
+
+**Validation Date**: 2026-03-05
+**Change Proposal**: [proposal.md](./proposal.md)
+**Validation Method**: Dry-run simulation — codebase interface analysis + temporary workspace
+**Source Plan**: `specfact-cli-internal/docs/internal/implementation/2026-03-05-CLAUDE-RESEARCH-INTENT-DRIVEN-DEVELOPMENT.md`
+
+## Executive Summary
+
+- Breaking Changes: 0 detected
+- Dependent Files: 3 files affected (additive, non-breaking)
+- Impact Level: Low-Medium (extends existing adapter with optional new capability)
+- Validation Result: **Pass**
+- User Decision: N/A
+- Implementation Constraint Identified: 1 (beartype type-annotation — implementation note, not a blocker)
+
+## Breaking Changes Detected
+
+None. All interface extensions are additive and optional:
+- `parse_change_proposal()` returns `dict[str, Any]` — adding optional `"intent_trace"` key is non-breaking
+- `--import-intent` CLI flag has no default effect (opt-in)
+- New files (`intent_trace_validator.py`, `intent-trace.schema.json`) have no existing callers
+
+## Implementation Constraint (Non-Breaking)
+
+**Constraint**: `_parse_proposal_content()` at `openspec_parser.py:335` has type annotation `dict[str, str]` (return type). If intent trace data (a nested dict) were added here, `@beartype` would raise a type error.
+
+**Required implementation approach**: Intent trace extraction MUST be done in `parse_change_proposal()` (returns `dict[str, Any]`) by:
+1. Calling `_parse_proposal_content(content)` as usual → returns `dict[str, str]`
+2. Separately extracting the YAML fenced block under `## Intent Trace` from `content`
+3. Parsing with `yaml.safe_load()` and assigning to `result["intent_trace"]`
+4. `parse_change_proposal()` return dict is `dict[str, Any]` — no type violation
+
+The task at step 5.2 ("Add `## Intent Trace` section parser") should be executed in `parse_change_proposal()`, not in `_parse_proposal_content()`. This is an implementation detail — recommend adding a note to `tasks.md`.
+
+## Dependencies Affected
+
+### Critical (hard blockers — must land before `--import-intent` write path)
+
+| Dependency | Issue | Status |
+|---|---|---|
+| `requirements-01-data-model` | [#238](https://github.com/nold-ai/specfact-cli/issues/238) | PENDING (Wave 5) |
+| `requirements-02-module-commands` | [#239](https://github.com/nold-ai/specfact-cli/issues/239) | PENDING (Wave 5/6) |
+
+Note: The validation/parsing components (JSON Schema, `validate_intent_trace()`, parser extension) do NOT require requirements-01/02. Only the `--import-intent` write path (creating `.req.yaml` files) requires them. This means parsing and validation can be implemented ahead of Wave 5.
+
+### Recommended Updates (affected, not breaking)
+
+| File | Reason | Update Type |
+|---|---|---|
+| `src/specfact_cli/adapters/openspec_parser.py` | Extend `parse_change_proposal()` with intent trace extraction | Additive |
+| `src/specfact_cli/adapters/openspec.py` | Extend `_import_change_proposal()` to pass intent trace to bundle; add `--import-intent` path | Additive |
+| `src/specfact_cli/validators/change_proposal_integration.py` | May need to call `validate_intent_trace()` when strict mode enabled | Additive |
+
+## Impact Assessment
+
+- **Code Impact**: Low — 2 existing files extended (additive only), 2 new files created
+- **Test Impact**: Low — new test files only; no existing test modifications required
+- **Documentation Impact**: Medium — `docs/adapters/openspec.md` and `docs/guides/openspec-journey.md` need updates
+- **Release Impact**: Minor version bump (new features, no breaking changes)
+
+## Format Validation
+
+- **proposal.md Format**: Pass
+  - `# Change:` title ✓
+  - `## Why`, `## What Changes`, `## Capabilities`, `## Impact` sections ✓
+  - NEW/EXTEND markers ✓
+  - Capabilities linked to spec folders ✓
+  - Source Tracking section ✓
+- **tasks.md Format**: Pass
+  - Hierarchical `## 1.`…`## 10.` structure ✓
+  - Task 1 = git worktree creation ✓
+  - Task 10 = PR creation (last) ✓
+  - Post-merge cleanup section ✓
+  - TDD / SDD order section at top ✓
+  - Tests before implementation (Tasks 2-3 tests before Tasks 4-5 implementation) ✓
+  - `TDD_EVIDENCE.md` recording tasks ✓
+  - Quality gate tasks ✓
+  - Documentation task included ✓
+  - Version and changelog task ✓
+  - GitHub issue creation task ✓
+  - Module signing verification task: not included — this change has no module-package.yaml changes; acceptable
+- **specs Format**: Pass
+  - `####` for scenario headers ✓
+  - `## ADDED Requirements` / `## MODIFIED Requirements` delta format ✓
+  - G/W/T format with THEN/AND ✓
+  - Every requirement has ≥1 scenario ✓
+- **Config.yaml Compliance**: Pass
+
+## OpenSpec Validation
+
+- **Status**: Pass
+- **Command**: `openspec validate openspec-01-intent-trace --strict`
+- **Output**: `Change 'openspec-01-intent-trace' is valid`
+- **Issues Found/Fixed**: 0
+
+## Dependency Phasing Note
+
+Unlike ai-integration-04, this change has **two separable implementation phases**:
+
+1. **Phase A (can land with Wave 5/6)**: JSON Schema definition, `validate_intent_trace()`, parser extension to extract the intent trace block, `openspec validate --strict` hook. No dependency on requirements-01/02.
+2. **Phase B (requires Wave 5 complete)**: `--import-intent` flag and `.req.yaml` artifact writer. Requires `BusinessOutcome`/`BusinessRule` Pydantic models.
+
+Tasks 2-4 can proceed as soon as the worktree is created. Task 5.3 (`--import-intent` flag) should wait for requirements-01 (#238).
+
+## Ownership Authority
+
+- **Intent trace schema** (`openspec/schemas/intent-trace.schema.json`): owned by this change; aligns with `requirements-01-data-model` field definitions (no conflict — requirements-01 owns the Pydantic model, this change owns the JSON Schema)
+- **`parse_change_proposal()` return dict** (`openspec_parser.py`): existing authority is `openspec_parser.py` itself; this change adds the `"intent_trace"` key — no conflict
+- **`--import-intent` write path** in `openspec.py`: this change is authoritative; no other pending change touches this code path
diff --git a/openspec/changes/openspec-01-intent-trace/design.md b/openspec/changes/openspec-01-intent-trace/design.md
new file mode 100644
index 00000000..22e7db53
--- /dev/null
+++ b/openspec/changes/openspec-01-intent-trace/design.md
@@ -0,0 +1,83 @@
+# Design: OpenSpec Intent Trace — Bridge Adapter Integration
+
+## Context
+
+SpecFact's OpenSpec bridge adapter (`specfact sync bridge --adapter openspec`) reads proposal and task files from an OpenSpec change directory and imports them into SpecFact's project bundle. Currently it reads: title, description, tasks list, and spec references. It does not read any business intent context. This change adds an optional `## Intent Trace` YAML block to the OpenSpec proposal format and teaches the bridge adapter to import it into the `.specfact/requirements/` storage hierarchy used by requirements-01-data-model.
+
+The principle is: **"OpenSpec owns the intent. SpecFact owns the evidence."** OpenSpec authors write intent in a human-readable YAML block; SpecFact validates conformance and generates evidence. This separation keeps the intent format tool-agnostic.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Define the `## Intent Trace` section YAML schema and JSON Schema validator
+- Extend the OpenSpec bridge adapter to parse and import intent artifacts when the section is present
+- Keep the `## Intent Trace` section strictly optional — existing proposals without it are unaffected
+- Validate the section against the JSON Schema during `openspec validate --strict`
+- Produce `.specfact/requirements/{id}.req.yaml` artifacts from imported intent data
+
+**Non-Goals:**
+- Forcing all existing OpenSpec proposals to add an `## Intent Trace` section
+- Building a new proposal authoring tool — the section is hand-authored YAML in Markdown
+- Replacing requirements-01/02 commands — the bridge adapter imports intent; the requirements module validates and traces it
+
+## Decisions
+
+### D1: YAML fenced block vs structured Markdown headings for Intent Trace
+
+**Decision**: YAML fenced block under `## Intent Trace` heading
+```yaml
+intent_trace:
+  business_outcomes:
+    - id: "BO-001"
+      description: "..."
+      persona: "..."
+  business_rules:
+    - id: "BR-001"
+      outcome_ref: "BO-001"
+      given: "..."
+      when: "..."
+      then: "..."
+```
+**Rationale**: YAML is machine-parseable with a single `yaml.safe_load()` call and maps directly to Pydantic models. Structured Markdown headings require custom parsing logic that is brittle and hard to validate with JSON Schema. YAML fenced blocks are already used in GitHub Actions, Docker Compose, and Kubernetes manifests — authors are familiar with the pattern.
+**Alternative rejected**: Structured `### Business Outcomes / ### Business Rules` Markdown sub-sections — readable but not JSON Schema validatable.
+
+### D2: JSON Schema stored in SpecFact vs in OpenSpec format repo
+
+**Decision**: JSON Schema at `openspec/schemas/intent-trace.schema.json` within SpecFact's own repo
+**Rationale**: SpecFact is the authority for validation. The schema living in SpecFact's repo means the bridge adapter always validates against the version it was built with. When OpenSpec is an external tool (not this repo), the schema reference is still resolvable locally.
+**Alternative rejected**: Hosting schema at `openspec.dev/schemas/intent-trace` — external HTTP dependency violates offline-first constraint.
+
+### D3: `--import-intent` flag vs automatic intent import
+
+**Decision**: `specfact sync bridge --adapter openspec --import-intent` — opt-in flag
+**Rationale**: Not every team using the OpenSpec bridge wants `.specfact/requirements/` files created from every proposal import. The opt-in flag gives teams control. When `## Intent Trace` is present but `--import-intent` is not passed, the bridge still validates the section on `openspec validate --strict` but does not write requirements artifacts.
+**Alternative rejected**: Automatic import when section is present — surprising side effect; could overwrite existing requirement files.
+
+### D4: `requirement_refs` in tasks.md — free-form vs validated IDs
+
+**Decision**: Free-form string list (`["BR-001", "AC-002"]`) with advisory validation
+**Rationale**: Task-level requirement refs are metadata for traceability, not for enforcement. Advisory-mode validation warns if a ref ID does not match any known `BusinessRule` or `ArchitecturalConstraint` in `.specfact/requirements/` but does not block import. Hard enforcement would break workflows where requirements are not yet captured.
+
+### D5: `evidence` field in archived changes
+
+**Decision**: Optional string field in change archive metadata: `evidence: ".specfact/evidence/{timestamp}_{run_id}_evidence.json"`
+**Rationale**: Minimal — just a file path reference. The evidence file itself is owned by governance-01-evidence-output. The archive metadata is a pointer, not a copy. This keeps the archive lightweight while enabling audit trail navigation.
+
+## Risks / Trade-offs
+
+- **[Risk] YAML indentation errors in proposals** — Authors writing `## Intent Trace` blocks manually may introduce YAML syntax errors. Mitigation: `openspec validate --strict` catches YAML parse errors before import; error message shows the line number and suggests a fix.
+- **[Risk] ID collision between imported BusinessOutcome IDs and existing requirements** — If a team runs `--import-intent` twice with the same proposal, duplicate `.req.yaml` files may result. Mitigation: bridge adapter checks for existing file with same ID before writing; uses `--overwrite` flag to allow update.
+- **[Trade-off] Schema evolution** — As requirements-01-data-model evolves (new fields), the `intent-trace.schema.json` must stay in sync. Mitigation: schema versioning (`schema_version: "1.0"` in the YAML block); bridge adapter rejects unknown schema versions with a clear error.
+
+## Migration Plan
+
+1. Land requirements-01-data-model (#238) — `BusinessOutcome` and `BusinessRule` Pydantic models must exist.
+2. Define `intent-trace.schema.json` using the Pydantic model fields from requirements-01 as source of truth.
+3. Extend bridge adapter parser to detect `## Intent Trace` section and extract the YAML block.
+4. Implement `--import-intent` flag and requirements artifact writer.
+5. Extend `openspec validate --strict` to call JSON Schema validator on intent trace section.
+6. Update existing SpecFact dogfood proposals (this repo's `openspec/changes/`) with `## Intent Trace` sections as the team adopts the format.
+
+## Open Questions
+
+- None currently blocking implementation.
diff --git a/openspec/changes/openspec-01-intent-trace/proposal.md b/openspec/changes/openspec-01-intent-trace/proposal.md
new file mode 100644
index 00000000..856df1d4
--- /dev/null
+++ b/openspec/changes/openspec-01-intent-trace/proposal.md
@@ -0,0 +1,47 @@
+# Change: OpenSpec Intent Trace — Bridge Adapter Integration
+
+## Why
+
+OpenSpec proposals are plain Markdown with no structured business-intent metadata. When SpecFact imports a proposal via `specfact sync bridge --adapter openspec`, it has no machine-readable context about the business outcomes, business rules, or architectural constraints the change is supposed to satisfy — it only sees tasks and specs. This means the traceability chain starts at the spec level, missing the upstream intent layer entirely. Adding a structured `## Intent Trace` section to OpenSpec proposals (with JSON Schema validation) gives SpecFact the data it needs to construct the full outcome → rule → constraint → spec → code chain automatically on import.
+
+## What Changes
+
+- **NEW**: `## Intent Trace` section schema for OpenSpec `proposal.md` files:
+  - YAML-fenced block under `## Intent Trace` with `intent_trace` root key
+  - Fields: `business_outcomes` (id, description, persona), `business_rules` (id, outcome_ref, given, when, then), `architectural_constraints` (id, outcome_ref, constraint), `requirement_refs` (list of REQ-NNN strings)
+  - JSON Schema at `openspec/schemas/intent-trace.schema.json` for validation
+- **NEW**: `requirement_refs` optional field on individual tasks in `tasks.md` — links a task to specific `BusinessRule` IDs or `ArchitecturalConstraint` IDs
+- **NEW**: `evidence` optional field on archived changes — points to evidence JSON envelope file(s) generated during implementation; creates immutable proposal → intent trace → implementation → evidence → archive chain
+- **NEW**: `specfact sync bridge --adapter openspec --import-intent` — reads `## Intent Trace` section from imported proposals and populates `.specfact/requirements/` with `BusinessOutcome` and `BusinessRule` artifacts automatically
+- **EXTEND**: `specfact sync bridge --adapter openspec` — when `## Intent Trace` section is present, include intent context in the imported project bundle; backwards-compatible (section is optional)
+- **EXTEND**: `openspec validate <change-id> --strict` — validates `## Intent Trace` section against `intent-trace.schema.json` when present
+
+## Capabilities
+
+### New Capabilities
+
+- `openspec-intent-trace-schema`: JSON Schema definition and validation for the `## Intent Trace` section in OpenSpec proposals — enabling machine-readable business-outcome traceability in change proposals.
+- `openspec-bridge-intent-import`: Extended SpecFact OpenSpec bridge adapter that reads, validates, and imports `## Intent Trace` sections from proposals into `.specfact/requirements/` artifacts automatically.
+
+### Modified Capabilities
+
+- `openspec-bridge-adapter`: Extended to parse optional `## Intent Trace` section on proposal import; backwards-compatible when section is absent.
+
+## Impact
+
+- New file: `openspec/schemas/intent-trace.schema.json`
+- Existing bridge adapter: `src/specfact_cli/adapters/` OpenSpec adapter extended with intent-trace parsing
+- CLI change: `specfact sync bridge --adapter openspec` — new optional `--import-intent` flag; no breaking change to existing workflows
+- Depends on: `requirements-01-data-model` (#238) — `BusinessOutcome` and `BusinessRule` schemas must exist to populate; `requirements-02-module-commands` (#239) — `specfact requirements capture` used for artifact creation
+- Wave: aligns with Wave 5/6 (after requirements-01/02 land)
+- Docs: new `docs/guides/openspec-journey.md` section on Intent Trace; update `docs/adapters/` for OpenSpec adapter
+
+---
+
+## Source Tracking
+
+<!-- source_repo: nold-ai/specfact-cli -->
+- **GitHub Issue**: #350
+- **Issue URL**: <https://github.com/nold-ai/specfact-cli/issues/350>
+- **Repository**: nold-ai/specfact-cli
+- **Last Synced Status**: proposed
diff --git a/openspec/changes/openspec-01-intent-trace/specs/openspec-bridge-adapter/spec.md b/openspec/changes/openspec-01-intent-trace/specs/openspec-bridge-adapter/spec.md
new file mode 100644
index 00000000..2012e709
--- /dev/null
+++ b/openspec/changes/openspec-01-intent-trace/specs/openspec-bridge-adapter/spec.md
@@ -0,0 +1,22 @@
+## MODIFIED Requirements
+
+### Requirement: OpenSpec Bridge Adapter Import
+The system SHALL import OpenSpec change proposals into SpecFact's project bundle with full backwards compatibility when the `## Intent Trace` section is absent, and include intent context when the section is present.
+
+#### Scenario: Proposal import without Intent Trace section is unchanged
+- **GIVEN** an OpenSpec proposal that has no `## Intent Trace` section
+- **WHEN** `specfact sync bridge --adapter openspec` is run
+- **THEN** the import behaviour is identical to the pre-change behaviour
+- **AND** no error, warning, or advisory is emitted related to missing intent trace
+
+#### Scenario: Proposal import includes intent context when section is present
+- **GIVEN** an OpenSpec proposal with a valid `## Intent Trace` section
+- **WHEN** `specfact sync bridge --adapter openspec` is run (without `--import-intent`)
+- **THEN** the proposal's intent trace metadata is attached to the project bundle as read-only context
+- **AND** `specfact project health-check` can report that intent context is available for the change
+
+#### Scenario: `openspec validate --strict` validates intent trace when present
+- **GIVEN** an OpenSpec change with a proposal containing a `## Intent Trace` section
+- **WHEN** `openspec validate <change-id> --strict` is run
+- **THEN** the validator checks the YAML block against `intent-trace.schema.json`
+- **AND** any schema violations cause a non-zero exit code with descriptive error messages
diff --git a/openspec/changes/openspec-01-intent-trace/specs/openspec-bridge-intent-import/spec.md b/openspec/changes/openspec-01-intent-trace/specs/openspec-bridge-intent-import/spec.md
new file mode 100644
index 00000000..6d04cad0
--- /dev/null
+++ b/openspec/changes/openspec-01-intent-trace/specs/openspec-bridge-intent-import/spec.md
@@ -0,0 +1,49 @@
+## ADDED Requirements
+
+### Requirement: Bridge Adapter Intent Import
+The system SHALL extend `specfact sync bridge --adapter openspec` with an `--import-intent` flag that reads the `## Intent Trace` YAML block from imported proposals and creates corresponding `.specfact/requirements/{id}.req.yaml` artifacts.
+
+#### Scenario: Intent import creates BusinessOutcome artifacts
+- **GIVEN** an OpenSpec proposal with a `## Intent Trace` section containing at least one `business_outcomes` entry
+- **WHEN** `specfact sync bridge --adapter openspec --import-intent` is run
+- **THEN** a `.specfact/requirements/{id}.req.yaml` file is created for each `BusinessOutcome` in the intent trace
+- **AND** each artifact validates against the `BusinessOutcome` Pydantic schema without errors
+
+#### Scenario: Intent import creates BusinessRule artifacts
+- **GIVEN** an OpenSpec proposal with `business_rules` entries in the `## Intent Trace` section
+- **WHEN** `specfact sync bridge --adapter openspec --import-intent` is run
+- **THEN** each `BusinessRule` (id, outcome_ref, given, when, then) is stored in the corresponding `.req.yaml` artifact under its parent `BusinessOutcome`
+- **AND** the `outcome_ref` is resolved to a valid `BusinessOutcome` ID in the imported requirements
+
+#### Scenario: Intent import skips existing artifacts without --overwrite
+- **GIVEN** a `.specfact/requirements/BO-001.req.yaml` file already exists
+- **WHEN** `specfact sync bridge --adapter openspec --import-intent` is run without `--overwrite`
+- **THEN** the existing file is not modified
+- **AND** the CLI output notes the skipped artifact with its ID
+
+#### Scenario: Intent import overwrites with --overwrite flag
+- **GIVEN** a `.specfact/requirements/BO-001.req.yaml` file already exists
+- **WHEN** `specfact sync bridge --adapter openspec --import-intent --overwrite` is run
+- **THEN** the existing file is updated with the content from the proposal's intent trace section
+- **AND** the CLI output confirms the overwritten artifact ID
+
+#### Scenario: Import without --import-intent ignores intent trace section
+- **GIVEN** an OpenSpec proposal with a `## Intent Trace` section
+- **WHEN** `specfact sync bridge --adapter openspec` is run without `--import-intent`
+- **THEN** no `.specfact/requirements/` artifacts are created
+- **AND** the section is validated but not imported
+
+### Requirement: Task-Level Requirement References
+The system SHALL support an optional `requirement_refs` list field on individual tasks in OpenSpec `tasks.md` files, linking tasks to specific `BusinessRule` or `ArchitecturalConstraint` IDs.
+
+#### Scenario: Bridge adapter parses requirement_refs in tasks
+- **GIVEN** a `tasks.md` file with a task containing `requirement_refs: ["BR-001", "AC-002"]`
+- **WHEN** the bridge adapter imports the proposal
+- **THEN** the imported task record includes the requirement ref IDs
+- **AND** they are included in the project bundle's task metadata
+
+#### Scenario: Advisory validation warns on unresolved requirement refs
+- **GIVEN** a task with `requirement_refs: ["BR-999"]` where BR-999 does not exist in `.specfact/requirements/`
+- **WHEN** `specfact sync bridge --adapter openspec` is run
+- **THEN** the CLI emits an advisory warning: `[ADVISORY] Task X: requirement_refs contains unknown ID BR-999`
+- **AND** the import proceeds without failing
diff --git a/openspec/changes/openspec-01-intent-trace/specs/openspec-intent-trace-schema/spec.md b/openspec/changes/openspec-01-intent-trace/specs/openspec-intent-trace-schema/spec.md
new file mode 100644
index 00000000..b9fa93ae
--- /dev/null
+++ b/openspec/changes/openspec-01-intent-trace/specs/openspec-intent-trace-schema/spec.md
@@ -0,0 +1,42 @@
+## ADDED Requirements
+
+### Requirement: Intent Trace Section Schema
+The system SHALL define a JSON Schema at `openspec/schemas/intent-trace.schema.json` that validates the `## Intent Trace` YAML block in OpenSpec proposal files.
+
+#### Scenario: Valid intent trace section passes schema validation
+- **GIVEN** an OpenSpec proposal with a correctly structured `## Intent Trace` YAML block
+- **WHEN** `openspec validate <change-id> --strict` is run
+- **THEN** the intent trace section validates without errors
+- **AND** the validation output confirms intent trace section is present and valid
+
+#### Scenario: Invalid intent trace section fails schema validation
+- **GIVEN** an OpenSpec proposal with a `## Intent Trace` YAML block missing a required field (e.g., `id` on a `BusinessOutcome`)
+- **WHEN** `openspec validate <change-id> --strict` is run
+- **THEN** the validation exits with a non-zero code
+- **AND** the error message identifies the specific field violation and the line context
+
+#### Scenario: Missing intent trace section is valid (section is optional)
+- **GIVEN** an OpenSpec proposal without any `## Intent Trace` section
+- **WHEN** `openspec validate <change-id> --strict` is run
+- **THEN** the validation passes without intent-trace errors
+- **AND** no warning about missing intent trace is emitted in normal mode
+
+#### Scenario: Intent trace schema includes schema version field
+- **GIVEN** an intent trace YAML block with `schema_version: "1.0"`
+- **WHEN** the bridge adapter reads the block
+- **THEN** it accepts the artifact and records the schema version
+- **AND** if the schema version is unknown the adapter emits a clear error with supported versions
+
+### Requirement: Intent Trace Evidence Field in Archive
+The system SHALL support an optional `evidence` field in change archive metadata pointing to the evidence JSON envelope file produced during implementation.
+
+#### Scenario: Archive metadata includes evidence reference
+- **GIVEN** an archived change that generated a governance evidence artifact
+- **WHEN** the archive metadata is read
+- **THEN** the `evidence` field contains a relative path to the `.specfact/evidence/` JSON file
+- **AND** the path resolves to a readable file on disk
+
+#### Scenario: Archive without evidence field is valid
+- **GIVEN** an archived change that did not produce governance evidence
+- **WHEN** the archive metadata is validated
+- **THEN** validation passes without errors related to the missing evidence field
diff --git a/openspec/changes/openspec-01-intent-trace/tasks.md b/openspec/changes/openspec-01-intent-trace/tasks.md
new file mode 100644
index 00000000..fc8d320c
--- /dev/null
+++ b/openspec/changes/openspec-01-intent-trace/tasks.md
@@ -0,0 +1,151 @@
+# Tasks: OpenSpec Intent Trace — Bridge Adapter Integration
+
+## TDD / SDD order (enforced)
+
+Per `openspec/config.yaml`, tests MUST precede production code for any behavior-changing task.
+
+Order:
+1. Spec deltas (already in `specs/`)
+2. Tests derived from spec scenarios — run and expect failure
+3. Production code — implement until tests pass
+
+Do not implement production code until tests exist and have been run (expecting failure).
+
+---
+
+## 1. Create git worktree for this change
+
+- [ ] 1.1 Fetch latest and create a worktree with a new branch from `origin/dev`.
+  - [ ] 1.1.1 `git fetch origin`
+  - [ ] 1.1.2 `git worktree add ../specfact-cli-worktrees/feature/openspec-01-intent-trace -b feature/openspec-01-intent-trace origin/dev`
+  - [ ] 1.1.3 `cd ../specfact-cli-worktrees/feature/openspec-01-intent-trace`
+  - [ ] 1.1.4 `python -m venv .venv && source .venv/bin/activate && pip install -e ".[dev]"`
+  - [ ] 1.1.5 `git branch --show-current` (verify `feature/openspec-01-intent-trace`)
+
+## 2. Define Intent Trace JSON Schema
+
+- [ ] 2.1 Create `openspec/schemas/intent-trace.schema.json`:
+  - [ ] 2.1.1 Root object with `schema_version` (required string), `intent_trace` object
+  - [ ] 2.1.2 `business_outcomes` array: each item requires `id` (string), `description` (string), `persona` (string)
+  - [ ] 2.1.3 `business_rules` array: each item requires `id`, `outcome_ref`, `given`, `when`, `then`
+  - [ ] 2.1.4 `architectural_constraints` array: each item requires `id`, `outcome_ref`, `constraint`
+  - [ ] 2.1.5 `requirement_refs` optional array of strings
+  - [ ] 2.1.6 `additionalProperties: false` on all objects for strict validation
+- [ ] 2.2 Write schema unit tests in `tests/unit/specfact_cli/test_intent_trace_schema.py`:
+  - [ ] 2.2.1 Test valid complete intent trace block passes validation
+  - [ ] 2.2.2 Test missing required `id` field on BusinessOutcome fails
+  - [ ] 2.2.3 Test missing intent trace section (None) passes (optional)
+  - [ ] 2.2.4 Test unknown `schema_version` raises descriptive error
+- [ ] 2.3 Run schema tests — expect failure: `hatch test -- tests/unit/specfact_cli/test_intent_trace_schema.py -v`
+- [ ] 2.4 Record failing test evidence in `TDD_EVIDENCE.md`
+
+## 3. Write bridge adapter tests (TDD — expect failure)
+
+- [ ] 3.1 Review existing OpenSpec bridge adapter tests in `tests/`
+- [ ] 3.2 Add `tests/unit/specfact_cli/test_openspec_bridge_intent.py`:
+  - [ ] 3.2.1 Test bridge import of proposal with `## Intent Trace` creates `.req.yaml` files (with `--import-intent`)
+  - [ ] 3.2.2 Test bridge import without `## Intent Trace` section is unchanged (backwards compatible)
+  - [ ] 3.2.3 Test `--import-intent` without `--overwrite` skips existing artifacts
+  - [ ] 3.2.4 Test `--import-intent --overwrite` updates existing artifacts
+  - [ ] 3.2.5 Test advisory warning on unresolved `requirement_refs`
+  - [ ] 3.2.6 Test `requirement_refs` parsed into imported task metadata
+- [ ] 3.3 Add `tests/integration/test_openspec_intent_trace_e2e.py`:
+  - [ ] 3.3.1 End-to-end test: proposal with intent trace → bridge import → `.req.yaml` exists and validates
+- [ ] 3.4 Run bridge tests — expect failure: `hatch test -- tests/unit/specfact_cli/test_openspec_bridge_intent.py -v`
+- [ ] 3.5 Record failing test evidence in `TDD_EVIDENCE.md`
+
+## 4. Implement Intent Trace schema validator
+
+- [ ] 4.1 Add `src/specfact_cli/validators/intent_trace_validator.py`:
+  - [ ] 4.1.1 `validate_intent_trace(yaml_block: dict | None) -> ValidationResult` with `@require` and `@beartype`
+  - [ ] 4.1.2 Load `openspec/schemas/intent-trace.schema.json` (bundled resource)
+  - [ ] 4.1.3 Use `jsonschema.validate()` for schema check
+  - [ ] 4.1.4 Return structured errors with field path, message, and suggestion
+- [ ] 4.2 Register schema file in `pyproject.toml` `[tool.hatch.build.targets.wheel]` force-include
+
+## 5. Extend OpenSpec bridge adapter with intent import
+
+> **Implementation constraint (from CHANGE_VALIDATION.md)**: `_parse_proposal_content()` in `openspec_parser.py` has return type `dict[str, str]`. Intent trace extraction MUST be done in `parse_change_proposal()` (returns `dict[str, Any]`) — NOT in `_parse_proposal_content()` — to avoid a `@beartype` type violation.
+
+- [ ] 5.1 Locate OpenSpec bridge adapter in `src/specfact_cli/adapters/`
+- [ ] 5.2 Add `## Intent Trace` section parser:
+  - [ ] 5.2.1 Extract YAML fenced block under `## Intent Trace` heading from proposal Markdown
+  - [ ] 5.2.2 Parse YAML with `yaml.safe_load()`
+  - [ ] 5.2.3 Run `validate_intent_trace()` on the parsed block
+- [ ] 5.3 Add `--import-intent` flag to `specfact sync bridge --adapter openspec` command:
+  - [ ] 5.3.1 `@require`: intent import requires requirements-01 module is installed (advisory check)
+  - [ ] 5.3.2 Write `.specfact/requirements/{id}.req.yaml` for each `BusinessOutcome`
+  - [ ] 5.3.3 Embed `BusinessRule` entries in parent `.req.yaml` files
+  - [ ] 5.3.4 Respect `--overwrite` flag; skip existing files otherwise
+- [ ] 5.4 Add `requirement_refs` parsing from `tasks.md` task entries
+  - [ ] 5.4.1 Parse optional `requirement_refs:` YAML field on task lines
+  - [ ] 5.4.2 Include in imported task metadata in project bundle
+  - [ ] 5.4.3 Advisory warning for unresolved IDs
+- [ ] 5.5 Extend `openspec validate --strict` hook to call `validate_intent_trace()` when section present
+- [ ] 5.6 Add `@require`, `@ensure`, `@beartype` decorators to all new public API functions
+
+## 6. Passing tests and quality gates
+
+- [ ] 6.1 Run all new tests — expect passing: `hatch test -- tests/unit/specfact_cli/test_intent_trace*.py tests/unit/specfact_cli/test_openspec_bridge*.py tests/integration/test_openspec_intent_trace*.py -v`
+- [ ] 6.2 Record passing test evidence in `TDD_EVIDENCE.md`
+- [ ] 6.3 `hatch run format`
+- [ ] 6.4 `hatch run type-check`
+- [ ] 6.5 `hatch run lint`
+- [ ] 6.6 `hatch run yaml-lint`
+- [ ] 6.7 `hatch run contract-test`
+- [ ] 6.8 `hatch run smart-test`
+
+## 7. Documentation
+
+- [ ] 7.1 Update `docs/adapters/openspec.md` (or equivalent):
+  - [ ] 7.1.1 Document `## Intent Trace` section format with full YAML example
+  - [ ] 7.1.2 Document `--import-intent` and `--overwrite` flags
+  - [ ] 7.1.3 Document `requirement_refs` field on tasks
+- [ ] 7.2 Update `docs/guides/openspec-journey.md` — add Intent Trace section
+- [ ] 7.3 Ensure front-matter on all updated/new doc pages is valid (layout, title, permalink, description)
+- [ ] 7.4 Update `docs/_layouts/default.html` sidebar navigation if new pages are added
+
+## 8. Version and changelog
+
+- [ ] 8.1 Bump minor version in `pyproject.toml`, `setup.py`, `src/__init__.py`, `src/specfact_cli/__init__.py`
+- [ ] 8.2 Add CHANGELOG.md entry under new `[X.Y.Z] - 2026-XX-XX` with Added/Changed sections
+
+## 9. GitHub issue creation
+
+- [ ] 9.1 Create GitHub issue:
+  ```bash
+  gh issue create \
+    --repo nold-ai/specfact-cli \
+    --title "[Change] OpenSpec Intent Trace — Bridge Adapter Integration" \
+    --body-file /tmp/github-issue-openspec-01.md \
+    --label "enhancement" \
+    --label "change-proposal"
+  ```
+- [ ] 9.2 Link issue to project: `gh project item-add 1 --owner nold-ai --url <ISSUE_URL>`
+- [ ] 9.3 Update `proposal.md` Source Tracking section with issue number and URL
+- [ ] 9.4 Link branch to issue: `gh issue develop <issue-number> --repo nold-ai/specfact-cli --name feature/openspec-01-intent-trace`
+
+## 10. Pull request
+
+- [ ] 10.1 `git add` all changed files; commit with `feat: add OpenSpec Intent Trace section and bridge adapter import`
+- [ ] 10.2 `git push -u origin feature/openspec-01-intent-trace`
+- [ ] 10.3 Create PR:
+  ```bash
+  gh pr create \
+    --repo nold-ai/specfact-cli \
+    --base dev \
+    --head feature/openspec-01-intent-trace \
+    --title "feat: OpenSpec Intent Trace bridge adapter integration" \
+    --body-file /tmp/pr-body-openspec-01.md
+  ```
+- [ ] 10.4 Link PR to project: `gh project item-add 1 --owner nold-ai --url <PR_URL>`
+- [ ] 10.5 Set project status to "In Progress"
+
+## Post-merge cleanup (after PR is merged)
+
+- [ ] Return to primary checkout: `cd .../specfact-cli`
+- [ ] `git fetch origin`
+- [ ] `git worktree remove ../specfact-cli-worktrees/feature/openspec-01-intent-trace`
+- [ ] `git branch -d feature/openspec-01-intent-trace`
+- [ ] `git worktree prune`
+- [ ] (Optional) `git push origin --delete feature/openspec-01-intent-trace`
diff --git a/openspec/changes/requirements-01-data-model/specs/requirements-data-model/intentspec-delta.md b/openspec/changes/requirements-01-data-model/specs/requirements-data-model/intentspec-delta.md
new file mode 100644
index 00000000..d0ed64e4
--- /dev/null
+++ b/openspec/changes/requirements-01-data-model/specs/requirements-data-model/intentspec-delta.md
@@ -0,0 +1,35 @@
+## ADDED Requirements
+
+### Requirement: IntentSpec Schema Compatibility
+The system SHALL ensure `BusinessOutcome` and `BusinessRule` schemas are compatible with the IntentSpec.org JSON Schema standard (5 fields: Objective, User Goal, Outcomes, Edge Cases, Verification), so that IntentSpec-formatted intent documents can be imported without data loss.
+
+#### Scenario: BusinessOutcome maps to all 5 IntentSpec fields
+- **GIVEN** an IntentSpec-formatted YAML document with fields: objective, user_goal, outcomes, edge_cases, verification
+- **WHEN** it is imported via `specfact requirements capture --format intentspec`
+- **THEN** the resulting `BusinessOutcome` record preserves all 5 IntentSpec fields in the stored artifact
+- **AND** the imported artifact validates against the `BusinessOutcome` Pydantic schema without errors
+
+#### Scenario: SQUER 7-question answers map to IntentSpec fields
+- **GIVEN** a completed SQUER intent interview with 7 answers
+- **WHEN** the interview output is serialized to a `BusinessOutcome` artifact
+- **THEN** the serialization produces all 5 IntentSpec fields as a superset (SQUER answers cover objective, user_goal, outcomes, edge_cases, and verification)
+- **AND** no data is silently dropped from the SQUER answers during the mapping
+
+### Requirement: Traceability Invariants
+The system SHALL enforce three traceability invariants as preconditions on the publish gate for requirement artifacts:
+
+1. **Traceability invariant**: Every shipped feature SHALL trace backward to at least one `BusinessOutcome` and forward through `BusinessRule` (G/W/T), `ArchitecturalConstraint`, specs, contracts, and tests.
+2. **Evidence completeness invariant**: No artifact SHALL pass the publish gate without a corresponding evidence record capturing validation timestamp, tool version, verdict (pass/fail/error), and artifact hash.
+3. **Intent schema conformance invariant**: `BusinessOutcome`, `BusinessRule`, and `ArchitecturalConstraint` documents SHALL validate against their canonical schemas before entering the pipeline.
+
+#### Scenario: Traceability invariant enforced on publish gate
+- **GIVEN** a `BusinessOutcome` with no downstream spec reference
+- **WHEN** `specfact enforce stage --preset strict` runs the publish gate
+- **THEN** the gate blocks with a BLOCK verdict
+- **AND** the blocking reason identifies the orphaned `BusinessOutcome` ID and the missing spec link
+
+#### Scenario: Intent schema conformance checked before pipeline entry
+- **GIVEN** a `BusinessRule` YAML file with a missing `given` field
+- **WHEN** `specfact requirements validate` is run
+- **THEN** the command exits non-zero
+- **AND** the error output identifies the missing field, its expected type, and the file path
diff --git a/openspec/specs/documentation-alignment/spec.md b/openspec/specs/documentation-alignment/spec.md
index 72bc0e4a..e8c580bd 100644
--- a/openspec/specs/documentation-alignment/spec.md
+++ b/openspec/specs/documentation-alignment/spec.md
@@ -92,3 +92,38 @@ Any stated performance or timing in the docs SHALL reflect current benchmarks or
 - **WHEN** the docs are published
 - **THEN** metrics reflect current benchmarks or are removed if outdated
 
+### Requirement: Live docs reflect lean-core and grouped bundle command topology
+The live documentation set SHALL describe the current command surface as a lean core plus marketplace-installed grouped bundle commands, and SHALL NOT present the former flat all-commands topology as the primary current UX.
+
+#### Scenario: Reader checks command examples
+- **WHEN** a reader follows command examples in README or published docs
+- **THEN** core commands are shown as always available from `specfact-cli`
+- **AND** bundle commands are shown through grouped command paths and marketplace installation context
+- **AND** stale flat-command examples are removed, corrected, or clearly marked as historical compatibility context
+
+### Requirement: Marketplace guidance is discoverable and non-duplicative
+Marketplace, bundle installation, dependency, trust, and publishing documentation SHALL be available through clear entry points and SHALL avoid contradictory or duplicate guidance across README, landing pages, guides, and reference pages.
+
+#### Scenario: Reader looks for marketplace workflow guidance
+- **WHEN** a reader wants to install, trust, publish, or understand official bundles
+- **THEN** the docs provide a discoverable path from README or docs landing into marketplace-specific pages
+- **AND** terminology, command examples, and workflow descriptions are consistent across those pages
+
+### Requirement: Command reference reflects ownership and package boundaries
+The command reference documentation SHALL distinguish permanent core commands from marketplace-delivered bundle commands and SHALL organize module command coverage by package/category ownership instead of one legacy flat command inventory.
+
+#### Scenario: Reader checks command reference
+- **WHEN** a reader opens command reference documentation
+- **THEN** the reference identifies which commands belong to core and which are provided by installed bundles
+- **AND** bundle command coverage is grouped by category or package boundary
+- **AND** readers can navigate from command docs to the relevant marketplace/module docs without ambiguity
+
+### Requirement: Markdown quality workflow auto-fixes low-risk issues before enforcement
+The documentation workflow SHALL automatically fix low-risk Markdown issues during pre-commit checks before enforcing markdown lint failures for non-fixable or higher-risk issues.
+
+#### Scenario: Contributor stages Markdown changes with trivial spacing issues
+- **WHEN** a contributor stages Markdown files and runs the repository pre-commit checks
+- **THEN** the workflow attempts safe markdown auto-fixes first using the configured markdown lint tooling
+- **AND** any auto-fixed Markdown files are re-staged automatically
+- **AND** markdown lint still runs afterward to fail on remaining non-fixable issues
+
diff --git a/openspec/specs/implementation-status-docs/spec.md b/openspec/specs/implementation-status-docs/spec.md
index 81e990b7..912ae79f 100644
--- a/openspec/specs/implementation-status-docs/spec.md
+++ b/openspec/specs/implementation-status-docs/spec.md
@@ -43,3 +43,11 @@ The implementation status page SHALL be linked from the architecture README or r
 - **THEN** the implementation status page is linked
 - **AND** discoverable from the architecture index or README
 
+### Requirement: Implementation-status docs describe core versus bundle ownership
+Implementation-status and architecture status documentation SHALL explicitly describe which capabilities are owned by core runtime versus marketplace-installed bundles, and SHALL identify documentation that is still temporarily hosted in core despite belonging to bundle workflows.
+
+#### Scenario: Reader checks ownership in status docs
+- **WHEN** a reader reviews implementation-status or architecture status pages
+- **THEN** the docs distinguish core lifecycle/runtime ownership from bundle workflow ownership
+- **AND** temporary docs-hosting exceptions are called out so documentation location does not imply incorrect runtime ownership
+
diff --git a/openspec/specs/module-development-guide/spec.md b/openspec/specs/module-development-guide/spec.md
index 4f9e3a60..93a40ae6 100644
--- a/openspec/specs/module-development-guide/spec.md
+++ b/openspec/specs/module-development-guide/spec.md
@@ -33,3 +33,19 @@ The module development guide SHALL be reachable from the docs navigation (e.g. G
 - **THEN** the guide is reachable from the docs navigation
 - **AND** from the architecture or module system documentation
 
+### Requirement: Module development docs reflect the dedicated modules repository model
+The module development guide SHALL describe that official bundle implementation lives in `specfact-cli-modules`, while `specfact-cli` owns the lean runtime, registry, marketplace lifecycle, and shared contracts needed by installed bundles.
+
+#### Scenario: Developer reads module development docs after modularization
+- **WHEN** a contributor reads the module development guide
+- **THEN** the guide explains the current two-repository model
+- **AND** it identifies which code and documentation concerns belong in `specfact-cli` versus `specfact-cli-modules`
+
+### Requirement: Directory and dependency docs reflect bundle boundaries
+Module development, directory-structure, and dependency documentation SHALL describe the current bundle/package layout, canonical repository ownership, and bundle dependency relationships introduced by marketplace-installed official bundles.
+
+#### Scenario: Contributor checks structure and dependency guidance
+- **WHEN** a contributor reads directory or dependency documentation related to modules
+- **THEN** the docs show the current bundle/package boundaries and repository ownership
+- **AND** dependency explanations match the marketplace-installed bundle model rather than the former in-repo bundled module layout
+
diff --git a/openspec/specs/module-docs-ownership/spec.md b/openspec/specs/module-docs-ownership/spec.md
new file mode 100644
index 00000000..724306b1
--- /dev/null
+++ b/openspec/specs/module-docs-ownership/spec.md
@@ -0,0 +1,21 @@
+# module-docs-ownership Specification
+
+## Purpose
+TBD - created by archiving change docs-01-core-modules-docs-alignment. Update Purpose after archive.
+## Requirements
+### Requirement: Core docs declare current and target docs ownership boundaries
+The documentation SHALL state which documentation concerns remain owned by `specfact-cli` core, which concerns belong to marketplace-installed module bundles, and that module-specific docs are temporarily still hosted in the core docs set until they are migrated to `specfact-cli-modules`.
+
+#### Scenario: Reader checks docs ownership model
+- **WHEN** a reader opens the README, docs landing page, or module architecture/development documentation
+- **THEN** the docs explain that core runtime, installation, lifecycle, registry, and marketplace concepts remain documented in `specfact-cli`
+- **AND** they explain that bundle-specific command and workflow docs are temporarily hosted there but are intended to migrate to `specfact-cli-modules`
+
+### Requirement: Module-specific docs carry a migration note while hosted in core
+Any live module-specific guide or reference page that remains in `specfact-cli` SHALL include a consistent note that the page is temporarily hosted in core and is planned to migrate to the modules repository.
+
+#### Scenario: Reader opens a bundle-focused page
+- **WHEN** a reader opens a module- or bundle-focused guide in the core docs set
+- **THEN** the page includes a visible note about temporary hosting in `specfact-cli`
+- **AND** the note points to `specfact-cli-modules` as the future long-term home for module-specific documentation
+
diff --git a/scripts/pre-commit-smart-checks.sh b/scripts/pre-commit-smart-checks.sh
index 3bb62fe4..dadbd7cc 100755
--- a/scripts/pre-commit-smart-checks.sh
+++ b/scripts/pre-commit-smart-checks.sh
@@ -33,6 +33,30 @@ has_staged_markdown() {
   staged_files | grep -E '\\.md$' >/dev/null 2>&1
 }
 
+staged_markdown_files() {
+  staged_files | grep -E '\\.md$' || true
+}
+
+fail_if_markdown_has_unstaged_hunks() {
+  local md_files
+  md_files=$(staged_markdown_files)
+  if [ -z "${md_files}" ]; then
+    return
+  fi
+
+  local file
+  while IFS= read -r file; do
+    [ -z "${file}" ] && continue
+    if ! git diff --quiet -- "$file"; then
+      error "❌ Cannot auto-fix Markdown with unstaged hunks: $file"
+      warn "💡 Stage the full file or stash/revert the unstaged Markdown changes before commit"
+      exit 1
+    fi
+  done <<EOF
+${md_files}
+EOF
+}
+
 run_module_signature_verification() {
   info "🔐 Verifying bundled module signatures/version bumps"
   if hatch run ./scripts/verify-modules-signature.py --require-signature --enforce-version-bump; then
@@ -44,11 +68,46 @@ run_module_signature_verification() {
   fi
 }
 
+run_markdown_autofix_if_needed() {
+  if has_staged_markdown; then
+    info "📝 Markdown changes detected — attempting safe auto-fix"
+    local md_files
+    md_files=$(staged_markdown_files)
+    if [ -z "${md_files}" ]; then
+      info "ℹ️  No staged markdown files resolved — skipping markdown auto-fix"
+      return
+    fi
+
+    fail_if_markdown_has_unstaged_hunks
+
+    if command -v markdownlint >/dev/null 2>&1; then
+      if echo "${md_files}" | xargs -r markdownlint --fix --config .markdownlint.json; then
+        echo "${md_files}" | xargs -r git add --
+        success "✅ Markdown auto-fix applied"
+      else
+        error "❌ Markdown auto-fix failed"
+        exit 1
+      fi
+    else
+      if echo "${md_files}" | xargs -r npx --yes markdownlint-cli --fix --config .markdownlint.json; then
+        echo "${md_files}" | xargs -r git add --
+        success "✅ Markdown auto-fix applied (npx)"
+      else
+        error "❌ Markdown auto-fix failed (npx)"
+        warn "💡 Install markdownlint-cli globally for faster hooks: npm i -g markdownlint-cli"
+        exit 1
+      fi
+    fi
+  else
+    info "ℹ️  No staged Markdown changes — skipping markdown auto-fix"
+  fi
+}
+
 run_markdown_lint_if_needed() {
   if has_staged_markdown; then
     info "📝 Markdown changes detected — running markdownlint"
     local md_files
-    md_files=$(staged_files | grep -E '\\.md$' || true)
+    md_files=$(staged_markdown_files)
     if [ -z "${md_files}" ]; then
       info "ℹ️  No staged markdown files resolved — skipping markdownlint"
       return
@@ -177,6 +236,7 @@ run_module_signature_verification
 run_format_safety
 
 # Always run lint checks when relevant files changed
+run_markdown_autofix_if_needed
 run_markdown_lint_if_needed
 run_yaml_lint_if_needed
 run_actionlint_if_needed
diff --git a/scripts/setup-git-hooks.sh b/scripts/setup-git-hooks.sh
index c8c03801..5ea9aa58 100755
--- a/scripts/setup-git-hooks.sh
+++ b/scripts/setup-git-hooks.sh
@@ -48,7 +48,8 @@ echo ""
 echo "The pre-commit hook will now:"
 echo "  • Verify module signatures and enforce version bumps"
 echo "  • Run hatch formatter safety check and fail if files are changed"
-echo "  • Run markdownlint for staged Markdown files"
+echo "  • Auto-fix low-risk Markdown issues for staged Markdown files"
+echo "  • Re-stage auto-fixed Markdown files and then run markdownlint"
 echo "  • Run yamllint for YAML changes (relaxed policy)"
 echo "  • Run actionlint for .github/workflows changes"
 echo "  • Check for file changes using smart detection"
@@ -60,6 +61,7 @@ echo ""
 echo "Manual commands:"
 echo "  • Module signatures: hatch run ./scripts/verify-modules-signature.py --require-signature --enforce-version-bump"
 echo "  • Format code: hatch run format"
+echo "  • Markdown auto-fix: markdownlint --fix --config .markdownlint.json <files.md>"
 echo "  • Markdown lint: markdownlint --config .markdownlint.json <files.md>"
 echo "  • YAML lint: hatch run yaml-lint"
 echo "  • Workflow lint: hatch run lint-workflows"
diff --git a/tests/unit/docs/test_release_docs_parity.py b/tests/unit/docs/test_release_docs_parity.py
index 3a8466d4..7ce2672a 100644
--- a/tests/unit/docs/test_release_docs_parity.py
+++ b/tests/unit/docs/test_release_docs_parity.py
@@ -23,3 +23,29 @@ def test_patch_mode_is_not_left_under_unreleased() -> None:
 def test_command_reference_documents_patch_apply() -> None:
     commands_doc = _repo_file("docs/reference/commands.md").read_text(encoding="utf-8")
     assert "specfact govern patch" in commands_doc
+
+
+def test_module_bootstrap_checklist_uses_current_bundle_ids() -> None:
+    checklist = _repo_file("docs/getting-started/module-bootstrap-checklist.md").read_text(encoding="utf-8")
+    assert "specfact module install backlog --source bundled" in checklist
+    assert "backlog-core" not in checklist
+
+
+def test_module_publishing_docs_describe_modules_repo_flow() -> None:
+    publishing = _repo_file("docs/guides/publishing-modules.md").read_text(encoding="utf-8")
+    assert "specfact-cli-modules" in publishing
+    assert "Push to `dev` and `main`" in publishing
+    assert "tags matching `*-v*`" not in publishing
+
+
+def test_module_contracts_reference_external_bundle_boundary() -> None:
+    contracts_doc = _repo_file("docs/reference/module-contracts.md").read_text(encoding="utf-8")
+    assert "specfact-cli-modules" in contracts_doc
+    assert "Core runtime must not import external bundle package namespaces" in contracts_doc
+
+
+def test_docs_note_module_docs_are_temporarily_hosted_in_core() -> None:
+    readme = _repo_file("README.md").read_text(encoding="utf-8")
+    docs_index = _repo_file("docs/index.md").read_text(encoding="utf-8")
+    assert "temporarily hosted" in readme
+    assert "temporarily hosted" in docs_index
diff --git a/tests/unit/scripts/test_pre_commit_smart_checks_docs.py b/tests/unit/scripts/test_pre_commit_smart_checks_docs.py
new file mode 100644
index 00000000..41fa28e7
--- /dev/null
+++ b/tests/unit/scripts/test_pre_commit_smart_checks_docs.py
@@ -0,0 +1,25 @@
+from __future__ import annotations
+
+from pathlib import Path
+
+
+def _script_text() -> str:
+    return (Path(__file__).resolve().parents[3] / "scripts" / "pre-commit-smart-checks.sh").read_text(encoding="utf-8")
+
+
+def test_pre_commit_markdown_checks_run_autofix_before_lint() -> None:
+    script = _script_text()
+    assert "run_markdown_autofix_if_needed" in script
+    assert "markdownlint --fix --config .markdownlint.json" in script
+    assert "run_markdown_autofix_if_needed\nrun_markdown_lint_if_needed" in script
+
+
+def test_pre_commit_markdown_autofix_restages_files() -> None:
+    script = _script_text()
+    assert "xargs -r git add --" in script
+
+
+def test_pre_commit_markdown_autofix_rejects_partial_staging() -> None:
+    script = _script_text()
+    assert 'git diff --quiet -- "$file"' in script
+    assert "Cannot auto-fix Markdown with unstaged hunks" in script