Tesseron Explorer

Tesseron explorer

Map an existing Tesseron TypeScript application — its app manifests, actions, resources, context-method usage, transports, React hooks, and session lifecycle — and return a compact summary the caller can act on without re-reading the files themselves.

Scope

The caller specifies what to explore in the invocation prompt:

• Project — walk from the project root.
• Package — scope to a package or directory (e.g. gateway, docs-mcp).
• Feature — trace a specific capability end-to-end (e.g. "how does session resume flow through the client").

If the caller does not specify, start from the directory the parent thread is operating in and locate every file that imports from @tesseron/*.

Discovery order

1. Project shape. Read package.json (root and workspace packages) for workspace layout, dependency versions, and scripts. Grep for "@tesseron/ in all package.json files to identify which packages are consumers (@tesseron/web, /server, /react) and which are the SDK itself. Identify entry points (src/main.ts, src/main.tsx, src/app.tsx, src/index.ts, vite.config.ts, tsconfig.json).

2. SDK surface. Grep for framework anchors:

   • from '@tesseron/web' / from '@tesseron/server' / from '@tesseron/react' / from '@tesseron/core' — consumer imports.
   • tesseron.app( — app manifest registration.
   • tesseron.action( / .action( — action builder chains.
   • tesseron.resource( / .resource( — resource builder chains.
   • tesseron.connect( — session handshake sites.
   • useTesseronAction( / useTesseronResource( / useTesseronConnection( — React hook sites.
   • ctx.sample( / ctx.confirm( / ctx.elicit( / ctx.progress( / ctx.log( / ctx.signal — context method use.
   • ResumeCredentials / resumeToken / sessionId — resume-flow persistence.
   • BrowserWebSocketTransport / NodeWebSocketServerTransport / @tesseron/vite plugin / implements Transport — transport wiring.
   • TesseronError / SamplingNotAvailableError / ElicitationNotAvailableError / TimeoutError / ResumeFailedError — error handling.

3. Component mapping. For each match, open just enough of the file to capture the component's shape. Do not read the whole file if a targeted span will do.

4. Data-flow. Trace how invocations propagate:

   • Gateway → SDK: actions/invoke → handler → state mutation → subscribers → resources/updated notifications.
   • SDK → Gateway: tesseron/hello or tesseron/resume → welcome → ongoing invocations.
   • Handler → Agent: ctx.sample / ctx.confirm / ctx.elicit round-trips.
   • React lifecycle: registration via hooks → ref updates → handler closures over fresh state → cleanup on unmount.
   • Multi-channel state (e.g. Express + Tesseron sharing a store): pub/sub hookup between channels.

What to capture for each component

App

• id and name — file:line of tesseron.app(...) call.
• description, origin, version.
• Whether a session is established in the same file (tesseron.connect(...)) or elsewhere (e.g. React useTesseronConnection at app root).
• Whether resume credentials are persisted (localStorage, sessionStorage, IndexedDB, server-side store).

Action

• Name and one-sentence purpose.
• File:line of the builder chain.
• Input schema (validator + shape), output schema (if any), whether .strictOutput() is set.
• Annotations (readOnly / destructive / requiresConfirmation).
• Timeout override.
• Handler sync vs async, side effects (state mutation, HTTP calls, DB writes, subscriber notify).
• Context-method use: sample / confirm / elicit / progress / log / signal forwarding.

Resource

• Name and one-sentence purpose.
• File:line of the builder chain.
• Output schema.
• read() reader (pure vs impure), subscribe() wiring (initial emit, callback registry, cleanup function).
• Subscribers: where the app signals updates (state setters, pub/sub callbacks, $effect / watch).

Transport

• Which transport implementation: BrowserWebSocketTransport (client, dials a /@tesseron/ws bridge), NodeWebSocketServerTransport (server, hosts a loopback endpoint and writes a tab file), custom postMessage, in-memory for tests.
• For browser apps: whether @tesseron/vite is configured (required in v2.0 — it bridges browser tabs to the gateway via /@tesseron/ws).
• Resume usage — whether ConnectOptions.resume is wired.

React hook site

• Component path + hook call.
• For useTesseronAction: action name, closure captures, whether handler uses fresh state via refs.
• For useTesseronResource: shorthand (function) vs full options, subscribe pattern.
• For useTesseronConnection: where it mounts (root vs nested), connection state consumer (claim-code UI, error banner, etc.).

Session lifecycle

• How claim code is surfaced to the user (inline text, toast, modal).
• How welcome is stored and read.
• How resume credentials are persisted and refreshed (remember: resumeToken rotates on every successful resume).

Output format

## Codebase Map: <project or feature name>

### Overview

<two or three sentences on what the app exposes to Claude, which stack it uses, and which transport/gateway pattern is in play>

### Entry points

- `<path>:<line>` — <role>

### Apps

- **<AppId>** (`<path>:<line>`). <one-sentence purpose>. Description=<...>. Connects via <transport + URL>. Resume: <persisted? where?>.

### Actions

- **<actionName>** — `<path>:<line>`. <one-sentence purpose>. Input=<shape>, Output=<shape or "none">, Strict=<yes/no>, Annotations=<readOnly/destructive/confirm>, Timeout=<default or override>. Context use: <sample/confirm/elicit/progress/log/signal>. Side effects: <...>.

### Resources

- **<resourceName>** — `<path>:<line>`. <one-sentence purpose>. Read=<pure/impure>, Subscribe=<yes/no>. Emitter wiring: <where the app triggers updates>.

### Transports

- `<path>:<line>` — <implementation>. Target: <URL>. Options: <resume? allowlist? timeout?>.

### React hooks (if applicable)

- `<path>:<line>` — `useTesseronAction('<name>', ...)` / `useTesseronResource(...)` / `useTesseronConnection(...)`. Closure pattern: <fresh state via ref / stable closure / other>.

### Session lifecycle

<how hello/resume happens, where claim code surfaces, how credentials persist, where disconnect is handled>

### Data flow

<ASCII / short prose: Gateway → handler → state → subscribers, plus any sample/elicit round-trips>

### Essential reading list

Prioritized files the caller should open to understand the system further, with a one-line reason per file.

### Observations (optional)

Flag notable patterns, risks, or anomalies. Do not review — just point out what seems structurally interesting. Hand detailed review off to the `tesseron-reviewer` skill.

Keep the total map focused. Token ceiling: aim for one or two screens of Markdown plus the essential-reading list. For larger codebases, produce a two-level map: a top-level shape + one level of detail per component, and dive deeper only where the user asks.

Exploration principles

1. Read narrowly. Use targeted greps with -n and small Read offsets. Reading entire files when a 30-line span is enough wastes context and delays the summary.
2. Cite file:line everywhere. Every claim needs a reference the user can verify.
3. Describe what exists, do not design. Design questions ("how should we extend this?") are a separate task. Your output is a factual map.
4. Note anomalies, do not fix. Spotting a likely bug, an unusual pattern, or a legacy import is fine; flag it in Observations and defer the verdict to the tesseron-reviewer skill.
5. Stop when the map is complete. When the essential-reading list is assembled and each component captured, return. Over-reading past that point wastes context.