Changing webui code

1. Understand

• Read the files you're about to change in full before wide-ranging edits, and before editing a file you haven't inspected. Don't work from search snippets alone.
• Check node_modules for external API types instead of guessing.

2. Implement

• Match the style of the surrounding code.
• Keep comments short (1–3 lines): state the non-obvious constraint or rationale, never narrate what the code does.
• Ask before removing functionality that looks intentional. Don't preserve backward compatibility unless asked.

3. Test — required, not optional

Every behavioral change ships with tests. This is a gate, not a nicety:

• New behavior → add a test for it. Changed behavior → update the affected tests.
• Bug fix → add a regression test and apply the fail-first check: confirm it goes red without the fix, then restore. A fix without a test that pins it is incomplete.
• Follow the write-tests skill for setup, layout, and harness patterns.
• Run the file you touched, then the suite (yarn test); iterate until green.

If a change genuinely has no unit-testable surface (pure styling, config), say so explicitly rather than skipping silently.

Tests are how a change is verified — a passing, fail-first-checked test is the evidence the change works.

4. Changelog

Add an entry for the change under ## [next] in CHANGELOG.md, in the right subsection (### Added / ### Changed / ### Fixed / ### Removed / ### Dependencies) — see AGENTS.md for the format rules. This covers product code; test-only, docs, and tooling changes don't get an entry.

5. Lint

yarn lint (full output, no | tail). Fix every error, warning, and info before considering the change done. Never run yarn smoke-tests unless asked. Never commit unless asked.