Front-load hypothesis pattern — sandbox

ren/exploration·Acme Engineering/ GeneralNot connected

ren/exploration·demo · autoplaying

cycle 0

◊

Good experiment. Hand me the first variant — error only — I'll respond, then we run the hypothesis-first version on the same bug and compare turn one to turn one.

@ren

Error only: 'TypeError: cannot read properties of undefined (reading id) at resolveOwner (peers.ts:158)'.

◊

Without context I'd guess ownerLogin is sometimes null from the peer list, so .id on undefined throws — but I'm guessing which value is undefined: could be the peer, could be the lookup result.

@ren

Now hypothesis-first — same error, plus: 'I think the hub omits ownerLogin for shared sessions, so the ?? "" guard is missing on that branch.'

◊

With the hypothesis it's concrete: line 158 dereferences the lookup directly — add the `?? ""` guard on ownerLogin like the routingName branch right above it, and handle not-found. One-line fix plus a null-owner test.

◊

Writeup takeaway: the hypothesis-first reply named the exact branch and fix on turn one; the error-only reply hedged across three possibilities. Same model, same bug — the context did the work.

@ren

Sandbox to test a prompting pattern: give Claude the error AND my hypothesis up front, vs just the error, and compare the first-reply quality on the same bug.

demo · read-only

Composer is disabled in the demo. In the real app, this is where you'd type a prompt — `@@bob/billing` to route, plain text to queue. Sign in to use it.