Park the BYOD / inner-zone access tension as an open question.

Raised by the founder from the bao.coulomb.social retraction: ADR-0008's
operator posture assumes a company-network-shaped device, which this estate
does not have. Written down, not solved.

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

docs/agent-environment-orientation.md

@@ -31,7 +31,7 @@ Services are private by default (railiance-master ADR-0008) and are reached thro
 | OpenBao | `http://127.0.0.1:18200` (in-cluster: `openbao.openbao.svc:8200`) | `openbao-ui-railiance01` |
 | k3s API | `https://127.0.0.1:16444` (`~/.kube/config` → `config-railiance01`) | `k3s-api-railiance01` |
 
-**Retired name:** `bao.coulomb.social` is **retired**, not a trap to work around. Its public Ingress was retracted on 2026-09-15 (railiance-master RMASTER-WP-0020-T09); the self-signed Traefik cert and the 404 are leftovers of a dangling DNS record, and DNS withdrawal sits with railiance-infra. No certificate or route will be restored (railiance-platform RPF-WP-0025-T03). Operators use the tunnel `http://127.0.0.1:18200`, which `~/.bashrc` has exported as `BAO_ADDR`/`VAULT_ADDR` since 2026-09-22; workloads use `openbao.openbao.svc:8200`. A shell opened before that change still needs the prefix.
+**Retired name:** `bao.coulomb.social` is **retired**, not a trap to work around. Its public Ingress was retracted on 2026-09-15 (railiance-master RMASTER-WP-0020-T09); the self-signed Traefik cert and the 404 are leftovers of a dangling DNS record, and DNS withdrawal sits with railiance-infra. No certificate or route will be restored (railiance-platform RPF-WP-0025-T03). Operators use the tunnel `http://127.0.0.1:18200`, which `~/.bashrc` has exported as `BAO_ADDR`/`VAULT_ADDR` since 2026-09-22; workloads use `openbao.openbao.svc:8200`. A shell opened before that change still needs the prefix. Whether operators should be able to reach management surfaces at all from a device without an SSH certificate is an open question, parked in [`inner-zone-access-without-a-company-network.md`](inner-zone-access-without-a-company-network.md).
 
 ## 3. Permissions and the agent harness (Claude Code)
 

docs/inner-zone-access-without-a-company-network.md

@@ -0,0 +1,64 @@
+# Open question: reaching the inner management zone without a company network
+
+**Status:** open, parked deliberately. Not scheduled, not assigned.
+**Raised by:** the founder, 2026-09-23, out of the `bao.coulomb.social` retraction.
+**Touches:** railiance, net-kingdom, helixforge, coulomb.
+**Owner when picked up:** railiance-master (exposure posture, ADR-0008) with
+net-kingdom (identity and assurance).
+
+This file exists so the tension is written down, not solved. Do not treat
+anything here as a decision.
+
+## The tension
+
+Management surfaces — the OpenBao UI, the k3s API, ArgoCD, the State Hub —
+are `private` or `operator` under
+[ADR-0008](../../railiance-master/docs/adr/ADR-0008-private-by-default-exposure.md).
+`operator` means the listener stays unpublished and reachable only through a
+named ops-bridge/SSH tunnel. That is a good posture for a secret store, and on
+2026-09-15 it is why the public OpenBao listener was retracted
+(RMASTER-WP-0020-T09, closed as railiance-platform RPF-WP-0025-T03).
+
+It also assumes something this estate does not have: a classic company network.
+The tunnel model quietly requires a device carrying an SSH certificate and an
+ops-bridge setup. The real operating model is remote, bring-your-own-device, and
+includes collaborators who are not company staff and never will be. Those two
+facts pull against each other:
+
+- **Posture pull:** an internet-reachable login form in front of the estate's
+  credentials is a standing invitation. Requiring a certificate before the form
+  is even visible removes a whole class of attack.
+- **Access pull:** an operator on a phone, a tablet, a fresh laptop, or an
+  external collaborator on their own device cannot reach a management surface at
+  all. The workaround is to provision another SSH-carrying device, which is
+  exactly the company-network assumption re-entering through the back door.
+
+Neither pull is wrong. Today the second one loses by default, because `private`
+is the default posture and there is no considered answer for BYOD access.
+
+## What a later answer has to cover
+
+- Identity and device assurance strong enough to replace "is on the network":
+  what net-kingdom can already assert (IAM Profile claims, AAL, factor state)
+  and what it cannot.
+- Whether a device must be enrolled at all, and what an unenrolled device may
+  reach. Enrolment is itself a company-network assumption if made mandatory.
+- Non-company collaboration: guests reaching a bounded surface without becoming
+  operators, and without a membership implying authorization (the user-engine
+  boundary rule holds here too).
+- Whether the answer is per-surface exposure grants under ADR-0008, an identity-
+  aware proxy in front of `operator` surfaces, or something else. This note does
+  not choose.
+- Break-glass: what works when ops-bridge is down. Note that the cluster
+  generally needs SSH in that situation anyway, so the gap may be narrower than
+  it looks.
+- Seeding: how a brand-new zone gets its first trusted operator before any of
+  this exists.
+
+## Not blocked on this
+
+The retraction stands. The OpenBao UI is unchanged and reachable through the
+`openbao-ui-railiance01` tunnel at `http://127.0.0.1:18200/ui/`; nothing was made
+headless. Separately, `bao.coulomb.social` is to stop serving a broken-looking
+TLS error and serve a plain "not publicly available" page instead — requested of
+railiance-platform on 2026-09-23, tracked there, and not part of this question.