This runbook is canonical for public, release, and platform-boundary semantics.
Repository docs are not a live platform dashboard.
Product-positioning shorthand in public surfaces should stay: Movi as the brand, movi-organizer as the repo/CLI, a local-first review-first workbench rather than a hosted SaaS or autonomous organizer, and Movi MCP v1 as a repo-local stdio extension surface rather than a hosted agent platform.
The target public shape is:
- public source repository
- GitHub Releases as the canonical release surface
- limited-maintenance collaboration
- no promise of PyPI or public container distribution
In short: limited-maintenance open source + a GitHub source repo + GitHub Releases.
Do not freeze platform state inside a long-lived document. Platform state is like an airport departure board: check the live screen, not a copied note in a travel guide.
Auto-generated: public-surface and platform-state policy facts live in generated governance reference, and required checks matrix.
- Repo public readiness gate:
bash tooling/gates/public_readiness_gate.sh repo - Release public readiness gate:
bash tooling/gates/public_readiness_gate.sh release - Platform alignment gate:
bash tooling/gates/platform_alignment_gate.sh - Release-mode policy: tracked public files=
yes/ public repo=yes/ PVR=yes/ branch protection=yes
To inspect the live GitHub platform state directly, run:
gh repo view --json nameWithOwner,url,isPrivate,defaultBranchRef
gh api repos/<owner>/<repo>/private-vulnerability-reporting
gh api repos/<owner>/<repo>/branches/main/protection
gh release list --limit 5What you actually need to verify:
- Whether the repo-side public surface is complete.
- Whether release-mode constraints are satisfied.
- Whether GitHub is actually exposing the required checks, PVR, release trail, and zero-open-alert security posture.
Do not mistake a repo-mode pass for full platform closure.
repo-sideonly proves that the repository-facing public surface is ready; it does not prove that GitHub has aligned required checks, PVR, or default-branch reality. If branch protection or required checks return 404/permission-limited responses in the currentghsession, treat that asplatform-side-query-blocked, not as a silent pass. Snapshot scope labels used here:repo-side-onlyandplatform-side-not-fresh.
bash tooling/runtime/bootstrap_env.sh
bash tooling/gates/public_readiness_gate.sh repo
bash tooling/gates/public_readiness_gate.sh release
bash tooling/gates/platform_alignment_gate.sh
bash tooling/gates/sensitive_surface_gate.sh --mode all
bash tooling/gates/public_artifact_audit.sh
bash tooling/docs/check_docs_scope.sh
bash tooling/docs/docs_smoke.sh --install-smoke
bash tooling/gates/quality_gate.sh
bash tooling/gates/history_secret_scan.shbash tooling/gates/quality_gate.sh: the only delivery-complete signal. Only a fresh pass lets this snapshot be described as complete.bash tooling/docs/docs_smoke.sh --install-smoke: only smoke-checks command examples and packaging/installability docs. It is not the full docs governance verdict by itself, and this search-before-write note is part of keeping docs navigation and gate boundaries honest.bash tooling/gates/public_readiness_gate.sh repo: checks whether the repo-side public surface is complete.bash tooling/gates/public_readiness_gate.sh release: performs the strict pre-release comparison between tracked files and GitHub platform truth.bash tooling/gates/platform_alignment_gate.sh: closes the loop between release-mode checks and required checks / branch protection as the dedicated platform gate.bash tooling/gates/sensitive_surface_gate.sh --mode all: blocks tracked absolute user-home paths, personal contact data, unsafe header/token dumps, and tracked log/db/key-style artifacts before they leak into the repo surface.bash tooling/gates/public_artifact_audit.sh: verifies that declared public assets and synthetic public fixtures stay inside governed roots, keep allowed classifications, and do not carry obvious dump/secret-style content in text-readable artifact surfaces.- GitHub-hosted workflow security lanes should stay green for current closeout truth:
codeql,dependency-review,zizmor,trivy-fs, andtrufflehog. - Release/platform verification now also requires zero open GitHub code-scanning alerts and zero open GitHub secret-scanning alerts; if the current
ghcontext cannot query them, treat that asplatform-side-query-blocked, not as a silent pass. - If those gates report
query-blocked-permission-context, rerun them with an admin-capable GitHub context before describing platform closure as verified.
Use these entrypoints for release-facing facts:
npm run release:draft
npm run release:evidence
npm run release:truthTreat npm run release:truth as the operator-facing entrypoint for current-head release truth.
Only published_release_verified counts as a verified published closure.
- Confirm the repository is public and the default branch is
main - Verify branch protection and required checks on GitHub
- Verify Private Vulnerability Reporting when the platform supports it
- Confirm
CODEOWNERS, issue templates,SECURITY.md, andSUPPORT.mdare live on the default branch - Verify the release draft or published release against the current tag and assets
Public / release / platform readiness is not the same thing as product-value maturity.