# ADR-0012: Stable Inventory-Driven E27 API Surface

Status: Accepted

## Context

The E27 API is described across multiple documents and examples.
Documentation may be incomplete, inconsistent, or evolve over time.

Relying directly on documentation as the canonical API definition
creates ambiguity for implementers and contributors and complicates
long-term maintenance.

A stable, explicit definition of the supported API surface is required.

## Decision

The supported E27 API surface is defined by a committed inventory.

- The inventory explicitly lists supported domains, commands,
  request shapes, and response expectations
- Code generation, dispatch, and validation rely solely on the inventory
- Documentation is treated as an input, not as authority

The inventory is the canonical definition of what the system supports.

## Rationale

An inventory-driven model:
- provides a stable contract for contributors
- enables deterministic dispatch and validation
- prevents accidental expansion of the API surface
- allows documentation and protocol evolution without breaking code

This makes the supported API surface explicit and reviewable.

## Consequences

- Adding new API commands requires updating the inventory
- Undocumented or experimental commands are not implicitly supported
- Tooling and tests can be generated from the inventory
- Documentation discrepancies do not directly affect behavior

## Scope / Non-Goals

- Does not claim documentation is incorrect
- Does not prevent referencing documentation during development
- Does not mandate a specific inventory format

## References

- HelpDealerAPI_UL documentation
- DDR-0003
