#189 enhancement: session history, integer resume, and session listing for execute_prompt

[Anonymous]

Originally created by: kumaakh

Summary

Three related enhancements to improve session management in execute_prompt, enabling orchestrators (e.g. the PM skill) to make informed decisions about which session to resume.

---

a. Remember last 5 session IDs per member with prompt preview

The fleet MCP server should store the last 5 session IDs per member in the agent registry, along with the first 80 characters of the prompt that initiated each session.

Motivation: Currently only the latest sessionId is stored per member (agent-helpers.ts). If a bad resume=false dispatch overwrites the session, the prior session context is unrecoverable. With a 5-deep history, orchestrators can recover from accidental session overwrites and have an audit trail of which prompt initiated which session.

Proposed shape:

interface SessionHistoryEntry {
  sessionId: string;
  promptPreview: string;  // first 80 chars of the prompt
  timestamp: string;      // ISO timestamp
}

// On Agent record:
sessionHistory: SessionHistoryEntry[];  // last 5, newest first

---

b. Change resume from boolean to integer

Change the resume parameter of execute_prompt from a boolean to an integer offset into the session history:

Value	Behavior
0	Resume latest session (equivalent to current resume=true / claude -c)
1	Resume one older than latest
2	Resume two older than latest
...	...
false / omitted	Start fresh (equivalent to current resume=false)

This mirrors how Gemini handles session history natively. For Claude, the server resolves the offset by looking up sessionHistory[n].sessionId and passing it to claude --resume <sessionId>.

Motivation: The PM currently has no way to target a specific prior session — resume=true always hits whatever the server last recorded. An integer offset (or eventually a direct session ID) gives orchestrators precise control, especially after an accidental resume=false overwrites the latest session.

Backward compatibility: resume=true maps to resume=0; resume=false maps to fresh session. Existing callers are unaffected.

---

c. Add session listing capability

Add a way to list available sessions per member, so orchestrators can inspect the session history before deciding which to resume.

For Gemini: Use gemini --list-sessions (native support).

For Claude: Use the stored session history (from enhancement a) — return session ID, timestamp, and prompt preview for each of the last 5 sessions.

Proposed tool: Either extend member_detail to include sessionHistory[] in its JSON output, or add a dedicated list_sessions tool:

list_sessions(member_name) → [
  { index: 0, sessionId: "abc123", promptPreview: "You are executing fixes for PR #183...", timestamp: "2026-04-27T04:42:19Z" },
  { index: 1, sessionId: "def456", promptPreview: "Review PR #183 on the apra-fleet repo...", timestamp: "2026-04-27T03:11:05Z" },
  ...
]

Motivation: Gives the PM (and other orchestrators) visibility into available sessions before dispatching. Eliminates the guesswork of "which session is current" that caused context loss in this sprint. Pairs directly with enhancement b — list first, then resume=<index>.

---

Related

These three enhancements are designed to work together:

1. Store history (a) so there's something to list and target
2. Integer resume (b) so orchestrators can target specific sessions
3. List sessions (c) so orchestrators know what's available before deciding

Together they give PM-level orchestrators the session visibility they need to reliably maintain reviewer context across multi-step sprints.