@botbotgo/agent-harness 0.0.297 → 0.0.299

package/dist/client/acp.d.ts

@@ -1,14 +1,16 @@
 import { type AcpHttpClientOptions, type AcpStdioClient, type AcpStdioClientOptions } from "../acp.js";
-import type { Approval, OperatorOverview, RequestEvent, RequestTraceItem } from "../api.js";
+import type { Approval, OperatorOverview, RequestEvent, RequestPlanState, RequestTraceItem } from "../api.js";
 import type { CancelOptions, RequestSummary, RuntimeHealthSnapshot, SessionListSummary, SessionRecord, SessionSummary } from "../contracts/types.js";
-import type { HarnessClient, HarnessClientApprovalFilter, HarnessClientRequestFilter, HarnessClientRequestOptions, HarnessClientRequestResult, HarnessClientRequestStartOptions, HarnessClientStreamItem } from "./types.js";
+import type { HarnessClient, HarnessClientApprovalFilter, HarnessClientRequestFilter, HarnessClientRequestOptions, HarnessClientRequestResult } from "./types.js";
 export type AcpHarnessTransport = Pick<AcpStdioClient, "request" | "subscribe" | "close">;
 export declare class AcpHarnessClient implements HarnessClient {
     private readonly transport;
     private streamSequence;
     constructor(transport: AcpHarnessTransport);
     request(options: HarnessClientRequestOptions): Promise<HarnessClientRequestResult>;
-    streamRequest(options: HarnessClientRequestStartOptions): AsyncGenerator<HarnessClientStreamItem>;
+    private hasStreamingListeners;
+    private streamRequestInternal;
+    private requestWithStreamingListeners;
     resolveApproval(options: Parameters<HarnessClient["resolveApproval"]>[0]): Promise<HarnessClientRequestResult>;
     cancelRequest(options: CancelOptions): Promise<HarnessClientRequestResult>;
     subscribe(listener: (event: RequestEvent) => void | Promise<void>): () => void;
@@ -25,6 +27,10 @@ export declare class AcpHarnessClient implements HarnessClient {
     getRequest(requestId: string): Promise<RequestSummary | null>;
     listApprovals(filter?: HarnessClientApprovalFilter): Promise<Approval[]>;
     getApproval(approvalId: string): Promise<Approval | null>;
+    getRequestPlanState(input: {
+        sessionId: string;
+        requestId: string;
+    }): Promise<RequestPlanState | null>;
     listRequestEvents(input: {
         sessionId: string;
         requestId: string;

package/dist/client/acp.js

@@ -1,4 +1,5 @@
 import { createAcpHttpClient, createAcpStdioClient, } from "../acp.js";
+import { applyRequestStreamItemToSnapshot, createInitialRequestEventSnapshot, toRequestDataEvent, } from "../request-events.js";
 function toEvent(notification) {
     return notification.params.event;
 }
@@ -15,9 +16,17 @@ export class AcpHarnessClient {
         this.transport = transport;
     }
     request(options) {
+        if (this.hasStreamingListeners(options)) {
+            return this.requestWithStreamingListeners(options);
+        }
         return this.transport.request("requests.submit", options);
     }
-    async *streamRequest(options) {
+    hasStreamingListeners(options) {
+        return Boolean(("eventListener" in options && options.eventListener)
+            || ("dataListener" in options && options.dataListener)
+            || options.listeners);
+    }
+    async *streamRequestInternal(options) {
         const streamId = `harness-stream-${++this.streamSequence}`;
         const queued = [];
         let notify;
@@ -61,6 +70,9 @@ export class AcpHarnessClient {
         const resultPromise = this.transport.request("requests.submit", {
             ...options,
             streamId,
+            listeners: undefined,
+            eventListener: undefined,
+            dataListener: undefined,
         });
         resultPromise
             .then((result) => {
@@ -104,6 +116,45 @@ export class AcpHarnessClient {
             unsubscribe();
         }
     }
+    async requestWithStreamingListeners(options) {
+        const legacyListeners = options.listeners;
+        const eventListener = "eventListener" in options ? options.eventListener : undefined;
+        const dataListener = "dataListener" in options ? options.dataListener : undefined;
+        let snapshot = createInitialRequestEventSnapshot();
+        let finalResult;
+        for await (const item of this.streamRequestInternal(options)) {
+            snapshot = applyRequestStreamItemToSnapshot(snapshot, item);
+            if (item.type === "event") {
+                await legacyListeners?.onEvent?.(item.event);
+            }
+            else if (item.type === "upstream-event") {
+                await legacyListeners?.onUpstreamEvent?.(item.event);
+                if (item.surfaceItem) {
+                    await legacyListeners?.onTraceItem?.({
+                        sessionId: item.sessionId,
+                        requestId: item.requestId,
+                        surfaceItem: item.surfaceItem,
+                        event: item.event,
+                    });
+                }
+            }
+            else if (item.type === "plan-state") {
+                await legacyListeners?.onPlanState?.(item.planState);
+            }
+            else if (item.type === "result") {
+                finalResult = item.result;
+            }
+            const dataEvent = toRequestDataEvent(item);
+            if (dataEvent) {
+                await dataListener?.(dataEvent);
+            }
+            await eventListener?.(snapshot);
+        }
+        if (!finalResult) {
+            throw new Error("ACP streaming request completed without a terminal result.");
+        }
+        return finalResult;
+    }
     resolveApproval(options) {
         return this.transport.request("approvals.resolve", options);
     }
@@ -138,6 +189,9 @@ export class AcpHarnessClient {
     getApproval(approvalId) {
         return this.transport.request("approvals.get", { approvalId });
     }
+    getRequestPlanState(input) {
+        return this.transport.request("requests.plan.get", input);
+    }
     listRequestEvents(input) {
         return this.transport.request("events.list", input);
     }

package/dist/client/in-process.d.ts

@@ -1,11 +1,10 @@
 import { cancelRequest, listSessionSummaries, listSessions, resolveApproval, subscribe, type CreateAgentHarnessOptions } from "../api.js";
 import type { AgentHarnessRuntime } from "../runtime/harness.js";
-import type { HarnessClient, HarnessClientApprovalFilter, HarnessClientRequestFilter, HarnessClientRequestOptions, HarnessClientRequestResult, HarnessClientRequestStartOptions, HarnessClientStreamItem } from "./types.js";
+import type { HarnessClient, HarnessClientApprovalFilter, HarnessClientRequestFilter, HarnessClientRequestOptions, HarnessClientRequestResult } from "./types.js";
 export declare class InProcessHarnessClient implements HarnessClient {
     readonly runtime: AgentHarnessRuntime;
     constructor(runtime: AgentHarnessRuntime);
     request(options: HarnessClientRequestOptions): Promise<HarnessClientRequestResult>;
-    streamRequest(options: HarnessClientRequestStartOptions): AsyncGenerator<HarnessClientStreamItem>;
     resolveApproval(options: Parameters<typeof resolveApproval>[1]): Promise<HarnessClientRequestResult>;
     cancelRequest(options: Parameters<typeof cancelRequest>[1]): Promise<HarnessClientRequestResult>;
     subscribe(listener: Parameters<typeof subscribe>[1]): () => void;
@@ -26,6 +25,10 @@ export declare class InProcessHarnessClient implements HarnessClient {
     getRequest(requestId: string): Promise<import("../contracts/runtime.js").RequestRecord | null>;
     listApprovals(filter?: HarnessClientApprovalFilter): Promise<import("../api.js").Approval[]>;
     getApproval(approvalId: string): Promise<import("../api.js").Approval | null>;
+    getRequestPlanState(input: {
+        sessionId: string;
+        requestId: string;
+    }): Promise<import("../api.js").RequestPlanState | null>;
     listRequestEvents(input: {
         sessionId: string;
         requestId: string;

package/dist/client/in-process.js

@@ -1,4 +1,4 @@
-import { cancelRequest, createAgentHarness, getApproval, getHealth, getOperatorOverview, getRequest, getSession, listApprovals, listRequestEvents, listRequests, listRequestTraceItems, listSessionSummaries, listSessions, request, resolveApproval, subscribe, stop, } from "../api.js";
+import { cancelRequest, createAgentHarness, getApproval, getHealth, getOperatorOverview, getRequestPlanState, getRequest, getSession, listApprovals, listRequestEvents, listRequests, listRequestTraceItems, listSessionSummaries, listSessions, request, resolveApproval, subscribe, stop, } from "../api.js";
 export class InProcessHarnessClient {
     runtime;
     constructor(runtime) {
@@ -7,11 +7,6 @@ export class InProcessHarnessClient {
     request(options) {
         return request(this.runtime, options);
     }
-    async *streamRequest(options) {
-        for await (const item of this.runtime.streamEvents(options)) {
-            yield item;
-        }
-    }
     resolveApproval(options) {
         return resolveApproval(this.runtime, options);
     }
@@ -42,6 +37,9 @@ export class InProcessHarnessClient {
     getApproval(approvalId) {
         return getApproval(this.runtime, approvalId);
     }
+    getRequestPlanState(input) {
+        return getRequestPlanState(this.runtime, input);
+    }
     listRequestEvents(input) {
         return listRequestEvents(this.runtime, input);
     }

package/dist/client/index.d.ts

@@ -1,4 +1,4 @@
 export { AcpHarnessClient, createAcpHarnessClient, createAcpHttpHarnessClient, createAcpStdioHarnessClient } from "./acp.js";
 export { InProcessHarnessClient, createAgentHarnessClient, createInProcessHarnessClient } from "./in-process.js";
-export type { HarnessClient, HarnessClientApprovalFilter, HarnessClientRequestFilter, HarnessClientRequestOptions, HarnessClientRequestResult, HarnessClientRequestStartOptions, HarnessClientStreamItem, } from "./types.js";
+export type { HarnessClient, HarnessClientApprovalFilter, HarnessClientRequestFilter, HarnessClientRequestOptions, HarnessClientRequestResult, HarnessClientRequestStartOptions, } from "./types.js";
 export type { AcpHarnessTransport } from "./acp.js";

package/dist/client/types.d.ts

@@ -1,16 +1,14 @@
-import type { Approval, OperatorOverview, PublicRequestListeners, PublicRequestOptions, PublicRequestResult, RequestEvent, RequestTraceItem } from "../api.js";
-import type { CancelOptions, HarnessStreamItem, InvocationEnvelope, MessageContent, RequestSummary, ResumeOptions, RuntimeHealthSnapshot, SessionListSummary, SessionRecord, SessionSummary } from "../contracts/types.js";
+import type { Approval, OperatorOverview, PublicRequestOptions, PublicRequestResult, RequestEvent, RequestTraceItem } from "../api.js";
+import type { CancelOptions, InvocationEnvelope, MessageContent, RequestPlanState, RequestSummary, ResumeOptions, RuntimeHealthSnapshot, SessionListSummary, SessionRecord, SessionSummary } from "../contracts/types.js";
 export type HarnessClientRequestStartOptions = {
     agentId?: string;
     input: MessageContent;
     sessionId?: string;
     priority?: number;
     invocation?: InvocationEnvelope;
-    listeners?: PublicRequestListeners;
 };
 export type HarnessClientRequestOptions = PublicRequestOptions;
 export type HarnessClientRequestResult = PublicRequestResult;
-export type HarnessClientStreamItem = HarnessStreamItem;
 export type HarnessClientRequestFilter = {
     agentId?: string;
     sessionId?: string;
@@ -23,7 +21,6 @@ export type HarnessClientApprovalFilter = {
 };
 export interface HarnessClient {
     request(options: HarnessClientRequestOptions): Promise<HarnessClientRequestResult>;
-    streamRequest(options: HarnessClientRequestStartOptions): AsyncGenerator<HarnessClientStreamItem>;
     resolveApproval(options: ResumeOptions): Promise<HarnessClientRequestResult>;
     cancelRequest(options: CancelOptions): Promise<HarnessClientRequestResult>;
     subscribe(listener: (event: RequestEvent) => void | Promise<void>): () => void;
@@ -40,6 +37,10 @@ export interface HarnessClient {
     getRequest(requestId: string): Promise<RequestSummary | null>;
     listApprovals(filter?: HarnessClientApprovalFilter): Promise<Approval[]>;
     getApproval(approvalId: string): Promise<Approval | null>;
+    getRequestPlanState(input: {
+        sessionId: string;
+        requestId: string;
+    }): Promise<RequestPlanState | null>;
     listRequestEvents(input: {
         sessionId: string;
         requestId: string;

package/dist/config/agents/direct.yaml

@@ -12,6 +12,8 @@ spec:
   runtime:
     # agent-harness feature: workspace-level durable long-term memory defaults for this host profile.
     runtimeMemory: default
+    # agent-harness feature: optional background-only procedural memory defaults for this host profile.
+    proceduralMemory: default
   # =====================
   # Runtime Agent Features
   # =====================
@@ -31,14 +33,9 @@ spec:
   subagents: []
   # Upstream execution feature: direct host does not attach MCP servers by default.
   mcpServers: []
-  # Runtime execution feature: checkpointer config passed into the selected backend adapter.
-  # Even the lightweight direct path can benefit from resumable state during interactive use.
-  # Available `kind` options in this harness: `SqliteSaver`, `FileCheckpointer`, `MemorySaver`.
-  # The repository default uses the sqlite-backed preset so durable checkpoint state stays inside `runtime/checkpoints.sqlite`.
-  checkpointer: default
-  # Upstream execution feature: LangGraph store available to middleware and runtime context hooks.
-  # The default direct host keeps this enabled so middleware can use the same durable store surface as other hosts.
-  store: default
+  # Upstream execution feature: leave graph checkpointers and stores unset in the repository default.
+  # `direct` is the low-latency path; add `checkpointer:` or `store:` only when the host really needs resumable
+  # graph state or middleware-owned store access.
   # Upstream execution feature: no declarative HITL tool routing by default.
   interruptOn: {}
   # Upstream execution feature: filesystem middleware settings for LangChain v1 agents.
@@ -74,12 +71,5 @@ spec:
   # Keep this prompt biased toward concise, self-contained answers. If richer routing policy is
   # needed for choosing between host agents, configure that separately via `Runtime.spec.routing`
   # rather than overloading the direct host prompt with classifier behavior.
-  systemPrompt: |-
-    You are the direct agent.
-
-    This is a manual low-latency host.
-    Answer simple requests directly.
-    Keep the path lightweight.
-    Do not delegate.
-    Do not perform broad multi-step execution.
-    Do not behave like the default execution host.
+  systemPrompt:
+    path: ../prompts/direct-system.md

package/dist/config/agents/orchestra.yaml

@@ -12,6 +12,8 @@ spec:
   runtime:
     # agent-harness feature: workspace-level durable long-term memory defaults for this host profile.
     runtimeMemory: default
+    # agent-harness feature: optional background-only procedural memory defaults for this host profile.
+    proceduralMemory: default
   # =====================
   # Runtime Agent Features
   # =====================
@@ -19,41 +21,19 @@ spec:
   backend: deepagent
   # Upstream execution feature: model ref for the underlying LLM used by this execution host.
   modelRef: model/default
-  memory:
-    # Upstream execution feature: bootstrap memory sources supplied to the selected backend at construction time.
-    # These paths resolve relative to the workspace root unless they are already absolute.
-    # Treat this as agent-owned startup context, not as a dynamic long-term memory sink:
-    # - keep `systemPrompt` for stable role, boundaries, and hard behavioral rules
-    # - use `memory:` for stable project knowledge, operating conventions, and shared or agent-specific context files
-    # - use `/memories/*` via the backend/store below for durable knowledge learned from prior requests
-    # - use the harness checkpointer for resumable graph state for an in-flight request
-    # Updating these files changes future agent constructions, but they are still bootstrap inputs rather than
-    # self-updating runtime memory.
-    - path: config/agent-context.md
+  memory: []
   # Upstream execution feature: top-level host starts with no extra direct tool refs beyond discovered workspace tools.
   tools: []
   # Upstream execution feature: the starter runtime ships one host plus a small set of behavior skills so the
   # first request already feels like real work instead of an empty shell.
-  skills:
-    - resource://skills/workspace-inspection
-    - resource://skills/safe-editing
-    - resource://skills/delegation-discipline
-    - resource://skills/approval-execution-policy
-    - resource://skills/completion-discipline
+  skills: []
   # Upstream execution feature: subagent topology is empty in the repository default and can be filled in YAML.
   subagents: []
   # Upstream execution feature: host-level MCP servers are opt-in and empty by default.
   mcpServers: []
-  # Runtime execution feature: checkpointer config passed into the selected backend adapter.
-  # This persists resumable graph state for this agent.
-  # Available `kind` options in this harness: `SqliteSaver`, `FileCheckpointer`, `MemorySaver`.
-  # The repository default uses the sqlite-backed preset so durable checkpoint state stays inside `runtime/checkpoints.sqlite`.
-  checkpointer: default
-  # Upstream execution feature: store config passed into the selected backend adapter.
-  # In the default deepagent adapter this is the LangGraph store used by `StoreBackend` routes.
-  # Built-in kinds in this harness today: `FileStore`, `InMemoryStore`.
-  # Other store kinds should flow through a custom runtime resolver instead of being claimed as built in.
-  store: default
+  # Upstream execution feature: leave graph checkpointers and stores unset in the repository default.
+  # The starter runtime should stay responsive for local chat and inspection work. Add `checkpointer:` and `store:`
+  # back only when this host truly needs resumable graph state or middleware-owned store access.
   # Upstream execution feature: backend config passed into the selected backend adapter.
   # Prefer a reusable backend preset via `ref` so backend topology stays declarative and reusable in YAML.
   # The default preset keeps DeepAgent execution semantics upstream-owned:
@@ -82,41 +62,5 @@ spec:
   # Upstream execution feature: system prompt for the orchestration host.
   # This becomes the top-level instruction block for the selected execution backend and should hold the
   # agent's durable role, priorities, and behavioral guardrails rather than bulky project facts.
-  systemPrompt: |-
-    You are the orchestra agent.
-
-    You are the default execution host for a user-facing runtime.
-    The first request should feel like a capable working session, not a thin demo.
-    Try to finish the request yourself before delegating.
-    Use your own tools first when they are sufficient.
-    Use your own skills first when they are sufficient.
-    Delegate only when a subagent is a clearly better fit or when your own tools and skills are not enough.
-    If neither you nor any suitable subagent can do the work, say so plainly.
-
-    Prefer visible progress over abstract planning. When the request is about this workspace, inspect the workspace
-    before answering. When the request would be improved by a concrete edit or command, do the smallest safe action
-    that moves the work forward instead of only describing what you might do.
-
-    Do not delegate by reflex.
-    Do not delegate just because a task has multiple steps.
-    Do not delegate when a direct answer or a short local tool pass is enough.
-    Keep the critical path local when immediate progress depends on it; otherwise delegate bounded sidecar work to
-    the most appropriate subagent.
-
-    Use your own tools for lightweight discovery, inventory, and context gathering.
-    Prefer the structured checkout, indexing, retrieval, and inventory tools that are already attached to you over
-    ad hoc shell work when those tools are sufficient.
-    Keep answers crisp, concrete, and usable. Close the loop: explain what you inspected, what you changed, what you
-    verified, and what still needs approval or follow-up.
-    Use the attached subagent descriptions as the source of truth for what each subagent is for.
-    Do not delegate to a subagent whose description does not clearly match the task.
-    Integrate subagent results into one coherent answer and do not claim checks or evidence you did not obtain.
-
-    When the user asks about available tools, skills, or agents, use the attached inventory tools instead of
-    inferring from memory.
-
-    Write to `/memories/*` only when the information is durable, reusable across future requests or sessions, and likely
-    to matter again: user preferences, project conventions, confirmed decisions, reusable summaries, and stable
-    ownership facts are good candidates.
-    Do not store transient reasoning, temporary plans, scratch work, one-off search results, or intermediate
-    outputs that can be cheaply recomputed.
+  systemPrompt:
+    path: ../prompts/orchestra-system.md

package/dist/config/catalogs/embedding-models.yaml

@@ -13,7 +13,7 @@ spec:
     # LangChain aligned feature: concrete embedding model identifier passed to the provider integration.
     model: nomic-embed-text
     # LangChain aligned feature: provider-specific initialization options for embeddings.
-    baseUrl: http://127.0.0.1:11434
+    baseUrl: ${env:AGENT_HARNESS_OLLAMA_BASE_URL:-http://127.0.0.1:11434}
 
     # ===================
     # DeepAgents Features

package/dist/config/catalogs/stores.yaml

@@ -8,7 +8,7 @@ spec:
     name: default
     description: Default sqlite-backed store preset for runtime-managed agent state and durable memory.
     storeKind: SqliteStore
-    path: knowledge/records.sqlite
+    path: knowledge/knowledge.sqlite
 
   # agent-harness feature: reusable checkpointer preset for resumable execution state.
   - kind: Checkpointer

package/dist/config/knowledge/knowledge-runtime.yaml

@@ -41,12 +41,46 @@ spec:
       enabled: true
     manager:
       enabled: true
-      strategy: rules
+      strategy: model
+      prompt: |-
+        You are the runtime memory manager.
+        Decide whether a candidate should be stored as durable memory and refine it if appropriate.
+        Return JSON only.
+
+        Rules:
+        - Store only durable reusable knowledge. Reject transient chatter, scratchpad, or duplication without added value.
+        - Reject raw request/session summaries, source-specific page/news recaps, and generic "we learned how to use the tools/workflow" reflections unless they clearly contain reusable preferences, facts, decisions, or procedures.
+        - If transcript evidence shows the user explicitly asked the system to remember or follow a future instruction and the assistant confirmed that intent, store the durable instruction instead of rejecting it as a generic summary.
+        - Treat durable knowledge as generic mutable records with database-like operations over the same underlying knowledge item.
+        - One candidate may yield zero, one, or multiple durable knowledge items. Split it only when the input clearly contains multiple independently mutable knowledge points.
+        - When storing a knowledge item, always return a `knowledgeMutation` object with a stable `identity` and an `operation` of `create`, `update`, or `delete`.
+        - Keep `knowledgeMutation.identity` stable across revisions of the same knowledge point, even when the wording changes.
+        - Use `create` for a newly introduced knowledge item, `update` for a revised active state of an existing knowledge item, and `delete` when the candidate says an existing knowledge item should no longer remain active.
+        - If an existing relevant record already represents the same underlying knowledge item, reuse that record's `knowledge_identity` instead of inventing a new one.
+        - Do not invent a second identity just because the new statement negates, revokes, deletes, or replaces the old wording. That is usually the same knowledge item with a different mutation operation.
+        - The stored `content` must be canonical knowledge text, not an assistant acknowledgement such as "已记住" or "I will remember".
+        - You may optionally include `operationalRule` when the knowledge is naturally a rule, instruction, or recurring procedure. Treat it as structured metadata, not as the primary identity mechanism.
+        - Prefer semantic/episodic/procedural kinds only.
+        - Prefer scopes session/agent/workspace/user/project only.
+        - If the candidate should not be stored, return {"store": false, "reason": "..."}
+        - If the candidate maps to one durable item, you may return {"store": true, "content": "...", "summary": "...", "kind": "...", "scope": "...", "tags": ["..."], "confidence": 0.0, "knowledgeMutation": {"identity": "...", "operation": "create|update|delete"}, "operationalRule": {"trigger": "...", "action": "...", "target": "...", "effect": "apply|invalidate"}}
+        - If the candidate maps to multiple durable items, return {"store": true, "mutations": [{"content": "...", "summary": "...", "kind": "...", "scope": "...", "tags": ["..."], "confidence": 0.0, "knowledgeMutation": {"identity": "...", "operation": "create|update|delete"}, "operationalRule": {"trigger": "...", "action": "...", "target": "...", "effect": "apply|invalidate"}}]}
+
+        sessionId={{sessionId}}
+        requestId={{requestId}}
+
+        Candidate:
+        {{candidateJson}}
+
+        Existing relevant records:
+        {{existingRecords}}
       maxContextRecords: 12
     background:
       enabled: true
       scopes:
-        - session
+        - user
+        - project
+        - workspace
       stateStorePath: knowledge/formation-state.json
       maxMessagesPerRequest: 40
       writeOnApprovalResolution: true

package/dist/config/knowledge/procedural-memory-runtime.yaml

@@ -0,0 +1,78 @@
+# agent-harness feature: schema version for this declarative config object.
+apiVersion: agent-harness/v1alpha1
+# agent-harness feature: standalone procedural-memory runtime defaults.
+# Keep experience memory separate from durable knowledge, but under the same data root.
+kind: ProceduralMemoryRuntime
+metadata:
+  # agent-harness feature: stable singleton name for the default procedural-memory runtime object.
+  name: default
+spec:
+  # agent-harness feature: enable or disable background procedural-memory learning.
+  enabled: true
+  provider:
+    # agent-harness feature: provider identifier for a procedural-memory backend.
+    kind: reme
+  mode:
+    # agent-harness feature: keep procedural learning off the request hot path.
+    backgroundOnly: true
+  trigger:
+    # agent-harness feature: nearline formation hooks for newly completed work.
+    onRequestCompleted: true
+    onApprovalResolved: true
+  store:
+    # agent-harness feature: provider-owned procedural-memory metadata and state store.
+    kind: SqliteStore
+    path: knowledge/procedural-memory.sqlite
+  vectorStore:
+    # agent-harness feature: separate procedural vector substrate under the shared knowledge directory.
+    kind: LibSQLVectorStore
+    url: file:knowledge/procedural-vectors.sqlite
+    table: procedural_memory
+    column: embedding
+  embeddingModel:
+    # agent-harness feature: default embedding model used with the procedural vector store.
+    ref: embedding-model/default
+  extraction:
+    # agent-harness feature: background procedural formation focus.
+    focus:
+      - coding_patterns
+      - debugging_lessons
+      - workflow_patterns
+      - failure_prevention
+      - reusable_procedures
+    maxMessagesPerRequest: 60
+  retrieval:
+    # agent-harness feature: bounded procedural recall defaults.
+    enabled: true
+    defaultTopK: 5
+    maxPromptItems: 4
+  state:
+    # agent-harness feature: incremental background cursor for procedural formation.
+    cursorPath: knowledge/procedural-memory-state.json
+  maintenance:
+    # agent-harness feature: keep procedural memory consolidated outside the request path.
+    enabled: true
+    onWrite:
+      dedupeNearby: true
+      updateFrequency: true
+    schedule:
+      enabled: true
+      everyMinutes: 60
+    idle:
+      enabled: true
+      minIdleMinutes: 20
+      maxRunsPerIdleWindow: 1
+    tasks:
+      - dedupe
+      - merge_similar
+      - decay_stale
+      - prune_low_value
+    limits:
+      maxRecordsPerRun: 200
+      maxClustersPerRun: 50
+    decay:
+      enabled: true
+      maxAgeDays: 90
+    pruning:
+      minScore: 0.2
+      minFrequency: 2

package/dist/config/{catalogs/models.yaml → models.yaml}

@@ -18,12 +18,12 @@ spec:
     provider: ollama
   # LangChain aligned feature: concrete model identifier passed to the selected provider integration.
   # Example values depend on `provider`, such as `gpt-oss:latest` for `ollama`.
-    model: gpt-oss:latest
+    model: gemma4:e2b
   # LangChain aligned feature: provider-specific initialization options.
   # Write these fields directly on the model object.
   # Common examples include `baseUrl`, `temperature`, and auth/client settings.
   # `baseUrl` configures the Ollama-compatible endpoint used by the model client.
   # For `openai-compatible`, `baseUrl` is normalized into the ChatOpenAI `configuration.baseURL` field.
-    baseUrl: http://127.0.0.1:11434
+    baseUrl: ${env:AGENT_HARNESS_OLLAMA_BASE_URL:-http://127.0.0.1:11434}
   # LangChain aligned feature: provider/model initialization option controlling sampling temperature.
     temperature: 0.2

package/dist/config/prompts/direct-system.md

@@ -0,0 +1,16 @@
+You are the direct agent.
+
+This is a manual low-latency host.
+Answer simple requests directly.
+Keep the path lightweight.
+Do not delegate.
+Do not perform broad multi-step execution.
+Do not behave like the default execution host.
+
+For simple local utility questions, use the attached local tools immediately instead of guessing.
+Examples:
+- if the user asks for the current time or date, run a local command and return the real result
+- if the user asks for a simple local inventory question that one short tool call can answer, run that tool first
+- if the user asks for a recurring or scheduled system task such as "run ls every 5 minutes", call `schedule_task` instead of claiming you cannot do background work
+
+Do not fabricate live local facts such as the current time.

package/dist/config/prompts/orchestra-system.md

@@ -0,0 +1,62 @@
+You are the orchestra agent.
+
+You are the default execution host for a user-facing runtime.
+The first request should feel like a capable working session, not a thin demo.
+Try to finish the request yourself before delegating.
+Use your own tools first when they are sufficient.
+Use your own skills first when they are sufficient.
+Delegate only when a subagent is a clearly better fit or when your own tools and skills are not enough.
+If neither you nor any suitable subagent can do the work, say so plainly.
+
+Prefer visible progress over abstract planning. When the request is about this workspace, inspect the workspace
+before answering. When the request would be improved by a concrete edit or command, do the smallest safe action
+that moves the work forward instead of only describing what you might do.
+
+For simple local utility questions, execute the relevant tool immediately instead of answering abstractly.
+Examples:
+- if the user asks for the current time or date, run a local command and return the result
+- if the user asks to list files, inspect the workspace and return the file listing
+- if the user asks what is in this workspace, inspect it first and answer from tool evidence
+Do not say you lack access when the attached local tools can answer the question directly.
+For recurring or scheduled system tasks such as "run ls every 5 minutes", call `schedule_task` and let the runtime install a system-level schedule instead of saying you cannot do background work.
+
+For current external information such as today's news, only claim live information when you actually used a
+web-capable tool in this runtime. If no web/news tool is attached, say plainly that this workspace runtime does
+not currently have a web source for live news instead of redirecting the user back to generic workspace help.
+
+When the task is clearly multi-step and requires real execution, do not ask the user to restate it. Start from
+the supplied task immediately. For non-trivial multi-step work, call `write_todos` before other tool calls so the
+runtime can show a live todo board. Keep that todo list updated throughout execution instead of only at the end:
+mark completed steps as `completed`, keep the active step as `in_progress`, mark failures as `failed`, and attach
+short `result` summaries when they help the user follow progress. Use descriptive todo content that names the
+real step; never use placeholders like `1`, `2`, `3`, `step 1`, or `todo 1`.
+
+For workspace file operations, always use workspace-relative paths such as `tmp-counter.txt` or `docs/index.html`.
+Do not use absolute host paths like `/tmp/...` or `/Users/...`. Use `write_file` only for the initial creation of
+a file. After a file exists, switch to `read_file` plus `edit_file` for updates instead of repeating `write_file`.
+When the user asks for repeated execution steps such as write/read/wait/append loops, keep iterating until the
+requested sequence is complete or a real tool error blocks further progress.
+
+Do not delegate by reflex.
+Do not delegate just because a task has multiple steps.
+Do not delegate when a direct answer or a short local tool pass is enough.
+Keep the critical path local when immediate progress depends on it; otherwise delegate bounded sidecar work to
+the most appropriate subagent.
+
+Use your own tools for lightweight discovery, inventory, and context gathering.
+Prefer the structured checkout, indexing, retrieval, and inventory tools that are already attached to you over
+ad hoc shell work when those tools are sufficient.
+Keep answers crisp, concrete, and usable. Close the loop: explain what you inspected, what you changed, what you
+verified, and what still needs approval or follow-up.
+Use the attached subagent descriptions as the source of truth for what each subagent is for.
+Do not delegate to a subagent whose description does not clearly match the task.
+Integrate subagent results into one coherent answer and do not claim checks or evidence you did not obtain.
+
+When the user asks about available tools, skills, or agents, use the attached inventory tools instead of
+inferring from memory.
+
+Write to `/memories/*` only when the information is durable, reusable across future requests or sessions, and likely
+to matter again: user preferences, project conventions, confirmed decisions, reusable summaries, and stable
+ownership facts are good candidates.
+Do not store transient reasoning, temporary plans, scratch work, one-off search results, or intermediate
+outputs that can be cheaply recomputed.

package/dist/config/prompts/routing-system.md

@@ -0,0 +1,14 @@
+You are a routing classifier for an agent harness. Reply with exactly one agent id:
+{{primaryAgentId}} or {{secondaryAgentId}}.
+
+Choose {{primaryAgentId}} only for lightweight conversational turns that can be answered directly in one step
+without tool use, repository inspection, file lookup, external checkout, or orchestration.
+
+Choose {{secondaryAgentId}} for requests that need tools, multi-step execution, external research, repository or
+file analysis, downloading or cloning content, codebase exploration, verification, or any task where the agent
+should inspect the workspace or another repository before answering.
+
+If the request asks to download, clone, fetch, inspect, analyze, trace, or locate implementation in a repo or
+codebase, choose {{secondaryAgentId}}.
+
+When uncertain, prefer {{secondaryAgentId}}.