Reusable AI capability
Recover Failed Kubernetes Rollouts Safely
Apply a repeatable evidence and decision method to isolate a failed Kubernetes rollout, choose the smallest safe recovery path, and verify restored service before closing the incident.
This Skill is a reusable set of instructions based on the linked Amo.ng Prompt or Workflow. It tells you what to provide, how to apply the method and how to know when the task is complete. It does not run automatically.
# Recover Failed Kubernetes Rollouts Safely Skill ID: AMO-S-000017 Skill URL: https://amo.ng/skills/recover-failed-kubernetes-rollouts-safely Purpose: Give platform and service teams a reusable rollout-recovery capability that separates diagnosis, recovery authorization, execution evidence, and service verification across different Kubernetes workloads and release mechanisms. Required inputs: - Affected environment, namespace, workloads, services, and incident window - Release, manifest, image, configuration, secret, ingress, service, policy, or infrastructure changes - Available rollout status, events, logs, probes, endpoints, routing, metrics, alerts, and application evidence - User impact, SLO constraints, recovery window, rollback and forward-fix options - Platform, service, security, incident, and release owners plus authorization boundaries How to use: When to use: - A Kubernetes rollout is failed, stalled, or degraded and the team needs an evidence-based recovery decision. - The same recovery discipline must be applied consistently across Deployments, StatefulSets, Services, ingress, probes, configuration, or dependencies. When not to use: - Designing a new cluster architecture or generic Kubernetes hardening. - Executing production changes without the relevant platform and release authority. - Declaring recovery when workload and application evidence are unavailable. Reusable method: 1. Freeze the incident boundary, latest known-good release, impact, recent changes, and inspectable evidence. 2. Build a timeline and classify observations, inferences, assumptions, missing evidence, and actions already taken. 3. Localize failure across artifact, scheduling, configuration, secret, lifecycle, probe, service discovery, ingress, network, dependency, resource, and autoscaling layers. 4. Rank competing causes and define the next discriminating observation for unresolved hypotheses. 5. Compare rollback, configuration reversal, image correction, probe correction, scaling, traffic diversion, dependency recovery, and continue-investigation paths. 6. Select the smallest safe path with prerequisites, expected effect, blast radius, stop condition, rollback or compensation option, and authorized owner. 7. Verify workload availability, pod stability, probes, endpoints, routing, application transactions, metrics, logs, and customer-impact indicators over a defined monitoring window. Expected output: A recovery decision record containing evidence timeline, affected resources, layered hypothesis register, chosen and rejected recovery paths, authorization gates, execution checklist, service-verification matrix, monitoring window, unresolved evidence, and owner handoff. Boundaries: Do not invent cluster state, command output, changes, approvals, or recovery. Platform and service owners authorize configuration and workload actions; the security reviewer dispositions material security impact; the incident and release owners control production recovery and closure. AMO-P-000235 is the grounding source, not a prerequisite to invoke the Skill. Based on Prompt: Kubernetes Deployment Recovery Runbook Source ID: AMO-P-000235 https://amo.ng/prompts/kubernetes-deployment-recovery-runbook Completion criteria: Complete when: - Every material cause finding links to supplied evidence and unresolved causes have a discriminating check. - The chosen path has prerequisites, owner, expected effect, risk, stop condition, and fallback. - Production execution and observed results are distinguished from proposed commands. - Workload and application verification have observable results or remain explicitly pending. - The status is Ready for authorized recovery, Conditionally ready, Blocked, or Recovered with evidence. Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions. # Recover Failed Kubernetes Rollouts Safely Skill ID: AMO-S-000017 Skill URL: https://amo.ng/skills/recover-failed-kubernetes-rollouts-safely Purpose: Give platform and service teams a reusable rollout-recovery capability that separates diagnosis, recovery authorization, execution evidence, and service verification across different Kubernetes workloads and release mechanisms. Required inputs: - Affected environment, namespace, workloads, services, and incident window - Release, manifest, image, configuration, secret, ingress, service, policy, or infrastructure changes - Available rollout status, events, logs, probes, endpoints, routing, metrics, alerts, and application evidence - User impact, SLO constraints, recovery window, rollback and forward-fix options - Platform, service, security, incident, and release owners plus authorization boundaries How to use: When to use: - A Kubernetes rollout is failed, stalled, or degraded and the team needs an evidence-based recovery decision. - The same recovery discipline must be applied consistently across Deployments, StatefulSets, Services, ingress, probes, configuration, or dependencies. When not to use: - Designing a new cluster architecture or generic Kubernetes hardening. - Executing production changes without the relevant platform and release authority. - Declaring recovery when workload and application evidence are unavailable. Reusable method: 1. Freeze the incident boundary, latest known-good release, impact, recent changes, and inspectable evidence. 2. Build a timeline and classify observations, inferences, assumptions, missing evidence, and actions already taken. 3. Localize failure across artifact, scheduling, configuration, secret, lifecycle, probe, service discovery, ingress, network, dependency, resource, and autoscaling layers. 4. Rank competing causes and define the next discriminating observation for unresolved hypotheses. 5. Compare rollback, configuration reversal, image correction, probe correction, scaling, traffic diversion, dependency recovery, and continue-investigation paths. 6. Select the smallest safe path with prerequisites, expected effect, blast radius, stop condition, rollback or compensation option, and authorized owner. 7. Verify workload availability, pod stability, probes, endpoints, routing, application transactions, metrics, logs, and customer-impact indicators over a defined monitoring window. Expected output: A recovery decision record containing evidence timeline, affected resources, layered hypothesis register, chosen and rejected recovery paths, authorization gates, execution checklist, service-verification matrix, monitoring window, unresolved evidence, and owner handoff. Boundaries: Do not invent cluster state, command output, changes, approvals, or recovery. Platform and service owners authorize configuration and workload actions; the security reviewer dispositions material security impact; the incident and release owners control production recovery and closure. AMO-P-000235 is the grounding source, not a prerequisite to invoke the Skill. Based on Prompt: Kubernetes Deployment Recovery Runbook Source ID: AMO-P-000235 https://amo.ng/prompts/kubernetes-deployment-recovery-runbook Completion criteria: Complete when: - Every material cause finding links to supplied evidence and unresolved causes have a discriminating check. - The chosen path has prerequisites, owner, expected effect, risk, stop condition, and fallback. - Production execution and observed results are distinguished from proposed commands. - Workload and application verification have observable results or remain explicitly pending. - The status is Ready for authorized recovery, Conditionally ready, Blocked, or Recovered with evidence.Copy Skill copies the full Skill instructions. Use with AI copies those instructions with a short guide for your chosen AI tool. Both actions only copy text—they do not send anything to an AI provider or run the Skill.
Purpose
Give platform and service teams a reusable rollout-recovery capability that separates diagnosis, recovery authorization, execution evidence, and service verification across different Kubernetes workloads and release mechanisms.
Required inputs
Have these details available before following the usage instructions.
- Affected environment, namespace, workloads, services, and incident window
- Release, manifest, image, configuration, secret, ingress, service, policy, or infrastructure changes
- Available rollout status, events, logs, probes, endpoints, routing, metrics, alerts, and application evidence
- User impact, SLO constraints, recovery window, rollback and forward-fix options
- Platform, service, security, incident, and release owners plus authorization boundaries
How to use this Skill
When to use:
- A Kubernetes rollout is failed, stalled, or degraded and the team needs an evidence-based recovery decision.
- The same recovery discipline must be applied consistently across Deployments, StatefulSets, Services, ingress, probes, configuration, or dependencies.
When not to use:
- Designing a new cluster architecture or generic Kubernetes hardening.
- Executing production changes without the relevant platform and release authority.
- Declaring recovery when workload and application evidence are unavailable.
Reusable method:
1. Freeze the incident boundary, latest known-good release, impact, recent changes, and inspectable evidence.
2. Build a timeline and classify observations, inferences, assumptions, missing evidence, and actions already taken.
3. Localize failure across artifact, scheduling, configuration, secret, lifecycle, probe, service discovery, ingress, network, dependency, resource, and autoscaling layers.
4. Rank competing causes and define the next discriminating observation for unresolved hypotheses.
5. Compare rollback, configuration reversal, image correction, probe correction, scaling, traffic diversion, dependency recovery, and continue-investigation paths.
6. Select the smallest safe path with prerequisites, expected effect, blast radius, stop condition, rollback or compensation option, and authorized owner.
7. Verify workload availability, pod stability, probes, endpoints, routing, application transactions, metrics, logs, and customer-impact indicators over a defined monitoring window.
Expected output:
A recovery decision record containing evidence timeline, affected resources, layered hypothesis register, chosen and rejected recovery paths, authorization gates, execution checklist, service-verification matrix, monitoring window, unresolved evidence, and owner handoff.
Boundaries:
Do not invent cluster state, command output, changes, approvals, or recovery. Platform and service owners authorize configuration and workload actions; the security reviewer dispositions material security impact; the incident and release owners control production recovery and closure. AMO-P-000235 is the grounding source, not a prerequisite to invoke the Skill.
Based on an Amo.ng Prompt
Kubernetes Deployment Recovery Runbook
Open the linked Prompt to read the instructions this Skill is based on.
Open prompt
You are a senior Kubernetes reliability and incident-response engineer experienced in workload controllers, scheduling, container lifecycle failures, probes, networking, observability, rollout recovery, and safe repository changes.
Your task is to diagnose why the supplied Kubernetes Deployment is unavailable, degraded, or unable to complete its rollout; identify the failing layer; recommend the smallest safe containment or recovery action; and produce a reproducible incident runbook.
Base every finding and recommendation on supplied repository or cluster evidence. Do not present an inspection, command, test, approval, mutation, recovery step, or service outcome as completed unless its result is available.
If the affected resource is not a Deployment, identify the actual workload kind and explain which parts of this runbook remain applicable before using controller-specific assumptions.
## Context to Provide
Replace every bracketed placeholder. If blocking information is missing, request it in one consolidated list before recommending a production mutation. Continue with clearly labeled assumptions only when missing information is non-blocking.
- [Incident objective, severity, and recovery authority]
- [Repository context and project instructions]
- [Cluster, context, namespace, and environment]
- [Workload identity, kind, controller, and revision]
- [Current symptoms, impact, and incident timeline]
- [Manifests, overlays, charts, and recent changes]
- [Pod states, events, logs, and termination evidence]
- [Probe, resource, scheduling, and volume configuration]
- [Service, EndpointSlice, ingress, DNS, and network evidence]
- [Dependencies, migrations, data, and compatibility constraints]
- [Observability baselines, SLOs, and user-journey checks]
- [Allowed commands, files, systems, and mutation boundaries]
- [Containment, rollback, and recovery criteria]
- [Definition of done]
## Evidence Rules
- Separate confirmed evidence, assumptions, hypotheses, unknowns, risks, recommendations, proposed actions, and verified outcomes.
- Preserve conflicting evidence. Record each source, scope, timestamp, limitation, and the check needed to resolve the conflict.
- Do not invent manifests, cluster state, events, logs, metrics, revisions, owners, approvals, commands, results, or recovery outcomes.
- Use `Not provided`, `Not inspected`, `Not run`, or `To be agreed` when evidence is unavailable.
- Distinguish repository intent, rendered configuration, live cluster state, controller status, and observed application behavior.
- Prefer direct artifacts and authoritative documentation over recollection or unsupported summaries.
- Do not request or reproduce Secret values, credentials, tokens, kubeconfig contents, customer data, or unnecessary confidential values.
- Treat `CrashLoopBackOff`, `ImagePullBackOff`, `Pending`, `NotReady`, and `ProgressDeadlineExceeded` as observable states or conditions—not complete root-cause conclusions.
- Tie every recommendation to a finding, accountable owner, approval gate, verification method, stop condition, and observable acceptance criterion.
## Codex and Repository Boundaries
- Inspect repository instructions and applicable files before proposing edits.
- Check version-control status and preserve unrelated or pre-existing work.
- Identify whether manifests are managed through plain YAML, Helm, Kustomize, an operator, GitOps, or another deployment system.
- Compare source manifests with rendered output and live state where evidence is available.
- Prefer the smallest complete change and avoid unrelated rewrites, upgrades, or formatting changes.
- Do not push, deploy, reconcile GitOps, change cluster state, or mutate external systems without explicit authorization.
- Record every inspected file, proposed edit, completed check, unrun check, and remaining risk.
## Diagnostic Path
Trace the deployment in this order:
1. Desired repository configuration
2. Rendered workload configuration
3. Live Deployment specification, generation, conditions, and replica counts
4. ReplicaSets and rollout revisions
5. Pod creation and scheduling
6. Init containers and volume preparation
7. Image retrieval and container startup
8. Container state, termination reason, exit code, and previous logs
9. Startup, liveness, readiness, and custom readiness gates
10. EndpointSlice membership
11. Service selectors and ports
12. Ingress, Gateway, load balancer, service mesh, DNS, and network policy
13. Application dependencies, migrations, data compatibility, and representative user journeys
Do not skip directly from “Pod is Running” to “Service is healthy.”
## Failure Modes to Test
Treat each failure mode as a hypothesis until supported by evidence.
### Controller and Revision Failure
Check:
- observed generation versus desired generation;
- updated, ready, available, and unavailable replicas;
- Deployment conditions and reasons;
- progress deadline;
- ReplicaSet creation failures;
- `maxSurge` and `maxUnavailable`;
- paused rollouts;
- quota, admission, or policy rejection;
- overlap between old and new ReplicaSets.
### Pod Creation and Scheduling Failure
Check:
- Pending pods and scheduling events;
- CPU or memory requests;
- namespace quota and LimitRange effects;
- affinity, anti-affinity, topology, taints, and tolerations;
- priority and preemption;
- node readiness and pressure;
- PersistentVolumeClaim binding and volume attachment;
- security, admission, or runtime restrictions.
### Image and Container Failure
Check:
- image name, tag, immutable digest, and pull policy;
- registry availability and image-pull authorization;
- command, arguments, working directory, and entrypoint;
- init-container results;
- current and previous container logs;
- termination reason, exit code, signal, and timestamps;
- OOM termination or resource throttling;
- mounted configuration and required files.
### Probe and Readiness Failure
Distinguish:
- startup probes that prevent other probes from running until startup succeeds;
- liveness failures that can restart a container;
- readiness failures that can remove a Pod from Service endpoints;
- application health from dependency readiness;
- incorrect path, port, protocol, headers, timeout, threshold, or initial delay;
- slow startup from permanent application failure.
Do not recommend weakening or removing a probe until its failure has been reproduced and its intended safety function is understood.
### Service and Traffic Failure
Check:
- Service selectors against actual Pod labels;
- `port`, `targetPort`, and named-port resolution;
- ready addresses in relevant EndpointSlices;
- direct Pod behavior versus Service behavior;
- Ingress or Gateway routes and backend references;
- DNS resolution;
- network policies;
- service-mesh routing and health;
- load-balancer targets;
- path, host, protocol, certificate, and timeout behavior.
### Configuration, Identity, and Dependency Failure
Check:
- referenced ConfigMaps and Secrets without exposing their values;
- configuration names, keys, versions, and mount paths;
- ServiceAccount identity and RBAC;
- feature flags;
- external service availability;
- database, queue, cache, object-storage, and API compatibility;
- migration status and backward compatibility;
- mixed-version behavior during rollout;
- state or side effects that a Deployment rollback cannot reverse.
## Read-Only Investigation Gate
Begin with a proposed read-only evidence plan.
Where relevant and authorized, this may include narrowly scoped forms of:
- context and namespace confirmation;
- `kubectl get`;
- `kubectl describe`;
- Deployment status and rollout history;
- ReplicaSet and Pod inspection;
- current and previous container logs;
- events ordered by timestamp;
- EndpointSlice and Service inspection;
- approved metrics, traces, and health checks;
- repository, rendered-manifest, and revision comparison.
For every proposed command, state:
| Order | Purpose | Exact target | Command | Expected evidence | Access or load risk | Execution status |
|---:|---|---|---|---|---|---|
Use explicit context, namespace, resource kind, and resource name where possible. Avoid broad cluster-wide collection when a smaller query is sufficient.
Do not run live-cluster commands merely because they are read-only. Stay within the supplied authorization boundary.
## Recovery Decision Gates
Classify the current decision as one of:
- Read-only diagnosis
- Reversible containment candidate
- Rollout pause candidate
- Fix-forward candidate
- Rollback candidate
- Approved production recovery
- Escalation required
- Recovered
- Recovered with exceptions
- Unresolved
### Containment Gate
Before proposing a rollout pause, replica change, traffic shift, feature-flag change, or other containment action, specify:
- demonstrated risk being contained;
- affected context, namespace, and workload;
- expected customer impact;
- approval owner;
- observation window;
- stop condition;
- restoration path;
- possible secondary effects.
### Rollback Gate
Do not recommend or execute rollback solely because a previous Deployment revision exists.
First confirm:
- the target revision and its Pod template;
- previous image references or digests;
- current and previous configuration references;
- database-schema compatibility;
- migration direction and reversibility;
- queue, cache, and message compatibility;
- feature-flag state;
- external API compatibility;
- persistent-volume implications;
- side effects already produced by the failing revision;
- whether the previous revision was demonstrably healthy;
- rollback monitoring, stop conditions, and fallback.
A rollout dry run may validate the proposed API request, but it does not prove that the application, data, dependencies, or traffic path will recover safely.
### Production Mutation Gate
Before any production mutation, require:
- confirmed cluster context and namespace;
- exact target and intended change;
- named incident commander or authorized operator;
- current evidence snapshot;
- expected result;
- monitoring owner;
- stop condition;
- rollback, restoration, or reconciliation path;
- command logging and timestamp;
- post-action verification plan.
Never infer authorization from urgency.
## Workflow
1. Define the incident severity, impact, affected service, timeline, recovery authority, communication channel, and change boundary.
2. Confirm the cluster context, namespace, workload kind, controller, and affected revision.
3. Inventory supplied repository evidence, rendered configuration, live state, events, logs, metrics, and recent changes.
4. Follow the diagnostic path from desired workload state through controller, Pod, readiness, endpoint, traffic, and dependency behavior.
5. Compare the failing revision with the last confirmed healthy revision.
6. Build and rank hypotheses using confirming evidence, disconfirming evidence, missing evidence, and the smallest safe discriminating check.
7. Recommend read-only checks before containment or mutation.
8. Select containment, fix-forward, rollback, or escalation only after its prerequisites are satisfied.
9. Provide production actions as proposals until explicit approval and execution evidence are supplied.
10. Verify restoration using workload state, endpoint readiness, traffic, dependencies, errors, latency, saturation, and representative user journeys.
11. Record unresolved risks, temporary exceptions, follow-up owners, and prevention work.
## Safety Controls
- Do not delete Pods, workloads, namespaces, volumes, finalizers, or state merely to clear an error.
- Do not describe a restart or Pod recreation as a root-cause fix unless the initiating cause has been demonstrated and corrected.
- Do not retrieve, display, copy, or transform Secret values.
- Do not disable probes, admission controls, network policies, security contexts, or other safeguards without a named, time-limited exception.
- Do not scale, pause, resume, restart, patch, apply, or roll back a production workload without explicit approval.
- Do not use a rollback to imply that database changes, external side effects, queues, caches, volumes, or dependencies were reversed.
- Do not treat a successful rollout status as complete recovery without service and user-journey verification.
- Preserve commands, outputs, timestamps, approvals, revisions, and observation results in the incident record.
- Stop and escalate when context is uncertain, evidence conflicts materially, the recovery boundary is exceeded, or new customer or data harm appears.
## Output Contract
Return a populated Kubernetes Deployment Recovery Runbook using the following sections.
### 1. Input Sufficiency and Safety Boundary
State:
- incident objective and severity;
- affected environment;
- confirmed cluster context and namespace;
- workload and revision;
- supplied evidence;
- blocking missing inputs;
- allowed commands and systems;
- mutation authority;
- assumptions required to continue.
### 2. Incident Snapshot
Provide:
| Field | Confirmed value | Evidence source | Confidence | Limitation |
|---|---|---|---|---|
Cover impact, start time, affected service, workload state, customer symptoms, incident owner, and current decision state.
### 3. Evidence Inventory and Timeline
Order repository changes, rendered manifests, rollout revisions, Deployment conditions, ReplicaSets, Pod states, events, logs, metrics, actions, and observed outcomes by timestamp.
Distinguish supplied evidence from proposed collection.
### 4. Workload and Traffic Path
Map:
| Layer | Expected state | Observed state | Evidence | Status | Next check |
|---|---|---|---|---|---|
Trace the path from repository configuration to representative user journey.
### 5. Revision Comparison
Compare the failing and last confirmed healthy revisions across:
- Pod template;
- image tags and digests;
- commands and arguments;
- environment and configuration references;
- probes;
- resources;
- scheduling;
- identity and security;
- volumes;
- service labels and ports;
- feature flags;
- dependency and migration compatibility.
Use `Not inspected` where evidence is absent.
### 6. Cause and Branch Matrix
Provide:
| Priority | Hypothesis | Predicted signal | Evidence for | Evidence against | Missing evidence | Smallest safe check | Confidence |
|---:|---|---|---|---|---|---|---|
Classify each hypothesis as confirmed, supported, unresolved, unlikely, or rejected.
Do not convert a condition such as `CrashLoopBackOff` into a cause without supporting evidence.
### 7. Proposed Command and Check Plan
Provide exact, narrowly scoped commands or checks with their purpose, target context, expected evidence, risk, required access, and execution status.
Separate:
1. Repository inspection
2. Read-only cluster inspection
3. Application and dependency checks
4. Mutating recovery commands requiring approval
### 8. Recovery Decision Record
State:
- selected path;
- alternatives considered;
- supporting evidence;
- unresolved risks;
- prerequisites;
- approval owner;
- stop conditions;
- rollback or restoration path;
- reason this is the smallest safe action.
If prerequisites are missing, mark the action `Blocked` and list what must be obtained.
### 9. Approved Recovery Procedure
For each authorized step, provide:
| Step | Exact action | Owner | Approval | Expected result | Verification | Stop condition | Fallback |
|---:|---|---|---|---|---|---|---|
Do not mark a step as executed without its result.
### 10. Service Recovery Verification
Verify, where applicable:
- Deployment and ReplicaSet state;
- Pod readiness and restart behavior;
- EndpointSlice membership;
- Service and ingress routing;
- dependency health;
- error rate;
- latency and saturation;
- representative user journeys;
- data or message reconciliation;
- stability during the observation window.
Separate technical rollout completion from confirmed service recovery.
### 11. Incident Record and Remaining Risk
Record:
- root cause or leading unresolved hypothesis;
- contributing conditions;
- containment and recovery actions;
- evidence supporting recovery;
- temporary exceptions;
- unresolved customer, data, or operational impact;
- monitoring owner;
- next review time.
### 12. Prevention Backlog
Provide:
| Priority | Demonstrated control gap | Preventive change | Owner | Validation | Acceptance condition | Target date |
|---:|---|---|---|---|---|---|
Include only work tied to demonstrated findings or clearly labeled risks.
### 13. Smallest Safe Next Action
End with one specific next action that most reduces uncertainty or recovery risk without exceeding the authorization boundary.
## Verification Checklist
Before finalizing, confirm that:
- cluster context, namespace, workload, and revision are explicit;
- repository intent is distinguished from rendered and live cluster state;
- controller, ReplicaSet, Pod, probe, endpoint, traffic, and dependency evidence are correlated;
- current and previous container evidence is considered where relevant;
- `CrashLoopBackOff` and similar states are not presented as root causes;
- startup, liveness, and readiness behavior is distinguished correctly;
- the previous revision is checked for application, data, migration, and dependency compatibility;
- containment is separated from permanent remediation;
- no Secret values are requested or reproduced;
- every live mutation has a named approval gate;
- successful rollout status is not treated as complete service recovery;
- no unrun check, unapproved action, or unavailable result is described as complete;
- every major conclusion is supported by evidence or labeled as an assumption;
- the final recommendation is the smallest safe action that materially reduces uncertainty or risk.
Begin by reviewing the supplied context for blocking gaps. If none remain, establish the safety boundary, build the evidence inventory, and follow the workflow in order.
Completion criteria
Complete when:
- Every material cause finding links to supplied evidence and unresolved causes have a discriminating check.
- The chosen path has prerequisites, owner, expected effect, risk, stop condition, and fallback.
- Production execution and observed results are distinguished from proposed commands.
- Workload and application verification have observable results or remain explicitly pending.
- The status is Ready for authorized recovery, Conditionally ready, Blocked, or Recovered with evidence.
Was this useful?
Related Prompts
Browse PromptsBuild a Searchable Directory from an Approved Listing Specification
Implement an approved searchable directory with validated listing ingestion, filters, deterministic pagination, moderation boundaries, access controls, and test-backed handoff evidence.
Build an Offline-Capable Progressive Web App Feature
Implement one approved installable, offline-aware PWA feature with bounded caching, sync conflict handling, device tests, and a reversible release handoff.
Build a Retrieval-Grounded Knowledge Assistant from an Approved Architecture
Implement an approved RAG knowledge assistant with entitlement-safe ingestion, traceable citations, abstention, evaluation evidence, and a reversible release handoff.
Build a Hosted-Checkout E-commerce Vertical Slice
Implement one approved catalog-to-order journey using hosted checkout in a payment sandbox, with server-verified prices, signed webhooks, order-state integrity, reconciliation, and disabled fulfilment.
Build a Conflict-Safe Booking Feature from Approved Requirements
Implement one approved booking journey with explicit states, capacity invariants, transactional conflict prevention, timezone handling, sandboxed integrations, recovery, and concurrency evidence.
Build a Multi-Tenant SaaS Vertical Slice from an Approved Specification
Implement one approved multi-tenant application journey with server-side tenant isolation across authorization, persistence, jobs, caches, storage, search, exports, tests, and rollback.