[EPIC] Enterprise-ready: make ScriptHammer a repo you can build real work on (eval-3 → eval-1)

[TortoiseWolfe]

Umbrella / epic. This is the standing tracking issue for making ScriptHammer enterprise-ready. It defines the bar, tracks the child work, and records the constraint driving it.

⛔ Blocking constraint (owner): "I can't use this repo for real work until it's enterprise-ready." This arc gates real production use of ScriptHammer. Until the bar below is met, ScriptHammer is a shipping template + reference app, not a foundation the owner will build real work on.

What "enterprise-ready" means here

The repo's own eval-* labels name the gap precisely. ScriptHammer today reads as eval-3 — "hard backend task on a template-framed repo." The goal is eval-1 — "established enterprise OSS or enterprise-clone repo": something a company would adopt, staff, and maintain in production. The prior repositioning work (#250, #152 — both CLOSED) fixed the framing/narrative; this arc fixes the engineering substance so the framing is earned, not asserted.

Concretely, "enterprise-ready" = all of:

1. Swappable, non-vendor-locked backend. The app is not hard-wired to Supabase. A team can run it on a backend they control (ASP.NET Core + EF Core, KDG-style) by configuration, with the security model preserved. → Modular backend: abstract messaging so it swaps Supabase↔.NET (EF Core) by env var #266, Migration anchor: swap ScriptHammer's Supabase backend for ASP.NET Core + EF Core (.NET), KDG as reference #265.
2. Security model that survives the swap. The 75 RLS policies / SECURITY DEFINER membership helpers / 15-min edit window / no-delete ban are re-expressed as an explicit, tested app-side authorization contract on any backend — no rule silently dropped. → Modular backend: abstract messaging so it swaps Supabase↔.NET (EF Core) by env var #266, Migration anchor: swap ScriptHammer's Supabase backend for ASP.NET Core + EF Core (.NET), KDG as reference #265.
3. Production operations posture. Container hygiene, secrets handling, observability (Sentry live), health/self-heal, and a documented deploy story that isn't "GitHub Pages + one shared Supabase project." → Docker best-practices audit: 0 high / 4 med / 2 low (Bret Fisher rubric) #275 (docker audit), Sentry DSN flip ([Gap-Audit] 044 Error Handler Integrations: Sentry/LogRocket integration + PII scrubbing + session replay #45), ops backlog.
4. Compliance + data-integrity already met. GDPR export/erasure, audit logging, payment integrity, messaging reliability — the correctness floor a real product needs. → DONE (cluster PayPal payments are double-counted in admin revenue #239–248 shipped 2026-07-13, PRs fix(#239,#240,#241,#242): close the security-critical auth/payments bug cluster #276–fix(#244,#245,#246): make concurrent + offline message delivery reliable #279).

When 1–4 hold, ScriptHammer clears the eval-3 → eval-1 bar and the owner can build real work on it.

Child tickets (the tracked work)

Backend independence — the core of the bar (eval-3, tied to the closed #106 arc):

• Modular backend: abstract messaging so it swaps Supabase↔.NET (EF Core) by env var #266 — Modular backend: abstract messaging so it swaps Supabase↔.NET (EF Core) by env var. The MessagingProvider interface + NEXT_PUBLIC_BACKEND_PROVIDER switch + a Supabase impl + a skeleton .NET/EF impl with the messaging RLS rules re-expressed as an explicit app-side auth contract. The first real step — proves the seam on one domain.
• Migration anchor: swap ScriptHammer's Supabase backend for ASP.NET Core + EF Core (.NET), KDG as reference #265 — Migration anchor: swap the whole Supabase backend for ASP.NET Core + EF Core (.NET), KDG as reference. The full paradigm migration: 75 RLS policies → EF filters/authorization handlers, 12 edge functions → controllers/middleware, 18 realtime files → SignalR, 81 Supabase-client files. The flagship — "we migrated our entire production backend."

Production operations posture:

• Docker best-practices audit: 0 high / 4 med / 2 low (Bret Fisher rubric) #275 — Docker best-practices audit (Bret Fisher rubric): 0 high / 4 med / 2 low. Close the 4 med + 2 low.
• Sentry DSN → flip [Gap-Audit] 044 Error Handler Integrations: Sentry/LogRocket integration + PII scrubbing + session replay #45 live (error monitoring in production — an ops-readiness signal).
• (add as identified) — a documented non-Pages deploy story; secrets posture review; per-tenant / multi-project story if that's part of the target.

Already met (the correctness floor):

• GDPR + data-integrity + messaging reliability — cluster PayPal payments are double-counted in admin revenue #239–248 shipped (admin auth single-source, audit logging, payment integrity, GDPR export/erasure, group-key rotation, concurrent/offline messaging). PRs fix(#239,#240,#241,#242): close the security-critical auth/payments bug cluster #276–fix(#244,#245,#246): make concurrent + offline message delivery reliable #279, all merged, verified live. ✅
• Enterprise framing/narrative — Reposition ScriptHammer to read as an enterprise product, not a starter template #250 (product positioning) + Reposition README to lead with the product (keep fork as secondary) #152 (README leads with the product). ✅ CLOSED.
• Shared CI infra + payment E2E un-skipped — [Phase 0f] Shared infra + un-skip 86 E2E payment tests (~2h) #106 (Phase 0f). ✅ CLOSED.

Sequencing (recommendation, not a commitment)

#266 → #265 is the natural order: prove the provider seam on the messaging domain first (bounded, one domain, the security-contract problem in miniature), then do the full backend migration with that pattern established. #275 + Sentry are independent ops work that can slot in anytime. None of this conflicts with the Combined Arms (048) game arc — 048's match server is a separate Node/TS deployable with no Supabase schema changes, so the two arcs run independently.

Relationship to the roadmap (#115)

This arc is not the current active arc (#115 points at 048 Combined Arms). This umbrella exists so the enterprise bar is tracked and visible regardless of what the active arc is — the owner's constraint (real work is blocked until this is met) means it should be scheduled deliberately, not left implicit. When the owner wants to prioritize it, promote #266 into the roadmap's "next 3 sessions."

How to use this issue

• New enterprise-gating work → add a child checkbox here + link the ticket.
• A child ships → check it, note the PR.
• When items 1–4 under "What enterprise-ready means" all hold → the bar is met; close this umbrella and the repo is cleared for the owner's real work.

[TortoiseWolfe]

Child added: #287 — production auth was never provisioned.

Found 2026-07-15 when the owner couldn't sign in on production. Both OAuth providers are enabled with literal placeholder client IDs (placeholder_google_client_id / placeholder_github_client_id), there's no custom SMTP (built-in sender capped at 2 emails/hour, exhausted by 368 E2E users), and site_url was still http://localhost:3000 with an empty redirect allow-list. All three sign-up paths were blocked — no real human had ever created an account.

This is a textbook instance of criterion (3) production ops posture: the code is correct and every test is green, but the deployed instance was never provisioned for real users. The E2E suite provisions users via the admin API, which routes around the exact paths a human hits — so nothing caught it.

Fixed already (no secrets needed): site_url + uri_allow_list corrected, owner account provisioned, auth stack verified working end-to-end. Still blocked on owner-supplied credentials: Google OAuth client, GitHub OAuth app, real SMTP.

[TortoiseWolfe]

Child added: #288 — enterprise-level testing gap.

Direct fallout from #287, and the owner's point: "if we're going to be enterprise ready we're going to need enterprise level testing."

The proof is one line — tests/e2e/security/oauth-csrf.spec.ts:186 reads the real OAuth client_id and asserts expect(...).toBeTruthy(). The live value was "placeholder_google_client_id" — a non-empty string — so the test held the defect in its hand and passed. It asserted presence, not validity.

Compounding it: every test user is minted via admin.createUser({email_confirm:true}) (test-user-factory.ts:159), which bypasses the real signup form, the mailer, and OAuth — i.e. the suite exercises a path no human can take, and never the three paths every human must take. Nothing in tests/ targets the deployed origin at all.

#288 proposes: assert config validity (not presence), a post-deploy @smoke suite against the real origin, one E2E through the real signup form, and CI drift-checking of the config-as-code.

Also fixed today as part of this: scripts/supabase/auth-config.json now declares site_url + uri_allow_list — previously my live production fixes were untracked, and a re-apply of the config tool would have silently reverted prod back to localhost:3000.

[TortoiseWolfe]

Child added: #290 — SMTP / Resend domain verification (criterion 3: production ops posture).

Split out of #287 so that ticket can close. Blocked on 3 DNS records at Squarespace only — the Resend API key is already saved and validated; nothing technical is unknown.

Key finding recorded there: the shared onboarding@resend.dev sender cannot be used as a stopgap — verified by API test that it only delivers to the account owner (jonpohlner@gmail.com) and 403s for every other recipient. Wiring Supabase to it would silently fail for all real users. Domain verification is mandatory.

Also documented (cost an hour to establish): DNS for scripthammer.com is at Squarespace (registrar = Squarespace Domains II LLC per RDAP), NOT Google Cloud DNS — the NS-CLOUD-*.GOOGLEDOMAINS.COM nameservers are legacy leftovers from Google Domains being sold to Squarespace in 2023. The GCP scripthammer project has no DNS zone ("Cloud DNS API has not been used… No rows to display"). And the Mailgun account backing the apex MX/SPF is inaccessible (bad credentials). Don't re-walk those dead ends.