🤖 Generated by the Daily AI Engineer
Evidence
Maintainer direction (2026-07-19, interactive session): with the agents running at full autonomy, following what changed across the portfolio is hard — a per-repo changelog would make it legible. Live state: 12 repos run semantic-release (.releaserc) with commit-analyzer only, so releases are cut but no notes file is ever written; only actions (release-please) has a CHANGELOG.md today. The raw material is already good — every repo squash-merges on Conventional-Commit PR titles.
Audience & problem
The maintainer (and any future contributor) reviewing a product after the fact: today "what changed" requires walking merged PRs or GitHub Releases per repo; there is no single in-repo, versioned, skimmable history.
Hypothesis
A generated CHANGELOG.md in each repo root — written by the repo's existing release pipeline, never by hand — gives an always-current, versioned change history at near-zero ongoing cost.
Success signal
After the next release in each converted repo, its CHANGELOG.md contains that release's entries automatically (no manual step), and the maintainer can answer "what shipped here recently" from the file alone. Guardrail: release pipelines stay green; no release is blocked by changelog generation.
Smallest useful change
Convert ONE semantic-release repo end-to-end and verify a real release writes the file, then roll the proven pattern out per repo family.
Design constraint (decide in the first child)
semantic-release writes CHANGELOG.md via @semantic-release/release-notes-generator + @semantic-release/changelog + @semantic-release/git — the git plugin pushes a commit to main, which collides with branch protection/merge queues unless the release identity may bypass. release-please instead delivers the changelog through its release PR (the model actions already proves live). The first child evaluates: extend the semantic-release chain (and solve the protected-main push), or converge repos on release-please, or a hybrid per repo family. Portfolio consistency (shared config in devantler-tech/.github) is preferred over 12 hand-rolled configs.
Scope
- semantic-release repos (12): ksail, platform, .github, world-at-ruin, ascoachingogvaner, go-template, dotnet-template, platform-template, gitops-tenant-template, aws, wedding-app (+ actions already done via release-please).
- Repos with no release automation today (monorepo, unifi, provider-upjet-unifi, kyverno-policies, agent-skills, agent-plugins, homebrew-tap, fleet-gitops): each first needs a release pipeline decision — decompose separately; do not block the 12 on them.
- Generated file discipline applies: CHANGELOG.md is never hand-edited; the generator owns it.
Acceptance criteria
Rough size: L (portfolio-wide; ships as per-repo children off this epic).
Evidence
Maintainer direction (2026-07-19, interactive session): with the agents running at full autonomy, following what changed across the portfolio is hard — a per-repo changelog would make it legible. Live state: 12 repos run semantic-release (
.releaserc) with commit-analyzer only, so releases are cut but no notes file is ever written; onlyactions(release-please) has a CHANGELOG.md today. The raw material is already good — every repo squash-merges on Conventional-Commit PR titles.Audience & problem
The maintainer (and any future contributor) reviewing a product after the fact: today "what changed" requires walking merged PRs or GitHub Releases per repo; there is no single in-repo, versioned, skimmable history.
Hypothesis
A generated CHANGELOG.md in each repo root — written by the repo's existing release pipeline, never by hand — gives an always-current, versioned change history at near-zero ongoing cost.
Success signal
After the next release in each converted repo, its CHANGELOG.md contains that release's entries automatically (no manual step), and the maintainer can answer "what shipped here recently" from the file alone. Guardrail: release pipelines stay green; no release is blocked by changelog generation.
Smallest useful change
Convert ONE semantic-release repo end-to-end and verify a real release writes the file, then roll the proven pattern out per repo family.
Design constraint (decide in the first child)
semantic-release writes CHANGELOG.md via
@semantic-release/release-notes-generator+@semantic-release/changelog+@semantic-release/git— the git plugin pushes a commit tomain, which collides with branch protection/merge queues unless the release identity may bypass. release-please instead delivers the changelog through its release PR (the modelactionsalready proves live). The first child evaluates: extend the semantic-release chain (and solve the protected-main push), or converge repos on release-please, or a hybrid per repo family. Portfolio consistency (shared config indevantler-tech/.github) is preferred over 12 hand-rolled configs.Scope
Acceptance criteria
Rough size: L (portfolio-wide; ships as per-repo children off this epic).