feat: add DevOps IaC pack

[ZzZueszZ]

Summary / Context

Adds pack-devops-iac v0.1 for Terraform/OpenTofu dependency safety, Kubernetes workload readiness, CI/CD plan gates, environment promotion, drift ownership, and rollback readiness.

The pack includes the full manifest/docs/retrieval/prompt structure, seven narrow Layer-1 validators, ten common pitfalls, focused positive/negative tests, catalog registration, and regenerated release metadata.

Problem & Why

Infrastructure changes need context beyond generic backend and security guidance. The existing roadmap called out pack-devops-iac, but no pack encoded deterministic infrastructure change and deployment safety rules.

The implementation keeps security, performance, and database responsibilities in their existing packs. Higher-judgment concerns such as blast radius, artifact promotion, and drift ownership remain Layer-2 self-checks instead of unreliable regex gates.

Test Notes

• python scripts/test_lint_wiki.py
• python scripts/test_atomic_write.py
• python scripts/test_detect_repetition.py
• python scripts/lint-wiki.py --all-workspaces --wiki-root .
• python scripts/test_contextd_runtime.py (34 passed)
• python scripts/test_pack_devops_iac.py
• python scripts/cli.py pack-validate --all --format text (15 packs, 0 errors, 0 warnings)

Related Issues

No linked issue; implements the pack-devops-iac item listed in the pack roadmap.

Docs / Workflow Impact

• Updated docs because behavior/workflow changed
• No docs update needed

Adds an opt-in pack only. Existing workspaces are unchanged until they enable pack-devops-iac.

Wiki-specific checks

• Preserved workspace isolation
• No cross-workspace knowledge mixing
• Avoided duplicate docs/patterns

Project Spirit Check

• Change reinforces knowledge-first workflow (contracts/patterns before invention)
• Contributor experience stays simple and practical (no unnecessary complexity)
• Project voice and intent remain consistent across docs/workflows
• Trade-offs are documented in the pack heuristic limitations and validator catalog

[philngt]

Thanks for the contribution — the pack structure, documentation, Layer-1/Layer-2 separation, and test integration are well designed.

Before merging, I think the Layer-1 validators need to address a few false-negative cases that currently allow changes violating the documented constraints to pass:

1. Terraform apply does not have to consume the reviewed plan.
   The validator accepts a workflow whenever any terraform plan command exists in the file. For example, terraform plan followed by terraform apply -auto-approve passes even though apply generates and executes a new plan. A plan in an unrelated job or environment also suppresses the violation. Each apply should consume an identifiable saved plan, or uncertain cases should remain warnings.

2. Kubernetes readiness and resource requests are checked at file level rather than per container.
   If one container—or one workload in a multi-document YAML file—has a readinessProbe or requests, other containers/workloads missing them are not reported. These checks should be scoped per YAML document, workload, and container.

3. The “immutable” checks accept mutable references.
   Terraform refs such as ?ref=develop or ?ref=feature/foo pass as immutable. Kubernetes images such as api:stable, api:v1.2.3, or an untagged image also pass, although tags can be moved. Either enforce commit SHAs/image digests, or rename and document these rules as narrower “non-floating reference” heuristics.

Please also add regression tests for these cases, especially:

• plan present but apply does not consume the plan file;
• unrelated plan/apply jobs;
• multi-container and multi-document Kubernetes YAML;
• Git branch refs versus commit SHA;
• untagged, stable-tagged, and digest-pinned images.

The overall direction looks good. Once these validator semantics match the documented guarantees, this should be ready to merge.

[philngt]

Thanks for the update. The previous findings have been addressed well: apply commands are now checked independently, Kubernetes checks are scoped per document and container, immutable references are enforced consistently, and the requested regression cases have been added.

I found one remaining false-negative case before approval:

Container detection depends on the first key being name or image

CONTAINER_ITEM currently recognizes a container only when its list item starts with name or image:

CONTAINER_ITEM = re.compile(r"^(\s*)-\s+(?:name|image)\s*:")

YAML key order is not significant, so this is valid:

containers:
  - securityContext:
      runAsNonRoot: true
    name: api
    image: registry.example/api:latest

This container is skipped entirely, allowing it to bypass the image digest, readiness probe, and resource request validators.

Please detect every direct list item under containers: by indentation, regardless of its first key, and add a regression test where securityContext or another field appears before name.

Non-blocking suggestion: _apply_consumes_saved_plan may treat shell redirection tokens as positional plan arguments—for example, terraform apply > apply.log—and multiline apply commands may produce false positives. It would be useful to add redirection and multiline cases to the CI parser tests, either in this PR or a follow-up.

Once the container detection case is fixed, this looks ready to approve.