Add section config API and user preferences

[stvncode]

Summary

• Section config endpoints (GET/POST /devices/{config}/section-config): Returns rich ConfigEntry lists for any YAML section (core config like wifi/api/logger, components like sensor/switch/light, automations like script/interval) with current values parsed from the device YAML. POST updates values back into the YAML preserving formatting.
• User preferences endpoints (GET/PUT /preferences): Global user preferences (e.g. editor layout mode) stored in .device-builder.json under a _preferences key. Supports partial merge updates.
• New models: ConfigEntry, ConfigValueOption, SectionConfigResponse, UserPreferences

Test plan

• GET /devices/{config}/section-config?key=wifi returns entries with current values from YAML
• GET /devices/{config}/section-config?key=sensor returns component entries with parsed values
• POST /devices/{config}/section-config with {section_key, values} updates YAML correctly
• GET /preferences returns {} initially, saved preferences after PUT
• PUT /preferences with {editor_layout: "left"} persists and returns updated prefs
• Unknown section keys return a generic "use YAML editor" alert entry

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR adds backend support for a “visual section editor” API over ESPHome YAML sections, plus a small preferences API for persisting UI/user settings in the existing .device-builder.json metadata file.

Changes:

• Registers a new section_config handler module in the aiohttp app.
• Introduces GET/POST /devices/{configuration}/section-config for reading/updating “rich” config-entry definitions with values parsed from YAML.
• Adds GET/PUT /preferences backed by .device-builder.json under the _preferences key, plus new related models.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
server.py	Registers the new handlers/section_config.py route table.
section_config.py	Adds section-entry definitions and a text-based YAML value extractor used by the section-config API.
models.py	Adds dataclasses for ConfigEntry, ConfigValueOption, SectionConfigResponse, and UserPreferences.
metadata.py	Adds _preferences read/merge-write helpers using .device-builder.json.
handlers/section_config.py	Implements GET/POST endpoints and a text-based YAML updater for section values.
handlers/misc.py	Implements GET/PUT /preferences endpoints.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

get_section_config() never returns None (it returns a generic SectionConfigResponse for unknown keys), so this 404 branch is dead and the endpoint behavior is inconsistent. Either update get_section_config() to actually return None for unknown keys, or (per the PR description) remove this check and always return the generic alert response.

Suggested change

	if result is None:
	return error_response(f"Unknown section: {section_key}", status=404)

[Copilot]

values is assumed to be a dict but body.get("values") can be any JSON type (e.g. list/null), which will cause _update_yaml_section() to crash when iterating .items() or looking up keys. Validate that values is a dict (and reject non-dict bodies) and return a 400 error when the shape is invalid.

Suggested change

	return error_response("Invalid JSON body")
	section_key = body.get("section_key", "")
	values: dict[str, Any] = body.get("values", {})
	if not section_key:
	return error_response("Missing 'section_key'")
	return error_response("Invalid JSON body", status=400)
	if not isinstance(body, dict):
	return error_response("Invalid JSON body: expected an object", status=400)
	section_key = body.get("section_key", "")
	raw_values = body.get("values", {})
	if not isinstance(raw_values, dict):
	return error_response("Invalid 'values': expected an object", status=400)
	values: dict[str, Any] = raw_values
	if not section_key:
	return error_response("Missing 'section_key'", status=400)

[Copilot]

current_parent is set when encountering a nested mapping key, but there’s no indentation tracking to know when that nested block ends. This will incorrectly treat sibling keys (e.g. port: under api:) as children of the previous parent (e.g. encryption.port), leading to wrong reads and writes. Track the parent indentation level and reset current_parent when indentation decreases back to the section child level (or switch to a YAML parser for value extraction).

[Copilot]

List sections (e.g. sensor: / switch:) can have multiple items; this parser stores list item keys into a flat dict, so repeated keys overwrite earlier items and only the last item “wins”. If this endpoint is meant to support component sections, you’ll need a way to address a specific list item (e.g. by index/id/name) and return/update per-item values instead of collapsing the whole list into one dict.

[Copilot]

Same indentation issue as the reader: current_parent is never cleared based on indentation, so after a nested block like encryption:, subsequent sibling keys may be treated as encryption.<key> and updated/added under the wrong path. Track the parent indent level and reset current_parent when encountering a key at the parent’s indent (or lower).

[Copilot]

For dotted keys, this appends a new parent: line for every key (e.g. encryption.key and encryption.foo will produce duplicate encryption: blocks). It also doesn’t check whether the parent mapping already exists in the section. Consider grouping appended dotted keys by parent and emitting a single parent block, or inserting missing children into an existing parent block when present.

[Copilot]

List item updates are applied purely by key name; if a section contains multiple list items (multiple sensors/switches), this loop will update every matching - <key>: occurrence, unintentionally modifying multiple components at once. The update API likely needs a way to target a specific list entry (index/id/name) rather than bulk-updating all list items with the same key.

[Copilot]

request.json() can return any JSON type; if the client sends a list/string/etc, set_preferences() will raise (because it expects a mapping). Add a check that body is a dict and return a 400 error when it’s not (and ideally validate allowed preference keys/values).

Suggested change

	return error_response("Invalid JSON body")
	return error_response("Invalid JSON body", status=400)
	if not isinstance(body, dict):
	return error_response("Invalid JSON body: expected an object", status=400)

[Copilot]

current.update(prefs) assumes prefs is a dict and that the stored _preferences value is also a dict. If either is not a mapping (e.g. malformed JSON, or caller passes a list), this will raise and break the /preferences endpoint. Add defensive type checks/coercion (e.g. treat non-dict _preferences as {} and reject non-dict prefs with a clear error).