Reading the complaints nobody reads

A user who cannot receive a payment does not file a usability report. They write “Failed to add funds: error in payment response: no_route — how will this get resolved?” under an issue number, or they post in r/Bitcoin that twenty thousand sats are stuck. Individually each of those is a support ticket. Together they are a research corpus, and nobody was treating them as one.

So the summer had two halves. First: build a way to read the whole pile — extract it, structure it, filter it, and count it. Second: take what it says one issue at a time and answer it in the interface. 25 issues were worked end to end; two of them turned into full redesigns.

Two rules kept the corpus honest. Only live issues count — a closed thread is a decision already made, not evidence. And every extract carries who opened it, the issue number, the date, and the whole discussion, not just the title. Most of the useful material is in the replies: the title says “QR scanner is slow”, the third comment says which Android version and what the user did instead.

AI is what made a corpus this size readable by one person in one summer. It is also the fastest way to produce confident, well-formatted, wrong counts — and a count is exactly what the rest of this page rests on. So the split is deliberate: the model does the volume work that has a checkable answer, and a human owns every step where being wrong is invisible.

Every diamond in these flows is a place the shipped app currently answers with a raw string. “Is channel opening successful?” resolves to error in payment response: no_route. “Is the channel closure confirmed?” resolves to “Failed to retrieve fee. Please try again later.” Mapping the flows is what turns eight scattered error-message issues into one recurring failure of the same kind.