v1: validate candidate issue #114 grouped controls #135

Objective

Decide whether issue #114, grouped controls, merits a v1 fix that preserves Chota's existing gapless grouped-control contract.

Prerequisites

• The report is reproduced using current built CSS and documented markup.
• The v1 support policy confirms the CSS feature used by a proposed remedy.
• VRT can compare normal and edge-case group layouts.

Investigation scope

Evaluate only the reported spacing/alignment failure. If gap is considered, compare it with existing border, radius, wrapping, and gapless control behavior across the supported layout directions.

Do not

• Add a new component or form-layout system.
• Replace all grouping styles opportunistically.
• Treat a modern property as safe without confirming its policy and fallback behavior.
• Merge production CSS as part of this validation card.

Procedure

1. Build minimal horizontal and wrapping control-group fixtures.
2. Reproduce the failing condition at desktop and narrow widths.
3. Test proposed gap behavior against intended zero-gap cases, border joins, focus outlines, and disabled controls.
4. State whether the change is a safe targeted fix, needs design/API decision, or should defer.

Done checklist

• The reproduction distinguishes intended gapless appearance from the reported defect.
• The compatibility matrix covers supported browsers and narrow layout behavior.
• A promoted fix has explicit regression fixtures and no unintended spacing change.
• The card ends with a close, defer, or separate implementation decision.

Required handoff

Provide markup, before evidence, browser/viewport matrix, candidate comparison, risk assessment, and explicit decision.

Evidence integrity gate — coordinator review

This card is not complete because code, a screenshot, or a claimed result exists. Every conclusion must be reproducible from the recorded commit and command output.

• Record the exact base SHA, worker branch, OS, browser and version, Node/Yarn versions, viewport/device settings, command, exit status, and artifact path.
• Use the current built dist/ from the recorded commit; do not inspect source alone when the claim concerns runtime CSS.
• A screenshot is evidence only. It is a VRT result only when the test asserts against a named baseline and the command proves that assertion ran.
• Record measured values and the selector/element that produced those. "Looks correct" is not evidence.
• If a required command or browser cannot run, write BLOCKED with the error and do not convert it into a pass.
• The handoff must list changed files and prove that no excluded or unrelated files are present.
• The worker may recommend a disposition, but only the coordinator/owner may accept it or change GitHub state.
• Validation cards must not contain production CSS changes. A promoted fix requires a separate implementation card.

Unless this card explicitly names otherwise, excluded files are AGENTS.md, PLAN.md, generated reports, unrelated snapshots, package-manager lockfiles, and unrelated source files.

Required file scope

Allowed changes are limited to validation fixtures/specs, evidence screenshots/reports, and the handoff. No production CSS, dependency, or component-system changes are allowed in the validation work.

The evidence must include explicit expected-versus-actual spacing for gapless groups, wrapping groups, borders, radii, focus outlines, and disabled controls across the named viewport/browser matrix.

Handoff acceptance gate

Before requesting coordinator review, provide a criterion-to-evidence table: each Done checklist item | fixture/spec | assertion or measured value | command and exit status | artifact path. A screenshot augments a required measurement assertion; it never replaces one.

• Preserve required computed-style or measurement assertions when adding VRT; do not replace them with screenshots.
• Any claimed keyboard behavior must send the relevant keyboard input and assert the resulting focused element or focus order. Counting potentially focusable elements is not evidence of keyboard navigation.
• If snapshots are added to test:vrt, the handoff must show the exact CI command passing on Linux with the committed Chromium baselines, or explicitly report BLOCKED. A local macOS pass is not a substitute per card requirements.
• State every unverified checklist item as BLOCKED; do not replace it with a weaker proxy or mark the card complete.

Implementation handoff clarification

This card is validation-only. When the evidence confirms the reported defect, the coordinator may choose promote and create or use a separate implementation PR/card to fix it. The validation card's prohibition on production CSS applies to the validation work; it does not prohibit the follow-up implementation.

For this issue, the confirmed defect is the narrow-viewport overflow reported in #114. A follow-up implementation such as PR #170 may change the production CSS, but it must preserve desktop grouped controls, gapless behavior, focus outlines, disabled controls, and the supported browser contract. The implementation PR must carry its own regression evidence and CI validation before merge.