Measured on the live Office1 edge (OPNsense 26.1), while starting the D-115 q3
IPv6 deployment. D-113(a2)'s rationale asserts "everything else -- DHCP,
firewall, interfaces: the REST API." The interfaces half was never measured; it
was inferred from DHCP and firewall being API-native, and it is wrong.

Interfaces > [LAN] is served by /interfaces.php?if=lan -- a LEGACY PHP page.
Only the Devices and Neighbors sub-trees were migrated to MVC. There is no API
call that sets LAN's ipaddrv6. Measured: LAN vtnet0 currently has 10.10.0.1/24
and NO IPv6 at all.

What IS API-native (measured, not assumed): radvd (/api/radvd/settings/*,
currently 0 entries), Kea DHCPv6 (/api/kea/*), and Virtual IPs
(/api/interfaces/vip_settings/*, modes ipalias|carp|proxyarp on wan|lan|lo0).

This does NOT reopen (a2). The prohibition D-113 adopted is on hand-authored
config.xml and full rendered pushes -- the clobber path. D-113 separately
records "GUI access is a REQUIREMENT" as the constraint that eliminated VyOS and
plain-Linux, so a one-time operator GUI edit is the vendor interface the
decision PRESERVED, not a violation of it.

It DOES mean the chain is not fully API-scriptable for any edge needing IPv6 --
Office1 now, DC0/DC1 at Stage 3. Logged the open experiment: the radvd model has
NO prefix field (it derives the prefix from the interface's configured IPv6), so
whether an ipalias VIP satisfies that generator is UNKNOWN and is NOT assumed.

Doc only. No cloud state touched -- the audit was entirely read-only (GET).
repo-lint: 0 fail (1 documented legacy warn).

Revert: git revert HEAD

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ZBxzAbmqwLW7jEmMG23Xw