📖 [Docs]: Deployment capability documented, and Capability/Framework unified into one model

[Marius Storhaug (MariusStorhaug)]

The docs now describe the deployment capability — how a change to managed resources is approved together with its effect and deployed exactly as approved — and they settle a long-standing split: Capability and Framework are one concept, documented the same way.

New: Deployment capability

A new capability under Capabilities covers deployment: a change's effect on every environment in the promotion path is computed and shown, the team approves the code change together with that effect as one decision, and the approved effect is exactly what deploys — failing closed on stale plans, with every action recorded. It ships a technology-agnostic spec plus a first design, Deploying Azure from GitHub (GitHub Actions and Terraform with passwordless OIDC identity). Each design is named "deploying a service provider from a CI/CD platform" so its two axes are clear, and the per-design pages live in a designs/ subfolder so more combinations can hang off the same spec.

Changed: One model for everything the ecosystem builds

A capability and a framework only differed by atomic building block versus a composition of building blocks — a property of the thing, not a reason for two documentation models. Everything is now documented one way: a spec (why and what) plus a design (how). Framework becomes an adjective for a capability whose design composes other capabilities, and the Frameworks section is being absorbed into Capabilities over time. The Documentation Model and the Capabilities and Frameworks index pages are updated to reflect this.

---

Technical details

• Deployment docs moved from MSXOrg/Platform@terraform-deployment-research into src/docs/Capabilities/deployment/ (index.md, spec.md, designs/azure-from-github.md), following the release-management house style. Cross-repo absolute msxorg.github.io links were converted to relative links.
• Designs are framed as "deploying a service provider from a CI/CD platform" (service provider = where resources live: Azure, AWS, GitHub; CI/CD platform = what runs the deployment: GitHub, Azure DevOps); the first design is azure-from-github.md.
• deployment/index.md keeps hand-written Spec/Designs tables (no INDEX:START/END markers): the auto-generator only lists direct files and subfolders that carry their own index.md, so a generated table would drop the designs/ design.
• Registered the pages in src/zensical.toml nav under Capabilities.
• Updated Ways-of-Working/Documentation-Model.md, Capabilities/index.md, and Frameworks/index.md for the taxonomy unification.
• Disabled markdownlint MD051: it cannot resolve python-markdown attr_list heading anchors ({ #fr1 }) — the ecosystem's documented anchor standard — so it false-positives on valid same-page requirement links; Test-DocumentationLink.ps1 remains the authoritative fragment validator.
• Ran Update-DocumentationIndex.ps1 and Test-DocumentationLink.ps1 before marking ready.
• Follow-on captured in Unify Capability and Framework into a single spec-and-design concept #102: migrate Process-PSModule and Agentic-Development into Capabilities with their own spec+design (Process-PSModule's living in MSXOrg/docs).

Relevant issues (or links)

• Closes Document the deployment capability in the docs Capabilities area #104
• Unify Capability and Framework into a single spec-and-design concept #102