@reticlehq/server 3.6.0 → 3.7.0

package/dist/language/flows/buddy-status.js

@@ -1,32 +0,0 @@
-/**
- * The buddy channel. The co-dev experience for the HUMAN: a single ambient line they can park in
- * a statusline or terminal and glance at — never a wall of output, never something they have to ask for.
- *
- * The rule this encodes: say the reassuring thing briefly and the alarming thing specifically. "41 flows
- * nominal" needs no detail; a deviation needs its name, because a status line that says only "1 deviation"
- * forces the human to go digging, which is exactly the work the buddy exists to remove.
- */
-/** How many deviation names to spell out before collapsing to a count (a status line must stay one line). */
-const MAX_NAMED = 2;
-/**
- * One line, safe to print on every save. Shape:
- * `✓ 41 flows nominal`
- * `✗ 2 deviations: checkout, billing · 39 nominal · 1 flaky quarantined`
- */
-export function formatBuddyStatus(input) {
-    const parts = [];
-    const deviations = input.deviations.length;
-    if (0 === deviations) {
-        parts.push(`✓ ${String(input.passing)}/${String(input.total)} flows nominal`);
-    }
-    else {
-        const named = input.deviations.slice(0, MAX_NAMED).join(', ');
-        const rest = deviations - Math.min(MAX_NAMED, deviations);
-        parts.push(`✗ ${String(deviations)} deviation${1 === deviations ? '' : 's'}: ${named}${rest > 0 ? ` +${String(rest)} more` : ''}`);
-        parts.push(`${String(input.passing)} nominal`);
-    }
-    if (input.quarantined.length > 0) {
-        parts.push(`${String(input.quarantined.length)} flaky quarantined`);
-    }
-    return parts.join(' · ');
-}

package/dist/language/flows/change/watch-batcher.d.ts

@@ -1,18 +0,0 @@
-/**
- * Debounce batcher for `reticle watch` — a save-heavy editor fires many change events per real edit
- * (temp files, multi-file formats-on-save). This coalesces a burst of changed paths into one flush after
- * a quiet window, so we compute affected flows once per edit, not per keystroke. The scheduler (setTimeout)
- * is injected, keeping the batching logic pure and unit-testable.
- */
-interface WatchBatcher {
-    onChange(file: string): void;
-}
-interface WatchBatcherOptions {
-    debounceMs: number;
-    /** Injected scheduler (setTimeout) — deterministic in tests. */
-    schedule: (fn: () => void, ms: number) => void;
-    /** Called once per quiet window with the unique changed paths since the last flush. */
-    onFlush: (files: string[]) => void;
-}
-export declare function createWatchBatcher(options: WatchBatcherOptions): WatchBatcher;
-export {};

package/dist/language/flows/change/watch-batcher.js

@@ -1,19 +0,0 @@
-export function createWatchBatcher(options) {
-    let pending = new Set();
-    let scheduled = false;
-    return {
-        onChange(file) {
-            pending.add(file);
-            if (scheduled)
-                return;
-            scheduled = true;
-            options.schedule(() => {
-                scheduled = false;
-                const files = [...pending];
-                pending = new Set();
-                if (files.length > 0)
-                    options.onFlush(files);
-            }, options.debounceMs);
-        },
-    };
-}

package/dist/memory/cloud/harness-offer.d.ts

@@ -1,44 +0,0 @@
-/**
- * Whether this workspace has taken the three months of free harness, read by the thing that would
- * advertise it.
- *
- * The HUD can only advertise honestly if it knows, and only the platform knows. This is the read —
- * filed beside the other reads of the linked account rather than with the harness itself, because
- * nothing that DRIVES needs it; the thing that needs it is the snapshot the HUD paints from. Same
- * shape as the harness's own `platform-config.ts` and for the same reasons: it is INFORMATION, not a
- * credential, so every failure answers `undefined`, which every caller must treat as "say nothing"
- * rather than as "not claimed". An offline laptop must not start advertising something the person
- * already owns.
- *
- * It is also SYNCHRONOUS at the point of use. The impact snapshot is built inline, dozens of times a
- * session, and the answer changes about once per workspace lifetime, so a cache that refreshes in
- * the background is the whole design: readers get what we last heard, and a stale answer is only
- * ever stale in the safe direction — the card the person is looking at is the one they can act on.
- */
-import { type HarnessOffer } from '@reticlehq/core';
-/** A GET, narrowed to what this file uses, so a test can answer it without a network. */
-export type OfferFetch = (url: string, init: {
-    method: string;
-    headers: Record<string, string>;
-    signal?: AbortSignal;
-}) => Promise<{
-    ok: boolean;
-    status: number;
-    text(): Promise<string>;
-}>;
-/** Ask the platform where this workspace stands. `undefined` means "no answer", never "not claimed". */
-export declare function fetchHarnessOffer(env: Record<string, string | undefined>, claimUrl: string | undefined, doFetch?: OfferFetch, timeoutMs?: number): Promise<HarnessOffer | undefined>;
-/** What the impact snapshot reads: the last answer, with a refresh kicked off when it goes stale. */
-export interface OfferSource {
-    read(): HarnessOffer | undefined;
-}
-/**
- * A self-refreshing cache over the read above.
- *
- * Deliberately NOT a timer. A daemon that lives for days would otherwise hold an interval whose only
- * job is to re-ask a question nobody is asking, and it would have to be torn down in a place that
- * already has nine teardowns. Refreshing on a stale READ means the work only happens while somebody
- * is actually looking, and the first read of a process — which is always stale — starts the fetch
- * that the second read answers from.
- */
-export declare function harnessOfferSource(env: Record<string, string | undefined>, claimUrl: () => string | undefined, now?: () => number, load?: (claim: string | undefined) => Promise<HarnessOffer | undefined>): OfferSource;

package/dist/memory/cloud/harness-offer.js

@@ -1,145 +0,0 @@
-/**
- * Whether this workspace has taken the three months of free harness, read by the thing that would
- * advertise it.
- *
- * The HUD can only advertise honestly if it knows, and only the platform knows. This is the read —
- * filed beside the other reads of the linked account rather than with the harness itself, because
- * nothing that DRIVES needs it; the thing that needs it is the snapshot the HUD paints from. Same
- * shape as the harness's own `platform-config.ts` and for the same reasons: it is INFORMATION, not a
- * credential, so every failure answers `undefined`, which every caller must treat as "say nothing"
- * rather than as "not claimed". An offline laptop must not start advertising something the person
- * already owns.
- *
- * It is also SYNCHRONOUS at the point of use. The impact snapshot is built inline, dozens of times a
- * session, and the answer changes about once per workspace lifetime, so a cache that refreshes in
- * the background is the whole design: readers get what we last heard, and a stale answer is only
- * ever stale in the safe direction — the card the person is looking at is the one they can act on.
- */
-import { platformCredentialFrom } from '@reticlehq/core';
-const OFFER_PATH = '/v1/harness/offer';
-/** Same budget as the model-config read: a drive must never wait on an advert. */
-const TIMEOUT_MS = 2_000;
-/**
- * How long a cached answer is trusted.
- *
- * A claim happens once. The only transition worth catching quickly is the one the person just made
- * in another tab, and ten minutes is well inside the time it takes them to come back and look.
- */
-const FRESH_MS = 10 * 60 * 1_000;
-/**
- * Parse the platform's answer.
- *
- * The platform reports `null` for "never claimed" on the fields it has no value for; the wire
- * contract says ABSENT. They are the same fact and the translation belongs here, at the edge,
- * rather than in a HUD that would then need to know about two spellings of nothing.
- */
-function parse(body, claimUrl) {
-    try {
-        const parsed = JSON.parse(body);
-        if ('object' !== typeof parsed || null === parsed)
-            return undefined;
-        const record = parsed;
-        const claimed = record['claimed'];
-        if ('boolean' !== typeof claimed)
-            return undefined;
-        const offer = { claimed };
-        const expiresAt = record['expiresAt'];
-        if ('number' === typeof expiresAt)
-            offer.expiresAt = expiresAt;
-        const days = record['daysRemaining'];
-        if ('number' === typeof days)
-            offer.daysRemaining = days;
-        // The one field that cannot be inferred from the others: a LAPSED claim reports `claimed:false`
-        // and `daysRemaining:0`, which is indistinguishable from never having claimed unless the
-        // platform's own answer about offerability is carried through.
-        const eligible = record['eligible'];
-        if ('boolean' === typeof eligible)
-            offer.eligible = eligible;
-        if (claimUrl !== undefined && 0 < claimUrl.length)
-            offer.claimUrl = claimUrl;
-        return offer;
-    }
-    catch {
-        return undefined;
-    }
-}
-/** Ask the platform where this workspace stands. `undefined` means "no answer", never "not claimed". */
-export async function fetchHarnessOffer(env, claimUrl, doFetch = (url, init) => fetch(url, init), timeoutMs = TIMEOUT_MS) {
-    const cloud = platformCredentialFrom(env);
-    if (cloud === undefined)
-        return undefined;
-    const key = cloud.apiKey;
-    const host = cloud.url;
-    const controller = new AbortController();
-    const timer = setTimeout(() => {
-        controller.abort();
-    }, timeoutMs);
-    try {
-        const res = await doFetch(`${host.replace(/\/+$/, '')}${OFFER_PATH}`, {
-            method: 'GET',
-            headers: { authorization: `Bearer ${key}` },
-            signal: controller.signal,
-        });
-        if (!res.ok)
-            return undefined;
-        return parse(await res.text(), claimUrl);
-    }
-    catch {
-        return undefined;
-    }
-    finally {
-        clearTimeout(timer);
-    }
-}
-/**
- * A self-refreshing cache over the read above.
- *
- * Deliberately NOT a timer. A daemon that lives for days would otherwise hold an interval whose only
- * job is to re-ask a question nobody is asking, and it would have to be torn down in a place that
- * already has nine teardowns. Refreshing on a stale READ means the work only happens while somebody
- * is actually looking, and the first read of a process — which is always stale — starts the fetch
- * that the second read answers from.
- */
-export function harnessOfferSource(env, claimUrl, now = () => Date.now(), load = (claim) => fetchHarnessOffer(env, claim)) {
-    let cached;
-    // `undefined` rather than 0: "never asked" is a different state from "asked at the epoch", and
-    // conflating them made a source with an injected clock never take its first read.
-    let fetchedAt;
-    let inFlight = false;
-    const refresh = () => {
-        if (inFlight)
-            return;
-        inFlight = true;
-        void load(claimUrl())
-            .then((offer) => {
-            // A failed read keeps the LAST good answer rather than blanking the card mid-session: one
-            // dropped request is not evidence that the offer changed.
-            if (offer !== undefined)
-                cached = offer;
-            fetchedAt = now();
-        })
-            .catch(() => {
-            fetchedAt = now();
-        })
-            .finally(() => {
-            inFlight = false;
-        });
-    };
-    /*
-     * Asked once at construction, not first read.
-     *
-     * Measured in a browser: a daemon pushes the impact snapshot the INSTANT a session attaches, and
-     * on a page nobody drives that is the only push there will ever be. Refreshing on the first read
-     * meant that push always carried "we have not heard", the answer landed a moment later with
-     * nobody to tell, and the HUD showed nothing for the whole session. Starting the fetch when the
-     * daemon starts puts the answer in place before any page can connect.
-     */
-    refresh();
-    return {
-        read() {
-            if (fetchedAt === undefined || FRESH_MS <= now() - fetchedAt)
-                refresh();
-            return cached;
-        },
-    };
-}

package/dist/surface/tools/feature-capture.d.ts

@@ -1,151 +0,0 @@
-import { type Intent, type JournalAction } from '@reticlehq/core/artifacts';
-/**
- * Were `reticle_context` and `reticle_intent` used at all — and did using them change anything?
- *
- * Both shipped with the same pre-registered disproof: *if agents never call it, cut it*. Nothing
- * recorded whether they were called, so the disproof could never be run, and a feature whose
- * disproof cannot be run is one nobody can kill. This is the smallest thing that makes the question
- * answerable, per session, locally — an instrument, not a scold. The numbers exist so a FEATURE can
- * be removed, never so an agent can be blamed for how it drove.
- *
- * ## Fold first, record only what nothing records
- *
- * Three of the four questions are already answerable from what is on disk. The intent ledger says
- * what was declared; the journal says what was driven and what verdicts were drawn. Those are folded
- * here and never re-stored, for the reason `run-context.ts` gives at length: two ways to compute one
- * number is worse than one way.
- *
- * The journal does NOT record read-only calls — it holds actions and verdicts only. So "was
- * `reticle_context` called" has no ledger to fold, and that one thing is recorded, in memory, on the
- * session, by `CaptureLedger`. It is the whole of the new state.
- *
- * ## Absent is not zero
- *
- * A session this daemon has recorded nothing for — journaling off, a session adopted after the fact
- * — reports `observed: false` and states no counts at all. It has not established that the features
- * went unused; it has established that it was not watching. This repo has shipped the other bug
- * twice.
- */
-/**
- * The calls this instrument needs and the journal does not keep.
- *
- * Deliberately a short explicit list rather than "everything that is not an action". Under-inclusion
- * is the safe direction: a read tool missing from here lowers the hit side and the miss side by the
- * same call, so the comparison the disproof turns on stays fair. Over-inclusion is not — a lifecycle
- * or disk-side tool landing in here would be counted as a "read" the agent made of the app, which it
- * was not.
- */
-export declare const CAPTURED_TOOLS: ReadonlySet<string>;
-/** One recorded call: which tool, what it was about, and how far into the run it happened. */
-export interface CapturedCall {
-    tool: string;
-    /** The ref or target the call named, when it named one. Absent for a whole-page read. */
-    subject?: string;
-    /**
-     * The session's dispatched-action count at the moment of the call — the same counter that mints
-     * journal action ids, so it lines up with `reticle_context`'s own `step` whenever the journal is on.
-     */
-    afterActions: number;
-}
-/**
- * The one thing that is stored rather than folded: the read-only calls the journal never sees.
- *
- * In memory and per session, the same shape as `GapLedger`. It is not durable on purpose — the
- * question is about one run, and a second file on disk would be a second thing to reconcile with the
- * journal.
- */
-export declare class CaptureLedger {
-    #private;
-    /**
-     * One call, under the name of the tool that RAN — every tool, not just the read set above.
-     *
-     * Separate from `note` because it answers a different question and is bounded differently: this
-     * map cannot outgrow the tool table however long the session runs, so it needs no cap and never
-     * has to report a floor. See surface/tools/tool-hit-rate.ts for what it feeds.
-     */
-    noteTool(tool: string): void;
-    /** How many times each tool was called this session, in first-call order. */
-    toolCalls(): ReadonlyMap<string, number>;
-    note(call: CapturedCall): void;
-    calls(): readonly CapturedCall[];
-    /** How many calls fell off the front. Non-zero means the counts below are a floor. */
-    get dropped(): number;
-}
-/**
- * Record one captured call against the session that made it.
- *
- * Tolerates a session that carries no ledger, exactly as `noteSessionGaps` does and for the same
- * reason: `Session` is satisfied structurally, and many specs — plus any consumer embedding this
- * engine — build one as an object literal. Such a session is a real caller that simply keeps no
- * ledger, and an instrument must never be the reason a tool call throws. Its calls are then absent
- * rather than counted as zero, which is what `observed: false` exists to say.
- */
-export declare function noteCapturedCall(session: {
-    capture?: CaptureLedger;
-    actionCount?: number;
-}, call: Omit<CapturedCall, 'afterActions'>): void;
-/**
- * Count one call against the session that made it, whichever tool it was.
- *
- * Tolerant of a ledger-less session for exactly the reason `noteCapturedCall` is: its calls are then
- * absent rather than counted as zero, which is what `observed: false` exists to say.
- */
-export declare function noteToolDispatched(session: {
-    capture?: CaptureLedger;
-}, tool: string): void;
-/** What one session's use of the two features looks like. Everything but `observed` is omitted when nothing was recorded. */
-interface FeatureCapture {
-    /** False when this daemon recorded nothing for the session — "not watched", never "not used". */
-    observed: boolean;
-    /** The ledger dropped calls, so every count is a floor. Present only when true. */
-    truncated?: boolean;
-    context?: {
-        calls: number;
-        /** The dispatched-action count each call was made at, in order. */
-        atSteps: number[];
-        acted: number;
-        refetched: number;
-        readOther: number;
-        nothingAfter: number;
-    };
-    intents?: {
-        declared: number;
-        open: number;
-    };
-    missed?: {
-        verdictsWithNoIntentDeclared: number;
-        refetchedEstablished: number;
-    };
-}
-/**
- * Did calling `reticle_context` change what happened next?
- *
- * The mechanical proxy, stated so it can be argued with: look at the very next recorded call. If an
- * action was dispatched before it — the action counter moved — the agent ACTED, and the context
- * plausibly helped. If instead the next call is a read of a subject the context had just supplied,
- * the agent re-fetched what it had been handed, and the context did not help.
- *
- * ## What this proxy CANNOT see
- *
- *  - Whether the agent READ the response, reasoned over it, or wrote a better answer from it. There
- *    is no signal for that anywhere, and this must not be mistaken for one.
- *  - Anything that happens between two Reticle calls: source edits, calls to other MCP servers, a
- *    turn ending, a human interrupting. A long gap is invisible and reads as adjacency.
- *  - Reads that name no ref or target (a whole-page snapshot). They land in `readOther`, never in
- *    `refetched`, so a snapshot that duplicated the context is under-counted, not over-counted.
- *  - Causation. `acted` is proximity in a call sequence, nothing more. An agent that would have acted
- *    anyway is indistinguishable from one the context unblocked.
- *  - `reticle_context` called with no session connected — it answers there by design, and there is no
- *    per-session ledger to record it against, so those calls are missing entirely.
- *  - Two agents driving one session. Their calls interleave into one sequence and "next call" stops
- *    meaning "next thing that agent did".
- */
-export declare function foldFeatureCapture(input: {
-    calls: readonly CapturedCall[];
-    dropped: number;
-    actions: readonly JournalAction[];
-    intents: readonly Intent[];
-    /** The session's dispatched-action count now, so a run that ended on an action is not read as idle. */
-    finalActions: number;
-}): FeatureCapture;
-export {};

package/dist/surface/tools/feature-capture.js

@@ -1,235 +0,0 @@
-import { IntentState, JournalVerdictEffectSchema, RUN_ESTABLISHED_CAP, } from '@reticlehq/core/artifacts';
-import { subjectOf } from '../../judgement/runs/artifact/run-context.js';
-import { ReticleTool } from '@reticlehq/core';
-/**
- * Were `reticle_context` and `reticle_intent` used at all — and did using them change anything?
- *
- * Both shipped with the same pre-registered disproof: *if agents never call it, cut it*. Nothing
- * recorded whether they were called, so the disproof could never be run, and a feature whose
- * disproof cannot be run is one nobody can kill. This is the smallest thing that makes the question
- * answerable, per session, locally — an instrument, not a scold. The numbers exist so a FEATURE can
- * be removed, never so an agent can be blamed for how it drove.
- *
- * ## Fold first, record only what nothing records
- *
- * Three of the four questions are already answerable from what is on disk. The intent ledger says
- * what was declared; the journal says what was driven and what verdicts were drawn. Those are folded
- * here and never re-stored, for the reason `run-context.ts` gives at length: two ways to compute one
- * number is worse than one way.
- *
- * The journal does NOT record read-only calls — it holds actions and verdicts only. So "was
- * `reticle_context` called" has no ledger to fold, and that one thing is recorded, in memory, on the
- * session, by `CaptureLedger`. It is the whole of the new state.
- *
- * ## Absent is not zero
- *
- * A session this daemon has recorded nothing for — journaling off, a session adopted after the fact
- * — reports `observed: false` and states no counts at all. It has not established that the features
- * went unused; it has established that it was not watching. This repo has shipped the other bug
- * twice.
- */
-/**
- * The calls this instrument needs and the journal does not keep.
- *
- * Deliberately a short explicit list rather than "everything that is not an action". Under-inclusion
- * is the safe direction: a read tool missing from here lowers the hit side and the miss side by the
- * same call, so the comparison the disproof turns on stays fair. Over-inclusion is not — a lifecycle
- * or disk-side tool landing in here would be counted as a "read" the agent made of the app, which it
- * was not.
- */
-export const CAPTURED_TOOLS = new Set([
-    ReticleTool.CONTEXT,
-    ReticleTool.SNAPSHOT,
-    ReticleTool.QUERY,
-    ReticleTool.INSPECT,
-    ReticleTool.STATE,
-    // All four of the above, merged, on the `merged` surface. A read is a read under either name.
-    ReticleTool.LOOK,
-    ReticleTool.STORAGE,
-    ReticleTool.NETWORK,
-    ReticleTool.CONSOLE,
-    ReticleTool.OBSERVE,
-    ReticleTool.EXPLORE,
-]);
-/**
- * How many calls the ledger holds before it starts dropping the oldest.
- *
- * A verification loop is 50–200 calls, so this is not reached in normal use; it exists so a runaway
- * session cannot grow a per-session array without bound. When it IS reached the report says
- * `truncated` rather than presenting a short count as a complete one.
- */
-const CAPTURE_CAP = 2000;
-/**
- * The one thing that is stored rather than folded: the read-only calls the journal never sees.
- *
- * In memory and per session, the same shape as `GapLedger`. It is not durable on purpose — the
- * question is about one run, and a second file on disk would be a second thing to reconcile with the
- * journal.
- */
-export class CaptureLedger {
-    #calls = [];
-    #dropped = 0;
-    #tools = new Map();
-    /**
-     * One call, under the name of the tool that RAN — every tool, not just the read set above.
-     *
-     * Separate from `note` because it answers a different question and is bounded differently: this
-     * map cannot outgrow the tool table however long the session runs, so it needs no cap and never
-     * has to report a floor. See surface/tools/tool-hit-rate.ts for what it feeds.
-     */
-    noteTool(tool) {
-        this.#tools.set(tool, (this.#tools.get(tool) ?? 0) + 1);
-    }
-    /** How many times each tool was called this session, in first-call order. */
-    toolCalls() {
-        return this.#tools;
-    }
-    note(call) {
-        this.#calls.push(call);
-        if (this.#calls.length > CAPTURE_CAP) {
-            this.#calls.shift();
-            this.#dropped += 1;
-        }
-    }
-    calls() {
-        return this.#calls;
-    }
-    /** How many calls fell off the front. Non-zero means the counts below are a floor. */
-    get dropped() {
-        return this.#dropped;
-    }
-}
-/**
- * Record one captured call against the session that made it.
- *
- * Tolerates a session that carries no ledger, exactly as `noteSessionGaps` does and for the same
- * reason: `Session` is satisfied structurally, and many specs — plus any consumer embedding this
- * engine — build one as an object literal. Such a session is a real caller that simply keeps no
- * ledger, and an instrument must never be the reason a tool call throws. Its calls are then absent
- * rather than counted as zero, which is what `observed: false` exists to say.
- */
-export function noteCapturedCall(session, call) {
-    session.capture?.note({ ...call, afterActions: session.actionCount ?? 0 });
-}
-/**
- * Count one call against the session that made it, whichever tool it was.
- *
- * Tolerant of a ledger-less session for exactly the reason `noteCapturedCall` is: its calls are then
- * absent rather than counted as zero, which is what `observed: false` exists to say.
- */
-export function noteToolDispatched(session, tool) {
-    session.capture?.noteTool(tool);
-}
-/**
- * Every point in the run at which each subject became an established fact.
- *
- * "Established" is not a second definition: it is the rule `establishedFromJournal` folds by — an
- * action with an observed settle outcome, filed under the ref or target it named — and `subjectOf`
- * is imported from there rather than rewritten, so the two cannot drift apart.
- */
-function establishedIndexes(actions) {
-    const out = new Map();
-    actions.forEach((action, index) => {
-        if (undefined === action.settled)
-            return;
-        const key = subjectOf(action);
-        if (undefined === key)
-            return;
-        const at = out.get(key);
-        if (at === undefined)
-            out.set(key, [index]);
-        else
-            at.push(index);
-    });
-    return out;
-}
-/** Was this subject already an established fact by the time a call at `afterActions` was made? */
-function wasEstablished(index, subject, afterActions) {
-    if (undefined === subject)
-        return false;
-    const at = index.get(subject);
-    if (at === undefined)
-        return false;
-    // Action `i` has been dispatched once the counter reads `i + 1`, so `i + 1 <= afterActions` is
-    // "already true when the call was made" — which is what keeps a FIRST look off this count. The
-    // lower bound is the run context's own window: a fact that has scrolled past RUN_ESTABLISHED_CAP
-    // is not something `reticle_context` would have handed back, so re-reading it is not a re-fetch.
-    return at.some((i) => i + 1 <= afterActions && i + 1 > afterActions - RUN_ESTABLISHED_CAP);
-}
-/**
- * Did calling `reticle_context` change what happened next?
- *
- * The mechanical proxy, stated so it can be argued with: look at the very next recorded call. If an
- * action was dispatched before it — the action counter moved — the agent ACTED, and the context
- * plausibly helped. If instead the next call is a read of a subject the context had just supplied,
- * the agent re-fetched what it had been handed, and the context did not help.
- *
- * ## What this proxy CANNOT see
- *
- *  - Whether the agent READ the response, reasoned over it, or wrote a better answer from it. There
- *    is no signal for that anywhere, and this must not be mistaken for one.
- *  - Anything that happens between two Reticle calls: source edits, calls to other MCP servers, a
- *    turn ending, a human interrupting. A long gap is invisible and reads as adjacency.
- *  - Reads that name no ref or target (a whole-page snapshot). They land in `readOther`, never in
- *    `refetched`, so a snapshot that duplicated the context is under-counted, not over-counted.
- *  - Causation. `acted` is proximity in a call sequence, nothing more. An agent that would have acted
- *    anyway is indistinguishable from one the context unblocked.
- *  - `reticle_context` called with no session connected — it answers there by design, and there is no
- *    per-session ledger to record it against, so those calls are missing entirely.
- *  - Two agents driving one session. Their calls interleave into one sequence and "next call" stops
- *    meaning "next thing that agent did".
- */
-export function foldFeatureCapture(input) {
-    const { calls, actions, intents } = input;
-    if (0 === calls.length && 0 === actions.length)
-        return { observed: false };
-    const established = establishedIndexes(actions);
-    const isRefetch = (call) => ReticleTool.CONTEXT !== call.tool &&
-        wasEstablished(established, call.subject, call.afterActions);
-    let acted = 0;
-    let refetched = 0;
-    let readOther = 0;
-    let nothingAfter = 0;
-    const atSteps = [];
-    calls.forEach((call, i) => {
-        if (ReticleTool.CONTEXT !== call.tool)
-            return;
-        atSteps.push(call.afterActions);
-        const next = calls[i + 1];
-        if (next === undefined) {
-            if (input.finalActions > call.afterActions)
-                acted += 1;
-            else
-                nothingAfter += 1;
-            return;
-        }
-        if (next.afterActions > call.afterActions)
-            acted += 1;
-        else if (isRefetch(next))
-            refetched += 1;
-        else
-            readOther += 1;
-    });
-    // A verdict is any journal action carrying the bounded verdict effect both verification tools
-    // write. Parsed with core's own schema rather than a local shape, for the usual reason.
-    const verdicts = actions.filter((a) => JournalVerdictEffectSchema.safeParse(a.effect).success);
-    return {
-        observed: true,
-        ...(input.dropped > 0 ? { truncated: true } : {}),
-        context: { calls: atSteps.length, atSteps, acted, refetched, readOther, nothingAfter },
-        intents: {
-            declared: intents.length,
-            open: intents.filter((it) => IntentState.PROVED !== it.state).length,
-        },
-        missed: {
-            // The coarse question, asked honestly. Nothing binds a verdict to a specific intent outside
-            // flow replay, so "covered" cannot mean "this intent proves this verdict" without inventing a
-            // link Reticle cannot observe — the same reason `undeclared-change.ts` asks only whether
-            // anything at all was declared. So this counts verdicts drawn against an EMPTY ledger, and
-            // stops at zero once anything is declared. That zero is not a claim that every verdict was
-            // covered; it is the end of what this can see.
-            verdictsWithNoIntentDeclared: 0 === intents.length ? verdicts.length : 0,
-            refetchedEstablished: calls.filter(isRefetch).length,
-        },
-    };
-}