# Test results app 0.2.61 / firmware 0.2.52 (2026-09-17)

Max built the Override YAML feature with ChatGPT and asked for a review before release. The feature is app-only:
`installation_yaml` gives every new profile a `local_overrides: !include <name>.local.yaml` package after the shared
board package, `Firmware.save_override` attaches an existing profile on the first save (spliced into `packages:`
without reformatting the rest), and the page edits the sidecar in a dialog with Save and Save & check (ESPHome
`config` of the complete profile). The review changed four things before release:

- **The example was wrong.** ESPHome 2026.6.2 `merge_config` appends package lists (`old + new`); it does not merge
  items by `id`. `display: - id: my_display, model: ST7789V` therefore adds a second display without a platform and
  `esphome config` fails with "'display' requires a 'platform' key". The example, placeholder and docs now use
  `id: !extend my_display`, which edits the display the shared package defines. Checked with the CLI (below).
- **A too-big body was a bare 413.** The app accepts 16 KB request bodies; the override allowed 128 KB, so anything
  in between made aiohttp answer a 413 HTML page and the dialog said "That didn't work". The override is now 12 KB at
  most, and the guard middleware answers `HTTPRequestEntityTooLarge` as JSON like every other refusal.
- **Order of writes.** The sidecar is written before the profile gets its include, so a profile never points at a
  file that isn't there. A profile whose `packages:` is the last section without a trailing newline no longer gets
  the include glued to its last line.
- **Symlinks.** A symlinked `<name>.local.yaml` is refused for reading and writing; `profile()` already did that for
  profiles. The Save & check poller stops when the dialog closes instead of polling `/api/firmware` for two hours.

## Automated

- Python (`.venv-portal`): `tests/test_overrides.py` 11/11 OK: hidden empty sidecar on create, attach without
  reformatting and survive a reload, attach an existing profile, refuse managed sections / managed substitutions /
  bad YAML without writing, accept `!extend`, normalise empty text and a missing newline, refuse 12 KB+, refuse a
  symlinked sidecar without touching its target, append the include after a `packages:` section without newline,
  leave a profile with a foreign `local_overrides` alone; plus the HTTP round trip (CSRF 403, GET, PUT 200, managed
  section 400, oversized 413 as JSON, the sidecar stays out of the profile list).
- Full Python suite: 291 tests, 1 failure in `test_tile_icons` (`light: F0335`). That test passes on a clean copy of
  HEAD; the failure comes from the binary-sensor-words session's uncommitted firmware headers in the shared working
  tree, not from this change.
- `node --check app.js` clean.

## ESPHome CLI (2026.6.2)

- A profile generated by `installation_yaml` for a CYD, with the remote `packages/cyd.yaml` from GitHub and an
  override of `display: - id: !extend my_display, model: ST7789V`: **Configuration is valid**, the merged display
  shows `model: ST7789V`.
- Minimal local configs: an empty `{}` sidecar is valid; a bare `id:` in the override fails ("requires a 'platform'
  key"); `id: !extend` merges into the package's component and a later package wins for scalars (`logger.level`).

## Not tested / for the owner

- Nothing was flashed and the Home Assistant add-on was not rebuilt locally. In the add-on: open a screen, Override
  YAML, Use example, Save & check; the status should end in "The complete profile is valid".
- Existing profiles from before 0.2.61 have no include until the first save; the dialog says so ("Ready to attach").
- The example changes the display controller. It is right only for a board that really has an ST7789V.