mosaicstack/stack
1
0
Fork 1
Code Issues 246 Pull Requests 7 Actions Packages Projects Releases 15 Wiki Activity

Branch-model layering conflict: L0 Constitution gates 5/15 hardcode main; commissioned next-first policy (#1214/PR #1215) cannot merge until controlling sources align #1216

New Issue
Closed
opened 2026-08-13 17:37:27 +00:00 by mos-dt-0 · 3 comments
mos-dt-0 commented 2026-08-13 17:37:27 +00:00
Collaborator
Copy Link
Copy Source

Problem

Jason commissioned (2026-08-13) codifying the repo's actual branch model in root AGENTS.md: every contribution targets next; main is promotion-only. PR #1215 implements this. Independent review (scrappy) returned AMEND/HOLD, blocker B1: the repository ships its own L0 layer, and L0 is supreme — a project AGENTS.md may only tighten, never contradict.

Conflicting shipped surfaces (exact citations from review of head 2d7a932d):

  • packages/mosaic/framework/defaults/CONSTITUTION.md:15-18 — L0 supremacy / tighten-only precedence
  • Constitution gate 5 (:28) — completion requires a merged PR to main
  • Constitution gate 15 (:38) — branch from main, reviewed squash merge to main
  • packages/mosaic/framework/guides/E2E-DELIVERY.md:81,202 — PR to main; completion = merged to main
  • packages/mosaic/framework/guides/CODE-REVIEW.md:11-16 — HARD RULE: PR target and squash merge target are main
  • packages/mosaic/framework/defaults/AGENTS.md:83-86 — session closure records merge commit on main

B2 (absolute author≠merger vs gate 13) was withdrawn by the reviewer: removing a permission is a valid project-level tightening.

Required disposition (operator-owned)

Hard-gate changes belong to Jason/framework owner. Two options:

(a) Parameterize the trunk (recommended — matches the commissioned policy and actual practice): one atomic PR to next amending, in the same change set: Constitution gates 5/15 (completion and branching defined against "the project's designated integration trunk (default main)"), E2E-DELIVERY PR-target/completion steps, CODE-REVIEW hard rule, defaults/AGENTS.md closure record, and root AGENTS.md (#1215 content rebased to cite the amended gates). Installed ~/.config/mosaic surfaces follow via the normal bootstrap update path.

(b) Keep L0 as-is: rewrite PR #1215 to conform to a main-trunk model — this reverses the commissioned next-first directive and diverges from how the repo actually operates (next=f82307c4 is the live integration trunk; promotion to main is Jason-owned).

PR #1215 stays open under AMEND/HOLD until this issue is resolved. A root-only patch cannot pass review.

Refs: #1214, #1215, review verdict comms 20260813T173430Z__from-scrappy__7def5e (jarvis-brain), #1152 (historical divergence debt the policy addresses).

## Problem Jason commissioned (2026-08-13) codifying the repo's actual branch model in root `AGENTS.md`: every contribution targets `next`; `main` is promotion-only. PR #1215 implements this. Independent review (scrappy) returned **AMEND/HOLD, blocker B1**: the repository ships its own L0 layer, and L0 is supreme — a project `AGENTS.md` may only tighten, never contradict. Conflicting shipped surfaces (exact citations from review of head `2d7a932d`): - `packages/mosaic/framework/defaults/CONSTITUTION.md:15-18` — L0 supremacy / tighten-only precedence - Constitution gate 5 (`:28`) — completion requires a merged PR to `main` - Constitution gate 15 (`:38`) — branch from `main`, reviewed squash merge to `main` - `packages/mosaic/framework/guides/E2E-DELIVERY.md:81,202` — PR to `main`; completion = merged to `main` - `packages/mosaic/framework/guides/CODE-REVIEW.md:11-16` — HARD RULE: PR target and squash merge target are `main` - `packages/mosaic/framework/defaults/AGENTS.md:83-86` — session closure records merge commit on `main` B2 (absolute author≠merger vs gate 13) was **withdrawn** by the reviewer: removing a permission is a valid project-level tightening. ## Required disposition (operator-owned) Hard-gate changes belong to Jason/framework owner. Two options: **(a) Parameterize the trunk (recommended — matches the commissioned policy and actual practice):** one atomic PR to `next` amending, in the same change set: Constitution gates 5/15 (completion and branching defined against "the project's designated integration trunk (default `main`)"), E2E-DELIVERY PR-target/completion steps, CODE-REVIEW hard rule, defaults/AGENTS.md closure record, and root `AGENTS.md` (#1215 content rebased to cite the amended gates). Installed `~/.config/mosaic` surfaces follow via the normal bootstrap update path. **(b) Keep L0 as-is:** rewrite PR #1215 to conform to a `main`-trunk model — this reverses the commissioned next-first directive and diverges from how the repo actually operates (`next`=`f82307c4` is the live integration trunk; promotion to `main` is Jason-owned). PR #1215 stays open under AMEND/HOLD until this issue is resolved. A root-only patch cannot pass review. Refs: #1214, #1215, review verdict comms `20260813T173430Z__from-scrappy__7def5e` (jarvis-brain), #1152 (historical divergence debt the policy addresses).
mos-dt-0 commented 2026-08-13 18:36:52 +00:00
Author
Collaborator
Copy Link
Copy Source

RULED by Jason (2026-08-13, relayed by fred): Option (a).

His reasoning, verbatim intent: the constitution must supply the general framework and allow the user/project to establish its desired flow — forcing a branch naming convention in the constitution is bad structure.

Execution plan (fred):

  1. One atomic PR to next parameterizing the L0 contract files on "the project's designated integration trunk (default: main)": CONSTITUTION.md gates 5/15, E2E-DELIVERY.md, CODE-REVIEW.md, framework defaults AGENTS.md — plus the declaration mechanism (a project's AGENTS.md declares its integration trunk; absent declaration = main, so every existing project is unchanged).
  2. Full gates: CI terminal green, independent exact-head review (scrappy), author≠merger. As an L0 change it remains operator-owned: merge executes only on Jason's explicit go.
  3. After it lands on next: PR #1215 (branch-process AGENTS.md) comes off HOLD as a now-legal tightening and gets its fresh-head re-gate.

Dispatched to the pi fleet as card L0-TRUNK-PARAM.

**RULED by Jason (2026-08-13, relayed by fred): Option (a).** His reasoning, verbatim intent: the constitution must supply the general framework and allow the user/project to establish its desired flow — forcing a branch naming convention in the constitution is bad structure. Execution plan (fred): 1. One atomic PR to `next` parameterizing the L0 contract files on "the project's designated integration trunk (default: `main`)": CONSTITUTION.md gates 5/15, E2E-DELIVERY.md, CODE-REVIEW.md, framework defaults AGENTS.md — plus the declaration mechanism (a project's AGENTS.md declares its integration trunk; absent declaration = `main`, so every existing project is unchanged). 2. Full gates: CI terminal green, independent exact-head review (scrappy), author≠merger. As an L0 change it remains operator-owned: merge executes only on Jason's explicit go. 3. After it lands on `next`: PR #1215 (branch-process AGENTS.md) comes off HOLD as a now-legal tightening and gets its fresh-head re-gate. Dispatched to the pi fleet as card L0-TRUNK-PARAM.
mos-dt-0 commented 2026-08-13 18:46:36 +00:00
Author
Collaborator
Copy Link
Copy Source

Option-(a) execution PR is up: #1217 (docs/1216-trunk-parameterization, head 18f960d3e1191291bcd59f44edce5d5d23efd09c, base next). Author fred; independent gate scrappy; merge only on Jason's explicit GO (L0 operator-owned). Known mechanized-consumer follow-up tracked here: framework/tools/git/pr-merge.sh:133 {main,next} allowlist — fail-closed today, to be parameterized against the declaration grammar with red-first tests in a separate code PR.

Option-(a) execution PR is up: **#1217** (`docs/1216-trunk-parameterization`, head `18f960d3e1191291bcd59f44edce5d5d23efd09c`, base `next`). Author fred; independent gate scrappy; merge only on Jason's explicit GO (L0 operator-owned). Known mechanized-consumer follow-up tracked here: `framework/tools/git/pr-merge.sh:133` {main,next} allowlist — fail-closed today, to be parameterized against the declaration grammar with red-first tests in a separate code PR.
mos-dt-0 commented 2026-08-13 22:11:44 +00:00
Author
Collaborator
Copy Link
Copy Source

Closed per Jason's operator ruling (2026-08-13): "1216 is gone" + "branch-model: go".

The layering conflict this issue tracked is superseded by the confirmed v4 branch-model direction: per-repo declared integration trunk (Integration trunk: line in AGENTS.md, read at the pinned tip of the provider default branch — authority location only, never an equality check), absent declaration resolves to main, global default applies at scaffold time only (~/.config/mosaic profile.json). The v3 migration plan (default-branch flip + fail-closed brake) is dead: Stack never flips its default branch.

Dispositions: the v4 mechanism card is with scrappy for full re-review; PR #1217 (L0 trunk parameterization) remains open and appears compatible with v4 — scrappy's re-review will confirm or amend; PR #1215 stays held pending v4 acceptance, then reframes as a one-line declaration on the authority branch.

— fred (adjudicator), posted via fleet principal

**Closed per Jason's operator ruling (2026-08-13): "1216 is gone" + "branch-model: go".** The layering conflict this issue tracked is superseded by the confirmed v4 branch-model direction: per-repo declared integration trunk (`Integration trunk:` line in AGENTS.md, read at the pinned tip of the provider default branch — authority location only, never an equality check), absent declaration resolves to `main`, global default applies at scaffold time only (`~/.config/mosaic` profile.json). The v3 migration plan (default-branch flip + fail-closed brake) is dead: Stack never flips its default branch. Dispositions: the v4 mechanism card is with scrappy for full re-review; PR #1217 (L0 trunk parameterization) remains open and appears compatible with v4 — scrappy's re-review will confirm or amend; PR #1215 stays held pending v4 acceptance, then reframes as a one-line declaration on the authority branch. — fred (adjudicator), posted via fleet principal
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
be-coder-05 be-coder-06 be-coder-07 be-coder-08 coder-mos1 coder-mos2 coder2 coder3 f10-coder fred happy jason.woltje (Jason Woltje) merge-gate mos-dt-0 pepper rev-974 (Rev-974 (Mosaic reviewer seat, web1)) rev-security-02 rev0 sanity scooby (Scooby) scrappy shaggy tess velma
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1216