feat(standards): seed standards/ from site + add STANDARDS.md stub (Phase 1)

.github/workflows/platform-ci.yml

@@ -24,6 +24,7 @@ jobs:
             !site/**
             !node_modules/**
             !.venv/**
+            !CHANGELOG.md
 
   yaml-lint:
     name: YAML lint

decisions/0003-maproom-iic-canon.md

@@ -0,0 +1,65 @@
+# ADR 0003 — MAPROOM framework & IIC canon centralization
+
+- **Status**: Proposed
+- **Date**: 2026-04-12
+- **Deciders**: @kristopherjturner
+
+## Context
+
+MAPROOM — the contract-testing framework that asserts a live target (cluster, host pool, tenancy, fleet) matches an expected shape encoded as a JSON fixture — currently lives in [`azurelocal-S2DCartographer/tests/maproom/`](https://github.com/AzureLocal/azurelocal-S2DCartographer/tree/main/tests/maproom). The IIC canon (`iic-org.json`, `iic-cluster-01.json`, `iic-networks.json`) — the canonical test data representing the fictional Infinite Improbability Corp environment — lives alongside it.
+
+Three problems today:
+
+1. **Framework is repo-locked.** A second consumer (`azurelocal-ranger`) exists; a third (`azurelocal-avd`, `azurelocal-sofs-fslogix`, etc.) is blocked on "go copy the framework, maybe." Forking the framework into each repo recreates the drift problem [ADR-0002](./0002-standards-single-source.md) just solved for standards.
+2. **IIC canon is repo-locked.** Same problem. Every consumer wants to assert "my cluster matches the IIC canonical shape"; none can without vendoring the canon.
+3. **Framework is S2D-shaped.** MAPROOM's vocabulary (pools, tiers, volumes, witness, fault domains) encodes cluster-fabric assumptions that don't fit non-fabric consumers (AVD host pools, FSLogix profile fleets, VM-conversion inventories, Nutanix source manifests).
+
+TRAILHEAD (scenario runner for user journeys) has the same shape of problem but smaller surface — it's templated enough today that centralizing it is straightforward; the open questions are about MAPROOM.
+
+## Decision
+
+**Proposed** — not yet accepted. The shape of the decision:
+
+1. Move MAPROOM framework → [`platform/testing/maproom/framework/`](../testing/maproom/). Ship as PowerShell module `AzureLocal.Maproom` (manifest + `.psm1`). Consumers reference by module name.
+2. Move TRAILHEAD harness + templates → [`platform/testing/trailhead/`](../testing/trailhead/). Consumers reference by path or, if module-shaped content emerges, `AzureLocal.Trailhead` sibling module.
+3. Move IIC canon → [`platform/testing/iic-canon/`](../testing/iic-canon/). Consumers reference canonical fixtures by path; additional per-domain canons (AVD, FSLogix, Nutanix) land here as they're authored, not in consumer repos.
+4. Publish schemas under [`platform/testing/maproom/schema/`](../testing/maproom/): `fixture.schema.json`, `iic-canon.schema.json`. All consumer fixtures validate against these in CI.
+5. Framework surface (what primitives `AzureLocal.Maproom` exposes) is **under classification review** in platform issue [#3](https://github.com/AzureLocal/platform/issues/3). This ADR is blocked on that issue — Phase 2 implementation does not start until classification lands.
+
+## Consequences
+
+### Positive
+
+- One canonical MAPROOM implementation; no per-repo forks.
+- IIC canon is genuinely canonical — the same JSON powers every consumer's contract tests.
+- Schema-gated fixtures catch drift between consumers and framework at PR time.
+- Non-S2D consumers become plausible — the classification work (issue #3) ensures the framework surface actually fits their shapes.
+
+### Negative
+
+- Consumers pay a coupling cost — bumping `AzureLocal.Maproom` is a platform PR, and consumers see the new version on schedule, not on demand.
+- Module-based distribution means consumers need either a Git-referenced install or (eventually) PSGallery publication. Phase 2 uses Git reference; PSGallery is deferred until the public surface stabilizes.
+- Decoupling the framework from S2D-specific assumptions is non-trivial and is the actual design work — captured in issue [#3](https://github.com/AzureLocal/platform/issues/3).
+
+### Neutral
+
+- `azurelocal-S2DCartographer` becomes the first migration — its current `tests/maproom/` is the reference implementation being ported, and once ported it becomes the first consumer of the centralized framework.
+- `azurelocal-ranger` becomes the **second** consumer, deliberately chosen — two consumers is the minimum signal that the framework isn't secretly S2DCartographer-shaped.
+
+### Affected repos / owners
+
+- **`AzureLocal/platform`**: gains `testing/maproom/`, `testing/trailhead/`, `testing/iic-canon/`. Phase 2 work.
+- **`azurelocal-S2DCartographer`**: existing `tests/maproom/` is re-pointed at the platform module. Local copy of framework code is deleted; fixtures + tests remain.
+- **`azurelocal-ranger`**: switches to consuming platform MAPROOM. Second-consumer validation.
+- **All other product repos**: opt in as their use case matures; required testing surface is documented in [Testing Standards](../standards/testing.mdx).
+
+## Alternatives considered
+
+- **Keep MAPROOM in S2DCartographer, let consumers reference it directly.** Rejected — same drift pattern standards had; cross-repo references are fragile and discoverability is poor.
+- **Fork MAPROOM into each consuming repo.** Rejected — this is the current state and is exactly what's not working.
+- **Publish `AzureLocal.Maproom` to PSGallery in v1.** Rejected for now — surface will churn during Phase 2; PSGallery deferred until v0.3 at earliest, probably v1.0.
+- **Generalize the framework in-place (inside `azurelocal-S2DCartographer`).** Rejected — the repo's identity is S2D, not platform tooling; generalization would make the repo's purpose less clear.
+
+## Status
+
+Proposed 2026-04-12. Blocked on issue [#3](https://github.com/AzureLocal/platform/issues/3) — classification rubric for testing toolsets must land before this ADR can be accepted. Phase 2 implementation does not start until that resolves.

standards/automation.mdx

@@ -0,0 +1,70 @@
+# Automation Interoperability
+
+> **Canonical reference:** [Scripting Framework (full)](https://azurelocal.cloud/standards/scripting/scripting-framework)  
+> **Applies to:** All AzureLocal repositories  
+> **Last Updated:** 2026-03-17
+
+---
+
+## Overview
+
+This standard defines how multiple automation tools (Terraform, Bicep, ARM, PowerShell, Ansible) interoperate across AzureLocal solutions. All tools share a single configuration source and must produce identical infrastructure.
+
+---
+
+## Config Flow
+
+```mermaid
+flowchart TB
+    A["config/variables/variables.yml<br/>(single source of truth)"] --> B[Terraform .tfvars]
+    A --> C[Bicep .bicepparam]
+    A --> D[ARM parameters.json]
+    A --> E[PowerShell ConvertFrom-Yaml]
+    A --> F[Ansible group_vars]
+    B --> G[Identical Infrastructure]
+    C --> G
+    D --> G
+    E --> G
+    F --> G
+```
+
+---
+
+## Deployment Path Matrix
+
+| Tool | Azure Resources | Configuration | Monitoring | Scaling |
+|------|:---:|:---:|:---:|:---:|
+| **Terraform** | ✅ | Delegates | ✅ | ✅ |
+| **Bicep** | ✅ | Delegates | ✅ | ✅ |
+| **ARM** | ✅ | Delegates | ✅ | — |
+| **PowerShell** | ✅ | ✅ | ✅ | ✅ |
+| **Ansible** | ✅ | ✅ | ✅ | ✅ |
+
+:::warning[Delegates]
+"Delegates" means the IaC tool provisions Azure resources but does not configure the guest OS or application layer. A separate tool (PowerShell or Ansible) handles guest configuration.
+:::
+
+---
+
+## Interoperability Rules
+
+1. **Single source of truth** — `config/variables/variables.yml` is the only config file. All tool-specific parameter files are derived.
+2. **Identical output** — Given the same config, every tool must produce the same infrastructure.
+3. **Idempotency** — All scripts and templates must be safe to re-run.
+4. **Error handling** — Every tool must validate config before executing changes.
+5. **Logging** — All operations logged to `./logs/` with consistent format.
+
+---
+
+## Variable Path Contract
+
+Scripts must use variable paths that exist in the schema. See the [Variable Standards](variables) for naming rules and the [Variable Reference](variables) for the complete catalog.
+
+---
+
+## Related Standards
+
+- [Scripting Standards](scripting)
+- [Infrastructure Standards](infrastructure)
+- [Solution Standards](solutions)
+- [Variable Standards](variables)

standards/documentation.mdx

@@ -0,0 +1,75 @@
+# Documentation Standards
+
+> **Canonical reference:** [Documentation Standards (full)](https://azurelocal.cloud/standards/documentation/documentation-standards)  
+> **Applies to:** All AzureLocal repositories  
+> **Last Updated:** 2026-03-17
+
+---
+
+## Principles
+
+| Principle | Rule |
+|-----------|------|
+| Documentation-First | Document **before** implementing. Keep docs current with code. |
+| Single Source of Truth | One authoritative document per topic. Cross-reference, don't duplicate. |
+| Audience-Aware | Write for operators, developers, or executives — with appropriate depth. |
+| Actionable | Step-by-step procedures, examples, prerequisites, and outcomes. |
+
+---
+
+## File Naming
+
+| Type | Convention | Pattern | Example |
+|------|-----------|---------|---------|
+| Directories | lowercase-with-hyphens | `^[a-z][a-z0-9-]*$` | `guides/`, `reference/` |
+| Markdown (docs/) | lowercase with hyphens | `*.md` | `deployment-guide.md` |
+| Root files | UPPERCASE | — | `README.md`, `CHANGELOG.md`, `CONTRIBUTING.md` |
+| PowerShell scripts | PascalCase | `Verb-Noun.ps1` | `Deploy-Solution.ps1` |
+| Config files | lowercase-with-hyphens | — | `variables.example.yml` |
+
+---
+
+## MkDocs Material Conventions
+
+This repo uses **MkDocs Material** with the following conventions:
+
+- **Admonitions**: Use `!!! note`, `!!! warning`, `!!! danger`, `!!! info`, `!!! tip`
+- **Code blocks**: Always include a language identifier (e.g., ` ```powershell `, ` ```yaml `)
+- **Code copy**: Enabled via `content.code.copy`
+- **Mermaid diagrams**: Supported via `pymdownx.superfences` custom fence
+- **Tables**: Use standard Markdown tables
+- **Tabs**: Use `=== "Tab Name"` via `pymdownx.tabbed`
+
+---
+
+## Frontmatter & Metadata
+
+Every documentation page should include:
+
+```markdown
+# Page Title
+
+> Brief one-line description of the page's purpose.
+
+---
+```
+
+---
+
+## Fictional Company — Infinite Improbability Corp (IIC)
+
+All examples must use IIC. See the [Examples & IIC Policy](examples) page for the full reference card.
+
+| Never Use | Use Instead |
+|-----------|-------------|
+| `contoso`, `fabrikam`, `northwind` | Infinite Improbability Corp |
+| `example.com`, `test.com` | `improbability.cloud` |
+| Real customer names | IIC naming patterns |
+
+---
+
+## Related Standards
+
+- [Naming Conventions (full reference)](https://azurelocal.cloud/standards/documentation/naming-conventions)
+- [Badge Library](https://azurelocal.cloud/standards/documentation/badge-library)
+- [Scripting Standards](scripting)

standards/examples.mdx

@@ -0,0 +1,104 @@
+# Examples & IIC Policy
+
+> **Canonical reference:** [Fictional Company Policy (full)](https://azurelocal.cloud/standards/fictional-company-policy)  
+> **Applies to:** All AzureLocal repositories  
+> **Last Updated:** 2026-03-17
+
+---
+
+## Policy
+
+All examples, sample configurations, and walkthroughs use **one** fictional company: **Infinite Improbability Corp (IIC)**.
+
+:::warning[Mandatory]
+Never use `contoso`, `fabrikam`, `adventure-works`, `woodgrove`, `example.com`, or any real customer name.
+    **IIC only** — in every repo, every example, every sample config.
+:::
+
+---
+
+## IIC Reference Card
+
+| Attribute | Value |
+|-----------|-------|
+| **Full Name** | Infinite Improbability Corp |
+| **Abbreviation** | IIC |
+| **Domain (public)** | `improbability.cloud` / `iic.cloud` |
+| **Domain (on-prem AD)** | `iic.local` |
+| **NetBIOS Name** | `IMPROBABLE` |
+| **Entra ID Tenant** | `improbability.onmicrosoft.com` |
+| **Email Pattern** | `user@improbability.cloud` |
+
+---
+
+## AzureLocal Naming Patterns
+
+### Azure Resources
+
+| Resource | Pattern | Example |
+|----------|---------|---------|
+| Resource Group | `rg-iic-<purpose>-<##>` | `rg-iic-platform-01` |
+| Virtual Network | `vnet-iic-<purpose>-<##>` | `vnet-iic-compute-01` |
+| Subnet | `snet-iic-<purpose>` | `snet-iic-management` |
+| Network Security Group | `nsg-iic-<purpose>` | `nsg-iic-compute` |
+| Key Vault | `kv-iic-<purpose>` | `kv-iic-platform` |
+| Storage Account | `stiic<purpose><##>` | `stiicdata01` |
+| Log Analytics | `law-iic-<purpose>-<##>` | `law-iic-monitor-01` |
+| Managed Identity | `id-iic-<purpose>` | `id-iic-deploy` |
+
+### Active Directory
+
+| Resource | Pattern | Example |
+|----------|---------|---------|
+| OU path | `OU=<Purpose>,OU=Servers,DC=iic,DC=local` | — |
+| Service account | `svc.iic.<purpose>` | `svc.iic.deploy` |
+| Group | `grp-iic-<purpose>` | `grp-iic-admins` |
+
+### IP Addresses
+
+| Network | Range | Usage |
+|---------|-------|-------|
+| Management | `10.0.0.0/24` | Node management |
+| Compute | `10.0.2.0/24` | Workload traffic |
+
+---
+
+## Real Identities
+
+| Name | Usage |
+|------|-------|
+| **Azure Local Cloud** | Community project, GitHub org, `azurelocal.cloud` |
+| **Hybrid Cloud Solutions** | Author/maintainer LLC, script headers, copyright |
+
+---
+
+## Usage Examples
+
+### In `config/variables/variables.example.yml`
+
+```yaml
+subscription:
+  subscription_id: "00000000-0000-0000-0000-000000000000"
+  tenant_id: "00000000-0000-0000-0000-000000000000"
+  location: "eastus"
+
+security:
+  keyvault_name: "kv-iic-platform"
+
+azure_local:
+  resource_group: "rg-iic-platform-01"
+  cluster_name: "azlocal-iic-01"
+```
+
+### In Documentation
+
+> Infinite Improbability Corp deploys Azure Local clusters using IIC naming patterns,
+> with all configuration driven from a single `config/variables/variables.yml` file.
+
+---
+
+## Enforcement
+
+- **PR review**: Reviewers flag any use of `contoso`, `fabrikam`, or other non-IIC names
+- **Config validation**: `variables.example.yml` uses IIC naming in all placeholders
+- **CI**: Vale linting rules flag non-IIC fictional company names (when configured)

standards/index.mdx

@@ -0,0 +1,47 @@
+---
+title: "Standards"
+sidebar_label: "Standards"
+sidebar_position: 10
+description: "Standards and conventions"
+---
+
+# Standards
+
+This repository follows the **org-wide AzureLocal standards** maintained on the central documentation site.
+
+:::info[Central Standards]
+The full standards suite is at [azurelocal.cloud/standards](https://azurelocal.cloud/standards/).
+    This section provides the key rules adapted for this solution.
+:::
+
+---
+
+## Standards Pages
+
+| Standard | Local Page | Central Reference |
+|----------|-----------|------------------|
+| Documentation | [Documentation Standards](documentation) | [Full Reference](https://azurelocal.cloud/standards/documentation/documentation-standards) |
+| Repository Management | [Repository Management Standard](repository-management) | [Full Reference](https://azurelocal.cloud/standards/repository-management/) |
+| Scripting | [Scripting Standards](scripting) | [Full Reference](https://azurelocal.cloud/standards/scripting/scripting-standards) |
+| Variables | [Variable Standards](variables) | [Full Reference](https://azurelocal.cloud/standards/variable-management/) |
+| Naming Conventions | [Naming Conventions](naming) | [Full Reference](https://azurelocal.cloud/standards/documentation/naming-conventions) |
+| Solutions | [Solution Standards](solutions) | [Full Reference](https://azurelocal.cloud/standards/solutions/solution-development-standard) |
+| Infrastructure | [Infrastructure Standards](infrastructure) | [Full Reference](https://azurelocal.cloud/standards/infrastructure/) |
+| Automation | [Automation Interoperability](automation) | [Full Reference](https://azurelocal.cloud/standards/scripting/scripting-framework) |
+| Examples & IIC | [Examples & IIC](examples) | [Full Reference](https://azurelocal.cloud/standards/fictional-company-policy) |
+
+---
+
+## References
+
+- [Variable Reference](variables) — Per-variable catalog for this repo
+- [Repository Structure](https://azurelocal.cloud/standards/repo-structure) — Required file layout
+- [Repository Management Standard](repository-management) — Portfolio-level governance and repo-management contract
+
+---
+
+## Repo-Specific Conventions
+
+- **IaC tooling**: Terraform, Bicep, ARM, PowerShell, Ansible
+- **Config contract**: runtime `config/variables/variables.yml`, template `config/variables/variables.example.yml`, schema `config/variables/schema/variables.schema.json`, bootstrap policy defined in [Variable Standards](variables)
+- **Fictional company**: Infinite Improbability Corp (IIC) — see [IIC Policy](examples)