Architecture: How should Platform Elements editing be architected — three ...

Documentation for Sessions

🏗️ Architecture: How should Platform Elements editing be architected — three ...

Date: 2026-03-25
Time: 21:46:55 UTC
Session: gspace1-270.2
Agent: architecture
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

How should Platform Elements editing be architected — three separate modes (chat, visual, CRUD builder) or a unified loop?

Task: S270 Platform Elements Evolution

🎯 Decision Made

Chosen:

Unified editing loop with multiple entry points (click, chat, slash command, property panel) converging on a single mutation protocol. Local suggestion engine for instant deterministic suggestions. LLM (Vitto) only invoked when user acts on a suggestion or types a custom request.

Options Considered:

  1. Three separate editing modes (chat plugin, visual property panel, CRUD builder UI) — each independent
  2. Unified loop with LLM-generated suggestions on every click (high latency, high cost)
  3. Unified loop with local deterministic suggestions + LLM only on action (chosen)

💭 Reasoning

Three separate editing modes would triple the code surface, create inconsistencies between edit paths, and make each mode independently testable but not interoperable. The unified loop means: (1) Every edit is a PEMutation — same contract regardless of entry point. (2) Click context enrichment feeds both suggestions and Vitto — one data path. (3) The suggestion engine is deterministic and instant (no LLM latency for option generation). (4) Vitto only runs when the user actually wants something done — saves cost and latency. The key insight was that sendVisualEditContext() already existed but was a POST that didn't trigger proactive responses — so suggestions had to be local, not LLM-generated.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation