release-please standardization: Phase 1 done; Phase 2 config-centralization needs a decision (config-free regresses 12/14 repos)

[JacobPEvans-personal]

Summary

Org-wide standardization of release-please. Phase 1 (auto-merge reliability) is done; Phase 2 (config centralization) needs a decision because new evidence contradicts the originally-chosen "config-free" approach for most of the fleet.

Phase 1 — DONE / merged

Change	PR
Fix _release-please.yml: auto-merge via the action's pr output (branch-name-proof), drop the no-op jq major-block, drop orphaned checkout, auto-merge all bumps, add pass-through inputs for config-free callers	#26 ✅
Migrate nix-ai-server off inline release-please-action@v4 → thin wrapper	dryvist/nix-ai-server#5 ✅

Root causes fixed

1. Branch-match bug: the old find-PR step used an exact gh pr list --head release-please--branches--main match, which missed component-suffixed branches (e.g. …--components--nix-claude-code) and silently skipped auto-merge. Now reads fromJSON(steps.release.outputs.pr).number.
2. No-op major block: the jq … always-bump-minor step rewrote the config in the local checkout, but release-please reads config from the repo via API at branch HEAD — local edits are ignored. It never blocked anything (terraform-proxmox ships patches with no versioning key). Removed; per owner decision, all bumps auto-merge, including major.

BLOCKER (needs repo-admin / Terraform) — allow_auto_merge OFF

nix-claude-code, nix-ai-server, cc-edge-pack-template have allow_auto_merge = false, so auto-merge can't engage there even with the fixed workflow. The default DRYVIST token gets 403 on the settings PATCH. Tracked + analyzed in dryvist/tofu-github#12 (the first two are already in config/repos.yml — drift; the third isn't managed). Fix = terraform apply (or a repo-admin PATCH as stopgap). Until then, nix-claude-code#54 (release 0.1.13) stays stuck.

Phase 2 — config centralization: GATE PASSED, but the fleet doesn't fit

The chosen approach was config-free / non-manifest mode (repos carry zero release-please files; behaviour lives in .github workflow inputs). I verified it works mechanically via a release-please … --dry-run:

• ✅ Detects current version from existing tags (no manifest needed)
• ✅ Proposes the correct next version, v-prefixed tags preserved (v-in-tag is the default; identical output with/without the flag)
• ✅ Clean release-please--branches--main branch
• Pilot opened (draft): feat(release): adopt config-free (non-manifest) release-please [PILOT — do not merge until allow_auto_merge is on] nix-claude-code#55

The problem: config-free can't express what 12/14 repos use

googleapis/release-please-action@v5 has no input for version-file, changelog-sections, or include-v-in-tag — docs route "advanced config" to manifest mode. Classification of the central-inheriting repos:

Uses version-file: VERSION + custom changelog-sections?	Repos
No — vanilla, config-free is clean	nix-claude-code, raycast-smart-issue
Yes — config-free would REGRESS them	terraform-proxmox, ansible-splunk, ai-assistant-instructions, claude-code-plugins, ansible-proxmox, nix-home, nix-devenv, ai-workflows, tf-splunk-aws, terraform-runs-on, nix-ai-server
Custom changelog only (release-type: python)	mlx-benchmarks

Going config-free on the 12 would stop updating their VERSION file (nothing bumps it anymore) and revert their curated changelog to release-please defaults (chore/docs/refactor/etc. would un-hide). That's a real regression, not cosmetic.

Decision needed

1. Config-free only for the 2 vanilla repos (nix-claude-code via #55, raycast-smart-issue); leave the other 12 in manifest mode as-is. Minimal benefit, partial centralization.
2. Synced canonical config (manifest), recommended. .github holds ONE canonical release-please-config.json (with version-file: VERSION + the standard changelog-sections); every repo carries an identical synced copy — the same "canonical-in-.github, distributed to consumers" model already used for the lint/precommit configs (fetch-shared-configs / Renovate). Keeps every feature, makes the config uniform and single-sourced, and per-repo files become synced artifacts rather than hand-maintained. Each repo still keeps a one-line .release-please-manifest.json (version state, not config).
3. Config-free fleet-wide and accept the loss of VERSION files + custom changelogs. Only if those features are genuinely unwanted.

Recommendation: Option 2. It's what "the config should live in .github, as with everything else" actually means in practice (the other shared configs are synced copies, not absent), and it doesn't regress 12 repos. Option 1's #55 pilot is still valid for the 2 vanilla repos regardless.

Sequencing (whatever path)

1. Resolve the allow_auto_merge blocker (terraform-github#12) first — otherwise every migrated repo just accumulates a stuck release PR.
2. Then execute the chosen config path, pilot-first, verifying each repo's first post-change release proposes the right version + v-tag before moving on.
3. Finalize: once uniform, the thin wrappers can drop any transitional with: overrides.

Pointers

• Pilot PR: feat(release): adopt config-free (non-manifest) release-please [PILOT — do not merge until allow_auto_merge is on] nix-claude-code#55 (draft — do not merge until allow_auto_merge is on; it supersedes the stuck #54).
• Settings blocker: Reconcile allow_auto_merge drift: nix-claude-code, nix-ai-server, cc-edge-pack-template tofu-github#12.
• Central workflow: dryvist/.github/.github/workflows/_release-please.yml (now dual-mode: manifest default, non-manifest via inputs).