Phase 1 -- Implementation Skipped

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

SK-1: REQ-EXT-003 — PostmarkNonProd 2FA enable

Status: Partial in the operator-runbook sign-off table (2026-05-05).

State:

• PostmarkNonProd account exists.
• Account is on the Platform plan.
• Account-level API token captured in 1Password (Postmark-NonProd).
• Drift-check probe (GET /servers?count=1&offset=0) returns HTTP 200.
• 2FA on the owner mailbox: not enabled. The Postmark Console UI’s account-settings page (https://account.postmarkapp.com/account) does not expose a 2FA toggle for this account on walkthrough date; the per-user profile URL was not located.

Why skipped: the Phase 1 downstream consumers do not block on owner-mailbox 2FA. Drift workflow runs successfully without it. Phase 4 deploys against the same account use the SDK-resolved account token; no operator UI involvement.

Why not blocking: the 2FA toggle is a security hardening measure, not a functional requirement. The PostmarkProd account has 2FA enabled (REQ-EXT-001 sign-off complete); PostmarkNonProd is dev / sandbox / non-prod, lower blast radius.

Trigger to close: any future walkthrough that has access to the user-profile menu in the Postmark Console for the PostmarkNonProd login. Re-run row 3 of the runbook’s sign-off table; flip Deviations to “None” and update the Notes column with the URL discovered.

SK-2: T-C5 — first workflow_dispatch run of external-resources-drift.yml

Status: Deferred until PR #446 merges to main.

State:

• Workflow file authored, committed, pushed (PR #446).
• OP_SERVICE_ACCOUNT_TOKEN GHA secret is set on Arda-cards/infrastructure.
• Pre-merge dispatches against --ref jmpicnic/email-integration-phase-1-infra return HTTP 404 (workflow not on default branch); GitHub registers workflows when they appear on the repo’s default branch.

Why skipped: GitHub Actions design constraint, not a project decision. There is no pre-merge path to dispatch the workflow.

Trigger to close: PR #446 merge. Immediately after merge, run:

gh workflow run external-resources-drift.yml -R Arda-cards/infrastructure
gh -R Arda-cards/infrastructure run list --workflow external-resources-drift.yml --limit 1
gh -R Arda-cards/infrastructure run watch <run-id>

Expected: run completes successfully with passed: 5, failed: 0 from tools/drift-check.ts. Verifies V-CI-102.

SK-3: Migration of tools/gha-secret.ts from the prior implementation

Status: Skipped by design.

State: the prior Phase-0 implementation had infrastructure/scripts/gha-secrets/ (~1370 lines, TS+Octokit+libsodium). Phase 1 ships tools/set-gha-repo-secret.sh (~130 lines, shell) instead. The earlier implementation survives only as a closed-PR record and is not migrated.

Why skipped: the spec § 4 explicitly carves the tools/gha-secret.ts migration out as a separate concern. The shell substitute closes the same operator workflow with zero scope creep. See alternatives.md A-1 for the full trade-off.

Trigger to revisit: when a third helper appears with the same op read | gh secret set pattern. At that point a shared sourceable helper (tools/lib-gh-secret.sh) becomes worthwhile (see suggestions.md S-3). Below that, the duplication is small and bounded.

SK-4: Tightening AllowCreatingNSRecordsRole.allowedParentHostedZoneIds

Status: Out of scope.

State: the IAM role currently scopes route53:ChangeResourceRecordSets to arn:aws:route53:::hostedzone/* (any zone in the account). Tightening to a specific list of zone IDs would be defensive.

Why skipped: not part of this project. Phase 2 doesn’t change the role; Phase 3 / Phase 4 use it as-is. Tightening would be a separate refactor with its own design and rollout plan.

Trigger to revisit: a separate security-hardening project, or a security audit recommendation. Not on the email-integration project’s path.

SK-5: Postmark domain verification

Status: Out of scope of Phase 1; transferred to Phase 3 / Phase 4.

State: per-domain DKIM, Return-Path, optional DMARC, and the manual “Verify” click in the Postmark Console at https://account.postmarkapp.com/signature_domains. Without at least one verified sending domain, a Postmark account is in sandbox mode for end-recipient delivery.

Why skipped: Phase 1 implements account creation + token capture; sending-domain verification is a per-domain workflow that doesn’t apply until a domain is created (Phase 3 for Free Kanban; Phase 4 per partition).

Trigger to close: Phase 3 implementation. The runbook’s “Looking Ahead: Domain Verification” section forward-references the Phase 3 stub at 3-corporate-updates/operator-domain-verification-checklist.md for the detailed checklist.

SK-6: Sandbox-to-live approval-request submission for Postmark accounts

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

State: Postmark accounts in their default state are in sandbox mode for delivery to non-owner email addresses. Submitting an “approval request” via the Postmark Console takes the account out of sandbox after Postmark support reviews. The submission requires a verified sending domain, which Phase 1 doesn’t create.

Why skipped: depends on a verified sending domain (SK-5). Phase 1 has neither.

Trigger to close: Phase 3 (Corporate). Submitted from the Postmark Console for PostmarkProd after arda.ardamails.com is verified. The Phase 3 stub includes this step in its draft operator checklist.