Phase 2 -- Implementation Skipped

Items considered or partially implemented during Phase 2 that were intentionally not closed in this phase. Each entry records what was skipped, why, and what triggers picking it up later.

SK-1: Tighten AllowCreatingNSRecordsRole.allowedParentHostedZoneIds

Status: Out of scope (per requirements.md § Out of scope of Phase 2).

State: the IAM role currently scopes its zone allow-list broadly (arn:aws:route53:::hostedzone/*). Phase 2 leaves the scope as-is and adds a new consumer (ardamails.com) without tightening.

Why skipped: not part of Phase 2. Tightening would be a separate refactor whose risk profile (potential to break Phase 4 deploys if a partition zone ID is omitted) warrants its own design + rollout plan.

Trigger to revisit: a separate security-hardening project, or post-Phase-4 once the tightened scope is verifiable end-to-end. Recorded in suggestions.md S-5 as a forward-looking improvement.

SK-2: Extraction of the IAM role into a RootSecurityStack

Status: Out of scope of this project (settled by DQ-013).

State: AllowCreatingNSRecordsRole continues to live inside RootDnsStack (CFN name: RootConfiguration). The decision was reached pre-rev1 and stands; Phase 2 does not revisit it.

Why skipped: extraction would force CFN-stack changes (new stack, cross-stack reference rewiring), each with their own deploy-and-rollback considerations, for no functional gain. DQ-013 records the trade-off.

Trigger to revisit: a future change in trust-boundary or naming convention that motivates separating the IAM role from the DNS stack. None on the horizon.

SK-3: arda reserved-words update

Status: Out of scope of Phase 2; transferred to Phase 3.

State: the arda partition slug needs to be added to the project’s reserved-words list so it can’t be allocated as a tenant slug. Phase 2 does not own the reserved-words file; Phase 3 (Corporate) is the natural owner because the arda reservation is what makes the Corporate arda.ardamails.com zone name safe.

Why skipped: the reserved-words list is consumed by tenant-provisioning code (Phase 3 / Phase 4 territory), not by Root-instance-group code (Phase 2 territory).

Trigger to close: Phase 3 implementation. Spec and task plan for Phase 3 will include the reserved-words PR alongside the Corporate stack work.

SK-4: NS-delegation entry for arda.ardamails.com

Status: Out of scope of Phase 2; transferred to Phase 3.

State: ardamails.com exists (Phase 2 imports it); arda.ardamails.com does not. The NS-delegation record from ardamails.com to arda.ardamails.com’s nameservers will be written by Phase 3’s Corporate stack via WriteNSRecordsToUpstreamDns (per DQ-R1-006).

Why skipped: the writer-stack-owns-its-NS-record pattern (DQ-R1-006). Phase 2 cannot write a record whose nameServers value comes from a zone that doesn’t exist yet; Phase 3 owns both the child zone and its delegation entry into the parent.

Trigger to close: Phase 3 Corporate stack implementation. The exit criterion dig +short NS arda.ardamails.com returning the four AWS-assigned nameservers belongs to Phase 3.

SK-5: NS-delegation entries for <partition>.ardamails.com

Status: Out of scope of Phase 2; transferred to Phase 4.

State: per-partition mail sub-zones ({partition}.ardamails.com) and their NS-delegation entries are Phase 4 territory.

Why skipped: same rationale as SK-4 — the child zone (in each partition account) doesn’t exist until Phase 4 creates it; Phase 4 owns the delegation write.

Trigger to close: Phase 4 per-partition deploys.

SK-6: Apex-level SPF / DMARC / TXT records on ardamails.com

Status: Out of scope of Phase 2.

State: the imported zone has only the AWS-default NS and SOA records. Apex-level records that affect mail authentication (SPF flattening, DMARC policy at the org level, MX records) have not been declared in CDK.

Why skipped: Phase 2’s scope is “declare the zone and export its ID”. Apex-record decisions depend on whether the project ever needs to send mail from arda@ardamails.com directly (probably not — the architecture sends from <tenant>.<partition>.ardamails.com) and on the DMARC reporting strategy (a Phase-N policy decision, not a Phase-2 implementation question).

Trigger to revisit: when the email-integration project plans org-wide DMARC reporting (likely a post-Phase-5 concern), or when an external requirement (e.g., a deliverability vendor) needs apex SPF / DMARC on the mail-root domain.

SK-7: Migration of pre-rev1 root-stack imports / call sites in completed roadmap docs

Status: Skipped by design (read-only history).

State: completed-roadmap pages and earlier closed-PR documentation snapshots continue to mention the old folder path (apps/rootConfiguration/) and the old class (RootConfigurationStack). Phase 2’s renames do not back-propagate to those frozen artifacts.

Why skipped: completed-roadmap docs and the closed-PR history of the prior implementation are immortal historical records; rewriting them would erase the trail of when the rename happened. The current-system docs reflect the rev1 names; the historical docs reflect the names that were live at the time.

Trigger to revisit: never, by design. If a future reader is confused, the current design pages and the Phase 2 changelog (changelog.md in this directory) are the canonical “this is what happened and when”.

SK-8: V-ROOT-002 dig assertion against arda.ardamails.com

Status: Deferred to Phase 3.

State: the original Phase 2 verification regime included dig +short NS arda.ardamails.com @8.8.8.8 returning the four AWS-assigned nameservers as an exit criterion. The phases.md patch for Phase 2 (per DQ-R1-006) narrowed Phase 2’s exit criteria to forward declaration only; the dig assertion was moved to Phase 3.

Why skipped: the assertion only succeeds after Phase 3 has provisioned the arda.ardamails.com zone and written its NS-delegation record into ardamails.com. Phase 2 cannot make the assertion true; making it a Phase-2 exit criterion would have created a joint state Phase 2 alone could not reach.

Trigger to close: Phase 3 verification. The dig assertion belongs to Phase 3’s verification.md (V-CORP-NN) and Phase 3’s exit criteria.