Feature: Interactive Plan Editor and Approval Queue in the Web Dashboard

[hoangsonww]

Summary

Add an interactive dashboard workflow for reviewing, editing, approving, rejecting, and sequencing Forge plans before execution, including support for pending approval queues across multiple running UI tasks.

Problem / Opportunity

Forge's agentic loop includes plan generation, validation, user approval, execution, validation gates, reviewer checks, and bounce-backs. The dashboard already exposes task execution and pending prompts, but plan review is not yet a first-class visual workflow. Users working in the browser should be able to:

• Inspect generated plans before tools run.
• Edit plan steps and constraints without going back to the CLI.
• Understand which permissions will likely be requested.
• Approve, reject, or send plans back for revision.
• Manage multiple pending tasks from one approval queue.

A visual plan editor would make Forge's controllability more accessible while preserving the same runtime guarantees as the CLI.

Proposed Feature

Build a dashboard Plan Editor and Approval Queue:

• Plan detail view with step list, dependencies, target files/modules, expected tools, and validation expectations.
• Inline editing for step text, order, mode, and constraints before approval.
• Approval queue for tasks waiting on user decisions.
• Plan diff view when the planner revises a plan after user edits or validation feedback.
• Permission forecast panel based on expected tools and side effects.
• WebSocket updates so queue status changes without reloads.

Scope

Expected implementation areas:

• src/core/loop.ts and src/core/plan-fixer.ts for exposing editable plan state safely.
• src/ui/task-runner.ts for pending approval state and responses.
• src/ui/server.ts REST/WebSocket endpoints for plan fetch/update/approve/reject.
• src/ui/public/ vanilla JS/CSS for the editor and queue.
• src/types/index.ts for serializable plan/edit/approval contracts.
• src/persistence/tasks.ts and events for recording plan revisions.
• Docs updates for dashboard task approval.

Acceptance Criteria

• Dashboard users can view a pending plan before execution starts.
• Users can approve, reject, or request revision with feedback.
• Users can edit plan step text and ordering while preserving state-machine legality.
• Plan revisions are persisted as events and visible in task replay/history.
• The approval queue shows all tasks waiting for user action, including permission prompts and plan approvals.
• Permission forecasts are clearly marked as estimates and never replace actual requestPermission calls.
• Concurrent browser tabs receive consistent queue updates through existing watcher/broadcaster patterns.
• Unit tests cover plan update validation, illegal transition rejection, and queue serialization.

Non-Goals

• Building a full project management board.
• Allowing dashboard edits to bypass planner validation or permission gates.
• Replacing CLI plan approval for terminal users.
• Supporting arbitrary custom DAG editing in the first version.

Dependencies / Risks

• Plan edits must remain compatible with the task state machine in src/persistence/tasks.ts.
• The UI shell should remain lean and avoid adding a framework unless there is a strong justification.
• Permission forecasts may be incomplete; wording and data contracts should prevent over-trust.
• Multiple tabs editing the same pending plan need conflict handling.

Open Questions

• Should edited plans be revalidated automatically before approval?
• Should the queue group tasks by project, mode, or age?
• Should the editor support dependency edges visually in the first version, or start with ordered steps?
• Should rejected plans remain resumable from the dashboard?