GSoC 2026 – Interest: Idea #6 — Interactive Progress Visualization & Task Stepping

[PrafulVRaj]

GSoC 2026 – Interest: Idea #6 — Interactive Progress Visualization & Task Stepping

Hi! I'm [YOUR NAME] (@PrafulVRaj), a Computer Science student from East West Institute of Technology, Bangalore. I'm applying for Idea #6 – Interactive Progress Visualization & Task Stepping and have been actively contributing to the Gemini CLI codebase over the past two weeks — including two visualization-related features that directly overlap with this project's goals.

---

👋 About Me

• Active Gemini CLI contributor with 4 open/in-progress PRs across UI, core, and security areas
• Production experience in TypeScript/Node.js — [1-line example, e.g. "built and shipped X"]
• Strong background in React state management (Zustand, useReducer, context), async UI patterns
• Hands-on with Ink (React for CLIs) — through real PRs in this repo, not just side projects
• GitHub: @PrafulVRaj

---

Existing Contributions to Gemini CLI

These aren't just warm-up PRs — they're directly relevant to this proposal:

PR	Title	Area	Status	Relevance to Idea #6
#22118	Feat(cli): add interactive repository visualizer	Agent/UI	🟡 Open	Directly proves ability to build interactive tree visualizations in the CLI
#21067	Feat: tracker visualization	Core/UI	🟡 Open	Directly proves real-time state tracking and visualization in the TUI
#21858	Fix(privacy): pass projectId in GET and throw on ambiguous API response	Security	🟡 Open	Shows I read the codebase deeply enough to catch security edge cases
#20881	fix: restore AskUser answers after Ctrl+Z + fg suspend/resume	Core/UI	⚪ Closed	Tackled a subtle terminal signal handling bug — directly relevant to TUI robustness

The bottom line: I've already shipped visualization features into this exact codebase. The work for Idea #6 is a natural continuation of what I'm already doing.

---

🔍 Codebase Research

Through my PRs and code review, here's what I know directly shapes the design:

1. The exact integration point: useReactToolScheduler

packages/cli/src/ui/hooks/useReactToolScheduler.ts

This hook is the bridge between packages/core's CoreToolScheduler and the Ink UI. It already fires events for tool start/confirm/complete/error and drives the existing flat confirmation prompts. All GSoC work is consuming and extending these events — no core logic changes needed.

2. The confirmation seam is already there

messageBus.sendAndWaitForResponse() is already used for destructive tool confirmation — the core pauses, the UI handles input via messageBus.respond(), and execution resumes. Step-through mode is simply extending this pause to all tool calls when the mode is active.

3. shouldConfirmExecute() and getDescription() on every tool

Every tool already exposes structured metadata — no string parsing needed, just a typed interface. This is the foundation for rich per-node display in the tree.

4. Clean monorepo boundary

packages/cli (Ink UI) is strictly separated from packages/core (backend). This project lives entirely in packages/cli — zero risk of regressions in core logic.

5. Current UX gap

The existing UI shows a flat per-tool confirmation box: [a] Accept [r] Reject. There's no timing, no parent-child nesting, no sense of what already ran or what's coming next. My work on #21067 and #22118 has made this gap even more visible to me — the infrastructure for richer visualization is almost there; it just needs this project to fully realize it.

---

Achitecture

---

Technical Design

Core Data Model

// packages/cli/src/ui/stores/taskTreeStore.ts

type VerbosityCategory = 'read' | 'write' | 'shell' | 'search' | 'model';
type NodeStatus = 'pending' | 'awaiting-approval' | 'running' | 'done' | 'failed' | 'skipped';

interface TaskNode {
  id: string;
  parentId: string | null;
  type: 'model-turn' | 'tool-call' | 'tool-result' | 'error';
  toolName?: string;
  description?: string;           // from tool.getDescription()
  params?: Record<string, unknown>;
  result?: ToolResult;
  status: NodeStatus;
  startedAt?: number;
  durationMs?: number;
  children: string[];             // child node IDs for sub-agent calls
  verbosityCategory: VerbosityCategory;
  isExpanded: boolean;
}

interface TaskTreeState {
  nodes: Map<string, TaskNode>;
  rootIds: string[];
  stepThroughMode: boolean;
  pendingApprovalId: string | null;
  verbosityConfig: Record<VerbosityCategory, 'hidden' | 'collapsed' | 'expanded'>;
}

Key design decision: nodes are stored flat in a Map, not as a nested tree object. This makes streaming-safe updates trivial — patch a single Map entry by ID rather than deep-cloning nested structures. Children are referenced by ID.

---

Extending useReactToolScheduler

case 'tool-start':
  dispatch({
    type: 'NODE_START',
    id: call.id,
    toolName: call.name,
    description: call.tool.getDescription(),
    verbosityCategory: inferCategory(call.name), // 'read'|'write'|'shell'|'search'
    parentId: currentModelTurnId,
  });
  break;

case 'tool-confirm':
  dispatch({ type: 'NODE_AWAITING', id: call.id });
  if (stepThroughMode) {
    // Extend the existing messageBus pause to all tools, not just destructive
    await messageBus.sendAndWaitForResponse({
      type: 'step-through-approval',
      callId: call.id,
    });
  }
  break;

case 'tool-complete':
  dispatch({
    type: 'NODE_DONE',
    id: call.id,
    result,
    durationMs: Date.now() - startedAt
  });
  break;

case 'tool-error':
  dispatch({ type: 'NODE_FAILED', id: call.id, error });
  // Propagate failure status up to parent node
  dispatch({ type: 'NODE_CHILD_FAILED', parentId: call.parentId });
  break;

---

Ink Component Tree

<App>
  ├── <ChatPanel>               (existing, unchanged)
  └── <TaskTreePanel>           (new — toggled via /tree or always-on)
       ├── <TreeStatusBar>      mode + verbosity level indicator
       ├── <ScrollableContent flexGrow={1}>
       │    └── <TurnRow>       one per model turn (collapsible)
       │         └── <ToolCallRow isFocused={bool} depth={n}>
       │              ├── [▶/▼] [icon] tool_name   42ms
       │              └── <Collapsible isOpen={node.isExpanded}>
       │                   ├── <ParamsPanel>     syntax-highlighted JSON
       │                   └── <ResultPanel>     output or error trace
       └── <StepThroughBar>     only visible in step-through mode

Keyboard navigation:

Key	Action
↑ / ↓	Move focus between nodes
Enter / Space	Toggle expand/collapse
t	Toggle task tree panel
s	Skip current tool (step-through mode)
y	Approve current tool (step-through mode)
v	Cycle verbosity level
e	Expand all / collapse all

---

Verbosity System

// Configured via /verbosity command, persisted to settings.json
// Usage: /verbosity read=collapsed write=expanded shell=expanded model=hidden

type VerbosityLevel = 'hidden' | 'collapsed' | 'expanded';

const DEFAULT_VERBOSITY: VerbosityConfig = {
  read:   'collapsed',  // read_file, search — show name only
  write:  'expanded',   // edit, create — always show diff
  shell:  'expanded',   // run_shell — always show command + output
  search: 'collapsed',
  model:  'hidden',     // internal reasoning turns hidden by default
};

Power users can expose everything; beginners get a clean collapsed view by default.

---

Error State Visualization

When a nested tool fails, the failure status propagates up the tree visually:

▼ ✗ model-turn-3                         [FAILED — 1 child error]
  ▼ ✓ read_file(src/auth.ts)             42ms
  ▼ ✗ run_shell_command(npm test)        3201ms  [FAILED]
    └─ Error: FAIL src/auth.test.ts
         ● AuthService › login › should reject invalid tokens
           Expected: true  Received: false
  ▶ ⏸ edit(src/auth.ts)                 [SKIPPED — parent failed]

The SKIPPED state (⏸) is automatically applied to pending siblings of a failed node so users immediately understand the full blast radius of a failure.

---

📅 Timeline (175 hours, ~10 weeks)

Week	Hours	Deliverable
1	15	Sync with mentor on #22118 and #21067 feedback; finalise TaskNode schema incorporating lessons from existing visualization PRs
2	20	Wire taskTreeStore to useReactToolScheduler — all events dispatch to store, no UI yet. Unit tests for reducer
3–4	35	<TaskTreePanel> with <ToolCallRow> — flat list, status icons, timing. Keyboard focus + scroll
5–6	35	Tree hierarchy (parent-child from parentId), <Collapsible> params/results, JSON syntax highlight
7	20	Step-through mode: extend messageBus pause to all tools, <StepThroughBar> approve/skip/diff
8	20	Error propagation + nested failure visualization, SKIPPED state for orphaned pending nodes
9	15	/verbosity command + settings.json persistence, hidden/collapsed/expanded per category
10	15	Terminal resize safety, keyboard nav polish, integration tests, docs, final PR

Buffer built in: Weeks 3–4 and 5–6 are two-week blocks because Ink layout debugging (scroll + flexbox + resize) reliably takes longer than expected — I've hit this already in #22118.

---

🚀 Post-GSoC Ideas

• Trace export — gemini --trace-output run.json dumps the full task tree as structured JSON for CI audit logs
• Waterfall view — Gantt-style timeline of overlapping tool call durations, especially relevant if parallel tool execution lands in CoreToolScheduler
• VSCode companion — Surface the task tree in packages/vscode-ide-companion as an IDE sidebar panel

---

❓ Questions for the Mentor

1. Should the task tree be always visible (split-panel layout) or toggled on demand via /tree? I lean toward always-on with a compact collapsed default, but want to understand terminal real estate tradeoffs from your side.
2. For step-through mode — should skipping a tool halt the entire agent turn or just skip that individual call and let the model adapt to the missing result?
3. Are there plans for parallel tool execution in CoreToolScheduler? That would affect whether sibling nodes need to handle concurrent running states in the tree.

I'm already in the codebase daily — happy to jump into any follow-up discussion. Thanks for the great project idea, @jacob314 !

gsoc-2026 idea-6 tui ink task-visualization