jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/devops-rollout-plan/SKILL.md

@@ -0,0 +1,206 @@
+---
+name: devops-rollout-plan
+description: 'Generate comprehensive rollout plans with preflight checks, step-by-step deployment, verification signals, rollback procedures, and communication plans for infrastructure and application changes. Use this skill whenever someone needs a deployment plan, release checklist, go-live runbook, cutover plan, production rollout, AI agent deployment plan, GenAI release strategy, or asks how to safely ship a change to production. Also use when the context involves Pod delivery handoffs, prototype-to-production transitions, Jump Start follow-on deployments, or any AI Innovation Pod work that needs operational release controls. Trigger even when phrased as "how do we go live", "what does the release look like", "write a deployment runbook", or "we need a cutover plan for Friday".'
+---
+
+# DevOps Rollout Plan Generator
+
+Generate production-ready rollout plans for infrastructure, application, and AI/GenAI system changes. Plans follow progressive exposure principles from the Azure Well-Architected Framework and include the operational controls (observability, evaluation gates, rollback) that AI Innovation Pod delivery teams need when transitioning prototypes to production.
+
+## How This Skill Fits Pod Delivery
+
+In the AI Innovation Pod model, the rollout plan is a critical handoff artifact. Whether the Pod is leading the deployment, co-delivering with CIS/Intelligent Operations, or handing off to the client's platform team, the plan must be explicit about:
+
+- **Who owns what** — Pod roles vs. client platform team vs. adjacent Sogeti teams (CIS, QET, DAE)
+- **Evaluation gates** — AI-specific quality checks (prompt regression, guardrail validation, cost thresholds) that must pass before traffic shifts
+- **GenAIOps integration** — How traces, evaluations, and prompt versions connect to the deployment pipeline
+- **Progressive exposure** — Ring-based or canary patterns that limit blast radius for non-deterministic AI systems
+
+When generating a plan, consider which Pod delivery pattern applies:
+1. **Pod-Led Innovation Sprint** — Pod owns the full deployment; plan is comprehensive
+2. **Embedded Co-Delivery** — Pod deploys AI layer; adjacent teams handle surrounding infrastructure
+3. **Accelerate and Handoff** — Plan IS the handoff artifact; must be self-contained enough for another team to execute
+
+## Input Requirements
+
+Gather these details before generating the plan. Ask the user directly for anything missing — do not invent details.
+
+### Change Description
+- What's changing (infrastructure, application, AI agent, prompt/model version, configuration)
+- Version or state transition (from/to)
+- Problem solved, feature added, or business outcome enabled
+- Whether this is a first production release or an update to an existing system
+
+### Environment Details
+- Target environment (dev, staging, production, all)
+- Infrastructure type (Azure AI Foundry, Kubernetes/AKS, App Service, Container Apps, Azure Functions, VMs, serverless)
+- Affected services and dependencies (LLM endpoints, vector stores, data pipelines, downstream APIs)
+- Current capacity, scale, and traffic patterns
+- Existing observability stack (Application Insights, custom tracing, GenAI-specific tooling)
+
+### AI/GenAI-Specific Details (when applicable)
+- Model provider and version (Azure OpenAI GPT-4o, Anthropic Claude, etc.)
+- Agent framework (Semantic Kernel, LangChain, PydanticAI, AutoGen, custom)
+- Prompt versioning approach (git-tracked, prompt management platform, inline)
+- Evaluation dataset and pass criteria (golden set, LLM-as-judge thresholds)
+- Guardrails and content safety configuration
+- Token budget / cost controls
+- RAG pipeline components (embeddings model, vector index, chunking strategy)
+
+### Constraints & Requirements
+- Acceptable downtime window (or zero-downtime requirement)
+- Change window restrictions (maintenance windows, business-critical periods)
+- Approval requirements (technical lead, security, compliance, business owner, client)
+- Regulatory or compliance considerations (GDPR, SOC 2, industry-specific)
+- Client responsibilities vs. Pod responsibilities
+
+### Risk Assessment
+- Blast radius of change (number of users, business processes affected)
+- Data migrations or schema changes
+- Rollback complexity (stateless vs. stateful, prompt version vs. infrastructure)
+- Known risks and mitigations
+- Non-determinism risk (AI outputs may vary between deployments even with same config)
+
+## Output Format
+
+Generate a structured rollout plan. For the full template structure, read `templates/standard-rollout-plan.md`. For AI/agent-specific deployments, also consult `templates/ai-agent-rollout-plan.md`. For lower-risk changes (dev/staging, config-only), use the lighter `templates/lightweight-rollout-plan.md`.
+
+The plan always includes these sections:
+
+### 1. Executive Summary
+- What, why, when, duration
+- Risk level (Low / Medium / High / Critical) and rollback time estimate
+- Affected systems and user impact
+- Expected downtime (or confirmation of zero-downtime approach)
+- Pod delivery pattern in use and ownership model
+
+### 2. Prerequisites & Approvals
+- Required approvals with named roles (Pod Architect, Client Platform Lead, Security, etc.)
+- Required resources (capacity, backups, monitoring, rollback automation)
+- Pre-deployment backups and state snapshots
+- Dependency readiness confirmation (third-party APIs, LLM endpoint quotas, vector index freshness)
+
+### 3. Preflight Checks
+- Infrastructure health validation (compute, networking, DNS, certificates)
+- Application/agent health baseline (current error rates, latency percentiles, token usage)
+- Dependency availability (LLM endpoints, search indexes, databases, external APIs)
+- Monitoring and alerting readiness
+- Evaluation gate results (for AI: prompt regression suite, guardrail validation, cost projections)
+- Go/no-go decision checklist with named decision-maker
+
+### 4. Step-by-Step Rollout Procedure
+
+**Progressive exposure pattern** — choose based on risk and infrastructure:
+- **Ring-based** (Ring 0: internal team → Ring 1: 5% canary → Ring 2: 25% → Ring 3: 100%)
+- **Blue-Green** (deploy to inactive pool, validate, swap traffic)
+- **Canary** (route percentage of traffic to new version, observe, expand)
+- **Feature Flag** (deploy dark, enable for target audience progressively)
+
+For each phase:
+- Specific commands or automation steps
+- Validation criteria that must pass before proceeding
+- Bake time between phases (hours/days, not minutes — allow full usage cycles)
+- Duration estimates
+- Who executes vs. who approves progression
+
+### 5. Verification Signals
+
+**Immediate** (0-5 min): Deployment success, containers healthy, endpoints responding, no crash loops
+**Short-term** (5-30 min): Error rates within baseline ±threshold, latency acceptable, LLM responses coherent
+**Medium-term** (30 min - 2h): Sustained metrics stability, integrations working, evaluation scores holding, cost within budget
+**Long-term** (2h - 24h): No degradation over time, business metrics normal, no drift in AI behavior, user feedback neutral/positive
+
+For AI systems, also verify:
+- Guardrail trigger rates within expected range
+- Token consumption within budget projections
+- No prompt injection bypass detected in logs
+- Evaluation scores on golden dataset meet threshold
+- Trace quality — complete request traces flowing to observability
+
+### 6. Rollback Procedure
+
+**Decision Criteria**: Specific, measurable triggers that initiate rollback (not "when things look bad"):
+- Error rate exceeds X% for Y minutes
+- P95 latency exceeds Xms
+- Evaluation score drops below threshold
+- Cost burn rate exceeds X% of budget
+- Guardrail bypass detected
+- Client reports critical issue
+
+**Rollback Steps**: Infrastructure revert, traffic shift, feature flag disable, model version pin, or prompt version revert
+**Data Considerations**: How to handle any state changes made during the failed deployment window
+**Post-Rollback Verification**: Confirm system health restored to pre-deployment baseline
+**Communication**: Immediate stakeholder notification with ETA for investigation and next attempt
+
+### 7. Communication Plan
+
+| Timing | Action | Audience | Channel | Owner |
+|--------|--------|----------|---------|-------|
+| T-24h | Schedule & impact notice | All stakeholders | Email/Teams | Engagement Lead |
+| T-1h | Final go/no-go confirmation | Deployment team | Teams call | Pod Architect |
+| T-0 | Deployment started | Stakeholders | Teams channel | Deployment lead |
+| T+intervals | Progress updates | Technical team | Teams channel | Deployment lead |
+| Complete | Success confirmation | All stakeholders | Email/Teams | Engagement Lead |
+| Rollback | Issue notification + ETA | All stakeholders | Email/Teams + call | Engagement Lead |
+
+Adapt the stakeholder matrix to the delivery pattern — Pod-led plans notify differently than handoff plans.
+
+### 8. Post-Deployment Tasks
+- **Immediate** (1h): Confirm all verification signals green, review initial traces/logs, close change ticket
+- **Short-term** (24h): Review error patterns, validate cost actuals vs. projections, check AI evaluation drift
+- **Medium-term** (1 week): Post-deployment review / retrospective, update runbooks, feed lessons into Pod retrospective library
+- **Handoff** (if applicable): Transfer operational ownership with documentation, runbooks, dashboards, and escalation paths
+
+### 9. Contingency Plans
+
+For each scenario, define symptoms → response → timeline → escalation:
+- Partial deployment failure (some instances updated, some not)
+- Performance degradation (latency increase without errors)
+- AI behavior regression (evaluation scores drop but system stays up)
+- Cost spike (token usage exceeds projections)
+- Dependency failure during deployment (LLM endpoint throttling, database connection loss)
+- Data inconsistency (cache staleness, vector index version mismatch)
+
+### 10. Ownership & Contacts
+
+| Role | Name | Contact | Escalation |
+|------|------|---------|------------|
+| Deployment Lead (Pod) | | | |
+| Pod Architect | | | |
+| Client Platform Lead | | | |
+| On-call Secondary | | | |
+| Security Escalation | | | |
+| Vendor Support (if applicable) | | | |
+
+## Plan Customization
+
+Select the appropriate template and depth:
+
+| Factor | Guidance |
+|--------|----------|
+| **Risk Level** | Low → `templates/lightweight-rollout-plan.md`; Medium → standard; High/Critical → standard + additional gates |
+| **Change Type** | Infrastructure, application code, AI model/prompt, configuration, data migration |
+| **Environment** | Production (full plan), staging (simplified), development (minimal checklist) |
+| **AI vs. Traditional** | AI deployments → include evaluation gates, cost controls, non-determinism handling |
+| **Delivery Pattern** | Pod-led (full), Embedded (AI layer only), Handoff (self-contained artifact) |
+| **Client Maturity** | Mature DevOps → assume CI/CD exists; Greenfield → include pipeline setup |
+
+## References
+
+Read these for deeper guidance on specific scenarios:
+- `references/azure-safe-deployment.md` — Azure-specific progressive exposure patterns, service-level deployment guidance, and Azure DevOps/GitHub Actions integration
+- `references/ai-agent-deployment.md` — GenAI and agent-specific deployment considerations including evaluation-gated CI/CD, prompt versioning, guardrail validation, and cost controls
+- `references/pod-delivery-context.md` — How rollout plans fit within Pod delivery patterns, handoff conventions, and the relationship between deployment and GenAIOps
+
+## Key Principles
+
+- Every deployment is a risk event — treat it as such regardless of perceived simplicity
+- Progressive exposure protects users — canary/ring patterns limit blast radius
+- AI systems need evaluation gates, not just health checks — passing health checks doesn't mean the agent is behaving correctly
+- Bake times should be hours and days, not minutes — allow full usage cycles before expanding
+- Rollback criteria must be specific and measurable — "looks bad" is not a trigger
+- Plans are handoff artifacts — someone who wasn't in the room should be able to execute the plan
+- Communicate early and often — silence during deployment breeds anxiety
+- Learn from every deployment — feed observations into retrospective library
+- Never deploy on Friday afternoon (unless critical and rollback is tested)
+- Never skip verification steps — they exist because something failed before

package/.github/skills/devops-rollout-plan/evals/evals.json

@@ -0,0 +1,119 @@
+{
+  "skill_name": "devops-rollout-plan",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We just finished building a RAG-based internal knowledge assistant using Azure OpenAI GPT-4o and Azure AI Search during our Pod's Turbo phase. The client (a mid-size insurance company) wants us to deploy it to their 200 claims adjusters next week. They're on Azure Container Apps and have basic Application Insights set up. This is the first production AI deployment for this client — they've never had anything LLM-based in prod before. Can you write us a rollout plan?",
+      "expected_output": "A comprehensive AI agent rollout plan that includes: evaluation gates with specific thresholds, progressive exposure pattern (not big-bang), Azure-specific deployment mechanics (Container Apps revisions or feature flags), cost controls for token usage, guardrail validation section, clear ownership split between Pod and client platform team, RAG-specific verification (retrieval quality), and communication plan appropriate for a first-time AI deployment at a traditional enterprise.",
+      "assertions": [
+        {
+          "name": "includes_evaluation_gate",
+          "type": "contains_concept",
+          "description": "Plan includes a pre-deployment evaluation gate with specific pass/fail thresholds for AI quality metrics"
+        },
+        {
+          "name": "progressive_exposure",
+          "type": "contains_concept",
+          "description": "Plan uses progressive exposure (canary, rings, or feature flags) rather than deploying to all 200 users at once"
+        },
+        {
+          "name": "cost_controls",
+          "type": "contains_concept",
+          "description": "Plan includes token budget projections, cost alerts, and a cost-based rollback trigger"
+        },
+        {
+          "name": "rollback_procedure",
+          "type": "contains_concept",
+          "description": "Plan has a specific rollback procedure with measurable decision criteria (not just 'if things look bad')"
+        },
+        {
+          "name": "pod_ownership_model",
+          "type": "contains_concept",
+          "description": "Plan identifies Pod roles vs. client responsibilities in the deployment process"
+        },
+        {
+          "name": "azure_specific",
+          "type": "contains_concept",
+          "description": "Plan references Azure-specific services/patterns (Container Apps, App Insights, Azure OpenAI deployment config)"
+        },
+        {
+          "name": "communication_plan",
+          "type": "contains_concept",
+          "description": "Plan includes a stakeholder communication timeline"
+        }
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Hey, we need a quick rollout plan. We're updating the system prompt on our production customer service agent — it's a minor tweak to improve how it handles refund requests. The agent has been in prod for 3 months on AKS, using Semantic Kernel + GPT-4o. We have eval suites and Langfuse tracing already set up. No infra changes, just the prompt text changing. Client's DevOps team handles the actual kubectl stuff, we just need to tell them what to do and how to verify.",
+      "expected_output": "A lightweight rollout plan appropriate for a low-risk prompt-only change. Should NOT be a full heavyweight plan — recognize that this is a minor change with instant rollback (prompt revert). Should include: run eval suite against new prompt version, have client DevOps team deploy, verify via existing Langfuse traces that responses are appropriate, simple rollback (revert prompt version). Should be proportionate to the risk level. Should respect that the client's DevOps team executes while the Pod provides the plan and verification criteria.",
+      "assertions": [
+        {
+          "name": "proportionate_to_risk",
+          "type": "contains_concept",
+          "description": "Plan is concise and lightweight, not a full 10-section heavyweight plan for a prompt text change"
+        },
+        {
+          "name": "eval_before_deploy",
+          "type": "contains_concept",
+          "description": "Plan requires running the evaluation suite against the new prompt version before deploying"
+        },
+        {
+          "name": "prompt_specific_rollback",
+          "type": "contains_concept",
+          "description": "Rollback is a simple prompt version revert, not a full infrastructure rollback"
+        },
+        {
+          "name": "handoff_to_client_devops",
+          "type": "contains_concept",
+          "description": "Plan acknowledges the client DevOps team executes deployment and provides clear instructions for them"
+        },
+        {
+          "name": "verification_via_existing_tools",
+          "type": "contains_concept",
+          "description": "Verification uses existing Langfuse tracing and eval suite rather than requiring new tooling"
+        }
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "Our Pod just finished an Overdrive engagement where we built a multi-agent orchestration system (3 agents: intake classifier, document processor, and approval workflow agent) on Azure. The client's CIS/Intelligent Operations team is taking over day-to-day operations next month. I need a rollout plan that doubles as a handoff artifact — something their ops team can use for future deployments without calling us back. They use Azure DevOps for CI/CD, have a standard change management process (ServiceNow), and their monitoring is all in Datadog (not native Azure). Help me create this.",
+      "expected_output": "A self-contained rollout plan designed as a handoff artifact for a multi-agent system. Should include: deployment sequencing for the 3 interdependent agents, integration with client's Azure DevOps CI/CD and ServiceNow change management, observability tied to Datadog (not forcing Azure Monitor), reusable template sections the ops team can adapt for future releases, evaluation instructions they can follow independently, multi-agent rollback considerations (can't roll back one without considering others), and explicit handoff quality criteria.",
+      "assertions": [
+        {
+          "name": "multi_agent_sequencing",
+          "type": "contains_concept",
+          "description": "Plan addresses deployment order/dependencies between the 3 agents"
+        },
+        {
+          "name": "handoff_self_contained",
+          "type": "contains_concept",
+          "description": "Plan is designed to be executable by the CIS team without Pod involvement, with clear instructions"
+        },
+        {
+          "name": "client_tooling_integration",
+          "type": "contains_concept",
+          "description": "Plan integrates with client's existing tools (Azure DevOps, ServiceNow, Datadog) rather than prescribing new ones"
+        },
+        {
+          "name": "multi_agent_rollback",
+          "type": "contains_concept",
+          "description": "Rollback procedure addresses the complexity of rolling back interdependent agents"
+        },
+        {
+          "name": "reusable_template",
+          "type": "contains_concept",
+          "description": "Plan is structured as a reusable template the ops team can adapt, not a one-time document"
+        },
+        {
+          "name": "knowledge_transfer",
+          "type": "contains_concept",
+          "description": "Plan includes operational knowledge transfer elements (runbooks, escalation paths, evaluation instructions)"
+        }
+      ],
+      "files": []
+    }
+  ]
+}

package/.github/skills/devops-rollout-plan/examples/azure-openai-agent-rollout.md

@@ -0,0 +1,237 @@
+# Example: Azure OpenAI Customer Service Agent — Production Rollout
+
+This example shows a completed rollout plan for a customer service AI agent being deployed to production for the first time as part of an AI Innovation Pod engagement. The Pod has completed the Turbo phase (MVP development) and is releasing v1.0 to a subset of real customer traffic.
+
+---
+
+# Rollout Plan: Customer Service Agent v1.0 — Production Release
+
+**Version**: 1.2  
+**Author**: Sarah Chen, AI Solution Architect  
+**Last Updated**: 2026-04-25  
+**Status**: Approved
+
+---
+
+## 1. Executive Summary
+
+| Field | Value |
+|-------|-------|
+| **What** | Deploy customer service AI agent to production (first release) |
+| **Why** | Reduce Tier 1 support ticket volume by 30% through automated resolution of common queries |
+| **When** | Monday 2026-04-28, 06:00 UTC (before business hours) |
+| **Duration** | 4 hours deployment + 8 hours initial monitoring + 5-day progressive rollout |
+| **Risk Level** | High (first production release, customer-facing, handles PII) |
+| **Rollback Time** | < 2 minutes (feature flag disable) |
+| **Downtime** | None — progressive enablement via feature flag |
+| **Affected Users** | Customer support portal users (initially 5%, expanding to 100% over 5 days) |
+| **Delivery Pattern** | Pod-Led Innovation Sprint |
+| **AI Components** | Azure OpenAI GPT-4o, Azure AI Search (RAG), Semantic Kernel, Azure Container Apps |
+
+---
+
+## 2. AI System Configuration
+
+### Model Details
+
+| Parameter | Value |
+|-----------|-------|
+| Provider | Azure OpenAI |
+| Model | gpt-4o-2024-08-06 |
+| Deployment name | cs-agent-prod-v1 |
+| Region | East US 2 |
+| TPM limit | 80,000 |
+| RPM limit | 480 |
+| Temperature | 0.3 |
+| Max tokens | 2,048 |
+| Content filter | Medium (all categories) |
+
+### Agent Architecture
+
+| Component | Technology | Version |
+|-----------|-----------|---------|
+| Framework | Semantic Kernel (Python) | 1.15.0 |
+| Vector store | Azure AI Search | Standard S1 |
+| Embeddings | text-embedding-3-large | 3072 dimensions |
+| Compute | Azure Container Apps | 2 replicas min, 10 max |
+| State | Azure Cosmos DB (session store) | Serverless |
+| Tools | OrderLookup, RefundProcessor, ArticleSearch, EscalateToHuman | |
+
+### Prompt Versioning
+
+| Prompt | Version | Change Summary |
+|--------|---------|----------------|
+| System prompt | v1.0 (commit a3f7b2c) | Initial production version |
+| Tool calling prompt | v1.0 (commit a3f7b2c) | Initial production version |
+| RAG grounding prompt | v1.0 (commit a3f7b2c) | Initial production version |
+
+---
+
+## 3. Evaluation Gate
+
+### Pre-Deployment Evaluation Results
+
+**Evaluation suite**: `/tests/evaluation/golden_dataset.json`  
+**Run date**: 2026-04-24  
+**Golden dataset size**: 87 test cases
+
+| Metric | Threshold | Score | Pass? |
+|--------|-----------|-------|-------|
+| Task completion accuracy | ≥ 0.85 | 0.91 | ✓ |
+| Guardrail compliance | ≥ 0.99 | 1.00 | ✓ |
+| Tool call correctness | ≥ 0.90 | 0.94 | ✓ |
+| Response relevance | ≥ 0.85 | 0.88 | ✓ |
+| Harmful content rate | = 0 | 0 | ✓ |
+| Prompt injection resistance | ≥ 0.95 | 0.98 | ✓ |
+| Response latency (P95) | ≤ 4000ms | 2,847ms | ✓ |
+| Token cost per request (avg) | ≤ $0.04 | $0.028 | ✓ |
+
+**Approved for deployment**: Marcus Webb, Engagement Lead — 2026-04-25
+
+---
+
+## 4. Guardrail Validation
+
+| Test Category | Tests | Pass Rate | Pass? |
+|---------------|-------|-----------|-------|
+| Prompt injection attempts | 25 | 25/25 | ✓ |
+| Jailbreak attempts | 15 | 15/15 | ✓ |
+| PII handling | 20 | 20/20 | ✓ |
+| Off-topic refusal | 12 | 12/12 | ✓ |
+| Tool misuse prevention | 10 | 10/10 | ✓ |
+| Data exfiltration prevention | 8 | 8/8 | ✓ |
+
+---
+
+## 5. Cost Controls
+
+| Metric | Projection | Alert Threshold | Hard Limit |
+|--------|-----------|-----------------|-----------|
+| Daily token consumption | 2.4M tokens | > 4M tokens | 8M tokens |
+| Daily cost | $67 | > $120 | $250 |
+| Cost per request (avg) | $0.028 | > $0.06 | $0.15 |
+| Monthly budget | $2,000 | > $1,600 (80%) | $3,000 |
+
+---
+
+## 6. Rollout Procedure
+
+### Strategy: Feature Flag with Progressive Enablement
+
+Using Azure App Configuration feature flags to progressively enable the agent for increasing percentages of users.
+
+### Phase 0: Deploy Dark (Day 1 — Monday 06:00 UTC)
+
+| Step | Action | Validation | Owner |
+|------|--------|-----------|-------|
+| 0.1 | Deploy Container Apps revision (feature flag OFF) | Revision healthy, 0 traffic | Dev team |
+| 0.2 | Run full evaluation suite against prod instance | All 87 tests pass | Dev team |
+| 0.3 | Internal team conversation testing (30 min) | Natural responses, tools working | Full Pod |
+| 0.4 | Verify observability: traces in Langfuse, metrics in App Insights | Data flowing | Architect |
+
+**Bake time**: 2 hours internal testing  
+**Promotion criteria**: Evaluation passes, internal team satisfied, traces complete
+
+### Phase 1: 5% Canary (Day 1 — Monday 10:00 UTC)
+
+| Step | Action | Validation | Owner |
+|------|--------|-----------|-------|
+| 1.1 | Enable feature flag for 5% of users | App Config confirms 5% allocation | Architect |
+| 1.2 | Monitor error rate, latency, cost over 4 hours | Within thresholds | Dev team |
+| 1.3 | Review 20 random traces for response quality | Appropriate, helpful responses | BA + Architect |
+| 1.4 | Check guardrail trigger rates | 2-5% trigger rate (expected) | Architect |
+
+**Bake time**: 8 hours (covers afternoon peak)  
+**Promotion criteria**: All metrics green, no user complaints, cost tracking to projection  
+**Promotion approver**: Sarah Chen, Architect
+
+### Phase 2: 25% (Day 2 — Tuesday 06:00 UTC)
+
+| Step | Action | Validation | Owner |
+|------|--------|-----------|-------|
+| 2.1 | Increase feature flag to 25% | App Config confirms | Architect |
+| 2.2 | Monitor all metrics, compare to baseline | Scaled proportionally, no anomalies | Dev team |
+| 2.3 | Review escalation patterns | Escalation rate reasonable (< 20%) | BA |
+| 2.4 | Client spot-check 5 random conversations | Quality acceptable | Client PM |
+
+**Bake time**: 24 hours  
+**Promotion approver**: Marcus Webb, Engagement Lead + Client PM
+
+### Phase 3: 50% (Day 3 — Wednesday)
+
+[Same structure, 24h bake]
+
+### Phase 4: 100% (Day 5 — Friday 06:00 UTC)
+
+[Full production, 48h monitoring before declaring stable]
+
+---
+
+## 7. Rollback Procedure
+
+### Rollback Triggers
+
+| Trigger | Threshold | Action |
+|---------|-----------|--------|
+| Error rate | > 5% for 5 minutes | Disable feature flag |
+| Harmful content generated | Any instance | Immediate disable |
+| Cost burn rate | > 3x projection for 15 min | Disable feature flag |
+| P95 latency | > 6000ms for 10 min | Disable feature flag |
+| Guardrail bypass confirmed | Any instance | Immediate disable |
+| Client-reported P1 | Any confirmed | Disable feature flag |
+
+### Rollback Steps
+
+| Step | Action | Duration |
+|------|--------|----------|
+| R1 | Disable feature flag in Azure App Configuration | 30 seconds |
+| R2 | Verify flag disabled (no new conversations routed to agent) | 1 minute |
+| R3 | Confirm existing conversations completing or failing gracefully | 5 minutes |
+| R4 | Verify metrics returning to baseline | 10 minutes |
+| R5 | Notify stakeholders | 5 minutes |
+
+**Total rollback time**: < 2 minutes to stop new traffic; < 15 minutes to confirm stable
+
+---
+
+## 8. Communication Plan
+
+| Timing | Action | Audience | Channel |
+|--------|--------|----------|---------|
+| Apr 25 (T-3d) | Deployment plan shared | Client PM, Support Lead | Email |
+| Apr 28 06:00 | Deployment started | Pod team | Teams |
+| Apr 28 10:00 | Phase 1 live (5% canary) | Client PM | Teams |
+| Apr 28 18:00 | Phase 1 healthy, Phase 2 planned | All stakeholders | Email |
+| Apr 29 06:00 | Phase 2 live (25%) | Client PM | Teams |
+| Daily | Status update with metrics | All stakeholders | Email |
+| May 2 | Full production confirmed | All stakeholders + exec sponsor | Email |
+
+---
+
+## 9. Post-Deployment (Week 1)
+
+- [ ] Daily metrics review (Pod standup): cost, quality, escalation rate, user satisfaction
+- [ ] Day 3: First client satisfaction survey analysis
+- [ ] Day 5: Pod retrospective on deployment process
+- [ ] Day 7: Post-deployment review with client (metrics, lessons, next phase planning)
+- [ ] Week 1: Update operational runbook with real-world learnings
+- [ ] Week 1: Expand golden dataset with interesting real-world edge cases observed
+
+---
+
+## 10. Ownership
+
+| Role | Name | Contact |
+|------|------|---------|
+| Deployment Lead / Architect | Sarah Chen | sarah.chen@sogeti.com |
+| Engagement Lead | Marcus Webb | marcus.webb@sogeti.com |
+| AI Developer | James Park | james.park@sogeti.com |
+| Client Platform Lead | Rachel Torres | rtorres@client.com |
+| Client PM / Support Lead | David Kim | dkim@client.com |
+| Azure Support (escalation) | | Premier Support case: [ID] |
+
+---
+
+## Key Learnings (added post-deployment)
+
+_[To be filled after deployment completes]_