AI SDLC Standards: cross-cutting requirements mono repo

- Security: input validation, SQL injection, auth annotations, secrets, CVE checks
- Architecture: API contract first, service boundaries, breaking change protocol
- DevOps: health checks, structured logging, resource limits, rollback safety
- Cost: resource tagging, auto-scaling limits, storage lifecycle
- Deterministic compliance checker (.tests/check.sh)
- Agent skill for context injection (Cursor, OpenSpec, Claude Code examples)
- Demo with intentional violations
This commit is contained in:
Max Mayfield
2026-03-07 07:31:16 +00:00
commit a7728c6266
14 changed files with 476 additions and 0 deletions

1
devops/OWNERS Normal file
View File

@@ -0,0 +1 @@
@devops-team

36
devops/requirements.md Normal file
View File

@@ -0,0 +1,36 @@
# DevOps Requirements
Phase: deployment
Enforcement: informational (graduating to blocking Q3 2026)
## OPS-001: Health Check Endpoint
Every deployable service MUST expose a `/health` or `/actuator/health` endpoint that returns 200 when healthy.
**Rule:** New services must include a health check. Existing services adding deployment config must verify health endpoint exists.
**Test:** Check that service has a health endpoint registered (grep for health route registration).
## OPS-002: Structured Logging
All log statements MUST use structured logging (JSON format) with at minimum: timestamp, level, service name, correlation ID.
**Rule:** No `System.out.println`, `console.log` for production logging. Use the logging framework with structured output.
**Test:** Grep for `System.out.print`, `System.err.print`, raw `console.log` in non-test source files.
## OPS-003: Resource Limits
All Kubernetes deployment manifests MUST specify CPU and memory requests and limits.
**Rule:** No unbounded resource consumption. Every container spec must have `resources.requests` and `resources.limits`.
**Test:** Parse YAML deployment files, verify `resources` block present with both `requests` and `limits`.
## OPS-004: Rollback Safety
Database migrations MUST be backward-compatible with the previous service version (N-1 compatibility).
**Rule:** No column renames or drops without a multi-step migration. Additive changes only in a single release.
**Test:** Scan migration SQL for `DROP COLUMN`, `RENAME COLUMN`, `ALTER TYPE` — flag for manual review.