ac-framework 1.5.0 → 1.6.0

package/framework/.augment/commands/opsx-new.md

@@ -24,27 +24,27 @@ Start a new change using the experimental artifact-driven approach.
 
    **Use a different schema only if the user mentions:**
    - A specific schema name → use `--schema <name>`
-   - "show workflows" or "what workflows" → run `openspec schemas --json` and let them choose
+   - "show workflows" or "what workflows" → run `acfm spec schemas --json` and let them choose
 
    **Otherwise**: Omit `--schema` to use the default.
 
 3. **Create the change directory**
    ```bash
-   openspec new change "<name>"
+   acfm spec new "<name>"
    ```
    Add `--schema <name>` only if the user requested a specific workflow.
    This creates a scaffolded change at `openspec/changes/<name>/` with the selected schema.
 
 4. **Show the artifact status**
    ```bash
-   openspec status --change "<name>"
+   acfm spec status --change "<name>"
    ```
    This shows which artifacts need to be created and which are ready (dependencies satisfied).
 
 5. **Get instructions for the first artifact**
    The first artifact depends on the schema. Check the status output to find the first artifact with status "ready".
    ```bash
-   openspec instructions <first-artifact-id> --change "<name>"
+   acfm spec instructions <first-artifact-id> --change "<name>"
    ```
    This outputs the template and context for creating the first artifact.
 

package/framework/.augment/commands/opsx-onboard.md

@@ -12,11 +12,11 @@ Guide the user through their first complete OpenSpec workflow cycle. This is a t
 Before starting, check if OpenSpec is initialized:
 
 ```bash
-openspec status --json 2>&1 || echo "NOT_INITIALIZED"
+acfm spec status --json 2>&1 || echo "NOT_INITIALIZED"
 ```
 
 **If not initialized:**
-> OpenSpec isn't set up in this project yet. Run `openspec init` first, then come back to `/opsx:onboard`.
+> OpenSpec isn't set up in this project yet. Run `acfm spec init` first, then come back to `/opsx:onboard`.
 
 Stop here if not initialized.
 
@@ -162,7 +162,7 @@ Let me create one for our task.
 
 **DO:** Create the change with a derived kebab-case name:
 ```bash
-openspec new change "<derived-name>"
+acfm spec new "<derived-name>"
 ```
 
 **SHOW:**
@@ -231,7 +231,7 @@ Does this capture the intent? I can adjust before we save it.
 
 After approval, save the proposal:
 ```bash
-openspec instructions proposal --change "<name>" --json
+acfm spec instructions proposal --change "<name>" --json
 ```
 Then write the content to `openspec/changes/<name>/proposal.md`.
 
@@ -417,7 +417,7 @@ Archived changes become your project's decision history—you can always find th
 
 **DO:**
 ```bash
-openspec archive "<name>"
+acfm spec archive "<name>"
 ```
 
 **SHOW:**

package/framework/.augment/commands/opsx-sync.md

@@ -13,7 +13,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 1. **If no change name provided, prompt for selection**
 
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+   Run `acfm spec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have delta specs (under `specs/` directory).
 

package/framework/.augment/commands/opsx-verify.md

@@ -11,7 +11,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 
 1. **If no change name provided, prompt for selection**
 
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+   Run `acfm spec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have implementation tasks (tasks artifact exists).
    Include the schema used for each change if available.
@@ -21,7 +21,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 
 2. **Check status to understand the schema**
    ```bash
-   openspec status --change "<name>" --json
+   acfm spec status --change "<name>" --json
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
@@ -30,7 +30,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 3. **Get the change directory and load artifacts**
 
    ```bash
-   openspec instructions apply --change "<name>" --json
+   acfm spec instructions apply --change "<name>" --json
    ```
 
    This returns the change directory and context files. Read all available artifacts from `contextFiles`.

package/framework/.augment/skills/openspec-apply-change/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-apply-change
 description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -20,13 +20,13 @@ Implement tasks from an OpenSpec change.
    If a name is provided, use it. Otherwise:
    - Infer from conversation context if the user mentioned a change
    - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+   - If ambiguous, run `acfm spec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
 
    Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
 
 2. **Check status to understand the schema**
    ```bash
-   openspec status --change "<name>" --json
+   acfm spec status --change "<name>" --json
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
@@ -35,7 +35,7 @@ Implement tasks from an OpenSpec change.
 3. **Get apply instructions**
 
    ```bash
-   openspec instructions apply --change "<name>" --json
+   acfm spec instructions apply --change "<name>" --json
    ```
 
    This returns:

package/framework/.augment/skills/openspec-archive-change/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-archive-change
 description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -17,7 +17,7 @@ Archive a completed change in the experimental workflow.
 
 1. **If no change name provided, prompt for selection**
 
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+   Run `acfm spec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show only active changes (not already archived).
    Include the schema used for each change if available.
@@ -26,7 +26,7 @@ Archive a completed change in the experimental workflow.
 
 2. **Check artifact completion status**
 
-   Run `openspec status --change "<name>" --json` to check artifact completion.
+   Run `acfm spec status --change "<name>" --json` to check artifact completion.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
@@ -106,7 +106,7 @@ All artifacts complete. All tasks complete.
 
 **Guardrails**
 - Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
+- Use artifact graph (acfm spec status --json) for completion checking
 - Don't block archive on warnings - just inform and confirm
 - Preserve .openspec.yaml when moving to archive (it moves with the directory)
 - Show clear summary of what happened

package/framework/.augment/skills/openspec-bulk-archive-change/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-bulk-archive-change
 description: Archive multiple completed changes at once. Use when archiving several parallel changes.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -19,7 +19,7 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
 1. **Get active changes**
 
-   Run `openspec list --json` to get all active changes.
+   Run `acfm spec list --json` to get all active changes.
 
    If no active changes exist, inform user and stop.
 
@@ -36,7 +36,7 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
    For each selected change, collect:
 
-   a. **Artifact status** - Run `openspec status --change "<name>" --json`
+   a. **Artifact status** - Run `acfm spec status --change "<name>" --json`
       - Parse `schemaName` and `artifacts` list
       - Note which artifacts are `done` vs other states
 

package/framework/.augment/skills/openspec-continue-change/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-continue-change
 description: Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -17,7 +17,7 @@ Continue working on a change by creating the next artifact.
 
 1. **If no change name provided, prompt for selection**
 
-   Run `openspec list --json` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
+   Run `acfm spec list --json` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
 
    Present the top 3-4 most recently modified changes as options, showing:
    - Change name
@@ -31,7 +31,7 @@ Continue working on a change by creating the next artifact.
 
 2. **Check current status**
    ```bash
-   openspec status --change "<name>" --json
+   acfm spec status --change "<name>" --json
    ```
    Parse the JSON to understand current state. The response includes:
    - `schemaName`: The workflow schema being used (e.g., "spec-driven")
@@ -54,7 +54,7 @@ Continue working on a change by creating the next artifact.
    - Pick the FIRST artifact with `status: "ready"` from the status output
    - Get its instructions:
      ```bash
-     openspec instructions <artifact-id> --change "<name>" --json
+     acfm spec instructions <artifact-id> --change "<name>" --json
      ```
    - Parse the JSON. The key fields are:
      - `context`: Project background (constraints for you - do NOT include in output)
@@ -79,7 +79,7 @@ Continue working on a change by creating the next artifact.
 
 4. **After creating an artifact, show progress**
    ```bash
-   openspec status --change "<name>"
+   acfm spec status --change "<name>"
    ```
 
 **Output**

package/framework/.augment/skills/openspec-explore/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-explore
 description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -83,7 +83,7 @@ You have full context of the OpenSpec system. Use it naturally, don't force it.
 
 At the start, quickly check what exists:
 ```bash
-openspec list --json
+acfm spec list --json
 ```
 
 This tells you:

package/framework/.augment/skills/openspec-ff-change/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-ff-change
 description: Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -26,13 +26,13 @@ Fast-forward through artifact creation - generate everything needed to start imp
 
 2. **Create the change directory**
    ```bash
-   openspec new change "<name>"
+   acfm spec new "<name>"
    ```
    This creates a scaffolded change at `openspec/changes/<name>/`.
 
 3. **Get the artifact build order**
    ```bash
-   openspec status --change "<name>" --json
+   acfm spec status --change "<name>" --json
    ```
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
@@ -47,7 +47,7 @@ Fast-forward through artifact creation - generate everything needed to start imp
    a. **For each artifact that is `ready` (dependencies satisfied)**:
       - Get instructions:
         ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
+        acfm spec instructions <artifact-id> --change "<name>" --json
         ```
       - The instructions JSON includes:
         - `context`: Project background (constraints for you - do NOT include in output)
@@ -62,7 +62,7 @@ Fast-forward through artifact creation - generate everything needed to start imp
       - Show brief progress: "✓ Created <artifact-id>"
 
    b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - After creating each artifact, re-run `acfm spec status --change "<name>" --json`
       - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
       - Stop when all `applyRequires` artifacts are done
 
@@ -72,7 +72,7 @@ Fast-forward through artifact creation - generate everything needed to start imp
 
 5. **Show final status**
    ```bash
-   openspec status --change "<name>"
+   acfm spec status --change "<name>"
    ```
 
 **Output**
@@ -85,7 +85,7 @@ After completing all artifacts, summarize:
 
 **Artifact Creation Guidelines**
 
-- Follow the `instruction` field from `openspec instructions` for each artifact type
+- Follow the `instruction` field from `acfm spec instructions` for each artifact type
 - The schema defines what each artifact should contain - follow it
 - Read dependency artifacts for context before creating new ones
 - Use `template` as the structure for your output file - fill in its sections

package/framework/.augment/skills/openspec-new-change/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-new-change
 description: Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -30,20 +30,20 @@ Start a new change using the experimental artifact-driven approach.
 
    **Use a different schema only if the user mentions:**
    - A specific schema name → use `--schema <name>`
-   - "show workflows" or "what workflows" → run `openspec schemas --json` and let them choose
+   - "show workflows" or "what workflows" → run `acfm spec schemas --json` and let them choose
 
    **Otherwise**: Omit `--schema` to use the default.
 
 3. **Create the change directory**
    ```bash
-   openspec new change "<name>"
+   acfm spec new "<name>"
    ```
    Add `--schema <name>` only if the user requested a specific workflow.
    This creates a scaffolded change at `openspec/changes/<name>/` with the selected schema.
 
 4. **Show the artifact status**
    ```bash
-   openspec status --change "<name>"
+   acfm spec status --change "<name>"
    ```
    This shows which artifacts need to be created and which are ready (dependencies satisfied).
 
@@ -51,7 +51,7 @@ Start a new change using the experimental artifact-driven approach.
    The first artifact depends on the schema (e.g., `proposal` for spec-driven).
    Check the status output to find the first artifact with status "ready".
    ```bash
-   openspec instructions <first-artifact-id> --change "<name>"
+   acfm spec instructions <first-artifact-id> --change "<name>"
    ```
    This outputs the template and context for creating the first artifact.
 

package/framework/.augment/skills/openspec-onboard/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-onboard
 description: Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -18,11 +18,11 @@ Guide the user through their first complete OpenSpec workflow cycle. This is a t
 Before starting, check if OpenSpec is initialized:
 
 ```bash
-openspec status --json 2>&1 || echo "NOT_INITIALIZED"
+acfm spec status --json 2>&1 || echo "NOT_INITIALIZED"
 ```
 
 **If not initialized:**
-> OpenSpec isn't set up in this project yet. Run `openspec init` first, then come back to `/opsx:onboard`.
+> OpenSpec isn't set up in this project yet. Run `acfm spec init` first, then come back to `/opsx:onboard`.
 
 Stop here if not initialized.
 
@@ -168,7 +168,7 @@ Let me create one for our task.
 
 **DO:** Create the change with a derived kebab-case name:
 ```bash
-openspec new change "<derived-name>"
+acfm spec new "<derived-name>"
 ```
 
 **SHOW:**
@@ -237,7 +237,7 @@ Does this capture the intent? I can adjust before we save it.
 
 After approval, save the proposal:
 ```bash
-openspec instructions proposal --change "<name>" --json
+acfm spec instructions proposal --change "<name>" --json
 ```
 Then write the content to `openspec/changes/<name>/proposal.md`.
 
@@ -423,7 +423,7 @@ Archived changes become your project's decision history—you can always find th
 
 **DO:**
 ```bash
-openspec archive "<name>"
+acfm spec archive "<name>"
 ```
 
 **SHOW:**

package/framework/.augment/skills/openspec-sync-specs/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-sync-specs
 description: Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -19,7 +19,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 1. **If no change name provided, prompt for selection**
 
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+   Run `acfm spec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have delta specs (under `specs/` directory).
 

package/framework/.augment/skills/openspec-verify-change/SKILL.md

@@ -2,7 +2,7 @@
 name: openspec-verify-change
 description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires acfm CLI (bundled).
 metadata:
   author: openspec
   version: "1.0"
@@ -17,7 +17,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 
 1. **If no change name provided, prompt for selection**
 
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+   Run `acfm spec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
 
    Show changes that have implementation tasks (tasks artifact exists).
    Include the schema used for each change if available.
@@ -27,7 +27,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 
 2. **Check status to understand the schema**
    ```bash
-   openspec status --change "<name>" --json
+   acfm spec status --change "<name>" --json
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
@@ -36,7 +36,7 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 3. **Get the change directory and load artifacts**
 
    ```bash
-   openspec instructions apply --change "<name>" --json
+   acfm spec instructions apply --change "<name>" --json
    ```
 
    This returns the change directory and context files. Read all available artifacts from `contextFiles`.

package/framework/.augment/skills/performance-optimizer/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: performance-optimizer
+description: Transform the agent into a performance engineer. Apply methodologies for measuring, profiling, and optimizing code (caching, algorithm complexity, resource usage).
+---
+
+# Performance Optimization
+
+## Overview
+
+Use this skill to analyze and improve the performance of the codebase. Focus on measurable improvements, not premature optimization.
+
+## Workflow
+
+1.  **Measure First**:
+    *   Never optimize without a baseline.
+    *   Use profiling tools or simple timing logs to identify bottlenecks.
+    *   "What gets measured, gets managed."
+
+2.  **Analyze and Hypothesize**:
+    *   Identify the root cause: CPU, Memory, I/O, or Network?
+    *   Look for common culprits: N+1 queries, unoptimized loops, large payload sizes, unnecessary re-renders (frontend).
+
+3.  **Optimize**:
+    *   **Algorithmic**: Improve Big-O complexity (e.g., O(n^2) -> O(n)).
+    *   **Caching**: Implement caching strategies (in-memory, Redis, HTTP caching).
+    *   **Database**: Add indexes, optimize queries, use batching.
+    *   **Frontend**: Lazy loading, memoization, code splitting, asset optimization.
+
+4.  **Verify**:
+    *   Run the measurements again.
+    *   Confirm the improvement.
+    *   Ensure no regression in functionality.
+
+## Techniques & Patterns
+
+*   **Database**: Explain Analyze, Indexing, Connection Pooling.
+*   **Backend**: Async processing, Caching layers, Load balancing.
+*   **Frontend**: Virtualization for long lists, Debouncing/Throttling events.
+
+## Output
+
+*   Create a brief report of findings and improvements.
+*   Update code with optimized solution.

package/framework/.augment/skills/project-constitution/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: project-constitution
+description: Manage the project's core principles and ensuring alignment. Create or update the project constitution from interactive or provided principle inputs.
+---
+
+# Project Constitution Management
+
+## Overview
+
+You are updating the project constitution at `.specify/memory/constitution.md` (or `.specify/.specify/memory/constitution.md` if the user's structure differs). This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
+
+**Note**: If the constitution file does not exist yet, it should have been initialized from a template during project setup. If it's missing, copy the template first (check `.specify/templates/constitution-template.md`).
+
+## Execution Flow
+
+1.  **Load the existing constitution**.
+    *   Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
+    *   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
+
+2.  **Collect/derive values for placeholders**:
+    *   If user input (conversation) supplies a value, use it.
+    *   Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
+    *   For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
+    *   `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
+        *   MAJOR: Backward incompatible governance/principle removals or redefinitions.
+        *   MINOR: New principle/section added or materially expanded guidance.
+        *   PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
+    *   If version bump type ambiguous, propose reasoning before finalizing.
+
+3.  **Draft the updated constitution content**:
+    *   Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
+    *   Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
+    *   Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
+    *   Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
+
+4.  **Consistency propagation checklist**:
+    *   Check if `.specify/templates/plan-template.md`, `.specify/templates/spec-template.md`, and any other templates align with the updated constitution.
+    *   Update runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`) if they reference changed principles.
+
+5.  **Produce a Sync Impact Report** (prepend as an HTML comment at top of the constitution file after update):
+    *   Version change: old → new
+    *   List of modified principles (old title → new title if renamed)
+    *   Added/Removed sections
+    *   Templates requiring updates (✅ updated / ⚠ pending) with file paths
+    *   Follow-up TODOs.
+
+6.  **Validation before final output**:
+    *   No remaining unexplained bracket tokens.
+    *   Version line matches report.
+    *   Dates ISO format YYYY-MM-DD.
+    *   Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
+
+7.  **Write the completed constitution** back to the file (overwrite).
+
+8.  **Output a final summary**:
+    *   New version and bump rationale.
+    *   Any files flagged for manual follow-up.
+    *   Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
+
+## Formatting & Style Requirements
+
+*   Use Markdown headings exactly as in the template.
+*   Wrap long rationale lines to keep readability (<100 chars ideally).
+*   Keep a single blank line between sections.
+*   Avoid trailing whitespace.
+*   If critical info missing, insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report.