@open-mercato/cli 0.6.6-develop.6483.1.b623f50e2b → 0.6.6-develop.6484.1.2d3741fd58

package/dist/agentic/shared/ai/skills/om-prepare-issue/SKILL.md

@@ -1,202 +0,0 @@
----
-name: om-prepare-issue
-description: Capture a feature the user wants built later without building it now. Researches and writes a spec via the om-spec-writing conventions, ships it as a docs-only spec PR against `develop` (reusing om-auto-create-pr mechanics; `skip-qa`, `documentation`), then opens a tracking GitHub issue that links the spec path and the spec PR so the work can be picked up later with om-auto-fix-github or om-implement-spec. Use for "park this idea", "write a spec and an issue for later", "prepare an issue to build X eventually", "spec it out but don't implement yet".
----
-
-# Prepare Issue (deferred work)
-
-Turn a "we want this eventually" brief into durable, actionable backlog without implementing it. The deliverable is three linked artifacts:
-
-1. A **spec** under `.ai/specs/` written to `om-spec-writing` standards.
-2. A **docs-only spec PR** against `develop` that adds only that spec file (`documentation`, `skip-qa`).
-3. A **GitHub issue** to implement the spec, linking both the spec path and the spec PR.
-
-This skill is for **deferred** work. It does NOT implement the feature. If the user wants the feature built now, hand off to `om-auto-create-pr` (free-form task) or `om-implement-spec` (after the spec exists) instead.
-
-This skill reuses the worktree/branch/commit/label discipline of `.ai/skills/om-auto-create-pr/SKILL.md` for the PR, the spec methodology of `.ai/skills/om-spec-writing/SKILL.md` for the spec, and the issue-claim/linking conventions of `.ai/skills/om-auto-fix-github/SKILL.md` for the tracking issue. Read those before deviating.
-
-## Arguments
-
-- `{brief}` (required) — free-form description of the feature to capture. One sentence or several paragraphs.
-- `--slug <kebab-case>` (optional) — override the slug used in the spec filename and branch. Default: derived from the brief.
-- `--enterprise` (optional) — write the spec under `.ai/specs/enterprise/` instead of `.ai/specs/` (commercial scope). Default: OSS scope (`.ai/specs/`).
-- `--priority <low|medium|high|extreme>` (optional) — priority label for the tracking issue. Default: unset (treated as `priority-medium`).
-- `--no-issue` (optional) — write the spec and open the spec PR, but skip issue creation. Use when the user only wants the spec on record.
-- `--force` (optional) — bypass the claim-conflict check when a previous run left a branch or spec file behind.
-
-## Workflow
-
-### 0. Pre-flight and claim
-
-Follow `.ai/skills/om-auto-create-pr/SKILL.md` step 0 verbatim. This is new docs work, so the branch MUST use the `feat/` prefix.
-
-```bash
-CURRENT_USER=$(gh api user --jq '.login')
-DATE=$(date -u +%Y-%m-%d)
-SLUG="{slug-or-derived}"
-SPEC_DIR=".ai/specs"            # or .ai/specs/enterprise when --enterprise
-SPEC_PATH="${SPEC_DIR}/${DATE}-${SLUG}.md"
-BRANCH="feat/prepare-${SLUG}"
-```
-
-A run is **already in progress** when ANY of these is true (treat as re-entry if the current user owns it, otherwise STOP and ask via `AskUserQuestion` unless `--force`):
-
-- A file at `$SPEC_PATH` already exists on `origin/develop` or any remote branch.
-- A remote branch `origin/${BRANCH}` already exists.
-- An open PR already adds `$SPEC_PATH`.
-- An open issue already tracks the same feature (search before creating — see step 5).
-
-### 1. Triage the brief before writing
-
-Read enough context to write a credible spec, not to build it:
-
-- Match the brief to rows in the root `AGENTS.md` Task Router and read every matching guide (module, UI, search, events, etc.).
-- Check `.ai/specs/` and `.ai/specs/enterprise/` for an existing spec covering the same area. If one exists, extend or supersede it instead of duplicating — confirm the direction with the user via `AskUserQuestion`.
-- Skim `.ai/lessons.md`.
-
-Reduce the brief to: goal in one sentence, affected modules/packages, and the rough scope. If a wrong assumption would force a spec rewrite, surface it as an Open Question (see step 2) rather than guessing.
-
-### 2. Write the spec with om-spec-writing
-
-Follow `.ai/skills/om-spec-writing/SKILL.md` end to end. Key points for this skill:
-
-- Create the spec at `$SPEC_PATH` (`{YYYY-MM-DD}-{kebab-title}.md`, `date` UTC). Enterprise scope goes under `.ai/specs/enterprise/`.
-- Start with a **Skeleton Spec** (TLDR + 2-3 key sections). If critical unknowns exist, add a numbered **Open Questions** block right after the TLDR and **STOP** — ask the user before filling in the rest. This is a hard gate; do not invent answers to architecture-blocking questions.
-- After answers land, expand the spec: Problem Statement, Proposed Solution, Phasing (stories), Implementation Plan (testable Steps), and the architectural concerns the `om-spec-writing` lens requires (singular naming, FK-only cross-module links, `organization_id` scoping, undoability, zod validation, encryption maps for sensitive columns, canonical primitives, Design System tokens, Frontend Architecture Contract when UI is touched).
-- The spec MUST include an **integration coverage** section listing the affected API paths and key UI paths the implementer will need to test (root `AGENTS.md` → Documentation and Specifications requires this for every feature).
-- Apply the `om-spec-writing` Spec Checklist and Final Compliance Review before finalizing.
-
-Do NOT write any implementation code, migrations, or module files. The only file this run adds is the spec.
-
-### 3. Isolated worktree, branch, and first commit
-
-Follow `.ai/skills/om-auto-create-pr/SKILL.md` steps 4–5 verbatim. Base is always `develop`. Commit the spec as the first commit, then push.
-
-```bash
-git add "$SPEC_PATH"
-git commit -m "docs(spec): add ${SLUG} spec for deferred implementation"
-git push -u origin "$BRANCH"
-```
-
-If the Open Questions gate in step 2 is still unresolved, do not create the worktree or push — resolve the questions with the user first.
-
-### 4. Open the spec PR
-
-This is a docs-only / spec-only PR. The minimum validation gate is the docs-only gate from `.ai/skills/om-auto-create-pr/SKILL.md` step 7:
-
-- `yarn lint` if it catches markdown/YAML issues.
-- `git diff --check` — no trailing whitespace, no merge markers.
-- A manual re-read of the spec.
-
-Never run the full code gate (`yarn test` / `yarn typecheck` / `yarn build:app`) for a spec-only run.
-
-Open the PR against `develop`:
-
-```bash
-gh pr create --base develop \
-  --title "docs(spec): ${SLUG} — deferred implementation spec" \
-  --body-file <(cat <<'EOF'
-## Goal
-- {one-line feature summary from the brief}
-
-## What this PR adds
-- Spec only: `{SPEC_PATH}`. No implementation, no code, no migrations.
-
-## Why now
-- Captures deferred work as a reviewable spec so it can be implemented later via `om-implement-spec` / `om-auto-fix-github`.
-
-## Tracking issue
-- {issue URL — filled in after step 5, or "see follow-up comment"}
-
-## Backward Compatibility
-- No contract surface changes (spec document only).
-EOF
-)
-```
-
-Apply labels per root `AGENTS.md` PR workflow, each followed by a short explanatory comment (per the `om-auto-create-pr` label-comment rule):
-
-- `review` — "PR is ready for code review."
-- `documentation` — "spec-only deliverable under `.ai/specs/`."
-- `skip-qa` — "spec/docs-only; no customer-facing runtime behavior."
-
-Never add `needs-qa` to a prepare-issue PR — it adds no runtime behavior to exercise.
-
-### 5. Create the tracking issue
-
-Skip this step only when `--no-issue` was passed.
-
-First, avoid duplicates — search for an existing tracking issue:
-
-```bash
-gh issue list --state open --search "${SLUG} in:title,body" --json number,title,url
-```
-
-If a credible duplicate exists, link the spec/PR in a comment on that issue instead of opening a new one, and report which issue you reused.
-
-Otherwise create the issue. It MUST link the spec path and the spec PR, and name the recommended implementer skill so a future run can pick it up:
-
-```bash
-gh issue create \
-  --title "Implement: {feature title}" \
-  --label "feature" \
-  --body-file <(cat <<'EOF'
-## Summary
-- {one-line feature summary from the brief}
-
-## Spec
-- Implementation spec: `{SPEC_PATH}`
-- Spec PR: {spec PR URL}
-
-## How to implement
-- Once the spec PR merges, run `/om-implement-spec {SPEC_PATH}` (multi-phase) or `/om-auto-fix-github {thisIssueNumber}` (smaller scope).
-- Do not start implementation until the spec PR is merged into `develop`.
-
-## Scope notes
-- {affected modules/packages}
-- {non-goals captured in the spec}
-EOF
-)
-```
-
-Label rules for the issue:
-
-- Always add the `feature` category label (or `refactor` / `bug` when the brief is clearly one of those).
-- Add `enterprise` when `--enterprise` was passed.
-- Add a priority label only when `--priority` was passed (`priority-low` / `priority-medium` / `priority-high` / `priority-extreme`); otherwise leave priority unset (treated as `priority-medium`).
-- Do NOT add pipeline labels (`review`, `qa`, `merge-queue`, …) to the issue — those are PR-only.
-
-### 6. Cross-link the artifacts
-
-Make the three artifacts point at each other so the trail is navigable:
-
-- Edit the spec PR body (or post a comment) so the `Tracking issue` line resolves to the real issue URL.
-- The issue already links the spec path and spec PR from step 5.
-- Optionally add a one-line reference to the issue at the top of the spec (e.g. `Tracking issue: #{n}`), committed and pushed to the PR branch.
-
-### 7. Cleanup and report back
-
-Clean up any worktree you created (per `.ai/skills/om-auto-create-pr/SKILL.md` step 13). Then report:
-
-```text
-prepare-issue: {brief}
-Spec: {SPEC_PATH}
-Spec PR: {url}
-Tracking issue: {url | skipped (--no-issue) | reused #{n}}
-Branch: {branch}
-Status: {spec-and-issue ready | open-questions pending — answer to continue}
-```
-
-If the Open Questions gate is still pending, say so explicitly and list the unanswered questions — do not claim the spec is complete.
-
-## Rules
-
-- This skill captures deferred work only. NEVER implement the feature, write module code, or run migrations. The only file added is the spec.
-- Always write the spec with `om-spec-writing` standards, including the Open Questions hard gate and the integration-coverage section.
-- The spec PR is docs-only: run only the docs-only validation gate, never the full code gate.
-- Spec PR labels are `review`, `documentation`, `skip-qa` — never `needs-qa`. Post a short comment after each label.
-- Base branch is always `develop`. Branch uses the `feat/prepare-<slug>` prefix; never `codex/`.
-- The tracking issue MUST link the spec path and the spec PR, and name the recommended implementer skill (`om-implement-spec` / `om-auto-fix-github`).
-- Search for an existing tracking issue before creating a new one; reuse via comment if a credible duplicate exists.
-- Respect existing claims/locks per `om-auto-create-pr` step 0 and `om-auto-fix-github` step 0; never silently clobber another actor's branch, spec file, or issue.
-- Never paste secrets, tokens, or `.env` content into the spec, PR, or issue.

package/dist/agentic/shared/ai/skills/om-spec-writing/SKILL.md

@@ -1,85 +0,0 @@
----
-name: om-spec-writing
-description: Guide for creating high-quality specifications for {{PROJECT_NAME}}. Use when starting a new SPEC or reviewing specs against architectural standards.
----
-
-# Spec Writing & Review
-
-Design and review specifications (SPECs) against Open Mercato architecture and quality rules.
-
-## Workflow
-
-1. **Load Context**: Read `AGENTS.md` for module conventions and `.ai/specs/` for existing specs.
-2. **Initialize**: Create `{date}-{title}.md` in `.ai/specs/`.
-3. **Start Minimal**: Write a Skeleton Spec (TLDR + 2-3 key sections). Do NOT write the full spec in one pass.
-   - Scan for **critical unknowns** — decisions that block data model, scope, or architecture.
-   - If unknowns exist, add a numbered **Open Questions** block (`Q1`, `Q2`, …) after the TLDR.
-   - **STOP after presenting the skeleton.** Do not proceed until the user answers all questions.
-4. **Iterate**: Apply answers, remove Open Questions block. Repeat if new unknowns surface.
-5. **Research**: Challenge requirements against open-source market leaders.
-6. **Design**: Create architecture, data models, API contracts.
-7. **Implementation Breakdown**: Break into **Phases** (stories) and **Steps** (testable tasks).
-8. **Review**: Apply the [Spec Checklist](references/spec-checklist.md).
-9. **Output**: Finalize the specification file.
-
-## Output Formats
-
-### 1. New Specification
-
-Use the [Specification Template](references/spec-template.md). Adapt if needed, but ensure core concerns are addressed.
-
-**Required sections**: TLDR, Problem Statement, Proposed Solution, Data Models, API Contracts, Risks, Changelog.
-
-### 2. Architectural Review
-
-```markdown
-# Architectural Review: {SPEC-0XX: Title}
-
-## Summary
-{1-3 sentences: what the spec proposes and overall health}
-
-## Findings
-
-### Critical
-{Cross-module ORM, tenant isolation leaks, missing auth guards}
-
-### High
-{Missing undo logic, incorrect module placement, missing phase strategy}
-
-### Medium
-{Missing failure scenarios, inconsistent terminology}
-
-### Low
-{Style suggestions, nits}
-```
-
-## Review Heuristics
-
-1. **Command Graph vs. Independent Ops**: Graph Save (coupled calculation) or Compound Command (independent steps)?
-2. **Architectural Diff**: Cut standard CRUD noise. Focus on what's unique.
-3. **Singularity Law**: Singular naming for entities, commands, events, feature IDs.
-4. **Undo Contract**: Is the "Undo" logic as detailed as the "Execute"?
-5. **Module Isolation**: Using Event Bus for side effects or cheating with direct imports?
-6. **Canonical Mechanisms**: Does the spec reach for the framework primitives (`makeCrudRoute`, `<CrudForm>`, `<DataTable>`, `apiCall` / `useGuardedMutation`, DI-resolved cache, `createModuleEvents`) or invent its own substitute? See `AGENTS.md` → **Mandatory Module Mechanisms** for the full canon and links. No raw `fetch`, no raw `<form>`, no `new Redis(...)`, no manual cross-module ORM joins.
-7. **Sensitive Data**: For every PII / GDPR / address / contact / free-text-about-people / integration-credential column the spec proposes, does it declare an `encryption.ts` `defaultEncryptionMaps` entry and route reads through `findWithDecryption`? See `AGENTS.md` → CRITICAL Rule #11 (Encryption maps) + the "Encryption maps for sensitive data" row of the Mandatory Module Mechanisms table and `.ai/skills/om-data-model-design/SKILL.md` § Sensitive Data and Encryption Maps. No hand-rolled AES, no `crypto.subtle`, no "TODO encrypt later".
-8. **Design System**: Does every UI mock / className snippet in the spec match the DS canon — semantic status tokens (no `text-red-*` / `bg-green-*`), Tailwind text scale (no `text-[11px]` / `text-[13px]`), shared primitives (`StatusBadge`, `Alert`, `FormField`, `SectionHeader`, `CollapsibleSection`, `LoadingMessage` / `Spinner` / `DataLoader`, `EmptyState`), lucide-react icons in page body (never inline `<svg>`), dialog `Cmd/Ctrl+Enter` submit + `Escape` cancel, `aria-label` on every icon-only button? See `AGENTS.md` → CRITICAL Rule #10 (Strict Design System alignment for every UI change) and `.ai/skills/om-backend-ui-design/SKILL.md`. Specs that touch existing pages MUST honour the Boy Scout rule.
-
-## Quick Rule Reference
-
-- **Singular naming** for entities, commands, events, feature IDs.
-- **FK IDs only** for cross-module links — no ORM relationships.
-- **`organization_id`** is mandatory for all tenant-scoped entities.
-- **Undoability** is the default for state changes.
-- **Zod validation** for all API inputs.
-- **Encryption maps** for every sensitive / GDPR-relevant column (declare in `<module>/encryption.ts`, read via `findWithDecryption`) — see `AGENTS.md` → Data Encryption.
-- **Canonical primitives** for CRUD APIs (`makeCrudRoute`), backend forms (`CrudForm`), tables (`DataTable`), HTTP (`apiCall` — never raw `fetch`), non-`CrudForm` writes (`useGuardedMutation`), cache (DI-resolved `@open-mercato/cache`), events (`createModuleEvents`) — see `AGENTS.md` → Mandatory Module Mechanisms.
-- **Design System** tokens and shared UI primitives — no hardcoded status colors, no arbitrary text sizes, no inline `<svg>` in page-body UI. See `AGENTS.md` → Design System.
-
-## Reference Materials
-
-- [Spec Template](references/spec-template.md)
-- [Spec Checklist](references/spec-checklist.md) — § 3 covers encryption maps; § 5 covers canonical mechanisms + DS
-- [AGENTS.md](../../../AGENTS.md) — Mandatory Module Mechanisms table; CRITICAL Rule #10 (Design System); CRITICAL Rule #11 (Encryption maps)
-- [`.ai/skills/om-data-model-design/SKILL.md`](../om-data-model-design/SKILL.md) → Sensitive Data and Encryption Maps
-- [`.ai/skills/om-module-scaffold/SKILL.md`](../om-module-scaffold/SKILL.md) → Encryption maps
-- [`.ai/skills/om-backend-ui-design/SKILL.md`](../om-backend-ui-design/SKILL.md) — DS-compliant pages

package/dist/agentic/shared/ai/skills/om-spec-writing/references/spec-checklist.md

@@ -1,67 +0,0 @@
-# Spec Review Checklist
-
-Every item must be answered in the spec or marked N/A with justification.
-
-## 1. Design Logic & Phasing
-
-- [ ] TLDR defines scope, value, and clear boundaries
-- [ ] MVP is explicit; future work is deferred and labeled
-- [ ] User stories map to API/data/UI sections
-- [ ] Phase plan is testable and incrementally deliverable
-
-## 2. Architecture & Module Isolation
-
-- [ ] Cross-module links use FK IDs only (no direct ORM relations)
-- [ ] Tenant isolation and `organization_id` scoping are explicit
-- [ ] Module placement is in `src/modules/<id>/`
-- [ ] DI usage is specified (Awilix)
-- [ ] Event/subscriber boundaries are clear and non-circular
-
-## 3. Data Integrity & Security
-
-- [ ] Entities include `id`, `organization_id`, `tenant_id`, `created_at`, `updated_at`, `deleted_at`, `is_active`
-- [ ] Write operations define transaction boundaries — specs touching multi-phase scalar + relation writes MUST name `withAtomicFlush({ transaction: true })` and declare that cache invalidation / side effects (`emitCrudSideEffects`) fire AFTER commit (outside the flush block)
-- [ ] Input validation uses zod schemas
-- [ ] All user input validated before business logic/persistence
-- [ ] Auth guards declared per-method in `metadata` (`requireAuth`, `requireFeatures`) — never legacy top-level `export const requireAuth`
-- [ ] Tenant isolation: every scoped query filters by `organization_id` (and `tenant_id` where applicable)
-- [ ] **Encryption maps mechanism is used (no hand-rolled crypto).** For every PII / GDPR-relevant column the spec proposes — names, addresses, contacts, free-text notes about people, integration credentials, secrets, document numbers — the spec MUST declare them in a module-level `<module>/encryption.ts` exporting `defaultEncryptionMaps: ModuleEncryptionMap[]` (type from `@open-mercato/shared/modules/encryption`). Reads MUST go through `findWithDecryption` / `findOneWithDecryption` (5-arg `(em, entity, where, options?, scope?)`) from `@open-mercato/shared/lib/encryption/find`. Equality-lookup columns (e.g. login email) declare a sibling `hashField`. No `crypto.subtle`, no custom KMS calls, no "TODO encrypt later". See `AGENTS.md` → CRITICAL Rule #11 (Encryption maps) + the "Encryption maps for sensitive data" row of the Mandatory Module Mechanisms table; `.ai/skills/om-data-model-design/SKILL.md` § Sensitive Data and Encryption Maps.
-
-## 4. Commands, Events & Naming
-
-- [ ] Naming is singular and consistent
-- [ ] All mutations are commands with undo logic
-- [ ] Events declared in `<module>/events.ts` via `createModuleEvents({ moduleId, events } as const)` before emitting; cross-module side effects use `subscribers/*.ts`, never direct cross-module imports
-- [ ] Side-effect reversibility is documented
-
-## 5. API & UI — Canonical Mechanisms
-
-- [ ] API contracts are complete (request/response/errors)
-- [ ] Routes include `openApi` expectations
-- [ ] **Canonical mechanisms — no DIY substitutes.** The spec MUST reach for the framework primitives, not invent its own. See `AGENTS.md` → **Mandatory Module Mechanisms**.
-  - [ ] **CRUD APIs** use `makeCrudRoute({ entity, entityId, operations, schema, indexer: { entityType } })` from `@open-mercato/shared/lib/crud/factory`. Custom write routes use the mutation guard registry: map the route to `create`/`update`/`delete` (action endpoints usually `update`), collect registered guards, append `bridgeLegacyGuard(container)` when present, call `runMutationGuards(...)` with `{ userFeatures }` before mutation, merge `modifiedPayload`, and run returned `afterSuccessCallbacks` after while catching/logging callback failures.
-  - [ ] **API route files export `metadata`** with per-method `requireAuth` / `requireFeatures` (no top-level `export const requireAuth`).
-  - [ ] **Backend forms** use `<CrudForm>` from `@open-mercato/ui/backend/CrudForm` with helpers `createCrud` / `updateCrud` / `deleteCrud` from `@open-mercato/ui/backend/utils/crud`, throwing `createCrudFormError` from `@open-mercato/ui/backend/utils/serverErrors` for field-level errors. No raw `<form>`, no raw `fetch`.
-  - [ ] **Lists** use `<DataTable entityId apiPath columns />` from `@open-mercato/ui/backend/DataTable` with stable `entityId` / `extensionTableId` so widget injection (columns / row actions / bulk actions / filters / toolbar) keeps working.
-  - [ ] **HTTP clients** use `apiCall` / `apiCallOrThrow` / `readApiResultOrThrow` from `@open-mercato/ui/backend/utils/apiCall` — never raw `fetch`.
-  - [ ] **Non-`CrudForm` writes** are wrapped in `useGuardedMutation(...).runMutation(...)` and pass `retryLastMutation` in the injection context.
-  - [ ] **Cache** is resolved via DI (`container.resolve('cache')`) — never `new Redis(...)` or raw SQLite. Tags include `tenant:<id>` / `org:<id>`.
-- [ ] **Design System compliance for every UI mock and className snippet in the spec.** See `AGENTS.md` → CRITICAL Rule #10 (Strict Design System alignment) and `.ai/skills/om-backend-ui-design/SKILL.md`.
-  - [ ] Use semantic status tokens (`text-status-error-text`, `bg-status-success-bg`, `border-status-warning-border`, `text-status-info-icon`, `text-destructive`, `bg-destructive`) — NEVER hardcoded shades like `text-red-500`, `bg-green-100`, `text-amber-*`, `text-emerald-*`, `bg-blue-*`. Status tokens already cover dark mode; no `dark:` overrides.
-  - [ ] Use the Tailwind text scale (`text-xs` 12, `text-sm` 14, `text-base` 16, `text-lg` 18, `text-xl` 20, `text-2xl` 24) or `text-overline` for 11px uppercase labels — NEVER arbitrary sizes (`text-[11px]`, `text-[13px]`, `text-[15px]`, `p-[13px]`, `rounded-[24px]`, `z-[9999]`).
-  - [ ] Use shared primitives instead of raw HTML: `<Alert variant=...>` for inline status, `flash('msg', 'success|error|warning|info')` for toasts, `useConfirmDialog()` for destructive confirmations, `<StatusBadge>` for entity status, `<FormField label error>` to wrap form inputs, `<SectionHeader title count action>` for section headers, `<CollapsibleSection>` for collapsible regions, `<LoadingMessage>` / `<Spinner>` / `<DataLoader>` for async states, `<EmptyState>` (or DataTable `emptyState` prop) for empty lists.
-  - [ ] Use lucide-react icons in PAGE BODY UI (`Page`, `DataTable`, `CrudForm`, cards, buttons) — never inline `<svg>`. Sizes from the `size-{3|4|5|6}` scale; `strokeWidth` is not overridden per-instance. `page.meta.ts` icons follow the `React.createElement('svg', …)` pattern.
-  - [ ] Every dialog supports `Cmd/Ctrl+Enter` to submit and `Escape` to cancel.
-  - [ ] Every icon-only button has an `aria-label`.
-  - [ ] Boy Scout rule: when the spec edits an existing page, any line touched gets migrated to semantic tokens / DS scale.
-- [ ] i18n keys are planned for user-facing strings (`useT()` client-side, `resolveTranslations()` server-side; never hard-coded labels)
-- [ ] Pagination limits defined (`pageSize <= 100`)
-
-## 6. Risks & Anti-Patterns
-
-- [ ] Risks include concrete scenarios with severity and mitigation
-- [ ] Blast radius and detection described
-- [ ] Does not introduce cross-module ORM links
-- [ ] Does not skip undoability for state changes
-- [ ] Does not mix MVP with speculative future phases
-- [ ] Does not introduce hand-rolled AES, raw `fetch`, raw `<form>`, `new Redis(...)`, or arbitrary Tailwind sizes / status colors

package/dist/agentic/shared/ai/skills/om-spec-writing/references/spec-template.md

@@ -1,86 +0,0 @@
-# {Title}
-
-**Date**: {YYYY-MM-DD}
-**Status**: Draft
-
-## TLDR
-
-**Key Points:**
-- [What is being built — 1-2 sentences]
-- [Primary goal / value proposition]
-
-**Scope:**
-- [Feature 1]
-- [Feature 2]
-
-## Open Questions *(remove before finalizing)*
-
-- **Q1**: [Critical unknown — e.g. "Should this store data per-tenant or globally?"]
-- **Q2**: [Critical unknown — e.g. "Does this replace X or coexist with it?"]
-
----
-
-## Overview
-
-[What this feature does and why. Target audience and key benefits.]
-
-> **Market Reference**: [Name the open-source leader you studied. What did you adopt vs. reject?]
-
-## Problem Statement
-
-[Specific pain points or gaps this solves.]
-
-## Proposed Solution
-
-[High-level technical approach.]
-
-### Design Decisions (Optional)
-
-| Decision | Rationale |
-|----------|-----------|
-| [Choice] | [Why this over alternatives] |
-
-## User Stories
-
-- **[User]** wants to **[Action]** so that **[Benefit]**
-
-## Data Models
-
-### [Entity Name] (Singular)
-
-- `id`: string (UUID)
-- `organization_id`: string (FK)
-- `created_at`: Date
-- `updated_at`: Date
-- ...
-
-## API Contracts
-
-### [Endpoint Name]
-
-- `METHOD /api/path`
-- Request: `{...}`
-- Response: `{...}`
-
-## Implementation Plan
-
-### Phase 1: [Name]
-
-1. [Step — testable]
-2. [Step — testable]
-
-### Phase 2: [Name]
-
-1. [Step]
-
-## Risks
-
-| Risk | Severity | Mitigation | Residual |
-|------|----------|------------|----------|
-| [What goes wrong] | High/Med/Low | [How addressed] | [What remains] |
-
-## Changelog
-
-| Date | Change |
-|------|--------|
-| {date} | Initial spec |