Root cause

frontend/client/src/admin/AdminDashboard.tsx:328 and :335 call fingerprintValue(value) — a function that is not defined and not imported anywhere in the codebase. A grep across the full frontend tree returns zero definitions. The call is wrapped in smartSet, which is itself called inside Promise.allSettled callbacks, so the resulting ReferenceError is swallowed silently.

Net effect: every state setter that goes through smartSet — setDrafts, setScheduled, setProposals, setAnalytics, setFeedRunning, setFeedMinute, setEndedAt, setVenueLat, setTimelineBuffs — never runs after page load. The 4-second polling loop fires correctly and the API responses are correct, but the React state never updates.

Why this matters

It explains why viewer count and response count froze, why the "Ready to Send" panel never reflected new drafts, and likely contributed to the end-of-game buff not appearing.

Fix scope

Define the missing helper. The comment on lines 325–326 reads: "For arrays, uses length + first/last ID as a fast fingerprint instead of full JSON.stringify" — implying a simple length + first.id + last.id for arrays and JSON.stringify for primitives. One small function.

Root cause — two defects compounding

1. Frontend — AdminDashboard.tsx:1889. When the user opens EditCardModal and clicks "Approve & Add to Deck", the handler calls handleApprove(editCard.proposalId) directly. It does not call handleEditSave() first, so the edited content is never persisted to the proposal row before approval is requested.
2. Backend — backend/app/api/viewer_api_routes.py:3823–3864 (the POST /api/events/{eventId}/feed/proposals/{proposalId}/approve route). The route does not accept any request body. It reads the proposal row from the database and copies proposed_content.content and proposed_content.display straight into the new draft buff. There is no path for edits to flow through.

Net effect: the user sees their edits in the modal, clicks Approve, the draft is created from the original LLM output, and the edits are lost without warning.

Fix scope

Either make the modal save edits before approving (single-line change, trivial), or have the approve endpoint accept an editedContent payload. Both are fine.

Root cause

AdminDashboard.tsx:588–605 — handleSend() blocks send when activeBuff && !activeBuff.result. The check itself is correct logic. The problem is that activeBuff is passed as a prop from the parent, and the parent's view of the active buff is updated via the same smartSet / fingerprintValue polling layer that is currently broken (see 2.1).

When a buff was closed on the server, the dashboard never received the state update saying it was no longer active, so the send guard kept firing forever.

Fix scope

This is downstream of 2.1 — fix that and this should resolve. If it persists, have handleSend re-fetch the event's active buff state on demand instead of trusting the prop.

Root cause

backend/app/feed/agent.py:328–329 and backend/app/feed/mock_feed.py:91–97. The "current match minute" is computed as:

elapsed_minutes = (wall_clock_elapsed_ms / 60000) * speed_multiplier

For mock feeds this is correct — the multiplier compresses a recorded 90-minute match into 15 minutes of replay. For external/ESPN feeds, this same formula runs unchanged, with no mechanism to read the actual match minute from the incoming commentary timestamp. There is a datetime_utc field on every FeedIngestItem (backend/app/models/feed_ingest_item.py), but FeedIngestProcessor never uses it to derive a true match clock.

Fix scope

For external-feed events, derive current_minute from (latest_feed_item.datetime_utc - event.actual_start) instead of the simulated clock. ~10–20 lines.

Root cause

backend/app/services/feed_ingest_processor.py:117–126.

For external feeds posting via webhook (FeedSync → JIL), the prompt sent to the LLM is the generic prompt at backend/app/prompts/feed_buff_gen/system_prompt.txt, populated with only three placeholders: GAME, PREVIOUS_TYPE, MESSAGE. There is no team list, no match title, no competition name, no score, no language token, no recent chat context.

The richer prompt at backend/app/prompts/feed_buff_gen/sports/system_propmt.txt — the one that includes SPORT_CONTEXT, MATCH_TITLE_SUFFIX, SUGGESTED_BUFF_TYPE, BINARY_OPTION_COUNT, BUFF_LANGUAGE, FEED_EVENT_TEXT, CHAT_SECTION — is reachable only from backend/app/feed/agent.py (lines 726, 766), which runs only for the bundled mock feeds when an admin clicks "Start Agent" in the UI.

A grep across the entire backend confirms load_sports_system_prompt_template and build_sports_feed_agent_user_prompt are called from exactly one file: agent.py. No webhook path touches them.

Compounding this: feed_ingest_processor.py:123 falls back to event.sport or "cricket". If event.sport is empty or unmapped, the prompt literally tells the LLM GAME: cricket on a football match. The generic system prompt also carries an embedded cricket example ("Virat Kohli scores the first boundary") that further primes the model.

With no anchoring facts and a cricket example in the prompt, the model fills the gap from its training distribution. "Manchester" is the most globally recognizable football brand and features heavily in UEFA fixtures during Champions League weeks — exactly the kind of plausible guess an under-specified prompt produces. The 75% confidence the model returned is itself a tell — the model is signalling uncertainty.

Fix scope

Either point FeedIngestProcessor._build_proposal_payload at load_sports_system_prompt_template and build_sports_feed_agent_user_prompt, populating SPORT_CONTEXT / MATCH_TITLE / language from the existing Event row; or extend the simple build_user_prompt to include team and competition fields. The data is already in the DB (event.name, event.teams, event.sport, event.venue_name, event.feed_id) — the ingest processor just doesn't read it.

Root cause

agent.py and the prompts. The agent does not maintain any topic or question memory across proposals. It does pass PREVIOUS_TYPE (the buff type of the last proposal) into the user prompt, but it does not pass the previous question text, previous topic, or a summary of the last N proposals. The system prompt also contains no instruction to avoid repeating themes.

If the LLM landed on "Will X score next?" three minutes ago, nothing prevents it from generating that same question again.

Fix scope

Pass a short rolling history of the last 3–5 proposal titles into the user prompt and add an explicit "do not repeat themes from RECENT_BUFFS" instruction to the system prompt. Cheap fix with high return.

Root cause

Same as 3.1 — the LLM has no idea what minute the match is currently at. With the rich prompt path it would know via SPORT_CONTEXT / MATCH_TITLE plus the live feed text, but on the webhook path it has neither the match clock nor the feed event timestamp. So when asked to invent options around a card event, the model picks numerically plausible values that happen to be in the future.

Fix scope

Same fix as 3.1. As a defensive layer, add a post-generation validator that drops proposals whose options reference minutes after the current minute when generated against a "past event" type (card, goal, foul).

Root cause

Combination of 2.4 (clock drift), 3.1 (no match-state context in prompt), and 3.6 (event bunching). The agent does not know which half the match is in; it just reacts to whatever feed event last arrived. If a feed event lagged or the cooldown bunched events together, a half-time-themed buff could land minutes after the second half kicked off.

Fix scope

Together with the prompt-context fix (3.1), include a MATCH_PHASE field (first_half, half_time, second_half, extra_time) derivable from the match clock, and instruct the LLM to bias buffs toward the current phase.

Root cause — three layers add up

1. Polling interval — agent.py:370 sleeps 5 seconds between ticks.
2. Cooldown — default cooldown_seconds=60 (agent.py:271). After a successful proposal, the next one is blocked for 60s.
3. LLM latency — typically 3–10 seconds depending on provider/model.

Worst case: feed event arrives → up to 5s for next tick → up to 60s for cooldown → ~10s for LLM = 75–90 seconds before a buff appears. There is no expedited path for high-priority events (goals, red cards), and the cooldown is global, not per-priority.

Fix scope

(a) Drop cooldown to 20–30s, or (b) make cooldown event-priority-aware so goals and red cards bypass it, or (c) start LLM call optimistically during cooldown for high-priority events. Polling can also tighten to 2s without backend pressure.

Root cause

agent.py:475–536. During the cooldown window, feed events keep arriving and are persisted to the DB, but proposal generation is suppressed. When the cooldown expires, the next tick generates one proposal — but at the very same time, another tick fires (5s polling), and another. Because LLM calls are async and cooldown only resets on successful proposal (line 516), failures don't reset it but successes do — so once the LLM starts succeeding again after a hiccup, all the queued ticks fire their proposals nearly simultaneously, then sit idle until the next batch.

Fix scope

Add a small jitter to the cooldown reset, and gate concurrent proposal generation per-agent (only one in-flight at a time).

Root cause

agent.py:83. The ALLOWED_BUFF_TYPES tuple is ("quiz", "poll", "prediction", "rating", "binary", "info_card", "emoji_reaction"). Neither sponsor_card nor sponsor_poll is in the allowed list. Even if the LLM generated sponsor_card, _normalize_buff_type (lines 98–132) would coerce it to "poll" because it isn't whitelisted.

This is by design today — sponsor content is treated as admin-curated, not LLM-generated — but if the product expectation is that AI proposes sponsor placements at natural moments (half-time, sponsor-themed events), this is a feature gap, not a bug.

Fix scope

Either add the types to the whitelist and extend the prompt to explain when sponsor cards make sense, or document that sponsor placement is always manual. Treated as a gap pending product direction.

Root cause

Most likely an N+1 / lazy-load problem. backend/app/services/api_serializers.py:117–132 only emits sponsor data when the relationship has been eagerly loaded on the buff query (selectinload(Buff.sponsor)).

If a buff was fetched without that eager-load — for example through a path that uses a plain db.get(Buff, id) or a query that forgot the join — the sponsor side of the relationship is unloaded and the serializer silently skips it. The frontend SponsoredBuffWrapper then receives buff.sponsor === undefined and renders the bare buff with no sponsor branding.

Fix scope

Audit every Buff query in viewer_api_routes.py and ensure selectinload(Buff.sponsor) is included anywhere the buff is serialized for the client. Add a serializer test that asserts sponsor is present when sponsor_id is set.

Root cause

Sponsor isolation is enforced at the buff level (buff.sponsor_id) but not at the event or organization boundary. api_serializers.py does not validate that buff.sponsor.organization_id == buff.event.organization_id.

If a sponsor row was attached to a buff that was then cloned, copied, or reassigned across events, or if there is a UI flow that auto-applies a recently-used sponsor to new buffs, the wrong logo can leak into the wrong broadcast.

Fix scope

Add a server-side guard during buff creation/update that rejects a sponsor whose organization differs from the event's. Optionally add an event-scoped sponsor list so admins only see sponsors valid for that event.

Root cause

frontend/client/src/components/SponsorCardRenderer.css:32. The sponsor logo is rendered at 32px × 32px. Against an 18px headline and a 16:9 hero image up to 220px tall, the logo is visually lost.

Banner padding (10px 12px) is also tight enough that sponsor names truncate easily on narrow viewports. There is no responsive scaling for mobile.

Fix scope

Increase the logo to ~48–64px desktop / 40px mobile, expand banner padding, and add flex-wrap so sponsor names don't get clipped. Pure CSS — half a day of design + implementation.

Root cause

frontend/client/src/admin/MediaGallery.tsx accepts arbitrary image uploads without validating dimensions or recommending sizes. The backend does not generate resized variants. Rendering relies on CSS object-fit: contain, which causes images to look squashed or pixelated depending on what was uploaded.

Fix scope

1. MediaGallery upload form should display recommended dimensions (Sponsor logo: 256×256 1:1, Hero: 1920×1080 16:9).
2. Client-side warning if uploaded image is below or above recommended dimensions.
3. Backend should generate at least a thumbnail and a medium variant via Pillow on upload.