vrr/open-notebook
2
0
Fork 0
mirror of https://github.com/lfnovo/open-notebook.git synced 2026-10-19 09:13:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
open-notebook/.claude/skills/release/gates.md
Luis Novo 9bd5f89c59
Some checks are pending
Development Build / extract-version (push) Waiting to run
Details
Development Build / changes (push) Waiting to run
Details
Development Build / build-regular (push) Blocked by required conditions
Details
Development Build / build-single (push) Blocked by required conditions
Details
Development Build / summary (push) Blocked by required conditions
Details
Tests / Frontend Lint (push) Waiting to run
Details
Tests / Frontend Build (push) Waiting to run
Details
Tests / Backend Tests (push) Waiting to run
Details
Tests / Backend Lint (push) Waiting to run
Details
Tests / Backend Typecheck (push) Waiting to run
Details
Tests / Frontend Tests (push) Waiting to run
Details
chore: version .claude skills and agents as shared project tooling (#1272) 
* chore: version .claude skills and agents as shared project tooling

The process-discussions skill encodes the Discussion facilitation
mechanics announced publicly in the Open Contribution bets (#1212,
#1270); the release skill orchestrates the process documented in
.github/RELEASE_PROCESS.md; the QA agents (harness-qa, smoke-e2e)
support contributor and release workflows. Versioning them makes the
process inspectable and reviewable instead of living only on one
machine.

Personal state (settings.local.json, sessions, worktrees) stays
ignored via the .claude/* allowlist pattern.

* docs(skills): add incubating status, pull-based graduation and close-on-answer to process-discussions

* docs(skills,agents): address review findings — GHCR -single manifest check, contributor list truncation, global ask note, regenerable node ids
2026-09-02 11:38:32 -03:00

2 KiB
Raw Blame History

Gates — what needs a human, what doesn't

The contract that made v1.11.0 safe. When in doubt, ask — a blocked action is feedback, not an obstacle to route around.

You may do autonomously (once the release run is underway)

  • Run any test, build, probe or analysis; start/stop local dev services
  • Create branches, commits, and open PRs
  • Spawn subagents (smoke-e2e, investigation, fixes)
  • Build/pull Docker images locally; run the release-test harness and RC stack
  • Dispatch the Build and Release CI workflow with push_latest=false (version tags only — this is the agreed pre-verification push)

Requires explicit, in-session authorization from the owner

Action Why
Merging PRs you authored two-party review; ask once per session ("merge when clean?") and honor the answer
Publishing the GitHub release public, triggers v1-latest — the point of no return
Anything that pushes v1-latest users receive it immediately
Creating GitHub issues external artifacts the owner may not want
Mass-labeling issues (released) bulk modification of shared state
Touching the owner's dev data only ever work on copies (export/import); never mount or mutate originals

Never

  • Push directly to main
  • Publish a prerelease/release to work around a blocked step
  • Mark a phase complete with failing checks ("GO with known issues is worse than a NO-GO that catches problems before users do")

Re-test policy after each fix merge

  • Cheap suite (pytest + lint + frontend tests/build): always
  • smoke-e2e / image gate: only if the fix touches what they cover
  • Owner's manual verification: only if the fix touches what they verified
  • The final image gate (Phase 5.3) always runs on the exact release artifact

GO/NO-GO

A release is GO when: bucket A fully green · image gate green (fresh + upgrade) · bucket C signed off by the owner · no open release-regression findings · Dependabot highs resolved or explicitly accepted.