Architecture Finding
Type: coupling
Affected area: src/components/ImagePicker/index.tsx
The 591-line ImagePicker component owns both presentation and the domain policy that maps a product selection to published artifacts. The same module defines product, desktop, and edition catalogs; implements the wizard transition graph; filters supported variant/desktop/edition combinations; constructs OCI image names, ISO URLs, builder URLs, and documentation URLs; and renders every step and result state.
Ten policy functions (getEditionOptions, getDesktopOptions, hasDesktopOptions, editionSuffix, hasExtraEditions, getNextStep, getPrevStep, buildImageName, getIsoUrl, getDocsUrl, and getVisibleSteps) are private to the React component module. Repository-wide test discovery finds no test or spec exercising the picker or these mappings. Consequently, validating a release-contract change requires rendering through the UI, while a UI refactor can change artifact naming or availability behavior.
The coupling is especially risky because the module bridges three independently changing contracts: VARIANTS, static/iso-index.json, and the public GHCR/download URL schemes.
Impact
- Release matrix changes can silently produce incorrect image, ISO, builder, or documentation links.
- Forward/back transition behavior and conditional step skipping have no headless contract tests.
- Presentation changes share a diff boundary with artifact-publication policy.
- Other consumers cannot reuse or validate the selection-to-artifact mapping without importing a browser-facing React module.
Recommendation
Extract a pure imageSelection domain module containing the selection types, option filtering, transition graph, and artifact URL/name derivation. Pass the live ISO-name set into that module as data, keep React rendering and state hooks in ImagePicker, and add table-driven tests covering every published variant/desktop/edition combination plus forward/back transitions. Keep catalogs sourced from VARIANTS rather than introducing another release-matrix copy.
Filed by architect agent (ACMM L6 — full mode)
🐝 Hive Agent: architect | Instance: hive-school-tunaos | SHA: 867a0d8
— hive: agent=architect backend=codex model=gpt-5.6-sol codex=0.146.0
Architecture Finding
Type: coupling
Affected area:
src/components/ImagePicker/index.tsxThe 591-line
ImagePickercomponent owns both presentation and the domain policy that maps a product selection to published artifacts. The same module defines product, desktop, and edition catalogs; implements the wizard transition graph; filters supported variant/desktop/edition combinations; constructs OCI image names, ISO URLs, builder URLs, and documentation URLs; and renders every step and result state.Ten policy functions (
getEditionOptions,getDesktopOptions,hasDesktopOptions,editionSuffix,hasExtraEditions,getNextStep,getPrevStep,buildImageName,getIsoUrl,getDocsUrl, andgetVisibleSteps) are private to the React component module. Repository-wide test discovery finds no test or spec exercising the picker or these mappings. Consequently, validating a release-contract change requires rendering through the UI, while a UI refactor can change artifact naming or availability behavior.The coupling is especially risky because the module bridges three independently changing contracts:
VARIANTS,static/iso-index.json, and the public GHCR/download URL schemes.Impact
Recommendation
Extract a pure
imageSelectiondomain module containing the selection types, option filtering, transition graph, and artifact URL/name derivation. Pass the live ISO-name set into that module as data, keep React rendering and state hooks inImagePicker, and add table-driven tests covering every published variant/desktop/edition combination plus forward/back transitions. Keep catalogs sourced fromVARIANTSrather than introducing another release-matrix copy.Filed by architect agent (ACMM L6 — full mode)
🐝 Hive Agent:
architect| Instance:hive-school-tunaos| SHA:867a0d8— hive: agent=architect backend=codex model=gpt-5.6-sol codex=0.146.0