@openora/create 0.4.1-canary.31 → 0.4.1-canary.310

package/template/__dot__rulesync/rules/e2e-conventions.md

@@ -0,0 +1,52 @@
+---
+root: false
+targets:
+  - '*'
+globs:
+  - 'apps/e2e/**'
+description: Playwright E2E conventions - specs run against the real stack; mocking is a narrow, justified exception.
+---
+
+# E2E conventions (`apps/e2e`)
+
+Applies once this repo has an `apps/e2e` Playwright suite; a repo without one is not covered by this rule, and adding the suite is what turns it on.
+
+This file governs **how** a spec is written. A feature or fix PR ships its specs in the same branch as the change, after the manual verification pass (`docs/standards/testing.md`).
+
+Two kinds of spec live here:
+
+- **Browser specs** (`tests/<app>/**`) - a player or admin journey through the UI.
+- **API specs** (`tests/api/**`) - the `api` Playwright project: no browser, no `page`. Drives the real API over HTTP against real Postgres, with each external vendor replaced by a stub HTTP server the API is pointed at by env. This is the tier that proves an overlay end to end: request -> route -> service -> rows -> webhook -> resulting state. `USE_MOCKS` does not apply here at all.
+
+## Real stack by default
+
+Every spec runs against the real seeded stack - API, Postgres, and the apps under test - and that
+run is what blocks merge. A test that never executes the backend cannot tell you the backend works.
+
+`USE_MOCKS=true` intercepts responses in the browser and exists only for a state you cannot produce
+for real: a third-party widget or redirect you are not allowed to run in CI. It is an exception you
+justify per spec, never the mode a suite is written for. Anything reachable by seeding data or by
+scripting a vendor stub is NOT such a state - script the stub instead, and prefer the API tier when
+the behaviour under test is the backend's.
+
+Existing mocked specs are converted as they are touched; delete the fixture with the last spec that
+used it.
+
+## Rules
+
+- Import `test`/`expect` from `fixtures.ts`, NEVER from `@playwright/test` - fixtures add `cleanup()` and shared setup.
+- Set up state through the product: seed data or drive the API, so the spec exercises the same path a player would. `mockApi(page, routes)` (from `lib/mocks.ts`) is the escape hatch above - reach for it only after the real setup is genuinely impossible, and never branch test logic on the mode.
+- A mock that stays is typed: fixture shapes in `mocks/<domain>.ts` mirror the response contract - type platform-endpoint fixtures with the `z.infer` contract type from `@openora/*` so a contract change fails typecheck. No loose hand-written JSON.
+- Selectors use `data-testid` - kebab-case, domain-prefixed (`chat-message`, `chat-input`). Never assert on CSS classes or component-library structure; shared UI components spread props so `data-testid` passes through.
+- Page objects in `pages/<name>.page.ts` are functional factories - no classes, no `this`; locators + actions returned as a plain object.
+- Test names are behavioural: "shows masked standings", not "table renders".
+- `cleanup(fn)` reverses any data a test creates (runs in reverse order) - the suite shares one database, so a spec that leaks rows breaks the next one.
+- Layout: `tests/<app>/<domain>/<scenario>.spec.ts` (one Playwright project per app, sharing fixtures/mocks/pages; run one with `--project=<app>`), `mocks/<domain>.ts`, `pages/<name>.page.ts`.
+
+## API specs (`tests/api/**`)
+
+- Use `request` (Playwright's APIRequestContext), never `page`. Assert status, body, and the state a follow-up request reports - not internals.
+- A vendor stub is a plain `node:http` server under `apps/e2e/`, modelled on `mock-identity-server.mjs`: it answers only the vendor endpoints the flow reaches and records the calls a spec asserts on. Point the API at it with the vendor's base-URL env var; every vendor adapter must accept one.
+- Drive the vendor's inbound side the way the vendor does - post the real webhook shape to the real route with a signature the stub's key material produces. Never call the adapter directly.
+- Own your data: create the player the spec needs and reverse it with `cleanup(fn)`. The suite shares one database.
+- Layout: `tests/api/<domain>/<scenario>.spec.ts`.

package/template/__dot__rulesync/rules/frontend-conventions.md.tpl

@@ -0,0 +1,35 @@
+---
+root: false
+targets:
+  - '*'
+globs:
+  - 'apps/web/**'
+  - 'apps/backoffice/**'
+  - 'packages/ui/**'
+description: React/UI conventions (component library, theming, i18n, permission gating, modular architecture) for apps/web, apps/backoffice, packages/ui - applies once those apps exist; full detail in docs/standards/frontend.md.
+---
+
+# Frontend conventions
+
+Applies once this repo has UI apps (`apps/web`, `apps/backoffice`, `packages/ui`); an api-only repo has none of those paths and this rule is inert there.
+
+UI-specific rules for `apps/web`, `apps/backoffice`, and `packages/ui`. Stack-agnostic rules (naming, types, functions, comments, errors, testing, git) live in `conventions`. Styling, i18n, and the modular architecture are specified in `docs/standards/frontend.md` - read it before touching a component, page, or module. The rules below are the ones that file does not state.
+
+## Component library
+
+- `{{scope}}/ui` is the component library: compose from its primitives (`Button`, `Dialog`, `Select`, `Switch`, `Tabs`, `Badge`, ...) plus utility classes on the theme tokens. Don't hand-roll what a primitive already provides; a genuinely missing one is added to `packages/ui/src/primitives/`.
+- Theme tokens and CSS variables are declared once in `packages/ui/themes.css`; `cn()` and `registerTranslations()` come from the `{{scope}}/ui` barrel - never deep-import.
+- `{{scope}}/ui` is consumed pre-built, so the React Compiler exception in `docs/standards/frontend.md` applies to it.
+
+## Permission-gated UI
+
+A page, nav item, tab, panel, or write action gated on a permission must check the exact resource/level the backend route actually asserts (`adminGuard.assert(resource, action)`) - never a looser, unrelated, or merely-plausible resource, and never a coarse "is admin" shortcut. Confirm the check against the route/service being called, not against what reads correctly at a glance.
+
+- Gate at every layer the feature touches, and keep them in agreement: the nav entry, the route guard, the data-fetching hook's `enabled`, and the rendered branch. A mismatch between any two of these reopens the exact bug class this guards against - a request that fires (and 403s) before the UI hides itself, a control shown that fails on click, or a section rendering an empty/failed state instead of disappearing.
+- Thread the permission into the query hook itself (`enabled: Boolean(id) && useHasPermission(resource, level)`), not only into the component that renders it - a hook with no grant check still fires for any caller that forgets the wrapper, including ones added later.
+- A missing or denied permission hides the section outright - never a failed-to-load screen, an empty state standing in for "no access," or a disabled-but-visible control. See `conventions` > Testing: cover the authz-negative for every new gate as part of the same change.
+
+## Modular architecture
+
+- Outer composition code (`src/app/`, `src/routes/`) imports a module only as `@/modules/<name>`; files inside a module use relative paths to siblings.
+- Cross-module communication is query invalidation, never a direct import.

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

@@ -0,0 +1,78 @@
+---
+root: false
+targets:
+  - '*'
+globs:
+  - 'apps/**'
+  - 'packages/**'
+  - 'package.json'
+  - 'pnpm-workspace.yaml'
+description: OSS core is read-only except in an OSS worktree (paired changes); enforced import/module boundaries.
+---
+
+# OSS core + import boundaries
+
+## Never patch OSS core in place
+
+`@openora/*` is a dependency - read it for reference, never patch it where it is installed.
+
+- Do NOT edit `node_modules/**` or the main linked OSS checkout (`{{ossDir}}`). The `guard-core` hook denies those writes in every agent tool; don't route around it with `sed`, redirection, or scripts. A patched dependency is lost on reinstall and diverges from the published package, and other sessions build against the main checkout.
+- Extend from the OUTSIDE first: overlay plugins, adapter rebindings, UI plugins, config.
+
+## Changing OSS core (paired change)
+
+When a fix can only live in core, change it in core - in a git worktree of `{{ossDir}}`, the one OSS path the hook lets you write. Works the same from any agent tool; `docs/agents/cross-repo.md` lists how each tool is granted access to `{{ossDir}}`.
+
+**Scope.** Any core change can be made here, in the worktree: a bug, a missing export or field, a contract alignment, or a new feature or module. Use the `handoff` skill only when the work should run in a separate session rooted in the OSS repo.
+
+**Genericity test - before the first edit.** Core serves every operator, and this session carries this operator's requirements. Write down, for the OSS PR's Why section: why it cannot be an overlay, adapter, or config here, and why another operator would want the same change. If only this operator needs it, core gets only the seam (an adapter token, an event, a config field, a hook) and the behavior stays in this repo. Jurisdiction rules, vendor specifics, and limits or flows only this operator uses never go into core.
+
+1. `pnpm oss:worktree <branch>`, with this repo's branch name: the same name in both repos is how skills pair the two requests. It creates or reuses `{{ossDir}}/.worktrees/<branch, / as +>` and installs its dependencies. `--link` also builds it and points `pnpm link:oss` at it, so this repo runs against the change; rebuild with `pnpm -C <worktree> build` after each core edit.
+2. Before the first edit there, read `<worktree>/AGENTS.md`, every `<worktree>/.rulesync/rules/*.md`, and the `<worktree>/docs/standards/` file for the kind of change. Files in the worktree follow the OSS rules; files in this repo follow this repo's rules. On conflict, the file's location decides.
+3. Review before any push. The OSS repo's own edit hooks (format, lint, typecheck) and its reviewer agents do not run from this session, so do their work yourself: run `pnpm -C <worktree> verify`, then review the worktree diff by `<worktree>/docs/standards/skills/review.md`, applying the checklists in `<worktree>/.rulesync/subagents/contract-reviewer.md` and, for money, auth, KYC, or RG paths, `security-reviewer.md`. Fix every BLOCK, and re-check the genericity test against the final diff.
+4. Commit and open the OSS pull request from the worktree, per `<worktree>/docs/standards/skills/delivery.md`, with its own explicit push confirmation. The OSS repo is public: its commits and PR carry the bare ticket key at most - no operator name, no internal URL, no link to this repo's request, and no ticket text or operator-specific domain detail. Describe the change in generic terms.
+5. Do not link the two requests - the shared branch name pairs them. This repo's request may be read by people outside the team, so it never names or links the OSS repo.
+6. Never `git checkout` a branch in the main `{{ossDir}}` checkout. Remove the worktree with `pnpm oss:worktree <branch> --remove` once both requests have merged.
+
+
+## Import boundaries (enforced)
+
+Enforced by `pnpm check:lint` (oxlint, per-edit), the pre-commit hook, CI, and the agent PostToolUse hook - plus `pnpm check:boundaries` (dependency-cruiser, one graph per app/package via turbo) and `pnpm check:shape` in repos that ship them. Fix the import, never work around a violation.
+
+### Across packages
+
+- No deep OSS imports: `@openora/*/src/*` or `/dist/*` - import only the package entrypoint (oxlint owns this one; every published entrypoint resolves into `dist/`, so the boundary graph cannot tell the two apart).
+- No deep `{{scope}}/ui` imports - only the barrel.
+- No app-to-app imports (`apps/web` <-> `apps/backoffice` <-> `apps/api`) - extract shared code to `packages/*`. Never reach across with a relative `../../apps/` path either.
+- No deep workspace-package imports - only the index entrypoint.
+- No import cycles.
+- A shared package (`packages/*`) must not import from an app.
+- `{{scope}}/ui` is renderer- and router-agnostic: no `next`, no router package. Take the capability through an injected adapter (see `navigation.tsx`).
+- No Node builtins in browser code (the Next instrumentation/proxy entries and `src/lib/api-server.*` are the declared exceptions).
+
+### Inside an app (ADR-0001)
+
+- No cross-module imports; a module is reached only through its barrel `index.ts`.
+- Layering inside a module: `pages/` is the leaf - `components/`, `hooks/`, `utils/` must not import it; `utils/` must not import `components/`, `hooks/` or `pages/`.
+- A file inside a module must not import its own barrel.
+- The shared kernel (`src/lib`, `src/hooks`, `src/utils`, `src/components`) must not import a feature module - dependencies point inwards.
+- Routes are leaves: nothing may import `src/app/**` (web) or `src/routes/**` / `routeTree.gen.ts` (backoffice, except `main.tsx`).
+- Transport clients (`@orpc/client`, `@orpc/openapi-client`, `@orpc/tanstack-query`) are constructed in `src/lib/` only.
+- A `'use client'` file must not import server-only code (`next/headers`, `src/lib/api-server.*`, `*.server.ts`).
+
+### Dependency manifest hygiene
+
+- Every import resolves; every npm package used is declared in that package's own `package.json`; no package sits in two dependency sections (a library's devDependency + peerDependency pair is the exception).
+- Production code imports no devDependency and no test/mock/fixture file.
+
+### Structure checks (`pnpm check:shape`, in repos that ship it)
+
+Runs the checks a dependency graph cannot make, because they are about files that do not exist or edges that do not exist:
+
+- Every module has `index.ts`. An `AGENTS.md` is optional - only for knowledge local to the module that the rules and the code do not show. A `check:shape` that still requires one drops that assertion with this rule, or the gate contradicts it.
+- The barrel re-exports only; the single side effect it may carry is `import './locales'`.
+- Every file under a module's `pages|components|hooks|utils` is reachable from the barrel, and every `packages/ui/src` file from the `{{scope}}/ui` barrel - otherwise it is dead code.
+
+Each app/package owns its own `.dependency-cruiser.cjs` (its own tsconfig for `@/*` alias resolution) built on the shared rule/option helpers in `.dependency-cruiser.shared.cjs`. Where the repo ships `pnpm gen:boundaries-graph`, it renders each package's graph (needs Graphviz).
+
+The shared options keep npm packages in the graph on purpose - a dependency-type rule can only judge a package that is a node - so build output is excluded per workspace path, never as a bare `/dist/`.

package/template/__dot__rulesync/rules/overview.md

@@ -8,85 +8,30 @@ globs:
 
 # Agent instructions
 
-Canonical brief for AI agents (Claude Code, GitHub Copilot, Codex) and humans working on
-this repo. Every per-tool instruction file (`AGENTS.md` - shared, also Codex's brief;
-`CLAUDE.md`; `.github/copilot-instructions.md`) plus Codex's `.codex/config.toml` and the
-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.
+This repo is a downstream igaming operator built on the OSS platform (`@openora/*`). Every per-tool instruction file (`AGENTS.md`, `CLAUDE.md`, `.github/copilot-instructions.md`, `.codex/config.toml`) and the subagent and command mirrors are generated by [rulesync](https://github.com/dyoshikawa/rulesync) from `.rulesync/`. Edit the source, run `pnpm gen:agents`, never hand-edit a generated file.
 
-This repo is a downstream igaming operator built on the OSS platform (`@openora/*`).
+Sibling rules (load on demand; don't reopen settled questions):
 
-## HARD RULE: never modify OSS core
+- `conventions` - the always-on code standard, with a table routing each kind of change to its deep-dive file in `docs/standards/`.
+- `oss-boundaries` - never patch `@openora/*` in place; core changes go through an OSS worktree; enforced import/module boundaries.
+- `e2e-conventions` - Playwright specs against the real stack, fixtures, page objects, API specs.
+- `db-conventions` - SQL / Drizzle rules for the tables an overlay owns.
+- `frontend-conventions` - React/UI rules for the operator's apps and shared UI package.
 
-`@openora/*` is a third-party dependency - treat it like any published npm package. You may READ it for reference, never write to it.
+## Agent files: generated from the template, or owned here
 
-- Do NOT edit anything in `node_modules/**` or in the linked OSS checkout. Edit/Write to those paths is denied in `.claude/settings.json`; do not try to work around it with `sed`, shell redirection, or a script.
-- Locally patching a dependency is an anti-pattern: it is lost on reinstall and diverges from the published package every other operator uses.
-- You extend the platform from the OUTSIDE only - overlay plugins, adapter rebindings, UI plugins, config. Never fork or hand-edit core.
-- If something can only be fixed in core, STOP and report it as an upstream bug/feature request for the OSS repo (describe the problem, expected behavior, where you think it lives). Do not patch it here.
+Most of `.rulesync/` (skills, subagents, commands, hooks, the shared rules) and `docs/standards/` are generated: `pnpm install` renders them from `@openora/create`'s consumer template at the pinned `@openora/*` version, using the variables in `.rulesync/sync.json`. They are gitignored via the managed `synced-agents` block in `.gitignore`, so they never appear in a diff and cannot drift - editing one locally is pointless, the next install overwrites it. Change it upstream in the template instead. This repo owns and tracks the rules and skills the template does not ship, plus the `consumerOwned` overrides in `.rulesync/sync.json`; operator-specific facts belong there or in `sync.json` vars.
 
-## Getting started
+## How you work here
 
-When the user opens Claude Code or asks to build something, call the `start` MCP tool (server: `oss`) and follow the script it returns.
-
-Trigger phrases: "start", "help", "what can I build", "what can I do", "I want to build X", "how do I begin", "getting started".
-
-## Enhance the ask first (pre-step)
-
-Before acting on any non-trivial request - and before delegating to an agent - run the `enhance-prompt` skill on the raw ask: restate the intent, gather scoped context (your tracker / roadmap / team chat / local docs), surface the blocking ambiguities, and produce the brief you actually execute. Skip it only when the ask is already precise. Subagents act on the brief they are handed - they do not re-enhance it.
-
-## How you work here: collect requirements, delegate everything else
-
-Your one human-facing job is to **gather thorough requirements** from the user - interview them (goal, actors, value flow, rules, lifecycle, compliance, UI, edge cases, success criteria, out of scope) until you could hand a stranger a buildable spec. The `start` / `enhance-intent` tools give you the checklist.
-
-Once requirements are confirmed, **delegate the rest to the agents** via the Task tool - you orchestrate, you do not implement feature code yourself:
-
-1. `expert` - formalizes the requirements into acceptance criteria, flags compliance/gaps.
-2. `builder` - implements (`pnpm gen ...`, code, wiring).
-3. `qa` - writes/runs the E2E test against the acceptance criteria.
-
-Only return to the user to resolve genuine decisions they alone can make.
+- Before acting on a non-trivial request, and before delegating, run the `enhance-prompt` skill on the raw ask. Skip it only when the ask is already precise. Subagents act on the brief they are handed; they do not re-enhance it.
+- Your human-facing job is gathering requirements until a stranger could build from them; the `start` / `enhance-intent` MCP tools give the checklist. Then delegate to the subagents (`expert` -> `builder` -> `tester`) and return to the user only for decisions they alone can make.
+- A task that names a ticket key starts by reading the whole ticket per `docs/agents/issue-tracker.md`. Never write to the tracker unless the user asks for that exact write.
+- `pnpm verify` on the committed tree is the gate before a merge/pull request; the `guard-mr` hook refuses to open one until it has passed on HEAD.
 
 ## What this repo is
 
-- `apps/api/` - thin Hono + oRPC API entry, your own `extensions.config.ts`
-- this is a headless api consumer; build your frontend in its own repo and consume the api over HTTP via `@openora/react`
-- `@openora/*` packages are linked from a sibling OSS checkout via `pnpm.overrides`
-
-## How to extend
-
-| What you want                                | Command            |
-| -------------------------------------------- | ------------------ |
-| New behavior / routes                        | `pnpm gen plugin`  |
-| Swap a vendor (payment / KYC / notification) | `pnpm gen adapter` |
-
-Register new plugins in `apps/api/src/extensions.config.ts`. Adapters must be listed AFTER the module that owns the default binding (last registration of a DI token wins).
-
-## Agents (spawn via the Task tool)
-
-Delegate work to these scoped agents - the `start` / `enhance-intent` playbooks tell you when to use each:
-
-- `expert` - turns a fuzzy product ask into requirements + acceptance criteria (jurisdiction rules, player journey). Advisory, writes no code. Use BEFORE building anything non-obvious.
-- `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.
-
-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.
-
-## MCP tools available (server: `oss`)
-
-This server reads the platform CATALOG (not OSS source) - it tells you what exists so you extend without forking. Call these instead of grepping:
-
-- `start` - onboarding flow (call when the user asks what to build)
-- `enhance-intent` - turn a fuzzy ask into a grounded spec + playbook
-- `dev:infra` - start/stop/status docker compose (postgres :5432)
-- `catalog-overview` - START HERE: counts + adapter seams + config fields
-- `list-adapters` - vendor swap seams (interface + token + status)
-- `list-routes [module]` - oRPC route namespaces
-- `list-events` - cross-module domain events you can subscribe to
-- `list-slots` - named UI slots you can fill from a UI plugin
-- `describe-module <name>` - one module's group, tables, routes
-- `schema-get <name>` - locate a Zod contract schema's file
-- `get-config-schema` - the igaming-config fields a consumer can set
+- `apps/api/` - thin Hono + oRPC API entry, your own `extensions.config.ts`.
+- This is a headless API consumer; build your frontend in its own repo and consume the API over HTTP via `@openora/react`.
+- `@openora/*` packages are pinned npm dependencies.
+- New behaviour, a vendor swap or a mounted page: the `create-plugin` skill picks the generator.

package/template/__dot__rulesync/skills/create-plugin/{SKILL.md → SKILL.md.tpl}

@@ -1,19 +1,17 @@
 ---
 name: create-plugin
-
+targets: ['*']
 description: >
-  Guided creation of an extension - the right way to add behavior or swap a vendor without
+  Guided creation of a {{name}} 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
+# create-plugin ({{name}})
 
-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`.
+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 `review`.
 
 ## 1. Classify the seam (ask if unclear)
 
@@ -24,23 +22,17 @@ Domain questions go to `expert` first; review the result with `code-review`.
 | 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.
+If the behavior genuinely cannot be expressed from the outside, STOP - it's an OSS-core change. Hand off via the `ship` skill's `handoff.md`. Never patch `{{ossDir}}`.
 
 ## 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.
+- Read `CLAUDE.md` / `AGENTS.md` (the rendered `overview` rule: what you may and may not touch), `.claude/rules/oss-boundaries.md`, and `.claude/rules/db-conventions.md` + `docs/standards/database.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.
+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
@@ -52,19 +44,16 @@ 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.
+- **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 `docs/standards/database.md` (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.
+- Hand to `review` before opening an MR.
 
 ## Rules
 

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

@@ -0,0 +1,38 @@
+---
+name: create-pr
+targets: ['*']
+description: Commit, push, and open a pull request on this repo's forge, targeting the branch `docs/agents/forge.md` names. Use on "create pr", "create mr", "open a pr/mr", "/create-pr", or "promote <branch>".
+---
+
+# create-pr ({{name}})
+
+`docs/agents/forge.md` is the source of truth for this repo's forge: which CLI to use, how to open and read a pull request, and where a change lands. Read it first - the steps below never hardcode a forge command.
+
+## Steps
+
+1. **Determine source + target.** `git branch --show-current`, then take the target from the "Where a change lands" section of `docs/agents/forge.md`.
+2. **Land the paired OSS change first, if there is one.** It is paired when `{{ossDir}}/.worktrees/<branch, / as +>` exists or `git -C {{ossDir}} branch --list <branch>` matches. First finish step 3 of "Changing OSS core" in the `oss-boundaries` rule (verify, OSS review, no open BLOCK). Then run steps 3-7 inside that worktree under the OSS repo's own delivery rules (`<worktree>/docs/standards/skills/delivery.md`: `gh`, its PR template, `pnpm verify`, public-record rules), with its own explicit push confirmation. Reuse an open OSS PR (`gh pr list --head <branch>` in the worktree).
+3. **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.
+4. **Commit.** Conventional-commit message (`feat:`, `fix:`, `docs:`, `refactor:`, `chore:`); the scope is a commitlint-enum package or app, never the ticket key; for ticket work the key goes at the END of the subject (e.g. `feat(web): add deposit limits ({{trackerKey}}-123)`). No "Co-Authored-By" / "Generated with" trailers.
+5. **Verify the commit.** Run `pnpm verify` on the committed, clean tree: it is the pre-MR gate and records the verified commit. The `guard-mr` hook refuses to open the pull request until that record matches HEAD. Don't push a red tree.
+6. **Push** the current branch - but STOP and get an explicit per-action "yes push" from the user FIRST. The one exception: run by `ship` without `--ask`, the `/ship` invocation is that yes for its ticket branch only. Report the commit SHA, then ask. Invoking this skill is NOT push authorization. Pushing to a shared/env branch (`{{mrTarget}}`, `stage`, `prod`) without that explicit yes is forbidden. Only after the yes: `git push -u origin <current>`.
+7. **Open the pull request** using the command in `docs/agents/forge.md` (only after the push is confirmed and done). Reuse an open request for the same source -> target instead of creating a duplicate, and never delete a long-lived branch on merge.
+8. **Report** the pull-request URL back to the user, and the OSS PR URL when paired.
+
+## Pull-request description
+
+- State the user-facing change and its reason briefly.
+- Add short, reproducible local test steps for the changed behavior (for example, `pnpm dev` then the relevant URLs or user flow).
+- Close the ticket by key at the end: `Closes <KEY>-n` if this PR finishes it, else `Refs <KEY>-n` (see `docs/agents/issue-tracker.md`).
+- Do not include a generic verification-command list: CI already reports those checks.
+- **Attach the manual-verification evidence.** The videos are what a reviewer reads as proof of a user-visible change: one short clip per acceptance criterion, embedded under that criterion, the before/after pair on a fix. A screenshot only where a clip adds nothing, such as a second theme. Upload each file to the forge and embed the markdown it returns - `docs/agents/forge.md` says how (its "Attach evidence" section). A local path under `apps/e2e/test-results/` shows a reviewer nothing; never put one in a description. An API-only change attaches the request/response trace instead. Paste the `tester` pass's verdict table next to it. Skip this only when nothing user-visible changed.
+- **Diagram the flow.** A change that adds or changes a flow across components (a request path through gates and a vendor, a state machine, an async job or webhook, a new module or overlay) embeds a fenced `mermaid` block (`flowchart` or `sequenceDiagram`), right after the summary - GitHub and GitLab both render it. Name nodes as the code does, keep it under ~15 nodes, include the refusal and failure branches. No flow (copy, styling, deps, a one-file fix): no diagram.
+- **End with a "Tests" list** - one line per test this PR adds, drawn from what the manual pass exercised (happy path, the hostile paths, the authz negatives), naming its tier (unit / API E2E / browser E2E) and path. A change that needs none says why in one line.
+- A paired change links neither way: the shared branch name pairs the two requests. The OSS repo is public, so its PR never names this repo or the operator; this request may be read by people outside the team, so it never names or links the OSS repo.
+
+## Rules
+
+- NEVER push without an explicit per-action "yes push" from the user (or `/ship` on its ticket branch, see step 6). Invoking this skill does NOT authorize a push. Report the commit SHA, ask, then push only on yes.
+- `pnpm verify` must pass on the commit you push.
+- Keep the pull request scoped to one concern; split unrelated changes into separate ones.
+- No AI-attribution trailers anywhere - not in the commit, not in the pull-request title or description. No "Generated with", no "Co-Authored-By: Claude", no robot-emoji footer.

package/template/__dot__rulesync/skills/create-task/{SKILL.md → SKILL.md.tpl}

@@ -1,38 +1,33 @@
 ---
 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.
+targets: ['*']
+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 {{trackerKey}}-XXX description work.
 ---
 
-# create-task
+# create-task ({{name}})
 
-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.
+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`)
+- `cloudId`: `{{jiraCloudId}}` (`{{jiraSite}}`)
+- Project key: `{{trackerKey}}` (ticket keys look like `{{trackerKey}}-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.
+- 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**.
+- 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
+## Jira gotchas
 
-- **No markdown checkboxes.** `- [ ]` renders as literal `\[ \]` in Jira. Use plain
-  `-` bullets for task lists and acceptance criteria.
+- **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.
 
@@ -64,14 +59,11 @@ scannable, and free of filler. Use for new tasks and for rewriting bloated ones.
 - <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.
+Infra/DevOps tickets: swap **Scope** for **Provision** (services as bullets) + a **One-time bootstrap** section. 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.
+1. If rewriting: read the issue whole per `docs/agents/issue-tracker.md` (`atlassian-read`; comments and images included) - a rewrite that drops a decision buried in a comment or a screenshot is a regression.
 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.
+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/create-ui-module/SKILL.md.tpl

@@ -0,0 +1,60 @@
+---
+name: create-ui-module
+targets: ['*']
+description: >
+  Create a frontend feature module in apps/backoffice or apps/web following the modular
+  architecture in the `frontend-conventions` rule: 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 ({{name}})
+
+Applies once this repo has UI apps (`apps/web` / `apps/backoffice`); an api-only repo has no `src/modules/` to scaffold into.
+
+Scaffold a feature module under `src/modules/<name>/` per the modular architecture in `frontend-conventions` and `docs/standards/frontend.md`. Where the repo ships a module-structure lint rule, it enforces the shape (folder structure, `use-` hook naming, kebab-case files, client-component naming). Copy an existing module in the same app as the reference.
+
+## 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>`; mirror a sibling route file.
+- 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 via a `use-<domain>-client-deps.ts` hook so they're testable without global mocks.
+- Follow the `frontend-conventions` rule + `docs/standards/frontend.md` (daisyUI, theme tokens, hoisted `styles` const, React Compiler - no manual memo).
+
+## 5. Verify
+
+`/check` green (any structure lint runs inside `pnpm check:lint`); route renders (`pnpm dev`). Hand to `review` before an MR.

package/template/__dot__rulesync/skills/enhance-prompt/{SKILL.md → SKILL.md.tpl}

@@ -3,14 +3,14 @@ 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
+  for orchestration skills and subagents: extract the real intent, gather scoped context (Jira +
+  Confluence + Slack + roadmap + 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
+# enhance-prompt ({{name}})
 
 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.
 
@@ -27,7 +27,7 @@ Match effort to the ask: a small task gets a one-line restatement, not a full br
 
 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.
+3. **Gather scoped context** - targeted, never a data dump (token budget matters). Pull only what changes the plan: Jira + Confluence via `atlassian-read` per `docs/agents/issue-tracker.md` (roadmap + related tickets, specs / decisions - comments and images included), Slack (recent decisions, `slack-reader`), 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.