feat: Azure DevOps repo support

.gitattributes

@@ -0,0 +1,5 @@
+# Shell scripts must check out LF everywhere: bash (incl. Git Bash on Windows) chokes on
+# CRLF (`set -uo pipefail\r` is an invalid option), so an autocrlf checkout would install
+# broken hooks and rails scripts — and broke the Windows CI leg running the hook tests.
+# pwsh is CRLF-tolerant, so .ps1 files are left to the platform default.
+*.sh text eol=lf

README.md

@@ -153,6 +153,12 @@ Full enterprise stack with compliance:
 - **Visual verification:** Screenshot capture with manual baseline comparison
 - **Evaluation criteria:** Phase-scoped rubrics for requirements (testability, traceability), design (ADR completeness, interface specificity), foundation (section plan verifiability), and Build-loop code (Result pattern, immutable state, FluentValidation, API docs)
 
+### ado-enterprise
+microsoft-enterprise's stack, hosted on Azure DevOps:
+- **Stack:** C#/.NET 8, Angular 17, SQL Server, Azure (identical to microsoft-enterprise)
+- **Repos & CI/CD:** Azure Repos + Azure Pipelines (`.azuredevops/pipelines/`, branch policies via `az repos policy`)
+- **Quality / Compliance / Conventions:** same as microsoft-enterprise (80% coverage, TDD, SOC 2 gates)
+
 ### starter
 Minimal profile for quick start:
 - **Stack:** Configurable (defaults to TypeScript/Node)

SKILL.md

@@ -64,6 +64,7 @@ For long-running phases (especially the Build loop), session continuity is maint
 
 Profiles configure the plugin for your company/team:
 - `microsoft-enterprise` — C#/.NET 8 + Angular 17 + Azure + SOC 2 compliance
+- `ado-enterprise` — microsoft-enterprise's stack on Azure Repos + Azure Pipelines
 - `starter` — Minimal profile, no compliance, quick start
 
 Profiles define: technology stack, quality thresholds (coverage, file size limits), compliance frameworks, coding conventions (commit format, naming, immutability).

commands/sdlc-doctor.md

@@ -12,25 +12,25 @@ Run it after `/sdlc-setup`, when onboarding a second developer, and any time a g
    ```bash
    uv run --project ${CLAUDE_PLUGIN_ROOT}/scripts ${CLAUDE_PLUGIN_ROOT}/scripts/doctor.py
    ```
-   Add `--offline` to skip the checks that need `gh` (repo secrets and branch protection). Add `--repo <path>` to check a repo other than the current directory.
+   Add `--offline` to skip the checks that need the platform CLI — `gh` on GitHub installs (repo secrets, branch protection), `az` on Azure DevOps installs (variable groups, branch policies). Add `--repo <path>` to check a repo other than the current directory.
 
 2. **Report the results verbatim.** Each line is already `PASS` / `FAIL` / `WARN` with the fix attached. Do not summarise away the fix lines — they are the actionable part.
 
 3. **Explain what each failure means, in plain terms**, before offering to act. What matters is the consequence, not the check name:
    - *missing `pwsh`* — the hooks are registered but can never run, so an agent can finish a turn on a red build and nothing objects
    - *script not executable* — the gate shells out and gets `Permission denied`; because the gates fail closed, this reads as a blocked merge with a confusing reason
-   - *missing secret* — the named workflows fail closed on every PR
-   - *no active ruleset* — the gates run and report, but a red PR can still merge
+   - *missing secret (GitHub) / missing variable group (ADO)* — the named workflows/pipelines fail closed on every PR
+   - *no active ruleset (GitHub) / no branch policies (ADO)* — the gates run and report, but a red PR can still merge
 
-4. **Offer to fix what is safely fixable.** `chmod +x` on the installed scripts is safe and mechanical — offer it. Setting a repository secret is not: it needs a real credential value from the human, so tell them the exact `gh secret set` command and let them run it. Never invent a secret value.
+4. **Offer to fix what is safely fixable.** `chmod +x` on the installed scripts is safe and mechanical — offer it. Providing a credential is not: it needs a real value from the human, so give them the platform-appropriate fix and let them run it — on GitHub the exact `gh secret set` command; on Azure DevOps the variable group to create and link (Key-Vault-backed, via `az pipelines variable-group`). Never invent a secret value.
 
-5. **Treat `WARN` as information, not a problem.** A warning marks something that could not be determined (Windows cannot see POSIX permission bits; `gh` may not be authenticated) or setup a later phase is meant to finish (an unfilled `<<TOKEN>>` carries the phase that fills it). Do not push the user to "clear" warnings.
+5. **Treat `WARN` as information, not a problem.** A warning marks something that could not be determined (Windows cannot see POSIX permission bits; `gh`/`az` may not be authenticated) or setup a later phase is meant to finish (an unfilled `<<TOKEN>>` carries the phase that fills it). Do not push the user to "clear" warnings.
 
 6. **If the harness is not installed at all**, stop and point at `/sdlc-setup`. The rest of the report is meaningless without it.
 
 ## Arguments
 
-- `--offline` — skip the checks that need `gh` (secrets, branch protection)
+- `--offline` — skip the checks that need `gh`/`az` (secrets / variable groups, branch protection / branch policies)
 - `--repo <path>` — check a different repo (default: current directory)
 
 ## Exit codes
@@ -39,6 +39,8 @@ Run it after `/sdlc-setup`, when onboarding a second developer, and any time a g
 
 ## Notes
 
-Required secrets are read from **this repo's installed workflows**, not from a fixed list. A repo that has adapted `ANTHROPIC_API_KEY` to `CLAUDE_CODE_OAUTH_TOKEN`, or deleted the eval workflows, is checked against what it actually runs — the doctor must never tell someone to "fix" a working setup.
+The doctor is **pack-aware**: it reads the installed CI/CD pack from `.claude/harness-manifest.json` and the platform-facing checks follow it — an Azure DevOps install is checked with `az` (variable groups, branch policies) and is never told to install `gh` for a platform it does not use.
+
+Required secrets (GitHub) / variable-group references (ADO) are read from **this repo's installed workflows/pipelines**, not from a fixed list. A repo that has adapted `ANTHROPIC_API_KEY` to `CLAUDE_CODE_OAUTH_TOKEN`, or deleted the eval workflows, is checked against what it actually runs — the doctor must never tell someone to "fix" a working setup.
 
 See `ONBOARDING.md` in the repo root for the day-1 checklist this command automates.

commands/sdlc-harness.md

@@ -18,15 +18,23 @@ uv run --project ${CLAUDE_PLUGIN_ROOT}/scripts ${CLAUDE_PLUGIN_ROOT}/scripts/ins
 
 ### Step 2: Report
 Summarize what was written vs skipped, then remind the user:
-- Fill any remaining `{{PLACEHOLDER}}` tokens in `CLAUDE.md` and the workflows.
-- **Prove the rails** before trusting them — the shakedown drills in `.github/RAILS.md`.
+- Fill any remaining `{{PLACEHOLDER}}` tokens in `CLAUDE.md` and the workflows/pipelines.
+- **Prove the rails** before trusting them — the shakedown drills in `.github/RAILS.md`
+  (the same path holds the ADO guide on azure-devops installs — the pack deliberately overlays it).
 - Apply branch protection if on GitHub: `bash scripts/rails/apply-branch-protection.sh`.
+  On Azure DevOps, configure branch policies instead — needs `az` + the `azure-devops` extension:
+  `bash scripts/rails/configure-branch-policies.sh --dry-run` to preview, then re-run without the
+  flag to apply.
 
 ## What it installs
 `CLAUDE.md` (governance), `specs/spec-template.md`, `.claude/{settings.json,hooks,agents,skills}`,
 `.github/workflows/` (ci, grader, correctness, security, deploy-dev, eval-regression, eval-suite)
 + `RAILS.md`, `.github/{profile/rubrics,rulesets,CODEOWNERS,eval-bypasses.md}`, `scripts/rails/`,
-`eval-datasets/`, `prompts/`, and `infra/`. See `.claude/agents/README.md` for the agent/skill
+`eval-datasets/`, `prompts/`, and `infra/`. On `platform: azure-devops` profiles the platform
+surface is realized as `.azuredevops/pipelines/` (the same rails as Azure Pipelines) and
+`.azuredevops/rails/` (rubrics + `branch-policies.json` — build-validation and required-reviewer
+policies standing in for rulesets and CODEOWNERS); `.github/RAILS.md` still carries the operator
+guide. See `.claude/agents/README.md` for the agent/skill
 catalog and the on-demand menu.
 
 ## Error Handling

commands/sdlc-setup.md

@@ -15,6 +15,7 @@ List available profiles from the plugin's `profiles/` directory (exclude `_schem
 
 Present every profile found there to the user. The current built-ins:
 - **microsoft-enterprise** — C#/.NET 8 + Angular 17 + Azure, SOC 2 compliance, 80% coverage minimum, TDD required
+- **ado-enterprise** — microsoft-enterprise's stack on Azure Repos + Azure Pipelines (`platform: azure-devops`); same SOC 2 gates, coverage, and TDD bar
 - **starter** — Minimal profile, no compliance gates, quick start for any stack
 - **creative-tooling** — Python/uv-scripts + pytest for creative pipelines (ComfyUI registry/inventory tooling); 80% coverage, TDD + code/security review required, schema- and cross-reference-integrity evaluation criteria, no compliance frameworks
 
@@ -52,7 +53,10 @@ Install the standard-aligned harness (the kit) from the plugin's bundled `harnes
 the repo. This lays down the governance `CLAUDE.md`, `.claude/{settings,hooks,agents,skills}`, the
 CI workflows in `.github/workflows/` (7 files: 5 rail gates — ci, grader, correctness, security,
 deploy-dev — plus 2 eval workflows), the `profile/` rubrics + branch-protection ruleset, and the
-`infra/` starters. Idempotent — existing files are left in place and reported as SKIPPED (pass
+`infra/` starters. On `platform: azure-devops` profiles the platform surface lands as Azure
+Pipelines under `.azuredevops/pipelines/` with branch policies as code
+(`.azuredevops/rails/branch-policies.json`) instead of `.github/workflows/` + the ruleset — same
+rails, different realization. Idempotent — existing files are left in place and reported as SKIPPED (pass
 `--force` only when you intend to overwrite). One exception: the JSON merge targets (`.mcp.json`
 and `.claude/settings.json`) are re-merged on every run by design — the installer deep-merges the
 payload's entries into them rather than skipping, so pack additions always land. The install
@@ -68,7 +72,8 @@ pipeline workflows, which overlay the core placeholders). A profile may also lis
 small static surface and the installer PRINTS their manual setup steps (self-installing tools are never
 run by the installer). The install also writes `.mcp.json` at the repo root — the team's shared MCP
 servers (core: context7, sequential-thinking, playwright; the dotnet pack adds microsoft-learn; the
-azure-devops pack adds the Azure DevOps server with an `<<ADO_ORGANIZATION>>` token to fill). Each
+azure-devops pack adds the Azure DevOps server with an `ADO_ORGANIZATION_NOT_SET` sentinel to fill
+— a plain sentinel, not a `<<TOKEN>>`, because the value lands in an argv). Each
 developer approves the set once when they first open the repo; auth-requiring servers authenticate
 per developer (e.g. `az login`) — no credentials ever go in the file. If the profile declares a
 frontend (`stack.frontend`), the frontend axis also composes: the generic `ux-reviewer` agent, plus
@@ -111,15 +116,22 @@ prove the system can be operated and handed over. Quality thresholds and convent
 `.sdlc/profile.yaml`.
 ```
 
-### Step 7: Apply branch protection (optional — needs GitHub + `gh`)
-The harness ships a branch-protection ruleset (`.github/rulesets/branch-protection.json`) and an
-applier. If the repo is on GitHub and `gh` is authenticated, offer to apply it:
+### Step 7: Apply branch protection / branch policies (optional — needs the platform CLI)
+On GitHub, the harness ships a branch-protection ruleset (`.github/rulesets/branch-protection.json`)
+and an applier. If the repo is on GitHub and `gh` is authenticated, offer to apply it:
 ```bash
 bash scripts/rails/apply-branch-protection.sh
 ```
-This makes the five blocking checks (build-and-test, spec-gate, grader, correctness-review, security-review)
+On Azure DevOps, the analogue is branch policies as code (`.azuredevops/rails/branch-policies.json`)
+and its applier — needs `az` with the `azure-devops` extension, logged in (`az login`). Offer the
+dry run first, then apply:
+```bash
+bash scripts/rails/configure-branch-policies.sh --dry-run   # show the plan, no writes
+bash scripts/rails/configure-branch-policies.sh
+```
+Either way, this makes the five blocking checks (build-and-test, spec-gate, grader, correctness-review, security-review)
 + a non-author approval mandatory at merge; deploy-dev runs post-merge and is not a merge check.
-Skip if the repo isn't on GitHub yet; the ruleset stays in the repo to apply later.
+Skip if the repo isn't on its platform yet; the ruleset / policy file stays in the repo to apply later.
 
 ### Step 8: Confirmation
 Display:
@@ -132,13 +144,18 @@ Harness: CLAUDE.md, .claude/, .github/workflows (7 workflows: 5 rails + 2 eval),
 
 Next steps:
 1. Fill the {{PLACEHOLDER}} tokens in CLAUDE.md (stack, glossary, gated paths);
-   on Azure DevOps, also replace <<ADO_ORGANIZATION>> in .mcp.json
+   on Azure DevOps, also replace ADO_ORGANIZATION_NOT_SET in .mcp.json
    (docs/harness.md explains every installed piece — point the team there)
 2. PROVE THE RAILS before trusting them — run the shakedown drills in .github/RAILS.md
 3. Run /sdlc to start the Phase 0 discovery interview
 4. Run /sdlc-gate when ready to check exit criteria; /sdlc-next to advance
 ```
 
+On `platform: azure-devops` profiles, render the `Harness:` line with the ADO layout instead:
+`.azuredevops/pipelines/` (Azure Pipelines rails + eval pipelines) + branch policies in
+`.azuredevops/rails/`. Leave the `.github/RAILS.md` drills path as-is — it is correct on both
+platforms (the azure-devops pack deliberately overlays that same path with the ADO guide).
+
 ### Step 9: Validate
 Run the profile validator to confirm the setup is healthy:
 ```bash

commands/sdlc-upgrade.md

@@ -57,6 +57,31 @@ version; never replace the whole file.
 - Stage the upgraded files + `.claude/harness-manifest.json` and commit, e.g.
   `chore: upgrade delivery harness to <new plugin version>`.
 
+## Switching CI platform
+
+Moving a repo between CI platforms (e.g. GitHub Actions → Azure DevOps) is just an upgrade with
+a changed profile — the classification table above already describes everything that happens.
+The runbook:
+
+1. Edit `stack.ci_cd.platform` in the frozen `.sdlc/profile.yaml` (`github-actions` ↔
+   `azure-devops`). This is the one deliberate use of the Step 1 warning: here the old pack
+   classifying as RETIRED is the point, not a misreport.
+2. Dry-run the upgrade (Step 1) with that profile. Expect the old platform's pack files to
+   classify `RETIRED` and the new pack's files as `NEW` — that is the swap report, not an error.
+   The core payload has been platform-aware since Fold A, so on an ADO target the retired GitHub
+   files no longer churn as `UPDATE`/`CONFLICT` noise.
+3. Apply (Step 3). The new pack lands; retired files stay on disk with their manifest entries
+   dropped.
+4. Delete the retired files yourself — upgrade never deletes (see the `RETIRED` row). On a
+   GitHub → ADO switch that means the `.github/workflows/` rail YAMLs,
+   `rulesets/branch-protection.json` + `scripts/rails/apply-branch-protection.sh`, and
+   `CODEOWNERS`; their ADO analogues arrive as `NEW` (`.azuredevops/pipelines/`, branch policies
+   via `scripts/rails/configure-branch-policies.sh`, a required-reviewer policy in place of
+   CODEOWNERS).
+5. Re-run `/sdlc-doctor` — it follows the installed pack (`az` checks on ADO, `gh` on GitHub) —
+   and re-prove the rails with the shakedown drills in `.github/RAILS.md` (the rails guide keeps
+   that path on both platforms; the ADO pack deliberately overlays it).
+
 ## Error Handling
 - If uv is not installed: `pip install uv` or `brew install uv`.
 - Exit 2 with `ERROR:` means a bad payload/profile or corrupt manifest — fix and re-run; nothing