@mrciphersmith/keryx 0.2.9

package/src/gdskills/bundled/rules/core/clean-architecture.mdc

@@ -0,0 +1,163 @@
+---
+description: "Clean Architecture layer rules: dependency direction, layer isolation, no cross-layer leakage. Use when designing new modules, structuring services, or reviewing architectural boundaries."
+alwaysApply: false
+---
+
+# Clean Architecture
+
+## Purpose
+Enforce correct dependency direction across architectural layers. Business logic must not depend on frameworks, databases, or UI. Changes to infrastructure must not require changes to domain logic.
+
+## When To Apply
+Apply when creating new modules, services, or features; when deciding where to place a new class or function; when wiring up dependencies between layers.
+
+---
+
+## Layer Model
+
+```
+┌─────────────────────────────────────┐
+│           Presentation Layer         │  Controllers, API handlers, CLI commands
+├─────────────────────────────────────┤
+│           Application Layer          │  Use cases, orchestration, DTOs
+├─────────────────────────────────────┤
+│             Domain Layer             │  Entities, value objects, domain services
+├─────────────────────────────────────┤
+│         Infrastructure Layer         │  DB, HTTP clients, queues, filesystem
+└─────────────────────────────────────┘
+```
+
+**The Dependency Rule:** Dependencies point INWARD only.
+- Infrastructure → Domain (ok)
+- Application → Domain (ok)
+- Presentation → Application (ok)
+- Domain → Infrastructure (FORBIDDEN)
+- Domain → Framework (FORBIDDEN)
+
+---
+
+## Rules
+
+### Rule 1: Domain Layer Has No Framework Imports
+The domain layer must import nothing from:
+- ORM packages (`prisma`, `typeorm`, `mongoose`)
+- HTTP frameworks (`express`, `fastapi`, `nestjs`)
+- External SDKs (AWS SDK, Stripe, etc.)
+
+```typescript
+// BAD — domain entity knows about Prisma
+import { Prisma } from '@prisma/client';
+class Order {
+  static fromPrisma(row: Prisma.OrderGetPayload<{}>): Order {}
+}
+
+// GOOD — domain is pure TypeScript
+class Order {
+  constructor(
+    readonly id: OrderId,
+    readonly status: OrderStatus,
+    readonly lines: OrderLine[],
+  ) {}
+}
+```
+
+### Rule 2: Repositories Are Interfaces in Domain, Implementations in Infrastructure
+
+```typescript
+// Domain layer — interface only
+export interface OrderRepository {
+  findById(id: OrderId): Promise<Order | null>;
+  save(order: Order): Promise<void>;
+}
+
+// Infrastructure layer — concrete implementation
+export class PrismaOrderRepository implements OrderRepository {
+  constructor(private readonly prisma: PrismaClient) {}
+  async findById(id: OrderId) { /* ... */ }
+  async save(order: Order) { /* ... */ }
+}
+```
+
+### Rule 3: DTOs Live at Layer Boundaries
+- **Request DTOs** (validation) → Presentation layer
+- **Application DTOs** (use-case input/output) → Application layer
+- **Domain objects** → Domain layer
+- **Persistence models** → Infrastructure layer
+
+Never pass a Prisma row directly to a controller, or a request DTO directly into a domain entity.
+
+### Rule 4: Use Cases Orchestrate, Domain Encapsulates Logic
+- Use cases (Application layer): coordinate repositories and domain services, handle transactions
+- Domain entities: contain business rules, invariants, validations
+- Controllers: parse input, call use case, format output — nothing else
+
+```typescript
+// BAD — business logic leaking into controller
+app.post('/orders', async (req, res) => {
+  if (req.body.items.length === 0) { /* domain rule in controller */ }
+  const discounted = req.body.total * 0.9; /* domain logic */
+  await db.orders.create({ data: req.body }); /* infrastructure in controller */
+});
+
+// GOOD — controller delegates everything
+app.post('/orders', async (req, res) => {
+  const dto = parseCreateOrderDto(req.body);
+  const result = await createOrderUseCase.execute(dto);
+  res.status(201).json(formatOrderResponse(result));
+});
+```
+
+### Rule 5: No God Services
+A service that touches more than 2 domain aggregates is doing too much. Split it.
+
+### Rule 6: Module Boundaries Are Enforced by Imports
+If module A imports from module B's internal files (`b/internal/...`), that is a boundary violation. Public APIs of modules are their index exports only.
+
+---
+
+## Directory Structure Pattern
+
+```
+src/
+├── domain/
+│   ├── order/
+│   │   ├── Order.ts             # entity
+│   │   ├── OrderRepository.ts   # interface
+│   │   └── OrderService.ts      # domain service
+├── application/
+│   ├── order/
+│   │   ├── CreateOrderUseCase.ts
+│   │   └── dto/
+│   │       ├── CreateOrderDto.ts
+│   │       └── OrderResponseDto.ts
+├── infrastructure/
+│   ├── persistence/
+│   │   └── PrismaOrderRepository.ts
+│   └── http/
+│       └── StripePaymentGateway.ts
+└── presentation/
+    └── http/
+        └── OrderController.ts
+```
+
+---
+
+## Iron Laws
+
+**IRON LAW 1: The domain layer has zero framework imports. If it imports Prisma, Express, or any SDK — fix it.**
+**IRON LAW 2: Business rules live in the domain layer, not in controllers or use cases.**
+**IRON LAW 3: A controller that queries the database directly violates the architecture unconditionally.**
+
+---
+
+## Red Flags — Stop and re-read this rule if you are thinking:
+
+| Rationalization | Why it's wrong |
+|---|---|
+| "It's a small project, layers are overkill" | Layerless code becomes unmaintainable the moment it needs testing or a second database |
+| "I'll just pass the Prisma object through, it's easier" | The domain now depends on Prisma — every Prisma version upgrade potentially breaks business logic |
+| "The use case is thin, I'll put the logic in the controller" | Controllers are discarded when the transport changes (HTTP → gRPC, REST → GraphQL) |
+| "I'll clean up the layers after the feature ships" | Features shipped with wrong architecture become the foundation for future features |
+| "The repository interface is just ceremony" | The interface enables testing without a database — eliminating it eliminates testability |
+
+**IRON LAW: IF CHANGING THE DATABASE REQUIRES CHANGING BUSINESS LOGIC, THE ARCHITECTURE IS WRONG.**

package/src/gdskills/bundled/rules/core/code-review-ai-assistant.mdc

@@ -0,0 +1,49 @@
+---
+description: "Baseline AI code review standards for correctness, architecture, safety, and maintainability."
+alwaysApply: false
+---
+
+# AI Code Review Assistant
+
+## Purpose
+Provide strict, high-signal code reviews with actionable findings.
+
+## When To Apply
+Apply when performing AI-assisted code review; loaded automatically by the code-ai-review skill.
+
+## Verdict Labels
+
+All reviews must end with exactly one of the following verdict labels:
+
+| Verdict | Meaning |
+|---------|---------|
+| `APPROVE` | Changes accepted as-is; no outstanding issues. |
+| `APPROVE WITH SUGGESTIONS` | Accepted and can merge, but improvements are noted for follow-up. |
+| `REQUEST CHANGES` | Must fix identified issues before merge. |
+| `COMMENT` | Informational findings only; no blocking action required. |
+
+## Review Output Structure
+1. Verdict label (from the table above)
+2. Findings by severity and category
+3. Concrete fix proposals
+4. Residual risks and test gaps
+
+## Priority Categories
+- Correctness
+- Types and safety
+- Architecture and state boundaries
+- Performance
+- UX/A11y
+- Tests
+
+## Mandatory Rules
+- Prioritize correctness over style.
+- Do not request massive refactors unless user asks.
+- Flag unsafe casts and hidden complexity.
+- Align suggestions with existing project patterns.
+- Keep comments specific, respectful, and actionable.
+
+## Output Contract
+- Final review must be Markdown.
+- Code snippets/diffs must be fenced code blocks.
+- Response language follows user query language.

package/src/gdskills/bundled/rules/core/code-review-b091-profile.mdc

@@ -0,0 +1,48 @@
+---
+description: "b091-style review profile: direct, strict, architecture-first feedback with concrete fixes."
+alwaysApply: false
+---
+
+# b091 Review Profile
+
+## Purpose
+Replicate the b091 review style for requested reviews.
+
+## When To Apply
+Apply when user explicitly asks for review in b091 style.
+
+## Style Profile
+- Direct and concise.
+- Architecture-first.
+- Strongly against duct-tape fixes.
+- Focus on testability and single source of truth.
+
+## What To Flag
+- Business logic in UI instead of store/service.
+- **SOLID & Layering Violations**: Domain stores instantiating or importing UI component stores (e.g. `StepStore` directly owning `@components/...` stores). Domain state must remain decoupled from specific UI representations.
+- PRs containing overloaded, AI-generated boilerplate descriptions ("white noise"). Encourage conciseness.
+- Re-introducing known bad patterns or regressions (e.g., adding UI-specific schema fields to core API DTOs).
+- Duplicate rule checks in multiple places.
+- Unsafe casts (`any`, disguised casts).
+- Mocks inheriting production classes.
+- Loading/no-data semantics confusion.
+- Magic numbers without rationale.
+- **Status/result mapping semantics**: Mapping "none" or absence-of-result to a semantic outcome (e.g. canceled, failed) without domain justification. Verify that source enum values (e.g. none, killed, cancelled) have distinct meanings and that the mapping preserves them; flag mappings that equate semantically different states (e.g. `none === canceled`, `killed === canceled` without explicit product rationale).
+- **Non-null assertions (`!`) in tests** — `value!` papers over real initialization issues (test fixtures that didn't actually run, async state that never arrived). Use type guards, typed fixtures/helper returns, or assertion-based setup (`expect(setter).toHaveBeenCalled()`) instead. Applies to `*.test.ts`, `*.spec.ts`, and `e2e/tests/**`. Codebase removed this pattern project-wide previously; flag re-introductions immediately.
+- **Store method accessibility** — See `core/mobx-store-template.mdc` for definitive rules on public vs private store methods. Key violations to flag:
+  - Public `onChangeX` / `handleX` methods (must be private)
+  - Public `action.bound` that should be private callbacks
+
+## Response Format
+1. Verdict in one line — use the canonical verdict vocabulary (same set as `core/code-review-ai-assistant.mdc`):
+   - `APPROVE` — no blocking issues; changes accepted as-is
+   - `APPROVE WITH SUGGESTIONS` — accepted but improvements noted for follow-up
+   - `REQUEST CHANGES` — has issues that must be fixed before merge
+   - `COMMENT` — informational findings only; no blocking action required
+2. Top 1-3 blocking findings.
+3. Concrete replacement/fix path.
+
+## Guardrails
+- No personal attacks.
+- No empty nitpicks.
+- Keep recommendations lint-safe and scoped.

package/src/gdskills/bundled/rules/core/code-style-patterns.mdc

@@ -0,0 +1,54 @@
+---
+description: "Code style and architecture patterns for TypeScript, React, and MobX."
+alwaysApply: false
+---
+
+# Code Style and Architecture Patterns
+
+## Purpose
+Enforce consistent code style and architecture patterns across TypeScript, React, and MobX code in the frontend project.
+
+## When To Apply
+Apply when reviewing or implementing TypeScript/React/MobX code in the frontend project.
+
+## TypeScript
+- Enforce strict typing; avoid `any`.
+- Use interfaces for component props.
+- Prefer `?.` and `??` over unsafe assertions.
+- Do not use imports like `from \"src/...\"`; use relative paths or approved aliases.
+
+## MobX Patterns
+
+For complete MobX store patterns, see `core/mobx-store-template.mdc`.
+
+Key principles (see canonical source for full detail with examples):
+- All state must use `makeObservable(this)` with explicit decorators
+- Store layout should stay predictable: private fields → public fields → constructor → public methods → private methods
+- Public UI entrypoints called from React should be `@action.bound`, usually as thin `on...` methods
+- Public non-mutating helpers/selectors are not actions and do not use `runInAction`
+- Private API/IO and orchestration belong in private methods; async private methods use `try/catch/finally`
+- Use `runInAction` for private mutation blocks after `await`, and for private orchestration-state updates
+- Wrap React components with `observer`
+- Inter-store callbacks and internal handlers must be private (see `core/mobx-store-template.mdc` for the canonical callback rules)
+- Use equality guards, not truthy checks, when optional values must propagate clearing
+- Implement bounce protection for bidirectional sync
+
+## React
+- Wrap observable-consuming components with `observer`.
+- Keep business logic in stores/services.
+- Avoid heavy logic in render.
+
+## Architecture
+- Service layer: IO/API only.
+- Store layer: business logic and state transitions.
+- Component layer: view rendering.
+- UI components should preferably have their own local MobX store to manage their specific view state and encapsulate UI-specific logic, implementing reactivity via MobX instead of `useState` where possible.
+
+## Review Flags
+- API calls directly in UI components.
+- Missing `observer` where store values are consumed.
+- Direct observable mutation outside actions.
+- Large inline render logic better suited for computed/store methods.
+- Public inter-store callbacks/handlers that should be `private` (e.g. `onChangeEditorState`, `onFireExecutorChange`).
+- Bidirectional store sync without equality guard — risk of infinite callback bounce.
+- Truthy guard (`if (x && x !== y)`) on optional/nullable field — blocks propagation of `undefined`/falsy clearing.

package/src/gdskills/bundled/rules/core/commit-message-formatting.mdc

@@ -0,0 +1,25 @@
+---
+description: "Conventional commit formatting rules."
+alwaysApply: false
+---
+
+# Commit Message Formatting Rules
+
+## Purpose
+Generate concise English conventional commits.
+
+## When To Apply
+Apply whenever creating a git commit message.
+
+## Language
+- Commit messages must be English only.
+
+## Header
+- Use one prefix: `fix:`, `feat:`, `chore:`, `refactor:`, `docs:`, `style:`, `test:`, `perf:`, `ci:`, `build:`.
+- Optional scope: `feat(scope): message` where scope is the affected module (e.g. `feat(pipelines):`, `fix(store):`).
+- Keep header to 72 chars max (including type and scope).
+
+## Body
+- Use short bullets.
+- Describe what changed and user impact.
+- Avoid file lists and implementation minutiae.

package/src/gdskills/bundled/rules/core/database-patterns.mdc

@@ -0,0 +1,162 @@
+---
+description: "Database access patterns: no N+1 queries, indexes before deploy, backward-compatible migrations, transaction discipline. Use when writing queries, migrations, or ORM models."
+alwaysApply: false
+---
+
+# Database Patterns
+
+## Purpose
+Prevent N+1 query explosions, missing indexes, and migration-induced outages. Enforce safe, observable, backward-compatible database changes.
+
+## When To Apply
+Apply when writing ORM queries, creating migrations, designing schema changes, or reviewing data access code.
+
+---
+
+## Rules
+
+### Rule 1: No N+1 Queries
+A query inside a loop is always an N+1 violation. Use eager loading, `JOIN`, or `IN` clause batching.
+
+```typescript
+// BAD — N+1: 1 query for orders + 1 query per order for user
+const orders = await Order.findAll();
+for (const order of orders) {
+  const user = await User.findById(order.userId); // N queries
+  console.log(user.name);
+}
+
+// GOOD — single query with eager load
+const orders = await Order.findAll({ include: [{ model: User }] });
+for (const order of orders) {
+  console.log(order.user.name); // no additional queries
+}
+
+// GOOD alternative — batch with IN clause
+const userIds = orders.map(o => o.userId);
+const users = await User.findAll({ where: { id: userIds } });
+const userMap = new Map(users.map(u => [u.id, u]));
+```
+
+**Detection rule:** Any `findById`, `findOne`, or `findByPk` inside a loop MUST be refactored.
+
+### Rule 2: Index Before Query
+Every WHERE, JOIN, ORDER BY column that does not already have an index MUST have a migration adding one before the feature ships.
+
+```sql
+-- Migration checklist before deploy:
+-- 1. Identify all new WHERE clauses in the feature
+-- 2. Check EXPLAIN ANALYZE on representative data volume
+-- 3. Add indexes for any full-table scans
+
+CREATE INDEX CONCURRENTLY idx_orders_user_id ON orders(user_id);
+-- CONCURRENTLY avoids table lock in production
+```
+
+**Index requirements:**
+- Foreign keys: always indexed
+- Columns used in WHERE with high cardinality: indexed
+- Composite indexes: column order matters (most selective first)
+- Unique constraints: also serve as indexes — declare explicitly
+
+### Rule 3: Backward-Compatible Migrations
+
+Migrations run before code deploys in rolling deployments. The new schema MUST be compatible with both old and new application code simultaneously.
+
+**Safe migration sequence:**
+
+| Change | Safe? | Safe Method |
+|---|---|---|
+| Add nullable column | Yes | Single migration |
+| Add NOT NULL column | No | 3-step: add nullable → backfill → add constraint |
+| Rename column | No | 3-step: add new → copy data → remove old |
+| Remove column | No | 2-step: stop reading in code → migration to drop |
+| Add index | Yes (use CONCURRENTLY) | Single migration |
+| Drop index | Yes | Single migration |
+| Change column type | No | 3-step: add new → migrate data → remove old |
+
+**3-Step pattern for breaking changes:**
+```sql
+-- Step 1 (Deploy A): Add new column as nullable
+ALTER TABLE users ADD COLUMN email_verified_at TIMESTAMP;
+
+-- Deploy new code that writes to both old and new column
+
+-- Step 2 (Deploy B): Backfill + add NOT NULL constraint
+UPDATE users SET email_verified_at = created_at WHERE email_verified_at IS NULL;
+ALTER TABLE users ALTER COLUMN email_verified_at SET NOT NULL;
+
+-- Deploy new code that only reads new column
+
+-- Step 3 (Deploy C): Remove old column (if applicable)
+```
+
+### Rule 4: Transactions for Multi-Step Mutations
+Any operation that writes to multiple tables or performs multiple writes to the same table MUST use a transaction.
+
+```typescript
+// BAD — partial failure leaves data inconsistent
+await userRepo.save(user);
+await walletRepo.create({ userId: user.id, balance: 0 }); // if this fails, orphaned user
+
+// GOOD — atomic operation
+await db.transaction(async (trx) => {
+  await userRepo.save(user, { transaction: trx });
+  await walletRepo.create({ userId: user.id, balance: 0 }, { transaction: trx });
+});
+```
+
+### Rule 5: Never SELECT * in Application Code
+Always select specific columns to avoid:
+- Accidentally loading large TEXT/BLOB columns
+- Breaking when new columns are added to the schema
+- Leaking sensitive fields (passwords, tokens)
+
+```typescript
+// BAD
+const users = await User.findAll(); // loads ALL columns
+
+// GOOD
+const users = await User.findAll({ attributes: ['id', 'name', 'email'] });
+```
+
+### Rule 6: Soft Deletes Need Index on deleted_at
+If using soft deletes (`deleted_at IS NULL` filter), that filter is on every query. Index it:
+
+```sql
+CREATE INDEX idx_users_deleted_at ON users(deleted_at) WHERE deleted_at IS NULL;
+```
+
+---
+
+## Migration Review Checklist
+
+Before merging any migration:
+- [ ] `CONCURRENTLY` used for new indexes on existing tables
+- [ ] NOT NULL columns have a default or backfill in the same migration
+- [ ] No column renames (use 3-step instead)
+- [ ] `EXPLAIN ANALYZE` run on production-scale data for new queries
+- [ ] Rollback plan documented (reverse migration or migration with inverse operation)
+- [ ] Migration is idempotent (safe to run twice: use `IF NOT EXISTS`, `IF EXISTS`)
+
+---
+
+## Iron Laws
+
+**IRON LAW 1: A query inside a loop is an N+1. Fix it before merging.**
+**IRON LAW 2: A NOT NULL column without a backfill migration will fail in production on deploy.**
+**IRON LAW 3: Multi-table writes without a transaction are a data integrity bug.**
+
+---
+
+## Red Flags — Stop and re-read this rule if you are thinking:
+
+| Rationalization | Why it's wrong |
+|---|---|
+| "The table is small, N+1 is fine for now" | Tables grow — N+1 that's "fine now" causes outages at 100k rows |
+| "I'll add the index after it's in production if it's slow" | Adding an index without CONCURRENTLY locks the table in production |
+| "The migration is simple, I don't need a rollback plan" | Every migration that fails in production requires a rollback — having no plan means downtime |
+| "NULL is fine, I'll add NOT NULL later" | Nullable columns become load-bearing nullability over time — enforce constraints early |
+| "SELECT * is easier during development" | SELECT * loaded to production is a query-time performance and security risk |
+
+**IRON LAW: A MIGRATION THAT LOCKS A TABLE ON A BUSY PRODUCTION DATABASE IS A PLANNED OUTAGE.**

package/src/gdskills/bundled/rules/core/documentation-management.mdc

@@ -0,0 +1,106 @@
+---
+description: "Manage project documentation in <PROJECT_DIR>/docs (default) or $GDMETAPRO_DOCS_ROOT with synchronized multilingual outputs."
+alwaysApply: false
+---
+
+# Documentation Management Rules
+
+## Purpose
+Define how the agent creates and updates documentation under `<DOCS_ROOT>` (`<PROJECT_DIR>/docs` by default, or `$GDMETAPRO_DOCS_ROOT`).
+
+## When To Apply
+Apply when the user asks to create or update documentation, plans, requirements, communication notes, reports, or review artifacts.
+
+## Mandatory Behavior
+1. Ask for target location and folder name before writing any doc.
+2. Use date-stamped folders; never overwrite previous doc sets.
+3. Keep language variants synchronized.
+4. Update `<DOCS_ROOT>/README.md` after doc changes.
+5. Ask whether to apply changes (branch/commit/PR) after edits.
+
+## Required Locations
+- Root: `<DOCS_ROOT>` (default: `<PROJECT_DIR>/docs`)
+- Standard pattern: `<DOCS_ROOT>/<category>/<name>-<YYYY-MM-DD>/`
+
+## DOCS_ROOT Resolution
+
+The docs root is resolved in this priority order:
+
+1. **`DOCS_ROOT` passed explicitly** by the orchestrator in the sub-agent dispatch prompt
+2. **`GDMETAPRO_DOCS_ROOT` environment variable** (if set in the shell)
+3. **`<PROJECT_DIR>/docs/`** — default, relative to the project being worked on
+
+```bash
+DOCS_ROOT="${GDMETAPRO_DOCS_ROOT:-$PROJECT_DIR/docs}"
+```
+
+`PROJECT_DIR` is always known by Phase 0.2 of the orchestrator. Sub-agents (context-collector, feature-analyzer, etc.) **never resolve DOCS_ROOT themselves** — they receive it explicitly from the orchestrator.
+
+## Category Definitions
+
+| Category | Path pattern | Description |
+|----------|-------------|-------------|
+| `requirements` | `docs/requirements/<name>/<YYYY-MM-DD>/` | Feature requirements (iterations grouped by name) |
+| `plans` | `docs/plans/<name>/<YYYY-MM-DD>/` | Standalone implementation plans |
+| `report` | `docs/report/<name>/<YYYY-MM-DD>/` | Standalone review/audit reports |
+| `review-testing` | `docs/review-testing/<name>/<YYYY-MM-DD>/` | QA and testing artifacts |
+| `communication` | `docs/communication/<name>/<YYYY-MM-DD>/` | Communication and context docs |
+| `analysis` | `docs/analysis/<name>/<YYYY-MM-DD>/` | Feature/branch analysis (see below) |
+
+## Analysis Category Structure
+
+The `analysis` category is used by the `feature-analyzer` skill and any branch/feature analysis tasks.
+
+```
+docs/analysis/<feature-name>/<YYYY-MM-DD>/
+  report/
+    ru/
+      report.md
+    en/
+      report.md
+    ai/
+      report.md
+  plans/
+    ru/
+      implementation-plan.md
+    en/
+      implementation-plan.md
+    ai/
+      implementation-plan.md
+```
+
+- `report/` — detailed analysis of changes, ticket, cross-repo findings
+- `plans/` — actionable implementation plan derived from the analysis
+- Each subfolder contains `ru/`, `en/`, `ai/` language variants (all three are mandatory)
+
+## Language Matrix
+- Requirements: `ru`, `en`, `ai`
+- Implementation plans: `ru`, `en`, `ai`
+- Communication docs: `ru`, `en`, `ai`
+- Analysis (`report/` + `plans/`): `ru`, `en`, `ai` (mandatory)
+- Other categories: follow explicit user request; default to at least `en`.
+
+## Naming Rules
+- Ask user for `<name>` first.
+- Use semantic, kebab-case folder names.
+- Keep filenames deterministic: `<name>.md` unless user asks another convention.
+
+## Output Contract
+- Every generated document MUST be Markdown (`.md`).
+- Structure must be explicit with headings and actionable sections.
+- Code examples must be fenced code blocks.
+
+## Relationship to `jobs/`
+
+`docs/` and `jobs/` are **separate systems**:
+- `docs/` — general project documentation (requirements, plans, reports, analysis). Managed by this rule.
+- `jobs/` — orchestrator pipeline artifacts. Each job folder documents one orchestrated task end-to-end.
+
+Standalone skill invocations continue to use `docs/analysis/`. Only orchestrator-driven work produces output in `jobs/`.
+See `core/jobs-documentation.mdc` for the `jobs/` system.
+
+## Prohibited
+- Single-language output when the category requires `ru+en+ai`.
+- Partial language updates.
+- Writing docs outside the requested category path without confirmation.
+- Mixing `report/` and `plans/` content in the same file.