chore: streamline CLAUDE.md, add HACS info.md, clean up hacs.json

Condense dev server docs (details in project memory), simplify code
style section, add HACS store description page, remove deprecated
render_readme key.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: chrisdpurcell

CLAUDE.md

@@ -14,9 +14,6 @@ HA-Light-Controller is a Home Assistant custom integration providing reliable li
 control with state verification, automatic retries, and preset management. It ensures
 lights actually reach their target state after commands are sent. Distributed via HACS.
 
-**Scope**: Focused on core light control with verification/retry and preset management.
-Notification feature and blueprints removed in v0.2.0.
-
 ## Environment
 
 - **Python**: 3.14.2 (HA 2025.2+ requires Python 3.13+)
@@ -186,95 +183,23 @@ Tests mock HA modules before import. Key fixtures in `conftest.py`:
 
 ### Live Testing with HA Dev Server
 
-A Docker-based HA instance lives at `~/ha-plugin-test-workspace/` for integration
-testing against a real Home Assistant runtime.
-
-**Setup:**
+A Podman-based HA instance at `~/ha-plugin-test-workspace/` enables runtime testing.
+Connection details and access token are stored in project memory.
 
 ```bash
-# Start the dev server (HA on http://localhost:8123)
-podman compose -f ~/ha-plugin-test-workspace/docker-compose.yml up -d
-
-# Deploy current integration code to the dev server
+# Deploy and restart
 cp -r custom_components/ha_light_controller/* \
   ~/ha-plugin-test-workspace/ha-config/custom_components/ha_light_controller/
-
-# Restart HA to pick up changes
 podman restart ha-plugin-test
-
-# Tail logs to verify loading
-podman logs -f ha-plugin-test 2>&1 | grep ha_light_controller
-```
-
-**Environment details:**
-
-- Runtime: Podman (rootless containers)
-- Container: `ha-plugin-test` (image: `ghcr.io/home-assistant/home-assistant:stable`)
-- Config dir: `~/ha-plugin-test-workspace/ha-config/` (mounted as `/config`)
-- The `demo` integration provides test light entities (`light.ceiling_lights`, etc.)
-- REST API enabled on port 8123
-- Debug logging enabled for `custom_components.ha_light_controller`
-- Login: `admin` / `admin`
-- Long-lived access token name: `Claude Code Dev` (value stored in project memory)
-
-**Common verification commands:**
-
-```bash
-# Check integration loaded (HA_TOKEN is the long-lived access token)
-curl -s http://localhost:8123/api/states \
-  -H "Authorization: Bearer $HA_TOKEN" | python -m json.tool
-
-# Call a service
-curl -X POST http://localhost:8123/api/services/ha_light_controller/ensure_state \
-  -H "Authorization: Bearer $HA_TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{"entity_id": "light.ceiling_lights", "state": "on", "brightness_pct": 50}'
-
-# Verify entity cleanup (e.g., after preset deletion)
-curl -s http://localhost:8123/api/states \
-  -H "Authorization: Bearer $HA_TOKEN" \
-  | python -c "import sys,json; [print(s['entity_id']) for s in json.load(sys.stdin) if 'preset' in s['entity_id']]"
 ```
 
-**Workflow:** Unit tests (`make test`) validate logic in isolation. Live testing
-validates HA runtime behavior that mocks can't cover — entity lifecycle, service
-registration persistence across reloads, config flow UI, and entity registry cleanup.
-
-## Documentation Style
-
-Target technically proficient Home Assistant users:
-
-- Use proper HA terminology (`entities`, `services`, `ConfigEntry`)
-- Prefer code examples over prose
-- Skip basic explanations (don't explain what HACS is)
-
-## Code Principles
-
-Two requirements govern all code in this repository:
-
-### 1. Readability
-
-- **Prefer flat over nested** - Avoid deep nesting (3+ levels). Extract helpers instead.
-- **Name for intent** - Variables and functions should describe what they do, not how.
-- **Consistent patterns** - Similar operations should use identical patterns throughout.
-- **Minimal comments** - Code should be self-explanatory. Comments explain "why", not
-  "what".
-
-### 2. Simplicity
-
-- **No speculative handling** - Only handle edge cases that actually occur. Delete code
-  for hypothetical scenarios.
-- **DRY without over-abstraction** - Extract repeated code, but don't create
-  abstractions for single-use cases.
-- **Delete, don't deprecate** - Remove unused code entirely. No commented-out code or
-  compatibility shims.
-- **Fail early, fail clearly** - Validate inputs at boundaries, then trust internal
-  state.
+Unit tests validate logic in isolation. Live testing validates HA runtime behavior that
+mocks can't cover — entity lifecycle, service registration persistence across reloads,
+config flow UI, and entity registry cleanup.
 
-### Anti-patterns to Avoid
+## Code Style
 
-- Defensive coding for impossible cases
-- Multiple validation points for the same data
-- Redundant lookups within the same scope
-- Overly broad exception handling (`except Exception`)
-- State persistence via instance variables when dataflow would be clearer
+- Prefer flat over nested (3+ levels → extract helpers)
+- Consistent patterns — similar operations use identical structure throughout
+- Delete, don't deprecate — no commented-out code or compatibility shims
+- Fail early, fail clearly — validate at boundaries, trust internal state

hacs.json

@@ -1,5 +1,4 @@
 {
   "name": "Light Controller",
-  "homeassistant": "2025.2.0",
-  "render_readme": true
+  "homeassistant": "2025.2.0"
 }

info.md

@@ -0,0 +1,50 @@
+HA Light Controller adds state verification and automatic retries to light commands.
+When you call `light.turn_on`, Home Assistant sends the command once and assumes
+success. This integration verifies that entities actually reached the target state and
+retries if they didn't.
+
+This solves the common problem of lights occasionally missing commands due to network
+congestion, Zigbee/Z-Wave mesh issues, or unresponsive devices. Instead of building
+retry logic into every script and automation, HA Light Controller handles verification
+centrally with configurable tolerances and backoff strategies.
+
+## How It Works
+
+1. Sends the light command (on/off, brightness, color, etc.)
+2. Waits a configurable delay for the state to update
+3. Verifies entity attributes match target values within tolerance
+4. Retries with exponential backoff if verification fails
+5. Optionally logs success to the Home Assistant logbook
+
+## Key Features
+
+- **State verification** - Confirms entities reached target brightness, color, and
+  temperature within configurable tolerances
+- **Automatic retries** - Configurable retry attempts with exponential backoff
+- **Group expansion** - Automatically expands `light.*` and `group.*` entities to
+  individual lights
+- **Per-entity overrides** - Set different attributes for each light in a single service
+  call via the `targets` parameter
+- **Presets** - Store light configurations as button entities for one-tap activation
+
+## Quick Start
+
+```yaml
+service: ha_light_controller.ensure_state
+data:
+  entities:
+    - light.living_room_ceiling
+    - light.living_room_lamp
+  brightness_pct: 80
+  color_temp_kelvin: 3000
+```
+
+## Services
+
+| Service | Description |
+|---|---|
+| `ensure_state` | Control lights with verification and retries |
+| `activate_preset` | Activate a saved preset by name or ID |
+| `create_preset` | Create a preset programmatically |
+| `create_preset_from_current` | Capture current light states as a preset |
+| `delete_preset` | Delete a preset by ID |