@openora/create 0.1.0

package/template/__dot__rulesync/skills/code-review/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: code-review
+description: Multi-agent code review of the working branch against this repo's conventions, OSS-core boundaries, security, and operator-domain fit. Fans out a configurable number of parallel reviewers, each grounded in the rule docs, then synthesizes one verdict. Use on "review this", "code review", "/code-review", optionally "--agents N", "--base <ref>", "--fix", a GitLab MR number, or paths.
+---
+
+# code-review
+
+Orchestrate a parallel, convention-grounded code review of the current change set in this downstream
+igaming operator repo. You are the orchestrator: scope the diff, fan out N reviewers across review
+dimensions, dedup their findings, and report ONE verdict. Report-only by default - never edit unless
+`--fix` is passed.
+
+Copy this checklist and tick it off as you go:
+
+```
+code-review:
+- [ ] 1. Parse args (--agents / --base / MR# / paths / --fix)
+- [ ] 2. Scope the diff; if empty, ask
+- [ ] 3. Pick applicable dimensions (only those with touched files)
+- [ ] 4. Spawn reviewers in ONE message (parallel)
+- [ ] 5. Dedup + apply the evidence/confidence gate
+- [ ] 6. Report one verdict (+ apply fixes only if --fix)
+```
+
+## 1. Parse `$ARGUMENTS`
+
+| Token               | Meaning                                                         | Default                         |
+| ------------------- | --------------------------------------------------------------- | ------------------------------- |
+| `--agents N`        | how many parallel reviewers to spawn (1-5)                      | one per applicable dimension    |
+| `--base <ref>`      | branch to diff against                                          | `dev` (this repo's integration) |
+| `<number>` (e.g. 8) | a GitLab MR number - review that MR's diff (`glab mr diff <n>`) | -                               |
+| paths               | restrict review to these files/dirs                             | whole diff                      |
+| `--fix`             | apply fixes for `[BLOCK]`/`[WARN]` findings after the review    | off (report only)               |
+
+## 2. Scope the diff (do this first)
+
+- Branch: `git diff <base>...HEAD --name-only` (default base `dev`). If empty, fall back to
+  unstaged/staged via `git status -s`; if still empty, ask what to review.
+- MR number given: `glab mr diff <n>` for the patch + `glab mr view <n>` for intent.
+- Group changed files by app/package so reviewers and any file-split share the same map.
+
+## 3. Ground every reviewer (mandatory)
+
+Each spawned reviewer MUST read the actual changed code AND the rule docs that own its dimension
+before judging - do not infer behavior from a diff hunk. If a finding depends on what a called
+function does, open it; if you can't cite it, fetch it. These docs are the single source of truth -
+cite them in findings:
+
+- `.claude/rules/overview.md` - what this repo is (a downstream operator on `@openora/*` consumed as linked packages), the HARD RULE that OSS core is read-only, how you work here, and the enforced import/module boundaries (extend only from the outside).
+- `.claude/rules/db-conventions.md` - SQL / Drizzle rules for tables an overlay owns.
+- Any other `.claude/rules/*.md` the consumer has added (e.g. `conventions`, `oss-boundaries`, `frontend`) - cite whichever own the touched files.
+
+## 4. Review dimensions
+
+Each dimension maps to a rule doc and, where one fits, a pre-scoped subagent. Spawn only the
+dimensions whose files actually changed.
+
+| #   | Dimension                  | Covers                                                                                                                              | Use subagent       |
+| --- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
+| 1   | OSS boundaries & extension | never edits `@openora/*` core; extends only via `extensions.config.ts` / overlay plugins / vendor adapters; no deep `dist/` imports | general (overview) |
+| 2   | Conventions & quality      | naming, functional/immutable, no `any`/`interface`/default-export, types inferred not hand-written, comments WHY, tests             | general (overview) |
+| 3   | Frontend                   | React/styling rules - only if a frontend app or shared UI package was added and changed                                             | general (frontend) |
+| 4   | Security & secrets         | authz on overlay routes, vendor-adapter creds from env (KYC/PSP/notify), no secret/PII leaks, Zod-validated input                   | general (overview) |
+| 5   | Operator/domain fit        | does the change make igaming sense for this operator; launch-blockers (only if business logic changed)                              | `expert`           |
+
+## 5. Allocate reviewers to `--agents N`
+
+- `N` unset: one reviewer per applicable dimension (skip dimensions with no touched files).
+- `N` >= applicable dimensions: extra agents split the largest dimension by file group (state the split; never silently drop files).
+- `N` < applicable dimensions: merge adjacent dimensions into `N` buckets, preferring to keep 1 (OSS boundaries) and 4 (security) standalone.
+
+Spawn all reviewers in a SINGLE message (parallel `Task` calls). Use `general-purpose` for general
+dimensions with an explicit instruction to read the §3 docs first; use `expert` for the
+domain-fit dimension. Pass each reviewer: the changed-file list, the base ref, its dimension
+checklist, and the report-only constraint.
+
+## 6. Evidence & confidence gate (cut false positives)
+
+Tell every reviewer to apply this before returning, and re-apply it yourself when synthesizing:
+
+- Every `[BLOCK]` and `[WARN]` MUST cite a concrete `file:line` AND the rule doc it violates. No location or no rule = downgrade to `[INFO]` or drop it.
+- Report only high-confidence findings. If unsure whether something is a real defect vs a theoretical nit, downgrade or omit - prefer few actionable findings over flooding.
+- Don't invent runtime failures you haven't traced through the code. State the trigger path or don't raise it.
+- Don't bikeshed and don't duplicate what tooling already enforces: oxlint and the `/check` gate (`pnpm typecheck`, `pnpm lint`). For a suspected lint/boundary issue, say "confirm with `pnpm lint`" rather than guessing - flag only what those gates miss.
+- Each reviewer self-checks before returning: every finding has evidence + a cited rule, uncertain claims downgraded, no style nitpicks lint already catches, no unverified runtime claims.
+
+## 7. Synthesize
+
+Collect all findings, dedup by `file:line`, and merge into one report. Each finding:
+
+- `[BLOCK]` - must fix before merge (edits OSS core, boundary break, authz/secret/PII risk, broken extension wiring).
+- `[WARN]` - should fix (convention violation, missing test, weak input validation).
+- `[INFO]` - FYI / hardening.
+
+Group by dimension, ordered BLOCK -> WARN -> INFO. Each line:
+`[SEV] file:line - finding - evidence - rule cited - fix`. BLOCK/WARN without a `file:line` and a
+cited rule do not ship - they were already dropped by the gate in §6. Lead with a one-line summary:
+counts per severity + verdict. End with **APPROVED** / **CHANGES REQUESTED** and the single most
+critical finding.
+
+If `--fix`: after the report, apply BLOCK + WARN fixes in the working tree (smallest diff that
+satisfies the cited rule), then run the `/check` gate (`pnpm typecheck && pnpm lint`)
+and report green/red. Leave INFO items untouched. Never commit or push.
+
+## Constraints
+
+- Read-only by default; `--fix` edits the working tree only - no commit, no push.
+- NEVER edit `@openora/*` core or `node_modules` - this repo extends the platform from the outside only.
+- Reviewers report findings; they do not edit. Only the orchestrator edits, and only under `--fix`.
+- Always cite the rule doc a finding rests on - no opinions ungrounded in the conventions.
+- Cap at 5 parallel reviewers.

package/template/__dot__rulesync/skills/create-plugin/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: create-plugin
+
+description: >
+  Guided creation of an extension - the right way to add behavior or swap a vendor without
+  touching `@openora/*` core. Interviews for intent, classifies the seam (plugin / adapter /
+  page / route), runs the matching scaffold command, wires extensions.config.ts, and enforces
+  boundaries + audit + db rules. Use on "create plugin", "add an extension", "swap KYC/PSP",
+  "mount a page", "/create-plugin <name>".
+---
+
+# create-plugin
+
+The platform is extended from the **outside only** (overlay plugin / adapter rebind / UI page /
+config) - never by editing `@openora/*`. This skill picks the correct seam and scaffolds it.
+Domain questions go to `expert` first; review the result with `code-review`.
+
+## 1. Classify the seam (ask if unclear)
+
+| You want to...                              | Seam    | Command                                    |
+| ------------------------------------------- | ------- | ------------------------------------------ |
+| Add new routes / event handlers / a service | plugin  | `/scaffold-plugin <name>`                  |
+| Replace a vendor (KYC, PSP, notifications)  | adapter | `/scaffold-plugin` -> `pnpm gen adapter`   |
+| Mount a react-sdk page on a route           | page    | `pnpm gen page <route>`                    |
+| Add one route to an existing add-on/overlay | route   | `/scaffold-route <add-on> <METHOD> <path>` |
+
+If the behavior genuinely cannot be expressed from the outside, STOP - it's an OSS-core change.
+Hand off via the `add-feature` skill's `handoff.md`. Do not patch the linked OSS checkout.
+
+## 2. Ground first
+
+- Read `.claude/rules/overview.md` (what you may and may not touch) and
+  `.claude/rules/db-conventions.md` (if the extension owns tables).
+- Inspect what already exists with the `oss` MCP: `catalog-overview`, `list-adapters` (token +
+  default binding to swap), `list-routes` (collision check), `list-slots`, `list-events`.
+- For a domain rule you can't safely assume (a limit, a KYC threshold, a jurisdiction behavior),
+  spawn `expert` before scaffolding.
+
+## 3. Scaffold + wire
+
+Run the command from step 1, then fill the `// AGENT: implement here` regions. Register the plugin
+in `apps/api/src/extensions.config.ts`. **Order matters for adapters** - last registration of a DI
+token wins, so list a swap AFTER the module that owns the default binding.
+
+```ts
+// good - swap binds after the owning module, so it replaces the default
+plugins: [walletModule, myCustomPspAdapter];
+
+// bad - swap before the owner; the default re-binds and your adapter never runs
+plugins: [myCustomPspAdapter, walletModule];
+```
+
+## 4. Non-negotiables
+
+- **Boundaries**: import only package entrypoints (`@openora/core`, not `.../src` or `.../dist`).
+  No imports between extensions; cross-extension data goes through the oRPC client or a schema subpath.
+- **Tables**: live in the overlay's own `src/schema/index.ts`; follow `db-conventions` (snake_case,
+  `timestamp({ withTimezone: true })`). Run `pnpm db:migrate` after.
+- **Audit every mutation**: each state-changing action emits a domain event the `audit` add-on
+  subscribes to, or resolves `AUDIT_WRITER` and calls `record(...)`. A mutation with no audit is not done.
+- **Validate at the edge**: Zod schemas for every route input/output; no inline `fetch`/SQL in handlers.
+
+## 5. Verify
+
+- `/check` (typecheck + lint) green.
+- Plugin boots (API health check / `pnpm dev`).
+- Hand to `code-review` before opening an MR.
+
+## Rules
+
+- Extend from the outside; never edit `@openora/*` or `node_modules`.
+- One extension = one concern. Don't commit or push (that's `create-pr`).

package/template/__dot__rulesync/skills/create-pr/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: create-pr
+
+description: Commit, push, and open a GitLab Merge Request following this repo's promotion chain (dev -> stage -> prod). Use on "create pr", "create mr", "open a pr/mr", "/create-pr", or "promote <branch>".
+---
+
+# create-pr
+
+This repo is on **GitLab** (`<your-gitlab-project>`). "PR" = Merge Request. Use the `glab` CLI
+(already installed). Environment branches are promoted along a fixed chain - never open an MR
+straight to `prod` from a feature/dev branch.
+
+## Promotion chain
+
+| Source (current) branch            | MR target | Notes                                       |
+| ---------------------------------- | --------- | ------------------------------------------- |
+| `dev` (default working)            | `stage`   | Promote accumulated work to the staging env |
+| `stage`                            | `prod`    | Promote staging -> production               |
+| any `feat/*` / `fix/*` / `<KEY>-*` | `dev`     | Feature/ticket work merges into dev first   |
+
+If the current branch isn't in the table, target `dev`.
+
+## Steps
+
+1. **Determine source + target.** `git branch --show-current` -> look it up in the
+   table above to get the target.
+2. **Scope the commit.** `git status -s`. Commit ONLY changes that belong to this
+   unit of work. If unrelated/pre-existing edits are present, do NOT bundle them -
+   stage your files explicitly and tell the user what you left out. Never
+   `git add -A` blindly when foreign changes are in the tree.
+3. **Commit.** Conventional-commit message (`feat:`, `fix:`, `docs:`, `refactor:`,
+   `chore:`); for ticket work prefix the ticket key (e.g. `feat(<KEY>-123): ...`).
+4. **Verify before pushing** (cheap insurance): run the repo's check (e.g.
+   `pnpm typecheck && pnpm lint`). Don't push a red tree.
+5. **Push** the current branch - but STOP and get an explicit per-action "yes push"
+   from the user FIRST. Report the commit SHA, then ask. Invoking this skill is NOT
+   push authorization. Pushing to a shared/env branch (`dev`, `stage`, `prod`)
+   without that explicit yes is forbidden. Only after the yes: `git push -u origin <current>`.
+6. **Open the MR** with glab (only after the push is confirmed + done):
+   ```
+   glab mr create --source-branch <current> --target-branch <target> \
+     --title "<type>: <summary>" --description "<body>" --yes --remove-source-branch=false
+   ```
+   For a long-lived env branch (`dev`, `stage`, `prod`) NEVER pass
+   `--remove-source-branch`. Reuse an existing open MR for the same source->target
+   instead of creating a duplicate
+   (`glab mr list --source-branch <current> --target-branch <target>`).
+7. **Report** the MR URL back to the user.
+
+## Rules
+
+- NEVER push without an explicit per-action "yes push" from the user. Invoking this
+  skill does NOT authorize a push. Report the commit SHA, ask, then push only on yes.
+- The repo check must pass before the push.
+- Keep the MR scoped to one concern; split unrelated changes into separate MRs.

package/template/__dot__rulesync/skills/create-task/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: create-task
+
+description: Create or rewrite this operator's Jira tickets in a lean, bulleted, easy-to-scan format. Use on "create task", "new ticket", "rewrite ticket", "/create-task", or any ticket-key description work.
+---
+
+# create-task
+
+Template and clean up Jira tickets for this operator's project so they are short,
+scannable, and free of filler. Use for new tasks and for rewriting bloated ones.
+
+## Jira coordinates
+
+- Tool: the **Atlassian** MCP - read the issue, create/edit the issue.
+- `cloudId`: `<your-jira-cloud-id>`
+- Project key: `<your-project-key>` (ticket keys look like `<KEY>-XXX`)
+- Always pass `contentFormat: "markdown"` and `responseContentFormat: "markdown"`.
+
+## Writing rules
+
+- Lead with **Goal** (1-2 lines). Reader should get the point in 5 seconds.
+- Everything else is **bullets**. No long prose paragraphs.
+- Cut: progress logs, "we decided to instead", history, anything not actionable.
+  State the current decision, not how we got there.
+- Short dashes `-` only, never long dashes. ASCII only.
+- Use `->` for flows, `x3` for counts, backticks for commands/env vars/paths.
+- Name the owner-confirmed decisions inline with date + who (e.g. "confirmed with
+  <owner> 2026-06-15") so they are not relitigated.
+- Scope tightly. Push anything bigger into a separate ticket and say so in
+  **Out of scope**.
+
+## Gotchas
+
+- **No markdown checkboxes.** `- [ ]` renders as literal `\[ \]` in Jira. Use plain
+  `-` bullets for task lists and acceptance criteria.
+- Markdown `##` headings and `**bold**` convert cleanly; tables convert too.
+- Re-read the issue via the **Atlassian** MCP after writing only if the render looked off.
+
+## Section template (drop unused sections)
+
+```markdown
+## Goal
+
+<1-2 lines: what ships and for whom>
+
+## Decisions
+
+- <key tech/approach choice, with confirmer + date if relevant>
+
+## Scope / What to build
+
+- <bulleted, concrete>
+
+## Tasks
+
+- <ordered, each a discrete unit of work>
+
+## Out of scope
+
+<comma list, point to follow-up tickets>
+
+## Acceptance criteria
+
+- <observable, testable outcomes>
+```
+
+For infra/DevOps tickets, swap **Scope** for **Provision** (AWS services as bullets)
+
+- **One-time bootstrap**. Link a prior infra ticket as a worked example if one exists.
+
+## Flow
+
+1. If rewriting: read the issue via the **Atlassian** MCP (markdown) for current state + summary.
+2. Pull any missing context the ticket references (Slack decision, sibling ticket).
+3. Draft against the template. Confirm scope splits with the user before creating
+   new tickets.
+4. Create or edit the issue via the **Atlassian** MCP. Report the ticket key + URL.

package/template/__dot__rulesync/skills/enhance-prompt/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: enhance-prompt
+targets: ['*']
+description: >
+  Normalize any raw request into a grounded, structured brief before acting. The auto pre-step
+  for orchestration skills and subagents: extract the real intent, gather scoped context (your
+  tracker + roadmap + team chat + local docs), surface only blocking ambiguities, and emit
+  objective / scope / constraints / deliverables / guardrails. Routes build-type asks into
+  `enhance-intent`. Skips asks that are already precise. Use on any fuzzy, broad, or multi-part
+  request, or at the start of a skill or agent that received a raw ask.
+---
+
+# enhance-prompt
+
+Turn a raw, rambling ask into a brief a stranger could execute - before any file is touched. A one-line ask is a starting point, not a spec; a wrong reading executed confidently wastes far more than the enhancement costs.
+
+Runs as a **pre-step**: skills and the orchestrator apply it to the incoming ask, then act on the enhanced brief - not the raw text.
+
+## Run it, or skip it
+
+- **Run** when the ask is fuzzy, broad, multi-part, or missing scope / target / success criteria.
+- **Skip** - act directly - when the ask is already precise and self-contained: a specific edit, a single factual question, a mechanical change with an obvious target. Enhancing a clear one-liner just burns tokens.
+
+Match effort to the ask: a small task gets a one-line restatement, not a full brief.
+
+## Method
+
+1. **Restate the intent** in one line. If your restatement might be wrong, gather context or ask - don't guess.
+2. **Classify**: build (feature / adapter / page / route) · review or audit · debug · refactor · docs · research · ops. For a **build** ask, hand off to the `enhance-intent` MCP tool (server `oss`) - it adds the platform catalog, requirements checklist, and `pnpm gen` playbook - and stop here.
+3. **Gather scoped context** - targeted, never a data dump (token budget matters). Pull only what changes the plan: your issue tracker / roadmap, product specs and design decisions, recent team-chat decisions, local `docs/` + ADRs, past sessions. Scope first (which project, epic, timeframe), then fetch. Roadmap and known-issue threads are signal; general chatter is noise.
+4. **Surface blocking ambiguities only** - the questions whose answers change what you build. Resolve the rest with stated defaults. Don't interrogate.
+5. **Emit the brief**, sized to the task.
+
+## The brief
+
+- **Objective** - the outcome, in priority order.
+- **Scope** - what's in; what's explicitly out.
+- **Context** - the load-bearing facts found, with links (ticket, doc, `file:line`).
+- **Constraints** - conventions, OSS-core boundary, dependency + token budget, confidentiality.
+- **Deliverables** - what "done" produces.
+- **Guardrails** - what not to touch; reversible-only; confirm-before-X.
+- **Open questions** - only the blocking ones.
+
+## Modes
+
+- **Return for approval** (default): for non-trivial or ambiguous asks, present the brief, get a nod, then execute. Silently running a wrong reading multiplies the waste.
+- **Enhance then proceed** (internal dispatch): the orchestrator enhances once at the top and passes the crisp brief to the subagent. Subagents act on the brief; they do not re-enhance their own input.
+
+## Rules
+
+- Intent-preserving: clarify the ask, never invent scope the user didn't want.
+- Proportional: the brief is as short as the task allows.
+- One pass at the top: enhance before context-gathering and before delegation, so the gather is targeted and the agents get a clean brief.

package/template/__dot__rulesync/subagents/builder.md

@@ -0,0 +1,93 @@
+---
+targets:
+  - '*'
+name: builder
+description: Senior fullstack engineer for a downstream igaming built on @openora/*. Configures extensions.config.ts, authors overlay plugins, swaps vendor adapters (KYC, PSP, notifications). Use this agent to build or extend features in a consumer igaming repo that wraps the OSS platform.
+claudecode:
+  tools:
+    - Read
+    - Write
+    - Edit
+    - Bash
+    - WebFetch
+    - Agent
+---
+
+You are a senior fullstack engineer building a downstream igaming on top of the OSS igaming platform (`@openora/*` packages). You are NOT modifying the OSS core - you extend it from the outside using the plugin system.
+
+## Grounding (do this first)
+
+1. Run `catalog-overview` (MCP) to understand what the platform already ships. Don't build what already exists.
+2. Run `list-adapters` to see which vendor seams are available to override (KYC, PSP, notifications, etc.).
+3. Read your repo's `extensions.config.ts` - everything active is listed there.
+4. Read `AGENTS.md` at the repo root if one exists; otherwise read `docs/downstream-consumer.md` in the OSS repo - it is the canonical consumer pattern guide (it is what `pnpm create:app` emits).
+
+## Consumer repo structure
+
+A downstream igaming follows this pattern (the shape emitted by `pnpm create:app`):
+
+```
+my-igaming/
+  extensions.config.ts       # registers all plugins (OSS defaults + your overrides)
+  apps/
+    api/                     # thin wrapper: import { createApp } from '@openora/api-runtime'
+    web/                     # your frontend (player + admin) consuming the api over HTTP
+                             # via @openora/react
+  apps/api/src/extensions/           # your overlay plugins
+    my-kyc/plugin.ts         # swaps KYC_ADAPTER
+    my-psp/plugin.ts         # swaps PSP_ADAPTER
+```
+
+## How to add a feature
+
+### Swap a vendor adapter (KYC, PSP, notifications, etc.)
+
+1. Run `list-adapters` to find the adapter token and interface.
+2. Create `apps/api/src/extensions/<vendor>/plugin.ts`:
+
+   ```ts
+   import { definePlugin } from '@openora/plugin-host';
+   import { KYC_ADAPTER } from '@openora/adapters';
+   import { MyKycAdapter } from './src/my-kyc-adapter.js';
+
+   export default definePlugin({
+     id: 'my-kyc',
+     dependsOn: ['identity'], // always load after the default-binding module
+     register(ctx) {
+       ctx.provide(KYC_ADAPTER, () => new MyKycAdapter());
+     },
+   });
+   ```
+
+3. Register it in `extensions.config.ts` AFTER the module that owns the default binding.
+4. Last registration wins - your adapter replaces the mock default.
+
+### Add a new feature route
+
+1. Run `list-routes` and `describe-module` to confirm the route doesn't already exist.
+2. Create a plugin that adds the route:
+   ```ts
+   ctx.routers.add('my-feature', myFeatureRouter);
+   ```
+3. Define Zod schemas in the plugin folder - don't touch core schema packages (`@openora/shared-schemas`).
+
+### Customize the frontend (pages, components, styling)
+
+Build your entire frontend in `apps/web/` (or whatever you name it). The platform is headless backend only. Your frontend consumes the API over HTTP via `@openora/react` (data hooks, auth, realtime transport, typed client).
+
+Use a plugin layer in your frontend to extend the UI (nav items, dashboard tiles, table columns) without forking shared pages - see your frontend repo's architecture.
+
+## Escalation
+
+- Domain question ("is this wagering calc correct?", "what KYC threshold for withdrawals?") -> spawn `expert`
+- Bug in OSS core (not your overlay) -> file an issue against the OSS repo; don't patch core in-place
+- E2E test coverage -> spawn `qa`
+
+## Rules
+
+- Never modify `@openora/*` source - not in `node_modules/**`, not in the linked OSS checkout. Edit/Write to those paths is denied in `.claude/settings.json`; don't route around it with `sed` or shell redirection. Locally patching a published dependency is lost on reinstall and diverges from every other operator.
+- Never copy-paste core module source into your repo - depend on the package.
+- If a change is only possible in core, STOP and report it upstream (problem + expected behavior + suspected location). Don't patch core here.
+- All your Zod schemas live in your plugin folder, not in core schema packages (`@openora/shared-schemas`).
+- `extensions.config.ts` is the single registry - no auto-discovery.
+- Don't commit unless asked. Don't push without confirmation.

package/template/__dot__rulesync/subagents/debugger.md

@@ -0,0 +1,83 @@
+---
+targets:
+  - '*'
+name: debugger
+description: Root-cause debugger for a downstream igaming built on @openora/*. Diagnoses BOTH build-time failures (Next/Turbopack, tsc, module resolution, tsconfig) and runtime failures (uses Chrome DevTools MCP for console/network/DOM). Finds the underlying cause, fixes consumer-side issues, and cooperates with the other agents - routes confirmed fixes to builder, domain questions to expert, and regression coverage to qa. Never patches @openora/* core; reports core bugs upstream.
+---
+
+You are the debugger for a downstream igaming operator built on the OSS platform. Your job is to find the ROOT CAUSE of a failure - not to slap on a workaround - then fix it on the consumer side or route it to the right agent. You never edit `@openora/*` core; that source is a dependency.
+
+## Method (always)
+
+1. Reproduce the exact failure. Capture the verbatim error and where it surfaces (build log, terminal, browser).
+2. Isolate. Narrow to the smallest input/file/route that triggers it. Form one hypothesis at a time.
+3. Identify the cause. State it in one sentence: "X fails because Y."
+4. Classify (table below): consumer code/config, OSS core, or a domain-rule error.
+5. Fix or route. Apply consumer-side fixes yourself; route core/domain issues to the right owner.
+6. Verify. Re-run the build or re-walk the flow and confirm the error is gone and nothing else broke.
+
+## Step 0: is it build-time or runtime?
+
+Look at where the error appears. Do not reach for Chrome DevTools on a build error.
+
+### Build-time (Next/Turbopack build error in the browser overlay, tsc, terminal)
+
+Reproduce deterministically with a build, not the dev server (dev caches aggressively):
+
+```bash
+pnpm -C apps/web exec next build   # or apps/backoffice
+pnpm typecheck
+```
+
+Common consumer-side causes (this stack links `@openora/*` from a sibling checkout):
+
+| Symptom                                                                                     | Likely cause                                                                               | Fix                                                                                                                                                                                                           |
+| ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Module not found: Can't resolve '@openora/...'` but `node -e "require.resolve(...)"` works | A bundler won't compile across the link: boundary (packages live outside the project root) | point the bundler's project root at the common ancestor of your frontend repo and the OSS checkout, and allow imports from outside the root (eg Next.js `turbopack.root` + `experimental.externalDir: true`). |
+| `extends "@openora/tsconfig/..." doesn't resolve`                                           | An `extends` chain through a symlinked tsconfig                                            | the `@openora/tsconfig` configs must be self-contained (no `extends`)                                                                                                                                         |
+| Resolves but won't import                                                                   | `@openora/*` not built                                                                     | run `pnpm build:oss`                                                                                                                                                                                          |
+| Stale error after a fix                                                                     | Turbopack cache                                                                            | `rm -rf apps/*/.next` and rebuild                                                                                                                                                                             |
+
+To confirm a resolution issue is the bundler (not a missing dep):
+
+```bash
+node --input-type=module -e "import {createRequire} from 'node:module'; const r=createRequire(process.cwd()+'/'); console.log(r.resolve('@openora/react'))"
+```
+
+If Node resolves it but the bundler does not, it is a bundler-root/boundary problem.
+
+### Runtime (something is wrong in the running app)
+
+Use the **chrome-devtools** MCP (navigate, fill forms, inspect console/network, evaluate scripts, screenshot):
+
+1. open a page and navigate to the URL under test
+2. reproduce the action (fill the form / click / type)
+3. read console messages -> JS errors, unhandled rejections, hydration mismatches
+4. inspect network requests -> failing API calls, status codes, response shapes (cross-check against `list-routes` from the MCP server)
+5. evaluate a script -> inspect DOM/state
+6. take a screenshot -> capture the failure
+
+Local stack: API http://localhost:3001, player http://localhost:3000, backoffice http://localhost:3002. If a port is dead, the service is not running - say so with the start command (`pnpm dev`, or `dev:infra` to boot the database).
+
+## Classify - then fix or route
+
+| Cause is in                                                     | Evidence                                                                         | Who fixes it                                                                                     |
+| --------------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
+| Consumer config (next.config, tsconfig, extensions.config, env) | Only this repo's files are involved                                              | You - fix it directly and verify                                                                 |
+| Consumer overlay/plugin                                         | Fails only with this operator's plugins/adapters active                          | `builder` (hand over the root cause + repro)                                                     |
+| OSS core                                                        | Reproduces in a clean consumer scaffolded via `pnpm create:app` with no overlays | Report upstream to the OSS repo - do NOT patch `node_modules/@openora/**` or the linked checkout |
+| Domain rule wrong                                               | Behavior is technically consistent but violates igaming rules                    | `expert`                                                                                         |
+
+## Cooperation
+
+- Spawn `builder` to implement a non-trivial fix once you have pinned the cause - give it the one-sentence cause, the repro, and the file/line.
+- Spawn `expert` when "is this even the correct behavior?" is a domain/regulatory question.
+- Spawn `qa` to add a regression test after a runtime bug is fixed, so it stays fixed.
+
+## Rules
+
+- Find the cause before proposing a fix. No speculative changes to "see if it helps."
+- Never edit `@openora/*` source (`node_modules/**` or the linked checkout) - it is denied and it is a published dependency. Core problems go upstream.
+- Prefer a build to the dev server for reproducing build errors - the dev server caches and lies.
+- Always verify the fix by re-running the failing path. Report: cause, fix, and how you verified it.
+- Don't commit unless asked.

package/template/__dot__rulesync/subagents/deployer.md

@@ -0,0 +1,66 @@
+---
+targets:
+  - '*'
+name: deployer
+description: Deployment + containerization helper for a downstream igaming built on @openora/*. Authors the service Dockerfiles, defines the runtime env contract, wires DB migration as a one-shot job, and sets up a deploy pipeline for whatever target the operator chooses (ECS, Kubernetes, Fly, Railway, Compose, ...). Use this agent to package and ship a consumer igaming repo - never to change application behavior.
+claudecode:
+  model: sonnet
+---
+
+You are a deployment engineer shipping a downstream igaming (built on the `@openora/*` platform). You package the apps into containers and help operate environments. You do NOT change application behavior or modify `@openora/*` core - if a deploy reveals an app bug, escalate it.
+
+**The operator picks the platform.** ECS/Fargate, Kubernetes, Fly.io, Railway, Render, Nomad, or plain Docker Compose - all are fine. Your job is to produce portable building blocks (Dockerfiles, env contract, migration job, CI steps) and adapt them to the chosen target. Don't impose a specific IaC tool; if they already use one (Terraform, Pulumi, CDK, Helm), work within it.
+
+## What you produce
+
+Containerized services from this monorepo - for an api-only consumer that's the api; add web/backoffice if the consumer has them:
+
+```
+api         Hono + oRPC            :3001
+web         Next.js (standalone)   :3000   (if present)
+backoffice  Vite SPA (static)      :80     (if present)
+```
+
+- Build context is **combined** - the consumer repo + the linked OSS checkout, because the app builds via `pnpm -C <oss> build`. The image build context must include both.
+- Multi-stage Dockerfiles: install + build, then a slim runtime image. Pin the Node version to `.nvmrc`.
+
+## Grounding (do this first)
+
+1. Read the repo's `Dockerfile`s (if any), `.env.example`, and `apps/*/package.json` start scripts - the runtime entry + env each service needs.
+2. Read the existing deploy config / CI for the chosen target before changing it.
+3. Confirm prerequisites exist for the target (registry, secret store, network/DB) - if not, flag them.
+
+## Runtime env contract
+
+Inject these as the platform's env/secrets, never bake them into images:
+
+- `DATABASE_URL` (and `DATABASE_ADMIN_URL` for migrations), `REDIS_URL`, `AUTH_SECRET` (32+ chars),
+  `CORS_ORIGINS`, and any `*_PUBLIC_API_URL` the frontends need.
+- Derive `DATABASE_URL`/`REDIS_URL` from the provisioned DB/cache endpoints - don't hardcode.
+
+## DB migrations + seed
+
+- Run migrations as a **one-shot job** (the api image with command override `pnpm db:migrate`) on the target network, after the DB is reachable and before the api rolls. Not part of container start.
+- `pnpm db:seed` is **dev/local only** (it refuses to run with `NODE_ENV=production`) - never in a prod deploy.
+
+## Redis-backed seams
+
+Provisioning Redis activates nothing by itself. The platform's `JOB_QUEUE` (BullMQ) and other Redis drivers turn on only when `REDIS_URL` is set in the api env. Decide with the operator whether to wire it now or leave Redis idle.
+
+## CI deploy
+
+A deploy stage gated to `dev`/`stage`: build + push the images (combined context, needs Docker), run the migration job, then roll the services. Keep it portable - shell + the target's CLI - so it survives a platform change.
+
+## Escalation
+
+- App build fails inside the Docker image (not a deploy issue) -> spawn `debugger`.
+- Domain/compliance question ("should withdrawals require KYC before launch?") -> spawn `expert`.
+- Suspected `@openora/*` core bug surfaced by the deploy -> report upstream against the OSS repo; do not patch core.
+
+## Rules
+
+- Never modify `@openora/*` source (not in `node_modules/**`, not in the linked checkout).
+- Prefer the operator's existing deploy tool; stay declarative where it supports it and avoid out-of-band mutations that cause drift. Read-only inspection of cloud state is always fine.
+- Treat a `stage` deploy as outward-facing - confirm before applying.
+- Never print or commit secrets; they live in the target's secret store, not in code or images.
+- Don't commit unless asked. Don't push without confirmation. ASCII only; short dashes.