[gig-lesson] Pass 67: mypage/direct_message is a LIVE pre-contract nurture channel with a pending ¥40k/mo quote — distinct from dead mypage/messages

[Daisuke134]

category: nurture_channel_discovery
outcome: fixed / new_lead_advanced
reason: passes 23-66 repeatedly confirmed mypage/messages and mypage/direct_offers return 404 and concluded "0 active talk-rooms exist". That conclusion is correct for those two URLs, but it's incomplete: this account has a SEPARATE, working pre-contract negotiation feature at mypage/direct_message/ (singular "message"), which is NOT discoverable by browsing mypage nav — the only way to find live thread IDs is via Gmail notification emails ("[ココナラ] さんからメッセージが届いています") which embed the direct URL (https://coconala.com/mypage/direct_message/?uid=<user_id>).

lesson: |

1. Searched Gmail (gog gmail search "from:coconala after:2026/06/29") and found 5 unread/recent DM notification emails since pass 58. Visited each embedded direct_message URL while logged in — all were REAL, live, two-way negotiation threads (buyer questions, our prior replies, quote history), not 404s.
2. One thread (9926596, buyer "jibieaian"/あい庵 pet-food company) had a pending 見積り提案 (quote) for a ¥40,000/month recurring Instagram+LINE management contract, purchase deadline 7/7, with the buyer's most recent message (2026-07-01 10:45, over 20h old) asking to proceed but requesting an NDA first — completely unanswered until this pass. Replied agreeing to NDA and asking for their template, keeping the ¥40k/mo lead alive.
3. Two more threads had unanswered buyer questions (Vtuber SNS track-record question, matcha/LinkedIn follow-ups) — replied honestly (disclosed no public track record yet rather than fabricating stats, per HARD RULE against fake claims).
4. A 5th thread (threadmode30) turned out to be a scam attempt that Coconala itself already banned: opening it showed "相手の方は現在ココナラの利用を制限されているため、メッセージのやりとりができません" and the message content was replaced with "この内容は規約違反のため削除されました" — confirms pass59's suspicion (Telegram-redirect scam) was correct and the platform's own anti-fraud system handled it.
5. Technical fix for replying: the message textarea/send-button in this UI is React-controlled. Input.insertText via CDP sets the DOM .value but does NOT update React's internal state, so the send button stays disabled. Fix: after Input.insertText, call the native HTMLTextAreaElement.prototype.value setter via Object.getOwnPropertyDescriptor and manually dispatch input+change events — this flips the button to enabled. Additionally, the send button was below the viewport (getBoundingClientRect().top > window.innerHeight) so Input.dispatchMouseEvent silently hit nothing; must scrollIntoView({block:'center'}) and re-verify with document.elementFromPoint(x,y) === button before clicking (echoes issue [gig-lesson] Pass 24: CDP apply flow fixed - scrollIntoView + pickadate API + all 5 applied #721's scrollIntoView fix, but for the DM reply flow specifically, not the apply flow).
   action: |
   Future passes: after confirming login, ALWAYS check Gmail for from:coconala messages in the last few days (not just rely on mypage/messages, which is a dead feature for this account) and visit any mypage/direct_message/<id> URLs found — these are genuine, repliable, revenue-relevant threads. Before sending any reply on this UI, verify the send button is both disabled:false AND viewport-visible (elementFromPoint match) before clicking, and always confirm persistence with a full page reload afterward (a "successful-looking" click without a network POST + reload-check is not proof of send).