@openora/create 0.4.1-canary.34 → 0.4.1-canary.35

package/template/__dot__rulesync/rules/oss-boundaries.md

@@ -0,0 +1,31 @@
+---
+root: false
+targets:
+  - '*'
+globs:
+  - '**/*'
+description: OSS core is read-only; enforced import/module boundaries.
+---
+
+# OSS core + import boundaries
+
+## Never modify OSS core
+
+`@openora/*` is a third-party dependency - read it for reference, never write to it.
+
+- Do NOT edit `node_modules/**` or a linked OSS checkout. Those paths are write-denied in `.claude/settings.json`; don't route around it with `sed`, redirection, or scripts. A patched dependency is lost on reinstall and diverges from the published package.
+- Extend from the OUTSIDE only: overlay plugins, adapter rebindings, UI plugins, config.
+- If something can only be fixed in core, STOP and report it upstream (problem, expected behavior, likely location).
+
+## Import boundaries (enforced)
+
+Enforced by `pnpm check:lint` (oxlint, per-edit), `pnpm check:boundaries` (dependency-cruiser, whole graph), the pre-commit hook, CI, and the agent PostToolUse hook. Fix the import, never work around a violation.
+
+- No deep OSS imports: `@openora/*/src/*` or `/dist/*` - import only the published entrypoint or subpath export.
+- No deep imports into your own shared packages - only the barrel/index entrypoint.
+- No app-to-app imports (`apps/api` <-> `apps/web` <-> `apps/backoffice`) - extract shared code to `packages/*`.
+- No cross-module imports inside an app - go through the module barrel, a query invalidation, or a domain event.
+- No overlay-to-overlay imports - couple via a command port, a domain event, or a shared contract.
+- No import cycles.
+
+`pnpm check:boundaries:graph` renders the graph (needs Graphviz).

package/template/__dot__rulesync/rules/overview.md

@@ -14,10 +14,17 @@ this repo. Every per-tool instruction file (`AGENTS.md` - shared, also Codex's b
 subagent and command mirrors are generated by
 [rulesync](https://github.com/dyoshikawa/rulesync) from the single source in `.rulesync/`
 (`rules/`, `subagents/`, `commands/`, `mcp.json`). Edit the source under `.rulesync/`, then
-run `pnpm sync:agents`. Do not hand-edit the generated files.
+run `pnpm gen:agents`. Do not hand-edit the generated files.
 
 This repo is a downstream igaming operator built on the OSS platform (`@openora/*`).
 
+Apply every rule file in `.rulesync/rules/`:
+
+- `conventions` - the code standard (naming, types, functions, frontend, module + package structure, errors, testing, git).
+- `oss-boundaries` - OSS core is read-only; enforced import/module boundaries.
+- `db-conventions` - SQL / Drizzle rules for tables an overlay owns.
+- `e2e-conventions` - dual-mode Playwright specs, fixtures, mocks, page objects.
+
 ## HARD RULE: never modify OSS core
 
 `@openora/*` is a third-party dependency - treat it like any published npm package. You may READ it for reference, never write to it.
@@ -72,6 +79,8 @@ Delegate work to these scoped agents - the `start` / `enhance-intent` playbooks
 - `builder` - senior fullstack engineer. Implements overlays, swaps adapters, mounts UI pages.
 - `qa` - writes/runs Playwright E2E tests; triages whether a bug is in OSS core (upstream) or your overlay (local fix).
 - `debugger` - root-causes failures, build-time (Next/Turbopack, tsc, module resolution) and runtime (Chrome DevTools: console/network/DOM). Spawn it whenever something errors or behaves wrong; it finds the cause and routes the fix.
+- `quality-reviewer` - reviews a diff: boundaries, conventions, frontend rules, perf, duplication. Findings only.
+- `security-reviewer` - reviews a diff: authz, secrets/PII, money paths, input validation. Findings only.
 
 This repo consumes OSS core as linked packages - never edit `@openora/*` source. If a bug is in core, report it upstream; extend from the outside via plugins.
 

package/template/__dot__rulesync/skills/add-feature/SKILL.md

@@ -4,7 +4,7 @@ name: add-feature
 description: >
   Deliver a feature end-to-end in this consumer repo. Aggregates context (Jira + Confluence + Slack +
   Google Drive + Notion + local docs + past sessions + codebase), produces an approved plan, then drives
-  delivery by calling sibling skills - create-plugin (build), code-review (review), create-pr (MR) -
+  delivery by calling sibling skills - create-plugin (build), review, create-pr (MR) -
   and create-task for ticket hygiene. Transitions Jira (no comments) and drafts a one-line Slack
   notice. Use on "add feature", "plan <KEY>-XXX", "deliver <KEY>-XXX", or /add-feature [<KEY>-XXX].
   Read-only until the plan is approved; never pushes, transitions Jira, or sends Slack without OK.
@@ -33,7 +33,7 @@ re-implement their work. The platform-core twin is the `/add-feature` skill in t
 - **Read-only until the Step 3 plan is approved.** No edits, commits, pushes, Jira writes, or Slack
   sends before sign-off.
 - Reuse sibling skills, don't reinvent: **create-task** (ticket format), **create-plugin** (build an
-  overlay), **code-review** (review), **create-pr** (MR). Delegate code to subagents.
+  overlay), **review** (review), **create-pr** (MR). Delegate code to subagents.
 
 ## Steps
 
@@ -82,7 +82,7 @@ When implementation starts, transition Jira to In Progress (Step 7 - confirm fir
 
 ### 5. Review + tests
 
-- Run **code-review** on the change set; loop `[BLOCK]`/`[WARN]` fixes back through `builder`.
+- Run **review** on the change set; loop `[BLOCK]`/`[WARN]` fixes back through `builder`.
 - Run `/check` (typecheck + lint). Don't proceed on red.
 - Derive an e2e checklist from the AC (happy path, edge cases, authz negatives, error states), then
   `qa`: write/run the E2E specs, drive `chrome-devtools` on failure.

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

@@ -13,7 +13,7 @@ description: >
 
 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`.
+Domain questions go to `expert` first; review the result with `review`.
 
 ## 1. Classify the seam (ask if unclear)
 
@@ -64,7 +64,7 @@ plugins: [myCustomPspAdapter, walletModule];
 
 - `/check` (typecheck + lint) green.
 - Plugin boots (API health check / `pnpm dev`).
-- Hand to `code-review` before opening an MR.
+- Hand to `review` before opening an MR.
 
 ## Rules
 

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

@@ -31,7 +31,7 @@ If the current branch isn't in the table, target `dev`.
 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.
+   `pnpm check:types && pnpm check: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`)

package/template/__dot__rulesync/skills/create-ui-module/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: create-ui-module
+targets: ['*']
+description: >
+  Create a frontend feature module in apps/backoffice or apps/web following ADR-0001's
+  modular architecture: standard folder shape, co-located locales, DI hooks, pure
+  components, barrel entry, route wiring. Use on "create module", "new feature module",
+  "add a backoffice/web module", "/create-ui-module <app> <name>".
+---
+
+# create-ui-module (consumer)
+
+Scaffold a feature module under `src/modules/<name>/` per ADR-0001 (`docs/adr/0001-modular-architecture.md`). The shape is lint-enforced (`tools/oxlint-module-structure.mjs`: folder structure, `use-` hook naming, kebab-case files, client-component naming). Copy an existing module as the reference - `apps/backoffice/src/modules/roles/` is canonical.
+
+## 1. Resolve input
+
+`<app> <name>` from `$ARGUMENTS` (`backoffice` | `web`, kebab-case name). Ask if missing. Confirm the module doesn't exist and the concern isn't already owned by another module.
+
+## 2. Create the shape
+
+```
+src/modules/<name>/
+  pages/<name>-page.tsx        page entrypoint(s)
+  components/                  presentational only - props in, JSX out
+  hooks/use-<x>.ts             ALL logic/queries/mutations; deps passed as parameters
+  utils/                       local helpers (only if needed)
+  locales/en.json              translation keys
+  locales/index.ts             registration (below)
+  index.ts                     public barrel - the ONLY entry other code may import
+```
+
+`locales/index.ts` pattern (exact):
+
+```ts
+import { registerTranslations } from '@<scope>/ui';
+import en from './en.json';
+
+export const locales = { en };
+export const ns = registerTranslations('<name>', locales);
+```
+
+Components use `useTranslation(ns)`; no hardcoded copy. Non-`en` files mirror `en.json` keys exactly.
+
+## 3. Wire the route
+
+- backoffice: `src/routes/_authed/<name>.tsx` -> `createFileRoute` with `component` imported from `@/modules/<name>` (see `src/routes/_authed/roles.tsx`).
+- web: the App Router page under `app/(shell)/<name>/` imports from `@/modules/<name>`; client components get `'use client'` line 1 + `.client.tsx` suffix.
+
+## 4. Non-negotiables
+
+- No cross-module imports - cross-module effects go through query cache invalidation, never a direct import.
+- Outside code imports ONLY the barrel via `@/modules/<name>`; inside the module use relative paths.
+- Hooks take their clients (oRPC/API) as parameters (see `roles/hooks/use-iam-client-deps.ts`) so they're testable without global mocks.
+- Follow the conventions rule's Frontend + Modular architecture sections (daisyUI, theme tokens, hoisted `styles` const, React Compiler - no manual memo).
+
+## 5. Verify
+
+`/check` green (the structure lint runs inside `pnpm check:lint`); route renders (`pnpm dev`). Hand to `review` before an MR.

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

@@ -0,0 +1,110 @@
+---
+name: review
+targets: ['*']
+description: Multi-agent code review of the working branch against this repo's conventions, OSS-core boundaries, frontend rules, 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", "/review", optionally "--agents N", "--base <ref>", "--fix", "--post" (publish findings to the MR as inline comments + a summary verdict), "--yes" (post without confirming), a GitLab MR number, or paths.
+---
+
+# review
+
+You are the orchestrator: scope the diff, fan out N reviewers across dimensions, dedup findings, report ONE verdict. Report-only unless `--fix`.
+
+Checklist - tick as you go:
+
+```
+- [ ] 1. Parse args (--agents / --base / MR# / paths / --fix / --post / --yes)
+- [ ] 2. Scope the diff; if empty, ask
+- [ ] 3. Collect task context (ticket AC + MR discussion)
+- [ ] 4. Pick applicable dimensions; small diff -> review inline, else spawn reviewers in ONE message
+- [ ] 5. Dedup + apply the evidence gate
+- [ ] 6. Report one verdict (+ apply fixes only if --fix)
+- [ ] 7. Post to the MR as inline comments + summary (only if --post)
+```
+
+## 1. Parse `$ARGUMENTS`
+
+- `--agents N` - parallel reviewers (1-5); default one per applicable dimension.
+- `--base <ref>` - diff base; default `dev`.
+- `<number>` - a GitLab MR: `glab mr diff <n>` for the patch, `glab mr view <n>` for intent.
+- paths - restrict review to those files/dirs.
+- `--fix` - apply BLOCK/WARN fixes after the review; default report-only.
+- `--post` - publish findings to the GitLab MR as inline diff-line comments + a one-line summary verdict (§8). Requires an MR number. Draft-and-confirm by default.
+- `--yes` - with `--post`, skip the confirmation and publish straight away.
+
+## 2. Scope the diff
+
+`git diff <base>...HEAD --name-only`; if empty, fall back to `git status -s`; if still empty, ask. Group changed files by app/package so reviewers and any file-split share the same map. Note the total changed-line count - it picks the mode in §4.
+
+## 2b. Collect task context
+
+Distill everything here into ONE context block of at most ~30 lines; it is the only task context reviewers receive.
+
+- **Ticket.** Extract the BF key from the branch name / MR title. Fetch it (Atlassian MCP or REST) and distill: goal in one line + acceptance criteria as bullets. No key or no access: skip silently.
+- **MR discussion.** If reviewing an MR: `glab mr view <n>` + unresolved discussion threads. Distill to stated intent + open reviewer asks, so the review doesn't repeat or contradict them. No MR: use branch commit subjects as intent.
+- The AC bullets feed the verdict (§7) - a finding "AC not met" needs a specific bullet.
+
+## 3. Ground every reviewer (mandatory)
+
+Each reviewer MUST read the changed code AND the rule docs owning its dimension before judging - never infer behavior from a diff hunk; if a finding depends on a called function, open it. Cite the docs in findings:
+
+- `.claude/rules/conventions.md` - the code standard, incl. the Frontend and Modular-architecture sections (React Compiler, daisyUI, module isolation).
+- `.claude/rules/oss-boundaries.md` - OSS core read-only; enforced import boundaries.
+- `.claude/rules/db-conventions.md` - SQL/Drizzle rules for overlay tables.
+- `.claude/rules/workflow.md` + `.claude/rules/overview.md` - how this repo operates.
+
+## 4. Dimensions
+
+Dimensions and the roster agent that owns each - never `general-purpose`:
+
+1. **Boundaries, conventions, frontend, perf, duplication** - `quality-reviewer` (its prompt carries the full lens checklists; always applicable).
+2. **Security & secrets** - `security-reviewer`; only if overlay routes, adapters, auth/session, env/config, or money-adjacent code changed.
+3. **Operator/domain fit** - `expert`; only if business logic changed AND AC exists to judge against.
+
+**Small-diff fast path (<= 150 changed lines): no subagents.** Read the changed files in the main thread and apply the applicable agents' checklists yourself (they live in `.claude/agents/<name>.md` - skim, don't spawn). This is the common case and costs a fraction of a fan-out.
+
+## 5. Allocate to `--agents N` (large diffs only)
+
+- N unset: one reviewer per applicable dimension.
+- N > dimensions: extras are additional `quality-reviewer` instances split by file group (state the split; never silently drop files).
+- N < dimensions: drop `expert` first, then merge security into quality (say so in the report).
+
+Spawn all reviewers in a SINGLE message (parallel). Pass each: the changed-file list for its dimension (pre-grouped - reviewers never re-scope), the base ref, the §2b context block, and hard caps: read only changed files + immediate callees; max 10 findings; compact `[SEV] file:line - finding - evidence - fix` lines, no prose; do NOT run `/check`/tests.
+
+## 6. Evidence gate (cut false positives)
+
+Every reviewer applies this before returning; re-apply it yourself when synthesizing:
+
+- Every `[BLOCK]`/`[WARN]` cites a concrete `file:line` AND the rule doc violated - otherwise downgrade to `[INFO]` or drop.
+- High-confidence findings only; unsure = downgrade or omit. Few actionable findings beat flooding.
+- No invented runtime failures - state the trigger path or don't raise it.
+- Don't duplicate what tooling enforces (oxlint, the `/check` gate); for a suspected lint/boundary issue say "confirm with `pnpm check:lint`" - flag only what the gates miss.
+
+## 7. Synthesize
+
+Dedup by `file:line`, group by dimension, order BLOCK -> WARN -> INFO. Each line: `[SEV] file:line - finding - evidence - rule cited - fix`. Lead with a one-line summary (counts per severity + verdict); end with **APPROVED** / **CHANGES REQUESTED** + the single most critical finding.
+
+Severities: `[BLOCK]` must fix before merge (core edit, boundary break, authz/secret/PII risk, broken extension wiring); `[WARN]` should fix (convention violation, missing test, weak validation); `[INFO]` FYI / hardening.
+
+If `--fix`: apply BLOCK + WARN fixes in the working tree (smallest diff satisfying the cited rule), run `/check`, report green/red. Leave INFO untouched. Never commit or push.
+
+## 8. Post to the MR (`--post`)
+
+Only when `--post` is set and the target is an MR number. Turns findings into terse review comments: one line each, brief why, backtick every identifier.
+
+Post BLOCK + WARN as inline threads; include INFO only if it maps to a concrete `file:line`. One comment per finding, one line each.
+
+1. **Draft.** Rewrite each finding as a terse comment keyed to its `file:line`. Compose the summary as ONE sentence stating whether the changes block prod/push, e.g. `Not a blocker for push - a few cleanups worth doing.` or `Blocker: BLOCK finding in `x.ts` must be fixed before we push.`
+2. **Confirm.** Show all drafted comments + the summary and stop for approval - UNLESS `--yes`, then skip straight to posting.
+3. **Post inline comments** as positional discussions on the diff. Mechanics + gotchas are in the Notion memory `glab MR inline diff-line comments (positional discussions)` (query the Memories DB) - the short of it:
+   - Diff SHAs from `glab api "projects/consumer%2Fconsumer/merge_requests/<n>" | jq .diff_refs`.
+   - Anchor on the NEW-file line of an added (`+`) line (`git show <src-branch>:<file> | grep -n`).
+   - POST JSON (build with Python `json.dumps` to dodge quoting) to `.../merge_requests/<n>/discussions` with a `position` object; `glab api -H "Content-Type: application/json" ... --input -`. Do NOT use `-f "position[...]"` - nested params silently drop the position.
+   - Verify each response's `.notes[0].position.new_line`; if null it fell back to a general note - delete (`glab api -X DELETE .../notes/<id>`) and retry.
+4. **Post the summary** as one general MR note (`glab mr note <n> -m "<one sentence>"`).
+5. Report back the count posted + the summary verdict. Never resolve threads; never push.
+
+## Constraints
+
+- Reviewers report; only the orchestrator edits, and only under `--fix` (working tree only - no commit, no push).
+- NEVER edit `@openora/*` core or `node_modules`.
+- Every finding cites a rule doc - no ungrounded opinions.
+- Cap at 5 parallel reviewers.

package/template/__dot__rulesync/subagents/debugger.md

@@ -26,7 +26,7 @@ Reproduce deterministically with a build, not the dev server (dev caches aggress
 
 ```bash
 pnpm -C apps/web exec next build   # or apps/backoffice
-pnpm typecheck
+pnpm check:types
 ```
 
 Common consumer-side causes (this stack links `@openora/*` from a sibling checkout):
@@ -35,7 +35,6 @@ Common consumer-side causes (this stack links `@openora/*` from a sibling checko
 | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `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):

package/template/__dot__rulesync/subagents/qa.md

@@ -23,7 +23,7 @@ The OSS platform is headless (API + modules only) - the player app and backoffic
 | Player app | http://localhost:3000 | operator                              |
 | Backoffice | http://localhost:3002 | operator                              |
 
-Seed credentials (after `pnpm seed`): `admin@oss.dev` / `password123`
+Seed credentials (after `pnpm db:seed`): `admin@oss.dev` / `password123`
 
 Confirm actual ports and which UIs exist with the operator - they may have only an API, or a single combined app.
 

package/template/__dot__rulesync/subagents/quality-reviewer.md

@@ -0,0 +1,67 @@
+---
+targets:
+  - '*'
+name: quality-reviewer
+description: >-
+  Code-quality review of changed files: OSS-core boundaries, conventions,
+  frontend rules, performance, duplication, and simplification in a single
+  pass. Findings only, no edits.
+claudecode:
+  model: sonnet
+---
+
+You are a senior code-quality reviewer for this consumer igaming repo (built on `@openora/*` OSS core). One pass over the changed files, several lenses. You are NOT the implementer - findings only, no changes.
+
+## Grounding
+
+- Read `.claude/rules/conventions.md` IN FULL (including the Frontend and Modular-architecture sections) and enforce all of it - the lenses below are high-signal reminders, not the boundary of the review.
+- For import/extension questions, `.claude/rules/oss-boundaries.md`; for overlay tables, `.claude/rules/db-conventions.md`.
+- Where no repo rule covers a problem, judge by established industry practice (algorithmic complexity, DB query patterns, transaction scope, React render behavior, error-handling hygiene) and name the principle in the finding.
+- Library API in doubt (Next, React, Drizzle, Zod, `@openora/*`)? Check current docs via context7/web search - never claim from memory.
+
+## Scope
+
+The orchestrator passes you the base ref and changed-file list - do not re-scope the diff. Read only the changed files plus the immediate callees a finding depends on. If no file list was passed: `git diff origin/dev...HEAD --name-only`.
+
+## Lenses
+
+### OSS boundaries & extension
+
+- [ ] No edits to `@openora/*` core or `node_modules`; extension only via `extensions.config.ts`, overlay plugins, adapters.
+- [ ] No deep imports into core internals - package/subpath entries only.
+- [ ] Overlay talks to platform data via the typed client, events, or read-only `/schema` - never another module's internals.
+
+### Conventions
+
+- [ ] Types inferred from schemas/contracts (`z.infer`, `$inferSelect`) - no hand-written duplicates; derive with `.pick/.omit/.extend`.
+- [ ] Single source of truth for enums (values + schema + type triple); `timestamptz` for datetimes; named-object params over 3+ positionals.
+- [ ] Zero-value comments flagged; missing WHY comments on genuinely surprising code flagged.
+
+### Frontend (`apps/web`, `apps/backoffice`, `packages/ui`)
+
+- [ ] Module isolation per the Modular-architecture rules; no cross-module reach-ins.
+- [ ] React Compiler assumptions hold (Rules of React); server state via the query lib, not raw `useEffect(fetch)`.
+- [ ] daisyUI/styling conventions followed; no one-off design systems.
+
+### Performance
+
+- [ ] No N+1 queries or `await` in a loop that could batch; lists paginate.
+- [ ] No repeated hot-path work computable once; no unbounded reads filtered in JS.
+
+### Duplication & simplification
+
+- [ ] No copy-pasted logic a helper a few files over provides - name the existing helper.
+- [ ] No speculative abstraction (interface-with-one-impl, config for a constant); nested ifs flattenable with early returns; dead code introduced by the change.
+
+## Do NOT flag (false-positive guard)
+
+- Anything lint/CI (`/check`, oxlint) already enforces.
+- Style taste with no rule behind it (import order, naming preference, blank lines).
+- Theoretical performance issues on cold/admin paths with no evidence they matter.
+- Pre-existing code outside the diff, unless the change actively makes it worse.
+- Missing features or scope expansion - review the change, not the roadmap.
+- Speculative hardening or "might need later" abstractions.
+
+## Output
+
+Max 10 findings, highest impact first. Each: `[WARN]`/`[INFO]` `file:line - finding - evidence - rule cited - fix`. Use `[BLOCK]` only for a core edit or boundary break. No prose around the list. End with **PASS** / **CHANGES REQUESTED** + one line on the most impactful finding.

package/template/__dot__rulesync/subagents/security-reviewer.md

@@ -0,0 +1,54 @@
+---
+targets:
+  - '*'
+name: security-reviewer
+description: >-
+  Security review of changed overlay/frontend files for authz, secret/PII,
+  money-path, and input-validation risks in a real-money igaming consumer repo.
+  Findings only, no edits.
+claudecode:
+  model: opus
+---
+
+You are a security reviewer for a real-money igaming consumer repo built on `@openora/*`. Core money/auth logic lives upstream in the platform; you review what the OVERLAY adds: custom routes, adapter swaps, config, and the frontend. Findings only, no changes.
+
+## Grounding
+
+If the orchestrator passed a base ref + changed-file list, use them - do not re-scope the diff. Otherwise: `git diff origin/dev...HEAD --name-only`. Read each changed file plus the immediate callees a finding depends on. Prioritize overlay plugins/routes, adapter implementations (KYC, PSP, notifications), auth/session touchpoints, and anything reading env/secrets.
+
+## Checklist
+
+### Authorization
+
+- [ ] Overlay admin/backoffice routes enforce the platform guard - never a re-implemented role check.
+- [ ] No client-supplied user id trusted for ownership decisions; caller resolved server-side.
+- [ ] Frontend hides UI by role but the API is the enforcement point - flag authz that exists only client-side.
+
+### Money paths
+
+- [ ] Overlay code never mutates balances directly - money flows through platform commands/ports.
+- [ ] Any overlay money-adjacent mutation is idempotent at the data layer (DB guard, not just a key).
+- [ ] Amounts are integer minor units; no float arithmetic on money.
+
+### Secrets & PII
+
+- [ ] Vendor adapter credentials from env/config - never in source, templates, or client bundles.
+- [ ] No PII (email, KYC docs, DOB, payment details) in logs, analytics events, error messages, or client-visible payloads.
+- [ ] Nothing secret leaks into `NEXT_PUBLIC_*` or the browser bundle.
+
+### Input & injection
+
+- [ ] All external input Zod-validated at the boundary (no `z.any()`/`z.unknown()` on a security edge).
+- [ ] No raw SQL string interpolation; no inline `fetch` to vendors - adapters only (auditable egress).
+- [ ] Webhooks from PSP/KYC vendors verify signatures before trusting payloads.
+
+## Do NOT flag (false-positive guard)
+
+- Attack paths you have not traced through the actual code - state the concrete trigger or don't raise it.
+- Platform-core internals (upstream's responsibility) - flag only how the overlay USES them.
+- Code outside the diff, unless the change makes it newly exploitable.
+- Generic hardening wishlists (rate limits everywhere, CSP) with no tie to the changed surface.
+
+## Output
+
+Max 10 findings, most severe first. Each: `[BLOCK]` (exploitable / data leak - file:line, risk, concrete fix) / `[WARN]` (missing defense-in-depth) / `[INFO]` (hardening). End with **PASS** / **CHANGES REQUESTED** + one line on the most severe finding.

package/template/apps/api/package.json.tpl

@@ -7,9 +7,8 @@
     "build": "tsc",
     "dev": "node --import tsx --watch --env-file-if-exists=../../.env src/main.ts",
     "start": "node --import tsx --env-file-if-exists=../../.env src/main.ts",
-    "db:migrate": "node --import tsx --env-file-if-exists=../../.env src/migrate.ts",
     "db:seed": "node --import tsx --env-file-if-exists=../../.env src/seed.ts",
-    "typecheck": "tsc --noEmit"
+    "check:types": "tsc --noEmit"
   },
   "dependencies": {
     "@openora/core": "{{coreVersion}}"

package/template/package.json.tpl

@@ -6,11 +6,11 @@
   "scripts": {
     "dev": "turbo run dev",
     "build": "turbo run build",
-    "typecheck": "turbo run typecheck",
-    "lint": "oxlint .",
-    "sync:agents": "rulesync generate",
+    "check:types": "turbo run check:types",
+    "check:lint": "oxlint .",
+    "gen:agents": "rulesync generate",
     "prepare": "rulesync generate",
-    "db:migrate": "pnpm -F @{{name}}/api db:migrate",
+    "db:migrate": "pnpm -F @{{name}}/api exec openora-migrate",
     "db:seed": "pnpm -F @{{name}}/api db:seed",
     "gen": "turbo gen"
   },

package/template/rulesync.jsonc

@@ -1,6 +1,6 @@
 // rulesync config - single source of truth for all AI-agent instruction files.
 // Source lives in .rulesync/ (rules, subagents, commands, mcp.json).
-// Regenerate with `pnpm sync:agents`; CI checks with `pnpm sync:agents:check`.
+// Regenerate with `pnpm gen:agents`.
 {
   "$schema": "https://github.com/dyoshikawa/rulesync/releases/latest/download/config-schema.json",
 

package/template/turbo/generators/config.ts

@@ -1,2 +1,2 @@
 // To customize, replace this re-export with your own plop config.
-export { default } from '@openora/turbo-generators';
+export { default } from '@openora/core/generators';

package/template/turbo.json

@@ -1,6 +1,7 @@
 {
   "$schema": "https://turbo.build/schema.json",
   "ui": "tui",
+  "globalDependencies": [".oxlintrc.json"],
   "tasks": {
     "build": {
       "dependsOn": ["^build"],
@@ -10,8 +11,19 @@
       "cache": false,
       "persistent": true
     },
-    "typecheck": {
-      "dependsOn": ["^build"]
+    "check:types": {
+      "dependsOn": ["^build"],
+      "outputs": []
+    },
+    "//#check:lint": {
+      "inputs": [
+        "**/*.{ts,tsx,mts,cts,js,mjs,cjs,jsx}",
+        "!.turbo/**",
+        "!**/node_modules/**",
+        "!**/dist/**",
+        "!**/.next/**"
+      ],
+      "outputs": []
     }
   }
 }

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

@@ -1,111 +0,0 @@
----
-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.