v3.15.1

What's new

A maintenance release whose one substantive change closes a drift gap in the dependency-update pipeline: artifacts that are generated from a dependency now regenerate inside the Renovate branch that bumps it, so a schema-affecting upgrade lands complete rather than red.

Bug Fixes

Zod moves from 4.4.3 to 4.5.4 (#891, 4e99f0e). The upgrade changes the JSON Schema that Zod emits for ISO date-time fields: the date-time pattern in skills/ce-review/references/review-summary-schema.json now requires an explicit seconds component instead of treating it as optional. Because that file is checked in and generated from Zod's toJSONSchema output, the regenerated schema travels in the same commit as the bump -- the first Renovate PR to exercise the post-upgrade wiring described below. The same PR also carries typebox to 1.3.24.

If you validate ce:review summary payloads against the published schema, completed_at values must now include seconds (2026-09-04T17:52:51Z), not just hours and minutes.

Continuous Integration

Renovate regenerates every dependency-derived artifact, not just one (#893, aff01fe). The postupgrade script that Renovate runs in-branch previously covered only bun run build and the agent-browser stub regeneration. It now also runs schema:generate, review-schema:generate, and scripts/generate-registry.ts.

The gap stayed invisible until a bump hit it: an update that shifted the config schema, the review-summary schema, or registry content would open a PR that failed its own drift gates, and a human had to regenerate the file by hand before the update could merge. Extending postUpgradeTasks moves that work into the branch that caused it. The Zod bump above is the immediate proof -- its regenerated schema arrived inside the update PR instead of as a follow-up fix.

Documentation

A stated merge order is not an enforced one (#874, dd32db0). A new learning in docs/solutions/workflow-issues/ records a pull request that stated the precondition it then failed to satisfy: its body said to merge a dependency first, explained precisely why, and was based on a commit that predated it -- leaving it mergeable in exactly the order it warned against. The warning was accurate and completely inert. The reviewer caught it only by building the artifact at that branch's head and finding that the command the prose told readers to run was not executable.

The doc gives equal weight to the alternative, because stacking had failed the same day: a pull request opened against another open pull request's branch lost its base when that branch merged and was deleted, and creation failed outright. Being burned by that is what produced the retreat to prose, which felt safer and was strictly weaker. So the guidance is conditional rather than a slogan -- stack when the dependency is not about to merge and let the platform refuse the wrong order; hold the dependent branch unopened when the dependency is approved and could land at any moment; write the dependency down as well, but never only that. Recovery from a vanished base is documented too, since knowing it is cheap makes the stacking risk feel correctly sized.

Both failures share a cause: the ordering lived somewhere that could not enforce it. Of the two, the description is worse -- a vanished base fails loudly and immediately, while a description fails by saying nothing at all.

Also in this release

• deps: fro-bot/agent advanced through v0.105.1, v0.106.0, v0.106.1, v0.106.2, v0.107.0, and v0.107.1 (#882, #884, #886, #887, #889, #892).
• deps: bfra-me/.github to v4.22.0 (#878), github/codeql-action to v4.37.9 (#876), plus a non-major roll-up (#875).
• dev: typebox to v1.3.18, v1.3.19, and v1.3.20 (#879, #883, #890); @types/node to v26.3.0 and v26.4.0 (#881, #885); plus a non-major roll-up (#888).

Compare

v3.15.0...v3.15.1