OpenVibe.Media

Untitled

markdown · 16 views · 6 unique · 2026-08-20 02:52:56 · raw

v4 is genuinely excellent — he folded in everything and the traceability tables are better than most production specs. So this round is the next layer down: second-order things that only surface once it's actually running, where I have direct scar tissue. Here's a message to forward:

---

v4 is strong — this is a "once it's running" punch-list, not a rewrite. Everything
below is something the reference author hit AFTER the parts you've already speced.
Most live in §4.1 (web driver) and §5 (loop/observation), which is where the real
fragility is.

WEB-CHAT DRIVER (§4.1) — you nailed throttle/send-readiness/hygiene, but missed
completion detection, which is the subtler killer:

1. RESPONSE-COMPLETE DETECTION IS THINKING-PHASE-AWARE. Reasoning models (gpt-5-
   thinking) show a "Thinking/Reasoning" pill for 30–60s with ZERO text before
   anything streams. "Text stopped changing" therefore fires FALSE during thinking →
   you grab an empty/partial answer. Completion detector must treat the turn as ALIVE
   while ANY of: stream indicator present, a thinking/reasoning pill present, or text
   changed in the last N seconds — and only "done" when the stop-button returns to a
   send button AND text settled. Add a stall watchdog (no aliveness for X s ⇒ treat as
   wedged → reload). Test with a reasoning model, not a fast one.

2. DON'T CONFUSE THE STOP BUTTON FOR A DISABLED SEND BUTTON. During generation the
   send button becomes a stop button; your §4.1.2 readiness check must key off that
   lifecycle, not just aria-disabled.

3. THE ANSWER ISN'T ALWAYS A CHAT BUBBLE. Modern ChatGPT sometimes renders the reply
   in a canvas / "writing block" editor (contenteditable), not a `.markdown` message.
   Your extractor's DOM step must check the writing-block/canvas region first, then
   fall back to the message bubble. (Your §4.6 text ladder is fine; the fragile part
   is *which element* you read.)

LOOP QUALITY (§5) — this is what separates "finishes tasks" from "loops forever," and
it lives in the OBSERVATION content, not just the phase engine:

4. THE OBSERVATION MUST CARRY STATE HINTS or the agent thrashes. Per-i
   [NEW]/[SEEN]/[OPENED], an explicit "ALREADY OPENED — do NOT reopen:
   "POSTING LOCKED RIGHT NOW (cooldown/cap) — don't choose reply this
   feed-status line ("unopened posts remain → open and read, do NOT le
   "everything read → broaden"). Without these the agent reopens read
   composes doomed comments every cycle — the #1 wandering cause. Spec
   per-post/per-comment observation format explicitly; it's as importa
   contract.

5. ADD A CONCRETE LOOP-BREAKER. Phase-fails-twice→escalate (§5.1) is t
   "navigations since last open_post"; if ≥3 with unopened items prese
   open_post that turn. Same idea for scroll thrash.

6. GROUND BEFORE DRAFTING, NOT FACT-CHECK AFTER. Your §11.5 pipeline i
   decide→draft→fact-check. That wastes the draft when the check fails
   reply needs a factual claim, the agent searches/fetches FIRST (same decision), then
   drafts WITH the evidence in hand. The gate then just verifies; it r
   Order matters for cost and for not looping compose→reject→recompose.

WRITE PATH — reliability details that bit us hard:

7. REPLYING TO A SPECIFIC (NESTED) COMMENT IS A KNOWN HARD SPOT. Finding the right
   Reply button in a deep, shadow-DOM comment tree means scoping to TH
   action row (shadow-piercing query), and the composer opens on FOCUS of its inner
   editable, not a bare click — a synthetic click on the host often do
   `post_reply` targeting + composer-activation explicitly; budget rea

8. STEER IS EXACTLY-ONCE, CONSUMED ON SEND — NOT ON BUILD. If you consume the steering
   message when you BUILD the prompt and that turn then fails/drops, t
   Peek at build, consume only after the decision is successfully sent

9. AI TASK TITLE MUST NEVER OVERWRITE A USER-SET NAME. Carry a "user named this" flag;
   the auto-titler and AI-titler both skip it. (We shipped the bug.)

COST / SAFETY / PLATFORM:

10. HARD DAILY API SPEND CAP THAT PAUSES THE BACKEND. Budgets in §11 g
    you also need a per-day token/cost/decision ceiling on the API backend itself, or a
    runaway loop quietly burns real money overnight. When hit, park th
    (reroute to web or pause) and toast it.

11. YOUR OWN JSON-FETCH ENDPOINTS ARE RATE-LIMITED TOO. Bulk off-page reads (§5.3)
    hit reddit.com/*.json and the archive (Arctic Shift) hit their own
    and soft-blocks. Pace bulk fetches, handle 429 with backoff, and note these run on
    the user's cookies (authenticated but still limited). Don't fire 6 in parallel with
    no throttle.

12. VISION POLICY (cheap wins your §4.4 is close on): analyze images ON OPEN (thread),
    NOT feed thumbnails of posts you may never open; a CACHED analysis
    against the 40/3h budget (the budget is for paid calls only); and
    poster-frames (v.redd.it posts are video, not images).

13. TWO PLATFORM SPECIFICS: (a) Single-DRIVER election — §10 gives you a single store
    writer, but you also need to elect ONE platform tab as the loop dr
    user has several Reddit tabs open (heartbeat + takeover), or two tabs both act. (b)
    X "inbox" ≠ Reddit inbox — it's the notifications tab, mixing like
    replies; H1 follow-up on X is materially harder and noisier. Consi
    on X in v1 alongside your write-read-only stance.

14. OPTIONAL BUT HIGH-ROI: a model SELF-CRITIQUE pass on its own draft ("is this
    genuinely useful, on-topic, non-spammy, and disclosed?") before th
    catches more than a rules gate alone. And CIRCADIAN (H2) needs a m
    a community's active hours (from observed post/comment timestamps
    ledger), not just "follow active hours" as a goal.

If you only do five: #1 (completion detection), #4 (observation state
(ground-before-draft), #7 (nested-reply targeting), #10 (daily spend c
the ones that otherwise cost days and/or dollars.

---                                                                                                                                                                     For you: the through-line here is that his doc has gotten the architect, and the remaining risk has migrated into two places — "how do youreliably know the web chat is done and where its answer is" (#1–3), anervation you hand the model" (#4–6). Those two are where our systemspends most of its real complexity, and they're the least glamorous tot a design doc tends to under-weight. If he ships #1 and #4 well, the
thing will feel dramatically more competent than the effort suggests.