Charm TUI QA
Overview
Use this before claiming Charm terminal UI work is complete. The goal is evidence: tests for behavior, terminal runs for interaction, and screenshots or VHS recordings when visual quality matters.
Workflow
- Read
references/qa-checks.md before designing verification.
- Derive checks from the changed UX: architecture, component behavior, layout, forms, SSH sessions, markdown, motion, or logs.
- Run automated checks first:
go test ./..., existing lint/type/static checks, and targeted tests.
- Run the app manually in a real terminal or pseudo-terminal at multiple sizes.
- Capture screenshots or VHS recordings when layout, motion, onboarding, demos, or regression artifacts matter.
- Report exact commands, dimensions, scenarios, and any unverified risk.
Verification
Use both automated checks and manual terminal checks. Pick the depth based on the UI risk, but never claim terminal UX quality from build output alone.
Automated Checks
- Unit-test Bubble Tea
Update behavior with typed messages and keypresses.
- Test pure render helpers and stable view output where the project already supports golden/snapshot tests.
- Test validation functions for Huh forms.
- Test renderer configuration for Glamour.
- Test log configuration without asserting fragile color output unless the project already has terminal golden testing.
Manual Checks
- Run at narrow, normal, and wide terminal sizes.
- Use keyboard-only navigation for every primary task.
- Exercise loading, empty, populated, error, success, cancel, back, quit, and resize states.
- Check long labels, wide Unicode, ANSI-colored content, pasted input, and no-color mode when supported.
- Confirm logs do not corrupt full-screen output.
Recording
Use VHS when a feature needs a reproducible visual demo, screenshot, or motion proof. Keep tapes deterministic: fixed terminal size, seeded data, short sleeps, explicit waits, and no network dependency unless the product requires it.
Avoid
- Avoid claiming visual quality from unit tests alone.
- Avoid recording a demo with private data, live tokens, or unstable timestamps.
- Avoid only testing the happy path.
- Avoid treating one terminal size as proof of responsiveness.
- Avoid leaving manual observations vague. Record dimensions and actions.
Completion Evidence
A strong final verification note includes:
- Commands run and whether they passed.
- Manual scenarios and terminal dimensions.
- Screenshots/video paths when captured.
- Known gaps, if any.
- Any follow-up risk that remains outside the task scope.
References
references/qa-checks.md: test strategy, manual terminal checklist, VHS tape pattern, and evidence template.
1---2name: charm-tui-qa3description: Verify, record, and polish Charm terminal user interfaces with automated and manual terminal UX checks. Use when Codex needs to test Bubble Tea update/view behavior, run Go tests, capture screenshots or videos with VHS, inspect terminal rendering at multiple sizes, validate keyboard-only workflows, accessibility/plain-output paths, error/loading/empty states, or produce completion evidence for Charm CLI/TUI work.4---56# Charm TUI QA78## Overview910Use this before claiming Charm terminal UI work is complete. The goal is evidence: tests for behavior, terminal runs for interaction, and screenshots or VHS recordings when visual quality matters.1112## Workflow13141. Read `references/qa-checks.md` before designing verification.152. Derive checks from the changed UX: architecture, component behavior, layout, forms, SSH sessions, markdown, motion, or logs.163. Run automated checks first: `go test ./...`, existing lint/type/static checks, and targeted tests.174. Run the app manually in a real terminal or pseudo-terminal at multiple sizes.185. Capture screenshots or VHS recordings when layout, motion, onboarding, demos, or regression artifacts matter.196. Report exact commands, dimensions, scenarios, and any unverified risk.2021## Verification2223Use both automated checks and manual terminal checks. Pick the depth based on the UI risk, but never claim terminal UX quality from build output alone.2425## Automated Checks2627- Unit-test Bubble Tea `Update` behavior with typed messages and keypresses.28- Test pure render helpers and stable view output where the project already supports golden/snapshot tests.29- Test validation functions for Huh forms.30- Test renderer configuration for Glamour.31- Test log configuration without asserting fragile color output unless the project already has terminal golden testing.3233## Manual Checks3435- Run at narrow, normal, and wide terminal sizes.36- Use keyboard-only navigation for every primary task.37- Exercise loading, empty, populated, error, success, cancel, back, quit, and resize states.38- Check long labels, wide Unicode, ANSI-colored content, pasted input, and no-color mode when supported.39- Confirm logs do not corrupt full-screen output.4041## Recording4243Use VHS when a feature needs a reproducible visual demo, screenshot, or motion proof. Keep tapes deterministic: fixed terminal size, seeded data, short sleeps, explicit waits, and no network dependency unless the product requires it.4445## Avoid4647- Avoid claiming visual quality from unit tests alone.48- Avoid recording a demo with private data, live tokens, or unstable timestamps.49- Avoid only testing the happy path.50- Avoid treating one terminal size as proof of responsiveness.51- Avoid leaving manual observations vague. Record dimensions and actions.5253## Completion Evidence5455A strong final verification note includes:5657- Commands run and whether they passed.58- Manual scenarios and terminal dimensions.59- Screenshots/video paths when captured.60- Known gaps, if any.61- Any follow-up risk that remains outside the task scope.6263## References6465- `references/qa-checks.md`: test strategy, manual terminal checklist, VHS tape pattern, and evidence template.
peternicholls