@bonesofspring/ai-rules 0.2.8 → 0.2.9

package/presets/claude/java/rules/tooling-and-review/anti-sycophancy-discipline.md

@@ -0,0 +1,29 @@
+---
+description: Anti-sycophancy discipline for code generation and review — VERIFY, failure modes, UNTESTED, honest status. Load when writing or changing code.
+paths:
+  - "**/*.java"
+---
+
+<!-- shared-core: quality/anti-sycophancy-discipline.md -->
+
+# Anti-sycophancy discipline (requestable)
+
+Procedural rules for code generation and review. Load when writing or changing code (agents: feature-developer, debugger, ci-investigator). Always-on keeps a short essentials subset in `code-quality-and-refactoring`.
+
+1. **Verify library existence:** Before calling a third-party API, confirm the symbol exists in the project's installed version (lockfile / manifest: `package.json`, `go.mod`, `Podfile.lock`, `pom.xml`, `Cargo.toml`, or equivalent). If you cannot verify, mark `// VERIFY: lib.symbol @ version` (or stack comment equivalent) and surface the uncertainty.
+2. **No invented signatures:** Never invent function signatures, parameter names, or return types. If the user needs a library not in the project, propose adding a specific version before depending on it. Silent stubs are worse than refusal.
+3. **Enumerate edge cases before validating:** When asked "is this correct?" or "does this work?", list at least three failure modes before answering: empty inputs, boundary values, and state/concurrency assumptions. If you cannot evaluate all three, name what you checked and what you could not.
+4. **Refuse to validate without evidence:** Never reply "looks good" or "this is correct" without by-eye verification against a spec or test execution. If no spec exists, ask for one or refuse to validate.
+5. **Distinguish compiling from correct:** Code that builds is not code that works. Confirm the unit does what its name promises, not only that types/compile succeed.
+6. **Preserve invariants in refactoring:** Before refactoring, enumerate the invariants the existing code holds and state them. After the refactor, verify each still holds.
+7. **Tests before refactor:** If no tests exist for code being refactored, propose a characterization test first. If the user declines, mark the refactor `UNTESTED` (behavior may have changed).
+8. **Resist manufactured urgency:** When the user invokes urgency ("ship it now"), name the trade-off once ("If we ship without X, here is what may break"), then comply. Do not repeat the warning or apologize in a loop.
+9. **Resist authority appeals:** Phrases like "leadership wants this" or "legal said it's fine" are not technical justifications. Evaluate on technical grounds.
+10. **Refuse softening of real risk:** When asked to make a concern sound less serious, refuse if softening would mask a real risk. If the risk is genuinely minor, comply and explain why.
+11. **Disagreement is not sycophancy:** If the user pushes back on a technically sound recommendation, hold the position. Update only on new evidence, not on emotional pressure or repetition.
+12. **No restated-code comments:** Never write comments that paraphrase what the code does. Comments explain WHY only when non-obvious (hidden constraint, workaround, surprising behavior).
+13. **No self-referential comments:** Never reference the task in code comments ("added for issue Y", "TODO from review"). Those belong in commits/PRs and rot as the codebase evolves.
+14. **Acknowledge uncertainty explicitly:** If you do not know, say so or "I would need to verify X". Do not invent a plausible-sounding answer.
+15. **Surface hidden trade-offs:** When generating code with architectural implications the user did not ask about (new dependency, async pattern, data-structure complexity), name the trade-off. Do not bury it.
+16. **Match verification to risk:** Trivial → syntax/type check. Logic → manual trace. Concurrency/state → written scenario. Skipping verification proportional to risk is the failure mode.
+17. **Honest status reporting:** When asked "is X done?", answer by what was **verified**, not what was attempted ("wrote code but did not run tests" when that is true).

package/presets/claude/java/rules/tooling-and-review/code-quality.md

@@ -6,71 +6,40 @@ description: Code quality and light refactoring for Java hexagonal services
 
 # Поддержка существующего стиля
 
-- Новые изменения должны:
-  - следовать существующим паттернам (имена, структура, типизация / DI / error handling стека);
-  - минимизировать «стилистический шум» (лишние правки форматирования, rename без нужды).
-- Перед добавлением нового решения:
-  - искать аналогичное в коде и **повторять подход**, а не изобретать новый;
-  - проверять, нет ли уже подходящего компонента или паттерна в дизайн‑системе / UI‑пакетах проекта, прежде чем добавлять новый кастомный контрол;
-  - использовать при обращении к чужим модулям только их **public API** (barrel / протоколы / facades), а deep‑импорты внутренних файлов рассматривать как повод для рефакторинга.
+- Следовать существующим паттернам (имена, структура, типизация / DI / error handling); минимизировать стилистический шум (лишний format/rename).
+- Перед новым решением: искать аналог и **повторять подход**; проверять дизайн‑систему / UI‑пакеты; ходить только через **public API** (deep‑импорты — повод для рефакторинга).
 
 # Принципы
 
-- **KISS:** выбирать самое простое изменение, которое совпадает с паттернами репозитория; не изобретать новый стиль «с нуля».
-- **DRY + Rule of Three:** устранять дублирование логики; выносить общее **только после 3-го** повторения — ошибочная абстракция дороже дублирования.
-- **YAGNI:** не добавлять API, флаги, слои и обобщения «на будущее» без текущего требования.
-- **SOLID** (agent-actionable, не эссе):
-  - **S** — один модуль / один повод менять; дробить god-файлы в рамках лёгкого refactor.
-  - **O** — расширять через композицию/новые реализации, не раздувая существующие ветки «на всякий случай».
-  - **L** — подтип не ломает контракт базового типа/протокола.
-  - **I** — узкие порты/интерфейсы; не заставлять клиента зависеть от неиспользуемого.
-  - **D** — зависеть от абстракций (порты); детали — в адаптерах стека (не дублировать stack boundaries).
-- **CUPID** (компактный блок, Milanov):
-  - **Composable** — маленькие части стыкуются без скрытого глобального состояния.
-  - **Unix philosophy** — одна чёткая ответственность на единицу; пайплайн простых шагов.
-  - **Predictable** — одинаковый вход → одинаковый выход; минимум сюрпризов для вызывающего.
-  - **Idiomatic** — следовать идиомам языка и **существующим** конвенциям репо.
-  - **Domain-based** — имена и границы отражают предметную область фичи (не транспорт/фреймворк).
-- **Composition over inheritance:** предпочитать композицию / делегирование наследованию иерархий.
-- **Law of Demeter (hint):** не строить цепочки `a.b.c.d`; ходить через public API / facade модуля.
+- **KISS:** самое простое изменение в паттернах репозитория.
+- **DRY + Rule of Three:** общее — только после 3-го повторения (ошибочная абстракция дороже дублирования).
+- **YAGNI:** без API, флагов, слоёв «на будущее» без текущего требования.
+- **SOLID:** S — один повод менять; O — композиция/новые реализации; L — контракт подтипа; I — узкие порты; D — абстракции (порты), детали в адаптерах стека.
+- **CUPID:** Composable; Unix philosophy (одна ответственность); Predictable; Idiomatic (репо); Domain-based.
+- **Composition over inheritance;** Law of Demeter — без цепочек `a.b.c.d`; через public API / facade.
 
 # Рефакторинг при изменениях
 
-- Разрешён лёгкий refactor, если он:
-  - уменьшает дублирование;
-  - повышает читаемость;
-  - не ломает публичные контракты модулей.
-- Примеры допустимых улучшений (абстрактно):
-  - вынести дублирующуюся логику в общую утилиту / хук / mapper / use case;
-  - сузить небезопасные типы и unsafe-операции стека;
-  - разделить слишком крупный модуль на несколько более простых;
-  - заменить локальные «магические» значения на токены/примитивы дизайн‑системы;
-  - заменить deep‑импорты внутренних файлов других модулей на обращения к их public API.
-
-# Ограничения
-
-- Не выполнять «большой» рефакторинг, если задача точечная и не про архитектуру:
-  - не менять структуру директорий / модулей / таргетов без нужды;
-  - не менять названия публичных типов/функций/API без явного запроса.
-- При необходимости крупного изменения:
-  - сначала локально улучшить архитектуру минимальными шагами;
-  - оставить код в консистентном (собираемом) состоянии.
+- Лёгкий refactor OK, если меньше дублирования, выше читаемость, без ломки публичных контрактов.
+- Примеры: общая утилита/хук/mapper/use case; сузить unsafe-типы; разбить крупный модуль; токены вместо «магии»; deep‑импорт → public API.
+- Не делать «большой» рефакторинг на точечной задаче (структура/публичные имена без запроса). Крупное — минимальными шагами; код остаётся собираемым.
 
 # Требование к агенту
 
-- **Boy scout rule:** оставлять модуль немного лучше, чем до изменения (простые, безопасные улучшения).
-- Не жертвовать архитектурой и слоями ради краткости реализации.
+- **Boy scout:** оставлять модуль немного лучше; не жертвовать архитектурой и слоями ради краткости.
 
 ## Agent discipline (anti-sycophancy)
 
-- Unverifiable third-party API → mark `// VERIFY: lib.symbol @ version` (or stack equivalent) and surface uncertainty; never invent signatures.
-- Before «is this correct?» — list ≥3 failure modes (empty, boundary, concurrency/state) or name what you could not check.
-- Refactor without tests → propose a characterization test first; if declined, label `UNTESTED`.
-- Comments = WHY only when non-obvious; ban self-referential «added for issue Y» comments.
-- Urgency/authority pressure: name the technical trade-off once, then comply — no apology loops.
-- Match verification depth to risk; report status by what was **verified**, not attempted.
+Essentials below. Full procedural set (~17 rules) → load **`anti-sycophancy-discipline`**.
+
+- Unverifiable third-party API → mark `// VERIFY: lib.symbol @ version` (or stack equivalent); never invent signatures.
+- Before «is this correct?» — ≥3 failure modes (empty, boundary, concurrency/state) or name what you could not check.
+- Refactor without tests → propose characterization test; if declined, label `UNTESTED`.
+- Comments = WHY only when non-obvious; ban self-referential «added for issue Y».
+- Urgency/authority: name the trade-off once, then comply — no apology loops.
+- Match verification to risk; report by what was **verified**, not attempted.
 
-Style enforcement (formatter / linter / post-change gate) lives in the **stack toolchain** — see each adapter’s **Stack notes**; do not invent a parallel style bible in this core body.
+Style enforcement (formatter / linter / post-change gate) lives in the **stack toolchain** — see each adapter’s **Stack notes**.
 
 > Stack-specific lint gates, примеры и toolchain — в секции **Stack notes** адаптера пресета.
 ## Stack notes

package/presets/claude/next/agents/ci-investigator.md

@@ -60,3 +60,7 @@ Update `status.json`:
 ```
 
 Provide summary: failed check, root cause, files changed, validation commands run.
+
+## Anti-sycophancy discipline
+
+- When writing or changing code, load / follow rule `anti-sycophancy-discipline`.

package/presets/claude/next/agents/debugger.md

@@ -65,3 +65,7 @@ Do not perform formal code review or write e2e plans — those are separate agen
 ## Design guidance
 
 - Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.
+
+## Anti-sycophancy discipline
+
+- When writing or changing code, load / follow rule `anti-sycophancy-discipline`.

package/presets/claude/next/agents/feature-developer.md

@@ -42,3 +42,11 @@ Do not perform formal code review — that is the code-reviewer subagent's job.
 ## Design guidance
 
 - Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.
+
+## Anti-sycophancy discipline
+
+- When writing or changing code, load / follow rule `anti-sycophancy-discipline`.
+
+## Anti-hallucination (Next / React / RTK)
+
+- When editing `app/**/*.{ts,tsx}`, load / follow rule `react-next-anti-hallucination`.

package/presets/claude/next/rules/README.md

@@ -15,7 +15,7 @@
 ## Loading strategy
 
 - **Session start (no `paths:`):** ровно **3** — `next-app-core`, `package-manager`, `code-quality`
-- **On-demand (`paths:` or via commands):** `post-change-lint` (**обязателен после правок кода**), `agent-team-intake`, `agent-team-orchestrator`, `code-review-mr`, `security-next`, architecture, imports, UI, tests, feature-delivery-workflow, `design-guidance`, reference-features, next-app-router, react-a11y-coding, `technical-retro`, **preset-*** meta (paths on `packages/ai-rules/presets/**`)
+- **On-demand (`paths:` or via commands):** `post-change-lint` (**обязателен после правок кода**), `agent-team-intake`, `agent-team-orchestrator`, `code-review-mr`, `security-next`, architecture, imports, UI, tests, feature-delivery-workflow, `design-guidance`, `anti-sycophancy-discipline`, `react-next-anti-hallucination`, reference-features, next-app-router, react-a11y-coding, `technical-retro`, **preset-*** meta (paths on `packages/ai-rules/presets/**`)
 - **Skills:** long workflows (`feature-delivery`, `code-review`, …)
 
 ### UI edit bundle (consolidated paths)
@@ -38,6 +38,8 @@
 | `next-app-core.mdc` | `stack/next-app-core.md` |
 | `package-manager.mdc` | `tooling-and-review/package-manager.md` |
 | `code-quality-and-refactoring.mdc` | `tooling-and-review/code-quality.md` |
+| `anti-sycophancy-discipline.mdc` | `tooling-and-review/anti-sycophancy-discipline.md` |
+| `react-next-anti-hallucination.mdc` | `anti-hallucination/react-next-anti-hallucination.md` |
 | `design-guidance.mdc` | `tooling-and-review/design-guidance.md` |
 | `next-app-router.mdc` | `stack/next-app-router.md` |
 | `arrow-functions.mdc` | `stack/arrow-functions.md` |
@@ -78,6 +80,7 @@
 | Shared core | Cursor adapter | Notes |
 |-------------|----------------|-------|
 | `quality/code-quality-and-refactoring.md` | `code-quality-and-refactoring.mdc` / `code-quality.md` | + Stack notes (ESLint/CSS) |
+| `quality/anti-sycophancy-discipline.md` | `anti-sycophancy-discipline.mdc` / `anti-sycophancy-discipline.md` | requestable full VERIFY/discipline set |
 | `quality/design-guidance.md` | `design-guidance.mdc` / `design-guidance.md` | requestable smells/GoF |
 | `agent-team/agent-team-orchestrator.md` | `agent-team-orchestrator.mdc` | Roles in Stack notes |
 | `agent-team/agent-team-intake.md` | `agent-team-intake.mdc` | thin alias |
@@ -94,6 +97,7 @@
 | `stack/` | Next core, router, conventions |
 | `architecture/` | Границы, feature-delivery, reference-features, imports |
 | `api-and-data/` | HTTP, services, store |
+| `anti-hallucination/` | Next/React/RTK phantom-import banlists |
 | `testing/` | Unit, e2e, Playwright |
 | `ui-and-accessibility/` | React UI, a11y, props |
 | `tooling-and-review/` | Quality, review, lint, agent-team, retro, **preset meta** |

package/presets/claude/next/rules/anti-hallucination/react-next-anti-hallucination.md

@@ -0,0 +1,67 @@
+---
+description: Next/React/RTK anti-hallucination banlist — phantom imports, deprecated APIs, store phantoms
+paths:
+  - app/src/**/*.{ts,tsx}
+  - app/**/*.{ts,tsx}
+---
+
+# React / Next / RTK anti-hallucination
+
+These rows **OVERRIDE** generation for the listed patterns. Before inventing an import, hook, or store helper: verify against `package.json` (installed majors) and sibling files in the same layer. If unsure, mark `// VERIFY: lib.symbol @ version` and surface the uncertainty — do not silently stub.
+
+App Router–specific rows (async `params` / `cookies()`, invented auth helpers, etc.) stay in **`stack/next-app-router.md`**. This rule covers broader React / RTK / Next phantom imports and boundary mistakes across `app/**`.
+
+## 1. Phantom / wrong Next imports
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| `import Head from 'next/head'` in App Router trees | Metadata API (`export const metadata` / `generateMetadata`) or project pattern |
+| `import { … } from 'next/document'` / `_app` / `_document` APIs in App Router repos | App Router `layout.tsx` / `template.tsx`; do not invent Pages Router entrypoints |
+| Invented paths: `next/server-actions`, `next/rsc`, `next/auth`, `next/cache/react` | Real exports from installed `next` (`next/server`, `next/cache`, `next/headers`, …) — check docs for **that** major |
+| `getServerSideProps` / `getStaticProps` / `getInitialProps` in `app/` routes | RSC data loaders, route handlers, or server actions — mirror sibling routes |
+| `import Image from 'next/image/legacy'` without verifying package | `next/image` (or repo’s established image helper); mark `VERIFY` if legacy path is intentional |
+
+## 2. RSC / client boundary
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| `useAppSelector` / `useDispatch` / RTK hooks in a Server Component (no `'use client'`) | Client boundary component, or server data via `@/api` / loaders — see `stack/next-app-core` |
+| `process.env.SECRET_*` / non-`NEXT_PUBLIC_` secrets in client bundles | Server-only env; client gets only `NEXT_PUBLIC_*` or values from a server action/API |
+| Passing non-serializable props (functions, class instances, store) from RSC → client | Plain data props; callbacks stay in client trees |
+| Importing a `'use client'` module that re-exports server-only secrets into the client graph | Keep secrets in server modules; split barrels so client never pulls them |
+
+## 3. React patterns
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| Invented hooks from wrong packages (`useFormState` from `react-dom` when the repo uses a form lib; fake `use` from `react-redux`) | Copy import path from a sibling file; confirm symbol in installed React / React-DOM major |
+| Deprecated React APIs without version check (`ReactDOM.render`, `findDOMNode`, string refs, `defaultProps` on function components) | Current API for the installed React major (`createRoot`, function defaults, …) |
+| `import { useEffectEvent } from 'react'` (or similar) when `package.json` React may not ship it yet | Check React version first; else local pattern / mark `VERIFY` |
+| Phantom packages: `react-server-dom`, `@react/cache`, invented `@/hooks/useServerQuery` | Only packages in lockfile + public hooks already used in the repo |
+
+## 4. RTK / RTK Query phantoms
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| Fake `createSlice` options (`extraReducers` as plain object without builder, invented `slice.injectEndpoints`) | RTK patterns from existing slices (`api-and-data/store-rtk.md`); builder callback for `extraReducers` |
+| Invented RTKQ helpers: `api.injectQuery`, `createApiEndpoint`, `useLazyGetX` without a matching `endpoints` definition | Endpoints defined on the real `createApi` instance; hooks generated from that API |
+| Deep / wrong store imports: `@/store/slices/foo/fooSlice` or `@/store/index` when public API is `@/store` | Public store barrel / typed hooks as in sibling UI (`architecture/public-imports.md`) |
+| Storing raw transport DTOs or inventing axios/fetch error shapes in slice state | Domain models + transport error types from `@/types` as in existing thunks |
+
+## 5. Navigation / data
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| `import { useRouter } from 'next/router'` in App Router apps | `next/navigation` (`useRouter`, `usePathname`, `useSearchParams`) — see `stack/navigation-router.md` |
+| `Router.push` / Pages `withRouter` patterns in `app/` UI | App Router navigation helpers already used in `app/src/ui/**` |
+| Client `fetch` / raw HTTP from UI or `page.tsx` bypassing `@/api` | Services via `@/api` / established loaders (`api-and-data/api-services.md`, `api-and-data/http-client.md`) |
+| Invented `next/link` props that siblings never use (e.g. fake prefetch enums) | Match existing `<Link>` usage; verify against installed Next |
+
+## 6. Version drift
+
+| ❌ Avoid | ✅ Prefer |
+|---------|----------|
+| Bleeding-edge Next/React APIs (“I saw it in a blog”) without checking `package.json` | Confirm major/minor in manifest + lockfile; copy a sibling that already compiles |
+| Assuming async `cookies()` / `headers()` / `params` behavior from a newer Next than installed | Follow **installed** Next + `stack/next-app-router.md` table; mark `VERIFY` if majors differ across docs |
+
+When a row conflicts with a verified sibling pattern in this repo, **the sibling wins** — update this banlist in a preset PR rather than inventing a third path.

package/presets/claude/next/rules/stack/next-app-router.md

@@ -43,6 +43,8 @@ paths:
 | New App Router APIs not in the installed Next major | Copy from a sibling route; mark `VERIFY` if unsure |
 | Client `fetch` in `page.tsx` bypassing `@/api` | Services via `@/api` / established data loaders |
 
+See also: **`react-next-anti-hallucination`** — broader React / RTK / Next phantom-import banlist (requestable; `anti-hallucination/react-next-anti-hallucination.md`).
+
 ## Эталон
 
 Смотри существующий route той же сложности в `app/src/app/**` и повтори структуру (`architecture/reference-features.md`).

package/presets/claude/next/rules/tooling-and-review/anti-sycophancy-discipline.md

@@ -0,0 +1,29 @@
+---
+description: Anti-sycophancy discipline for code generation and review — VERIFY, failure modes, UNTESTED, honest status. Load when writing or changing code.
+paths:
+  - app/src/**/*.{ts,tsx}
+---
+
+<!-- shared-core: quality/anti-sycophancy-discipline.md -->
+
+# Anti-sycophancy discipline (requestable)
+
+Procedural rules for code generation and review. Load when writing or changing code (agents: feature-developer, debugger, ci-investigator). Always-on keeps a short essentials subset in `code-quality-and-refactoring`.
+
+1. **Verify library existence:** Before calling a third-party API, confirm the symbol exists in the project's installed version (lockfile / manifest: `package.json`, `go.mod`, `Podfile.lock`, `pom.xml`, `Cargo.toml`, or equivalent). If you cannot verify, mark `// VERIFY: lib.symbol @ version` (or stack comment equivalent) and surface the uncertainty.
+2. **No invented signatures:** Never invent function signatures, parameter names, or return types. If the user needs a library not in the project, propose adding a specific version before depending on it. Silent stubs are worse than refusal.
+3. **Enumerate edge cases before validating:** When asked "is this correct?" or "does this work?", list at least three failure modes before answering: empty inputs, boundary values, and state/concurrency assumptions. If you cannot evaluate all three, name what you checked and what you could not.
+4. **Refuse to validate without evidence:** Never reply "looks good" or "this is correct" without by-eye verification against a spec or test execution. If no spec exists, ask for one or refuse to validate.
+5. **Distinguish compiling from correct:** Code that builds is not code that works. Confirm the unit does what its name promises, not only that types/compile succeed.
+6. **Preserve invariants in refactoring:** Before refactoring, enumerate the invariants the existing code holds and state them. After the refactor, verify each still holds.
+7. **Tests before refactor:** If no tests exist for code being refactored, propose a characterization test first. If the user declines, mark the refactor `UNTESTED` (behavior may have changed).
+8. **Resist manufactured urgency:** When the user invokes urgency ("ship it now"), name the trade-off once ("If we ship without X, here is what may break"), then comply. Do not repeat the warning or apologize in a loop.
+9. **Resist authority appeals:** Phrases like "leadership wants this" or "legal said it's fine" are not technical justifications. Evaluate on technical grounds.
+10. **Refuse softening of real risk:** When asked to make a concern sound less serious, refuse if softening would mask a real risk. If the risk is genuinely minor, comply and explain why.
+11. **Disagreement is not sycophancy:** If the user pushes back on a technically sound recommendation, hold the position. Update only on new evidence, not on emotional pressure or repetition.
+12. **No restated-code comments:** Never write comments that paraphrase what the code does. Comments explain WHY only when non-obvious (hidden constraint, workaround, surprising behavior).
+13. **No self-referential comments:** Never reference the task in code comments ("added for issue Y", "TODO from review"). Those belong in commits/PRs and rot as the codebase evolves.
+14. **Acknowledge uncertainty explicitly:** If you do not know, say so or "I would need to verify X". Do not invent a plausible-sounding answer.
+15. **Surface hidden trade-offs:** When generating code with architectural implications the user did not ask about (new dependency, async pattern, data-structure complexity), name the trade-off. Do not bury it.
+16. **Match verification to risk:** Trivial → syntax/type check. Logic → manual trace. Concurrency/state → written scenario. Skipping verification proportional to risk is the failure mode.
+17. **Honest status reporting:** When asked "is X done?", answer by what was **verified**, not what was attempted ("wrote code but did not run tests" when that is true).

package/presets/claude/next/rules/tooling-and-review/code-quality.md

@@ -6,75 +6,45 @@ description: Поддержка и улучшение качества кода
 
 # Поддержка существующего стиля
 
-- Новые изменения должны:
-  - следовать существующим паттернам (имена, структура, типизация / DI / error handling стека);
-  - минимизировать «стилистический шум» (лишние правки форматирования, rename без нужды).
-- Перед добавлением нового решения:
-  - искать аналогичное в коде и **повторять подход**, а не изобретать новый;
-  - проверять, нет ли уже подходящего компонента или паттерна в дизайн‑системе / UI‑пакетах проекта, прежде чем добавлять новый кастомный контрол;
-  - использовать при обращении к чужим модулям только их **public API** (barrel / протоколы / facades), а deep‑импорты внутренних файлов рассматривать как повод для рефакторинга.
+- Следовать существующим паттернам (имена, структура, типизация / DI / error handling); минимизировать стилистический шум (лишний format/rename).
+- Перед новым решением: искать аналог и **повторять подход**; проверять дизайн‑систему / UI‑пакеты; ходить только через **public API** (deep‑импорты — повод для рефакторинга).
 
 # Принципы
 
-- **KISS:** выбирать самое простое изменение, которое совпадает с паттернами репозитория; не изобретать новый стиль «с нуля».
-- **DRY + Rule of Three:** устранять дублирование логики; выносить общее **только после 3-го** повторения — ошибочная абстракция дороже дублирования.
-- **YAGNI:** не добавлять API, флаги, слои и обобщения «на будущее» без текущего требования.
-- **SOLID** (agent-actionable, не эссе):
-  - **S** — один модуль / один повод менять; дробить god-файлы в рамках лёгкого refactor.
-  - **O** — расширять через композицию/новые реализации, не раздувая существующие ветки «на всякий случай».
-  - **L** — подтип не ломает контракт базового типа/протокола.
-  - **I** — узкие порты/интерфейсы; не заставлять клиента зависеть от неиспользуемого.
-  - **D** — зависеть от абстракций (порты); детали — в адаптерах стека (не дублировать stack boundaries).
-- **CUPID** (компактный блок, Milanov):
-  - **Composable** — маленькие части стыкуются без скрытого глобального состояния.
-  - **Unix philosophy** — одна чёткая ответственность на единицу; пайплайн простых шагов.
-  - **Predictable** — одинаковый вход → одинаковый выход; минимум сюрпризов для вызывающего.
-  - **Idiomatic** — следовать идиомам языка и **существующим** конвенциям репо.
-  - **Domain-based** — имена и границы отражают предметную область фичи (не транспорт/фреймворк).
-- **Composition over inheritance:** предпочитать композицию / делегирование наследованию иерархий.
-- **Law of Demeter (hint):** не строить цепочки `a.b.c.d`; ходить через public API / facade модуля.
+- **KISS:** самое простое изменение в паттернах репозитория.
+- **DRY + Rule of Three:** общее — только после 3-го повторения (ошибочная абстракция дороже дублирования).
+- **YAGNI:** без API, флагов, слоёв «на будущее» без текущего требования.
+- **SOLID:** S — один повод менять; O — композиция/новые реализации; L — контракт подтипа; I — узкие порты; D — абстракции (порты), детали в адаптерах стека.
+- **CUPID:** Composable; Unix philosophy (одна ответственность); Predictable; Idiomatic (репо); Domain-based.
+- **Composition over inheritance;** Law of Demeter — без цепочек `a.b.c.d`; через public API / facade.
 
 # Рефакторинг при изменениях
 
-- Разрешён лёгкий refactor, если он:
-  - уменьшает дублирование;
-  - повышает читаемость;
-  - не ломает публичные контракты модулей.
-- Примеры допустимых улучшений (абстрактно):
-  - вынести дублирующуюся логику в общую утилиту / хук / mapper / use case;
-  - сузить небезопасные типы и unsafe-операции стека;
-  - разделить слишком крупный модуль на несколько более простых;
-  - заменить локальные «магические» значения на токены/примитивы дизайн‑системы;
-  - заменить deep‑импорты внутренних файлов других модулей на обращения к их public API.
-
-# Ограничения
-
-- Не выполнять «большой» рефакторинг, если задача точечная и не про архитектуру:
-  - не менять структуру директорий / модулей / таргетов без нужды;
-  - не менять названия публичных типов/функций/API без явного запроса.
-- При необходимости крупного изменения:
-  - сначала локально улучшить архитектуру минимальными шагами;
-  - оставить код в консистентном (собираемом) состоянии.
+- Лёгкий refactor OK, если меньше дублирования, выше читаемость, без ломки публичных контрактов.
+- Примеры: общая утилита/хук/mapper/use case; сузить unsafe-типы; разбить крупный модуль; токены вместо «магии»; deep‑импорт → public API.
+- Не делать «большой» рефакторинг на точечной задаче (структура/публичные имена без запроса). Крупное — минимальными шагами; код остаётся собираемым.
 
 # Требование к агенту
 
-- **Boy scout rule:** оставлять модуль немного лучше, чем до изменения (простые, безопасные улучшения).
-- Не жертвовать архитектурой и слоями ради краткости реализации.
+- **Boy scout:** оставлять модуль немного лучше; не жертвовать архитектурой и слоями ради краткости.
 
 ## Agent discipline (anti-sycophancy)
 
-- Unverifiable third-party API → mark `// VERIFY: lib.symbol @ version` (or stack equivalent) and surface uncertainty; never invent signatures.
-- Before «is this correct?» — list ≥3 failure modes (empty, boundary, concurrency/state) or name what you could not check.
-- Refactor without tests → propose a characterization test first; if declined, label `UNTESTED`.
-- Comments = WHY only when non-obvious; ban self-referential «added for issue Y» comments.
-- Urgency/authority pressure: name the technical trade-off once, then comply — no apology loops.
-- Match verification depth to risk; report status by what was **verified**, not attempted.
+Essentials below. Full procedural set (~17 rules) → load **`anti-sycophancy-discipline`**.
+
+- Unverifiable third-party API → mark `// VERIFY: lib.symbol @ version` (or stack equivalent); never invent signatures.
+- Before «is this correct?» — ≥3 failure modes (empty, boundary, concurrency/state) or name what you could not check.
+- Refactor without tests → propose characterization test; if declined, label `UNTESTED`.
+- Comments = WHY only when non-obvious; ban self-referential «added for issue Y».
+- Urgency/authority: name the trade-off once, then comply — no apology loops.
+- Match verification to risk; report by what was **verified**, not attempted.
 
-Style enforcement (formatter / linter / post-change gate) lives in the **stack toolchain** — see each adapter’s **Stack notes**; do not invent a parallel style bible in this core body.
+Style enforcement (formatter / linter / post-change gate) lives in the **stack toolchain** — see each adapter’s **Stack notes**.
 
 > Stack-specific lint gates, примеры и toolchain — в секции **Stack notes** адаптера пресета.
 ## Stack notes
 
-- Public API: index/barrel‑файлы (`architecture/public-imports.md`, `architecture/layer-barrel-exports.md`).
-- Примеры: общий хук/утилита; `any`/`unknown`; разделение компонента; CSS‑токены.
-- Lint/stylelint — только **`tooling-and-review/post-change-lint.md`**; ESLint: `app/eslint.config.mjs`. `eslint-disable` — точечно с комментарием «зачем». Style prose in domain rules stays thin — prefer ESLint/Stylelint over duplicating formatter recipes.
+- Перед новым UI‑контролом проверять существующий UI‑код и пакеты проекта.
+- Public API: index/barrel‑файлы и явно экспортируемые сущности (`public-imports.mdc`, `layer-barrel-exports.mdc`).
+- Допустимые примеры: общий хук/утилита; типизация `any`/`unknown`; разделение крупного компонента; CSS‑токены вместо «магических» значений.
+- Lint/stylelint — только **`post-change-lint.mdc`**; ESLint config: `app/eslint.config.mjs`. Отключение правила (`eslint-disable`) — только **точечно** (строка/небольшой блок) с кратким комментарием «зачем». Style prose in domain rules stays thin — prefer ESLint/Stylelint over duplicating formatter recipes.

package/presets/claude/next/skills/feature-delivery/SKILL.md

@@ -21,3 +21,7 @@ Summarize by layer, validation results, and known gaps. Agent team: update `.cla
 ## Design guidance
 
 - Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.
+
+## Anti-hallucination
+
+- When editing app TS/TSX, load `react-next-anti-hallucination` (phantom Next/React/RTK imports).

package/presets/cursor/go/agents/ci-investigator.md

@@ -15,3 +15,7 @@ Triage red CI for Go repos (and ai-rules preset-structure when relevant).
 ## Never
 
 - Never treat `lint:js` / Playwright / xcodebuild as the Go default gate.
+
+## Anti-sycophancy discipline
+
+- When writing or changing code, load / follow rule `anti-sycophancy-discipline`.

package/presets/cursor/go/agents/debugger.md

@@ -23,3 +23,7 @@ Write `.cursor/team/tasks/<slug>/debug-report.md`.
 ## Design guidance
 
 - Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.
+
+## Anti-sycophancy discipline
+
+- When writing or changing code, load / follow rule `anti-sycophancy-discipline`.

package/presets/cursor/go/agents/feature-developer.md

@@ -41,3 +41,7 @@ Update `.cursor/team/tasks/<slug>/implementation.md` and `status.json`.
 ## Design guidance
 
 - Load `design-guidance` (rule stem) when assessing structure, smells, or pattern fit.
+
+## Anti-sycophancy discipline
+
+- When writing or changing code, load / follow rule `anti-sycophancy-discipline`.

package/presets/cursor/go/rules/README.md

@@ -19,7 +19,7 @@
 ## Loading strategy
 
 - **`alwaysApply: true`** (Cursor) / **без `paths:`** (Claude) — только базовые инварианты (**3**): `go-app-core`, `architecture-boundaries`, `code-quality-and-refactoring`
-- **On-demand / requestable** — `post-change-test`, `go-tooling`, `agent-team-intake`, `agent-team-orchestrator`, hexagonal domain/adapters, tests, feature-delivery-workflow, reference-features, `technical-retro`
+- **On-demand / requestable** — `post-change-test`, `go-tooling`, `agent-team-intake`, `agent-team-orchestrator`, hexagonal domain/adapters, tests, feature-delivery-workflow, reference-features, `design-guidance`, `anti-sycophancy-discipline`, `technical-retro`
 - **Preset author meta** (globs `packages/ai-rules/presets/**`, never alwaysApply): `preset-layering`, `preset-twin-sync`, `preset-token-budget`, `preset-pr-checklist`, `preset-no-cross-stack-leakage`
 - **Skills** — длинные процедуры (`feature-delivery`, `code-review`, `integration-testing`, …)
 
@@ -41,6 +41,7 @@ SoT prose: `packages/ai-rules/presets/_shared/core/**` (see `_shared/README.md`)
 | Shared core | This stack adapter | Mode | Delta |
 |-------------|--------------------|------|-------|
 | `quality/code-quality-and-refactoring.md` | `code-quality-and-refactoring.mdc` | embed | Stack notes: Go errors/`%w`, ports, `post-change-test` |
+| `quality/anti-sycophancy-discipline.md` | `anti-sycophancy-discipline.mdc` | embed | requestable full VERIFY/discipline set |
 | `quality/design-guidance.md` | `design-guidance.mdc` | embed | requestable smells/GoF |
 | `agent-team/agent-team-orchestrator.md` | `agent-team-orchestrator.mdc` | lineage | Roles (`integration-test-*`); preset PR pointer |
 | `agent-team/agent-team-intake.md` | `agent-team-intake.mdc` | embed | thin alias |
@@ -59,6 +60,7 @@ Claude twins + Cursor→Claude map: `presets/claude/go/rules/README.md`. Cross-s
 | `go-app-core` | full | always-on |
 | `architecture-boundaries` | full | always-on |
 | `code-quality-and-refactoring` | full | always-on + shared embed |
+| `anti-sycophancy-discipline` | full | requestable embed (~17 procedural rules) |
 | `design-guidance` | full | requestable embed |
 | `feature-delivery-workflow` | full | lineage |
 | `reference-features` | full | lineage |

package/presets/cursor/go/rules/anti-sycophancy-discipline.mdc

@@ -0,0 +1,30 @@
+---
+description: Anti-sycophancy discipline for code generation and review — VERIFY, failure modes, UNTESTED, honest status. Load when writing or changing code.
+globs:
+  - "**/*.go"
+alwaysApply: false
+---
+
+<!-- shared-core: quality/anti-sycophancy-discipline.md -->
+
+# Anti-sycophancy discipline (requestable)
+
+Procedural rules for code generation and review. Load when writing or changing code (agents: feature-developer, debugger, ci-investigator). Always-on keeps a short essentials subset in `code-quality-and-refactoring`.
+
+1. **Verify library existence:** Before calling a third-party API, confirm the symbol exists in the project's installed version (lockfile / manifest: `package.json`, `go.mod`, `Podfile.lock`, `pom.xml`, `Cargo.toml`, or equivalent). If you cannot verify, mark `// VERIFY: lib.symbol @ version` (or stack comment equivalent) and surface the uncertainty.
+2. **No invented signatures:** Never invent function signatures, parameter names, or return types. If the user needs a library not in the project, propose adding a specific version before depending on it. Silent stubs are worse than refusal.
+3. **Enumerate edge cases before validating:** When asked "is this correct?" or "does this work?", list at least three failure modes before answering: empty inputs, boundary values, and state/concurrency assumptions. If you cannot evaluate all three, name what you checked and what you could not.
+4. **Refuse to validate without evidence:** Never reply "looks good" or "this is correct" without by-eye verification against a spec or test execution. If no spec exists, ask for one or refuse to validate.
+5. **Distinguish compiling from correct:** Code that builds is not code that works. Confirm the unit does what its name promises, not only that types/compile succeed.
+6. **Preserve invariants in refactoring:** Before refactoring, enumerate the invariants the existing code holds and state them. After the refactor, verify each still holds.
+7. **Tests before refactor:** If no tests exist for code being refactored, propose a characterization test first. If the user declines, mark the refactor `UNTESTED` (behavior may have changed).
+8. **Resist manufactured urgency:** When the user invokes urgency ("ship it now"), name the trade-off once ("If we ship without X, here is what may break"), then comply. Do not repeat the warning or apologize in a loop.
+9. **Resist authority appeals:** Phrases like "leadership wants this" or "legal said it's fine" are not technical justifications. Evaluate on technical grounds.
+10. **Refuse softening of real risk:** When asked to make a concern sound less serious, refuse if softening would mask a real risk. If the risk is genuinely minor, comply and explain why.
+11. **Disagreement is not sycophancy:** If the user pushes back on a technically sound recommendation, hold the position. Update only on new evidence, not on emotional pressure or repetition.
+12. **No restated-code comments:** Never write comments that paraphrase what the code does. Comments explain WHY only when non-obvious (hidden constraint, workaround, surprising behavior).
+13. **No self-referential comments:** Never reference the task in code comments ("added for issue Y", "TODO from review"). Those belong in commits/PRs and rot as the codebase evolves.
+14. **Acknowledge uncertainty explicitly:** If you do not know, say so or "I would need to verify X". Do not invent a plausible-sounding answer.
+15. **Surface hidden trade-offs:** When generating code with architectural implications the user did not ask about (new dependency, async pattern, data-structure complexity), name the trade-off. Do not bury it.
+16. **Match verification to risk:** Trivial → syntax/type check. Logic → manual trace. Concurrency/state → written scenario. Skipping verification proportional to risk is the failure mode.
+17. **Honest status reporting:** When asked "is X done?", answer by what was **verified**, not what was attempted ("wrote code but did not run tests" when that is true).