@dzhechkov/keysarium 1.7.15 → 1.7.19

package/templates/docs/keysarium/02-admin-guide.md

@@ -401,7 +401,7 @@ CHECKPOINT X: [Phase Name] Complete
 | `domain-specific.md` | Доменные правила (банк, ритейл, enterprise, healthcare) |
 | `file-conventions.md` | Конвенции именования файлов и директорий |
 | `modular-reuse.md` | Правила модульного переиспользования скиллов и команд |
-| `research-quality.md` | Требования к качеству research (PARANOID mode) |
+| `research-quality.md` | Выбор режима GOAP и требования к источникам |
 | `witness-chain.md` | Witness chain integration: SHA-256 хеширование артефактов |
 | `reward-learning.md` | Reward-calibrated learning: memory_query/memory_store протокол |
 | `background-workers.md` | Background workers: isolation, model routing, concurrency limits |
@@ -700,7 +700,7 @@ Markdown-документ с чёткой структурой:
 
 ## Instructions (Variant D — Trend Research)
 1. Загрузить goap-research-ed25519 SKILL.md
-2. Исследовать 5 категорий трендов (PARANOID mode)
+2. Исследовать 5 категорий трендов в режиме, разрешённом возможностями источников (`moderate` по умолчанию)
 3. Синтезировать Future-Ready CJM
 4. Записать в промежуточный файл: _variant_d_draft.md
 

package/templates/docs/keysarium/03-user-guide.md

@@ -628,7 +628,7 @@ CHECKPOINT 1: Explore Complete
 Даже в Quick Mode:
 - Phase 2.5 (CJM Prototype) **не пропускается** (только упрощается)
 - `08_executive_summary.md` **обязателен**
-- Research в PARANOID mode -- **все утверждения с источниками**
+- Research с указанием источников; обычные источники работают в GOAP `moderate`
 - Checkpoint-ы **сохраняются** (но можно отвечать `ок` быстрее)
 
 ### 5.4. Распределение времени в Quick Mode (1.5 часа)
@@ -946,9 +946,9 @@ A: Домен определяется автоматически по ключ
 
 ---
 
-**Q: Что такое PARANOID mode в research?**
+**Q: Когда доступен `paranoid` в research?**
 
-A: Это режим повышенной верификации данных. Каждое фактическое утверждение должно иметь проверяемый источник. Утверждения без источников помечаются как `[UNVERIFIED]`. Это защищает от галлюцинаций AI и обеспечивает доверие жюри.
+A: Только когда для выбранного класса источников есть закреплённые ключи издателей и подписанная выдача. Обычные публикации и сайты используют `moderate`: факты снабжаются ссылками, пробелы помечаются `[UNVERIFIED]`. Ссылка сама по себе не доказывает подпись издателя и не гарантирует истинность утверждения.
 
 ---
 

package/templates/docs/keysarium/05-architecture.md

@@ -212,7 +212,7 @@ Read(".claude/skills/<skill-name>/SKILL.md")
 | `domain-specific.md` | Доменные правила (банки, ритейл, enterprise, healthcare) |
 | `file-conventions.md` | Соглашения об именовании файлов и структуре директорий |
 | `modular-reuse.md` | Правила модульного переиспользования компонентов |
-| `research-quality.md` | PARANOID mode: требования к верификации источников |
+| `research-quality.md` | Выбор режима GOAP и требования к источникам |
 
 ---
 
@@ -313,15 +313,16 @@ researches/<case-slug>/
 - **Оптимизация моделей:** haiku для простых операций, sonnet для анализа, opus для креативной работы
 - **Синтез:** после каждого параллельного этапа оркестратор объединяет результаты
 
-### 4. Верифицируемость: PARANOID mode для research
+### 4. Верифицируемость: режим по возможностям источников
 
-Все исследовательские данные проходят строгую верификацию:
+Для обычных источников доступен GOAP `moderate`. `strict` и `paranoid` требуют
+реальных закреплённых ключей издателей и подписанной выдачи выбранного класса
+источников. Во всех режимах действуют требования к качеству:
 
-- Каждое утверждение должно иметь проверяемый источник
+- Существенные фактические утверждения снабжаются источниками
 - Нулевая толерантность к галлюцинированным цитатам
-- Порог уверенности: минимум 0.99
 - Непроверенные данные маркируются как `[UNVERIFIED]`
-- Перед завершением фазы -- чеклист верификации
+- Перед завершением фазы -- чеклист доказательств; `GOAL_UNREACHABLE` блокирует checkpoint
 
 ### 5. Расширяемость: легко добавить новый домен или фазу
 
@@ -410,7 +411,7 @@ sequenceDiagram
     O->>P2: Загрузить goap-research-ed25519 SKILL.md
     Note over P2: 3 агента параллельно
     P2->>P2: Аналоги || Технологии || Регуляторика
-    Note over P2: PARANOID mode: верификация каждого утверждения
+    Note over P2: GOAP moderate для обычных источников; ссылки и пробелы явны
     P2-->>O: 02_research_findings.md
     O->>U: Checkpoint 2
     U->>O: "ок"
@@ -499,7 +500,7 @@ graph TB
     subgraph "Phase 2.5: CJM Prototype (3 агента)"
         P25_O["Orchestrator Phase 2.5"] --> P25_A1["Agent 1:<br/>CJM Variant A"]
         P25_O --> P25_A2["Agent 2:<br/>CJM Variant B + C"]
-        P25_O --> P25_A3["Agent 3:<br/>Trend Research (Variant D)<br/>GOAP PARANOID"]
+        P25_O --> P25_A3["Agent 3:<br/>Trend Research (Variant D)<br/>GOAP mode by capabilities"]
         P25_A1 --> P25_S["Синтез → 4 варианта<br/>prototype/cjm-prototype.jsx"]
         P25_A2 --> P25_S
         P25_A3 --> P25_S

package/templates/docs/keysarium/06-user-flows.md

@@ -66,7 +66,7 @@ sequenceDiagram
 
     Note over C: ═══ Phase 2: Research ═══
     C->>FS: Read .claude/skills/goap-research-ed25519/SKILL.md
-    C->>A: Spawn 3 агента (PARANOID mode)
+    C->>A: Spawn 3 агента (режим по доступным проверкам источников)
     A->>A: Agent 1: Аналоги + метрики
     A->>A: Agent 2: Технологии + Anti-patterns
     A->>A: Agent 3: Регуляторика + market data
@@ -154,7 +154,7 @@ User: /casarium Кейс: Автоматизация контакт-центра
 - Checkpoint 1 -> пользователь подтверждает "ок"
 
 **Шаг 5. Phase 2 -- Research**
-- Загружается скилл `goap-research-ed25519` в PARANOID mode
+- Загружается скилл `goap-research-ed25519`; обычные источники исследуются в `moderate`
 - 3 агента параллельно: аналоги, технологии, регуляторика
 - Синтез с верификацией каждого утверждения
 - Результат: `02_research_findings.md`
@@ -264,7 +264,7 @@ sequenceDiagram
 
 - Phase 2.5 (CJM) все равно **не пропускается** -- упрощается до 2 вариантов
 - `08_executive_summary.md` все равно **обязателен**
-- PARANOID mode для research **сохраняется** (лучше меньше утверждений, но верифицированных)
+- Требование указывать источники и пробелы **сохраняется**; режим GOAP выбирается по возможностям источников
 - Checkpoints **сохраняются** (но можно пройти быстрее)
 
 ---
@@ -865,7 +865,7 @@ flowchart TD
 
 **Принципы обработки:**
 - Research **никогда не пропускается** -- даже при отсутствии данных фиксируется сам факт отсутствия
-- PARANOID mode: лучше `[NO_DATA]`, чем непроверенное утверждение
+- Лучше `[NO_DATA]`, чем неподтверждённое утверждение, представленное как факт
 - Пробелы маркируются явно -- это ценная информация для последующих фаз
 - Пользователь всегда информируется о состоянии данных на checkpoint
 

package/templates/lib/platform-templates/copilot.md

@@ -34,7 +34,7 @@ Create `.github/copilot-instructions.md` with the following structure:
 {Summarize the rule to 5-10 key bullet points.
  Focus on actionable instructions.
  Omit implementation details specific to Claude Code.
- Preserve critical constraints (PARANOID mode, mandatory phases, etc.)
+ Preserve critical constraints (research mode capability gate, mandatory phases, etc.)
 }
 
 ---

package/templates/lib/platform-templates/opencode.md

@@ -24,7 +24,7 @@ project:
 instructions: |
   {Extract the critical rules from CLAUDE.md:
    - File conventions
-   - Research quality requirements (PARANOID mode)
+   - Research quality requirements and GOAP mode capability gate
    - Checkpoint protocol summary
    - Anti-patterns to avoid
    Keep to 30-50 lines.}

package/templates/.claude/skills/feature-adr/references/agentic-qe/enterprise-integration-testing.md

@@ -1,111 +0,0 @@
-# Enterprise Integration Testing (Condensed for Feature ADR)
-
-> Source: agentic-qe `enterprise-integration-testing` skill (Tier 3)
-> Condensed from 735 lines — SAP-specific sections removed, universal patterns retained.
-
-## Purpose
-
-Verify that independently correct modules/systems work correctly together.
-The biggest risks are in the seams between components, not within them.
-
-## Integration Testing Protocol
-
-### 1. Map E2E Flow
-
-Before writing tests, map the complete flow:
-```
-User Action → API → Service A → Service B → Database → Response
-```
-
-Identify every integration boundary (API calls, DB queries, message queues, file I/O).
-
-### 2. Test Each Boundary
-
-For each integration point:
-
-| Boundary Type | What to Test |
-|---|---|
-| API (REST/GraphQL) | Contract compliance, schema validation, error codes |
-| Database | Query correctness, transaction isolation, migration compatibility |
-| Message Queue | Message format, ordering, DLQ handling, retry logic |
-| File I/O | Format validation, encoding, path handling |
-| External Service | Mock fidelity, timeout handling, circuit breaker |
-
-### 3. Cross-Module Data Consistency
-
-After each integration event, verify:
-- Data written by module A is correctly read by module B
-- No data loss or transformation errors at boundaries
-- Eventual consistency windows are respected (async flows)
-
-### 4. Contract Testing
-
-```
-Consumer defines expected contract
-  → Provider validates against contract
-    → Break = blocked merge
-```
-
-Key checks:
-- Request/response schemas match between caller and callee
-- Error response formats are consistent
-- API versioning is respected
-- No breaking changes in shared interfaces
-
-### 5. Error Recovery
-
-Test failure scenarios at every boundary:
-- What happens when Service B is down?
-- Are partial operations compensated/rolled back?
-- Do correlation IDs propagate through the chain?
-- Are DLQ messages reprocessable?
-
-## Integration Quality Gates
-
-| Gate | Threshold | Action |
-|---|---|---|
-| Cross-module data consistency | 100% for critical paths | BLOCK on failure |
-| API contract compliance | 100% | BLOCK on failure |
-| Error recovery | All compensation paths tested | WARN if partial |
-| Performance | E2E flow < defined SLA | WARN if exceeded |
-
-## Hierarchical Testing Strategy
-
-Execute integration tests in phases:
-1. **Contract validation** — verify interfaces match
-2. **Integration testing** — verify boundary behavior
-3. **E2E validation** — verify complete flows
-4. **Authorization check** — verify access control across modules
-
-## QCSD Flags for Integration
-
-```
-HAS_CROSS_MODULE_DATA: true   → Data replicated/shared across modules
-HAS_ASYNC_PROCESSING: true    → Message queues, event-driven flows
-HAS_EXTERNAL_SERVICES: true   → Third-party API integrations
-HAS_DATABASE_SHARING: true    → Multiple modules access same DB
-```
-
-## Best Practices
-
-### Do
-- Map the full E2E flow before writing any tests
-- Test each integration boundary separately AND end-to-end
-- Validate data consistency across all modules after each event
-- Use service virtualization for hard-to-provision dependencies
-- Include correlation ID tracing in test assertions
-
-### Avoid
-- Testing only through the UI without API-level tests
-- Ignoring async processing errors (DLQ, failed events)
-- Assuming cross-module data is immediately consistent
-- Testing integrations only in isolation (mock everything)
-- Deploying without verifying no breaking API changes
-
-## Agent Coordination
-
-When used as Fleet QE Agent 3 (Integration Integrity Checker):
-- Focus scope: cross-module interactions within the feature
-- Input: `{CODE_CHANGES}` file list, `{ARCHITECTURE}` component diagram
-- Output: integration issues found, contract violations, data consistency risks
-- Verdict per issue: BLOCKER / WARNING / INFO

package/templates/.claude/skills/feature-adr/references/agentic-qe/qcsd-ideation-swarm.md

@@ -1,126 +0,0 @@
----
-name: qcsd-ideation-swarm
-description: "QCSD Ideation phase swarm for Quality Criteria sessions using HTSM v6.3, Risk Storming, and Testability analysis before development begins."
-source: https://github.com/proffesor-for-testing/agentic-qe/tree/main/assets/skills/qcsd-ideation-swarm
-version: 7.5.1
-trust_tier: 3
-agents:
-  core: [qe-quality-criteria-recommender, qe-risk-assessor, qe-requirements-validator]
-  conditional: [qe-accessibility-auditor, qe-security-auditor, qe-qx-partner]
----
-
-# QCSD Ideation Swarm (Adapted for Feature-ADR)
-
-Shift-left quality engineering swarm applied to feature ADR and requirements analysis.
-
----
-
-## Phase 1: Flag Detection
-
-Scan feature requirements/ADR and SET these flags:
-
-```
-□ HAS_UI = FALSE
-  Set TRUE if feature contains: UI, frontend, visual, component, screen, page, form, button,
-  modal, dialog, dashboard, widget, interface, display, view, layout, CSS, styling
-
-□ HAS_SECURITY = FALSE
-  Set TRUE if feature contains: auth, security, credential, token, encrypt, PII, compliance,
-  password, login, session, OAuth, JWT, permission, role, access control, RBAC, sensitive
-
-□ HAS_UX = FALSE
-  Set TRUE if feature contains: user experience, UX, journey, usability, user flow, persona,
-  friction, delight, onboarding, retention, engagement
-```
-
-## Phase 2: Spawn Core Agents (3 parallel)
-
-ALL THREE core agents MUST be spawned in a single message:
-
-### Agent 1: Quality Criteria Recommender (HTSM v6.3)
-Analyze ALL 10 HTSM categories with weight and testability score:
-1. Capability — does it do what's required?
-2. Reliability — under stress, load, edge cases
-3. Usability — learnability, accessibility, efficiency
-4. Charisma — visual design, responsiveness
-5. Security — authentication, authorization, data protection
-6. Scalability — growth handling, resource limits
-7. Compatibility — browsers, devices, APIs, integrations
-8. Performance — speed, throughput, resource usage
-9. Installability — deployment, configuration, migration
-10. Development — testability, maintainability, portability
-
-### Agent 2: Risk Assessor (SFDIPOT)
-Apply SFDIPOT framework:
-- **S**tructure: Code architecture, component dependencies
-- **F**unction: Business logic, calculations, workflows
-- **D**ata: Data integrity, migrations, edge values
-- **I**nterfaces: API contracts, integration points, UI interactions
-- **P**latform: OS, browser, infrastructure dependencies
-- **O**perations: Deployment, monitoring, maintenance
-- **T**ime: Scheduling, concurrency, timeouts, caching
-
-Identify minimum 10 risks with probability (1-5), impact (1-5), and risk score.
-
-### Agent 3: Requirements Validator (Testability)
-Apply 10 Principles of Testability, score each 0-100:
-1. Observability — can we see what the system does?
-2. Controllability — can we put it in the state we need?
-3. Decomposability — can we test parts independently?
-4. Simplicity — is it only as complex as needed?
-5. Stability — does it change predictably?
-6. Information — do we have what we need to test?
-7. Communication — do we know what to test?
-8. Relation to prior work — can we leverage past tests?
-9. Time — do we have enough time to test?
-10. Accountability — who owns quality?
-
-## Phase 3: Conditional Agents (based on flags)
-
-| Flag | Agent | Analysis |
-|------|-------|----------|
-| HAS_UI | qe-accessibility-auditor | WCAG 2.2 AA compliance assessment |
-| HAS_SECURITY | qe-security-auditor | STRIDE threat modeling |
-| HAS_UX | qe-qx-partner | User journey and experience quality analysis |
-
-## Phase 4: GO/NO-GO Decision
-
-| Metric | NO-GO | CONDITIONAL | GO |
-|--------|-------|-------------|-----|
-| Testability Score | < 40 | 40-79 | ≥ 80 |
-| HTSM Coverage | < 6/10 | 6-7/10 | ≥ 8/10 |
-| AC Completeness | < 50% | 50-89% | ≥ 90% |
-| Critical Risks | > 2 | 1-2 | 0 |
-
-**NO-GO**: Stop. Requirements need rework before development.
-**CONDITIONAL**: Proceed with advisory warnings. Include findings in judge context.
-**GO**: Full confidence. Proceed to implementation planning.
-
-## Phase 5: Synthesis Report
-
-Generate consolidated report with:
-1. Executive summary (GO/CONDITIONAL/NO-GO verdict)
-2. Quality criteria scores (10 HTSM categories)
-3. Risk matrix (top 10 risks by score)
-4. Testability assessment (10 principles)
-5. Test ideas (categorized by type: unit/integration/E2E)
-6. Recommendations (prioritized by risk × impact)
-
-## Integration with Feature-ADR
-
-This swarm runs as Step 3.5 in the feature-adr pipeline:
-- **Input**: Refined ADR from Step 3 + Requirements from Step 1
-- **Output**: Quality assessment report in `features/<slug>/03.5_ideation_report.md`
-- **Gate**: NO-GO blocks progression to Step 6 (Implementation Plan)
-- **CONDITIONAL**: Warnings are passed to Steps 6-8 as context
-
-## Enforcement Rules
-
-| Rule | Requirement |
-|------|------------|
-| E1 | ALL THREE core agents must be spawned. No exceptions. |
-| E2 | All parallel agents in a SINGLE message. |
-| E3 | STOP and WAIT after each batch. No proceeding early. |
-| E4 | Conditional agents MUST be spawned if flags are TRUE. |
-| E5 | GO/CONDITIONAL/NO-GO logic applied exactly as specified. |
-| E6 | Full report structure generated. No abbreviated versions. |