chore: bump PAYMENTS_VERSION to v3.4.4

[Quentin-David-24]

Bumps PAYMENTS_VERSION in Justfile from v3.4.0 to v3.4.4

[NumaryBot]

✅ Approve — automated review

The Payments version bump and corresponding Speakeasy lockfile digest updates are consistent, with no actionable correctness issue found.

No findings.

[shipfox-ai]

The functional change here is correct and complete: Justfile:3 now reads PAYMENTS_VERSION := "v3.4.4", and that variable is only consumed dynamically (Justfile:16 in download-specs, .github/scripts/generate-changelog.sh:12,27), so no companion edit is required — a repo-wide grep finds no other hard-coded payments version, and the event schemas are keyed by major version (events/services/payments/v3.0.0/), so they need no update for a patch bump. The remaining concerns are about verification and description, not about the edit itself. Note that nothing in CI validates this bump before merge: .github/workflows/releases.yml only triggers on v*.*.* tag pushes and .github/workflows/cron.yml only builds base images, so just validate-openapi first runs at release time — which raises the cost of the unverified items below. Recommendation: approve with comments (please answer the enum-overlay question and fix the PR body before merging).

Standards

1. .speakeasy/workflow.lock:1 — the committed lock metadata was produced by a Speakeasy CLI that is not the one this repo pins. The lock now records speakeasyVersion: 1.796.4, but flake.nix:29 pins speakeasyVersion = "1.759.2", and CI composes the spec with that pinned binary (.github/workflows/releases.yml:18, nix develop --impure --command just build). So the new sourceRevisionDigest/sourceBlobDigest values in this diff are not reproducible from the repo's own toolchain. To resolve the two candidate reviews explicitly: the claim that this line "silently changes the generator version used for releases" is not correct — .speakeasy/workflow.yaml:2 declares speakeasyVersion: latest and CI takes its CLI from the flake, so this field controls nothing at release time. The real, narrower impact is a reproducibility gap, and it is pre-existing rather than introduced here (the base already recorded 1.791.4 ≠ 1.759.2); this PR widens it. Low severity, but either regenerate inside nix develop or bump the flake pin so the two agree.

Rejected on this axis: the "stale composition artifacts / no evidence just pre-commit ran" claim. releases/overlays/generated.overlay.json is tracked, but generate-composition-overlay is a hard prerequisite of build-openapi and publish-speakeasy (Justfile:44-48,58,89), so it is regenerated from the freshly downloaded specs on every release build; a stale checked-in copy cannot affect the published output. Also rejected: the commit-message wording (Add the workflow lock for a modified file) — no documented convention in this repo, no correctness impact.

Spec

1. releases/overlays/shared.overlay.yaml:62 — the positional enum deletion is unverified against payments v3.4.4, and this bump is exactly its trigger. The overlay does - target: $.components.schemas.payments_LegacyPaymentStatus.enum[14] / remove: true with the comment "Remove the duplicated FAILED value". The validate-openapi duplicate-enum invariant (Justfile:75) only catches the case where a duplicate survives; it cannot catch a wrong deletion. Concretely: if v3.4.4 fixed the duplicate upstream or reordered that enum, index 14 now points at a legitimate distinct status, the overlay deletes it, the dedup check still passes, and a valid payment status silently disappears from the published openapi.json and every generated SDK. Because there is no PR-level build, this would only surface at release-tag time. Please paste the payments_LegacyPaymentStatus.enum array from the v3.4.4-composed releases/build/generate.json (or confirm just build-openapi ran clean locally), and consider switching the overlay to a value-based rather than index-based target.

2. PR body baseline contradicts the diff: Justfile:3 goes from v3.4.0 to v3.4.4, not from v3.2.0. The body states "Bumps PAYMENTS_VERSION in Justfile from v3.2.0 to v3.4.4". The target version is right, so the code is correct and the description is wrong — but the wrong baseline means any breaking-change assessment behind this PR (including NumaryBot's "no evident breaking issue") was reasoned over a v3.2.0→v3.4.4 range instead of the actual v3.4.0→v3.4.4. Fix the body and state the release-note range actually reviewed.

3. .speakeasy/workflow.lock:1,5,6 — undeclared scope beyond the stated one-line requirement. The body describes only the Justfile change, but the PR also rewrites speakeasyVersion and both source digests. The digest updates are a plausible consequence of recomposing the spec after the bump and are fine to keep; the CLI-version line is an incidental byproduct of the local toolchain (see Standards fix(Task): docker update doesnt accept boolean in the task file so by… #1). Either mention both in the body or drop the speakeasyVersion line so the PR is a clean component bump.

Reviewed independently by Claude (claude-opus-5) and Codex (gpt-5.6-sol) via Shipfox; verified and synthesized by Claude.

[shipfox-ai]

Summary

This PR is a two-line data change: PAYMENTS_VERSION moves v3.4.0 → v3.4.4 in Justfile:3, and .speakeasy/workflow.lock records the recomposed source digests plus the CLI version that produced them. I verified the stated intent against the code: PAYMENTS_VERSION has exactly one definition and only dynamic consumers (Justfile:16 interpolates it into the download URL, .github/scripts/generate-changelog.sh:12,27 re-extracts it from the Justfile), the tracked releases/overlays/generated.overlay.json is regenerated as a prerequisite of both build-openapi and publish-speakeasy (Justfile:44,48,88) so its being unchanged is consistent and harmless, and events/services/payments/** is keyed by major version so a patch bump implies no companion edit. No correctness, security, or compatibility defect is present in the diff itself. The one residual risk is that nothing validates this bump before a release tag, and one overlay action targets a payments enum by index. Recommendation: approve with comments — merge is fine, but confirm the enum index below (or compose the spec once) before cutting the next release tag.

Standards

No confirmed material finding on this axis. The repository documents no coding standards (no CONTRIBUTING.md/AGENTS.md; .editorconfig covers only Earthfile and *.tpl; events/.golangci.yml is Go-only and tooling-enforced), and the changed hunks are data lines that follow the surrounding conventions exactly (Justfile:3 keeps the quoted vX.Y.Z form shared by all nine entries of the # Component versions block). Claude's "possible Shotgun Surgery" and "tracked-but-unchanged generated overlay" candidates were checked and rejected: the two-file update is one cohesive change, and the generated overlay is rebuilt by generate-composition-overlay on every build/publish path, so no stale artifact can reach a release.

Spec

1. Low–medium — releases/overlays/shared.overlay.yaml:62 removes a payments enum member by position, and this bump is exactly the input that can shift it. The action is - target: $.components.schemas.payments_LegacyPaymentStatus.enum[14] / remove: true, intended to drop a duplicated FAILED value. If payments v3.4.4 reordered, added to, or itself de-duplicated that enum, index 14 now points at a different member and a legitimate status value is silently removed from the composed spec and every generated SDK. The uniqueness invariant at Justfile:75 (select(length != (unique | length))) only catches the sub-case where a duplicate survives; it does not catch removal of a distinct value. Compounding this, nothing exercises the composition before merge: .github/workflows/releases.yml:3-5 triggers only on v*.*.* tags and .github/workflows/cron.yml builds base images only, so any composition failure or mis-target surfaces mid-release rather than on this PR. I could not settle it locally because components/ is not committed and no network fetch was available. Action: run just build-openapi once against v3.4.4 and, ideally, replace the index target with a value-based one so it cannot silently retarget on future bumps.

Resolved candidate (not retained)

Both reviews flagged that .speakeasy/workflow.lock:1 records speakeasyVersion: 1.796.4 while flake.nix:25 pins 1.759.2, and Codex additionally reads the commit body's promise ("will be reconciled by regenerating inside nix develop") as unfinished work. The commit body does say that, and the mismatch is real, but the code shows it is not a defect and the promised remedy would not achieve what it claims: .speakeasy/workflow.yaml:2 declares speakeasyVersion: latest, and the pre-existing base lockfile already recorded 1.791.4 — i.e. the recorded value has never tracked the flake pin, because it reflects the CLI version Speakeasy resolves at run time. The field also governs nothing at release time (the release job runs speakeasy run inside nix develop, which rewrites these digests). There is no correctness, security, or compatibility impact, so I am not retaining it; at most, the commit's note is misleading for future readers and could be dropped.

Reviewed independently by Claude (claude-opus-5) and Codex (gpt-5.6-sol) via Shipfox; verified and synthesized by Claude.