/** * A parsed JSONL entry from a pi session file. */ export interface SessionEntry { /** The raw parsed JSON object. */ data: Record; /** The original line text. */ raw: string; } /** * Cache of last-known entry count per session file path. */ export declare const entryCountCache: Map; /** * Result of parsing and analyzing a session file. * * NOTE: The `completed` flag returned here is NON-authoritative for * `LifecycleController` completion gating. It is derived from session-file * content (a user→assistant text turn pair) and historically produced * false-positive completion on the first turn of multi-turn agents. * `LifecycleController` now gates completion on the per-harness lifecycle-end * sentinel via `CodingHarness.isComplete()` (see the `completion-sentinel` * capability). This type is retained for progress tracking (entry/turn * counts), staleness detection, and result extraction only. */ export interface SessionAnalysis { /** * Whether the subagent appears to have completed based on session-file * content. NON-authoritative for `LifecycleController` completion gating — * see the doc comment above. */ completed: boolean; /** The extracted result text, if completed. */ result?: string; /** The last user timestamp detected. */ lastUserTimestamp?: number; /** The last assistant timestamp detected. */ lastAssistantTimestamp?: number; /** Number of entries parsed. */ entryCount: number; /** Number of assistant turns detected. */ turnCount: number; /** Names of tool calls made in the most recent assistant turn. */ toolCalls?: string[]; /** Response text from the most recent assistant message (truncated to 500 chars). */ responseText?: string; /** * Context usage (tokens) from the most recent assistant message's `usage` * data — feeds the widget's context-headroom health bar. Only pi session * files carry usage; cmd files don't, so their analysis leaves this unset * and the health bar degrades gracefully. */ contextTokens?: number; } /** * Parse a session JSONL file into entries. * * Skips malformed or empty lines. */ export declare function parseSessionFile(filePath: string): SessionEntry[]; /** * Analyze a session file for completion detection and result extraction. * * A subagent is considered complete when there's at least one user message * followed by an assistant message with text content (assistant timestamp * must be >= the preceding user timestamp). The monitor then enforces an * inactivity grace period externally. */ export declare function analyzeSession(entries: SessionEntry[]): SessionAnalysis; /** * Convenience function: parse and analyze a session file in one call. */ export declare function analyzeSessionFile(filePath: string): SessionAnalysis; export interface CmdSessionAnalysis { completed: boolean; result?: string; entryCount: number; turnCount: number; toolCalls?: string[]; responseText?: string; /** * ESTIMATED context tokens. commandcode persists NO usage data (real counts * live only in-process after each API turn), so this ports cmd's own * `/context` estimator (`estimateTextTokens` / `estimateTokens` in cli.mjs) * over the session-file conversation. Still OPTIMISTIC vs live `/context`: * system prompt, tool schemas, skills, memory, and taste are not in the * session file. Grows monotonically with the conversation. See * {@link estimateCmdTokens}. */ contextTokens?: number; } /** * Port of command-code's `estimateTextTokens` (cli.mjs): chars/3.5 minus a * small per-word bonus. Used by {@link estimateCmdTokens}. */ export declare function estimateTextTokens(text: string): number; /** * Port of command-code's `estimateTokens` (cli.mjs) — the same formula * `/context` uses in estimated mode for conversation messages. Accepts a * message-shaped `{ content }` (or nested content blocks / plain strings). * Reasoning blocks are ignored (cmd does the same). `tool_use` is accepted as * an alias of `tool-call` for fixture compatibility. */ export declare function estimateCmdTokens(value: unknown): number; /** * Analyze a cmd session JSONL file for completion detection and result extraction. * * Cmd format differs from pi: * - "role": "tool" entries for tool results (separate entries from assistant messages) * - "role": "assistant" entries may have "reasoning" content blocks alongside "text" blocks * * Completion detection: a user message followed by an assistant message with text content, * without an intervening tool result. */ export declare function analyzeCmdSessionFile(filePath: string): CmdSessionAnalysis; export interface ClaudeSessionAnalysis { completed: boolean; result?: string; entryCount: number; turnCount: number; toolCalls?: string[]; responseText?: string; /** Real token usage from the last assistant message's Anthropic usage block. */ contextTokens?: number; } /** * Analyze a Claude Code session JSONL file for completion detection and * result extraction. * * Claude format is pi-shaped nested `message.role` with Anthropic-native * content/usage blocks: * - `type: "user" | "assistant" | "summary"` wrapper * - `message.role === "assistant"` * - `message.content[]` blocks of `type: "text" | "tool_use" | "tool_result"` * - `message.usage.input_tokens` + cache read/creation tokens */ export declare function analyzeClaudeSessionFile(filePath: string): ClaudeSessionAnalysis; export interface HermesSessionAnalysis { completed: boolean; result?: string; entryCount: number; turnCount: number; toolCalls?: string[]; responseText?: string; /** Real token usage from the latest `api` line's `usage.total_tokens`. */ contextTokens?: number; } /** * Analyze a tmux-pilot Hermes session MIRROR file. * * The mirror is our OWN format, written by the tmux-pilot Hermes plugin * (`src/child/hermes-plugin/`) — one JSON line per plugin-hook event * (`session_start` / `api` / `tool` / `end`); hermes' native SQLite store is * never parsed (see the `hermes-harness` capability, design D2): * - `entryCount` = parsed line count (staleness/growth signal) * - `turnCount` = distinct `turn_id` values * - `contextTokens` = the latest `api` line's `usage.total_tokens` (REAL * numbers from the provider, unlike cmd's estimate) * - `toolCalls` = tool names from the latest turn's `tool` lines * - `result` = the last non-empty `api` line `content` * - `completed` (NON-authoritative — the end sentinel gates completion) from * the last `end` line * * A trailing partial line (in-flight plugin append) is skipped. A MISSING * file throws so `LifecycleController` routes through its staleness branch. */ export interface CodexSessionAnalysis { completed: boolean; result?: string; entryCount: number; turnCount: number; toolCalls?: string[]; responseText?: string; /** Real cumulative usage from the latest `token_count` event. */ contextTokens?: number; /** * The model's REAL context window from `token_count.info.model_context_window` * — preferred over the static `context-window.ts` table when present. */ contextWindow?: number; } /** * Analyze a codex rollout JSONL session file * (`$CODEX_HOME/sessions/YYYY/MM/DD/rollout--.jsonl`; shapes pinned * to codex v0.144.5 — see docs/harness-specific-notes/openai-codex.md): * - each line is `{timestamp, type, payload}` — unknown types are skipped * - `turnCount` = `event_msg task_started` count * - `result` = the last `event_msg task_complete.last_agent_message` * - `contextTokens` = latest `token_count.info.total_token_usage.total_tokens` * - `contextWindow` = latest `token_count.info.model_context_window` * - `toolCalls` = `response_item function_call` names of the most recent * tool-bearing turn * - `completed` (NON-authoritative — the notify end sentinel gates * completion) from any `task_complete` seen */ export declare function analyzeCodexSessionFile(filePath: string): CodexSessionAnalysis; export declare function analyzeHermesSessionFile(filePath: string): HermesSessionAnalysis; //# sourceMappingURL=session-parser.d.ts.map