Code Review — Open Mercato extension

This file extends the shared om-code-review skill from open-mercato/skills (installed at .agents/skills/om-code-review/SKILL.md). Follow the shared skill's full workflow — config loading, validation gate, checklists, breaking-change gate, output format — with the repo-specific rules below layered on top. The validation commands come from .ai/agentic.config.json; the full repo checklist is .ai/review-checklist.md (wired via the config's reviewChecklist field).

Step 0 — Decide where to run the gate (execute ONCE before any gate command)

Before running any validation.commands gate, pick the runner (Docker vs local) using the probe order documented in root AGENTS.md § Validation Commands — honor DOCKER_COMPOSE_FILE first, then probe starters/docker/compose.*dev*.local.yml (sorted), legacy root docker-compose.*dev*.local.yml (sorted), starters/docker/compose.fullapp.dev.yml, starters/docker/compose.fullapp.yml with docker compose --project-directory . -f <file> ps --status running -q app, and in Docker mode map each yarn X to node scripts/docker-exec.mjs X. Record the chosen runner in the review output (e.g. Runner: docker (starters/docker/compose.fullapp.dev.yml) or Runner: local). Never silently fall through to the production compose profile on a parse error — log and try the next candidate.

The same Step 0 applies wherever the validation gate runs (om-check-and-commit, om-auto-create-pr, om-implement-spec, om-smart-test).

Gate-order note: run yarn typecheck and yarn test in parallel (they are independent); the second yarn build:packages run exists to rebuild with the files yarn generate produced.

Template parity gate

After the validation gate, run yarn template:sync. If drift is reported (especially app layout/routes between apps/mercato/src/{app,modules} and packages/create-app/template/src/{app,modules}), ask the user whether to sync now; if approved, run yarn template:sync:fix and include the synced files in the change.

Scope classification (Open Mercato layers)

Classify each changed file by Open Mercato layer: API route, entity, validator, backend page, frontend page, subscriber, worker, command, search config, setup, ACL, events, DI, widget, test. Then read the AGENTS.md of each touched module/package — the task-routing table in the root AGENTS.md maps layers to the files that govern them.

Context sources

• .ai/specs/ — check for active specs on the touched modules; flag divergence from an active spec.
• .ai/lessons.md — scan the tagged index by affected module/area/topic, open only matching lesson records, and treat those documented lessons as review rules.
• BACKWARD_COMPATIBILITY.md — protected contract surfaces (the shared skill already enforces this; violations are Critical).

Frontend performance gate

The shared skill's UI Performance Gate applies with these Open Mercato specifics: run yarn check:client-boundaries when the diff touches web routes, providers, or the app shell (the "use client" boundary ledger — see the Frontend Architecture Contract at .ai/skills/om-spec-writing/references/frontend-architecture-contract.md); watch for backend pages that turn server components into client components, route entry points that import heavy editors/calendars/graphs eagerly instead of dynamic islands, and global providers importing route-specific SDKs. om-ds-guardian and om-backend-ui-design (local skills) define the DS/UI conventions the diff must follow.

Release lines and backports

Policy: .ai/docs/pr-workflow.md § Release lines and backports. Report as blocker: a hand-edited version in any workspace manifest, a hand-edited released # X.Y.Z CHANGELOG.md entry, a feature or refactor labelled backport release/v*, or a hand-written PR that targets release/v* directly — except PRs opened by the Backport workflow (labelled backport) and a can't-wait hotfix carrying backport main. For a PR whose base is release/vX.Y.x, review the diff against that line's code rather than main's — a clean cherry-pick into a different context is the dangerous case. Flag (as minor) a priority-high/priority-extreme bug fix or security fix that touches code which already exists on the newest line without a backport release/vX.Y.x label.

Release-note labels

Policy and the change → label table: .ai/docs/pr-workflow.md § Release-note labels. Every review checks that the PR carries exactly the category label(s) its change calls for — or skip-changelog for release and branch bookkeeping — and that the title reads as a release-note line. When the review runs with label permission (om-auto-review-pr), it fixes a missing or wrong category itself and records it in the review report; it never requests changes for labels alone. When it cannot write labels, it reports the expected label as a minor finding so a maintainer applies it before merge.

Severity taxonomy

This repo historically reports findings as Critical / High / Medium / Low; the shared skill uses blocker / major / minor / nit. They map 1:1 in that order. Use the shared skill's labels in the verdict (callers consume blocker/major) and classify by these repo rules: