@fastagent-sh/fastagent 0.19.0 → 0.20.0

package/dist/engines/pi/session-builder.js

@@ -36,10 +36,9 @@ import { resolveModel } from "./config.js";
 import { assembleSystemPrompt, piBasePrompt } from "./create.js";
 import { canonicalPath, loadAgentDefinition, loadExtensionPaths } from "./definition.js";
 import { createPiModelRuntime, probeAuthSource } from "./models.js";
-import { log } from "../../log.js";
-import { additiveActivation, agentSessionManager, turnContext, } from "./tool-context.js";
+import { log, reportModuleLoadFailures } from "../../log.js";
+import { agentSessionManager, sessionToolActivation, turnContext, } from "./tool-context.js";
 import { reportFindingsIfChanged, reportToolCollisions } from "./report.js";
-import { reportModuleLoadFailures } from "../../log.js";
 import { resolveAgentAssembly } from "./open.js";
 /**
  * Build pi's interactive runtime driven by fastagent's assembled agent (model, prompt, tools,
@@ -49,34 +48,6 @@ import { resolveAgentAssembly } from "./open.js";
 export async function buildAgentSessionRuntime(dir, options = {}, 
 /** Session backend. Defaults to pi's project-scoped store; tests inject SessionManager.inMemory(). */
 sessionManager) {
-    /** The turn's {@link ToolActivation} over pi's AgentSession — the counterpart of invoke.ts's
-     *  serving bridge, so the SAME builtin search_tools serves both paths. Additive; unknown names
-     *  filtered (`setActiveToolsByName` is authoritative on the session and rebuilds its prompt — our
-     *  static override keeps the prompt identical to serving). */
-    function sessionToolActivation(session) {
-        // Same serialization as invoke.ts's bridge (there per turn; here per session — interactive turns
-        // make per-session equivalent): the read-modify-write below is only race-free while nothing awaits
-        // between read and write, and pi's session setters happening to be synchronous today is not a
-        // contract worth betting parallel tool batches on. Built ONCE per session (createRuntime), so
-        // parallel calls actually share the chain.
-        let chain = Promise.resolve([]);
-        return {
-            active: () => session.getActiveToolNames(),
-            registered: () => session.getAllTools().map((t) => ({ name: t.name, description: t.description ?? "" })),
-            activate(names) {
-                const run = async () => {
-                    const current = session.getActiveToolNames();
-                    const added = additiveActivation(session.getAllTools().map((t) => t.name), current, names);
-                    if (added.length > 0)
-                        session.setActiveToolsByName([...current, ...added]);
-                    return added;
-                };
-                const result = chain.then(run, run); // run after the predecessor settles, success or failure
-                chain = result.catch(() => []); // the caller sees a rejection on `result`; the chain stays usable
-                return result;
-            },
-        };
-    }
     async function resolveAssembly(cwd) {
         // The shared front half — the SAME placement/config/model-spec/tool/auth resolution the serving
         // opener uses (open.ts); those inputs cannot drift between the two consumption shapes.
@@ -154,11 +125,13 @@ sessionManager) {
     // would leak env or require mutating global env at runtime.
     const rootCwd = canonicalPath(dir);
     // The CURRENT pi session + its activation bridge, BOUND TOGETHER — rebuilt on /new//resume/fork
-    // while the memoized assembly (and its tool execute closures) stays. The bridge must share the
-    // session's lifetime, NOT be rebuilt per tool call (a per-call chain serializes nothing). Note on
+    // while the memoized assembly (and its tool execute closures) stays. The bridge shares the
+    // session's lifetime because a tool call has to see what the previous one activated. Note on
     // parallel batches: pi wraps SDK customTools in its own before/after active-set diff, so an
     // activating tool must carry `executionMode: "sequential"` (the builtin loader does) — pi then runs
     // the whole batch serially and the outer diff sees correct snapshots.
+    // NO activation record here: pi's chat session has nowhere to put one (see sessionToolActivation's
+    // `onActivated`), which is the documented divergence from serving — a resumed chat re-discovers.
     const sessionRef = {};
     let assembly;
     const assemblyFor = (cwd) => {

package/dist/engines/pi/session-control.d.ts

@@ -1,8 +1,21 @@
-import type { ThinkingLevel } from "@earendil-works/pi-agent-core";
-import type { Models } from "@earendil-works/pi-ai";
+/**
+ * The pi implementation of the session control plane. `createPiSessionControl` returns the neutral
+ * `SessionControl` plus the {@link SessionObserver} to plug into the invoke pipeline
+ * (`createPiAgent({ observer })`).
+ *
+ * It holds no durable state of its own: live truth comes from the event stream (plus the
+ * {@link RunControls} a `run_started` carries), durable truth from {@link PiSessionRecordStore} —
+ * which is also what performs every write, so how a record takes a property is not knowledge this
+ * file has. What it owns is the vocabulary: capability gating, the lease, error codes, and the
+ * events its own writes emit.
+ *
+ * Writes take the same lease as runs. Without boundary wiring they reject before acceptance with
+ * `unsupported_capability` — a client gating on `capabilities()` never sends them.
+ */
+import { type ThinkingLevel } from "@earendil-works/pi-agent-core";
+import { type Models } from "@earendil-works/pi-ai";
 import { type AgentCommand, type SessionControl, type SessionEvent } from "../../session.ts";
-import type { SessionObserver } from "./turn-kit.ts";
-import type { Lease } from "./turn-kit.ts";
+import type { SessionObserver, Lease } from "./turn-kit.ts";
 import type { AnyModel } from "./models.ts";
 import type { PiAgentSessionFactory } from "./invoke-session.ts";
 import type { PiSessionRecordStore } from "./session-store.ts";
@@ -15,8 +28,8 @@ import type { PiSessionRecordStore } from "./session-store.ts";
  *  permanently stalled one holds the frozen buffer until its TCP connection dies. Recovery either
  *  way is the standard reconnect+backfill, semantically lossless. */
 export declare const SUBSCRIBER_BUFFER_CAP = 10000;
-/** What boundary mutations (compact / set_model / set_thinking / navigate) need — the SAME instances the
- *  agent assembly uses: the lease (mutations must not race a run), the model registry (validation +
+/** What the plane's writes (`update` / `compact` / `fork` / `delete`) need — the SAME instances the
+ *  agent assembly uses: the lease (a write must not race a run), the model registry (validation +
  *  allowedModels), and the session factory (compaction is a model call). Writes go through the
  *  record the hub's reader opened — after an existence check, so the control plane never creates
  *  a session (that is the data plane's monopoly). */