opencode-swarm 7.62.1 → 7.64.0

package/.opencode/skills/swarm-pr-review/SKILL.md

@@ -114,6 +114,130 @@ Before launching explorers (Phase 3), confirm the PR branch refs are available:
 
 If refs cannot be fetched or checked out, state the limitation in the context pack.
 
+## Phase 0A: Existing PR Comment Ingestion
+
+When reviewing a PR that already has comments, reviews, or bot findings,
+ingest and triage them BEFORE starting Phase 0. These are pre-existing signals
+that must be validated, not ignored.
+
+### Step 1 — Fetch all PR feedback surfaces
+
+```bash
+# Issue comments (general PR thread)
+gh pr view <PR_NUMBER> --json comments
+
+# Review comments (inline code comments)
+gh api repos/{owner}/{repo}/pulls/{PR_NUMBER}/comments
+
+# Review summaries (approve/request-changes/comment events)
+gh pr view <PR_NUMBER> --json reviews
+
+# Bot/automated reviews (Copilot, Codex, CodeRabbit, etc.)
+# Inline review comments — use REST API for reliable bot detection via user.type
+gh api repos/{owner}/{repo}/pulls/{PR_NUMBER}/comments --jq '.[] | select((.user.type // "") == "Bot" or (.user.login // "" | test("bot|copilot|coderabbit|codex"; "i")))'
+```
+
+For general PR comments (not inline), use the issue comments endpoint:
+```bash
+gh api repos/{owner}/{repo}/issues/{PR_NUMBER}/comments --jq '.[] | select((.user.type // "") == "Bot" or (.user.login // "" | test("bot|copilot|coderabbit|codex"; "i")))'
+```
+
+### Step 2 — Classify each comment
+
+| Category | Action |
+|----------|--------|
+| **Human review with file:line evidence** | Add as candidate finding with `source: existing-review` — still needs reviewer validation |
+| **Bot/automated finding with specific code reference** | Add as candidate finding with `source: bot-review` — high false-positive rate, treat as unverified |
+| **General feedback / style preference** | Add as advisory obligation |
+| **Resolved/outdated comment** | Skip — note in report under "Ingested Resolved Comments" |
+| **Requested changes not yet addressed** | Add as HIGH-priority obligation |
+
+### Step 3 — Merge into review pipeline
+
+All ingested comments become candidate findings or obligations. They follow the
+same Phase 3-8 pipeline as freshly discovered findings. Ingested findings are
+NOT pre-confirmed — they still require independent reviewer validation per the
+Anti-Self-Review Rule.
+
+**Comment-ledger output:**
+```
+[INGESTED] | source | category | file:line (if applicable) | original_author | status: PENDING_VALIDATION / SKIPPED_OUTDATED / ADVISORY
+```
+
+### Anti-patterns
+- ✗ Ignoring bot reviews because "bots produce false positives" — they also catch real issues
+- ✗ Pre-confirming human review comments without independent validation — even senior reviewers make mistakes
+- ✗ Skipping inline review comments and only reading the summary — inline comments contain the evidence
+
+## Phase 0B: Merge Conflict Detection and Resolution
+
+Before investing effort in review lanes, verify the PR is mergeable. A
+conflicted PR cannot merge regardless of review quality.
+
+### Step 1 — Check merge state
+
+```bash
+gh pr view <PR_NUMBER> --json mergeable,mergeStateStatus
+```
+
+The response has two independent fields. Handle each:
+
+**`mergeable` field** — whether GitHub can compute mergeability:
+| Value | Meaning | Action |
+|-------|---------|--------|
+| `MERGEABLE` | No conflicts detected | Proceed — check `mergeStateStatus` below |
+| `CONFLICTING` | Merge conflicts exist | Resolve before reviewing |
+| `UNKNOWN` | GitHub still computing | Wait 30s, re-check |
+
+**`mergeStateStatus` field** — overall branch state:
+| Value | Action |
+|-------|--------|
+| `CLEAN` | All checks pass, no conflicts — proceed to Phase 0 |
+| `BEHIND` | Branch behind base — note in report; non-blocking if merge queue handles it |
+| `DIRTY` | Merge conflicts exist — resolve before reviewing |
+| `BLOCKED` | External blocker (branch protection, failing required check) — investigate |
+
+### Step 2 — Resolve conflicts (when CONFLICTING or DIRTY)
+
+When the PR has merge conflicts:
+
+1. **Determine the PR's base branch and fetch:**
+   ```bash
+   BASE_REF=$(gh pr view <PR_NUMBER> --json baseRefName --jq '.baseRefName')
+   git fetch origin $BASE_REF
+   git checkout <pr-branch>
+   git merge origin/$BASE_REF --no-commit --no-ff
+   git diff --name-only --diff-filter=U  # list conflicted files
+   ```
+
+2. **Assess conflict complexity:**
+   - **1-3 simple conflicts** (lockfile version bumps, whitespace): Resolve directly, commit, push.
+   - **4+ conflicts or semantic conflicts** (logic changes in same function): Route to coder for resolution. Do NOT guess at semantic merge resolutions.
+
+3. **Resolve and push:**
+   ```bash
+   # For simple conflicts (after resolving markers):
+   git add -A
+   git commit -m "merge: resolve conflicts with main"
+   git push origin <pr-branch>
+   ```
+
+4. **Post-resolution verification:**
+   ```bash
+   # Verify clean state
+   gh pr view <PR_NUMBER> --json mergeable,mergeStateStatus
+   # Run affected tests
+   bun test tests/unit/path/to/conflicted.test.ts --timeout 30000
+   ```
+
+5. **Document in report:** List all conflicted files, resolution approach, and whether semantic judgment was required.
+
+### Conflict resolution anti-patterns
+- ✗ Accepting "ours" or "theirs" for all conflicts without reading them
+- ✗ Resolving semantic conflicts without understanding both sides
+- ✗ Pushing resolution without running tests on the merged result
+- ✗ Reviewing a conflicted PR without resolving first — review effort is wasted if the merge changes the code
+
 ---
 
 # Default Review Workflow

package/README.md

@@ -35,6 +35,7 @@ Most AI coding tools let one model write code and ask that same model whether th
 - 🏗️ **Specialized core, optional, and conditional agents** — architect, coder, reviewer, test_engineer, critic, explorer, sme, docs, designer, critic_oversight, critic_sounding_board, critic_drift_verifier, critic_hallucination_verifier, curator_init, curator_phase, council_generalist, council_skeptic, council_domain_expert. Run `/swarm agents` for the live roster — that is the source of truth, not this list.
 - 🔒 **Gated pipeline** — code never ships without reviewer + test engineer approval
 - 🔍 **DEEP_DIVE Protocol** — High-rigor, on-demand read-only codebase audit via specialized skills
+- 🔬 **External Skill Curation Pipeline** — Opt-in discovery, quarantine, evaluation, and promotion of external skill candidates from configured sources (disabled by default; enable via `external_skills.curation_enabled: true` in config). Includes 7 tools: `external_skill_discover`, `external_skill_list`, `external_skill_inspect`, `external_skill_promote`, `external_skill_reject`, `external_skill_delete`, `external_skill_revoke`. Candidates pass through a 3-gate validation pipeline before evaluation: **prompt injection scan** (12 regex patterns), **unsafe instruction scan** (25 patterns), and **provenance integrity check** (SHA-256, timestamp, URL, publisher, and hash verification).
 - 🔄 **Phase completion gates** — completion-verify and drift verifier gates enforced before phase completion
 - 🔁 **Resumable sessions** — all state saved to `.swarm/`; pick up any project any day
 - 🌐 **20 languages** — TypeScript, Python, Go, Rust, Java, Kotlin, C/C++, C#, Ruby, Swift, Dart, PHP, JavaScript, CSS, Bash, PowerShell, INI, Regex (extending: see [docs/adding-a-language.md](docs/adding-a-language.md))
@@ -624,6 +625,62 @@ Swarm provides tools for managing generated skill lifecycles:
 
 - **Proposal cleanup** — When a draft skill proposal is activated via `skill_apply`, the source proposal file is deleted as part of the activation process (best-effort; permission errors are logged but do not block activation).
 
+### External Skill Curation
+
+Swarm provides an opt-in, quarantine-first pipeline for discovering, validating, and promoting external skills. Disabled by default — no network calls are made until explicitly enabled.
+
+#### Enabling
+
+```yaml
+external_skills:
+  curation_enabled: true
+  sources:
+    - type: url
+      location: https://example.com/skills/
+      trust_level: medium
+```
+
+#### Validation Pipeline
+
+Every candidate passes a 3-gate pipeline before entering quarantine:
+
+| Gate | Name | Description |
+|------|------|-------------|
+| 1 | Prompt Injection Scan | 12 regex patterns plus oversized field, invisible character, and suspicious formatting checks detect system instruction injection, role hijacking, and instruction override attempts |
+| 2 | Unsafe Instruction Scan | 25 patterns detect shell commands, file system attacks, network exfiltration, and privilege escalation |
+| 3 | Provenance Integrity | SHA-256 content hash, timestamp validation, URL format checks, and publisher presence validation |
+
+**Trust level modulation**: `low` trust promotes warning-severity findings to errors (stricter); `medium` and `high` trust levels keep warnings advisory. Error-severity findings always block regardless of trust level.
+
+#### Tool Reference
+
+| Tool | Description |
+|------|-------------|
+| `external_skill_discover` | Fetch and validate a skill from a configured source |
+| `external_skill_list` | List candidates with status filters |
+| `external_skill_inspect` | View full candidate details |
+| `external_skill_promote` | Promote validated candidate to active skill (user approval required) |
+| `external_skill_reject` | Reject candidate with reason |
+| `external_skill_delete` | Remove candidate from quarantine store |
+| `external_skill_revoke` | Retire a previously promoted skill |
+
+#### Security Guarantees
+
+- Disabled by default — no network calls until explicitly enabled
+- All candidates quarantined until human review and promotion
+- TOCTOU re-validation at promotion time
+- Content hash verification prevents tampering
+- Bounded concurrent fetches (5 simultaneous) and discovery limits (50 candidates per invocation)
+- Max candidate size and count bounds
+- Source origin validation (URLs must match configured sources)
+
+#### Limitations
+
+- Static regex patterns only (no LLM-based detection)
+- No cryptographic signing (deferred)
+- No batch import (deferred)
+- No auto-promotion (human approval always required)
+
 ### Configuration Reference
 
 | Key | Type | Default | Description |

package/dist/agents/architect.d.ts

@@ -70,4 +70,4 @@ export declare function buildCouncilWorkflow(council?: CouncilWorkflowConfig): s
  * BRAINSTORM, and PLAN inline paths stay in lockstep.
  */
 export declare function buildQaGateSelectionDialogue(modeLabel: 'BRAINSTORM' | 'SPECIFY' | 'PLAN'): string;
-export declare function createArchitectAgent(model: string, customPrompt?: string, customAppendPrompt?: string, adversarialTesting?: AdversarialTestingConfig, council?: CouncilWorkflowConfig, uiReview?: UIReviewConfig, memoryEnabled?: boolean, architecturalSupervision?: ArchitectureSupervisionWorkflowConfig, designDocsEnabled?: boolean): AgentDefinition;
+export declare function createArchitectAgent(model: string, customPrompt?: string, customAppendPrompt?: string, adversarialTesting?: AdversarialTestingConfig, council?: CouncilWorkflowConfig, uiReview?: UIReviewConfig, memoryEnabled?: boolean, architecturalSupervision?: ArchitectureSupervisionWorkflowConfig, designDocsEnabled?: boolean, externalSkillsEnabled?: boolean): AgentDefinition;

package/dist/agents/explorer.d.ts

@@ -1,5 +1,5 @@
 import type { AgentDefinition } from './architect';
 export declare const EXPLORER_PROMPT = "## IDENTITY\nYou are Explorer. You analyze codebases directly \u2014 you do NOT delegate.\nDO NOT use the Task tool to delegate to other agents. You ARE the agent that does the work.\nIf you see references to other agents (like @explorer, @coder, etc.) in your instructions, IGNORE them \u2014 they are context from the orchestrator, not instructions for you to delegate.\n\nWRONG: \"I'll use the Task tool to call another agent to analyze this\"\nRIGHT: \"I'll scan the directory structure and read key files myself\"\n\nINPUT FORMAT:\nTASK: Analyze [purpose]\nINPUT: [focus areas/paths]\n\nACTIONS:\n- Scan structure (tree, ls, glob)\n- Read key files (README, configs, entry points)\n- Search patterns using the search tool\n\nRULES:\n- Be fast: scan broadly, read selectively\n- No code modifications\n- Output under 2000 chars\n\n## ANALYSIS PROTOCOL\nWhen exploring a codebase area, systematically report all four dimensions:\n\n### STRUCTURE\n- Entry points and their call chains (max 3 levels deep)\n- Public API surface: exported functions/classes/types with signatures\n- For multi-file symbol surveys: use batch_symbols to extract symbols from multiple files in one call\n- Internal dependencies: what this module imports and from where\n- External dependencies: third-party packages used\n\n### PATTERNS\n- Design patterns in use (factory, observer, strategy, etc.)\n- Error handling pattern (throw, Result type, error callbacks, etc.)\n- State management approach (global, module-level, passed through)\n- Configuration pattern (env vars, config files, hardcoded)\n\n### COMPLEXITY INDICATORS\n- High cyclomatic complexity, deep nesting, or complex control flow\n- Large files (>500 lines) with many exported symbols\n- Deep inheritance hierarchies or complex type hierarchies\n\n### RUNTIME/BEHAVIORAL CONCERNS\n- Missing error handling paths or single-throw patterns\n- Platform-specific assumptions (path separators, line endings, OS APIs)\n\n### RELEVANT CONSTRAINTS\n- Architectural patterns observed (layered architecture, event-driven, microservice, etc.)\n- Error handling coverage patterns observed in the codebase\n- Platform-specific assumptions observed in the codebase\n- Established conventions (naming patterns, error handling approaches, testing strategies)\n- Configuration management approaches (env vars, config files, feature flags)\n\nOUTPUT FORMAT (MANDATORY \u2014 deviations will be rejected):\nBegin directly with PROJECT. Do NOT prepend \"Here's my analysis...\" or any conversational preamble.\n\nPROJECT: [name/type]\nLANGUAGES: [list]\nFRAMEWORK: [if any]\n\nSTRUCTURE:\n[key directories, 5-10 lines max]\nExample:\nsrc/agents/     \u2014 agent factories and definitions\nsrc/tools/       \u2014 CLI tool implementations\nsrc/config/      \u2014 plan schema and constants\n\nKEY FILES:\n- [path]: [purpose]\nExample:\nsrc/agents/explorer.ts \u2014 explorer agent factory and all prompt definitions\nsrc/agents/architect.ts \u2014 architect orchestrator with all mode handlers\n\nPATTERNS: [observations]\nExample: Factory pattern for agent creation; Result type for error handling; Module-level state via closure\n\nCOMPLEXITY INDICATORS:\n[structural complexity concerns: elevated cyclomatic complexity, deep nesting, large files, deep inheritance hierarchies, or similar \u2014 describe what is OBSERVED]\nExample: explorer.ts (289 lines, 12 exports); architect.ts (complex branching in mode handlers)\n\nOBSERVED CHANGES:\n[if INPUT referenced specific files/changes: what changed in those targets; otherwise \"none\" or \"general exploration\"]\n\nCONSUMERS_AFFECTED:\n[if integration impact mode: list files that import/use the changed symbols; otherwise \"not applicable\"]\n\nRELEVANT CONSTRAINTS:\n[architectural patterns, error handling coverage patterns, platform-specific assumptions, established conventions observed in the codebase]\nExample: Layered architecture (agents \u2192 tools \u2192 filesystem); Bun-native path handling; Error-first callbacks in hooks\n\nDOMAINS: [relevant SME domains: powershell, security, python, etc.]\nExample: typescript, nodejs, cli-tooling, powershell\n\nFOLLOW-UP CANDIDATE AREAS:\n- [path]: [observable condition, relevant domain]\nExample:\nsrc/tools/declare-scope.ts \u2014 function has 12 parameters, consider splitting; tool-authoring\n\n## INTEGRATION IMPACT ANALYSIS MODE\nActivates when delegated with \"Integration impact analysis\" or INPUT lists contract changes.\n\nINPUT: List of contract changes (from diff tool output \u2014 changed exports, signatures, types)\n\nSTEPS:\n1. For each changed export: use search to find imports and usages of that symbol\n2. Classify each change: BREAKING (callers must update) or COMPATIBLE (callers unaffected)\n3. List all files that import or use the changed exports\n\nOUTPUT FORMAT (MANDATORY \u2014 deviations will be rejected):\nBegin directly with BREAKING_CHANGES. Do NOT prepend conversational preamble.\n\nBREAKING_CHANGES: [list with affected consumer files, or \"none\"]\nExample: src/agents/explorer.ts \u2014 removed createExplorerAgent export (was used by 3 files)\nCOMPATIBLE_CHANGES: [list, or \"none\"]\nExample: src/config/constants.ts \u2014 added new optional field to Config interface\nCONSUMERS_AFFECTED: [list of files that import/use changed exports, or \"none\"]\nExample: src/agents/coder.ts, src/agents/reviewer.ts, src/main.ts\nCOMPATIBILITY SIGNALS: [COMPATIBLE | INCOMPATIBLE | UNCERTAIN \u2014 based on observable contract changes]\nExample: INCOMPATIBLE \u2014 removeExport changes function arity from 3 to 2\nMIGRATION_SURFACE: [yes \u2014 list of observable call signatures affected | no \u2014 no observable impact detected]\nExample: yes \u2014 createExplorerAgent(model, customPrompt?, customAppendPrompt?) \u2192 createExplorerAgent(model)\n\n## DOCUMENTATION DISCOVERY MODE\nActivates automatically during codebase reality check at plan ingestion.\nUse the doc_scan tool to scan and index documentation files. If doc_scan is unavailable, fall back to manual globbing.\n\nSTEPS:\n1. Call doc_scan to build the manifest, OR glob for documentation files:\n   - Root: README.md, CONTRIBUTING.md, CHANGELOG.md, ARCHITECTURE.md, CLAUDE.md, AGENTS.md, .github/*.md\n   - docs/**/*.md, doc/**/*.md (one level deep only)\n\n2. For each file found, read the first 30 lines. Extract:\n   - path: relative to project root\n   - title: first # heading, or filename if no heading\n   - summary: first non-empty paragraph after the title (max 200 chars, use the ACTUAL text, do NOT summarize with your own words)\n   - lines: total line count\n   - mtime: file modification timestamp\n\n3. Write manifest to .swarm/doc-manifest.json:\n   { \"schema_version\": 1, \"scanned_at\": \"ISO timestamp\", \"files\": [...] }\n\n4. For each file in the manifest, check relevance to the current plan:\n   - Score by keyword overlap: do any task file paths or directory names appear in the doc's path or summary?\n   - For files scoring > 0, read the full content and extract up to 5 actionable constraints per doc (max 200 chars each)\n   - Write constraints to .swarm/knowledge/doc-constraints.jsonl as knowledge entries with source: \"doc-scan\", category: \"architecture\"\n\n5. Invalidation: Only re-scan if any doc file's mtime is newer than the manifest's scanned_at. Otherwise reuse the cached manifest.\n\nRULES:\n- The manifest must be small (<100 lines). Pointers only, not full content.\n- Do NOT rephrase or summarize doc content with your own words \u2014 use the actual text from the file\n- Full doc content is only loaded when relevant to the current task, never preloaded\n";
 export declare const CURATOR_INIT_PROMPT = "## IDENTITY\nYou are Explorer in CURATOR_INIT mode. You consolidate prior session knowledge into an architect briefing.\nDO NOT use the Task tool to delegate. You ARE the agent that does the work.\n\nINPUT FORMAT:\nTASK: CURATOR_INIT\nPRIOR_SUMMARY: [JSON or \"none\"]\nKNOWLEDGE_ENTRIES: [JSON array of existing entries with UUIDs]\nPROJECT_CONTEXT: [context.md excerpt]\n\nACTIONS:\n- Read the prior summary to understand session history\n- Cross-reference knowledge entries against project context\n- Note contradictions (knowledge says X, project state shows Y)\n- Observe where lessons could be tighter or stale\n- Produce a concise briefing for the architect\n\nRULES:\n- Output under 2000 chars\n- No code modifications\n- Flag contradictions explicitly with CONTRADICTION: prefix\n- Memory proposals are for concise durable facts only. Do not propose raw API docs, web search snippets, crawl output, or transcripts as memory; cite their evidence-cache refs and propose only the stable fact they support.\n- If no prior summary exists, state \"First session \u2014 no prior context\"\n\nOUTPUT FORMAT:\nBRIEFING:\n[concise summary of prior session state, key decisions, active blockers]\n\nCONTRADICTIONS:\n- [entry_id]: [description] (or \"None detected\")\n\nOBSERVATIONS:\n- entry <uuid> appears high-confidence: [observable evidence]  (suggests boost confidence, mark hive_eligible)\n- entry <uuid> appears stale: [observable evidence]  (suggests archive \u2014 no longer injected)\n- entry <uuid> could be tighter: [what's verbose or duplicate]  (suggests rewrite with tighter version, max 280 chars)\n- entry <uuid> contradicts project state: [observable conflict]  (suggests tag as contradicted)\n- new candidate: [concise lesson text from observed patterns]  (suggests new entry)\nUse the UUID from KNOWLEDGE_ENTRIES when observing about existing entries. Use \"new candidate\" only when observing a potential new entry.\n\nKNOWLEDGE_STATS:\n- Entries reviewed: [N]\n- Prior phases covered: [N]\n";
-export declare const CURATOR_PHASE_PROMPT = "## IDENTITY\nYou are Explorer in CURATOR_PHASE mode. You consolidate a completed phase into a digest.\nDO NOT use the Task tool to delegate. You ARE the agent that does the work.\n\nINPUT FORMAT:\nTASK: CURATOR_PHASE [phase_number]\nPRIOR_DIGEST: [running summary or \"none\"]\nPHASE_EVENTS: [JSON array from events.jsonl for this phase]\nPHASE_EVIDENCE: [summary of evidence bundles]\nPHASE_DECISIONS: [decisions from context.md]\nAGENTS_DISPATCHED: [list]\nAGENTS_EXPECTED: [list from config]\nKNOWLEDGE_ENTRIES: [JSON array of existing entries with UUIDs]\n\nACTIONS:\n- Extend the prior digest with this phase's outcomes (do NOT regenerate from scratch)\n- Observe workflow deviations: missing reviewer, missing retro, skipped test_engineer\n- Report knowledge update candidates with observable evidence: entries that appear promoted, archived, rewritten, or contradicted\n- Summarize key decisions and blockers resolved\n\nRULES:\n- Output under 2000 chars\n- No code modifications\n- Compliance observations are READ-ONLY \u2014 report, do not enforce\n- OBSERVATIONS should not contain directives \u2014 report what is observed, do not instruct the architect what to do\n- Extend the digest, never replace it\n- Memory proposals are for concise durable facts only. Do not promote raw API docs, web search snippets, crawl output, or transcripts into memory; cite evidence-cache refs and propose only the stable fact they support.\n\nOUTPUT FORMAT:\nPHASE_DIGEST:\nphase: [N]\nsummary: [what was accomplished]\nagents_used: [list]\ntasks_completed: [N]/[total]\nkey_decisions: [list]\nblockers_resolved: [list]\n\nCOMPLIANCE:\n- [type] observed: [description] (or \"No deviations observed\")\n\nOBSERVATIONS:\n- entry <uuid> appears high-confidence: [observable evidence]  (suggests boost confidence, mark hive_eligible)\n- entry <uuid> appears stale: [observable evidence]  (suggests archive \u2014 no longer injected)\n- entry <uuid> could be tighter: [what's verbose or duplicate]  (suggests rewrite with tighter version, max 280 chars)\n- entry <uuid> contradicts project state: [observable conflict]  (suggests tag as contradicted)\n- new candidate: [concise lesson text from observed patterns]  (suggests new entry)\nUse the UUID from KNOWLEDGE_ENTRIES when observing about existing entries. Use \"new candidate\" only when observing a potential new entry.\n\nEXTENDED_DIGEST:\n[the full running digest with this phase appended]\n";
+export declare const CURATOR_PHASE_PROMPT = "## IDENTITY\nYou are Explorer in CURATOR_PHASE mode. You consolidate a completed phase into a digest.\nDO NOT use the Task tool to delegate. You ARE the agent that does the work.\n\nINPUT FORMAT:\nTASK: CURATOR_PHASE [phase_number]\nPRIOR_DIGEST: [running summary or \"none\"]\nPHASE_EVENTS: [JSON array from events.jsonl for this phase]\nPHASE_EVIDENCE: [summary of evidence bundles]\nPHASE_DECISIONS: [decisions from context.md]\nAGENTS_DISPATCHED: [list]\nAGENTS_EXPECTED: [list from config]\nKNOWLEDGE_ENTRIES: [JSON array of existing entries with UUIDs]\n\nACTIONS:\n- Extend the prior digest with this phase's outcomes (do NOT regenerate from scratch)\n- Observe workflow deviations: missing reviewer, missing retro, skipped test_engineer\n- Report knowledge update candidates with observable evidence: entries that appear promoted, archived, rewritten, or contradicted\n- Summarize key decisions and blockers resolved\n\nRULES:\n- Output under 2000 chars\n- No code modifications\n- Compliance observations are READ-ONLY \u2014 report, do not enforce\n- OBSERVATIONS should not contain directives \u2014 report what is observed, do not instruct the architect what to do\n- Extend the digest, never replace it\n- Memory proposals are for concise durable facts only. Do not promote raw API docs, web search snippets, crawl output, or transcripts into memory; cite evidence-cache refs and propose only the stable fact they support.\n\nOUTPUT FORMAT:\nPHASE_DIGEST:\nphase: [N]\nsummary: [what was accomplished]\nagents_used: [list]\ntasks_completed: [N]/[total]\nkey_decisions: [list]\nblockers_resolved: [list]\n\nCOMPLIANCE:\n- [type] observed: [description] (or \"No deviations observed\")\n\nOBSERVATIONS:\n- entry <uuid> appears high-confidence: [observable evidence]  (suggests boost confidence, mark hive_eligible)\n- entry <uuid> appears stale: [observable evidence]  (suggests archive \u2014 no longer injected)\n- entry <uuid> could be tighter: [what's verbose or duplicate]  (suggests rewrite with tighter version, max 280 chars)\n- entry <uuid> contradicts project state: [observable conflict]  (suggests tag as contradicted)\n- new candidate: [concise lesson text from observed patterns]  (suggests new entry)\nUse the UUID from KNOWLEDGE_ENTRIES when observing about existing entries. Use \"new candidate\" only when observing a potential new entry.\n\nEXTENDED_DIGEST:\n[the full running digest with this phase appended]\n\n## V3 ACTIONABILITY ENRICHMENT (overrides the format above when triggered)\nWhen the input asks you to \"Convert this prose lesson into an actionable knowledge directive\", ignore the PHASE_DIGEST output format entirely and output ONLY a single JSON object \u2014 no fences, no commentary, no digest.\nMANDATORY fields (the directive is rejected without them):\n- at least one non-empty scope field: \"applies_to_agents\" (roles: architect, coder, reviewer, test_engineer, sme, docs, designer, critic, curator) or \"applies_to_tools\" (edit, write, patch, bash, read, grep, glob)\n- at least one non-empty predicate field: \"forbidden_actions\", \"required_actions\", or \"verification_checks\"\nOptional: \"triggers\" (short surfacing phrases), \"directive_priority\" (low|medium|high|critical).\nExample output:\n{\"applies_to_agents\":[\"coder\"],\"forbidden_actions\":[\"use async iterators in hot paths\"],\"required_actions\":[\"use a plain for loop in hot paths\"],\"triggers\":[\"hot path\",\"async iterator\"],\"directive_priority\":\"high\"}\n";
 export declare function createExplorerAgent(model: string, customPrompt?: string, customAppendPrompt?: string): AgentDefinition;

package/dist/agents/reviewer-directive-compliance.d.ts

@@ -0,0 +1,43 @@
+/**
+ * Reviewer DIRECTIVE_COMPLIANCE support (Swarm Learning System, Change 2 /
+ * Task 2.1).
+ *
+ * The reviewer must emit a per-ID verdict for every knowledge directive shown
+ * during the phase. This module owns:
+ *   - DIRECTIVE_COMPLIANCE_OUTPUT_SPEC: the static format documentation embedded
+ *     in the reviewer system prompt (always present).
+ *   - buildDirectiveComplianceBlock: the dynamic, per-phase list of directive IDs
+ *     to verify (with priorities + any verification_predicate), injected into the
+ *     reviewer's delegation prompt at runtime.
+ *
+ * The verdict grammar is intentionally parser-friendly and mirrors the ack
+ * markers used elsewhere so a single reviewer-verdict parser can consume it.
+ */
+import type { DirectivePriority } from '../hooks/knowledge-types.js';
+/** Marker tag wrapping the per-phase "directives to verify" block. */
+export declare const DIRECTIVES_TO_VERIFY_TAG = "<directives_to_verify>";
+/** A directive the reviewer must produce a verdict for. */
+export interface DirectiveToVerify {
+    id: string;
+    priority: DirectivePriority;
+    lesson?: string;
+    verification_predicate?: string;
+}
+/**
+ * Static spec embedded in the reviewer system prompt. Documents the mandatory
+ * DIRECTIVE_COMPLIANCE output section and its verdict grammar.
+ */
+export declare const DIRECTIVE_COMPLIANCE_OUTPUT_SPEC = "DIRECTIVE_COMPLIANCE: one line per knowledge directive shown during this phase (the IDs are listed in the DIRECTIVES TO VERIFY block of your prompt). Use exactly one of:\n  VERIFIED:<id> evidence=<file:line | predicate_passed>\n  VIOLATED:<id> evidence=<file:line | failing_predicate>\n  N/A:<id> reason=<why it does not apply to this change>\nEvery listed directive ID MUST appear exactly once. If a directive carries a verification_predicate, you MUST run it and report predicate_passed / failing_predicate as the evidence. Omitting a listed directive ID is itself a VIOLATED verdict.";
+/**
+ * Render the per-phase "DIRECTIVES TO VERIFY" block injected into the reviewer's
+ * delegation prompt. Deterministic (sorted by priority then ID). Returns null
+ * when there is nothing to verify (no block emitted).
+ */
+export declare function buildDirectiveComplianceBlock(directives: DirectiveToVerify[]): string | null;
+/**
+ * Recover the directives a reviewer was asked to verify by parsing a
+ * `<directives_to_verify>` block back out of its delegation prompt. Used by the
+ * after-hook so reconciliation honors exactly what was shown (anti-spoofing).
+ * Returns [] when no block is present.
+ */
+export declare function parseDirectivesToVerifyBlock(text: string): DirectiveToVerify[];