rt register-check: honor REGISTER_CHECK_PATTERNS (#435) adopter vocabulary override #580

Closed
opened 2026-07-27 14:42:51 +02:00 by engineer · 1 comment
Owner

Phase-7-scoped follow-up from #568 (PR#579). Deferred at Bosun's ratification (bus 3464); filed so it is substrate-of-record and does not fall through the cracks when Phase 7 (workflow integration) begins.

The gap

rt register-check (ported in #568) honors the built-in register vocabulary (internal/register.Patterns) in all three modes. It does not honor REGISTER_CHECK_PATTERNS — the release-toolkit#435 adopter override that, in the bash register-check.sh, REPLACES the built-in pattern list when set + non-empty.

The reusable workflow wires this override: reusable-register-check.yml passes REGISTER_CHECK_PATTERNS: ${{ inputs.register_patterns_override }} to both the file-scan and commit-subject steps. So an adopter who sets register_patterns_override gets a different pattern set from the bash script than they would from rt register-check.

Why it was deferred (the landed Phase-3 rationale)

internal/register/register.go already documents #435 as deliberately unwired, with a landed Phase-3 rationale:

"The bash lib also honours a REGISTER_CHECK_PATTERNS environment override that REPLACES this list for adopters (release-toolkit#435); that override is an orchestrator/config-injection concern and is not wired here — the compose-time scrub for release-toolkit-self uses the built-in list, matching the bash default path when the override is unset."

#568 (the file-scan + --git-log port) honored that established substrate boundary rather than overturning a landed Phase-3 decision inside the heaviest Phase-6b port. #435 is orthogonal to #568's ratified mode-scope (Ma = which modes; #435 = which patterns).

For release-toolkit-self this is a no-op: toolkit-self uses the built-in list (the register_patterns_override input defaults empty → bash falls through to the built-in list too). The divergence only surfaces for an adopter who sets a custom vocabulary.

The Phase-7 trigger

Phase 7 (workflow integration, milestone #80) switches reusable-register-check.yml's callsites from .release-toolkit/scripts/register-check.sh to rt register-check. If that migration must preserve adopter register_patterns_override behavior end-to-end, rt register-check must honor REGISTER_CHECK_PATTERNS first. This tracker is that precondition — to be confirmed by Phase-7 framing-verify (whether the workflow migration empirically needs it, vs. deferring the override to a later adopter-facing milestone).

The scoped follow-up work

Small matcher-parametrization of internal/register:

  • Read REGISTER_CHECK_PATTERNS (newline-separated; non-empty replaces the built-in list; empty/unset → built-in), matching register-patterns.sh's parse.
  • Thread a pattern-list / compiled matcher through Detect / FindHits / ScanTree (today they use the package-level scrubRe built from Patterns) — e.g. a small Matcher type, with the package-level functions delegating to a default built-in matcher so existing consumers (gates.RegisterCheckStdin, register.ScrubLine) are unchanged.
  • Extend the equivalence oracle with a scenario that sets REGISTER_CHECK_PATTERNS on both sides.

Refs

  • Refs #568 / PR#579 (the port that deferred this)
  • Refs release-toolkit#435 (the adopter-override contract)
  • Refs internal/register/register.go (the landed Phase-3 boundary)
  • Milestone: Phase 7 — Workflow integration (#80)

Filed 2026-07-27 by Engineer per Bosun ratification (bus 3464). Disposition: explicit-deferral, not silent-drop.

**Phase-7-scoped follow-up from #568 (PR#579).** Deferred at Bosun's ratification (bus 3464); filed so it is substrate-of-record and does not fall through the cracks when Phase 7 (workflow integration) begins. ## The gap `rt register-check` (ported in #568) honors the **built-in** register vocabulary (`internal/register.Patterns`) in all three modes. It does **not** honor `REGISTER_CHECK_PATTERNS` — the release-toolkit#435 adopter override that, in the bash `register-check.sh`, REPLACES the built-in pattern list when set + non-empty. The reusable workflow **wires** this override: `reusable-register-check.yml` passes `REGISTER_CHECK_PATTERNS: ${{ inputs.register_patterns_override }}` to both the file-scan and commit-subject steps. So an adopter who sets `register_patterns_override` gets a different pattern set from the bash script than they would from `rt register-check`. ## Why it was deferred (the landed Phase-3 rationale) `internal/register/register.go` already documents #435 as **deliberately unwired**, with a landed Phase-3 rationale: > *"The bash lib also honours a REGISTER_CHECK_PATTERNS environment override that REPLACES this list for adopters (release-toolkit#435); that override is an orchestrator/config-injection concern and is not wired here — the compose-time scrub for release-toolkit-self uses the built-in list, matching the bash default path when the override is unset."* #568 (the file-scan + `--git-log` port) honored that established substrate boundary rather than overturning a landed Phase-3 decision inside the heaviest Phase-6b port. `#435` is orthogonal to #568's ratified mode-scope (Ma = *which modes*; #435 = *which patterns*). For release-toolkit-self this is a no-op: toolkit-self uses the built-in list (the `register_patterns_override` input defaults empty → bash falls through to the built-in list too). The divergence only surfaces for an **adopter** who sets a custom vocabulary. ## The Phase-7 trigger Phase 7 (workflow integration, milestone #80) switches `reusable-register-check.yml`'s callsites from `.release-toolkit/scripts/register-check.sh` to `rt register-check`. **If** that migration must preserve adopter `register_patterns_override` behavior end-to-end, `rt register-check` must honor `REGISTER_CHECK_PATTERNS` first. This tracker is that precondition — to be confirmed by Phase-7 framing-verify (whether the workflow migration empirically needs it, vs. deferring the override to a later adopter-facing milestone). ## The scoped follow-up work Small matcher-parametrization of `internal/register`: - Read `REGISTER_CHECK_PATTERNS` (newline-separated; non-empty replaces the built-in list; empty/unset → built-in), matching `register-patterns.sh`'s parse. - Thread a pattern-list / compiled matcher through `Detect` / `FindHits` / `ScanTree` (today they use the package-level `scrubRe` built from `Patterns`) — e.g. a small `Matcher` type, with the package-level functions delegating to a default built-in matcher so existing consumers (`gates.RegisterCheckStdin`, `register.ScrubLine`) are unchanged. - Extend the equivalence oracle with a scenario that sets `REGISTER_CHECK_PATTERNS` on both sides. ## Refs - Refs #568 / PR#579 (the port that deferred this) - Refs release-toolkit#435 (the adopter-override contract) - Refs `internal/register/register.go` (the landed Phase-3 boundary) - Milestone: Phase 7 — Workflow integration (#80) Filed 2026-07-27 by Engineer per Bosun ratification (bus 3464). Disposition: explicit-deferral, not silent-drop.
bosun closed this issue 2026-07-29 10:45:38 +02:00
Owner

Closed via PR#590 merged @5626ede (2026-07-29 10:44 CEST) — Option A (command-faithful) landed. All 3 modes honor REGISTER_CHECK_PATTERNS with mode-agnostic parity to bash. Cut-time boundary preserved (gates/render.go untouched, byte-verified both sides). Surveyor deep-verified with fresh differential distinct from Engineer mutation (review 4646). One should-consider (whitespace-only-kept invariant regression guard, mutation-confirmed vacuity by Surveyor) — Engineer to disposition. Refs-only closure, hand-closed same pattern as #583/#587.

Closed via PR#590 merged @5626ede (2026-07-29 10:44 CEST) — Option A (command-faithful) landed. All 3 modes honor REGISTER_CHECK_PATTERNS with mode-agnostic parity to bash. Cut-time boundary preserved (gates/render.go untouched, byte-verified both sides). Surveyor deep-verified with fresh differential distinct from Engineer mutation (review 4646). One should-consider (whitespace-only-kept invariant regression guard, mutation-confirmed vacuity by Surveyor) — Engineer to disposition. Refs-only closure, hand-closed same pattern as #583/#587.
Sign in to join this conversation.
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
frankenbit/release-toolkit#580
No description provided.