jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/devops-rollout-plan/references/ai-agent-deployment.md

@@ -0,0 +1,250 @@
+# AI Agent and GenAI Deployment Considerations
+
+Reference material for deploying AI agents, LLM-based applications, RAG pipelines, and GenAI features to production. These deployments have unique challenges beyond traditional software.
+
+## Table of Contents
+1. [Why AI Deployments Are Different](#why-ai-deployments-are-different)
+2. [Evaluation-Gated Deployment](#evaluation-gated-deployment)
+3. [Prompt and Model Versioning](#prompt-and-model-versioning)
+4. [Guardrail Validation](#guardrail-validation)
+5. [Cost and Token Controls](#cost-and-token-controls)
+6. [RAG Pipeline Deployment](#rag-pipeline-deployment)
+7. [Multi-Agent System Deployment](#multi-agent-system-deployment)
+8. [Observability for AI Systems](#observability-for-ai-systems)
+
+---
+
+## Why AI Deployments Are Different
+
+Traditional software is deterministic — same input, same output. AI systems introduce:
+
+| Challenge | Impact on Deployment |
+|-----------|---------------------|
+| **Non-determinism** | Same code + same prompt can produce different outputs between runs |
+| **Model version sensitivity** | A provider-side model update can change behavior without any code change |
+| **Dynamic tool orchestration** | Agent trajectory varies per request — testing coverage is inherently incomplete |
+| **Stateful memory** | Agent context accumulates — fresh deployment may behave differently than warm system |
+| **Unpredictable cost** | Token usage varies with input complexity and reasoning depth |
+| **Prompt injection risk** | New deployments may introduce vulnerability surfaces in modified prompts |
+
+These factors mean that passing health checks (HTTP 200, pod running) is necessary but NOT sufficient. The system can be "up" but behaving incorrectly, expensively, or unsafely.
+
+---
+
+## Evaluation-Gated Deployment
+
+The single most important addition to a rollout plan for AI systems: **no version reaches production without passing an evaluation suite**.
+
+### Golden Dataset
+
+Maintain a curated set of test cases that represent:
+- Core functionality (happy path for primary use cases)
+- Edge cases (unusual inputs, long contexts, multi-turn conversations)
+- Guardrail tests (prompt injection attempts, off-topic requests, PII handling)
+- Regression cases (previously failed scenarios that have been fixed)
+
+Minimum 20-50 cases for a production agent. Larger critical systems need 100+.
+
+### Evaluation Methods
+
+| Method | Use Case | Speed |
+|--------|----------|-------|
+| Exact match / regex | Structured outputs, tool calls, classification | Fast |
+| Semantic similarity | Open-ended generation quality | Medium |
+| LLM-as-judge | Complex quality assessment, helpfulness, accuracy | Slow |
+| Human review | Subjective quality, tone, brand alignment | Slowest |
+| Programmatic assertions | Tool call correctness, JSON schema compliance | Fast |
+
+### Pipeline Integration
+
+```
+Code Change → CI Build → Unit Tests → Evaluation Suite → Deploy to Canary → Live Evaluation → Promote
+                                           ↓ fail
+                                     Block deployment
+```
+
+Evaluation should run:
+1. **Pre-merge** (fast subset, 5-10 cases): Catch obvious regressions before PR merge
+2. **Post-merge to staging** (full suite, 50+ cases): Comprehensive validation before production
+3. **Post-deploy canary** (ongoing, sampled real traffic): Detect drift once live
+
+### Pass Criteria
+
+Define explicit thresholds:
+```yaml
+evaluation_gates:
+  accuracy_score: >= 0.85
+  guardrail_pass_rate: >= 0.99
+  tool_call_correctness: >= 0.90
+  response_latency_p95: <= 5000ms
+  token_cost_per_request_avg: <= $0.05
+  harmful_content_rate: == 0.0
+```
+
+Document these thresholds in the rollout plan. The go/no-go decision-maker must know what "pass" means.
+
+---
+
+## Prompt and Model Versioning
+
+### Prompt Versioning Strategies
+
+| Approach | Pros | Cons |
+|----------|------|------|
+| Git-tracked (alongside code) | Full history, PR review, blame | Requires deployment for changes |
+| Prompt management platform | A/B testing, hot-swap, analytics | Additional tool, potential drift from code |
+| Config-driven (environment vars) | Simple, deployment-independent | Limited history, no review workflow |
+
+For Pod delivery, recommend **git-tracked prompts with tagged releases** as the default. This gives:
+- Clear audit trail (who changed what, when, why)
+- PR-based review before production
+- Easy rollback to previous prompt version via git revert
+- Compatibility with evaluation pipeline (test against specific commit)
+
+### Model Version Pinning
+
+Always pin to a specific model version in production:
+```json
+{
+  "model": "gpt-4o-2024-08-06",  // Pinned — good
+  "model": "gpt-4o"              // Auto-updating — dangerous in production
+}
+```
+
+Plan model version upgrades as their own rollout event, not as a side effect.
+
+### Rollback Patterns
+
+| Scenario | Rollback Action |
+|----------|----------------|
+| Prompt regression | Revert to previous prompt version (git revert or config change) |
+| Model version issue | Pin back to previous model version in deployment config |
+| Agent logic bug | Standard code rollback (container image, deployment slot swap) |
+| RAG content issue | Revert vector index to previous snapshot |
+| Guardrail failure | Tighten content filter; may require immediate feature disable |
+
+---
+
+## Guardrail Validation
+
+Before deploying, validate that safety controls are functioning:
+
+### Pre-Deployment Guardrail Checks
+- Run prompt injection test suite against new version
+- Verify content safety filtering catches known-bad inputs
+- Confirm PII detection/redaction is active
+- Test rate limiting and token budget enforcement
+- Validate that the agent refuses out-of-scope requests appropriately
+
+### Post-Deployment Guardrail Monitoring
+- Track guardrail trigger rates — a sudden drop may indicate bypass
+- Monitor for new attack patterns in request logs
+- Alert on any successful prompt injection (content safety miss)
+- Track refusal rate — sudden spikes may indicate over-filtering
+
+---
+
+## Cost and Token Controls
+
+AI deployments can have unpredictable cost profiles. The rollout plan should include:
+
+### Pre-Deployment
+- Project token usage based on staging/load-test data
+- Set Azure OpenAI deployment-level rate limits (TPM/RPM)
+- Configure per-request token budgets in application code
+- Establish cost alerting thresholds in Azure Cost Management
+
+### During Deployment
+- Monitor token consumption rate compared to baseline
+- Compare canary cost-per-request vs. current production version
+- Alert if cost exceeds projection by >20%
+
+### Cost Rollback Trigger
+If token consumption exceeds budget projection by a defined threshold (e.g., 50% over), this is a valid rollback trigger even if the system is otherwise healthy.
+
+---
+
+## RAG Pipeline Deployment
+
+RAG systems have multiple independently-versioned components:
+
+```
+Documents → Chunking → Embeddings → Vector Index → Retrieval → LLM → Response
+```
+
+### Deployment Coordination
+
+| Component Change | Risk Level | Deployment Approach |
+|-----------------|------------|---------------------|
+| Document content update | Low | Incremental index update, no app deploy needed |
+| Chunking strategy change | Medium | Rebuild index, test retrieval quality before swap |
+| Embeddings model change | High | Full re-index required, run retrieval eval suite |
+| Vector index config (dimensions, algorithm) | High | Blue-green index swap after validation |
+| Retrieval logic change | Medium | Deploy with evaluation gate on retrieval metrics |
+| Prompt template change | Medium | Standard prompt versioning workflow |
+
+### Index Deployment Pattern
+
+For vector index updates that require a full rebuild:
+1. Build new index in parallel (shadow index)
+2. Run retrieval evaluation suite against new index
+3. Compare retrieval quality metrics (recall@k, MRR, relevance scores)
+4. If metrics pass, swap traffic to new index
+5. Keep old index available for 48h rollback window
+6. Decommission old index after confirmation
+
+---
+
+## Multi-Agent System Deployment
+
+When deploying systems with multiple cooperating agents:
+
+### Deployment Sequencing
+- Identify dependencies between agents (which calls which)
+- Deploy downstream agents first (the ones being called)
+- Verify inter-agent communication before deploying upstream orchestrator
+- Use API versioning to allow old orchestrator to work with new downstream agents temporarily
+
+### Rollback Complexity
+Multi-agent rollbacks are complex because:
+- Agent A v2 may depend on Agent B v2 — can't roll back A without also rolling back B
+- Shared state (conversation memory, task queues) may be incompatible across versions
+- Partial rollback may leave the system in an inconsistent state
+
+Mitigation: Deploy multi-agent changes behind a single feature flag that enables/disables the entire new version atomically.
+
+---
+
+## Observability for AI Systems
+
+The rollout plan must confirm these observability capabilities are in place BEFORE deployment:
+
+### Tracing
+- Request-level traces capturing: input → agent reasoning → tool calls → LLM calls → response
+- Correlation IDs spanning multiple agent hops
+- Token counts and latency per LLM call within the trace
+- Tool call parameters and results logged
+
+### Metrics
+- Request volume, error rate, latency (standard)
+- Token consumption (input + output) per request
+- Evaluation scores on sampled production traffic
+- Guardrail trigger rates (by type)
+- Cost per request / cost per hour
+- Cache hit rates (if semantic caching is used)
+
+### Alerts
+- Error rate threshold breach
+- Latency degradation (P95, P99)
+- Token burn rate anomaly
+- Evaluation score drop below threshold
+- Guardrail trigger rate anomaly (too high = over-blocking; too low = possible bypass)
+- Cost budget threshold
+
+### Tools
+Common observability stack for GenAI in Azure environments:
+- Azure Application Insights + custom telemetry for traces
+- Azure Monitor for metrics and alerts
+- Langfuse, Langsmith, or Weights & Biases Weave for GenAI-specific tracing
+- Azure Cost Management for spend tracking
+- Custom dashboards (Grafana, Power BI) for operational views

package/.github/skills/devops-rollout-plan/references/azure-safe-deployment.md

@@ -0,0 +1,206 @@
+# Azure Safe Deployment Patterns
+
+Reference material for Azure-specific deployment strategies. Use when the target environment is Azure.
+
+## Table of Contents
+1. [Progressive Exposure Models](#progressive-exposure-models)
+2. [Azure Service-Specific Patterns](#azure-service-specific-patterns)
+3. [Azure DevOps / GitHub Actions Integration](#cicd-integration)
+4. [Safe Decommissioning](#safe-decommissioning)
+
+---
+
+## Progressive Exposure Models
+
+The Azure Well-Architected Framework defines four core principles for safe deployment:
+
+1. **Safety and consistency** — All changes to production are inherently risky. Every deployment must follow a standard pattern and be automated.
+2. **Progressive exposure** — Minimize blast radius by rolling out to successively larger groups.
+3. **Health models** — Deployments must pass health checks before each phase can proceed.
+4. **Issue detection** — When issues are detected, halt immediately and initiate recovery.
+
+### Ring-Based Deployment
+
+```
+Ring 0: Internal team / canary (1-3 instances)
+   ↓ bake 2-4 hours
+Ring 1: Early adopters / 5-10% of traffic
+   ↓ bake 4-8 hours
+Ring 2: Broader rollout / 25-50% of traffic
+   ↓ bake 12-24 hours
+Ring 3: Full production / 100%
+```
+
+Bake times should be measured in hours and days, not minutes. Each ring should cover different time zones and usage patterns.
+
+### Blue-Green Deployment
+
+Two identical infrastructure pools. Blue runs current version, Green gets the update:
+1. Deploy to Green pool
+2. Internal validation on Green
+3. Shift small percentage of traffic to Green
+4. Progressive shift until Green carries 100%
+5. Blue becomes the new standby
+
+**Azure services for blue-green:**
+- Azure App Service deployment slots (swap-based)
+- AKS with multiple node pools or namespaces
+- Azure Front Door / Traffic Manager for traffic splitting
+- Azure Container Apps with revision-based routing
+
+### Canary Deployment
+
+Route a small percentage of real traffic to the new version:
+- Start at 1-5% canary allocation
+- Monitor health signals for the canary cohort specifically
+- Expand allocation progressively only when health signals are stable
+- Feature flags (Azure App Configuration) control which users see the new version
+
+### Feature Flags
+
+Azure App Configuration provides centralized feature flag management:
+- Deploy code dark (disabled), enable progressively
+- Target by user segment, percentage, or custom filter
+- Instant rollback by disabling the flag (no redeployment needed)
+- Useful for AI features where behavior may need rapid disable
+
+---
+
+## Azure Service-Specific Patterns
+
+### Azure Kubernetes Service (AKS)
+
+| Strategy | When to Use |
+|----------|-------------|
+| Rolling update (default) | Low-risk, stateless services |
+| Blue-green (namespace or cluster) | High-risk, need instant rollback |
+| Canary (Istio/Linkerd traffic split) | Progressive validation with real traffic |
+| Flagger + Prometheus | Automated canary with metric-based promotion |
+
+Key commands:
+```bash
+# Rolling update
+kubectl set image deployment/app app=image:v2
+
+# Canary with traffic split (Istio)
+kubectl apply -f canary-virtualservice.yaml
+
+# Rollback
+kubectl rollout undo deployment/app
+```
+
+### Azure App Service
+
+- Use **deployment slots** for zero-downtime swaps
+- Slot settings (connection strings, app settings) can be slot-sticky
+- Auto-swap from staging to production after warm-up
+- Swap with preview: route test traffic to staging slot before full swap
+
+### Azure Container Apps
+
+- **Revision-based routing**: Deploy new revision, split traffic by percentage
+- Label-based routing for targeted testing
+- Automatic scaling independent per revision
+- Built-in Dapr integration for service-to-service calls
+
+### Azure Functions
+
+- Deployment slots (same as App Service)
+- For Durable Functions: drain orchestrations before swap
+- Consider function app isolation for high-risk changes
+
+### Azure AI Foundry / Azure OpenAI
+
+- Model deployments are versioned — pin to specific model version
+- Use deployment names as abstraction layer (swap deployment target, keep name)
+- Quota and rate limits per deployment — plan capacity before rollout
+- Content filtering policies per deployment
+- Monitor token consumption as a health signal
+
+### Databases (Azure SQL, Cosmos DB, PostgreSQL)
+
+- Point-in-time restore as safety net (enable before migration)
+- Schema migrations should be backward-compatible (expand-contract pattern)
+- For Cosmos DB: use change feed to track write patterns before decommissioning
+- Never combine schema migration and application deployment in one change window
+
+---
+
+## CI/CD Integration
+
+### Azure DevOps Pipelines
+
+Multi-stage pipeline with approval gates:
+```yaml
+stages:
+  - stage: Build
+    jobs:
+      - job: BuildAndTest
+  - stage: DeployStaging
+    dependsOn: Build
+    jobs:
+      - deployment: DeployToStaging
+        environment: staging
+  - stage: DeployCanary
+    dependsOn: DeployStaging
+    jobs:
+      - deployment: DeployCanary
+        environment: production-canary
+        strategy:
+          canary:
+            increments: [5, 25, 50, 100]
+  - stage: DeployProduction
+    dependsOn: DeployCanary
+    condition: succeeded()
+    jobs:
+      - deployment: DeployToProduction
+        environment: production
+```
+
+Use environment approvals and gates for manual go/no-go decisions between stages.
+
+### GitHub Actions
+
+Multi-environment deployment with required reviewers:
+```yaml
+jobs:
+  deploy-staging:
+    environment: staging
+    steps: [...]
+  
+  deploy-canary:
+    needs: deploy-staging
+    environment: production-canary  # requires approval
+    steps: [...]
+  
+  deploy-production:
+    needs: deploy-canary
+    environment: production  # requires approval
+    steps: [...]
+```
+
+### Health Check Integration
+
+Both pipelines should validate health between stages:
+- HTTP health endpoint checks
+- Application Insights availability tests
+- Custom metric threshold queries (KQL via Azure Monitor)
+- AI evaluation suite execution (prompt regression, guardrail validation)
+
+---
+
+## Safe Decommissioning
+
+When removing or deprecating components:
+
+1. **Validate inactivity** — Confirm zero usage across a full business cycle (not just a few hours)
+2. **Preserve state** — Snapshot, export, or backup with tagged disposal date
+3. **Disable before delete** — Move to offline/disabled mode first; expose hidden dependencies
+4. **Monitor watch window** — Observe through normal and peak usage periods
+5. **Clean up references** — Remove DNS records, certificates, configuration pointing to the decommissioned resource
+
+For AI components specifically:
+- Check whether any downstream agents reference the component via tool definitions
+- Verify no prompt templates reference the endpoint
+- Confirm vector indexes aren't still being queried by other services
+- Archive evaluation datasets and golden sets before removing the model deployment

package/.github/skills/devops-rollout-plan/references/pod-delivery-context.md

@@ -0,0 +1,206 @@
+# Rollout Plans in Pod Delivery Context
+
+How deployment rollout plans fit within the AI Innovation Pod delivery model, Jump Start handoffs, and cross-team collaboration patterns.
+
+## Table of Contents
+1. [When Rollout Plans Get Created](#when-rollout-plans-get-created)
+2. [Ownership by Delivery Pattern](#ownership-by-delivery-pattern)
+3. [Handoff Conventions](#handoff-conventions)
+4. [GenAIOps Integration](#genaiops-integration)
+5. [Innovation Unit Alignment](#innovation-unit-alignment)
+
+---
+
+## When Rollout Plans Get Created
+
+In the Pod delivery lifecycle, rollout plans appear at specific moments:
+
+| Moment | Trigger | Plan Type |
+|--------|---------|-----------|
+| Jump Start → Pod transition | Workshop identified a use case ready for build; first deployment planned | Full plan (greenfield) |
+| Sprint delivery milestone | Feature complete, ready for staging/production promotion | Standard plan |
+| Model or prompt version update | LLM provider released new version, or prompt optimization complete | AI-specific plan |
+| Infrastructure change | Scaling, networking, security hardening | Infrastructure plan |
+| Pod → CIS/Operations handoff | Pod has completed build; operations team takes ownership | Handoff plan (self-contained) |
+| Emergency hotfix | Production issue requires rapid remediation | Lightweight emergency plan |
+
+The rollout plan is NOT optional even for small changes. The Pod's credibility with clients depends on controlled, professional releases. "We pushed it and it's live" is never acceptable in enterprise AI delivery.
+
+---
+
+## Ownership by Delivery Pattern
+
+### Pod-Led Innovation Sprint
+
+The Pod owns end-to-end deployment. Typical ownership:
+
+| Activity | Owner |
+|----------|-------|
+| Write rollout plan | AI Solution Architect |
+| Review plan | Engagement Lead + Client Platform Lead |
+| Execute deployment | AI Developer (with Architect oversight) |
+| Monitor verification | AI Developer + Business Analyst (user-side validation) |
+| Go/no-go decisions | AI Solution Architect (with Engagement Lead escalation) |
+| Post-deployment review | Full Pod |
+| Client communication | Engagement Lead |
+
+In this pattern, the Pod typically also establishes the GenAIOps foundation — traces, dashboards, evaluation automation — as part of the first deployment. This means the rollout plan for the initial release is heavier than subsequent ones.
+
+### Embedded Co-Delivery
+
+The Pod deploys the AI/GenAI layer while adjacent teams handle surrounding infrastructure:
+
+| Responsibility | Pod | Adjacent Team |
+|---------------|-----|---------------|
+| AI agent/model deployment | ✓ | |
+| Prompt and evaluation pipeline | ✓ | |
+| Container/compute infrastructure | | ✓ (CIS or ACE) |
+| Networking and DNS | | ✓ (Platform team) |
+| Database migrations | Shared | ✓ (DAE/I&D) |
+| Load testing | ✓ (AI-specific) | ✓ (QET - system-wide) |
+| Production monitoring | ✓ (AI telemetry) | ✓ (CIS - infra monitoring) |
+| Rollback execution | ✓ (AI layer) | ✓ (Infra layer) |
+
+The rollout plan must clearly delineate these boundaries. Include a RACI or ownership table for each deployment step.
+
+### Accelerate and Handoff
+
+The most demanding plan type. The rollout plan IS the handoff artifact — it must enable another team to:
+- Execute future deployments without Pod involvement
+- Diagnose and respond to production issues
+- Perform model/prompt version updates
+- Execute rollback if needed
+
+Include in the plan:
+- **Runbook for common operations** (scale up, rotate keys, update model version)
+- **Troubleshooting guide** (common failure modes and responses)
+- **Evaluation instructions** (how to run the eval suite, what scores mean, when to block)
+- **Escalation paths** (when to call the Pod back for support)
+
+---
+
+## Handoff Conventions
+
+When the Pod hands off operational ownership, the rollout plan package should include:
+
+### Minimum Handoff Package
+1. **Rollout plan template** — Adapted for the specific system, reusable for future deployments
+2. **Architecture decision record** — Why things are set up the way they are
+3. **Operational runbook** — Day-to-day operations, scaling, key rotation, certificate renewal
+4. **Monitoring dashboard** — Pre-built views of key health signals
+5. **Evaluation suite** — Tests, golden dataset, and instructions for running
+6. **Incident response playbook** — What to do when specific alerts fire
+7. **Cost baseline and budget thresholds** — What "normal" looks like financially
+
+### Quality Criteria for Handoff
+
+The receiving team should be able to answer YES to all:
+- [ ] Can we deploy a new version following this plan without calling the Pod?
+- [ ] Can we diagnose a production issue using the monitoring and runbook?
+- [ ] Can we execute a rollback within the documented timeframe?
+- [ ] Do we understand the evaluation criteria and how to run the suite?
+- [ ] Do we know when to escalate and to whom?
+
+If any answer is "no," the handoff isn't complete.
+
+---
+
+## GenAIOps Integration
+
+The rollout plan must account for how GenAIOps (observability, evaluation, prompt management) connects to the deployment pipeline.
+
+### First Deployment (GenAIOps Foundation)
+
+The initial production deployment typically includes standing up GenAIOps capabilities:
+
+```
+Deployment Package (First Release):
+├── Application / Agent code
+├── Infrastructure (IaC)
+├── Observability setup
+│   ├── Tracing instrumentation
+│   ├── Metrics collection
+│   ├── Alert rules
+│   └── Dashboard provisioning
+├── Evaluation automation
+│   ├── Golden dataset
+│   ├── Evaluation pipeline (CI integration)
+│   └── Scoring thresholds
+├── Prompt versioning
+│   ├── Version control setup
+│   └── Deployment automation
+└── Operational controls
+    ├── Rate limits
+    ├── Cost alerts
+    └── Feature flags
+```
+
+### Subsequent Deployments
+
+After the foundation exists, later rollout plans can reference existing GenAIOps rather than rebuilding:
+
+```
+Deployment Package (Subsequent Releases):
+├── Code/prompt changes
+├── Updated evaluation suite (if test cases added)
+├── Updated alert thresholds (if baselines changed)
+└── Verification against existing monitoring
+```
+
+### Brownfield Considerations
+
+When the client already has enterprise observability (Splunk, Datadog, PagerDuty, ServiceNow), the Pod should integrate AI telemetry into the existing stack rather than standing up parallel tooling. The rollout plan should document:
+- Where AI traces are routed (existing APM vs. dedicated GenAI tool)
+- How AI alerts integrate with existing incident workflow (ITSM integration)
+- Whether AI metrics appear in existing executive dashboards or dedicated views
+- Who owns the AI-specific monitoring vs. general infrastructure monitoring
+
+---
+
+## Innovation Unit Alignment
+
+In the Pod's Innovation Unit (IU) model, deployment activities consume IUs. The rollout plan should indicate:
+
+| Activity | Typical IU Weight | Notes |
+|----------|-------------------|-------|
+| Write rollout plan | 0.5 - 1 IU | Depends on complexity |
+| Execute first production deployment | 1 - 2 IU | Includes GenAIOps setup |
+| Execute routine deployment | 0.25 - 0.5 IU | Using established patterns |
+| Post-deployment validation | 0.25 IU | Standard verification cycle |
+| Handoff package creation | 1 - 2 IU | Self-contained operational documentation |
+| Emergency deployment / hotfix | 0.5 - 1 IU | Unplanned, higher pressure |
+
+This helps Engagement Leads plan sprint capacity and communicate deployment costs to clients. When estimating a milestone, include deployment IUs explicitly — clients often underestimate the effort required for production-quality releases.
+
+---
+
+## Client Communication Patterns
+
+### For Pod-Led Deployments
+
+Clients want to know:
+- **When** is the deployment happening?
+- **What** will change from their perspective?
+- **How long** will there be any impact?
+- **What do they need to do** (if anything)?
+- **Who to contact** if something seems wrong after deployment
+
+Template for client notification:
+```
+Subject: [System Name] — Planned Update [Date]
+
+What's changing: [1-2 sentence plain-language description]
+When: [Date, time, timezone]
+Expected duration: [X minutes/hours]
+User impact: [None / Brief interruption / Feature temporarily unavailable]
+Action required: [None / Please test X after Y time]
+Contact: [Name, channel] if you notice anything unexpected
+```
+
+### For Handoff Plans
+
+The receiving team needs:
+- **Written confirmation** that the Pod considers the system stable and handoff-ready
+- **Training session** walking through the rollout plan and runbook
+- **Shadow deployment** where the receiving team executes while Pod observes
+- **Supported-independence period** (2-4 weeks) where Pod is available for questions but not leading