# ACDL v1.11 — Multi-Persona Code Review (P60–P65 retrofit + new work)

**Reviewer:** ci-code-reviewer (model: glm-5.2)
**Scope:** v1.11 milestone, branch `milestone/v1.11-restart` — 22 commits
(e1bb214..8c09580), 25 files, +790/-142 lines
**Date:** 2026-07-29

## Commits reviewed

| Commit | Phase | Type | Summary |
|--------|-------|------|---------|
| e1bb214 | 60 | docs | retrofit plan — L1 lifecycle pipeline live-run |
| bc9058f | 60 | feat | L1 module lifecycle live run — module fixes (retrofit) |
| bb3ac7c | 60 | fix | WAF scope case + VPC modify DependencyViolation |
| 0c5c4d1 | 61 | docs | create phase plan — L2 lifecycle pipeline author |
| 361fe60 | 61 | feat | L2 lifecycle pipeline — extend matrix + workflows + tests |
| 9ac5720 | 61 | verify | 4-layer gate — PASS |
| 6441633 | 62 | docs | create phase plan — L2 lifecycle pipeline live run |
| 4dad967 | 60 | fix | ALB target group name_prefix — avoid orphaned conflicts |
| adfcf86 | 63 | docs | create phase plan — regression registry + cost docs |
| b71e63c | 63 | feat | CAP-017..022 regression registry + COST.md |
| beac2ef | 63 | verify | 4-layer gate — PASS |
| 06f4fc7 | 60 | fix | free disk space in lifecycle jobs |
| 92bb03e | 64 | docs | create phase plan — pre-mortem + teardown |
| 186cdde | 64 | feat | pre-mortem — v1.10 post-mortem + forward pre-mortem |
| 4102950 | 64 | feat | pre-mortem + teardown plan — HITL escalation CHG0680001 |
| 7c4fc1f | 64 | feat | teardown complete — zero live ACDL resources remain |
| a52f8a5 | 64 | verify | 4-layer gate — PASS |
| a03c019 | 60/62 | fix | ALB name_prefix + adapter dedup + L2 composition wiring |
| 93a6598 | 65 | docs | create phase plan — rewrite caps + decks |
| 6394801 | 65 | feat | rewrite caps — CAP-017..022 Verified via lifecycle pipeline |
| fc91f24 | 65 | verify | 4-layer gate — PASS |
| 8c09580 | 65 | docs | update v1.11 status — all phases complete |

## P0 issues (0)

No blocking issues found. The targeted fixes are correct for their stated
purposes. The 447 fast offline tests pass (485/490 collected; 5 slow
deselected, including 2 slow regression-integration tests that exercise the
CAPABILITY_REGISTRY against the live codebase).

## P1 issues (5 — should fix)

### P1-1: Adapter dedup silently drops resources whose module is not in the registry
[correctness] `adapters/terraform/adapter.py:159-170`

The new dedup loop only adds resources to `seen` when `tf_dir` is truthy
(in the registry). A resource whose module is missing from the registry is
**silently dropped** from `merged` — it never reaches `_emit_module_block`,
so no error is raised. The pre-dedup code (`parts.extend(... for r in
resources)`) would have raised `ValueError("no terraform_dir in registry
for module ...")` via `_emit_module_block`, surfacing the misconfiguration.

Confirmed by simulation: two resources, one with `module: nonexistent@1.0.0`,
produces a `merged` list of length 1 — the unknown-module resource vanishes
without diagnostic.

**Recommendation:** in the dedup loop, when `tf_dir` is `None`, either
(a) raise immediately (preserving the prior contract), or (b) append the
resource to a separate `unknown` list and extend `parts` with it so
`_emit_module_block` raises the descriptive error. As written, a typo in
a composition's `module` field (e.g. `iam-role@1.0.0` vs `iam_roles@1.0.0`)
will silently omit a resource from the emitted terraform — a class of
defect the v1.10 sweep was specifically created to catch.

### P1-2: L2 static-assets "modify" example is a no-op — complex ≡ simple
[correctness] `modules/l2/static-assets/examples/complex.yml`,
`modules/l2/static-assets/composition.json`

The complex.yml comment claims "Modify variant: same bucket_name as simple
(in-place modify, adds CDN + WAF)". But resolving both examples yields
**identical** resource sets: `['s3','cloudfront-distribution',
'cloudfront-originaccesscontrol','waf','kms']`. The CDN and WAF are
**always present** in the static-assets composition (they are unconditional
children + wires); the `waf_enabled`, `default_ttl`, `max_ttl`,
`price_class`, `viewer_protocol_policy` inputs in complex.yml have **no
corresponding wires** in composition.json and are silently dropped at
resolve time. So the L2 static-assets lifecycle cell's "modify" step
applies a contract that produces the same terraform as "simple" — it
exercises `terraform apply` twice with no change, not a true modify.

This is not a regression (the inputs were never wired), but the
CAPABILITY_INVENTORY claim "CAP-020 Verified live-aws via L2 static-assets
lifecycle pipeline (apply/modify/destroy exit 0)" overstates what the
modify step proves: it proves idempotent re-apply, not in-place modify.

**Recommendation:** either (a) wire `waf_enabled`/`default_ttl`/etc. in
composition.json so the complex contract genuinely differs, or (b) correct
the comment + CAPABILITY_INVENTORY wording to "apply + idempotent re-apply
+ destroy" rather than "apply/modify/destroy". The microservice complex
example, by contrast, is a real modify (desired_count 1→2) — that one is
fine.

### P1-3: L2 lifecycle scripts ignore the ci-vpc-outputs.json argument
[correctness] `scripts/run_l2_lifecycle_test.sh:14`,
`scripts/run_l2_lifecycle_destroy.sh:12`

Both L2 scripts declare `Usage: ... <module> <example> [ci-vpc-outputs.json]`
but neither reads `$3`/`$2`. The microservice composition references the
platform VPC via `terraform_remote_state` (data source), and the script
sets `ACDL_REMOTE_STATE_KEY=spike/ci-vpc/terraform.tfstate` so the data
source reads from the CI VPC state — that part is correct. But the
`ci-vpc-outputs.json` argument is positional noise: the workflow passes
it (`run_l2_lifecycle_test.sh ${{ matrix.module }} simple
/tmp/ci-vpc-outputs.json`) and it is silently ignored. The L1 scripts
(`run_lifecycle_test.sh`) inject VPC outputs by rewriting the contract in
Python; the L2 path takes a different approach (remote state) and does not
need the file, so the argument is vestigial, not a bug — but the usage
string advertises a feature the script does not provide, which will
confuse a future maintainer who assumes parity with the L1 scripts.

**Recommendation:** remove the `[ci-vpc-outputs.json]` token from the
usage strings (or add a comment explaining the L2 path uses remote state
and the arg is accepted-but-ignored for workflow-argument parity).

### P1-4: CAPABILITY_INVENTORY summary table is stale (says 16, body lists 22)
[maintainability] `.ciagent/CAPABILITY_INVENTORY.md:9-16`

The Summary table still reads "Verified 16 / Decayed 0 / Broken 0 / Total
16" — the v1.10 sweep count. The body (lines 93-110) now lists CAP-017..022
as **Verified** via the lifecycle pipeline, bringing the real total to 22.
The two counts disagree: a reader scanning the summary sees 16 Verified; a
reader scanning the inventory body sees 22 Verified. The PRE_MORTEM
(lines 82-83) and CAPABILITY_INVENTORY prose both assert all 22 are
Verified, but the headline table was not updated in the P65 rewrite.

**Recommendation:** update the Summary table to "Verified 22 / Decayed 0
/ Broken 0 / Total 22" and add CAP-017..022 rows to the Inventory table
(the body section "Cloud capabilities NOT re-verified..." is now
mis-titled — they ARE verified, just via the lifecycle-pipeline tier).

### P1-5: CAP-017..022 regression checks are offline proxies, not pipeline evidence
[adversarial] `core/regression_verify.py:432-519`,
`.ciagent/CAPABILITY_INVENTORY.md:93-110`

The CAP-017..022 checks (`_check_cap_017_dynamodb` etc.) call
`_check_lifecycle_module_terraform` / `_check_lifecycle_l2_module`, which
verify only that (a) the terraform dir + required files exist and (b) the
example contracts **resolve** (resolver exit 0). They do **not** run
`terraform validate`, do not run apply/modify/destroy, and do not query
the pipeline's actual green/red status. The CAPABILITY_INVENTORY claims
"Evidence = L1 rds module lifecycle pipeline green (terraform validate +
contracts resolve)" — but the check does not run terraform validate, and
"lifecycle pipeline green" is asserted, not verified by the regression
gate.

This means the lifecycle-pipeline evidence CAN be faked at the regression
tier: a module whose terraform is syntactically broken (e.g.
`scope = upper(var.scope)` removed, or a missing required variable) would
still pass `_check_lifecycle_module_terraform` as long as the files exist
and the resolver runs. The real green/red evidence lives only in the
workflow run history (Gitea/GitHub Actions), which the regression gate does
not read.

**Mitigation context:** the modules-lifecycle workflow IS the live
evidence — when it runs on a PR, the cells genuinely apply/modify/destroy
against live AWS. The gap is that the *regression gate* (which gates
milestone COMPLETE) trusts the workflow will be run, rather than proving it
was run and passed. A milestone could in principle be marked COMPLETE with
CAP-017..022 "Verified" if the regression gate runs but the workflow was
never executed (e.g. workflow_dispatch never triggered, or the PR was
merged without the workflow running).

**Recommendation:** (a) tighten the CAP-017..022 check docstrings + the
CAPABILITY_INVENTORY wording to "terraform files present + contracts
resolve (offline proxy; live apply/modify/destroy verified by the
modules-lifecycle workflow run, not by this gate)"; and/or (b) add a
`terraform validate` step to `_check_lifecycle_module_terraform` (slow but
cheap relative to init+apply) so at least HCL syntax is verified at the
gate. The teardown trustworthiness (P64) is good — `ci-vpc-destroy` runs
`if: always()` and the decommission `---ci---` block is the audit trail.

## P2 issues (4 — post-hoc)

### P2-1: ALB `name_prefix = "tg-ci-"` discards `var.name` entirely
[maintainability] `modules/l1/alb/terraform/main.tf:9`

The fix replaces `name = var.name` with `name_prefix = "tg-ci-"` (a
hardcoded literal). This is the correct terraform pattern for
create_before_destroy resources with name-uniqueness constraints, and the
commit message explains the orphaned-resource motivation well. However
the target group name is now non-configurable (always `tg-ci-<random>`),
and the `var.name` variable is no longer used by the target group at all
(it is still used by `aws_lb.this.name`). A consumer who sets `name:
my-app` gets an LB named `my-app` but a target group named `tg-ci-...` —
inconsistent tagging. Consider `name_prefix = "${var.name}-"` to keep the
consumer's name as a prefix while preserving uniqueness. Post-hoc: not
blocking; the lifecycle pipeline is the only current consumer and `tg-ci-`
is fine for CI.

### P2-2: No test covers the new dedup merge behavior or `ACDL_REMOTE_STATE_KEY`
[testing] `tests/test_adapter.py`, `tests/test_pipeline_contract.py`

The adapter gained (a) a dedup-merge loop for multi-resource L1s sharing a
terraform dir and (b) `ACDL_REMOTE_STATE_KEY` env override for the remote
state data block. Neither has a unit test:
- No test asserts that two resources with the same `module` collapse to one
  `module "<first_id>" { ... }` block with merged inputs.
- No test asserts that `ACDL_REMOTE_STATE_KEY` overrides the default
  `platform/terraform.tfstate` key in the emitted `data
  terraform_remote_state` block.
- No test covers the L2 lifecycle scripts (`run_l2_lifecycle_test.sh` /
  `run_l2_lifecycle_destroy.sh`) — the L1 equivalents are also untested at
  the script level, so this is consistent with existing practice, but the
  L2 scripts are new in this session and the `ACDL_REMOTE_STATE_KEY` wiring
  is the load-bearing correctness mechanism for the microservice lifecycle.

The 485 offline tests adequately cover the *contract* (pipeline schema,
byte-identical workflows, matrix membership, job needs) — the
`TestModulesLifecyclePipeline` class is solid (89 tests pass). The gap is
adapter *behavior* at the unit level.

**Recommendation:** add a `test_adapter_dedup_merges_same_module` and a
`test_adapter_remote_state_key_override` to `tests/test_adapter.py`.

### P2-3: `waf` complex example uses `scope: CLOUDFRONT` but WAF scope is now `upper()`'d
[correctness] `modules/l1/waf/examples/complex.yml:8`,
`modules/l1/waf/terraform/locals.tf:3`

The `locals.tf` change `scope = upper(var.scope)` is the correct defensive
fix (the AWS provider requires `CLOUDFRONT`/`REGIONAL` regardless of input
case). The complex.yml was simultaneously changed from `scope: cloudfront`
to `scope: CLOUDFRONT`. Both are now correct, but the example's uppercase
value is now redundant with the `upper()` — a future reader may wonder
which is authoritative. Minor; the defensive `upper()` is the right call
and the example matching it is fine. Post-hoc only.

### P2-4: COST.md reproducibility snippet could leak the account ID via CloudTrail
[security] `.ciagent/COST.md:106`

COST.md contains the AWS account ID `581513795199` in multiple places
(summary, S3 bucket name, methodology). This is consistent with the rest of
the repo (the bucket name `acdl-tfstate-581513795199-us-east-1` is hardcoded
in `adapter.py:130` and `adapter.py:146`), so it is not new leakage and not
a regression. No actual secret material (access keys, secret access keys)
appears in COST.md, PRE_MORTEM.md, CAPABILITY_INVENTORY.md, or the workflow
files — all credential references use `${{ secrets.ACDL_AWS_* }}` or env
var names only. The `.ciagent/PROJECT.md:731` reference to a deactivated
root key is redacted (`AKIA…ROOT-DEACTIVATED`). **No credential leakage
found.** The P2 is only that the account ID is published; if the account
is meant to be opaque, this is an accepted exposure (the bucket name
already requires it).

## What is correct

- **WAF scope fix (`upper(var.scope)`):** correct and defensive; AWS
  provider v5 requires uppercase. The `local.scope` indirection is clean.
- **VPC `create_before_destroy` + same-CIDR complex example:** correct
  fix for the DependencyViolation on modify. Using the same CIDR means
  terraform modifies in-place rather than replacing the VPC (which would
  cascade-fail on dependent subnets/IGW). The `create_before_destroy`
  lifecycle is the right guard.
- **ALB `name_prefix`:** correct terraform pattern for
  create_before_destroy + name-uniqueness; well-documented commit message.
- **Adapter dedup (for the registered-module case):** correct —
  multi-resource L1s like cloudfront (distribution + OAC) correctly merge
  into one `module "cloudfront-distribution" { ... }` block. The merge
  preserves first-resource inputs and union of outputs. (The
  unregistered-module drop is P1-1, a separate concern.)
- **L2 composition wiring (`ecr.inputs.name`, `roles.inputs.role_name`):**
  correct. Resolving microservice complex now shows `ecr.inputs.name =
  "app-repo"` and `roles.inputs.role_name = "app-role"` (defaults applied
  since the contract doesn't set `name`). Previously these would have hit
  the "missing required arg" defect class from the v1.10 sweep.
- **Microservice complex = real modify:** `desired_count: 2` (vs simple's
  default 1) is a genuine in-place modify — confirmed by resolving both
  and diffing `service-service.inputs.desired_count`.
- **`ACDL_REMOTE_STATE_KEY` plumbing:** correct end-to-end — the L2 scripts
  export it, the adapter reads it with a sensible default, and the
  microservice composition's `terraform_remote_state` data block picks it
  up. This cleanly separates the short-lived CI VPC state from the
  long-lived platform VPC state.
- **Workflow structure:** `l2-lifecycle` correctly `needs: ci-vpc-apply`;
  `ci-vpc-destroy` correctly `needs: [lifecycle, l2-lifecycle]` and
  `if: always()`. The 7 new L2 pipeline-contract tests assert all of this.
- **Byte-identical workflows:** `.gitea` and `.github` modules-lifecycle.yml
  are byte-identical (test asserts this); the `test_workflow_has_four_jobs`
  rename from three→four is correct.
- **Adapter line count:** 194 lines — under the 200-line ceiling, still a
  clean stateless assembler. The dedup logic added ~16 lines without
  bloating.
- **Teardown verification (P64):** trustworthy in structure — the
  `ci-vpc-destroy` job runs unconditionally and the decommission
  `---ci---` block is the audit trail. The adversarial concern (P1-5) is
  about the regression gate trusting the workflow ran, not about the
  teardown itself being fakeable.
- **Security:** no credential leakage in any reviewed file. All AWS auth
  in workflows uses `${{ secrets.* }}`; COST.md references only env var
  names and a redacted/deactivated root key ID.

## Test coverage assessment (485 offline tests)

- **Adequate:** pipeline contract (89 tests), schema validation, contract
  resolution, adapter emission (basic), confidence signal, outbox,
  interpolation, local emulators, module-standards file presence, design-doc
  currency.
- **Gaps (post-hoc):**
  1. Adapter dedup merge behavior (P2-2) — no unit test.
  2. `ACDL_REMOTE_STATE_KEY` override (P2-2) — no unit test.
  3. CAP-017..022 regression checks (P1-5) — not exercised at the unit
     level; the 2 slow tests in `test_verify_regression_mode.py` run the
     full registry but are `@pytest.mark.slow` and deselected from the
     fast suite, so a CI run of the 485 fast tests does not verify
     CAP-017..022 even at the offline-proxy level.
  4. WAF `upper()` scope — no test asserts the locals transform; relies
     on the lifecycle pipeline cell to catch a regression.
  5. ALB `name_prefix` — no test asserts the target group uses
     `name_prefix` (P2-1 context).

The 485 count is honest (447 pass fast, 5 deselected slow, 485/490
collected). The gap is behavioral coverage of the new adapter + module
logic, not contract/schema coverage.

## Verdict

**PASS with P1 flags for post-hoc review.** No P0 fixes applied. The
milestone's structural controls (regression gate, mandatory teardown,
byte-identical workflows, byte-identical contract↔workflow tests) are
sound. The most material finding is P1-5 (the regression gate's
CAP-017..022 evidence is an offline proxy, not live pipeline evidence) —
this is a repeat of the v1.10 "VERIFY was diff-scoped" structural defect
in a milder form: the gate trusts the workflow was run rather than proving
it. The mitigations in PRE_MORTEM (FM-1..FM-4) acknowledge related risks;
P1-5 is the specific instance for the lifecycle-pipeline tier.