# ADR-0108: Temporary Separate Home Assistant Integration Domain for E27 Development

Status: Accepted

## Context

The existing Home Assistant integration for Elk panels (`elkm1`) is a
core integration with established users and stable behavior.

E27 support introduces:
- a new discovery model
- a new protocol backend
- different authentication and lifecycle semantics
- significant new code paths

Developing E27 support directly inside `elkm1` during early iterations
would increase risk of regressions for existing M1 users and slow down
experimentation and validation.

At the same time, the long-term goal remains to integrate E27 support
into the existing `elkm1` integration once behavior stabilizes.

## Decision

For the initial implementation phase, E27 support will be developed
under a separate Home Assistant integration domain: `elke27`.

- The `elke27` integration is created by copying the existing `elkm1`
  integration as a starting point.
- `elke27` is treated as a **staging integration**, not a permanent fork.
- The architectural boundaries, layering, and semantics defined by ADRs
  apply identically to `elke27` and the eventual merged `elkm1` version.
- No E27-specific architectural shortcuts are permitted simply because
  the domain is separate.

The expected end state is reconciliation of E27 support into the
existing `elkm1` integration.

## Rationale

Using a temporary separate integration domain:

- allows rapid iteration without destabilizing M1 users
- simplifies debugging and testing of new E27 behavior
- avoids complex conditional logic during early development
- aligns with Home Assistant best practices for staging major changes

By explicitly declaring the separation as temporary and architectural
constraints as identical, we prevent long-term divergence.

## Consequences

- `elke27` must follow Home Assistant integration conventions
  (manifest, config flow, device registry, reauth/reconfigure).
- Device identity, entity unique_id schemes, and semantic models must be
  designed so reconciliation into `elkm1` is mechanically feasible.
- Users of `elke27` should expect eventual migration to `elkm1`
  once E27 support is merged upstream.
- Documentation must clearly state the temporary nature of `elke27`.

## Scope / Non-Goals

- Does not define the exact migration process back into `elkm1`.
- Does not guarantee backward compatibility for `elke27` users across
  early development versions.
- Does not alter the long-term goal of a unified `elkm1` integration.

## References

- ADR-0001: E27 as a First-Class Protocol Backend
- ADR-0008: Discovery UX and Panel Identity
- Home Assistant integration development guidelines
