Loomworks — dev/production configuration split — work item — v0.1

Version. 0.1 Date. 2026-07-19 Author. Claude Code on DUNIN7-M4, on Operator direction. Status. QUEUED. Not started. Reads with. security/loomworks-security-incident-2026-07-19-dev-endpoint-exposure-v0_1 — this is that incident's root cause.

Plain-language summary

One machine is both the daily development box and the interim production perimeter origin. One .env serves both. A single environment value cannot describe two postures, and on 2026-07-19 that produced an authentication bypass reachable from the public internet for about a day.

The immediate fix was to set the value to production, which closed the bypass and cost three development affordances. This item is the real fix: let the two postures coexist without either compromising the other.

The tension, stated plainly

LOOMWORKS_ENV decides three things at once:

1. Whether /auth/dev/issue-session is mounted — the dev session minter.
2. Whether localhost:3000 / localhost:3001 are added to the CORS allowlist.
3. Whether request-validation failures log verbose diagnostics.

Development wants all three. Production must not have the first at any price. There is currently no way to say so.

This is the third time the single-.env shape has forced a decision:

• Stage 1, WebAuthn origins. One engine, two hostnames, one WEBAUTHN_RP_ORIGIN. Resolved by making the setting accept additional origins — a real feature, published as Stele v0.4.0.
• Stage 1, cookie Secure flag. Resolved by accepting HTTPS-only development through the tunnel.
• Stage 2, environment posture. Resolved by giving up the development affordances entirely.

Each was resolved locally and correctly. The pattern is that the shape keeps producing these, and the third one had teeth.

Options, none chosen

• (a) A second engine process for development. Its own .env, its own port, loomworks-dev.dunin7.com routed to it. The production engine never has development posture at all. Costs a second process and a second database decision (shared or separate — they are different answers with different consequences).
• (b) Split the flag. Replace one LOOMWORKS_ENV with independent settings, so the dev session minter can be off while verbose logging stays on. Cheapest, and keeps one process — but multiplies the number of things that must each be right, and the bypass happened because one thing was wrong.
• (c) Bind dev affordances to the interface rather than the environment. Mount the dev router only on a loopback listener, so it is unreachable through the tunnel regardless of posture. Makes the safety property structural rather than configural — the strongest guarantee, and the largest change.
• (d) Accept the loss. Development uses real passkey ceremonies through the tunnel, which works today. Zero effort, and the current state.

(c) is the most robust and (d) is the status quo. The choice depends on how much longer this machine is the perimeter origin — the VPS cutover recorded in the perimeter handoff (§5B) dissolves the tension entirely by separating the machines, and may arrive before any of this is worth building.

The property any answer must preserve

A deployment that is misconfigured, or that forgets to configure anything, must land in production posture. The current default already does this and it is the right way round. Whatever replaces it must keep that direction: the failure mode of forgetting must be "too strict," never "wide open."

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — dev/production configuration split — work item — v0_1 — 2026-07-19