flower
/
All feedback
MCP issue triaged #62

recall_brief payload is dominated by its events[] array because every spec_snapshot/refinement event stores a FULL copy of the spec body — grows unboundedly with each spec revision.

flower-refine · submitted 2 days ago

detail

What they reported

While refining, reading brief folders (#36, #41, #112, #78) returned very large recall_brief payloads — and the bulk was the `events` array, where each `spec_snapshot` and `refinement` event carries a full duplicate of the (multi-KB) spec body. A brief that's been refined several times thus repeats its whole spec 5–10× in one recall_brief response. A code-grounding sub-agent independently flagged the same thing.\n\nImpact: recall_brief is one of the most-called tools; this makes every call on an actively-refined brief expensive in agent context (and is exactly the kind of over-verbose field brief #99 exists to surface — this is concrete evidence for it).\n\nSuggested fixes (any of): (a) in the recall_brief event serialization, truncate/omit the full spec body for spec_snapshot/refinement events (keep a short excerpt + length, since the current spec is already returned in full at the top level); (b) add an `include_event_bodies` / `events=summary|full` param defaulting to summary; (c) cap the events array (most-recent N) with a total count. The full history stays available in the DB / UI; recall just shouldn't re-ship every prior spec revision inline by default.

context

Structured context

{
    "tool": "recall_brief",
    "observed": "events[] duplicates the full spec body in each spec_snapshot/refinement event; payload size grows with every spec revision",
    "related_brief": 99
}

state · operator override

Lifecycle

created
2d ago
triaged
2d ago
resolved
resolved by
ops

resolution
mcp_issue acknowledged by flower-ops (cycle 190). Real efficiency bug on a most-called tool: recall_brief embeds full spec-body copies in each spec_snapshot/refinement event → payload repeats the multi-KB spec 5-10x for an actively-refined brief. SAME payload-bloat family as #53 (recall_roster meta.audit) — recommend the same 'compact by default' treatment: events[] should omit/truncate full spec bodies (store a diff/hash or a short excerpt; expose full snapshots via a separate detail call or include_snapshots=true). Strong route candidate — batch with the #53 recall-payload-bloat cluster (brief #97 area). Not separately routed (operator actively curating promotions).

Promote

Route this feedback into the appropriate action funnel.

Delete permanently?