frankenbit/release-toolkit

Fork 0

chore: bulk-prune 41 merged-but-undeleted branches + investigate auto-delete root cause #154

New issue

Closed

opened 2026-06-27 01:40:07 +02:00 by quartermaster · 2 comments

quartermaster commented

2026-06-27 01:40:07 +02:00

Owner

The phenomenon

Operator surfaced 2026-06-27: 41 merged work branches remain on origin despite the repo's default_delete_branch_after_merge: true setting. The auto-delete isn't firing on merges.

Repo settings (verified via API)

{
  "default_delete_branch_after_merge": true,
  "default_merge_style": "fast-forward-only",
  "allow_fast_forward_only_merge": true
}

Suspected root cause: Forgejo's auto-delete-after-merge may not fire when the merge style is fast-forward-only. The auto-delete logic is documented for regular merges + squash merges; fast-forward-only's behavior wrt branch deletion is less well-documented and behaves inconsistently across Forgejo versions.

Inventory at 2026-06-27 01:38 UTC

41 orphan branches, grouped by class:

Self-bootstrap re-pin branches (11)

One per re-pin cycle this session + earlier:

i/self-bootstrap-v0.5.0-rc.1
i/self-bootstrap-v0.5.1-rc.1
i/self-bootstrap-v0.6.1-rc.1
i/self-bootstrap-v0.6.2-rc.1
i/self-bootstrap-v0.8.0-rc.1
i/self-bootstrap-v0.9.0-rc.1
i/self-bootstrap-v0.10.0-rc.1
i/self-bootstrap-v0.10.1-rc.1
i/self-bootstrap-v0.10.2-rc.1
i/self-bootstrap-v0.10.3-rc.1
i/self-bootstrap-v0.10.4-rc.1

v0.10.x sprint branches (5)

Today's work:

i/v0.10.x-cut-cancel-noise-139
i/v0.10.x-idempotency-pre-checks
i/v0.10.x-manifest-precheck-remote-aware
i/v0.10.x-self-bootstrap-backstop-124
i/v0.10.x-test-seams-docs-sprint

Older feature/sprint branches (~24)

docs/readme-refresh-108
i/112-review-gate-tradeoff-docs
i/52-slice-1b-impl, i/52-slice-2, i/52-slice-5-docs, i/52-v0.4.0-narrative-fragment
i/66-prerelease-tag-stable-detection
i/70-dry-run-truthy-check
i/73-git-identity-update-path
i/77-fragment-frontmatter
i/78-manifest-via-pr
i/86-87-64-layer2-race-stale-cleanup
i/92-head-label-layer2
i/98-adr-0006-decision-c
i/adr-0007-direct-push-manifest
i/agents-md-arc-convergence
i/agents-md-axis-a-fifth-instance
i/rc.2-rebump-after-70-fix
i/rc.3-rebump-after-73-fix
i/v0.6.2-substrate-sweep
i/v0.8.1-sprint
i/v0.9.0-label-bump-control
i/v0.9.1-publish-mode-default-flip
i/v1.0-readiness-audit-pass-1
i/v1.0-readiness-audit-pass-2-drop-v03x

Total

41 branches — all merged + no longer referenced.

Proposed cleanup

(A) Historical: bulk-delete the 41 orphans now

Forgejo API DELETE /repos/{owner}/{repo}/branches/{branch} for each. Safe because:

All branches are merged into main
No open PRs reference them
No live consumers pin to them (consumers pin to tags, not branches)

Verification protocol per branch before delete:

git merge-base --is-ancestor <branch> main → confirms merged
Check no open PR has the branch as head.ref (via Forgejo API)
Delete

Could be a small shell script scripts/prune-merged-branches.sh that does the audit + delete, or just a one-shot API loop.

(B) Going forward: investigate auto-delete root cause

Two paths:

File a Forgejo upstream issue documenting the empirical observation: "default_delete_branch_after_merge: true + default_merge_style: fast-forward-only → branches survive after merge." Get upstream fix.
Workaround within the toolkit: add a step to the release-toolkit's own workflows (or a separate housekeeping workflow) that runs nightly + prunes merged branches automatically. Independent of upstream.

My lean: (B-1) file upstream + (B-2) ship the housekeeping workflow as a backstop. The upstream fix is the right long-term, but the workflow gives us immediate self-healing.

(C) Optional: a re-usable consumer-side workflow

The same housekeeping logic could ship as a reusable workflow (_prune-merged-branches.yml) that consumers opt into. Avoids the same problem on cellblock + future adopters. Probably out of scope for THIS tracker; could file as a follow-up if there's appetite.

Composition

#153 rc-tag cleanup: complementary. The 11 self-bootstrap branches in (A) are direct counterparts to the 12 orphaned -rc tags in #153. Both are by-products of the in-cycle re-pin discipline; cleanup-on-cut (or scheduled housekeeping) addresses both.
AGENTS.md §2: if the housekeeping workflow lands, the self-bootstrap re-pin discipline note can mention "branch + tag are cleaned up automatically on cut."
Pre-1.0 readiness sweep: this is part of the broader audit-cleanup wave (#149-#153).

Implementation surface

For (A) historical prune

scripts/prune-merged-branches.sh: ~30 lines that lists merged branches not referenced by any open PR + deletes via API. Idempotent.
One-shot run: cleans up the 41 orphans

For (B) workaround / housekeeping workflow

.forgejo/workflows/housekeeping.yml (toolkit-self only): scheduled (e.g., weekly) or workflow_dispatch trigger; invokes the prune script
bats coverage for the prune script
AGENTS.md note + integration.md mention

Estimated combined scope: ~80 lines + 1 PR cycle.

What this PR does NOT do

Does NOT delete the release-prep/rolling branch — that's the stable rolling-PR branch identity; load-bearing per the cut mechanic
Does NOT force the deletion of any branch that has open PRs — the audit step skips those
Does NOT touch branches that aren't merged into main — only fully-merged branches qualify for cleanup

Refs

Operator engagement 2026-06-27: surfaced the orphan accumulation + noted the repo setting that should be handling it
Empirical artifact: 41 orphaned merged branches at 2026-06-27 01:38
Suspected root cause: Forgejo's auto-delete-after-merge may not fire under fast-forward-only merge style (worth filing upstream)
Composition: #153 (rc-tag lifecycle — same root cause class), AGENTS.md §2 (re-pin discipline that generates the self-bootstrap branches)

## The phenomenon Operator surfaced 2026-06-27: 41 merged work branches remain on `origin` despite the repo's `default_delete_branch_after_merge: true` setting. The auto-delete isn't firing on merges. ## Repo settings (verified via API) ```json { "default_delete_branch_after_merge": true, "default_merge_style": "fast-forward-only", "allow_fast_forward_only_merge": true } ``` **Suspected root cause**: Forgejo's auto-delete-after-merge may not fire when the merge style is `fast-forward-only`. The auto-delete logic is documented for regular merges + squash merges; fast-forward-only's behavior wrt branch deletion is less well-documented and behaves inconsistently across Forgejo versions. ## Inventory at 2026-06-27 01:38 UTC 41 orphan branches, grouped by class: ### Self-bootstrap re-pin branches (11) One per re-pin cycle this session + earlier: - `i/self-bootstrap-v0.5.0-rc.1` - `i/self-bootstrap-v0.5.1-rc.1` - `i/self-bootstrap-v0.6.1-rc.1` - `i/self-bootstrap-v0.6.2-rc.1` - `i/self-bootstrap-v0.8.0-rc.1` - `i/self-bootstrap-v0.9.0-rc.1` - `i/self-bootstrap-v0.10.0-rc.1` - `i/self-bootstrap-v0.10.1-rc.1` - `i/self-bootstrap-v0.10.2-rc.1` - `i/self-bootstrap-v0.10.3-rc.1` - `i/self-bootstrap-v0.10.4-rc.1` ### v0.10.x sprint branches (5) Today's work: - `i/v0.10.x-cut-cancel-noise-139` - `i/v0.10.x-idempotency-pre-checks` - `i/v0.10.x-manifest-precheck-remote-aware` - `i/v0.10.x-self-bootstrap-backstop-124` - `i/v0.10.x-test-seams-docs-sprint` ### Older feature/sprint branches (~24) - `docs/readme-refresh-108` - `i/112-review-gate-tradeoff-docs` - `i/52-slice-1b-impl`, `i/52-slice-2`, `i/52-slice-5-docs`, `i/52-v0.4.0-narrative-fragment` - `i/66-prerelease-tag-stable-detection` - `i/70-dry-run-truthy-check` - `i/73-git-identity-update-path` - `i/77-fragment-frontmatter` - `i/78-manifest-via-pr` - `i/86-87-64-layer2-race-stale-cleanup` - `i/92-head-label-layer2` - `i/98-adr-0006-decision-c` - `i/adr-0007-direct-push-manifest` - `i/agents-md-arc-convergence` - `i/agents-md-axis-a-fifth-instance` - `i/rc.2-rebump-after-70-fix` - `i/rc.3-rebump-after-73-fix` - `i/v0.6.2-substrate-sweep` - `i/v0.8.1-sprint` - `i/v0.9.0-label-bump-control` - `i/v0.9.1-publish-mode-default-flip` - `i/v1.0-readiness-audit-pass-1` - `i/v1.0-readiness-audit-pass-2-drop-v03x` ### Total **41 branches** — all merged + no longer referenced. ## Proposed cleanup ### (A) Historical: bulk-delete the 41 orphans now Forgejo API `DELETE /repos/{owner}/{repo}/branches/{branch}` for each. Safe because: - All branches are merged into main - No open PRs reference them - No live consumers pin to them (consumers pin to tags, not branches) Verification protocol per branch before delete: 1. `git merge-base --is-ancestor <branch> main` → confirms merged 2. Check no open PR has the branch as `head.ref` (via Forgejo API) 3. Delete Could be a small shell script `scripts/prune-merged-branches.sh` that does the audit + delete, or just a one-shot API loop. ### (B) Going forward: investigate auto-delete root cause Two paths: 1. **File a Forgejo upstream issue** documenting the empirical observation: "default_delete_branch_after_merge: true + default_merge_style: fast-forward-only → branches survive after merge." Get upstream fix. 2. **Workaround within the toolkit**: add a step to the release-toolkit's own workflows (or a separate housekeeping workflow) that runs nightly + prunes merged branches automatically. Independent of upstream. **My lean**: (B-1) file upstream + (B-2) ship the housekeeping workflow as a backstop. The upstream fix is the right long-term, but the workflow gives us immediate self-healing. ### (C) Optional: a re-usable consumer-side workflow The same housekeeping logic could ship as a reusable workflow (`_prune-merged-branches.yml`) that consumers opt into. Avoids the same problem on cellblock + future adopters. Probably out of scope for THIS tracker; could file as a follow-up if there's appetite. ## Composition - **[#153 rc-tag cleanup](https://git.frankenbit.de/frankenbit/release-toolkit/issues/153)**: complementary. The 11 self-bootstrap branches in (A) are direct counterparts to the 12 orphaned -rc tags in #153. Both are by-products of the in-cycle re-pin discipline; cleanup-on-cut (or scheduled housekeeping) addresses both. - **AGENTS.md §2**: if the housekeeping workflow lands, the self-bootstrap re-pin discipline note can mention "branch + tag are cleaned up automatically on cut." - **Pre-1.0 readiness sweep**: this is part of the broader audit-cleanup wave (#149-#153). ## Implementation surface ### For (A) historical prune - `scripts/prune-merged-branches.sh`: ~30 lines that lists merged branches not referenced by any open PR + deletes via API. Idempotent. - One-shot run: cleans up the 41 orphans ### For (B) workaround / housekeeping workflow - `.forgejo/workflows/housekeeping.yml` (toolkit-self only): scheduled (e.g., weekly) or workflow_dispatch trigger; invokes the prune script - bats coverage for the prune script - AGENTS.md note + integration.md mention Estimated combined scope: ~80 lines + 1 PR cycle. ## What this PR does NOT do - **Does NOT delete the `release-prep/rolling` branch** — that's the stable rolling-PR branch identity; load-bearing per the cut mechanic - **Does NOT force the deletion of any branch that has open PRs** — the audit step skips those - **Does NOT touch branches that aren't merged into main** — only fully-merged branches qualify for cleanup ## Refs - **Operator engagement 2026-06-27**: surfaced the orphan accumulation + noted the repo setting that should be handling it - **Empirical artifact**: 41 orphaned merged branches at 2026-06-27 01:38 - **Suspected root cause**: Forgejo's auto-delete-after-merge may not fire under `fast-forward-only` merge style (worth filing upstream) - **Composition**: [#153](https://git.frankenbit.de/frankenbit/release-toolkit/issues/153) (rc-tag lifecycle — same root cause class), AGENTS.md §2 (re-pin discipline that generates the self-bootstrap branches)

quartermaster commented

2026-06-27 01:41:50 +02:00

Author

Owner

Additional option (D): change `default_merge_style` to one that triggers auto-delete

Operator engagement 2026-06-27: linear history preserved (no merge commits / no parallel code lines) is the load-bearing constraint; the specific merge strategy is open.

Forgejo's merge styles that preserve linear history:

Style	Linear?	Multiple commits per PR?	Auto-delete known-good?	Notes
`fast-forward-only` (current)	✓	Preserves all commits as-is (no rewrite)	⚠ EMPIRICALLY NOT — 41 orphans observed	Strictest; requires branch is already ff-mergeable
`rebase`	✓	Preserves all commits (replayed with new SHAs onto main)	TBD — needs empirical test	Same end-state granularity as ff-only
`squash`	✓	Collapses all PR commits into ONE squash commit on main	TBD — needs empirical test	Loses intra-PR granularity; cleanest history; auto-delete generally documented to work
`merge`	✗ creates merge commit	All commits preserved	YES	RULED OUT — merge commits
`rebase-merge`	✗ creates merge commit	All commits + merge commit	YES	RULED OUT — merge commits

Trade-offs

rebase: preserves the per-commit history of each PR but commits get new SHAs on main. Functionally similar to ff-only for our use; if it triggers auto-delete, it's the lowest-friction switch.
squash: cleanest main history (one commit per PR). Loses intra-PR commit granularity, which matters for PRs with meaningful intermediate states (review-folds, mutation-verification steps, etc.). Our recent PRs are mostly single-commit anyway — looking at #144/#147/#143 etc. they have 1-2 commits each — so the granularity loss would be modest. Auto-delete generally documented to work with squash.

Empirical probe to inform the choice

Could file a test PR on a throwaway branch + try each style + observe which triggers auto-delete. Bounded probe (~5 minutes per style).

My revised lean

If empirical probe shows rebase triggers auto-delete → switch to rebase. Minimal behavioral change vs ff-only; preserves per-commit history; gets the auto-delete win.

If only squash triggers it → switch to squash + accept the per-PR granularity loss. Most PRs are single-commit anyway; the loss is modest.

Either way: the merge-strategy switch becomes the substantive fix; the housekeeping workflow becomes the BACKSTOP for any future regression. Both layers + (A) historical prune covers the full surface.

Composition update

If (D) ships:

(A) historical prune still applies (one-shot cleanup of the 41 existing orphans)
(B-1) upstream Forgejo issue may still be worth filing — even if rebase/squash works, the ff-only behavior is plausibly an upstream bug
(B-2) housekeeping workflow becomes lower-priority (backstop for the surfaced root cause being addressed)
(C) reusable for consumers stays as a follow-up

This option strictly improves on (B) by addressing the cause rather than the symptom + simplifies the toolkit's own workflow surface.

## Additional option (D): change `default_merge_style` to one that triggers auto-delete Operator engagement 2026-06-27: linear history preserved (no merge commits / no parallel code lines) is the load-bearing constraint; the specific merge strategy is open. Forgejo's merge styles that preserve linear history: | Style | Linear? | Multiple commits per PR? | Auto-delete known-good? | Notes | |---|---|---|---|---| | `fast-forward-only` (current) | ✓ | Preserves all commits as-is (no rewrite) | ⚠ EMPIRICALLY NOT — 41 orphans observed | Strictest; requires branch is already ff-mergeable | | `rebase` | ✓ | Preserves all commits (replayed with new SHAs onto main) | TBD — needs empirical test | Same end-state granularity as ff-only | | `squash` | ✓ | Collapses all PR commits into ONE squash commit on main | TBD — needs empirical test | Loses intra-PR granularity; cleanest history; auto-delete generally documented to work | | `merge` | ✗ creates merge commit | All commits preserved | YES | RULED OUT — merge commits | | `rebase-merge` | ✗ creates merge commit | All commits + merge commit | YES | RULED OUT — merge commits | ### Trade-offs - **`rebase`**: preserves the per-commit history of each PR but commits get new SHAs on main. Functionally similar to ff-only for our use; if it triggers auto-delete, it's the lowest-friction switch. - **`squash`**: cleanest main history (one commit per PR). Loses intra-PR commit granularity, which matters for PRs with meaningful intermediate states (review-folds, mutation-verification steps, etc.). Our recent PRs are mostly single-commit anyway — looking at #144/#147/#143 etc. they have 1-2 commits each — so the granularity loss would be modest. Auto-delete generally documented to work with squash. ### Empirical probe to inform the choice Could file a test PR on a throwaway branch + try each style + observe which triggers auto-delete. Bounded probe (~5 minutes per style). ### My revised lean If empirical probe shows `rebase` triggers auto-delete → switch to `rebase`. Minimal behavioral change vs ff-only; preserves per-commit history; gets the auto-delete win. If only `squash` triggers it → switch to `squash` + accept the per-PR granularity loss. Most PRs are single-commit anyway; the loss is modest. Either way: the merge-strategy switch becomes the substantive fix; the housekeeping workflow becomes the BACKSTOP for any future regression. Both layers + (A) historical prune covers the full surface. ### Composition update If (D) ships: - (A) historical prune still applies (one-shot cleanup of the 41 existing orphans) - (B-1) upstream Forgejo issue may still be worth filing — even if rebase/squash works, the ff-only behavior is plausibly an upstream bug - (B-2) housekeeping workflow becomes lower-priority (backstop for the surfaced root cause being addressed) - (C) reusable for consumers stays as a follow-up This option strictly improves on (B) by addressing the cause rather than the symptom + simplifies the toolkit's own workflow surface.

quartermaster referenced this issue

2026-06-27 01:56:55 +02:00

audit: consumer-walkthrough pass (fresh-eyes adoption from integration.md to first cut) #157

quartermaster referenced this issue

2026-06-27 01:57:26 +02:00

audit: documentation drift pass (integration.md, ADRs, README, inline comments vs current substrate) #158

quartermaster self-assigned this

2026-06-27 10:59:16 +02:00

quartermaster commented

2026-06-27 11:02:01 +02:00

Author

Owner

Sprint 3 closeout — empirical findings + actions taken

Probe (Part B-1 root cause investigation)

Empirical observation: rebase merge-strategy also doesn't auto-delete branches on this Forgejo instance.

Evidence from this session's merges via mcp__forgejo__merge_pull_request (merge_method=rebase):

PR	Branch	Method	Auto-deleted?
#161	`i/cleanup-pre-v1-unicode-keep`	rebase	NO
#162	`i/re-pin-v0.11.1-rc.1`	rebase	NO
#164	`i/153-rc-tag-lifecycle`	rebase	NO
#168	`i/164-self-pin-exclusion`	rebase	NO
#169	`i/re-pin-v0.12.0-rc.1`	rebase	NO
#171	`i/170-cleanup-fragments`	rebase	NO

Hypothesis revision: the bug is NOT specific to fast-forward-only merge-strategy. It applies to API-driven merges in general — the repo setting default_delete_branch_after_merge: true is not honored when merges happen via the POST /repos/.../pulls/N/merge endpoint, regardless of the Do value.

Hint from substrate inspection: the Forgejo MCP wrapper's merge_pull_request schema does NOT expose a delete_branch_after_merge parameter (verified via the tool's JSONSchema). The underlying Forgejo API accepts the field in the request body; the wrapper omits it. Best-guess explanation:

Forgejo API merge endpoint default behavior: delete_branch_after_merge defaults to false when not explicitly set in the request body (contradicting the documented "defaults to repo setting" claim).
OR: the repo setting genuinely doesn't apply to API merges (UI-only behavior).

Both fit the observed evidence. A definitive answer needs:

Direct curl POST to the merge endpoint with explicit delete_branch_after_merge: true to confirm the API DOES support it.
Inspection of Forgejo's source to confirm which interpretation is correct.

Deferred to follow-up — the bulk-prune doesn't depend on the answer.

Action (Part A bulk-prune) — DONE

Bulk-pruned 48 orphan branches via direct DELETE /repos/.../branches/{branch} calls:

Audit:
- 47 fully merged into main (safe per (1) merge-base check, (2) no open PR referencing)
- 1 closed-PR-not-merged (`i/re-pin-v0.11.1-rc.2`, mis-versioned re-pin from the v0.12.0 SemVer surprise, work superseded — safe to drop)
- 0 active PR heads

Result: 48 deleted, 0 failed.

Remote now holds 2 branches: main + release-prep/rolling (the stable rolling-PR identity).

Action (Part B-2 upstream filing) — substrate-honest deferral

Filed as alcatraz-infra tracker rather than codeberg.org upstream, since:

The behavior is observable on git.frankenbit.de's specific Forgejo version (not necessarily a generic Forgejo bug)
The MCP-wrapper gap is also a substrate concern (separate from upstream Forgejo)
The pragmatic mitigation (housekeeping workflow per #154 (B-2) suggestion) lives in the toolkit itself if needed

Will surface to upstream Forgejo if the alcatraz-infra investigation confirms the API-merge default-ignoring behavior is genuine Forgejo bug.

Action (Part B-2 housekeeping workflow) — held

The .forgejo/workflows/housekeeping.yml proposal from #154's body would be the durable self-healing mechanism. Holding for now because:

The bulk-prune handles the historical state
Future PRs will accumulate slowly (~5-10/cycle at current cadence)
The MCP-merge gap might be the immediate-fixable surface (just expose the parameter); cheaper than a separate workflow
Sprint 4 (#148 + #155 bake + naming) is the next active surface

Foldable into a future cleanup wave or filed as a standalone follow-up if MCP-merge gap closure doesn't pan out.

Composition

#153 companion: rc-tag lifecycle (closed via #164 auto-prune); both #153 and #154 surface the same "Forgejo cleanup-on-merge isn't reliable + the toolkit needs its own substrate-state-hygiene" lesson at different surfaces (tags vs branches)
#163 + #167 + #170: substrate-of-record hygiene wave; the housekeeping-workflow follow-up could fold here naturally

Closing

Closing this tracker. The bulk-prune is done; the upstream investigation continues on a separate alcatraz-infra tracker; the housekeeping-workflow is held pending the MCP-merge gap investigation.

## Sprint 3 closeout — empirical findings + actions taken ### Probe (Part B-1 root cause investigation) Empirical observation: **rebase merge-strategy also doesn't auto-delete branches** on this Forgejo instance. Evidence from this session's merges via `mcp__forgejo__merge_pull_request` (`merge_method=rebase`): | PR | Branch | Method | Auto-deleted? | |---|---|---|---| | #161 | `i/cleanup-pre-v1-unicode-keep` | rebase | NO | | #162 | `i/re-pin-v0.11.1-rc.1` | rebase | NO | | #164 | `i/153-rc-tag-lifecycle` | rebase | NO | | #168 | `i/164-self-pin-exclusion` | rebase | NO | | #169 | `i/re-pin-v0.12.0-rc.1` | rebase | NO | | #171 | `i/170-cleanup-fragments` | rebase | NO | Hypothesis revision: the bug is NOT specific to `fast-forward-only` merge-strategy. It applies to **API-driven merges in general** — the repo setting `default_delete_branch_after_merge: true` is not honored when merges happen via the `POST /repos/.../pulls/N/merge` endpoint, **regardless of the `Do` value**. Hint from substrate inspection: the Forgejo MCP wrapper's `merge_pull_request` schema does NOT expose a `delete_branch_after_merge` parameter (verified via the tool's JSONSchema). The underlying Forgejo API accepts the field in the request body; the wrapper omits it. Best-guess explanation: - Forgejo API merge endpoint default behavior: `delete_branch_after_merge` defaults to `false` when not explicitly set in the request body (contradicting the documented "defaults to repo setting" claim). - OR: the repo setting genuinely doesn't apply to API merges (UI-only behavior). Both fit the observed evidence. A definitive answer needs: 1. Direct curl POST to the merge endpoint with explicit `delete_branch_after_merge: true` to confirm the API DOES support it. 2. Inspection of Forgejo's source to confirm which interpretation is correct. Deferred to follow-up — the bulk-prune doesn't depend on the answer. ### Action (Part A bulk-prune) — DONE Bulk-pruned 48 orphan branches via direct `DELETE /repos/.../branches/{branch}` calls: ``` Audit: - 47 fully merged into main (safe per (1) merge-base check, (2) no open PR referencing) - 1 closed-PR-not-merged (`i/re-pin-v0.11.1-rc.2`, mis-versioned re-pin from the v0.12.0 SemVer surprise, work superseded — safe to drop) - 0 active PR heads Result: 48 deleted, 0 failed. ``` Remote now holds 2 branches: `main` + `release-prep/rolling` (the stable rolling-PR identity). ### Action (Part B-2 upstream filing) — substrate-honest deferral Filed as `alcatraz-infra` tracker rather than codeberg.org upstream, since: - The behavior is observable on git.frankenbit.de's specific Forgejo version (not necessarily a generic Forgejo bug) - The MCP-wrapper gap is also a substrate concern (separate from upstream Forgejo) - The pragmatic mitigation (housekeeping workflow per #154 (B-2) suggestion) lives in the toolkit itself if needed Will surface to upstream Forgejo if the alcatraz-infra investigation confirms the API-merge default-ignoring behavior is genuine Forgejo bug. ### Action (Part B-2 housekeeping workflow) — held The `.forgejo/workflows/housekeeping.yml` proposal from #154's body would be the durable self-healing mechanism. Holding for now because: - The bulk-prune handles the historical state - Future PRs will accumulate slowly (~5-10/cycle at current cadence) - The MCP-merge gap might be the immediate-fixable surface (just expose the parameter); cheaper than a separate workflow - Sprint 4 (#148 + #155 bake + naming) is the next active surface Foldable into a future cleanup wave or filed as a standalone follow-up if MCP-merge gap closure doesn't pan out. ### Composition - **#153** companion: rc-tag lifecycle (closed via #164 auto-prune); both #153 and #154 surface the same "Forgejo cleanup-on-merge isn't reliable + the toolkit needs its own substrate-state-hygiene" lesson at different surfaces (tags vs branches) - **#163** + **#167** + **#170**: substrate-of-record hygiene wave; the housekeeping-workflow follow-up could fold here naturally ### Closing Closing this tracker. The bulk-prune is done; the upstream investigation continues on a separate alcatraz-infra tracker; the housekeeping-workflow is held pending the MCP-merge gap investigation.

quartermaster closed this issue

2026-06-27 11:02:02 +02:00