Unify Capability and Framework into one spec-and-design model

Document framework as an adjective for a capability whose design composes other
capabilities, note the Frameworks section is being absorbed into Capabilities,
and regenerate the affected index tables.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Author: MariusStorhaug

src/docs/Capabilities/index.md

@@ -12,6 +12,11 @@ capability's folder. See the
 [Documentation Model](../Ways-of-Working/Documentation-Model.md) for how spec
 and design relate and evolve.
 
+A capability whose design **composes other capabilities** is called a
+*framework* — an adjective, not a different kind of document. It lives here with
+the same spec-and-design shape as any other capability; the standalone
+[Frameworks](../Frameworks/index.md) section is being folded into this one.
+
 <!-- INDEX:START -->
 
 | Section | Description |
@@ -20,6 +25,7 @@ and design relate and evolve.
 | [Dependency Updates](dependency-updates/index.md) | How a repository's pinned dependencies are kept current and secure through automated, labelled update pull requests. |
 | [Merge Automation](merge-automation/index.md) | How a pull request's required status checks become the machine-readable signal that drives automated approval and merge — green merges, red holds, nothing bypasses the gate. |
 | [Downstream Release Propagation](downstream-release-propagation/index.md) | How a release in one repository propagates to the repositories that depend on it, via a delegated agent pull request. |
+| [Deployment](deployment/index.md) | How a change to managed resources is approved together with its effect and deployed exactly as approved — one spec, one design per deployment platform and service provider. |
 | [VS Code Extension Framework](vscode-extension-framework/index.md) | How a VS Code extension is built, tested, versioned, packaged, and published — one GitHub-native pipeline, opt-in from a template and a single settings file. |
 | [PowerShell on GitHub](powershell-on-github/index.md) | How we make GitHub a first-class platform for PowerShell through reusable modules, actions, and capability gaps we close over time. |
 

src/docs/Frameworks/index.md

@@ -1,18 +1,22 @@
 ---
 title: Frameworks
-description: The complete, end-to-end frameworks the ecosystem ships — opinionated automation a project adopts wholesale to go from source to shipped.
+description: Frameworks are capabilities whose design composes other capabilities — being absorbed into Capabilities, documented with the same spec and design.
 ---
 
 # Frameworks
 
-The complete, end-to-end frameworks a project adopts wholesale. Where a
-[capability](../Capabilities/index.md) is a single independently versioned thing
-the ecosystem builds, a framework composes many of them into one opinionated
-pipeline that takes a repository from source to shipped with a single
-configuration file.
-
-Each framework is documented as its own section — an overview plus the pages that
-cover how it works, how to use it, and how to configure it.
+A *framework* is a [capability](../Capabilities/index.md) whose design **composes
+other capabilities** into one opinionated pipeline that takes a repository from
+source to shipped with a single configuration file. "Framework" is an adjective
+for that kind of capability, not a separate documentation model: each framework
+carries the same **spec** and **design** as any other capability.
+
+This standalone section is being **absorbed into
+[Capabilities](../Capabilities/index.md)** — the evidence it should be is already
+here: `vscode-extension-framework` lives under Capabilities with a spec and a
+design, while the pages below still lack that pair. As each framework gains its
+spec and design it moves under Capabilities; until then it is documented as its
+own section here.
 
 <!-- INDEX:START -->
 

src/docs/Ways-of-Working/Documentation-Model.md

@@ -26,6 +26,13 @@ user (human or agent) can rely on. It never prescribes implementation. The
 mechanism, the moving parts, the configuration. Both are durable, and both
 evolve — neither is a one-time plan.
 
+Everything the ecosystem builds is documented this one way — there is no second
+shape. A capability whose **design composes other capabilities** is simply called
+a *framework*: "framework" is an adjective for that kind of capability, not a
+separate section or a different pair of documents. It carries the same spec and
+design as any other capability, and lives beside them under
+[Capabilities](../Capabilities/index.md).
+
 Only the detail of a *single change* — the paths touched, the trade-off taken
 this once — stays out of both, living in the [issue](Issues/Process/Format.md) and the
 pull request where it belongs.

src/docs/index.md

@@ -50,7 +50,7 @@ Each area below carries its own index. Start here, read the descriptions, and fo
 | [Agents](Agents/index.md) | The roles agents play across the ecosystem — authored once as documentation and pointed to from each repository. |
 | [Coding Standards](Coding-Standards/index.md) | The shared baseline every repository inherits, and the per-language standards that build on it. |
 | [Capabilities](Capabilities/index.md) | The capabilities the ecosystem builds, each documented by a spec (why and what) and a design (how and what). |
-| [Frameworks](Frameworks/index.md) | The complete, end-to-end frameworks the ecosystem ships — opinionated automation a project adopts wholesale to go from source to shipped. |
+| [Frameworks](Frameworks/index.md) | Frameworks are capabilities whose design composes other capabilities — being absorbed into Capabilities, documented with the same spec and design. |
 | [Dictionary](Dictionary/index.md) | Shared vocabulary for the MSX ecosystem — the terms a reader or agent meets across these docs. |
 
 <!-- INDEX:END -->