Repository navigation
stewards: stacked pull requests are visible for their whole life (BB-287) - #316
Conversation
|
Independent review running in bb thread @thread:thr_nvky2ne5fg. — from bb thread thr_wgcg4z2j5y |
Review round 1 (GLM 5.3, at 5e5d19e)Owner review required: yes — the stewards plumbing trigger; decide list entry "The stewards plugin's roles parsing, ready gate and approval and escalation plumbing outside the hard-coded self-widening list" is decide: user ("A store migration" [project] also matched on store.ts, but the user entry decides). @trotterdylan, this one needs your approval — a project-steward bb-approval will not meet this gate; your unsigned approval will. BB-287's approved spec (2026-11-10) covers the product scope, so it is not re-asked. Reviewed the diff against the stacked base 08cf33f (PR #315's head). The move of Tested
Looks good. — from bb thread thr_nvky2ne5fg |
|
Approved 5e5d19e from the Stewards page |
35c9392 to
548f3d7
Compare
2429e36 to
5393543
Compare
…ch (BB-289) (#317) `sourceDependabotAlerts` gains an additive, optional `graphEmpty: string[]`: the repositories whose GraphQL `dependencyGraphManifests(first:1){totalCount}` is zero, so an empty alert list means Dependabot cannot see any manifest rather than that there is nothing open. A failed graph read is not an empty graph: the repo stays unflagged. The contract copy is updated in all three plugins, and the deps-alerts wake and `bb stewards check` now say "dependency graph empty" and name the by-hand toggle (repo Settings → Advanced Security → Dependency graph) instead of "no open alerts". Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
5393543 to
e97f7c2
Compare
|
Rebased #316 and re-pointed its base at
No branch deleted, and not merged — left for the steward. — from bb thread thr_qjdrvtue2g |
|
Merged: owner-reviewed lane, reviewer approved 5e5d19e, checks green, approved by the owner, escalated by the reviewer to the owner. |
1 similar comment
|
Merged: owner-reviewed lane, reviewer approved 5e5d19e, checks green, approved by the owner, escalated by the reviewer to the owner. |
…ds (BB-288) (#319) Implements [BB-288](https://linear.app/bit-complete/issue/BB-288). The learning loop never completed: no wake or brief showed a `gu_` id, so no hand-written guidance unit could be cited; trial lessons read as owner to-dos; and a lesson's pull request was merged by its scope, not by the decide list. This renders the ids, moves trial lessons onto the project steward's early-land path, places lesson PRs by the ordinary decide list, and stops the efficacy view blaming guidance before ids ever rendered. > **A merge to `bb-plugins` `main` moves the pin, builds a new `bb-server` image and stages a restart for every developer's server** (`.bb/AGENTS.md`, "Shipping a plugin change"). Anyone who never presses Restart now is updated in the quiet window, 03:00–05:00 US Eastern. Was stacked on #316, which squash-merged to `main` at 11:54Z; this branch is rebased onto `main` and the PR is retargeted to it. ## Classification owner-reviewed: the decide-list entry "The stewards plugin outside its authority seams (the app and the sidebar UI, its skills, every other stewards file)" (`decide: project`) matches the seven changed files, so the project steward approves. No self-widening file (`decisions.ts`, `gate.ts`, `approvals.ts`, `approvals-store.ts`, `.bb/stewards/project.json`) is touched, and no approval-recording code is added. ## What changes - `wake.ts`: a compact `## Guidance units` index (id, file, heading, a 120-char snippet) in the binding wake, the brief and the project steward's wake, listing the binding's playbook units before AGENTS.md and placed where `fit` can clip it, so it never costs the snapshot or "What changed"; the project steward's `## Lessons (trial)` block names the early-land command and says trial lessons are not owner to-dos. - `lessons.ts`: `lessonLandingMark` places a lesson by `decideForPull` on its file (a `boundary` lesson stays the user's); `landLessonInstruction` is the one early-land sentence the wake and the record reply share. - `server.ts`: wakes and briefs carry the AGENTS.md and binding-playbook units; `mergeLessonPr` consults the decide list and merges a `project`-file (playbook) lesson exactly as before, while a `user` file (`AGENTS.md`, the project file, `roles.json`) files the owner's Review PR/Drop item and does not merge; the first `gu_` render is stored and `bb stewards lessons --efficacy` suppresses the "uncited for 90 days" list until 90 days after it. - `skills/stewards/SKILL.md`: the landing rule now names the decide list. ## Testing - `npm run typecheck`: pass. - `npm test`: pass (32 files, 1528 tests; not all in the plugins CI matrix). - New tests: the wake/brief render a `gu_` id beside each unit; a realistic 75-unit index lists every id and a 1000-unit one still keeps "## 4. Snapshot" and "## 5. What changed"; the binding's playbook units are listed before AGENTS.md; the project wake names the early-land command and the digest record carries no trial lesson; `lessonLandingMark` places a playbook lesson `project` and an AGENTS.md lesson `user` against the entry BB-280 landed; the server e2e merges a playbook procedure lesson as the project steward's with no `bb-approval` marker, and files an AGENTS.md procedure lesson for the owner (not merged, Review PR/Drop filed); `lessons --efficacy` is suppressed before 90 days and lists after. - Not tested: no live bb-server; the behaviour is unit- and harness-tested.
Implements BB-287. Stacked pull requests are visible for their whole life, not only once the stacked pull request's gate is met.
Base PR: #315.
Classification
owner-reviewed:
plugins/stewards/server.tsandwake.tsare the plumbing entry the project'suserdecide-list entry names.What changes
syncNeedsreadspullBaseDispositionfor every open own pull request, not only underif (g.gateMet), so the "Retarget" wake fires on a base merge for a stacked pull request that is not yet gate-met (acceptance criterion 1).BASE OF:change and a standing line) and inbb stewards show(a newstacked_pullsbinding field) (criterion 2).<sha>, reopen or replace, approvals carry" (criterion 3, a newstacked_recoveredfield, once per pull request).plugins/stewards/skills/build-tickets/SKILL.md: never delete a branch that is the base of an open pull request, and thegh pr list --base <branch> --state opencheck. This complements BB-282's.bbedit without reintroducing--delete-branch.github.ts:openPullsByBase,branchExists, andpullByHeadnow returns the base branch's lastheadShafor the recovery text.Criterion 4 (the by-hand
delete_branch_on_mergecheck and the.bb/AGENTS.mdline) is out of scope for this PR: it is a separatebb-gatePR, opened only after bb-gate#110 merges.Testing
cd plugins/stewards && npm test: pass (1507 tests; 3 new BB-287 tests, not in the CI matrix).cd plugins/stewards && npm run typecheck: pass.delete_branch_on_mergebehaviour (criterion 4), which is a separate bb-gate PR.