@jetrabbits/agentic 0.0.1

package/areas/software/security/prompts/compliance-report.md

@@ -0,0 +1,113 @@
+---
+workflow: compliance-report
+---
+
+# Prompt: `/compliance-report`
+
+Use when: generating a compliance evidence report for a specific framework (SOC 2, PCI-DSS, GDPR, ISO 27001) — mapping controls to evidence and identifying gaps.
+
+---
+
+## Example 1 — SOC 2 Type II readiness
+
+**EN:**
+```
+/compliance-report
+
+Framework: SOC 2 Type II (Trust Service Criteria: Security + Availability)
+Scope: order-service, payment-service, user-service (production AWS environment)
+Audit window: last 12 months
+Evidence sources to collect:
+  - Access control: IAM role assignments, MFA enforcement logs (AWS CloudTrail)
+  - Change management: PR merge records, CI/CD pipeline logs (GitHub Actions)
+  - Incident response: PagerDuty incident log, postmortem documents
+  - Monitoring: CloudWatch alarm configs, uptime records (SLA: 99.9%)
+  - Encryption: KMS key policies, S3 bucket encryption settings
+Gaps from last audit: CC6.1 (access review not documented quarterly)
+Output: compliance-report-soc2-2024.md — control matrix with evidence links + gap list
+```
+
+**RU:**
+```
+/compliance-report
+
+Фреймворк: SOC 2 Type II (Trust Service Criteria: Security + Availability)
+Скоуп: order-service, payment-service, user-service (production AWS окружение)
+Период аудита: последние 12 месяцев
+Источники доказательств для сбора:
+  - Контроль доступа: назначения IAM ролей, логи соблюдения MFA (AWS CloudTrail)
+  - Управление изменениями: записи мержа PR, логи CI/CD pipeline (GitHub Actions)
+  - Реагирование на инциденты: лог инцидентов PagerDuty, документы postmortem
+  - Мониторинг: конфигурации алармов CloudWatch, записи uptime (SLA: 99.9%)
+  - Шифрование: политики KMS ключей, настройки шифрования S3 bucket
+Пробелы с прошлого аудита: CC6.1 (ежеквартальный ревью доступа не задокументирован)
+Результат: compliance-report-soc2-2024.md — матрица контролей со ссылками на доказательства + список пробелов
+```
+
+---
+
+## Example 2 — GDPR data processing audit
+
+**EN:**
+```
+/compliance-report
+
+Framework: GDPR (EU) — Articles 13, 14, 17, 30
+Concern: new analytics pipeline collects user behaviour events — need DPA review
+Data flows to document:
+  - User events → Kafka → ClickHouse (EU region) — retention 90 days
+  - Aggregated reports → BigQuery (EU region) — retention 3 years
+  - Raw events → S3 (EU region) — retention 30 days
+PII in events: user_id (pseudonymised), session_id, country, browser
+Legal basis: legitimate interest (analytics) — documented in privacy policy v3.2
+Right to erasure: user_id hash deletion must cascade to ClickHouse + BigQuery
+Output: Article 30 record of processing + erasure procedure + DPA checklist
+```
+
+**RU:**
+```
+/compliance-report
+
+Фреймворк: GDPR (EU) — Статьи 13, 14, 17, 30
+Озабоченность: новый analytics pipeline собирает события поведения пользователей — нужно ревью DPA
+Потоки данных для документирования:
+  - Пользовательские события → Kafka → ClickHouse (EU регион) — хранение 90 дней
+  - Агрегированные отчёты → BigQuery (EU регион) — хранение 3 года
+  - Сырые события → S3 (EU регион) — хранение 30 дней
+PII в событиях: user_id (псевдоанонимизирован), session_id, country, browser
+Правовое основание: законный интерес (аналитика) — задокументировано в политике конфиденциальности v3.2
+Право на удаление: удаление хэша user_id должно каскадироваться в ClickHouse + BigQuery
+Результат: Запись обработки по Статье 30 + процедура удаления + чеклист DPA
+```
+
+---
+
+## Example 3 — Quick / PCI-DSS scope check
+
+**EN:**
+```
+/compliance-report
+
+Framework: PCI-DSS v4.0 — scope assessment only (not full audit)
+Question: does our new in-app chat feature bring card data into PCI scope?
+Context: chat allows users to type free text; could contain card numbers
+Assessment needed:
+  - Is chat text stored? Where? How long?
+  - Is there PAN detection / masking on input?
+  - Does Stripe.js token flow bypass our servers?
+Output: scope determination (in-scope / out-of-scope) with justification + required controls if in-scope
+```
+
+**RU:**
+```
+/compliance-report
+
+Фреймворк: PCI-DSS v4.0 — только оценка скоупа (не полный аудит)
+Вопрос: попадает ли наша новая функция внутреннего чата в скоуп PCI из-за данных карт?
+Контекст: чат позволяет пользователям вводить произвольный текст; может содержать номера карт
+Необходимая оценка:
+  - Хранится ли текст чата? Где? Как долго?
+  - Есть ли обнаружение PAN / маскирование на вводе?
+  - Обходит ли Stripe.js токен flow наши серверы?
+Результат: определение скоупа (в скоупе / вне скоупа) с обоснованием + необходимые контроли если в скоупе
+```

package/areas/software/security/prompts/pen-test-sim.md

@@ -0,0 +1,113 @@
+---
+workflow: pen-test-sim
+---
+
+# Prompt: `/pen-test-sim`
+
+Use when: simulating a penetration test on a staging environment to find exploitable vulnerabilities before they reach production.
+
+---
+
+## Example 1 — Full web application pen test
+
+**EN:**
+```
+/pen-test-sim
+
+Target: https://staging.myapp.com (isolated staging — not production)
+Scope: web application only; infrastructure out of scope
+Authorization: confirmed — written sign-off from CTO (attached)
+Application type: SPA (React) + REST API (FastAPI) + PostgreSQL
+Auth mechanism: JWT (RS256) in Authorization header + refresh token in HttpOnly cookie
+Test areas (OWASP Top 10 focus):
+  - A01 Broken Access Control: IDOR on /api/orders/{id}, horizontal privilege escalation
+  - A02 Cryptographic Failures: JWT algorithm confusion (RS256→HS256), weak token entropy
+  - A03 Injection: SQL injection in search/filter params, NoSQL injection if applicable
+  - A07 Identity/Auth Failures: brute force, credential stuffing, session fixation
+  - A09 Logging Failures: verify audit events present for sensitive actions
+Test accounts: admin@test.myapp.com / viewer@test.myapp.com (credentials in vault)
+Output: pentest-report.md — finding per OWASP category, CVSS score, PoC, remediation
+```
+
+**RU:**
+```
+/pen-test-sim
+
+Цель: https://staging.myapp.com (изолированный staging — не production)
+Скоуп: только веб-приложение; инфраструктура вне скоупа
+Авторизация: подтверждена — письменное согласие от CTO (приложено)
+Тип приложения: SPA (React) + REST API (FastAPI) + PostgreSQL
+Механизм auth: JWT (RS256) в Authorization header + refresh token в HttpOnly cookie
+Области тестирования (фокус OWASP Top 10):
+  - A01 Broken Access Control: IDOR на /api/orders/{id}, горизонтальная эскалация привилегий
+  - A02 Cryptographic Failures: JWT algorithm confusion (RS256→HS256), слабая энтропия токена
+  - A03 Injection: SQL injection в параметрах поиска/фильтрации, NoSQL injection если применимо
+  - A07 Identity/Auth Failures: brute force, credential stuffing, session fixation
+  - A09 Logging Failures: проверить наличие audit событий для чувствительных действий
+Тестовые аккаунты: admin@test.myapp.com / viewer@test.myapp.com (credentials в vault)
+Результат: pentest-report.md — находка по категории OWASP, CVSS оценка, PoC, устранение
+```
+
+---
+
+## Example 2 — API-only targeted test
+
+**EN:**
+```
+/pen-test-sim
+
+Target: staging API — https://api-staging.myapp.com/api/v1
+Scope: REST API endpoints only (no frontend, no infrastructure)
+Focus: authentication bypass and authorisation boundary violations
+Specific concern: new multi-tenant feature — verify tenant A cannot access tenant B data
+Test vectors:
+  - JWT tampering: modify tenant_id claim, try none algorithm
+  - Forced browsing: enumerate /api/v1/tenants/{id}/... with ids 1–1000
+  - Mass assignment: send undocumented fields in PATCH requests
+  - Rate limiting: confirm 429 on /api/v1/auth/token after 10 failed attempts
+Tools: Burp Suite CE, custom Python scripts
+Output: findings per endpoint with HTTP request/response evidence
+```
+
+**RU:**
+```
+/pen-test-sim
+
+Цель: staging API — https://api-staging.myapp.com/api/v1
+Скоуп: только REST API эндпоинты (без фронтенда, без инфраструктуры)
+Фокус: обход аутентификации и нарушения границ авторизации
+Конкретная озабоченность: новая multi-tenant фича — убедиться что tenant A не может получить данные tenant B
+Тестовые векторы:
+  - JWT tampering: изменить claim tenant_id, попробовать алгоритм none
+  - Forced browsing: перечислить /api/v1/tenants/{id}/... с id 1–1000
+  - Mass assignment: отправить недокументированные поля в PATCH запросах
+  - Rate limiting: убедиться в 429 на /api/v1/auth/token после 10 неудачных попыток
+Инструменты: Burp Suite CE, кастомные Python скрипты
+Результат: находки по эндпоинту с доказательствами HTTP запрос/ответ
+```
+
+---
+
+## Example 3 — Quick / Auth flow check
+
+**EN:**
+```
+/pen-test-sim
+
+Scope: authentication flow only — login, registration, password reset
+Target: staging environment
+Check: password reset token entropy (should be ≥ 128 bits); token expiry enforced;
+reset link single-use; account enumeration via timing attack on /auth/login
+Output: pass/fail per check with evidence; critical findings block release
+```
+
+**RU:**
+```
+/pen-test-sim
+
+Скоуп: только поток аутентификации — вход, регистрация, сброс пароля
+Цель: staging окружение
+Проверить: энтропия токена сброса пароля (должна быть ≥ 128 бит); истечение токена соблюдается;
+ссылка для сброса одноразовая; перечисление аккаунтов через timing attack на /auth/login
+Результат: pass/fail по каждой проверке с доказательствами; критические находки блокируют релиз
+```

package/areas/software/security/prompts/secret-rotation.md

@@ -0,0 +1,115 @@
+---
+workflow: secret-rotation
+---
+
+# Prompt: `/secret-rotation`
+
+Use when: rotating credentials, API keys, or certificates without service downtime — using the dual-read window pattern.
+
+---
+
+## Example 1 — Database password rotation
+
+**EN:**
+```
+/secret-rotation
+
+Secret type: PostgreSQL superuser password (prod)
+Reason: scheduled quarterly rotation (compliance requirement)
+Services consuming this secret: order-service, payment-service, analytics-service
+Secret manager: AWS Secrets Manager
+Current secret name: prod/db/postgres-password
+Rotation strategy: dual-read window
+  Phase 1: create new password, store as prod/db/postgres-password-new
+  Phase 2: deploy all services with dual-read (try new → fall back to old)
+  Phase 3: verify all services healthy with new password
+  Phase 4: revoke old password, rename new → canonical
+Rollback plan: revert all services to old secret if error rate > 0.1% in Phase 3
+Zero-downtime requirement: yes — prod traffic must not be interrupted
+```
+
+**RU:**
+```
+/secret-rotation
+
+Тип секрета: пароль суперпользователя PostgreSQL (prod)
+Причина: плановая квартальная ротация (требование compliance)
+Сервисы использующие этот секрет: order-service, payment-service, analytics-service
+Secret manager: AWS Secrets Manager
+Текущее имя секрета: prod/db/postgres-password
+Стратегия ротации: dual-read window
+  Фаза 1: создать новый пароль, сохранить как prod/db/postgres-password-new
+  Фаза 2: задеплоить все сервисы с dual-read (пробовать новый → откат к старому)
+  Фаза 3: убедиться что все сервисы здоровы с новым паролем
+  Фаза 4: отозвать старый пароль, переименовать новый → канонический
+План отката: откатить все сервисы к старому секрету если error rate > 0.1% в Фазе 3
+Требование zero-downtime: да — прод трафик не должен прерываться
+```
+
+---
+
+## Example 2 — Third-party API key rotation (after suspected leak)
+
+**EN:**
+```
+/secret-rotation
+
+Secret type: Stripe secret API key (sk_live_...)
+Reason: URGENT — key found in git history (commit abc1234, merged 6 days ago)
+Risk: key may be compromised; unknown if exploited
+Immediate actions needed:
+  1. Generate new Stripe key NOW via Stripe dashboard
+  2. Deploy new key to all environments (prod, staging) within 30 minutes
+  3. Revoke old key in Stripe dashboard
+  4. Audit Stripe dashboard for unexpected API calls in last 6 days
+  5. Add git-secrets / trufflehog pre-commit hook to prevent recurrence
+Services affected: payment-service, subscription-service
+Secret manager: HashiCorp Vault
+```
+
+**RU:**
+```
+/secret-rotation
+
+Тип секрета: Stripe secret API key (sk_live_...)
+Причина: СРОЧНО — ключ найден в git истории (коммит abc1234, слит 6 дней назад)
+Риск: ключ может быть скомпрометирован; неизвестно был ли использован
+Немедленные действия:
+  1. Сгенерировать новый Stripe ключ СЕЙЧАС через Stripe dashboard
+  2. Задеплоить новый ключ во все окружения (prod, staging) в течение 30 минут
+  3. Отозвать старый ключ в Stripe dashboard
+  4. Проверить Stripe dashboard на неожиданные API вызовы за последние 6 дней
+  5. Добавить git-secrets / trufflehog pre-commit hook для предотвращения рецидива
+Затронутые сервисы: payment-service, subscription-service
+Secret manager: HashiCorp Vault
+```
+
+---
+
+## Example 3 — TLS certificate renewal
+
+**EN:**
+```
+/secret-rotation
+
+Secret type: TLS certificate for api.myapp.com (Let's Encrypt)
+Reason: certificate expires in 14 days (automated renewal failed)
+Current location: Kubernetes Secret tls-api-cert in namespace prod
+Renewal tool: cert-manager (already installed, renewal should be automatic)
+Diagnose: check cert-manager logs for renewal failure reason
+After renewal: verify new cert loaded by nginx ingress without pod restart
+Alert: set up monitoring alert if cert expiry < 30 days
+```
+
+**RU:**
+```
+/secret-rotation
+
+Тип секрета: TLS сертификат для api.myapp.com (Let's Encrypt)
+Причина: сертификат истекает через 14 дней (автоматическое обновление не сработало)
+Текущее расположение: Kubernetes Secret tls-api-cert в namespace prod
+Инструмент обновления: cert-manager (уже установлен, обновление должно быть автоматическим)
+Диагностика: проверить логи cert-manager на причину сбоя обновления
+После обновления: убедиться что новый сертификат загружен nginx ingress без перезапуска подов
+Оповещение: настроить monitoring alert если истечение cert < 30 дней
+```

package/areas/software/security/prompts/security-scan.md

@@ -0,0 +1,91 @@
+---
+workflow: security-scan
+---
+
+# Prompt: `/security-scan`
+
+Use when: running a full automated security sweep — SAST, dependency audit, secrets detection, IaC checks — before a release or after a major change.
+
+---
+
+## Example 1 — Pre-release security gate
+
+**EN:**
+```
+/security-scan
+
+Trigger: release candidate v2.5.0 ready for staging sign-off
+Scope: full — SAST + dependency CVEs + secrets + IaC (Terraform)
+Stack: Python 3.12 / FastAPI, PostgreSQL, Redis, Terraform (AWS)
+Tools available: bandit, ruff, safety, trufflehog, tfsec, semgrep
+Severity threshold: block release on any Critical or High; report Medium/Low
+Output: security-scan-report.md with findings, severity, remediation steps
+Branch: release/2.5.0
+```
+
+**RU:**
+```
+/security-scan
+
+Триггер: release candidate v2.5.0 готов к sign-off на staging
+Скоуп: полный — SAST + CVE зависимостей + секреты + IaC (Terraform)
+Стек: Python 3.12 / FastAPI, PostgreSQL, Redis, Terraform (AWS)
+Доступные инструменты: bandit, ruff, safety, trufflehog, tfsec, semgrep
+Порог серьёзности: блокировать релиз на любом Critical или High; отчитываться о Medium/Low
+Результат: security-scan-report.md с находками, серьёзностью, шагами устранения
+Ветка: release/2.5.0
+```
+
+---
+
+## Example 2 — Post-incident targeted scan
+
+**EN:**
+```
+/security-scan
+
+Trigger: post-incident — suspected SQL injection in orders module (INC-2024-088)
+Scope: targeted — SAST only on src/api/ and src/repositories/; dependency audit for SQLAlchemy
+Priority: SQL injection patterns, unsanitised inputs, ORM bypass risks
+Skip: IaC scan, secrets scan (already clean, saves time)
+Output: findings with code location + PoC query if reproducible
+Timeframe: results needed within 2 hours for incident postmortem
+```
+
+**RU:**
+```
+/security-scan
+
+Триггер: после инцидента — подозрение на SQL injection в модуле orders (INC-2024-088)
+Скоуп: целевой — только SAST на src/api/ и src/repositories/; аудит зависимостей для SQLAlchemy
+Приоритет: паттерны SQL injection, неэкранированные входные данные, риски обхода ORM
+Пропустить: IaC сканирование, проверку секретов (уже чисто, экономия времени)
+Результат: находки с расположением кода + PoC запрос если воспроизводимо
+Срок: результаты нужны в течение 2 часов для postmortem инцидента
+```
+
+---
+
+## Example 3 — Dependency-only quick scan
+
+**EN:**
+```
+/security-scan
+
+Scope: dependency CVE audit only
+Stack: Node.js 20 / Express, npm lockfile
+Command: npm audit --audit-level=high
+Auto-fix: apply non-breaking patches automatically (npm audit fix)
+Report: list packages with unresolved High/Critical CVEs that need manual review
+```
+
+**RU:**
+```
+/security-scan
+
+Скоуп: только аудит CVE зависимостей
+Стек: Node.js 20 / Express, npm lockfile
+Команда: npm audit --audit-level=high
+Авто-исправление: применить неломающие патчи автоматически (npm audit fix)
+Отчёт: список пакетов с неустранёнными High/Critical CVE которые требуют ручного ревью
+```

package/areas/software/security/prompts/threat-model-review.md

@@ -0,0 +1,105 @@
+---
+workflow: threat-model-review
+---
+
+# Prompt: `/threat-model-review`
+
+Use when: reviewing an existing or new system design for security threats using STRIDE methodology before implementation or as part of an architecture review.
+
+---
+
+## Example 1 — New feature threat model
+
+**EN:**
+```
+/threat-model-review
+
+Feature: "OAuth2 social login (Google + GitHub)"
+Stage: pre-implementation design review
+System context:
+  - Current auth: username/password with JWT (RS256)
+  - Adding: OAuth2 authorization code flow
+  - New components: OAuth callback endpoint, state parameter store (Redis), token exchange
+  - User data stored: OAuth provider user ID, email, profile picture URL
+Threat focus: token interception, CSRF via state param, account takeover via email collision
+Assets to protect: user session, OAuth tokens, account linkage integrity
+Output: STRIDE threat table + prioritised mitigations + go/no-go recommendation
+```
+
+**RU:**
+```
+/threat-model-review
+
+Фича: "OAuth2 социальный вход (Google + GitHub)"
+Этап: ревью дизайна до реализации
+Системный контекст:
+  - Текущая auth: username/password с JWT (RS256)
+  - Добавляем: OAuth2 authorization code flow
+  - Новые компоненты: OAuth callback endpoint, хранилище state параметра (Redis), обмен токенов
+  - Хранимые данные пользователя: OAuth provider user ID, email, URL фото профиля
+Фокус угроз: перехват токена, CSRF через state параметр, захват аккаунта через коллизию email
+Защищаемые активы: пользовательская сессия, OAuth токены, целостность привязки аккаунта
+Результат: таблица угроз STRIDE + приоритизированные меры защиты + рекомендация go/no-go
+```
+
+---
+
+## Example 2 — Architecture-level review
+
+**EN:**
+```
+/threat-model-review
+
+System: payment processing service (PCI-DSS scope)
+Review type: full architecture threat model (annual review)
+Architecture:
+  - Public API gateway → payment-service (internal) → Stripe API
+  - Card data: never stored locally; tokenised via Stripe.js on client
+  - Sensitive fields: card_last4, billing_address stored in payments table
+  - Internal comms: mTLS between services
+  - Admin access: VPN + MFA required
+Compliance: PCI-DSS SAQ-A (card data handled by Stripe only)
+Output: DFD diagram description + STRIDE analysis per trust boundary + compliance gap list
+```
+
+**RU:**
+```
+/threat-model-review
+
+Система: сервис обработки платежей (зона PCI-DSS)
+Тип ревью: полная threat model архитектуры (ежегодное ревью)
+Архитектура:
+  - Публичный API gateway → payment-service (внутренний) → Stripe API
+  - Данные карт: никогда не хранятся локально; токенизируются через Stripe.js на клиенте
+  - Чувствительные поля: card_last4, billing_address хранятся в таблице payments
+  - Внутренние коммуникации: mTLS между сервисами
+  - Доступ администратора: VPN + MFA обязательны
+Соответствие: PCI-DSS SAQ-A (данные карт обрабатываются только Stripe)
+Результат: описание DFD диаграммы + STRIDE анализ на каждой границе доверия + список несоответствий
+```
+
+---
+
+## Example 3 — Quick / Single endpoint review
+
+**EN:**
+```
+/threat-model-review
+
+Scope: single endpoint — POST /admin/users/{id}/impersonate
+Context: allows support team to log in as any user for debugging
+Concerns: privilege escalation, audit trail completeness, session isolation
+Must verify: impersonation sessions cannot perform irreversible actions (payments, deletions)
+Output: threat list + required controls (audit log, scope restriction, TTL)
+```
+
+**RU:**
+```
+/threat-model-review
+
+Скоуп: один эндпоинт — POST /admin/users/{id}/impersonate
+Контекст: позволяет команде поддержки входить от имени любого пользователя для отладки
+Опасения: эскалация привилегий, полнота audit trail, изоляция сессий
+Обязательно проверить: сессии имперсонации не могут выполнять необратимые действия (платежи, удаления)
+Результат: список угроз + необходимые меры (audit log, ограничение скоупа, TTL)
+```

package/areas/software/security/rules/compliance-baseline.md

@@ -0,0 +1,23 @@
+# Rule: Compliance Baseline
+
+**Priority**: P1 — Required before processing real user data.
+
+## Minimum Controls
+
+| Control | Requirement |
+|:---|:---|
+| Encryption at rest | All databases and file storage encrypted |
+| Encryption in transit | TLS 1.2+ on all endpoints |
+| Access logging | All admin actions logged with actor identity |
+| Backup & recovery | Data backed up daily; restore tested quarterly |
+| Incident response | Defined escalation path and communication plan |
+| Vulnerability scanning | Weekly automated scan; critical patched within 7 days |
+
+## PCI DSS (if handling card data)
+- Card data never stored post-authorization (use Stripe/Adyen tokens)
+- Network segmentation: cardholder data environment isolated
+
+## GDPR/CCPA (if processing EU/CA user data)
+- Data processing inventory maintained
+- User deletion must complete within 30 days
+- Breach notification procedure in place (72-hour window for GDPR)

package/areas/software/security/rules/dependency-policy.md

@@ -0,0 +1,12 @@
+# Rule: Dependency Security Policy
+
+**Priority**: P1 — Critical CVEs block deploy; High CVEs require plan within 72 hours.
+
+## Constraints
+
+1. **No direct use of packages with Critical CVEs**: Upgrade or replace immediately.
+2. **High CVEs**: Remediation plan within 72 hours.
+3. **Dependency audit in CI**: `npm audit`, `pip audit`, `trivy` run on every PR. Fail on severity ≥ HIGH.
+4. **Pin transitive dependencies**: Lockfiles committed to Git (`package-lock.json`, `poetry.lock`, `go.sum`).
+5. **No abandoned packages**: Packages without updates > 2 years require security review.
+6. **License compliance**: No GPL in closed-source products without legal review. MIT, Apache 2.0, BSD pre-approved.

package/areas/software/security/rules/secrets-policy.md

@@ -0,0 +1,22 @@
+# Rule: Secrets Policy
+
+**Priority**: P0 — Any committed secret triggers immediate incident response.
+
+## Constraints
+
+1. **Zero secrets in Git**: No passwords, API keys, tokens, certificates in any committed file — including `.env.example`.
+2. **Pre-commit scanning mandatory**: `gitleaks` or `trufflehog` must run as pre-commit hook and in CI on every PR.
+3. **Secret store required**: All secrets stored in: AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, or Azure Key Vault.
+4. **Rotation schedule**: Every secret has defined expiry. No secret older than 90 days without documented rotation.
+5. **Audit trail**: All secret access events must be logged (CloudTrail, Vault audit log).
+
+## If a Secret is Leaked
+
+```
+Within 30 minutes:
+1. REVOKE the exposed secret immediately
+2. Audit access logs for the exposure window
+3. Rotate all secrets sharing the same scope
+4. File security incident report
+5. Remove from Git history (git filter-repo) — does NOT replace revocation
+```

package/areas/software/security/rules/secure-coding.md

@@ -0,0 +1,22 @@
+# Rule: Secure Coding Standards
+
+**Priority**: P0 — Security vulnerabilities block merge unconditionally.
+
+## Input Validation & Injection Prevention
+
+1. **Validate all inputs at system boundaries**: HTTP requests, file uploads, queue payloads validated for type, length, format before processing.
+2. **Parameterized queries only**: SQL never constructed via string concatenation. Use ORM or parameterized prepared statements.
+3. **Output encoding**: User-controlled data rendered in HTML must be encoded. Never use `dangerouslySetInnerHTML` without `DOMPurify`.
+4. **Command injection prevention**: Never pass user input to shell commands. Use allowlist validation and argument arrays.
+5. **Path traversal prevention**: File paths from user input must be canonicalized against an allowed base directory.
+
+## Authentication & Authorization
+
+6. **Authentication on all endpoints**: Every endpoint explicitly declares auth requirement. "Private by default" with explicit `@public` annotation.
+7. **Authorization checked server-side**: Re-verify permissions on every request. Never trust client-side auth state.
+8. **No security through obscurity**: Hiding endpoints is not an access control mechanism.
+
+## Error Handling
+
+9. **No stack traces in production responses**: Generic messages to clients; details logged server-side only.
+10. **No sensitive data in logs**: Passwords, tokens, credit card numbers, PII never in log output.

package/areas/software/security/skills/auth-patterns/SKILL.md

@@ -0,0 +1,42 @@
+# Skill: Authentication & Authorization Patterns
+
+## When to load
+
+When implementing login, token management, OAuth integration, RBAC, or reviewing auth code.
+
+## JWT Best Practices
+
+```python
+def create_access_token(user_id: str) -> str:
+    return jwt.encode(
+        payload={
+            "sub": user_id,
+            "iat": datetime.utcnow(),
+            "exp": datetime.utcnow() + timedelta(minutes=15),  # Short expiry
+            "jti": str(uuid.uuid4()),  # Unique ID for revocation
+            "type": "access",          # Prevent refresh token as access token
+        },
+        key=settings.JWT_PRIVATE_KEY,
+        algorithm="RS256",  # Asymmetric. Never HS256 in distributed systems.
+    )
+```
+
+**Anti-patterns**: No `exp` claim; storing JWT in `localStorage`; using `alg: none`; sensitive data in payload.
+
+## RBAC Pattern
+
+```python
+PERMISSIONS = {
+    "invoices:read":   ["viewer", "editor", "admin"],
+    "invoices:create": ["editor", "admin"],
+    "invoices:delete": ["admin"],
+}
+
+def require_permission(permission: str):
+    def dependency(current_user: User = Depends(get_current_user)):
+        allowed_roles = PERMISSIONS.get(permission, [])
+        if current_user.role not in allowed_roles:
+            raise HTTPException(status_code=403)
+        return current_user
+    return dependency
+```