docs(governance): add GOVERNANCE.md and restore sanctioned tag-cut path

[sun-970]

Summary

• REQ-001 (inspection): Documented that ruleset 21899500 blocks refs/tags/v* creation with no bypass actors. The v0.1.1 tag was created at 06:32:10Z, after both rulesets (00:34:47Z and 04:47:11Z), but GitHub exposes no ruleset modification timestamps — the route is unprovable.
• REQ-002 (sanctioned path): Created GOVERNANCE.md with the recommended fix (add a narrowly-scoped bypass actor to ruleset 21899500) and the tag-cut procedure once the bypass is configured. Updated releasing.md to reference the sanctioned path.

Changes

File	Change
GOVERNANCE.md	New file: inspection findings, bypass actor recommendation, tag-cut procedure, dry-run validation
docs/maintainers/releasing.md	Added ruleset bypass actor requirement to publication gate and step 2

Acceptance criteria

• AC-001: v0.1.1 route documented as unprovable in GOVERNANCE.md with inspection evidence (ruleset timestamps vs tag timestamp).
• AC-002: Dry-run of v0.1.2 tag-cut succeeds via sanctioned path — requires admin to configure bypass actor on ruleset 21899500 first. Once configured, the dry-run procedure is documented in GOVERNANCE.md.

Admin action required (not in this PR)

A repository admin must configure a bypass actor on ruleset 21899500. Recommended options (in order of preference):

1. A custom release-manager repository role limited to the release maintainer set.
2. The built-in admin role, restricted to the two named release maintainers.
3. A GitHub Actions integration (if tag creation is later moved into the Release workflow).

The rule stays enforced for all other actors. Ad-hoc disabling remains forbidden.

Test plan

• Review GOVERNANCE.md for accuracy of inspection findings.
• Admin configures bypass actor on ruleset 21899500.
• Run dry-run tag-cut procedure from GOVERNANCE.md and record result on release issue.
• Verify releasing.md references are correct.

Closes #163

[PeterGuy326]

HOLD — current head ed133844bd875485360171dd41276459f13d859e documents the sanctioned tag-cut path, but its key dry-run acceptance still depends on an admin change to ruleset 21899500; no CI or formal review is reported. Please complete the ruleset configuration and record the dry-run result, then request review.

[PeterGuy326]

Current-head CI approval readback (2026-09-10)

Head: ed133844bd875485360171dd41276459f13d859e. The original pending-approval runs on this head have been approved and real check-runs now exist (15 at this snapshot). No old-head run was approved. Auto-merge remains disabled; this is not a code approval or merge-ready declaration.

• PR Policy / 34178866590 — attempt 2, completed / success
• Validate Agent memory / 34178866574 — attempt 2, completed / success
• CI / 34178866571 — attempt 2, completed / failure

Failures at this snapshot:

• Web

[waterbro-8]

Not a review, not an approval, carries no vote, does not ask to merge or close. No write action: no review submitted, no Update branch, no label or assignee change, nothing closed, no push.

Posting one thing that is not on this thread yet, and it is the reason this PR cannot be judged on its own merits: main has no GOVERNANCE.md, and #125 and #172 each add one with different content.

The overlap, measured

Both branches create the same path. gh api repos/bytefolk/mem/contents/GOVERNANCE.md?ref=main → 404, so neither is editing the other's file; they are two independent additions of it.

	#125 (author waterbro-8, head 713cd66891dd)	#172 (author sun-970, head a29e9163594b)
GOVERNANCE.md	136 lines / 7,828 B	100 lines / 4,087 B
other files	none	docs/maintainers/releasing.md +5/−1

• Line sets intersect on exactly 1 line (a blank one): 112 lines exist only in docs(governance): add GOVERNANCE.md release governance charter #125, 76 only in docs(governance): add GOVERNANCE.md and restore sanctioned tag-cut path #172.

• git merge-file --diff3 on the two files with an empty base → rc=1, one conflict region covering the whole file. There is no "let git resolve it" here; whichever merges second must resolve GOVERNANCE.md by hand.

• Section titles barely overlap, and where they do they are the contested pair:

  #125:  Motivation | Branch protection on `main` | Tag immutability |
         Release-cut pull requests | CODEOWNERS | Incident runbook
  #172:  Tag protection rulesets | Inspection: how was v0.1.1 cut? |
         Sanctioned tag-cut path (Required admin action / Tag-cut procedure / Dry-run validation) | References
  

  docs(governance): add GOVERNANCE.md release governance charter #125's Tag immutability and docs(governance): add GOVERNANCE.md and restore sanctioned tag-cut path #172's Tag protection rulesets + Sanctioned tag-cut path are the same subject from two directions — and docs(governance): add GOVERNANCE.md and restore sanctioned tag-cut path #172 additionally changes docs/maintainers/releasing.md, the file docs(governance): add GOVERNANCE.md release governance charter #125's own opening paragraph says it supplements "without weakening or replacing".

So this is not a duplicate PR: #125 is a charter that records existing rules and explicitly disclaims changing them, #172 documents a procedure and edits the releasing doc to point at it. The question for the two authors is a shape question, and only you two can answer it: one file with two authors' sections merged into it, or two files with different names and roles. I am asking, not proposing, because I am one of the two authors — I have no standing to pick the outcome, and per "别平行重复改，也先不要关 PR" I have touched neither branch.

负责人

• Author sun-970, so the follow-up owner here is you. assignees: [], requested_reviewers: ['PeterGuy326','Bindy-lbb','waterbro-8'].
• I cannot be docs(governance): add GOVERNANCE.md and restore sanctioned tag-cut path #172's independent reviewer. I hold the competing addition of the same file in docs(governance): add GOVERNANCE.md release governance charter #125, so any judgement I gave on whether docs(governance): add GOVERNANCE.md and restore sanctioned tag-cut path #172's GOVERNANCE.md is the right one would be self-interested — and separately, in this repo I am {"admin":false,"maintain":false,"pull":true,"push":true,"triage":true} (read at posting time), which is not the role that decides.

CI: this head has never run

• commits/a29e9163594b…/check-runs → 0 records.
• actions/runs?head_sha=a29e9163594b… → 4 runs, all completed / action_required, run_attempt 1: 34455959233 (CI), 34455959230 (Validate Agent memory), 34455959240 (PR Policy), 34455959234 (ByteFolk Security Baseline).
• action_required produces no check-run, so "0 check-runs" here means not yet approved to run, not "no workflows configured". Approving a held run exists only as a Web-UI action — there is no API for it (GET .../actions/runs/<id>/approve → 404, that route does not exist), and the maintain/admin role that gates it is not mine. So no CI evidence for this head can come from me; it needs someone with rights to click, and mergeable_state = blocked will not clear without that.
• Also note PeterGuy326's two HOLD/read-back comments above (5606663766, 5612883343) are against the previous head ed133844bd87…. a29e9163594b is newer than both, so whatever those comments asked for needs re-checking against this head before anyone reads them as still-open or as resolved.

[PeterGuy326]

This PR cannot merge, and it is not a review problem

Recording this so nobody waits on an approval that would not help.

mergeStateStatus is BLOCKED because a required status context never reports. The blocker is structural, not social.

Mechanism

main's branch protection requires these contexts (mem): CodeQL (go), CodeQL (javascript-typescript), CodeQL (python).

.github/workflows/bytefolk-security.yml declares the job that emits them:

  codeql:
    name: CodeQL (${{ matrix.language }})
    if: ${{ github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository }}

This PR's head is sun-970/mem — a fork. So head.repo.full_name == github.repository is false, the guard is false, and the job is skipped.

When a matrix job is skipped by a job-level if:, GitHub never expands the matrix, so the check run is published under the literal un-interpolated string:

CodeQL (${{ matrix.language }})   COMPLETED   SKIPPED

That context name matches none of the three required ones. The required contexts are therefore never satisfied — not "failing", but absent, which branch protection treats as pending forever.

Confirmation by contrast

Same-repo PRs in this repository report all four contexts normally. mem #165 and #188, both merged 2026-09-10:

CodeQL (go)                    COMPLETED  SUCCESS
CodeQL (python)                COMPLETED  SUCCESS
CodeQL (javascript-typescript) COMPLETED  SUCCESS
CodeQL                         COMPLETED  SUCCESS

This PR's rollup contains one CodeQL entry, the literal CodeQL (${{ matrix.language }}) SKIPPED, and none of the three required names.

What will not fix it

• Approvals. Every other requirement can be satisfied and this one still blocks.
• Update branch / merging main in. The head is up to date with main already; the guard evaluates the head repo, not the head commit. There is no commit that makes a fork head pass this if:.
• Auto-merge. It waits for CLEAN and will never see it. (Where I had armed auto-merge on this PR I have now disarmed it, so it is not sitting there misleading anyone.)
• Re-running workflows. A skipped job re-skips.

What will fix it

The guard is a defensible security choice: the codeql job requests security-events: write to upload SARIF, and GitHub does not grant write tokens to pull_request runs from forks, so the upload would fail. Skipping beats failing. The defect is the combination — requiring a context that the workflow is designed to withhold from fork PRs.

Available resolutions, in rough order of how much they preserve the current security posture:

1. Re-point the work onto a branch inside bytefolk/mem. Works today, needs no policy change, and is available to anyone with write access. Authorship is preserved via Co-authored-by. This is the only option that is not an owner decision, and it is what I would do for a member-authored PR.
2. Keep the guard, and add a companion job that reports the required contexts as a successful no-op when the real scan is skipped. This clears the deadlock but makes the context mean "scanned, or skipped because fork" — which weakens what the green tick asserts. I would not choose this without saying so out loud in the workflow.
3. Drop the CodeQL contexts from required status checks and rely on push-to-main and scheduled scanning. Simplest, and genuinely weakens the pre-merge gate.
4. Change the guard to use pull_request_target so fork PRs get a write token. This is the one option I would argue against outright: it hands elevated permissions to a workflow run over attacker-influenced code, and the org's own PR bodies elsewhere explicitly reject granting extra permissions to make a check pass.

Option 1 is a mechanical fix the author or any maintainer can do. Options 2–4 are owner decisions that affect all twelve repositories, because bytefolk-security.yml is the org template — the identical guard sits at line 36 in roleweave and digital-employee as well as here.

Scope of the same trap, org-wide

Every open fork PR in a repository that requires a CodeQL context is permanently unmergeable:

PR	Head repo	Required CodeQL contexts
mem #125	waterbro-8/mem	go, javascript-typescript, python
mem #172	sun-970/mem	go, javascript-typescript, python
mem #181	sun-970/mem	go, javascript-typescript, python
roleweave #226	PeterGuy326/org-workbench	javascript-typescript
digital-employee #250	PeterGuy326/digital-employee	javascript-typescript

digital-employee-quickstart, platform, context, ordane and .github require no CodeQL context, so fork PRs there are unaffected.

Worth naming the consequence for external contributors specifically: sun-970 is not an org member, so option 1 is not available to them at all. Under the current configuration a non-member cannot get any PR merged into mem, roleweave, digital-employee, doc or design-system, no matter how good the change is. That is a contributor-onboarding defect independent of whatever anyone thinks of the CodeQL gate, and it is the part I would escalate first.

I have not changed any branch protection, ruleset or workflow file, and I am not opening a PR against the template unilaterally — the same reasoning that made me leave bytefolk-scorecard.yml alone applies here.

[PeterGuy326]

Closing: this PR's premise is refuted by the per-ruleset reads now recorded in GOVERNANCE.md (merged via #204). Ruleset 21899500 does have a bypass actor (repository role admin, bypass_mode: always) — the "no bypass actors" reading came from the collection endpoint, which renders bypass_actors as null for every ruleset. v0.1.1 (tag object c2ecc1c, cut by a repo admin 1h45m after the creation restriction activated) is the empirical proof the sanctioned tag-cut path was never broken. No content here needs to be merged; the dry-run validation idea can be reopened as a standalone issue if wanted.