feat(register-check): make REGISTER_PATTERNS adopter-overridable (post-#403 follow-up) #435
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#435
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Motivation
Surveyor 3661 review on PR#434 (#403 close) flagged: the
REGISTER_PATTERNSarray inscripts/register-check.shis currently frankenbit-chamber-specific (Bosun / Surveyor / Herald / Quartermaster / Pilot / Engineer / Shipwright / substrate-honest) and NOT adopter-overridable. Only the allowlist path (.register-allowlist) is overridable.The names are common English words. An adopter who opts into
check_commit_subjects: true(release-toolkit#403) will trip the gate on unrelated content — e.g."The pilot program shipped."or"Our lead engineer reviewed it."FAIL as chamber-name hits. Subjects are especially exposed:feat: pilot the new enginewould fail the PR-gate.Verified live during PR#434 review — Surveyor tested against the shipped gate and confirmed the false-positive class fires on legitimate adopter prose.
Scope
Make
REGISTER_PATTERNSadopter-overridable. Same shape as the#421Part 1 thresholds (workflow input + env-var, empty-default → script fallback to built-in list):scripts/register-check.shwith an env-var override — e.g.REGISTER_CHECK_PATTERNS(newline- or pipe-separated list). When set + non-empty, overrides the built-in array. When unset or empty, falls back to the built-in list (frankenbit-specific, matches release-toolkit maintainer needs)..forgejo/workflows/reusable-register-check.ymlwith an inputregister_patterns_override:(string). Wire through asREGISTER_CHECK_PATTERNSenv in every step that callsregister-check.sh.REGISTER_CHECK_PATTERNS_ADD(append to built-in) vs full override, so adopters who want the frankenbit-specific patterns AND their own extension can do so.Verification AC
--file-scan,--git-log,--stdin)reusable-register-check.ymlheader + input description name the override shape + how adopters compose their own listPriority
Medium — the current default-OFF for
check_commit_subjectsmeans most adopters dont hit the class today. But the file-scan already runs by default on adopters, and the frankenbit-specific patterns will start firing on adopter prose the moment an adopter uses e.g. the word "engineer" in a doc. Not blocking, but a real hygiene bar the toolkit should meet before broader adoption.Anchor
Surveyor review 3661 on PR#434 (2026-07-06) — should-consider #2 flagged as "document in-PR + follow-up tracker." PR#434 lands the documentation (input description names the frankenbit-specificity + points at this tracker); the code fix waits for this tracker.
Related: release-toolkit#403 (parent PR#434), release-toolkit#392 (parent register-check class), release-toolkit#396 (sibling line-level exemption), release-toolkit#402 (sibling allowlist-scope gap).
Register-discipline family — adopter-facing vs maintainer-internal (Surveyor bus 5e14, requested folded here per Bosun routing so the family-cluster framing survives post-sprint).
Three same-sprint findings trace to one axis: a register mechanism built for the frankenbit crew's internal discourse, shipped through an adopter-facing surface without the adopter-vs-internal boundary made explicit.
n=3 structurally distinct on this axis; per over-banking discipline NOT meta-pin-worthy yet (Bosun concurs) — the family-cluster naming is vocabulary, not a fired pin. Preserved here so the framing survives post-sprint if future n increments push it toward meta-pin promotion.
Concrete asks for this tracker (Surveyor 5e14):
pilot/engineerprose doesn't trip.PR#434 lands #3 (minimum) via the input description update. This tracker owns #1 (established pattern) as the recommended path, with #2 (scoped patterns) as a fallback if #1 has unforeseen adopter friction.