opencode-swarm 7.112.2 → 7.113.1

package/.opencode/skills/parallel-work-check/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: parallel-work-check
+audience: swarm-plugin
+description: >
+  Apply before starting work on an existing branch. Checks for parallel work by
+  other agents or developers that may supersede or conflict with your planned
+  changes. Prevents wasted effort on stale branches.
+effort: small
+generated_from_knowledge: []
+source_knowledge_ids: ['f07c1f4d-9bb0-4219-9804-26aa8efe8146']
+generated_at: 2026-06-14T16:50:00Z
+confidence: 0.8
+status: active
+version: 4
+skill_origin: generated
+provenance_note: >
+  Re-linked to current knowledge entries (version 4). The original source ID
+  b8fee776... is no longer present in the active knowledge store. The skill
+  body and behavior are unchanged; only source_knowledge_ids metadata was
+  updated to point to the current lesson about verifying pre-existing state
+  on parent commit, which is directly relevant to the parallel-work-check
+  protocol.
+---
+
+# Parallel Work Check Protocol
+
+Run this check before starting ANY work on an existing branch (not a fresh branch
+you just created). This applies to PR branches, feature branches, and any branch
+that may have concurrent contributors.
+
+## Step 1 — Check current branch state
+
+1. Determine the current branch name.
+2. Determine the remote tracking branch (usually `origin/<branch-name>`).
+
+## Step 2 — Fetch remote state
+
+Fetch the latest state from the remote for the current branch. Do NOT skip this
+step because "the branch looks recent" or "I just checked."
+
+## Step 3 — Compare local vs remote
+
+Compare the local HEAD commit hash with the remote HEAD commit hash:
+
+- **Identical**: Remote has not diverged. Proceed with your work.
+- **Remote ahead**: The remote branch has commits you don't have locally.
+  - Read the new commit messages with `git log local..remote`.
+  - Check if any of those commits touch files you plan to modify.
+  - If yes: evaluate whether the parallel work supersedes your planned changes.
+  - If the parallel work is superior: reset your local branch to match remote
+    and abandon your planned approach. Document the decision.
+  - If the parallel work is complementary: integrate it first, then proceed.
+- **Local ahead**: You have local commits not on remote. This is normal if you
+  already started work. Proceed, but be aware that pushing may conflict with
+  subsequent remote changes.
+- **Diverged**: Both local and remote have unique commits. This requires
+  integration. Merge or rebase as appropriate for the team's workflow.
+
+## Step 4 — Check for parallel swarm/agent work
+
+If the remote has new commits:
+
+1. Check the commit authors. If commits are from a different swarm/agent
+   (different author name/email pattern), treat this as parallel swarm work.
+2. Parallel swarm work is often superior because:
+   - It may have access to different context or tools
+   - It may have started earlier or had more iterations
+   - It may have taken a fundamentally better approach
+3. Default stance: **prefer the parallel swarm's work** unless you can clearly
+   articulate why your approach is better.
+
+## Step 5 — Decision and documentation
+
+Before proceeding, document your decision:
+
+```
+PARALLEL WORK CHECK:
+- Branch: <name>
+- Local HEAD: <hash> <message>
+- Remote HEAD: <hash> <message>
+- Diverged: yes/no
+- New commits on remote: <count>
+- Parallel swarm work detected: yes/no
+- Decision: [proceed / integrate-then-proceed / abandon-use-remote / needs-review]
+- Rationale: <one sentence>
+```
+
+## Anti-patterns — do NOT do these
+
+- Skip the fetch because "I'm sure nothing changed."
+- Ignore remote commits because "my approach is probably better."
+- Start fixing code without checking if the remote already fixed it.
+- Blindly overwrite remote work with local changes without evaluating first.
+
+## Example: parallel swarm superseded local work
+
+```
+PARALLEL WORK CHECK:
+- Branch: codex/issue-956-plan-completion-gate
+- Local HEAD: 5aa34f88 fix(delegation-gate): block next task until completion is persisted
+- Remote HEAD: 2b4e9266 fix: correct contradictory test title/comments
+- Diverged: yes (remote is 8 commits ahead)
+- New commits on remote: 8
+- Parallel swarm work detected: yes (different commit author)
+- Decision: abandon-use-remote
+- Rationale: Parallel swarm restored file from main and re-integrated cleanly,
+  producing 486 passing tests vs our incremental patching which left 38 failures.
+```
+
+## Integration with swarm workflow
+
+This check should run:
+- At session start (MODE: RESUME or MODE: EXECUTE)
+- Before creating a new plan for an existing branch
+- Before dispatching the first coder task
+- After any significant pause where parallel work could have occurred
+
+## Integration with other skills
+
+The parallel-work-check skill is referenced by other skills that start work on an existing branch:
+
+| Skill | Usage |
+|-------|-------|
+| `file:.swarm/bundled-skills/swarm-pr-feedback/SKILL.md` | Checks before starting PR feedback fixes — ensures no parallel work has already addressed the same findings |
+| Legacy `pr-review-fix` alias | Compatibility entry that delegates to the bundled `swarm-pr-feedback` protocol |
+| `file:.swarm/bundled-skills/swarm-implement/SKILL.md` | Checks before implementation Phase 1 — ensures the branch is up-to-date before planning |
+| Any skill that starts work on an existing branch | Run the parallel-work-check protocol before beginning fixes or implementation |
+
+When a skill references parallel-work-check, the checking agent must:
+1. Fetch and compare remote vs local state
+2. Read any new commits from parallel work
+3. Evaluate whether the parallel work supersedes, complements, or does not affect the planned work
+4. Document the decision using the PARALLEL WORK CHECK template

package/.opencode/skills/phase-wrap/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: phase-wrap
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: PHASE-WRAP -- phase boundary evidence, drift and hallucination gates, retrospectives, phase completion, and final council.
 ---

package/.opencode/skills/plan/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: plan
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: PLAN -- plan creation, external plan ingestion, QA gate persistence, task granularity, and traceability checks.
 ---

package/.opencode/skills/pre-phase-briefing/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: pre-phase-briefing
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: PRE-PHASE BRIEFING -- phase-start context assembly, evidence review, and task readiness checks.
 ---

package/.opencode/skills/resume/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: resume
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: RESUME -- continuing an existing approved plan safely from current state.
 ---

package/.opencode/skills/running-tests/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: running-tests
+audience: swarm-plugin
 description: >
   Safe test execution patterns for opencode-swarm. Covers when to use the test_runner
   tool vs shell bun commands, scope safety rules, per-file isolation loops (bash and

package/.opencode/skills/skill-edit-validation/SKILL.md

@@ -1,5 +1,6 @@
----
+---
 name: skill-edit-validation
+audience: swarm-plugin
 description: Content-assertion sweep after editing SKILL.md files. Triggered when a task changes skill or prompt content that tests assert against. Prevents stale-assertion CI failures.
 ---
 

package/.opencode/skills/specify/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: specify
+audience: swarm-plugin
 description: >
   Full execution protocol for MODE: SPECIFY -- spec creation, codebase reality checks, SME input, QA gate persistence, and optional council spec review.
 ---

package/.opencode/skills/swarm/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: swarm
+audience: swarm-plugin
 description: Cross-agent swarm-mode behavior model — a higher-rigor workflow using parallel investigation, independent reviewer validation, and critic challenge, plus the mandatory implementation closeout gate. Runtime adapters (.claude, .agents) add execution-specific notes and command wiring.
 ---
 

package/.opencode/skills/swarm-ci-monitor/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: swarm-ci-monitor
+audience: swarm-plugin
 description: >
   End-to-end CI monitor that takes an already-human-reviewed PR, exhaustively
   researches every CI failure, fixes it end-to-end, iterates until all required
@@ -33,7 +34,7 @@ invoking user is the source of truth: only invoke after review is done.
 
 Load these skills before doing anything destructive (push / merge):
 
-- `../../../.opencode/skills/generated/ci-fix-monitor/SKILL.md` — for failure
+- `file:.swarm/bundled-skills/ci-fix-monitor/SKILL.md` — for failure
   classification and the per-type fix recipes (package-check, rebase,
   format/lint, macOS file I/O, integration, security, smoke). Do not re-derive
   these recipes here; ci-fix-monitor owns them.
@@ -94,9 +95,9 @@ Only after all three gates pass, enter the loop.
 Maintain an iteration counter starting at 5 (decremented at the end of each
 fix-push cycle, in 2g — this is a hard safety gate, not a soft target). At 0,
 stop (Step 5). This loop can span multiple CI runs and several minutes per
-iteration; if the session may compact mid-loop, persist the counter per
-`../../../.claude/skills/durable-session-state/SKILL.md` so the 5-cap
-survives a resume.
+iteration; if the session may compact mid-loop, record the remaining count in
+the active durable task/plan checkpoint and reload it on resume. Never reset
+the counter to 5 after compaction.
 
 ### 2a. Fetch check runs for the PR head SHA
 

package/.opencode/skills/swarm-implement/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: swarm-implement
+audience: swarm-plugin
 description: Execute complex implementation work with a swarm-like workflow: parallel exploration, scoped planning, objective validation, mandatory independent implementation review for changed work, and final critic approval. Use for feature work, bug fixes, refactors, and multi-file changes.
 disable-model-invocation: true
 ---
@@ -58,10 +59,9 @@ before coding.
 
 ### Phase 0a - Parallel work check
 
-If this project has the OpenCode-generated
-[`parallel-work-check` skill](../generated/parallel-work-check/SKILL.md), follow
-its full protocol. Otherwise, before starting implementation on an existing
-branch:
+Load and follow
+`file:.swarm/bundled-skills/parallel-work-check/SKILL.md`. Then, before
+starting implementation on an existing branch:
 
 1. Fetch remote state and compare with local (`git fetch` plus HEAD hashes).
 2. If parallel swarm work is detected on the target branch, read the new commits,

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

@@ -1,5 +1,6 @@
 ---
 name: swarm-pr-feedback
+audience: swarm-plugin
 description: >
   Ingest and resolve known pull request feedback with skeptical source verification.
   Use when addressing pasted PR feedback, GitHub review comments or threads,
@@ -183,8 +184,8 @@ tree:
 
 - If `head_ref` is a remote branch that is not checked out locally, fetch it
   (`git fetch origin <head_ref>`).
-- **Check for parallel work first.** Before checkout, run the
-  [`parallel-work-check`](../generated/parallel-work-check/SKILL.md) protocol to
+- **Check for parallel work first.** Before checkout, run
+  `file:.swarm/bundled-skills/parallel-work-check/SKILL.md` to
   detect concurrent pushes from other agents (e.g., `hermes-pr-review` bot
   following up, maintainer pushing fixes, parallel swarm work). If remote has new
   commits: read `git log local..remote`, evaluate whether the parallel work
@@ -512,9 +513,29 @@ or compatibility policy, mark the item `NEEDS_USER_DECISION` and ask.
 - When `main` has a merge queue enabled, do not rebase or force-push a PR only
   because `main` advanced. Once required checks and review are green, queue the PR
   and let the merge queue perform final current-base validation. Still resolve real
-  merge conflicts and SHA-dependent review threads before queuing.
-
-## Mandatory Gates
+   merge conflicts and SHA-dependent review threads before queuing.
+
+ ### Operational Gotchas
+
+ - **Plan identity change:** When switching from a review plan to a feedback-closure
+   plan, `save_plan` rejects with `PLAN_IDENTITY_MISMATCH`. Pass
+   `confirm_identity_change: true` to acknowledge the intentional overwrite.
+ - **Stale gate evidence:** After a plan identity change, `check_gate_status` returns
+   timestamps from the *prior* plan. Reset task statuses and re-run Stage A gates
+   before trusting gate results. Do not accept cached gate verdicts from before the
+   identity change.
+ - **PowerShell PR comment posting:** Complex markdown bodies containing backticks,
+   dollar signs, or nested quotes fail in PowerShell here-strings. Write the body
+   to a temp file and use `gh pr comment <number> --body-file <tempfile>` instead
+   of inline `--body "..."`.
+ - **Same-file batching:** Multiple findings targeting the same file for the same
+   review cycle CAN be fixed in one coder task when the fixes are trivially
+   independent (e.g., a one-line guard and a typo fix). When findings require
+   different fixes on different code paths, use separate coder tasks even if
+   targeting the same file. The "ONE task per coder" rule is about distinct
+   objectives, not about N edits to one file.
+
+ ## Mandatory Gates
 
 **Stage A and Stage B gates and the reviewer + critic closeout gate are
 MANDATORY for any change made as part of the PR-feedback process.** No fix

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

@@ -1,5 +1,6 @@
 ---
 name: swarm-pr-review
+audience: swarm-plugin
 description: Run a graph-guided, tool-augmented Swarm PR review using context packing, parallel exploration, triggered plugin micro-lanes, independent reviewer validation, critic challenge, and metrics writeback. Use for deep pull request review with low false-positive tolerance and high recall.
 disable-model-invocation: true
 ---
@@ -308,7 +309,7 @@ For each new commit on the remote:
    - Does the remote commit introduce a new branch-state fact the handoff should
      mention?
 3. **Default stance: prefer the remote state as the next baseline.** Run
-   the [`parallel-work-check`](../generated/parallel-work-check/SKILL.md)
+   `file:.swarm/bundled-skills/parallel-work-check/SKILL.md`
    protocol for the formal decision template and record the outcome in the
    handoff artifact.
 

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

@@ -1,5 +1,6 @@
 ---
 name: swarm-pr-subscribe
+audience: swarm-plugin
 description: >
   Monitor a pull request after creation and act autonomously on pushed PR
   activity. Use when subscribing to a PR after opening it, when asked to watch,

package/.opencode/skills/test-file-split/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: test-file-split
+audience: swarm-plugin
+description: Protocol for splitting test files that exceed the FR-006 500-line hard limit. Covers describe-block extraction, shared helper management, pure-function extraction, mock isolation verification, and cascading-split detection. Load when a test file approaches or exceeds 500 lines.
+---
+
+# Test File Split Protocol (FR-006)
+
+CI enforces a **hard 500-line limit** per test file (FR-006 / SC-006.1). Files exceeding this limit fail the quality gate and block PR merge. This skill covers the complete splitting protocol.
+
+Read first: `.opencode/skills/writing-tests/SKILL.md` (or `.claude/skills/writing-tests/SKILL.md`) for bun:test framework rules, mock isolation patterns, and file placement conventions.
+
+## When to use this skill
+
+- A test file exceeds or approaches 500 lines
+- CI fails with an FR-006 file-size violation
+- You are adding tests to a file that is already above 400 lines (proactive split)
+
+## Step 1 — Measure and identify split boundaries
+
+```bash
+# Check the file
+wc -l tests/unit/scripts/my-module.test.ts
+
+# Find all test files exceeding 400 lines (early warning)
+find tests/ -name "*.test.ts" -exec wc -l {} \; | sort -rn | awk '$1 > 400'
+```
+
+Identify natural `describe()` block boundaries. Group blocks by functional area:
+- Each `describe()` block should belong to exactly one split file
+- Shared `beforeEach`/`afterEach` hooks determine which blocks must stay together
+
+## Step 2 — Choose a suffix for the new file
+
+| Pattern | Example | When to use |
+|---------|---------|-------------|
+| `<module>-<area>.test.ts` | `release-notes-fragments-sha.test.ts` | Split by functional area (SHA resolution, validation, merge logic) |
+| `<module>-<area>.adversarial.test.ts` | `auth-login.adversarial.test.ts` | Split adversarial tests into their own file |
+
+## Step 3 — Manage shared imports and helpers
+
+Three options, in order of preference:
+
+1. **Extract to shared utility (preferred for complex shared setup):**
+   Create `tests/helpers/<module>-shared.ts` with shared fixtures, mock factories, and setup functions. Import from both split files.
+
+2. **Duplicate simple imports (for small overlap):**
+   If only `bun:test` imports and 1-2 source imports are shared, duplicate them in both files. Simpler than a utility module for trivial cases.
+
+3. **Extract pure functions from source (for testability):**
+   If the source module has inline validation logic, extract them as exported pure functions (e.g., `isValidPrNumber`, `resolveAllCandidates`) so both test files can target them independently. See the PR #1762 example below. See `.opencode/skills/generated/safe-extraction/SKILL.md` for the source extraction pattern.
+
+## Step 4 — Extract and move describe blocks
+
+1. Cut the selected `describe()` blocks from the original file.
+2. Paste them into the new file.
+3. Add all necessary imports to the new file.
+4. Remove now-unused imports from the original file.
+
+## Step 5 — Verify both files
+
+### Line count check
+```bash
+wc -l tests/unit/scripts/my-module.test.ts tests/unit/scripts/my-module-sha.test.ts
+# Both must be under 500 lines
+```
+
+### Isolated run
+```bash
+bun --smol test tests/unit/scripts/my-module.test.ts --timeout 60000
+bun --smol test tests/unit/scripts/my-module-sha.test.ts --timeout 60000
+```
+
+### Co-run (mock isolation verification)
+```bash
+# Critical: Bun shares a single process across test files.
+# mock.module leaks can cause co-run failures even when isolated runs pass.
+bun --smol test tests/unit/scripts/my-module*.test.ts --timeout 60000
+```
+
+If the co-run fails but isolated runs pass, check for `mock.module()` leakage. See `.opencode/skills/writing-tests/SKILL.md` → "Mock Isolation Rules" and the `_internals` DI seam pattern.
+
+## Step 6 — Evaluate `_test_exports` opportunity
+
+After splitting, evaluate whether internal utility functions in the source module can be exported via `_test_exports` for zero-mock testing. This is a natural cleanup moment — the split already forces you to review test coverage boundaries.
+
+## Cascading split warning
+
+If a previously split file exceeds 500 lines **again**, the test suite is structurally too large for a single module. Do not split a third time — reorganize the tests by source module boundaries instead. Repeated splitting produces fragmented test suites that are hard to navigate and maintain.
+
+## Real-world example (PR #1762 — pending merge)
+
+> **Note:** This example references functions and files from PR #1762's branch. These do not exist on `main` until the PR is merged. The pattern is still valid as an illustration of the splitting protocol.
+
+`tests/unit/scripts/release-notes-fragments.test.ts` exceeded 500 lines. It was split into:
+
+| File | Lines | Content |
+|------|-------|---------|
+| `release-notes-fragments.test.ts` | 379 | Fragment collection, deduplication, output formatting |
+| `release-notes-fragments-sha.test.ts` | 261 | `extractCommitShasFromBody`, `mergeCandidateLists`, `resolveAllCandidates`, `isValidPrNumber`, `stripCustomReleaseNotesBlock` |
+
+The split also extracted `isValidPrNumber` and `resolveAllCandidates` as pure exported functions from the source module, enabling independent testing.

package/.opencode/skills/worktree-retry-cleanup/SKILL.md

@@ -1,5 +1,6 @@
----
+---
 name: worktree-retry-cleanup
+audience: swarm-plugin
 description: Protocol for cleaning parallel-coder worktree lanes before retry. Triggered before re-dispatching any task that already has a lane (completed, denied, cancelled, or failed).
 ---
 

package/.opencode/skills/writing-tests/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: writing-tests
+audience: swarm-plugin
 description: >
   Guidelines for writing, organizing, and maintaining tests in the opencode-swarm repository.
   Covers framework rules (bun:test), mock isolation, CI pipeline structure, file placement,
@@ -610,6 +611,48 @@ authority checks:
 - For matcher caches or other shared state, test both priming orders when the
   selected behavior depends on mode, platform, or prior calls.
 
+## FR-006: Test File Size Limit (500 lines)
+
+CI enforces a **hard 500-line limit** per test file (FR-006). Files exceeding this limit fail the quality gate and block PR merge.
+
+### Checking file length
+
+```bash
+# Check a single file
+wc -l tests/unit/scripts/my-test.test.ts
+
+# Find all test files exceeding 400 lines (early warning threshold)
+find tests/ -name "*.test.ts" -exec wc -l {} \; | sort -rn | awk '$1 > 400'
+```
+
+### Splitting pattern
+
+When a test file approaches or exceeds 500 lines, split it by extracting cohesive `describe()` blocks into a new file with a descriptive suffix:
+
+1. **Identify natural boundaries.** Group `describe()` blocks by functional area (e.g., SHA resolution, validation, merge logic).
+2. **Create the new file** with a descriptive suffix: `<module>-<area>.test.ts` (e.g., `release-notes-fragments-sha.test.ts`, `release-notes-fragments-validation.test.ts`).
+3. **Move shared imports and helpers.** Either:
+   - Duplicate shared imports in both files (simple, for small overlap), OR
+   - Extract shared test helpers to a utility module (e.g., `tests/helpers/<module>-shared.ts`) and import from both files (preferred for complex shared setup).
+4. **Extract testable pure functions.** If the source module has inline validation logic (e.g., `isValidPrNumber`), extract it as an exported pure function so both test files can target it independently.
+5. **Verify both files are under 500 lines.**
+6. **Run both files independently AND co-run** to verify no mock isolation breakage:
+   ```bash
+   bun --smol test tests/unit/scripts/release-notes-fragments.test.ts --timeout 60000
+   bun --smol test tests/unit/scripts/release-notes-fragments-sha.test.ts --timeout 60000
+   bun --smol test tests/unit/scripts/release-notes-fragments*.test.ts --timeout 60000
+   ```
+
+### When to split vs refactor
+
+- **Split** when there are natural `describe()` boundaries (e.g., one file per functional area).
+- **Refactor** when the file is a single monolithic test with no clear boundaries — consolidate test logic instead.
+- **Warning:** If a previously split file exceeds 500 lines again, the test suite is structurally too large. Reorganize by module rather than continuing to split.
+
+### Reference
+
+See PR #1762 for a real-world example: `release-notes-fragments.test.ts` was split into `release-notes-fragments.test.ts` (379 lines) + `release-notes-fragments-sha.test.ts` (261 lines).
+
 ## Cross-Entry Invariants (config maps)
 
 When you modify any entry of a "map of agents/tools/roles" in `src/config/constants.ts` (`AGENT_TOOL_MAP`, `DEFAULT_MODELS`, `QA_AGENTS`, `PIPELINE_AGENTS`, etc.) or tool-name registration in `src/tools/tool-names.ts`, there are tests that assert **parity across sibling entries**, not just shape of one entry.

package/dist/cli/{config-doctor-mmw4c50z.js → config-doctor-az11cwf5.js}

@@ -12,8 +12,8 @@ import {
   shouldRunOnStartup,
   writeBackupArtifact,
   writeDoctorArtifact
-} from "./index-xehrmy76.js";
-import"./index-cq2hgvd2.js";
+} from "./index-0gf6de8b.js";
+import"./index-1ey3dxq7.js";
 import"./index-bfwt3abw.js";
 import"./index-5e4e2hvv.js";
 import"./index-p0arc26j.js";

package/dist/cli/{curator-llm-factory-5bns4xy6.js → curator-llm-factory-nmhzc774.js}

@@ -1,16 +1,16 @@
 // @bun
 import {
   createCuratorLLMDelegate
-} from "./index-snmfqhez.js";
-import"./index-npxmfj48.js";
+} from "./index-npd9rypp.js";
+import"./index-8f256d7t.js";
 import"./index-c8s9a3zh.js";
-import"./index-xehrmy76.js";
-import"./index-cq2hgvd2.js";
+import"./index-0gf6de8b.js";
+import"./index-1ey3dxq7.js";
 import"./index-d0w40jm3.js";
 import"./index-scww5b77.js";
 import"./index-9fxs0rm1.js";
 import"./index-q1jaeynn.js";
-import"./index-82v0d72f.js";
+import"./index-h389ed8y.js";
 import"./index-30ejh1tx.js";
 import"./index-t6wfwdm1.js";
 import"./index-hpp2r0sd.js";

package/dist/cli/{curator-snvp9542.js → curator-nm2c9y1p.js}

@@ -12,16 +12,16 @@ import {
   runCuratorInit,
   runCuratorPhase,
   writeCuratorSummary
-} from "./index-snmfqhez.js";
-import"./index-npxmfj48.js";
+} from "./index-npd9rypp.js";
+import"./index-8f256d7t.js";
 import"./index-c8s9a3zh.js";
-import"./index-xehrmy76.js";
-import"./index-cq2hgvd2.js";
+import"./index-0gf6de8b.js";
+import"./index-1ey3dxq7.js";
 import"./index-d0w40jm3.js";
 import"./index-scww5b77.js";
 import"./index-9fxs0rm1.js";
 import"./index-q1jaeynn.js";
-import"./index-82v0d72f.js";
+import"./index-h389ed8y.js";
 import"./index-30ejh1tx.js";
 import"./index-t6wfwdm1.js";
 import"./index-hpp2r0sd.js";

package/dist/cli/{guardrail-explain-4s7djf9p.js → guardrail-explain-q1np1xaw.js}

@@ -1,17 +1,17 @@
 // @bun
 import {
   handleGuardrailExplain
-} from "./index-9fjpecax.js";
-import"./index-snmfqhez.js";
-import"./index-npxmfj48.js";
+} from "./index-ky8eb4q6.js";
+import"./index-npd9rypp.js";
+import"./index-8f256d7t.js";
 import"./index-c8s9a3zh.js";
-import"./index-xehrmy76.js";
-import"./index-cq2hgvd2.js";
+import"./index-0gf6de8b.js";
+import"./index-1ey3dxq7.js";
 import"./index-d0w40jm3.js";
 import"./index-scww5b77.js";
 import"./index-9fxs0rm1.js";
 import"./index-q1jaeynn.js";
-import"./index-82v0d72f.js";
+import"./index-h389ed8y.js";
 import"./index-30ejh1tx.js";
 import"./index-t6wfwdm1.js";
 import"./index-hpp2r0sd.js";

package/dist/cli/{guardrail-log-xjgr00eq.js → guardrail-log-hysxdwg9.js}

@@ -1,9 +1,9 @@
 // @bun
 import {
   handleGuardrailLog
-} from "./index-w84stmkx.js";
-import"./index-npxmfj48.js";
-import"./index-cq2hgvd2.js";
+} from "./index-r9fjzr3k.js";
+import"./index-8f256d7t.js";
+import"./index-1ey3dxq7.js";
 import"./index-bfwt3abw.js";
 import"./index-5e4e2hvv.js";
 import"./index-p0arc26j.js";

package/dist/cli/{hive-promoter-zs295trk.js → hive-promoter-z4dezw62.js}

@@ -5,16 +5,16 @@ import {
   isHiveEligible,
   promoteFromSwarm,
   promoteToHive
-} from "./index-snmfqhez.js";
-import"./index-npxmfj48.js";
+} from "./index-npd9rypp.js";
+import"./index-8f256d7t.js";
 import"./index-c8s9a3zh.js";
-import"./index-xehrmy76.js";
-import"./index-cq2hgvd2.js";
+import"./index-0gf6de8b.js";
+import"./index-1ey3dxq7.js";
 import"./index-d0w40jm3.js";
 import"./index-scww5b77.js";
 import"./index-9fxs0rm1.js";
 import"./index-q1jaeynn.js";
-import"./index-82v0d72f.js";
+import"./index-h389ed8y.js";
 import"./index-30ejh1tx.js";
 import"./index-t6wfwdm1.js";
 import"./index-hpp2r0sd.js";

package/dist/cli/{index-xehrmy76.js → index-0gf6de8b.js}

@@ -5,7 +5,7 @@ import {
   GateConfigSchema,
   PluginConfigSchema,
   stripKnownSwarmPrefix
-} from "./index-cq2hgvd2.js";
+} from "./index-1ey3dxq7.js";
 import {
   log
 } from "./index-zgwm4ryv.js";

package/dist/cli/{index-cq2hgvd2.js → index-1ey3dxq7.js}

@@ -1839,9 +1839,17 @@ var KnowledgeApplicationConfigSchema = exports_external.object({
     "Task"
   ])
 });
+var SkillPropagationAudienceSchema = exports_external.string().max(64).refine((value) => value !== "swarm-plugin", {
+  message: "swarm-plugin is reserved for plugin-internal skill routing"
+}).refine((value) => !value.startsWith("runner:"), {
+  message: "runner:* values are derived from the active runner"
+}).regex(/^[a-z0-9]+(?:[._-][a-z0-9]+)*$/, {
+  message: "audiences must be lowercase domain tokens"
+});
 var SkillPropagationConfigSchema = exports_external.object({
   enabled: exports_external.boolean().default(true),
-  enforce: exports_external.boolean().default(false)
+  enforce: exports_external.boolean().default(false),
+  audiences: exports_external.array(SkillPropagationAudienceSchema).max(16).transform((values) => [...new Set(values)]).default([])
 });
 var SkillImproverConfigSchema = exports_external.object({
   enabled: exports_external.boolean().default(false),

package/dist/cli/{index-npxmfj48.js → index-8f256d7t.js}

@@ -1,7 +1,7 @@
 // @bun
 import {
   stripKnownSwarmPrefix
-} from "./index-cq2hgvd2.js";
+} from "./index-1ey3dxq7.js";
 import {
   init_logger,
   warn