tasks

Design AI Chat Interaction Model

Goal

Design the WebApp AI Chat model for explaining, navigating, diagnosing, and proposing content maintenance actions without bypassing repository review boundaries.

Sources

Context

AI Chat could eventually explain workspace state, diagnostics, references, views, and user-selected context. It also creates safety risk if suggestions are treated as direct writes. The first model should define Chat modes and boundaries before implementation, but it remains deferred while editor extensions are the primary product surface.

In Scope

  • Define supported AI Chat modes such as explain, find, diagnose, draft, dry-run, and propose.
  • Define what workspace context the Chat surface can read from existing and future Forma operations.
  • Define how Chat suggestions become operation proposals rather than direct file writes.
  • Define privacy, local-only, confirmation, and audit boundaries for Chat.
  • Identify backend operation needs and follow-up implementation tasks.

Out Of Scope

  • Selecting a specific model provider.
  • Implementing network calls, credentials, billing, or hosted AI services.
  • Letting Chat silently edit repository files.
  • Full autonomous Agent execution.
  • Editor extension Chat surfaces.

Acceptance Criteria

  • The design defines Chat modes and clear safety boundaries.
  • Chat output paths into reviewable operation proposals are explicit.
  • Required RPC/CLI context operations are listed.
  • Privacy and local-only constraints are documented.
  • Follow-up implementation tasks can be created with clear P1/P2 boundaries.

Relationship Notes

This task depends on the proposal flow because Chat should produce explainable plans or proposals before any write-capable implementation is considered.

AI Chat is deferred by decisions/editor-extension-primary-product-surface. Keep this backlog item as future product context, but do not treat it as part of the editor extension MVP or active WebApp maintenance scope.

Open Questions

  • Should the first Chat implementation be provider-agnostic shell design only, or include a local/manual mock provider for dogfooding?