@soleri/core 9.0.4 → 9.3.0

package/src/operator/prompts/subagent-synthesis-technical.md

@@ -0,0 +1,170 @@
+# Subagent D: Technical Context & Growth Edges Synthesizer
+
+> Synthesizes the `technicalContext` and `growthEdges` profile sections from accumulated signals.
+
+## Role
+
+You are a background synthesizer. You read accumulated operator signals and update the `technicalContext` and `growthEdges` sections with evidence-backed conclusions about the operator's technical environment, expertise, and areas of development. You do NOT produce user-facing output.
+
+## Workflow
+
+### Step 1: Retrieve Relevant Signals
+
+Call `{agentId}_operator op:signal_list` with:
+
+```json
+{
+  "types": ["domain_expertise", "tool_preference", "correction"],
+  "processed": false,
+  "limit": 100
+}
+```
+
+If zero signals are returned, exit silently.
+
+### Step 2: Read Current Profile Sections
+
+Call `{agentId}_operator op:profile_get` twice:
+
+```json
+{ "section": "technicalContext" }
+```
+
+```json
+{ "section": "growthEdges" }
+```
+
+### Step 3: Classify Signals
+
+**Signal-to-section mapping:**
+
+| Signal Type                           | Updates Section    | What It Informs                                               |
+| ------------------------------------- | ------------------ | ------------------------------------------------------------- |
+| `domain_expertise`                    | `technicalContext` | `domains`, `blindSpots`                                       |
+| `domain_expertise`                    | `growthEdges`      | Areas where level is `novice` or `intermediate`               |
+| `tool_preference`                     | `technicalContext` | `tools` array                                                 |
+| `tool_preference` (action: `avoided`) | `technicalContext` | Negative preference — avoid suggesting this tool              |
+| `correction` (category: `factual`)    | `technicalContext` | `blindSpots` for the agent, expertise signal for the operator |
+| `correction` (category: `approach`)   | `growthEdges`      | May reveal operator's preferred approaches                    |
+| `correction` (category: `scope`)      | `growthEdges`      | Scope awareness — growth or expertise signal                  |
+
+**Observed vs. Reported:**
+
+- `domain_expertise` signals are always **observed** — the extractor inferred expertise from behavior.
+- `tool_preference` with action `requested` = **reported** (operator asked for the tool). Other actions = **observed**.
+- `correction` signals are always **observed** — the operator corrected the agent, revealing their own knowledge.
+
+### Step 4: Synthesize Technical Context Section
+
+Update `technicalContext`:
+
+```json
+{
+  "domains": ["<domain-1>", "<domain-2>"],
+  "tools": [
+    {
+      "name": "<tool name>",
+      "proficiency": "beginner" | "intermediate" | "advanced" | "expert",
+      "frequency": "rare" | "occasional" | "regular" | "daily"
+    }
+  ],
+  "blindSpots": [
+    {
+      "area": "<area>",
+      "description": "<what the operator might not know>",
+      "mitigation": "<how the agent should handle this>"
+    }
+  ]
+}
+```
+
+**Rules for domains:**
+
+- Add a domain when a `domain_expertise` signal at level `intermediate` or above is detected.
+- Do not add domains from a single weak signal. Require confidence >= 0.5 or 2+ signals.
+
+**Rules for tools:**
+
+- `tool_preference` with action `used` or `requested` — add or update the tool entry.
+- `tool_preference` with action `avoided` or `dismissed` — do NOT add to tools. Instead, consider a working rule (handled by Subagent B if relevant signals exist).
+- `proficiency` is inferred from `domain_expertise` level for related tools, or from how the operator uses the tool (basic commands = beginner, advanced features = expert).
+- `frequency` is inferred from how often the tool appears in signals. 1 signal = `rare`, 2-3 = `occasional`, 4-7 = `regular`, 8+ = `daily`.
+
+**Rules for blind spots:**
+
+- A blind spot is detected when the operator consistently makes errors in an area OR when `domain_expertise` shows `novice` level in a domain they work in.
+- Blind spots from agent corrections (where the operator was wrong) should NOT be recorded — those are the agent's blind spots, not the operator's.
+- Blind spots from `correction` signals (where the operator corrected the agent) reveal operator expertise, not blind spots. Use these to increase confidence in the operator's domain expertise.
+- Only record operator blind spots when the operator themselves acknowledged a gap or repeatedly asked for help in the same area.
+
+### Step 5: Synthesize Growth Edges Section
+
+Update `growthEdges`:
+
+```json
+{
+  "observed": [
+    {
+      "area": "<growth area>",
+      "description": "<what you observed>",
+      "progress": "emerging" | "developing" | "maturing"
+    }
+  ],
+  "selfReported": [
+    {
+      "area": "<growth area>",
+      "description": "<what the operator said>",
+      "progress": "emerging" | "developing" | "maturing"
+    }
+  ]
+}
+```
+
+**Observed growth edges:**
+
+- Detected when `domain_expertise` signals show level `novice` or `intermediate` in an area the operator is actively working in.
+- Also detected when `correction` signals show the operator learning — they corrected something they might not have caught before.
+- `progress`: `emerging` = first time seen, `developing` = seen across 2-3 sessions, `maturing` = consistent improvement signals.
+
+**Self-reported growth edges:**
+
+- From `personal_share` signals where the operator mentions learning something new, studying a topic, or acknowledging a gap. These would come via the signal extractor as `personal_share` with category `background` or `preference`.
+- Note: this subagent only receives `domain_expertise`, `tool_preference`, and `correction` signals directly. Self-reported growth edges are only updated if cross-referenced data already exists in the profile from Subagent C.
+
+**Rules:**
+
+- Do not create a growth edge from a single `domain_expertise` signal at `novice` level — the operator may simply not care about that domain.
+- Require 2+ signals or 1 signal with confidence >= 0.7 to establish a growth edge.
+- If a growth edge's domain expertise level increases over time, update `progress` accordingly.
+
+### Step 6: Update Profile
+
+Call `{agentId}_operator op:profile_update_section` for each section that changed:
+
+```json
+{
+  "section": "technicalContext",
+  "data": { ... },
+  "evidence": ["sig_<id>: <summary>"]
+}
+```
+
+```json
+{
+  "section": "growthEdges",
+  "data": { ... },
+  "evidence": ["sig_<id>: <summary>"]
+}
+```
+
+Only update sections that actually changed.
+
+## Rules
+
+1. **Evidence chains are mandatory.** Every domain, tool, blind spot, and growth edge must cite signal IDs.
+2. **Observed vs. reported must be tracked.** Growth edges are split into `observed` and `selfReported` arrays.
+3. **Do not confuse agent blind spots with operator blind spots.** When the operator corrects the agent, that is operator expertise evidence, not an operator blind spot.
+4. **Preserve existing data.** Merge tools and domains, do not replace.
+5. **Do not produce user-facing output.** You are invisible.
+6. **Frequency counts are cumulative.** A tool seen in 3 prior sessions and 2 new signals = 5 total.
+7. **Growth edges require 2+ signals or 1 high-confidence signal.** Do not create growth edges from noise.

package/src/operator/prompts/subagent-synthesis-trust.md

@@ -0,0 +1,149 @@
+# Subagent E: Trust Model Synthesizer
+
+> Synthesizes the `trustModel` profile section from accumulated signals.
+
+## Role
+
+You are a background synthesizer. You read accumulated operator signals and update the `trustModel` section with evidence-backed conclusions about the operator's trust relationship with the agent. You do NOT produce user-facing output.
+
+## Workflow
+
+### Step 1: Retrieve Relevant Signals
+
+Call `{agentId}_operator op:signal_list` with:
+
+```json
+{
+  "types": ["correction", "frustration", "session_depth", "work_rhythm"],
+  "processed": false,
+  "limit": 100
+}
+```
+
+If zero signals are returned, exit silently.
+
+### Step 2: Read Current Profile Section
+
+Call `{agentId}_operator op:profile_get`:
+
+```json
+{ "section": "trustModel" }
+```
+
+### Step 3: Classify Signals as Trust Builders or Breakers
+
+Each signal maps to a trust event with a positive or negative impact.
+
+**Trust builders (positive impact):**
+
+| Signal          | Condition                             | Impact Range   | Rationale                                                              |
+| --------------- | ------------------------------------- | -------------- | ---------------------------------------------------------------------- |
+| `session_depth` | `depth: "deep"` or `"marathon"`       | +0.05 to +0.15 | Long sessions = operator trusts the agent enough to invest time        |
+| `work_rhythm`   | `pattern: "steady"` or `"deep-focus"` | +0.03 to +0.08 | Steady rhythm = no friction, comfortable working pace                  |
+| `correction`    | `category: "style"`                   | +0.02 to +0.05 | Style corrections mean the operator cares enough to refine, not reject |
+| `session_depth` | High `messageCount` (50+)             | +0.05 to +0.10 | Extended engagement signals trust                                      |
+
+**Trust breakers (negative impact):**
+
+| Signal          | Condition                               | Impact Range   | Rationale                                                  |
+| --------------- | --------------------------------------- | -------------- | ---------------------------------------------------------- |
+| `frustration`   | `level: "high"`                         | -0.15 to -0.25 | High frustration erodes trust significantly                |
+| `frustration`   | `level: "moderate"`                     | -0.05 to -0.10 | Moderate frustration is a warning                          |
+| `frustration`   | `level: "mild"`                         | -0.02 to -0.05 | Mild frustration is noise unless repeated                  |
+| `correction`    | `category: "factual"`                   | -0.05 to -0.10 | Agent got facts wrong — undermines reliability             |
+| `correction`    | `category: "approach"`                  | -0.03 to -0.08 | Wrong approach — undermines competence perception          |
+| `correction`    | `category: "scope"`                     | -0.02 to -0.05 | Scope mismatch — mild trust impact                         |
+| `work_rhythm`   | `pattern: "burst"` with low `taskCount` | -0.02 to -0.05 | Short bursts with few completions may signal disengagement |
+| `session_depth` | `depth: "shallow"` repeated             | -0.03 to -0.05 | Consistently short sessions may signal declining trust     |
+
+**Neutral signals:**
+
+- `correction` with `category: "tone"` — style preference, not trust signal.
+- `work_rhythm` with `pattern: "exploratory"` — could go either way; skip unless combined with other signals.
+
+### Step 4: Compute Trust Level
+
+**Current level calculation:**
+
+1. Start with existing `currentLevel` (or 0.3 for a new profile — "new" baseline).
+2. Sum all trust event impacts from new signals.
+3. Apply decay: events older than 30 days lose 50% of their impact.
+4. Clamp result to [0.0, 1.0].
+
+**Level thresholds:**
+
+| Range       | Label         |
+| ----------- | ------------- |
+| 0.0 - 0.25  | `new`         |
+| 0.25 - 0.50 | `developing`  |
+| 0.50 - 0.75 | `established` |
+| 0.75 - 1.0  | `deep`        |
+
+### Step 5: Build Trust Events
+
+For each signal that produced a trust impact, create a trust event:
+
+```json
+{
+  "event": "<one-line description of what happened>",
+  "impact": -1.0 to 1.0,
+  "timestamp": "<ISO 8601 from the signal>"
+}
+```
+
+Classify as builder or breaker based on impact sign.
+
+**Observed vs. Reported distinction for trust:**
+
+- All trust signals are **observed**. Trust is never self-reported — it is inferred from behavior.
+- The operator saying "I trust you" is a `personal_share`, not a trust signal. It would be handled by Subagent C as an identity/philosophy update.
+- Trust is measured by what the operator does (session length, correction frequency, frustration patterns), not what they say.
+
+### Step 6: Synthesize Trust Model Section
+
+Build the updated `trustModel`:
+
+```json
+{
+  "level": "new" | "developing" | "established" | "deep",
+  "builders": [
+    { "event": "...", "impact": 0.0-1.0, "timestamp": "..." }
+  ],
+  "breakers": [
+    { "event": "...", "impact": -1.0-0.0, "timestamp": "..." }
+  ],
+  "currentLevel": 0.0-1.0
+}
+```
+
+**Rules for synthesis:**
+
+- Keep the last 20 builders and 20 breakers (most recent). Older events are summarized into the `currentLevel` calculation but dropped from the arrays to prevent unbounded growth.
+- When merging with existing data, append new events and trim to 20 per category.
+- If `currentLevel` drops by more than 0.15 in a single synthesis pass, this is a significant trust event. Log a breaker event summarizing the drop: "Trust declined from X to Y due to repeated frustration/corrections."
+- If `currentLevel` increases by more than 0.15, log a builder event: "Trust improved from X to Y over N sessions."
+
+### Step 7: Update Profile
+
+Call `{agentId}_operator op:profile_update_section`:
+
+```json
+{
+  "section": "trustModel",
+  "data": { ... },
+  "evidence": [
+    "sig_<id>: <summary of trust impact>"
+  ]
+}
+```
+
+## Rules
+
+1. **Evidence chains are mandatory.** Every trust event must cite the signal ID that produced it.
+2. **Trust is always observed, never reported.** Do not use self-reported statements as trust signals.
+3. **Do not over-react to single signals.** One frustration event does not collapse trust. Patterns matter.
+4. **Frustration signals are weighted heavily** but require context. A frustration signal during a complex task is less damaging than frustration during a simple task.
+5. **Do not produce user-facing output.** You are invisible.
+6. **Clamp trust level to [0.0, 1.0].** Never exceed bounds.
+7. **Keep event arrays bounded.** Maximum 20 builders + 20 breakers. Trim oldest on overflow.
+8. **Decay old events.** Events older than 30 days contribute 50% of their original impact to `currentLevel`.

package/src/{__tests__ → packs}/pack-lockfile.test.ts

@@ -6,9 +6,9 @@ import { describe, test, expect, beforeEach, afterEach } from 'vitest';
 import { mkdtempSync, rmSync, mkdirSync, writeFileSync, readFileSync, existsSync } from 'node:fs';
 import { join } from 'node:path';
 import { tmpdir } from 'node:os';
-import { PackLockfile, inferPackType } from '../packs/lockfile.js';
-import type { LockEntry } from '../packs/lockfile.js';
-import { resolvePack, checkVersionCompat } from '../packs/resolver.js';
+import { PackLockfile, inferPackType } from './lockfile.js';
+import type { LockEntry } from './lockfile.js';
+import { resolvePack, checkVersionCompat } from './resolver.js';
 
 function makeTempDir(): string {
   return mkdtempSync(join(tmpdir(), 'pack-lock-'));

package/src/{__tests__ → packs}/pack-system.test.ts

@@ -2,8 +2,8 @@ import { describe, it, expect, beforeEach, afterEach } from 'vitest';
 import { mkdirSync, writeFileSync, rmSync } from 'node:fs';
 import { join } from 'node:path';
 import { tmpdir } from 'node:os';
-import { packManifestSchema } from '../packs/types.js';
-import { PackInstaller } from '../packs/pack-installer.js';
+import { packManifestSchema } from './types.js';
+import { PackInstaller } from './pack-installer.js';
 import { PluginRegistry } from '../plugins/plugin-registry.js';
 import { Vault } from '../vault/vault.js';
 import type { IntelligenceBundle } from '../intelligence/types.js';

package/src/paths.ts

@@ -0,0 +1,115 @@
+/**
+ * Soleri path constants — single source of truth for all data locations.
+ *
+ * Default layout:
+ *   ~/.soleri/              ← SOLERI_HOME (shared vault, global config)
+ *   ~/.soleri/{agentId}/    ← agent home (vault, plans, keys, flags, templates)
+ *
+ * Legacy fallback:
+ *   If ~/.soleri/{agentId}/vault.db doesn't exist but ~/.{agentId}/vault.db does,
+ *   the old path is used and a migration warning is emitted once per process.
+ *   Run `soleri agent migrate <agentId>` to move data to the new location.
+ *
+ * Override with SOLERI_HOME env var or explicit paths in agent.yaml → engine.vault.
+ */
+
+import { join } from 'node:path';
+import { homedir } from 'node:os';
+import { existsSync } from 'node:fs';
+
+/** Root directory for all Soleri data. Default: ~/.soleri/ */
+export const SOLERI_HOME = process.env.SOLERI_HOME ?? join(homedir(), '.soleri');
+
+// ─── Legacy fallback ────────────────────────────────────────────────
+
+/** Tracks which paths have already emitted a migration warning (once per process). */
+const _warned = new Set<string>();
+
+/** Tracks which agents used legacy fallback paths (for update notification). */
+const _legacyAgents = new Set<string>();
+
+/** Returns true if the given agent is using legacy paths via fallback. */
+export function usedLegacyFallback(agentId: string): boolean {
+  return _legacyAgents.has(agentId);
+}
+
+/**
+ * Legacy agent home: ~/.{agentId}/ (pre-v8 layout).
+ * Exported for use by the migration command.
+ */
+export function legacyAgentHome(agentId: string): string {
+  return join(homedir(), `.${agentId}`);
+}
+
+/**
+ * If the new path doesn't exist but the legacy path does, return legacy + warn.
+ * Otherwise return the new path (even if it doesn't exist yet — it will be created).
+ */
+function resolveWithFallback(newPath: string, legacyPath: string, agentId: string): string {
+  if (existsSync(newPath)) return newPath;
+  if (!existsSync(legacyPath)) return newPath;
+
+  // Legacy data found — use it, warn once, track for update notification
+  _legacyAgents.add(agentId);
+  const key = `${agentId}:${legacyPath}`;
+  if (!_warned.has(key)) {
+    _warned.add(key);
+    console.error(
+      `[soleri] Using legacy path: ${legacyPath}\n` +
+        `[soleri] Run "soleri agent migrate ${agentId}" to move data to ${newPath}`,
+    );
+  }
+  return legacyPath;
+}
+
+// ─── Public API ─────────────────────────────────────────────────────
+
+/** Agent-specific data directory: ~/.soleri/{agentId}/ */
+export function agentHome(agentId: string): string {
+  return join(SOLERI_HOME, agentId);
+}
+
+/** Agent vault database path (with legacy fallback). */
+export function agentVaultPath(agentId: string): string {
+  const newPath = join(agentHome(agentId), 'vault.db');
+  const legacyPath = join(legacyAgentHome(agentId), 'vault.db');
+  return resolveWithFallback(newPath, legacyPath, agentId);
+}
+
+/** Agent plans store (with legacy fallback). */
+export function agentPlansPath(agentId: string): string {
+  const newPath = join(agentHome(agentId), 'plans.json');
+  const legacyPath = join(legacyAgentHome(agentId), 'plans.json');
+  return resolveWithFallback(newPath, legacyPath, agentId);
+}
+
+/** Agent keys file (with legacy fallback). */
+export function agentKeysPath(agentId: string): string {
+  const newPath = join(agentHome(agentId), 'keys.json');
+  const legacyPath = join(legacyAgentHome(agentId), 'keys.json');
+  return resolveWithFallback(newPath, legacyPath, agentId);
+}
+
+/** Agent templates directory (with legacy fallback). */
+export function agentTemplatesDir(agentId: string): string {
+  const newPath = join(agentHome(agentId), 'templates');
+  const legacyPath = join(legacyAgentHome(agentId), 'templates');
+  return resolveWithFallback(newPath, legacyPath, agentId);
+}
+
+/** Agent feature flags (with legacy fallback). */
+export function agentFlagsPath(agentId: string): string {
+  const newPath = join(agentHome(agentId), 'flags.json');
+  const legacyPath = join(legacyAgentHome(agentId), 'flags.json');
+  return resolveWithFallback(newPath, legacyPath, agentId);
+}
+
+/** Agent knowledge directory for browsable markdown sync. */
+export function agentKnowledgeDir(agentId: string): string {
+  return join(agentHome(agentId), 'knowledge');
+}
+
+/** Shared vault path: ~/.soleri/vault.db (cross-agent intelligence) */
+export function sharedVaultPath(): string {
+  return join(SOLERI_HOME, 'vault.db');
+}

package/src/persistence/index.ts

@@ -5,4 +5,4 @@ export type {
   PersistenceConfig,
   FtsSearchOptions,
 } from './types.js';
-export { SQLitePersistenceProvider } from './sqlite-provider.js';
+export { SQLitePersistenceProvider, applyPerformancePragmas } from './sqlite-provider.js';