forgecraft-mcp 1.2.0 → 1.3.2

package/templates/hipaa/instructions.yaml

@@ -1,41 +1,41 @@
-tag: HIPAA
-section: instructions
-blocks:
-  - id: pii-masking
-    tier: recommended
-    title: "PII Masking & Data Protection"
-    content: |
-      ## PII Masking & Data Protection
-
-      - Identify all Personally Identifiable Information (PII) fields at design time using the 18 HIPAA identifiers as a baseline.
-      - Implement masking templates for every PII field: full mask for display, partial mask for verification, tokenized for logging.
-      - Apply dynamic masking based on user role — clinicians see full data, billing sees partial, analytics sees only de-identified data.
-      - Never store raw PII in caches, message queues, or temporary files. Use tokenized references that resolve through a secure lookup service.
-      - Validate masking coverage with automated tests: no PII field should reach a log sink, error report, or analytics pipeline unmasked.
-      - Maintain a PII field registry as a living document — every new field must be classified before it enters the data model.
-
-  - id: encryption-checks
-    tier: recommended
-    title: "Encryption Verification & Key Management"
-    content: |
-      ## Encryption Verification & Key Management
-
-      - Enforce AES-256 encryption at rest for all data stores containing PII. Verify encryption status in CI with infrastructure-as-code checks.
-      - Require TLS 1.2+ for all data in transit. Reject connections using older protocols at the load balancer level.
-      - Use envelope encryption with a managed KMS (AWS KMS, Azure Key Vault, GCP KMS). Never store encryption keys alongside encrypted data.
-      - Rotate encryption keys on a defined schedule (90 days minimum). Automate rotation and re-encryption of affected data.
-      - Include encryption verification in deployment checklists: database encryption enabled, TLS certificates valid, KMS policies correct.
-      - Test encryption boundaries: verify that data crossing service boundaries remains encrypted and that decryption only occurs in authorized services.
-
-  - id: audit-logging-hipaa
-    tier: recommended
-    title: "HIPAA Audit Logging"
-    content: |
-      ## HIPAA Audit Logging
-
-      - Log every access to PII: who, when, what data, from where, and the business justification.
-      - Store audit logs in an append-only, tamper-evident store separate from application databases.
-      - Retain audit logs for a minimum of 6 years per HIPAA requirements.
-      - Generate automated audit reports: access frequency per user, unusual patterns, after-hours access.
-      - Implement real-time alerting for anomalous access: bulk record access, out-of-role access, VIP record access.
-      - Include a unique correlation ID in every request touching PII for end-to-end traceability across services.
+tag: HIPAA
+section: instructions
+blocks:
+  - id: pii-masking
+    tier: recommended
+    title: "PII Masking & Data Protection"
+    content: |
+      ## PII Masking & Data Protection
+
+      - Identify all Personally Identifiable Information (PII) fields at design time using the 18 HIPAA identifiers as a baseline.
+      - Implement masking templates for every PII field: full mask for display, partial mask for verification, tokenized for logging.
+      - Apply dynamic masking based on user role — clinicians see full data, billing sees partial, analytics sees only de-identified data.
+      - Never store raw PII in caches, message queues, or temporary files. Use tokenized references that resolve through a secure lookup service.
+      - Validate masking coverage with automated tests: no PII field should reach a log sink, error report, or analytics pipeline unmasked.
+      - Maintain a PII field registry as a living document — every new field must be classified before it enters the data model.
+
+  - id: encryption-checks
+    tier: recommended
+    title: "Encryption Verification & Key Management"
+    content: |
+      ## Encryption Verification & Key Management
+
+      - Enforce AES-256 encryption at rest for all data stores containing PII. Verify encryption status in CI with infrastructure-as-code checks.
+      - Require TLS 1.2+ for all data in transit. Reject connections using older protocols at the load balancer level.
+      - Use envelope encryption with a managed KMS (AWS KMS, Azure Key Vault, GCP KMS). Never store encryption keys alongside encrypted data.
+      - Rotate encryption keys on a defined schedule (90 days minimum). Automate rotation and re-encryption of affected data.
+      - Include encryption verification in deployment checklists: database encryption enabled, TLS certificates valid, KMS policies correct.
+      - Test encryption boundaries: verify that data crossing service boundaries remains encrypted and that decryption only occurs in authorized services.
+
+  - id: audit-logging-hipaa
+    tier: recommended
+    title: "HIPAA Audit Logging"
+    content: |
+      ## HIPAA Audit Logging
+
+      - Log every access to PII: who, when, what data, from where, and the business justification.
+      - Store audit logs in an append-only, tamper-evident store separate from application databases.
+      - Retain audit logs for a minimum of 6 years per HIPAA requirements.
+      - Generate automated audit reports: access frequency per user, unusual patterns, after-hours access.
+      - Implement real-time alerting for anomalous access: bulk record access, out-of-role access, VIP record access.
+      - Include a unique correlation ID in every request touching PII for end-to-end traceability across services.

package/templates/hipaa/mcp-servers.yaml

@@ -1,13 +1,13 @@
-tag: HIPAA
-section: mcp-servers
-servers:
-  - name: postgres
-    description: "PostgreSQL database inspection and schema management — common backend for PHI/PII storage"
-    command: npx
-    args: ["-y", "@modelcontextprotocol/server-postgres"]
-    tags: [HIPAA, HEALTHCARE, API]
-    category: database
-    tier: recommended
-    env:
-      POSTGRES_CONNECTION_STRING: ""
-    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/postgres"
+tag: HIPAA
+section: mcp-servers
+servers:
+  - name: postgres
+    description: "PostgreSQL database inspection and schema management — common backend for PHI/PII storage"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-postgres"]
+    tags: [HIPAA, HEALTHCARE, API]
+    category: database
+    tier: recommended
+    env:
+      POSTGRES_CONNECTION_STRING: ""
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/postgres"

package/templates/infra/instructions.yaml

@@ -1,104 +1,104 @@
-tag: INFRA
-section: instructions
-blocks:
-  - id: iac-containers
-    tier: recommended
-    title: "Infrastructure as Code & Containers"
-    content: |
-      ## Infrastructure as Code & Container Orchestration
-
-      - Define all infrastructure declaratively using IaC tools (Terraform, Pulumi, CloudFormation, CDK). No manual resource creation—if it's not in code, it doesn't exist.
-      - Version IaC alongside application code. Use separate state files/workspaces per environment (dev, staging, prod) and lock state to prevent concurrent modifications.
-      - Write minimal, single-purpose Dockerfiles. Use multi-stage builds to keep production images small. Pin base image digests (not just tags) for reproducibility.
-      - Run containers as non-root users. Drop all Linux capabilities except those explicitly needed. Use read-only root filesystems where possible.
-      - Use container orchestration (Kubernetes, ECS, Nomad) for production workloads. Define resource requests and limits for every container to prevent noisy-neighbor issues.
-      - Implement health checks (liveness, readiness, startup probes) for every service. The orchestrator should not route traffic to unhealthy instances.
-      - Store environment-specific configuration in environment variables or a secrets manager—never bake secrets or environment config into container images.
-
-  - id: cicd-pipelines
-    tier: recommended
-    title: "CI/CD & Deployment Patterns"
-    content: |
-      ## CI/CD & Deployment
-
-      - Automate the full path from commit to production: lint → test → build → security scan → deploy to staging → integration test → promote to production.
-      - Keep CI pipelines fast (< 10 minutes for the inner loop). Parallelize test suites, cache dependencies aggressively, and use incremental builds.
-      - Use blue-green or canary deployments for zero-downtime releases. Automate rollback by monitoring error rates and latency during the canary window.
-      - Implement GitOps for Kubernetes: declare the desired cluster state in a Git repository and use a reconciliation controller (ArgoCD, Flux) to converge actual state to desired state.
-      - Scan container images for CVEs in CI using tools like Trivy or Grype. Block deployment of images with critical or high-severity vulnerabilities.
-      - Tag every deployment artifact with the git SHA, build number, and timestamp. Maintain a deployment log that records what was deployed, when, by whom, and the rollback procedure.
-
-  - id: observability-secrets
-    tier: recommended
-    title: "Observability & Secrets Management"
-    content: |
-      ## Observability, Monitoring & Secrets
-
-      - Implement the three pillars of observability: structured logs (JSON with correlation IDs), metrics (counters, gauges, histograms via Prometheus/OpenTelemetry), and distributed traces (OpenTelemetry spans).
-      - Define SLIs (error rate, latency p99, availability) and set SLOs (e.g., 99.9% availability, p99 latency < 200ms). Create error budget policies that slow down releases when the budget is exhausted.
-      - Set up actionable alerts: every alert must have a runbook link, clear ownership, and a defined severity level. Eliminate noisy alerts ruthlessly—alert fatigue is a reliability risk.
-      - Use a centralized secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager) for all credentials, API keys, and certificates. Rotate secrets automatically on a schedule.
-      - Never commit secrets to version control. Use pre-commit hooks (e.g., detect-secrets, gitleaks) to block accidental secret commits. Scan git history periodically for leaked secrets.
-      - Follow the 12-factor app methodology: externalize config, treat logs as event streams, maximize dev/prod parity, and design for stateless, disposable processes.
-      - Implement dashboards for each service covering the RED metrics (Rate, Errors, Duration) and the USE metrics (Utilization, Saturation, Errors) for infrastructure resources.
-
-  - id: iac-cdk-patterns
-    tier: recommended
-    title: "CDK, Pulumi & IaC Patterns"
-    content: |
-      ## CDK, Pulumi & Advanced IaC
-
-      ### AWS CDK
-      - Define infrastructure in TypeScript/Python — real programming language, not HCL.
-        Enables loops, conditionals, type checking, and IDE support.
-      - Organize stacks by lifecycle: networking stack, database stack, application stack.
-        Stacks that change together should be in the same stack.
-      - Use L2/L3 Constructs for common patterns (ApplicationLoadBalancedFargateService, etc.).
-        Drop to L1 (CfnResource) only when L2 doesn't expose what you need.
-      - `cdk diff` before every deploy. Review change sets. Never deploy blind.
-      - Use CDK Aspects for compliance: tag enforcement, encryption-at-rest checks, public access blocking.
-
-      ### Pulumi
-      - Same benefits as CDK (real language) but multi-cloud.
-        TypeScript, Python, Go, or C#. Choose the team's strongest language.
-      - Use ComponentResources to create reusable infrastructure modules.
-      - State in Pulumi Cloud or self-managed S3 backend. Lock state to prevent concurrent modifications.
-
-      ### IaC Best Practices (All Tools)
-      - **Modules**: Don't repeat resource definitions. Create reusable modules for VPC, ECS service, RDS cluster, etc.
-      - **Environments**: Same IaC, different configs. Use variables/parameters per environment, not separate code.
-      - **State**: Remote state with locking. Never local state files in production.
-      - **Drift detection**: Run periodic plan/diff against production. Alert on manual changes.
-      - **Cost tagging**: Every resource tagged with `Environment`, `Service`, `Owner`, `CostCenter`.
-        Untagged resources are flagged and blocked in CI.
-      - **Blast radius**: Small, independently deployable stacks. A bad deploy to one stack doesn't affect others.
-
-  - id: cloud-platform-guidance
-    tier: recommended
-    title: "Cloud Platform & Deployment Targets"
-    content: |
-      ## Cloud Platform Guidance
-
-      ### Cloud vs. Local
-      - **Local development**: Docker Compose for all backing services (DB, cache, queue, storage).
-        Use LocalStack or MinIO for cloud service emulation when needed.
-      - **Managed cloud**: Prefer managed services (RDS over self-hosted Postgres, SQS over self-hosted RabbitMQ)
-        unless cost, latency, or compliance requires self-hosted.
-      - **Serverless**: Consider for event-driven, bursty, or low-traffic workloads.
-        Lambda/Cloud Functions: cold start < 1s, function duration < 15 min, stateless.
-        Not suitable for: long-running processes, WebSockets, high-throughput steady-state.
-      - **Edge compute**: Cloudflare Workers, Vercel Edge Functions, Lambda@Edge.
-        Use for: auth, redirects, A/B testing, geo-routing. Keep logic simple and fast.
-
-      ### Multi-Cloud Considerations
-      - **Default**: single cloud provider. Multi-cloud adds operational complexity.
-      - **When to go multi-cloud**: regulatory requirements, vendor negotiation leverage, or
-        specific best-of-breed services (e.g., GCP for ML, AWS for general infra).
-      - Abstract cloud-specific APIs behind interfaces if multi-cloud is a real possibility.
-      - Use provider-agnostic services where cost-effective: Terraform, Pulumi, containers, S3-compatible storage.
-
-      ### Cost Control
-      - Set budget alerts at 50%, 80%, 100% of monthly target.
-      - Reserved instances / savings plans for steady-state workloads. Spot/preemptible for batch jobs.
-      - Right-size: review instance utilization monthly. Downsize over-provisioned resources.
-      - Auto-sleep non-production environments outside business hours.
+tag: INFRA
+section: instructions
+blocks:
+  - id: iac-containers
+    tier: recommended
+    title: "Infrastructure as Code & Containers"
+    content: |
+      ## Infrastructure as Code & Container Orchestration
+
+      - Define all infrastructure declaratively using IaC tools (Terraform, Pulumi, CloudFormation, CDK). No manual resource creation—if it's not in code, it doesn't exist.
+      - Version IaC alongside application code. Use separate state files/workspaces per environment (dev, staging, prod) and lock state to prevent concurrent modifications.
+      - Write minimal, single-purpose Dockerfiles. Use multi-stage builds to keep production images small. Pin base image digests (not just tags) for reproducibility.
+      - Run containers as non-root users. Drop all Linux capabilities except those explicitly needed. Use read-only root filesystems where possible.
+      - Use container orchestration (Kubernetes, ECS, Nomad) for production workloads. Define resource requests and limits for every container to prevent noisy-neighbor issues.
+      - Implement health checks (liveness, readiness, startup probes) for every service. The orchestrator should not route traffic to unhealthy instances.
+      - Store environment-specific configuration in environment variables or a secrets manager—never bake secrets or environment config into container images.
+
+  - id: cicd-pipelines
+    tier: recommended
+    title: "CI/CD & Deployment Patterns"
+    content: |
+      ## CI/CD & Deployment
+
+      - Automate the full path from commit to production: lint → test → build → security scan → deploy to staging → integration test → promote to production.
+      - Keep CI pipelines fast (< 10 minutes for the inner loop). Parallelize test suites, cache dependencies aggressively, and use incremental builds.
+      - Use blue-green or canary deployments for zero-downtime releases. Automate rollback by monitoring error rates and latency during the canary window.
+      - Implement GitOps for Kubernetes: declare the desired cluster state in a Git repository and use a reconciliation controller (ArgoCD, Flux) to converge actual state to desired state.
+      - Scan container images for CVEs in CI using tools like Trivy or Grype. Block deployment of images with critical or high-severity vulnerabilities.
+      - Tag every deployment artifact with the git SHA, build number, and timestamp. Maintain a deployment log that records what was deployed, when, by whom, and the rollback procedure.
+
+  - id: observability-secrets
+    tier: recommended
+    title: "Observability & Secrets Management"
+    content: |
+      ## Observability, Monitoring & Secrets
+
+      - Implement the three pillars of observability: structured logs (JSON with correlation IDs), metrics (counters, gauges, histograms via Prometheus/OpenTelemetry), and distributed traces (OpenTelemetry spans).
+      - Define SLIs (error rate, latency p99, availability) and set SLOs (e.g., 99.9% availability, p99 latency < 200ms). Create error budget policies that slow down releases when the budget is exhausted.
+      - Set up actionable alerts: every alert must have a runbook link, clear ownership, and a defined severity level. Eliminate noisy alerts ruthlessly—alert fatigue is a reliability risk.
+      - Use a centralized secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager) for all credentials, API keys, and certificates. Rotate secrets automatically on a schedule.
+      - Never commit secrets to version control. Use pre-commit hooks (e.g., detect-secrets, gitleaks) to block accidental secret commits. Scan git history periodically for leaked secrets.
+      - Follow the 12-factor app methodology: externalize config, treat logs as event streams, maximize dev/prod parity, and design for stateless, disposable processes.
+      - Implement dashboards for each service covering the RED metrics (Rate, Errors, Duration) and the USE metrics (Utilization, Saturation, Errors) for infrastructure resources.
+
+  - id: iac-cdk-patterns
+    tier: recommended
+    title: "CDK, Pulumi & IaC Patterns"
+    content: |
+      ## CDK, Pulumi & Advanced IaC
+
+      ### AWS CDK
+      - Define infrastructure in TypeScript/Python — real programming language, not HCL.
+        Enables loops, conditionals, type checking, and IDE support.
+      - Organize stacks by lifecycle: networking stack, database stack, application stack.
+        Stacks that change together should be in the same stack.
+      - Use L2/L3 Constructs for common patterns (ApplicationLoadBalancedFargateService, etc.).
+        Drop to L1 (CfnResource) only when L2 doesn't expose what you need.
+      - `cdk diff` before every deploy. Review change sets. Never deploy blind.
+      - Use CDK Aspects for compliance: tag enforcement, encryption-at-rest checks, public access blocking.
+
+      ### Pulumi
+      - Same benefits as CDK (real language) but multi-cloud.
+        TypeScript, Python, Go, or C#. Choose the team's strongest language.
+      - Use ComponentResources to create reusable infrastructure modules.
+      - State in Pulumi Cloud or self-managed S3 backend. Lock state to prevent concurrent modifications.
+
+      ### IaC Best Practices (All Tools)
+      - **Modules**: Don't repeat resource definitions. Create reusable modules for VPC, ECS service, RDS cluster, etc.
+      - **Environments**: Same IaC, different configs. Use variables/parameters per environment, not separate code.
+      - **State**: Remote state with locking. Never local state files in production.
+      - **Drift detection**: Run periodic plan/diff against production. Alert on manual changes.
+      - **Cost tagging**: Every resource tagged with `Environment`, `Service`, `Owner`, `CostCenter`.
+        Untagged resources are flagged and blocked in CI.
+      - **Blast radius**: Small, independently deployable stacks. A bad deploy to one stack doesn't affect others.
+
+  - id: cloud-platform-guidance
+    tier: recommended
+    title: "Cloud Platform & Deployment Targets"
+    content: |
+      ## Cloud Platform Guidance
+
+      ### Cloud vs. Local
+      - **Local development**: Docker Compose for all backing services (DB, cache, queue, storage).
+        Use LocalStack or MinIO for cloud service emulation when needed.
+      - **Managed cloud**: Prefer managed services (RDS over self-hosted Postgres, SQS over self-hosted RabbitMQ)
+        unless cost, latency, or compliance requires self-hosted.
+      - **Serverless**: Consider for event-driven, bursty, or low-traffic workloads.
+        Lambda/Cloud Functions: cold start < 1s, function duration < 15 min, stateless.
+        Not suitable for: long-running processes, WebSockets, high-throughput steady-state.
+      - **Edge compute**: Cloudflare Workers, Vercel Edge Functions, Lambda@Edge.
+        Use for: auth, redirects, A/B testing, geo-routing. Keep logic simple and fast.
+
+      ### Multi-Cloud Considerations
+      - **Default**: single cloud provider. Multi-cloud adds operational complexity.
+      - **When to go multi-cloud**: regulatory requirements, vendor negotiation leverage, or
+        specific best-of-breed services (e.g., GCP for ML, AWS for general infra).
+      - Abstract cloud-specific APIs behind interfaces if multi-cloud is a real possibility.
+      - Use provider-agnostic services where cost-effective: Terraform, Pulumi, containers, S3-compatible storage.
+
+      ### Cost Control
+      - Set budget alerts at 50%, 80%, 100% of monthly target.
+      - Reserved instances / savings plans for steady-state workloads. Spot/preemptible for batch jobs.
+      - Right-size: review instance utilization monthly. Downsize over-provisioned resources.
+      - Auto-sleep non-production environments outside business hours.

package/templates/infra/mcp-servers.yaml

@@ -1,20 +1,20 @@
-tag: INFRA
-section: mcp-servers
-servers:
-  - name: docker
-    description: "Docker container and image management via MCP"
-    command: npx
-    args: ["-y", "mcp-server-docker"]
-    tags: [INFRA]
-    category: deployment
-    tier: recommended
-    url: "https://github.com/ckreiling/mcp-server-docker"
-
-  - name: kubernetes
-    description: "Kubernetes cluster management — pods, deployments, services"
-    command: npx
-    args: ["-y", "mcp-server-kubernetes"]
-    tags: [INFRA]
-    category: deployment
-    tier: optional
-    url: "https://github.com/strowk/mcp-k8s-go"
+tag: INFRA
+section: mcp-servers
+servers:
+  - name: docker
+    description: "Docker container and image management via MCP"
+    command: npx
+    args: ["-y", "mcp-server-docker"]
+    tags: [INFRA]
+    category: deployment
+    tier: recommended
+    url: "https://github.com/ckreiling/mcp-server-docker"
+
+  - name: kubernetes
+    description: "Kubernetes cluster management — pods, deployments, services"
+    command: npx
+    args: ["-y", "mcp-server-kubernetes"]
+    tags: [INFRA]
+    category: deployment
+    tier: optional
+    url: "https://github.com/strowk/mcp-k8s-go"

package/templates/infra/nfr.yaml

@@ -1,46 +1,46 @@
-tag: INFRA
-section: nfr
-blocks:
-  - id: infra-reliability
-    tier: recommended
-    title: "Infrastructure Reliability"
-    content: |
-      ## NFR: Infrastructure Reliability
-
-      ### Availability
-      - Target uptime for infrastructure platform: {{infra_uptime | default: 99.95%}}.
-      - Multi-AZ deployment for all production workloads. Single-AZ acceptable for dev/staging.
-      - Automated failover tested quarterly. Document actual recovery time.
-
-      ### Change Management
-      - All infrastructure changes go through code review (IaC PR).
-      - Plan/diff output reviewed before apply. No blind applies.
-      - Rollback procedure documented and tested for every change type.
-      - Change windows for breaking changes. Emergency changes require post-mortem.
-
-      ### Drift Detection
-      - Scheduled drift detection (weekly minimum). Alert on any manual changes.
-      - Drift remediation: either update code to match reality or re-apply to match code.
-      - No resources outside IaC management in production.
-
-  - id: infra-security
-    tier: recommended
-    title: "Infrastructure Security"
-    content: |
-      ## NFR: Infrastructure Security
-
-      ### Network
-      - Least-privilege security groups / firewall rules. No 0.0.0.0/0 ingress except load balancers.
-      - Private subnets for application and database tiers. Public subnets only for load balancers.
-      - VPC flow logs enabled. Anomaly detection on network patterns.
-
-      ### Access Control
-      - IAM roles with minimum required permissions. No wildcard (*) actions on production resources.
-      - MFA required for all human access to cloud consoles and CI/CD pipelines.
-      - Service-to-service auth via IAM roles or mTLS, not shared API keys.
-      - Access reviewed quarterly. Revoke unused permissions.
-
-      ### Secrets
-      - All secrets in a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager).
-      - Secrets rotated on schedule (90 days max). Auto-rotation preferred.
-      - Pre-commit hooks block secret commits (gitleaks, detect-secrets).
+tag: INFRA
+section: nfr
+blocks:
+  - id: infra-reliability
+    tier: recommended
+    title: "Infrastructure Reliability"
+    content: |
+      ## NFR: Infrastructure Reliability
+
+      ### Availability
+      - Target uptime for infrastructure platform: {{infra_uptime | default: 99.95%}}.
+      - Multi-AZ deployment for all production workloads. Single-AZ acceptable for dev/staging.
+      - Automated failover tested quarterly. Document actual recovery time.
+
+      ### Change Management
+      - All infrastructure changes go through code review (IaC PR).
+      - Plan/diff output reviewed before apply. No blind applies.
+      - Rollback procedure documented and tested for every change type.
+      - Change windows for breaking changes. Emergency changes require post-mortem.
+
+      ### Drift Detection
+      - Scheduled drift detection (weekly minimum). Alert on any manual changes.
+      - Drift remediation: either update code to match reality or re-apply to match code.
+      - No resources outside IaC management in production.
+
+  - id: infra-security
+    tier: recommended
+    title: "Infrastructure Security"
+    content: |
+      ## NFR: Infrastructure Security
+
+      ### Network
+      - Least-privilege security groups / firewall rules. No 0.0.0.0/0 ingress except load balancers.
+      - Private subnets for application and database tiers. Public subnets only for load balancers.
+      - VPC flow logs enabled. Anomaly detection on network patterns.
+
+      ### Access Control
+      - IAM roles with minimum required permissions. No wildcard (*) actions on production resources.
+      - MFA required for all human access to cloud consoles and CI/CD pipelines.
+      - Service-to-service auth via IAM roles or mTLS, not shared API keys.
+      - Access reviewed quarterly. Revoke unused permissions.
+
+      ### Secrets
+      - All secrets in a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager).
+      - Secrets rotated on schedule (90 days max). Auto-rotation preferred.
+      - Pre-commit hooks block secret commits (gitleaks, detect-secrets).

package/templates/infra/review.yaml

@@ -1,65 +1,65 @@
-tag: INFRA
-section: review
-blocks:
-  - id: infra-architecture-review
-    tier: recommended
-    dimension: architecture
-    title: "Infrastructure Architecture Review"
-    description: |
-      Evaluate IaC patterns, resource organization, and environment management.
-    checklist:
-      - id: iac-all-resources
-        description: "All production resources defined in IaC. No manually created resources."
-        severity: critical
-      - id: module-reuse
-        description: "Common patterns (VPC, database, service) extracted into reusable modules, not copy-pasted."
-        severity: important
-      - id: environment-isolation
-        description: "Environments fully isolated: separate state files, separate accounts/projects where possible."
-        severity: critical
-      - id: blast-radius
-        description: "Stacks/modules scoped to limit blast radius. A bad deploy to one stack doesn't affect others."
-        severity: important
-
-  - id: infra-security-review
-    tier: recommended
-    dimension: code-quality
-    title: "Infrastructure Security Review"
-    description: |
-      Evaluate network security, access control, and secrets management.
-    checklist:
-      - id: least-privilege
-        description: "IAM roles use minimum required permissions. No wildcard actions on production."
-        severity: critical
-      - id: no-public-exposure
-        description: "Databases and application servers in private subnets. Only load balancers are publicly accessible."
-        severity: critical
-      - id: secrets-managed
-        description: "All secrets in a secrets manager with rotation. No hardcoded credentials in IaC files."
-        severity: critical
-      - id: encryption-at-rest
-        description: "Storage volumes, databases, and backups encrypted at rest. KMS keys managed per environment."
-        severity: important
-
-  - id: infra-ops-review
-    tier: recommended
-    dimension: performance
-    title: "Infrastructure Operations Review"
-    description: |
-      Evaluate monitoring, cost management, and operational readiness.
-    checklist:
-      - id: resource-limits
-        description: "CPU and memory limits defined for all containers. No unbounded resource consumption."
-        severity: critical
-      - id: auto-scaling
-        description: "Auto-scaling configured with sensible min/max. Tested under load."
-        severity: important
-      - id: cost-tagging
-        description: "Every resource tagged with Environment, Service, Owner. Untagged resources flagged in CI."
-        severity: important
-      - id: monitoring-alerting
-        description: "Dashboards and alerts for all services. Every alert has a runbook link and clear ownership."
-        severity: important
-      - id: backup-tested
-        description: "Backup and restore procedures tested. RPO/RTO validated against targets."
-        severity: critical
+tag: INFRA
+section: review
+blocks:
+  - id: infra-architecture-review
+    tier: recommended
+    dimension: architecture
+    title: "Infrastructure Architecture Review"
+    description: |
+      Evaluate IaC patterns, resource organization, and environment management.
+    checklist:
+      - id: iac-all-resources
+        description: "All production resources defined in IaC. No manually created resources."
+        severity: critical
+      - id: module-reuse
+        description: "Common patterns (VPC, database, service) extracted into reusable modules, not copy-pasted."
+        severity: important
+      - id: environment-isolation
+        description: "Environments fully isolated: separate state files, separate accounts/projects where possible."
+        severity: critical
+      - id: blast-radius
+        description: "Stacks/modules scoped to limit blast radius. A bad deploy to one stack doesn't affect others."
+        severity: important
+
+  - id: infra-security-review
+    tier: recommended
+    dimension: code-quality
+    title: "Infrastructure Security Review"
+    description: |
+      Evaluate network security, access control, and secrets management.
+    checklist:
+      - id: least-privilege
+        description: "IAM roles use minimum required permissions. No wildcard actions on production."
+        severity: critical
+      - id: no-public-exposure
+        description: "Databases and application servers in private subnets. Only load balancers are publicly accessible."
+        severity: critical
+      - id: secrets-managed
+        description: "All secrets in a secrets manager with rotation. No hardcoded credentials in IaC files."
+        severity: critical
+      - id: encryption-at-rest
+        description: "Storage volumes, databases, and backups encrypted at rest. KMS keys managed per environment."
+        severity: important
+
+  - id: infra-ops-review
+    tier: recommended
+    dimension: performance
+    title: "Infrastructure Operations Review"
+    description: |
+      Evaluate monitoring, cost management, and operational readiness.
+    checklist:
+      - id: resource-limits
+        description: "CPU and memory limits defined for all containers. No unbounded resource consumption."
+        severity: critical
+      - id: auto-scaling
+        description: "Auto-scaling configured with sensible min/max. Tested under load."
+        severity: important
+      - id: cost-tagging
+        description: "Every resource tagged with Environment, Service, Owner. Untagged resources flagged in CI."
+        severity: important
+      - id: monitoring-alerting
+        description: "Dashboards and alerts for all services. Every alert has a runbook link and clear ownership."
+        severity: important
+      - id: backup-tested
+        description: "Backup and restore procedures tested. RPO/RTO validated against targets."
+        severity: critical