D-113(a2) PROVEN: the OPNsense REST API round-trips the edge config ...

The API path adopted in D-113 is now demonstrated working against the LIVE Office1 edge,
closing the question that gated the ruling.

Measured:
  GET  core/firmware/status     -> HTTP 200, OPNsense 26.1 (auth works)
  GET  kea/dhcpv4/get           -> dhcpv4.general.enabled=1, interfaces=lan
  POST kea/dhcpv4/search_subnet -> 1 row: subnet 10.10.0.0/24, pools 10.10.0.100-10.10.0.199,
                                   option_data.routers 10.10.0.1, dns 10.10.0.1,
                                   domain office1.vr1.cloud.neumatrix.local, descr "LAN DHCP"

The API reads back EXACTLY what we pushed via config.xml yesterday, and exposes it as TYPED,
NAMED FIELDS -- not free-form XML. That is the (a2) argument made concrete: DOCFIX-191 (missing
sshd), DOCFIX-192 (silenced console) and DOCFIX-193 (an inert ISC <dhcpd> block against a Kea
backend) are NOT EXPRESSIBLE here. You cannot omit a typed field that has a default, and you
cannot address the wrong DHCP backend when the endpoint IS the backend.

GUI gotcha worth recording (26.1): API keys are NOT created in the user-edit dialog, and NOT in
the ApiKeys tab -- that tab wires only search_api_key + del_api_key, so it can list and delete
but CANNOT create. Creation is a ROW ACTION on the Users list: the fa-ticket icon, "Create and
download API key for this user" (source: mvc/app/views/OPNsense/Auth/user.volt). Any instruction
saying "edit user -> API keys -> +" describes the OLD UI and is wrong for 26.1. ApiKeyField::add()
mints key+secret as base64(random_bytes(60)) and stores key|crypt(secret,'$6$') -- the secret is
shown EXACTLY ONCE.

API gotchas: response root key is `dhcpv4`, NOT `dhcp4` (the config XML element name differs from
the API key name -- do not infer one from the other). camelCase actions map to snake_case URLs:
searchSubnetAction -> POST /api/kea/dhcpv4/search_subnet.

SEC-007 amended: ~/vr1-office1-creds/ now also holds the OPNsense API key/secret (0600).

NOT DONE: no WRITE through the API yet -- that is a live mutation and stays gated. And the
config.xml template is still in place: DO NOT push a full rendered config.xml now, it would
clobber API-managed state. Next step is reducing the template to a MINIMAL bootstrap (sshd +
root key + console) and moving DHCP/firewall/interfaces to the API.

Revert: read-only against the edge + docs; nothing to undo. To revoke the credential: GUI ->
System > Access > Users > root row > ApiKeys tab -> delete, then rm ~/vr1-office1-creds/opnsense-api.txt

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

SEC-006/SEC-007: put the two known credential exposures on the ledger ...

Both were flagged only in changelog/session-ledger prose, never as ledger rows -- exactly
the failure mode the security-ledger header warns about ("never only a comment in a script
header, where the libvirt item lived for a week"). An exposure with no row has no owner, no
status, and no revoke trigger.

SEC-006: the NetBox API token pasted into agent chat context during the D-111 IPv6 work.
This one is BURNED, not merely due for rotation -- it exists in a transcript outside our
control, so it needs revoke + reissue. Operator ruling 2026-07-13: DEFERRED, revoke at
completion of this deployment. Recorded as OPEN and explicitly live-and-exposed until then,
so the deferral is visible rather than forgotten.

SEC-007: ~/vr1-office1-creds/ holds the Office1 edge root password, its bcrypt hash, and the
office1_svc SSH private key in plaintext (0700/0600). This is a ROTATION obligation, not a
delete-me: D-112(c) makes SSH the only management path to the edge, so the key must exist.

No change to any live system; documentation only.

Revert: git revert this commit (the rows are the only change).

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

SEC-005: store a GitBucket credential on the jumphost so pushes stop failing ...

The jumphost clone could not push (could not read Username for https://git.baldurkeep.com),
which left this branch 12 commits ahead of origin for two days -- all the D-112 / OPNsense
edge work existed only on this box. Now fixed: credential.helper store + a dedicated PAT at
~/.git-credentials (mode 600), written by the operator via a hidden prompt. The token was
never read into agent context; the credential is verified by USING it, never by printing it.

Two GitBucket behaviours measured and recorded, because both cost a cycle:

1. The git username is NOT the web-UI login. The operator signs in with an email; that is
   rejected for git transport. Measured against info/refs?service=git-receive-pack:
   jesse.austin@neumatrix.com -> 401, JANeumatrix (the git user.name) -> 401,
   jesse.austin -> 200 CAN PUSH. Note GitBucket 401s PAT basic-auth on /api/v3/ across the
   board while accepting it for git -- so validating a credential against the API gives a
   FALSE NEGATIVE. Validate against the receive-pack endpoint.

2. credential.helper store DELETES the stored credential when the server rejects it (git
   calls credential reject on a 401). The first bad-username push therefore emptied
   ~/.git-credentials to 0 bytes, and the follow-up diagnostics were authenticating with an
   empty string -- which read as a corrupt file and misdirected the investigation. If the
   file mysteriously empties: the credential was rejected, it did not fail to write.
   Tooling consequence: validate BEFORE writing.

SEC-005 is OPEN by operator ruling: a long-lived, account-wide PAT now sits in plaintext on
the jumphost (GitBucket has no per-repo token scoping, so the control is rotation, not
scope). Revoke/rotate at v1 close, or immediately if the jumphost is shared or rebuilt.

Revert: git config --global --unset credential.helper && rm -f ~/.git-credentials,
then revoke the token in GitBucket -> Account Settings -> Applications.

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

addendum 20: operator ruling sweep -- D-050 closed via D-051, D-073 adopted (list_trusts hardening, impl pending), SEC re-triggers, D-072 upstream bug withdrawn ...

Also fixes a self-inflicted scan poisoning: the 2026-07-05 ledger finding note
quoted high-numbered decoy identifiers literally, inflating ledger-scan's
DOCFIX/BUNDLEFIX next-free; tokens de-fanged + standing rule recorded. D-050
block Status line made scan-closable (D-063 precedent, keywords avoided).

Scan verified post-change: open = D-068, D-071; next-free D-074/DOCFIX-091/
BUNDLEFIX-012; fences 4/0/0; files ASCII.

Revert: git revert this commit (doc-only; no cloud state touched).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Patches