release(tag-path): verify v0.1.1 tag route and restore a sanctioned tag-cut path under ruleset 21899500

[PeterGuy326]

schemaVersion: requirement-record.v1
revision: R1
status: ready
priority: P0
productOwner: "@PeterGuy326"
technicalOwner: "@PeterGuy326"
userOutcome: "The release runbook's 'cut a new patch tag' step is actually executable under the current rulesets, with the v0.1.1 route documented or a sanctioned replacement in place."
requirements:
  - REQ-001
  - REQ-002
acceptanceCriteria:
  - AC-001
  - AC-002
parent: null
dependencies:
  - "https://github.com/bytefolk/mem/issues/125"
supersedes: []
lastDecisionAt: null

User problem and observable outcome

Ruleset 21899500 (Restrict stable release tag creation) blocks refs/tags/v* creation with no bypass actor. GitHub exposes no ruleset timestamps, so nobody can prove which path v0.1.1 actually used; if that path no longer exists, the GOVERNANCE.md runbook step "cut a new patch tag" is unexecutable today. This is a repository-configuration problem, not a documentation problem — split out of #125 by owner decision 2026-09-03.

Requirements

• REQ-001: Admin-only inspection of ruleset 21899500 configuration and repo tag history to determine (a) how v0.1.1 was cut, and (b) whether any sanctioned tag-cut path exists today.
• REQ-002: Restore exactly one sanctioned path — either a narrowly-scoped bypass actor (release workflow / Trusted Publishing) added to 21899500, or a documented admin-executed tag-cut procedure recorded in GOVERNANCE.md. Ad-hoc rule disabling is forbidden; the rule stays enforced for everyone else.

Acceptance criteria

• AC-001: The v0.1.1 route is documented (or explicitly marked unprovable) in GOVERNANCE.md with the inspection evidence.
• AC-002: A dry-run of the v0.1.2 tag-cut step succeeds via the sanctioned path without disabling 21899500, and the result is recorded in the release evidence ledger.

Non-goals

• No changes to npm scope migration ([Release] Migrate mem-mcp to @bytefolk/mem-mcp v0.1.2 #153) or Trusted Publishing setup (.github#22) — those are separate pre-release actions.
• No retrospective judgment on historical merges; status quo ante is recorded, not relitigated.

[PeterGuy326]

Premise correction: ruleset 21899500 does have a bypass actor, and the v0.1.1 route is provable

This issue's stated mechanism — "Ruleset 21899500 … blocks refs/tags/v* creation with no bypass actor" and "GitHub exposes no ruleset timestamps, so nobody can prove which path v0.1.1 actually used" — is not what the live configuration says. Read back on 2026-09-11:

1. GET /repos/bytefolk/mem/rulesets/21899500

{"name":"Restrict stable release tag creation","target":"tag","enforcement":"active",
 "conditions":{"ref_name":{"include":["refs/tags/v*"],"exclude":[]}},
 "rules":["creation"],
 "bypass_actors":[{"actor_id":5,"actor_type":"RepositoryRole","bypass_mode":"always"}]}

actor_type: RepositoryRole with actor_id: 5 is Admin (GitHub's role IDs: 1 Read · 2 Triage · 3 Write · 4 Maintain · 5 Admin), and bypass_mode: "always". So repository admins are explicitly exempted from the creation rule.

Note the collection endpoint GET /repos/bytefolk/mem/rulesets renders bypass_actors: null — the bypass actor is only visible on the single-ruleset endpoint. That is the most likely source of the "no bypass actor" reading.

For contrast, the sibling ruleset 21888356 ("Protect stable release tags", rules: ["update","deletion"]) genuinely has "bypass_actors": [] — no bypass. That is the one #122 step 3 describes ("permits creation and blocks update/deletion with no bypass"), and it is accurate. The two rulesets appear to have been conflated here.

2. Ruleset timestamps are exposed, contrary to the issue text:

ruleset	created_at	updated_at
21888356 Protect stable release tags	2026-08-31T08:34:47+08:00 (00:34:47Z)	2026-08-31T08:34:47+08:00
21899500 Restrict stable release tag creation	2026-08-31T12:47:11+08:00 (04:47:11Z)	2026-08-31T12:48:05+08:00 (04:48:05Z)

3. The v0.1.1 route is therefore provable, and it is the sanctioned one. GET /repos/bytefolk/mem/git/tags/c2ecc1c49ff8bbe13b9d7800bc910e4b7ac99b74:

tag: v0.1.1        message: "Release v0.1.1"
tagger: PeterGuy326   date: 2026-08-31T06:32:10Z
object: cc727db0bc72655f299166de1f60756f5c686cc7  (the #130 release-prep merge commit)

The tag was created by a repository admin 1h45m after ruleset 21899500 became active, it is an annotated tag (type tag, not commit), and it sits exactly on the reachable release merge commit. The GitHub Release v0.1.1 (published_at 2026-08-31T06:34:08Z, author github-actions[bot]) carries the six platform binaries plus mem-mcp-checksums.txt. That is an admin push through the actor_id: 5 bypass — a normal, currently-executable path, not an ad-hoc rule disabling.

Consequence for the requirements

• REQ-001 is answered by the read-back above: (a) v0.1.1 was cut by an admin under the bypass; (b) a sanctioned tag-cut path exists today and is the documented docs/maintainers/releasing.md §"cut a new annotated tag and push only that new tag" step.
• REQ-002 — "restore exactly one sanctioned path" — has nothing to restore. Adding a further bypass actor (release workflow / Trusted Publishing) would be a new widening of tag-creation authority, and releasing.md:77-89 deliberately states the opposite contract: "Publication is deliberately split at the tag boundary. The workflow never creates, moves, or replaces a tag" and "the input is not permission to create a tag." So option (a) of REQ-002 contradicts the existing runbook; option (b) is already the status quo.
• AC-001 is satisfiable now, with the evidence above, as "documented" rather than "unprovable".
• AC-002 — a v0.1.2 tag-cut dry run — is not blocked by 21899500. What actually gates it is upstream: @bytefolk/mem-mcp does not exist on npm yet, npm/package.json on main is still @fullstack-ai-infra/mem-mcp@0.1.1, and npm authentication returns ENEEDAUTH ([Release] Migrate mem-mcp to @bytefolk/mem-mcp v0.1.2 #153, release: publish mem-mcp v0.1.1 and bootstrap npm Trusted Publishing #122). Cutting v0.1.2 before [Release] Migrate mem-mcp to @bytefolk/mem-mcp v0.1.2 #153's version-surface sync (chore(release): sync every version surface to 0.1.2 #168 / chore(release): prepare ByteFolk mem-mcp 0.1.2 #193) would build binaries that disagree with the package metadata.
• Both ACs are written against GOVERNANCE.md, which does not exist on main — it is still an open deliverable of docs(governance): add GOVERNANCE.md release governance charter #125 / docs(governance): add GOVERNANCE.md and restore sanctioned tag-cut path #172. So this issue remains dependent on that PR landing; its dependencies: entry cites issues/125, which is a pull request, not an issue.

Suggested disposition: keep open, but re-scope to "record the verified tag-cut mechanism in GOVERNANCE.md once #125 lands", and correct the ruleset description. status:ready is arguably no longer honest for REQ-002 as written, since its premise is false.

Read back via gh api as PeterGuy326. No repository setting, ruleset, branch protection, tag, or PR was modified to produce this comment.

[waterbro-8]

Blocked for this account. REQ-001 needs admin inspection of ruleset 21899500 (Restrict stable release tag creation). gh api here has admin: false / maintain: false on bytefolk/mem, so I cannot read the ruleset bypass list or perform a sanctioned tag-cut dry-run.

I will not disable the ruleset, invent a bypass, or cut v0.1.2. Needs an org owner (issue technicalOwner @PeterGuy326) to record how v0.1.1 was cut and restore exactly one sanctioned path in GOVERNANCE.md.