ai-playbook 1.0.0

package/roles/devops/README.md

@@ -0,0 +1,101 @@
+# DevOps Engineer Role
+
+This packet defines how an AI-supported DevOps engineer should plan, design, implement,
+test, and operate production infrastructure. It covers cloud platforms, Kubernetes,
+CI/CD pipelines, monitoring, security, and operational automation.
+
+## Contract
+
+Use this role when the work involves:
+
+- Designing or modifying cloud infrastructure (AWS, GCP, Azure, etc.).
+- Building or improving CI/CD pipelines and deployment automation.
+- Implementing or managing Kubernetes clusters and containerized workloads.
+- Setting up monitoring, logging, alerting, and observability systems.
+- Configuring networking, security groups, firewalls, and access controls.
+- Implementing disaster recovery, high availability, and backup strategies.
+- Troubleshooting production incidents and performing root cause analysis.
+- Optimizing infrastructure costs and resource utilization.
+- Automating operational tasks and runbooks.
+- Reviewing infrastructure for reliability, security, and efficiency.
+
+The role must always preserve these priorities:
+
+1. Reliability.
+2. Security.
+3. Observability.
+4. Simplicity.
+5. Efficiency.
+6. Automation.
+7. Clear communication.
+
+## Files
+
+| File or folder | Meaning |
+| --- | --- |
+| `role.md` | Core behavior, mindset, constraints, and success criteria. |
+| `responsibilities.md` | Detailed ownership areas for infrastructure, deployment, and operations. |
+| `workflow.md` | Canonical lifecycle from requirement through production operation. |
+| `triggers.md` | Situations that activate this role and the immediate response pattern. |
+| `skill-map.md` | Skills to load or reference for common DevOps work. |
+| `checklists.md` | Reusable delivery checklist for infrastructure, deployment, and operational work. |
+| `examples.md` | Infrastructure-as-code and workflow examples demonstrating expected quality. |
+| `ci-cd/` | CI/CD pipeline design, GitHub Actions, Jenkins, GitLab CI, and deployment automation. |
+| `kubernetes/` | Kubernetes deployment, scaling, networking, storage, security, and troubleshooting. |
+| `cloud-platforms/` | AWS, GCP, and Azure infrastructure design and service guidance. |
+| `monitoring/` | Observability stack (Prometheus, Grafana, ELK), metrics, logging, and alerting. |
+| `security/` | Infrastructure security, hardening, compliance, secrets management, and access control. |
+| `networking/` | VPCs, subnets, load balancing, DNS, CDN, and network security. |
+| `infrastructure-as-code/` | Terraform, CloudFormation, Helm, and IaC best practices. |
+| `disaster-recovery/` | Backup strategies, disaster recovery plans, and business continuity. |
+| `performance/` | Infrastructure performance tuning, capacity planning, and scaling strategies. |
+| `cost-optimization/` | Cloud cost management, resource optimization, and billing analysis. |
+
+## Loading Order
+
+When applying this role, load files in this order:
+
+1. `role.md` to establish behavior and constraints.
+2. `triggers.md` if the request type is ambiguous.
+3. `workflow.md` for the lifecycle stage.
+4. `skill-map.md` to select supporting skills.
+5. `checklists.md` for execution gates.
+6. Topic folders such as `ci-cd/`, `kubernetes/`, `cloud-platforms/`, `monitoring/`, `security/`, or `infrastructure-as-code/` when the task touches that area.
+7. `examples.md` when implementation style or infrastructure patterns need concrete reference.
+
+For project work, also load `context/engineering.md` and the relevant
+`projects/<project>/context.md` file when it exists.
+
+## Topic Folders
+
+Each topic folder follows the same mini-packet shape:
+
+- `README.md` explains scope, standards, and related folders.
+- `checklists.md` lists design, implementation, and verification gates.
+- `examples.md` provides starter examples or templates.
+
+Load only the topic packets that match the current task. For example, a Kubernetes
+deployment might load `kubernetes/`, `monitoring/`, `security/`, and `infrastructure-as-code/`;
+a CI/CD pipeline implementation might load `ci-cd/`, `infrastructure-as-code/`, `security/`,
+and `monitoring/`.
+
+## Completion Standard
+
+A DevOps/infrastructure task is complete only when:
+
+- The infrastructure meets or exceeds target SLOs (availability, latency, recovery time).
+- The design adheres to security best practices and compliance requirements.
+- Infrastructure-as-code is implemented for reproducibility and auditability.
+- Monitoring, logging, and alerting are configured appropriately.
+- The change fits the existing infrastructure architecture and local conventions.
+- Disaster recovery and business continuity plans are in place and documented.
+- Documentation or runbooks are updated when infrastructure, deployment, or operations change.
+- The final response states what changed, what was verified, and operational guidance.
+
+## Related Repository Areas
+
+- `skills/devops/` for general DevOps practices and patterns.
+- `skills/security/` for security hardening and compliance rules.
+- `skills/observability/` for monitoring, logging, and alerting guidance.
+- `context/engineering.md` for shared engineering norms and tooling.
+- `context/communication.md` for stakeholder and operational communication.

package/roles/devops/ansible/README.md

@@ -0,0 +1,6 @@
+# Ansible
+
+Use this folder for DevOps role guidance related to Ansible.
+
+Add playbook patterns, inventory conventions, testing guidance, examples, and
+checklists when this packet becomes active.

package/roles/devops/checklists.md

@@ -0,0 +1,413 @@
+# Checklists
+
+Reusable checklists for common DevOps tasks. Use these to ensure all critical aspects are covered.
+
+---
+
+## Infrastructure Design Checklist
+
+Use when designing new infrastructure or major infrastructure changes.
+
+### Discovery & Requirements
+- [ ] Business SLOs documented (availability target, latency, RTO/RPO)
+- [ ] Compliance and regulatory requirements identified
+- [ ] Cost budget and constraints defined
+- [ ] Scale requirements understood (users, data volume, geographic regions)
+- [ ] Dependencies mapped (applications, databases, external services)
+- [ ] Disaster recovery requirements defined
+
+### Architecture Design
+- [ ] Multiple approaches evaluated with trade-offs documented
+- [ ] Architecture diagrams created (topology, data flow, dependencies)
+- [ ] Single points of failure identified and mitigated
+- [ ] Failover and recovery strategies planned
+- [ ] Scalability approach defined (vertical, horizontal, auto-scaling)
+- [ ] Capacity requirements estimated
+
+### Security & Compliance
+- [ ] Security hardening requirements identified
+- [ ] Least-privilege access controls designed
+- [ ] Encryption requirements (at rest, in transit) defined
+- [ ] Secrets management approach chosen
+- [ ] Compliance controls mapped to requirements
+- [ ] Security audit and vulnerability scanning planned
+
+### Observability & Operations
+- [ ] Metrics and logging strategy defined
+- [ ] SLOs and alerting thresholds identified
+- [ ] Dashboards and runbook requirements specified
+- [ ] On-call procedures and escalation paths defined
+- [ ] Incident response procedures documented
+
+### Cost & Optimization
+- [ ] Cost estimation completed
+- [ ] Right-sizing strategy defined
+- [ ] Opportunity for cost optimization identified
+- [ ] Budget monitoring and alerts configured
+
+### Approval
+- [ ] Architecture reviewed and approved by infrastructure team
+- [ ] Security review completed
+- [ ] Application team input incorporated
+- [ ] Compliance team sign-off obtained (if required)
+
+---
+
+## CI/CD Pipeline Checklist
+
+Use when building or updating CI/CD pipelines.
+
+### Requirements & Planning
+- [ ] Current deployment pain points identified
+- [ ] Required pipeline stages defined (build, test, security, deploy)
+- [ ] Target environments documented (dev, staging, production)
+- [ ] Approval gates and required approvals identified
+- [ ] Rollout strategy chosen (blue-green, canary, rolling, feature flags)
+- [ ] Success metrics and SLOs defined
+
+### Build Stage
+- [ ] Source code checkout configured
+- [ ] Dependency management set up
+- [ ] Build script or tool configured (Maven, Gradle, npm, etc.)
+- [ ] Build artifacts versioning strategy defined
+- [ ] Build caching configured (if applicable)
+- [ ] Build notifications configured (on success/failure)
+
+### Test Stage
+- [ ] Unit tests configured to run
+- [ ] Integration tests configured
+- [ ] Test coverage minimum defined
+- [ ] Test result reporting configured
+- [ ] Failing tests block pipeline progression
+
+### Security Scanning
+- [ ] Dependency scanning enabled (Snyk, Dependabot, etc.)
+- [ ] SAST scanning enabled (SonarQube, etc.)
+- [ ] Container scanning enabled (if using containers)
+- [ ] Secrets scanning configured
+- [ ] Scan results reviewed and enforced
+
+### Deployment Stage
+- [ ] Deployment target environments configured
+- [ ] Deployment credentials and secrets secured (not in code)
+- [ ] Blue-green/canary/rolling deployment strategy implemented
+- [ ] Health checks and smoke tests configured
+- [ ] Rollback procedure documented and tested
+- [ ] Deployment notifications configured
+
+### Monitoring & Validation
+- [ ] Post-deployment health checks configured
+- [ ] Monitoring metrics validated after deployment
+- [ ] Automated rollback configured (if thresholds exceeded)
+- [ ] Deployment logs and artifacts retained for troubleshooting
+- [ ] Pipeline execution metrics tracked (build time, success rate)
+
+### Documentation & Training
+- [ ] Pipeline documentation created
+- [ ] Troubleshooting guide written
+- [ ] Team trained on pipeline usage
+- [ ] Runbook for common issues created
+
+---
+
+## Kubernetes Deployment Checklist
+
+Use when deploying applications to Kubernetes.
+
+### Cluster Preparation
+- [ ] Kubernetes cluster provisioned (EKS, GKE, AKS, self-managed)
+- [ ] Node sizing appropriate for workload
+- [ ] Storage classes configured
+- [ ] Ingress controller configured
+- [ ] CNI (networking plugin) selected and configured
+- [ ] RBAC policies configured
+
+### Application Deployment
+- [ ] Container image built and stored in registry
+- [ ] Deployment manifests created (YAML or Helm charts)
+- [ ] Resource limits (CPU, memory) specified
+- [ ] Health checks (liveness, readiness probes) configured
+- [ ] Auto-scaling policies configured
+- [ ] Pod security policies configured
+
+### Networking
+- [ ] Service type chosen (ClusterIP, LoadBalancer, NodePort)
+- [ ] Service DNS names resolvable
+- [ ] Ingress configured for external access
+- [ ] Network policies configured (if required)
+- [ ] Load balancer health checks configured
+
+### Storage
+- [ ] Persistent volume claims created (if needed)
+- [ ] Storage class appropriate for workload
+- [ ] Backup and snapshot procedures documented
+- [ ] Storage access policies configured
+
+### Secrets & Configuration
+- [ ] Secrets managed securely (not in manifests)
+- [ ] ConfigMaps for configuration created
+- [ ] Secret rotation policy defined
+- [ ] Database credentials rotated after deployment
+
+### Monitoring & Logging
+- [ ] Prometheus metrics exposed
+- [ ] Logging to centralized system configured
+- [ ] Application logs accessible
+- [ ] Kubernetes cluster metrics monitored
+- [ ] Alerts configured for critical metrics
+
+### Security
+- [ ] Pod security policies enforced
+- [ ] RBAC policies restrict access
+- [ ] Network policies restrict traffic
+- [ ] Container images scanned for vulnerabilities
+- [ ] Secrets encrypted (at rest and in transit)
+
+### Testing & Validation
+- [ ] Deployment tested in staging cluster
+- [ ] Failover scenario tested
+- [ ] Health checks verified
+- [ ] Monitoring and alerting validated
+- [ ] Rollback procedure tested
+
+---
+
+## Monitoring & Observability Checklist
+
+Use when setting up monitoring, logging, and alerting.
+
+### Metrics Collection
+- [ ] Metrics collection tool selected (Prometheus, CloudWatch, etc.)
+- [ ] Scrape intervals and retention configured
+- [ ] Infrastructure metrics collected (CPU, memory, disk, network)
+- [ ] Application metrics instrumented and collected
+- [ ] Custom business metrics defined and collected
+- [ ] Metric naming conventions documented
+
+### Dashboards
+- [ ] Key dashboards created for operations team
+- [ ] SLO dashboards created for leadership
+- [ ] Problem dashboards created for troubleshooting
+- [ ] Dashboard access controls configured
+- [ ] Thresholds and alerts configured on dashboards
+
+### Alerting
+- [ ] Alert rules defined for critical metrics
+- [ ] Alert thresholds tuned to minimize false positives
+- [ ] Alert routing configured (escalation, on-call)
+- [ ] Alert notifications tested (Slack, PagerDuty, email)
+- [ ] Alert runbooks linked and accessible
+- [ ] Alert acknowledgment and assignment workflows defined
+
+### Logging
+- [ ] Centralized logging configured (ELK, Splunk, CloudLogging)
+- [ ] Log parsing and structuring configured
+- [ ] Log retention policy defined (compliance and cost)
+- [ ] Log indexing for search configured
+- [ ] Sensitive data redaction/masking configured
+- [ ] Application structured logging implemented
+
+### SLOs & Error Budgets
+- [ ] SLOs defined (availability, latency, error rate)
+- [ ] SLI (Service Level Indicator) metrics identified
+- [ ] Error budget calculated
+- [ ] Error budget tracking dashboard created
+- [ ] Burn rate alerts configured
+
+### Tracing & Distributed Tracing (if applicable)
+- [ ] Distributed tracing tool selected (Jaeger, Zipkin, etc.)
+- [ ] Instrumentation libraries integrated
+- [ ] Trace sampling configured
+- [ ] Trace storage configured
+- [ ] Trace querying interface accessible
+
+### Runbooks & Documentation
+- [ ] Runbooks created for common operational tasks
+- [ ] Troubleshooting guides written for common issues
+- [ ] Escalation procedures documented
+- [ ] On-call playbooks created
+- [ ] Dashboard and alert interpretation documented
+
+### Testing & Validation
+- [ ] Metrics verified to be collecting correctly
+- [ ] Alerts tested to confirm they fire appropriately
+- [ ] Logging verified to capture all necessary information
+- [ ] Dashboard data accuracy verified
+- [ ] Runbooks tested and validated
+
+---
+
+## Security Hardening Checklist
+
+Use when implementing security controls or meeting compliance requirements.
+
+### Access Control
+- [ ] IAM roles and policies implemented (least privilege)
+- [ ] Service accounts configured with minimal permissions
+- [ ] User access provisioning process defined
+- [ ] User access review process scheduled
+- [ ] Privileged access management (PAM) configured (if needed)
+- [ ] Multi-factor authentication enabled for sensitive access
+
+### Secrets Management
+- [ ] Secrets management solution configured (Vault, Secrets Manager)
+- [ ] Secrets never stored in code or configuration files
+- [ ] Secret rotation policy implemented
+- [ ] Secret access audit logging enabled
+- [ ] Secrets encrypted at rest
+- [ ] Secrets never logged or exposed in errors
+
+### Network Security
+- [ ] Firewalls and security groups properly configured
+- [ ] Network segmentation implemented (DMZ, internal, database tiers)
+- [ ] Unused ports and services disabled
+- [ ] DDoS protection configured (if needed)
+- [ ] VPN or private links for remote access configured
+- [ ] Network traffic inspection/IDS configured (if needed)
+
+### Encryption
+- [ ] Data encryption at rest configured (database, storage)
+- [ ] Data encryption in transit (TLS/SSL) enforced
+- [ ] Key management configured
+- [ ] Certificate management automated
+- [ ] Weak cipher suites disabled
+
+### Compliance & Audit
+- [ ] Compliance requirements identified and documented
+- [ ] Audit logging configured for sensitive operations
+- [ ] Audit logs stored in tamper-proof location
+- [ ] Audit log retention policy defined
+- [ ] Regular security audit schedule established
+- [ ] Vulnerability scanning configured
+
+### Patching & Updates
+- [ ] OS and system patches applied regularly
+- [ ] Application dependency updates scheduled
+- [ ] Security patch process defined and automated
+- [ ] Emergency patching procedure for critical vulnerabilities
+- [ ] Patch testing in staging before production
+
+### Incident Response
+- [ ] Security incident response plan documented
+- [ ] Incident escalation procedures defined
+- [ ] Security monitoring and alerting configured
+- [ ] Forensic tools and procedures available
+- [ ] Incident communication templates prepared
+
+### Documentation
+- [ ] Security architecture documented
+- [ ] Security policies documented
+- [ ] Incident response procedures documented
+- [ ] Security training material created
+- [ ] Access control matrix maintained
+
+---
+
+## Disaster Recovery Checklist
+
+Use when planning or testing disaster recovery procedures.
+
+### RTO & RPO Definition
+- [ ] RTO (Recovery Time Objective) defined for each critical system
+- [ ] RPO (Recovery Point Objective) defined for each data set
+- [ ] Recovery strategy chosen (backup, failover, multi-region)
+- [ ] Stakeholder communication strategy defined
+
+### Backup Strategy
+- [ ] Backup frequency defined and implemented
+- [ ] Backup retention policy defined
+- [ ] Backup storage location chosen (separate region/provider)
+- [ ] Backup encryption configured
+- [ ] Backup restoration tested and validated
+- [ ] Incremental and full backup strategy defined
+
+### Data Replication
+- [ ] Data replication configured (if using multi-region)
+- [ ] Replication lag monitored
+- [ ] Failover procedures documented
+- [ ] Data consistency validation configured
+
+### Failover Infrastructure
+- [ ] Failover region or backup infrastructure provisioned
+- [ ] DNS failover configured
+- [ ] Application failover procedures tested
+- [ ] Database failover and reconciliation procedures tested
+- [ ] Load balancer failover configured
+
+### Testing & Validation
+- [ ] Disaster recovery drill scheduled (quarterly or annually)
+- [ ] Backup restoration test completed successfully
+- [ ] Failover test completed successfully
+- [ ] Recovery time verified to meet RTO target
+- [ ] Data loss verified to meet RPO target
+- [ ] Post-recovery validation procedures tested
+
+### Documentation
+- [ ] Disaster recovery plan documented
+- [ ] Failover procedures documented
+- [ ] Recovery procedures documented
+- [ ] Critical system dependencies documented
+- [ ] Contact information for key personnel updated
+
+### Monitoring & Alerting
+- [ ] Backup completion monitored and alerted
+- [ ] Replication lag monitored and alerted
+- [ ] Failover system health monitored
+- [ ] Disaster recovery automation tested
+
+---
+
+## Infrastructure Code Review Checklist
+
+Use when reviewing Terraform, CloudFormation, Helm, or other IaC code.
+
+### Correctness
+- [ ] Code implements the intended design
+- [ ] Resources configured correctly for intended purpose
+- [ ] Dependencies between resources properly defined
+- [ ] Output values correctly defined
+- [ ] Destruction procedures tested (no orphaned resources)
+
+### Security
+- [ ] No secrets hardcoded in code
+- [ ] Secrets retrieved from secure management system
+- [ ] IAM policies follow least privilege principle
+- [ ] Security groups/firewall rules appropriately restrictive
+- [ ] Encryption enabled for sensitive data (at rest, in transit)
+- [ ] Audit logging enabled for sensitive operations
+
+### Cost & Optimization
+- [ ] Resource sizes appropriate for expected load
+- [ ] Spot instances or reserved capacity considered
+- [ ] Auto-scaling configured to prevent over-provisioning
+- [ ] Unused resources identified and removed
+- [ ] Cost estimates reviewed
+
+### Maintainability
+- [ ] Code is clear and well-organized
+- [ ] Variable naming is descriptive
+- [ ] Complex logic is documented with comments
+- [ ] DRY principle applied (no duplication)
+- [ ] Modules are reusable and properly abstracted
+- [ ] Version constraints specified for dependencies
+
+### Operability
+- [ ] Monitoring and logging integrated
+- [ ] Health checks configured
+- [ ] Backup procedures configured
+- [ ] Disaster recovery tested
+- [ ] Operational runbooks referenced or included
+
+### Documentation
+- [ ] README explains infrastructure purpose and design
+- [ ] Variable descriptions are clear and complete
+- [ ] Output descriptions are clear
+- [ ] Usage examples provided
+- [ ] Architectural decisions documented
+
+### Testing
+- [ ] Code passes linting and validation
+- [ ] Changes tested in non-production environment first
+- [ ] Infrastructure tested to verify it meets requirements
+- [ ] Rollback procedure tested and documented
+

package/roles/devops/ci-cd/README.md

@@ -0,0 +1,169 @@
+# CI/CD Pipeline Guidance
+
+This folder provides guidance for designing and implementing continuous integration and
+continuous deployment pipelines that enable fast, safe, and repeatable deployments.
+
+## Scope
+
+Use this guidance when:
+
+- Building CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins, CircleCI)
+- Implementing automated testing in pipelines
+- Designing deployment automation and strategies
+- Setting up security scanning in pipelines
+- Configuring artifact management and versioning
+- Implementing deployment approval workflows
+
+## Core Principles
+
+1. **Automation First** – Eliminate manual operations and repetitive tasks.
+2. **Fast Feedback** – Detect issues as early as possible in the pipeline.
+3. **Safe Deployments** – Use staged rollouts and automated validation.
+4. **Auditability** – Track every build, test, and deployment decision.
+5. **Failure Recovery** – Enable quick rollbacks and issue diagnosis.
+
+## Pipeline Stages
+
+### 1. Source Control
+- Code committed to version control (Git)
+- Branch strategy defined (main, develop, feature branches)
+- Commit messages follow convention
+- Code review process enforced before merge
+
+### 2. Build Stage
+- Source code compiled or packaged
+- Dependencies downloaded and verified
+- Build artifacts created and versioned
+- Build failures block downstream stages
+- Build logs retained for troubleshooting
+
+### 3. Test Stage
+- Unit tests run automatically
+- Test results reported and thresholds enforced
+- Test coverage measured and tracked
+- Failed tests block deployment
+
+### 4. Security Scanning
+- Dependency scanning (known vulnerabilities)
+- SAST scanning (static application security testing)
+- Container/artifact scanning (if applicable)
+- Secrets scanning (API keys, passwords, tokens)
+- Security issues block or flag for review
+
+### 5. Artifact Management
+- Build artifacts versioned uniquely
+- Container images tagged with commit/version
+- Artifacts signed for integrity
+- Artifact retention policy enforced
+- Artifact provenance tracked
+
+### 6. Deployment to Staging
+- Automated deployment to staging environment
+- Infrastructure identical to production
+- Health checks and smoke tests run
+- Database migrations applied automatically
+- Deployment process documented
+
+### 7. Validation & Testing
+- Automated smoke tests validate deployment
+- Integration tests run against deployed app
+- Performance tests (if applicable)
+- Security tests (DAST, penetration testing)
+- Failed validations block production deployment
+
+### 8. Approval & Release
+- Manual approval required for production (if policy)
+- Release notes generated automatically
+- Change tickets created
+- Notification sent to stakeholders
+
+### 9. Production Deployment
+- Blue-green or canary deployment strategy
+- Gradual traffic shift (if using canary)
+- Health monitoring during deployment
+- Automatic rollback on failures
+- Deployment completion notification
+
+### 10. Post-Deployment
+- Metrics and logs monitored
+- Error rate tracked
+- Performance validated
+- Incident response procedures ready
+
+## Platform Considerations
+
+### GitHub Actions
+- Built into GitHub, no separate infrastructure
+- Good for GitHub-hosted repositories
+- Workflow files stored in `.github/workflows/`
+- Secrets managed through GitHub settings
+- Supports self-hosted runners for complex workloads
+
+### GitLab CI
+- CI/CD integrated with GitLab platform
+- `.gitlab-ci.yml` pipeline definition
+- Supports on-premise installation
+- Built-in container registry
+- Advanced features (Auto DevOps, Environment-specific deployment)
+
+### Jenkins
+- Self-hosted CI/CD server
+- Highly customizable with plugins
+- Supports complex workflows
+- Requires infrastructure investment
+- Good for complex, non-standard pipelines
+
+### CircleCI
+- Cloud-hosted CI/CD platform
+- YAML-based configuration
+- Free tier available for open source
+- Supports Docker and machine executors
+- Good balance of simplicity and power
+
+## Common Patterns
+
+### Rolling Deployment
+- Gradually replace old instances with new ones
+- Minimal downtime, allows quick rollback
+- Suitable for most applications
+- Requires good health checks
+
+### Blue-Green Deployment
+- Maintain two identical production environments
+- Switch all traffic at once
+- Instant rollback by switching back
+- Requires doubled infrastructure
+- Good for critical applications
+
+### Canary Deployment
+- Deploy to small percentage of instances/users first
+- Monitor metrics and error rates
+- Gradually increase traffic if healthy
+- Automatic rollback if thresholds exceeded
+- Good for high-risk changes
+
+## Related Folders
+
+- `kubernetes/` – Kubernetes-specific deployment considerations
+- `infrastructure-as-code/` – Terraform/Helm for infrastructure provisioning
+- `monitoring/` – Metrics and alerting for deployment validation
+- `security/` – Security scanning in pipelines
+
+## Key Checklist Items
+
+- [ ] Pipeline stages defined and automated
+- [ ] Build failures prevent downstream execution
+- [ ] Tests run automatically and block on failure
+- [ ] Security scanning integrated (dependencies, SAST, secrets)
+- [ ] Deployment strategy chosen (rolling, blue-green, canary)
+- [ ] Rollback procedure documented and tested
+- [ ] Monitoring and alerting configured for deployments
+- [ ] Deployment notifications sent to stakeholders
+- [ ] Pipeline documentation and runbooks created
+- [ ] On-call team trained on pipeline operations
+
+## Files in This Folder
+
+- `README.md` – This file
+- `checklists.md` – Detailed CI/CD implementation checklist
+- `examples.md` – Concrete CI/CD pipeline examples