cdkd changelog (extracted from AGENTS.md)

Detailed per-PR notes split out from the project's main AGENTS.md so that file fits within Claude Code's recommended ≤200-line instruction-file size (official memory docs).

Each entry below describes a shipped change — the file at the top of the entry, the public-facing surface that changed, the user-visible behavior delta, the tests added, and (where present) the issue / PR number that drove it. Pre-PR behavior is described in the past tense and post-PR behavior in the present tense, so a reader reconstructing the history of any subsystem can read top-to-bottom by date and see when each capability landed.

AGENTS.md retains the load-bearing summary ("for dev/test workflows only — early in development, not yet production-ready"); the per-PR detail moved here.

What ONE entry may carry (issue #2552)

An entry is capped at 2000 characters, counted over the bullet and every continuation line under it, and enforced by tests/unit/scripts/changelog-entry-size.test.ts. In a fragment the count is the whole file as it reads, trailing whitespace stripped — so a blank line between two prose lines counts, where the assembled document's own check skips it, and a --- at column 0 counts along with everything below it, where that check stops at the rule. The two agree unless you pad or park a --- mid-entry. The entry keeps the user-visible behavior delta, the changed files, the issue / PR numbers, and the residual's issue number — roughly the headline plus the file list plus a few sentences of mechanism.

Everything past that moves rather than disappears: a design decision to docs/design/<issue>-<slug>.md (the directory already holds documents of that shape, and .claude/rules/ bullets already close with Design: docs/design/<n>-<slug>.md), and a mechanism to the doc comment on the module or test that implements it — where it sits next to the thing it describes and moves when that thing does. The entry links to it.

The cap exists because prose here asserts implementation detail that no fence can verify, and it drifts: a sentence describing an integration fixture's premise guard has nothing checking it still matches that fixture, and one such sentence needed its own follow-up PR (#2549). Editing this file also costs a full unit-suite run, since docs/** is a check gate input — and moving the rationale does not reduce that: both redirect targets, docs/** and tests/**, are in the same check scope. What shrinks is the number of implementation facts one entry asserts with nothing verifying them. Narrowing .markgate.yml's scope is a separate question. There is deliberately no per-entry opt-out.

Every fragment you write is capped, whatever date its filename carries. A fragment under changelog.d/entries/ is new by construction, so the date in its name is a sort key for the assembler and never evidence about when the entry was written. There is no allowlist of exempted entries and no date that buys an exemption.

The cap is still forward-only, but the forward-only part now applies only to the ARCHIVE: everything in changelog.d/_archive.md was written under no cap, is already correct, and rewriting it buys nothing, so entries under a heading dated before 2026-09-05 stay exempt there.

That exemption is reachable, and saying otherwise would be papering over it: _archive.md is an ordinary tracked file the assembler reads on its own path, so a bullet appended to it under a pre-cutoff heading bypasses the fragment cap entirely. Nothing fences that. "No lane edits the archive again" is a convention, not a mechanism — what the fragment cap buys is that the ordinary way to write an entry is capped.

Until issue #2859 the cap keyed on the heading date alone, which meant a fragment named with a pre-cutoff date shipped uncapped. That was survivable only because issue #2813 happened to refuse any fragment dated inside the archive's span; fixing #2813 would have widened the uncapped window by about three months, so the cap moved to the fragment itself.

The cutoff is the day after the cap landed, not the day of. A same-day cutoff races every other lane merging that day: while this was in review, two unrelated PRs merged the same afternoon and added 3,001- and 1,854-character entries under the same heading. A same-day cutoff would have turned main red for entries written before the rule existed, or forced a grandfathering list that grows by whoever merges next — an opt-out reachable by being late.

WHEN an entry is required (issue #2779)

The section above caps what one entry may carry. This one decides whether a change writes one at all, and it NARROWS the population: a change with no user-visible behavior delta needs no bullet.

The test is what the SHIPPED ARTIFACT does — the binary a user runs. A change that alters it writes an entry; a change to how this repository is developed, reviewed, or checked does not. In practice that means src/**, plus anything that feeds data the runtime reads. Agent instructions under .claude/**, the unit and integration suites, the CI workflows, the hooks, and documentation edits that describe behavior rather than change it are all out.

One case sits on the line and is IN, deliberately: a scripts/** generator whose output the deploy path consumes. The refreshed CloudFormation schemas decide SDK-versus-Cloud-Control routing at deploy time, so a change there can silently drop a property from a user's stack — a behavior delta that happens to be produced by a build-time script.

That clause is a BACKSTOP rather than a common case, and saying so is better than letting the next reader over-estimate it: such a generator commits its output under src/** and CI fails on drift, so a PR that really changes what the deploy path reads is already IN by the ordinary trigger. What the clause catches is the split landing — a generator edit whose regenerated output arrives in a later PR.

On the src/** side this is codification; on the other side it is a real narrowing. Measured over the 40 merged PRs ending at #2787, ordered by merge time: 20 wrote an entry, and 9 of the 10 touching src/** did — the one exception being a comment-only edit. That half the rule only writes down.

The other 30 are where it bites. Eleven of them wrote an entry and nineteen did not, along no line anyone could name: retiring nine PreToolUse gates wrote none while pinning one environment flag wrote one, and both change how every future session behaves. Under this rule all eleven of those flip to no entry. Six touch scripts/** and none of the six feeds the deploy path — they are CI checkers, coverage-matrix generators and a schema-refresh REPORTER, not the schema refresh itself — so the exception above does not rescue them; the remaining five are hooks, tests and docs. That is over a quarter of the window changing behavior, not a formality.

The window is named by its BOUNDARY PR rather than by a date on purpose: these figures were first published as "the 40 most recently merged as of 2026-09-08" and were invalidated within the hour by two same-day merges, which a date stamp cannot express. Re-derive by walking merged PRs from that boundary.

The rate is also window-dependent, so treat any of it as a reading rather than a constant: over 120 merged PRs from the same boundary the src/** side holds at 87.8% while the non-src entry rate falls from 36.7% to 19.0%.

Two consequences worth stating, since neither is obvious from the rule. An entry is not a record of effort — a large agent-tooling PR correctly writes nothing, and that is not a demotion. And the entry a change does not write still has somewhere to go: the reasoning belongs in the commit message, a design note under docs/design/, or the doc comment of the module it describes, all of which outlive a bullet.

Enforced only by review. A CI check could require an entry from a src/** diff, and deliberately is not added: a missing bullet harms nobody at the moment of the merge and is repaired by an edit, which is below this repo's bar for a blocking gate. This file is the contract; AGENTS.md carries one line pointing here, and /check-docs restates the cap — kept in step by hand.

Note for anyone editing THIS section: a line starting with - at column 0 reads as a changelog ENTRY to the uniqueness fence, which would key it and count it toward that fence's population floors. (The size cap does not see it — it resolves each entry's date and so exempts everything above the first dated heading.) The contract sections are written as prose on purpose.

WHERE an entry goes (issue #2779)

You are reading an ASSEMBLED document. It is built by vp run gen:changelog from changelog.d/ and is gitignored — never edit it, and never commit it.

An entry is one file, changelog.d/entries/<YYYY-MM-DD>-<issue>-<slug>.md, containing the bullet and nothing else. The issue number in the path is what makes two lanes structurally unable to choose the same file, which is the whole point: every lane used to append to one anchor at the top of one list, and that anchor is what conflicted on nearly every parallel-lane rebase.

Do not write a dated heading into a fragment. The assembler emits one per DATE, grouping the entries that share it, and splices a date the archive already heads underneath that heading rather than opening a second one. That is what makes the duplicate-heading defect above structurally impossible rather than merely fenced: no lane writes a heading, so no merge resolution can duplicate one. assemble-changelog.test.ts refuses a fragment carrying one.

Everything written before the migration lives in changelog.d/_archive.md as a single file. Splitting settled history into hundreds of fragments would have produced a diff nobody could review, in which a mis-split is indistinguishable from a correct one, to make uniform something no lane will edit again.

What a SECTION HEADING must be (issue #1837)

Entries are grouped under **Recently Implemented** (YYYY-MM-DD): headings. tests/unit/scripts/changelog-entry-uniqueness.test.ts requires that every line which READS as one is spelled exactly that way — at column 0, in that case, with a YYYY-MM-DD date — that no heading text repeats, and that the dates never rise as you read down the file.

They exist because a rebase resolving "keep both sides" duplicates a heading as readily as it duplicates an entry, and the entry verdicts in that file cannot see it — they key - bullets, and a heading is not one. Measured on main at 2026-09-08, before the fence: the 2026-08-18 and 2026-08-25 headings each appeared twice among 52, and the 08-25 pair had an 08-24 section wedged between its halves, so the dates ran 25 → 24 → 25 → 23.

Splitting one day deliberately is fine and needs no exemption — distinguish the headings the way (2026-07-02, second batch): does. Uniqueness keys the whole heading text, and the ordering verdict rejects only a rising date, never an equal one.

Recently Implemented (2026-10-24):

• A redeploy that changes an AWS::ApiGatewayV2::Api's BodyS3Location, or its BasePath / FailOnWarnings while the definition comes from BodyS3Location, now updates the API in place instead of being refused (issue #5264) -- src/provisioning/apigwv2-body-import-patch.ts, src/provisioning/cloud-control-provider.ts, unit cases, and a phase in the cc-api-fallback integ. cdkd reads the definition object as the deploy identity, in the bucket's own region. It reads a pinned Version as that version, and follows a 301 redirect once to the region S3 names. A template declaring both Body and BodyS3Location is refused. Then it reimports the text through ReimportApi, as it does for an inline Body, and re-sends a declared Description. A refused read names the failure by its class and the next step: an AccessDenied names the s3:GetObject grant (plus s3:GetObjectVersion for a pinned version and kms:Decrypt for an SSE-KMS object), and AWS's own text goes to --verbose only. A throttled or failed read is retried as any update is. CloudFormation reads the object with the stack's execution role; cdkd reads it with the deploy identity.
• A redeploy that edits an AWS::ApiGatewayV2::Api's inline OpenAPI Body now updates the API in place instead of failing with "Redundant fields [...] provided when either Body or BodyS3Location is not empty" (issue #5260) -- src/provisioning/apigwv2-body-import-patch.ts, src/provisioning/cloud-control-provider.ts, unit cases, and a two-edit phase in the cc-api-fallback integ. Such an API is routed through Cloud Control, which applies an update to the model it reads back. That model carries Name, ProtocolType and four more keys that API Gateway refuses beside Body, and no Cloud Control patch can leave them out: removing the create-only ProtocolType is itself refused. So cdkd now sends a change to Body, BasePath or FailOnWarnings through ReimportApi, as the import path does, and sends any other changed property through Cloud Control without the import keys. A Tags or Description change on such an API goes through Cloud Control with the import keys left out, including the write-only Body every Cloud Control update re-adds. A declared Description is re-sent after the reimport, since a definition holding info.description overwrites it. A change to a BodyS3Location definition, or to BasePath / FailOnWarnings on an API defined by one, is refused with a message naming the two ways out (inline Body, or a replacement), since ReimportApi takes the definition's text only; CloudFormation accepts that change.
• A malformed template, --env-vars file, event payload, Cloud Control model, lock, manifest or config file no longer prints a window of itself in its error (issue #5254) -- src/utils/json-parse-failure.ts, src/cli/yaml-cfn.ts, src/cli/commands/{import,state,local-invoke,local-invoke-agentcore,local-run-task,local-start-api}.ts, src/cli/config-loader.ts, src/state/lock-manager.ts, src/synthesis/{assembly-reader,context-store,macro-expander}.ts, src/synthesis/context-providers/cc-api-provider.ts, src/provisioning/{create-only,write-only}-properties.ts, src/assets/{asset-manifest-loader,asset-publisher,asset-redirect,asset-storage}.ts. These are the siblings of #5247. Each site put Node's JSON.parse error text into a thrown message, a Caused by: line or a warning, and that text quotes about 30 characters of the body, which can be a plaintext secret. Each now reads invalid JSON[ at code-unit position N]; <bytes> byte(s) read. manifest.json's cause, which a Stage reader classifies, and the bootstrap marker's, whose message has no detail of its own, are a SyntaxError carrying that text; the others attach none. A YAML template's error names the yaml library's error code, line and column (or cdkd's own !GetAtt refusal) instead of a reason and code frame that quoted the source, and a YAML warning such as an unknown tag is a warn line in that form instead of a code frame on stderr. cdkd state refresh-observed prints only SyntaxError for a readback that failed to parse. Node's full text, ASCII-sanitized, is logged at --verbose only. src/provisioning/cloud-control-provider.ts's readCurrentState is not changed here.
• A corrupt state.json or rollback journal no longer prints a window of the file in its error (issue #5247) -- src/utils/json-parse-failure.ts (new: describeJsonParseFailure, utf8ByteLength), src/state/s3-state-backend.ts, src/types/rollback-journal.ts, src/state/export-index-store.ts, src/cli/commands/gc.ts, docs/troubleshooting-locks-state.md. Before, State file for stack <S> is not valid JSON: ... and Rollback journal for '<S>' is not valid JSON: ... carried Node's JSON.parse error text, which quotes about 30 characters of the body. Before cdkd scrub, that can be a plaintext property or output value, and it reached the terminal and CI logs at default verbosity -- twice for the state file, whose Caused by: line repeated it. Both messages now read invalid JSON[ at code-unit position N]; <bytes> byte(s) read, the form the exports index already used, and neither the state refusal nor cdkd gc's corrupt-state abort (which printed the same window on its Caused by: line) attaches the parse error as its cause. Node's full text, ASCII-sanitized, is logged at --verbose only.
• cdkd deploy --concurrency defaults to 20 instead of 10, and CDKD_PHASE_TIMINGS=1 counts retries by error class (issue #5242) -- src/cli/options.ts, src/deployment/deploy-engine.ts, src/deployment/retry.ts, docs/cli-deploy.md, docs/troubleshooting-slow-deploys.md, docs/architecture-deploy-pipeline.md, docs/provider-rules.md, tests/integration/wide-independent (a Cloud Control mode), the new tests/integration/wide-web-functions, and a new unit file. A stack with many independent resources provisions up to 2x faster: 24 Lambda web functions took 40 s at 10 and 20 s at 20; 48 independent Cloud Control resources 103 s at 10, 75 s at 15, 66 s at 20 and 72 s at 30, where Cloud Control began to throttle. A stack whose resources depend on each other rarely has more than 10 ready at once, so it deploys as before. A nested stack's child deploys at its parent's limit, so a nested level now allows up to 20 x 20 operations in flight. Pass --concurrency 10 to keep the previous limit. The phase report now carries a retry after <error class> line per class, naming the AWS error a provider wrapped, with the scheduled backoff and the longest; an error's message is never shown.
• cdkd state destroy refuses a stack deployed with terminationProtection: true (issue #5238) -- src/types/state.ts (terminationProtection, carried by stackInstanceIdCarriedFrom), src/deployment/deploy-engine/deploy-flow.ts, src/deployment/deploy-engine/options.ts, src/cli/commands/deploy.ts, src/cli/commands/state.ts, src/cli/commands/destroy.ts, src/utils/error-handler.ts, docs/cli-destroy.md, docs/cli-state-writing.md, a new unit file. Before, cdkd state destroy (no CDK app) could not see the setting and deleted a protected stack after the ordinary prompt. Each deploy now records the synthesized stack's setting in its state (root stacks only; a deploy that changes nothing else still saves a toggle), and cdkd state destroy refuses such a stack with STACK_TERMINATION_PROTECTION (exit 2) unless --remove-protection is given. cdkd destroy also honors the recorded setting, so code that dropped the protection protects nothing only once it is redeployed, as in CloudFormation. The field is additive, so no schema bump; a record an earlier version wrote is unprotected until its next deploy.
• A delete failure that is not proof the resource is gone keeps its retries (issue #5228) -- src/provisioning/not-gone.ts (new), the three already-deleted classifiers (src/deployment/deploy-engine/delete.ts, src/deployment/deploy-engine/update-in-place.ts, src/cli/commands/destroy-runner.ts), and the delete guards in the Cloud Map, ECS, CodeCommit, CloudFront, API Gateway Account, Scheduler and Cloud Control providers, with their unit suites and a new unit file. Before, the only way a provider could stop those classifiers reading a needle such as NotFound in a delete failure's message as "already deleted" was to mark the failure non-retryable. So a guarded failure lost every retry, and a transient failure that carried a needle (a throttle on a logical id like PageNotFound) could not be guarded: once its retries ran out, the classifiers dropped a live resource's state record. Now a dedicated not-gone mark, which the classifiers refuse, carries that verdict on its own. Each guard sets it instead, so a retry the failure qualifies for comes back, and Cloud Control marks a needle-bearing failure whether or not it is transient.
• A failed Cloud Control delete is read as "already deleted" only on a typed not-found (issue #5225) -- src/provisioning/cloud-control-provider.ts, tests/unit/provisioning/cloud-control-provider.test.ts, a new unit file. Before, the delete's already-deleted check also matched does not exist, not found or NotFound anywhere in the error message. So a live resource's state record was dropped when DeleteResource failed with TypeNotFoundException, when a FAILED delete's handler message named a missing dependency ("subnet ... not found"), or when the logical id itself spelled NotFound. Now only the handler's ErrorCode: NotFound, DeleteResource's ResourceNotFoundException, and InvalidVolume.NotFound on the EBS volume path count. A failure that is kept and whose message still holds one of those phrases is now marked non-retryable. The engine and the destroy runner check that mark before their own message match, so they no longer drop the record either. A failure that is transient for another reason, such as a throttle, is left unmarked and keeps its retry.
• A failed CloudFront Distribution, API Gateway Account or Scheduler Schedule delete whose AWS failure is a *NotFound about something else no longer reads the resource as already deleted (issue #5222) -- src/provisioning/providers/cloudfront-distribution-provider.ts, apigateway-provider.ts, scheduler-schedule-provider.ts, and unit cases. Since thrown messages name an AWS failure by its class (issue #2319), a class such as CloudFront's EntityNotFound, NoSuch* or *DoesNotExist (the disable step's referenced policy, function or key group is gone), API Gateway's NotFoundException from UpdateAccount, or Scheduler's ResourceNotFoundException from the redacted-GroupName ListSchedules search satisfied the "already deleted" substring checks, so a live resource's state record could be dropped, or a replacement created beside it. These wraps are now marked non-retryable, which those checks read first. Cloud Control's RequestTokenNotFoundException was already safe: it surfaces as an abandoned wait, which every such check refuses.
• cdkd destroy re-reads the stack's state under its lock, so a write during the confirmation prompt cannot make it delete another stack's resource (issue #5220) -- src/cli/commands/destroy-runner.ts (holdsSameResourcesAs), docs/cli-destroy.md, a new unit file and updated destroy test harnesses. Before, a destroy deleted the resources of the record read BEFORE its confirmation prompt: a cdkd refactor that moved a resource to another stack, or a deploy that replaced one, while the prompt waited left the destroy deleting a resource the record no longer owned, and a resource a deploy added in that time was dropped with the record while it stayed live. Now, under the stack lock, the record is read again (beside the refactor marker, in one concurrent round trip) and the destroy refuses with STATE_CHANGED, deleting nothing, unless the record still holds exactly the resources it held before.
• CDKD_SDK_CALL_LOG now counts S3 calls (issue #5219) -- src/utils/sdk-call-log.ts (quietS3Logger), src/utils/aws-clients.ts, src/utils/bucket-region-client.ts, src/deployment/intrinsic-resolver/stack-state.ts, two new unit files. The S3 clients replaced the call log's counting logger with a silent one (to hide the SDK's "Stream of unknown length" warning), so every state, lock, exports-index and refactor-marker call was missing from the log. They now keep the counting logger while the log is on; the warning stays hidden either way.
• The Provider Coverage Report and the Tier 3 pre-flight refusal list are current again (issue #5214) -- scripts/audit-provider-coverage.ts (listProvisioningTypes), docs/_generated/provider-coverage.{json,md}, src/provisioning/unsupported-types.generated.ts, src/provisioning/stateful-types.ts, docs/_generated/stateful-candidates.{json,md}, docs/cli-deploy-safety.md. The report had not been regenerated since 2026-09-04: 220 types AWS publishes were in no tier (among them AWS::Lambda::WebFunction, now Tier 2), and 27 types AWS has since made provisionable (e.g. AWS::AppStream::Fleet, AWS::Config::ConfigurationRecorder) were still refused at pre-flight; they now deploy through Cloud Control. 88 newly published NON_PROVISIONABLE types are now refused up front. The regeneration reads each type's provisioning type from three filtered ListTypes walks instead of one DescribeType call per type. Of the newly covered types, 19 that hold data (snapshots and backups of DocDB Elastic, ElastiCache, FSx, MemoryDB, Redshift and Timestream InfluxDB, Storage Gateway volumes, FSx file caches, Managed Microsoft AD directories, SageMaker notebook instances, Cloud9 EC2 environments, and seven types whose emptiness cannot be proven) join the stateful guard, so a deploy that would replace one asks for --force-stateful-recreation as for the other data-bearing types.
• A cdkd refactor interrupted mid-move is now safe and finishes itself on the next run (issue #5212) -- src/cli/commands/refactor-move.ts, src/cli/commands/refactor.ts, src/state/pending-moves.ts and src/state/refactor-marker.ts (new), src/state/s3-state-backend.ts (getRefactorMarker / saveRefactorMarker), src/utils/deferred-interrupts.ts (new), src/types/state.ts (pendingMovesOut), src/deployment/deploy-engine/deploy-flow.ts, src/cli/commands/{deploy,destroy,destroy-runner,diff-recursive}.ts, docs/cli-refactor.md, docs/state-management.md, a new Guides page docs/refactor.md, new unit files, and new phases in the refactor-move integ. Before, a refactor killed between the state writes of a move left the resource in no cdkd state, and the destination's next deploy created a second one; Ctrl+C also skipped every finally, stranding the stack locks. Now SIGINT / SIGTERM is held until the writes finish, and a move is first listed in {prefix}/_refactor/pending.json, then marked in the source record (pendingMovesOut, ids only) while the source keeps the resource, then added to the destination, dropped from the source, and unlisted. While a move is listed, cdkd deploy and cdkd destroy of either stack refuse and cdkd diff exits 3; the next cdkd refactor of either stack finishes it (--dry-run only lists it). A deploy reads the list per stack beside that stack's state read, so it adds no wait; a destroy reads it under each stack's lock; a denied read counts as no move. The record field is additive, so no schema bump.
• CDKD_PHASE_TIMINGS=1 reports how long resources waited for a --concurrency slot (issue #5209) -- src/deployment/dag-executor.ts, src/deployment/deploy-engine/execute.ts, docs/troubleshooting-slow-deploys.md, the new tests/integration/wide-independent fixture, and unit tests in tests/unit/deployment/dag-executor.test.ts. Each stack's report gains a ready, waiting for a --concurrency slot line: how long each resource sat with every dependency done before a slot freed, added up, with the longest wait. A stack whose resources depend on each other rarely waits (17 resources: 8 ms in all); a stack of 48 independent resources waited 75 s in all at the default of 10, and its resource DAG took 3.78 s, against 2.09 s at --concurrency 30. Unset, nothing is recorded and nothing changes.
• cdkd diff and the deploy approval prompt name a removal cdkd refactor would keep (issue #5203) -- src/analyzer/refactor-hints.ts (new), src/analyzer/destructive-changes.ts, src/cli/commands/diff.ts, src/cli/commands/diff-recursive.ts, src/deployment/deployment-approval.ts, docs/cli-diff.md, docs/cli-diff-json.md, docs/refactor.md, a new unit file, and new assertions in the refactor-command and refactor-move integ fixtures. A DELETE row whose resource reappears under another logical ID, in the same stack or in another selected stack of the same account and region, with the same type and properties and no other candidate, now reads (moved to <Stack>.<LogicalId>, run 'cdkd refactor' to keep it), as the AWS CDK CLI words it. It is on the diff line, the --fail-on=destructive list, --json (movedTo), and the cdkd deploy --require-approval prompt (renames within the deployed stack). Rows the diff already holds; no AWS call.
• cdkd refactor moves a resource between stacks instead of letting the next deploy replace it (issue #5202) -- src/cli/commands/refactor-move.ts (new), src/cli/commands/refactor.ts, src/state/logical-id-rename.ts (removeMovedRecords, insertMovedRecords), docs/cli-refactor.md, a new unit file, and the new refactor-move integ. Before, a construct moved to another stack made the source's deploy delete the AWS resource and the destination's deploy create a new one, and cdkd refactor refused a mapping between two stacks. When a run selects two or more stacks of one account and region, a resource the source no longer declares now moves into the destination stack whose template newly declares one of the same type, when the destination's diff then shows it unchanged; look-alikes are named with --override-file. Both stacks are locked; the source is written first, and a failed write puts the destinations back before any source, so a resource is never recorded in two stacks. A named move to a stack with no state yet, and a stack that would both lose and gain a resource in one run, are refused; a stack with no state is never a detected destination. No AWS resource is touched.
• New cdkd refactor keeps a resource whose logical ID a construct rename changed, instead of letting the next deploy replace it (issue #5201) -- src/cli/commands/refactor.ts, src/analyzer/refactor-pairing.ts, src/state/logical-id-rename.ts, src/cli/program.ts, src/cli/index.ts, docs/cli-refactor.md, three new unit files, and the new refactor-command integ. Before, renaming or moving a construct within a stack made cdkd deploy delete the old logical ID and create the new one, so the AWS resource was replaced and a stateful one lost its data. cdkd refactor [stacks...] pairs each removed logical ID with an added one of the same type and renames the state record when the new resource then shows no change in the same diff cdkd deploy computes; look-alikes it cannot tell apart are reported as ambiguous and named with --override-file (the cdk refactor mapping format, --revert applies it in reverse). A pair whose properties also changed is refused, as by cdk refactor. Only cdkd state is rewritten, under the stack lock and conditional on the state it planned from; no AWS resource is touched. --dry-run prints the plan. Moving a resource between stacks is not supported yet (#5202).
• CDKD_PHASE_TIMINGS=1 prints where a cdkd deploy spent its time, and a deploy that updates many resources writes fewer interim state saves (issue #5200) -- src/utils/phase-timings.ts (new), src/cli/commands/deploy.ts, src/deployment/deploy-engine/deploy-flow.ts, src/deployment/deploy-engine/execute.ts, src/deployment/deploy-engine.ts, src/state/s3-state-backend.ts, src/provisioning/cloud-control-provider.ts, src/provisioning/providers/dynamodb-table-provider.ts, docs/troubleshooting-slow-deploys.md, docs/state-schema-internals.md, and two new unit files. With the variable set, the deploy ends with a per-phase report: Node startup, synthesis beside the state-bucket preparation, asset builds and publishes, and per stack the lock, the state load, the diff, the resource DAG, each resource's provider call, the interim and final state saves, and the teardown. It makes no AWS call of its own, and unset it costs nothing. Interim state saves after each resource now coalesce: at most one save waits behind the one in flight, and every resource that completes meanwhile joins it, since that save reads the live records when it starts. The saved state after each completion is the same as before; fewer identical writes are queued, so the end of the resource DAG no longer waits for a backlog of them. Three serial round trips now overlap other work: the account lookup that names the asset destinations runs beside synthesis, the rollback journal is read beside the state record, and a first deploy reads its stack-instance.json sibling beside the diff. A first deploy's final save no longer waits for that sibling's removal, which now takes one call (the version it wrote) and runs beside the post-save writes, before the lock is released.
• cdkd state browse: pick a stack with the keyboard and view its resources or record (issue #5199) -- src/cli/commands/state-browse.ts and src/cli/interactive-select.ts (new), src/cli/commands/state.ts (printStackResources / printStackShow, the bodies of state resources / state show, now shared), docs/cli-state.md, new unit files. Lists the stacks in the state bucket; arrow keys move, typing filters, Enter picks. A picked stack offers its resources, its resources with dependencies and attributes, and its full record, each printed by the same code as cdkd state resources, cdkd state resources --long and cdkd state show. Without a terminal it exits 1 before any AWS call.
• A teardown failure that cannot be converted to text no longer stops the cleanup of cdkd local invoke, cdkd local invoke-agentcore or cdkd local run-task (src/cli/commands/{local-invoke,local-invoke-agentcore,local-run-task}.ts, go-to-k/cdkd#3361). The cleanup handlers built their message with x instanceof Error ? x.message : String(x), and String() throws for a null-prototype object, so the handler itself threw: on invoke and invoke-agentcore a failed container-log drain skipped the response write and stopped the cleanup before docker rm -f, and a failed docker rm -f skipped the remaining tmpdir and credentials removals and the stdio flush; on run-task a failed cleanupEcsRun skipped the credentials-file dispose that covers it, leaving the file behind. Each now goes through describeAwsFailure(x).detail, byte-identical whenever the value converts and a placeholder only when it cannot; the same rendering in those commands' --event / --env-vars read and parse errors and in cdkd local start-api's WebSocket error log is converted too. Tests: tests/unit/cli/{local-invoke-stdout-stream,local-invoke-agentcore-stdout-stream,local-run-task-command-body}.test.ts.
• A failure value that cannot be converted to text no longer replaces the Cloud Map partial-create failure or the Lambda create failure, nor drops the Cognito --remove-protection "left on" warn (src/provisioning/providers/{servicediscovery,lambda-function,cognito}-provider.ts, go-to-k/cdkd#3361). These helpers took the caught value as a PARAMETER, where the catch-scoped sweep did not look, and rendered it with String(), which throws for a null-prototype object. So a TypeError: Cannot convert object to primitive value replaced the ServiceAttributes failure a Cloud Map create rethrows when its cleanup DeleteService rejected with such a value, replaced the Lambda create failure, and, when Cognito refused the settings echo with such a name, threw out of the best-effort flip so the warn naming why DeletionProtection stayed on was never printed; the Cognito MFA-configuration read and restore did the same with the failure's name, losing the read's fail-open answer and the restore warn. That --remove-protection warn now also masks the failure text it prints when AWS gave no answer, which is the raw message. describeAwsFailure (src/utils/aws-failure-text.ts) itself threw the same way for an AWS-authored error whose name cannot be converted, since its summary interpolated the name; it now renders a placeholder there (unchanged for a string name). ACM's in-use classifier (src/provisioning/providers/acm-certificate-provider.ts) is converted as defence in depth: delete() always hands it an Error today. Each now goes through describeAwsFailure(x).detail or safeStringify(x), byte-identical for every value String() converts and a placeholder otherwise.
• A corrupt exports index no longer prints its contents, and the last state / utils / types catches stop out-throwing an unconvertible value (issue #3361) -- src/state/export-index-store.ts, src/state/s3-state-backend.ts, src/state/s3-replication-purge-gap.ts, src/utils/role-arn.ts, src/utils/assembly-path.ts and src/types/rollback-journal.ts, with a new unit file and the replication-check suite. When the exports index failed to parse, the Exports index corrupt (...) warning quoted the JavaScript parser's message, which repeats part of the index body, and the index holds resolved Output values. It now reports only the size, plus the position when the parser states one, as the read-only path already did. Separately, these catches and the helpers they call built their message with x instanceof Error ? x.message : String(x), which throws for a value that cannot be converted to text (a null-prototype object), so the failure being reported was replaced by an unrelated TypeError. That cost the corrupt-index rebuild, and the replication check's own report on a failed probe. These now print a fixed placeholder for such a value. Text for every other value is unchanged.
• A failure value that cannot be converted to text no longer replaces the failure being reported in the macro-expansion, asset-publishing and retry-mark handlers (src/synthesis/{macro-expander,failed-stages,assembly-reader}.ts, src/assets/{asset-manifest-loader,file-asset-publisher}.ts, src/analyzer/security-diff.ts, src/cli/{yaml-cfn,options}.ts, src/cli/commands/retire-cfn-stack.ts, src/deployment/retryable-errors/marks.ts, go-to-k/cdkd#3361). String() throws for a null-prototype object, and these handlers built their message with it, so a TypeError: Cannot convert object to primitive value took the place of the handler's own error when an SDK call rejected with such a value: a rejected macro-expansion CreateChangeSet, a failed S3 HeadObject asset check (which also threw on a null rejection), and a provider failure that wrapMaskedAwsError wraps. The Stage-scoped synthesis error, the cloud-assembly and asset-manifest read failures, the security-diff failure (SECURITY_DIFF_FAILED), the template-parse failures and the --resource-timeout per-type parse failure are converted as defence in depth: nothing known today throws them a non-Error. Each now goes through describeAwsFailure(x).detail or safeStringify(x), byte-identical for every value String() converts and a placeholder otherwise. Test: tests/unit/string-outthrow-3361.test.ts.
• The SDK provider attaches a VPN gateway to a VPC itself: AWS::EC2::VPCGatewayAttachment.VpnGatewayId (issue #2762) -- src/provisioning/providers/ec2-provider.ts, the regenerated property-coverage map, tests/fixtures/cfn-schemas/_todo-backfill.json, a new unit file, the physical-id rows in docs/import-resource-types.md / docs/state-management-physical-ids.md / docs/state-schema-internals.md, and a new VPN gateway arm in the ec2-route-targets integ. Before, an attachment naming VpnGatewayId routed through Cloud Control. It now sends AttachVpnGateway and waits for the attachment to be attached, so a route through the gateway can be created next. The record is <vgwId>|<vpcId>. Destroy sends DetachVpnGateway and waits for detached, because AWS refuses to delete the VPN gateway or the VPC until then. Drift reads the attachment with DescribeVpnGateways. --migrate-from-cloudformation and cdkd import now adopt a CloudFormation VGW|<vpcId> attachment. A template naming both InternetGatewayId and VpnGatewayId, or neither, is refused before any AWS call: CloudFormation's documentation allows exactly one of the two. Changing InternetGatewayId / VpnGatewayId now swaps the attached gateway in place, as CloudFormation does (issue #5216). Before, it was refused, and --replace could not help because AWS allows one gateway of each kind per VPC. A record naming only the attachment type (VGW|<vpcId>) resolves its gateway from the VPC. An attachment Cloud Control already created stays on Cloud Control.
• A failed Cloud Control create, update or delete keeps the handler's message but no longer writes the caller's principal ARN or account id into the persisted deployment events (issue #2319) -- src/provisioning/cloud-control-provider.ts and tests/unit/provisioning/cloud-control-statusmessage-identity-2319.test.ts. The handler's StatusMessage, and the text of a rejected CreateResource / UpdateResource / DeleteResource, is what a user fixes the template from (Property validation failure: ...), so it stays in the message. A denial in it quoted the caller (User: arn:aws:sts::<account>:assumed-role/<role>/<session> is not authorized ...), and deployments/{runId}.jsonl outlives the run. Now an STS session ARN, an IAM user / role / root ARN in the denied-principal position, and a principal's unique id read <caller-principal>, and an account id in an ARN, a name, a path, a host, or after a word such as account reads <account-id>; a resource ARN keeps its service, region and name, and a free-standing 12-digit size or template value is kept. The unmasked text is printed at --verbose. Name-collision, retry, already-deleted and downstream-403 hint classification is unchanged.
• A failed ECR repository, SQS queue, SNS topic, Step Functions state machine, WAFv2 web ACL or CodeBuild project create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/ecr-provider.ts, sqs-queue-provider.ts, sns-topic-provider.ts, stepfunctions-provider.ts, wafv2-provider.ts, codebuild-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (for example AccessDeniedException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, through the operation's secret masker. A cdkd-authored or transport error keeps its text, masked. The warning for a failed cleanup of an SNS topic left behind by a failed create names the class too. The AWS error is still the wrap's cause, so an IAM grant that is still propagating and an SQS queue name still in its 60-second cooldown are retried as before, and an "already exists" from the create call is still stated as such. A delete failure whose class names a NotFound other than the resource's own (a missing KMS key, for example) is marked as not proving the resource gone, so the class now in the message is not read as "already deleted".
• A failed resource whose AWS error reaches the deploy engine unwrapped, and three engine replacement refusals, no longer write the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/types/deployment-events.ts, src/deployment/deploy-engine/update-replace.ts, update-in-place.ts, and unit cases. When a provider lets AWS's own error escape, deployments/{runId}.jsonl recorded AWS's text as the event message, and AWS names the caller on an access denial. The recorder now writes the error class instead (for example AccessDenied. Re-run with --verbose for AWS's own message.), next to the awsErrorCode and requestId it already kept. The same applies to the --recreate-via-* destroy failure, the create-first collision refusals of a replacement, and the create failure after the update-not-supported fallback: each names an AWS-authored failure by its class, with AWS's text in the debug log through the same secret masker and on the error's cause. A cdkd-authored or transport error keeps its text. Two refusals get the same treatment: the --strict-getatt output refusal, and the refusal of an AWS CDK-generated cross-account Fn::GetStackOutput whose lookup role was denied. The lookup role's ARN stays in that message. cdkd events also stops printing the class twice on such a row.
• A failed Kinesis stream, EventBridge rule or CloudFront origin access identity create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/kinesis-provider.ts, eventbridge-rule-provider.ts, cloudfront-oai-provider.ts, unit cases, and a rollback-command integ check. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (for example AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, through the operation's secret masker. This includes a failure after CreateStream returned (a denied status read while waiting for ACTIVE) and an EventBridge rule whose targets step failed after PutRule, which still name the stream or rule left behind for cdkd rollback --revert-failed; the warning for a failed cleanup of that rule names the class too. A cdkd-authored or transport error keeps its text, masked. The AWS error is still the wrap's cause, so an IAM grant that is still propagating is retried as before, and an "already exists" is still stated as such.
• A refused name check before a create or a replacement no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/deployment/deploy-engine/replacement.ts, create.ts, and unit cases. For a type whose create API hands back or overwrites an existing resource of the same name, cdkd looks the name up first and refuses when the lookup fails; that refusal ("cdkd could not check whether another resource already holds it") quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (for example AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, through the same secret masker. A cdkd-authored or transport error keeps its text, masked. The same holds for the two --replace delete-first fallback failures ("Failed to delete old resource ..." and "Failed to re-create ... Cause: ...") when the provider let an AWS SDK error through. The AWS error is still the cause.
• A failed ELBv2 load balancer, target group or listener, Firehose delivery stream, CloudWatch alarm or anomaly detector, CloudFront origin access control, S3 Express directory bucket, S3 vector bucket, Kinesis stream consumer, or Bedrock AgentCore runtime, evaluator, default browser or default code interpreter no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/{elbv2,firehose,cloudwatch-alarm,cloudwatch-anomaly-detector,cloudfront-oac,s3-directory-bucket,s3-vectors,kinesis-streamconsumer,agentcore-runtime,agentcore-evaluator,agentcore-browser,agentcore-code-interpreter}-provider.ts unit cases, and remove-protection / created-before-failure-revert integ checks. The create, update and delete failure messages quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (for example AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, through the operation's secret masker. A cdkd-authored or transport error keeps its text, masked. The AWS error is still the wrap's cause, so an IAM grant that is still propagating, or a throttle, is retried as before, a --remove-protection load balancer delete still decides between retrying and restoring the guard on AWS's text, and an "already exists" is still stated as such (but not for a load balancer, target group or listener whose post-create wiring step failed). A delete failure whose class is another resource's not-found (for example KMSNotFoundException) no longer reads as "already deleted": the state record is kept. The ELBv2 partial-create cleanup warning names an AWS failure by its class too, and no longer fails on a rejection value that cannot be converted to text.
• A failed Lambda function, permission, layer version or event invoke config no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/{lambda-function,lambda-permission,lambda-layer,lambda-event-invoke-config,s3-bucket-policy,appsync,glue,s3-tables,s3-bucket,servicediscovery}-provider.ts unit cases. The create, update and delete failure messages quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (for example AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, through the operation's secret masker. A cdkd-authored or transport error keeps its text, masked. The S3 bucket policy wrap, which already named the class, now masks it and the cdkd-authored text too, and restates an "already exists". The AWS error is still the wrap's cause, so an IAM grant that is still propagating, a throttle or a Lambda function still updating is retried as before, and an "already exists" is still stated as such, except from a post-create step of a Lambda function, AppSync GraphQL API or S3 bucket. A delete failure whose class is another resource's not-found (for example KMSNotFoundException) no longer reads as "already deleted" for these providers or for the S3 bucket policy, AppSync, Glue, S3 Tables and S3 bucket deletes: the state record is kept. A failed S3 bucket delete now masks a secret spelled in the error class too. The Lambda function post-create cleanup lines, the AppSync GraphQL API rollback warning and the Cloud Map service cleanup warning name an AWS failure by its class too.
• A failed Cloud Map namespace or service, ECS cluster, task definition or service, or CodeCommit repository create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/servicediscovery-provider.ts, ecs-provider.ts, codecommit-repository-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDeniedException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, masked through the operation's secret masker. This also covers a Cloud Map operation that AWS reports as FAIL (the message names its ErrorCode when AWS reports one), the ECS service --full-wait steady-state failure (the SDK waiter's result, which lists every DescribeServices answer and failure text, is reduced to its state), the CodeCommit trigger put beside kept live triggers, and the free-text detail of a DescribeClusters failure during an ECS cluster name lookup. A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before, a name that is taken still reads as a name collision, and a CodeCommit delete refused for a missing KMS key (EncryptionKeyNotFoundException) is never read as an already-deleted repository.
• A failed SNS Subscription create, update or delete, a rollback's reverse replacement, or an Fn::GetAZs lookup no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/sns-subscription-provider.ts, src/deployment/rollback-executor/replay-reverse-replacement.ts, src/deployment/intrinsic-resolver/functions.ts, src/deployment/work-graph.ts, and unit cases. These messages quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. They now carry the error class (AuthorizationErrorException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, masked. In a rollback this covers the re-create of the old resource after the new one was deleted, the Underlying collision: line of a refused reverse replacement, and the reason recorded for a new resource that could not be deleted. The N node(s) failed summary at the end of a deploy names an AWS-authored failure (an asset upload's AccessDenied) the same way; its Failed: line above still prints AWS's text. A cdkd-authored or transport error keeps its text, and the AWS error stays as the cause, so a throttle or a still-propagating IAM grant is retried as before and a taken subscription still reads as a name collision.
• A failed SSM parameter create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events, and the SSM parameter's Arn-attribute warning, the CloudTrail trail's skipped event-selector reset warning, and the partial-create / best-effort cleanup warnings of the IAM user and group, FSx file system and EMR cluster / instance group / instance fleet providers name an AWS failure by its class (issue #2319) -- src/provisioning/providers/{ssm-parameter,kinesis,cloudtrail,iam-user-group,fsx-filesystem,emr-cluster,emr-instance-group-config,emr-instance-fleet-config}-provider.ts unit cases. The SSM failure message now carries the error class (for example AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log through the operation's secret masker; the AWS error is still the wrap's cause, so a propagating grant or a throttle is retried as before, and an "already exists" is still stated as such. A cleanup warning shows the class at warn and AWS's text at debug, masked; an EMR cluster that terminated with errors shows the state-change reason's code at warn. An SSM parameter, Kinesis stream, CloudTrail trail or FSx file system delete failure whose class is another resource's not-found no longer reads as "already deleted": the state record is kept. A CloudTrail update whose event-selector reset is denied on a trail whose name contains "advanced event selector" now fails instead of being skipped. A Kinesis stream, CloudTrail trail, IAM user or IAM group whose post-create step fails with "already exists" no longer adds "AWS reports that it already exists", which read as the resource's own name collision.
• AWS::FSx::FileSystem: the warning for a removed StorageCapacity, StorageType or NetworkType now says CloudFormation keeps the value too (issue #1160) -- src/provisioning/providers/fsx-filesystem-provider.ts. A CloudFormation A/B on the issue (us-east-1, 2026-10-23) removed each property in its own update. Every update completed in place, with the same file system and no FSx administrative action. An OpenZFS SINGLE_AZ_1 file system kept NetworkType DUAL, StorageCapacity and StorageType SSD. A Lustre PERSISTENT_1 file system kept StorageType HDD and StorageCapacity. cdkd already left these values in place, so only the warning changes: it now reads ... and keeps its current AWS value, as CloudFormation leaves it; .... The claim is made only for the file system types measured (Lustre and OpenZFS, and NetworkType on OpenZFS only), and never for an INTELLIGENT_TIERING file system. A warning that names an unmeasured property, such as a Windows or ONTAP removal or a Lustre NetworkType, keeps its old wording. Tests: tests/unit/provisioning/providers/fsx-filesystem-provider.test.ts; the fsx-openzfs integ gains a phase that removes all three.
• AWS::FSx::FileSystem: the warning for a removed OpenZFS ThroughputCapacity, ReadCacheConfiguration or EndpointIpv6AddressRange now says CloudFormation keeps the value too, on the shapes measured (issue #1160) -- src/provisioning/providers/fsx-filesystem-provider.ts. A CloudFormation A/B on the issue (us-east-1, 2026-10-24) removed each property from an OpenZFS MULTI_AZ_1 file system. Every update completed in place, with the same file system, the value unchanged and no FSx administrative action: ThroughputCapacity on SSD and on INTELLIGENT_TIERING, ReadCacheConfiguration on INTELLIGENT_TIERING, and EndpointIpv6AddressRange on a dual-stack SSD file system in the same update that removed NetworkType. cdkd already sent nothing for these removals, so only the warning changes: it now reads ... and keeps its current AWS value, as CloudFormation leaves it; ... on those shapes, for ThroughputCapacity and ReadCacheConfiguration only as the deploy's single removal with NetworkType not declared DUAL (CloudFormation refused every update while it was). Any other shape keeps the line that claims nothing about CloudFormation: a SINGLE_AZ_* file system, a deploy that also changes StorageType, an EndpointIpv6AddressRange removal while NetworkType stays declared, and, on MULTI_AZ_1, a NetworkType removal while EndpointIpv6AddressRange stays declared (CloudFormation refused both). Tests: tests/unit/provisioning/providers/fsx-filesystem-provider.test.ts; the fsx-openzfs integ gains a phase that removes ThroughputCapacity on its SINGLE_AZ_1 file system and asserts the value stays and the warning makes no CloudFormation claim.

Recently Implemented (2026-10-23):

• An RDS, Neptune or DocDB DB instance update that AWS refuses because the instance is not available is retried once it reads available again (issue #5194) -- src/provisioning/providers/db-instance-modify-retry.ts (new), src/provisioning/providers/neptune-provider.ts, src/provisioning/providers/docdb-provider.ts, src/provisioning/providers/rds-provider.ts, and a new unit file. A deploy that changed a DB cluster (for example by removing its VpcSecurityGroupIds) and a member instance together could fail with Database instance is not in available state.: the cluster change moves the member to modifying a moment after the cluster update returns, and the instance's ModifyDBInstance was sent before that showed up. CloudFormation lets the cluster change settle first, so the same template succeeded there. Now only that refusal (InvalidDBInstanceStateFault / InvalidDBClusterStateFault with the not-available wording) is retried. cdkd waits out any transitional status and resends, for up to 30 minutes or what --resource-timeout leaves, whichever is less. A terminal status (failed, incompatible-*, ...) fails at once and names the status. An update AWS accepts makes no call beyond the one ModifyDBInstance. A modify AWS answered with success is never resent; a request the SDK replayed after a lost response can be resent once with the same values.
• cdkd drift compares AWS::Budgets::Budget again, through the provider's own read-back (issue #5183) -- src/provisioning/providers/budgets-budget-provider.ts (readCurrentState, getDriftUnorderedPaths, getDriftUnknownPaths, canonicalizeDriftProperties), src/analyzer/drift-cc-api-deny-list.ts, docs/cli-drift.md, docs/cli-drift-internals.md, a new unit file, and the budgets integ. Since #5179 every budget was reported as drift unknown (? CostBudget), because the Cloud Control READ response diffed on an unchanged budget. The provider now reads the budget with DescribeBudget, DescribeNotificationsForBudget, one DescribeSubscribersForNotification per notification and ListTagsForResource, mapped to the template shape: amounts as numbers, dates as ISO strings, and members AWS changes on its own (CalculatedSpend, LastUpdatedTime, HealthStatus) left out. Notifications and their subscribers are compared as sets. An absent ThresholdType reads as AWS's default PERCENTAGE on both sides. Budget.BudgetLimit is not compared on a budget declaring AutoAdjustData or PlannedBudgetLimits, where AWS sets it. The deny-list entry is removed. Like every provider with a read-back, a deploy that creates or updates a budget now captures its observedProperties off the critical path; --no-capture-observed-state turns that off.
• cdkd local start-api serves several stacks that reuse a construct id, each with its own Lambdas, Stage and CORS (issue #5181) -- src/cli/commands/local-start-api.ts, tests/integration/local-invoke-stage/. Take two stacks with their own physical names that each declare new HttpApi(this, 'Api') backed by a Handler Lambda, served together with --stack 'Svc*'. Before #5177, one stack's Lambda, Stage variables or CORS settings answered the other stack's routes. #5177 made start-api refuse that set instead. Now the container specs and the Stage and CORS maps are keyed by stack and logical ID, so each stack's API is served from its own handler with its own Stage and CORS. Two refusals remain. start-api still refuses two served stacks that share one physical stack name (#5175). It also refuses a bare logical ID in --assume-role <LogicalId>=<arn> or an --env-vars key when more than one served stack declares that Lambda. The error names the stacks, and for --env-vars it suggests the stack-qualified construct-path key, such as "SvcA/Handler".
• A multi-region app that deploys one CDK Stage per region under a shared stackName is now deployed, diffed, listed and destroyed in every region, as the AWS CDK CLI does (issue #5176) -- src/cli/stack-matcher.ts, src/analyzer/cross-stack-deps.ts, src/cli/commands/{deploy,destroy,diff,list,synth,publish-assets,scrub,local-run-task}.ts, src/deployment/intrinsic-resolver/cross-stack.ts, docs/cross-stack-internals.md, unit cases and the shared-stackname-multi-region integ fixture. Before, cdkd deploy '**' (and diff, list, synth, publish-assets, scrub) kept one stack per physical name and silently deployed only the first region's. cdkd destroy UsWest/Api destroyed the FIRST Stage's stack (us-east-1). Now each selected stack is handled under its own name and region: deploy work-graph nodes, asset nodes, dependency edges and destroy targets. A dependency resolves to the producer in the dependent's own Stage, or to the stack that exports an imported name. A name shared by two app stacks is destroyed only where its selected stack lives. Two selected stacks with the same name AND region (or a selected one and an unselected one pinning that region in a possibly-equal account) would be one CloudFormation stack, so they are refused before any lock or engine runs, with both CDK paths named. destroy skips a shared-name stack pinned to another account than the run's. Fn::ImportValue now prefers a producer in the consumer's own region. A cross-region import with no same-region producer resolves as before. cdkd list without a pattern no longer drops a same-named stack. cdkd synth --verbose writes <name>.<region>.template.json for a shared name. scrub --all reads each shared-name stack in its own region. cdkd local run-task no longer takes the first Stage's state for a shared name.
• A failed Neptune DB subnet group, DB cluster or DB instance, or DocumentDB DB subnet group, DB cluster or DB instance create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/neptune-provider.ts, docdb-provider.ts, docdb-subnet-group-provider.ts, docdb-shared.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (for example AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, through the operation's secret masker. This includes a failure after CreateDBCluster / CreateDBInstance returned (a denied status read while waiting for available), which still names the cluster or instance left behind for cdkd rollback --revert-failed. A cdkd-authored or transport error keeps its text, masked. The AWS error is still the wrap's cause, so an IAM grant that is still propagating is retried as before, and an "already exists" is still stated as such.

Recently Implemented (2026-10-22):

• cdkd destroy --remove-protection no longer fails when AWS refuses the final-snapshot delete right after the guard change on an RDS / DocDB / Neptune DB cluster or a standalone RDS DB instance (issue #5184) -- src/provisioning/providers/deletion-protection-compensation.ts (deleteAfterProtectionFlipWithFinalSnapshot), rds-provider.ts, docdb-provider.ts, neptune-provider.ts, tests/unit/provisioning/providers/deletion-protection-compensation.test.ts. Before this change, the wait added by #5155 could end on its first read. After DeletionProtection was turned off, AWS could keep reading the resource available, then move it to modifying and refuse the delete ("Can't create a snapshot because the database cluster ... isn't currently in the available state"). The destroy failed and the guard was put back. Now a delete AWS refuses that way is retried once the resource reads available again, within the same 15-minute cap and resource timeout. Both before the delete and between retries, cdkd waits through any status that is neither available nor terminal (modifying, configuring-enhanced-monitoring, backing-up, ...). A terminal status (stopped, failed, inaccessible-*, ...) is not waited on, and neither is storage-optimization or storage-initialization, which AWS documents as still available. Any other refusal still fails at once, so a cluster that still has members is not retried. A read of protection off and available before any such status has shown is held for up to 30 seconds from the first read showing protection off. As before, all of this runs only when this destroy turned the guard off and a final snapshot is requested.
• --remove-protection --verbose (on cdkd destroy, cdkd state destroy and rollback) now masks secret values in the debug line printed when cdkd cannot read a deletion guard before turning it off (issue #5180) -- src/provisioning/providers/deletion-protection-compensation.ts, its callers in src/provisioning/cloud-control-provider.ts and src/provisioning/providers/{asg,cognito,docdb,elbv2,emr-cluster,logs-loggroup,neptune,rds}-provider.ts, src/provisioning/providers/dynamodb-table-provider.ts, and unit cases. The line Could not read <guard> on <physical id> before disabling it: <AWS's text> was printed without the delete's secret masker. A physical id can come from a dynamic reference ({{resolve:secretsmanager:...}}), and AWS's text quotes it, so --verbose output could show that plaintext. The same applied to the debug line printed when the guard could not be turned off, for an Auto Scaling group, load balancer, log group, Cognito user pool (whose AWS text can quote an echoed template value; also its failed write-back when the compensation restores the guard), DocDB cluster, Neptune cluster or instance, and DynamoDB table (also its wait after the flip). These lines now go through the masker. They are printed only with --verbose and are never written to the state bucket. The EC2 instance path is unchanged: its id is assigned by EC2 and cannot hold a template value.
• cdkd drift no longer reports false drift on an unchanged AWS::Budgets::Budget, or a permanent read failure on an AWS::EMR::InstanceFleetConfig / InstanceGroupConfig (issue #5179) -- src/analyzer/drift-cc-api-deny-list.ts, docs/cli-drift.md, tests/unit/cli/drift-per-resource-failure.test.ts, tests/integration/budgets/verify.sh. cdkd has no read-back of its own for these three types, so drift asks Cloud Control. Cloud Control used to have no READ handler for them, and drift reported each one as drift unknown. AWS has since added handlers. For a budget, the response lists notification subscribers in a different order and adds the default ThresholdType: PERCENTAGE, so NotificationsWithSubscribers showed as drift on every run. For the EMR types, Cloud Control needs the cluster id together with the fleet or group id, and cdkd records only the latter. It refused every read, and drift exited 2. Drift now reports all three as drift unknown again and exits 0 for them.
• cdkd local invoke / run-task / start-api refuse a target naming a physical stack name that two CDK Stage stacks share, instead of running the first Stage's code (issue #5175) -- src/cli/stack-matcher.ts, src/local/lambda-resolver.ts, src/local/ecs-task-resolver.ts, src/cli/commands/local-start-api.ts, tests/integration/local-invoke-stage/. Take an app with two Stages that each declare new Stack(stage, 'Api', { stackName: 'SharedApiStack' }). Before this change, cdkd local invoke SharedApiStack:Fn (or SharedApiStack/...) silently ran the first Stage's function, and cdkd local start-api --stack SharedApiStack served only the first Stage. Now invoke and run-task refuse with matched 2 stacks, naming both stacks by their CDK paths, and say to address one by its path (Beta/Api/...). start-api refuses to serve two stacks that share a physical name, because it reads deployed state by that name. It also refuses any served set in which two stacks declare the same routed Lambda or API logical id. Its container and stage / CORS maps are keyed by the bare logical id, so one stack's Lambda used to answer the other's routes. That case includes --stack '**' over a Stage deployed twice. Each error names the stacks and tells you to pass --stack '<CDK path>'. Separately, deploy, diff, list, synth, publish-assets and scrub given a CDK path such as Prod/Api now select that stack. They used to select the first stack carrying the same physical name, Beta/Api.
• cdkd local start-service / start-alb / start-cloudfront / invoke-agentcore / start-agentcore now resolve a stack inside a cdk.Stage by its display path, and a bad --max-tasks / --restart-policy value is reported like cdkd's own option errors (issues #5162, #5163) -- package.json (cdk-local ^0.153.2 -> ^0.154.0), tests/unit/cli/local-start-service.test.ts, tests/unit/cli/local-embed-logger-stdout.test.ts, tests/integration/local-invoke-container/verify.sh, tests/integration/local-invoke-from-state/verify.sh. Before this change, those commands took a path-form target's first /-segment as the stack, matched a slash-free stack pattern as a glob over the physical name only, and kept one of two stacks sharing a physical name. Now the longest display-path prefix wins, a pattern matches the hierarchical id first and the exact physical name second (as cdkd deploy does), and two stacks sharing a physical name are both kept, so a command needing one stack reports the ambiguity instead of taking the first. Their Available stacks lists show Physical (Display/Path) when the two differ. A value such as --max-tasks 84 used to be rethrown as a cdkd error; it now prints error: option '--max-tasks <n>' argument '84' is invalid. --max-tasks 84 exceeds ... and exits 1, with the same message text. The local engine's log lines also change: a continuation line of a multi-line message starts with two spaces, a control character renders as \uXXXX where cdkd showed a space, a plain identifier loses the quotes it used to carry (Lambda 'Fn' -> Lambda Fn), and an argv element on the --verbose docker build and docker run lines that carries a * is quoted (--build-arg "KEY=***", -e "KEY=***").
• cdkd local start-service / start-alb --image-override <service>=<dockerfile> now matches a service by its ServiceName (or its construct id when it sets none), logical id or Stack:LogicalId, and --strict-overrides refuses before any service starts (issues #5156, #5157) -- package.json (cdk-local ^0.153.1 -> ^0.153.2), docs/local-start-service-image-overrides.md, tests/integration/local-start-alb-from-state/. Before this change, only the exact target string matched as <service>. Under start-alb, whose services are keyed Stack:LogicalId, a key such as WebService=./Dockerfile matched nothing: cdkd warned, then pulled and ran the registry image, so local edits never reached the container. The same held for the per-service --image-build-arg <svc>:K=V, --image-build-secret <svc>:id=src and --image-target <svc>=stage forms. Now each of those names matches. A name shared by two registry-image services, or two keys for one service, is refused with an error. --strict-overrides used to refuse only after the replicas had booted; it now refuses first. The bump also changes one proxy detail inside the local engine: when every proxy variable set names a scheme it cannot use (for example only ALL_PROXY=socks5://...), its AWS clients take the SDK's default handler and the one-time Unsupported proxy scheme warning is printed when the client is built. Requests still go direct, as before.
• cdkd destroy --remove-protection no longer fails on a protected RDS / DocDB / Neptune DB cluster or a standalone RDS DB instance that takes a final snapshot (issue #5155) -- src/provisioning/providers/rds-provider.ts, docdb-provider.ts, neptune-provider.ts, tests/unit/provisioning/remove-protection-final-snapshot-wait-5155.test.ts. Before this change, cdkd turned DeletionProtection off and sent the delete at once. When the delete took a final snapshot (DeletionPolicy: Snapshot, or no DeletionPolicy), AWS could refuse it because the resource was still modifying from that change ("Can't create a snapshot because the database cluster ... isn't currently in the available state"). The destroy then ended partial and the guard was put back. cdkd now waits until the resource reads protection off and available before such a delete. The wait runs only when this destroy turned the guard off and a final snapshot is requested, so no other delete takes longer. If the resource is not available within 15 minutes, the delete is not sent, the guard is put back, and the error says to re-run the destroy once it is.
• Updating a DocDB / RDS DB cluster or an RDS DB instance no longer resets its master password when the password did not change (issue #5153) -- src/provisioning/providers/docdb-provider.ts, rds-provider.ts, tests/unit/provisioning/db-master-password-resend-5153.test.ts, tests/integration/docdb-neptune/verify.sh. Before this change, every update of an AWS::DocDB::DBCluster, AWS::RDS::DBCluster or AWS::RDS::DBInstance that declares MasterUserPassword sent the password again, even when only another property changed. AWS treats a supplied password as a credential reset, so a DocDB cluster entered resetting-master-credentials after, for example, a PreferredMaintenanceWindow-only change. cdkd now sends the password only when the template changed it, as CloudFormation does. The check compares the templates as written, so a secret is compared by its {{resolve:...}} reference, never by its value: a secret rotated under a reference the template spells literally is not sent again, as in CloudFormation. On RDS, ManageMasterUserPassword and the MasterUserSecret KMS key are likewise sent only with a master-credential change. A password fed by a NoEcho parameter is still sent on every update, because cdkd keeps no value to compare it with.
• A failed RDS DB proxy target group create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/rds-dbproxy-targetgroup-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (for example AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, through the operation's secret masker. The same holds for the failed cleanup a create appends when it cannot deregister the targets it registered; the manual aws rds deregister-db-proxy-targets command is still printed. A cdkd-authored or transport error keeps its text. The AWS error is still the wrap's cause, so an IAM grant that is still propagating is retried as before, and an "already exists" is still stated as such.
• A failed IAM user, IAM group, IAM UserToGroupAddition, IAM inline policy or IAM instance profile create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/iam-user-group-provider.ts, iam-policy-provider.ts, iam-instance-profile-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, masked through the operation's secret masker; the instance profile, inline policy and UserToGroupAddition delete messages now go through that masker too. A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before and a taken user, group or instance profile name still reads as a name collision. A DeleteUser that finds the user already gone (NoSuchEntity) now reads as already deleted, as CloudFormation treats it, instead of failing the delete.
• A failed CloudWatch Logs log group, EventBridge Scheduler schedule, DLM lifecycle policy or EventBridge Pipes pipe operation, and a failed detach of an RDS cluster from its global cluster, no longer write the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/{logs-loggroup,scheduler-schedule,dlm-lifecycle-policy,pipes,rds}-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (for example AccessDeniedException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, through the operation's secret masker. This covers the create, update and delete failures of the four types, the Fn::GetAtt lookup failure of a schedule, lifecycle policy or pipe, a pipe's *_FAILED state reason, and the RDS RemoveFromGlobalCluster / DescribeGlobalClusters failures that stop a cluster delete. A cdkd-authored or transport error keeps its text, masked through the operation's secret masker on every create, update and delete wrap. Each wrap that carried the AWS error as its cause still does, so an IAM grant that is still propagating is retried as before, and an "already exists" is still stated as such (except for a log group's create-time wiring call, where "it" would read as the log group).
• A failed RDS DB subnet group, DB cluster or DB instance create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/rds-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (for example AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, through the operation's secret masker. This includes a failure after CreateDBCluster / CreateDBInstance returned (a denied status read while waiting for available), which still names the cluster or instance left behind for cdkd rollback --revert-failed. A cdkd-authored or transport error keeps its text, masked. The AWS error is still the wrap's cause, so an IAM grant that is still propagating is retried as before, and an "already exists" is still stated as such.
• A failed IAM role, IAM managed policy, Budgets budget or Lambda network connector create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/iam-role-provider.ts, iam-managed-policy-provider.ts, budgets-budget-provider.ts, lambda-network-connector-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, masked through the operation's secret masker where the provider has one. This also covers the partial reason a renamed IAM role or managed policy records when the old one could not be deleted, the budget Arn attribute read, and a network connector that AWS reports as FAILED, update Failed or DELETE_FAILED: its status reason stays out of the message, which names the reason code instead. A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before, a role or policy name that is taken still reads as a name collision, and a role already gone at delete time still reads as not found.
• Removing AvailabilityZoneImpairmentPolicy from an AWS::AutoScaling::AutoScalingGroup now turns zonal shift off, as CloudFormation does (issue #1160) -- src/provisioning/providers/asg-provider.ts, tests/unit/provisioning/asg-provider-update-removal.test.ts, tests/integration/launchtemplate-asg-inplace/. Before this change, cdkd sent nothing for a removed policy, so the group kept zonal shift enabled and cdkd diff reported no changes afterwards. A real CloudFormation A/B showed that CloudFormation sends ZonalShiftEnabled: false with the previous ImpairedZoneHealthCheckBehavior, after which AWS reports no policy; cdkd now sends the same. The same A/B confirmed that CloudFormation keeps a removed DesiredCapacity and ServiceLinkedRoleARN, and sends only the newly declared member on a LaunchTemplate / MixedInstancesPolicy or VPCZoneIdentifier / AvailabilityZones switch, which is what cdkd already did.
• Removing Monitoring from an AWS::ECS::Service now resets the service's metric resolution, as CloudFormation does (issue #1160) -- src/provisioning/providers/ecs-provider.ts, tests/unit/provisioning/ecs-service-removal-1160d.test.ts, tests/integration/ecs-service-update-props/. Before this change, cdkd sent nothing to UpdateService when a template dropped Monitoring, so a service kept its old metric configuration (for example a 20-second resolution) indefinitely. A CloudFormation A/B showed CloudFormation resets the service revision to {metricConfigurations: []}, which cdkd now sends. The same A/B confirmed the existing behavior of three siblings: a removed VolumeConfigurations or VpcLatticeConfigurations is cleared, and a removed AvailabilityZoneRebalancing keeps its live value.
• AWS::RDS::DBProxy: removing Auth from the template is now refused before any AWS call, as CloudFormation's update fails on it; the FSx and DBProxy removal warnings now say when CloudFormation keeps the value too (issue #1160) -- src/provisioning/providers/rds-dbproxy-provider.ts, src/provisioning/providers/fsx-filesystem-provider.ts. A CloudFormation A/B on the issue (us-east-1) measured each removal. CloudFormation sends an Auth removal, and AWS refuses it while DefaultAuthScheme is NONE or unset. cdkd used to keep Auth and warn; it now stops the deploy with an error that says to declare Auth again. A rollback replay still keeps it and warns; drift --revert keeps it without a warning, as before. CloudFormation keeps a removed DBProxy RequireTLS / IdleClientTimeout / DebugLogging / VpcSecurityGroupIds, an FSx FileSystemTypeVersion, a Lustre DataCompressionType / AutoImportPolicy / WeeklyMaintenanceStartTime, and an OpenZFS AutomaticBackupRetentionDays / CopyTagsToBackups / CopyTagsToVolumes / DailyAutomaticBackupStartTime / WeeklyMaintenanceStartTime / DiskIopsConfiguration. cdkd already kept them, so only the warning changes: it now reads ... and keeps its current AWS value, as CloudFormation leaves it; .... A warning that names an unmeasured property (FSx StorageType, NetworkType, a Windows or ONTAP sub-property) keeps its old wording. Tests: tests/unit/provisioning/rds-dbproxy-provider.test.ts, tests/unit/provisioning/providers/fsx-filesystem-provider.test.ts; the fsx-lustre and rds-aurora integ needles now require the new wording.

Recently Implemented (2026-10-21):

• A name collision with this stack's own rollback-retained copy now says so (issue #5143) -- src/deployment/deploy-engine/replacement.ts, src/deployment/kept-in-history.ts, src/deployment/deploy-engine.ts, docs/cli-rollback-limitations.md. When a rolled-back deploy keeps a replacement's new copy because of UpdateReplacePolicy: Retain (as CloudFormation does), that copy keeps its fixed name. The next deploy that asks for the name is refused, and that is still the outcome. The refusal used to say only "another existing resource already holds the name ... delete it if it is yours". It now reads the stack's event history. When a rolled-back deploy of this stack kept this resource's replacement under that name, it says so, and says to delete the holder only if it is that copy and no longer needed. The read happens only on that refusal, so a successful deploy reads nothing more.
• Changing an AWS::ApiGateway::Method's Integration or MethodResponses now reaches AWS (issue #5140) -- src/provisioning/providers/apigateway-provider.ts. An update patched only the Method's own fields: a changed integration (for example its Uri, after the Lambda function behind a LambdaIntegration was replaced) was recorded in state but never sent, so the API kept invoking the old target, or answered 500 once it was deleted, after a green deploy. An update now puts the integration and its integration responses, and adds, changes or removes method and integration responses, in the order API Gateway accepts: PutIntegration replaces the integration and drops its integration responses, so they are put again, and a changed method response is deleted before it is put. Nothing extra is called when neither changed.
• Replacing an un-named AWS::Lambda::Permission no longer fails the name-idempotent guard, with or without --replace (issue #5137) -- src/provisioning/providers/lambda-permission-provider.ts, src/deployment/type-change-guard.ts, docs/provisioning-layers.md. The SDK provider sent the bare logical id as the statement id. When a permission was replaced (for example because its function was replaced behind an API Gateway method), the new statement came back under the old id, and the deploy refused it as "the create returned the existing resource". Under --replace it deleted the old statement and then failed to re-create the new one, because the new one already existed. On a stack with a stack instance id, the statement id is now generated as <StackName>-<LogicalId>-<suffix>, as CloudFormation does, with a new suffix for each replacement, so the replacement creates first. A legacy stack keeps sending the bare logical id. On either kind of stack, two records with the same id whose FunctionNames name different functions now count as two statements, so the old one is deleted from the old function. Existing records keep their ids.
• A declined --require-approval prompt now prints as one yellow line, as the AWS CDK CLI prints it, instead of a red failure reported twice (issue #5136) -- src/utils/error-handler.ts, src/deployment/deployment-approval.ts, src/deployment/work-graph.ts. Answering n used to print Failed: stack:<name>: ... and then Error: 1 node(s) failed: ... in red. The deploy now prints only Deployment of stack <name> was not approved (...). Nothing was changed. in yellow, and adds a line counting any dependent stacks it skipped. It still exits 1, because the template was not applied (the AWS CDK CLI's AbortError exits 1 too). A decline that happens alongside a genuine failure keeps the red failure report.
• A Cloud Map Service whose Description comes from a secret dynamic reference or a NoEcho parameter now keeps a removed HealthCheckConfig when the Description did not change, as CloudFormation does (issue #5112) -- src/types/resource.ts, src/deployment/deploy-engine/{update,update-in-place}.ts, src/provisioning/providers/servicediscovery-provider.ts. State records such a Description as its {{resolve:...}} token or ***, which the provider could not compare with the resolved value, so it treated it as changed: every update of that Service sent UpdateService (a Tags- or ServiceAttributes-only change included), clearing a removed HealthCheckConfig and, with a removed DnsConfig, failing. The deploy now hands providers the properties that changed template to template (UpdateContext.changedProperties), counting a masked or secret-derived value as changed when its template, inputs or secret version moved, or when AWS did not confirm a NoEcho value (for a Service, cdkd reads it back to check); the Service sends UpdateService only for a Description / HealthCheckConfig change among them. A rollback and cdkd drift --revert compare as before.
• A failed Cognito User Pool or Auto Scaling group create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/{cognito,asg}-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (for example AccessDeniedException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, through the operation's secret masker. This also covers the Auto Scaling group's note about a group whose create-time cleanup could not finish (the group and its delete command are still named), and the warning about a user pool whose partial-create cleanup failed. A cdkd-authored or transport error keeps its text, masked through the operation's secret masker on both providers (the Cognito wraps and the Auto Scaling group delete now apply it too). The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before, and an "already exists" is still stated as such.
• A failed ElastiCache subnet group or cache cluster, CloudTrail trail, CloudFront distribution or IAM access key create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/elasticache-provider.ts, cloudtrail-provider.ts, cloudfront-distribution-provider.ts, iam-access-key-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, masked through the operation's secret masker. This also covers a CloudFront distribution update whose tag change failed, and the IAM access key warnings about a denied key listing or a key cleanup that failed: they keep their remedy and command, with the class in place of AWS's text. A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before. A name that is already taken still says it already exists, so a create-first replacement still recognises the name collision.
• Removing VpcSecurityGroupIds from an RDS or Neptune DB cluster now moves the cluster to its VPC's default security group, as CloudFormation does (issue #1160) -- src/provisioning/providers/rds-provider.ts, neptune-provider.ts, docdb-provider.ts, tests/unit/provisioning/db-cluster-sg-removal-1160.test.ts. Before this change, cdkd sent no security groups when the property was removed, and ModifyDBCluster then kept the removed groups attached while the deploy reported success. A real CloudFormation A/B showed CloudFormation attaches the VPC's default security group in place of the removed ones on AWS::RDS::DBCluster and AWS::Neptune::DBCluster. cdkd now finds that group (the cluster's DB subnet group gives the VPC; ec2:DescribeSecurityGroups gives the group named default) and sends it. If the group cannot be found, the update fails before any change and says to declare VpcSecurityGroupIds. The lookup runs only on this removal, and the deploy credentials need ec2:DescribeSecurityGroups for it. A warning names the group attached. An update that changes a cluster's security groups (this reset, or a changed declared list, DocDB included) now waits until the cluster reports the new groups active and each member instance is available, as CloudFormation does, so a member instance's own change in the same deploy is no longer refused with "Database instance is not in available state"; --no-wait skips the wait, as it does on create. An empty list is still never sent, and cdkd drift --revert does not reset. AWS::DocDB::DBCluster is unchanged: CloudFormation keeps a DocDB cluster's groups on removal, and so does cdkd.
• A Firehose delivery stream now applies every destination sub-field its template declares, on create and on an ExtendedS3 update (issue #1160) -- src/provisioning/providers/firehose-provider.ts, tests/unit/provisioning/firehose-provider-removal-1160.test.ts, firehose-provider-readcurrentstate.test.ts, and tests/integration/stream-delete-redeploy/ (Phase 1 and Phase 3c). Before this change, FileExtension, CustomTimeZone and DynamicPartitioningConfiguration were dropped from ExtendedS3 creates and updates. A stream therefore came up without them, a change to them was never applied, and a dynamic-partitioning stream could be neither created nor updated: UpdateDestination refuses a call that omits that block. Creates also dropped SecretsManagerConfiguration on HttpEndpoint, Redshift and Splunk destinations, RetryOptions and the S3 backup settings on Redshift, BufferingHints on Splunk, and VpcConfiguration / DocumentIdOptions on the OpenSearch and Elasticsearch destinations. cdkd drift now reads FileExtension / CustomTimeZone too. A stream deployed earlier still lacks these fields after the upgrade, because an unchanged template sends nothing. To apply them, change the destination or redeploy with --replace. VpcConfiguration is create-only on the OpenSearch and Elasticsearch destinations, so it takes effect only through --replace. A destination sub-field REMOVED from the template still stays at its live value. A live CloudFormation A/B showed CloudFormation keeps it as well (UpdateDestination merges), so the unit suite pins that no reset value is sent.
• AWS::Glue::Crawler: a deploy now names an optional property removed from the template, and says CloudFormation keeps the value too (issue #1160) -- src/provisioning/providers/glue-provider.ts. A CloudFormation A/B on the issue (us-east-1) covered all ten optional schema properties: DatabaseName, Description, Classifiers, TablePrefix, Schedule, SchemaChangePolicy, RecrawlPolicy, LakeFormationConfiguration, Configuration and CrawlerSecurityConfiguration. They were removed all at once, first with no other change and then beside a Targets change. CloudFormation kept every live value, because its UpdateCrawler carries only Name, Role and Targets. cdkd already left them out, so what reaches AWS does not change. Before, the removal passed silently. Now the deploy prints one line, ... were removed from the template and keep their current AWS value, as CloudFormation leaves them; UpdateCrawler keeps a setting it is not sent., and a rollback revert prints its own wording. LineageConfiguration, which cdkd accepts but the CloudFormation schema lacks, is kept and named too, without the CloudFormation clause. Tests: tests/unit/provisioning/glue-crawler-removal-1160.test.ts. The glue-update-hardening integ fixture's phase 2g now removes four crawler properties and asserts that the values are kept and that the line is printed.

Recently Implemented (2026-10-20):

• A DynamoDB table replaced under the same name is no longer left deleted with nothing in its place when its re-create comes too soon (issue #5131) -- src/provisioning/providers/dynamodb-table-provider.ts, src/types/resource.ts, src/deployment/deploy-engine/{replacement,update-replace,update-in-place}.ts, src/deployment/rollback-executor/replay-reverse-replacement.ts. A replacement that deletes the old table first and re-creates it under the same name (--replace's delete-first fallback, --recreate-via-*, an update the provisioning layer rejects, and a rollback reversing one) could fail the re-create with ResourceInUseException: DeleteTable returns while the table is still DELETING, and DynamoDB keeps the name until it is gone, so the deploy ended with the old table deleted and no new one. These re-creates now wait (bounded, and Ctrl+C stops it) until DescribeTable reports the table gone. cdkd destroy and every other deploy path make no extra call.
• A replacement that deleted the old resource first is no longer abandoned half-way when another resource of the same deploy fails (issue #5118) -- src/deployment/deploy-engine.ts, src/deployment/deploy-engine/{replacement,update-replace,update-in-place,deploy-flow}.ts. cdkd deploy --replace (and --recreate-via-*, an update the provisioning layer rejects, a resource that went with its re-created parent) can delete a resource first and re-create it under the same name. When the re-create met the service's late release of that name (DynamoDB's Table already exists while the old table is still deleting) or a throttle, it retries -- but a failure of any other resource in the same deploy stopped that retry, leaving the stack with neither the old nor the new resource while state still recorded it. Only the user's interrupt (Ctrl+C) stops that retry now, including a Ctrl+C pressed after another resource has already failed; a sibling's failure lets it finish. Ctrl+C now also stops the automatic rollback, which keeps its journal so cdkd rollback finishes it.
• cdkd destroy: a stack recorded in a region other than the CLI's deletes its Cloud Control-routed resources again (issue #5115) -- src/cli/commands/destroy-runner.ts. Since #4941 the cross-region destroy built its provider registry before entering the stack's AWS scope, and the registry's constructor builds its Cloud Control and custom-resource fallbacks there, so both captured the CLI region's clients. Every Cloud Control-routed resource (e.g. AWS::ApiGateway::RestApi) was then refused with AWS client region us-east-1 does not match stack state region ... and the stack was left half-destroyed (the refusal touched nothing in the wrong region). The registry is now built inside the scope, as deploy, diff, drift, rollback and orphan already do. Workaround on older versions: run destroy with AWS_REGION=<stack region>. Tests: tests/unit/cli/destroy-nested-cross-region-scope-4941.test.ts.
• AWS::ServiceDiscovery::Service: a create right after its namespace no longer fails on Cloud Map's NamespaceNotFound lag (issue #5113) -- src/provisioning/providers/servicediscovery-provider.ts. Cloud Map can answer CreateService with NamespaceNotFound just after the namespace's create operation reported SUCCESS (seen live: one of four parallel creates against a fresh namespace), and cdkd sent the call once, so the deploy failed and rolled back. cdkd now retries that error only, for about 30 seconds (27.5s of backoff); every other error still fails at once, and a create that gives up says it retried. The rejection creates no service, so a retry cannot duplicate one. Tests: tests/unit/provisioning/servicediscovery-provider-create-namespace-retry-5113.test.ts; the servicediscovery integ fixture exercises the path.
• A replaced resource whose delete was refused "in use" is no longer lost when the deploy stops before its cleanup (issue #5111) -- src/deployment/superseded-resources.ts, src/deployment/deploy-engine/{replacement,superseded-retry,execute,deploy-flow}.ts, src/cli/commands/destroy-runner.ts, src/types/state.ts. A replacement whose old resource was still used by something the deploy had yet to update (an ELBv2 target group behind a listener) deferred that delete to the end of the deploy, but only in memory, while state already recorded the new resource: a deploy killed, crashed or interrupted before the end left the old resource in AWS with no record, and nothing ever deleted it -- it survived cdkd destroy and kept billing. The old resource is now recorded in state (supersededResources, additive, no schema bump) by the same save that records the replacement. Every later deploy, an unchanged one included, retries its delete after its own changes and drops the record once it is gone; cdkd destroy deletes it after the stack's own resources and keeps the state while it fails. The end-of-deploy retry also waits out an "in use" refusal for up to a minute (a deleted load balancer's listeners go asynchronously; an endpoint moving off a Lambda web function revision), and a delete still refused keeps the record with a warning naming the next deploy and cdkd destroy as the remedy.
• A rollback re-creates a replaced resource's old copy before reverting what references it (issue #5064) -- src/deployment/rollback-executor.ts, src/deployment/rollback-executor/plan.ts, replay-reverse-replacement.ts, replay-scope.ts, src/deployment/superseded-resources.ts, src/cli/commands/rollback.ts, src/deployment/nested-child-journal.ts. When a replacement gave the resource a new physical id (a generated name at its next generation, or a renamed resource), cdkd rollback and the automatic rollback reverted the resources that moved onto it (an IAM managed policy's Roles, an inline policy's role) BEFORE re-creating the old resource, so they named one AWS no longer had ("The role with name ... cannot be found") and the rollback exited with a partial failure. The old resource is now re-created before the first revert that may reference it (and before a replaced resource its own old properties reference), and the new one is deleted after those reverts, as CloudFormation does. Until that delete runs, cdkd rollback keeps the new resource in supersededResources, so a killed run leaves it for the next deploy to delete; there it also stays, for both rollbacks, when its delete fails or a resource still using it did not revert, and when cdkd rollback is interrupted. A same-physical-id re-create, a delete-first reversal, and one whose old id another record still holds keep their order.
• A failed custom resource create or update no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/custom-resource-provider.ts, and unit cases. When the backing Lambda Invoke, the SNS Publish or the response placeholder PutObject was denied, the thrown message quoted AWS's raw text, which names the caller, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDeniedException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, masked through the operation's secret masker. A backing Lambda that never became ready keeps its StateReasonCode / LastUpdateStatusReasonCode in the message, but the reason sentence, which AWS words with ARNs, goes to the debug log too. The retry warning for a denial before the request was delivered, and the warning for a delete whose handler could not be reached, name the class too. The handler's own FAILED reason and other cdkd-authored errors keep their text. An IAM grant that is still propagating is retried as before: that retry runs on AWS's own error inside the invoke loop, before the message is built. The AWS error stays as the cause.
• AWS::ApiGatewayV2::*: the remaining properties removed from the template now follow CloudFormation (issue #1160) -- src/provisioning/providers/apigatewayv2-provider.ts. A removed Authorizer IdentitySource is now cleared (UpdateAuthorizer gets []); before, cdkd left it in place. As in CloudFormation, AWS refuses that clear for a JWT authorizer or a REQUEST authorizer with caching on. A forward deploy that removes an Integration IntegrationSubtype without declaring an IntegrationUri is now refused before any call, because CloudFormation fails that update. Before, cdkd reported success and kept the subtype. Declared beside an IntegrationUri, it is sent without the subtype, as CloudFormation does. A rollback replay keeps a subtype the live integration still has, and warns. Every other removable property (Api RouteSelectionExpression; Stage Description / DefaultRouteSettings; Integration IntegrationUri / IntegrationMethod / PayloadFormatVersion / TimeoutInMillis and the other #609 fields; Route Target / ModelSelectionExpression / RouteResponseSelectionExpression; Authorizer AuthorizerUri / EnableSimpleResponses / JwtConfiguration) is kept, as before. Also fixed: an update to an EventBridge-PutEvents service integration that did not change its RequestParameters (a Description-only change, for example) failed with requires enabling passthrough, or defining all of the following parameters. AWS re-validates the parameter mapping on every update, so cdkd now re-sends the declared map beside the subtype; a declared map missing a required key still fails, as it does in CloudFormation, and a redacted secret stand-in in it refuses instead of being sent. Tests: apigatewayv2-provider-roundtrip.test.ts; integ apigatewayv2-update-removal phases 2, 2b, 2c.
• AWS::EC2::Instance property removals now match CloudFormation: a removed Monitoring is turned off, and a removed DisableApiTermination is refused (issue #1160) -- Two rounds of real CloudFormation A/B decide each case. When Monitoring is removed, CloudFormation turns detailed monitoring off. cdkd used to send nothing, so monitoring stayed on; it now calls UnmonitorInstances. A removed MetadataOptions or CreditSpecification keeps its live value, in both. When DisableApiTermination is removed (from true or false), CloudFormation fails the whole update and keeps the value, but it applies an explicit true / false. cdkd used to drop the removal silently and leave protection on. A deploy that removes it now fails before any AWS call, other changes in the same update included. The error names the instance and says to keep the property declared and set it to false to turn protection off. A rollback that restores a state without the property does not refuse: the user cannot edit that state, so the rollback leaves protection as it is and warns when it was on. cdkd drift --revert is unchanged. Changed: src/provisioning/providers/ec2-provider.ts, tests/unit/provisioning/ec2-provider-instance-removal-1160.test.ts, tests/integration/ec2-instance/.
• AWS::ElasticLoadBalancingV2::Listener: the warning for a removed AlpnPolicy, MutualAuthentication, Certificates, SslPolicy, Port or Protocol now says CloudFormation keeps the value too (issue #1160) -- src/provisioning/providers/elbv2-provider.ts. A CloudFormation A/B on the issue (us-east-1, each property removed alone and beside a DefaultActions change) showed CloudFormation keeps all six live values and no update fails. cdkd already kept them, because ModifyListener keeps a field it is not sent, so the behaviour does not change. The deploy warning used to make no claim about CloudFormation; it now reads ... were removed from the template and keep their current AWS value, as CloudFormation leaves them; .... The rollback wording is unchanged. Tests: tests/unit/provisioning/elbv2-listener-removal-1160.test.ts; the alb integ fixture gains a phase that drops the listener's Port and Protocol.
• AWS::EMR::Cluster / AWS::EMR::InstanceFleetConfig: the warning for a removed StepConcurrencyLevel, ResizeSpecifications or InstanceTypeConfigs now says CloudFormation keeps the value too (issue #1160) -- src/provisioning/providers/emr-cluster-provider.ts, src/provisioning/providers/emr-instance-fleet-config-provider.ts. A CloudFormation A/B on the issue (us-east-1, a fleet cluster with a running TASK fleet; each property removed alone, and StepConcurrencyLevel / ResizeSpecifications also beside a companion change) showed CloudFormation keeps all three live values and no update fails, although its documented StepConcurrencyLevel default is 1. cdkd already kept them, because ModifyCluster / ModifyInstanceFleet keep a field they are not sent, so the behaviour does not change. The deploy warning used to make no claim about CloudFormation; it now reads ... was removed from the template and keeps its current AWS value, as CloudFormation leaves it; .... The rollback wording is unchanged. Tests: tests/unit/provisioning/providers/emr-cluster-provider-removal-1160.test.ts, tests/unit/provisioning/providers/emr-instance-fleet-config-provider-removal-1160.test.ts; the emr-cluster and emr-instance-fleets integ fixtures' Phase 2b needles now require the new wording.
• AWS::KMS::Key: a removed RotationPeriodInDays or KeyPolicy is reset, as CloudFormation does (issue #1160) -- src/provisioning/providers/kms-provider.ts. A CloudFormation A/B showed that a Key update resets a removed RotationPeriodInDays to 365 and a removed KeyPolicy to the KMS default key policy (Id: key-default-1, kms:* for the account root), alone and beside another change. cdkd sent nothing for either, so the old period and policy stayed. It now re-sends the period with EnableKeyRotation whenever it changes while rotation stays on (a period change was dropped too), and puts the default policy, named from the key ARN's partition and account. cdkd drift --revert still never puts a policy it did not read. The update follows CloudFormation's order: EnableKey, the rotation calls, DisableKey, then tags and the key policy, so a policy denying kms:DisableKey deploys. A rotation change on a key that stays disabled fails, as it does in CloudFormation, and the error now says to enable the key first (declare Enabled: true, or enable it in AWS) or drop the rotation change. A string 'false' for Enabled or EnableKeyRotation (a String parameter's Ref) now reads as false on create and update, as in CloudFormation; it used to turn rotation on and leave the key enabled. The existing resets of a removed Description, Enabled and EnableKeyRotation already matched CloudFormation. Tests: tests/unit/provisioning/kms-provider-removal-1160.test.ts; the kms-encryption integ fixture gains a verify.sh with a removal phase.
• AWS::Lambda::EventSourceMapping: a BatchSize removed from the template is reset to the source's default, and a removed LoggingConfig or ProvisionedPollerConfig on a Kafka mapping is cleared, as CloudFormation does (issue #1160) -- src/provisioning/providers/lambda-eventsource-provider.ts. UpdateEventSourceMapping keeps a field it is not sent, so cdkd used to leave all three at their old AWS value while the deploy succeeded and cdkd diff reported no changes. A CloudFormation A/B (us-east-1; CloudTrail read of the update CloudFormation sent) measured the reset on SQS, DynamoDB-stream and self-managed Kafka mappings: BatchSize 10 for SQS and 100 for DynamoDB and self-managed Kafka, and {} for a self-managed Kafka mapping's LoggingConfig / ProvisionedPollerConfig. Kinesis, MQ and DocumentDB take the Lambda API reference default of 100, MSK is assumed to match self-managed Kafka, and an unclassifiable source gets nothing. CloudFormation keeps an SQS mapping's ProvisionedPollerConfig and a Kafka mapping's MaximumBatchingWindowInSeconds, and cdkd still does too. Tests: tests/unit/provisioning/lambda-eventsource-provider.test.ts; the sqs-esm-max-concurrency integ fixture now drops batchSize in its update phase, and lambda-esm-self-managed-kafka gains a Phase 2c dropping BatchSize, the poller config and a LoggingConfig.
• AWS::Route53::HostedZone: removing VPCs from a private hosted zone now prints a warning that the zone keeps its VPC associations, as CloudFormation does (issue #1160) -- src/provisioning/providers/route53-provider.ts. A CloudFormation A/B on the issue (us-east-1) showed CloudFormation keeps every association when VPCs is removed whole, from a zone with one VPC or two, or set to [], and no update fails. cdkd already kept them, so no AWS call changes. The deploy used to say nothing; it now warns <LogicalId> (AWS::Route53::HostedZone): VPCs was removed from the template, and the zone keeps its current VPC associations, as CloudFormation leaves them. .... A rollback revert gets its own wording, and cdkd drift --revert does not warn. Dropping some VPCs while keeping others still disassociates the dropped ones. Tests: tests/unit/provisioning/route53-hostedzone-vpcs-removal-1160.test.ts; the ec2-vpc integ fixture gains a private hosted zone whose VPCs its removal phase drops.
• AWS::ServiceDiscovery::Service: a Description, DnsConfig or HealthCheckConfig removed from the template now follows CloudFormation (issue #1160) -- src/provisioning/providers/servicediscovery-provider.ts. UpdateService replaces its body, and cdkd sent it whenever any of the three was declared, so a removal on its own cleared a removed Description / HealthCheckConfig and failed the deploy for a removed DnsConfig (Service dns config cannot be null). CloudFormation A/Bs on the issue showed it sends the update only when a declared Description or HealthCheckConfig changed, with the declared values as they are; cdkd now does the same: a removal on its own keeps the value, and beside such a change a removed field is cleared (a removed DnsConfig is refused by AWS, as for CloudFormation). Deliberate divergence: CloudFormation drops a DnsConfig.DnsRecords-only change (a TTL); cdkd applies it and keeps any removed Description / HealthCheckConfig from the live service. Known divergence: an unchanged Description recorded as any dynamic reference ({{resolve:...}}) or a NoEcho *** counts as changed, so a HealthCheckConfig removed beside it is cleared (#5112). The type is audited into removalHandledInUpdate. Tests: tests/unit/provisioning/providers/servicediscovery-provider.test.ts; the servicediscovery integ fixture gains three removal phases.

Recently Implemented (2026-10-19):

• cdkd rollback now reverses a replacement that re-created a resource under the same physical id, instead of reporting success over it (issue #5096) -- src/deployment/rollback-executor/plan.ts. A replacement that deleted the old resource first and re-created it under the same name (cdkd deploy --replace's delete-first fallback, a fixed-name --recreate-via-*, an update the provisioning layer rejects) was rolled back in place: the provider could not change the create-only property, so the re-created resource stayed while the rollback wrote the old record into state and reported success. Such a replacement is now reversed: the re-created resource is deleted and the old one re-created, as for any delete-first replacement; a re-run after a completed reversal does nothing. When the stack records a resource AWS stores inside it (a function's permission, a topic's subscription, a role's inline policy), which deleting it again would take too, the rollback refuses that resource before deleting anything and names cdkd deploy --replace of the previous template as the fix. It refuses the same way when every property the deploy changed is a secret redacted identically in state before and after, since state then cannot tell whether an earlier rollback already reversed it.
• An un-named resource gets the same generated name on the SDK provider and Cloud Control routes (issue #5095) -- src/provisioning/resource-name.ts, every SDK provider that generates a name, src/deployment/deploy-engine/routing.ts, src/deployment/deploy-engine/update-in-place.ts, src/deployment/replacement-name-holder/. Each type now has one name rule that both routes read. A Cloud Control create of an un-named AWS::CodeCommit::Repository, AWS::RDS::DBProxy or AWS::RDS::DBProxyEndpoint used to fail, because their schemas require the name; it now gets the name the SDK provider gives. An un-named AWS::S3Express::DirectoryBucket on Cloud Control used to be sent a name without the required --<zone id>--x-s3 suffix; it now gets the suffix from LocationName, and a create whose LocationName is not a zone id is refused with the fix named. On a stack with a stack instance id, an un-named CodeBuild project, EC2 security group, CloudTrail trail, Glue job, crawler, connection or trigger, or Firehose delivery stream is now named {stackName}-{logicalId}-{suffix} instead of its bare logical id, which collided across stacks sharing a VPC or account and region and on every replacement, and Cloud Control names log groups, SSM parameters, Auto Scaling groups, DynamoDB global tables, ECS task definitions, Lambda network connectors, EventBridge pipes and Scheduler schedules as their SDK providers do. Neither route generates an AWS::Events::EventBus name any more: CloudFormation requires it. Stacks without an instance id keep every name either route generated before.
• A redacted AWS failure whose class name contains AlreadyExists is no longer retried as a name collision when AWS's own message describes something else (issue #5088) -- src/deployment/retryable-errors/name-collision.ts. A provider wrap that withholds AWS's text reduces the failure to its class, such as HostedZoneAlreadyExists. Re-run with --verbose for AWS's own message. The delete-then-re-create retry filter read that class as an "already exists" collision. Route 53's HostedZoneAlreadyExists reports a reused caller reference, not a taken name, and S3's BucketAlreadyExists reports a name held by another account. Both were retried for about 64 seconds before failing. For a wrap marked as withholding text, the filter now ignores the class in that reduced message and reads AWS's own message on the cause chain, plus any "AWS reports that it already exists." sentence the provider restated. Genuine collisions and name cooldowns are still retried. Tests: tests/unit/deployment/redacted-already-exists-class-5088.test.ts.
• A 1-3 character secret embedded in a literal no longer reaches state.json in plaintext when a failed deploy trims a lost attachment's record (issue #5076) -- src/deployment/deploy-engine/execute.ts, src/deployment/deploy-engine/record-shape.ts, src/deployment/secret-redaction/pairs.ts. When a deploy fails after re-creating an IAM principal under the same name, cdkd keeps the record of a resource that lost its attachment, with the re-created principal dropped from its lists. The rebuilt record was a plain copy that lost the marks the original record carried. A resource whose record this deploy had already installed was then saved without the claim that lets a secret below the value scan's 4-character floor be stored as its reference. Examples are a Cloud Control update that sent nothing, and an update that failed after recording. The copy now carries the original's redaction marks, and adds none it lacked. Tests: tests/unit/deployment/deploy-engine-lost-attachment-marks-5076.test.ts.
• Changing an AWS::EC2::NetworkAclEntry's rule (for example RuleAction from allow to deny, or its CidrBlock, Protocol, PortRange or Icmp) now updates the entry in place with one ReplaceNetworkAclEntry call, as CloudFormation does, instead of failing the deploy as not updatable (issue #5070) -- src/provisioning/providers/ec2-provider.ts, tests/unit/provisioning/ec2-nacl-entry-replace-5070.test.ts, and the ec2-vpc integ's Phase 2. The refusal's suggested cdkd deploy --replace deleted the entry and created it again, leaving the rule number absent between the two calls so traffic fell through to the next rule. A rollback of the change, and cdkd drift --revert of a console-side rule edit, now replace the rule back in place too. A change to NetworkAclId, RuleNumber or Egress is createOnly and still replaces the entry.
• Changing an AWS::EC2::Route's target (for example GatewayId to TransitGatewayId) now updates the route in place with one ReplaceRoute call, as CloudFormation does, instead of deleting and re-creating it (issue #5068) -- src/provisioning/providers/ec2-provider.ts, tests/unit/provisioning/ec2-route-replace-5068.test.ts, and the ec2-route-targets integ's Phase 2. The old DeleteRoute + CreateRoute left the route table without the route between the two calls, so traffic to that destination dropped for the window, and a refused create (a target not yet attached, a permission, a throttle) left the route deleted. The update now reports the route as updated in place rather than replaced, and a rollback of a target change replaces the target back. A change to the route table or destination is createOnly and still replaces the route.
• New stacks get CloudFormation-style generated names: {stackName}-{logicalId}-{suffix} (issue #5064, part 2) -- src/provisioning/resource-name.ts, src/deployment/deploy-engine/deploy-flow.ts, src/deployment/deploy-engine.ts, the IAM role / managed policy / inline policy and EventBridge rule providers, and the commands that replay provider calls (cdkd rollback, drift --revert, state refresh, destroy). A resource the template does not name, in a stack whose record carries a stack instance id (every stack first deployed by this version), is named {stackName}-{logicalId}- plus 12 hex characters derived from that id and the logical id; the {stackName}-{logicalId} part is cut so the whole fits the type's limit. The name stays the same until the resource is replaced (part 3). After cdkd destroy, a redeploy gets a new id and new names, so it no longer collides with, or takes back, a resource a DeletionPolicy: Retain (or cdkd state orphan) left behind; the first deploy warns once and names cdkd import for adopting such a resource. Existing stacks keep their names: a stack whose record predates the id keeps {stackName}-{logicalId}, and nothing is renamed or replaced. Declared names never change. An update() that re-derives a name keeps the recorded one of an un-named resource rather than replace it; cdkd drift --revert of an un-named EventBridge rule now updates the rule its ARN names, where it used to send PutRule under the bare logical id and create a second rule on a legacy stack. Generated names now stay within each service's limit for long stack names, where they used to fail: Lambda capacity provider (64), CloudWatch alarm (255), CodeBuild project (150) and S3 directory bucket (63 with its zone suffix).
• A replaced auto-named resource gets a new name and is created before the old one is deleted, as in CloudFormation (issue #5064, part 3) -- src/state/name-generation.ts, src/provisioning/resource-name.ts, src/deployment/deploy-engine/update*.ts, replacement.ts, create.ts, execute.ts, deploy-flow.ts, src/deployment/generated-name-guard.ts, orphan-adoption.ts, the rollback executor, cdkd import, cdkd orphan. On a stack with a stack instance id, a resource the template does not name records its name generation (state v13, nameGeneration). A replacement (an immutable property, --recreate-via-*, an update the provisioning layer rejects) creates the new resource under the next generation's name first and then deletes the old one, with no --replace; a collision on that name refuses and names cdkd import, and --replace deletes nothing. A crash re-run asks for the same name (the generated-name guard takes back what the killed run made); a rollback restores the old resource and remembers the generation reached, so the retry gets a new name. A resource removed from the template (deleted, Retain, cdkd orphan) and later re-added gets a new name, and what a rollback left in AWS under Retain is no longer taken back: the deploy creates a new resource and names cdkd import. A CREATE a rollback took back (the automatic rollback, cdkd rollback, a nested child's) is created under a new name next time, as in CloudFormation, so a type that refuses a just-deleted name for a while (an SQS queue, a Secrets Manager secret) does not fail the retry. Legacy stacks keep their names and today's replacement behavior.
• State schema v13: a stack records the id of its current lifetime (issue #5064, part 1) -- src/types/state.ts, src/state/stack-instance-id.ts, src/state/s3-state-backend.ts, src/deployment/deploy-engine/deploy-flow.ts, src/cli/commands/import.ts, src/cli/commands/state.ts. A stack's first state write (its first deploy, the partial save of a failed first deploy, or cdkd import creating the record) records stackInstanceId, a random id kept until the record is deleted; a recreated stack gets a new one. Once a first deploy is going ahead (past --require-approval), it writes the id to stack-instance.json beside state.json before any resource is created, so a re-run after a crash reuses it; the object is deleted once state.json carries the id, and with the record on destroy, state orphan, export and a rolled-back first deploy. A stack whose record an older cdkd wrote never gets one (legacy), and a deploy of a stack with a record makes no extra AWS call; a first deploy adds one read and one write, --dry-run none. cdkd never prints the id (cdkd state show --json shows <withheld>). Generated resource names derive from it (part 2). Older binaries fail on v13 with "Upgrade cdkd".
• A 1-3 character secret embedded in a literal no longer reaches state.json in plaintext when a provider records its own effectiveProperties (issue #5063) -- src/deployment/secret-redaction/pairs.ts, src/deployment/deploy-engine/record-shape.ts, src/deployment/deploy-engine.ts, src/deployment/deploy-engine/rollback.ts, src/deployment/rollback-executor/replay-retry.ts, src/deployment/rollback-executor/replay-secrets.ts. Nine providers record a spread of the resolved properties they were handed (S3, Kinesis, AppSync, Cognito, the DynamoDB global table, the nested stack, the RDS proxy target group, the Secrets Manager secret, and the EC2 security group ingress), for example a Tags[].Value or a Description. Such a bag was never given the claim that lets a secret below the value scan's 4-character floor be written as its reference, because a provider may carry a previous value into it. It is now LEAF-certified: the redaction claim holds per leaf, since every arm the claim relaxes accepts a leaf only where it equals this deploy's own rendering of the template, so a carried value keeps its old answer. This applies on the deploy, in the rollback journal, and when a rollback replay restores the record. The v12 reference provenance of such a record is unchanged. Tests: tests/unit/deployment/deploy-engine-leaf-certified-5063.test.ts, tests/unit/deployment/deploy-engine-short-embedded-secret.test.ts, tests/unit/deployment/secret-redaction-context-1940.test.ts; integ tests/integration/secrets-dynamic-ref (a Kinesis stream tag).
• A 1-3 character secret embedded in a literal beside a public ssm reference no longer reaches state.json in plaintext (issue #5056) -- src/deployment/secret-redaction/positions.ts, src/deployment/deploy-engine/update.ts. Such a secret is below the value scan's 4-character floor, so only its position can redact it. Before, a literal such as postgres://{{resolve:ssm:/db/host}}:5432/?pin={{resolve:secretsmanager:...}} was persisted with the pin in plaintext: the position arm refused the whole leaf because the public token has no secret pair. A deploy now persists the secret span as its reference and the public span as its resolved value, where this deploy's own lookup proved the parameter public and the leaf is exactly that rendering; any leaf the value scan would answer differently keeps its old form. A record an older cdkd wrote with the plaintext spelling is rewritten on the next deploy without an UPDATE when the template is unchanged. A rollback replay can now state the same generation claim as the deploy for a provider bag the provider marked; no provider marks one on a replay today, so a provider's effectiveProperties echoing such a secret keeps the residual (issue #5063). Tests: tests/unit/deployment/secret-redaction-subfloor-5056.test.ts, tests/unit/deployment/deploy-engine-mixed-literal-legacy-repair-5056.test.ts, tests/unit/deployment/secret-redaction-context-1940.test.ts.
• A failed ACM certificate, Lambda web function revision or endpoint, Lambda MicroVM image, event source mapping or function URL create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/acm-certificate-provider.ts, lambda-web-function-revision-provider.ts, lambda-web-function-endpoint-provider.ts, lambda-microvm-image-provider.ts, lambda-eventsource-provider.ts, lambda-url-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDeniedException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, masked through the operation's secret masker. This also covers a web function revision or endpoint that AWS reports as Failed: its status reason stays out of the message (a revision keeps its build error's code). A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before. An occupied name (an event source mapping or MicroVM image that already exists) still says it already exists, so a create-first replacement still recognises the name collision. An ACM create whose cleanup could not delete the requested certificate still names it.
• A failed AppSync (GraphQLApi, GraphQLSchema, DataSource, Resolver, ApiKey) create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/appsync-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an AccessDeniedException (or S3's AccessDenied when a *S3Location object cannot be fetched), and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDeniedException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, masked where the operation has a secret masker. A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before, and an occupied name still says it already exists, so a create-first replacement still recognises the name collision.
• A failed DynamoDB Table or GlobalTable create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/dynamodb-table-provider.ts, dynamodb-globaltable-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an AccessDeniedException, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDeniedException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, masked with the operation's secret masker. A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before. An occupied name (Table already exists) still says it already exists, so a create-first replacement still recognises the name collision, and a delete that gives up on a busy global secondary index still says so and that re-running the destroy succeeds once the index is ACTIVE. The GlobalTable TimeToLive rate-limit refusal closes the class as one sentence before its remedy.
• A failed EMR (Cluster, InstanceGroupConfig, InstanceFleetConfig), FSx FileSystem or EFS (FileSystem, MountTarget, AccessPoint) create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/{emr-cluster,emr-instance-group-config,emr-instance-fleet-config,fsx-filesystem,efs}-provider.ts, src/utils/aws-failure-text.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDeniedException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, through the operation's secret masker. This also covers the EMR cluster's describe-before-delete and termination-poll failures and the FSx file system's deletion-poll failure. A failed or terminal state that EMR or FSx reports (EMR's state-change reason, which can name an IAM role ARN, and FSx's failure details) is named the same way, by EMR's reason code where there is one. A cdkd-authored or transport error keeps its text (on EFS still masked, as before). The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before, and an EMR or FSx create that left a resource behind still names it for cdkd rollback --revert-failed. An "already exists" is still stated as such.
• A failed Route 53 (HostedZone, RecordSet) or KMS (Key, Alias) create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/route53-provider.ts, kms-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access denial (and the account id in a KMS alias ARN), and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDenied. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, masked where the operation has a secret masker. This also covers the hosted zone's Accelerated Recovery and tag-removal failures and the record set's HostedZoneName lookup failure. A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant that is still propagating, or a zone locked during an Accelerated Recovery transition, is retried as before. An occupied name (a duplicate record, a KMS alias that already exists) still says it already exists, so a create-first replacement still recognises the name collision.
• A failed S3 Tables (TableBucket, Namespace, Table), API Gateway (Account, Authorizer, Resource, Deployment, Stage, Method) or API Gateway v2 (Api, Stage, Integration, Route, Authorizer) create, update or delete no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/s3-tables-provider.ts, apigateway-provider.ts, apigatewayv2-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an AccessDeniedException, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDeniedException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log, masked where the operation has a secret masker. A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before, and an occupied name (ConflictException ... already exists) still says it already exists, so a create-first replacement still recognises the name collision.
• Removing CloudWatchRoleArn from an AWS::ApiGateway::Account now clears the account's CloudWatch role, matching CloudFormation (issue #1160) -- A real CloudFormation A/B showed CloudFormation clears the region's API Gateway CloudWatch role ARN when the template stops declaring it. UpdateAccount is a patch call, and cdkd sent it with no operations for the removed property, so the old role ARN stayed set. cdkd now sends replace /cloudwatchRoleArn '' for a removed CloudWatchRoleArn, the same clear its delete already sends. Changed: src/provisioning/providers/apigateway-provider.ts, tests/unit/provisioning/apigateway-provider.test.ts, tests/integration/apigateway/.
• Removing EnableDnsHostnames or EnableDnsSupport from an AWS::EC2::VPC now resets it to the VPC default, matching CloudFormation (issue #1160) -- A real CloudFormation A/B showed CloudFormation resets a removed attribute: DNS hostnames back to off and DNS support back to on. ModifyVpcAttribute changes only the attribute it is sent, so cdkd used to leave the old value live (for example, DNS support kept off after the template stopped declaring it). cdkd now sends the default for each removed attribute, and sends nothing when the removed value already was the default. cdkd drift --revert writes no such reset. Changed: src/provisioning/providers/ec2-provider.ts, tests/unit/provisioning/ec2-vpc-dns-removal-1160.test.ts, tests/integration/ec2-vpc/.

Recently Implemented (2026-10-18):

• AWS::Events::EventBus: a template-declared Policy is now applied to the bus (issue #5044) -- src/provisioning/providers/eventbridge-bus-provider.ts. Before, the provider declared Policy handled but never sent it, so the deploy succeeded and the bus had no resource policy: a cross-account PutEvents the policy granted was refused. The bus is now created and then given the whole document through PutPermission (an object or a JSON string). An update with a changed Policy replaces the whole bus policy, statements a separate AWS::Events::EventBusPolicy added included, as CloudFormation does; an update that leaves Policy unchanged sends nothing for it, and removing Policy from the template leaves the live policy in place, as CloudFormation leaves it, with a warning saying so. A create or update refused by AWS now names the error class and points to --verbose instead of relaying AWS's text, which can carry the caller's assumed-role ARN into the persisted deployment journal (issue #2319). Tests: tests/unit/provisioning/eventbridge-bus-policy-5044.test.ts, integ tests/integration/eventbus-policy.
• A failure that cannot be converted to text no longer turns a best-effort handler in cdkd deploy or cdkd diff into a hard failure, nor replaces a provider's rejection with a TypeError (src/deployment/deploy-engine/{create,delete,deploy-flow,execute,observed-capture,outputs,provision,replacement,rollback,update-in-place,update-replace}.ts, src/cli/commands/diff-recursive.ts, go-to-k/cdkd#3361). These handlers built their message with x instanceof Error ? x.message : String(x) (or its x.message || x.name variant), and String() throws for a null-prototype object, so the handler itself threw: a failed per-resource, post-rollback or post-output-failure state save, a failed lock release, and a failed rollback-journal write, pop or delete stopped the deploy instead of warning; a failed observed-properties readback failed the deploy before its final state save; a failed output resolution off --strict-getatt failed instead of skipping the output; a failed final snapshot or old-resource delete during a replacement lost its handling; a failed DELETE was replaced by a TypeError before the not-found check and the per-resource failure report could read it; and cdkd diff's partial parameter binding and condition evaluation fallbacks failed the diff. Each now goes through describeAwsFailure(x).detail (safeStringify(x) on the output handler's String arm), byte-identical whenever the value converts and a placeholder only when it cannot. Tests: tests/unit/deployment/deploy-engine-string-outthrow-3361.test.ts.
• A failure that cannot be converted to text no longer turns a best-effort fallback of the intrinsic-function resolver into a hard failure (src/deployment/intrinsic-resolver/*, go-to-k/cdkd#3361). These handlers built their message with x instanceof Error ? x.message : String(x), and String() throws for a null-prototype object, so the handler itself threw: a failed CloudFormation ListExports / DescribeStacks fallback stopped Fn::ImportValue / Fn::GetStackOutput with a TypeError instead of the not-found error; an exports-index lookup failure skipped the state scan, a failed index write-through became an unhandled rejection, and one unreadable producer state stopped the scan instead of being skipped; a condition whose evaluation failed rejected the deploy instead of being assumed false; a failed Ipv6CidrBlocks / launch-template version read lost its [] / $Latest fallback; an Fn::Sub variable that failed to resolve stopped the deploy instead of keeping its placeholder, an abandoned dynamic reference stopped it instead of being recorded and reported, and a failed pinned recorded-reference read threw instead of answering failed; and Fn::GetAZs, the Fn::GetAtt refusal for a constructed attribute whose live read failed (DescribeSecurityGroups, DescribeInstances, GetNamespace or the provider read, via describeFailureObserved) and the lookup-role denial message replaced the failure they describe with the converter's TypeError. Each now goes through describeAwsFailure(x).detail (or safeStringify(x) for the bare form), byte-identical whenever the value converts (so every message's secret masking reads exactly the text it read before) and a placeholder only when it cannot. Tests: tests/unit/deployment/intrinsic-resolver-string-outthrow-3361.test.ts.
• A failure that cannot be converted to text no longer turns a rollback or destroy handler into a TypeError (src/deployment/rollback-executor/{replay-reverse-replacement,journaled-orphans,messages}.ts, src/cli/commands/{destroy,rollback}.ts, go-to-k/cdkd#3361). These handlers built their message with x instanceof Error ? x.message : String(x) (or a bare String(x)), and String() throws for a null-prototype object, so the handler itself threw. In a reverse replacement, a failed delete of the new resource after the old one was re-created failed the op instead of warning that the new resource is left untracked, and a failed re-create, or a failed delete of what it made, failed the op with Cannot convert object to primitive value instead of a placeholder naming the failure. The per-op failure line (rollbackFailureText) and cdkd rollback's journal-backend error lines (backendErrorText) rendered such a value with the same String() and are converted too. An unreadable rollback journal, or a failed journal rewrite after a successful deploy, threw instead of keeping the journal with a warning; cdkd destroy --purge-events threw instead of warning that the event history was not purged; and a synthesis failure in cdkd destroy threw instead of falling back to the state's stack list. Each now goes through describeAwsFailure(x).detail (or safeStringify(x) for the bare form), byte-identical whenever the value converts and a placeholder only when it cannot. Tests: tests/unit/deployment/rollback-executor-string-outthrow-3361.test.ts, tests/unit/cli/destroy-string-outthrow-3361.test.ts.
• A failed EC2 create, update or delete (VPC, Subnet, InternetGateway, EIP, VPCGatewayAttachment, NatGateway, RouteTable, Route, SubnetRouteTableAssociation, SecurityGroup, SecurityGroupIngress, Instance, NetworkAcl, NetworkAclEntry or SubnetNetworkAclAssociation, for each operation the type supports) no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events (issue #2319) -- src/provisioning/providers/ec2-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an UnauthorizedOperation, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (UnauthorizedOperation. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log. A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before; a security group whose name is taken still says it already exists, so a custom-named group's replacement is still handled as a name collision; and a create denied both with and without tags still says so.
• Removing a key from an AWS::ElasticLoadBalancingV2::Listener's ListenerAttributes now keeps its live value, matching CloudFormation (issue #1160) -- A real CloudFormation A/B showed CloudFormation KEEPS a removed listener attribute key, whether one key or the whole list is dropped. cdkd used to reset it (to the documented default for routing.http.response.server.enabled, to an empty value for other keys) and now sends nothing for it, as it already does for LoadBalancerAttributes and TargetGroupAttributes. A removed CORS key (routing.http.response.access_control_*, which CloudFormation also keeps) or request-header rename (routing.http.request.<header>.header_name) prints one warning naming the keys, since a kept one can keep a cross-origin grant live or leave the backend reading a header the ALB no longer writes. A listener recorded on Cloud Control still returns to the SDK provider on its next change, now for the SDK path's speed; both routes keep the key. Changed: src/provisioning/providers/elbv2-provider.ts, src/provisioning/provider-registry.ts (rationale only), the ELBv2 listener unit suites, tests/integration/alb/, docs/cli-deploy-safety-routing.md, docs/provider-rules.md, docs/state-schema-internals.md, docs/troubleshooting-internals.md.
• Removing Description, KmsKeyIdentifier, LogConfig or DeadLetterConfig from an AWS::Events::EventBus now clears it, matching CloudFormation (issue #1160) -- A real CloudFormation A/B showed CloudFormation clears each removed property: no description, the AWS owned key instead of the customer managed key, LogConfig at OFF / NONE, and no dead-letter queue. UpdateEventBus keeps any field it is not given, so cdkd used to leave all four live, including encryption with a key the template no longer names. cdkd now sends the clearing value for each one ('', '', OFF / NONE, an empty queue ARN). cdkd drift --revert writes no such clear. Changed: src/provisioning/providers/eventbridge-bus-provider.ts, tests/unit/provisioning/eventbridge-bus-removal-1160.test.ts, tests/integration/eventbridge/.

Recently Implemented (2026-10-17):

• A failure that cannot be converted to text no longer turns a best-effort handler in cdkd export, cdkd import, cdkd local start-api, cdkd orphan, asset publishing or config loading into a hard failure (src/cli/commands/{export,import,local-start-api}.ts, src/analyzer/orphan-rewriter.ts, src/assets/docker-asset-publisher.ts, src/cli/{config-loader,upload-cfn-template}.ts, src/synthesis/context-store.ts, go-to-k/cdkd#3361). These handlers built their message with x instanceof Error ? x.message : String(x) (or a bare String(x)), and String() throws for a null-prototype object, so the handler itself threw: an unreadable cdk.json / cdk.context.json failed the command instead of warning; a failed DescribeType skipped cdkd export's fallback identifier table; a provider lookup failure aborted the orphan reference rewrite instead of reporting the reference as unresolvable; a failed watcher close or tmpdir removal in local start-api's shutdown skipped the cleanup after it, the profile-credentials tmpdir removal among them, and a failed --warm pre-warm stopped the server from starting; cdkd export's lock release, template-upload cleanup and per-stack state removal stopped the run; and a docker push rejection was replaced by a TypeError before the ECR auth retry could classify it. The transient-template version purge (upload-cfn-template.ts), which nothing known today makes reject, is converted as defence in depth. Each now goes through describeAwsFailure(x).detail (or safeStringify(x) for the bare form), byte-identical whenever the value converts and a placeholder only when it cannot. Tests: tests/unit/cli/singletons-string-outthrow-3361.test.ts.
• A failed create, update or delete of a Glue Database, Table, SecurityConfiguration, Workflow, Job, Crawler, Connection or Trigger no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events, and no longer replaces the failure with a TypeError when the thrown value cannot be converted to text (issues #2319, #3341) -- src/provisioning/providers/glue-provider.ts, and unit cases. The thrown message quoted AWS's raw text, which names the caller on an access-denied error, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDeniedException. Re-run with --verbose for AWS's own message.), and AWS's text goes to the debug log through the operation's secret masker. A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant that is still propagating is retried as before, and an occupied table name is still classified as a name collision.
• Removing a property from an AWS::ElasticLoadBalancingV2::LoadBalancer or TargetGroup now does what a CloudFormation update does (issue #1160) -- A real CloudFormation A/B decided each case. A removed load balancer IpAddressType now resets to ipv4; before, it stayed dualstack. A removed HealthCheckPort on a GENEVE target group now resets to traffic-port like every other protocol; before, it kept its value. A key removed from LoadBalancerAttributes or TargetGroupAttributes now keeps its live value, because CloudFormation leaves it in place; before, cdkd reset it to a documented default or an empty value, and warned for a target group key it had no default for. A kept access_logs.s3.* / connection_logs.s3.* / health_check_logs.s3.* key prints one warning naming the keys, since the load balancer may keep delivering logs to the bucket they name. ListenerAttributes still resets. drift --revert writes no IpAddressType reset for a value its recorded baseline lacks. Changed: src/provisioning/providers/elbv2-provider.ts, tests/unit/provisioning/elbv2-tg-lb-removal-1160.test.ts and the existing ELBv2 suites, tests/integration/alb/.

Recently Implemented (2026-10-16):

• AWS published 1 writable property the 2026-10-16 schema refresh now carries, so cdkd classifies it instead of treating it as unrecognized (PR #5005) -- AWS::CloudWatch::Alarm: ActionConfiguration. Changed: tests/fixtures/cfn-schemas/, src/provisioning/property-coverage.generated.ts (regenerated). On AWS::CloudWatch::Alarm, no SDK provider writes it yet (not yet implemented by cdkd), so pre-flight classifies each as a silent drop and the issue #614 auto-route sends a resource whose template carries one through Cloud Control, which forwards the full property map. Since issue #3713 a key absent from the snapshot already routed so, unless the state record held it with the declared value; such a resource moves on its next deploy. AWS::CloudWatch::Alarm is not in STICKY_CC_MIGRATION_EXEMPT, so an existing SDK-provisioned resource of that type whose template gains one moves to Cloud Control and pins provisionedBy: 'cc-api' ONE-WAY. The snapshot marks none of them create-only, so createOnlyDrops and the record narrowing are unchanged; the capture is top-level-only, so it says nothing about a nested create-only path.
• Removing an ApiGatewayV2 property from a template no longer resets properties CloudFormation keeps (issue #5004) -- A real CloudFormation A/B showed CloudFormation leaves the live value of these when they are dropped from the template, so cdkd now sends nothing for them either (the live value stays): Api Description, Version, DisableExecuteApiEndpoint, IpAddressType, ApiKeySelectionExpression; Stage StageVariables (per key), ClientCertificateId; Integration Description, RequestParameters (per key); Route AuthorizationType, AuthorizerId, OperationName, RequestModels and RequestParameters (per key); Authorizer AuthorizerCredentialsArn, AuthorizerPayloadFormatVersion, AuthorizerResultTtlInSeconds, IdentityValidationExpression. Api CorsConfiguration, Stage AutoDeploy / AccessLogSettings / RouteSettings and Route AuthorizationScopes are reset by CloudFormation too and keep their resets. Changed: src/provisioning/providers/apigatewayv2-provider.ts, docs/provider-rules.md, the apigatewayv2-update-removal integ fixture and the ApiGatewayV2 unit tests. Route ApiKeyRequired was not measured and is still reset, and cdkd drift --revert still removes a console-added map key.
• Removing nine AWS::AutoScaling::AutoScalingGroup properties from a template no longer resets them, matching CloudFormation (issue #5004) -- A real CloudFormation A/B showed CloudFormation keeps the live value of a removed HealthCheckType, HealthCheckGracePeriod, Cooldown, TerminationPolicies, NewInstancesProtectedFromScaleIn, CapacityRebalance, DesiredCapacityType, DefaultInstanceWarmup or DeletionProtection, while cdkd reset each to a default (for example HealthCheckType back to EC2). cdkd now sends nothing for them, so the live value stays. InstanceMaintenancePolicy, MaxInstanceLifetime, CapacityReservationSpecification and AvailabilityZoneDistribution still reset, as CloudFormation does. Changed: src/provisioning/providers/asg-provider.ts, docs/provider-rules.md, tests/unit/provisioning/asg-provider-update-removal.test.ts, tests/integration/launchtemplate-asg-inplace/verify.sh.
• Removing a property from the template no longer resets it for 7 properties CloudFormation keeps (issue #5004) -- A real CloudFormation A/B showed CloudFormation leaves the live value in place when these are dropped from a template, where cdkd used to reset them. AWS::SQS::Queue: SqsManagedSseEnabled, DeduplicationScope, FifoThroughputLimit; AWS::SecretsManager::Secret: Description, KmsKeyId; AWS::IAM::Role: MaxSessionDuration; AWS::Lambda::Url: InvokeMode. cdkd now sends nothing for them on removal. The other SQS attributes, IAM Role Description and Lambda Url Cors are reset by CloudFormation and keep cdkd's reset. Changed: src/provisioning/providers/{sqs-queue,secretsmanager-secret,iam-role,lambda-url}-provider.ts, docs/provider-rules.md, the matching unit tests and the fifo-sqs-event-source, iam-role-prefixed-name-update, sns-sqs-event, secrets-dynamic-ref and cloudfront-function-url integ fixtures, which now assert the value is retained.
• AWS::DLM::LifecyclePolicy: removing a default-policy shorthand property no longer resets it (#5004): CreateInterval, RetainInterval, CopyTags, ExtendDeletion, CrossRegionCopyTargets and Exclusions keep their live value when dropped from the template, matching a real CloudFormation A/B (cdkd previously reset them to 1 / 7 / false / false / [] / empty). Changed: src/provisioning/providers/dlm-lifecycle-policy-provider.ts, docs/provider-rules.md.
• Removing DeletionProtection or BackupRetentionPeriod from an AWS::DocDB::DBCluster, DeletionProtection, IamAuthEnabled or BackupRetentionPeriod from an AWS::Neptune::DBCluster, or AutoMinorVersionUpgrade from an AWS::Neptune::DBInstance no longer resets the live value: cdkd now leaves it untouched, as CloudFormation does (measured in a real CloudFormation A/B). A removed DeletionProtection previously switched protection off. Changed docdb-provider.ts, neptune-provider.ts. Issue #5004.
• Removing PlatformVersion, HealthCheckGracePeriodSeconds, PropagateTags, EnableECSManagedTags, EnableExecuteCommand, CapacityProviderStrategy, PlacementConstraints or PlacementStrategies from an AWS::ECS::Service template no longer resets them (issue #5004) -- src/provisioning/providers/ecs-provider.ts (removalDefaults is now empty; updateService sends nothing for these members), tests/unit/provisioning/ecs-provider.test.ts, and the ecs-service-update-props integ fixture (now asserts the live value is retained). A real CloudFormation A/B showed CloudFormation KEEPS the live value of all eight on removal, while cdkd (issue #1160) reset them to a default, so a removal changed a running service where CloudFormation would not. ServiceConnectConfiguration removal still resets to disabled, which the same A/B confirmed CloudFormation does; VolumeConfigurations and VpcLatticeConfigurations were not measured and are unchanged.
• Removing SnapshotRetentionLimit, AutoMinorVersionUpgrade or NotificationTopicArn from an AWS::ElastiCache::CacheCluster no longer resets it, matching CloudFormation (issue #5004) -- src/provisioning/providers/elasticache-provider.ts, tests/unit/provisioning/elasticache-provider-update-removal.test.ts, docs/provider-rules.md. A real CloudFormation A/B showed CloudFormation keeps the live value of all three when they are removed from the template, while cdkd reset them (retention to 0, auto minor version upgrade to true, notifications set inactive). cdkd now sends nothing for a removed one and leaves the live value. LogDeliveryConfigurations keeps its reset (CloudFormation disables delivery).
• Removing DeletionProtection, EnableIAMDatabaseAuthentication (RDS DBCluster / DBInstance) or MonitoringInterval (RDS DBInstance) from the template no longer resets it, matching CloudFormation (issue #5004) -- A real CloudFormation A/B showed CloudFormation KEEPS the live value of these properties when they are removed, while cdkd reset them (DeletionProtection to false, EnableIAMDatabaseAuthentication to false, MonitoringInterval to 0). cdkd now sends no value for them, so the live setting is left as it is; a protected cluster or instance stays protected after the property is removed, and cdkd destroy --remove-protection still lifts it. DBCluster BackupRetentionPeriod (CloudFormation resets it to 1) is unchanged, and DBCluster MonitoringInterval is unchanged because it could not be measured. Changed: src/provisioning/providers/rds-provider.ts, tests/unit/provisioning/rds-provider-update-removal.test.ts, tests/integration/rds-aurora/, tests/integration/rds-dbinstance-backfill/.
• Deploying an AWS::ElasticLoadBalancingV2::TargetGroup with TargetType: lambda no longer fails intermittently with "Lambda function ... is not in Active state" (issue #5002). The function's create returns while it is still Pending, and ELBv2 rejects registering a Pending function, so the first deploy sometimes rolled back and a re-run passed. The target group now waits for each Lambda target to reach State=Active immediately before RegisterTargets (create and update); no other target group and no Lambda create pays for it. A function that ends Failed or never turns Active fails the target group with an error naming the function, without AWS's message text. Source: src/provisioning/providers/elbv2-provider.ts, src/provisioning/providers/custom-resource-provider.ts.
• cdkd local * with a cross-account --role-arn now resolves ${AWS::AccountId} to the deploy account, where the stack lives, except under --from-cfn-stack (issue #5001) -- src/local/local-role-arn.ts, src/cli/commands/local-invoke.ts, local-start-api.ts, local-run-task.ts, local-invoke-agentcore.ts, cdk-local bumped to 0.153.1. --from-state already resolved the role's account (#3230); what changes is the case with NO state source (a local run-task image Fn::Sub or a bare --assume-task-role), which was the caller's account and is now the deploy account, so a pinned ECR image URI and account-derived ARNs point at the deployed resources. --from-cfn-stack keeps the caller's account (it reads as you; CloudFormation sees only your account). The engine commands (start-service, start-alb, start-cloudfront, start-agentcore) follow the same rule through cdk-local 0.153.1. Container credentials, assumed roles and secrets still resolve as you. Same-account use and runs without --role-arn are unchanged.
• Fn::GetAtt on an AWS::Lambda::WebFunctionEndpoint's whole RegionalEndpoints map (attrRegionalEndpoints) and on a path through one of its object members (RegionalEndpoints.<region>.ScalingConfig.MaxEnvironments, .ThrottleConfig.RateLimit, .RevisionWeights) resolves again instead of returning the endpoint ARN (issue #4992). Since the SDK provider landed in 0.300.0 these logged Unknown attribute ... returning physical ID; 0.301.1 (#4978) restored only the scalar members. The provider now also records RegionalEndpoints as the nested region -> entry object in CloudFormation casing, as the Cloud Control path did on 0.299.x, leaving out every member AWS did not assign. A record written by 0.300.x or 0.301.x gains it on the next deploy that reaches the Fn::GetAtt, through the stale-attribute heal. Source: src/provisioning/providers/lambda-web-function-endpoint-provider.ts.
• Two secret values that overlap inside one property value no longer leave part of a secret in state (issue #4986) -- src/deployment/secret-redaction/redact-state.ts. When two recorded secret plaintexts overlapped in one string (us-east-1pw12 and pw12-str4ddle-4973 inside us-east-1pw12-str4ddle-4973), the redaction replaced the first and persisted the rest of the second in plaintext. Overlapping matches now take one rule: where their {{resolve:...}} references render the overlapping run exactly (one match spanning it, or matches meeting end to start) those references are persisted; otherwise, or where a match cuts a fresh NoEcho value or the Fn::Base64 encoding of a secret, the whole value is persisted as the redaction mask (***). A record holding the old partial spelling is repaired by the resource's next deploy, which cdkd scrub does not do: where it equals what the old walk stored for today's value, it is rewritten to the mask with nothing sent (src/deployment/deploy-engine/update.ts), and a real template change is sent as usual. Earlier versions of state.json in the versioned state bucket keep the partial value: cdkd scrub --purge-history deletes them, and the exposed secret should be rotated. A rollback to a baseline holding that mask refuses as it does for the other masks, and the refusals (rollback, Fn::GetAtt of a masked attribute, cdkd export) now name this case and its remedy. The same union-of-overlaps masking now applies to a Cloud Control call's withheld-identifier scrub (src/provisioning/cloud-control-provider.ts) and to the masked display of a secret-bearing export name or state key (src/deployment/outputs-export-alias/secret-scan.ts), which could print the tail of one of two overlapping values.
• Fn::GetAtt into an AWS::Lambda::WebFunctionEndpoint's RegionalEndpoints.<region>.<Member> resolves again instead of returning the endpoint ARN (issue #4978). Since the dedicated SDK provider landed in 0.300.0, Fn::GetAtt on RegionalEndpoints.us-west-2.DomainName (and the other members) logged Unknown attribute ... returning physical ID and served the endpoint ARN, so a CloudFront origin built from it failed with origin name cannot contain a colon. The provider now records RegionalEndpoints.<region>.{DomainName,AuthType,State,StateReason,UpdateStatus,UpdateStatusReason} from GetWebFunctionEndpointResponse.regionalEndpoints; a member AWS did not assign (a MultiRegion endpoint reports domainName: null per region) is not recorded. A record written by 0.300.x gains the keys on the next deploy that reaches the Fn::GetAtt, through the stale-attribute heal. Source: src/provisioning/providers/lambda-web-function-endpoint-provider.ts.
• cdkd diff --recursive --fail no longer reports a change on an unchanged nested stack in which one child resource reads a parameter the parent spelled as a literal embedding {{resolve:...}} tokens beside a sibling parameter spelling the same secret differently, through an Fn::Select / Fn::Split / Fn::If over an Fn::Sub (or Fn::Join) naming AWS::AccountId (issue #4975). The #4962 fix left AWS::AccountId unbound in the nested-stack parameter re-read; it is now bound too. After upgrading, the first deploy of such a stack shows a change on the child resources reading the literal parameter, because their state now records the parameter's own {{resolve:...}} spelling instead of the sibling's; the deployed VALUE is unchanged, and a create-only property is replaced once with an identical value. The account comes from the same lookup and cache as AWS::AccountId itself, so every pass binds the same value whether or not the account was already known. That can add one STS GetCallerIdentity call per process, made only by a nested child that inherits parent secrets and has a resource naming AWS::AccountId beside an Fn::Select / Fn::Split / Fn::If, and only when the account is not yet known; any other stack makes no added call. If the lookup fails, the account stays unbound (the earlier behavior) and no new error is raised. Source: src/deployment/intrinsic-resolver/{account-drain,parameter-secrets,params-conditions}.ts, src/deployment/secret-redaction/nested-stack.ts.
• cdkd diff --recursive --fail no longer reports a change on an unchanged nested stack in which a child's Outputs read a parameter the parent spelled as a literal embedding {{resolve:...}} tokens, beside another output reading a sibling parameter that spells the same secret differently through an Fn::Join / Fn::Sub naming two or more pseudo parameters, e.g. `${Aws.REGION}.${Aws.ACCOUNT_ID}.${param.valueAsString}` (issue #4973). The redaction of a child's outputs could hold at most one pseudo parameter unknown in such an output, so it fell back to the sibling's spelling for the literal parameter across the whole child. It now reads AWS::Region, AWS::Partition, AWS::URLSuffix and (where the child already looks it up, #4975) AWS::AccountId from the values the child's parameter resolution records (#4962); no AWS call is added. After upgrading, the first deploy of such a stack shows a change on the child resources reading the literal parameter, because their state (and the child's outputs) now record the parameter's own {{resolve:...}} spelling instead of the sibling's; the deployed VALUE is unchanged, and a create-only property is replaced once with an identical value. AWS::StackName, AWS::StackId, and an AWS::AccountId the child does not look up, stay unknown. Source: src/deployment/secret-redaction/{placeholder-positions,nested-stack}.ts, src/deployment/intrinsic-resolver/parameter-secrets.ts.
• An AWS::IAM::Role, AWS::SSM::Parameter, AWS::Kinesis::Stream and the EC2 VPC, Subnet, InternetGateway, EIP, NatGateway, RouteTable, SecurityGroup, Instance and NetworkAcl now send their tags on the create call itself (issue #4971) -- src/provisioning/providers/{iam-role-provider,ssm-parameter-provider,kinesis-provider,ec2-provider}.ts. cdkd created these resources untagged and tagged them afterwards (TagRole, AddTagsToResource, AddTagsToStream, CreateTags), so an organization SCP requiring a tag on the create action (aws:RequestTag/...) denied the create, where cdk deploy succeeds. The tags now go in CreateRole.Tags, PutParameter.Tags, CreateStream.Tags and each EC2 create's TagSpecifications, and the follow-up tagging call is gone: a tagged create makes one AWS call fewer. A tagged create needs the tagging permission the follow-up call already needed (iam:TagRole, ssm:AddTagsToResource, kinesis:AddTagsToStream, ec2:CreateTags). The old EC2 path only warned when CreateTags failed, so a role without ec2:CreateTags could still create: such a role's tagged create is re-sent once untagged and then tagged with CreateTags as before. Updates still tag with the separate calls (SSM refuses Tags with Overwrite). An EC2 tag the create call refuses now fails the create instead of warning. A possible orphan of a lost EC2 create response is now matched by carrying no tags or exactly the template's tags, and the deploy's post-create EC2 read re-reads a not-found answer briefly before dropping the drift baseline.
• An AWS::S3::Bucket now sends its tags on CreateBucket itself, and an access denial from an explicit deny fails fast instead of being retried (issue #4969) -- src/provisioning/providers/s3-bucket-provider.ts, src/deployment/retryable-errors/transient.ts. cdkd created a bucket untagged and applied its tags afterwards with PutBucketTagging, so an organization SCP requiring a tag on s3:CreateBucket (aws:RequestTag/...) denied the create, where cdk deploy succeeds. The template's tags now go in CreateBucketConfiguration.Tags, and a create that carried them no longer repeats them with PutBucketTagging; an adopted bucket still gets the PutBucketTagging. Tags on CreateBucket need s3:TagResource: a role that lacks it but holds s3:PutBucketTagging gets the old path back automatically (one untagged retry of each bucket's create, then PutBucketTagging); when that untagged create is denied too, the error names the missing s3:TagResource (and fails at once when the untagged denial is an explicit deny); an endpoint that refuses the Tags member itself takes the same untagged path. Separately, an AccessDenied that says the call was refused with an explicit deny (a service control policy, resource control policy, identity- or resource-based policy, permissions boundary, session policy, VPC endpoint policy or role trust policy) was matched as IAM propagation and retried for about 48 seconds; it now fails on its first answer, and an S3 bucket error names the policy type that denied it. A role holding s3:TagResource makes no extra AWS call, and its tagged bucket's create makes one call fewer.
• cdkd diff --recursive --fail no longer reports a change on an unchanged nested stack in which one child resource reads a parameter the parent spelled as a literal embedding {{resolve:...}} tokens beside a sibling parameter spelling the same secret differently, through an Fn::Select / Fn::Split over an Fn::Sub (or Fn::Join) naming AWS::Region, AWS::Partition or AWS::URLSuffix (issue #4962). After upgrading, the first deploy of such a stack shows a change on the child resources reading the literal parameter, because their state now records the parameter's own {{resolve:...}} spelling instead of the sibling's; the deployed VALUE is unchanged, and a create-only property is replaced once with an identical value. The child's parameter resolution records those three values, each a function of the stack's region, and the redaction re-reads such a leaf with them, as cdkd deploy, cdkd scrub and the diff side all resolve them; no AWS call is added. AWS::AccountId is bound since #4975; AWS::StackName, AWS::StackId and AWS::NotificationARNs are not bound, so a leaf naming one still falls back to the sibling's spelling. Source: src/deployment/secret-redaction/nested-stack.ts, src/deployment/intrinsic-resolver/{parameter-secrets,params-conditions}.ts.
• cdkd deploy, cdkd diff and cdkd destroy now mask two more resource names taken from a secret (issue #3869). (1) With --verbose, a parent resource reading a nested stack's output with Fn::GetAtt Child.Outputs.<Key> printed the name of a child resource taken from a secret, when the child's provider had rewritten or case-folded it (an IAM name with the stack prefix, an RDS identifier), in the Resolved Fn::GetAtt ... resolved to line and the reader's own lines. A nested-stack row created or updated by this version records which outputs hold such a name (ResourceState.secretNamedAttributes, attribute keys only; no state schema bump), so a later deploy where the row is unchanged masks them too. An existing nested stack is covered after its next update: there is no backfill, which would read the child's state on every no-change deploy. (2) A name taken from a NoEcho parameter whose value has since changed (a record written before schema v11 still holds the old value), or from a short value, printed on a replacement's Deleting old / was replaced lines (shown without --verbose) and on cdkd destroy's delete lines. Each record's own value at a position the template fills from a NoEcho parameter is now judged as secret. Beyond that key list, print-only: nothing else persisted, and nothing compared or sent, changes. Source: src/deployment/secret-name-needles.ts, src/deployment/secret-redaction/noecho-leaves.ts, src/provisioning/providers/nested-stack-provider.ts, src/deployment/deploy-engine/masking.ts, src/deployment/deploy-engine/attribute-healer.ts, src/cli/commands/destroy-runner.ts, src/cli/commands/diff-recursive.ts.
• A provider failure whose thrown value cannot be converted to text now reports that failure instead of TypeError: Cannot convert object to primitive value (issue #3341). Catch blocks under src/provisioning/providers/ that rethrow read the caught value with a bare String(err), which throws for a null-prototype object or a hostile toString and replaced the real AWS failure (and the text persisted to deployments/{runId}.jsonl). They now read it through describeAwsFailure(err).detail or safeStringify(err), byte-identical for every value that converted before. Enforced by an exact, shrink-only ratchet in tests/unit/provisioning/provider-swallowing-catch-out-throw.test.ts.
• The four engine cdkd local start-service / start-alb / start-cloudfront / start-agentcore commands no longer hand the --role-arn role to the emulated workload (issue #3240) -- src/cli/commands/local-invoke.ts, src/local/local-role-arn.ts, src/cli/commands/local-state-source.ts, src/cli/commands/local-start-{service,alb,cloudfront,agentcore}.ts, local-start-api.ts, local-run-task.ts, local-invoke-agentcore.ts. With --role-arn and no profile, these commands copied the role's credentials into containers, injected ECS task secrets and {{resolve:...}} values fetched with the role, resolved ${AWS::AccountId} to the role's account, read --from-cfn-stack as the role and made the --assume-role hop as the role. They now resolve all of it as the caller (pass --profile to choose the identity), via cdk-local 0.152.0's workloadIdentity: 'caller'. A literal layer ARN on local invoke / start-api is likewise fetched as the caller now, and those four cdkd-owned commands record their assume with cdk-local through applyRoleArnForLocal. The startup warning the engine commands printed is gone. Under --role-arn the --assume-role / --ecr-role-arn / --layer-role-arn hops are signed by your own identity, so the target role's trust policy must trust you, and local start-cloudfront --from-state's deployed S3-origin / KeyValueStore reads now run as you. Synthesis, the ECR login without --ecr-role-arn, and cdkd's --from-state state reads still use the role. Tests: tests/unit/local/local-role-arn.test.ts, tests/unit/cli/local-embed-config.test.ts, tests/unit/local/ecr-puller.test.ts, tests/unit/local/local-role-arn-from-cfn-stack.test.ts.
• cdkd local start-cloudfront accepts --from-state again, start-alb's --from-state reaches Lambda target groups, and cdkd local invoke <image-fn> | jq gets a clean payload (issues #2600, #2429, #2525, #3393; #2602) -- package.json (cdk-local 0.151.1), src/cli/commands/local-start-cloudfront.ts, local-start-alb.ts, local-invoke.ts, local-state-source.ts, src/utils/local-aws-failure.ts. With cdk-local 0.151.0 consulting a host's state provider on every state-backed path, start-cloudfront no longer refuses --from-state / --state-bucket / --state-prefix: they resolve a deployed S3 origin's bucket, cf.kvs() stores and the Function URL / Lambda@Edge environment. Under --role-arn with no --profile, the startup warning now also names the engine's origin, KeyValueStore and ${AWS::AccountId} reads under either state flag. start-alb drops its boot warning that --from-state misses a Lambda target, since it no longer does. cdk-local's own log lines now go through cdkd's logger, so local invoke keeps Building container image ... off stdout, --verbose reaches cdk-local's debug lines, and its warnings print in cdkd's format (no WARN: prefix) unless CDKL_LOG_LEVEL / CDKL_LOG_STREAM is set. Bundled-engine fixes picked up by the bump: the start-cloudfront --help text says Lambda@Edge runs locally, a --profile name is rendered safely in cdk-local's messages, and a --verbose build line masks --build-arg and cache-credential values.

Recently Implemented (2026-10-15):

• cdkd diff --recursive --fail no longer reports a change on an unchanged nested stack in which one child resource reads a parameter the parent spelled as a literal embedding {{resolve:...}} tokens beside a sibling parameter spelling the same secret differently, through an Fn::If whose branches resolve to that secret spelled two ways, an Fn::If whose other branch is an attribute, a resource or a pseudo parameter, or an array of which only some Fn::If elements resolve to AWS::NoValue or which holds another intrinsic beside one (issue #4954). After upgrading, the first deploy of such a stack shows a change on the child resources reading the literal parameter, because their state now records the parameter's own {{resolve:...}} spelling instead of the sibling's; the deployed VALUE is unchanged, and a create-only property is replaced once with an identical value. The resolver now records, per resource, which branch each Fn::If took and which array elements dropped out as AWS::NoValue, and the state redaction reads those records instead of guessing from the resolved value, so an array element that drops out keeps the rest of the array paired with its template in any stack. An Fn::Sub naming a pseudo parameter inside Fn::Select (#4962), and a taken branch reading the parameter through an intrinsic the redaction cannot evaluate, still fall back to the sibling's spelling. Source: src/deployment/secret-redaction/{nested-stack,redact-path,resolver-outcomes}.ts, src/deployment/intrinsic-resolver/{functions,parameter-secrets}.ts, src/deployment/intrinsic-function-resolver.ts.
• A rollback no longer re-adopts the old resource of a replacement when the deploy's delete had already stripped it before AWS refused the delete (issue #4946) -- src/deployment/rollback-executor/replaced-survivor.ts, src/provisioning/delete-started.ts. Several providers change a resource before the call that deletes it: an IAM role, user or group loses its policies, memberships and instance profiles, a managed policy is detached from every principal, an EventBridge rule loses its targets, a CloudFront distribution is disabled, an ECS service is scaled to 0, a CloudTrail trail stops logging, a VPC Lambda function is detached from its VPC, and so on. When AWS then refused the delete by name (an SCP denying iam:DeletePolicy but allowing the detach, for example) and a later resource failed the deploy, the rollback re-adopted the stripped resource in place of the working new copy, and the next cdkd deploy saw no difference to repair. Such a delete now marks its error, and the replacement journals oldResourceMaySurvive: unconfirmed: the rollback refuses that operation with the journal kept and offers cdkd rollback --orphan, as it already did for the same providers' own in-update replacement. A refusal before the delete changed anything still re-adopts the old resource. Providers changed: IAM role, managed policy, policy, user / group / UserToGroupAddition, instance profile, EventBridge rule and event bus, CloudFront distribution, CloudTrail trail, ECS service, Glue trigger, Lambda function, Route 53 hosted zone, RDS DB cluster (a global-cluster detach), DynamoDB global table, SQS queue policy and SNS topic policy. The cdkd rollback plan line for such an operation now also names a delete that only partly ran. No extra AWS call is made.
• A failed create that left a resource behind is no longer retried into making another one -- src/deployment/retry.ts, src/provisioning/auxiliary-failure.ts, and the iam-access-key, appsync, cognito, ec2, emr-cluster, emr-instance-fleet-config, emr-instance-group-config and lambda-web-function-revision providers. A create whose attempt made its resource and then failed (marked for the failed-CREATE journal) was retried, and for a type whose create sends no name and no idempotency token, each retry made another resource while the journal recorded only the last one. An AWS::IAM::AccessKey with Status: Inactive, deployed by a principal denied iam:UpdateAccessKey and iam:DeleteAccessKey, minted a second key on the retry (the deny reads like IAM propagation, which is retried), filled the user's 2-key quota, and failed on LimitExceeded with the first key unrecorded. That create now fails on its own error once it leaves its resource behind, for the access key, AppSync GraphQL API, Cognito user pool, EC2 VPC and EIP, EMR cluster, instance fleet and instance group, and Lambda web function revision, so cdkd rollback --revert-failed and a fix-forward find the one resource. An EIP, a web function revision and an EMR TASK instance group that a later step failed after are now released, deleted or scaled to 0 first, so a transient failure there is still retried. For every other type, a retry whose create made a resource other than the one an earlier attempt left behind stops there with a warning; a create that resumes its earlier resource (KMS, S3, an idempotency token, an SNS or SQS policy over several targets) is retried as before. Issue #4945.
• cdkd destroy and cdkd state destroy now delete a cross-region stack's nested children in the stack's region, not the CLI's (issue #4941) -- src/cli/commands/destroy-runner.ts, src/cli/commands/state.ts, new tests/unit/cli/destroy-nested-cross-region-scope-4941.test.ts and integ fixture destroy-nested-cross-region. Destroying a stack recorded in a region other than the CLI's switched region for the parent's own resources, but its nested children ran with the provider registry and AWS clients the command had built in the CLI's region. A provider that builds its own SDK client (Kinesis, CodeBuild, CloudTrail, Glue, WAFv2, S3 Tables, ...) captures its region when it is constructed, so a child's resource was deleted by name in the CLI's region: a same-named resource there that cdkd does not manage was deleted irreversibly, and the real one was left behind. A child's DeletionPolicy: Snapshot final snapshot also went through the CLI-region clients. Such a stack is now destroyed inside a stack AWS scope for its region, as deploy and rollback run theirs, with a provider registry built in that scope, and its nested children are handed that registry and the stack's clients. cdkd state destroy --region X run from a shell in another region also built its registry in the shell's region, so it deleted by name there for a stack recorded in X; it now points the SDK at X first, as cdkd destroy --region does. A stack in the CLI's region is otherwise unchanged.
• cdkd orphan now reads live Fn::GetAtt values in the orphaned stack's region, not the CLI's --region / AWS_REGION (issue #4937) -- src/cli/commands/orphan.ts, new tests/unit/cli/orphan-stack-aws-scope-4937.test.ts, and a new phase 4b in tests/integration/orphan-getatt-takeover/. cdkd orphan picked the stack's region from its synthesized env.region, its state record or --stack-region, but built its providers on the CLI-region clients and never entered that stack's AWS scope. So when the rewrite read an orphan's attribute live (the record could not serve it), the read went to the CLI's region: a NotFound aborted the orphan, or a same-named resource's value (or an ARN naming the wrong region) was written into a sibling's state. The provider registry and the rewrite now run inside runWithStackAwsClients for the stack's region, as deploy does. The state backend and lock stay on the CLI's clients, and process.env.AWS_REGION is left unchanged.
• cdkd rollback now runs its providers in the rolled-back stack's region, not the CLI's ambient AWS_REGION (issue #4932) -- src/cli/commands/rollback.ts, new tests/unit/cli/rollback-stack-aws-scope-4932.test.ts. A standalone cdkd rollback resolved the stack's region from its journal or state key and pinned the global getAwsClients() set to it, but never entered the stack AWS scope that deploy uses. Providers that build their own SDK client read the region from ambientRegion(), which outside a scope is process.env.AWS_REGION. So a rollback of a stack recorded in a region other than the shell's could delete, re-create or update a same-named resource in the ambient region, which cdkd does not manage. The provider registry and the whole replay now run inside runWithStackAwsClients for the stack's region, so every provider captures that region when it is constructed and when it builds a client. A nested child's revert is also handed the stack's clients, which its destroy takes final snapshots through, as deploy does. process.env.AWS_REGION is left unchanged.
• cdkd diff --recursive no longer reports an unchanged nested child that splits a parent-built parameter on a delimiter inside a secret {{resolve:...}} reference's text, such as : (issue #4929). A child reading Fn::Select [1, Fn::Split [':', {Ref: Conn}]] over a parent row Conn: postgres://{{resolve:...}}:{{resolve:...}}@host showed a change on every run, and --fail exited 1, because the diff cut each reference into fragments (//{{resolve) that no deploy persists. The child now keeps whole each reference its parent's deploy replaces with the secret before handing the value down (one in the row's literal, Fn::Join or Fn::Sub, or one the parent itself received that way), as the deploy's plan does since #4914. Reference text the parent passes down as plain text (a Ref to its own parameter, an Fn::FindInMap value) is still split as text, as the deploy does. No secret is fetched and no AWS call is added. Source: src/cli/commands/diff-recursive.ts, src/deployment/intrinsic-resolver/string-functions.ts, src/deployment/intrinsic-resolver/dynamic-refs.ts, src/deployment/intrinsic-resolver/context.ts.
• AWS::Lambda::NetworkConnector now deploys through an SDK provider; deleting a connector takes about 3 s instead of about 13 s -- new src/provisioning/providers/lambda-network-connector-provider.ts, src/provisioning/provider-registry.ts, src/utils/aws-clients.ts, new dependency @aws-sdk/client-lambda-core. A connector is the VPC egress path Lambda Web Functions and MicroVM images share. Its create still waits until the connector is ACTIVE (about 4 minutes, AWS's own provisioning), which cdkd now notices within a second rather than through Cloud Control's report and poll backoff; its delete settles in about 3 s, where Cloud Control took 12.6 s (us-east-1). A configuration change goes through UpdateNetworkConnector and waits for the new version, a tags-only change through Lambda's tagging API. Removing OperatorRole from a deployed connector's template, or declaring a non-string one, now fails the deploy before any change, naming the cause: the update would send no role, leaving the old one attached. A connector created by an earlier cdkd, recorded on Cloud Control, moves to the SDK provider on the next deploy that changes it. cdkd drift and cdkd import (by ARN or name) are supported. Issue #4928.
• AWS::Lambda::WebFunctionRevision and AWS::Lambda::WebFunctionEndpoint now deploy through SDK providers, about 5 s faster per Web Function code change -- new src/provisioning/providers/lambda-web-function-revision-provider.ts, lambda-web-function-endpoint-provider.ts and lambda-web-function-arns.ts, src/provisioning/provider-registry.ts, src/utils/aws-clients.ts, new dependency @aws-sdk/client-lambda-web. A code change creates a new revision, moves the endpoint's RevisionWeights to it and deletes the old revision; through Cloud Control those three steps took about 12 s, and through the Lambda Web API about 7 s (median of three, us-east-1). A revision created by an earlier cdkd, recorded on Cloud Control, moves to the SDK provider on the next deploy that changes it, and so does an endpoint. Both providers support cdkd drift and cdkd import. AWS::Lambda::WebFunction stays on Cloud Control: the public CreateWebFunction refuses a function without a first revision and endpoint, which only CloudFormation's handler may create. Issue #4926.
• cdkd drift --revert can now revert drift on an AWS::GuardDuty::Detector (issue #4921) -- src/provisioning/guardduty-detector-patch.ts, src/provisioning/cloud-control-provider.ts, unit cases and a new phase in the guardduty-detector-update integ fixture. The revert hands Cloud Control the AWS snapshot with the drifted keys overlaid. That snapshot carried both DataSources and the full Features list on every read measured, which UpdateDetector refuses together, so reverting a drifted scalar or feature failed with EKS_RUNTIME_MONITORING and RUNTIME_MONITORING cannot be provided in the same request. Now an undrifted Features or DataSources (one the patch has no op on) is removed from the request instead of sent as read back, unless the live read lacks it; GuardDuty leaves an omitted setting as it is. A drifted Features list is narrowed to the entries that differ from the live entry of the same Name, so a toggled feature is reverted alone, and a drifted DataSources beside it (GuardDuty's legacy view of features such as S3 and EKS audit logs) is left out. When no entry differs, the drift is only in entry order or in entries GuardDuty added, which UpdateDetector cannot undo: the revert fails with an error saying so, rather than reporting a revert that changed nothing, and warns that cdkd drift --accept records every drifted property of the stack, so other drift on the detector should be reverted first. A desired entry without a string Name, an unreadable live list or an op without a list keeps the op as it was. Still refused: a drift that switched the runtime monitoring mode, since reverting it changes both runtime features.
• cdkd diff --recursive --fail no longer reports a change on an unchanged nested stack in which one child resource reads a parameter the parent spelled as a literal embedding {{resolve:...}} tokens beside a sibling parameter spelling the same secret differently, either of the two through Fn::If, through Fn::Sub inside Fn::Select, or inside an array holding an Fn::If or AWS::NoValue element (issue #4919). After upgrading, the first deploy of such a stack shows a change on the child resources reading the literal parameter, because their state now records the parameter's own {{resolve:...}} spelling instead of the sibling's; the deployed VALUE is unchanged, and a create-only property is replaced once with an identical value. Before, cdkd fell back to the sibling's spelling for that parameter in the whole child while cdkd diff --recursive rendered its literal. The child leaf re-read (#4731) now evaluates Fn::Sub and Fn::If: an Fn::If is re-read only when every branch is and no two branches resolve to one value spelled two ways, so its branch is read off the persisted value with no condition outcome needed. A bag array shorter than its source pairs the remaining elements in order when the count alone says which AWS::NoValue elements dropped; this applies to any stack's resource arrays, so a {{resolve:...}} element there keeps its own spelling where two references share one secret value. Anything else keeps the old fallback. Source: src/deployment/secret-redaction/{nested-stack,redact-path}.ts, src/deployment/intrinsic-resolver/parameter-secrets.ts.
• A deploy's plan and cdkd diff no longer report an unchanged resource whose Fn::Split delimiter occurs inside a secret {{resolve:...}} reference's text, such as : (issue #4914). A nested child splitting a parameter the parent built as postgres://{{resolve:...}}:{{resolve:...}}@host on : showed an UPDATE row for that resource in every child redeploy's plan, and on a create-only property a replacement that --require-approval=destructive asked about each time (refused without a terminal); the engine's post-resolution check then skipped the call, so AWS was never touched. cdkd diff reported a change on every run, and --fail exited 1, for a stack splitting a literal, Fn::Join or Fn::Sub holding such references. The comparison side cut each reference into fragments (//{{resolve) that no deploy persists. It now keeps a reference whole where it splits whenever the real deploy replaces it with its secret before splitting (one in the split's own literal, Fn::Join or Fn::Sub, or one a nested child's parent resolved), which matches what the deploy persists unless the secret value itself holds the delimiter. Reference text reaching the split as plain text (a Ref to a parameter, an Fn::FindInMap value) is still split as text, as the deploy does. cdkd diff --recursive still reports the nested-child case (#4929). After upgrading, a nested child in which one resource reads such a split beside a sibling parameter spelling the same secret differently may show a one-time change (a replacement on a create-only property) on the resources reading the split parameter: their state now records that parameter's own spelling instead of the sibling's. The deployed value is unchanged. No AWS call is added. Source: src/deployment/intrinsic-resolver/string-functions.ts, src/deployment/secret-redaction/nested-stack.ts.
• cdkd diff --recursive --fail no longer reports a change on an unchanged nested stack whose child Outputs read a parameter the parent spelled as a literal embedding {{resolve:...}} tokens beside a sibling parameter spelling the same secret differently (issue #4913). Before, no output was positioned per parameter, so cdkd fell back to the sibling's spelling for that parameter in the whole child (its resources included) while cdkd diff --recursive rendered the literal. Now the outputs redaction carries the outputs pass's parameter reads and the parent's per-parameter associations, so an output whose Value is a bare Ref, an Fn::Select / Fn::Split re-read, or an Fn::Join / Fn::Sub over the parameters (with at most one other non-literal part) persists each parameter's own spelling, and the collision check reads each output Value as it reads a resource. After upgrading, the first deploy of such a stack shows a change on those outputs, and on child resources reading the literal parameter that had taken the sibling's spelling; the deployed VALUE is unchanged, and a create-only property is replaced once with an identical value. A read the outputs redaction cannot position (under Fn::If, through Fn::Sub inside Fn::Select, inside a list-valued output, in an Fn::Join / Fn::Sub with two or more other non-literal parts, or in an Export.Name) keeps the old behaviour. cdkd scrub writes the same outputs. Source: src/deployment/intrinsic-resolver/parameter-secrets.ts, src/deployment/deploy-engine/outputs.ts.
• A rollback no longer re-creates the old resource of a replacement a provider made inside its own update when that provider could not delete it (issue #4911) -- src/deployment/deploy-engine/update-in-place.ts. A provider that replaces a resource inside update() (an AWS::CertificateManager::Certificate whose ValidationMethod changes; also the IAM role, IAM managed policy and API Gateway resource providers) and whose delete of the old one failed or was skipped reports a partial update. The deploy journaled that operation without the #2631 survivor mark, so when a later resource of the same deploy failed, the rollback re-created the old resource while it was still there: a duplicate certificate, for example, when ACM refused the delete because a load balancer or CloudFront distribution still used it. The operation is now journaled with oldResourceMaySurvive, from the provider's own verdict on the old resource: kept when the ACM or API Gateway provider proves AWS refused the delete outright (by AWS error name, ACM's in-use refusal included) or never sent it, unconfirmed otherwise, and always for the IAM role and managed policy, whose delete strips them before the refused call. The rollback reads AWS for the old resource first: re-created when AWS reports it gone, re-adopted when it is still there and kept (the replacement is deleted, as CloudFormation would), otherwise refused with the journal kept and cdkd rollback --orphan offered (the refusal now also names a delete that only partly ran). Providers also changed: acm-certificate-provider.ts, apigateway-provider.ts, and src/types/resource.ts (oldResourceSurvivor on a partial update). The deliberate UpdateReplacePolicy: Retain survivor of the update-unsupported fallback is still recorded as retained, and an ordinary deploy makes no extra AWS call.
• A fix-forward deploy now deletes the IAM access key or Cloud Map namespace or service an earlier failed CREATE left behind (issue #4606, access key and Cloud Map slice) -- src/provisioning/providers/{iam-access-key,servicediscovery}-provider.ts. When a cdkd deploy --no-rollback made an AWS::IAM::AccessKey or an AWS::ServiceDiscovery::Service (or a private DNS, public DNS or HTTP namespace), failed on a later call and could not delete it again, and a later deploy created a new one under the same logical id, the successful deploy warned about the earlier one, left it in AWS and exited 2; cdkd rollback and cdkd destroy kept it the same way. The providers now compare the two: an access key id and a Cloud Map ns- / srv- id are generated by AWS and never reused, so the earlier resource is a different one once the record's key, namespace (of the record's kind) or service reads back in the stack's region, and it is deleted. An id of another form, a read that fails, or a record that does not read back keeps the warning. No ordinary deploy makes an extra call. Tests: tests/unit/provisioning/{iam-access-key,servicediscovery}-provider-same-resource-4606.test.ts; integ: access-key-cloudmap-fix-forward-orphan.
• A fix-forward deploy now deletes the EventBridge pipe an earlier failed CREATE left behind (issue #4606, Pipes slice) -- src/provisioning/providers/pipes-provider.ts. When a cdkd deploy --no-rollback made an AWS::Pipes::Pipe, the pipe never settled (a *_FAILED state, the wait's cap, an interrupt, or a state read that failed) and cdkd could not delete it again, and a later deploy kept the logical id under another name, the successful deploy warned about the earlier pipe, left it in AWS and exited 2; cdkd rollback and cdkd destroy kept it the same way. The provider now answers both questions: a pipe name is unique per account and region and cannot be changed, so the earlier pipe is a different one once the record's reads back (two names equal ignoring case are never compared); and the failed deploy records the pipe's ARN and creation time (from CreatePipe's answer, else read when the failure is journaled), so the earlier pipe is deleted only while its name still reads back with that creation time. One deleted by hand and re-created under the name has another creation time and is kept, with a warning, and so is one AWS reports DELETING. Such a failure is no longer retried by re-sending CreatePipe (which could only collide with the pipe it left), so its message keeps the aws pipes delete-pipe advice instead of ending in "already exists". No ordinary deploy makes an extra call. Tests: tests/unit/provisioning/pipes-provider-same-resource-4606.test.ts; integ: pipes-fix-forward-orphan.
• destroy --remove-protection on a Cognito User Pool with a DEVELOPER (SES) EmailConfiguration now says plainly when a write reset it to Cognito's default sender (issue #4149) -- src/provisioning/providers/cognito-provider.ts and tests/unit/provisioning/providers/cognito-remove-protection-rmw.test.ts. Measured in us-east-1: an UpdateUserPool that omits a DEVELOPER EmailConfiguration resets it to EmailSendingAccount: COGNITO_DEFAULT, dropping its SES SourceArn; echoed back unchanged it is accepted and kept. The DeletionProtection flip already echoes it; when AWS refuses that echo and cdkd re-sends without it, the warn used to say a reset was "not measured" -- it now says the email configuration WAS reset, and if the delete then fails and the live pool reads back on the default sender, cdkd reports that at ERROR with how to put it back (a redeploy will not). A re-send that fails with no clear answer (a timeout or 5xx, which may have landed) now warns of the reset on the throttle/5xx retry path and on the re-enable after a failed delete, where it used to say nothing. The ERROR report after a bare flip now lists the DEVELOPER sending account among what the pool held. Turning the guard back on after a failed delete, cdkd no longer sends a write without the SES settings to a pool that already reads it on, unless the flip-off's own write without them is known to have landed.
• A failure value that cannot be converted to text no longer turns a best-effort step of cdkd diff, the --recreate-via-* consumer listing, cdkd bootstrap --destroy or cdkd publish-assets into a hard failure (src/analyzer/outputs-diff.ts, src/cli/commands/{recreate-downstream-consumers,bootstrap-destroy,publish-assets}.ts, go-to-k/cdkd#3361). String() throws for a null-prototype object, and these handlers built their message with it, so the handler itself threw: an output value or Export.Name that cdkd diff could not resolve failed the diff instead of being skipped; one unreadable state file, or a failed stack listing, failed the downstream-consumer enumeration instead of being skipped or falling back to an empty list; a failed bootstrap-marker listing failed bootstrap --destroy instead of warning and continuing; and, with more than one stack selected, one stack's failure in cdkd publish-assets stopped the run instead of being recorded while the remaining stacks were published. Each now goes through describeAwsFailure(x).detail or safeStringify(x), byte-identical for every value String() converts and a placeholder otherwise. Tests: tests/unit/{analyzer/outputs-diff,cli/recreate-downstream-consumers,cli/bootstrap-destroy,cli/publish-assets}-string-outthrow-3361.test.ts.
• A failure that cannot be converted to text no longer stops the teardown or dispatch of cdkd local start-api, cdkd local run-task or cdkd local invoke-agentcore --watch (src/local/{container-pool,websocket-server,ecs-task-runner,invoke-agentcore-watch-loop}.ts, go-to-k/cdkd#3361). Handlers that log a failure and carry on built their message with x instanceof Error ? x.message : String(x), and String() throws for a null-prototype object, so the handler itself threw: the container pool skipped docker rm after a failed log-stream stop, and a failed in-flight start made dispose() reject before tearing down any warm container; a WebSocket dispatch failure left the 1011 close or the error frame unsent and broke the connection's dispatch chain, so every later frame and its $disconnect were skipped; run-task's cleanup stopped at a failed hook, in-flight removal, log-stream stop or drain, leaving the network and volumes behind (and, without --keep-running, the containers); and the --watch loop lost its rebuild fallback, kept pinging a torn-down container after a failed rebuild, stopped running later reloads, or rejected when closing its watcher failed. Each now goes through describeAwsFailure(x).detail, or safeStringify(x) beside a kept err.stack arm, byte-identical whenever the value converts and a placeholder only when it cannot. Tests: tests/unit/local/*-string-outthrow-3361.test.ts.
• A value that cannot be converted to text no longer defeats cdkd local start-api's graceful shutdown or hides a failed --watch reload (src/cli/commands/local-start-api.ts, go-to-k/cdkd#3361). The uncaughtException and unhandledRejection listeners, and the reload's synth catch, rendered the value they received with a bare String(), which throws for a null-prototype object. A throw inside the uncaughtException listener ended the process without the shutdown that removes the warm containers and the profile credentials tmpdir; the unhandledRejection listener reported the converter's TypeError instead of the rejection; and a failed re-synth printed nothing, because the reload chain swallowed the TypeError in place of the "keeping previous version" warning. Each now renders through safeStringify / describeAwsFailure(x).detail, byte-identical whenever the value converts and a placeholder only when it cannot. Tests: tests/unit/cli/local-start-api-string-outthrow-3361.test.ts.
• A state read rejecting with a value that cannot be converted to text no longer defeats a --from-state fallback of cdkd local (src/cli/commands/local-state-loader.ts, go-to-k/cdkd#3361). Six handlers that log a failed S3 read at debug and carry on built their message with x instanceof Error ? x.message : String(x), and String() throws for a null-prototype object, so the handler itself threw: a failed state-bucket resolution or bootstrap-marker read failed cdkd local run-task instead of falling back to the conventional asset-repo names; a failed exports-index lookup skipped the per-stack scan, and one unreadable stack during that scan stopped it, so an Fn::ImportValue a later stack could answer was dropped from the env, and failed cdkd local invoke-agentcore when it named a fromS3 code bucket; and a failed stack listing or Fn::GetStackOutput state read dropped its entry with the converter's TypeError as the reason. Each now goes through describeAwsFailure(x).detail, byte-identical whenever the value converts and a placeholder only when it cannot. Tests: tests/unit/cli/local-state-loader-string-outthrow-3361.test.ts.
• A Cloud Control create cdkd stopped waiting for is now resumed by the next cdkd deploy, and settled by cdkd destroy and cdkd rollback (issue #3252) -- src/deployment/cc-pending-requests.ts, src/deployment/deploy-engine/create.ts, src/deployment/deploy-engine/deploy-flow.ts, src/deployment/deploy-engine/execute.ts, src/deployment/deploy-engine/rollback.ts, src/provisioning/cloud-control-provider.ts, src/provisioning/wait-abandoned.ts, src/deployment/rollback-executor/journaled-orphans.ts, src/cli/commands/destroy-runner.ts, src/cli/commands/rollback.ts, src/cli/commands/rollback-drop-failed.ts, src/state/s3-state-backend.ts, src/types/rollback-journal.ts, src/deployment/rollback-executor/orphan-identity.ts. When a network outage made cdkd give up on a Cloud Control create, the request token was printed and lost, and the user had to check it and import or delete the resource by hand. The rollback journal now records it (pendingCloudControlRequest, additive, no journalVersion bump). The next deploy, destroy or rollback reads the request's status under the stack lock before anything else. Whether its id is unique is read from the type's registry schema: a read-only primary identifier field AWS minted, not a name the create sent. A deploy whose template still declares the resource with the same properties takes a unique one over instead of creating another; otherwise it becomes a journaled resource the failed deploy created, deleted when its id is unique and named in a warning, with the cdkd import remedy, when it is a name. A create that made nothing, or that Cloud Control no longer has (requests expire after seven days), is forgotten. One still unknown refuses the command, which names the status command and cdkd rollback --drop-failed.
• An update of a CloudFront distribution, origin access control or origin access identity is refused when the AWS client's region differs from the region recorded in cdkd state (issue #2613) -- src/provisioning/providers/cloudfront-{distribution,oac,oai}-provider.ts (assertRegionMatch now runs before any AWS call in these update()s; their delete()s compare the regions only on a NotFound), scripts/check-provider-update-context.ts (OMITS_UPDATE_CONTEXT is now empty, so every SDK provider's update takes the region the deploy engine passes), and unit cases. CloudFront's client is built in the stack's region rather than pinned to us-east-1, so a stack in any region updates as before; only a client whose region disagrees with the record now stops before the first call, names both regions, and says that the global endpoint would have reached the same resource through a client not built for that stack. A state record with no region is unchanged.
• An update or delete of an S3 Express directory bucket, an S3 Tables table bucket, namespace or table, or a WAFv2 web ACL, an update of a Glue security configuration, and a delete of any Glue resource cdkd's SDK providers handle (database, table, workflow, security configuration, job, crawler, connection, trigger) is refused when the AWS client's region differs from the region recorded in cdkd state (issue #2613) -- src/provisioning/providers/{s3-directory-bucket,s3-tables,wafv2,glue}-provider.ts (assertRegionMatch now runs before any AWS call in these update()s and delete()s; the directory bucket's update compares both the S3 client its ARN comes from and the S3 Control client its tag writes use), scripts/check-provider-update-context.ts (four names leave OMITS_UPDATE_CONTEXT, leaving the three CloudFront providers), and unit cases. A run with a client in another region sent its writes there; a delete checked the region only when AWS answered NotFound, so for a name-shaped physical id it deleted a same-named resource cdkd does not manage. A Glue security configuration update failed with a "cannot be updated in place" error pointing at --replace, whose replacement would then run in the wrong region. The call now stops first and names both regions. A state record with no region is unchanged.
• A failed create, update or delete of an S3 bucket policy, SNS topic policy or SQS queue policy no longer writes the caller's account id, assumed-role ARN and session name into the persisted deployment events, and no longer replaces the failure with a TypeError when the thrown value cannot be converted to text (issues #2319, #3341) -- src/provisioning/providers/{s3-bucket-policy,sns-topic-policy,sqs-queue-policy}-provider.ts, and unit cases. The thrown message interpolated AWS's raw text, which on an access-denied error names the caller, and deployments/{runId}.jsonl outlives the run. The message now carries the error class (AccessDenied. Re-run with --verbose for AWS's own message.) and AWS's text goes to the debug log, through the operation's secret masker. A cdkd-authored or transport error keeps its text. The AWS error stays as the cause, so an IAM grant still propagating is retried as before.
• On Windows, a container secret whose name differs only in letter case from a variable already in your shell now replaces it, and Windows system variables are no longer forwarded as secret names (issue #2190) -- src/utils/docker-cmd.ts. Windows treats MY_TOKEN and my_token as one variable, but both spellings reached the container client's environment, so a secret named my_token reached the container as the host's MY_TOKEN value. cdkd now removes the other spelling before it starts the client, so the secret wins as it does when spelled the same, and it warns when two secrets differ only in letter case (the container then receives the last one's value under both names). A secret matching another name only through a letter outside A-Z (ß against SS) is dropped with a warning instead, so it can never remove the operator's variable. Secrets named ComSpec, SystemRoot, windir, SystemDrive, PSModulePath or PSExecutionPolicyPreference, in any letter case and on every platform, are now dropped with the existing rename warning, because they choose which programs and libraries the client and its credential helpers load or trust. TEMP and TMP are still forwarded. A new windows-env-precedence CI job runs this on a real Windows host. Linux and macOS behaviour is otherwise unchanged.

Recently Implemented (2026-10-14):

• An AWS::GuardDuty::Detector can now be updated in place (issue #4910) -- src/provisioning/cloud-control-provider.ts, a new src/provisioning/guardduty-detector-patch.ts, unit cases and a new guardduty-detector-update integ fixture. cdkd updates the detector through Cloud Control, which applies the patch on top of the model it reads back. For a detector that model carried both DataSources and the full Features list on every read measured (us-east-1 and us-west-2), and UpdateDetector refused them together, whichever of the two the template declared: a scalar-only change failed with EKS_RUNTIME_MONITORING and RUNTIME_MONITORING cannot be provided in the same request, and a Features change with both data sources and features were provided. So the detector deployed once and then refused those updates. Now, for each of the two keys a non-empty update patch has no op on, the patch also gets add /<key> with the declared value, or remove /<key> when the template does not declare it, so the request carries what the template declares, as a CloudFormation update does. Features the template omits keep their AWS status, and RDS_DATA_RISK, which GuardDuty enables under RDS_LOGIN_EVENTS, stays enabled. Every other type is unchanged.
• A failed update that cdkd moved from an SDK provider to Cloud Control API now names the move and the two ways through -- src/provisioning/cc-autoroute-update-remedy.ts, src/deployment/deploy-engine/update-in-place.ts. When a property the SDK provider does not handle is added to a resource recorded on that provider, the deploy routes its update through Cloud Control, which addresses the resource by the physical id the SDK provider recorded; for some types Cloud Control does not accept that id. Such a failure printed only Cloud Control's error. It now also says the update moved the resource to Cloud Control because of the named properties, and gives --recreate-via-cc-api <LogicalId> (re-create it on Cloud Control) and --prefer-sdk-route <Type>:<Property> (stay on the SDK provider without sending them). A successful deploy runs nothing new, and other failures keep their message. Issue #4904.
• AWS published 1 writable property the 2026-10-14 schema refresh now carries, so cdkd classifies it instead of treating it as unrecognized (PR #4902) -- AWS::Route53::HostedZone: DelegationSetId. Changed: tests/fixtures/cfn-schemas/, src/provisioning/property-coverage.generated.ts (regenerated). On AWS::Route53::HostedZone, no SDK provider writes it yet (not yet implemented by cdkd), so pre-flight classifies each as a silent drop and the issue #614 auto-route sends a resource whose template carries one through Cloud Control, which forwards the full property map. Since issue #3713 a key absent from the snapshot already routed so, unless the state record held it with the declared value; such a resource moves on its next deploy. AWS::Route53::HostedZone is not in STICKY_CC_MIGRATION_EXEMPT, so an existing SDK-provisioned resource of that type whose template gains one moves to Cloud Control and pins provisionedBy: 'cc-api' ONE-WAY. The snapshot marks AWS::Route53::HostedZone.DelegationSetId create-only, so it joins createOnlyDrops and the record narrowing keeps it in the record; the capture is top-level-only, so it says nothing about a nested create-only path.
• A replacement whose old resource is still in use by a resource the same deploy has not updated yet now deletes it after the rest of the deploy, instead of leaving it behind (issue #4900) -- src/deployment/deploy-engine/replacement.ts (deleteReplacedAfterCreate defers its first failure; new retryDeferredReplacedDeletes / warnUnretriedReplacedDeletes), src/deployment/deploy-engine/execute.ts, src/deployment/deploy-engine.ts, and a new unit file. A create-first replacement deleted the old resource right after creating the new one, before the dependents had moved to it. When a dependent still used the old resource, AWS refused the delete. For example, an AWS::Lambda::WebFunctionEndpoint refuses the delete of its AWS::Lambda::WebFunctionRevision with a 409 ConflictException. cdkd warned Failed to delete old resource and the old resource stayed in AWS, untracked, on every replacing deploy. Now the first failure inside a deploy is retried once after its creates, updates and deletes have all completed, as CloudFormation deletes old resources in its cleanup phase. The fix is not specific to any resource type. A retry that fails warns as before, and a retry the provider skips makes the row a partial update. A deploy that fails or is interrupted first does not retry, and it warns Failed to delete old resource ... (not retried: ...). The retry runs under the row's own masking, stack-records and delete-guard scopes, and records its skip and guard events as the row's. A delete that succeeds inline is unchanged, so an ordinary deploy makes no extra call.
• cdkd state destroy '<parent>~<child>' resolves a secret principal reference the child's state record places in a region (issue #4887) -- src/cli/commands/destroy-runner.ts, src/provisioning/secret-principal-resolution.ts, src/provisioning/providers/nested-stack-provider.ts, iam-policy-provider.ts, iam-user-group-provider.ts, src/provisioning/region-check.ts. A nested child destroyed on its own skipped every AWS::IAM::Policy / AWS::IAM::UserToGroupAddition whose principal list holds a {{resolve:...}} reference (record kept, exit 2), because the regions its parent reads from are unknown there. It now resolves a region-less reference its state schema v12 record places in a region, in that region, and removes the policy or memberships. A record holding any other region-less reference keeps the skip and the hint to destroy it through the parent, and the child's own nested children inherit that limit instead of reading the child's regions as complete. No new AWS call.
• cdkd drift --revert now removes an out-of-band AWS::SSM::Parameter policy instead of reporting a revert that left it in place -- src/provisioning/providers/ssm-parameter-provider.ts. When the template declares Policies and the recorded baseline holds none, a policy added out of band is drift. The revert sent no Policies, and PutParameter keeps a parameter's policies until it is sent new ones or an empty one, so the policy stayed and the next cdkd drift reported it again. A revert to no policies against a parameter that has some now sends the empty policy the Systems Manager guide documents for removal ([{}]), when the template declares no policies either; a baseline whose empty list stands for a failed read never removes a policy the template declares. A deploy still sends no Policies when the template has none, as CloudFormation does. Issue #4884.
• cdkd destroy resolves a region-less secret reference in an IAM principal list in the region its state record names (issue #4879) -- src/provisioning/secret-principal-resolution.ts, src/cli/commands/destroy-runner.ts, src/provisioning/providers/iam-policy-provider.ts, iam-user-group-provider.ts. An AWS::IAM::Policy or AWS::IAM::UserToGroupAddition whose Roles / Groups / Users names a principal through a {{resolve:...}} reference with no region was skipped (record kept, exit 2) when the stack also reads a value from another region, because the reference could have been resolved there. A state schema v12 record says which region resolved it, so cdkd destroy and cdkd state destroy now resolve it in that region, as the rollback replay, cdkd drift and cdkd scrub already do, and remove the policy or memberships. A record without that field keeps the skip. The destroy makes no new AWS call to find the region. A nested stack destroyed on its own still skips such a record.
• cdkd import --migrate-from-cloudformation records the resource CloudFormation holds after the Retain update, not one it replaced (issue #4873) -- src/cli/commands/import.ts, src/cli/commands/retire-cfn-stack.ts. The command wrote cdkd state from the physical ids it read before the UpdateStack that adds the Retain policies. When that update replaced a resource (an auto-named AWS::SSM::Document is a known case), state named the superseded copy, and cdkd destroy left the live replacement unmanaged. The Retain update now runs before the state write; when it completes, cdkd re-reads the ids (nested stacks included), adopts every resource by the new ids, and warns with both ids; the superseded copy is kept by UpdateReplacePolicy: Retain for you to delete. A failed update or re-read leaves no state from the run, and its error names the manual route (Retain update by hand, cdkd import without the flag, then DeleteStack) and says a replacement CloudFormation cannot perform fails by hand too. When the update may have completed, the error also says how to find retained copies in the stack events. A failed DeleteStack says the state is written and every resource is retained, and to delete the stack by hand once its cause is resolved. After a replacement, --record-resource-mapping is rewritten so it no longer names a superseded id. A resource replaced at any nesting depth that can no longer be imported by its new id refuses before DeleteStack rather than orphan it. A re-import that adopts a different number of resources than were confirmed warns with both counts. Declining the retirement prompt still writes the confirmed state and leaves the stack unchanged; that prompt and its non-interactive refusal now say nothing was written yet. Integ: migrate-from-cfn now fails when the replacement Document survives the destroy.
• A reader left on the value of a resource replaced in an earlier deploy is updated (issue #4852, part 3 of 3) -- src/analyzer/read-provenance-promotion.ts, src/analyzer/diff-calculator.ts, src/deployment/deploy-engine/read-provenance-moved.ts, src/deployment/intrinsic-resolver/cross-stack.ts, src/deployment/rollback-executor/replay-props.ts, src/cli/commands/diff-recursive.ts. A queue named from a secret and replaced after the secret rotated stores its Arn as arn:...:{{resolve:...}}, so a reader of it compared equal to its record and kept the deleted queue's ARN whenever the replacement and the reader's update did not happen in the same deploy: an interrupted deploy, a nested stack's child reading it through a parameter, a cross-stack consumer, or a producer updated in place earlier. With the state schema v12 record, cdkd deploy and cdkd diff now compare the secret versions a reader recorded with the ones its upstream records, promote it (cdkd diff labels it [read value moved upstream]), and send it, naming why. A rotation alone still sends nothing. A cross-stack consumer resolves a reference at the version the producer's output records (one read of the producer's state per deploy, only where needed), and a rollback restores a reference at its record's version. Records without the v12 field behave as before. Integ: secret-derived-immutable-names (5h-5j), cross-stack-secret-import.
• A stored {{resolve:...}} reference is re-resolved in the region and at the secret version its record names (issue #4847, part 2 of 3) -- src/deployment/intrinsic-resolver/recorded-reference-routes.ts, getatt.ts, dynamic-refs.ts, dynamic-ref-lookups.ts, src/deployment/rollback-executor/replay-secrets.ts, src/cli/commands/drift.ts, src/cli/commands/scrub.ts. A resource named from a secret that a stack in another region publishes (Fn::GetStackOutput with Region) stores its Arn as arn:...:{{resolve:...}}; a reader of that Arn added while the resource was unchanged was sent the literal reference (SSM refused it; a queue policy matched nothing), because cdkd could not tell which region resolved it. It now uses the state schema v12 record: the recorded region answers, and a single recorded version is read by a pinned lookup, so a reader also gets the value the resource was named with after the secret rotated. A pinned version that is gone warns and falls back to the previous check. The rollback replay, cdkd drift and cdkd scrub resolve such a reference in its recorded region instead of refusing it. A record without the v12 field behaves as before; an unchanged deploy makes the same AWS calls, and a pin equal to the current version adds none. Integ: getstackoutput-crossregion (two-region arm), rollback-cross-region-secret, rollback-nested-cross-region-secret.
• cdkd drift --revert of an AWS::SSM::Parameter no longer fails with "Start of list found where not expected" -- src/provisioning/providers/ssm-parameter-provider.ts. The read-back baseline drift reverts from holds the parameter's policies as a parsed list (an empty one when it has none), and the update sent that list to PutParameter, which takes a JSON string, so AWS refused every revert of an SSM parameter. A list is now sent as its JSON string, and the empty placeholder as no Policies, as an absent template property is. Found by the rollback-cross-region-secret integ of issue #4847.
• cdkd diff --recursive --fail no longer reports a change on an unchanged nested stack in which one child resource reads a parameter the parent spelled as a literal embedding {{resolve:...}} tokens beside a sibling parameter spelling the same secret differently, either of the two through Fn::Select / Fn::Split (issue #4731). After upgrading, the first deploy of such a stack shows a change on the child resources reading the literal parameter, because their state now records the parameter's own {{resolve:...}} spelling instead of the sibling's. The other direction happens too: where one child resource reads such a parameter as a bare Ref inside an array that also holds an Fn::If or AWS::NoValue element, beside the sibling, every resource in that child reading the parameter now records the sibling's spelling. Either way the deployed VALUE is unchanged, and a create-only property is replaced once with an identical value. Before, cdkd fell back to the sibling's spelling for that parameter in the whole child while cdkd diff --recursive rendered its literal. A child leaf whose source holds Fn::Select / Fn::Split (possibly with Fn::Join beneath or around it) over the child's parameters is now persisted as the deploy's diff side computes it, re-read with the same parameter bindings, when that answer renders back to the resolved value through the parent's own secret pairs. Three cases keep the old behaviour: a read under Fn::If, through Fn::Sub inside Fn::Select, or inside an array holding an Fn::If or AWS::NoValue element (#4919); a split that cuts a token (#4914); and two reads in the child's Outputs (#4913). Source: src/deployment/secret-redaction/{nested-stack,redact-path}.ts, src/deployment/intrinsic-resolver/parameter-secrets.ts.
• A fix-forward deploy now deletes the IAM instance profile or managed policy an earlier failed CREATE left behind (issue #4606, IAM instance profile and managed policy slice) -- src/provisioning/providers/iam-instance-profile-provider.ts, src/provisioning/providers/iam-managed-policy-provider.ts. When a cdkd deploy --no-rollback made an AWS::IAM::InstanceProfile or AWS::IAM::ManagedPolicy, failed wiring it (adding its role, or attaching the policy to a group, role or user) and could not delete it again, and a later deploy kept the logical id under another name, the successful deploy warned about the earlier profile or policy, left it in AWS and exited 2; cdkd rollback and cdkd destroy kept it the same way. The providers now answer both questions: an instance profile or policy name is unique per account, so the earlier one is a different one once the record's reads back (two whose names are equal ignoring case are never compared); and the failed CREATE records the InstanceProfileId / PolicyId its CreateInstanceProfile / CreatePolicy returned, so the earlier one is deleted (a policy detached first) only while its name still reads back under that id. One deleted by hand and re-created under the name has another id and is kept, with a warning. A managed policy that reads back but is gone by its DeletePolicy (a concurrent delete) is now treated as already deleted, after the region check, instead of failing the delete. Tests: tests/unit/provisioning/iam-profile-policy-provider-same-resource-4606.test.ts; integ: iam-profile-policy-fix-forward-orphan.
• A fix-forward deploy now deletes the IAM role an earlier failed CREATE left behind (issue #4606, IAM role slice) -- src/provisioning/providers/iam-role-provider.ts. When a cdkd deploy --no-rollback made an AWS::IAM::Role, failed wiring it (a managed policy, an inline policy or its tags) and could not delete it again, and a later deploy kept the logical id under another role name, the successful deploy warned about the earlier role, left it in AWS and exited 2; cdkd rollback and cdkd destroy kept it the same way. The IAM role provider now answers both questions: a role name is unique per account and cannot be changed, so the earlier role is a different one once the record's role reads back (a record holding the same name in another case holds that role, which is never deleted); and the failed CREATE records the RoleId its CreateRole returned, so the earlier role is deleted only while its name still reads back under that RoleId. A role deleted by hand and re-created under the name has another RoleId and is kept, with a warning. Tests: tests/unit/provisioning/iam-role-provider-same-resource-4606.test.ts; integ: iam-role-fix-forward-orphan.
• A fix-forward deploy now deletes the IAM user or group an earlier failed CREATE left behind (issue #4606, IAM user and group slice) -- src/provisioning/providers/iam-user-group-provider.ts. When a cdkd deploy --no-rollback made an AWS::IAM::User or AWS::IAM::Group, failed wiring it (a permissions boundary, a login profile, a managed or inline policy, or a group membership) and could not delete it again, and a later deploy kept the logical id under another name, the successful deploy warned about the earlier user or group, left it in AWS and exited 2; cdkd rollback and cdkd destroy kept it the same way. The provider now answers both questions: a user or group name is unique per account, so the earlier one is a different one once the record's reads back (a record holding the same name in another case holds that very user or group, which is never deleted); and the failed CREATE records the UserId / GroupId its CreateUser / CreateGroup returned, so the earlier one is deleted only while its name still reads back under that id. One deleted by hand and re-created under the name has another id and is kept, with a warning. Tests: tests/unit/provisioning/iam-user-group-provider-same-resource-4606.test.ts; integ: iam-user-group-fix-forward-orphan.
• A fix-forward deploy now deletes the CloudWatch Logs log group an earlier failed CREATE left behind (issue #4606, log group slice) -- src/provisioning/providers/logs-loggroup-provider.ts. When a cdkd deploy --no-rollback made an AWS::Logs::LogGroup, failed configuring it (its retention, data protection or index policy, or bearer-token setting) and could not delete it again, and a later deploy kept the logical id under another name, the successful deploy warned about the earlier log group, left it in AWS and exited 2; cdkd rollback and cdkd destroy kept it the same way. The provider now answers both questions: a log group name is unique per account and region and cannot be changed, so the earlier one is a different one once the record's reads back (two names equal ignoring case are never compared); and the failed deploy records the log group's ARN and the creationTime CloudWatch Logs reports for it, so the earlier one is deleted only while its name still reads back with that creation time. One deleted by hand and re-created under the name has another creation time and is kept, with a warning. No ordinary deploy makes an extra call: the creation time is read only when a failed CREATE is journaled. Tests: tests/unit/provisioning/logs-loggroup-provider-same-resource-4606.test.ts; integ: logs-loggroup-fix-forward-orphan.
• cdkd drift, state refresh-observed, orphan, import and the cdkd diff / cdkd deploy attribute heal mask a physical name derived from a secret (issue #3869) -- src/cli/commands/{drift,state,orphan,import,diff-recursive}.ts, src/deployment/deploy-engine/heal.ts. These hand a record to a provider with no printing bag bound. For a resource named from a secret, such as an IAM role whose RoleName is a {{resolve:secretsmanager:...}} reference, the provider's --verbose lines printed its physical id. So did a failed read's warning quoting AWS's error, and a resource reading the name (an instance profile's Roles). Each read now runs under the per-resource printing bag cdkd drift --revert and cdkd destroy bind: the record's own name spellings and those of each secret-named record it holds. cdkd drift's report, --json and accept / revert plans mask such a name in a drifted row's path and its value's leaves and keys, keeping the value's shape; --accept still writes the raw value. cdkd orphan and cdkd state orphan --resource mask it in the rewrite, audit and unresolvable report. cdkd import masks a name its template takes from a secret in the read (an id from --resource, --resource-mapping[-inline] or --migrate-from-cloudformation) and the Import plan: listing. Display only. Judged from the records (for import, the template), so a NoEcho-derived name a pre-v11 record holds in plaintext is not recognised. Tests: tests/unit/cli/*-secret-name-needles-3869.test.ts, tests/unit/deployment/deploy-engine-stale-attribute-heal.test.ts. Integ secret-derived-immutable-names step 5k runs cdkd orphan --dry-run over a hand-added reference to the secret-named queue and fails when the log names it.
• cdkd deploy's own messages flatten each value they interpolate to one line, so a logical id, physical id, type or name cannot forge an output line (issue #2676) -- src/deployment/deploy-engine/*.ts (except update.ts, which follows after #4852). The logger sink strips terminal control characters but keeps newlines, so a newline in a value from the template or the state file started a line cdkd never wrote. The deploy engine's log lines and thrown errors now build their text with safeMsg, which keeps cdkd's own newlines and colours and turns each interpolated value's newline or tab into a space. The rule: only the values the deploy engine interpolates are flattened; an error message embedded in a wrapping message (the per-resource Failed to <op> <id>: line, Failed to resolve output <key>:, the replacement failures, the state-save warnings) prints as before, masked where it was masked before but not flattened (asIsMessage in src/utils/display-safe.ts), so a remedy command it ends in keeps its own last line. Under --strict-getatt, the output failure now reads Failed to resolve output <key> (--strict-getatt ...): <message>, with the message last. Where a message is masked for secrets, each value is masked before it is flattened, and the printing maskers (src/deployment/secret-redaction/) also match a secret's flattened spelling. The CodeCommit, S3 Tables, Glue, Cloud Control and provider-registry refusals now flatten the logical id, physical id or property they name. tests/raw-log-interpolation-baseline.json drops these files, so a new raw interpolation in them fails audit:raw-log-interpolation:check.
• cdkd deploy's UPDATE path and its ServiceToken refusal flatten each value they interpolate to one line (issue #2676) -- src/deployment/deploy-engine/update.ts, src/deployment/custom-resource-service-token.ts. The follow-up to the deploy-engine sweep, for the file that sweep left out. A newline in a logical id, resource type or property name from the template no longer starts a line cdkd never wrote in three messages: the Cannot update <id>: resource not found in state error, the Skipping <id>: no actual changes debug line, and the unwritten create-only refusal. The custom-resource ServiceToken refusal (Refusing to deploy <stack>: ...) renders the stack name through displayStackName, and its remedies keep their own line breaks. tests/raw-log-interpolation-baseline.json drops update.ts, so a new raw logger interpolation there fails audit:raw-log-interpolation:check.
• A rollback no longer re-creates the old resource of a replacement whose delete the deploy could not confirm while that resource is still there (issue #2631) -- src/deployment/deploy-engine/replacement.ts, src/deployment/deploy-engine/update-replace.ts, src/deployment/deploy-engine/execute.ts, src/deployment/deploy-engine.ts, src/deployment/rollback-executor/replay-reverse-replacement.ts, new src/deployment/rollback-executor/replaced-survivor.ts, src/types/rollback-journal.ts, src/cli/commands/rollback.ts. When a replacement's delete of the old resource failed (including the post-deploy retry from #4900, or a deploy that failed before it), was skipped by the provider, or was blocked by a failed UpdateReplacePolicy: Snapshot snapshot, a later failure in the same deploy rolled the replacement back by re-creating the old resource. When the old one was still alive, that made a duplicate (auto-named types) or failed with AlreadyExists (named types). The rollback journal now records oldResourceMaySurvive on such an operation (kept when AWS refused the delete outright or it was never sent, unconfirmed otherwise; an additive field, no journal version change), and the rollback reads AWS for the old resource through the provider's drift read before re-creating it. If AWS reports it gone, it is re-created as before. If it is still there and kept, it is re-adopted, with a warning to check it with cdkd drift (exit 2). Otherwise (a delete that may still be running, or no answer) the operation is refused with the journal kept, and the message offers cdkd rollback --orphan. The cdkd rollback plan preview names all three outcomes. An ordinary deploy, and the rollback of any other replacement, makes no extra AWS call.
• An update of a Bedrock AgentCore evaluator or runtime, a DLM lifecycle policy, a DocumentDB subnet group, a Kinesis Data Firehose delivery stream or a Lambda layer version is refused when the AWS client's region differs from the region recorded in cdkd state (issue #2613) -- src/provisioning/providers/{agentcore-evaluator,agentcore-runtime,dlm-lifecycle-policy,docdb-subnet-group,firehose,lambda-layer}-provider.ts (update() now takes the UpdateContext and calls assertRegionMatch before any AWS call), src/provisioning/providers/{agentcore-browser,agentcore-code-interpreter,wait-condition-handle}-provider.ts (they take the UpdateContext too, with no guard: their update() sends nothing), scripts/check-provider-update-context.ts (nine names leave OMITS_UPDATE_CONTEXT), and unit cases in each provider's test file. These providers ignored the recorded region on update, so a deploy, rollback or cdkd drift --revert run with a client in another region sent its writes there -- for a subnet group or a delivery stream, to whatever carried the same name in that region, a resource cdkd does not manage. A DLM DefaultPolicy change and any Lambda layer version update instead failed with a "cannot be updated in place" error pointing at a replacement, the wrong next step when it is the region that disagrees. The update now stops before the first call and names both regions. An update whose state record has no region is unchanged.
• An update of an SQS queue, an S3 bucket policy, an EventBridge event bus or rule, or a Step Functions state machine is refused when the AWS client's region differs from the region recorded in cdkd state (issue #2613) -- src/provisioning/providers/{sqs-queue,s3-bucket-policy,eventbridge-bus,eventbridge-rule,stepfunctions}-provider.ts (update() now takes the UpdateContext and calls assertRegionMatch before any AWS call), scripts/check-provider-update-context.ts (five names leave OMITS_UPDATE_CONTEXT), and unit cases in each provider's test file. These providers ignored the recorded region on update, so a deploy, rollback or cdkd drift --revert run with a client in another region sent its writes there -- for an event bus or rule, to whatever carried the same name in that region, a resource cdkd does not manage (an EventBridge PutRule creates the rule when none exists). An SQS queue update instead failed at AWS with a request-signing error naming neither region, because the SDK sends the call to the queue URL's host but signs it for the client's region. The update now stops before the first call and names both regions. An update whose state record has no region is unchanged.
• cdkd state destroy now removes the earlier versions of the state records it deletes, so their bodies stop being readable by version id (issue #2346 sites 1-3) -- src/state/s3-state-backend.ts (purgeDeletedStateHistory), src/cli/commands/destroy-runner.ts (purgeStateHistory), src/cli/commands/state.ts, src/provisioning/nested-stack-context.ts and src/provisioning/providers/nested-stack-provider.ts, new tests/unit/state/state-destroy-version-purge.test.ts. The state bucket is versioned, so the record delete used to write only a delete marker, and every earlier state.json body (every recorded property and attribute) stayed readable through GetObject with a VersionId. After the delete and the kept-resource record's write, the command now purges the region-scoped key's noncurrent versions, plus those of a cascading nested child. It also purges the legacy <prefix>/<stack>/state.json key's history, but only when no other region of the stack has state.json versions, current or earlier, because that history may belong to that region. Otherwise, or when the record's absence could not be confirmed or the other regions could not be listed, the history is kept and a warning says so. Every other delete keeps the history as the recovery path: cdkd destroy, cdkd state orphan, rollback, export and the v1 -> v2 migration tail. That split is the maintainer's decision on the issue. The purge needs s3:ListBucketVersions and s3:DeleteObjectVersion. Without them the destroy still succeeds, and a warning names both grants.
• Removing AlpnPolicy, MutualAuthentication, Certificates, SslPolicy, Port or Protocol from an AWS::ElasticLoadBalancingV2::Listener now warns that the live value stays -- src/provisioning/providers/elbv2-provider.ts. ModifyListener keeps any field it is not sent, so a removed one stayed live while the deploy reported success and the next cdkd diff showed no change. cdkd still sends no reset, since CloudFormation's behavior on these removals is unmeasured, and now names each removed property in one warning after the update succeeds. SslPolicy and Certificates are not named on an HTTPS to HTTP or TLS to TCP change, where AWS drops them itself. drift --revert prints no such warning. Issue #1160.

Recently Implemented (2026-10-13):

• More cdkd local * AWS-failure relays follow the #2300 render policy (issue #4857, completing #2300's enumerated items) -- src/local/ecr-puller.ts, src/local/ecs-secrets-resolver.ts, src/cli/commands/local-state-loader.ts, local-run-task.ts, local-start-api.ts, src/cli/config-loader.ts, src/utils/local-aws-failure.ts (moved from src/cli/commands/), src/utils/docker-cmd.ts. The ECR-pull refusals (STS GetCallerIdentity, --ecr-role-arn's AssumeRole -- printed twice, the second time as Caused by: -- and ECR GetAuthorizationToken), the ECS secret refusals (Secrets Manager, SSM), the --assume-task-role / local start-api --assume-role / --profile credential refusals, the --from-state state-bucket warns and the uncaught state-bucket access failure printed the SDK error's raw message. They now keep a modeled service exception's message (AccessDenied: User ... is not authorized ...) and print anything else as <Class>[ <code>]; N-character message withheld, logged at debug level under --verbose. Through the default credential chain on the pinned SDK a credential_process failure already arrives as the generic Could not load credentials from any providers, so the main effect is sanitizing forged names and control characters. The ECR errors keep the SDK error's classification fields as their cause through a redacted copy (redactedAwsCause); No cdkd state bucket found ... Run 'cdkd bootstrap' is now a StateError and still prints in full; a withheld --profile failure names the aws sso login remedy.
• cdkd local start-agentcore / start-cloudfront / start-service / start-alb synthesize with cdkd's own synthesizer (issue #4856) -- src/cli/commands/local-host-synthesizer.ts (new), src/cli/commands/local-start-{agentcore,cloudfront,service,alb}.ts, package.json (cdk-local 0.150.0, which takes a synthesizer, go-to-k/cdk-local#787). These four commands synthesized the CDK app through cdk-local's @aws-cdk/toolkit-lib synthesizer, the only cdkd commands that did. They now use cdkd's synthesizer, as local invoke / start-api / run-task do, on boot and on every --watch reload. The stacks these commands pick a target from now include a cdk.Stage's stacks, which cdk-local's synthesizer did not enumerate (go-to-k/cdk-local#746); a stack carrying a CloudFormation macro is expanded, using --state-bucket for a template too large to expand inline, and context lookups and cdk.json / cdk.context.json context resolve as in every other cdkd command. A macro-bearing stack is expanded on every --watch reload too, which needs credentials and a region. --verbose shows the synthesis debug output again, and --role-arn is the identity of the synthesis's own AWS calls (macro change set, upload) under --profile as well. Tests: tests/unit/cli/local-host-synthesizer.test.ts, tests/unit/cli/local-start-own-synth-wiring.test.ts (new). Integ: local-start-agentcore, local-start-cloudfront, local-start-service, local-start-alb, local-start-service-watch-fast, local-start-alb-from-state.
• Editing an SNS subscription's attributes updates it in place instead of replacing it (#4853) -- src/provisioning/providers/sns-subscription-provider.ts. A change to RawMessageDelivery, FilterPolicy, FilterPolicyScope, RedrivePolicy, DeliveryPolicy, ReplayPolicy or SubscriptionRoleArn on an AWS::SNS::Subscription made cdkd deploy unsubscribe and subscribe again. The subscription got a new ARN, messages published in between were not delivered, and an email or http(s) endpoint went back to pending confirmation. cdkd now reads the subscription and applies only the attributes that differ with SetSubscriptionAttributes, keeping the ARN, as CloudFormation does. An attribute removed from the template is reset to its default (RawMessageDelivery off, no FilterPolicy or RedrivePolicy, FilterPolicyScope back to MessageAttributes). A change to the topic, protocol or endpoint, the removal of DeliveryPolicy, ReplayPolicy or SubscriptionRoleArn, and a new FilterPolicy together with a change of its FilterPolicyScope (declared or dropped) still replace the subscription.
• A resource named from a NoEcho parameter keeps its ARN in state, so its readers redeploy (#4849) -- src/deployment/secret-redaction/redact-state.ts, src/deployment/deploy-engine/masking.ts, src/provisioning/providers/nested-stack-provider.ts. When a resource's name came from a NoEcho template parameter (an SNS topic with TopicName: !Ref Name), state.json stored its own ARN attribute (TopicArn) as ***, and so did every stack output and export holding that ARN. The next deploy that re-resolved a reader (editing a subscription or a grant using Fn::GetAtt Topic.TopicArn) failed with Cannot resolve Topic.TopicArn ... redaction mask and rolled back. A consumer stack importing the exported ARN in a later run was refused the same way. AWS publishes a resource's name inside its ARN, and cdkd already keeps the physical id itself as AWS returns it; the ARN attribute, the outputs, the exports and a nested stack's outputs holding a child's id are now kept the same way. An attribute or output that equals the NoEcho value itself (TopicName) still stays ***, unless the resource's physical id is that value (then it is stored as the physical id is). A record an earlier cdkd wrote with *** there is repaired by the next deploy that reads the attribute: cdkd re-reads the resource and replaces the mask only with a value that is the physical id, or an ARN that ends in it with nothing but the ARN's partition, service, region, account and resource type before it (a function's or role's ARN).
• State schema v12: each stored {{resolve:...}} reference records where it was resolved and which secret version it stood for (issues #4847, #4852, part 1 of 3) -- src/types/state.ts, src/deployment/secret-redaction/reference-provenance.ts, src/deployment/reference-provenance-record.ts, src/deployment/deploy-engine/provenance-capture.ts, src/state/token-free-state.ts. A resource record gains referenceProvenance and the stack outputReferenceProvenance: per token, the region that resolved it and the secret's own version ids (a Secrets Manager VersionId, an SSM Version), read off the lookups cdkd already makes, never a value or a hash. Nothing reads them yet: every command behaves as before, and the fixes that use them follow. The first deploy after upgrading adds them to unchanged records through a one-time capture that sends, updates and replaces nothing (a record it cannot attribute gets an empty entry and one warning; a throttled lookup is retried next deploy); later deploys make no extra AWS call, and a stack holding no reference takes no extra work. CDKD_SDK_CALL_LOG=<file> appends, per cdkd process, a line counting every AWS SDK command it sent. Older binaries fail on v12 with "Upgrade cdkd". Integ: schema-v11-to-v12-migration (new).
• cdkd import through Cloud Control keeps ProposedSegmentChange on NetworkManager attachments (PR #4840) -- src/provisioning/getatt-attributes.generated.ts, regenerated from @aws-cdk/aws-service-spec 0.1.219. On AWS::NetworkManager::ConnectAttachment, SiteToSiteVpnAttachment, TransitGatewayRouteTableAttachment and VpcAttachment, ProposedSegmentChange is both a writable property and a Fn::GetAtt attribute. An import recorded it as ***, so a later deploy reading Fn::GetAtt <attachment>.ProposedSegmentChange from the imported resource was refused. It is now kept, like the other writable attributes (#3735).
• --remove-protection keeps a user pool's custom ACR level names (PR #4839) -- src/provisioning/providers/cognito-provider.ts. The AWS SDK bump adds AcrConfiguration to UpdateUserPool, and the API reference says a level a write does not name gets its default name, so the DeletionProtection flip could reset the custom names of an Essentials or Plus pool. The flip now echoes the custom-named levels with the other read-back members (#4066). Levels carrying their default urn:cognito:loa:<n> are not sent, so a pool with no custom name -- every Lite pool -- gets no AcrConfiguration in the write. Tests: tests/unit/provisioning/providers/cognito-remove-protection-rmw.test.ts.
• A reader that spells a secret is no longer skipped, left on a deleted resource's ID, when the secret-named resource it reads is replaced under the rotated secret (issue #4838) -- src/deployment/deploy-engine/update.ts. When a secret rotated and a create-only change replaced a resource named from it (an SQS queue renamed sdin-q-1 -> sdin-q-2), a reader that also spells the same {{resolve:...}} reference (a tag beside Value: Fn::GetAtt Queue.Arn) recorded the new name against that reference, so the new ARN redacted to the same arn:...:{{resolve:...}} it had stored for the old queue. The no-change re-check compared equal, the reader was not updated, and it kept the deleted queue's ARN in AWS. A resource that reads a resource whose physical ID changed in this deploy is now sent, rather than skipped, whenever the redaction rewrote any of its values. A create-only property the redaction rewrote counts as changed, so a reader such as an event source mapping is replaced rather than updated in place. A reader whose values no secret rewrote, or of a resource replaced under the same physical ID, is still skipped. A reader left stale by an interrupted earlier deploy, a nested child fed by a parameter, and a cross-stack consumer are not covered (issue #4852).
• A deploy finishes sooner after its last resource (issue #4837) -- src/provisioning/providers/dynamodb-table-provider.ts, src/state/{lock-manager,s3-state-backend,export-index-store}.ts, src/provisioning/providers/create-token-ledger.ts, src/deployment/deploy-engine/{deploy-flow,rollback}.ts, src/cli/commands/deploy.ts. The bookkeeping after the last resource took ~5s on a 5-resource stack. A DynamoDB table's follow-up reads for its drift baseline (tags, point-in-time recovery, TTL, resource policy, Kinesis destination, contributor insights, stream members) now run concurrently, in the same key order; per-index contributor insights stay one after another. A deploy that finds no rollback journal at its start (under the stack lock) purges the journal key's leftover versions then, beside the deploy (on a first deploy, once its pre-provisioning gate passes), and waits for that purge before releasing the lock on every path; and its success then no longer reads, deletes and purges the absent journal again; any journal write through the same backend voids that. The create-token ledger, and the exports index when the stack's record publishes no export, are read at the start too, so an unchanged success needs no read of either. The state backend opens its connections beside the final drain, as S3 drops a keep-alive socket idle about five seconds. cdkd deploy no longer waits for the lock's old-version purge before its events flush: the lock is still deleted before the deploy returns, and the purge finishes beside the flush, before the command exits. Tests: tests/unit/provisioning/{dynamodb-table-provider-readcurrentstate,create-token-ledger}.test.ts, tests/unit/state/{lock-noncurrent-version-purge,rollback-journal-version-purge,export-index-store}.test.ts, tests/unit/deployment/deploy-engine-tail-ordering.test.ts.
• A copy of a string-declared NoEcho value is now stored masked, as a boolean one is (issue #4831) -- src/deployment/intrinsic-resolver/parameter-secrets.ts. For a parameter declared NoEcho: "true" (the string form CloudFormation accepts), a leaf that held the value without reading the parameter by position (a literal, or a copy in another property) was persisted in plaintext in state.json. The value was recorded only as a log-only needle, unlike NoEcho: true, because masking that copy would have replaced a create-only resource on the next unchanged deploy. Now that the migration witness also reads a record another NoEcho source already marked (#4836), the value is a mask-only needle too. A record written before is masked on its next deploy without being replaced, and the leaf is named in noEchoLeaves. The --verbose log lines that print a resolved value holding it now mask the WHOLE value, as for NoEcho: true (Resolved Fn::Sub: *** rather than Resolved Fn::Sub: str-***). Tests: tests/unit/deployment/noecho-string-value-arm-4831.test.ts. Integ: noecho-parameter-masking Phase 4v deploys an isolated stack with @go-to-k/cdkd@0.297.0, then redeploys it unchanged with this binary, and fails if the topic is replaced, its name prints, or the copy stays in plaintext.
• A reader of an unchanged resource whose secret-derived name is assembled by an intrinsic or read from another stack in the same region is no longer sent the unresolved {{resolve:...}} spelling (issue #4805) -- src/deployment/intrinsic-resolver/getatt.ts (referencesRegionProven), src/deployment/intrinsic-resolver/context.ts, src/deployment/deploy-engine/resolver-context.ts, src/deployment/deploy-engine.ts, src/deployment/deploy-engine/deploy-flow.ts. Since go-to-k/cdkd#4800 a reference in a stored record (an SQS Arn around a queue named from a secret) is resolved before a reader's Fn::GetAtt / Ref is served, but only when the resource's template spelled the token literally and read no other stack. A name built by Fn::Join / Fn::Sub (CDK's secretValueFromJson on a secret in the stack), a literal name beside an imported dead-letter queue, a name read by Fn::ImportValue, or one copied by Fn::GetAtt from another resource was still served as stored: an AWS::SSM::Parameter reader refused it and the deploy failed. cdkd deploy now also proves the region from the stack's cross-stack reads (its state's imports / outputReads, this run's reads and a nested child's ancestors'): when they are complete and name no producer in another region, the reference is resolved here. A stack that reads a stack in another region, or a nested child whose parent's reads are unknown, is served as before. The physical-id check of go-to-k/cdkd#4800 still applies, so a rotated secret or a value that is not the name is still served as stored, with a warning.
• A fix-forward deploy now deletes the Lambda function an earlier failed CREATE left behind (issue #4606, Lambda function slice) -- src/provisioning/providers/lambda-function-provider.ts. When a cdkd deploy --no-rollback made an AWS::Lambda::Function, failed configuring it (RecursiveLoop, ReservedConcurrentExecutions or RuntimeManagementConfig) and could not delete it again, and a later deploy kept the logical id under another function name, the successful deploy warned about the earlier function, left it in AWS and exited 2; cdkd rollback and cdkd destroy kept it the same way. The Lambda function provider now answers both questions: a function name is unique per account and region and cannot be changed, so the earlier function is a different one once the record's function reads back; and the failed CREATE records the function's ARN and the LastModified its CreateFunction returned, so the earlier function is deleted only while its name still reads back under both. A function deleted by hand and re-created under the name has another LastModified and is kept, with a warning; so is one a later code or configuration update changed. A successful PutRuntimeManagementConfig moves LastModified too, so a failure after it journals a live read instead of the create's token. Tests: tests/unit/provisioning/lambda-function-provider-same-resource-4606.test.ts; integ: lambda-fix-forward-orphan.
• broadening no longer depends on a CDK library (issue #4601) -- src/analyzer/security-changes.ts (new), src/analyzer/security-diff.ts, package.json. cdkd diff --fail-on=broadening and cdkd deploy --require-approval=broadening read their verdict and security table from @aws-cdk/cloudformation-diff, a runtime dependency since 0.298.0. They now use cdkd's own classifier, which follows the AWS CDK CLI's rules for IAM statements, managed-policy attachments, AWS::Lambda::Permission, IAM Identity Center and security-group rules. The verdict and the printed table (text and colors) are unchanged, except that text the CDK CLI's table could not lay out (a combining mark, a control character, a ZWJ emoji) is now printed rather than dropped or replaced by a note, and @aws-cdk/cloudformation-diff is gone from cdkd's dependencies (it remains a devDependency for tests). Tests: tests/unit/analyzer/security-changes-parity.test.ts (new) runs both classifiers over 84 template pairs, with and without colors, and requires the same verdict and table, and requires cdkd's table of scrutinized resource types and properties to match the AWS service-spec database.
• cdkd state show / state resources no longer print U+2028 / U+2029 in a record key, logical id or value, and cdkd diff masks a secret that one of them split in a blocking reason (issue #2888) -- src/utils/regexp.ts, src/cli/commands/state.ts, src/cli/commands/diff-recursive.ts, src/analyzer/outputs-diff.ts. The state views write to stdout directly and stripped control characters with stripControlChars alone, which keeps both separators, and a JSON or web log viewer breaks a line on either, so a hand-edited record could still forge a row there. They now go through stripForDisplay, which deletes the same class, replaces the two separators with a space and trims; a legitimate value renders as before apart from leading and trailing whitespace, which is now trimmed. The cdkd diff headers, blocking reasons, Outputs preview values and warnings and the Outputs debug lines take the same helper; the logger already printed both separators as a space there, so only the trim is new. A blocking reason is now masked after that substitution, so a NoEcho value holding a space, carried as correct<U+2028>horse, prints as *** rather than correct horse, including in --json's blocking. Tests: tests/unit/utils/regexp.test.ts, tests/unit/cli/state-show.test.ts, tests/unit/cli/state-resources.test.ts, tests/unit/cli/diff-recursive.test.ts, tests/unit/cli/diff-noecho-render-4049.test.ts, tests/unit/analyzer/outputs-diff.test.ts.
• cdkd local * STS failure warnings follow cdk-local's render policy (issue #2300) -- src/utils/local-aws-failure.ts (new), local-invoke.ts, local-run-task.ts, local-start-api.ts, local-invoke-agentcore.ts. The default-level warn printed when STS GetCallerIdentity (for ${AWS::AccountId}) or --assume-role's AssumeRole failed interpolated the SDK error's raw message, which for a credential_process failure carries the failed command line. Each of the eight sites now renders through cdk-local's describeAwsFailureForWarn: a modeled STS exception keeps its message (AccessDenied: User ... is not authorized ..., one line, capped), and any other failure prints <Class>[ <code>]; N-character message withheld, logged at debug level under --verbose, with the full text at debug through cdkd's own logger. A CdkdError (cdkd's own AssumeRole(<arn>) returned no usable credentials.) still prints in full. The role ARN still prints. A matcher on the old warn text needs updating. The --from-state state-bucket warns and the src/local/** relays: #4857.
• A bare cdkd command uses your AWS profile's region, and keeps finding stacks the old us-east-1 default created (issue #2100) -- src/cli/region-options.ts, src/cli/config-loader.ts, src/state/s3-state-backend.ts, src/synthesis/app-executor.ts, src/assets/docker-build.ts, src/cli/commands/*.ts. With no --region / AWS_REGION, these commands keyed an env-agnostic stack's state, resources and AWS::Region by us-east-1 while their pre-flight clients followed the profile. They now resolve --region, AWS_REGION, AWS_DEFAULT_REGION, the profile's region, then us-east-1, as cdkd bootstrap / gc already did. Compatibility: when the region came from AWS_DEFAULT_REGION or the profile, an env-agnostic stack that has state only in us-east-1 stays there, and cdkd prints Continuing to use us-east-1 so the existing stack is not duplicated; a new stack joins it when the app's other stacks are all held, so the app stays in one region. The same hold applies to a force-unlock lock, the exports index (one file per command, the us-east-1 one while it exists) and a region-less legacy state record (S3StateBackend.stateExistsOwnedBy), and the default state bucket also reads cdkd-state-<account>-us-east-1, preferred while it holds state; cdkd state migrate with no --region picks its source the same way. A stack with state in both regions stays in us-east-1, and a us-east-1 legacy bucket that answers 403 never wins over a working one. A region taken from AWS_DEFAULT_REGION, which the AWS SDK does not read, is copied into AWS_REGION for cdkd's clients but not for the CDK app or an asset's build command. A fresh bare deploy into a profile region without cdkd asset storage creates it or uses the CDK bootstrap assets there. Tests: tests/unit/cli/*-2100.test.ts (new), region-effective, config-loader, state-migrate, s3-state-backend. Integ: profile-region-default (new).
• A provider's delete is handed the secret masker, so it can tell a name is secret-derived (issue #2007) -- src/provisioning/region-check.ts, src/types/resource.ts, src/deployment/deploy-engine/{delete,replacement,update-replace,update-in-place}.ts, src/cli/commands/destroy-runner.ts, src/deployment/rollback-executor.ts, src/deployment/rollback-executor/{names,replay-scope,replay-revert,replay-reverse-replacement,replay-orphan-delete}.ts, src/provisioning/cloud-control-provider.ts and the custom-resource, S3 Express directory bucket, IAM role / managed policy / user / group, DynamoDB global table, Glue, RDS DB proxy target group, SNS subscription and ACM certificate providers. DeleteContext had no maskSecrets, so a provider could not tell that a name it printed was derived from a secret. The S3 Express "bucket is not empty" refusal therefore printed aws s3 rm s3://*** --recursive once the log masked the name: a command that names no bucket. It now says the name is secret-derived and prints no command. A deploy's replacement delete also ran with no resolved value bound for the logger, so a provider's own delete lines could print one; they are masked now. Every cdkd delete site passes a masker: a replacement over the deploy's resolved secrets and its secret-named records, a rollback over both the re-resolved previous generation and the failed deploy's values (its own failure lines and events included), and cdkd destroy or a template-removal delete over the record's secret-derived names. A provider's internal delete during an update or a failed create's cleanup is handed the operation's masker too.

Recently Implemented (2026-10-12):

• Declaring an existing template parameter NoEcho no longer replaces a create-only resource that reads it, and the value is then stored masked (issue #4831) -- src/deployment/secret-redaction/noecho-leaves.ts, src/deployment/deploy-engine/{update,noecho}.ts, src/deployment/deploy-engine.ts. A record written while a parameter was ordinary stores its value in plaintext. Once the template declares the parameter NoEcho, the deploy compares what it would store (***) with that plaintext. The migration witness reconciles the two only when the record carries no noEchoLeaves at all. A record another NoEcho source had already marked read the leaf as moved: cdkd diff and cdkd deploy reported a create-only change and replaced the resource (a fixed-name topic, bucket or table), and cdkd diff printed the stored plaintext as the old value. The witness now covers every record. A leaf whose stored plaintext equals today's value reads as unchanged. The save stores *** there and adds the leaf to noEchoLeaves. A different value is still a change, shown as (previous NoEcho value). When the same deploy updates another property in place, the provider is now handed that leaf's value as the previous one rather than ***, so it no longer reads a create-only change there (an ACM certificate was re-created inside its update). Tests: tests/unit/deployment/noecho-witness-marked-4831.test.ts, tests/unit/cli/diff-noecho-witness-marked-4831.test.ts. Integ: noecho-parameter-masking Phase 4w declares the parameter behind a fixed-name SNS topic NoEcho with its value unchanged, and fails if the topic is replaced or the name prints.
• cdkd diff --security-only (issue #4827) -- src/cli/commands/diff.ts. The flag was refused as an unknown option, while cdk diff --security-only is valid. It now prints, instead of the diff, the AWS CDK CLI's warning and the security table (IAM and security-group changes, secret values shown as ***) of every stack in each top-level tree that broadens permissions, and one line for a tree that does not. It walks nested stacks, refuses --json, and for --fail-on counts only the stacks it prints: any-change fails on a security change in a broadening tree, broadening fails without printing the tables twice, destructive still reads the whole diff. The security diff (#4601) is computed only when the flag or --fail-on=broadening asks. Tests: tests/unit/cli/{diff-fail-on,diff-deploy-refusal-exit}.test.ts; integ require-approval-broadening.
• A template parameter declared NoEcho: "true" (the string form) is masked like NoEcho: true (issue #4824) -- src/deployment/noecho-declared.ts (new), src/deployment/intrinsic-resolver/parameter-secrets.ts, src/deployment/deploy-engine/{masking,noecho}.ts, src/deployment/outputs-export-alias/secret-scan.ts, src/deployment/condition-verdicts.ts, src/deployment/masked-property-fingerprints.ts, src/deployment/noecho-delete-reresolution.ts, src/deployment/intrinsic-resolver/{support,refs}.ts, src/analyzer/skipped-outputs.ts, src/cli/commands/diff-recursive.ts. CloudFormation accepts the string as well as the boolean (a hand-written or CfnInclude template). Several readers tested only the boolean. With the string form, the value printed on cdkd deploy's log lines (the resolver's --verbose lines and its diff lines). The export-name secret scan did not see it, and it fed a recorded condition verdict and the skipped-output digest. These readers now ask one predicate, isNoEchoDeclared (the boolean or exactly "true"). cdkd diff also masks a property's stored copy. A string-declared value copied into a leaf that does not read the parameter still persists in plaintext until the migration witness covers such records (issue #4831): masking it now would replace a create-only resource. A stack whose Export.Name spells a string-declared value loses that export on its next deploy, as a boolean one always did. Tests: tests/unit/deployment/noecho-string-form-4824.test.ts, tests/unit/cli/diff-noecho-string-form-4824.test.ts, tests/unit/deployment/noecho-string-form-replacement-4824.test.ts. Integ: noecho-parameter-masking declares a parameter with the string form and fails when its value reaches the deploy logs, events or state.
• A deploy that swaps an inline policy name between an AWS::IAM::Policy and an AWS::IAM::RolePolicy / UserPolicy / GroupPolicy on one principal now keeps both policies, and so does its rollback (issue #4821) -- src/deployment/inline-policy-claims.ts, deploy-engine.ts, deploy-engine/execute.ts, deploy-engine/replacement.ts, rollback-executor.ts, src/provisioning/cloud-control-provider.ts. Such a swap used to run both writers at once, and the replaced standalone policy's delete of its old name removed the policy that had just taken it, so the principal could end up with neither. CloudFormation finishes the same swap holding only the standalone policy's new name: its cleanup-phase delete removes the other policy. cdkd now runs the writer releasing a name before the standalone policy that takes it (Cloud Control refuses to create a name the principal still holds). A standalone policy's delete then leaves a name another resource of the same deploy has already written there. A rollback reverses that writer before the standalone policy. Writers that share no (principal, name) pair are not ordered, so a deploy with no such collision runs as before.
• cdkd drift no longer reports an AWS::IAM::RolePolicy / UserPolicy / GroupPolicy's policy as Policies drift on its role, user or group (issue #4821) -- src/provisioning/providers/iam-role-provider.ts (collectInlinePolicyNamesManagedBySiblings), src/deployment/deploy-engine/observed-capture.ts. Only an AWS::IAM::Policy sibling's inline policy was excluded from the principal's Policies, so a CfnRolePolicy on a role that declares inline policies showed its name as drift on the role. A standalone policy naming the principal in RoleName / UserName / GroupName is now excluded the same way, in the drift read and in the deploy-time baseline.
• A reader's copy of a secret-named resource's physical id read from another stack or a nested stack's parameter, or named from a NoEcho parameter, is no longer stored as {{resolve:...}} or *** (issue #4819) -- src/deployment/intrinsic-resolver/cross-stack.ts, src/deployment/intrinsic-resolver/parameter-secrets.ts, src/deployment/secret-redaction/fresh-noecho.ts. Since go-to-k/cdkd#4810 a copy read with Ref / Fn::GetAtt in the same stack stays as the id is. A queue policy whose Queues imports another stack's secret-named queue URL with Fn::ImportValue / Fn::GetStackOutput, and whose document spells the secret reference literally, still had the URL rewritten into https://sqs.../{{resolve:...}} by the save, so cdkd destroy of that stack failed with InvalidAddress. A value that is one of a same-account producer's physical ids (read from its state once per resolution) is now recorded as a copy where it is read; any other output value, and one read across an account boundary, is not. A nested child reading a parameter the parent filled with an id it read keeps that id's copy the same way, in cdkd deploy and cdkd scrub, whether or not the parent's row holds a secret. A queue named from a NoEcho parameter, read by a reader that also reads the parameter, had its URL copy flattened to ***; the NoEcho containment arm now keeps a copy's spans too, and still masks the value anywhere else.
• cdkd destroy no longer fails on a reader of a resource named from a secret because a deploy stored the reader's copy of that resource's physical id as a {{resolve:...}} reference (issue #4810) -- src/deployment/secret-redaction/physical-name-copies.ts (new), secret-redaction/redact-state.ts, intrinsic-resolver/refs.ts, deploy-engine/update.ts, src/cli/commands/drift.ts, src/provisioning/providers/scheduler-schedule-provider.ts. An AWS::SQS::QueuePolicy whose Queues reads a queue named from a secret, and whose policy document spells the secret reference literally, had its plaintext Queues URL rewritten into https://sqs.../{{resolve:secretsmanager:...}} by the save after a deploy (the final save after an automatic rollback included), because the policy's own secrets bag held the queue name; cdkd drift --accept / --revert did the same. The provider deletes by that URL, so cdkd destroy failed with InvalidAddress. Each physical id a Ref / Fn::GetAtt reads (for drift, every other record's) is now recorded beside the reader's secrets, and those writes keep a secret's text inside such an id, as the id is stored in plaintext. Elsewhere in a value, and in a literal reference, it is still the reference. The automatic rollback's own restore is go-to-k/cdkd#4801's half; that shape is fixed once both are released. A record an earlier deploy rewrote is repaired by the next cdkd deploy, which sends and replaces nothing for it, though its plan, cdkd diff and --require-approval show the reader as changed once; a cdkd destroy run first still fails. A copy read from another stack, through a nested stack's parameter, or of a NoEcho value is not covered (issue #4819).
• A cross-account Fn::GetStackOutput that the AWS CDK generates is now read through the producer account's CDK lookup role, or refused before the deploy with both remedies (issue #4808) -- the new src/deployment/intrinsic-resolver/cdk-cross-account-ref.ts, stack-output.ts, src/synthesis/assembly-reader.ts (StackInfo.lookupRoleArn), src/analyzer/cross-stack-deps.ts, src/cli/commands/deploy.ts, diff.ts, diff-recursive.ts. Such a reference used to fail mid-deploy with "RoleArn must be a literal string" (or, under @aws-cdk/core:enablePartitionLiterals, with an AssumeRole denial). cdkd deploy and cdkd diff now recognize it, only for a reference carrying a RoleArn: the RoleArn is a literal ARN or CDK's exact Fn::Join over AWS::Partition, and the producer stack in the same assembly declares a role of that name trusting only CloudFormation execution roles. cdkd then assumes the producer artifact's lookup role and reads the producer's state as for any RoleArn; the secret refusal still applies. When the producer is not in the assembly, names no lookup role, or the lookup role or state read is denied, cdkd refuses and names cdk bootstrap --trust-for-lookup <consumer-account> and a user-written cdk.Fn.getStackOutput(); cdkd deploy refuses the first two before anything is provisioned when the reference sits in a top-level stack's resource that every deploy resolves; one in a nested stack or a conditional branch is refused when it is resolved. A role you wrote keeps today's behavior, and a reference without RoleArn runs none of this.
• A reader of a resource named from a secret is no longer updated again on the deploy after that resource is updated (issue #4802) -- src/deployment/intrinsic-resolver/getatt.ts (recordProducerSecretPairs), src/deployment/intrinsic-resolver/context.ts, src/deployment/deploy-engine/resolver-context.ts. When a deploy updated an SQS queue named from a secret, a reader of its Fn::GetAtt Queue.Arn was served the provider's fresh ARN in plaintext and stored it that way, while a reader of an unchanged queue stores the reference form (go-to-k/cdkd#4800). The next deploy's diff reads the queue's stored, reference-form ARN, so every such reader was updated once more. A reader served an attribute of a resource resolved in the same deploy now records that resource's own secret pairs its value carries, and stores the reference form too, when the resource keeps its physical ID. A deploy that creates or replaces it still stores the plaintext in its readers and in a stack output reading it (an export alias carrying it is published on that deploy and withheld on the next), as before.
• A rollback that restores a resource holding a copy of a secret-derived physical name now records that copy as AWS knows it, so the next cdkd destroy can delete it (issue #4801) -- src/deployment/rollback-executor/replay-secrets.ts (redactRollbackRecord, keepPersistedPlainLeaves), with the previous record's attributes passed in by src/deployment/rollback-executor.ts, src/deployment/rollback-executor/replay-revert.ts and src/deployment/rollback-executor/replay-reverse-replacement.ts, and the rollback journal's copy of each previous record in src/deployment/deploy-engine/rollback.ts. When an automatic rollback (or cdkd rollback) reverted a resource such as an AWS::SQS::QueuePolicy whose queue is named from a {{resolve:secretsmanager:...}} reference, the restored record had the queue name inside its Queues URL replaced by the reference, so cdkd destroy failed with "The address https://sqs.../{{resolve:secretsmanager:...". The restore, and the journal cdkd rollback restores from, now keep a plaintext value exactly as the previous record stored it, in properties and attributes, as a normal deploy stores it. A value the previous record stored as a reference is still stored as the reference, and the rollback writes no value the previous record did not already hold. A record an older cdkd wrote with a secret value in plaintext is restored as it was; cdkd scrub repairs it.
• A reader of a resource named from a secret is no longer sent the unresolved {{resolve:...}} spelling when that resource is unchanged (issue #4800) -- src/deployment/intrinsic-resolver/getatt.ts (reresolveRecordedReferences), refs.ts. State stores a secret-derived attribute with the secret's expression in place of its value, so an SQS queue named from a secret records its Arn as arn:aws:sqs:...:{{resolve:secretsmanager:...}}. A deploy that left the queue unchanged served that record to a reader's Fn::GetAtt Queue.Arn and sent the spelling to AWS: an AWS::SSM::Parameter refused it and the deploy rolled back, while an AWS::SQS::QueuePolicy accepted it and its Resource matched nothing. A value an Fn::GetAtt or Ref serves from a stored record's attributes now resolves the references it carries first, when the resource's own template spells each one literally and reads no other stack's value anywhere in its properties, and when the resource's physical id holds the value each resolves to. Otherwise it is served as stored: a name assembled by an intrinsic or read from another stack (issue #4805), and, with a warning, any value the physical id does not hold: a secret rotated since the resource was deployed (it still carries the old name), but also a value that is not part of the name (a custom resource's Data, an AWS::S3Tables::Table TableName on the Cloud Control route) and a name shorter than four characters. The reader's record stores the expression back. A reader that stored the plaintext ARN after an update of the queue is updated once more, with the resolved ARN; that extra update is issue #4802.
• cdkd diff --fail-on=broadening and cdkd deploy --require-approval=broadening (issue #4601) -- src/analyzer/security-diff.ts (new), src/deployment/deployment-approval.ts, src/deployment/deploy-engine/options.ts, src/deployment/deploy-engine/deploy-flow.ts, src/cli/commands/{diff,diff-recursive,deploy,require-approval}.ts, package.json. Both options were refused as invalid choices, and "requireApproval": "broadening" in cdk.json (the AWS CDK CLI's default) was ignored with a warning, so a deploy that cdk would stop for approval went ahead. Both now take broadening, decided by the AWS CDK CLI's own security diff (@aws-cdk/cloudformation-diff's permissionsBroadened, now a direct dependency, loaded only at this level): an added IAM statement, managed-policy attachment, AWS::Lambda::Permission or security-group rule. cdk.json's broadening is honoured, so such a deploy now asks, and without a terminal it fails unless --yes. The approval prompt and the --fail-on report print the CDK CLI's security table. A secret value is shown as *** in the table; a masked policy or rule that changed counts as broadening, since it cannot be judged. With no deployed template, cdkd compares its state with the change, resolved as far as cdkd diff resolves it; a reference to a replaced resource is not a change. --fail-on=broadening walks nested stacks; under --require-approval each nested stack asks for its own changes. The default level stays never. Integ: require-approval-broadening. Tests: tests/unit/analyzer/security-diff.test.ts, tests/unit/deployment/deployment-approval-broadening-cost.test.ts, tests/unit/cli/diff-broadening-secrets-4601.test.ts (new), tests/unit/cli/{diff-fail-on,require-approval}.test.ts, tests/unit/deployment/{deployment-approval,deploy-engine-require-approval}.test.ts.
• Two AWS::IAM::Policy resources with no dependency between them that swap an inline policy name on one principal, or hand one off (a rename away from a name a new policy takes), no longer both lose it (issue #4227) -- src/deployment/inline-policy-claims.ts (orderInlinePolicyWriters), src/deployment/deploy-engine/execute.ts, src/deployment/deploy-engine.ts. Such resources used to run at once, so each one's removal of its old name could miss the other's put, leaving the role with neither policy until a later deploy changed one of them. Before dispatch, the deploy now makes each create / update that writes the same inline policy name on the same role, group or user wait for the one before it; a pair the template already orders, and every other resource, run exactly as before, so an ordinary deploy is unchanged. A name or principal cdkd cannot read before resolving counts as any name or principal of that kind; a principal of the same stack is told apart by its logical id even when its name is a token, so policies on different such roles stay concurrent. An AWS::IAM::Role / Group / User update that drops a name from its own Policies now also keeps it when another resource of the same deploy has already put that name there, as a rollback already did. Covered by tests/unit/deployment/inline-policy-write-order.test.ts, tests/unit/deployment/deploy-engine-inline-policy-claims.test.ts, and an unordered arm in the iam-role-policies-drift-clean integ fixture.
• cdkd destroy masks a resource name taken from a NoEcho parameter in state written before schema v11 (issue #3869) -- src/deployment/secret-name-needles.ts, src/deployment/noecho-delete-reresolution.ts, src/deployment/rollback-executor/journaled-orphans.ts, src/deployment/intrinsic-resolver/support.ts, src/cli/commands/destroy-runner.ts. Since v11, a NoEcho value persists as ***, and nothing migrates an older record when it is read. So a pre-v11 record still holds the value in plaintext, with no marker saying it is secret. Its delete lines printed the whole id (Deleting Bucket <value>), and so did a reader holding the name and the id spellings a provider folds. cdkd destroy now binds the stack's NoEcho values once from the synthesized template, falling back to each literal Default when the binding fails, and hands them to a nested child. It binds nothing when no NoEcho parameter is declared, and waits at most 10 seconds, warning on expiry. Every delete's printing bag, journaled failed-CREATE orphans and both pre-prompt orphan listings included, is judged with these values and also masks the values themselves. Without a usable template (cdkd state destroy, cdkd drift --revert, the state-only fallback, a stack no longer in the app, a macro template, another region's synth), or for a value changed since the record was written, the judgement stays record-only until the next cdkd deploy rewrites the record. The prompt's list of resources an earlier rollback kept (state.orphans) now masks an id named from any secret, as cdkd diff does. A NoEcho: "true" string now redacts the parameter's --verbose line too. Masking only. Tests: tests/unit/cli/destroy-noecho-plaintext-name-3869.test.ts, tests/unit/deployment/secret-name-needles-3869.test.ts, tests/unit/deployment/noecho-delete-reresolution.test.ts, tests/unit/deployment/noecho-string-true-parameter-log-3869.test.ts.
• cdkd import through Cloud Control no longer masks a Fn::GetAtt attribute that is also a writable property (issue #3735) -- src/provisioning/read-only-properties.ts (new getTopLevelAttributeNames), src/provisioning/cloud-control-provider.ts, the new generated src/provisioning/getatt-attributes.generated.ts and its generator scripts/gen-getatt-attributes.ts (vp run gen:getatt-attributes, vp run audit:getatt-attributes:check, chained into gen:all-matrices), and src/deployment/deploy-engine/masking.ts. The import kept only the type's registry readOnlyProperties and recorded every other model key as ***, but CloudFormation also accepts some writable properties in Fn::GetAtt (AWS::EC2::Subnet VpcId / CidrBlock / AvailabilityZone, AWS::SQS::Queue QueueName, ...). A later deploy reading one from an imported resource was refused, and the printed remedy (cdkd import --force) masked the same key again. The import now also keeps the writable properties the CloudFormation resource specification lists as attributes with the same value shape, from a table generated from the pinned @aws-cdk/aws-service-spec devDependency (no new runtime dependency). Other writable properties stay masked (so does AWS::SSM::Parameter Value), and an unresolvable schema still masks the whole model. Docs: docs/import-resource-types.md.
• cdkd state refresh-observed <stack> --accept-refused <LogicalId> --template <file> clears one resource's parameter baseline refusal on the user's assertion (issue #3466) -- new src/cli/commands/state-refresh-observed.ts, src/cli/commands/state.ts, src/cli/commands/refused-baseline-remedy.ts, docs/cli-state-writing.md, docs/cli-destroy-prompts.md. Previously an unverifiable-parameter (or reason-less) refusal cleared only on replacement or a re-import a CloudFormation stack could prove, impossible after --migrate-from-cloudformation. The new flag takes one logical id of one stack (--all, several stacks and a second id are refused) and the template the stack was last deployed from. It refuses an incomplete-resolution refusal, a resource the template does not define or types differently, a template it cannot judge, a resource that still reads a declared parameter (directly or through another resource's attribute), a record that does not hold exactly what the template defines (Ref / Fn::GetAtt / Fn::Join / Fn::Sub / Fn::Select evaluated against the stack's records, anything else refused), and a record holding a parameter's Default. The prompt states the assertion: AWS holds no secret the template does not spell as a dynamic reference, because whatever it holds is written to state.json. -y / --yes logs it as a warning instead; without it a non-interactive run is refused. Only that resource is read back, through the same position-based redaction as any refresh, and both observedBaselineRefused and observedBaselineRefusalReason are removed only after the read succeeds. The sticky remedies name the command. Tests: tests/unit/cli/state-refresh-observed-accept-refused.test.ts. Integ import-deployed-parameter-secret step 6d refuses an undeployed template and the parameter-bound record, then accepts a function moved to a dynamic reference.
• AWS::DynamoDB::Table now refuses an OnDemandThroughput ceiling member CloudFormation rejects, before any AWS call, instead of dropping it and deploying green (issue #3286) -- src/provisioning/providers/dynamodb-table-provider.ts (onDemandCeilingRefusal, refusedOnDemandCeilingShape), tests/unit/provisioning/dynamodb-table-provider-cfn-integer.test.ts and the dynamodb-ondemand integ fixture (Phase 1.8). A MaxReadRequestUnits / MaxWriteRequestUnits spelled padded, hex, exponent, decimal, null, boolean, array or object, at the table level or in a GlobalSecondaryIndexes[] entry, used to be omitted with a warning; both members are optional, so the request succeeded with that half unapplied while state recorded the declared spelling, and cdkd drift reported it on every run. create() and update() now throw naming the resource, the member and the value's TYPE (never the value; an index by position), as CloudFormation refuses the same template. On an update only a pending send is checked: an unchanged block sends nothing and is not refused. Integers, quoted integers and the -1 "remove the maximum" sentinel deploy as before; a blank string, an integer beyond JavaScript's safe range and a rollback replay keep the previous warn-and-drop, since CloudFormation may accept the first two and a replayed state record cannot be fixed from the template.
• A Cloud Control create or update no longer records the whole resource model as the resource's attributes, so the first deploy after cdkd import keeps the import's narrowing (issue #2925) -- src/provisioning/cloud-control-provider.ts (maskDeployedNonAttributeKeys), src/provisioning/read-only-properties.ts (getTopLevelDeployAttributeNames), the generated SHAPE_MISMATCHED_GETATT_ATTRIBUTES, src/cli/commands/import.ts, src/deployment/deploy-engine/masking.ts. Every model key that is not an Fn::GetAtt attribute of the type is now recorded as ***, key kept, as cdkd import already did. Every attribute the CloudFormation resource specification lists stays in the clear, including the writable ones whose value shape differs from the property's (AWS::DocDB::DBCluster Port, which CDK's allowDefaultPortFrom reads), and keys the enrichment computes (Endpoint.Address, ...) are never masked; AWS::SSM::Parameter Value stays clear unless the deploy resolved it from a secret. When the deploy cannot read the schema (no cloudformation:DescribeType), it still records the whole model, as before, rather than refusing every Fn::GetAtt. A re-import's "produced no value to replace the redaction mask" warning now names only keys the template reads through Fn::GetAtt or Fn::Sub; other kept masks go to --verbose. The masked-attribute refusal's Cloud Control cause no longer says only cdkd import writes the mask. Docs: docs/import-resource-types.md, docs/import-after.md, docs/import-internals.md, docs/cli-export-internals.md.
• The state bucket now expires custom-resource response objects with a one-day lifecycle rule (issue #2353) -- new src/state/state-bucket-lifecycle.ts, src/cli/commands/bootstrap.ts, src/provisioning/providers/custom-resource-provider.ts. A custom resource's handler writes its whole response, Data included, under custom-resource-responses/ in the state bucket. A run killed before cdkd deleted it left that object live until cdkd gc ran. cdkd bootstrap now adds the lifecycle rule cdkd-custom-resource-responses-expiration for custom-resource-responses/cdkd-1: a current version expires after one day and its noncurrent version one day later, each rounded up to midnight UTC. A state bucket bootstrapped earlier gets the rule from the first deploy or destroy that runs a custom resource: one GetBucketLifecycleConfiguration per run, started beside the response placeholder write and never awaited, plus a listing and one PutBucketLifecycleConfiguration the first time. Stacks with no custom resource make no call. The rule is merged into the existing configuration: every existing rule is kept, and nothing is written when a rule with the same ID exists, when the configuration cannot be read, or when a stack's state is stored where the rule would reach it (--state-prefix custom-resource-responses with a stack named cdkd-1*). A missing permission prints a warning on each such run and never fails the bootstrap, deploy or destroy.
• cdkd now reads the region of a cloud assembly's stack environment exactly as the AWS CDK CLI does, and refuses the ones it refuses, such as aws://<account>/US-EAST-1 (issue #2221) -- src/types/assembly.ts (parseEnvironment), src/synthesis/assembly-reader.ts. cdkd used to take any text after aws://<account>/ as the region. For US-EAST-1 the deploy succeeded against the lowercase region, because its AWS clients fold the region they sign with, but recorded the stack's state under the raw spelling (cdkd/<stack>/US-EAST-1/state.json), which a later deploy from the correctly spelled assembly does not read. A region carrying a line break fell back to the command's own region. The region is now the longest run of lowercase letters, digits and - after the /, the rest ignored, which is how the AWS CDK CLI reads it: us-east-1/extra, us-east-1 and a region followed by a line break all read as us-east-1. Where no such run starts right after the / (US-EAST-1, us-east-1), reading the assembly fails, naming the stack and the region, as the AWS CDK CLI fails with Unable to parse environment specification. The message tells you which spelling to re-synthesize with. For a spelling that differs only in case, it also warns that state an earlier cdkd recorded under the raw spelling is not found by the corrected deploy, and that cdkd state show and cdkd state orphan still reach that record with --stack-region given the exact raw spelling. The account part of the environment and the unknown-* sentinels are unchanged.

Recently Implemented (2026-10-11):

• cdkd's errors, warnings and --help text no longer cite GitHub issue numbers or probe dates -- 40 files under src/ (the type-change and ServiceToken refusals, the Glue Iceberg refusal, the Cognito, DynamoDB, EFS, Firehose and RDS notes, the cdkd local start-alb / start-cloudfront warnings and help, and the cdkd events, destroy --purge-events, state show --show-nested and deploy --recreate-via-sdk-provider help text, among others). Messages such as which cdkd does not replace in place (issue #2668). told a user nothing they could act on; each now states the behavior without the reference, and a message that leaned on one ("written by a cdkd version older than issue #1681") names an older cdkd version instead. The measured dates in the Glue, Cognito, DynamoDB and cdkd export messages are gone too. Wording only: no message changes what cdkd does.
• cdkd destroy of a parent stack whose nested child left only resources a failed deploy created now finishes in one run (issue #4738) -- src/provisioning/providers/nested-stack-provider.ts, src/cli/commands/destroy-runner.ts (journaledOrphanSkips on the result), src/provisioning/nested-stack-context.ts, and the new src/cli/commands/destroy-skip-message.ts used by destroy.ts and state.ts. A failed-CREATE resource that the rollback journal alone records, and that cdkd keeps in AWS because nothing proves it is the deploy's own (an SQS queue, for example), keeps no state record. A nested child whose only skips were such resources had already deleted its own state, yet the parent kept its AWS::CloudFormation::Stack row and its own state and needed a second destroy. The parent now drops that row and its state in the same run. Those resources still count as skipped, so the run exits 2, and the row's line names how many the child left. The final message of a cdkd destroy / cdkd state destroy whose every skip is such a resource no longer says "State preserved (the records are kept)": it says the resources were left in AWS and no state records them. When recorded skips sit beside them, only the recorded ones are counted as entries kept in state. A deploy that removes such a nested stack, and a rollback, are unchanged: they keep the row, and their next run finds the child's state gone.
• A fix-forward deploy now deletes the DynamoDB global table an earlier failed CREATE left behind (issue #4606, DynamoDB global table slice) -- src/provisioning/providers/dynamodb-globaltable-provider.ts. When a cdkd deploy --no-rollback made an AWS::DynamoDB::GlobalTable, failed configuring it (a replica, a TTL or a replica tag) and could not delete it again, and a later deploy kept the logical id under another table name, the successful deploy warned about the earlier table, left it in AWS and exited 2; cdkd rollback and cdkd destroy kept it the same way. The global table provider now answers both questions by the TableId of the table in the stack's region, which AWS generates and never reuses: the failed CREATE records the id its CreateTable returned, and the successful deploy deletes the earlier table only when the record's table reads back under another TableId and the old name still reads back under the recorded one. A table deleted by hand and re-created under the name has another TableId and is kept, with a warning. Tests: tests/unit/provisioning/dynamodb-globaltable-provider-same-resource-4606.test.ts; integ: globaltable-fix-forward-orphan.
• cdkd diff and cdkd deploy mask a secret-derived name that only a stored OLD value holds (issue #3869) -- src/deployment/secret-name-needles.ts, src/cli/commands/diff-recursive.ts, src/deployment/deploy-engine/{masking,deploy-flow,provision}.ts. Consider a metric filter whose create-only LogGroupName moves from a log group named from a secret to an ordinary one. The row's old side is the state record's copy of the secret group's name, and nothing in the new template reads that group, so no resolution recorded the name. The requires replacement (from <old> to <new>) line of cdkd diff --verbose and cdkd deploy --verbose printed it. So did cdkd diff --json's row, an output's stored old value, a nested child's line for a name its parent's row used to pass, and a deployed replacement's Deleting old <id> (<old id>) and was replaced lines, logged without --verbose, whose old id embeds the name. storedSecretNameNeedles now takes each record named from a secret, judged from state and the stack's whole NoEcho values, wherever another record or a stored output holds its name. A segment the record itself stores in the clear stays public. cdkd diff masks every line and row with these, adopted orphan records included, and hands a nested child its parent's secret-named records. The deploy masks its replacement line and a replaced row's old-id lines, and a nested-stack row's printing bag carries the parent's records, as the deploy found them, into the child's deploy. Masking only. Tests: tests/unit/cli/diff-secret-name-needles-3869.test.ts, tests/unit/deployment/deploy-engine-replacement-line-secret-name-3869.test.ts. Integ secret-derived-immutable-names steps 5c and 5d move a metric filter off a secret-named log group under cdkd diff --verbose, cdkd deploy --dry-run --verbose and a real deploy, and fail when a log names the group.
• An update of a KMS key or alias, an ECR repository, a CloudWatch alarm or a CodeBuild project is refused when the AWS client's region differs from the region recorded in cdkd state (issue #2613) -- src/provisioning/providers/{kms,ecr,cloudwatch-alarm,codebuild}-provider.ts (update() now takes the UpdateContext and calls assertRegionMatch before any AWS call), scripts/check-provider-update-context.ts (four names leave OMITS_UPDATE_CONTEXT), and unit cases in each provider's test file. These providers ignored the recorded region on update, so a deploy, rollback or cdkd drift --revert run with a client in another region sent its writes to whatever carried the same name there, a resource cdkd does not manage. The update now stops before the first call and names both regions. An update whose state record has no region is unchanged.

Recently Implemented (2026-10-10):

• cdkd deploy and cdkd destroy of a stack with hundreds of CloudWatch alarms no longer fail on Rate exceeded (issues #4774, #4781) -- src/provisioning/providers/cloudwatch-alarm-provider.ts (create(), update(), delete() through one sendWithThrottleRetry), a new unit file, and the throttle-wide-dag integ fixture (now with 300 alarms). The provider sends one PutMetricAlarm or DeleteAlarms per alarm, and a deploy or destroy runs them in parallel, so a large stack met CloudWatch's request quota. The engine's own per-resource retry ran out: a deploy failed and rolled back on an alarm create, and a destroy ended partially destroyed with alarms left behind. A throttled alarm write is now retried inside the provider with jittered backoff (8 retries, about 45s to 91s in total) before the engine's retry sees it. Any other failure is not retried there, and on delete ResourceNotFound is still treated as already deleted.
• A rollback reverses a delete-first replacement by deleting the new resource first (issue #4690) -- src/deployment/rollback-executor/replay-reverse-replacement.ts, src/deployment/deploy-engine/execute.ts, src/types/rollback-journal.ts, src/deployment/rollback-executor/types.ts, plus tests and the alb integ's Phase 6. Before this change, when a --recreate-via-cc-api / --recreate-via-sdk-provider recreate (or the update-unsupported fallback, --replace's delete-first fallback, or a child lost with its re-created parent) succeeded and a later operation in the same deploy failed, the rollback re-created the OLD resource while the NEW one still existed. For a resource only one copy of which can exist (an ELBv2 listener's port), the re-create collided, the rollback refused, and the user had to run cdkd rollback --orphan. The rollback journal now records, on every completed UPDATE, whether the deploy deleted the old resource before creating the new one (oldDeletedBeforeCreate, additive, no journalVersion bump). When it did, the rollback deletes the new resource first and then re-creates the old one. If that delete fails or is skipped, state keeps pointing at the new resource and the journal is kept. A journal written by an older cdkd, and a new resource kept by UpdateReplacePolicy: Retain, keep the create-first order, as does a resource whose old properties name another resource the same deploy replaced or deleted, which the rollback may not be able to restore under that id; its re-create never deletes the new resource first.
• A fix-forward deploy now deletes the DynamoDB table an earlier failed CREATE left behind (issue #4606, DynamoDB table slice) -- src/provisioning/providers/dynamodb-table-provider.ts. When a cdkd deploy --no-rollback made an AWS::DynamoDB::Table, failed configuring it (a TTL, point-in-time recovery or stream setting) and could not delete it again, and a later deploy kept the logical id under another table name, the successful deploy warned about the earlier table, left it in AWS and exited 2: it could not prove the two were different tables, nor that the table under the old name was still the one the failed CREATE made. The DynamoDB provider now answers both by the table's TableId, which AWS generates and never reuses: the failed CREATE records the id its CreateTable returned, and the successful deploy deletes the earlier table only when the record's table reads back under another TableId and the old name still reads back under the recorded one. A table deleted by hand and re-created under the name has another TableId and is kept, with a warning. The same identity serves cdkd rollback and cdkd destroy for such a journaled table. Tests: tests/unit/provisioning/dynamodb-table-provider-same-resource-4606.test.ts; integ: dynamodb-fix-forward-orphan.
• cdkd diff and the deployment events mask a secret-derived name a parent passes to a nested stack (issue #3869) -- src/cli/commands/diff-recursive.ts, src/deployment/deploy-engine.ts. Consider a nested stack whose parameter reads a resource named from a secret, such as Parameters: { QueueUrl: Ref SecretQueue }. cdkd diff --recursive discarded the needles of that read, so its walk into the child printed the queue name on the child's Parameter QueueUrl: using user-provided value line, its Ref lines and its changed rows. The row's reads now go into a mask-only bag. That bag is bound around the child's whole walk and masks its rows, a grandchild's included. It never joins the child's inherited secrets, so no export preview moves. A deleted nested stack's stored values are masked too, with the needles of the live stack above it and of every record named from a secret. On deploy, a nested child engine's event text in deployments/*.jsonl was masked only with the child's own secrets. That text is an AWS error quoting such a value. Every event is now masked in one pass with the resource's own secrets and the printing bags bound where it is recorded. That masker, the log sink and every printed-text mask now mask overlapping needle matches as one span, so neither leaves a fragment; a rollback refusal still masks a needle spanning lines. src/deployment/secret-redaction/log-only.ts, mask-errors.ts, src/deployment/secret-name-needles.ts. The physicalId field is unchanged. Tests: tests/unit/cli/diff-secret-name-needles-3869.test.ts, tests/unit/deployment/secret-name-needles-3869.test.ts, tests/unit/deployment/deploy-engine-derived-name-needle-3869.test.ts. Integ secret-derived-immutable-names step 5b now runs cdkd diff --recursive and FAILs when the child's lines name the queue; it used to print a NOTE.

Recently Implemented (2026-10-09):

• AWS::EMR::InstanceFleetConfig now records InstanceFleetId as well as Id in its attributes (issue #4770) -- src/provisioning/providers/emr-instance-fleet-config-provider.ts and emr-instance-group-config-provider.ts, plus tests. The CFn schema renamed the read-only attribute from Id to InstanceFleetId (#4769). Before this change, a template reading the new name got its value only through the physical-ID fallback, with a warning. It was refused under --strict-getatt, and cdkd orphan could not rewrite it. An aws-cdk-lib regenerated from that schema emits the new name as attrInstanceFleetId. create, update and getAttribute now serve both names as the instance fleet id, which is also the physical id. A fleet whose state was written before this change keeps only Id until its next update or replacement. Until then, InstanceFleetId still resolves through the fallback. The same holds for an AWS::EMR::InstanceGroupConfig update that changes nothing mutable: it now records InstanceGroupId too, where it previously kept the old attribute bag.
• Messages and help that send the reader to the documentation now link to the matching cdkd.dev section, instead of a repository path or a GitHub blob URL (PR #4768) -- src/cli/commands/{local-start-api,scrub}.ts, src/cli/options.ts, src/utils/role-arn.ts, src/provisioning/{provider-registry,replacement-protection-advice}.ts, src/provisioning/providers/logs-loggroup-provider.ts. The local start-api VPC and AWS_IAM warnings and help link to https://cdkd.dev/local-start-api/; the AssumeRole failure to the trust-policy setup on cross-stack-internals; the AWS_PROFILE-with-assumed-role warning to cli-reference/#profile-vs-role-arn; the deletion-protection replacement refusals and the LogGroupClass refusal to their section of cli-deploy-safety; the sticky Cloud Control warning and the stateful-types help text to that page; and the scrub legacy-key refusals to the version purge on cli-scrub. The distributed cdkd-skills plugin links to cdkd.dev the same way (0.7.14). Tests: tests/unit/scripts/cdkd-dev-links.test.ts resolves every cdkd.dev link in src/ and plugins/ to a page and heading.
• A retried S3 bucket create with an explicit BucketName no longer refuses the bucket its own first attempt made (issue #4758) -- src/provisioning/providers/s3-bucket-provider.ts. When a create made the bucket, then failed on a configuration call that cdkd retries (a permission or throttling error, say), and could not delete the bucket again, the retry met that bucket: S3 answered BucketAlreadyOwnedByYou (or, in us-east-1, the pre-flight found it), and the explicit-name refusal (issue #4684) failed a deploy the retry would have finished. The failed attempt now records the bucket's identity (name, region and the CreationDate this account's ListBuckets reports), and the retry of the same create takes the bucket as its own only while it still has that identity; any other holder of the name is refused as before. A generated name is unaffected. Tests: tests/unit/provisioning/providers/s3-bucket-retry-own-bucket-4758.test.ts.
• A deploy that stops while a create waits to retry now still records the resource that create made (issue #4757) -- src/deployment/retry.ts. When a resource's create call succeeded at AWS and a later step of the same create failed with an error cdkd retries (a permission or throttling error, say), and another resource then failed and stopped the deploy while this one was waiting to retry, the failed CREATE was recorded without the resource's id, with or without --no-rollback. The automatic rollback, cdkd rollback --revert-failed, cdkd destroy and a fix-forward deploy then had nothing to act on, and the resource stayed in AWS untracked. The stop now keeps the record of what the create made, as a give-up after the last retry already did. The same holds for cdkd rollback's own re-create of a replaced resource: stopped during its retry wait, the rollback now deletes what that re-create made (unless state holds it, or its DeletionPolicy is Retain or Snapshot) instead of leaving it untracked. Tests: tests/unit/deployment/retry-interrupt-carries-created-mark-4757.test.ts, tests/unit/deployment/deploy-engine-rollback-journal.test.ts.
• cdkd destroy and cdkd rollback now act on an orphan a fix-forward deploy kept, instead of asking for manual attention (issue #4754) -- src/deployment/rollback-executor.ts, src/deployment/rollback-executor/plan.ts, src/cli/commands/rollback.ts. When a successful deploy kept a resource an earlier failed CREATE left behind (its delete failed, or it was an S3 bucket that still held objects), a later cdkd destroy or cdkd rollback skipped that journal entry with a warning that it needed manual attention and exited 2, even after the user had emptied the bucket or deleted it by hand: only the deploy that kept it had proven it was not the resource state now tracks under the same logical id. Both commands now ask the resource's provider that question again. Proven, the resource is deleted while its creation identity still matches (an S3 bucket is still never emptied), and an entry whose resource is already gone is dropped. When the provider cannot answer (no such check, an error, or no answer within the same time limit), the entry is kept with the warning as before. The cdkd rollback plan shows the same outcome before you confirm. A deploy's own automatic rollback is unchanged. Tests: tests/unit/deployment/replay-recheck-kept-orphan-4754.test.ts, tests/unit/cli/rollback-preview-recheck-4754.test.ts; integ: s3-fix-forward-orphan.
• A deploy that changes a custom resource's ServiceToken is now refused, as CloudFormation refuses it, instead of being sent as an Update to the new handler (issue #4749) -- src/deployment/custom-resource-service-token.ts, src/deployment/deploy-engine/{deploy-flow,update}.ts, src/cli/commands/diff-recursive.ts. The old handler never received a Delete, so whatever it created was orphaned silently. Two different ARNs are refused before anything is provisioned (--dry-run too), with no request to either handler and state unchanged; cdkd diff reports it under Blocking and exits 3. A token that reads a resource the same deploy replaces or creates (a renamed backing Lambda) is refused once it resolves, before the handler is invoked, and the deploy rolls back; cdkd diff warns about it. A recorded token cdkd cannot compare (missing, ***, a {{resolve:...}} reference) is refused when the template moves it; a token fed by a NoEcho parameter, recorded as ***, is still updated as before, since cdkd keeps no value to compare. The message names the remedy: a new logical id, which creates the new resource through the new handler and deletes the old one through its old handler. A --recreate-via-cc-api target is not refused. Docs: docs/{cli-deploy,cli-diff,troubleshooting,state-management}.md. Tests: tests/unit/deployment/{custom-resource-service-token,deploy-engine-cr-service-token-4749}.test.ts, tests/unit/cli/diff-recursive.test.ts.
• An S3 bucket create no longer adopts a bucket already holding its explicit BucketName on the paths the deploy engine's name lookup does not cover (issue #4684) -- src/provisioning/providers/s3-bucket-provider.ts. Defense in depth behind the engine's lookup before a plain create (#4180) and a renamed replacement (#3937). A create the lookup does not cover (a replacement keeping its name, a rollback's re-create of a replaced bucket), or a bucket made between the lookup and CreateBucket, took BucketAlreadyOwnedByYou (or, in us-east-1, the legacy 200 that resets the bucket's ACLs) as success, configured that bucket and recorded it for a later destroy to delete. The provider now refuses an explicit name a bucket already holds, in us-east-1 before the send, asking the account's bucket list when the location lookup cannot answer. The refusal names the bucket, points at cdkd import and applies nothing. It is marked a name collision: a same-name replacement fails as CloudFormation's does (or uses --replace) without reconfiguring the old bucket first, a rollback's reverse replacement refuses a bucket a stranger took, and one whose new bucket holds the name deletes that new bucket and re-creates the old one instead of adopting it. A delete-first re-create still retries it while a deleted name is released. A generated name is still adopted (#4345). The #4639 ambiguous-create refusal now points an explicit name at cdkd import. Tests: tests/unit/provisioning/providers/s3-bucket-explicit-name-held-4684.test.ts, s3-bucket-create-retry-4639.test.ts; integ: s3-lifecycle phase 2d.
• A us-east-1 explicit-name create whose location lookup could not answer no longer claims the bucket on the account bucket list's word (#4684 follow-up) -- src/provisioning/providers/s3-bucket-provider.ts. ListBuckets can lag a concurrent same-account create, so a configuration failure now leaves that bucket with the "Not cleaning up" warning instead of deleting or journaling it.
• A fix-forward deploy now deletes the S3 bucket an earlier failed CREATE left behind (issue #4606, S3 bucket slice) -- src/provisioning/providers/s3-bucket-provider.ts. When a cdkd deploy --no-rollback made an AWS::S3::Bucket, failed configuring it and could not clean it up, and a later deploy kept the logical id under another bucket name, the successful deploy warned about the earlier bucket, left it in AWS and exited 2: it could not prove the two were different buckets, nor that the bucket under the old name was still the one the failed CREATE made. The S3 provider now answers both. Two different bucket names are two buckets (names are global and cannot be changed), once the record's bucket reads back in the stack's region. A bucket's identity is its name, region and the CreationDate this account's ListBuckets reports, recorded when the CREATE fails and compared before the delete: a bucket deleted by hand and re-created under the name reports another date and is kept, with a warning. A date S3 moved after a bucket change (a bucket policy edit) also keeps the bucket. The same identity serves cdkd rollback and cdkd destroy for such a journaled bucket. Such a bucket is never emptied on any of these paths, even with autoDeleteObjects: one that is not empty is kept with a warning. Tests: tests/unit/provisioning/providers/s3-bucket-identity-4606.test.ts; integ: s3-fix-forward-orphan.
• cdkd drift --accept and --revert write a NoEcho parameter's position as *** in every baseline they save (issue #4043, Phase C) -- src/cli/commands/drift.ts, docs/cli-drift.md. Both writers clone the record's existing baseline (observedProperties, or properties when there is none) and merge into it what was accepted or what the provider reported after a revert. A baseline that still held a NoEcho value in the clear at a position the record names in noEchoLeaves, or a provider echo of the live value a revert kept there, was written back as it came, and a value the redaction's value arm cannot match (under 4 characters, a number) stayed in the clear. Every such position is now masked in what either writer saves: by its list's identity field in an observed baseline (the whole list where none pairs it), and by index in properties. An observed baseline is also masked at every *** leaf of properties, as the deploy's capture is. Every writer that masks an observed baseline at a NoEcho position (deploy, cdkd state refresh-observed, the rollback replay, drift) now masks the WHOLE node where the readback holds a non-object (a JSON string, a list) at a key the position runs through, where it used to leave it in the clear (src/deployment/secret-redaction/noecho-leaves.ts). What --accept reports as recorded is unchanged. Tests: tests/unit/cli/drift-noecho-v11.test.ts.
• cdkd import and cdkd scrub store a NoEcho parameter's position as ***, and cdkd export exports a record masked only there (issue #4043, Phase C) -- src/cli/commands/{import,scrub,export}.ts, docs/cli-scrub.md, docs/cli-export.md. cdkd import now writes a property its template fills from a NoEcho template parameter as *** whatever the value's type or length, names it in noEchoLeaves, masks the observed baseline there, and masks and declares a same-named attribute echoing the value, as a v11 deploy does. Before, a value under 4 characters or a number stayed in the clear. cdkd scrub applies the same positional arm without a deploy. Where a record still holds a plaintext at such a position (a pre-v11 stack, or one deployed under an older Default), that value also masks its copies elsewhere in the record. A stack with no other secret is scrubbed for it, and --dry-run --fail counts it. An Export.Name the deploy refuses for holding or reading a NoEcho value no longer makes scrub keep every unnamed output key as a possible alias. cdkd export no longer blocks a resource whose only masks sit at those positions: the exported template reads the parameter, and CloudFormation receives its value. It still blocks one whose import identifier embeds the mask, or whose AWS::IAM::Policy pre-delete principals or name a NoEcho parameter fills, and refuses a nested child parameter that resolves to the mask. Scrub also masks an output a NoEcho parameter serves, with its alias and exports index entry. Tests: tests/unit/cli/import-noecho-positional-4043.test.ts, tests/unit/cli/commands/scrub-noecho-positional-4043.test.ts, tests/unit/cli/export-noecho-v11.test.ts.
• A rollback reverts a resource whose recorded properties hold a NoEcho parameter's value only as *** (issue #4043, Phase C) -- src/deployment/rollback-executor.ts, src/deployment/rollback-executor/{replay-noecho,replay-revert,replay-reverse-replacement,replay-props}.ts, src/deployment/nested-child-journal.ts, src/deployment/deploy-engine/{rollback,outputs}.ts, docs/cli-rollback.md. Since state schema v11 a property fed by a NoEcho template parameter (or a NoEcho attribute read through Fn::GetAtt) is recorded as *** at the coordinates noEchoLeaves names, and every rollback revert of such a resource, automatic or cdkd rollback (with or without --revert-failed), failed with ROLLBACK_REDACTED_BASELINE. The revert now reads the resource back from AWS, handing the provider the record masked at those coordinates, and sends the value AWS holds there, so a NoEcho value the failed deploy changed is not reverted (the next deploy restores it). The value becomes a mask-only and a log-only needle of the operation, and the restored record keeps *** by position and its noEchoLeaves, so it never reaches state, the events or the log in the clear (inside longer text, from 4 characters). A value that cannot be read back (write-only, absent, itself ***, no readback, a failed read) and the re-create of a reversed replacement refuse with a NoEcho-specific remedy. A nested stack row's masked Parameters entry no longer refuses its revert. A nested child's journal no longer snapshots a previous export alias that today's export-name verdict refuses, so a revert of the child cannot republish an alias an older cdkd wrote. Tests: tests/unit/deployment/rollback-executor-noecho-readback.test.ts, deploy-engine-noecho-v11.test.ts, nested-child-journal.test.ts; integ arm in tests/integration/noecho-parameter-masking/.

Recently Implemented (2026-10-08):

• The first deploy after upgrading to state schema v11 no longer prints a NoEcho parameter's previous value at a position the template still feeds from one (issue #4741) -- src/deployment/deploy-engine/update.ts. A record an older cdkd wrote still holds the plaintext it last sent at each NoEcho position. Where that value differs from the one this deploy binds, it is handed to the provider as the previous properties (and to a replacement's delete of the old resource), and nothing masked it: a provider that logs the previous value while reconciling (the Budgets provider's Deleted subscriber line under --verbose) printed it, as did an error quoting it. The value is now recorded for the duration of the deploy in the resource's print-only bag, the one bound around every line logged for the resource, so its log lines, errors and events print *** in its place. Nothing that is persisted or decided reads that bag. Where a whole list was compared (its length changed), only the leaves the template no longer holds are recorded. Not covered, and still printed: a previous value at a position this deploy no longer reads from a NoEcho parameter, or in a property the template removed, or in a removed list entry when the list no longer holds any NoEcho position (a pre-v11 record does not say which of its positions a NoEcho parameter fed); and a previous value of exactly true / false inside a list whose length changed, since recording it would mask every line containing that word. As with every NoEcho value, a whole printed text equal to it is masked at any length, and an occurrence inside a longer text only from 4 characters. Tests: tests/unit/deployment/deploy-engine-noecho-witness-log-4741.test.ts.

• Changing an IAM role's Path is a replacement through the engine's guards, not a deploy failing with EntityAlreadyExists (issue #4739) -- src/analyzer/replacement-rules.ts, src/provisioning/providers/iam-role-provider.ts. Path is create-only, but the replacement registry listed it as updatable, so the deploy sent a path edit on an iam.Role to the provider's in-place update, whose re-create asked for the name the live role still holds (IAM role names are unique whatever the path) and failed with EntityAlreadyExists, with no guidance. A Path change now replaces the role: the create-first attempt's name collision is refused with the replacement-collision guidance (the name's origin, and cdkd deploy --replace), and under --replace the role is deleted and re-created on the new path, and resources reading its ARN are updated to the new one. / and an absent Path are the same path and replace nothing. The provider's update() refuses a Path-only change as not updatable in place instead of attempting the colliding create. A Path taken from a secret reference the template did not change keeps the role in place (a rotated secret is not applied, with a warning, as CloudFormation keeps the live create-only value), and a Path fed by a changed NoEcho parameter is planned as a replacement (src/analyzer/diff-calculator.ts). Tests: tests/unit/deployment/deploy-engine-iam-role-path-4739.test.ts, tests/unit/analyzer/replacement-rules-iam-role-path.test.ts, tests/unit/provisioning/iam-role-provider.test.ts.

• A deploy no longer warns that a resource "is replaced" when a changed NoEcho value on a schema create-only property is updated in place (issue #4737) -- src/deployment/deploy-engine/update.ts. Where a record held a plaintext at a position a NoEcho parameter now feeds (a pre-v11 record, or a literal turned into a {Ref} to the parameter) and the value differs, the deploy printed <id>.<prop> is a create-only property, and a NoEcho parameter's value changed since the last deploy: <id> is replaced. for every property the CloudFormation schema lists as create-only. For one cdkd updates in place (an AWS::Budgets::Budget's NotificationsWithSubscribers, which its provider reconciles), the deploy sent an in-place update and printed that line anyway. The line is now printed only when the change replaces the resource. Tests: tests/unit/deployment/deploy-engine-noecho-v11.test.ts.

• cdkd diff no longer prints a rotated NoEcho parameter's previous value inside the name of a stale export alias's REMOVE row (src/analyzer/outputs-diff.ts, src/cli/commands/diff-recursive.ts, go-to-k/cdkd#4723). An older binary that published Export.Name: {Fn::Sub: 'x-${Short}-y'} while the NoEcho parameter Short held ab left the alias x-ab-y in state; after the value rotated, the diff withheld only a stored name equal to today's refused name (x-cd-y) and printed x-ab-y in the human rows and in --json. While any declared output (a condition-skipped one included) has an intrinsic Export.Name that can read a NoEcho parameter or custom-resource attribute under any Fn::If verdict (a nested child's parent rows included), the name of every stored alias today's template cannot account for is now withheld: a key the record's exportNames lists, or any such key when the record lists none. The row is still reported. The rule is stack-wide because state records no alias's owner; a stack where no declared name reads a NoEcho parameter prints its stale aliases as before. This also withholds the stored alias of a condition-false exporter, or of an Fn::If branch today's verdict drops, which printed even when it spelled today's short value. Tests: tests/unit/cli/diff-rotated-noecho-alias-4723.test.ts; integ noecho-parameter-masking (Phase 1c plants the legacy alias).

• --recreate-via-cc-api of an imported Application Auto Scaling scalable target is now refused instead of silently losing its scaling policies, and cdkd import records a resource it read through Cloud Control as provisionedBy: cc-api (src/cli/commands/import.ts, src/deployment/recreate-targets/validate.ts, src/deployment/child-of-recreated-parent.ts, go-to-k/cdkd#4706). Import recorded every resource as sdk, including a type with no SDK provider, which a deploy records as cc-api. For an AWS::ApplicationAutoScaling::ScalableTarget that let --recreate-via-cc-api past its already-on-Cloud-Control refusal: the recreate deregistered the target, which deletes its scaling policies, and re-registered it under the same ResourceId|ScalableDimension|ServiceNamespace id, so each AWS::ApplicationAutoScaling::ScalingPolicy resolved exactly as recorded, was skipped as unchanged, and state kept policies AWS no longer had under a green deploy. Import now records the layer its routing chose; the pre-flight refuses --recreate-via-cc-api of a type with no SDK provider whatever its record says, so a record an earlier import wrote is covered too; and a scaling policy whose target is re-created under the same id is re-created with it, like a Lambda permission with its function (go-to-k/cdkd#4411). Tests: tests/unit/cli/import.test.ts, tests/unit/deployment/recreate-targets.test.ts, tests/unit/deployment/child-of-recreated-parent.test.ts; integ app-autoscaling-recreate.

• One stack name deployed under two state backends no longer takes over, and then deletes, the other deployment's resources (issue #4705) -- src/deployment/{generated-name-guard,kept-in-history,retained-readoption}.ts, src/state/{stack-registry,s3-state-backend,cross-prefix-stack-scan,lock-manager,create-token-ledger}.ts, src/provisioning/{name-lookup,provider-registry}.ts, src/deployment/deployment-approval.ts, the name-adopting SDK providers, src/cli/commands/{deploy,cross-prefix-gate,destroy-runner,destroy,state,rollback,import,force-unlock,export,registry-release}.ts. A second deployment of the same stack under another --state-prefix, --state-bucket or account's bucket was handed the first one's SQS queue and log group (generated names derive from the stack name), and its rollback deleted the queue. Now a create of a type whose API hands back or overwrites an existing name (queue, topic, log group, alarm, rule, S3 bucket, ECS cluster, load balancer, target group, state machine) reads its generated name exactly first and refuses (GENERATED_NAME_HELD) unless this stack's state, journal, intent ledger, retained.json (what it kept under this prefix) or own history names the holder; about one round trip, none on a redeploy. In one bucket, a marker _cdkd-registry/<region>/<stack>.json names the stack's prefix: a first deploy claims it, and destroy, state destroy, rollback, a destructive plan and the automatic rollback's deletes refuse a stack another prefix holds. Removing a record (destroy, orphan, export, rollback, a failed first deploy) releases it. A record or stale marker from before pays one prefix listing, then claims. A 403 warns and continues. Residual: a cross-bucket pair formed before this version keeps both records. Docs: docs/state-store.md. Tests: tests/unit/**/*4705*.test.ts; integ cross-backend-same-stack, cross-backend-same-stack-migration, perf-cross-backend-check.

• cdkd rollback --remove-protection now reaches a deletion-protected resource the failed deploy created inside an existing nested stack (issue #4703) -- src/deployment/nested-child-journal.ts, src/cli/commands/rollback.ts. A nested stack's row is reverted by replaying that child's own journal, and that replay never received the flag: a protected resource whose CREATE completed in the child before a later parent resource failed (a load balancer with deletion_protection.enabled, an EC2 instance with DisableApiTermination) was deleted without it, AWS refused, and cdkd rollback --remove-protection exited non-zero until the protection was cleared by hand. The flag now travels into the child's replay, where a completed CREATE is the child's own state record, deleted as the stack's is; a foreign-holder scan scoped to the child travels with it. A deploy's automatic rollback still never turns protection off. Test: tests/unit/deployment/nested-child-remove-protection-4703.test.ts; integ remove-protection-journaled-orphan.

• A resource that holds a replaced resource through a create-only property the CloudFormation schema also lists write-only is now replaced with it, instead of updated in place (src/analyzer/diff-calculator.ts, src/deployment/recreate-target-readers.ts, go-to-k/cdkd#4701). The most common case is AWS::ApplicationAutoScaling::ScalingPolicy.ScalingTargetId: a change that replaces the scalable target (a renamed DynamoDB table, a moved ResourceId) planned each policy as an in-place update. AWS deletes a target's policies when it deregisters it, so the policy was updated after it was gone, or left pointing at the deleted target. cdkd did not replace on a write-only create-only property, a rule meant for a fresh NoEcho secret AWS never returns (go-to-k/cdkd#3803). That rule now applies only when the property is not exactly a Ref or Fn::GetAtt of the replaced resource: a plain reference resolves to the resource's new id or attribute, which cdkd compares with the state record, not with an AWS read. A Fn::GetAtt of a custom resource or nested stack, and any value built from a reference (a {{resolve:...}} dynamic reference, an Fn::If), keep the old rule. The --recreate-via-* pre-flight lists such a reader under "Replaced if the id changes". Other types this reaches include ElastiCache ReplicationGroup, VPC Lattice listeners and rules, DataSync locations and ServiceDiscovery::PrivateDnsNamespace.Vpc. Tests: tests/unit/analyzer/diff-calculator-synthetic-create-only.test.ts, tests/unit/deployment/recreate-target-readers.test.ts; integ dynamodb-autoscaling Phase 3 (a table rename replacing both scalable targets and their policies).

• A successful deploy and cdkd rollback no longer delete a journaled failed-CREATE resource that a state record holds under its identifier spelled in another case (issue #4692) -- src/deployment/replacement-name-holder/name-keys.ts, src/deployment/rollback-executor/{journaled-orphans,plan,replay-reverse-replacement}.ts. RDS, DocumentDB, Neptune and ElastiCache identifiers are case-insensitive, and a provider records the identifier as the template spells it. Every check that keeps a journaled orphan because a record holds it compared physical ids exactly, so a cdkd import adopting the cluster journaled as MyCluster under mycluster (in the same stack under another logical id, or in another stack under the same state prefix) left it unheld: the settle proved the identifier still named the journaled cluster and deleted it. Those checks (this stack's records, other stacks' records and rollback-orphan records, the supersede pass, the rollback classifier, a failed rollback re-create's cleanup, and the --remove-protection ownership proof) now compare under the type's case rule (physicalIdKey): case-folded for the types whose names already fold for replacement-name decisions, exact for every other type. Tests: tests/unit/deployment/journaled-orphans-case-fold-4692.test.ts, tests/unit/deployment/replacement-create-orphan.test.ts; integ rds-fix-forward-orphan.

• Replacing an ALB listener that has rules now replaces each AWS::ElasticLoadBalancingV2::ListenerRule onto the new listener, instead of failing the deploy with NotFound (src/analyzer/replacement-rules.ts, go-to-k/cdkd#4689). A --recreate-via-cc-api / --recreate-via-sdk-provider of the listener, or a change that replaces it (its LoadBalancerArn, or a replaced load balancer), planned each rule reading it as an in-place update: the rule's ListenerArn is create-only, but the CloudFormation schema also lists it write-only, and cdkd does not replace on a write-only create-only property it cannot read back (go-to-k/cdkd#3803). AWS deletes a listener's rules with it, so that update failed One or more rules not found after the listener had already been replaced, and the --recreate-via-* pre-flight did not list the rule. The replacement rules now name ListenerArn for this type, so the rule is re-created on the new listener, and the pre-flight lists it under "Replaced if the id changes". Tests: tests/unit/analyzer/diff-calculator-synthetic-create-only.test.ts, tests/unit/deployment/recreate-target-readers.test.ts; integ alb Phase 5 (a --recreate-via-cc-api of the listener with its rule).

• A token-less create the AWS SDK replayed inside one call after a reset connection is now checked for the duplicate its first request may have made (issue #4687) -- src/provisioning/providers/ambiguous-create.ts (replayedInSend / replayFollowedAmbiguousAttempt / replayedSendWindow / ambiguousAttemptLead), orphan-report.ts, iam-access-key-provider.ts, and the AmbiguousCreateLatch providers (kms, cognito, appsync, apigateway, apigatewayv2, emr-*, lambda-layer, lambda-eventsource, dlm-lifecycle-policy, ecs, ec2), their unit tests and docs/troubleshooting.md. Before, a socket reset or timeout after the request reached AWS was replayed by the SDK; when that replay SUCCEEDED, a create that is not name-unique had made a second resource -- for AWS::IAM::AccessKey a live credential no state records -- and nothing reported it. After a create the SDK retried inside its call, cdkd now checks right away: for CreateAccessKey, only when the retry followed a reset or timeout, the existing orphan reconcile deletes a key absent from the pre-create baseline, dated after the attempt started and not recorded by this process (never the key just returned; a failed delete warns with the aws iam delete-access-key command); for every latched create, its existing report-only lookup names candidates from the first request to the reply, never the returned resource, never adopting or deleting. A single-attempt create makes no extra call. A throttle the SDK retried also runs the report-only lookup: it finds nothing for a type with a creation date, and for an undated type it can name an unrelated resource of the same name, which the warning says may be another stack's.

• A custom resource that reads a NoEcho parameter is deleted again by cdkd destroy, with the real value in its Delete request (src/deployment/noecho-delete-reresolution.ts, src/provisioning/providers/custom-resource-provider.ts, src/cli/commands/destroy.ts, src/cli/commands/destroy-runner.ts, src/provisioning/providers/nested-stack-provider.ts, src/deployment/deploy-engine/{update-replace,update-in-place,replacement}.ts, go-to-k/cdkd#4682). Since schema v11 the record holds *** there, so the delete was skipped (record kept, exit 2). cdkd destroy with the app now re-resolves each such position from today's template and parameters (a nested child's from its parent's row) and sends that value; the record keeps ***, and the warnings, errors and handler log lines cdkd prints are masked as on a create. The delete stays skipped for cdkd state destroy, a deploy that removed the resource, a rollback, a position an attribute declared NoEcho fills, and a template that no longer reads a NoEcho parameter there, changed that property's text or resolved inputs, changed the type, carries a Transform or was synthesized for another region. Behavior change: a custom resource whose recorded properties hold *** at a position the record's noEchoLeaves does not name (one embedded through Fn::Join, a record an earlier cdkd wrote, one cdkd import / cdkd scrub wrote) used to receive *** in its Delete; that delete is now skipped too, keeping the record (for an import / scrub record, a cdkd deploy first records the positions). Tests: tests/unit/deployment/noecho-delete-reresolution.test.ts, tests/unit/cli/destroy-runner-noecho-reresolve-4682.test.ts; integ schema-v10-to-v11-migration.

• An ALB listener recorded provisionedBy: 'cc-api' now returns to the SDK provider on its next deploy that changes it, so a ListenerAttributes key removed from the template is reset instead of keeping its old value (src/provisioning/provider-registry.ts, go-to-k/cdkd#4679). A listener first deployed while tagged, before go-to-k/cdkd#4673 declared its Tags handled, was created through Cloud Control, and the sticky routing rule kept that record there. Cloud Control's update sends no ModifyListenerAttributes for a removed key, so for example routing.http.response.server.enabled stayed false after it was dropped. AWS::ElasticLoadBalancingV2::Listener is now an sdk-coverage sticky exemption: the record moves to the SDK provider in place, with its listener ARN unchanged, and that deploy resets the removed key. cdkd diff marks the listener [returning to SDK provider], and --pin-cc-api <LogicalId> declines the move for one deploy. A key already removed under Cloud Control by an earlier cdkd is not in the record any more, so nothing resets it: set it to its default value in the template and deploy. Tests: tests/unit/provisioning/elbv2-listener-sticky-cc-4679.test.ts; integ alb Phase 2.5 (a listener record seeded to cc-api as for go-to-k/cdkd#4117, Cloud Control identifier parity, in-place return and attribute reset).

• cdkd rollback --remove-protection now also deletes a deletion-protected resource whose CREATE the failed deploy completed (issue #4678) -- src/deployment/rollback-executor/replay-orphan-delete.ts, src/cli/commands/rollback.ts. The flag reached only a failed CREATE's resource; a protected resource the deploy had created before a later resource failed (an EC2 instance with DisableApiTermination, a load balancer with deletion_protection.enabled) was deleted without it, AWS refused, and every cdkd rollback exited non-zero until the protection was cleared by hand. The rollback's delete of a completed CREATE now carries the flag, as one final attempt so a failed delete puts the protection back. The resource is this stack's own state record, matched to the id the journal recorded, the same trust cdkd destroy --remove-protection gives it. A resource reverted inside an existing nested stack, through that child's own journal, still keeps its protection, and a deploy's automatic rollback still never turns protection off. Test: tests/unit/deployment/completed-create-remove-protection-4678.test.ts; integ remove-protection-journaled-orphan.

• --remove-protection now clears a deletion-protected resource that only the rollback journal records, on cdkd destroy / cdkd state destroy and, new, on cdkd rollback (issue #4678) -- src/cli/commands/{destroy-runner,rollback}.ts, src/deployment/rollback-executor.ts, src/deployment/rollback-executor/types.ts. A failed CREATE whose resource carried deletion or termination protection (an EC2 instance with DisableApiTermination, a load balancer with deletion_protection.enabled) left it journaled; destroy dropped the flag on the way to the journal's delete and cdkd rollback had none, so AWS refused the delete and every run exited non-zero until the user cleared the protection by hand. The flag now reaches that delete (RollbackExecutorContext.removeProtection, plus --revert-failed's delete of a state-recorded failed CREATE), as one final attempt so a failed delete puts the protection back. A journaled orphan gets it only when proven to be the resource its CREATE made (a type whose id AWS never reuses, or a live identity equal to the journaled one) and no other stack's state record holds it now; otherwise the protection stays, with a warning when the attempt had turned it on. The destroy prompt counts such a resource. A deploy's automatic rollback and a successful deploy's settle still never turn protection off. Tests: tests/unit/deployment/journaled-orphan-remove-protection-4678.test.ts, tests/unit/cli/{destroy-runner-journaled-orphan,rollback}-remove-protection-4678.test.ts; integ remove-protection-journaled-orphan.

• cdkd rollback and cdkd destroy no longer delete a journaled failed-CREATE orphan unless it is proven to be the resource the failed deploy made and no other stack's state record holds it (src/deployment/rollback-executor.ts, src/deployment/rollback-executor/{orphan-identity,journaled-orphans}.ts, src/cli/commands/{rollback,destroy-runner}.ts, go-to-k/cdkd#4658, go-to-k/cdkd#4696). The replay deleted such an orphan by physical id alone, so it deleted a resource that a later cdkd import had adopted into another stack, and a resource that reused the name of an orphan deleted by hand. It now runs the success settle's checks, in its order and through its helpers (askForeignHolder, createdResourceStillThere).

  • Name-keyed types: a name-keyed type's live resourceIdentity must equal the one the CREATE journaled. Only a Kinesis stream and an RDS, DocumentDB or Neptune cluster or instance journal one today. Every other name-keyed type (an S3 bucket, a Lambda function, an IAM role, a DynamoDB table, an SQS queue, ...) has none, so its journaled orphan is now kept instead of deleted. Types whose id AWS generates and never reuses are unaffected.
  • Held, disproven, or no identity: the orphan is a warned skip that names its physical id and says to delete it by hand if unused. cdkd rollback and cdkd destroy both exit 2.
  • Unreadable: if a record or the live identity cannot be read, the entry stays in the journal as a failed operation for a re-run. --drop-failed removes only the record.
  • Gone: an orphan AWS reports gone is settled with no delete.
  • Automatic rollback: it runs neither check. It acts inside the failed deploy, over that attempt's own operations.
  • --remove-protection: strips protection only from an orphan these checks cleared.
  • Tests: tests/unit/deployment/journaled-orphan-replay-guards-4658-4696.test.ts and the rollback and destroy suites; integ rollback-command steps O10 and O11.

• An Export.Name that reads a NoEcho: true parameter is now refused whatever the value's length, and a no-change deploy re-checks an export alias it carries forward (src/deployment/deploy-engine/outputs.ts, src/analyzer/outputs-diff.ts, src/deployment/no-change-outputs-merge.ts, src/deployment/outputs-export-alias/secret-scan.ts, go-to-k/cdkd#4657). An Export.Name intrinsic that reads a NoEcho parameter through Ref, an Fn::Sub variable, or an Fn::Join / Fn::Select / other intrinsic over one is refused from the template. Before, such a name was refused only when the value was 4 or more characters long, so a name embedding a 1-3 character value was published to state.json, exportNames and the exports index. An Fn::If reads only the branch its condition selects. The warning names the output and the parameter, never the name. A nested child also refuses a name reading a parameter its parent fills from a NoEcho source. When a no-change deploy carries a failed output's literal export alias forward from the previous record, it now runs the export-name check on that alias again. It drops an alias the check refuses, with the same warning, so a consumer's Fn::ImportValue of it stops resolving. cdkd diff previews both, and shows an earlier alias under a now-refused name as a removal with its name withheld. Tests: tests/unit/deployment/export-name-noecho-refusal-4043.test.ts, tests/unit/deployment/no-change-carried-alias-noecho-4657.test.ts, tests/unit/deployment/no-change-outputs-merge.test.ts, tests/unit/cli/diff-export-name-noecho-positional-4657.test.ts.

• A rotated NoEcho parameter value feeding a create-only property replaces the resource again, where AWS is proven to report that property exactly (issue #4656) -- src/deployment/deploy-engine/{noecho,update,create,update-replace,update-in-place}.ts, src/types/state.ts, docs/state-management.md. Since schema v11 (#4043) such a property was never replaced on a readback that differed: it warned on every deploy and named --recreate-via-*, because a provider that normalizes what it reports would read differs on an unchanged value. A record now carries noEchoExactEchoLeaves (optional, no schema bump): the coordinates at which a readback, handed the record with *** there, reported exactly the string cdkd sent. It is set at the deploy that creates or replaces the resource, at the migration deploy of a pre-v11 record (against a copy with the stored plaintext pre-masked), and by any later readback that holds the value; a differing readback never changes it, and a failed or unreadable one leaves it absent. Only a whole string leaf under a create-only property, reached by object keys, is eligible. Where the flag is set and the readback reports a different string, the deploy replaces the resource through the existing create-first path and its stateful and named-collision guards; without the flag the warning now says the provider is not known to report the property exactly. Under --require-approval=destructive / any-change, whose up-front prompt saw no replacement, the deploy asks again before it (--yes approves); a "no" keeps the resource and warns. Tests: tests/unit/deployment/deploy-engine-noecho-v11.test.ts, noecho-v11-nested-child.test.ts, tests/unit/cli/import-noecho-v11-field-carry.test.ts; integ schema-v10-to-v11-migration.

• cdkd export's and cdkd drift's pasteable cdkd state commands now carry the run's --profile, resolved --state-bucket and non-default --state-prefix (issue #4648). Changed files: src/cli/commands/export.ts, src/cli/commands/drift.ts and src/cli/commands/state.ts. Before this change these commands were printed without the flags, so on a non-default bucket or profile a pasted one acted on the default profile's bucket:

  • cdkd export's cdkd state refresh-observed remedy, which WRITES the record, and its cdkd state show inspect line;
  • cdkd export's cdkd state orphan drops: the failed pre-delete / phase 2, the per-stack recovery list, the tree's Recover with: template, and a missing or out-of-sync nested child (also reached by cdkd state show --show-nested);
  • cdkd drift --revert's Populate with: cdkd state refresh-observed line.

  The identity check that decides whether a command is offered is unchanged. Each account value goes through the same gate as #3909's: a refused one prints as a quoted hole such as '<profile>', with a sentence naming the flag and the reason, and the value is never repeated. When a drop names no record, its cdkd state list --json pointer says to run it with the same flags. This completes #4648.

• cdkd diff --recursive --fail no longer reports a change on an unchanged nested stack whose parent passes a parameter embedding {{resolve:...}} tokens (e.g. postgres://{{resolve:...user}}:{{resolve:...password}}@host) beside a sibling parameter that spells the same secret differently and resolves later (issue #4644). After upgrading, the first deploy of such a stack shows a change on the nested-stack row's Parameters.<Name> and on the child resources reading it, because their state now records the parameter's own {{resolve:...}} spelling instead of the sibling's; the deployed VALUE is unchanged, and a create-only property (e.g. an ECS TaskDefinition environment variable) is replaced once with an identical value. For a one-token literal only those child resources change (its row already kept its own spelling), and only where such a sibling exists. Before, state held the map's survivor per plaintext while cdkd diff --recursive rendered the parameter's literal. A literal now persists its own spelling when rendering it with the plaintexts this pass resolved each token to reproduces the resolved value exactly and its literal text holds no secret; the child's diff side, its {Ref} leaves, its Fn::Join / Fn::Sub leaves and the inherited-secret carry (so Fn::Select, Fn::Split, arrays and Fn::If too) read it. An Fn::Join / Fn::Sub parent source, a literal holding a public ssm token, and a parameter that one child resource reads beside such a sibling, either of the two through an intrinsic other than Fn::Join / Fn::Sub (Fn::Select, ...), or that the child's Outputs read beside it, keep the old behaviour (#4731). Source: src/deployment/secret-redaction/{positions,nested-stack,placeholder-positions}.ts, src/deployment/intrinsic-resolver/parameter-secrets.ts, src/deployment/deploy-engine/deploy-flow.ts, src/cli/commands/scrub.ts.

• An "already exists" that the AWS SDK's own retry hits after a dropped connection is no longer credited to another holder (issue #4639, socket-reset residual) -- src/provisioning/providers/ambiguous-create.ts, docs/troubleshooting.md. Every token-less create sent through a withoutServerErrorRetries client (the IAM, Lambda, EventBridge bus, ECR, data / streaming, Kinesis stream, CodeCommit, KMS, Cognito, AppSync and other sites) already refused the SDK's in-call replay of a 5xx. A socket reset, broken pipe or timeout after the request was sent was still replayed inside the same call, so when AWS had completed the first request, the replay's "already exists" reached the deploy engine as an ordinary name collision with someone else's resource. Every attempt that follows such an ambiguous one in the same call is now marked as a possible replay -- the same mark the engine sets after an ambiguous attempt of its own -- so the collision is reported as possibly this create's own, and a create that looks for an orphan after an ambiguous attempt (KMS, Cognito, AppSync, API Gateway, EMR, EC2, ECS, DLM, Lambda layers and event source mappings) now looks after such a call too. The SDK still retries the reset itself, so a flaky network does not fail the deploy; a refused connection, an unresolved host and a throttle are not marked, since the request never reached the service or the service declared it did nothing. Residual: a replay that SUCCEEDS after a reset is still a second, unreported resource for a create that is not name-unique (KMS key, Cognito user pool, AppSync API, IAM access key; #4687). The replayed-collision advice now names a dropped connection as a cause and says to confirm the holder is yours first, since a reset can precede the request. Tests: tests/unit/provisioning/ambiguous-create.test.ts, deploy-engine-orphaned-name-collision.test.ts.

• An S3 bucket that exists after a server error on its own CreateBucket is refused, not adopted (issue #4639, S3 bucket residual) -- src/provisioning/providers/s3-bucket-provider.ts. CreateBucket carries no idempotency token. When a 5xx hid a create S3 had completed, the replay answered BucketAlreadyOwnedByYou (or 200 in us-east-1) and the provider adopted the bucket as one that was already there: no created-before-failure mark, so a later configuration failure in the same create left a bucket this run made in no state record and out of cdkd rollback --revert-failed's reach. CreateBucket now goes through a dedicated client that refuses the SDK's 5xx retry (same region and identity as the provider's other calls), and when an earlier attempt of the SAME create ended ambiguous and the bucket now exists in this region, the create fails with a non-retryable refusal naming the bucket. It leads with aws s3api list-buckets --prefix (only this account's buckets; CreationDate is a hint) and list-object-versions, then a delete-bucket command only for an empty bucket of this account that nobody else uses, or a re-run to adopt a bucket you mean the stack to own. In us-east-1 the refusal comes from the pre-flight, before any re-create (also when the pre-flight could not read the bucket, where a re-create could make an unattributed bucket). An attempt interrupted by a non-ambiguous retryable failure (an OperationAborted, a SlowDown, a throttled location read) keeps the earlier attempt's window for the next one. Nothing is configured or deleted. A bucket that existed before any ambiguous attempt is still adopted as before (tracked in #4684). Tests: tests/unit/provisioning/s3-bucket-create-retry-4639.test.ts.

• A successful fix-forward deploy now deletes the DocumentDB DB cluster or DB instance an earlier failed CREATE left under the same logical id, once live reads prove it is not the new one and is still the one that failed CREATE made (issue #4606) -- src/provisioning/providers/docdb-provider.ts. After cdkd deploy --no-rollback failed with an AWS::DocDB::DBCluster or AWS::DocDB::DBInstance already created, and the fixed template created a new one under the same logical id with another identifier, the successful deploy warned, named the earlier resource, exited 2 and left it in AWS. DocDBProvider now implements isSameResource and resourceIdentity, both resting on the immutable DbClusterResourceId / DbiResourceId; identifiers equal apart from case are the same resource. The failed CREATE journals the resource id its create call returned, carried on the failure itself. A resource someone re-created under the identifier, in any case spelling, reads back under another resource id and is kept with a warning, and one of another engine (DocumentDB shares the identifier namespace and the describe calls with RDS and Neptune) is never read as a DocumentDB resource: it too is kept with a warning. Only the not-found fault name (or an empty describe list) counts as gone. Deleting an earlier resource that is already gone prints one info line. Tests: tests/unit/provisioning/docdb-provider-same-resource-4606.test.ts; new integ docdb-fix-forward-orphan.

• A successful fix-forward deploy now deletes the VPC, subnet or security group an earlier failed CREATE left under the same logical id (issue #4606) -- src/provisioning/providers/ec2-provider.ts. When an AWS::EC2::VPC, AWS::EC2::Subnet or AWS::EC2::SecurityGroup CREATE failed after AWS made the resource and its cleanup delete failed too, the resource was journaled as a proven orphan. If a later deploy created a new one under the same logical id, that successful deploy warned, named the earlier one, exited 2 and left it in place. EC2Provider now answers isSameResource for these types, using the AWS-generated vpc-, subnet- or sg- id. The client must be in the stack's region, and the record's resource must read back live (a VPC or subnet pending or available; a security group whenever EC2 lists it). The earlier resource is then different, whether it still exists or is not found, so the settle deletes it. Equal ids are same. Any other id form and a failed read stay unknown, which keeps the previous warning and exit 2. An earlier resource EC2 no longer lists (its own InvalidVpcID.NotFound, InvalidSubnetID.NotFound or InvalidGroup.NotFound, never a message that merely reads like one) is named in one info line; any other delete failure keeps the journal entry for the next deploy. Tests: tests/unit/provisioning/ec2-network-same-resource-4606.test.ts. Integ ec2-instance Phase 1c runs the read and the settle's delete against live resources, a throwaway VPC / subnet / security group and ids that never existed.

• A successful fix-forward deploy now deletes the Neptune DB cluster or DB instance an earlier failed CREATE left under the same logical id, once live reads prove it is not the new one and is still the one that failed CREATE made (issue #4606) -- src/provisioning/providers/neptune-provider.ts. After cdkd deploy --no-rollback failed with an AWS::Neptune::DBCluster or AWS::Neptune::DBInstance already created, and the fixed template created a new one under the same logical id with another identifier, the successful deploy warned, named the earlier resource, exited 2 and left it in AWS. NeptuneProvider now implements isSameResource and resourceIdentity, as RDSProvider does: both rest on the immutable DbClusterResourceId / DbiResourceId, identifiers equal apart from case are the same resource, and the failed CREATE journals the resource id its create call returned. Neptune shares its identifier namespace with RDS and DocumentDB, and its describe also answers for their resources: a resource of another engine under the identifier is never compared, so it is kept with a warning. Only the not-found fault name counts as gone. Deleting an earlier resource that is already gone prints one info line. Tests: tests/unit/provisioning/neptune-provider-same-resource-4606.test.ts; new integ neptune-fix-forward-orphan.

• cdkd deploy masks a secret-derived name a parent passes to a nested stack (issue #3869) -- src/deployment/deploy-engine/resolver-context.ts, src/deployment/deploy-engine/create.ts, src/deployment/deploy-engine/update.ts. Consider a nested stack whose parameter reads a resource named from a secret, such as Parameters: { QueueArn: GetAtt SecretQueue.Arn } where the queue's name comes from Secrets Manager. That read's needles went into a print-only bag that nothing used after the row's own resolver line. The child stack inherits only the row's own secrets, which deliberately hold no read needles, since they would seed the child's export-name verdict. So the child's Resolved Ref to parameter: QueueArn and Parameter QueueArn: using user-provided value lines, its provider lines and the row's own provider lines printed the name. The row's print-only bag is now its derived-name registry, which is bound as a printing bag around the row's whole body and therefore around the child's deploy. The child's inherited secrets are unchanged. The cdkd diff walk into a child is not covered yet. Tests: tests/unit/deployment/deploy-engine-derived-name-needle-3869.test.ts. Integ secret-derived-immutable-names gains the nested stack QueueReaderChild, fed SecretQueue's ARN; the deploy and update logs must not name the queue.

• A call rejecting with a value that cannot be converted to text no longer turns a best-effort step of cdkd import, cdkd state, cdkd orphan, cdkd gc or cdkd force-unlock into a hard failure (src/cli/commands/{import,state,retire-cfn-stack,orphan,gc,force-unlock}.ts, go-to-k/cdkd#3361). Handlers that log a failure and carry on built their message with x instanceof Error ? x.message : String(x), and String() throws for a null-prototype object, so the handler itself threw: a failed lock release after a successful import, state orphan, refresh or cdkd orphan failed the command; one resource whose import or readCurrentState failed aborted every other resource; a failed template-parameter, condition or intrinsic resolution aborted the import it was degrading; a failed transient-template delete failed a --migrate-from-cloudformation retire after CloudFormation had succeeded, and a mid-walk nested-template failure lost the uploads it should have carried out for deletion; a failed DescribeStackResources lookup aborted the import instead of falling back to per-resource lookups; cdkd gc's purge warning replaced its GC_DELETE_FAILED error, and its delete failure lost that code; and cdkd force-unlock stopped at the first such failure instead of attempting every remaining stack. Two throwing sites lost what they throw: the import's rollback-journal refusal and a retire's failed UpdateStack surfaced as the converter's TypeError. Each now goes through describeAwsFailure(x).detail, byte-identical whenever the value converts and a placeholder only when it cannot. Tests: tests/unit/cli/*-string-outthrow-3361.test.ts.

• A failure that cannot be converted to text no longer turns a best-effort deploy step into a hard failure (src/deployment/orphan-adoption.ts, src/deployment/nested-child-journal.ts, src/deployment/work-graph.ts, src/deployment/recreate-targets/probe.ts, go-to-k/cdkd#3361). Handlers that report a failure and carry on built their message with x instanceof Error ? x.message : String(x), and String() throws for a null-prototype object. The handler itself then threw: the orphan-adoption pre-pass rejected, and the deploy with it, instead of keeping a record it could not route or verify; the sibling-claim scan rejected instead of skipping an unreadable sibling or answering an empty set; the nested-journal sweep after a successful deploy, documented as never throwing, rejected and skipped the child's own journal delete; a failed state save after a nested child's revert, documented as a warning, failed the revert; a stack or asset node failing that way became an unhandled rejection in WorkGraph.execute that exited cdkd deploy / cdkd publish-assets with the converter's TypeError instead of the failure summary; and the --recreate-via-* stateful probe rejected instead of answering fail-open for a bucket or fail-closed for a log group. Each now goes through describeAwsFailure(x).detail, byte-identical for an Error and a placeholder otherwise. Tests: tests/unit/deployment/deployment-string-outthrow-3361.test.ts.

• A failure that cannot be converted to text no longer turns a degradation in cdkd drift into a failure of the command or of a revert that already landed (src/cli/commands/drift.ts, go-to-k/cdkd#3361). Thirteen handlers that log a failure and carry on built their message with x instanceof Error ? x.message : String(x), and String() throws for a null-prototype object. The handler itself then threw. In detection, a resource whose read failed or whose type has no READ handler aborted the command instead of being reported and skipped; a resource whose dynamic reference could not be resolved, or whose IAM principal lookup failed, was reported as not compared at all instead of comparing what it could; and an unreadable nested-stack ancestor rejected instead of making the producer-region evidence incomplete. --accept and --revert rejected after their work on a failed lock release. In --revert, a failed update, re-resolution or payload build abandoned the rest of the stack and its state write; a revert that LANDED was re-reported as AWS update failed when the provider's effective properties or returned attributes could not be read; and a failed best-effort state write after a landed revert rejected instead of warning. Each now goes through describeAwsFailure(x).detail, byte-identical for an Error and a placeholder otherwise. Tests: tests/unit/cli/drift-string-outthrow-3361.test.ts.

• A failure value that cannot be converted to text no longer turns a best-effort fallback in the analyzer, synthesis, assets or utils layers into a hard failure (src/analyzer/orphan-rewriter.ts, src/synthesis/macro-expander.ts, src/synthesis/context-providers/index.ts, src/assets/asset-storage.ts, src/utils/expected-bucket-owner.ts, src/utils/error-handler.ts, go-to-k/cdkd#3361). String() throws for a null-prototype object, and these handlers built their message with it. The handler itself then threw: a failed live Fn::GetAtt read in cdkd orphan rejected the rewrite instead of being reported as unresolvable (or, under --force, falling back to the recorded attribute); a failed DeleteStack of the macro-expansion transient stack failed the deploy from its cleanup; one failed context lookup lost every other value of that synth round; a failed asset-storage auto-create failed the deploy instead of falling back to the CDK bootstrap destinations; a failed ExpectedBucketOwner resolution rejected the state-bucket call instead of omitting the header; and formatError / normalizeAwsError, whose last arm exists for a non-Error value, threw on it. Each now goes through describeAwsFailure(x).detail or safeStringify(x), byte-identical for every value String() converts and a placeholder otherwise. Tests: tests/unit/{analyzer/orphan-rewriter,assets/asset-storage}-string-outthrow-3361.test.ts, tests/unit/{synthesis,utils}/string-outthrow-3361.test.ts.

• cdkd scrub no longer turns a failure it is built to report into a different, harder one when the failing call rejects with a value that cannot be converted to text (src/cli/commands/scrub.ts, go-to-k/cdkd#3361). Its handlers built their message with x instanceof Error ? x.message : String(x) (or a bare String(x)), and String() throws for a null-prototype object, so the handler itself threw. In --all, the per-stack failure boundary threw while reporting one stack and ended the run there, leaving every later stack unexamined; a nested-record listing failure or an unreadable exports index did the same instead of being recorded and reported after the summary. Inside one stack, a lock release failure after a successful rewrite reported the stack as failed, and a resource property, orphan record, output value, Export.Name, parameter, condition, cross-stack read on a suppressed output, producer re-read or consumer-records read that failed aborted the whole stack instead of being logged and skipped. Four refusals (SCRUB_CROSS_STACK_READ_UNRESOLVED, SCRUB_CROSS_REGION_SECRET_UNRESOLVED, SCRUB_NESTED_CHILD_UNRESOLVABLE, SCRUB_LEGACY_STATE_KEY_UNVERIFIED) were replaced by the converter's TypeError, losing their code and remedy. Each now goes through describeAwsFailure(x).detail (or safeStringify(x) for the bare form), byte-identical for every value the old expression could render and a placeholder where it threw. Tests: tests/unit/cli/commands/scrub-string-outthrow-3361.test.ts, tests/unit/cli/commands/scrub-nested-string-outthrow-3361.test.ts.

• A state-bucket call rejecting with a value that cannot be converted to text no longer turns a best-effort state-layer step into a hard failure (src/state/deployment-events-store.ts, src/state/export-index-store.ts, src/state/s3-noncurrent-version-purge.ts, go-to-k/cdkd#3361). Five handlers that log a failure and carry on, plus the noncurrent-version purge's failure recorder, built their message with x instanceof Error ? x.message : String(x), and String() throws for a null-prototype object. The handler itself then threw: DeploymentEventsStore.finalize, documented as never throwing, rejected out of the deploy and destroy runners' finally; an unreadable deployment-events index skipped the index write; one unreadable state record during an exports-index rebuild failed every lookup instead of skipping that stack; a failed or retry-exhausted exports-index write rejected instead of continuing on state.json; a purge rejected at the first failed listing; and a failed batch delete abandoned the rest of its prefix and was reported against the prefix, with the converter's TypeError in place of its own keys and reason. Each now goes through describeAwsFailure(x).detail, byte-identical for an Error and a placeholder otherwise. Tests: tests/unit/state/state-string-outthrow-3361.test.ts.

• A mis-cased deploy region no longer records one cross-stack producer twice, and the CloudFormation fallback client takes the canonical region (issue #2209) -- src/utils/aws-partition.ts (new sameRegion), src/deployment/intrinsic-resolver/{cross-stack,stack-output,cfn-fallback,clients}.ts, src/deployment/intrinsic-function-resolver.ts, and a new fence tests/unit/deployment/resolver-region-compare-fence.test.ts. IntrinsicFunctionResolver.resolverRegion stays RAW (it keys the stack's own state), while values derived from it are folded, so a bare === between two region values disagreed whenever the operands arrived by different paths. Under --region US-EAST-1, a producer read once without a Region and once with Region: us-east-1 was written twice into state.outputReads, and likewise into state.imports across the exports-index and state-scan arms. The CloudFormation fallback built ListExports with the raw region and DescribeStacks with the folded one, so one region held two cached clients and a mis-cased spelling reached the SDK's case-sensitive endpoint resolution. Every region equality in the resolver family now goes through sameRegion, which folds both operands at the comparison and moves no state key. The CFn client memo and the DescribeStacks cache fold their region key. The fence refuses a bare region comparison in the resolver family, !== and either operand order included. A comparison that genuinely means "this exact string" carries // allow-raw-region-compare: <reason>.

Recently Implemented (2026-10-07):

• cdkd drift reports an AWS::CloudWatch::AnomalyDetector as drift unknown again instead of exiting 2 (issue #4668) -- src/analyzer/drift-cc-api-deny-list.ts. AWS gave the type Cloud Control handlers. The SDK provider has no readCurrentState, so drift fell back to Cloud Control GetResource with cdkd's descriptor-derived physicalId, which Cloud Control refuses with a ValidationException on every run. That was reported as a read failure (NOT fully compared, exit 2) on every drift run of any stack holding a detector. The type is now on the Cloud Control fallback deny-list, so the row reports drift unknown and the run exits 0 as it did before. Tests: tests/unit/cli/drift-per-resource-failure.test.ts; integ cloudwatch-anomaly-detector.
• cdkd export refuses an AWS::CloudWatch::AnomalyDetector before locking the stack (issue #4668) -- src/cli/commands/export.ts. AWS gave the type Cloud Control handlers and the registry identifier AnomalyDetectorId, so the import-support pre-flight no longer blocked it. The single-key path would then have sent cdkd's descriptor-derived physicalId as AnomalyDetectorId, an opaque identifier the CloudWatch API never returns, and the IMPORT changeset would have failed after the stack was locked. The type is now blocked up front with the other export refusals, including under --skip-import-support-preflight. Tests: tests/unit/cli/export-composite-identifier.test.ts.
• Fn::GetAtt [<detector>, AnomalyDetectorId] on AWS::CloudWatch::AnomalyDetector now resolves (issue #4668) -- src/provisioning/providers/cloudwatch-anomaly-detector-provider.ts. The registry schema renamed the type's read-only primary identifier from Id to AnomalyDetectorId. The SDK provider recorded and resolved only Id, so AnomalyDetectorId fell through to the resolver's unknown-attribute physical-id fallback with a warning, and failed under --strict-getatt. Both names are now recorded on create, update and import and accepted by getAttribute, with the same value (cdkd's physical id); Id stays for aws-cdk-lib releases whose attrId still emits it. Tests: tests/unit/provisioning/providers/cloudwatch-anomaly-detector-provider.test.ts.
• A successful deploy no longer deletes a resource that reused the name of a journaled orphan the user deleted by hand (issue #4655) -- src/deployment/deploy-engine/execute.ts, src/deployment/rollback-executor/{journaled-orphans,orphan-identity,types}.ts, src/types/{resource,rollback-journal}.ts, src/provisioning/providers/kinesis-provider.ts. After cdkd deploy --no-rollback failed with a resource already created, the journal recorded it by physical id alone. If the user deleted it and something else created a resource under the same name, the next successful deploy deleted that unrelated resource. Providers gain an optional resourceIdentity; the failed CREATE journals its token as createdResourceIdentity (additive, no journalVersion bump), and the success-path settle deletes a name-keyed orphan only when a live read returns the same token, and drops one reported gone without a delete. Otherwise it warns, names the resource, clears the entry and exits 2. A journal an older cdkd wrote, and a name-keyed type without resourceIdentity, now lands there too instead of being deleted. AWS::Kinesis::Stream implements it (ARN plus creation time). Types whose physical id AWS generates and never reuses, AWS::SQS::QueuePolicy / AWS::SNS::TopicPolicy (whose delete compares content) and nested stacks (a cdkd-minted id) are unchanged. cdkd rollback and cdkd destroy are not covered yet (#4658). Tests: tests/unit/deployment/journaled-orphan-identity-4655.test.ts, tests/unit/provisioning/providers/kinesis-resource-identity-4655.test.ts; integ rollback-command step O9.
• More pasteable cdkd state commands now carry the run's --profile, resolved --state-bucket and non-default --state-prefix (issues #4648, #4159). Changed files: src/state/malformed-resources-bag.ts (exports accountArgs / withheldAccountClause), src/deployment/deploy-engine/delete.ts, src/cli/commands/{destroy,destroy-runner,state,gc}.ts, src/utils/error-handler.ts and src/provisioning/providers/nested-stack-provider.ts. Before this change these messages printed their commands without the flags, so on a non-default bucket or profile a pasted command acted on the default profile's bucket. Some of those commands drop records or delete resources. The messages are: a deploy's delete-skip warnings (Inspect it with: / Drop the record with:), cdkd destroy's multi-region cdkd state orphan, its nested-child refusal (cdkd destroy <parent> / cdkd state destroy <child>) and its termination-protection Retry with: line, cdkd state orphan's Destroy with: line, the partial-destroy hints, cdkd state orphan --resource's child drop, a nested child's destroy failure, the deploy-path refusal of a nested child's unreadable outputs (the last #4159 site), and cdkd gc's unreadable-state-file cdkd state show line, which names the prefix of the key the file was found under. Each value goes through the same gate as #3909's: a refused one prints as a quoted hole with its reason. Still without the flags: the cdkd export and cdkd drift commands, including cdkd state refresh-observed, which #4648 tracks.
• Data and streaming creates no longer let the AWS SDK replay a 5xx inside one call (issue #4639, data / streaming slice) -- the glue, firehose, kinesis-streamconsumer, pipes, cloudtrail, s3-vectors, s3-tables and s3-directory-bucket providers. Glue CreateDatabase / CreateTable / CreateWorkflow / CreateSecurityConfiguration / CreateJob / CreateCrawler / CreateConnection / CreateTrigger, Firehose CreateDeliveryStream, Kinesis RegisterStreamConsumer, Pipes CreatePipe, CloudTrail CreateTrail, S3 Vectors CreateVectorBucket, S3 Tables CreateTableBucket / CreateNamespace / CreateTable and S3 Express CreateBucket carry no idempotency token and were sent through a client whose SDK retry replays a 5xx even when AWS completed the request. The replay collided with the resource the first request made, the collision was credited to another holder, and the resource was left in no state record for every re-run to collide with. They now go through a dedicated client that refuses the SDK's 5xx retry, built with the same region and identity as the provider's other calls, so the 5xx reaches the deploy engine, which marks a later collision as possibly this create's own. Nothing is adopted. Scheduler CreateSchedule (its SDK-filled ClientToken is serialized once and reused by the SDK's retries) and S3 CreateBucket (a replay answers BucketAlreadyOwnedByYou, or 200 in us-east-1, and both paths already record the bucket) are unchanged. A failed Pipes create or update now passes AWS's error text through the secret masker before it reaches the error message. Tests: tests/unit/provisioning/*-create-retry-4639.test.ts, scheduler-create-token-4639.test.ts.
• An RDS, DocumentDB, Neptune, ElastiCache or DynamoDB create whose 5xx hid a server-side success is no longer replayed inside the AWS SDK and credited as somebody else's resource (issue #4639) -- src/provisioning/providers/{rds,rds-dbproxy,rds-dbproxy-endpoint,docdb,docdb-subnet-group,neptune,elasticache,dynamodb-table,dynamodb-globaltable}-provider.ts (getCreateClient) and new *-create-retry-4639 unit files. CreateDBSubnetGroup / CreateDBCluster / CreateDBInstance (RDS, DocumentDB, Neptune), CreateDBProxy, CreateDBProxyEndpoint, CreateCacheSubnetGroup / CreateCacheCluster and CreateTable (table and global table) carry no idempotency token and were sent through a client with the SDK's default retry, so a 5xx whose request had succeeded was replayed inside one send, and the replay's "already exists" surfaced from the deploy engine's FIRST attempt, read as a name another holder owns. Each now goes through a dedicated client wrapped by withoutServerErrorRetries: the 5xx reaches the engine's retry, whose ambiguous-outcome latch (#3983) marks the replay's collision as possibly this create's own. Such a 5xx is now retried on the engine's logged schedule rather than the SDK's quick in-send retries. Every other call keeps the full SDK retry, a name that existed before any ambiguous attempt is still a name collision, and nothing is adopted on that collision -- a name is not attribution. Residual: the other #4639 sites and the socket reset or timeout the SDK still replays.
• IAM creates no longer let the AWS SDK replay a 5xx inside one call (issue #4639, IAM slice) -- src/provisioning/providers/iam-create-client.ts and the iam-role, iam-user-group, iam-instance-profile, iam-managed-policy and iam-access-key providers. CreateRole, CreateUser, CreateGroup, CreateInstanceProfile, CreatePolicy and CreateAccessKey carry no idempotency token and were sent through the shared IAM client, whose SDK retry replays a 5xx even when IAM completed the request. For the name-unique creates the replay failed EntityAlreadyExists against the entity the first request made, the collision was credited to another holder, and the entity was left in no state record for every re-run to collide with. For CreateAccessKey the replay minted a second key and returned it, leaving the first as a live, unrecorded credential in one of the user's two key slots. They now go through a dedicated client that refuses the SDK's 5xx retry (the CodeCommit / EC2 pattern), so the 5xx reaches the deploy engine, which marks a later collision as possibly this create's own, and, for an access key, the provider's failed-attempt reconcile, which deletes the key that attempt minted when ListAccessKeys already shows it (the list is eventually consistent; a key it does not show yet is neither deleted nor reported, and the retry mints a second one). Tests: tests/unit/provisioning/iam-create-retry-4639.test.ts.
• Lambda, EventBridge bus and ECR creates no longer let the AWS SDK replay a 5xx inside one call (issue #4639, Lambda / EventBridge bus / ECR slice) -- src/provisioning/providers/lambda-create-client.ts and the lambda-function, lambda-url, lambda-permission, eventbridge-bus and ecr providers. CreateFunction, CreateFunctionUrlConfig, AddPermission, CreateEventBus and CreateRepository carry no idempotency token and were sent through a client whose SDK retry replays a 5xx even when AWS completed the request. Each is unique by name, so the replay failed with "already exists" against the resource the first request made. That collision was credited to another holder, and the resource was left in no state record for every re-run to collide with. They now go through a dedicated client that refuses the SDK's 5xx retry (the CodeCommit / EC2 / IAM pattern). The 5xx reaches the deploy engine, which marks a later collision as possibly this create's own. Tests: tests/unit/provisioning/lambda-ecr-create-retry-4639.test.ts.
• Seven more token-less creates no longer let the AWS SDK replay a 5xx inside one call (issue #4639, remaining-sites slice) -- the cloudfront-oac, ssm-parameter, codebuild, budgets-budget, asg, wafv2 and efs providers. CloudFront CreateOriginAccessControl, SSM PutParameter (Overwrite: false), CodeBuild CreateProject, Budgets CreateBudget, Auto Scaling CreateAutoScalingGroup, WAFv2 CreateWebACL and EFS CreateMountTarget carry no idempotency token and were sent through a client whose SDK retry replays a 5xx even when AWS completed the request. The replay collided with what the first request made, the deploy engine credited that "already exists" to another holder, and the create failed leaving a resource in no state record for every re-run to collide with. Each now goes through a dedicated client that refuses the SDK's 5xx retry, built in the same region and with the same identity as the provider's shared client, so the 5xx reaches the deploy engine, which marks the later collision as possibly this create's own. Nothing is adopted on that collision. The Budgets create / update and Auto Scaling group create failure messages, which a surfaced 5xx now reaches more often, quote AWS's text through the secret masker. AgentCore CreateAgentRuntime / CreateEvaluator, the Cloud Map namespace and service creates, Lambda CreateMicrovmImage and Secrets Manager CreateSecret are unchanged: each carries an idempotency token the SDK fills once per call, so its replay inside that call repeats the same token. Tests: tests/unit/provisioning/remaining-create-retry-4639.test.ts.
• cdkd rollback <stack> --drop-failed <logicalId> drops one journaled failed CREATE whose delete can never succeed (issue #4633) -- src/cli/commands/rollback-drop-failed.ts, src/cli/commands/rollback.ts, src/deployment/rollback-executor/journaled-orphans.ts. A failed CREATE whose resource cdkd proved it made is kept in the rollback journal until cdkd deletes that resource; when the delete kept failing for a cause the operator could not fix (a secret or KMS key they cannot read, go-to-k/cdkd#4612), every cdkd deploy exited 2 and every cdkd destroy ended "State preserved", and the only way out was removing the stack's rollback-journal.json, which dropped every other entry too. The new option removes exactly that entry (and the failed replacement UPDATE recorded beside it, go-to-k/cdkd#4604) under the stack lock, after printing the resource it names (masked where the name derives from a secret, with a policy's queue or topic targets) and asking for confirmation (--force / -y skip it; a non-interactive run without them is refused). It replays nothing and deletes nothing in AWS. It refuses an unknown id, a completed operation, a failed operation of any other kind or one a newer journal entry may own (neither blocks either command), an id with several such entries, a state record that cannot be read, and combination with --orphan, --revert-failed or --skip-final-snapshot. The retry warnings of cdkd destroy, a successful cdkd deploy and cdkd rollback now print the pasteable command for each such entry whose delete they tried and that failed. Tests: tests/unit/cli/rollback-drop-failed-4633.test.ts, tests/unit/cli/rollback-drop-failed-cli-4633.test.ts.
• cdkd rollback (plain and --revert-failed) and the automatic rollback no longer hand a provider a physicalId that is absent, empty, whitespace-only or not a string (issue #4628) -- src/deployment/rollback-executor.ts, src/deployment/rollback-executor/{messages,replay-revert,replay-reverse-replacement,replay-orphan-delete}.ts. Every replay arm that addresses AWS by a record's or journaled op's id -- the revert of a completed UPDATE, the --revert-failed force-revert of a failed one, the delete of a completed or partially-created CREATE, and both replacement reversals -- now skips such an op before any provider call: a Cannot ... -- its state record has no non-empty string 'physicalId' warning, a ROLLBACK_RESOURCE_SKIPPED event, exit 2, and the state record left as it is. Before, cdkd rollback --revert-failed (the remedy a failed deploy prints) sent provider.update a blank id for an UPDATE cdkd deploy had refused over such a record, a delete could read the provider's *NotFound as already deleted and drop the record, and a replacement reversal could re-create the old resource before its delete of the new one failed. Re-adopting a retained old resource (UpdateReplacePolicy: Retain) fails instead (journal kept), since only the journal names that resource. A failed CREATE no state record holds is named for manual deletion. A nested-stack record is exempt, as on cdkd deploy, unless it or the arm's route is Cloud Control. A replacement whose new copy is retained (UpdateReplacePolicy: Retain) sends nothing by that id and is unchanged. Tests: tests/unit/deployment/rollback-executor-unaddressable-physical-id-4628.test.ts.
• A successful fix-forward deploy now deletes the EC2 instance an earlier failed CREATE left under the same logical id (issue #4606) -- src/provisioning/providers/ec2-provider.ts. When an AWS::EC2::Instance CREATE failed after RunInstances and its cleanup terminate failed too, the instance was journaled as a proven orphan. If a later deploy created a new instance under the same logical id, that successful deploy warned, named the earlier instance, exited 2 and left it running. EC2Provider now answers isSameResource for instances, using the AWS-generated i- instance id. The client must be in the stack's region, and the record's instance must read back live (pending, running, stopping or stopped). The earlier instance is then different, whether it still runs, is shutting-down / terminated, or is not found, so the settle terminates it. Equal ids are same. Any other id form and a failed read stay unknown, which keeps the previous warning and exit 2. An earlier instance EC2 no longer lists is named in one info line; one still listed as shutting-down or terminated is settled quietly by the terminate. A termination-protected earlier instance is not deleted: the delete fails, the journal keeps the entry, and the next successful deploy tries again. Tests: tests/unit/provisioning/ec2-instance-same-resource-4606.test.ts. Integ ec2-instance Phase 1b runs the read against live instances, a terminated instance and an id that never existed.
• A successful fix-forward deploy now deletes the load balancer, target group or listener an earlier failed CREATE left under the same logical id (issue #4606) -- src/provisioning/providers/elbv2-provider.ts. After cdkd deploy --no-rollback failed with an AWS::ElasticLoadBalancingV2::LoadBalancer, TargetGroup or Listener already created and its wiring-failure cleanup unable to delete it (a journaled proven orphan) and the fixed template created a new one under the same logical id, the successful deploy warned, named the earlier one, exited 2 and left it in AWS. ELBv2Provider now answers isSameResource for the three types from the ARN, whose last segment AWS mints per create (a name alone is reusable, so it is never the identity): both ARNs must be the type's form in the stack's partition, account and region, the client must be in that region, and the record's ARN must read back as itself; the earlier one is then different when it reads back as itself or ELBv2 reports it gone by the type's own not-found error, so the settle deletes it. Equal ARNs are same; any other id form, a read naming another resource and a failed read stay unknown (the previous warning and exit 2). An earlier resource already gone (only by the type's own not-found error name) is named in one info line. A deletion-protected earlier load balancer still needs its protection cleared before the settle can delete it. Tests: tests/unit/provisioning/elbv2-same-resource-4606.test.ts; integ alb Phase 4 asserts the earlier load balancer deleted, the new one kept, exit 0.
• A successful fix-forward deploy now settles the EMR cluster an earlier failed CREATE left under the same logical id (issue #4606) -- src/provisioning/providers/emr-cluster-provider.ts. After cdkd deploy --no-rollback failed with an AWS::EMR::Cluster that RunJobFlow made and the create's own terminate could not stop (a journaled proven orphan) and the fixed template created a new cluster under the same logical id, the successful deploy warned, named the earlier cluster and exited 2. EMRClusterProvider now answers isSameResource from the j- cluster id: the client must be in the stack's region and the record's cluster must read back under its own id, in any state (a transient cluster may already be terminating); the earlier cluster is then different, so the settle deletes it (terminating a live one) and the deploy exits 0. Equal ids are same; any other id form and a failed read stay unknown (the previous warning and exit 2). An earlier cluster already terminated or gone is named in one info line. AWS::EMR::InstanceFleetConfig / AWS::EMR::InstanceGroupConfig keep the warning: no EMR call reads a fleet or group by id without its cluster id, and neither has a delete API. Tests: tests/unit/provisioning/emr-same-resource-4606.test.ts; integ emr-cluster Phase 3b asserts the earlier cluster settled, the new one kept, exit 0.
• A successful fix-forward deploy now deletes the Kinesis stream an earlier failed CREATE left under the same logical id, once a live read proves it is not the new stream (issue #4606) -- src/types/resource.ts, src/deployment/rollback-executor/{journaled-orphans,plan}.ts, src/deployment/rollback-executor.ts, src/provisioning/providers/kinesis-provider.ts. After cdkd deploy --no-rollback failed with a stream already created (a journaled proven orphan) and the fixed template created a new stream under the same logical id, the successful deploy could not prove the two differ, so it warned, named the earlier stream, exited 2 and left it in AWS. Providers gain an optional isSameResource, answering same, different or unknown from a live read; the success-path settle asks it when a record of the orphan's type sits under its logical id, deletes the orphan (per its journaled DeletionPolicy, still subject to the other-stack ownership check) only on different, without reading or dropping that record, and settles same silently as a tracked resource. AWS::Kinesis::Stream implements it: both ids must be stream names, the client must be in the stack's region, the record's stream must read back, and the earlier stream is different when it reads back under another StreamARN or is gone. Equal names are never compared and never deleted; an earlier stream already gone is named in one info line. Only AWS::Kinesis::Stream implements it so far: every other type, an unreadable record, and a read that fails keep the previous warning and exit 2 (the other types remain #4606). Tests: tests/unit/deployment/journaled-orphans-fix-forward-4606.test.ts, tests/unit/provisioning/providers/kinesis-same-resource-4606.test.ts; integ rollback-command step O8 now asserts the earlier stream deleted, the new one kept, exit 0.
• A successful fix-forward deploy now deletes the FSx file system an earlier failed CREATE left under the same logical id (issue #4606) -- src/provisioning/providers/fsx-filesystem-provider.ts. After cdkd deploy --no-rollback failed with an AWS::FSx::FileSystem already created (a journaled proven orphan: a file system whose wait failed and whose cleanup delete failed too) and the fixed template created a new one under the same logical id, the successful deploy warned, named the earlier one, exited 2 and left it in AWS, billed by the hour. FSxFileSystemProvider now answers isSameResource for every variant (Lustre / Windows / ONTAP / OpenZFS) from the fs- file system id FSx generates: the client must be in the stack's region and the record's file system must read back short of DELETING / FAILED, and the earlier one is then different, so the settle deletes it; equal ids are same. An unrecognised id form and a failed read stay unknown (the previous warning and exit 2). An earlier file system already gone is named in one info line. Tests: tests/unit/provisioning/fsx-same-resource-4606.test.ts; integ fsx-lustre Phase 2c asserts the earlier file system deleted, the new one kept, exit 0.
• A successful fix-forward deploy now deletes the NAT gateway or Elastic IP an earlier failed CREATE left under the same logical id (issue #4606) -- src/provisioning/providers/ec2-provider.ts. After cdkd deploy --no-rollback failed with an AWS::EC2::NatGateway or AWS::EC2::EIP already created (a journaled proven orphan: a gateway whose available-state wait failed, an address whose instance association failed) and the fixed template created a new one under the same logical id, the successful deploy warned, named the earlier one, exited 2 and left it in AWS. EC2Provider now answers isSameResource for those two types when SDK-routed (a Cloud Control-routed one, e.g. a NAT gateway setting MaxDrainDurationSeconds, is unchanged) from the AWS-generated id (the nat- gateway id; the eipalloc- allocation id from the composite PublicIp|AllocationId or the bare form, never the public IP): the client must be in the stack's region and the record's resource must read back live (a NAT gateway pending or available), and the earlier one is then different, so the settle deletes it; equal ids (including the composite and bare spellings of one allocation id) are same, and a bare journaled allocation id (the create's fallback when the composite fence refuses) is never different, since the settle's holder checks compare the id string. Every other EC2 type, an unrecognised id form and a failed read stay unknown (the previous warning and exit 2). An earlier gateway or address already gone is named in one info line. Tests: tests/unit/provisioning/ec2-nat-eip-same-resource-4606.test.ts; integ vpc-nat-gateway Phases 1d / 1e assert the earlier resource deleted, the new one kept, exit 0.
• A successful fix-forward deploy now deletes the RDS DB cluster or DB instance an earlier failed CREATE left under the same logical id, once live reads prove it is not the new one and is still the one that failed CREATE made (issues #4606, #4655) -- src/provisioning/providers/rds-provider.ts, src/provisioning/auxiliary-failure.ts, src/deployment/deploy-engine/execute.ts. After cdkd deploy --no-rollback failed with an AWS::RDS::DBCluster or AWS::RDS::DBInstance already created, and the fixed template created a new one under the same logical id with another identifier, the successful deploy warned, named the earlier resource, exited 2 and left it in AWS. RDSProvider now implements isSameResource and resourceIdentity. Both rest on the immutable DbClusterResourceId / DbiResourceId. Identifiers equal apart from case are the same resource, since RDS identifiers are case-insensitive. The failed CREATE journals the resource id its create call returned, carried on the failure itself, so a describe that cannot run (often the failure) does not cost the orphan its identity; a provider may carry such an id on its created-before-failure mark, and the deploy then journals it without a live read. A resource someone re-created under the identifier, in any case spelling, reads back under another resource id and is kept with a warning. Only the not-found fault name counts as gone. Deleting an earlier resource that is already gone prints one info line. Tests: tests/unit/provisioning/rds-provider-{same-resource-4606,resource-identity-4655}.test.ts; new integ rds-fix-forward-orphan.
• The malformed-record refusals and warnings from cdkd deploy, cdkd diff, cdkd drift, cdkd scrub, cdkd export, cdkd local --from-state and cdkd state show / cdkd state resources now print their cdkd state show commands with the run's --profile, resolved --state-bucket and non-default --state-prefix (issue #4159). Changed files: src/state/malformed-resources-bag.ts, src/state/export-index-store.ts, src/deployment/deploy-engine/{options,deploy-flow,update}.ts, src/analyzer/diff-calculator.ts, src/cli/commands/{deploy,destroy,diff,diff-recursive,drift,scrub,state,export,local-state-loader}.ts and src/local/s3-local-state-provider.ts. Before this change only cdkd destroy, cdkd import, cdkd orphan, cdkd rollback and cdkd state refresh-observed carried the flags (issue #3909). Every other command printed the inspect command bare, so on a non-default bucket or profile the pasted command read the wrong bucket. The deploy engine and the pre-lock --recreate-via-* check now print the same flags for the same record, and a nested child's engine inherits them. A value the shared paste gate refuses is printed as a quoted hole with its reason, as for #3909. A --state-prefix such as team/dev is now gated per /-separated part, so it prints as typed on these commands and on #3909's, where it used to be a '<prefix>' hole. One site remains: the nested-stack provider's read of a child's outputs during a deploy.
• A NoEcho: true parameter's value, and a value an attribute was declared NoEcho for, are no longer persisted in the clear: state schema v11 (issues #4043 Phase B, #2449) -- src/types/state.ts, src/deployment/secret-redaction/noecho-leaves.ts, src/deployment/deploy-engine/{noecho,update}.ts. State, observedProperties, outputs, the exports index and the rollback journal store *** where such a value was used (at a position the template names, nested children included, whatever its type or length; elsewhere from 4 characters); noEchoLeaves names those positions, noEchoAttributeNames the declared attributes. A comparison reads the resource back instead: a held value is skipped, an updatable one AWS cannot report is re-sent with an info line, and a create-only property is never replaced on a readback (a warning names --recreate-via-*; a failed read fails the resource). The first deploy after upgrading compares each value with the one last stored: an unchanged one is neither updated nor replaced, a changed one is applied as before, a create-only replacement included. A custom resource's Update runs every deploy with *** in OldResourceProperties; its Delete is skipped (exit 2) where its record holds *** for such a parameter or a declared attribute. A reader of a declared attribute out of an earlier run is still refused, naming it. cdkd drift reports a masked position in its own bucket; cdkd diff no longer shows a changed NoEcho value (one per-stack note, not counted for --fail); cdkd export blocks a resource such a value feeds. A replacement whose old resource's delete was skipped is a partial update (exit 2 unless --allow-unaddressed). Older binaries fail on v11 with "Upgrade cdkd"; earlier state.json versions keep the plaintext, so rotate it. Integ: schema-v10-to-v11-migration (new).
• A Kinesis stream create whose 5xx hid a server-side success is no longer replayed inside the AWS SDK and credited as somebody else's stream (issue #3978) -- src/provisioning/providers/kinesis-provider.ts (getCreateClient) and a new unit file. CreateStream carries no idempotency token and was sent through a client with the SDK's default retry, so a 5xx whose request had succeeded was replayed inside one send, and the replay's ResourceInUseException surfaced from the deploy engine's FIRST attempt, read as a name another holder owns. CreateStream now goes through a dedicated client wrapped by withoutServerErrorRetries: the 5xx reaches the engine's retry, whose ambiguous-outcome latch (#3983) marks the replay's collision as possibly this create's own. What the user sees changes accordingly: a plain create now prints the replay advice (the holder is most likely this create's own stream) instead of "an earlier cdkd run left it behind", and a replacement surfaces the raw create error instead of NAMED_REPLACEMENT_COLLISION. A CreateStream 5xx that did NOT hide a success is now retried on the engine's logged schedule rather than the SDK's quick in-send retries. Every other Kinesis call keeps the full SDK retry, and a stream that existed before any ambiguous attempt is still a name collision. The stream is not adopted on that collision -- a name is not attribution. Residual: #4639, the other token-less name-unique creates, and the socket reset or timeout the SDK still replays.
• cdkd destroy masks a physical name derived from a secret on a journaled orphan's delete lines and in its deployment events (issue #3869) -- src/deployment/secret-name-needles.ts, src/deployment/rollback-executor/journaled-orphans.ts, src/cli/commands/destroy-runner.ts. A resource a failed deploy created before failing is recorded only in the rollback journal, and cdkd destroy deletes it from there. When its name came from a secret, that delete's provider lines and final-snapshot lines printed the name: they ran under no printing bag. They now run under one judged from the journal entry itself (its type, recovered physical id and attempted properties), plus the names the entry read from a state record. The same deletes also run when a successful deploy acts on its journal. Separately, the reason and error message of each destroy event (RESOURCE_FAILED, RESOURCE_SKIPPED, RESOURCE_GUARD_INDETERMINATE, and a journaled orphan's rollback events, on the deploy-success path too) were stored verbatim in deployments/*.jsonl, while the log line beside them was masked. They are now masked with the same needles. An event's physicalId field stays exact. Tests: tests/unit/cli/destroy-journaled-orphans-secret-name-3869.test.ts, tests/unit/deployment/secret-name-needles-3869.test.ts; integ secret-derived-immutable-names gains step 6b, which destroys a failed-CREATE ECR repository named from the secret.
• cdkd diff's adoption refusal and both rollbacks' completed-op replay mask a physical name derived from a secret (issue #3869) -- src/deployment/secret-name-needles.ts, src/cli/commands/diff-recursive.ts, src/cli/commands/rollback.ts, src/deployment/deploy-engine/rollback.ts, src/deployment/nested-child-journal.ts, src/cli/commands/diff.ts. cdkd diff previews the refusal cdkd deploy throws when a resource an earlier rollback kept is recorded by another stack. It printed that resource's physical id in plaintext, in the rendered view and under --json, while the deploy's refusal masked it. It is now masked with the same needles (orphanRecordsPrintingBag). cdkd rollback and a failed deploy's automatic rollback revert the deploy's COMPLETED operations, for example by deleting a resource it created. That revert ran under no printing bag, so a resource named from a secret printed its name on the provider's delete lines. Both now revert under a bag judged from each op's record and the record it replaced, and so does a nested stack's child revert. The orphan-adoption planner's own lines (a vanished record, the existence check) are masked on cdkd deploy and cdkd diff too. cdkd rollback also judges each segment's failed ops against the state as that segment finds it, so it catches a name a newer segment's revert put back. An event's physicalId field stays exact. Tests: tests/unit/cli/diff-adoption-refusal-secret-name-3869.test.ts, tests/unit/cli/rollback-completed-ops-secret-name-3869.test.ts, tests/unit/deployment/deploy-engine-rollback-orphan-secret-name-3869.test.ts; integ secret-derived-immutable-names adds a completed-CREATE queue named from the secret to steps 6c and 6d.
• cdkd deploy masks an ElastiCache final-snapshot name cut from a secret-derived id (issue #3869) -- src/deployment/secret-name-needles.ts, src/provisioning/final-snapshot.ts. A final-snapshot name for an ElastiCache cache cluster or replication group keeps only the first 28 characters of the physical id. When the id was judged from plaintext, the masker had only the whole id or the secret as needles. Those plaintexts are a name resolved this deploy, a NoEcho parameter value, or a secret embedded in the id. If one of them ran past character 28, the snapshot name held only a fragment of it. No needle matched that fragment, so the fragment printed in the clear. That covers the Creating final snapshot and ready lines of a template-removal or replacement delete, and AWS's SnapshotAlreadyExistsFault text quoting the name. The derived-name judge now adds the snapshot's <base>-final- prefix as a needle whenever the cut splits one of its needles, and, for any snapshot-capable type, the folded spelling (lowercased, outside characters mapped to -) of a needle the base folds but carries whole. A state record still spelling a {{resolve: reference already had this prefix. Tests: tests/unit/deployment/derived-name-needle-3869.test.ts, tests/unit/provisioning/final-snapshot.test.ts. The noecho-parameter-masking integ gains Phases 4a and 4b: a replication group named rg-<NoEcho value> under DeletionPolicy: Snapshot is removed, and its snapshot line must print no fragment of the name.
• cdkd rollback and a failed deploy's automatic rollback mask a physical name derived from a secret on a journaled orphan's delete lines and in its events (issue #3869) -- src/cli/commands/rollback.ts, src/deployment/deploy-engine/rollback.ts. A resource a failed CREATE made before failing is recorded only in the rollback journal. Both rollback paths replay it, and cdkd rollback --revert-failed replays every other failed op too. That replay ran under no printing bag, so when the resource was named from a secret, its provider's delete lines and the final-snapshot lines printed the name. Its ROLLBACK_RESOURCE_FAILED and skip events were masked with the op's own masker only, which holds no name the resource READ from another record (an access key's UserName). cdkd rollback now replays under the printing bag cdkd destroy uses (#4631), judged from each journal entry. The automatic rollback, whose entries are still resolved plaintext in memory, replays under the engine's own bags: each orphan's resolved secrets and derived-name registry, plus the names it read, judged by the read resource's own resolution. Both mask each event's text with the bags bound where it is recorded. A deploy re-adopting a resource an earlier rollback kept also masks such a name on its Adopting ... as <physicalId> line, its notices about kept records, and its refusal of a record another stack holds. An event's physicalId field stays exact. Tests: tests/unit/cli/rollback-orphan-secret-name-3869.test.ts, tests/unit/deployment/deploy-engine-rollback-orphan-secret-name-3869.test.ts; integ secret-derived-immutable-names gains steps 6c and 6d, a plain cdkd rollback and an automatic rollback of a failed-CREATE ECR repository named from the secret.
• A nested-stack child resource reading a secret-carrying parameter no longer reports a change on every deploy (and cdkd scrub of a nested stack persists the same value) when the parameter's expression cannot be certified (issue #2349) -- src/deployment/secret-redaction/nested-stack.ts, src/deployment/secret-redaction/redact-path.ts, src/deployment/deploy-engine/masking.ts, src/deployment/intrinsic-resolver/parameter-secrets.ts. When two child parameters resolved to one secret plaintext and a resource read both, a {Ref: <Param>} leaf that cdkd could not tie to its parameter's own {{resolve:...}} expression (a value EMBEDDING the secret, such as a postgres://u:<secret>@host connection string the parent built with Fn::Sub, or a parameter whose association was refused) was persisted with whichever parameter's expression resolved last, while the diff side used the parent's. The two never matched, so the child reported an UPDATE that no deploy cleared (the post-resolve re-check prevented any AWS write). Both sides now answer such a leaf with one function over the parent's bag, redactInheritedParameterValue. The persisted leaf falls back to the previous redaction whenever that answer would leave a plaintext the resource's own bag holds, so nothing is persisted less redacted than before. Composite Fn::Sub / Fn::Join leaves that every positioning arm refuses keep the old behaviour. cdkd diff --recursive still renders such a parameter with its own spelling and can disagree in one parent resolution order (issue #4644). Tests: tests/unit/deployment/secret-redaction-nested-parameter-list.test.ts (the two pinned residual cases now assert agreement), tests/unit/deployment/secret-redaction-nested-parameter-fallthrough.test.ts.
• A tagged ALB / NLB listener now deploys through cdkd's ELBv2 provider, so removing a ListenerAttributes key resets it in AWS (issue #2085) -- src/provisioning/providers/elbv2-provider.ts, src/provisioning/property-coverage.generated.ts. An AWS::ElasticLoadBalancingV2::Listener carrying Tags (any CDK app that tags its stack, e.g. cdk.Tags.of(stack).add(...)) was routed through Cloud Control with "cdkd's SDK Provider does not yet wire Tags", although the provider already sent the tags on create, diffed them on update and read them back. On that route, dropping a key from ListenerAttributes (e.g. routing.http.response.server.enabled) left the old value live in AWS. ELBv2Provider now declares Tags handled for the listener, so a new tagged listener stays on the SDK route, where a removed key is reset to its documented default. A listener already recorded as provisioned through Cloud Control stays there for now. Tests: tests/unit/provisioning/elbv2-listener-tags-route-2085.test.ts; integ alb (the listener attribute removal assertion).
• When the delete of the old resource fails with an AWS API error during cdkd deploy --replace's delete-first fallback or --recreate-via-cc-api / --recreate-via-sdk-provider, the RESOURCE_FAILED event now records the AWS error code and request id (issue #1889) -- src/deployment/deploy-engine/replacement.ts, src/deployment/deploy-engine/update-replace.ts. Both paths re-threw the delete's failure as a new error with no cause, so the event's awsErrorCode / requestId were absent. The delete error is now chained as the cause, masked with the resource's resolved secrets like the message. A Cloud Control handler failure or a refusal cdkd raises itself still records neither, since neither carries AWS response metadata. The --replace re-create wrap's existing cause is masked the same way, and the --recreate-via-* destroy message is now masked where it is built. Tests: tests/unit/deployment/deploy-engine-rewrap-masked-cause-1889.test.ts; integ recreate-via-cc-api gains Sub-3e, a recreate whose bucket delete a bucket policy denies.
• A nested stack whose child failed to destroy keeps its state row whatever its logical id spells, and terminal intrinsic-resolution failures are declared non-retryable (issue #1889) -- src/provisioning/providers/nested-stack-provider.ts, src/deployment/intrinsic-function-resolver.ts, src/deployment/intrinsic-resolver/{getatt,params-conditions,functions,cross-stack,dynamic-ref-lookups,stack-output,stack-state,string-functions}.ts. The resolver's plain-Error refusals that no retry can change (an unsupported intrinsic, a malformed Fn::GetAtt / Fn::Join / Fn::Select / Fn::Base64 / Fn::Cidr / Fn::And / Fn::Or / Fn::Not argument, a missing Fn::FindInMap mapping or key, an invalid Fn::GetAZs region or an empty zone list, every Fn::GetStackOutput argument check and a missing output of a producer it read, a dynamic reference whose secret or parameter has no usable value, a required parameter with no value) are now marked non-retryable. Several quote a template value, so a name containing a retryable pattern such as DependencyViolation read as transient to cdkd's retry classifiers; no retry loop wraps resolution today, so this is a declaration rather than a change a deploy shows. A relayed AWS failure stays retryable, and so do the cross-stack "export / stack not found" errors, which can follow a swallowed transient lookup failure. AWS::CloudFormation::Stack's child-failure error is now marked on both arms, not only when interrupted: previously a child logical id containing NotFoundException made cdkd destroy and a deploy that removes the nested stack read the failure as "already deleted" and drop the parent's row while the child's state survived. Tests: tests/unit/deployment/intrinsic-terminal-bare-throws-non-retryable.test.ts, tests/unit/provisioning/nested-stack-provider.test.ts, tests/unit/provisioning/nested-stack-provider-cycle.test.ts.

Recently Implemented (2026-10-06):

• The NAMED_CREATE_COLLISION refusal ends on a pasteable cdkd import command (PR #4622) -- src/deployment/deploy-engine/create.ts. When a plain create of an explicitly named resource meets an existing holder of that name, the error printed only "adopt it with cdkd import" and named a deploy interrupted earlier as the only own-resource case. It now names a resource a cdkd destroy kept under DeletionPolicy: Retain too, and ends on Adopt with: cdkd import <stack> --resource <logicalId>=<physicalId> for the holder it found. It is preceded by a line asking the reader to confirm the resource is theirs, and withheld for a nested-stack child, for AWS::S3::Bucket (whose lookup also finds a listable bucket of another account), and when the secret mask would rewrite any part of the command. Tests: tests/unit/deployment/deploy-engine-create-name-takeover-4180.test.ts.
• Deleting a failed AWS::SQS::QueuePolicy or AWS::SNS::TopicPolicy journal entry no longer clears a queue or topic whose policy was replaced by a different one (issue #4612) -- src/provisioning/providers/{sqs-queue-policy,sns-topic-policy}-provider.ts, src/provisioning/{region-check,policy-document-content}.ts, src/types/resource.ts, src/deployment/{rollback-executor,delete-outcome}.ts, src/deployment/rollback-executor/{types,journaled-orphans}.ts. A policy that wrote some targets and then failed is journaled under exactly those (#4583). The automatic rollback, cdkd rollback, cdkd destroy and a later successful deploy cleared (or reset) each by name, so a target another policy or an outside write had since replaced lost that policy. The failed-CREATE delete now marks the entry a proven orphan and hands over a lazy re-resolution of its redacted attempted bag; the provider clears a queue, or resets a topic to its default, only while its live policy matches the attempted document by content, IAM-equivalent spellings folded (SQS stores a bare account id as its root ARN). Anything else is left with a warning and reported (leftInPlace), so the rollback and the deploy exit 2 (cdkd destroy warns only); so is a target the settling deploy itself just wrote. A missing or masked document, or a secret reference known to fail (not found, or refused for good: a refusal cdkd marks non-retryable) settles the entry, every target named, nothing cleared; any other failure (an unreadable policy, credentials, throttling) keeps it as a failed delete. A gone target is region-checked first; a one-target entry no longer widens; a record's own delete and update are as before. Tests: tests/unit/provisioning/{sqs-queue-policy,sns-topic-policy}-provider-orphan-content-4612.test.ts, tests/unit/deployment/failed-create-orphan-context-4612.test.ts; integ Phase 1d of sns-subscription-filter, Phase 2b of sns-sqs-event.
• An AWS::SNS::TopicPolicy is now actually removed from a topic: on destroy, and from a topic an update drops from Topics (issue #4610) -- src/provisioning/providers/sns-topic-policy-provider.ts. delete() sent an empty Policy, which SNS would reject: CloudFormation's own TopicPolicy handler source says SNS requires a policy on a topic. delete() read an Invalid parameter rejection as "already removed", so a destroy could report the policy deleted and drop its record while every topic kept the statement. It now writes each topic its default policy, as that handler does, and an InvalidParameter fails the delete. A record whose id is not a list of topic ARNs (the policy name an old --migrate-from-cloudformation recorded) falls back to the topic ARNs its Topics lists. When neither names one, the destroy now refuses, naming the by-hand reset and the cdkd state orphan --resource remedy. update() wrote only the new Topics, so a dropped topic kept the old statement; this is also what an in-place rollback of Topics [T1] -> [T1,T2] left on T2. It now resets each topic the record's id names that the new list drops, after writing the new list. A topic only the previous properties list (the attempted list a revert of a failed update passes) is reset only while its live policy matches that bag's PolicyDocument by content. Tests: tests/unit/provisioning/sns-topic-policy-provider-dropped-topics-4610.test.ts; integ arm in tests/integration/sns-sqs-event/.
• A removed or orphaned resource is listed by its construct path, and --require-approval=any-change asks for an Outputs-only change (issue #4607) -- src/types/state.ts, src/analyzer/destructive-changes.ts, src/deployment/deploy-engine.ts, src/deployment/deploy-engine/{deploy-flow,options}.ts, src/deployment/deployment-approval.ts, src/cli/commands/{import,require-approval}.ts. State records gain an optional constructPath (the template's aws:cdk:path, no schema bump), stamped on every deploy save and by cdkd import. cdkd diff --fail-on=destructive and the --require-approval=destructive list name a resource the template no longer declares by that recorded path (MyStack: AWS::DynamoDB::Table Table MyTable794EDED1 will be orphaned), where they showed only the logical ID. No save or S3 request is added: a stack written by an older release gains paths on its next deploy that writes state. --require-approval=any-change now asks before a deploy with no resource change writes changed Outputs (or a changed export set), matching the AWS CDK CLI; it deployed those without asking. Tests: tests/unit/deployment/deploy-engine-construct-path.test.ts, tests/unit/deployment/deploy-engine-require-approval.test.ts, tests/unit/analyzer/destructive-changes.test.ts, tests/unit/cli/{import-build-state-policies,require-approval}.test.ts; integ diff-fail-on-destructive.
• A replacement's new resource that was created and then failed is now deleted by every rollback path, and an in-place update that changed a physical id is now rolled back in place (issues #4604, #4615) -- src/deployment/deploy-engine{,/execute,/update-in-place,/rollback}.ts, src/deployment/rollback-executor{,/plan,/journaled-orphans,/replay-reverse-replacement}.ts, src/cli/commands/rollback.ts, src/types/rollback-journal.ts. A resource a create proved it made before failing (#1710) was journaled only on a first-time CREATE; a replacement's new one stayed in AWS, untracked. It is now journaled beside the replacement's UPDATE, naming the record it was replacing, and the automatic rollback, cdkd rollback, cdkd destroy and a later successful deploy that did not touch the logical id delete it per its DeletionPolicy without touching that record, and the failed UPDATE is never force-reverted (a rollback or destroy warns when a delete-first replacement already removed the old resource); a record that names anything else still skips it with a warning. A rollback's own re-create that leaves such a resource deletes it (kept and named under Retain / Snapshot or a failed delete). Separately, the rollback treated every completed UPDATE whose physical id changed as a replacement, so an in-place SQS QueuePolicy or SNS TopicPolicy update that moved its id was undone by re-creating the old policy and then deleting the "new" one, which removed the policy just written; the journal now records the provider's wasReplaced, and an in-place update is reverted in place (a journal from an older cdkd keeps the old reading). Tests: tests/unit/deployment/{replacement-create-orphan,deploy-engine-rollback-journal}.test.ts, tests/unit/types/rollback-journal.test.ts; integ Phase P in tests/integration/rollback-command/.
• A skipped DELETE during cdkd deploy names a drop command for that one record, not the whole stack (issue #4602) -- src/deployment/deploy-engine/delete.ts, docs/cli-deploy-safety.md. The deploy engine's warning for a delete a provider skipped ended on Drop the record with: cdkd state orphan <stack> --stack-region <region>, which drops the record of every resource in the still-deployed stack, so the next deploy re-creates or collides with all of them; it printed this beside the provider's own warning, which since #4609 names the --resource form. The line now ends in --resource <logicalId> (a logical id that is not a plain identifier prints as a '<logicalId>' hole), and the warning says to keep --resource on the drop. For a nested stack's AWS::CloudFormation::Stack row, where --resource refuses while the child has a record, the Inspect it with: and Drop the record with: lines name the child's own record (<stack>~<logicalId>) and the warning says to delete by hand what the child still holds first, after which the next deploy removes the row (an interrupted child is resumed by re-running the deploy instead); a withheld child name prints as '<child-stack>'. Tests: tests/unit/deployment/deploy-engine-delete-skipped-journal.test.ts; integ: nested-stack-3level (Step 4c).
• cdkd state orphan <stack> --resource <logicalId> drops one resource's record without a CDK app, and provider skip warnings name it instead of the whole-stack form outside a destroy (issue #4602) -- src/cli/commands/{state,orphan}.ts, src/analyzer/orphan-rewriter.ts, src/provisioning/{state-orphan-remedy,redacted-delete-address,composite-id}.ts, src/provisioning/providers/{custom-resource,cloudwatch-anomaly-detector,lambda-permission,iam-policy,iam-user-group,s3-bucket,ec2}-provider.ts, docs. No command removed one record of a deployed stack whose construct had left the template, so a skipped delete during cdkd deploy printed cdkd state orphan <stack>, which drops the record of every resource in the stack. The new repeatable --resource removes only the named entries, rewrites the Ref / Fn::GetAtt / Fn::Sub / dependencies / outputs that other records hold to them as cdkd orphan does (an unresolvable one refuses unless --force), takes the stack's lock (a held lock refuses, --force included) and saves conditionally; it needs one stack and refuses an ambiguous region, an unknown id, and a row whose nested-stack child still has a record. The provider delete-skip warnings and refusals now name --stack-region <region> --resource <logicalId> outside a stack destroy, and the whole-stack form (with the --resource alternative) only on cdkd destroy / cdkd state destroy; the SecurityGroupIngress update refusal always names --resource. cdkd orphan --force and state orphan --resource --force no longer copy a cached value cdkd recognises as a credential (by name, a custom resource's attribute, a known secret-valued attribute), the redaction mask or an unresolved {{resolve:}} into another record or print it. Tests: tests/unit/cli/state-orphan-resource.test.ts, tests/unit/provisioning/state-orphan-remedy-4602.test.ts; integ arm in tests/integration/retain-orphan-redeploy/.
• A successful deploy now acts on a resource a failed CREATE made before it failed, instead of silently dropping the rollback journal that is its only record (issue #4600) -- src/deployment/deploy-engine/{rollback,deploy-flow}.ts, src/deployment/rollback-executor/journaled-orphans.ts, src/deployment/nested-child-journal.ts, src/state/s3-state-backend.ts. After #4584 the automatic rollback, cdkd rollback and cdkd destroy acted on such a journaled resource, but a later successful deploy deleted the journal unconditionally, and a top-level deploy deleted each nested stack's journal the same way, leaving the resource in AWS untracked. Now the deploy deletes it per its journaled DeletionPolicy (Retain keeps it, Snapshot snapshots it) when, among the existing #1710 ownership checks, after the deploy no state record sits under its logical id, the deploy completed no operation under it, and no resource record of this stack, nor any resource or rollback-orphan record of another stack under the same state prefix, holds its type and physical id; a record of this stack holding that very resource tracks it, and the entry is dropped silently. Otherwise it warns, naming the physical id, drops the entry with the journal, and counts it with the skipped deletes, so the deploy exits 2 (--allow-unaddressed exits 0); a fix-forward that keeps the logical id under another name lands here, and deleting the earlier resource there is follow-up #4606. An entry the deploy could not act on (a failed delete, an interrupt, an unreadable record) keeps the journal, reduced to it where it can, for the next successful deploy. Tests: tests/unit/deployment/{deploy-engine-rollback-journal,deploy-engine-nested-journal,nested-child-journal,journaled-orphans-success}.test.ts, tests/unit/state/{s3-state-backend,malformed-resources-bag}.test.ts; integ Phase O steps O6-O8 in tests/integration/rollback-command/.
• A custom-resource delete skipped during cdkd deploy no longer tells the user to run cdkd state orphan (issue #4596) -- src/provisioning/providers/custom-resource-provider.ts, docs/cli-deploy.md. When a custom resource's delete was skipped (the handler answered FAILED, the invoke did not complete, or the recorded ServiceToken was the redaction mask or a {{resolve:...}} reference), the warning told the user to tear the resource down by hand and clear the stack's records with cdkd state orphan <stack> --stack-region <region>. That is safe on cdkd destroy, but on a deploy the stack is still deployed, so the command dropped the record of every live resource in it and the next deploy re-created or collided with all of them. The warning keeps that advice only on cdkd destroy / cdkd state destroy. Everywhere else it says to fix the handler (or restore ServiceToken in state.json) and re-deploy, which re-attempts the delete, that --allow-unaddressed lets a deploy exit 0 meanwhile, that a replacement or rollback whose other copy already exists leaves the surviving one untracked to tear down by hand, and not to run cdkd state orphan on a stack that is still deployed. The error for a recorded ServiceToken that is not a string no longer offers cdkd state orphan on create, update or a deploy-side delete; on create and update it points at the template, which a deploy reads and a rollback re-applies by re-deploying, and on a delete it names restoring the ARN. The skip outcome and reason are unchanged, and a destroy's warning no longer carries the deploy-only text. Tests: tests/unit/provisioning/custom-resource-skip-remedy-4596.test.ts.
• AWS::SQS::QueuePolicy naming several queues is now cleared from every queue it wrote on destroy, and from a queue an update drops from Queues (issue #4594) -- src/provisioning/providers/sqs-queue-policy-provider.ts. cdkd destroy cleared only the first queue (the physical id) and an update ignored the previous list, so the other queues kept granting what the policy granted. The physical id stays the first queue URL; create and update now also record every queue they wrote in a cdkd:WrittenQueues attribute, which delete() clears and update() uses to clear the queues the new list drops (a gone queue is tolerated). A record without the attribute (written before this change, or imported) needs no migration: its other listed queues are cleared only while they carry the recorded policy document, compared by content, because a failed create's revert (issue #4583) or a failed update's revert lists queues it may never have written; one that cannot be read is named in a warning. Tests: tests/unit/provisioning/sqs-queue-policy-provider-multi-queue-4594.test.ts; integ: sns-subscription-filter (two-queue policy shrink, grow, destroy).
• The automatic rollback, a plain cdkd rollback and cdkd destroy now delete a resource a failed CREATE made before it failed, instead of dropping its only record (issue #4584) -- src/deployment/deploy-engine/{rollback,execute}.ts, src/deployment/rollback-executor.ts, src/deployment/rollback-executor/{plan,journaled-orphans}.ts, src/cli/commands/{rollback,destroy-runner}.ts, src/state/{s3-state-backend,malformed-resources-bag}.ts. Since #1710 such a CREATE (Kinesis so far) is journaled with its physical id, but only cdkd rollback --revert-failed acted on it: the automatic rollback left the resource in AWS, a plain cdkd rollback popped the entry, and cdkd destroy swept the journal with the state, after which nothing in cdkd named it. Now, as CloudFormation's rollback deletes a failed CREATE, the automatic rollback deletes it before reverting the completed operations; a plain cdkd rollback replays it as --revert-failed does (other failed operations still need the flag); and cdkd destroy lists and counts it before the prompt, re-reads the journal under the lock, deletes it before the stack's resources and strips the entry, and never takes the unconfirmed empty-stack path while one is journaled (a journal it cannot read is still warned about and removed with the state). A later successful deploy still drops the journal without deleting it (#4600). Each honours the journaled DeletionPolicy (Retain keeps it, Snapshot snapshots it) and the #1710 ownership checks; a failed delete keeps the record (the full segment, or the state and journal on destroy). --no-rollback deletes nothing. Tests: tests/unit/deployment/deploy-engine-rollback-journal.test.ts, tests/unit/cli/commands/rollback.test.ts, tests/unit/cli/rollback-divergent-region.test.ts, tests/unit/cli/destroy-runner-journaled-orphans.test.ts; integ Phase O in tests/integration/rollback-command/.
• cdkd rollback --revert-failed now deletes the resource SDK providers made before their create failed, not only Kinesis's (issue #4583, follow-up of #1710) -- src/provisioning/providers/*.ts (among them EC2, ELBv2, Auto Scaling, IAM, Lambda, ECS, RDS, DynamoDB, S3, SNS, EFS, EMR, ACM, FSx, Pipes), docs/provider-rules.md, docs/cli-rollback.md. A follow-up call (tags, policies, a wait) failing after the create returned left the resource unrecorded. Providers now mark the thrown error with the id delete() takes (markCreatedBeforeFailure), so the failed CREATE is journaled with it and --revert-failed deletes it. A provider that already deletes its own resource in the catch marks only when that cleanup failed; a resource the create adopted or found held, the create call's own failure and a pre-flight refusal are never marked. AWS::IAM::Policy instead removes the policy from the principals it had already written and warns with the commands when that fails; AWS::SNS::TopicPolicy and AWS::SQS::QueuePolicy mark only the topics or queues they had written; an AWS::ElasticLoadBalancingV2::Listener create, and an AWS::ECS::Service create under --full-wait, first read whether the port or service name was already taken, and such a resource is neither cleaned up nor marked; AWS::S3Express::DirectoryBucket resolves its ARN before CreateBucket. Limits: a failed CREATE journals one id, so a retried create with an AWS-generated id names only its last resource; no id returned (a Cloud Map operation that never finished, CreateTrail / CreatePolicy / RegisterStreamConsumer with none) means no mark. A nested stack is marked when reading its deployed child back fails (issue #4595). Tests: tests/unit/provisioning/*-created-before-failure-4583.test.ts, plus cases in the S3 bucket and SNS topic cleanup tests.
• cdkd diff --fail-on and cdkd deploy --require-approval, ported from the AWS CDK CLI (issue #4429) -- src/analyzer/destructive-changes.ts (new), src/deployment/deployment-approval.ts (new), src/cli/commands/{diff,diff-recursive,deploy,require-approval,confirm-prompt,prefix-migration-check}.ts, src/cli/config-loader.ts, src/deployment/deploy-engine/{options,deploy-flow}.ts, src/deployment/resource-deadline.ts, src/utils/live-renderer.ts. Port of aws/aws-cdk-cli#2020, #2011 and #2021. cdkd diff --fail-on=never|any-change|destructive picks which change exits 1; --fail / --no-fail alias any-change / never, combining either with --fail-on or repeating it is refused, default never. destructive fails only on a replacement (will / may be replaced), deletion or orphaning (Retain / RetainExceptOnCreate removal), always walks nested stacks, and lists them; --json carries destructiveChanges per stack. cdkd deploy --require-approval=never|any-change|destructive (also requireApproval in cdk.json, default never) asks after the diff and before any provider call, counts a --recreate-via-* target as a replacement, fails without a terminal unless --yes, and serializes prompts across parallel stacks (the prefix-migration prompt too). A nested stack asks when its row is reached, with the row's --resource-timeout paused meanwhile. CDK's broadening is not offered (no security diff); cdk.json's broadening is ignored with a warning. Tests: tests/unit/analyzer/destructive-changes.test.ts, tests/unit/cli/{diff-fail-on,require-approval}.test.ts, tests/unit/deployment/{deployment-approval,deploy-engine-require-approval,resource-deadline}.test.ts; integ diff-fail-on-destructive.
• cdkd diff, import, scrub, export, destroy and drift --revert mask a physical name derived from a secret on their resolver, delete, revert and diff-row lines (issue #3869) -- src/deployment/secret-name-needles.ts (new, shared with deploy), src/deployment/deploy-engine/masking.ts, src/deployment/intrinsic-resolver/{context,getatt,masking,functions,string-functions}.ts, src/cli/commands/{diff-recursive,import,scrub,export,destroy-runner,drift}.ts. cdkd deploy already masked a resource NAMED from a secret (its record spells the name as a {{resolve: reference) wherever another resource read it. The commands that resolve against state did not. Under --verbose, cdkd diff, import, scrub and export printed that name, or an ARN or URL embedding it, on the resolver's resolved to line for a Ref / Fn::GetAtt to it, or as an Fn::Base64 encoding or Fn::Split piece of one; cdkd diff also printed it in a reader's rendered rows. cdkd destroy printed it on the resource's own delete lines, on a deleted reader's lines (an access key's UserName, an instance profile's Roles, a role detaching a policy whose path came from a secret) and on the final-snapshot lines; cdkd drift --revert printed it on a reverted reader's provider, retry and failure lines. These commands now record those reads into a print-only bag, so nothing they persist or decide changes, and each destroy delete and drift revert runs under a printing bag of its own needles and those it read. docs/deployment-events.md now says an event's physicalId field is stored as AWS returned it. Tests: tests/unit/deployment/secret-name-needles-3869.test.ts, tests/unit/cli/{destroy,diff,import,export,drift-revert}-secret-name-needles-3869.test.ts, tests/unit/cli/commands/scrub-secret-name-needles-3869.test.ts; integ secret-derived-immutable-names gains a cdkd diff --verbose step and destroy assertions.
• A physical name derived from a secret no longer prints in the lines of the resources that read it, or in the engine's own lines about it (issue #3869) -- src/deployment/deploy-engine.ts, src/deployment/deploy-engine/{masking,resolver-context,provision,create,update,outputs,update-in-place}.ts, src/deployment/intrinsic-resolver/{context,getatt,refs}.ts, src/deployment/resource-secrets-scope.ts, src/deployment/rollback-executor/names.ts, src/deployment/secret-redaction/mask-errors.ts. When a resource's name came from a secret or a NoEcho parameter (resolved this deploy, or still recorded as a {{resolve: reference after a rotation), a Ref / Fn::GetAtt to it resolves to a name or ARN no masker recognised. cdkd deploy --verbose printed it on the resolver's resolved to line, and the reading resource's provider lines, errors and events printed it too, a deleted reader's included. The read value and the name's spellings (the rollback's secretDerivedNamePairs) are now masked in those lines. The resource's own lines mask them too, from its create onward, including Deleting old <id> and was replaced: <old> -> <new>. No persisted property value, sent value or diff changes: the needles are print-only (a masked property's fingerprint can be refused more often, which fails closed). A nested-stack row, the outputs pass and the masked-input fingerprint pass record them into a print-only bag, so their decisions do not change. An event's physicalId field stays exact, and so does the id a failed CREATE journals for --revert-failed. Tests: tests/unit/deployment/{derived-name-needle-3869,deploy-engine-derived-name-needle-3869,deploy-engine-delete-guard-events,deploy-engine-rollback-journal,secret-redaction-error-masking}.test.ts. Integ: secret-derived-immutable-names gains a queue policy and a role that read the secret-named queue and policy.
• cdkd deploy no longer hands a resource record's torn properties map or missing physicalId to a provider (issue #3211, deploy half) -- src/deployment/deploy-engine/{deploy-flow,update,delete,observed-capture}.ts, src/deployment/read-only-attribute-healer.ts, src/state/malformed-resources-bag.ts. A record whose properties is absent, null or not an object is now refused at the state load, naming the stack, before any provider call. Before, the refusal came from the diff, after the observed-state auto-refresh had already handed the map to provider.readCurrentState. For a record whose physicalId is absent, empty, whitespace-only or not a string (other than a nested stack's not recorded on Cloud Control): a template removal skips the delete with skipped (state record has no physical id) and keeps the record, as cdkd destroy does; before, the provider was called with that value, and a *NotFound answer read as already deleted dropped the record of a resource still live. An update of such a record now fails before anything is sent, instead of calling provider.update (or a replacement's delete) with it. The auto-refresh and the Fn::GetAtt attribute heal (shared with cdkd diff) no longer read such a record. An unchanged record is not refused. A custom resource handler answering a whitespace-only PhysicalResourceId now takes the fallback an empty one always took (the logical id on create, the current id on update, src/provisioning/providers/custom-resource-provider.ts), so it is never recorded as an id later deploys would refuse. Tests: tests/unit/deployment/deploy-engine-unaddressable-record-3211.test.ts, tests/unit/deployment/deploy-engine-malformed-properties-refusal.test.ts, tests/unit/deployment/read-only-attribute-healer.test.ts, tests/unit/provisioning/custom-resource-unaddressable-physical-id-3211.test.ts.
• cdkd drift stops reading a stack after 5 reads in a row fail, instead of paying the same failure once per resource (issue #2207) -- src/cli/commands/drift.ts, docs/cli-drift.md. An expired token, a revoked role or a permission every read needs used to be read, and backed off, once for every resource of every stack before the run exited 2 anyway. Once 5 reads in a row in one stack throw through the same read path (every Cloud Control read, whether the resource is managed through Cloud Control or falls back to it, or a read through one of cdkd's own SDK providers), cdkd reads nothing more that way in that stack and reports each remaining resource it would have read so under the new notCompared cause readAborted (cdkd never read it: ...), with one warning saying why (a burst of throttling can trip it too, and a re-run clears that); the exit code is still 2. A read that returns resets the count for both paths, so one unreadable resource among readable ones is still the per-resource readFailed it was, and the rest of the stack is compared; a comparison that throws after a good read, and a type with no Cloud Control READ handler, reset it too. The count is per stack, so other stacks in an --all run are still read. Tests: tests/unit/cli/drift-per-resource-failure.test.ts, tests/unit/cli/drift-outcome.test-d.ts.
• cdkd local resolves CloudFormation dynamic references before a container starts (issue #2056) -- package.json (cdk-local ^0.149.9), src/cli/commands/{local-invoke,local-start-api,local-invoke-agentcore,local-run-task}.ts, src/local/{container-pool,ecs-task-runner,ecs-task-resolver}.ts. A container env value carrying {{resolve:secretsmanager:...}} / {{resolve:ssm:...}} / {{resolve:ssm-secure:...}} reached the container as the token text, including a --from-state Fn::ImportValue / Fn::GetStackOutput of a secret-bearing output, which cdkd persists redacted to its token (#1899). local invoke, local start-api, local invoke-agentcore and local run-task now resolve it with the developer's credentials (--profile honoured, never the --role-arn role: src/local/dynamic-reference.ts) through cdk-local's resolver (go-to-k/cdk-local#784): a cross-stack value in the producer's region, any other in the owning stack's. A resolved key is a value-less -e KEY, off the docker run argv and every log line; an --env-vars override skips the lookup; a failed lookup fails the command before any container starts, naming the reference and the IAM permission. local run-task refuses a token in Command / EntryPoint / a health-check command. The engine commands (start-agentcore, start-cloudfront, start-service, start-alb) get the same behaviour from the cdk-local bump. Tests: tests/unit/cli/{local-invoke,local-container-env,local-run-task}-dynamic-reference.test.ts, tests/unit/local/ecs-task-runner-dynamic-reference.test.ts, tests/unit/local/container-pool.test.ts; integ local-invoke-from-state.

Recently Implemented (2026-10-05):

• A masked UserData-style property that reads a nested stack's output is now redeployed when a clean output's value changes behind unchanged template text (issue #4565) -- src/deployment/masked-property-fingerprints.ts, src/deployment/nested-output-templates.ts (new), src/deployment/deploy-engine/{deploy-flow,resolver-context}.ts, src/deployment/deploy-engine.ts, src/cli/commands/diff-recursive.ts. The #4543 input fingerprint kept every Fn::GetAtt [Child, Outputs.X] (and ${Child.Outputs.X}) as written, so replacing the resource behind X compared *** with *** and the parent kept the old script under a green deploy. Each output is now classified from the cloud assembly's templates, never from child state, so the deploy and cdkd diff agree: a passed parameter takes the class the parent gives its value, an unpassed one its Default, and a NoEcho parameter, a {{resolve:...}} reference, a cross-stack read, an undeclared name, a custom resource's attribute or a condition over a secret keep the output as written, as does an unreadable or cyclic tree. Grandchild outputs are followed. A clean output is hashed with the value the parent recorded, through the existing secret checks. Values a parent passes from a sibling's clean output are classified clean too. A resource whose own definition reads a nested output is still treated as reading a secret. Tests: tests/unit/deployment/masked-nested-output-classes-4565.test.ts, tests/unit/deployment/deploy-engine-base64-secret-noop.test.ts, tests/unit/cli/diff-masked-input-fingerprint-4543.test.ts; integ Step 4e in tests/integration/nested-stack-3level/.
• cdkd rollback --revert-failed warns and exits 2 when a failed CREATE recorded a resource state no longer tracks (issue #4552) -- src/deployment/rollback-executor/plan.ts, src/deployment/rollback-executor/types.ts, src/deployment/rollback-executor.ts, src/cli/commands/rollback.ts. A failed CREATE whose recorded physical id differs from the current state record, with no cdkd import mark on its segment (an import by a cdkd older than #4547), was planned as failed CREATE left nothing to revert, logged at INFO, and the run exited 0, although the resource the op recorded may still exist, untracked. It now classifies as the new skip-failed-mismatch: the plan line names the recorded physical id (masked when secret-derived) as not the resource state tracks and needing manual attention, and the replay warns, records a ROLLBACK_RESOURCE_SKIPPED event, and counts a warning, so the run exits 2, like a completed op's skip-mismatch. Nothing is deleted and the state record is left as it is. The import-marked (displaced) path and the true no-op (a failed CREATE whose record is already gone, a failed DELETE) are unchanged. Tests: tests/unit/cli/rollback-imported-ops.test.ts, tests/unit/deployment/rollback-executor-skip-events.test.ts, tests/unit/deployment/rollback-executor.test.ts, tests/unit/deployment/rollback-executor-inline-policy-claims.test.ts.
• A masked UserData-style property is now redeployed when an input it reads changes behind unchanged template text: a parameter value, a Ref to a resource the deploy replaced, a flipped condition, in nested stacks too (issue #4543) -- src/deployment/masked-property-fingerprints.ts, src/deployment/deploy-engine/{update,create,deploy-flow,resolver-context,options}.ts, src/deployment/deploy-engine.ts, src/provisioning/providers/nested-stack-provider.ts, src/analyzer/diff-calculator.ts, src/cli/commands/diff-recursive.ts, src/types/state.ts. The #4451 fingerprint hashed template text only, so these compared *** with *** and the deploy kept the old script under a green run. A new field, maskedPropertyInputFingerprints, hashes the template value with each non-secret input resolved, bound to the unchanged maskedPropertyFingerprints text hash, which an older cdkd keeps reading. A NoEcho parameter, a {{resolve:...}} reference, what reads either, a custom resource's attribute, an input whose resolution read a secret, a nested stack's parent-passed value the parent built from any of these, and one the parent did not classify (a rollback replay, even when it equals the Default; the next classified deploy re-sends it once) stay in template form; a new NoEcho value is therefore still not sent through the mask. A record without the input field is re-baselined from today's inputs without sending. cdkd diff labels the row [masked input or expression changed] (was [template expression changed]). Tests: tests/unit/deployment/masked-input-{fingerprints,sources}-4543.test.ts, tests/unit/deployment/deploy-engine-base64-secret-noop.test.ts, tests/unit/cli/diff-masked-input-fingerprint-4543.test.ts; integ Phase 1b2d in tests/integration/secrets-dynamic-ref/ and Step 4d in tests/integration/nested-stack-3level/.
• A Scheduler Schedule created or imported from this version on, whose GroupName comes from a secret, can be updated in place and destroyed; a rotated secret can no longer make --replace or a rollback write a schedule or DB proxy target group into another environment (issue #4275) -- src/provisioning/providers/scheduler-schedule-provider.ts, src/provisioning/providers/rds-dbproxy-targetgroup-provider.ts. State keeps a secret-derived group as its {{resolve:...}} reference and the schedule's ARN embeds the group, so every update of such a schedule was refused and its destroy skipped it. cdkd now records each schedule's AWS creation date (attribute cdkd:CreationDate) and checks it, with the recorded target ARN and role, against the schedule the group the secret resolves to holds: an update or rollback revert goes ahead only on a match, and a destroy finds the schedule by them in any group. A secret rotated onto another schedule, or onto no schedule under the same reference, is refused without the --replace fallback; a re-pointed reference stays a group change. A record from before this version with a secret-derived group stays refused and skipped: delete the schedule by hand, drop its record with cdkd orphan, and deploy again. A DBProxyTargetGroup whose proxy name now addresses another target group (or none), on a deploy or a rollback revert, is refused the same way: under UpdateReplacePolicy: Retain the replacement only created, registering the targets on the proxy the rotated secret named. Tests: tests/unit/provisioning/{scheduler-schedule-provider,secret-reference-immutable-sites}.test.ts, tests/unit/deployment/deploy-engine-replace.test.ts; integ arm in tests/integration/secret-derived-immutable-names/.
• cdkd no longer prints a secret-derived Cloud Control identifier in a Cloud Control create's or delete's log lines, or in the error a create, update or delete throws (part of issue #3869) -- src/provisioning/cloud-control-provider.ts (IdScrubLog, installed per call so every line the call prints, its helpers' included, goes through it); unit tests in tests/unit/provisioning/cloud-control-provider-create-delete-id-masking.test.ts, and the secret-derived-immutable-names integration fixture now asserts its deploy and destroy logs. A Cloud Control identifier can carry a name taken from a secret (AWS::Logs::MetricFilter is <LogGroupName>|<FilterName>), and a pre-rotation or AWS-derived spelling of that name is one the deploy's masker cannot recognise. The update path already withheld it in its lines; now create() withholds the identifier Cloud Control returns (or a failed create's error names) when the desired properties hold a secret-derived value, delete() withholds it when the recorded properties hold a {{resolve: reference or ***, and the error leaving any of the three has the identifier and each | part replaced by *** in every message of its cause chain and in its physicalId field, AWS status text included; an abandoned wait's request token and resume command are kept whole. A CC delete's skipped and indeterminate-guard reasons are scrubbed too. The identifier the call returns is unchanged, and a withheld create's name-collision advice is dropped rather than printed. Residual: a delete handed resolved plaintext (an in-process rollback's) has no evidence to withhold on, a failed create whose error names no identifier cannot be scrubbed of it, and the engine-level registry, the engine's own lines, persisted events' physicalId field, import()'s two unreadable-model WARNs and other providers' lines stay open under #3869.
• cdkd destroy / cdkd state destroy no longer hand a resource record's torn properties map or missing physicalId to the provider's delete (issue #3211, destroy half) -- src/cli/commands/destroy-runner.ts, src/state/malformed-resources-bag.ts. A record whose properties is absent, null, a string, a list, a number or a boolean is now refused before the lock, naming each such resource and ending on a cdkd state show command; nothing is deleted or written for the stack. Before, the value reached provider.delete as it stood, where it decides the RDS final snapshot and whether an ECR repository is emptied first. A record whose physicalId is absent, empty, whitespace-only or not a string (other than a nested stack's, whose delete never reads it) is now skipped per resource with skipped (state record has no physical id), its record kept and state preserved. Before, the provider was called with that value, and a resulting *NotFound read as already deleted dropped the record of a resource still live in AWS. The deploy half of the issue stays open. Tests: tests/unit/cli/destroy-runner-malformed-fields.test.ts, tests/unit/cli/destroy-runner-malformed-entries.test.ts, tests/unit/state/malformed-resources-bag.test.ts.
• cdkd scrub's "No plaintext secrets found" lines now say what they cover, and a secret set out of band is documented as recorded by design (issue #2868) -- src/cli/commands/scrub.ts, docs/{import,state-management,cli-scrub,cli-drift,getting-started}.md, SECURITY.md. The drift baseline (observedProperties) records what AWS returns. That includes a value the template never references, such as a password an operator set in the console over a placeholder literal, or any key of a Cloud Control model. Secret redaction works only where the template spells a {{resolve:...}} reference, so such a value is stored as AWS returned it. That is by design, and for a property the template sets, CloudFormation's drift detection likewise reports the actual value. Scrub learns a secret's value only by resolving a reference, so it cannot see such a value. Its per-stack and summary no-finding lines used to read as a clean bill for the whole record. They now end with (scrub checks only values the template names through a {{resolve:...}} reference), and the --fail help text says the same. docs/import.md documents the population, why state.json is sensitive by construction, and how to remove such a value: rotate it through a reference and deploy, or edit the record by hand, then run cdkd scrub <stack> --purge-history. Tests: tests/unit/cli/commands/scrub-all-refusal-boundary.test.ts, tests/unit/cli/commands/scrub-nested-child.test.ts.
• cdkd events prune --all and cdkd destroy --purge-events now purge every earlier version under the stack's deployments/ prefix, including streams an earlier delete left behind a delete marker (issue #2624, site 3 residue) -- src/state/s3-noncurrent-version-purge.ts (purgeNoncurrentVersionsUnderPrefix), src/state/s3-state-backend.ts, src/state/deployment-events-store.ts, src/cli/commands/events.ts, src/cli/commands/destroy.ts, docs/deployment-events.md, docs/cli-destroy.md, docs/cli-events.md, docs/ci-per-pr.md, docs/state-management.md and the plugin skill doc (plugin 0.7.9). Before, the purge acted only on the keys a run deleted, found by an ordinary listing, so a stream deleted by an earlier release or by a purge that warned stayed readable with a VersionId and the output was scoped to "the deleted keys". Because --all empties the whole directory, it now walks every version under the exact <state-prefix>/<stack>/<region>/deployments/ prefix, keeping each key's current version, and runs even when nothing current is listed. Region discovery reads current keys only, so for a region where none of the stack's history is current any more, cdkd events prune needs --stack-region, and its "No deployment-event history found" error now says so. --stack-region is now lower-cased like every other command's, and when nothing current is left the summary claims a purge only if the sweep removed an earlier version with content (not just a delete marker), says none were found in that region if it removed nothing, and says the versions could not be purged if it failed. The trailing / keeps a stack whose name extends this one's out of the sweep, and a prefix without one is refused. --keep / --older-than and the writer's self-bounding prune are unchanged and still purge only the keys they delete. Without s3:ListBucketVersions / s3:DeleteObjectVersion it still succeeds and warns.
• cdkd scrub purges the earlier versions of every state.json and exports index it rewrites, and --purge-history purges every examined record's (issue #2624) -- src/cli/commands/scrub.ts, docs/cli-scrub.md. On a versioned state bucket, scrub's PutObject used to leave the pre-scrub body readable by VersionId. A real run now purges the noncurrent versions of each state.json it rewrites, including a nested child's record, a parent row repaired for a child output, and a pre-region-layout record, which is now migrated (it used to fail the rewrite) with its old key's history purged (a surviving or unverifiable old key fails the stack). It also purges {state-prefix}/_index/{region}/exports.json once per region whose entries it rewrote. The purge reuses the state backend's fail-soft purgeNoncurrentVersions (missing version grants or a replicated bucket only warn, above the summary). The purge also runs after an ambiguous or SDK-retried write failure, never after a definite refusal on the first attempt. The Done: scrubbed ... line says the earlier versions were purged "unless a warning above says otherwise". A record scrub did not rewrite keeps its history unless the new --purge-history flag is passed, which purges every examined record's earlier versions (each target and nested stack with a readable record, never a refused one) and is refused with --dry-run, which purges nothing. A plain cdkd deploy never purges, because those versions are the state-recovery history; the docs now say its implicit scrub leaves earlier versions that may hold the plaintext, removed by cdkd scrub --purge-history. Tests: tests/unit/cli/commands/scrub-purge-state-versions.test.ts, tests/unit/cli/commands/scrub-export-index.test.ts, tests/unit/cli/commands/scrub-all-refusal-boundary.test.ts, tests/unit/cli/commands/scrub-nested-child.test.ts.
• cdkd deploy and rollbacks persist a pre-flight safety guard that could not reach a verdict (issue #2422) -- src/deployment/delete-guard-scope.ts (new), src/deployment/deploy-engine/provision.ts, src/deployment/deploy-engine/{delete,replacement,update-in-place,update-replace}.ts, src/deployment/rollback-executor/messages.ts and the rollback delete arms, docs/deployment-events.md. A delete whose guard could not answer (for example an AWS::S3::Bucket routed through Cloud Control whose s3:GetBucketLocation is denied) recorded a RESOURCE_GUARD_INDETERMINATE event only under cdkd destroy / cdkd state destroy; the same delete on the deploy path (template removal, replacement, --recreate-via-*, replaced-resource cleanup, update-not-supported fallback) or in a rollback left only the live warning. Both now record the same event, with the destroy runner's payload and operation: DELETE even when the delete is a step of an UPDATE. The deploy engine emits it from one place per resource, before the row's outcome event, including when a later step of the same row fails; the rollback executor emits it from the helper every delete arm already calls, before a 'skipped' outcome is turned into a failure. The physical id and reason are masked with the resource's own secrets. No summary count is added and no result changes. Tests: tests/unit/deployment/deploy-engine-delete-guard-events.test.ts, tests/unit/deployment/rollback-executor-delete-guard-events.test.ts.
• cdkd destroy now reports a custom resource whose backing Lambda is gone as skipped, keeping its state record, instead of treating it as already deleted (issue #2115) -- src/provisioning/providers/custom-resource-provider.ts, src/provisioning/region-check.ts (DeleteContext.stackDestroy), src/cli/commands/{destroy,state,destroy-runner}.ts, src/provisioning/providers/nested-stack-provider.ts (a nested child inherits the flag only from a stack destroy). The issue-#804 GetFunction pre-check used to answer ResourceNotFoundException by dropping the record and letting cdkd destroy exit 0. Its usual caller was the second destroy after a handler refused its Delete (#2054): the first run kept the record but deleted the backing Lambda, and the second dropped the record over a resource that was still live. On a stack destroy (cdkd destroy / cdkd state destroy) the pre-check now returns a skip (backing Lambda function is gone — Delete handler not invoked), so the record is kept and the destroy exits 2. This matches CloudFormation, where a custom resource whose delete cannot be confirmed leaves the stack DELETE_FAILED until you retry with RetainResources. Compatibility: a shared provider stack destroyed before the stacks that use it now makes their destroy exit 2. Redeploy a function at that ARN and re-run, or confirm what the handler manages is gone and drop the records with cdkd state orphan <stack> --stack-region <region>. A cdkd deploy delete (template removal, replacement, rollback) keeps the warn-and-drop, as CloudFormation ignores delete failures in an update's cleanup phase. The pre-check is still fail-fast: one GetFunction call, no 10-minute waiter. Docs: docs/cli-destroy.md, docs/troubleshooting.md. Tests: tests/unit/provisioning/custom-resource-delete-failed-response.test.ts and its CR siblings; integ phase 4 of tests/integration/custom-resource-provider/.
• An EC2 VPC, internet gateway or Elastic IP create that hits a 5xx now reports candidate orphans instead of duplicating silently, and a subnet or security group create surfaces its replayed collision as possibly its own (issue #2080, Plan B: CreateVpc, CreateSubnet, CreateInternetGateway, AllocateAddress, CreateSecurityGroup; the SDK-5xx half of #3978 layer (b) for these creates) -- src/provisioning/providers/ec2-provider.ts. None of the five carries an idempotency token, so a 5xx whose request had succeeded left a second VPC, gateway or address (an unassociated Elastic IP keeps billing) with no state record, unreported when the AWS SDK replayed it inside one call. All five now refuse the SDK's 5xx retry. After an ambiguous CreateVpc, CreateSubnet, CreateInternetGateway or AllocateAddress, cdkd's retry first lists untagged candidates the failed attempt may have made -- VPCs with the same CIDR, subnets with the same CIDR in the same VPC, detached internet gateways, unassociated addresses of the same domain -- and warns with a describe-* read command and no delete command, since EC2 reports no creation time for them. Nothing is adopted or deleted; a throttle or 4xx triggers no lookup, and a failed lookup warns and lets the create proceed. A subnet CIDR and a security group name cannot repeat in a VPC, so those replays fail with InvalidSubnet.Conflict / InvalidGroup.Duplicate rather than duplicating; the group's collision is no longer credited to another holder. A reset or timeout after the send is still retried inside the SDK. Tests: tests/unit/provisioning/ec2-create-retry-2080.test.ts.
• A PUBLIC {{resolve:ssm:...}} reference inside a longer value of a LEGACY state record now keeps the value AWS holds in the drift baseline written by cdkd state refresh-observed and cdkd drift --accept / --revert (issue #2036) -- src/deployment/public-ssm-proof.ts (new), src/deployment/secret-redaction/{mask-only,redact-path,readback-certification}.ts, src/deployment/intrinsic-resolver/dynamic-refs.ts, src/cli/commands/state.ts. Only a legacy record carries such a reference in its properties: one imported before the #2944 refusal marker, written by an older binary, or edited by hand. A current deploy stores it resolved, and a current import refuses that record's baseline. With no secrets map these commands could not tell a public String parameter from a SecureString, so the leaf always took its expression and the baseline disagreed with AWS. A leaf now keeps the readback only when EVERY reference in it is a plain ssm one that this record's own pass PROVED public, AND the readback is exactly the source with each proven CURRENT value in place, so a type read today never vouches for a value resolved earlier or in another region. The proof is filed per record, never for the whole process (the cross-region disclosure PR #2415 withdrew). cdkd drift gets it from its own resolution of the record. cdkd state refresh-observed asks ssm:GetParameter with WithDecryption: false in the stack's region, and gives a nested child whose ancestors' reads cannot be established no proof. Any other answer, an error or a missing permission keeps the expression, as before. Tests: tests/unit/deployment/{public-ssm-proof,secret-redaction-public-ssm-proof}.test.ts, tests/unit/cli/{state-refresh-observed,drift-secret-redaction}.test.ts; integ Phases 1f3 and 1f4 in tests/integration/secrets-dynamic-ref/.
• cdkd rollback --revert-failed now deletes a resource whose CREATE succeeded at AWS and then failed (Kinesis so far) (issue #1710) -- src/provisioning/auxiliary-failure.ts, src/deployment/deploy-engine/execute.ts, src/deployment/{rollback-executor,retry,prior-attempt-scope}.ts, src/deployment/rollback-executor/{plan,types}.ts, src/provisioning/providers/kinesis-provider.ts, src/cli/commands/rollback.ts, src/types/rollback-journal.ts. A provider that failed after its create call returned (a Kinesis stream whose retention or encryption follow-up AWS rejected) left the resource in AWS with no state record, and the failed op was journaled with no physical id, so --revert-failed skipped it and a retry collided with the leftover name. A provider now marks the error once its create call has returned (markCreatedBeforeFailure); the deploy journals that id with physicalIdRecoveredFromError and the template's DeletionPolicy, and --revert-failed deletes, retains or snapshots it accordingly, only while nothing later owns it: no state resource or rollback-orphan record holds its ids, no newer entry of its type names its id or completed a CREATE, and no later removal superseded it; otherwise it is skipped, warned where it may be untracked. ProvisioningError.physicalId is never trusted: providers also set it on a collision with another owner's resource. A retry carries the mark forward. Kinesis is the first provider to mark; it also now refuses a non-numeric RetentionPeriodHours or a KMS StreamEncryption without a KeyId before CreateStream, and sends a numeric-string retention as a number; its update refuses a non-numeric retention too. Tests: tests/unit/deployment/{failed-create-orphan,deploy-engine-rollback-journal,retry-replayed-create-collision-3972}.test.ts, tests/unit/provisioning/kinesis-provider-metrics-and-record-size.test.ts; integ Phase O in tests/integration/rollback-command/.

Recently Implemented (2026-10-04):

• The startup compile cache no longer grows with every cdkd upgrade (issue #4544) -- src/cli/compile-cache.ts. Node never removes a compile-cache entry, so each release cdkd ran added its newly compiled chunks to ~/.cache/cdkd/compile-cache (or $XDG_CACHE_HOME/cdkd/compile-cache) and kept the old ones forever. The cache now lives in a per-version subdirectory, and a run deletes every other entry under the cache directory (older versions' subdirectories and the version-less layout 0.294.8 wrote) synchronously, so a command that exits at once still finishes the cleanup. Steady-state startup is unchanged; the delete costs time only on the first run after an upgrade.
• cdkd drift <Parent> checks the parent's nested stacks too, so a resource deleted or changed inside one exits 1 (issue #4533) -- src/cli/commands/drift.ts, docs/cli-drift.md, docs/design/459-nested-stacks.md. A nested stack's resources are recorded as their own <parent>~<child> stack, which drift compared only when named exactly or under --all, so cdkd drift Parent printed the parent's AWS::CloudFormation::Stack row as drift unknown and exited 0 over a deleted child resource. Naming a stack (or the single-stack auto-select) now also checks every nested stack below it in the same region, after the parent, each in its own block and each record once, as cdkd diff and cdkd destroy act on nested stacks. The auto-select counts a parent with its nested stacks as one stack. The nested row is now skipped when its record is checked, and deleted (exit 1, printed as RECORD MISSING naming the record, nestedStackRecordMissing: true in --json) when that record is gone from state; a parent holding only nested stacks prints no drift detected here rather than NOTHING was compared; --accept / --revert refuse it by name and act on each nested stack's drifted resources under that record's lock. --json change: the row moves from notSupported to skipped, or to deleted. Tests: tests/unit/cli/drift.test.ts; integ arm in tests/integration/nested-stack/verify.sh.
• A cross-stack secret read embedded beside two or more parts the template cannot state, or under an Fn::If, now persists its OWN {{resolve:...}} expression, not a sibling's (issue #4527, the residual of #2298) -- src/deployment/intrinsic-function-resolver.ts, src/deployment/intrinsic-resolver/sub.ts, src/deployment/intrinsic-resolver/string-functions.ts, src/deployment/secret-redaction/pairs.ts, src/deployment/secret-redaction/placeholder-positions.ts. A leaf such as Fn::Sub 'jdbc:mysql://${AWS::Region}.${AWS::AccountId}.host/?pw=${Child.Outputs.Pw}', the same through Fn::Join, or an Fn::If selecting such a leaf, was still redacted by the plaintext-keyed value scan: the #2298 fix aligned the template against the resolved string and allowed at most one part of unknown text. When another leaf of the same resource resolved to the same plaintext (one secret at two version-stage spellings), the embedded leaf was persisted with the OTHER reference, which a rollback or cdkd drift --revert would re-resolve and push to AWS as the wrong secret version. No plaintext was exposed. The resolver now records where each Fn::ImportValue / Fn::GetStackOutput / Fn::GetAtt read (and each ${Res.Attr} placeholder) landed on an Fn::Sub / Fn::Join output, keyed as the association store keys that read, and the persist path answers each such span from that read's own association, as it already did for a parameter Ref. A resource whose record holds the sibling's expression can take one UPDATE on the first deploy after upgrading (a replacement if the property is create-only), even though the value sent is unchanged. Tests: tests/unit/deployment/secret-redaction-cross-stack-embedded.test.ts; integ arm MultiUnknownSecretPair in tests/integration/nested-stack-secret/.
• cdkd rollback no longer deletes a resource cdkd import adopted after the failed deploy (issue #4523) -- src/cli/commands/import.ts, src/state/s3-state-backend.ts, src/types/rollback-journal.ts, src/cli/commands/rollback.ts, src/deployment/nested-child-journal.ts. The import did not touch the rollback journal. If a kept journal segment held a completed CREATE of an explicitly named resource, and the user then re-created that name by hand and imported it under the same logical id, the replay saw a physical id equal to the imported record's and deleted the resource the user had just adopted. Before it writes state, the import now records each adopted resource (logical id, physical id and type) in a new additive importedResources field on every segment that holds an operation of that logical id, and marks the id superseded on the newest segment. cdkd rollback and the nested-child replay then run none of those segments' operations for the id, failed ones included. An operation that recorded the adopted resource is listed as adopted by cdkd import after this deploy. One that recorded another resource under the id (or a replacement whose old resource it may have kept, which is then the id named) is listed with its physical id as not reverted, records a ROLLBACK_RESOURCE_SKIPPED event, warns and makes the rollback exit 2. Completed operations of an id passed to --orphan are not covered. Segments that later deploys add carry no mark and replay as before. The import now refuses, and writes no state, when it cannot read or write the journal. Tests: tests/unit/cli/rollback-imported-ops.test.ts, tests/unit/cli/commands/rollback.test.ts, tests/unit/state/s3-state-backend.test.ts, tests/unit/cli/import.test.ts, tests/unit/deployment/nested-child-journal.test.ts, tests/unit/types/rollback-journal.test.ts; integ arm R in tests/integration/import-retain-destroy/.
• Installing cdkd no longer pulls in aws-cdk-lib, and every command starts faster (issue #4521) -- package.json. cdk-local moves to ^0.149.8, which makes its aws-cdk-lib / constructs peers optional and loads @aws-cdk/toolkit-lib on first synth instead of at module load. A clean install of the packed cdkd shrinks from 453 MB to 254 MB of node_modules, and cdkd --help takes 510 ms of CPU instead of 659 ms (Node 24, median of 9, compile cache off). A CDK app still resolves aws-cdk-lib from its own project, as before.
• Every command starts about a quarter faster from the second run: cdkd enables Node's compile cache (issue #4521) -- src/cli/index.ts, src/cli/compile-cache.ts. The entry calls module.enableCompileCache() before importing the command tree, so V8 reuses compiled code for cdkd's chunks and the externalised @aws-sdk/* packages instead of compiling them on every run (cdkd --help: ~890 ms to ~680 ms wall-clock with a warm cache). The cache lives in the user's own cache directory ($XDG_CACHE_HOME/cdkd/compile-cache or ~/.cache/cdkd/compile-cache), never Node's default under the shared OS temp dir, where another local user could plant entries Node validates only by checksum; with no home directory it stays off; NODE_DISABLE_COMPILE_CACHE=1 turns it off and NODE_COMPILE_CACHE moves it (CLI Reference, "Startup compile cache"). The --version fast path is unchanged. Tests: tests/unit/cli/version.test.ts, tests/unit/cli/compile-cache.test.ts.
• Every command starts ~70 ms of CPU faster: graphql and adm-zip load on first use (issue #4521) -- src/provisioning/providers/appsync-provider.ts, src/provisioning/providers/codecommit-repository-provider.ts. registerAllProviders() evaluates every provider module on every command, and both providers imported a dependency at module scope that only one rarely taken path needs: graphql-js for the AppSync GraphQLSchema drift read, adm-zip for a CodeCommit repository seeded from Code.S3. Both are now imported where they are used; a failure to load graphql is no longer reported as an unparseable SDL. Tests: tests/unit/provisioning/lazy-optional-deps.test.ts.
• Commands that never touch a provider start ~270 ms of CPU faster: the SDK provider classes load when a command registers them (issue #4521) -- src/provisioning/register-providers.ts, src/provisioning/provider-classes.ts, src/cli/commands/{deploy,destroy,destroy-runner,diff,drift,import,orphan,rollback,state}.ts, src/provisioning/providers/wafv2-arn.ts, src/provisioning/providers/wafv2-provider.ts, src/deployment/intrinsic-resolver/ref-values.ts, scripts/diagnose-schema-refresh.mjs. Every command module that registers providers is reached statically from the command tree, and each provider module evaluates its @aws-sdk/client-* package, so cdkd --help, synth and list evaluated all of them. The classes now load through loadProviderClasses() (one dynamic import, once per process), awaited at the start of each command function so registration stays synchronous inside the per-stack AWS client scope; every type is still registered. A helper the intrinsic resolver imported from the WAFv2 provider moved to a leaf module. cdkd --help: ~1140 ms to ~870 ms CPU. Tests: tests/unit/provisioning/lazy-provider-classes.test.ts.
• The published package shrinks from 8.2 MB to 1.8 MB (29.8 MB to 8.5 MB unpacked) (issue #4521) -- vite.config.ts. The source maps no longer embed a copy of every src/*.ts file (sourcemapExcludeSources), and JSDoc blocks are dropped from the emitted JS. The emitted code is token-for-token unchanged; line numbers in dist/ shift where JSDoc was removed, while the maps keep their mappings, so node --enable-source-maps still reports the same src/*.ts lines.
• A --revert-failed rollback that re-creates an AWS::EC2::SecurityGroupIngress rule no longer keeps the revoked rule's sgr- id (issue #4484) -- src/provisioning/providers/ec2-provider.ts. When the replay re-authorized a rule the refused update had already revoked, it answered an in-place update, so a response naming no single rule id left the revoked id under attributes.Id for cdkd export and Fn::GetAtt <rule>.Id to read. It now answers a replacement, so only an id found now is recorded: the one the response names, else the one rule matching it on the group, else none. A live rule the replay adopts is recorded the same way, since an earlier send of the same replay may have created it. Tests: tests/unit/provisioning/ec2-sg-ingress-duplicate-ownership.test.ts.
• cdkd drift --revert records the physical id and attributes the revert's update returned (issue #4476) -- src/cli/commands/drift.ts, docs/cli-drift.md. The revert persisted only the narrowed effectiveProperties delta, so a provider that re-creates on update left the record naming what it removed: reverting a drifted AWS::EC2::SecurityGroupIngress revokes and re-authorizes the rule under a new sgr- id, while the record kept the revoked one for cdkd export and a later Fn::GetAtt <rule>.Id. The record now takes the returned identity exactly as the rollback replay does (go-to-k/cdkd#4434): attributes replaced wholesale when the update replaced the resource, merged key-wise when it updated in place, untouched when none were returned, and the physical id followed on a replacement. A NoEcho attribute is masked before the write, and the attributes are scrubbed of the revert's resolved secrets; a recorded value the scrub would mask only because it equals a live value the revert masks elsewhere keeps its recorded form. Tests: tests/unit/cli/drift.test.ts; integ arm in tests/integration/drift-revert-vpc/verify.sh.
• An edit around a secret reference inside one Fn::Base64 (the EC2 UserData shape) is now deployed, and cdkd diff reports it (issue #4451) -- src/deployment/masked-property-fingerprints.ts, src/deployment/deploy-engine/update.ts, src/analyzer/diff-calculator.ts, src/deployment/deploy-engine.ts, src/deployment/deploy-engine/record-shape.ts, src/deployment/deploy-engine/deploy-flow.ts, src/types/state.ts. State persists such a property as ***, and the edited script resolved to *** too, so the diff and the deploy's no-change skip compared equal: a change to the script around {{resolve:...}}, or a retarget of the reference, was skipped under a green deploy and the resource kept the old script. Each record now carries maskedPropertyFingerprints (optional, no schema bump): per property it holds as ***, a sha256 over the UNRESOLVED template value, never over a resolved one. A moved fingerprint is a change; a rotated secret behind an unchanged template is not, matching CloudFormation. A record written by an older cdkd has no fingerprint and is compared as before; the first deploy under this version records one from the template it deploys, so an edit made in that same deploy is still not sent, and every later one is; for a nested child, which is deployed only when its parent row changed, that first deploy is likely to carry such an edit. cdkd diff labels the row [template expression changed]. An input that changes without the template text (a parameter value, a replaced resource) is still not seen (#4543). Tests: tests/unit/deployment/deploy-engine-base64-secret-noop.test.ts, tests/unit/deployment/masked-property-fingerprints.test.ts, tests/unit/analyzer/diff-calculator-masked-fingerprint-4451.test.ts; integ Phase 1b2c in tests/integration/secrets-dynamic-ref/.
• cdkd drift reads an Elastic IP back, so one released outside cdkd reports deleted and exits 1 (issue #4447) -- src/provisioning/providers/ec2-provider.ts, src/analyzer/drift-cc-api-deny-list.ts, docs/cli-drift.md. AWS::EC2::EIP had no arm in EC2Provider.readCurrentState, so it read as drift unknown (exit 0) whether it existed or not. It is now read with DescribeAddresses: InvalidAllocationID.NotFound / InvalidAddress.NotFound report the address deleted, and Domain, a declared InstanceId, NetworkBorderGroup, PublicIpv4Pool and Tags are read back, so a change to one the baseline holds reports as drift. A deploy now also captures an EIP's drift baseline. A nested AWS::CloudFormation::Stack row still reads as drift unknown: no CloudFormation stack exists to read, and its resources are compared as the <parent>~<child> stack; cdkd drift <parent> not including that stack is #4533. A standalone AWS::EC2::SecurityGroupIngress whose Description was edited out of band, or a same-account SG-to-SG rule (the template omits the peer owner AWS reports), read as drift unknown because the reader matched the whole rule; it now falls back to the rule's identity when the record's own rule id still names that rule and no other record declares it, so the edit reports as drift and drift --revert can restore it.
• A rollback that removes an inline policy name another record still holds on that role, group or user now puts that record's document back (issue #4408) -- src/deployment/inline-policy-claims.ts, src/deployment/rollback-executor.ts, src/deployment/rollback-executor/replay-inline-policy-restore.ts. When a deploy dropped an AWS::IAM::Policy and created a new one under the same name on the same principal, then failed before its DELETE phase, the rollback deleted the new policy and the name went with it: the old policy's record still listed it, the principal no longer held it, and the next deploy showed no diff. The same happened when a swap's reversal deleted a copy whose name a sibling still recorded (a partial swap rolled back without --revert-failed), and when a re-adopted retained policy's name had been deleted by a sibling's reversal. Every removal the rollback lets proceed is now noted, and at the end of each completed-op replay, a removed name that another record holds on that principal is put back with that record's recorded document (Put{Role,Group,User}Policy), logged as Rollback: put back the inline policy <logicalId> records on its <role|group|user> and recorded as a ROLLBACK_RESOURCE_SUCCEEDED event for that logical id. Nothing is put back, and the rollback warns, when the records holding it disagree on the document, the recorded document is absent or redacted, or the holder's own rollback has not completed (its record may still be the failed deploy's); a failed put warns the same way. In each case the principal lacks the policy until the resource is next updated or cdkd drift <stack> --revert. Tests: tests/unit/deployment/rollback-executor-inline-policy-claims.test.ts; integ arm Phase 2c-rollback in tests/integration/iam-role-policies-drift-clean/ now includes the delete-beside-create pair.
• cdkd diff no longer reports a phantom change when two regions or accounts share an SSM parameter name with different types (issue #4105) -- src/deployment/intrinsic-resolver/{dynamic-refs,cross-stack}.ts, src/deployment/secret-redaction/mask-only.ts. cdkd remembered that a {{resolve:ssm:...}} reference pointed at a SecureString keyed by the token text alone. So once one stack's region answered SecureString, another stack whose region holds a plain String under the same name skipped its lookup on the comparison path: it compared the unresolved token against the resolved value in its state, and showed a change on every diff and deploy no-op check. A stack's comparison pass now reads only the verdict its own region and credentials pinned. The process-wide set the redaction path reads is unchanged. The dynamic-ref-cross-region integ gains a reversed mixed-type arm (phase 3f).
• A value cut at a display cap now names its withheld tail, so two long values that differ only past the cut in characters cdkd shows no longer print alike (issue #4002) -- src/utils/display-safe.ts, src/cli/commands/export.ts. An identifier cdkd cuts at its cap (255 characters, or 1152 for a stack name) was followed by [cut: N more characters withheld], so two planted values sharing the kept prefix and the length rendered byte-identically. The marker now reads [cut: N more characters withheld, tail sha256:<32 hex>] for an identifier (a stack name, region, logical id, or a state-record value in cdkd export's plan), the digest taken over the withheld characters only, after any masking; for a stack name, region or logical id also after the same ASCII sanitizing the kept part gets, so there a tail differing only in non-ASCII characters still renders alike, as it does under the cap. Free-form AWS error text keeps the bare marker. cutMarker is now the one spelling of the marker. Tests: tests/unit/utils/display-safe.test.ts and the suites that pin the marker.
• A Glue table replacement that keeps the table's address can now be performed with cdkd deploy --replace, and --replace on a table whose new address another table holds is refused with nothing deleted (issue #3932) -- src/provisioning/providers/glue-provider.ts, src/deployment/replacement-name-holder/name-keys.ts, src/deployment/replacement-name-holder/holder.ts. The Glue provider reworded every CreateTable AlreadyExistsException so the engine never treated it as a name collision (#3750). That kept --replace from deleting the old table when a third party held a renamed table's address, but it also hid the collision when the replacement kept the address (a change to the top-level Name alone): the create-first attempt then collides with the old table itself, and no flag could perform the replacement. The provider now relays the error, and the engine's name-holder check decides: --replace deletes the old table first only when it holds the address the create sent, reading the name as the provider does (TableInput.Name, else Name) and placing it by DatabaseName and, newly, CatalogId. Table names compare with ASCII case folded, as Glue stores them, and a table's <database>|<table> id never proves the name it holds (either name may contain |). A rename, another database or another Data Catalog is refused before anything is deleted, and so is a CatalogId given on only one side or a recorded name cdkd cannot read. Tests: tests/unit/deployment/deploy-engine-glue-table-collision-3932.test.ts, tests/unit/deployment/replacement-name-holder.test.ts, tests/unit/provisioning/providers/glue-provider.test.ts; integ phase 2f (and step 2b) in tests/integration/glue-update-hardening/.
• cdkd no longer prints a secret-derived Cloud Control identifier in a Cloud Control update's log lines (part of issue #3869) -- src/provisioning/cloud-control-provider.ts (updateIdLogSink, threaded through the sparse read-back merge, the GetResource failure line, the attribute-enrichment lines, the model-parse failure lines and the account-lookup WARN of accountInfoForSynthesizedArn) and a new unit file. A Cloud Control identifier can carry a name taken from a secret (AWS::Logs::MetricFilter is <LogGroupName>|<FilterName>); after a rotation under an unchanged reference that name is the pre-rotation value, which the masker never resolved, so it printed in plaintext on cdkd deploy, its rollback revert, and cdkd drift --revert. When the desired or previous properties hold a secret-derived leaf or key (a {{resolve: reference, ***, or a value the masker recognises), every occurrence of the identifier and of each | part, raw or as the masker rewrote it, now prints as *** in those lines, and the model-parse detail line, whose echo of the model is truncated, is dropped; every line goes through the masker first. An identifier whose name comes from ANOTHER resource's secret-derived value (neither bag holds the secret) still prints until the engine-level registry lands. Residual: that registry, the engine lines and other providers' lines naming a physical id, and this provider's create() / delete() lines and thrown update errors stay open under #3869.
• A rollback op cdkd skips is now recorded, and the automatic rollback keeps its journal over one; a create refused onto another owner's name is no longer journaled (issues #3338, #4356) -- src/deployment/rollback-executor.ts, src/deployment/rollback-executor/{messages,names,types,replay-revert,replay-reverse-replacement,replay-orphan-delete}.ts, src/deployment/deploy-engine/{execute,rollback,create}.ts, src/types/deployment-events.ts. A rollback op the replay declined (a deleted resource it cannot re-create, a missing record or properties baseline, a physical id a later attempt changed, a failed op with nothing to revert to) printed one warning and recorded no event, and the automatic rollback then dropped the rollback journal, so cdkd events showed a finished rollback naming nothing left unreverted. Each such op now records a ROLLBACK_RESOURCE_SKIPPED event with its reason, and an automatic rollback that skipped any keeps the journal and says so. A reverse-replacement whose re-create adopted the live new resource now gives its ROLLBACK_RESOURCE_SUCCEEDED event a reason. A create refused with NAMED_CREATE_COLLISION (or any create refused before anything was applied that recorded no physical id) is no longer journaled as a failed op, so cdkd rollback --revert-failed no longer advises deleting the resource holding that name. An automatic rollback whose own journal segment could not be written no longer removes an older attempt's segment. Tests: tests/unit/deployment/rollback-executor-skip-events.test.ts, deploy-engine-rollback-journal.test.ts, deploy-engine-create-name-takeover-4180.test.ts; integ arms in tests/integration/{rollback-command,s3-lifecycle,sg-circular-dependency}/verify.sh.
• --from-cfn-stack on cdkd local invoke / start-api / run-task / invoke-agentcore now reads the deployed stack with your own credentials instead of the --role-arn role, and the four engine start-* commands warn at startup when the role reaches the container (issue #3240) -- src/cli/commands/local-state-source.ts, src/cli/commands/local-start-service.ts, src/cli/commands/local-start-alb.ts, src/cli/commands/local-start-cloudfront.ts, src/cli/commands/local-start-agentcore.ts. With --role-arn and no profile, the --from-cfn-stack reader resolved as the role, so a SecureString parameter the caller could not read was decrypted and baked into the container's environment, and the deployed function's environment was read the same way. cdkd now builds that reader's CloudFormation / Lambda / SSM / AgentCore clients on the caller's identity, matching what --profile already gave; a cross-account stack the caller cannot read now falls back with the reader's own warning. If a future cdk-local release changes the members cdkd reviewed, the command refuses under a role with no profile rather than read as it. start-service / start-alb / start-cloudfront / start-agentcore run inside the local emulation engine, which accepts no caller credentials yet (go-to-k/cdk-local#783); they now print a warning naming what reaches the role (container credentials, ECS task secrets, ${AWS::AccountId}, --from-cfn-stack, the STS call behind --assume-role) when --role-arn or CDKD_ROLE_ARN is set without the --profile flag. Tests: tests/unit/cli/local-state-source-caller-identity.test.ts.
• cdkd deploy no longer reports success for a create-only property it never wrote once --prefer-sdk-route is removed (issue #2790) -- src/provisioning/property-coverage.ts, src/types/state.ts, src/analyzer/diff-calculator.ts, src/cli/commands/diff-recursive.ts, src/deployment/deploy-engine/update.ts, src/provisioning/provider-registry.ts. A create-only silent drop accepted with --prefer-sdk-route (or --allow-unsupported-properties) stays in the state record, so the deploy that dropped the flag compared the same value on both sides, called the resource unchanged, and the property never reached AWS. The record now names such a key in a new optional acceptedCreateOnlyDrops field (no state schema bump), and the comparison keeps a named key only while the deploy still accepts the drop; a key the record does not name (an imported resource, or a record an older cdkd wrote, including one created with the flag) keeps the previous behaviour, where --recreate-via-cc-api applies it. Without it the change is a replacement, and the deploy refuses it (CREATE_ONLY_DROP_NEEDS_REPLACEMENT) before touching that resource, naming the property, --recreate-via-cc-api <LogicalId> or --replace to replace the resource and apply it, and the --prefer-sdk-route entries that keep dropping it. A template that removes such a recorded key no longer forces a replacement. cdkd diff previews the flag-less deploy, so it shows the replacement and warns that the deploy refuses it, without changing its exit code. Tests: tests/unit/provisioning/property-coverage.runtime.test.ts, tests/unit/analyzer/diff-calculator-unwritten-create-only.test.ts, tests/unit/deployment/deploy-engine-unwritten-create-only.test.ts; integ arm (phases 7-10) in tests/integration/sdk-to-cc-autoroute/verify.sh.
• cdkd destroy --purge-events and cdkd events prune now purge the earlier versions of the deployment-event objects they delete (issue #2624, site 3) -- src/state/deployment-events-store.ts (deleteAndPurgeEventObjects, used by all four deletes under deployments/), src/cli/commands/events.ts, src/cli/commands/destroy.ts, docs/deployment-events.md, docs/cli-destroy.md, docs/cli-events.md, docs/ci-per-pr.md and docs/state-management.md. Before, every delete there sent DeleteObjects with no VersionId. On the versioned state bucket that only wrote delete markers, and because each run's JSONL is re-PUT in full on every flush, one readable version per flush survived. The output said so instead of claiming removal. Each delete now also runs the shared fail-soft purgeNoncurrentVersions over the deleted keys, in a finally. The writer's self-bounding prune is included, because a stream it drops is no longer listed and a later --all could not reach it, so a deploy past 20 runs can print the purge's IAM or replication warning too. Without s3:ListBucketVersions / s3:DeleteObjectVersion the command still succeeds, and a warning prints before the Pruned / Purged line, which now says "unless a warning above says otherwise". On an unversioned bucket nothing extra is deleted. Not reached: streams deleted before a purge ran on them (an earlier release, or a purge that warned), the earlier versions of an index.json that a partial prune rewrites (run metadata only), and a replica.
• A cross-stack secret read EMBEDDED in a longer string now persists its OWN {{resolve:...}} expression, not a sibling's (issue #2298) -- src/deployment/secret-redaction/placeholder-positions.ts. A leaf such as Fn::Sub 'jdbc:...password=${Child.Outputs.Pw}', or an Fn::Join / bound Fn::Sub variable over an Fn::ImportValue / Fn::GetStackOutput / nested-stack Fn::GetAtt, was redacted by the plaintext-keyed value scan. When another leaf of the same resource resolved to the same plaintext (one secret at two version-stage spellings), the embedded leaf was persisted with the OTHER reference, which a rollback or cdkd drift --revert would re-resolve and push to AWS as the wrong secret version. No plaintext was exposed. Each embedded reference is now answered from the association the resolver recorded for that reference, and only when the template's literal text plus those values rebuild the resolved string exactly; anything else falls back to the value scan as before. A resource whose record holds the sibling's expression can take one UPDATE on the first deploy after upgrading (a replacement if the property is create-only), even though the value sent is unchanged. Tests: tests/unit/deployment/secret-redaction-cross-stack-embedded.test.ts; integ arm EmbedSecretPair in tests/integration/nested-stack-secret/.
• cdkd scrub no longer reports a stack clean over a {{resolve:...}} reference an Fn::Sub placeholder left unresolvable (issue #2166) -- src/deployment/intrinsic-resolver/sub.ts, src/deployment/intrinsic-resolver/dynamic-refs.ts, src/deployment/intrinsic-resolver/context.ts, src/cli/commands/scrub.ts. A leaf such as Fn::Sub '{{resolve:secretsmanager:${Typo}-db:SecretString:password}}', where Typo names no resource or parameter of the template, keeps its ${Typo} with a keeping placeholder warning, so the reference is never looked up and nothing throws. Scrub recorded nothing for it and printed No plaintext secrets found, and --dry-run --fail exited 0, over a record that could still hold the plaintext an older deploy wrote. resolveSub now remembers such a placeholder and the dynamic-reference pass reports it as a placeholder unit in the abandoned-resolution bag once the assembled string (that Fn::Sub, or an enclosing Fn::Join / Fn::Sub) puts it inside a reference; scrub counts it as an abandoned scan: the stack is not printed clean and --fail exits 1. Fix the template (declare or rename the variable, or escape it as ${!Typo}) to clear it. Scrub also binds every parameter that has a non-empty Default when another parameter has none; it used to leave them all unbound, so a reference assembled from a defaulted parameter was never looked up and its plaintext never rewritten. A placeholder naming a Default-less parameter still only warns (#4559); one naming a declared resource only warns by design. A deferred reference whose lookup FAILS was already counted the same way. cdkd deploy is unchanged, since it collects no abandoned units. Tests: intrinsic-sub-kept-placeholder-report, scrub-cross-region-secret, scrub-all-refusal-boundary; integ dynamic-ref-cross-region phases 3g / 3h.
• cdkd drift --revert keeps AWS's value at a {{resolve:...}} token cdkd cannot resolve when the token is EMBEDDED in a longer string (issue #2102) -- src/cli/commands/drift.ts, src/deployment/secret-redaction/unresolved-token-frame.ts. A revert triggered by another drifted key preserved the live value only where a property's WHOLE value was the token; a token inside a longer string (jdbc:...password={{resolve:...}}), or beside a secret cdkd resolved, shipped the literal token and overwrote what AWS held. The live string is now kept when it equals the payload at every character outside the unresolved tokens' spans, resolved secrets included, so a secret rotated since the last deploy is never copied into the payload; otherwise the token ships as before. Both drift warnings say so. Also, a resolved secret that cdkd drift discards after a later reference on the same resource fails to resolve stays masked in the resource's comparison-failure warning. Tests: tests/unit/cli/drift-unresolved-token-frame.test.ts, tests/unit/cli/drift-masked-leaf-preserve.test.ts, tests/unit/cli/drift-secret-redaction.test.ts; integ arm in tests/integration/drift-revert/verify.sh (step 5b).
• An AppSync API key create that hits a 5xx now reports candidate orphans instead of duplicating silently (issue #2080, Plan C: AppSync CreateApiKey; #3978 layer (b) for this create) -- src/provisioning/providers/appsync-provider.ts, docs/troubleshooting.md. CreateApiKey mints the key's id and carries no idempotency token, so a 5xx whose request had succeeded left a second key on the API with no state record -- and, when the AWS SDK replayed it inside one call, nothing reported it. The create now goes through the same 5xx-refusing client as CreateGraphqlApi; the 5xx reaches cdkd's retry, which first lists the keys on the same API with the same description that this deploy did not record and warns, with a read command (aws appsync list-api-keys --api-id ... --region ...) and no delete command: a key has no name and no creation time, so nothing attributes one to this create. A key's id is the credential clients send, so the warning names each candidate only by its last four characters and its expiry. Nothing is adopted or deleted. A throttle, a 4xx or IAM propagation triggers no lookup. The lookup needs appsync:ListApiKeys; without it cdkd warns and the create proceeds. A reset connection or timeout after the send is still retried inside the SDK and not reported. Tests: tests/unit/provisioning/appsync-api-key-create-retry-2080.test.ts.
• A DLM lifecycle policy or ECS task definition create that hits a 5xx now reports candidate orphans instead of duplicating silently (issue #2080, Plan C: CreateLifecyclePolicy, RegisterTaskDefinition, CodeCommit CreateRepository / CreateCommit; the SDK-5xx half of #3978 layer (b) for these creates) -- src/provisioning/providers/dlm-lifecycle-policy-provider.ts, ecs-provider.ts, codecommit-repository-provider.ts. Neither DLM nor ECS create carries an idempotency token, so a 5xx whose request had succeeded left a second policy (still running its schedule) or an extra ACTIVE revision with no state record, unreported when the AWS SDK replayed it inside one call. Both now refuse the SDK's 5xx retry; cdkd's retry first lists what the failed attempt may have made -- policies with the same description and kind, or revisions of the same family, created in that attempt's window -- and warns with a read command, then a delete / deregister command to run only after confirming. Nothing is adopted or deleted; a throttle or 4xx triggers no lookup, and a failed lookup warns and lets the create proceed. A CodeCommit repository name cannot be duplicated, so its creates get only the 5xx-refusing client: a replayed collision is no longer credited to another holder, and a seed commit whose 5xx had succeeded no longer fails the deploy with ParentCommitIdRequiredException. A reset or timeout after the send is still retried inside the SDK. Tests: tests/unit/provisioning/{dlm,ecs-task-definition,codecommit}-create-retry-2080.test.ts.
• A Lambda layer version or event source mapping create that hits a 5xx now reports candidate orphans instead of duplicating silently (issue #2080, Plan C: Lambda; #3978 layer (b) for these two creates) -- src/provisioning/providers/{lambda-layer,lambda-eventsource}-provider.ts, docs/troubleshooting.md. PublishLayerVersion and CreateEventSourceMapping mint their id and carry no idempotency token, so a 5xx whose request had succeeded left a second layer version or mapping with no state record -- and, when the AWS SDK replayed it inside one call, nothing reported it. These creates no longer let the SDK retry a 5xx; the 5xx reaches cdkd's retry, which first lists what the failed attempt may have made and warns: a version of the same layer published during that attempt (a read command, then delete-layer-version to run only after confirming), or a mapping between the same function and source that this deploy did not record and that was not last modified before the attempt (a read command only: Lambda reports no creation time for a mapping). Nothing is adopted or deleted. Where Lambda refuses a second mapping for the same function and source (an SQS queue), the replayed create then fails naming the orphan's UUID instead of duplicating it. A throttle, a 4xx or IAM propagation triggers no lookup. The lookup needs lambda:ListLayerVersions / lambda:ListEventSourceMappings; without it cdkd warns and the create proceeds. A reset connection or timeout after the send is still retried inside the SDK and not reported. Tests: tests/unit/provisioning/lambda-create-retry-2080.test.ts.
• cdkd deploy's Updated: total no longer counts an orphaned predecessor left inside a nested stack (issue #1989) -- src/cli/commands/deploy.ts, src/deployment/deploy-engine.ts, src/deployment/deploy-engine/{options,execute,provision,deploy-flow}.ts. Since nested-stack counts reach the top-level stack (PR #4459), a replacement inside a nested child that left its old resource alive was added to the top-level Updated: total and its of which left an orphaned predecessor row, although Updated: counts the deployed stack's own resources only. Such survivors now print on their own row, Left an orphaned predecessor in a nested stack: N, and RunCounts.updated in cdkd events matches the console. The exit code and RunCounts.skipped still count them. docs/cli-deploy-safety.md no longer says the exit code covers top-level stacks only, and says a skipped DELETE inside a nested stack exits 2 on the first deploy and is re-attempted by the next. Tests: tests/unit/cli/deploy-unaddressed-exit.test.ts, tests/unit/deployment/deploy-engine-nested-child-unaddressed.test.ts, tests/unit/deployment/deploy-engine-nested-child-unaddressed-e2e.test.ts.

Recently Implemented (2026-10-03):

• cdkd local run-task and cdkd local start-api --watch no longer leave a container behind when ^C lands during a container start (issue #4495) -- src/local/ecs-task-runner.ts, src/local/ecs-network.ts, src/cli/commands/local-run-task.ts, src/local/container-pool.ts, src/cli/commands/local-start-api.ts. run-task recorded a container only after its docker run returned, so a ^C during that run (or during the network + metadata sidecar start, or a docker volume create) removed what it knew and exited, and the run then left its container behind. start-api --watch disposed a reload's previous container pool in the background, and the ^C cleanup exited without waiting for it, so a container that pool was still starting survived; a pool's own dispose also stopped waiting for an in-flight start after 5s. The ^C cleanup now waits for the in-flight docker step and removes what it created, and starts nothing more; start-api waits for every pool a reload replaced, and a reload whose re-synth outlasts the ^C swaps in no new pool. The wait is bounded at 20s; past it cdkd removes what the command creates by name and warns, naming it and the command that removes it (docker rm -f, docker volume rm -f or docker network rm), since a docker command still pending can create it later. Tests: tests/unit/local/ecs-task-runner-runner.test.ts, tests/unit/cli/local-run-task-command-body.test.ts, tests/unit/local/container-pool.test.ts, tests/unit/cli/local-start-api-reload-shutdown.test.ts; integ arms in tests/integration/local-run-task/verify.sh and tests/integration/local-start-api/verify.sh.
• cdkd deploy no longer fails when two AWS::EC2::SecurityGroupIngress resources of one stack resolve to the same rule (issue #4492) -- src/provisioning/providers/ec2-provider.ts, src/deployment/stack-records-scope.ts, src/deployment/deploy-engine/execute.ts, src/deployment/deploy-engine/provision.ts, src/deployment/rollback-executor.ts, src/cli/commands/destroy-runner.ts, src/cli/commands/export.ts. CDK cannot dedupe a rule whose port is a token, so an Aurora cluster with a DatabaseProxy on the same security group plus an explicit addIngressRule(sg, Port.tcp(3306)) emits two rules AWS stores as one. Since #4393 the second create was refused as someone else's rule. It now records the existing rule when another record of the same stack holds it — a SecurityGroupIngress record with the same group, protocol, ports and source, or the group's own record declaring it inline — waiting for a twin created in the same deploy to finish first; CloudFormation accepts both. A rule recorded under a different sgr- id than the live one is still refused, as is a rule held by nothing in the stack. A delete, a rollback, a destroy and a security group update dropping the rule from its inline list leave it in place while a record that outlives the operation still holds it (a destroy's retained records, a deploy's records it does not delete); the last holder revokes it, and a second revoke finding it gone succeeds (one with no recorded rule id still warns that nothing was revoked). cdkd export refuses two such records, naming each other, since an import adopts a rule into one logical id. Tests: tests/unit/provisioning/ec2-sg-ingress-sibling-holder.test.ts, tests/unit/deployment/stack-records-scope.test.ts, tests/unit/deployment/deploy-engine-stack-records-binding.test.ts, tests/unit/cli/destroy-runner-stack-records.test.ts, tests/unit/cli/export-sg-ingress-rule-id-backfill.test.ts.
• cdkd local invoke-agentcore --watch no longer leaves a container behind when ^C lands while a rebuild re-synthesizes or starts its new container (issue #4488) -- src/cli/commands/local-invoke-agentcore.ts (bootAgentCoreContainer, rebuildAgentCoreContainer, ContainerStartGuard). A rebuild removes the old container, re-synthesizes, then runs docker run for the new one. A ^C after the removal reached a cleanup that knew no container id, so it exited while the docker run was still starting a container nothing then removed. Once the cleanup begins, a rebuild now starts no container, and a container whose docker run was already in flight is removed before the process exits, with a line saying the ^C is waiting for that docker run. The wait is bounded at 15 s; past it, cdkd removes the container by its name if it exists, exits, and warns with the docker rm -f <name> to run in case a late docker run still starts it. Tests: tests/unit/cli/local-invoke-agentcore-stdout-stream.test.ts.
• cdkd local invoke, local invoke-agentcore and local run-task no longer drop the container's last log lines when the Docker daemon is slow to relay them (issue #4480) -- src/local/docker-runner.ts (followContainerLogs, killContainer, killAndDrainContainerLogs, flushStdio), src/local/ecs-task-runner.ts, src/cli/commands/{local-invoke,local-invoke-agentcore,local-run-task}.ts. The teardown SIGTERMed docker logs -f (after a fixed 250 ms on invoke) and then removed the container, so any line the daemon had not yet relayed was lost: under host load the handler's console.log output and the RIE's END / REPORT lines went missing while the invoke reported success. invoke / invoke-agentcore now run docker kill, wait (up to 5 s) for docker logs -f to end on its own, and only then write the response to stdout and remove the container, so every log line precedes the response. run-task waits for the essential container's follower after the container exits, and at teardown stops every container before draining the followers and removing the containers. The teardown flushes stdout and stderr before the process exits, on ^C (130) and on a failed invoke alike; run-task removes its --profile credentials file as soon as the containers are stopped, before the drain. invoke-agentcore --watch keeps the container between iterations, so it drains when the container is rebuilt or torn down. Tests: tests/unit/local/docker-runner-log-drain.test.ts, tests/unit/local/ecs-task-runner{,-runner}.test.ts, tests/unit/cli/local-invoke{,-agentcore}-stdout-stream.test.ts.
• cdkd diff reuses the condition verdict the last deploy recorded, so an Fn::If on a condition over a secret-fed parameter no longer always takes FALSE (issue #4479) -- src/deployment/condition-verdicts.ts (new), src/deployment/deploy-engine/deploy-flow.ts, src/cli/commands/diff-recursive.ts, src/types/state.ts. A condition that reads a parameter fed a secret {{resolve:...}} reference has no verdict at plan time. An Fn::If on one took its FALSE branch, so a stack whose last deploy took the TRUE branch diffed as a perpetual UPDATE, and cdkd diff --fail exited 1 on an unchanged stack. The deploy now records each such verdict in state (conditionVerdicts, additive, no schema bump) with a sha256 fingerprint of the condition's definitions, transitively through {Condition: X}, and of the parameter inputs they read: a secret-fed one as its expression, never its value. The diff reuses a verdict only when its own fingerprint is equal, for both Fn::If and pruning. So a branch swap, an edited condition or a different secret reference is still reported. A deploy's final save and its no-change save write the record; a child an older binary deployed gains it on the next deploy that changes it. No record (an older binary, a failed deploy), a different fingerprint (the diff warns), an unbound or SSM-typed parameter, a plain parameter the parent passes a value other than its Default, a parent row value the diff cannot vouch for, or a shape outside Fn::And / Or / Not / Equals over string literals and declared scalar parameters keeps the FALSE branch. The value behind an unchanged secret reference is assumed unchanged, as for every secret-bearing property. Tests: tests/unit/cli/diff-recorded-verdicts-4479.test.ts, tests/unit/deployment/condition-verdicts.test.ts, tests/unit/deployment/deploy-engine-condition-verdicts-4479.test.ts.
• Stack selection now matches the AWS CDK CLI: patterns use the hierarchical id with path-aware globs, and --all selects top-level stacks only (issue #4474) -- src/utils/glob-match.ts, src/cli/stack-matcher.ts, src/synthesis/assembly-reader.ts, and src/cli/commands/deploy.ts, destroy.ts and diff.ts, with unit tests beside each. A pattern without / used to match only the physical CloudFormation name, so cdkd deploy Api missed new Stack(app, 'Api', { stackName: 'prod-api' }), and * crossed /. Every pattern now matches the stack's hierarchical id (its CDK display path), as cdk does: * stays within one / segment, so '*' selects the top-level stacks only and 'MyStage/*' one Stage's stacks, and '**' selects every stack. An EXACT physical name still selects its stack as a cdkd extension when no hierarchical id matches, but a glob no longer matches physical names. --all changed scope: on deploy, destroy and diff it selects the top-level stacks only, as cdk deploy --all / cdk destroy --all do; the run names the Stage stacks it left out with the 'MyStage/*' / '**' patterns, and a stage-only app is refused. publish-assets --all and scrub --all still cover every stack. Re-audit scripts that pass physical names or globs to cdkd destroy / cdkd deploy: a pattern without / now matches CDK ids first, so it can select a different stack than before, and '*' or 'MyStage-*' no longer reaches Stage stacks; both commands warn in one line naming any stack the old rule would have selected (including one 'MyStage/*' used to reach deeper than one segment).
• A resource whose TOP-LEVEL property is a condition-false Fn::If selecting AWS::NoValue (Fn.conditionIf(cond, x, Aws.NO_VALUE) on an L1 property) no longer diffs as a perpetual UPDATE (issue #4471) -- src/analyzer/diff-calculator.ts (resolveBestEffort), tests/unit/analyzer/diff-calculator.test.ts, and a live arm on tests/integration/conditions-and-if/ (Phase 2b). The diff resolves desired properties one top-level key at a time, so the resolver returned the bare AWS::NoValue symbol for such a key instead of dropping it, and the symbol compared unequal to the absent recorded property: cdkd diff --fail exited 1 on an unchanged stack and every cdkd deploy planned an UPDATE of the resource. The key is now omitted, as the resolver already does for nested object keys and list elements; a key the stack still records is still reported as removed. The replacement decisions read the omission too: an AWS::Lambda::Function whose DurableConfig such a branch now removes is planned as a REPLACEMENT (it was an in-place UPDATE that kept the live durable config), one with no recorded DurableConfig no longer plans a spurious replacement, and a removed container whose record lacks a nested createOnly leaf updates in place instead of being conservatively replaced.
• cdkd diff evaluates Conditions per condition, so one secret-fed or unbindable parameter no longer turns every Fn::If in the stack FALSE (issue #4470) -- src/cli/commands/diff-recursive.ts. The diff used to skip the WHOLE Conditions section when any template parameter failed to bind or any one condition read a parameter fed a secret {{resolve:...}} reference, so every Fn::If resolved to its FALSE branch, even on a condition that reads no parameter at all: a condition-true property diffed as a perpetual UPDATE and cdkd diff --fail exited 1 on an unchanged stack, at the top level and in nested children alike. Parameters now bind one at a time, and only the conditions that reach an unbound or secret-fed parameter, directly or through a {Condition: X} chain, go unevaluated. They still never prune a resource, so no phantom DELETE is reported. Every other condition gets the verdict the deploy computes. An Fn::If on a condition that itself depends on an unbound or secret-fed parameter still takes its FALSE branch, unchanged. Residual: go-to-k/cdkd#4479. Tests: tests/unit/cli/diff-per-condition-4470.test.ts.
• A same-name IAM role, user or group re-create no longer silently drops the managed policies, instance profile and group memberships attached to it (issue #4461) -- src/deployment/child-of-recreated-parent.ts, src/deployment/deploy-engine/update.ts, src/deployment/deploy-engine/update-in-place.ts, src/deployment/deploy-engine/execute.ts, src/provisioning/providers/iam-user-group-provider.ts, src/provisioning/providers/iam-instance-profile-provider.ts. When a deploy re-created a fixed-name role, user or group under the same name, IAM had detached what was attached to it: an AWS::IAM::ManagedPolicy (Roles / Users / Groups), an AWS::IAM::InstanceProfile's role, a user's Groups membership, a UserToGroupAddition's members, and an inline AWS::IAM::Policy / UserPolicy / GroupPolicy on a user or group. Their references resolved to the same names, so every deploy diffed them unchanged while state kept recording them -- a Deny guardrail silently absent from the re-created role. cdkd now attaches each of them again in place (also when the same deploy edits the list) and writes the inline policies again. A deploy that fails first keeps their records minus the re-created principals, so the next deploy attaches them. Re-adding a role an instance profile already holds now succeeds instead of failing with LimitExceeded, and an IAM user's update no longer re-sends an unchanged LoginProfile, which reset its password. Tests: tests/unit/deployment/child-of-recreated-parent.test.ts, tests/unit/deployment/deploy-engine-iam-reattach.test.ts, tests/unit/provisioning/iam-user-group-provider-roundtrip.test.ts, tests/unit/provisioning/iam-instance-profile-provider-roundtrip.test.ts.
• A nested stack's skipped DELETE is re-attempted by the next cdkd deploy, which exits 2 again until it lands (issue #4453) -- src/provisioning/providers/nested-stack-provider.ts. A top-level stack's skipped DELETE keeps its record and is retried by the next deploy, but inside a nested child (or grandchild) the retry never ran: the parent's AWS::CloudFormation::Stack row diffed only TemplateURL / Parameters, so with no template change it was NO_CHANGE, the child never deployed, and the second deploy reported nothing and exited 0 over a resource cdkd still owns. A nested row now records the record-only key cdkd:PendingChildDeletes (the child's skipped-DELETE count, descendants included) while any remain, so the next deploy re-runs the child chain, retries the DELETE and counts it again; cdkd diff shows that pending re-run as a change on the row. A clean re-run records the plain template properties and the key is gone. A skip left by an earlier cdkd version carries no key, so it is re-attempted the next time that child stack deploys for another reason. Tests: tests/unit/deployment/deploy-engine-nested-child-unaddressed-e2e.test.ts, tests/unit/provisioning/nested-stack-provider.test.ts; integ: nested-stack-3level.
• A nested-stack child resource whose embedding leaf has several parts the template cannot state, or is an Fn::If selecting an Fn::Sub / Fn::Join, no longer reports an UPDATE on every deploy when a sibling {Ref} parameter resolves to the same plaintext (issues #4446, #4469) -- src/deployment/intrinsic-resolver/string-functions.ts, src/deployment/intrinsic-function-resolver.ts, src/deployment/secret-redaction/pairs.ts (IntrinsicLeafResolution.parameterSpans), src/deployment/secret-redaction/positions.ts, tests/unit/deployment/secret-redaction-nested-parameter-spans.test.ts, and a live arm on tests/integration/nested-stack-secret/ (HandoffSpans / HandoffSpansIf, their own spans JSON key). The #2320 arm aligned the template against the resolved leaf, so it refused a leaf like postgres:// + {Ref: User} + : + {Ref: A} + @ + an attribute, and never read an Fn::If; the leaf fell to the value scan and took the sibling parameter's expression, a perpetual UPDATE (a REPLACEMENT on a create-only property). The resolver now records, while it substitutes them, where each parameter Ref landed on an Fn::Sub / Fn::Join output, through nested parts and an Fn::If's selected branch, and drops that record when a later dynamic-reference pass rewrites the text; a part that places no span it can vouch for (a string-selected Fn::If such as CDK's Fn.conditionIf(c, '-prod', '')) is a gap rather than a reason to drop the others. The persist path reads those spans first: each certified span takes that parameter's own expression, every other stretch is kept verbatim only where the value scan would leave it alone, and the #2320 straddle and final re-scan guards still apply. Any refusal falls back to the template parse, then the value scan.
• The update-failure fallback's same-id re-create now brings back the sub-resources stored inside the resource (issue #4444) -- src/deployment/deploy-engine/update-in-place.ts, src/deployment/deploy-engine/execute.ts, src/deployment/child-of-recreated-parent.ts. When a provider refuses an in-place update (ResourceUpdateNotSupportedError under --replace, or Cloud Control's UnsupportedAction), cdkd deletes the resource and creates it again; with a fixed name it comes back under the same physical id, and what AWS stored inside it (a log group's streams and metric or subscription filters, from the #4411 table) went with the old one. The diff never promoted those children, since the parent was an in-place update, so they stayed NO_CHANGE and were never dispatched: after a green deploy they were missing in AWS while state recorded them. The fallback now records such a re-create, and as soon as the re-created resource completes the engine dispatches each NO_CHANGE child of it through the #4411 arm (re-created without a delete, or re-put), before any pending resource that reads the child, so a later failure elsewhere in the deploy no longer leaves it missing. Tests: tests/unit/deployment/deploy-engine-fallback-recreate-children.test.ts, tests/unit/deployment/child-of-recreated-parent.test.ts.
• A deploy that fails after re-creating a resource under the same physical id no longer leaves the sub-resources stored inside it lost for good (issue #4443) -- src/deployment/child-of-recreated-parent.ts, src/deployment/deploy-engine/execute.ts, src/deployment/deploy-engine/update.ts, src/deployment/deploy-engine.ts. Since #4411 the deploy re-creates a child that went with such a parent (a bucket's BucketPolicy, a function's Permission). When the deploy failed or was interrupted before reaching it, the child's record survived (the rollback keeps an equal-id parent as done) and every later deploy diffed it unchanged, so the child stayed missing in AWS while state recorded it: a bucket policy's deny of plain HTTP, or an IAM policy's Deny, silently absent. The failure path now drops the record of each such child the deploy did not restore, when its recorded value still names the re-created parent, with a warning naming it; the next deploy creates it again. Tests: tests/unit/deployment/child-of-recreated-parent.test.ts, tests/unit/deployment/deploy-engine-lost-child-after-failed-deploy.test.ts.
• After a destroy that kept an EFS or FSx file system or a CloudFront origin access identity, the same stack's next deploy creates a new one; a re-run of an interrupted deploy takes the one it made (issue #4438) -- src/provisioning/providers/{create-token-ledger,efs-provider,fsx-filesystem-provider,cloudfront-oai-provider}.ts, src/state/{create-token-ledger,s3-state-backend}.ts, the deploy engine, the rollback executor, src/cli/commands/{orphan,rollback}.ts. These create tokens were deterministic per stack, so a resource that outlived cdkd's record of it (RemovalPolicy.RETAIN, CDK's default for both file systems, RetainExceptOnCreate, UpdateReplacePolicy: Retain, cdkd orphan) still held the token the next create sent: EFS and FSx refused that redeploy where the AWS CDK CLI creates a new resource, and CloudFront handed the old identity back. A per-stack ledger, create-tokens.json beside state.json, folds a nonce into those tokens. It is deleted before the state record (failing the command if it cannot be), and rotated by cdkd orphan and by any Retain or --orphan. Each send is recorded before the create and kept until that deploy succeeds, so an interrupted deploy's re-run takes the resource it made, which #4437 refused. A deploy that finds no state record but a ledger written under one (an earlier cdkd destroyed the stack) starts a fresh ledger. A ledger that cannot be read or written refuses these creates, naming the stack and logical id. A create interrupted under an earlier cdkd creates a fresh resource on its re-run; for EFS, cdkd warns naming the file system left behind. Tests: tests/unit/{provisioning/create-token-ledger,state/create-token-ledger,deployment/deploy-engine-create-token-ledger-4438}.test.ts and the provider and orphan suites; integ: stack-copy-create-tokens.
• A rolled-back update now records the attributes the provider returned, so a reverted AWS::EC2::SecurityGroupIngress keeps its new sgr- rule id instead of the revoked one (issue #4434) -- src/deployment/rollback-executor/replay-retry.ts (recordAfterRollbackUpdate), src/deployment/rollback-executor.ts, src/deployment/rollback-executor/replay-revert.ts, src/deployment/rollback-executor/replay-reverse-replacement.ts, src/deployment/secret-redaction/mask-only.ts (recordNoEchoAttributeValues), tests/unit/deployment/rollback-executor-update-attributes.test.ts. Both UPDATE arms (cdkd rollback / the automatic rollback, and --revert-failed) kept the restored record's attributes, so after a revert that re-authorized a rule, cdkd export and a later Fn::GetAtt <rule>.Id read a revoked id. The record now takes the returned set wholesale when the update replaced, merges it key-wise when it updated in place, and keeps the restored set when the provider returned none; an update that replaced under a new physical id is recorded under that id, without the removed resource's attributes when it returned none. A NoEcho declaration on those attributes (a custom resource's response, a nested stack's masked outputs) is registered before the record is redacted, as the deploy engine does, so they persist as ***; the reverse-replacement replay-CREATE arm, which already recorded its create's attributes, now does the same.
• AWS::Pipes::Pipe has an SDK provider, so a stream or broker source's batch settings change in place (issue #4423) -- src/provisioning/providers/pipes-provider.ts (new), src/provisioning/{register-providers,provider-registry}.ts, new dependency @aws-sdk/client-pipes. A change to a mutable SourceParameters member of a Kinesis, DynamoDB Streams, MSK, self-managed Kafka, ActiveMQ or RabbitMQ source (e.g. KinesisStreamParameters.BatchSize) failed with "createOnlyProperties [...StartingPosition] cannot be updated": Cloud Control cannot express that update at all. The provider calls UpdatePipe, whose source shape has no create-only member, and waits for the pipe to settle after a create or update and to disappear after a delete. A pipe recorded provisionedBy: cc-api by an earlier cdkd returns to the SDK provider on its next in-place update under the same name (a cc-broken sticky exemption). Removing TargetParameters or EnrichmentParameters from the template is reported, not applied. Tests: tests/unit/provisioning/providers/pipes-provider.test.ts; integ: cc-write-only-create-only (a BatchSize change on a cc-api-seeded record), eventbridge-pipes.
• A SecurityGroupIngress duplicate is no longer adopted on the strength of a journal entry a rollback, a later deploy or a partial destroy already undid (issue #4402) -- src/deployment/prior-attempt-scope.ts, src/state/s3-state-backend.ts, src/types/rollback-journal.ts, src/deployment/deploy-engine/rollback.ts. Since #4355, a create that AWS rejects as a duplicate adopts the existing rule when the stack's rollback journal shows the same logical id attempted it. The journal's COMPLETED operations counted too, but a segment can keep them after they were undone: an automatic rollback whose segment cleanup failed, a cdkd rollback that failed on another operation, an unsettled nested-stack segment, or a cdkd destroy that failed partway. If someone then added the identical rule, the next deploy adopted it and cdkd destroy revoked it. Now only a FAILED attempt that no later completed operation of the logical id superseded is evidence: a completed operation's resource was recorded in state, so a later create of that id means it was reverted, destroyed or replaced. Removing a segment (or a successful deploy failing to delete the journal) now leaves its operations' logical ids on the next older segment (supersededLogicalIds, an additive journal field), so a reverted adoption no longer lets the attempt it adopted count again. Tests: tests/unit/deployment/deploy-engine-prior-attempt-binding.test.ts, tests/unit/state/s3-state-backend.test.ts, tests/unit/types/rollback-journal.test.ts, tests/unit/deployment/deploy-engine-rollback-journal.test.ts; integ arm: tests/integration/sg-circular-dependency phase 1e.
• cdkd drift reports a resource deleted outside cdkd as deleted and exits 1, instead of as an uncovered type with exit 0 (issue #4283) -- src/types/resource.ts (new RESOURCE_NOT_FOUND sentinel), src/cli/commands/{drift,state,import}.ts, src/deployment/deploy-engine/observed-capture.ts, src/provisioning/cloud-control-provider.ts, every SDK provider that reads state back under src/provisioning/providers/, docs/cli-{drift,state,reference}.md, the drift-revert and ecs-fargate integ fixtures. A resource AWS reports gone read as drift unknown ("provider does not support drift detection yet") with exit 0, so a CI gate on cdkd drift stayed green over a missing cluster, bucket or role. A read now returns RESOURCE_NOT_FOUND on AWS's own not-found answer (a not-found error name, an empty describe list for the id, or a terminal status such as ECS INACTIVE); access-denied, throttled or message-only answers never do. Drift reports such a resource under a new deleted outcome: a - <id> (<type>) — DELETED outside cdkd line in the drift block and exit 1. --json shape change: such a resource moves from notSupported to a new deleted array. Each stack is now read through its own region's clients, so --stack-region / --all cannot misread another region's resources as deleted. --revert and --accept refuse it by name, resolve the other drifted resources, and exit 2; a plain deploy does not recreate it, and the message names the remove-then-restore route. cdkd state refresh-observed names such a resource and counts it apart from read failures (exit 2), keeping its baseline; deploy and import baseline captures record nothing for it. An S3 Tables namespace is now checked with GetNamespace, so s3tables:GetNamespace is needed for drift. Not covered: a type with no reader (a nested stack, an Elastic IP) -- #4447.
• A Route 53 record whose name contains | is deployed instead of refused (issue #3890) -- src/provisioning/providers/route53-provider.ts, src/deployment/intrinsic-resolver/ref-values.ts, src/provisioning/composite-id.ts. Route 53 accepts | in a record name and CloudFormation deploys such a record, but cdkd refused it at deploy time because | separates the segments of its <hostedZoneId>|<name>|<type> physical id. The name is now recorded as is: every reader takes it from between the first and the last |, and only when it matches the recorded Name and the last segment matches the recorded Type. An id that does not match is read as CloudFormation's own physical id, the record name, as before. Ref returns the whole record name. Drift reads, renames and cdkd import find the record under Route 53's \174 spelling of |. An existing state record keeps its id and still decodes. Tests: tests/unit/provisioning/{composite-id-provider-guards,route53-provider-cfn-physical-id,route53-recordset-rename}.test.ts, tests/unit/deployment/intrinsic-functions.test.ts; integ: route53.
• A CDK Stage whose cloud assembly cannot be read now stops every command, as in the AWS CDK CLI (issue #3507) -- src/synthesis/assembly-reader.ts and src/synthesis/failed-stages.ts (stageLoadError), with the selection-time handling removed from src/cli/stack-matcher.ts and src/cli/commands/deploy.ts, destroy.ts, diff.ts, publish-assets.ts, scrub.ts, import.ts, export.ts, orphan.ts, list.ts and synth.ts; unit tests in tests/unit/synthesis/assembly-stage-refusal.test.ts and beside each command, and tests/integration/stage-assets Phases 2b and 2g. A Stage whose own manifest.json could not be read was tolerated: its stacks silently left the synthesized app, and a run then acted on the stacks that did load. That tolerance needed a refusal per selection -- --all, no stack named, a wildcard -- and this replaces those refusals, and the failed-Stage note appended to "no stacks matching", with one synthesis error, Stage <path> failed to load: <reason>. ..., raised before any stack is selected or any state is read, whatever was named. cdkd destroy no longer falls back to state for an exact name in that case, and its error names cdkd state destroy '<stack>', which needs no app. cdkd scrub refuses with exit 2 (SCRUB_STAGE_LOAD_FAILED), replacing the SCRUB_ALL_PARTIAL_APP / SCRUB_AUTO_PICK_PARTIAL_APP codes. The exported SynthesisResult.failedStages and AssemblyContents.failedStages fields are removed. Separately, cdkd destroy now warns about each pattern that matched nothing, as the AWS CDK CLI's destroy does, and about a name in state that is not a stack of this app.
• cdkd diff no longer reports a change on every run for an Fn::Base64 over a secret reference, so cdkd diff --fail can pass for such a stack (issue #2909) -- src/deployment/intrinsic-resolver/functions.ts, src/deployment/intrinsic-resolver/context.ts, src/analyzer/outputs-diff.ts. The diff leaves a {{resolve:secretsmanager:...}} / {{resolve:ssm-secure:...}} reference (or a plain ssm one to a SecureString) unresolved and encoded the reference TEXT, while the deploy encodes the secret and stores *** for it, so the two never matched: a resource or output holding such a value (the CDK EC2 UserData shape) always showed as changed, and the deploy then skipped it. The diff now compares such an Fn::Base64 as ***, the value the deploy stores, unless its input also holds a NoEcho value supplied in the same deploy, which must still reach AWS. Bound: an edit to the text around, or the target of, a secret reference inside the same Fn::Base64 is not shown by the diff either (nor is a rotated value); the deploy already did not send it (#4451). Tests: tests/unit/deployment/intrinsic-base64-diff-mask-2909.test.ts, tests/unit/deployment/deploy-engine-base64-secret-noop.test.ts, tests/integration/secrets-dynamic-ref/.
• A nested-stack child resource that embeds one parameter (Fn::Sub / Fn::Join) beside a whole-value {Ref} to a second parameter resolving to the same plaintext no longer reports an UPDATE on every deploy (issue #2320) -- src/deployment/secret-redaction/positions.ts (positionByParameterPlaceholders), src/deployment/secret-redaction/redact-path.ts, tests/unit/deployment/secret-redaction-nested-parameter-placeholders.test.ts, and a live arm on tests/integration/nested-stack-secret/ (HandoffMixed, its own mixed JSON key). The resource's secret bag holds one expression per plaintext -- whichever Ref resolved last -- so the embedded leaf was persisted with the sibling parameter's expression while the diff side rendered its own: a perpetual UPDATE, and a REPLACEMENT every run on a create-only property. The persist path now answers each placeholder of an Fn::Sub / Fn::Join over the child's parameters (a placeholder a 2-arg Fn::Sub map binds to a Ref, and a nested Fn::Sub / Fn::Join, included) from that parameter's own association, the same one a bare {Ref} leaf uses, and accepts the result only when the template's literals and those plaintexts reassemble the resolved leaf exactly; at most one other part (a pseudo parameter, an intrinsic, an unassociated parameter) is allowed, kept verbatim only where the value scan would leave it alone, and a recorded secret crossing a placeholder's edge refuses. A leaf with two or more such parts, or one the reassembly refuses, keeps the old value-scan answer (residual: #4446, since closed).
• cdkd deploy counts what a nested stack's child left unaddressed, and exits 2 for it (issue #1989) -- src/provisioning/{nested-stack-context,providers/nested-stack-provider}.ts, src/deployment/deploy-engine/{provision,options}.ts. The parent discarded the child engine's result, so a skipped DELETE or an orphaned replacement predecessor inside a nested child (or grandchild) printed its own warning and nothing else: the parent's Skipped (not deleted) / of which left an orphaned predecessor rows stayed at 0, RunCounts.skipped was unset, the stack reported Deployment completed successfully, and the run exited 0 (the #1960 exit code). The child's deleteSkipped / updatePartial now reach the parent's counters through a per-row slot on the nested-stack context, recursively, so those rows, the warning banner, the events record and exit 2 (--allow-unaddressed opts out) cover nested children too. Tests: tests/unit/deployment/deploy-engine-nested-child-unaddressed{,-e2e}.test.ts, tests/unit/provisioning/nested-stack-provider.test.ts; integ: nested-stack-3level.
• cdkd now refuses, instead of substituting the placeholder account 123456789012, when STS cannot name the deploy's account and AWS_ACCOUNT_ID is unset (issue #1730) -- src/deployment/intrinsic-resolver/{account-drain,functions,getatt-heal}.ts, src/utils/error-handler.ts (AccountIdUnavailableError), and the Cloud Control / SSM / AppSync / API Gateway V2 / custom-resource providers and cdkd import. A failed sts:GetCallerIdentity used to answer 123456789012 with only a warning, so Ref: AWS::AccountId and AWS::StackId served it silently and a custom resource's StackId carried 000000000000. Now they refuse with Cannot determine the AWS account id: ..., withholding AWS-authored message text from the STS failure, naming the aws sts get-caller-identity check and the AWS_ACCOUNT_ID escape hatch, which must be 12 digits. AWS::Region, AWS::Partition, Fn::GetAZs and any Fn::GetAtt whose value does not embed the account still resolve. An ARN a provider records after the resource exists is left out with a warning rather than failing the create; cdkd import leaves an account-bearing name unresolved; a custom-resource Delete asks again for about 17 seconds before it is reported skipped. A failure is never cached, so the next lookup asks STS again; the 10-second placeholder window is gone.

Recently Implemented (2026-10-02):

• Two copies of one stack in an account and region get their own FSx and EFS file systems and CloudFront origin access identities (issue #4428) -- src/provisioning/providers/{idempotency-token,fsx-filesystem-provider,efs-provider,cloudfront-oai-provider}.ts. The FSx ClientRequestToken, EFS CreationToken and OAI CallerReference came from the logical id (and create-only properties) only, so a Dev and a Staging copy sent the same token: FSx and CloudFront handed the second copy the FIRST copy's resource, which its cdkd destroy then deleted, and EFS refused the second deploy. All three now cover the stack name and region, stay stable across retries and runs of one stack, and fit the APIs' length limits. A create takes a handed-back or named file system only when it was created after the create's first send, judged on AWS's clock (the response Date), so a fast host clock does not refuse ordinary creates: EFS adopts its own lost-response retry (which used to fail), and a file system an earlier destroy kept is refused with its id and an inspect command instead of being recorded, and so later deleted. If you deployed stack copies with an earlier cdkd, compare their state files for a shared FSx FileSystemId or OAI id before destroying either. Re-running an INTERRUPTED deploy now refuses the FSx file system the interrupted run made, as EFS already did, naming it with an inspect command: import it into the stack or delete it, then deploy again (#4438 tracks adopting it). A create interrupted under an earlier cdkd sends the new token and so creates a fresh resource. Tests: tests/unit/provisioning/{stack-scoped-create-token,cloudfront-oai-provider,providers/efs-filesystem-creation-token-4428,providers/fsx-filesystem-provider}.test.ts; integ: stack-copy-create-tokens.
• A Cloud Control resource whose write-only property holds a create-only value is updated in place again (issue #4416) -- src/provisioning/{cloud-control-provider,write-only-properties}.ts. The update path re-adds every write-only property to the patch (#809), so these failed every update with "createOnlyProperties [...] cannot be updated", even when only an unrelated property changed: an AWS::Cognito::ManagedLoginBranding (ClientId is write-only and create-only), a Kinesis- / DynamoDB- / Kafka- / MQ-source AWS::Pipes::Pipe (write-only SourceParameters holding a create-only StartingPosition / topic / queue), an AWS::CodePipeline::CustomActionType (create-only Settings / ConfigurationProperties holding write-only leaves). Cloud Control refuses any patch bringing such a value into the model its read handler returns, unchanged or not. An UNCHANGED write-only property whose value holds such a path is no longer re-added, so it sends no op; an SQS-source pipe's SourceParameters is still re-added. A CHANGED one still fails: Cloud Control cannot express that update at all (a Kinesis-source pipe's BatchSize, issue #4423). Tests: tests/unit/provisioning/cloud-control-provider.test.ts; integ: cc-write-only-create-only.
• A resource stored inside a parent the deploy destroys and re-creates under the same physical id is now re-created with it (issue #4411) -- src/deployment/child-of-recreated-parent.ts, src/deployment/deploy-engine/update.ts, src/deployment/deploy-engine/update-replace.ts, src/deployment/deploy-engine.ts. Recreating a fixed-name Lambda function (--recreate-via-cc-api / --recreate-via-sdk-provider, or a delete-first --replace) deletes its resource-based policy with it, but the AWS::Lambda::Permission reading the function resolved exactly as recorded, so the deploy skipped it as unchanged: after a green deploy the new function had no permission while state still recorded one, and its trigger stopped invoking it. The engine now records each resource it destroyed and re-created under the same id, and a child of one -- a Lambda Permission, Version, Alias or EventInvokeConfig, an SNS Subscription, TopicPolicy or TopicInlinePolicy, an SQS QueuePolicy or QueueInlinePolicy, an S3 BucketPolicy, a Logs LogStream, MetricFilter or SubscriptionFilter, an IAM RolePolicy or role-attached Policy -- is created again without deleting the old one, which went with its parent (a delete would remove the fresh statement, since a permission's id is its statement id); a permission on an alias of the function is covered too, and a policy naming several parents (topic, queue, multi-role IAM policy) is written again in place. src/analyzer/diff-calculator.ts marks such a child as replaced whatever the schema lookup answers, so its own readers are promoted. Residuals: go-to-k/cdkd#4443, go-to-k/cdkd#4444. Tests: tests/unit/deployment/child-of-recreated-parent.test.ts, tests/unit/deployment/deploy-engine-child-of-recreated-parent.test.ts.
• A failed create no longer deletes a pre-existing ELBv2 load balancer or target group, SNS topic or EventBridge rule that the create handed back (issue #4403) -- src/provisioning/providers/create-ownership.ts (new), src/provisioning/providers/{elbv2,sns-topic,eventbridge-rule}-provider.ts, docs/provider-rules.md, unit cases per site. These create APIs answer success with a resource that already held the name (ELBv2 on identical settings, SNS CreateTopic, EventBridge PutRule, which overwrites). When a later step of the same create failed (a load balancer's active wait or attributes, a target group's attributes or targets, a topic's policies, delivery logging or subscriptions, a rule's targets), the provider's cleanup deleted whatever the create returned, so another stack's or a hand-made resource of that name was deleted, and an EventBridge rule was stripped of its targets first. Each provider now looks the name it sends up before the create, only when such a step is declared: Describe* by name for ELBv2, GetTopicAttributes on the ARN built from STS for SNS, DescribeRule on the rule's bus for EventBridge. Only the service's own not-found answer lets the cleanup run. A name that was held is left in place with a warning that it existed before this create attempt (an earlier attempt or failed deploy, another stack, or someone else), that this deploy may have changed its configuration, and that a cdkd-generated name is adopted by the next deploy, with the delete command to use only once it is confirmed no one else's; a lookup that could not answer (an ELBv2 empty answer included) leaves the resource too, with the delete command to run if this deploy created it. The EventBridge rule's cleanup warnings now go through the deploy's secret masker. The lookup and the create are two calls, so a resource created between them is still treated as this create's.
• cdkd destroy --remove-protection now restores a Cloud Control-routed Auto Scaling group's guards after a retry that later fails terminally (issue #4400) -- src/provisioning/cloud-control-provider.ts. A group recorded as provisionedBy: cc-api is deleted through the SDK Auto Scaling provider, which was built afresh on every attempt and so forgot what an earlier attempt had turned off. When one attempt turned the group's DeletionProtection and its instances' DisableApiTermination off and failed retryably, and the next failed terminally, neither guard was turned back on. The delegate is now kept for the Cloud Control provider's lifetime (one per region), as the SDK route already did, so the terminal failure restores both. Tests: tests/unit/provisioning/cloud-control-asg-delegate-reuse-4400.test.ts.
• A --recreate-via-cc-api / --recreate-via-sdk-provider target's same-stack readers now follow the id the recreate mints (issue #4383) -- src/analyzer/diff-calculator.ts, src/deployment/recreate-target-promotion.ts, src/deployment/recreate-target-readers.ts, src/deployment/deploy-engine/deploy-flow.ts, src/cli/commands/deploy.ts, src/cli/commands/recreate-confirm-prompt.ts. For a type whose physical id AWS assigns (an AWS::EC2::SecurityGroup, an AWS::ApiGateway::RestApi), a Ref / Fn::GetAtt reader the template did not touch kept the deleted resource's id in AWS and in state after a green deploy, also when the target had an in-place change. The diff now promotes the stack's own targets' readers as for a property-driven replacement (never a nested child's or another stack's), and the counts and --dry-run include them. A reader holding the target in a create-only property is replaced; the confirmation prompt lists those as "Replaced if the id changes" (DATA LOSS for a stateful one) instead of saying sibling resources are unaffected, and a stateful one without --force-stateful-recreation is now refused before anything is touched rather than after the target was recreated. Tests: tests/unit/analyzer/diff-calculator-recreate-target-dependents.test.ts, tests/unit/deployment/deploy-engine-recreate-target-dependents.test.ts, tests/unit/deployment/recreate-target-readers.test.ts, tests/unit/cli/deploy-recreate-replaced-readers-preflight.test.ts.
• cdkd deploy now refuses a list where the resource type's schema wants an object, or the reverse, before any provider runs (issue #4357) -- src/provisioning/property-shape.ts + .generated.ts, src/provisioning/provider-registry.ts, scripts/gen-property-shape.ts, scripts/refresh-cfn-schemas.mjs, tests/fixtures/cfn-schemas/*.json. CloudFormation validates properties against the type schema up front (Properties validation failed ... expected type: JSONArray, found: JSONObject); cdkd forwarded such a value, which then failed inside an SDK call with an unrelated-looking error or was silently dropped. The deploy pre-flight now names each offending resource, type and property path in one error, in CloudFormation's words. Only array-versus-object contradictions the schema pins exactly are refused: scalars, type lists, disagreeing oneOf / anyOf arms, legacy types whose schema CloudFormation does not validate against (no handlers), unknown types and paths, and every intrinsic (Ref, Fn::*) pass. The per-path table is generated offline from the committed schema fixtures (new propertyShapes section, vp run gen:property-shape); no AWS call is added. Tests: tests/unit/provisioning/property-shape.test.ts, tests/unit/scripts/gen-property-shape.test.ts.
• An AWS::EC2::SecurityGroupIngress create no longer adopts an identical rule it did not create (issue #4355) -- src/provisioning/providers/ec2-provider.ts, src/deployment/prior-attempt-scope.ts, src/deployment/deploy-engine/provision.ts, src/deployment/deploy-engine/execute.ts, src/utils/aws-clients.ts. When AuthorizeSecurityGroupIngress answered InvalidPermission.Duplicate, the create treated it as success and recorded the existing rule as the stack's, so cdkd destroy later revoked a rule added by hand or by another stack. The rule is now adopted only when this stack's rollback journal shows the same logical id attempted the same rule, with no later delete of it (a re-run after a failed or interrupted deploy, including one whose earlier attempt got no definite answer from AWS), or during a rollback replay; otherwise the deploy refuses, naming the existing sgr- id with a revoke command. The journal is read only on that duplicate path, and a refused op (or an Authorize AWS provably did not apply, judged per send: the Authorize is sent without SDK retries) is journaled without its attempted properties, so the refusal itself never reads as a prior attempt on the next deploy and cdkd rollback --revert-failed never reverts an update from the refused rule; it re-authorizes the previous rule the refused update had revoked. Deleting a rule now revokes it by its recorded sgr- id (a stale id: the one live rule matching its identity and description), and a revoke by properties no longer sends the description: a recorded description the live rule lacked made AWS answer not-found, read as already deleted. Tests: tests/unit/provisioning/ec2-sg-ingress-duplicate-ownership.test.ts, tests/unit/deployment/deploy-engine-prior-attempt-binding.test.ts, tests/unit/deployment/deploy-engine-rollback-journal.test.ts; integ arm: tests/integration/sg-circular-dependency phase 1e.
• A refusal or update log no longer prints a resource name taken from a secret that has since been rotated (issue #4339) -- src/provisioning/providers/{asg,elbv2,iam-managed-policy,logs-loggroup,s3-vectors,rds-dbproxy,rds-dbproxy-endpoint,kinesis-streamconsumer}-provider.ts, src/provisioning/replacement-protection-advice.ts. After a secret rotation under an unchanged {{resolve:...}} reference, the recorded physical id names the PRE-rotation value, which this deploy's masker never resolved. The AutoScalingGroup and ELBv2 LoadBalancer deletion-protection remedies pasted it as the command's identifier, the LogGroup class-change refusal pasted the log group name with no masker at all (so even an unrotated secret-derived name printed), and the ASG / LogGroup / TargetGroup updating lines, the IAM ManagedPolicy replacement line (its ARN carries the old Path) and that replacement's inner delete lines printed it at debug level; the S3 Vectors create-only refusal and the DBProxy / DBProxyEndpoint / StreamConsumer update lines and failure texts named it too. Each site now pairs the physical id (or the name / path its ARN carries) with the recorded reference through withDerivedNameMasks, so the pasted command is withheld (the console route stays) and the lines mask it. The DynamoDB GlobalTable remedy already did this (#2177); the Cognito and EMR remedies name AWS-minted ids. Tests: tests/unit/provisioning/recorded-secret-identifier-masking-4339.test.ts.
• A Cloud Control status poll that fails with EADDRNOTAVAIL is now re-polled instead of abandoning the wait (issue #4331) -- src/provisioning/cloud-control-provider.ts, src/deployment/retryable-errors.ts. EADDRNOTAVAIL is a local-address socket failure, seen on a machine running several deploys at once (read EADDRNOTAVAIL). The poll's transport classifier did not list it, so one such failure ended the wait with "the failure is not retryable": a CREATE that Cloud Control had accepted kept running in AWS with no cdkd state record, untracked by rollback and cdkd destroy (observed with an EKS cluster). The code now joins the other socket codes, matched on the error's code or, when a wrapper dropped it, in its message, and the poll -- a read of the same request token -- is retried within the existing transient grace. It also joins the socket codes cdkd treats as an ambiguous outcome (the call may have reached the service), since its read form can follow a request that was already written. Tests: tests/unit/provisioning/cloud-control-wait-abandoned.test.ts, tests/unit/deployment/retry-ambiguous-create-replay-3978.test.ts.
• AWS::ECS::Service's VpcLatticeConfigurations[].AdvancedConfiguration now reaches AWS instead of being silently dropped (PR #4324) -- The ECS SDK provider forwards VpcLatticeConfigurations through a generic key converter, and @aws-sdk/client-ecs 3.1140.0's VpcLatticeConfiguration had no advancedConfiguration member, so the serializer discarded the block (AlternateTargetGroupArn, ProductionListenerRule, TestListenerRule) on create and update with no error. Changed: package.json / pnpm-lock.yaml (@aws-sdk/client-ecs ^3.1144.0, the first release that models the member).
• cdkd destroy --remove-protection puts a deletion guard back when the delete gives up at its attempt cap (issue #4318) -- src/cli/commands/destroy-runner.ts, src/provisioning/providers/deletion-protection-compensation.ts. The guard cdkd turned off was restored only when the delete failed terminally, so a refusal that kept reading as retryable (an IAM deny worded not authorized to perform) ran the destroy loop to its attempt cap and left the guard off on a live resource with no message. The loop now marks its last attempt (runDeleteAttempt), and any failure there is compensated: the guard is turned back on, or, on a Cloud Control delete that may already be running, the warning naming the check and restore commands is printed. The compensation also classifies a failure as the loop does, reading the cause chain: a Cloud Control delete wait abandoned over a withheld access denial was counted as final while the loop retried it, so a refusal on that retry left the guard off. A per-resource --resource-timeout still restores nothing. Tests: tests/unit/cli/destroy-runner-remove-protection-cap.test.ts, tests/unit/provisioning/providers/deletion-protection-final-attempt.test.ts, tests/unit/provisioning/{cloud-control-remove-protection-compensate,providers/logs-cognito-remove-protection-compensate}.test.ts.
• A Cloud Control-routed resource whose create-only property comes from a secret reference no longer puts that property into every update's patch (issue #4275) -- src/provisioning/cloud-control-provider.ts. State records a secret-derived value as its {{resolve:...}} expression, while update() receives the resolved value, so the JSON Patch built from the two always carried an op at that path, even though the template had not changed it. On a create-only path such as a Logs MetricFilter's FilterName that op asks Cloud Control to update a property it cannot update, and after a secret rotation it carries a value the resource does not have. Now, on a key the engine replaces on any change, the patch is left without that key when the record holds a reference and the desired value is a secret this deploy resolved. A changed literal, a missing masker and a mutable key still produce their op, as before (a key that is also write-only: see #4416). Tests: tests/unit/provisioning/cloud-control-provider.test.ts. The fixture secret-derived-immutable-names gains a secret-named MetricFilter.
• An ACM certificate or Lambda MicroVM image whose immutable value comes from a secret is updated in place again (issue #4275) -- src/provisioning/providers/{acm-certificate,lambda-microvm-image}-provider.ts. State keeps a secret-derived value as its {{resolve:...}} reference while update() receives the resolved value, so an ACM certificate whose DomainName, SubjectAlternativeNames, DomainValidationOptions, CertificateAuthorityArn or KeyAlgorithm came from a secret was REPLACED on every update (a new certificate requested and the old one deleted), and a MicroVM image whose Name did was refused on every update. Both guards now use unchangedBehindSecretReference's masker arm, on create-only keys only: neither physical id carries the value, and both providers' writes address the resource by its ARN. A real change, a recorded *** and a key the engine does not replace on (ValidationMethod) still replace or refuse as before. The MicroVM refusal now masks the resolved name it prints. Tests: tests/unit/provisioning/secret-reference-immutable-sites-acm-microvm.test.ts.
• Rolling back a same-deploy inline policy swap or hand-off no longer removes the name another revert has just put back (src/deployment/inline-policy-claims.ts, src/deployment/rollback-executor.ts, src/provisioning/providers/iam-role-provider.ts, src/provisioning/providers/iam-user-group-provider.ts, go-to-k/cdkd#4225). An AWS::IAM::Policy rename is journaled with a new physical id, so a rollback reverses it by re-creating the old policy and deleting the new one. When two policies swapped names on one role, the second reversal's delete removed the name the first one had re-created, and the role ended up with only one of the two policies. When a policy had renamed away from a name the role's own Policies took, the role's revert removed the name the policy's reversal had put back. Each rollback removal now asks, as a deploy's has since go-to-k/cdkd#4156, whether another revert of the same rollback has already put that name on that principal, reading what that revert recorded, and keeps the name when it has. This covers the rollback's deletes and updates of an AWS::IAM::Policy (a reversed rename or re-adopted replacement, an in-place revert, a rolled-back create, --revert-failed) and a role, group or user revert dropping a Policies entry. cdkd rollback shares one record across failed ops, completed ops and segments. A revert that has not run, failed, came back partial or went through Cloud Control counts for nothing, and neither does one whose record a later op replaced, so the removal proceeds. Rolling back a created policy that took an old policy's name still removes the old policy's grant (go-to-k/cdkd#4408). Tests: tests/unit/deployment/rollback-executor-inline-policy-claims.test.ts, tests/unit/provisioning/iam-principal-inline-policy-claims.test.ts, tests/unit/cli/rollback-inline-policy-claims.test.ts, tests/unit/deployment/nested-child-journal.test.ts; fixture: iam-role-policies-drift-clean (forced-rollback phase).
• cdkd deploy refuses an Export.Name holding any NoEcho: true parameter's value, whatever reads it and in any declaration order (issue #4043, Phase B) -- src/deployment/deploy-engine/outputs.ts, src/deployment/outputs-export-alias.ts (noEchoParameterValueSeed), src/analyzer/outputs-diff.ts, src/cli/commands/diff-recursive.ts. Before, the refusal counted a value only when an output value, or the Export.Name of the same or an EARLIER-declared output, read it. So a literal name spelling a value only a resource reads, a name holding a needle only a LATER Export.Name recorded (an Fn::Base64 encoding), and a name reaching this stack's value through an attribute were published as keys of state.outputs, exportNames and the exports index, in plaintext. Now the verdict is seeded with every NoEcho value the stack holds (on a nested child, each parent NoEcho value a child parameter carries), and every Export.Name is resolved before any alias is decided. A Number counts as the operator wrote it too (0x1F2A), and a refusal caused only by a NoEcho value says so in its warning. The floor is unchanged: a name equal to the value at any length, one containing it at 4 or more characters. An unrelated name that happens to contain a short NoEcho value is now refused too, the same bound secrets already take. cdkd diff previews the same verdict. Still published: another stack's value through Fn::ImportValue, a piece or encoding of the value that a resource computes and an attribute echoes, a nested child's parameter fed a parent value without a Ref (which cdkd diff refuses), a 1-3 character value inside a longer name, and a failed output's alias carried forward by a deploy with no resource change.
• A CREATE whose retry collides after an ambiguous earlier attempt now prints recovery advice instead of only the raw "already exists" (issue #3984) -- src/deployment/deploy-engine/name-collision.ts, src/deployment/retryable-errors.ts (new isReplayedNameCollisionFrom), src/provisioning/auxiliary-failure.ts (RETRY_AUXILIARY_OWNER, isAuxiliaryMarkOf), src/deployment/retry.ts. Since #3978, a collision withRetry raises after an attempt that may already have made the resource (a 5xx, a Cloud Control handler failure, an auxiliary-call failure) is withheld from the name-collision verdict so no delete-first site acts on it. The #2902 orphan advice read the same verdict and went silent, in the case it fits best: the holder is most likely this create's own resource, in no state file, so no rollback or cdkd destroy removes it. Such a collision on a cdkd-derived name now gets its own line: the earlier attempt ended without a clear verdict, so this create most likely made the resource; confirm it is yours, then cdkd import it or delete it. Advice only: the delete-first sites still read the withholding classifier. A provider-marked auxiliary collision and a template-supplied name stay silent, as before.
• A replacement or create that names an ELBv2 load balancer or target group after one that already exists is refused before anything changes, and cdkd import resolves either by its template Name (issue #3937) -- src/deployment/replacement-name-holder.ts (NAME_ADOPTING_SDK_CREATE_TYPES, replacementSentNameMoves), src/provisioning/providers/elbv2-provider.ts (import(), sentElbv2Name), docs/cli-deploy-safety.md, unit cases and target-group, load-balancer, prefix-flag and plain-create arms in tests/integration/replacement-rename-onto-holder/. CreateLoadBalancer and CreateTargetGroup return the existing resource when one of the requested name has the same settings, so a rename onto it "succeeded", deleted the stack's own resource and recorded the other one for a later cdkd destroy to delete; a plain create with an explicit Name adopted the same way. The SDK route now looks the name up first, as for the other name-adopting types: a resource found there, or a lookup that fails, fails the deploy with nothing created or deleted. The lookup asks for the name the create sends, stack-name prefix included under --prefix-user-supplied-names, and also runs when only that flag changed the sent name; a secret-derived Name is masked in the spelling the provider sends. Before, the provider's import() reported every ELBv2 load balancer and target group without a --resource override as not found, though docs/import.md listed both as resolved by their template name; cdkd import looks up the unprefixed name, and a lookup that fails is a failed row.
• --all is refused when a CDK Stage failed to load beside surviving stacks (issue #3507) -- src/cli/stack-matcher.ts (renderAllWithFailedStages), src/cli/commands/deploy.ts, destroy.ts, diff.ts and publish-assets.ts, with unit tests in tests/unit/cli/stack-matcher.test.ts, deploy-unaddressed-exit.test.ts, destroy.test.ts, diff-failed-stage-selection.test.ts and publish-assets.test.ts. A Stage whose manifest could not be read drops every stack under it from the synthesized app, so cdkd deploy --all, cdkd destroy --all, cdkd diff --all and cdkd publish-assets --all acted on the stacks that did synthesize and exited 0, with the synthesis warning as the only sign that part of the app was skipped -- a destroy left the Stage's stacks running. Each now exits 1 before any stack is acted on, with --all would <verb> only part of this app; refusing. Synthesized: <stacks>, the failed-Stage note, and the way through: fix the Stage, or name the stacks explicitly. Named stacks and patterns are unchanged, as is --all when every Stage loaded.
• A command run with no stack named no longer auto-selects the only stack that synthesized when a CDK Stage failed to load (issue #3507) -- src/cli/stack-matcher.ts (renderAutoPickWithFailedStages), src/cli/commands/deploy.ts, destroy.ts, diff.ts, publish-assets.ts, scrub.ts, import.ts, export.ts and orphan.ts, with unit tests beside each command's existing failed-Stage cases and the bare arm of tests/integration/stage-assets Phase 2g. A Stage whose manifest could not be read drops every stack under it from the synthesized app, so in an app with one surviving stack a bare cdkd deploy (or destroy, diff, publish-assets, scrub, import, export) picked that stack without a prompt, as if it were the app's only one; cdkd scrub --dry-run --fail then reported the app clean and exited 0. Each now refuses before any stack's state is read and before any lock or write, with With no stack named, cdkd would <verb> only part of this app; refusing. Synthesized: <stacks>, the failed-Stage note, and the way through -- the sentence --all gained in #4387. A bare destroy whose surviving stack had no state record printed No stacks found in state and exited 0; it refuses the same way, before the state bucket is listed. scrub exits 2 (SCRUB_AUTO_PICK_PARTIAL_APP), including a bare run where no stack synthesized at all (which exited 1, the code --fail uses for plaintext found); the rest exit 1. cdkd orphan has no auto-pick; its construct path that matches no stack now names a Stage that failed to load. Naming the stack, and a bare run when every Stage loaded, are unchanged.
• cdkd export names a CDK Stage that failed to load when stack selection comes back empty (issue #3507) -- src/cli/commands/export.ts, with unit tests in tests/unit/cli/export-stack-selection.test.ts. A stack under a Stage whose manifest could not be read is dropped from the synthesized app, so cdkd export MyStage/MyStack answered Stack 'MyStage/MyStack' not found in synthesized app, and an app whose only stacks sit under such a Stage answered Multiple stacks found: . with no argument. export now raises the message deploy, diff, list, publish-assets, scrub, import and synth print: No stacks matching <arg> found in assembly. Available: <stacks> (or The assembly has no stacks, or No stacks found in assembly with no argument), plus the failed-Stage note naming the targeted Stage or listing every failed Stage behind Possibly unrelated:. The Multiple stacks found list now shows each stack's display path beside its physical name. Every selection refusal still comes before any state is read or locked, and exit codes are unchanged. The argument is still matched exactly, and an argument containing * is told so, since the shared wording reads as a pattern match.
• cdkd scrub --all is refused when a CDK Stage failed to load beside surviving stacks (issue #3507) -- src/cli/commands/scrub.ts, through the shared renderAllWithFailedStages in src/cli/stack-matcher.ts, with unit tests in tests/unit/cli/commands/scrub-stack-selection.test.ts and the scrub arm of tests/integration/stage-assets Phase 2g. A Stage whose manifest could not be read drops every stack under it from the synthesized app, so cdkd scrub --all scrubbed the stacks that did synthesize and reported the state clean, while the Stage's stacks were never examined -- the synthesis warning was the only sign. It now exits 2 (SCRUB_ALL_PARTIAL_APP, scrub's "declined to look" code, distinct from --fail's 1) before any state read, with --all would scrub only part of this app; refusing. Synthesized: <stacks>, the failed-Stage note, and the way through: fix the Stage, or name the stacks explicitly -- the same refusal deploy, destroy, diff and publish-assets gained in #4387. --all in an app whose every stack sat under a failed Stage, refused since #3935 with exit 1, now exits 2 with the same code. Named stacks and patterns are unchanged, as is --all when every Stage loaded.
• AWS::DynamoDB::Table refuses a PointInTimeRecoverySpecification.RecoveryPeriodInDays CloudFormation rejects, before any AWS call (issue #3255) -- src/provisioning/providers/dynamodb-table-provider.ts. A period spelled " 7 ", "0x9", "1e1", null or an unresolved intrinsic used to be dropped with a warning: UpdateContinuousBackups then succeeded at DynamoDB's default period while cdkd state kept the declared value, so cdkd drift reported a difference on every run and cdkd drift --revert re-sent the same call forever. create() and update() now refuse such a value, and one outside the API's 1-35 range, with a message naming the property, before any call, so no table is created only to be deleted and nothing is recorded to drift against. A non-object PointInTimeRecoverySpecification, which was read as "PITR disabled", is refused the same way. The AWS CDK CLI cannot deploy these templates either. A rollback replay or drift --revert keeps the warn-and-drop, since their properties come from cdkd state rather than the template; an unchanged block an older cdkd recorded is not refused, since nothing is sent for it. Tests: tests/unit/provisioning/dynamodb-table-provider-cfn-integer.test.ts.
• --recreate-via-cc-api / --recreate-via-sdk-provider now recreate a target whose template did not change (issue #2651) -- new src/deployment/recreate-target-promotion.ts, src/deployment/deploy-engine/{deploy-flow,update}.ts, docs/cli-deploy-safety.md. Moving a resource between provisioning layers is not a template edit, so the diff called the target NO_CHANGE and never dispatched it: the deploy printed the consented recreate plan, then "No changes detected", and exited 0 with the record still on the old layer. A target the diff calls NO_CHANGE is now made an UPDATE before the deploy counts its changes, and the UPDATE arm's post-resolution no-op skip no longer applies to a target, so the destroy + recreate runs and the summary counts it as an update. A target this deploy deletes instead (a Condition now false), or one it has no row for, is not recreated and is warned about by name. Also documents (issue #2666) that --force-stateful-recreation reaches nested child stacks, where it both clears the stateful guard and empties a replaced S3 bucket or ECR repository. Tests: tests/unit/deployment/{recreate-target-promotion,deploy-engine-recreate-target-no-change}.test.ts; the cc-to-sdk-reroute integ gains an unchanged-template recreate phase.
• The deploy engine's stateful-replacement refusals now say when --force-stateful-recreation cannot remove the resource because AWS protects it (issue #2610, sites 9-11) -- src/provisioning/recorded-protection.ts (new), src/provisioning/protection-flags.ts (new, the protection table moved out of src/cli/commands/destroy-runner.ts), src/deployment/deploy-engine/update-replace.ts, src/deployment/deploy-engine/update-in-place.ts, src/deployment/recreate-targets.ts. The property-driven replacement refusal, both arms of the update-failure fallback refusal and the --recreate-via-* stateful refusal told the user to re-run with --force-stateful-recreation (plus --replace on one arm) even when cdkd's record of the resource carries a deletion / termination protection flag. cdkd deploy has no --remove-protection, so AWS refuses that delete: the deploy then failed at it, or completed and left the old resource and its data in AWS, untracked. When the recorded properties, or the AWS read-back cdkd stored, carry the flag, the refusal now names it and the bag it came from, says the flag alone does not remove the resource, points at "Deletion protection blocks a replacement" in docs/cli-deploy-safety.md, and asks for protection to be turned off out of band first. The flag is read through the same per-type table the cdkd destroy confirm prompt counts with, and a target under UpdateReplacePolicy: Retain gets no note. Tests: tests/unit/provisioning/recorded-protection.test.ts, tests/unit/deployment/replacement-protection-note.test.ts, tests/unit/deployment/recreate-targets.test.ts.
• cdkd state destroy now records deployment events (issue #2423) -- src/cli/commands/state.ts, src/cli/commands/destroy-runner.ts. cdkd state destroy ran the same destroy as cdkd destroy but opened no event recorder, so it wrote no deployments/{runId}.jsonl at all: its per-resource deletes, skips and suppressed safety checks left nothing for cdkd events to read once the run ended. It now records one run per destroyed stack and region, under command: destroy, with the same RUN_FINISHED result and counts cdkd destroy records (FAILED on a resource error or skip). cdkd state destroy still takes no --purge-events; cdkd events prune '<stack>' --all drops the history. The warning for an incomplete safety check now names only the nested-stack child destroy as recording nothing. Tests: tests/unit/cli/state-destroy.test.ts, tests/unit/cli/destroy-runner-guard-indeterminate.test.ts; integ s3-lifecycle phase 0c-OK.
• cdkd destroy --remove-protection restores DisableApiTermination on the EC2 instances an Auto Scaling group launched when the group's delete then fails terminally (issue #2204) -- src/provisioning/providers/asg-provider.ts and the shared settleProtectionFlip in src/provisioning/providers/deletion-protection-compensation.ts, with unit tests in tests/unit/provisioning/providers/asg-instance-remove-protection-compensate.test.ts and a live arm in the remove-protection-compensation integ (the destroy runs under a role denied UpdateAutoScalingGroup on the group, so its prevent-all-deletion refuses the delete after the instance flip). Before, the group delete turned each launched instance's termination protection off (issue #796) and never put it back, so a failed destroy left the instances live with the guard stripped. Now each instance whose guard a pre-flip DescribeInstanceAttribute saw on, and this run turned off, is turned back on before the failure is reported, under the same rules as every other --remove-protection site: only on a terminal failure, never once AWS has accepted the group delete, and a failed re-enable is its own log line with a pasteable aws ec2 modify-instance-attribute command. The flip now also needs ec2:DescribeInstanceAttribute; a refused read leaves the delete running and compensates nothing.
• A provider's own log lines now mask the resource's resolved secrets at the logger itself (issue #2177) -- src/utils/logger.ts, src/utils/log-line-masker.ts, src/deployment/resource-secrets-scope.ts. A provider's debug / info / warn / error line reached no engine masking, so a {{resolve:...}} secret (or a NoEcho parameter value) it interpolated printed in plaintext unless that one call site threaded the masker, and about 256 such sites had not. ConsoleLogger now masks every line emitted during a provider create or update with that resource's secret bag, on the live terminal and in the per-stack output buffer of a multi-stack deploy alike. The message is masked before terminal sanitizing, and each string inside an extra log argument before it is JSON-escaped. Lines outside a provider call, and every command that binds no bag, are unchanged and pay one async-context read. Not covered here: names a provider derives from a secret (still masked per site), and delete() paths, which bind no bag (#2007). Tests: tests/unit/utils/logger-sink-secret-mask.test.ts.
• An EMR cluster, instance fleet or instance group create that hits a 5xx now reports candidate orphans instead of duplicating silently (issue #2080, Plan C: EMR) -- src/provisioning/providers/{emr-cluster,emr-instance-fleet-config,emr-instance-group-config}-provider.ts, src/provisioning/providers/orphan-report.ts (renamed from apigateway-orphan-report.ts, now shared), docs/troubleshooting.md. RunJobFlow, AddInstanceFleet and AddInstanceGroups mint their id and carry no idempotency token, so a 5xx whose request had succeeded left a second cluster (or TASK fleet / group) billing per instance-hour with no state record. These creates no longer let the AWS SDK retry a 5xx inside one call; the 5xx reaches cdkd's retry, which first lists what the failed attempt may have made and warns about each match created during that attempt: a live cluster of the same name, or a TASK fleet / group of the same name (any name when the template sets none) in the same cluster. Each match comes with a read command, then a command to run only after confirming: terminate-clusters (with a note to turn termination protection off first when the template turns it on and the candidate shows it), or a scale to zero for a fleet / group, which EMR cannot remove. Nothing is adopted, terminated or scaled. A cluster holds at most one MASTER and one CORE, so those trigger no lookup; nor does a throttle, a 4xx or IAM propagation. The lookup needs elasticmapreduce:ListClusters (clusters); without it cdkd warns and the create proceeds. A reset connection or timeout after the send is still retried inside the SDK and not reported (#3978 layer (b)). Tests: tests/unit/provisioning/emr-create-retry-2080.test.ts.
• The error-cause critic now scans all of src/, and four more wrappers keep the AWS / docker error they caught (issue #2075) -- scripts/check-provider-error-cause.ts, src/utils/error-handler.ts, src/assets/docker-asset-publisher.ts, src/local/ecr-puller.ts, src/local/ecs-task-runner.ts. The retry classifiers find a throttle or a 5xx by walking an error's .cause, so a wrapper that drops the caught error is classified on its message alone. The critic used to check only src/provisioning/providers; it now defaults to src/. A cause DERIVED on purpose (redactedDockerCause, normalizeAwsError, maskSecretsInError) is accepted only when imported from its own module, and a runtime test proves each one keeps the classifier verdict. The three deliberate omissions (two local file reads, one re-branded cdk-local error) are listed by name with an exact count. Fixed along the way: normalizeAwsError now chains the original SDK error under the message it rewrites, so an S3 Unknown HTTP 503 on the state bucket reads as transient and keeps its request id; and the cdkd local ECR pull / login / AssumeRole and ECS re-tag failures now carry their cause. Tests: tests/unit/scripts/provider-error-cause.test.ts, tests/unit/scripts/cause-composers-classify.test.ts.
• cdkd export imports an HttpApi's AWS::ApiGatewayV2::Stage in place instead of deleting it and letting CloudFormation re-create it (issue #1772) -- src/cli/commands/export.ts, docs/cli-export.md, the export integ fixture and the export unit tests. The stage sat in IMPORT_UNSUPPORTED_RECREATABLE_TYPES because CloudFormation once refused it in IMPORT changesets, so every export of a stack with an HttpApi (CDK auto-emits a $default stage) pre-deleted the stage between the two phases and left the API serving no stage for roughly ten seconds until phase 2 re-created it. The registry now reports the type FULLY_MUTABLE with a read handler and a [ApiId, StageName] primary identifier, and AWS's import-support table lists it as importable, so the stage leaves that list and its pre-delete handler, and joins COMPOSITE_ID_SPLITTERS: the bare StageName the SDK provider records is paired with the recorded ApiId, and Cloud Control's <apiId>|<stageName> is split. Neither field is read-only, so the whole identifier map is overlaid. --no-recreate-import-unsupported no longer applies to the stage, and the by-hand recovery after a failed pre-delete no longer prints aws apigatewayv2 delete-stage.
• A multi-replica AWS::DynamoDB::GlobalTable whose template declares no StreamSpecification now records the stream cdkd enables for it, and an update no longer re-sends a stream the table already has (issue #1723) -- src/provisioning/providers/dynamodb-globaltable-provider.ts (replicationImpliedStreamSpecification, create()'s needsStream arm, update()'s stream arm and its end, a new canonicalizeDesiredProperties), a new unit file and the dynamodb-globaltable-implied-stream integ fixture. create() enables a NEW_AND_OLD_IMAGES stream where the template is silent, but state recorded none. That was not phantom drift, but declaring the same stream later diffed as an UPDATE, and update() sent StreamEnabled: true for a live stream (a stream change the CloudFormation docs allow only on a single-replica table). Now create() records the stream, update() re-records it when the live table confirms it, and the twin folds it into both diff sides, so older records diff NO_CHANGE too. update() also skips the stream when the table already holds the declared view type, which covers older records and a rollback of a two-to-one replica change. Only the region-independent case (more than one replica, no MultiRegionConsistency declared) is recorded. A single replica outside the deploy region still records nothing, though the live check keeps a later declaration of its stream from being re-sent. Such a record that later moves to Cloud Control (a template adding a property cdkd's provider does not handle) now fails that update, since the patch asks to remove the recorded stream; the template is one CloudFormation rejects.
• AWS::CertificateManager::Certificate: removing CertificateTransparencyLoggingPreference from the template now resets it to ENABLED (issue #1160) -- src/provisioning/providers/acm-certificate-provider.ts. Before, the removal was silently dropped: UpdateCertificateOptions keeps an absent option, so a certificate opted out of transparency logging stayed opted out while cdkd diff reported no changes. CloudFormation documents the removal as the same as declaring ENABLED, so the provider now declares that reset through removalDefaults. CertificateExport cannot be updated after a certificate is created; the deploy already replaced the certificate on its change or removal (a createOnly property), and the provider's own update() now does the same instead of sending an Export ACM rejects or dropping the removal. The type is also audited into removalHandledInUpdate, so a removed property cdkd does not handle is warned about. Tests: tests/unit/provisioning/acm-certificate-provider.test.ts.
• Removing an optional setting from an RDS DB proxy now warns that the live value is kept, instead of passing silently (issue #1160) -- src/provisioning/providers/rds-dbproxy-provider.ts. Dropping Auth, RequireTLS, IdleClientTimeout, DebugLogging or VpcSecurityGroupIds from an AWS::RDS::DBProxy reported a successful update while the proxy kept its old value, because ModifyDBProxy keeps any setting it is not sent. cdkd still sends no reset, since CloudFormation's published DBProxy handler forwards the same omission, but the update now prints one warning naming each removed property and how to change it (a rollback revert words it as the state being restored), and a removal alone no longer issues an empty ModifyDBProxy call. cdkd drift --revert warns about nothing. Tests: tests/unit/provisioning/rds-dbproxy-provider.test.ts.
• EMR Cluster / InstanceFleetConfig: a property removed from the template that cdkd leaves in place is now named in a warning instead of being silently dropped, and no longer issues an empty ModifyCluster / ModifyInstanceFleet (issue #1160) -- src/provisioning/providers/emr-cluster-provider.ts, src/provisioning/providers/emr-instance-fleet-config-provider.ts. Both APIs keep a field they are not sent, and cdkd sends no reset for these removals. Before, removing a cluster's StepConcurrencyLevel, or a fleet's ResizeSpecifications or InstanceTypeConfigs, reported a successful update while AWS kept the old value, and when the removal was the only change cdkd still sent the Modify call (for a fleet, followed by a resize wait). Now the provider sends nothing for such a removal and names it in one warning per resource after a successful update, with no claim about what CloudFormation would do (both types declare removalHandledInUpdate, so the shared caller adds no second line). A removed fleet capacity is still sent as 0, and the cluster's other removals (VisibleToAllUsers, the scaling and auto-termination policies, Tags) are applied as before. Tests: tests/unit/provisioning/providers/emr-cluster-provider-removal-1160.test.ts, tests/unit/provisioning/providers/emr-instance-fleet-config-provider-removal-1160.test.ts.
• FSx FileSystem: a property removed from the template is now named in a warning instead of being silently dropped, and no longer issues an empty UpdateFileSystem (issue #1160) -- src/provisioning/providers/fsx-filesystem-provider.ts. UpdateFileSystem keeps a field it is not sent, and cdkd sends no reset for these removals. Before, removing StorageCapacity, StorageType, FileSystemTypeVersion, NetworkType or a mutable <Variant>Configuration sub-property (Lustre DataCompressionType / AutoImportPolicy, a Windows FsrmConfiguration, ...) reported a successful update while AWS kept the old value, and when the removal was the only change cdkd sent an UpdateFileSystem carrying no update field. Now the provider names every such removal, top-level and sub-property, in one warning per resource after a successful update, sends none of them, and makes no claim about what CloudFormation would do (the type declares removalHandledInUpdate, so the shared caller adds no second line). A removed RouteTableIds is still applied as a RemoveRouteTableIds delta, and a removed Tags still untags. Tests: tests/unit/provisioning/providers/fsx-filesystem-provider.test.ts.
• A property removed from the template is reset through a provider declaration, and a removal cdkd does not reset is now named in a warning instead of passing silently (issues #1160, #4362) -- src/provisioning/update-removal.ts, src/types/resource.ts, src/deployment/deploy-engine/update-in-place.ts, src/deployment/rollback-executor.ts, src/cli/commands/drift.ts, the Lambda / IAM Role / ASG / ECS Service / RDS / Neptune / DocDB / ElastiCache / CloudTrail / Secrets Manager / Cloud Map namespace providers, src/deployment/deploy-engine/observed-capture.ts. A provider now declares removalDefaults (the CloudFormation default sent when a property disappears from the template); the deploy's in-place update and both rollback revert arms compute the removed properties once, template against template, and inject those values into the bag the provider receives, while state keeps the template. The constant resets those providers already sent move into the declaration unchanged; coerced, aliased, nested and conditional resets stay in the provider. A type whose update path is fully audited (removalHandledInUpdate: Lambda Function, IAM Role, the three Cloud Map namespaces) gets one warning per resource for a removed property cdkd leaves in place, e.g. Lambda RecursiveLoop. drift --revert injects nothing: its previous side is an AWS readback. No AWS call is added. The post-create / post-update observed-state readback now runs inside the resource's secret scope, so its log lines are masked (#4362). Tests: tests/unit/provisioning/update-removal.test.ts, tests/unit/deployment/deploy-engine-removal-defaults.test.ts, tests/unit/deployment/observed-capture-secret-scope.test.ts, plus rollback / drift / Lambda cases.