- Task 1 (page shell) and Task 2 (record editor dialog) committed and
verified (tsc + build + acceptance-criteria greps all green)
- Task 3 is a blocking checkpoint:human-verify requiring a live 9-step
round-trip against a real AWS account — not run, not fabricated
- Marked 24-07-T1/24-07-T2 rows green in 24-VALIDATION.md; 24-07-T3 and
the three Manual-Only Verifications rows it covers remain pending
human execution
- RecordEditorDialog: plain-state form (name/type/ttl/values), type
selector offers exactly the six D-01 writable types, name/type
read-only in edit mode
- Submit disabled while in flight (T-24-20); 400/409/502 responses
render the server message inline and keep the dialog open
- RecordDeleteConfirm: single misclick-guard confirmation, deletes
immediately with no staged/approval state (D-03)
- Wired into the Records tab actions cell from the prior commit
- Four-tab detail page (Zones / Records / History / Schedule) following
the veeam/pax8 sync-detail-page shape
- Sync Now trigger with bounded polling and 409/503 handling
- Records tab: zone selector, type/search filters, actions cell gated on
the D-01 writable-type allowlist (NS/SOA render read-only)
- History tab: per-record change ledger with pulse_crud vs
sync_detected_drift source badges (D-06)
- Zone/history detail drill-downs via the existing DetailModal component
- app/api/route53/sync/route.ts: POST (requireAdmin, fire-and-forget) + GET (requireAuth, status/history)
- app/api/route53/zones/route.ts: GET (requireAuth) list mirrored hosted zones
- app/api/route53/zones/[zoneId]/records/route.ts: GET (requireAuth) list records with type/search filters
- app/api/route53/zones/[zoneId]/records/[recordId]/history/route.ts: GET (requireAuth) append-only change ledger
- None gated on integration_settings disable toggle (D-10 — route53 is not a PAX8-style exception)
- /api/route53 confirmed absent from middleware.ts public-route list
- tsc clean
- Hand-authored public/logos/route53.svg (globe/DNS glyph, primitive
shapes only, no script/external refs/raster data)
- New INTEGRATIONS entry linking to /admin/sync/route53 (built in
plan 24-07), color: orange (already used by datto-rmm)
- Add route53-incremental and route53-full to the sync_type union
- Seed both schedules disabled (*/15 * * * * incremental, 0 1 * * * full)
- Dispatch branches gate on isRoute53Configured() only (D-10 — no
integration_settings check, unlike the pax8-daily exception)
- Both branches use dynamic import to keep the AWS SDK out of the
scheduler's eager module graph
Plan 24-04's isolated worktree didn't have plan 24-03's
route53-record-validation.ts available (parallel wave, no direct
dependency), so it carried a local copy of the identical AWS error
redaction logic — flagged in its own SUMMARY for consolidation once
24-03 merged. Both plans are now merged; importing the shared
implementation instead of keeping two copies in sync.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Route 53 registered in integration health with D-12 live NS-delegation check
- Records EGRESS-OK path taken (Node dns module, no DoH fallback needed)
- Documents local sanitizeAwsError duplication vs plan 24-03 (parallel worktree gap)
- checkRoute53(): config gate + ListHostedZonesCommand auth probe, mirrors
checkDattoRmm()'s custom-body shape (key: 'route53', category: 'network')
- Auth-probe errors classified via isAwsAuthError (InvalidClientTokenId,
SignatureDoesNotMatch, AccessDenied, UnrecognizedClientException, 401/403)
and redacted through a local sanitizeAwsError before reaching IntegrationHealth.error
- D-12: queries route53_zones (is_deleted=false, capped at 50 by name),
feeds checkAllZoneDelegations(); mismatches downgrade status to a new
'degraded' HealthStatus member; lookup failures reported separately via
nsDelegationErrors, never counted as mismatches
- Whole delegation step wrapped in try/catch so a Postgres failure or
blocked resolver can never abort checkIntegrationHealth()'s Promise.all (T-24-16)
- summarize() updated so 'degraded' counts toward failed/hasIssues instead
of falling through uncounted (Rule 1 fix)
- No changes to applyDisableOverlay() — route53 covered by the existing
generic by-key overlay (D-10)
Route 53 sync + drift detection plan complete: 3 tasks, 4 files, all
verification passing (22 new tests, tsc clean, full suite green aside from
pre-existing unrelated itglue-search failures).
- 6 unit tests exercising the pure drift-classification wiring in Route53SyncService
- Confirms whole-recordset before/after payloads, not per-field deltas
- Confirms CRUD-originated changes still get tagged sync_detected_drift (sync cannot distinguish actor)
- Full suite green aside from 2 pre-existing itglue-search.test.ts failures logged in deferred-items.md (unrelated to this plan)
- fullSync/incrementalSync + getRoute53SyncService() singleton
- Paginated ListHostedZonesCommand + GetHostedZoneCommand (delegation set for D-12)
- Paginated ListResourceRecordSetsCommand per live zone
- Soft-delete reconciliation for zones and records (never hard-delete)
- sync_history bookkeeping with entity_type='route53', literal full/incremental sync_type
- Drift detection wired via buildDriftHistoryRows, writing sync_detected_drift history rows
- No integration_settings gating anywhere (D-10)
- createPendingAuditLog/markAuditCommitted/markAuditFailed implement the pending -> committed/failed lifecycle (D-07, SC-3); markAuditFailed always sanitizes via sanitizeAwsError
- insertPulseCrudHistory writes 'pulse_crud' history rows, documented as callable only after a committed write
- upsertMirrorRecord/softDeleteMirrorRecord/loadMirrorRecord manage the route53_records mirror; mirror writes are best-effort and soft-delete only (D-08), audit/history writes are not best-effort
- log same pre-existing itglue-search.test.ts failures (unrelated, out of scope) in deferred-items.md
- buildRecordKey, normalizeRecordSet, recordSetsEqual, classifyDrift, toHistoryPayload
- Pure, dependency-free module (no pg, no AWS client construction)
- 16 unit tests covering every behavior bullet from the plan
Checkpoint task 3 resolved: BWS secret keys renamed in Bitwarden
(AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY confirmed present), DNS egress
to public resolvers confirmed OK, credentials confirmed reaching the
Node process. IAM scope left as an open operational item for the
developer to confirm via AWS console.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tasks 1-2 complete (AWS SDK + schema migration, types + credential factory).
Task 3 is a blocking human-verify checkpoint requiring BWS/AWS credential
confirmation and live docker/DNS-egress verification — not fabricated, not
run unilaterally. Execution stops here pending developer response.
- lib/services/route53-factory.ts: isRoute53Configured() / getRoute53Client()
/ resetRoute53Client(), following the veeam-factory.ts singleton shape
- No explicit credentials option passed to Route53Client — relies on the AWS
SDK's default credential chain reading AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY
from process.env, exactly how BWS injects them at the container entrypoint
- CLAUDE.md: document the AWS_* env-prefix exception in the integration table
- All 7 route53-factory.test.ts assertions pass; npx tsc --noEmit clean
Tier 3 is the only tier automatic (webhook-triggered) grouping ever
reaches, since grouping runs before message parsing. It was scoped to
reports.requester_contact_id, so the same campaign reported by
different employees at the same company never consolidated into one
campaign — each report's evidence/blast-radius view silently
under-reported the campaign's true recipients.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
