Commit Graph

3 Commits

Author SHA1 Message Date
db91daabf8 console: the receipt is gone from the workflow, so stop describing it
The conversation panel told the reader that two automatic sends were absent
from the thread. Only one is now — 97 removed the "I have your message"
receipt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-08 18:57:24 +05:30
5d146e9ffb console: a thread that shows what the customer actually received
The order was right — the audit rows are in sequence and the panel
rendered them in sequence. Two other things were wrong.

A MESSAGE THE CUSTOMER GOT WAS NOT IN THE THREAD. After "Okay I confirm
the policy go ahead" the panel showed nothing from us until their next
question, so it read as though we had ignored somebody agreeing to buy.
We had not — the confirmation went out immediately — but it was composed
inside a trigger node and never written to a field, and the console can
only show what the workflow records. 90 stores it in customer_answer, so
it appears here and in the trail. An operator reviewing an acceptance no
human took needs to see exactly what the customer was told at the moment
they said yes.

ORDERING IS NOW (timestamp, id). One submission writes three rows in the
same second — the trigger commit, its repeat, the settle — so a timestamp
alone left their order to the sort's stability, and a reply could print
before the message it answered whenever the two landed in the same
second. It had not happened yet; it was waiting to.

DE-DUPLICATION ONLY COLLAPSES AN IMMEDIATE REPEAT, not any repeat
anywhere in the thread. A customer who asks the same thing twice because
the first went unanswered has said it twice, and a thread that silently
showed it once would hide exactly the impatience an operator needs to
see. Only a same-side, same-words turn directly after its twin is the
platform talking to itself.

The footer says which sends are still absent and why: the quote (a
registered template, not text we compose) and the read receipt (which
would sit between every question and its answer).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-08 15:47:49 +05:30
171aa4c2fa console: a live trail, faces for the agents, and the thread as a thread
Five of the six asks. The sixth — the whole row as the click target —
shipped in 704afe1 and is already live on both grids.

THE AUDIT TRAIL WAS FROZEN. Timeline fetched the rows once on mount and
never again, so a lead being worked by five agents in three minutes
showed the trail as it was when the page opened — on the one screen whose
job is watching work happen. The rows move to the lead page, which
already polls every 12s, and Timeline becomes presentational. One fetch,
one poll, and the conversation view reads the same rows so the two cannot
disagree.

THE ACCEPTANCE BUTTON OUTLIVED THE ACCEPTANCE. Recording an acceptance
twice is not a loop, a recovery or an alternative — it is meaningless,
and offering it invites someone to overwrite a customer's WhatsApp
acceptance with a worse record of the same event. Gone once
acceptance_ref is set, replaced by a line saying who accepted and when.

THE AGENTS HAD NO FACE. Five of them carry this workflow and the console
named them three different ways — "ai_engage" here, "Engage" there,
"Engage AI" elsewhere — so nobody could see that the thing which called
the customer and the thing which wrote the quote were one worker. One
roster now (api/agents.js): a short name, a colour and two initials each,
used wherever an agent is named. People get a disc too, in grey — a trail
where the machines are decorated and the humans are plain text reads as
though the machines are the important ones, which is backwards on a
screen built for oversight. A "Worked by" strip above the trail shows the
team at a glance.

THE CONVERSATION WAS A LOG, NOT A THREAD. Each turn sat as its own entry
among twenty others. Now one button opens it as a thread — theirs left,
ours right, oldest first — and the footer says plainly which parts it
holds: the quote, the read receipt and the acceptance confirmation are
sent by trigger nodes and never written to a field, so they are not
there. A thread that quietly omitted them would be worse than one that
admits what it is.

CONFIRMING A PREMIUM IS A SIGN-OFF, NOT A TASK. It is the only step
locked to one role and the only one that touches money — an employee that
could mark a premium received could put a customer on risk for a policy
nobody paid for. It sat fourth in a list of six queues. It gets its own
band now, shown only to the role that owns it, amber only when something
is actually waiting: a permanent alert colour on an empty queue teaches
people to stop seeing it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-08 15:29:02 +05:30