Demo 2 — hve-squad

What you are proving

That a single autopilot line can take a high-level business goal and autonomously produce a complete, council-reviewed migration package — and, just as importantly, that the built-in review gate catches quality problems and stops rather than shipping them. Unlike the Azure Squad walkthrough, there are no separate beats here: it was driven as one request, and the squad derived the whole Research → Plan → Council → Implement → Review pipeline itself.

Capability	Squad member (role)	Notes
Feasibility research	Alpha (researcher)	Service mapping (ACI + PostgreSQL), 117-customer migration context.
Migration plan	Beta (lead)	6-phase plan — 28-week ramp-up + 3-year migration — with gate criteria.
Council (ADRs, HLD/LLD)	Kappa, Epsilon (architect, Azure architect)	4 ADRs, Mermaid HLD, Azure-icon LLD; hub-spoke, Azure CAF landing zone.
Cost + security pass	Lambda, Mu (cost, security)	~$2.4M 3-year forecast; CMK encryption, managed identity, RBAC, audit logging.
IaC + automation	Zeta, Eta, Gamma, Iota (IaC, deployer, developer, monitoring)	Bicep (15 modules), CI/CD workflows, integration tests, monitoring.
Quality review + gate	Delta (tester)	The star of this demo — Gate 1 validation that paused the pipeline.

Before you start

This demo runs against a prepared repository, hve-squad-demo2, that already holds the Contoso source/process definitions and a private knowledge-docs/ folder. The whole run produces planning and scaffold artifacts only — nothing is deployed to Azure, so it is safe to run live.

Prerequisite	Why	Check
hve-squad installed (with the `azure` profile)	The migration cast — researcher, lead, architects, IaC, cost, security, tester — is seeded by the `azure` profile.	`apm install "Peter-N91/hve-squad"`
VS Code + Copilot (agent mode)	The coordinator dispatches the cast as subagents.	—
The `hve-squad-demo2` repo	Holds the Contoso process definitions and the gitignored `knowledge-docs/` context.	Open it as the workspace.
uv (or Python) + Graphviz (optional)	Only for the Azure-icon LLD via the `python-diagrams` skill; falls back to Mermaid without them.	`dot -V`

Private context stays private. The squad reads ./knowledge-docs (meeting notes, reference architecture) for context only. The request's guardrail keeps its contents out of every committed file and generated artifact — the folder is gitignored by design, and the run honors that. Never paste its contents into the deck or any pushed output.

The one request

The entire demo is this single autopilot line. It names the outcome and the guardrails, not the steps — the squad sequences the pipeline itself:

/squad profile=azure mode=autopilot request="Plan and prepare a migration of this project from on-premise Contoso Inc. to Azure.

Where to look:
- ./knowledge-docs — the private reference material (architecture, meeting notes). Read it for context only.
- the existing Contoso Inc. source/process definitions in this repo.

What I need:
- A recommended target Azure architecture and a concrete migration plan (Contoso Inc. BPMN/workflows mapped to the appropriate Azure services).
- IaC authored under infra/.
- A cost view and a security pass on the proposed design.
- A HLD diagram with mermaid and LLD diagram containing Azure icons.

Guardrails:
- Treat ./knowledge-docs as private: never copy its contents into committed files, generated artifacts, or any output that would be pushed. It is gitignored."

Narrate: "One line, no babysitting. Autopilot runs Research → Plan → Council → Implement → Review, stops only where it must, and treats the private folder as read-only context it will never leak."

What autopilot produced (Stages 1–4)

Stages 1 through 4 completed cleanly — research, plan, council decisions, and an implementation scaffold — each owned by a named member and persisted as decisions and history under .copilot-tracking/squad/:

Stage	Owner(s)	Output	Status
1 · Research	Alpha	Feasibility analysis, service mapping (ACI + PostgreSQL), 117-customer migration context.	✅ Complete
2 · Plan	Beta	6-phase plan (28-week ramp-up + 3-year migration) with gate criteria.	✅ Complete
3 · Council	Kappa, Epsilon, Lambda, Mu	4 ADRs, HLD/LLD diagrams, ~$2.4M 3-year cost forecast, security & compliance posture.	✅ Conditional GO
4 · Implement	Zeta, Eta, Gamma, Iota	Bicep IaC (15 modules), CI/CD workflows, integration tests, monitoring.	✅ Structure complete
5 · Review	Delta	Quality assessment + Gate 1 validation.	🔴 Blockers found — escalated
6 · Validate	—	Final-outcome validation.	⛔ Not reached

The proposed target: Azure Container Instances + Managed PostgreSQL on a hub-spoke tenancy with per-customer resource groups on an Azure CAF landing zone — the HLD as Mermaid, the LLD rendered with real Azure icons. The cost view forecast roughly $598K–$648K in Year 1 and ~$2.4M over three years.

Where it stopped — the review gate

At Stage 5 the reviewer (Delta) ran the Gate 1 quality assessment and found five critical production blockers. It did not silently fix them, and it did not wave the work through. It paused at the risk gate and handed the decision back to the human:

#	Blocker	Why it blocks production
1	Bicep compilation errors	Scope/function misuse and schema mismatches — the IaC will not compile, so deployment cannot proceed.
2	CI/CD path drift	Workflows reference template paths that don't exist; validation and what-if can't run.
3	Approval-gate bypass	The two-person deploy gate is documented but hard-coded to auto-approve — no real enforcement.
4	Integration tests blocked	All 5 scenarios are unmeasurable without a live deployment; Gate 1 cannot be validated.
5	Monitoring IaC incomplete	14 alerts documented, only 5 implemented — observability coverage doesn't match the claim.

This is the whole point of the demo. The architecture and planning were sound, but the scaffold was not production-ready — and the gate caught it. A model that just generated code would have handed over broken IaC with a confident summary. The squad stopped, named every blocker with file and line, and refused to claim success.

The decision point

Facing the blockers, the squad offered two paths and let the human choose — it never picks for you at a risk gate:

Remediate now — hand each blocker to the member who owns it, with a per-step effort estimate, fix, then re-review.
Escalate and stop — capture the findings, impact, and proposed remediation as one stakeholder document, and halt.

In the run, the user chose to escalate, so no fixes were applied and the pipeline halted at Stage 5. The escalation summary still records the would-be hand-off, so the work can resume later if approved:

Remediation step	Owner	Effort
Fix Bicep errors	Zeta (IaC Author)	1–2 h
Correct CI/CD paths	Eta (Deployer)	1–2 h
Wire integration tests	Gamma (Developer)	2–3 h
Complete monitoring IaC	Iota (Azure Diagnose)	1–2 h
Revalidate end-to-end	Delta (Tester)	2–3 h
Total	All roles	6–12 h

Failure-safe fallbacks

If…	Then…
The IaC will not compile	That is the demo's payoff — the review gate caught it. Show the escalation summary rather than trying to deploy.
`@azure/mcp` is not wired	The squad falls back to the `az` CLI / Resource Graph REST; research, planning, and council are unaffected.
Graphviz is not installed	The Azure-icon LLD falls back to Mermaid via `python-diagrams`; nothing blocks.
Someone asks "just fix it and ship"	The squad offers the remediation hand-off (owner + effort per blocker) — it never silently fixes and ships past a risk gate.

Closing talking points

One request, full pipeline. A single autopilot line drove Research → Plan → Council → Implement → Review with no per-step prompting.
The gate is the product. Review found five production blockers and stopped — it escalated instead of shipping broken IaC with a confident summary.
You stay in control. At the risk gate the squad offered remediate-now vs escalation summary; the human chose. No auto-fix, no silent deploy.
Private stays private. ./knowledge-docs was read for context only and never copied into committed output — gitignored by design.