Migrated from stefanwb/claude-shared#52, originally filed by @stefanwb on 2026-06-24 during the repo extraction. File paths below are updated for the standalone-repo layout (claude-docker/ prefix dropped).
Problem
Two functions in update_pins.py encode per-tool special cases as imperative branches instead of driving off the existing TOOLS registry / shared logic. Low urgency, but each makes adding or changing a tool more error-prone than it needs to be.
1. fragment_lines() is a dispatch table written as an if/elif chain (update_pins.py:347)
Each tool's env-fragment format (var-name prefix, URL template, arch keys) is hardcoded per-tool in a long if name == "...": chain. Adding a tool means editing both TOOLS (:61) and this chain — the registry already enumerates the tools, but fragment_lines re-enumerates them by hand.
Proposed fix: move the URL template + var-naming into the TOOLS entries so fragment_lines loops over structured data. (Caveat: the npm tools are installed in one batched npm install -g in the Dockerfile, so npm fragments still share a small special case; the real payoff is the binary tools — uv/glab/awscli/tfenv.) Reasonable to defer until the next binary tool is added.
2. resolve_awscli() duplicates the select_version() state machine (update_pins.py:296)
resolve_awscli re-implements the soak/held/status logic from select_version() (:242) because aws-cli git tags carry no publish date and need per-tag API calls. The result is two copies of the same Result state machine; if select_version gains a field or changes a rule, resolve_awscli can drift.
Proposed fix: give select_version() an optional date_of(version) -> datetime | None callback so aws-cli can supply lazily-fetched dates, unifying the state machine without eagerly fetching every tag's date.
Scope note
Surfaced during a CI/code review (branch worktree-review-lint-job). These are internal generator code-quality items — no external behavior change, no security impact. Backed by 30 unit tests in tests/, so refactors here are verifiable.
Problem
Two functions in
update_pins.pyencode per-tool special cases as imperative branches instead of driving off the existingTOOLSregistry / shared logic. Low urgency, but each makes adding or changing a tool more error-prone than it needs to be.1.
fragment_lines()is a dispatch table written as an if/elif chain (update_pins.py:347)Each tool's env-fragment format (var-name prefix, URL template, arch keys) is hardcoded per-tool in a long
if name == "...":chain. Adding a tool means editing bothTOOLS(:61) and this chain — the registry already enumerates the tools, butfragment_linesre-enumerates them by hand.Proposed fix: move the URL template + var-naming into the
TOOLSentries sofragment_linesloops over structured data. (Caveat: the npm tools are installed in one batchednpm install -gin the Dockerfile, so npm fragments still share a small special case; the real payoff is the binary tools — uv/glab/awscli/tfenv.) Reasonable to defer until the next binary tool is added.2.
resolve_awscli()duplicates theselect_version()state machine (update_pins.py:296)resolve_awsclire-implements the soak/held/status logic fromselect_version()(:242) because aws-cli git tags carry no publish date and need per-tag API calls. The result is two copies of the sameResultstate machine; ifselect_versiongains a field or changes a rule,resolve_awsclican drift.Proposed fix: give
select_version()an optionaldate_of(version) -> datetime | Nonecallback so aws-cli can supply lazily-fetched dates, unifying the state machine without eagerly fetching every tag's date.Scope note
Surfaced during a CI/code review (branch
worktree-review-lint-job). These are internal generator code-quality items — no external behavior change, no security impact. Backed by 30 unit tests intests/, so refactors here are verifiable.