@jetrabbits/agentic 0.0.1

package/areas/software/frontend/skills/testing-patterns/SKILL.md

@@ -0,0 +1,69 @@
+# Skill: Frontend Testing Patterns
+
+## When to load
+
+When writing tests for components, hooks, or integration flows.
+
+## Philosophy
+
+Test **behavior**, not implementation. A user doesn't care that you called `setState`; they care that clicking "Submit" shows a success message.
+
+## Component Test Template
+
+```tsx
+import { render, screen } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+import { UserCard } from './UserCard';
+
+const defaultUser: User = {
+  id: '1', name: 'Jane Smith', email: 'jane@example.com', role: 'admin',
+};
+
+describe('UserCard', () => {
+  it('renders user information', () => {
+    render(<UserCard user={defaultUser} />);
+    expect(screen.getByText('Jane Smith')).toBeInTheDocument();
+  });
+
+  it('calls onEdit when edit button is clicked', async () => {
+    const onEdit = vi.fn();
+    render(<UserCard user={defaultUser} onEdit={onEdit} />);
+    await userEvent.click(screen.getByRole('button', { name: /edit/i }));
+    expect(onEdit).toHaveBeenCalledWith(defaultUser.id);
+  });
+});
+```
+
+## Custom Hook Testing
+
+```tsx
+import { renderHook, act } from '@testing-library/react';
+import { useCounter } from './useCounter';
+
+it('increments count', () => {
+  const { result } = renderHook(() => useCounter(0));
+  act(() => { result.current.increment(); });
+  expect(result.current.count).toBe(1);
+});
+```
+
+## MSW: Mock API Calls
+
+```ts
+import { http, HttpResponse } from 'msw';
+
+export const handlers = [
+  http.get('/api/users', () =>
+    HttpResponse.json([{ id: '1', name: 'Jane' }])
+  ),
+];
+```
+
+## Test Type Decision
+
+| Scenario | Test Type |
+|:---|:---|
+| Component renders | Unit (RTL) |
+| User interaction | Unit (RTL + userEvent) |
+| Data fetching states | Unit (RTL + MSW) |
+| Full user journey | E2E (Playwright) |

package/areas/software/frontend/workflows/a11y-fix.md

@@ -0,0 +1,63 @@
+---
+name: a11y-fix
+type: workflow
+trigger: /a11y-fix
+description: Detect, fix, and validate accessibility issues for UI routes or components with WCAG compliance evidence.
+inputs:
+  - target_route_or_component
+outputs:
+  - remediated_accessibility_issues
+  - a11y_report
+roles:
+  - qa
+  - designer
+  - developer
+  - team-lead
+execution:
+  initiator: qa
+related-rules:
+  - accessibility.md
+  - quality.md
+uses-skills:
+  - a11y-audit
+  - testing-patterns
+quality-gates:
+  - no blocking WCAG A issues remaining
+  - keyboard and screen-reader critical paths validated
+  - automated a11y checks pass in CI
+---
+
+## Steps
+
+### 1. Audit & Severity Classification — `@qa`
+- **Input:** target route or component
+- **Actions:** run automated audit (axe, Lighthouse, jest-axe); classify each finding by WCAG level (A / AA / AAA) and user impact; identify keyboard navigation and screen reader critical paths
+- **Output:** `a11y_audit.md` — finding list with WCAG criterion, severity, and affected element
+- **Done when:** all findings classified; critical path issues flagged
+
+### 2. UX Decision for Ambiguous Fixes — `@designer`
+- **Input:** audit findings that require UX judgment (alt text wording, focus order, label copy)
+- **Actions:** review findings requiring design input; provide decisions on: alt text wording, ARIA label content, focus order, color contrast alternatives
+- **Output:** design decisions documented per ambiguous finding
+- **Done when:** all ambiguous findings have designer-approved decisions
+
+### 3. Implement Fixes — `@developer`
+- **Input:** audit + design decisions
+- **Actions:** implement ARIA attributes, role corrections, focus management, color contrast fixes, keyboard handler improvements; follow `accessibility.md` rules; do not introduce visual regressions
+- **Output:** fixes on feature branch
+- **Done when:** all A-level issues addressed; AA issues addressed per project policy
+
+### 4. Re-test & Regression Checks — `@qa`
+- **Input:** fix branch
+- **Actions:** re-run automated audit: zero new WCAG A issues; test keyboard navigation (Tab / Shift+Tab / Enter / Escape / Arrow keys); test with screen reader on at least one critical path; run visual regression to confirm no visual regressions
+- **Output:** updated `a11y_report.md` — before/after comparison
+- **Done when:** zero blocking A issues; critical keyboard and screen reader paths confirmed
+
+### 5. Final Review & Acceptance — `@team-lead`
+- **Input:** a11y report + fix branch
+- **Actions:** verify fixes are complete and don't introduce regressions; sign off on WCAG compliance status
+- **Output:** `@team-lead` approval
+- **Done when:** approved; CI a11y checks added or confirmed
+
+## Exit
+Zero WCAG A issues + screen reader path validated + `@team-lead` approval = a11y fix complete.

package/areas/software/frontend/workflows/bundle-analyze.md

@@ -0,0 +1,56 @@
+---
+name: bundle-analyze
+type: workflow
+trigger: /bundle-analyze
+description: Analyze frontend bundle size impact and produce a prioritized optimization backlog.
+inputs:
+  - build_artifacts
+  - baseline_metrics
+outputs:
+  - bundle_diff_report
+  - optimization_backlog
+roles:
+  - developer
+  - qa
+  - team-lead
+  - pm
+execution:
+  initiator: developer
+related-rules:
+  - performance.md
+  - architecture.md
+uses-skills:
+  - performance-tuning
+quality-gates:
+  - budget regressions triaged with root cause
+  - optimization actions prioritized by impact/effort
+---
+
+## Steps
+
+### 1. Generate & Compare Bundle Metrics — `@developer`
+- **Input:** build artifacts, baseline metrics
+- **Actions:** run bundle analyzer (webpack-bundle-analyzer, vite-bundle-visualizer, source-map-explorer); compare current bundle sizes vs. baseline; flag any chunk exceeding performance budget; identify top contributors to size regression
+- **Output:** bundle diff with size delta per chunk; budget violations flagged
+- **Done when:** all chunks analyzed; violations identified
+
+### 2. Validate Measurement Reliability — `@qa`
+- **Input:** bundle metrics
+- **Actions:** confirm measurement is reproducible (run analysis twice; results within 1%); verify build is production mode (no dev artifacts); confirm baseline was captured under same conditions
+- **Output:** reliability confirmation or flag if measurements inconsistent
+- **Done when:** measurements confirmed reliable
+
+### 3. Prioritize Optimization Candidates — `@team-lead` + `@developer`
+- **Input:** validated diff report
+- **Actions:** rank candidates by: size impact × user impact × implementation effort; flag quick wins (unused imports, missing tree-shaking, large non-split chunks); flag strategic work (route-based code splitting, lazy-loaded components)
+- **Output:** prioritized optimization list with effort estimates
+- **Done when:** list reviewed; quick wins vs. strategic work separated
+
+### 4. Publish Report & Next Actions — `@pm`
+- **Input:** prioritized list
+- **Actions:** produce `bundle_diff_report.md`: current vs. baseline sizes, budget violations, optimization backlog; schedule quick wins as engineering tasks; log strategic work in backlog
+- **Output:** `bundle_diff_report.md`; backlog items created
+- **Done when:** report shared; items logged in project tracker
+
+## Exit
+Report published + backlog items created = bundle analysis complete.

package/areas/software/frontend/workflows/release-prep.md

@@ -0,0 +1,66 @@
+---
+name: release-prep
+type: workflow
+trigger: /release-prep
+description: Prepare a frontend release through coordinated quality, performance, accessibility, and product checks.
+inputs:
+  - release_scope
+  - target_version
+outputs:
+  - release_readiness_decision
+  - release_notes
+roles:
+  - product-owner
+  - pm
+  - developer
+  - qa
+  - team-lead
+execution:
+  initiator: product-owner
+related-rules:
+  - quality.md
+  - performance.md
+  - accessibility.md
+uses-skills:
+  - performance-tuning
+  - testing-patterns
+quality-gates:
+  - all automated checks pass (lint / test / build / a11y / bundle)
+  - regression smoke test passes
+  - release notes approved by product-owner
+---
+
+## Steps
+
+### 1. Confirm Release Scope & Success Criteria — `@product-owner` + `@pm`
+- **Input:** release scope, target version
+- **Actions:** confirm what's in and out of the release; define success criteria for release (metrics, feature flags to enable); align on rollback trigger conditions
+- **Output:** confirmed release scope + success criteria
+- **Done when:** scope locked; `@product-owner` approved
+
+### 2. Execute Build/Lint/Test/Perf Checks — `@developer`
+- **Input:** confirmed scope
+- **Actions:** `make lint` — zero errors; `make test` — all pass; `make build` — production build clean; run bundle analysis against budget; run Lighthouse for performance and a11y scores
+- **Output:** all check results; any regressions flagged
+- **Done when:** all checks pass; no budget regressions or regressions accepted with rationale
+
+### 3. Regression + Smoke Verification — `@qa`
+- **Input:** built release candidate
+- **Actions:** run regression test suite for release scope; run smoke suite on staging with release candidate; confirm critical user paths work end-to-end; run visual regression check on changed routes
+- **Output:** `qa_release_report.md` — suite results, smoke results, visual diff status
+- **Done when:** no blocking failures; go recommendation from `@qa`
+
+### 4. Review Go/No-Go Risks — `@team-lead`
+- **Input:** all check and test results
+- **Actions:** review residual risks; confirm rollback procedure is documented and tested; make explicit go/no-go recommendation
+- **Output:** go/no-go decision with rationale
+- **Done when:** decision explicit; rationale documented
+
+### 5. Publish Release Notes & Decision — `@pm` + `@product-owner`
+- **Input:** go decision
+- **Actions:** `@pm` drafts release notes (features, fixes, known issues); `@product-owner` approves notes; publish to stakeholders; hand off to deployment process
+- **Output:** approved release notes; team informed
+- **Done when:** notes approved; deployment team has green light
+
+## Exit
+Go decision + approved release notes + all checks passed = release ready to deploy.

package/areas/software/frontend/workflows/scaffold-component.md

@@ -0,0 +1,67 @@
+---
+name: scaffold-component
+type: workflow
+trigger: /scaffold-component
+description: Create a reusable UI component with design alignment, implementation, tests, and accessibility checks.
+inputs:
+  - component_request
+  - design_system_context
+outputs:
+  - scaffolded_component
+  - validation_evidence
+roles:
+  - product-owner
+  - designer
+  - developer
+  - qa
+  - team-lead
+execution:
+  initiator: product-owner
+related-rules:
+  - architecture.md
+  - quality.md
+  - accessibility.md
+uses-skills:
+  - component-design
+  - css-architecture
+  - testing-patterns
+quality-gates:
+  - component API documented (props, events, slots)
+  - all component states implemented (loading, empty, error, success)
+  - unit and accessibility tests pass
+---
+
+## Steps
+
+### 1. Component Intent & Acceptance Criteria — `@product-owner` + `@designer`
+- **Input:** component request
+- **Actions:** define component purpose, consumer context, and expected states (loading / empty / error / success / permission-denied); `@designer` specifies interaction design, token usage, and accessibility requirements
+- **Output:** component spec with acceptance criteria and design reference
+- **Done when:** spec approved; all states defined
+
+### 2. Design System Alignment — `@designer`
+- **Input:** component spec
+- **Actions:** verify component fits within existing design system (tokens, spacing, typography, color); flag any new patterns needing design system addition; provide annotated interaction spec or Figma link
+- **Output:** design sign-off; annotated spec with accessibility notes (ARIA roles, keyboard interactions)
+- **Done when:** design aligned; no unresolved design system conflicts
+
+### 3. Component Implementation — `@developer`
+- **Input:** aligned design spec
+- **Actions:** scaffold component files following project structure; implement all states defined in spec; use design tokens only (no hardcoded values); ensure keyboard navigation and ARIA attributes per `accessibility.md`; export clear prop types / interface
+- **Output:** component implemented on feature branch
+- **Done when:** all states implemented; props typed; no hardcoded styles
+
+### 4. Functional & Accessibility Verification — `@qa`
+- **Input:** implemented component
+- **Actions:** verify all states render correctly; run automated accessibility check (axe, Lighthouse); test keyboard navigation: Tab, Enter, Escape, Arrow keys as applicable; verify component in isolation (Storybook or equivalent) and in consumer context
+- **Output:** `validation_evidence.md` — state screenshots, a11y report, keyboard nav results
+- **Done when:** no blocking WCAG A issues; all states verified; keyboard navigation confirmed
+
+### 5. Code Review & Merge Readiness — `@team-lead`
+- **Input:** component branch + validation evidence
+- **Actions:** review component API design (props, events, slots); verify CSS architecture (no specificity leaks, tokens used); check test coverage; approve or return with blocking feedback
+- **Output:** review feedback
+- **Done when:** all blocking feedback resolved; `@team-lead` approves
+
+## Exit
+Accepted component + passing tests + a11y clear = ready to merge and publish to design system.

package/areas/software/frontend/workflows/visual-regression.md

@@ -0,0 +1,65 @@
+---
+name: visual-regression
+type: workflow
+trigger: /visual-regression
+description: Detect, triage, and resolve unintended UI visual diffs before release using snapshot comparison.
+inputs:
+  - changed_ui_scope
+  - baseline_snapshots
+outputs:
+  - visual_diff_report
+  - approved_or_rejected_baseline_update
+roles:
+  - developer
+  - qa
+  - designer
+  - team-lead
+execution:
+  initiator: developer
+related-rules:
+  - quality.md
+  - accessibility.md
+  - performance.md
+uses-skills:
+  - testing-patterns
+  - component-design
+quality-gates:
+  - critical diffs reviewed by designer before baseline update
+  - accepted diffs documented with rationale
+  - no unreviewed diffs merged
+---
+
+## Steps
+
+### 1. Determine Visual Test Scope — `@developer`
+- **Input:** changed UI components or routes
+- **Actions:** identify which components and routes are affected by current changes; confirm baseline snapshots are up to date for the scope
+- **Output:** test scope list
+- **Done when:** scope defined; baseline verified
+
+### 2. Run Capture & Comparison Suite — `@qa`
+- **Input:** test scope
+- **Actions:** run visual regression tool (Percy, Chromatic, Playwright snapshots) against current branch; generate diff images for all changed snapshots
+- **Output:** visual diff report with diff images per component/route
+- **Done when:** all diffs captured; report generated
+
+### 3. Classify Diffs — `@designer` + `@qa`
+- **Input:** visual diff report
+- **Actions:** per diff: expected (intentional change matching design spec) vs. unexpected (unintended regression); `@designer` reviews all diffs involving design decisions; `@qa` flags unexpected diffs as blockers
+- **Output:** classification per diff: approved / rejected / needs designer review
+- **Done when:** all diffs classified; no diffs in "unknown" state
+
+### 4. Fix or Approve Baseline Updates — `@developer` + `@designer`
+- **Input:** classified diffs
+- **Actions:** rejected (unexpected): `@developer` fixes the regression; approved (expected): update baseline snapshots with `@designer` explicit sign-off; document rationale for each approved baseline change
+- **Output:** fixed code or updated baselines with documentation
+- **Done when:** all rejected diffs fixed; all approved baselines updated with sign-off
+
+### 5. Final Gate Decision — `@team-lead`
+- **Input:** updated branch + baseline sign-offs
+- **Actions:** verify all regressions fixed; confirm all approved baseline updates have designer sign-off; approve merge
+- **Output:** merge approval
+- **Done when:** all diffs resolved; no unreviewed changes
+
+## Exit
+Zero unexpected diffs + all baseline updates designer-approved + `@team-lead` sign-off = visual review complete.

package/areas/software/full-stack/AGENTS.md

@@ -0,0 +1,72 @@
+# Full Stack — guidance index
+
+## What this area covers
+
+End-to-end product feature development spanning backend services and frontend interfaces: API design, backend architecture, database access, async processing, frontend integration, testing pipelines, and full project lifecycle management.
+
+## Guidance chain
+
+1. Project `.agent/` baseline (`AGENTS.md` + `.agent/*`)
+2. `software/general/rules/*` — always active
+3. `full-stack/rules/*` — load all for this spec
+4. `full-stack/skills/*/SKILL.md` — load only the skill matching the current task
+5. `full-stack/workflows/*` — load the workflow matching the triggered command
+
+## Inherited from general
+
+- SDLC methodology, role responsibilities, and handoff contracts
+- Git / CI / lint / format and code style baselines
+- General development and code review workflows
+
+## Full-stack-specific constraints
+
+- API contracts are versioned and documented before implementation; no breaking changes without a migration path.
+- Frontend and backend changes for the same feature ship together in a coordinated, backward-compatible rollout.
+- Every new feature includes end-to-end tests covering at least the critical user path.
+
+## Spec map
+
+```text
+full-stack/
+├── rules/
+│   ├── api-design-guide.md            ← REST/GraphQL/tRPC conventions, versioning
+│   ├── backend-architecture-rule.md   ← layering, module boundaries, DI
+│   ├── database-access-guide.md       ← ORM patterns, query safety, N+1 prevention
+│   ├── database-migrations-guide.md   ← migration safety, backward compatibility
+│   ├── async-concurrency-guide.md     ← queues, workers, deadlock prevention
+│   ├── background-jobs-guide.md       ← job design, retry, DLQ
+│   ├── error-handling-guide.md        ← error taxonomy, propagation, user messaging
+│   ├── logging-observability-guide.md ← structured logs, trace IDs, metrics
+│   ├── security-guide.md              ← authN/authZ, input validation, secret handling
+│   ├── testing-ci-guide.md            ← test pyramid, CI checks, coverage thresholds
+│   ├── e2e-test-guide.md              ← e2e tool setup, test scope, flakiness policy
+│   ├── code-quality-guide.md          ← naming, DRY, single responsibility
+│   ├── env-settings-guide.md          ← environment config, secrets, local setup
+│   ├── domain-models-guide.md         ← entity design, value objects, aggregates
+│   └── project-guide.md               ← folder structure, module boundaries, tech stack
+├── skills/
+│   ├── api-design-principles/SKILL.md   ← REST best practices, GraphQL schema design
+│   ├── api-patterns/SKILL.md            ← auth, rate limiting, versioning, tRPC
+│   ├── app-builder/SKILL.md             ← project scaffolding, templates, tech stack detection
+│   ├── backend-developer/SKILL.md       ← service patterns, DI, repository design
+│   ├── python-pro/SKILL.md              ← Python idioms, packaging, async patterns
+│   ├── bash-pro/SKILL.md                ← shell scripting, automation, CI helpers
+│   ├── blackbox-test/SKILL.md           ← external API testing, contract validation
+│   ├── prompt-project-planner/SKILL.md  ← project planning, milestone scoping
+│   └── skill-creator/SKILL.md           ← authoring new skills for this repo
+├── workflows/
+│   ├── develop-feature.md              ← /develop-feature
+│   ├── debug-issue.md                  ← /debug-issue
+│   ├── backend-project-full-cycle.md   ← /backend-project-full-cycle
+│   ├── feature-implementation-flow.md  ← /feature-implementation-flow
+│   └── testing-ci-pipeline.md          ← /testing-ci-pipeline
+└── prompts/
+    └── *.md
+```
+
+## Discovery patterns
+
+- `rules/*.md`
+- `skills/*/SKILL.md`
+- `workflows/*.md`
+- `prompts/*.md`

package/areas/software/full-stack/PROMPTS.md

@@ -0,0 +1,66 @@
+# PROMPTS: full-stack
+
+Use these prompts with `full-stack/AGENTS.md` from the same directory.
+
+## 1) Backend Feature Impl
+
+```text
+# Prompt: Backend Feature Implementation
+workflow: feature-implementation-flow
+
+# Context
+feature_request: >
+  Add a "refund_order" endpoint.
+  - Input: order_id, reason
+  - Logic: Check if order is PAID. If yes, create transaction, update status to REFUNDED, emit event.
+  - If order is not PAID, return 400.
+
+# Constraints
+existing_codebase: ./src
+```
+
+## 2) Backend New Project
+
+```text
+# Prompt: New Backend Project
+workflow: backend-project-full-cycle
+
+# Project Details
+project_name: order-service
+project_dir: src
+business_logic_description: >
+  A service to manage customer orders.
+  - Create Order (Draft)
+  - Pay Order (Processing -> Paid)
+  - Cancel Order
+  - List Orders (with pagination)
+
+# Tech Stack (Optional - Agent will ask if omitted)
+tech_stack:
+  language: Python 3.12
+  framework: FastAPI
+  database: PostgreSQL
+  messaging: RabbitMQ
+```
+
+## 3) Backend Run Tests
+
+```text
+# Prompt: Run Tests (Backend)
+workflow: testing-ci-pipeline
+
+# Inputs
+project_type: backend
+test_scope: all
+```
+
+## 4) Frontend Run Tests
+
+```text
+# Prompt: Run Tests (Frontend)
+workflow: testing-ci-pipeline
+
+# Inputs
+project_type: frontend
+test_scope: unit
+```

package/areas/software/full-stack/prompts/backend-project-full-cycle.md

@@ -0,0 +1,141 @@
+---
+workflow: backend-project-full-cycle
+---
+
+# Prompt: `/backend-project-full-cycle`
+
+Use when: scaffolding a new Python/FastAPI backend service from scratch — architecture plan, project structure, Makefile, CI, and initial domain implementation.
+
+---
+
+## Example 1 — Domain API service
+
+**EN:**
+```
+/backend-project-full-cycle
+
+Project name: order-service
+Directory: src/
+Business logic:
+  - Create Order (status: Draft → Paid → Cancelled / Refunded)
+  - Add / remove Order Items (product_id, quantity, unit_price)
+  - Pay Order — validate item availability, create payment record, emit OrderPaid event
+  - Cancel Order — only if status is Draft or Paid (not Refunded)
+  - List Orders for a user with cursor pagination (limit 20 default)
+Tech stack:
+  language: Python 3.12
+  framework: FastAPI (async)
+  database: PostgreSQL 16 via SQLAlchemy (async) + Alembic
+  messaging: RabbitMQ (pika-async) for outbound events
+  task queue: none (synchronous only for now)
+  testing: pytest + pytest-asyncio + httpx
+  CI: GitHub Actions
+Non-functional: all DB operations async; Pydantic BaseSettings for config;
+                structured JSON logs (structlog); Makefile with install/dev/test/lint/fmt targets
+```
+
+**RU:**
+```
+/backend-project-full-cycle
+
+Название проекта: order-service
+Директория: src/
+Бизнес логика:
+  - Создание Заказа (статус: Draft → Paid → Cancelled / Refunded)
+  - Добавление / удаление позиций заказа (product_id, quantity, unit_price)
+  - Оплата заказа — валидация доступности позиций, создание записи платежа, отправка события OrderPaid
+  - Отмена заказа — только если статус Draft или Paid (не Refunded)
+  - Список заказов пользователя с cursor пагинацией (по умолчанию limit 20)
+Стек технологий:
+  язык: Python 3.12
+  фреймворк: FastAPI (async)
+  база данных: PostgreSQL 16 через SQLAlchemy (async) + Alembic
+  сообщения: RabbitMQ (pika-async) для исходящих событий
+  очередь задач: нет (только синхронно пока)
+  тестирование: pytest + pytest-asyncio + httpx
+  CI: GitHub Actions
+Нефункциональные: все операции с БД async; Pydantic BaseSettings для конфигурации;
+                  структурированные JSON логи (structlog); Makefile с targets install/dev/test/lint/fmt
+```
+
+---
+
+## Example 2 — Internal tool / simple CRUD
+
+**EN:**
+```
+/backend-project-full-cycle
+
+Project name: inventory-service
+Directory: src/
+Business logic:
+  - CRUD for Products (name, sku, price, stock_quantity)
+  - Stock reservation: reserve N units for an order (atomic, prevents oversell)
+  - Stock release: release reserved units (on order cancel)
+  - Low-stock alert: GET /products/low-stock returns products where stock < threshold
+Tech stack:
+  language: Python 3.12
+  framework: FastAPI
+  database: PostgreSQL via SQLAlchemy async
+  messaging: none
+  testing: pytest
+  CI: GitLab CI
+Scale: internal service, ~100 req/min peak, no need for caching yet
+No auth: internal network only (API key via X-API-Key header is sufficient)
+```
+
+**RU:**
+```
+/backend-project-full-cycle
+
+Название проекта: inventory-service
+Директория: src/
+Бизнес логика:
+  - CRUD для Products (name, sku, price, stock_quantity)
+  - Резервирование запасов: зарезервировать N единиц для заказа (атомарно, предотвращает oversell)
+  - Освобождение запасов: освободить зарезервированные единицы (при отмене заказа)
+  - Алерт о низком запасе: GET /products/low-stock возвращает продукты где stock < threshold
+Стек технологий:
+  язык: Python 3.12
+  фреймворк: FastAPI
+  база данных: PostgreSQL через SQLAlchemy async
+  сообщения: нет
+  тестирование: pytest
+  CI: GitLab CI
+Масштаб: внутренний сервис, ~100 req/min в пике, кэширование пока не нужно
+Без auth: только внутренняя сеть (API ключ через заголовок X-API-Key достаточно)
+```
+
+---
+
+## Example 3 — Minimal / Quick scaffold
+
+**EN:**
+```
+/backend-project-full-cycle
+
+Project name: webhook-receiver
+Directory: .
+Business logic:
+  - Receive POST /webhooks/{provider} with HMAC signature verification
+  - Store raw payload to PostgreSQL (table: webhook_events)
+  - Enqueue for processing (Redis list: webhook_queue)
+  - GET /webhooks/{id} to check processing status
+Tech stack: Python 3.12, FastAPI, PostgreSQL, Redis, pytest, GitHub Actions
+Keep minimal: no domain layers needed — single service file is fine; focus on correctness
+```
+
+**RU:**
+```
+/backend-project-full-cycle
+
+Название проекта: webhook-receiver
+Директория: .
+Бизнес логика:
+  - Приём POST /webhooks/{provider} с верификацией HMAC подписи
+  - Сохранение сырого payload в PostgreSQL (таблица: webhook_events)
+  - Постановка в очередь для обработки (Redis list: webhook_queue)
+  - GET /webhooks/{id} для проверки статуса обработки
+Стек: Python 3.12, FastAPI, PostgreSQL, Redis, pytest, GitHub Actions
+Минималистично: слои домена не нужны — один service файл подойдёт; фокус на корректности
+```