3 commits

Author	SHA1	Message	Date
Emi Griffith	ea613e33ca	flow: squash into dev, fast-forward the promotions ... Forgejo cannot scope merge styles per branch — they live on the repo's pull-request unit, and BranchProtection carries no merge-style or linear-history field in 9.0.3. So the chain is enforced repo-wide by allowing exactly two styles: squash and fast-forward-only. Merge commits and rebase merges are off. Squash belongs on the short-lived hop. Squashing dev into main would put a commit on main that does not have dev's commits as ancestors, freezing merge-base(dev, main); every later promotion would then list all commits since that stale point and re-apply changes main already has. Fast-forwarding the promotions instead means a promotion creates no commit at all, so the three branches keep identical history rather than merely identical trees, and `release ⊆ main ⊆ dev` holds permanently. Rebase-updates stay enabled. They are a different setting from rebase merges, and BRANCHING.md is right that the merge queue 403s without them. Also adds `release` to pr-build.yml's pull_request branches. This is step one of the order BRANCHING.md prescribes for closing the missing check on release: teach the workflow to fire there, confirm on a real PR that the context appears, and only then require it. Requiring a context nothing produces is what makes a production promotion unmergeable with a 405 that names no cause.	2026-08-01 17:14:45 -07:00
Emi Griffith	1d4defefb9	BRANCHING: the escape hatch, now that apply_to_admins binds the owner too ... Protection an admin walks through is documentation rather than a control, so apply_to_admins goes on — but that removes the direct-push route for everyone, including in an emergency, and the way back in should be written down before it is needed rather than improvised. There is no force flag; the supported route is lift the rule, act, restore it, with both halves audited. Names the failure mode that actually justifies it: a renamed status context makes the required check unsatisfiable, and with apply_to_admins on that blocks every merge into dev and main with no exemption for anyone.	2026-07-26 15:05:26 -07:00
Emi Griffith	890cb4a764	docs: the orchestrator runbook and the module map ... .claude/BRANCHING.md — how the trunk-based flow is actually run: the serialised merge queue (Forgejo has no native one, so whoever orchestrates is it), the two promotions and who decides each, and the hotfix down-merge that has to happen in the same session or it becomes a regression scheduled for the next promotion. Two things it states because getting them wrong is expensive here. CI does not gate PRs into `release` — pr-build.yml fires only for dev and main — so a required check on that branch would make every production promotion unmergeable with a 405 naming no cause; closing that gap means changing the workflow first and turning the requirement on second. And the chain cannot fast-forward: every promotion leaves a merge commit on the target the source never receives, so promotions are merge commits until someone deliberately reconciles the branches. .claude/ownership.md — which tasks may run concurrently, seamed along the four domains, plus the shared spine that has to be serialised: the workflows (CI lives only in the root .forgejo/), env-topology.sh, the deploy entry points and the CLAUDE.md files. Names the recurring collisions too — a schema change spans alembic and whatever reads the column, and if the payload shape moves it is PAYLOAD_VER and the frontend as well, which is one task and not two.	2026-07-26 12:53:33 -07:00