CR-2026-153 — Operator tools menu and authenticated edge access — v0_1

Version. 0.1 Date. 2026-07-17 Author. Claude.ai, on Operator direction. Status. Build specification. Filed as CR-2026-153 — the next in sequence, confirmed against the record's highest existing numbered CR (CR-2026-152) at filing time, 2026-07-17. Source. scoping-notes/loomworks-operator-tools-menu-scoping-note-v0_3.md. Scope is fixed by that note; this document specifies the build. Grounding. Three investigations, all 2026-07-17: loomworks-stele-agentic-identity-investigation-v0_1, loomworks-authenticated-marketing-access-investigation-v0_1, loomworks-operator-tools-menu-pre-cr-verification-investigation-v0_1. Technical consumer. Claude Code on DUNIN7-M4.

Targets — three repositories. This is unusual and is the reason for the build sequence in section 8.

| Repository | What changes | |---|---| | loomworks-engine | The mint endpoint, a settings field, a key-generation script | | loomworks-marketing | The entry point function, the verify helper, gating on the sales tools | | loomworks (Operator Layer) | The menu surface |

Plain-language summary

What this builds. A menu inside the Operator Layer listing the tools the Operator uses. The Operator signs in with Stele, as they already do. The menu asks the engine for a signed pass, hands it to the tool on the Operator's behalf, and the tool checks it before doing any work.

Why. The sales perspective generator has no gate. The gate designed for it was Cloudflare Access — another company's identity system, in front of a company that builds identity systems. The Operator's standing direction is that anything authenticating a person in a DUNIN7 system uses Stele.

What is new. Four pieces: the menu, an endpoint that mints a pass, a function that receives it and turns it into a cookie, and a check in each tool. Everything they depend on already exists and works.

What the Operator must do that Claude Code cannot. Generate the signing key, put the seed in the engine's environment, and put the public key in the marketing site's Cloudflare settings. Section 9.

Out of scope. Agents. Per-tool authorisation. Revocation. Key rotation. The public Example Generator, which is public by design.

1. Hard constraints

Non-negotiable. A build that violates any of these is wrong regardless of whether it works.

functions/api/_lib.js in the marketing repository is not modified. The public Example Generator depends on it. Change Request 2026-152 section 2 forbids it, and that rule holds here. Anything shared goes in functions/api/sales/_lib.js or a new sibling.
Stele is not modified. ~/stele is a dependency. Its contract is "Stele resolves who; the host gates what." Everything this Change Request builds is the host's business, on top of a resolved session. Nothing here belongs in Stele.
The public Example Generator stays ungated. /example-generator/, /api/analyze, /api/illustrate, /api/foundation-draft are unchanged and remain reachable with no pass. A stranger describing their work is the point of that page.
The mint fails closed. No principal, no founder match, no key — no pass. Never a pass on an error path.
The verify fails closed. No public key, no cookie, bad signature, expired, wrong tool — refuse. This deliberately departs from the rate limiter's fail-open posture: a limiter failing open costs money, an authorisation check failing open costs the gate.
The private key never leaves the engine. It is not logged, not returned by any endpoint, not written to any response, and not committed.
The pass never appears in a URL. Not in a query string, not in a fragment, not in a redirect target. It travels in a form body and lives in a cookie. See the scoping note section 9 for why.

2. The keypair

A script, not an endpoint. scripts/generate_tools_signing_key.py in the engine. It generates an Ed25519 keypair and prints both halves:

the private seed, base64-encoded, single line — for the engine's environment
the public key, base64-encoded, single line — for the marketing site's Cloudflare settings

It prints. It does not write to any file, does not store anything, and does not touch the database. The Operator places both halves by hand.

Why a script rather than an endpoint exposing the public key. An endpoint is a route to maintain, a thing to secure, and a runtime dependency between two deployments that this design otherwise avoids entirely. The public key changes when the key rotates, which is never in version one.

3. The mint

3.1 Configuration

One new field on Settings in config.py: the base64-encoded Ed25519 seed, single-line, following exactly the pattern loomworks_secret_key uses.

Verified 2026-07-17: the environment path carries a base64 seed unchanged. It does not cleanly carry a multi-line PEM — there is no normalisation helper and no precedent for multi-line environment values, and the key-rotation parser splits on commas, which base64 never contains. The seed is the shape the mechanism accepts. Do not introduce PEM.

Unset means the mint refuses. Fail closed.

3.2 The endpoint

POST /tools/pass, in a new router. Two dependencies, both existing:

get_current_principal — resolves the session cookie, enforces that the second factor was completed
require_founder — compares against the stored platform-founder identifier, fails closed if unset

Verified 2026-07-17: require_founder has exactly three consumers, all credit-admin routes, and is a pure read-only check with no writes, no nonce, and no shared mutable state. A fourth consumer disturbs nothing.

Request: the tool being asked for, by name.

Response: the pass, and its expiry.

Refuse an unknown tool name. The set of tools is a constant in the engine. A pass is minted for a tool that exists or not at all.

3.3 The pass

A signed statement, not an encrypted one. Ed25519 over a canonical payload, using the cryptography package already installed.

The payload carries: the person's identifier, the single tool it is good for, an issued-at time, and an expiry. Thirty minutes.

One tool per pass. A pass for the sales generator cannot open the FORAY generator. This is deliberate and is why the menu mints per tool rather than once.

Canonicalisation is part of the contract. The signer and the verifier are in different languages, in different repositories, written at different times. Specify the byte sequence being signed explicitly and do not rely on either language's default serialisation. A mismatch here produces a verify failure that looks like a key problem and is not.

The engine mints no asymmetric signature today. Its only use of cryptography is symmetric Fernet. This is new code.

4. The entry point

A new function on the marketing site, outside /api/. It is not a JSON endpoint; it receives a browser navigation.

onRequestPost. It:

Parses the form body and reads the pass
Verifies it (section 5)
On success, sets the cookie and redirects to the tool
On failure, refuses and sets nothing

The cookie: HttpOnly, Secure, SameSite Lax, path scoped to the tool, lifetime matching the pass's own expiry. Its value is the pass.

Verified 2026-07-17: setting a cookie in response to a cross-site form POST is allowed — SameSite governs when a cookie is sent, not when it is set. The cookie then rides the top-level redirect and every subsequent same-origin call.

The implementation detail that must not be discovered late: Response.redirect() returns an immutable response whose headers cannot be extended. Setting a cookie and redirecting requires constructing the response directly:


new Response(null, { status: 302, headers: { Location, 'Set-Cookie' } })

The marketing project has no example of this, because it has never set a cookie or returned a redirect at all.

5. The verify

One verification path, used in two places — the entry point before it sets the cookie, and every tool endpoint before it does any work. Write it once, in functions/api/sales/_lib.js or a new sibling. Not in the shared _lib.js.

It checks: signature valid against the public key, not expired, and naming this tool.

crypto.subtle.importKey then crypto.subtle.verify, no library.

Verified 2026-07-17: the marketing Pages project's compatibility date is 2026-05-10 on both production and preview, with no flags. Ed25519 is supported at that date with no flag and no bump. The project imports no cryptography today; this is new.

The public key arrives as a Pages environment variable, the same mechanism ANTHROPIC_API_KEY uses.

Every sales endpoint gates. /api/sales/analyze, /api/sales/shape, /api/sales/render, /api/sales/draft — all four read the cookie and verify before anything else, ahead of the rate limiter and ahead of any Anthropic call. A refused call spends nothing.

Refusal is a refusal, not a redirect. The tools do not know how to authenticate anyone and must not learn. A refused call says the pass is missing or expired. It does not send the browser anywhere.

6. The menu

A new route in the Operator Layer. It is behind the same Stele sign-in as everything else there; it adds no authentication of its own.

Data-driven from the start. The tool list is data, not markup. A new tool is a new entry. This is the whole reason this is infrastructure rather than a one-off gate — a FORAY generator is in design and inherits this.

Each entry carries: what the tool is, in plain terms, and a form that POSTs to that tool's entry point with the pass in a hidden field.

The menu mints on render, one call per tool listed, and embeds each pass in its form. A reloaded page is a fresh set of passes.

A tool the Operator cannot get a pass for does not appear. Not disabled, not greyed — absent. If the mint refuses, the entry is not rendered. This follows the standing rule: only show what is available.

Where it hangs: the Operator Layer's navigation is a hardcoded component and there is no launcher concept anywhere. Adding an entry to that navigation is the smallest correct change. Do not build a general navigation system.

7. What this does not do

Agents. Stele Agentic ID returns a verdict from a bounded chain walk, not a credential. There is nothing for an edge function to hold. Named as out of scope with a reason, not deferred silently.
Per-tool authorisation. Version one is founder-or-nothing. Which person may use which tool is GRANTHA's question, and GRANTHA is documents with four ratified items.
Revocation. The pass is stateless, like the Stele session it descends from. Nothing invalidates one early. Thirty minutes bounds it.
Key rotation. Undesigned. The script generates; nothing rotates.
The public Example Generator. Untouched.
Cloudflare Access on the record site and the mockups. Settled by the Operator: it stays. Those are static documents behind a perimeter, not tools authenticating a person.

8. Build sequence

The three repositories make this unusual. Build from the inside out — the thing nobody has exercised first.

The keypair script and the engine's settings field. Verify: the script prints a seed and a public key; the engine starts with the seed set and refuses to mint without it.
The mint endpoint. Verify locally: a signed-in founder gets a pass; an unknown tool name is refused; no principal is refused.
The entry point and the verify helper. Verify locally: a pass minted in step 2, POSTed as a form to the entry point, sets a cookie and redirects. A tampered pass sets nothing. An expired pass sets nothing.

Halt after step 3 and report. The cross-site form POST that sets a cookie is the one mechanism nothing in either project has ever performed. If it does not work, the carry is wrong and the menu is wasted work. This is the cheapest kill point and it comes before any surface is built.

Gate the four sales endpoints. Verify: an ungated call is refused before the rate limiter and before any Anthropic call.
The menu. Verify: it lists the sales generator, minting on render.

9. What the Operator must configure

None of this is in version control and Claude Code must not attempt it.

Run the key script and keep both halves.
The seed into the engine's environment, alongside loomworks_secret_key.
The public key into the marketing Pages project's environment variables, on the Cloudflare dashboard — production and preview both, the same mechanism ANTHROPIC_API_KEY uses.

Order matters. The public key must be set before the gated tools deploy, or every call refuses.

10. Acceptance

Accepted when the Operator can:

Sign into the Operator Layer with a passkey and a one-time code, as today.
Open the menu and see the sales perspective generator listed.
Click it and land on a working tool, without a second sign-in.
Generate — the pitch, the draft, two readers — end to end.
Visit /sales-generator/ directly, with no pass, from a private window, and be refused.
Call /api/sales/analyze with no cookie and be refused.
Open /example-generator/ and /harvest-surge/ and find them working, ungated.
Wait out thirty minutes and find the pass refused, then get a fresh one from the menu.

Point five is the test that matters. On 2026-07-17 a preview deployment of this tool was reachable by anyone holding the address. That must not be reproducible.

11. A stated dependency, not a defect

The menu's path to the engine exists because the Operator Layer is running as a development server.

Verified 2026-07-17: the engine is reachable at loomworks-dev.dunin7.com/api/, through a tunnel to the Operator Layer on port 3001, whose /api/ proxy forwards to the engine. That proxy is configured only when the environment is development; a production build emits no rewrites.

The design's premise holds — the menu talks to the engine the way the rest of the Operator Layer already does, and that works today. But building the Operator Layer frontend for production would cut this path, and the way out is not small: api.loomworks.dunin7.com has no tunnel ingress rule, the engine's cross-origin allowlist is empty in production, and the session cookie is host-only and would not reach a sibling subdomain without an engine change nobody has scoped.

This is recorded so that whoever productionises the frontend knows what they would be cutting. It is not a reason to delay this build.

12. Consequence for Change Request 2026-152

Section 8 of that Change Request specifies a Cloudflare Access application covering /sales-generator/ and /api/sales/, settled by Operator direction on 2026-07-17.

Under this build the pass is the gate, and that Access application is redundant — a second door, using the identity system this work exists to stop reaching for. When this lands, CR-2026-152 section 8 needs amending to say the sales generator is gated by the tools pass, with the Access decision preserved as the superseded prior.

That amendment is not in this Change Request's scope. It is named here so it is not discovered later.

13. Handoff must report

The commit on each of the three repositories. Nothing merges to any main branch.
The step-3 finding: did the cross-site form POST set a cookie and redirect? Quote what the browser received.
Confirmation that functions/api/_lib.js is unmodified, by diff against main.
Confirmation that ~/stele is unmodified, by diff.
Confirmation that the public Example Generator's four routes are unmodified, by diff.
The exact byte sequence being signed, so the two languages can be checked against each other.
That no private key appears in any log, response, or committed file.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-153 — Operator tools menu and authenticated edge access — v0_1 — 2026-07-17