OpenVibe.Media

Claude Prompt For Me

text · 14 views · 4 unique · 2026-04-07 23:31:10 · raw

You are working inside the HoboStreamer #codebase

Primary repo:
- GitHub.com/HoboStreamer/HoboStreamer.com

Secondary repo:
- GitHub.com/HoboStreamer/HoboApp

Priority:
- HoboStreamer.com is the source of truth for streamer-site bugs, UX, routing, live broadcast behavior, chat, voice chat, notifications, restreaming, analytics, requests, and pastes.
- HoboApp is secondary context only. Use it only if you find clearly relevant shared Hobo network patterns for paste/tool handoff or navigation consistency.
- Do not let HoboApp drive streamer bug fixes.
- Do not invent pages, systems, or backlog items that are not explicitly listed below.

Your job:
Do a real audit of the HoboStreamer based on the entire #codebase analyzed and then implement targeted fixes for the combined owner-written backlog below.

Do not stop at analysis.
Do not give vague suggestions.
Do not rewrite the entire app unless root-cause analysis proves it is necessary.
Find the real files, trace the actual route ownership, UI ownership, websocket ownership, and state ownership, identify the root causes, and produce real code changes.

Core rules:
- Preserve current architecture unless a focused refactor is clearly required.
- Be paranoid about duplicate listeners, duplicate websocket subscriptions, stale timers, stale intervals, reconnect loops, memory leaks, layout thrash, and stale state surviving in the wrong place.
- Verify every route, selector, handler, API call, and file path before editing it.
- If a file/module name is not real, do not hallucinate it. Discover the real owner first.
- Prefer safe modular helpers over duplicated logic.
- Keep the site fast and mobile-safe.
- Keep current broadcast, VOD, clip, relay, chat, voice, and websocket flows working.

Live surfaces to inspect if browser/network access is available via #web tools:
- https://hobostreamer.com/
- https://hobostreamer.com/dashboard
- https://hobostreamer.com/broadcast
- https://hobostreamer.com/chat
- https://hobostreamer.com/goosely

Codebase starting points to inspect first, then expand only where real ownership leads:
Backend:
- server/index.js
- server/chat/chat-server.js
- server/streaming/routes.js
- server/streaming/call-server.js
- server/vod/routes.js
- any actual notification, relay, platform integration, analytics, paste, or admin routes/services you discover

Frontend:
- public/index.html
- public/css/style.css
- public/js/app.js
- public/js/chat.js
- public/js/stream-player.js
- public/js/broadcast.js
- any actual notification, voice/call, dashboard, relay, analytics, requests, or paste UI files you discover

Important grounding:
- There is already a dedicated broadcast page. That should own going live.
- There is already a dashboard page. It should not own stream creation.
- There is already existing live chat, global chat, voice channel UI, restream UI, TTS UI, media/request UI, and pastes/images UI.
- Fix and unify the real existing surfaces. Do not create a parallel second system and call it a fix.

Combined backlog from the notebook + current live-site testing:

1) Dashboard should not own “Go Live”
- The dashboard currently contains a go-live area/button/form.
- Going live should happen through /broadcast, not /dashboard. Same with ending streams and such.
- The Go Live / Past Streams / Broadcast Settings tabs at the top of the go live page do not work properly
- You are unable to easily configure all your settings before going live
Required outcome:
- Audit nav, routing, and the actual dashboard/broadcast ownership boundary.
- Remove or repurpose stream-creation UI from dashboard.
- Dashboard may link users to /broadcast, but it should not be the page that owns stream creation.
- Make ownership explicit and consistent across nav, labels, and CTAs.

2) Notifications are stale / noisy / stay up too long
- Old notifications keep showing up.
- Irrelevant notifications feel like they linger too long.
Required outcome:
- Audit notification creation, fetch, storage, dedupe, unread/read state, dismissal, TTL, sort order, and initial-load behavior.
- Stop surfacing stale junk on initial render.
- Shorten transient on-screen lifetime.
- Dedupe repeated identical events.
- Keep important notifications visible enough without making the UI annoying.
- When opening notifications dropdown it often fails to load on the client end.

3) Broadcast page needs a real self-preview control
- Add a clear control on the streamer broadcast page that lets the streamer preview their outgoing stream “in all its quality glory.”
Required outcome:
- The streamer can intentionally preview what is being sent.
- No audio echo, no feedback loops, no accidental second broadcast session, no duplicate capture session.
- Do not break existing preview behavior if one already exists; improve/disambiguate it.

4) Restream functionality is buggy / weird
- Audit the restream system end to end.
- Ensure RTMP and JSMPEG streaming function. Specifically RTMP appears to be buggy and not function correctly.
- Verify RTMP / OBS / JSMPEG / WebRTC paths and IRL Pro compatibility where the code intends to support it.
Required outcome:
- Fix dead buttons, misleading statuses, bad reconnect/retry behavior, broken validation, and silent failure states.
- Make missing config fail clearly instead of silently.
- Preserve existing restream capabilities instead of replacing them with fake simplified behavior.

5) Stream chat typing feels laggy
- There is noticeable/slight lag while typing into stream chat and it does not feel fluid.
Required outcome:
- Profile the real input path.
- Remove keystroke lag caused by rerenders, synchronous filtering, message reprocessing, websocket echo handling, autosize/layout thrash, or expensive DOM updates.
- Keep send behavior, moderation hooks, relay hooks, and TTS behavior intact.

6) Chat should be resizable horizontally
- Make chat resizable width-wise with drag when watching a live stream.
Required outcome:
- Add real drag-resize behavior where it makes sense in the existing layout.
- Keep responsive/mobile behavior intact.
- Avoid layout thrash and broken overflow.
- Persist width sanely if appropriate.

7) Restarting a stream clears local chat incorrectly
- When the stream restarts, local chat log gets cleared even though the history may still exist globally.
Required outcome:
- Audit stream-local chat history vs global chat history ownership.
- Fix the confusing clear/reload/persistence behavior.
- Do not falsely imply deletion if backend history still exists.
- Make empty/history states honest.

8) “RS chats do not delete properly”
- This wording is ambiguous. “RS” may refer to RobotStreamer-related chat or a restream/relay chat path.
Required outcome:
- Inspect the code and infer the most likely meaning from the real implementation.
- Audit deletion/removal behavior for that chat path.
- Fix cases where UI says something was deleted but reload or backend exposure restores it.
- Explicitly document the assumption you made in the final summary.

9) Make external-platform chat TTS configurable
- Make RS / YouTube / Twitch / Kick chat messages readable via TTS in a configurable way.
Required outcome:
- Audit the existing chat relay and TTS path.
- Add sane configuration so relayed platform messages can be read out without breaking native HoboStreamer chat.
- Keep it explicit, configurable, and non-annoying.

10) Kick viewer count may require API/config (may require API/config which can be adjusted in hobo.tools/admin)
Required outcome:
- Audit Kick viewer count implementation and its config requirements.
- If credentials / channel identifiers / chatroom IDs / API keys are required, validate them clearly.
- Do not silently show bogus connected states or misleading counts.
- Fail loudly and clearly in UI and logs when config is missing or unsupported.

11) Fix YouTube view count and chat relay (may require API/config which can be adjusted in hobo.tools/admin)
Required outcome:
- Audit YouTube live viewer count and chat relay end to end.
- Fix broken counts, dead relay paths, missing validation, and misleading statuses.
- Handle unsupported/misconfigured states clearly.

12) Fix Kick emotes in chat
Required outcome:
- Audit how Kick emotes are parsed/rendered in the HoboStreamer live chat UI.
- Fix broken rendering/mapping without breaking existing emote tabs/sources.
- Verify both desktop and mobile rendering.

13) Requests feature is broken and the videos do not download properly or something
Required outcome:
- Audit the current request/media-request implementation.
- Make sure the system is modular so new request types can be added later.

14) Connect HoboStreamer pastes to hobo.tools image/text tools
Required outcome:
- Audit the current paste/image flow on HoboStreamer.
- Create a new pastes.hobo.tools which is linked to HoboStreamer pastes system. Convert HoboStreamer pastes into pastes.hobo.tools and connect them together
- Add sensible contextual handoff actions to hobo.tools image tools and text tools where content type makes sense.
- Keep it lightweight and contextual.

15) Per-country viewer analytics + honest map precision
- Add per-country analytics for viewers.
- Any map or location view must be approximate only if that is all the data supports.
- Allow streamers to show this map under their stream (disabled by default)
Required outcome:
- Audit current analytics and location data sources.
- Add country-level viewer aggregation.
- Add a lightweight map or geo visualization only if the data supports it.
- Label precision honestly as approximate / coarse / IP-based / relative.
- Never pretend exact location if the implementation only supports rough geo or latency-relative data.

16) Audit the voice chat system on /chat end to end
- The voice chat system needs a dedicated audit, not just chat UI tweaks.
- During testing, user `ChuckBot` joined the voice channel and audio worked both ways, but their displayed username showed as `finditfixit` instead.
- The 3-dots user dropdown/menu is not clickable.
Required outcome:
- Audit voice channel presence, identity mapping, participant rendering, speaking/user cards, menu hit targets, event handlers, and any auth/user-resolution path.
- Find the root cause of the wrong displayed username during voice presence.
- Fix the 3-dots dropdown so it is actually clickable and functional.
- Verify that audio still works after the identity/menu fixes.
- Be especially careful about stale cached participant state, reused DOM nodes, or incorrect user-id/session-id mapping.

17) Voice chat + global chat mobile layout is terrible and broken
- On mobile, the /chat layout does not work properly.
- The attached screenshot shows the voice-channel join UI and the global chat area stacking/overlapping badly, with cramped layout and poor interaction flow.
Required outcome:
- Audit /chat specifically on mobile viewport sizes.
- Fix layout, spacing, overflow, stacking, sticky/fixed behavior, safe-area handling, hit targets, and input usability.
- Make voice chat and global chat coexist properly on mobile without breaking desktop.
- Ensure message input, dropdowns, buttons, user menus, and voice join controls remain usable.
- Pay attention to z-index, scroll containers, keyboard behavior, and bottom-input visibility on mobile.

18. Go Live stats button / connection health overview is inaccurate and too weak
- The current stats button / stats overlay on the Go Live page is not reporting connection bitrate correctly, and the overall stats feel misleading or broken.
  Required outcome:
- Audit the entire broadcaster stats pipeline end to end, including how bitrate, FPS, resolution, connection state, packet health, reconnect state, and transport stats are gathered and displayed on the Go Live page.
- Fix incorrect bitrate reporting. Do not show fake or unstable numbers caused by bad byte-delta math, sampling the wrong peer connection, stale counters, missing reset logic, simulcast/double-counting mistakes, or fallback values being labeled like real measured stats.
- Add a clear top-level connection health overview for the streamer while live, with simple statuses such as excellent, good, fair, poor, reconnecting, unstable, or no data, based on real measured conditions rather than vague text.
- The health overview should consider multiple signals together, such as actual outgoing bitrate trends, frame rate stability, resolution drops, ICE/transport state, reconnect attempts, viewer connection state, recent packet loss/jitter/RTT if available, and whether the stream is actively degrading or recovering.
- Make the stats useful on mobile and desktop while the streamer is actively on the go live page.
- Distinguish clearly between:
  * measured live stats
  * estimated target settings
  * disconnected / unavailable telemetry
- If direct WebRTC stats are unavailable, show an honest fallback state instead of pretending everything is fine.
- Improve the stats button / overlay UX so it surfaces the most important live information first:
  * connection health overview
  * live measured bitrate
  * FPS
  * resolution
  * stream method/protocol
  * connection/transport state
  * viewer-side delivery health if available
  * recent reconnect/recovery activity
- Add sane polling, reset, and cleanup behavior so stats do not accumulate stale values when switching streams, resuming a stream, changing cameras, toggling screen share, reconnecting signaling, or recovering media.
- Prevent duplicate timers, stale intervals, stale per-stream counters, and misleading values when multiple live streams/tabs exist.
- Keep the implementation lightweight and avoid adding expensive polling that hurts performance on the broadcast page.
- If needed, redesign the stats data model so the UI can render a stable overview card plus deeper detailed stats inside the overlay, instead of dumping inconsistent raw values.

Execution phases:

Phase 1 — audit
Build a real bug matrix before coding.
For each issue include:
- issue
- exact frontend ownership
- exact backend ownership
- suspected root cause
- exact fix approach
- regression risks / edge cases

Then immediately move into implementation.

Phase 2 — implementation
- Implement the fixes directly.
- Touch only files that actually need changes.
- Reuse existing UI/state patterns where they are sane.
- Add cleanup for intervals, timeouts, listeners, observers, resize handlers, and websocket handlers where relevant.
- Keep current styling consistent.
- Keep desktop + mobile intact.

Phase 3 — verification
After coding, provide:
1. concise summary of every changed file and why
2. any schema/storage/API changes
3. any migrations/backfill/seed steps
4. any assumptions made for ambiguous notes
5. a focused manual QA checklist covering:
   - dashboard vs broadcast ownership
   - notifications
   - broadcast self-preview
   - restream behavior
   - IRL Pro / RTMP / OBS / JSMPEG / WebRTC paths
   - chat typing performance
   - chat horizontal resize
   - stream-restart chat persistence
   - RS/relay chat deletion behavior
   - external-platform chat TTS config
   - Kick viewer count
   - YouTube viewer count + relay
   - Kick emotes
   - request-system unification
   - paste handoff to hobo.tools
   - per-country analytics + approximate map display
   - voice chat identity mapping
   - voice chat 3-dots dropdown/menu
   - /chat mobile layout and usability

Output requirements:
- Give actual code edits, not just prose.
- Show changed functions/files when necessary.
- If schema changes are required, include them.
- If new helpers are added, wire them up fully.
- Do not leave TODO placeholders.
- Do not invent fake routes, fake tables, or fake data models.
- If a feature is missing, implement the smallest real version that fits the current architecture.

Extra guardrails:
- Do not “fix” this by hiding broken UI without fixing the underlying ownership/state problem.
- Do not introduce rendering loops, reconnect thrash, duplicate socket subscriptions, or duplicate event handlers.
- Do not break current VOD, clip, broadcast, chat, voice, or relay flows.
- Do not fake exact geo analytics.
- Do not invent pages or backlog items not explicitly listed above.
- Verify the real implementation first, then patch the real owners.

Now start by auditing the real codebase, building the bug matrix, and then implementing the fixes.