Loomworks — dunin7.com perimeter and sales-generator relocation — Session handoff — v0.1

Version. 0.1 Date. 2026-07-18 Author. Claude.ai, on Operator direction. Status. Session handoff. Captures a scoped-but-not-yet-built plan so a fresh chat can resume without reconstructing it. Nothing in this plan is built. The immediate next action is a Stage 0 inspection brief for Claude Code, described in section 8. Reads with. loomworks-operator-tools-menu-scoping-note-v0_3, cr-2026-153-operator-tools-menu-v0_1, and the three same-day investigations grounding them (agentic identity, authenticated marketing access, pre-Change-Request verification).

Plain-language summary

What this is. A plan to give the sales-perspective generator a proper, hardened, public home — reached by signing in with Stele — and to build the authentication-and-authorization perimeter that everything else insider will sit behind. It is scoped and agreed but not built.

The decision that shaped it. Everything DUNIN7 provides as a service lives on dunin7.com. Everything DUNIN7 says about a service lives on doneinseven.com. The sales generator is a service, so it moves off the marketing site (doneinseven.com) to dunin7.com, inside the authenticated perimeter. This single rule retires the entire cross-domain token mechanism that was built earlier, because sign-in, menu, engine, and tool then all share one registrable domain.

Who needs access, and why it matters. Three levels, and they are the reason this is being built properly now rather than hardcoded: the founder (everything), DUNIN7 representatives (Aldous and Warwick, who need sales access immediately), and outside customers (test users, who may arrive fast). Three real user types force a real authorization model from day one.

How it will be built. Four staged deliveries, each landing a working thing you can stop safely after, with the riskiest net-new piece (the outside-user redirect flow) built last on a proven perimeter.

The immediate next step. A Stage 0 inspection brief for Claude Code, which reads the local tunnel configuration and reports the exact facts needed before anything is built or any DNS record is created.

1. The domain rule (Operator, 2026-07-18)

Stated by the Operator, and now the governing principle for where things live:

• DUNIN7 providing a service → dunin7.com.
• DUNIN7 talking about a service → doneinseven.com.

dunin7.com is where DUNIN7's services and their sign-in live. Insiders, outside customers, and eventually agents all authenticate there, because that is where authentication happens — not because dunin7.com is insider-only. An outside Loomworks user given a URL is forwarded to a dunin7.com page where Stele authentication happens, then returned.

Consequence: the sales generator is a service DUNIN7 operates, so it belongs on dunin7.com. It sits on the marketing site today only as an accident of the spike's history. Moving it home dissolves the cross-domain problem (see section 4).

The public example generator stays on doneinseven.com, ungated — it is DUNIN7 talking about the service to draw people in. Correct by the rule.

2. Authentication and authorization are separate (correction, 2026-07-18)

An early framing — "everyone on dunin7.com signs in, everything is open to them" — was wrong and was corrected by the Operator. The correct model:

• Authentication (Stele) proves who you are. One door, on dunin7.com, no substitutes. This is the standing direction from 2026-07-17: anything authenticating a person in a DUNIN7 system uses Stele.
• Authorization decides what that identity may reach. Per-person, per-surface. A signed-in identity does not get everything — it gets what it is authorized for.

With only the founder, require_founder hid this distinction. Aldous, Warwick, and test users force it into the open, which is why the authorization model must be real from the start.

3. The three authorization levels (Operator-confirmed)

1. Founder (the Operator). Everything, including the sales generator and admin surfaces. require_founder today.
2. DUNIN7 representative (Aldous, Warwick). Sales and marketing tools including the sales generator; not admin, not credit-grant or provisioning routes. They represent DUNIN7 in a sales capacity and need access immediately.
3. Outside customer (test users). Loomworks itself; not the sales generator, not DUNIN7-internal surfaces. Test users may arrive fast, so this level is in scope now, not deferred.

The engine already has the raw material: require_operator_designation reads a designation from a fixed set (operator, contributor, domain_expert) on a membership. The authorization layer largely exists; it is not yet wired to the sales generator. Build authorization as a seam that GRANTHA can later answer, but hardcode the answer for now — do not build GRANTHA (it is documents with four ratified items and not ready).

4. What the domain move retires

The tools-pass mechanism in CR-2026-153 (the engine mint, the marketing-side entry point, the form-POST-to-cookie carry, the edge verify) existed only to cross registrable domains — tool on doneinseven.com, auth on dunin7.com. With the tool on dunin7.com, the session cookie set with Domain=dunin7.com spans everything, and the menu simply links to the tool.

What retires: the cross-domain carry — the mint-a-pass, POST-it, verify-it-at-the-edge dance.

What stays: the authorization question it was transporting. Same-domain, "is this authenticated person allowed to use this tool?" is answered against the session plus the designation, not a carried token. CR-2026-153's mint/verify is superseded as transport; its authorization intent lives on in the designation check. Preserved in the record as the superseded approach — it was the right answer to the cross-domain problem, which the domain rule made disappear.

5. Where the sales generator lands: the engine (Claude Code recommendation, verified)

Claude Code inspected both candidate homes and recommended the engine, one-sidedly:

• The engine already has the Anthropic client, a rate limiter, CORS middleware, and the founder-gated auth dependencies live and in use by sibling routes.
• The Operator Layer has confirmed-zero server-side infrastructure — no route handlers, no Anthropic SDK, no rate limiter. Landing there means building a thinner duplicate of what the engine already has, then calling the engine anyway.

So the /api/sales/* chain (currently JavaScript Cloudflare Pages Functions on the marketing project) ports into the engine as Python/FastAPI routes.

6. The staged build (four deliveries, stop-safe after each)

Agreed shape: build all of it, but as staged deliveries with a working, safe stop after each — not one long sequence. The two worst moments of the prior day (an API key leak, an ungated preview) both came from rushing a long sequence; staging isolates the risk.

• Stage 1 — the perimeter. Production build of the Operator Layer at app.dunin7.com; engine reachable at api.dunin7.com; session cookie set Domain=dunin7.com so it spans both; CORS opened to the one origin; the three-level authorization model built on the existing designation mechanism. Stop-safe: the Operator signs in on the real domain, end to end, and the perimeter correctly distinguishes the three levels. Verify the negative too — an unauthenticated request to a protected surface is refused.
• Stage 2 — relocate the tool. Port /api/sales/ into the engine, gated on designation (not founder-only). Retire the cross-domain carry. Stop-safe:* the tool works behind the gate, reached through the menu.
• Stage 3 — provision and finish content. Provision the Operator, Aldous, Warwick, and test users as Stele identities with their designations. Build the sales-generator content fixes still outstanding: v0.25 (rows derive from what the work demands; alternatives become a landscape section), v0.26 (renumbering and acceptance criteria), and decision B for §3.3c (with no current-approach input the table renders with the unsourced cells worded as questions for the first conversation — "Not yet known — a question for the first conversation," never a bare gap). Stop-safe: representatives have access, content matches spec.
• Stage 4 — the outside-user redirect flow. The forward-from-doneinseven.com, authenticate-on-dunin7.com, return flow. Built last, on a proven perimeter, adopting the established OIDC-shaped redirect pattern rather than hand-rolling it (open-redirect risk). Test-user identities from Stage 3 exercise it. Stop-safe: outside users can reach Loomworks through the proper arrival experience.

Discipline throughout: Claude Code verifies every step against the running system, not against a summary; halts between stages. Any Stele modification is surfaced to the Operator as a diff before it is applied.

7. The tunnel finding — the fact the whole Stage 0 brief is built around

Verified on the Cloudflare dashboard, 2026-07-18:

• The tunnel dunin7-m4 is a locally configured tunnel. The Zero Trust dashboard states plainly it "cannot be managed from the Zero Trust dashboard as it is a locally configured tunnel." Routing lives in a local config file on the Mac (a cloudflared config, e.g. ~/.cloudflared/config.yml), not in the dashboard.
• Do NOT click "Start migration" on that tunnel page. It is irreversible and would move ingress control to the dashboard, away from the local file Claude Code can read and edit. Wrong direction. Leave the tunnel local.
• A live wildcard footgun. .dunin7.com is a Tunnel record routing to dunin7-m4. Any new hostname not given an explicit ingress rule ahead of the wildcard* will be silently misrouted (Claude Code reported the wildcard resolves to Forge on :3400). app.dunin7.com and api.dunin7.com must have explicit ingress rules placed before the wildcard.
• app and api do not exist as DNS records yet. Dashboard DNS filters for both returned "No DNS records." The existing tunnel hostnames (forge, workforce, foraychallenge) are proxied CNAME/Tunnel records pointing at dunin7-m4 — the pattern the two new records must match.

The split this creates:

• Local config file (Claude Code's job): add ingress rules app.dunin7.com → localhost:3001 and api.dunin7.com → localhost:8000, placed before the *.dunin7.com wildcard; restart cloudflared.
• Dashboard (Operator's job): create two DNS records, app and api, as proxied records pointing at the tunnel, matching the existing tunnel-hostname pattern. To be done with exact content Claude Code reads from the local file — the tunnel UUID must match, and must not be guessed.

Both halves must match, or the hostname resolves without routing, or routes without resolving.

8. The immediate next action — Stage 0 inspection brief

Before anything is built or any DNS record is created, a fresh Claude Code session runs a Stage 0 inspection that:

• Reads the local tunnel config file and reports its path, the tunnel UUID, the current ingress rules, and exactly where the *.dunin7.com wildcard sits in the ordering.
• Confirms what a production build of the Operator Layer breaks (the dev-only /api/* proxy in next.config.ts) and what replaces it.
• Reports the exact Stele cookie change needed (Domain=dunin7.com on all set_cookie calls and the clear-cookie/logout call — missing the latter breaks logout) and the adjacent secure=False inconsistency in signup.py and me_reactivate.py that should be fixed in the same pass. Report only; do not modify Stele without surfacing the diff.
• Reports the engine's production CORS allowlist (LOOMWORKS_CORS_ORIGINS) and what origin it needs.
• Confirms the port of /api/sales/* into the engine: what is reused, what is net-new, the rate-limiter story.
• Hands back the exact DNS record content (tunnel UUID, type, proxy status) for the Operator's two-record dashboard step, read from the real config, not guessed.

Claude.ai writes this brief next. It commits nothing and recommends nothing to build — it verifies the whole path once, up front, so the staged build rests on the real configuration.

9. Open facts still needed (none block writing the Stage 0 brief)

• Hostnames confirmed: app.dunin7.com (Operator Layer), api.dunin7.com (engine).
• DNS records for app/api: do not exist yet; Operator creates them with Claude-Code-supplied content after Stage 0.
• Tunnel config location: local file, confirmed. Claude Code reads it in Stage 0.

10. Prior-day context this rests on (for a fresh chat)

• The sales-perspective generator is built through v0.24 on an unpushed marketing branch, specified through v0.26 in the record. The v0.25/v0.26/B content work is Stage 3 here.
• CR-2026-152 is the sales generator's Change Request, at v0.26 in the record, fully pushed.
• CR-2026-153 is the tools-menu / mint / verify Change Request — largely superseded as transport by the domain move (section 4), preserved in the record.
• The Operator Layer, engine, and marketing site run locally on the Mac (DUNIN7-M4); the Operator Layer has been reachable in production only as a development server, which Stage 1 replaces.
• Standing two-role discipline: Claude.ai scopes and writes; Claude Code executes, inspects, verifies against live code, and halts before every push. Record filings are bare instructions, separate from analysis.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — dunin7.com perimeter and sales-generator relocation — Session handoff — v0_1 — 2026-07-18