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

Activity

1. PeterGuy326

   added

   status:readyScope and acceptance criteria are ready for developmentScope and acceptance criteria are ready for development

   priority:p0Required for the next shared product proofRequired for the next shared product proof

   on Sep 3, 2026
2. sun-970

   added a commit that references this issue on Sep 10, 2026

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

   ...

   This issue will close once commit a29e916 is merged into the 'main' branch.

   a29e916
3. PeterGuy326 commented on Sep 10, 2026

   

   PeterGuy326

   on Sep 10, 2026

   CollaboratorAuthor

   More actions

   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.
4. waterbro-8 commented on Sep 17, 2026

   

   waterbro-8

   on Sep 17, 2026

   Collaborator

   More actions

   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.