@zelari/core 0.7.9 → 0.7.11

package/dist/agents/skills/builtin/testing.js

@@ -1,17 +1,17 @@
 import { registerCodingSkill } from '../../skills.js';
-const CLARIFICATION_PROTOCOL = `
-
-WHEN TO ASK THE USER (clarification):
-If a single missing fact would materially change your output (target platform, scope, a binary design choice with significant trade-offs, a constraint you cannot safely assume), pause and ask the user by appending EXACTLY this block at the end of your message:
-
----QUESTION---
-{ "question": "One focused question", "choices": ["Option A", "Option B", "Option C"], "context": "Why this matters" }
----END---
-
-Rules for clarifications:
-- Ask AT MOST ONE question per turn, and only when genuinely blocked.
-- Prefer a small set of concrete "choices" (2-4). The user can still type a custom answer.
-- Do NOT ask for information that could be reasonably assumed or already in shared context.
+const CLARIFICATION_PROTOCOL = `
+
+WHEN TO ASK THE USER (clarification):
+If a single missing fact would materially change your output (target platform, scope, a binary design choice with significant trade-offs, a constraint you cannot safely assume), pause and ask the user by appending EXACTLY this block at the end of your message:
+
+---QUESTION---
+{ "question": "One focused question", "choices": ["Option A", "Option B", "Option C"], "context": "Why this matters" }
+---END---
+
+Rules for clarifications:
+- Ask AT MOST ONE question per turn, and only when genuinely blocked.
+- Prefer a small set of concrete "choices" (2-4). The user can still type a custom answer.
+- Do NOT ask for information that could be reasonably assumed or already in shared context.
 - If you can proceed with a sound documented assumption, DO SO instead of asking.`;
 const writeUnitTests = {
     id: 'write-unit-tests',
@@ -57,31 +57,31 @@ const writeUnitTests = {
         },
     ],
     outputSchema: '{ testFile: string; tests: Array<{ name: string; input: unknown; expected?: unknown; options?: Record<string, unknown>; expectedThrows?: string }> }',
-    systemPromptFragment: `You are writing Vitest unit tests for a function or module.
-
-## Methodology
-1. **Read the source**: understand the function signature, branches, error paths.
-2. **Identify happy paths**: at least 2 tests for typical inputs.
-3. **Identify edge cases** (boundaries): 0, 1, max, empty array, empty string.
-4. **Identify error paths**: invalid input, network errors, partial data.
-5. **Write one test per assertion** — easier to debug when a test fails.
-6. **Use Vitest patterns**: describe/it/expect, vi.fn() for mocks, vi.spyOn for stubs.
-
-## Test naming
-- Use \`describe('moduleName', () => { it('does X when Y', ...) })\`.
-- Test name describes behavior, not implementation.
-- Group related tests in the same describe block.
-
-## Output format (JSON-typed)
-- testFile: string (the file path)
-- tests: Array<{ name, input, expected, options?, expectedThrows? }>
-
-## Anti-patterns to avoid
-- Tests that always pass (tautologies)
-- Tests with multiple assertions (split into separate tests)
-- Tests that depend on test execution order
-- Snapshot tests for non-deterministic output
-
+    systemPromptFragment: `You are writing Vitest unit tests for a function or module.
+
+## Methodology
+1. **Read the source**: understand the function signature, branches, error paths.
+2. **Identify happy paths**: at least 2 tests for typical inputs.
+3. **Identify edge cases** (boundaries): 0, 1, max, empty array, empty string.
+4. **Identify error paths**: invalid input, network errors, partial data.
+5. **Write one test per assertion** — easier to debug when a test fails.
+6. **Use Vitest patterns**: describe/it/expect, vi.fn() for mocks, vi.spyOn for stubs.
+
+## Test naming
+- Use \`describe('moduleName', () => { it('does X when Y', ...) })\`.
+- Test name describes behavior, not implementation.
+- Group related tests in the same describe block.
+
+## Output format (JSON-typed)
+- testFile: string (the file path)
+- tests: Array<{ name, input, expected, options?, expectedThrows? }>
+
+## Anti-patterns to avoid
+- Tests that always pass (tautologies)
+- Tests with multiple assertions (split into separate tests)
+- Tests that depend on test execution order
+- Snapshot tests for non-deterministic output
+
 Stay under 500 words.${CLARIFICATION_PROTOCOL}`,
 };
 const writeIntegrationTests = {
@@ -128,26 +128,26 @@ const writeIntegrationTests = {
         },
     ],
     outputSchema: '{ testFile: string; scenarios: Array<{ name: string; steps: string[] }>; contracts: Array<{ between: string; contract: string }> }',
-    systemPromptFragment: `You are writing integration tests that span multiple components.
-
-## Methodology
-1. **Identify the integration boundary**: which 2+ components interact?
-2. **Document the contract**: what does component A promise to component B?
-3. **Test the contract, not the internals**: verify the OBSERVABLE behavior, not the implementation.
-4. **Use real subsystems where possible**: in-memory SQLite instead of mocks; fake HTTP server instead of stubbed client.
-5. **Each scenario is a complete user story**: setup → action → verify.
-
-## Output format (JSON-typed)
-- testFile: string
-- scenarios: Array<{ name, steps[] }>
-- contracts: Array<{ between, contract }>
-
-## Integration test principles
-- **Minimal mocks**: mock only the OUTSIDE world (network, disk, time), not your own code
-- **Real data**: use realistic test data, not "foo" / "bar"
-- **Deterministic**: avoid timing-based assertions (use polling with timeout)
-- **Cleanup**: each scenario should leave the system in a clean state
-
+    systemPromptFragment: `You are writing integration tests that span multiple components.
+
+## Methodology
+1. **Identify the integration boundary**: which 2+ components interact?
+2. **Document the contract**: what does component A promise to component B?
+3. **Test the contract, not the internals**: verify the OBSERVABLE behavior, not the implementation.
+4. **Use real subsystems where possible**: in-memory SQLite instead of mocks; fake HTTP server instead of stubbed client.
+5. **Each scenario is a complete user story**: setup → action → verify.
+
+## Output format (JSON-typed)
+- testFile: string
+- scenarios: Array<{ name, steps[] }>
+- contracts: Array<{ between, contract }>
+
+## Integration test principles
+- **Minimal mocks**: mock only the OUTSIDE world (network, disk, time), not your own code
+- **Real data**: use realistic test data, not "foo" / "bar"
+- **Deterministic**: avoid timing-based assertions (use polling with timeout)
+- **Cleanup**: each scenario should leave the system in a clean state
+
 Stay under 500 words.${CLARIFICATION_PROTOCOL}`,
 };
 const regressionTest = {
@@ -180,35 +180,35 @@ const regressionTest = {
             input: 'Bug: "Council shows duplicate user message at session resume" was just fixed in commit a3f9d',
             output: {
                 testFile: 'tests/regression/duplicate-user-message.test.ts',
-                test: `import { describe, it, expect } from 'vitest';
-import { runCouncilPure } from '../agents/councilApi.js';
-
-describe('regression: duplicate user message at session resume', () => {
-  it('does not render duplicate user message when session resumes with duplicate input', async () => {
-    const messages = [
-      { role: 'user' as const, content: 'hi' },
-      { role: 'user' as const, content: 'hi' }, // duplicate from session resume
-    ];
-    const mockProvider = async function* () {
-      yield { kind: 'text' as const, delta: 'response' };
-      yield { kind: 'finish' as const, reason: 'stop' };
-    };
-    const events = [];
-    for await (const e of runCouncilPure('hi', {
-      model: 'test', provider: 'test',
-      messages,
-      tools: [],
-      councilSize: 1,
-      debateMode: false,
-      ragContext: '',
-      workspaceContext: '',
-      providerStream: mockProvider,
-    }, {})) {
-      events.push(e);
-    }
-    const userMessageDeltas = events.filter(e => e.type === 'message_delta').length;
-    expect(userMessageDeltas).toBe(1); // exactly 1, not 2
-  });
+                test: `import { describe, it, expect } from 'vitest';
+import { runCouncilPure } from '../agents/councilApi.js';
+
+describe('regression: duplicate user message at session resume', () => {
+  it('does not render duplicate user message when session resumes with duplicate input', async () => {
+    const messages = [
+      { role: 'user' as const, content: 'hi' },
+      { role: 'user' as const, content: 'hi' }, // duplicate from session resume
+    ];
+    const mockProvider = async function* () {
+      yield { kind: 'text' as const, delta: 'response' };
+      yield { kind: 'finish' as const, reason: 'stop' };
+    };
+    const events = [];
+    for await (const e of runCouncilPure('hi', {
+      model: 'test', provider: 'test',
+      messages,
+      tools: [],
+      councilSize: 1,
+      debateMode: false,
+      ragContext: '',
+      workspaceContext: '',
+      providerStream: mockProvider,
+    }, {})) {
+      events.push(e);
+    }
+    const userMessageDeltas = events.filter(e => e.type === 'message_delta').length;
+    expect(userMessageDeltas).toBe(1); // exactly 1, not 2
+  });
 });`,
                 whyRegression: 'Bug was reported 3 times in the last month. The fix (dedup user messages on session resume) was in commit a3f9d. This test guards against future refactors breaking the dedup logic.',
                 bugCommit: 'a3f9d',
@@ -216,26 +216,26 @@ describe('regression: duplicate user message at session resume', () => {
         },
     ],
     outputSchema: '{ testFile: string; test: string; whyRegression: string; bugCommit: string }',
-    systemPromptFragment: `You are converting a fixed bug into a permanent regression test.
-
-## Methodology
-1. **Confirm the bug is FIXED**: check git log / recent commits for the fix.
-2. **Write the test**: it should FAIL if you revert the fix (verify this mentally).
-3. **Add a comment** in the test file linking to the bug commit.
-4. **Place in tests/regression/**: separate from unit tests for visibility.
-
-## Output format (JSON-typed)
-- testFile: string
-- test: string (the full test code, runnable as-is)
-- whyRegression: string (why this test should stay forever)
-- bugCommit: string (the commit hash that fixed the bug)
-
-## Regression test principles
-- **One test per bug** — easier to identify which regression fired
-- **Reference the bug commit** in a comment so future devs understand the history
-- **Minimal repro** — strip to the essential trigger, don't include unrelated setup
-- **Never delete a regression test** without a written justification (the bug came back once, it'll come back again)
-
+    systemPromptFragment: `You are converting a fixed bug into a permanent regression test.
+
+## Methodology
+1. **Confirm the bug is FIXED**: check git log / recent commits for the fix.
+2. **Write the test**: it should FAIL if you revert the fix (verify this mentally).
+3. **Add a comment** in the test file linking to the bug commit.
+4. **Place in tests/regression/**: separate from unit tests for visibility.
+
+## Output format (JSON-typed)
+- testFile: string
+- test: string (the full test code, runnable as-is)
+- whyRegression: string (why this test should stay forever)
+- bugCommit: string (the commit hash that fixed the bug)
+
+## Regression test principles
+- **One test per bug** — easier to identify which regression fired
+- **Reference the bug commit** in a comment so future devs understand the history
+- **Minimal repro** — strip to the essential trigger, don't include unrelated setup
+- **Never delete a regression test** without a written justification (the bug came back once, it'll come back again)
+
 Stay under 300 words.${CLARIFICATION_PROTOCOL}`,
 };
 // Register in topological order

package/dist/agents/skills.js

@@ -29,11 +29,11 @@ export const SKILL_CATALOG = [
         enabledByDefault: true,
         builtin: true,
         requiredTools: ['createDocument', 'updateDocument', 'searchDocuments', 'linkDocuments'],
-        systemPromptFragment: `You can manage the Knowledge Vault directly.
-- Documents are markdown files with a path (e.g. "notes/architecture"), title, content, tags, and optional category.
-- Connect documents with [[wikilinks]]: write [[target]] or [[target|alias]] inside the content.
-- Add #hashtags anywhere in the content to tag a document.
-- Optional YAML frontmatter may precede the body (key: value lines wrapped in ---).
+        systemPromptFragment: `You can manage the Knowledge Vault directly.
+- Documents are markdown files with a path (e.g. "notes/architecture"), title, content, tags, and optional category.
+- Connect documents with [[wikilinks]]: write [[target]] or [[target|alias]] inside the content.
+- Add #hashtags anywhere in the content to tag a document.
+- Optional YAML frontmatter may precede the body (key: value lines wrapped in ---).
 - Prefer creating durable notes over answering in chat when the information is reusable.`,
     },
     {
@@ -48,11 +48,11 @@ export const SKILL_CATALOG = [
         enabledByDefault: true,
         builtin: true,
         requiredTools: ['createPlan', 'createTask', 'createPhase', 'createMilestone', 'updateTask'],
-        systemPromptFragment: `You plan projects hierarchically.
-- Decompose work into phases, then tasks within phases.
-- For each task include: title, description, priority (low|medium|high|critical), and optional tags/subtasks.
-- Define milestones to mark key deliverables.
-- When relevant, reference file paths and acceptance criteria.
+        systemPromptFragment: `You plan projects hierarchically.
+- Decompose work into phases, then tasks within phases.
+- For each task include: title, description, priority (low|medium|high|critical), and optional tags/subtasks.
+- Define milestones to mark key deliverables.
+- When relevant, reference file paths and acceptance criteria.
 - Prefer ONE createPlan call (phases with nested tasks + milestone) over many itemized createPhase/createTask calls.`,
     },
     {
@@ -67,9 +67,9 @@ export const SKILL_CATALOG = [
         enabledByDefault: true,
         builtin: true,
         requiredTools: ['addIdea', 'clusterIdeas'],
-        systemPromptFragment: `You generate and organize ideas.
-- Produce a diverse set of ideas, then cluster related ones.
-- Tag ideas consistently and assign a category.
+        systemPromptFragment: `You generate and organize ideas.
+- Produce a diverse set of ideas, then cluster related ones.
+- Tag ideas consistently and assign a category.
 - Evaluate feasibility and novelty briefly.`,
     },
     {
@@ -84,9 +84,9 @@ export const SKILL_CATALOG = [
         enabledByDefault: false,
         builtin: true,
         requiredTools: ['buildMindMap', 'addNode', 'linkNodes', 'createMindMapNode'],
-        systemPromptFragment: `You build mind maps as JSON structures.
-- Root → branches → leaves.
-- Each node has a label and short content.
+        systemPromptFragment: `You build mind maps as JSON structures.
+- Root → branches → leaves.
+- Each node has a label and short content.
 - Use semantic colors and connect nodes that relate to vault documents.`,
     },
     {
@@ -104,10 +104,10 @@ export const SKILL_CATALOG = [
         // network tools wherever the executor registry provides them (the
         // executable filter drops them where they don't exist).
         requiredTools: ['searchRAG', 'searchDocuments', 'web_search', 'fetch_url'],
-        systemPromptFragment: `You research using the retrieval system and the web.
-- Use the retrieval tool listed in your AVAILABLE TOOLS (searchDocuments or searchRAG) to find prior knowledge before answering.
-- For external facts (library docs, APIs, best practices), use web_search, then fetch_url on the best result.
-- Cite sources (document title or URL) when you rely on retrieved content.
+        systemPromptFragment: `You research using the retrieval system and the web.
+- Use the retrieval tool listed in your AVAILABLE TOOLS (searchDocuments or searchRAG) to find prior knowledge before answering.
+- For external facts (library docs, APIs, best practices), use web_search, then fetch_url on the best result.
+- Cite sources (document title or URL) when you rely on retrieved content.
 - Structure analyses with clear sections and a conclusion.`,
     },
     {
@@ -122,9 +122,9 @@ export const SKILL_CATALOG = [
         enabledByDefault: false,
         builtin: true,
         requiredTools: ['createDocument', 'updateDocument'],
-        systemPromptFragment: `You write polished documents.
-- Choose an appropriate structure (guide, spec, reference, narrative).
-- Maintain a consistent tone and voice.
+        systemPromptFragment: `You write polished documents.
+- Choose an appropriate structure (guide, spec, reference, narrative).
+- Maintain a consistent tone and voice.
 - Use headings, lists, and code blocks where helpful; link related notes with [[wikilinks]].`,
     },
 ];

package/dist/council/modeBanners.js

@@ -1,6 +1,6 @@
-export const DESIGN_PHASE_MODE_BANNER = `COUNCIL RUN MODE: design-phase.
+export const DESIGN_PHASE_MODE_BANNER = `COUNCIL RUN MODE: design-phase.
 Workspace tool emissions described in your role prompt are MANDATORY in this run — prose alone does not count as a deliverable. Persist artifacts via the workspace tools listed in your AVAILABLE TOOLS section.`;
-export const IMPLEMENTATION_MODE_BANNER = `COUNCIL RUN MODE: implementation.
+export const IMPLEMENTATION_MODE_BANNER = `COUNCIL RUN MODE: implementation.
 Prefer write_file, edit_file, and bash for code changes. Design-phase mandatory workspace blocks in your role prompt are INACTIVE in this run — only call workspace tools when they add durable project value.`;
 export function councilModeBanner(runMode) {
     return runMode === 'design-phase'

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zelari/core",
-  "version": "0.7.9",
+  "version": "0.7.11",
   "description": "Zelari Code core library — provider-neutral agent loop (AgentHarness), multi-agent council orchestration, and built-in skills. Used by the zelari-code CLI; consumable by other agent frontends.",
   "author": "N-THEM Studio",
   "license": "MIT",