@soleri/core 9.2.0 → 9.3.1

package/src/operator/prompts/hook-precompact-operator-dispatch.md

@@ -11,11 +11,13 @@ You are a dispatcher hook that runs during PreCompact. You decide which operator
 ### Step 1: Check Synthesis Status
 
 Call `{agentId}_operator op:synthesis_check` with:
+
 ```json
 {}
 ```
 
 This returns:
+
 ```json
 {
   "due": true | false,
@@ -40,6 +42,7 @@ This returns:
 Subagent A runs on every PreCompact regardless of synthesis status. It extracts new signals from the conversation that just happened.
 
 Spawn as **background** (non-blocking):
+
 - Prompt: contents of `subagent-soft-signal-extractor.md`
 - Context: the current conversation context available to this hook
 
@@ -49,12 +52,12 @@ Only spawn synthesis subagents if `synthesis_check` returned `due: true`.
 
 Map `sectionsToUpdate` to subagents:
 
-| Sections | Subagent | Prompt File |
-|----------|----------|-------------|
-| `communication: true` OR `workingRules: true` | Subagent B | `subagent-synthesis-communication.md` |
-| `cognition: true` OR `identity: true` OR `tasteProfile: true` | Subagent C | `subagent-synthesis-cognition.md` |
-| `technicalContext: true` OR `growthEdges: true` | Subagent D | `subagent-synthesis-technical.md` |
-| `trustModel: true` | Subagent E | `subagent-synthesis-trust.md` |
+| Sections                                                      | Subagent   | Prompt File                           |
+| ------------------------------------------------------------- | ---------- | ------------------------------------- |
+| `communication: true` OR `workingRules: true`                 | Subagent B | `subagent-synthesis-communication.md` |
+| `cognition: true` OR `identity: true` OR `tasteProfile: true` | Subagent C | `subagent-synthesis-cognition.md`     |
+| `technicalContext: true` OR `growthEdges: true`               | Subagent D | `subagent-synthesis-technical.md`     |
+| `trustModel: true`                                            | Subagent E | `subagent-synthesis-trust.md`         |
 
 Spawn each applicable subagent as **background** (non-blocking).
 
@@ -81,6 +84,7 @@ Pending signals: {count}.
 ## Subagent Isolation
 
 Each subagent operates independently:
+
 - They read their own signal types via `op:signal_list`.
 - They read their own profile sections via `op:profile_get`.
 - They write their own sections via `op:profile_update_section`.

package/src/operator/prompts/subagent-soft-signal-extractor.md

@@ -21,6 +21,7 @@ You extract exactly three signal types:
 The operator revealed something about themselves — background, preferences, philosophy, or anecdotes.
 
 **Data shape:**
+
 ```json
 {
   "signalType": "personal_share",
@@ -42,6 +43,7 @@ The operator revealed something about themselves — background, preferences, ph
 The operator showed a preference for how they want to interact with the agent.
 
 **Data shape:**
+
 ```json
 {
   "signalType": "communication_pref",
@@ -61,6 +63,7 @@ The operator showed a preference for how they want to interact with the agent.
 The operator reacted to something the agent produced — positively, negatively, or with mixed feelings.
 
 **Data shape:**
+
 ```json
 {
   "signalType": "reaction_to_output",
@@ -83,6 +86,7 @@ The operator reacted to something the agent produced — positively, negatively,
 Only emit signals with confidence >= 0.4. If you are less than 40% sure, skip it.
 
 **Calibration guide:**
+
 - 0.4-0.5: Weak inference from indirect evidence. One data point.
 - 0.5-0.7: Reasonable inference from multiple indirect signals.
 - 0.7-0.85: Clear evidence but not explicitly stated.
@@ -97,6 +101,7 @@ For each signal you detect, call:
 ```
 
 With params:
+
 ```json
 {
   "signals": [

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

@@ -11,6 +11,7 @@ You are a background synthesizer. You read accumulated operator signals and upda
 ### Step 1: Retrieve Relevant Signals
 
 Call `{agentId}_operator op:signal_list` with:
+
 ```json
 {
   "types": ["personal_share", "reaction_to_output"],
@@ -24,12 +25,15 @@ If zero signals are returned, exit silently.
 ### Step 2: Read Current Profile Sections
 
 Call `{agentId}_operator op:profile_get` three times:
+
 ```json
 { "section": "cognition" }
 ```
+
 ```json
 { "section": "identity" }
 ```
+
 ```json
 { "section": "tasteProfile" }
 ```
@@ -38,18 +42,19 @@ Call `{agentId}_operator op:profile_get` three times:
 
 **Signal-to-section mapping:**
 
-| Signal Type | Updates Section | What It Informs |
-|-------------|----------------|-----------------|
-| `personal_share` (category: `background`) | `identity` | `background`, `role` |
-| `personal_share` (category: `philosophy`) | `identity` | `philosophy` |
-| `personal_share` (category: `preference`) | `tasteProfile` | New taste entries |
-| `personal_share` (category: `anecdote`) | `identity` or `cognition` | Context-dependent |
-| `reaction_to_output` (aspect: `style`) | `tasteProfile` | Style preferences |
-| `reaction_to_output` (aspect: `approach`) | `cognition` | Cognitive patterns |
-| `reaction_to_output` (aspect: `accuracy`) | `cognition` | Derivations about reasoning |
-| `reaction_to_output` (aspect: `completeness`) | `cognition` | Depth preference patterns |
+| Signal Type                                   | Updates Section           | What It Informs             |
+| --------------------------------------------- | ------------------------- | --------------------------- |
+| `personal_share` (category: `background`)     | `identity`                | `background`, `role`        |
+| `personal_share` (category: `philosophy`)     | `identity`                | `philosophy`                |
+| `personal_share` (category: `preference`)     | `tasteProfile`            | New taste entries           |
+| `personal_share` (category: `anecdote`)       | `identity` or `cognition` | Context-dependent           |
+| `reaction_to_output` (aspect: `style`)        | `tasteProfile`            | Style preferences           |
+| `reaction_to_output` (aspect: `approach`)     | `cognition`               | Cognitive patterns          |
+| `reaction_to_output` (aspect: `accuracy`)     | `cognition`               | Derivations about reasoning |
+| `reaction_to_output` (aspect: `completeness`) | `cognition`               | Depth preference patterns   |
 
 **Observed vs. Reported — applies here too:**
+
 - `personal_share` with `explicit: true` = **reported**. Direct statement from the operator.
 - `personal_share` with `explicit: false` = **observed**. Inferred by the signal extractor.
 - `reaction_to_output` is always **observed**. The operator reacted; they did not describe their cognitive style.
@@ -70,6 +75,7 @@ Update `identity`:
 ```
 
 **Rules:**
+
 - Only update `background` and `role` from `personal_share` signals with `explicit: true` or confidence >= 0.7.
 - `philosophy` can be inferred from repeated `personal_share` (philosophy category) or consistent `reaction_to_output` patterns showing values (e.g., always reacting negatively to over-engineering suggests "simplicity" as a value).
 - Never overwrite a reported identity field with an observed inference. Reported wins.
@@ -101,6 +107,7 @@ Update `cognition`:
 ```
 
 **Cognitive patterns to look for:**
+
 - `visual-first-thinker` — reacts positively to diagrams, tables, visual structure.
 - `depth-over-breadth` — prefers deep dives over surveys.
 - `breadth-first-explorer` — prefers seeing all options before choosing.
@@ -110,6 +117,7 @@ Update `cognition`:
 - Custom patterns as appropriate.
 
 **Rules:**
+
 - A new pattern requires at least 2 supporting signals.
 - Pattern `strength` starts at 0.3 and increases with each reinforcing signal (cap at 0.95).
 - Derivations require at least 2 source patterns. A derivation from a single pattern is just a restatement.
@@ -135,6 +143,7 @@ Update `tasteProfile`:
 ```
 
 **Rules:**
+
 - Taste entries from `reaction_to_output` (aspect: `style`) are observed.
 - Taste entries from `personal_share` (category: `preference`) may be reported (if `explicit: true`) or observed.
 - Every taste entry must have a `workImplication` — what should the agent do differently because of this taste?

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

@@ -11,6 +11,7 @@ You are a background synthesizer. You read accumulated operator signals, compare
 ### Step 1: Retrieve Relevant Signals
 
 Call `{agentId}_operator op:signal_list` with:
+
 ```json
 {
   "types": ["command_style", "communication_pref", "frustration"],
@@ -24,9 +25,11 @@ If zero signals are returned, exit silently. Nothing to synthesize.
 ### Step 2: Read Current Profile Sections
 
 Call `{agentId}_operator op:profile_get` twice:
+
 ```json
 { "section": "communication" }
 ```
+
 ```json
 { "section": "workingRules" }
 ```
@@ -38,6 +41,7 @@ If no profile exists yet, you are building from scratch. Use empty defaults.
 For each signal, classify it:
 
 **Observed vs. Reported:**
+
 - **Observed**: You inferred the preference from behavior. The operator used terse one-word messages (observed: prefers concise). The operator got frustrated when the agent was verbose (observed: dislikes verbosity).
 - **Reported**: The operator explicitly stated the preference. "Keep it short." "I prefer bullet points." "Don't explain things I already know."
 
@@ -45,13 +49,13 @@ This distinction matters. Reported preferences override observed ones. Observed
 
 **Signal-to-section mapping:**
 
-| Signal Type | Updates Section | What It Informs |
-|-------------|----------------|-----------------|
-| `command_style` | `communication` | `style`, `formality`, `signalWords` |
-| `command_style` | `workingRules` | Rules about how to interpret terse vs verbose requests |
-| `communication_pref` | `communication` | `style`, `patience`, `adaptationRules` |
-| `frustration` | `communication` | `patience`, `adaptationRules` |
-| `frustration` | `workingRules` | Rules about what to avoid |
+| Signal Type          | Updates Section | What It Informs                                        |
+| -------------------- | --------------- | ------------------------------------------------------ |
+| `command_style`      | `communication` | `style`, `formality`, `signalWords`                    |
+| `command_style`      | `workingRules`  | Rules about how to interpret terse vs verbose requests |
+| `communication_pref` | `communication` | `style`, `patience`, `adaptationRules`                 |
+| `frustration`        | `communication` | `patience`, `adaptationRules`                          |
+| `frustration`        | `workingRules`  | Rules about what to avoid                              |
 
 ### Step 4: Synthesize Communication Section
 
@@ -74,6 +78,7 @@ Build the updated `communication` section:
 ```
 
 **Rules for synthesis:**
+
 - Do not overwrite existing data without stronger evidence. If the current profile says `style: "concise"` with 5 reinforcing signals, a single contradictory signal should not flip it.
 - Merge `signalWords` — add new ones, do not remove existing ones unless a correction signal contradicts them.
 - `formality` and `patience` are rolling averages. Weight recent signals more heavily (2x weight for signals from the last 3 sessions vs. older ones).
@@ -98,6 +103,7 @@ Build the updated `workingRules` section:
 ```
 
 **Rules for synthesis:**
+
 - A new rule requires at least 2 observed signals OR 1 reported signal.
 - If an existing rule is reinforced by new signals, increment `reinforcements` and update `lastSeen`.
 - If signals contradict an existing rule, do NOT remove it. Instead, add a new rule reflecting the updated preference and let the higher `reinforcements` count determine which is dominant.

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

@@ -11,6 +11,7 @@ You are a background synthesizer. You read accumulated operator signals and upda
 ### Step 1: Retrieve Relevant Signals
 
 Call `{agentId}_operator op:signal_list` with:
+
 ```json
 {
   "types": ["domain_expertise", "tool_preference", "correction"],
@@ -24,9 +25,11 @@ 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" }
 ```
@@ -35,17 +38,18 @@ Call `{agentId}_operator op:profile_get` twice:
 
 **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 |
+| 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.
@@ -75,16 +79,19 @@ Update `technicalContext`:
 ```
 
 **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.
@@ -114,15 +121,18 @@ Update `growthEdges`:
 ```
 
 **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.

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

@@ -11,6 +11,7 @@ You are a background synthesizer. You read accumulated operator signals and upda
 ### Step 1: Retrieve Relevant Signals
 
 Call `{agentId}_operator op:signal_list` with:
+
 ```json
 {
   "types": ["correction", "frustration", "session_depth", "work_rhythm"],
@@ -24,6 +25,7 @@ If zero signals are returned, exit silently.
 ### Step 2: Read Current Profile Section
 
 Call `{agentId}_operator op:profile_get`:
+
 ```json
 { "section": "trustModel" }
 ```
@@ -34,33 +36,35 @@ 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 |
+| 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 |
+| 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.
@@ -68,12 +72,12 @@ Each signal maps to a trust event with a positive or negative impact.
 
 **Level thresholds:**
 
-| Range | Label |
-|-------|-------|
-| 0.0 - 0.25 | `new` |
-| 0.25 - 0.50 | `developing` |
+| Range       | Label         |
+| ----------- | ------------- |
+| 0.0 - 0.25  | `new`         |
+| 0.25 - 0.50 | `developing`  |
 | 0.50 - 0.75 | `established` |
-| 0.75 - 1.0 | `deep` |
+| 0.75 - 1.0  | `deep`        |
 
 ### Step 5: Build Trust Events
 
@@ -90,6 +94,7 @@ For each signal that produced a trust impact, create a trust event:
 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.
@@ -112,6 +117,7 @@ Build the updated `trustModel`:
 ```
 
 **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."

package/src/persona/defaults.test.ts

@@ -1,9 +1,5 @@
 import { describe, it, expect } from 'vitest';
-import {
-  ITALIAN_CRAFTSPERSON,
-  PERSONA_TEMPLATES,
-  createDefaultPersona,
-} from './defaults.js';
+import { ITALIAN_CRAFTSPERSON, PERSONA_TEMPLATES, createDefaultPersona } from './defaults.js';
 
 describe('ITALIAN_CRAFTSPERSON', () => {
   it('uses italian-craftsperson template id', () => {