[IAmJSD]

Root cause

Deleting an editor-managed plan is refused (409 managed_plan_has_live_executions) while any execution may hold or buy capacity. requireManagedDeleteTx counts a failed row without a no_submission proof as live, because its outcome is unknown and it can still be retried (a retry of a row detached from a deleted plan would buy with no plan). Nothing could ever change that row: failed rows are never pruned, and the retry link isn't consulted. So even after a retry of the row completed, the plan could never be deleted, only disabled.

Fix

As the issue asks, this adds an explicit, audited operator action and leaves delete without a flag. Delete still fails closed on an unknown outcome until a named person has accounted for it.

• Migration 000143: purchase_executions.outcome_settled_at, outcome_settled_by (TEXT, so the audit survives user deletion and records the admin API key sentinel) and outcome_settlement (the complete fixed-format record), with a CHECK that the three are set together. 134 to 139 are taken by open PRs, and 140 to 142 by open PRs fix(recommendations): key stored recs, rec ID and purchase identity on RDS az_config (#408) #1239 and perf(api): page recommendations from an ID-ordered keyset scan instead of the full list #1240. Gaps are expected (previousMigrationVersion).
• SettleFailedExecution (internal/config/store_postgres_execution_settle.go):
  • Accepts only a failed plan execution with no no_submission proof. Any other status, a no_submission row, an ad-hoc row or a row whose plan is gone gets 409.
  • Requires Acknowledge and a reason, and stores operator:settled_unknown_outcome: ack=true chain_tail=<id> tail_status=<status> reason="...".
  • Locks the plan FOR SHARE, then the row FOR UPDATE, then its retry-chain tail FOR UPDATE. That's the same plan-first order as DeletePurchasePlan and the editor command footprint. It re-checks plan_id under the locks.
  • Refuses while the chain may still buy: a tail outside the terminal allowlist (pending, running and so on), a failed tail that can still be retried (unknown outcome and not itself settled), or a chain past LadderChainMaxDepth.
  • An identical repeat by the same actor replays (200, replayed: true). A different one gets 409.
• What settling does not do: it never changes status and never makes the row count as unbought. holdsCapacity, the ramp ledger (ListPlanCommittedTx), ramp_ledger_holds and the retention trigger are untouched, so a possibly-submitted purchase is never hidden or re-bought. The row stays failed in History after the plan is deleted (plan_id is set to NULL, as for completed rows today). RecoverReapedExecution can still record a late completion over it.
• requireManagedDeleteTx skips a settled failed row (blocksManagedDelete). Every other classification is unchanged.
• LinkRetryExecutionAtomic also requires outcome_settled_at IS NULL, so a settled row can never be retried. Retry's lost-race 409 now reads "already retried or settled; reload it".
• POST /api/purchases/{id}/settle, body {"reason": "...", "acknowledge_unknown_outcome": true}:
  • Requires execute:purchases (admin:* alone is not enough, matching the separation-of-duties carve-out) and account access to the execution (out of scope gets 404).
  • Checks the grant's constraints with StrictScope against what the execution would have bought: its recommendations' providers, services, regions and total commitment, plus its accounts. Any dimension the execution leaves unknown requires an unconstrained grant.
  • The reason must be 10 to 300 characters with no control characters. Unknown fields are rejected.
  • Logs purchase execution settled by operator with the actor, the credential kind and the stored record.
• known_issues/resolved/35_legacy_guard_followups.md: the feat(plans): settle a failed-with-submission row so a managed plan can be deleted #999 entry is marked resolved. Its other entry (fix(cleanup): give the cleanup lambda the live-status guard CleanupOldExecutions has #998) was handled by PR fix(cleanup): only delete settled executions when their TTL lapses #1173, which is now on main, so the doc's audit status reads 0 needs triage · 2 resolved and the doc moved to known_issues/resolved/ in the merge of main.

Closes #999

Verification

All of this ran locally on macOS against a real Postgres in Docker (testcontainers). It is unit and integration evidence, not real-cloud evidence. Tests ran with AWS_CONFIG_FILE=/dev/null AWS_SHARED_CREDENTIALS_FILE=/dev/null because this machine's default AWS profile is invalid.

go build ./...
go test -tags integration -count=1 ./internal/config/                                   # ok (full package, 24s)
go test -tags integration -count=1 -run 'Retry|Managed|Settle|Delete|Reschedule|Resume' ./internal/api/   # ok
go test -tags integration -count=1 -run 'TestMigration_PurchaseExecutionsOutcomeSettlement' ./internal/database/postgres/migrations/  # ok
go test -count=1 ./internal/api/ ./internal/config/ ./internal/mocks/ ./internal/purchase/   # ok
go vet ./internal/api/ ./internal/config/ ./internal/database/...   (also with -tags integration)
golangci-lint v2.10.1 run --build-tags integration ./internal/api/... ./internal/config/... ./internal/database/...   # 0 issues (and without the tag)
gocyclo -over 10 -ignore "_test\.go" internal/api internal/config   # silent
bash scripts/gosec-hook.sh <changed .go files>   # clean
npx markdownlint-cli@0.47.0 known_issues/35_legacy_guard_followups.md   # clean (before the move to resolved/)
git-secrets (fresh repo, isolated HOME, changed files git-added, planted AKIA key flagged, clean once removed); scripts/test-git-secrets-allowlist.sh   # 137 PASS, 0 FAIL

New tests:

• internal/config/store_postgres_execution_settle_integration_test.go
  • TestSettleFailedExecutionLetsManagedDeleteProceed reproduces the issue scenario: a failed row whose retry completed blocks the delete. After a settle, the delete proceeds, the row is still failed and not no_submission, the audit survives, and ListPlanCommittedTx returns exactly the same ledger before and after.
  • TestSettleFailedExecutionRefusals covers completed, pending, canceled, failed+no_submission, retry tails pending/running/failed, no plan, not found, and no ack/actor/reason. None of them writes anything.
  • TestSettleFailedExecutionChainOfUnknownOutcomes checks that the head is refused while its failed tail can still be retried, and that the delete stays blocked until both are settled.
  • TestSettleFailedExecutionReplayAndRetry covers the replay, the 409 on a different reason, and the retry CAS refusing a settled row.
  • Races, each queued on a real lock and asserted via pg_stat_activity:
    • TestSettleWaitsForRetryAndRefusesItsLiveSuccessor: a retry linked first; the settle waits on the row lock, then refuses the pending successor.
    • TestSettleWaitsForDeleteAndRefusesDetachedRow: a delete holding the plan lock commits first; the settle waits on FOR SHARE, then refuses the detached row.
    • TestDeleteWaitsForSettleAndSeesIt: a delete queued behind a settle sees the committed settlement.
• internal/api/handler_execution_settle_integration_test.go
  • TestSettleUnblocksManagedPlanDeleteOverHTTP: delete 409, then POST /api/purchases/{id}/settle through HandleRequest (routing and CSRF) returns 200, then delete succeeds.
  • TestSettleAuthorizationAndValidation: admin without execute gets 403, out of account scope gets 404, execute constrained to another account or provider gets 403, a missing ack, short reason or unknown field gets 400, and a completed row gets 409. A refused settle writes nothing. Execute constrained to the plan's account succeeds.
• Unit tests: TestBlocksManagedDelete, TestSettlementRecordReplayMatchesOnlyTheSameReason, TestDecodeExecutionSettle, TestMapExecutionSettleError, plus the migration up/down/CHECK test.

Fail-before / pass-after (mutation probes on this branch, each reverted afterwards):

Mutation	Failing test(s)
guard ignores settlement (the pre-fix behavior)	...LetsManagedDeleteProceed, ...ChainOfUnknownOutcomes, TestDeleteWaitsForSettleAndSeesIt
retry CAS ignores settlement	...ReplayAndRetry
no plan_id re-check under the locks	TestSettleWaitsForDeleteAndRefusesDetachedRow
no plan FOR SHARE lock	TestSettleWaitsForDeleteAndRefusesDetachedRow
retryable failed tail allowed	...Refusals, ...ChainOfUnknownOutcomes
status check removed	...Refusals
handler skips constraints / account access / uses view instead of execute	TestSettleAuthorizationAndValidation

On main, TestDeleteManagedPlanByExecutionStatus/failed already shows the permanent 409, and no operation existed that could clear it.

Coverage gaps: nothing here touches a real cloud account. The operator's cloud-side check stays a human step, recorded only as the free-text reason and the acknowledgement. The full internal/api integration package was not run, only the subset above.

Out of scope

• The delete 409 still doesn't name the blocking execution ids. An operator finds them in History (failed rows of the plan). Adding blocking_execution_ids to the refusal details would be a small follow-up.
• History/execution GET responses don't expose the settlement columns yet. The settle response and the server log carry them.
• No structured cloud check (account/region/service/checked_at), unlike the ladder resolve, because a plan execution can span several services and regions. The reason field carries it.

Frontend follow-up for the UI owner

• On a 409 managed_plan_has_live_executions from plan delete, explain that failed purchases with an unknown outcome must be settled first, and link to the plan's failed executions in History.
• In History, for a failed plan execution that isn't no_submission, offer Settle next to Retry. It should open a confirm dialog that asks for a reason (10 to 300 characters) and a required "I checked the cloud account; this may have been bought, and it will never be retried" checkbox. It then sends POST /api/purchases/{id}/settle with {"reason", "acknowledge_unknown_outcome": true}. On 409, show the message (for example, a retry is still pending).
• Once settled, hide Retry for that row. That needs the settlement fields on the History payload (see the out-of-scope note above).

Maintainer: please mirror the issue's triage labels onto this PR: priority/p2, severity/medium, triaged, urgency/this-quarter, impact/few, effort/m, type/feat.

Known unrelated CI failure: govulncheck (GO-2026-6809) until #1236 merges.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[IAmJSD]

Merged origin/main (at a14dc8f) to resolve the conflict in known_issues/35_legacy_guard_followups.md. There are no review findings on this PR yet, so the merge is the only change.

How it was resolved

• known_issues/35_legacy_guard_followups.md: both sides changed the audit-status line. Main's fix(cleanup): only delete settled executions when their TTL lapses #1173 marked the fix(cleanup): give the cleanup lambda the live-status guard CleanupOldExecutions has #998 entry resolved and this PR marks the feat(plans): settle a failed-with-submission row so a managed plan can be deleted #999 entry resolved. Both entries are now resolved, so the line reads 0 needs triage · 2 resolved (dated 2026-10-23). As the PR body said, the second of the two to merge moves the doc, so it is now at known_issues/resolved/35_legacy_guard_followups.md. Both entries' text is kept as-is. The PR body now describes the move.
• internal/api/handler_purchases.go, internal/api/router.go and internal/config/store_postgres.go merged without conflicts. I read main's changes to them (fix(purchase): fail a plan step's root row atomically with its reason and suppression release #1176 TransitionExecutionStatusPinnedTx/executionQuerier, fix(config): lock a deleted account's plans before disabling them #1087 account-delete plan locks, fix(api): apply the RI exchange history limit after the account filter #1169 RI-exchange history, sec(api): bound update-any by its Constraints on planned-purchase run #1192/fix(api): bound update-any by its Constraints on planned-purchase DELETE #1097 update-any constraints, sec(api): enforce CSRF on PATCH and every other non-safe method #1104 CSRF). None of them touch LinkRetryExecutionAtomic, the retry 409 or the /settle route. Retry is still the only writer of retry_execution_id.
• fix(auth): require every requested AccountIDs/Providers/Services value to be permitted #1163 (all-match AccountIDs/Providers/Services constraints) applies to the settle handler's requirePermissionConstraints call, which passes every account of the execution. A grant constrained to some of those accounts is now refused. That is stricter, and it matches this PR's intent.
• Migration stays 000143. Main's highest is 000134.

git diff origin/main...HEAD lists the same 14 files as before the merge.

New head: ee85e18

Verification on the merged tree (Linux, Go 1.26.9, AWS_CONFIG_FILE=/dev/null AWS_SHARED_CREDENTIALS_FILE=/dev/null)

• go build ./...; go vet of ./internal/api/ ./internal/config/ ./internal/database/... with and without -tags integration: clean
• go test -count=1 of ./internal/api/, ./internal/config/, ./internal/mocks/, ./internal/database/postgres/migrations/ and ./internal/purchase/: ok
• go test -tags integration -count=1 ./internal/config/: ok (232s). I skipped TestPostgresStoreDB_ResolveStaleRIExchange_ValidatesCloudCheck, which already fails on main and is fixed in fix(config): compare resolve checked_at at the database's microsecond precision #1252.
• ./internal/database/postgres/migrations/ integration: TestMigration_PurchaseExecutionsOutcomeSettlement and TestMigrations_DownAllRoundTrip pass. The full package does not finish within -timeout 20m on this shared machine (each migration test takes about 50s).
• ./internal/api/ integration: every top-level test matching Retry|Managed|Settle|Delete|Reschedule|Resume|UpdateAny (38 tests) passes, including TestSettleUnblocksManagedPlanDeleteOverHTTP and TestSettleAuthorizationAndValidation. I ran them in batches to stay under 20m. Three subtests (TestDeleteManagedPlanByExecutionStatus/notified, /scheduled and TestRetry_RefusesSettledLadderTranche/completed) first failed to start their container (testcontainers reaper unexpected container status "removing" on the shared Docker host). All three passed on rerun. The full internal/api integration package was not run.
• golangci-lint v2.10.1 on ./internal/api/... ./internal/config/... ./internal/database/..., with and without --build-tags integration: 0 issues
• gocyclo -over 10 -ignore "_test\.go" on the changed non-test files: silent. scripts/gosec-hook.sh on them: clean.
• git-secrets: fresh repo with an isolated HOME and the 14 changed files git-added: clean. A planted AKIA key was flagged. scripts/test-git-secrets-allowlist.sh: 137 PASS, 0 FAIL.
• Not run: markdownlint (not available offline here). Only the audit-status line and the file path of the Markdown doc changed.

Known unrelated CI failure: govulncheck (GO-2026-6809) until #1236 merges.

[cristim]

Independent review 2 (claude-fleet, cold): REQUEST_CHANGES a190e55

Findings:

• One blocking finding has been reported privately to the maintainers.
• [non-blocking] internal/config/store_postgres_execution_settle.go:209 (replaySettlement) - No test covers the actor half of the replay check.
  • Removing *t.settledBy != req.Actor || (M4) passes every test.
  • If it regressed, a second operator sending the same reason would get 200 replayed:true instead of the promised 409.
  • Nothing is written, so the impact is audit confusion only.
• [non-blocking] settle.go:168 (lockSettleChainTail) - No test covers the retryID != nil "chain changed while settling" refusal (M7 survives).
  • The window is narrow, because only the tail is locked.
  • Losing this check would let a settle record a stale chain_tail while a newer successor is live.
• [non-blocking] settle.go:21/108 vs handler_execution_settle.go:20/151 - The handler allows up to 300 characters, but the store allows up to 1000 bytes.
  • A 300-character reason in 4-byte runes (1200 bytes) passes the handler and then gets a 400 that says "1 to 1000 bytes".
  • The two limits should use the same unit.
• [non-blocking] settle.go:149 (checkSettleTarget) - Settle works on a failed row of any plan, not only an editor-managed one (DatesManaged).
  • On a non-managed plan it unblocks nothing, and only removes Retry permanently.
  • Restrict it, or state in the PR that this is intended.

Attacked:

• The settle transition runs in one transaction. The lock order is:
  1. the plan FOR SHARE;
  2. the row FOR UPDATE, with a plan_id re-check;
  3. the tail FOR UPDATE;
  4. a CAS UPDATE WHERE outcome_settled_at IS NULL.
  • Status, no_submission, settledAt and the tail are all judged under those locks.
  • Retry: LinkRetryExecutionAtomic is the only writer of the retry link (store_postgres.go:1201, with one caller at handler_purchases.go:2633). Under READ COMMITTED it re-evaluates outcome_settled_at IS NULL after the settle commits, so whichever side commits first wins.
  • Re-drive only claims approved rows (manager.go:620).
  • The reaper only CASes running and approved rows. Its follow-up annotation (reaper.go:283) and RecoverReapedExecution both go through SavePurchaseExecutionTx, whose DO UPDATE SET covers neither plan_id nor the settlement columns (store_postgres.go:1096-1120). So a late completion over a settled, detached row still records the money and keeps the audit stamp.
  • Ladder executions have no plan_id, so settle refuses them (409).
• Outcome recording:
  • Status and no_submission are untouched.
  • holdsCapacity, ramp_ledger_holds and the retention trigger are unchanged.
  • DeletePurchasePlan drops suppressions only for pending, notified and paused rows (store_postgres.go:900-910). So a settled failed row keeps its suppressions and its ledger spend.
  • The test asserts the ledger is identical before and after the settle.
• The delete gate: blocksManagedDelete skips only a settled failed row. Unsettled failed rows, including the chain head, keep blocking (ChainOfUnknownOutcomes).
• Migration 000143:
  • Up and down are symmetric: 3 columns plus an all-or-none CHECK.
  • Main is at 000134. The open chain is 135-139, then fix(recommendations): key stored recs, rec ID and purchase identity on RDS az_config (#408) #1239's 140/141 and perf(api): page recommendations from an ID-ordered keyset scan instead of the full list #1240's 142.
  • There is no collision, but this must merge last.
• Mutation probes on a scratch copy, each restored and confirmed identical with cmp:
  • M1, the guard ignores settlement: 4 tests FAIL.
  • M2, the retry CAS ignores settlement: ReplayAndRetry FAILS.
  • M3, a retryable tail allowed: Refusals and Chain FAIL.
  • M4, replay ignores the actor: survives (gap above).
  • M5, no plan FOR SHARE: WaitsForDelete FAILS.
  • M6, no_submission allowed: Refusals FAILS.
  • M7, the chain-changed check off: survives (gap above).
  • M8, the handler skips constraints: AuthorizationAndValidation FAILS.
• Fail-before: on base, the new store tests do not compile, and TestDeleteManagedPlanByExecutionStatus/failed passes, which confirms the permanent 409.

Verified locally, with GOTOOLCHAIN=go1.26.10 and no cloud credentials, under the heavy lock, on testcontainers:

• go build ./... and go vet on api, config and database, with and without -tags integration: OK. gofmt: clean.
• go test -count=1 on api, config, mocks, purchase and migrations: ok.
• Integration tests: ok.
  • config: Settle|ManagedDelete|LinkRetry|RecoverReaped.
  • api: TestSettle|TestDeleteManagedPlanByExecutionStatus|TestRetry.
  • migrations: TestMigration_PurchaseExecutionsOutcomeSettlement (up/down/up) and TestMigrations_DownAllRoundTrip.
  • All 7 store settle tests and both HTTP settle tests pass.
• git merge-tree --write-tree origin/main <head>: clean.

Reviewed by an independent agent with no author context (second reviewer). Review only: nothing was pushed, and the GitHub review state is unchanged.

[IAmJSD]

Independent review (IAmJSD's agent, fresh context, given only the diff, the issue and the PR text): VERDICT: APPROVE a190e552c908a1077ca954e01449534e372d694e

Blocking:

• none

Non-blocking:

• Merge conflict with main. The PR is CONFLICTING. git merge-tree shows one conflict, in internal/api/handler_purchases.go: main's chore(api): remove dead submit-dedupe code and lock the retry-successor path #1217 moved the body of persistRetrySuccessorTx into writeRetrySuccessorTx. The resolution should carry the "already retried or settled" 409 text into main's new location. The authoritative guard is the outcome_settled_at IS NULL predicate in LinkRetryExecutionAtomic (store_postgres.go), which merges cleanly. The new head needs a fresh review.

• Migration 000143 up (000143_purchase_executions_outcome_settlement.up.sql:19): ADD CONSTRAINT ... CHECK validates every row while holding ACCESS EXCLUSIVE on purchase_executions. All rows are NULL, so it passes, but it is a full scan under the strongest lock. ADD CONSTRAINT ... NOT VALID followed by VALIDATE CONSTRAINT would avoid that if the table is large in any deployment. The number (143) matches the reservation for feat(plans): settle a failed-with-submission row so a managed plan can be deleted #1241. Up, down and re-up are covered by the migration test and pass.

• Rolling deploy. Until every instance runs the new LinkRetryExecutionAtomic, an old instance could still retry a row that a new instance just settled. The window is small and requires both actions at once. Noting it, not blocking.

• Reason length mismatch (internal/api/handler_execution_settle.go:20 vs internal/config/store_postgres_execution_settle.go:21): the handler allows 300 runes, but the store caps the reason at 1000 bytes. A 300-character reason of 4-byte runes (e.g. emoji or CJK extension characters) passes the handler and then gets the store's 400 "reason must be 1 to 1000 bytes". It's harmless, but the two limits should agree.

• No 4-eyes on settle. One execute:purchases holder can settle a row, which permanently retires it from retry and lets the managed plan be deleted. This moves no money, but it is a policy choice. I've flagged it for the acting owner.

• History doesn't show the settlement yet (out of scope, per the body). The UI will still offer Retry on a settled row, and that click returns the new 409.

• (From an earlier review, which I agree with.) checkSettleTarget accepts a failed row of any plan, not only an editor-managed one. On a non-managed plan, settling unblocks nothing and only removes Retry for good. Either restrict it to dates_managed plans or say in the PR that this is intended.

• (From an earlier review.) No test covers the actor half of replaySettlement (*t.settledBy != req.Actor) or the "retry chain changed while settling" refusal in lockSettleChainTail. Each is a one-test gap.

• An earlier review on this same head (cristim, 2026-10-25) says one blocking finding was reported privately to the maintainers. I could not see it, so this approval does not cover it. That finding needs to be resolved before merge.

Attacked:

• Money/guard paths. I read requireManagedDeleteTx/blocksManagedDelete: only an operator-settled failed row stops blocking, and every other classification is unchanged. holdsCapacity, the ramp ledger and the retention paths are untouched, which the integration test asserts (ListPlanCommittedTx unchanged across the settle).
• Other ways out of failed. I grepped for paths that move a row out of failed: only the retry CAS and RecoverReapedExecution (failed to completed, which is harmless), so the CAS predicate is enough to stop a settled row from being bought again.
• Retry atomicity. The retry inserts the successor and links it in one tx, so a settled row makes the link match 0 rows and the successor is rolled back.
• Lock order. plan FOR SHARE, then row FOR UPDATE, then tail FOR UPDATE. This is compatible with the delete (plan lock first) and the retry (row only), and the three race tests queue on real locks.
• Authorization. execute:purchases (admin alone is refused), requireExecutionAccess, then StrictScope constraint sets with the execution's accounts. Ad-hoc rows, no_submission rows and rows whose plan is gone are refused.
• Fail-before. In my scratch checkout I reverted blocksManagedDelete's settled branch and the CAS predicate, then ran -tags integration -run 'TestSettle|TestDeleteWaitsForSettle' ./internal/config/. Four tests failed: LetsManagedDeleteProceed, ChainOfUnknownOutcomes, ReplayAndRetry and TestDeleteWaitsForSettleAndSeesIt. I restored the PR's code afterwards.
• Commands. go build ./...; go vet with and without -tags integration on internal/{api,config,database/...}; go test -race -short -count=1 on the same packages, ok; go test -race -tags integration -count=1 on ./internal/config/ (180s), ./internal/database/postgres/migrations/ (177s) and the full ./internal/api/ (258s), all ok; golangci-lint v2.10.1 with and without the integration tag, 0 issues; gocyclo -over 10 on the changed non-test files, silent.

Body-stale:

• "134 to 139 are taken by open PRs": 134 to 139 are on main now (main is at 000139).
• "the doc moved to known_issues/resolved/ in the merge of main": on main the doc is still at known_issues/35_legacy_guard_followups.md. This PR is what moves it.
• "Known unrelated CI failure: govulncheck (GO-2026-6809) until fix(deps): bump Go to 1.26.10 for GO-2026-6809 #1236 merges": fix(deps): bump Go to 1.26.10 for GO-2026-6809 #1236 has merged.
• "The full internal/api integration package was not run": I ran it at this head and it passes.

_{Reviewer: rB27. Bar while the maintainers are away (set by IAmJSD as acting owner): one approving independent review on the head, two for money, auth and security paths.}

[IAmJSD]

Migration renumbering needed before this merges. The reviewed, ready PRs have taken 000140-000145 so they could merge without waiting on owner decisions: #1240 (000140), #1302 (000141), #1268 (000142), #1287 (000143), #1289 (000144), #1116 (000145). This PR's migration(s) (000143) must be renumbered to start at 000146, or the next free number at that time, when it's ready to merge (000143 -> 000146 or the next free number). golang-migrate skips a version below the database's current one, so a lower number merged after those would never apply.

Dependency check: none of the six ready migrations touches purchase_executions, so the order doesn't matter beyond the number. That ordering hasn't been run.