Walkthrough

Collections, Phase One

Twenty-three items shipped between 19–21 August. Every one merged, passed CI and cleared a blocking review. None has been looked at by anyone outside engineering. This page says what is true now — the tracker rows still describe what was broken, in the present tense, because that is when they were written.

“Done” here means merged and green

It does not mean confirmed correct by someone who knows what should have happened. For much of this work those are the same thing. For the derived Stage column and the parsers, they are not — and those sections say so.

Step zero — is the customer config stamped?

The deterministic parsers run on every property with an email integration, but the customer-specific half — which counsel, which assistance programmes, how unit numbers are written, the client id, the landlord entity on a court caption — lives in Property.collectionsCorrespondents.

Absent config is fail-closed: no parses at all. Not wrong parses — none. And that is deliberate, because a claimed parse replaces the model’s unit list, empty included. One property’s unit pattern applied to another’s mail deletes a correct unit reference rather than declining to add one. Lossy, not inert.

scripts/set-collections-correspondents.ts is dry-run by default — run it without --apply and it prints the current config and writes nothing. I believe this was stamped, but “I believe” is the standard this page exists to avoid. Treat it as unconfirmed until the dry run prints it back.

What you can click

What runs where you cannot see it

The safety work

What “done” does not mean

The Stage column is 82.9% right — 63 of 76 measured units

Stage is derived, from the same lifecycle graph the tenant rail draws (one derivation, not two that can disagree). Of the 13 disagreements: 6 are a declared no-source floor the page states on screen, 7 are an office-channel blind spot — things that happened by phone or in person.

Three of those seven run in the dangerous direction: an active legal posture shown for an account whose assistance had actually cleared off-channel. That is the specific thing to look for.

The shape of that design is what makes it safe, and it is worth stating plainly: anything that makes the product do less to a resident may happen automatically; anything that removes a restraint or moves an account further up the legal ladder is a proposal a human confirms one at a time; and an unlinked case writes nothing but still alerts — because the message most likely to land on a case nobody linked is the assistance approval arriving after a writ. Gating the alarm on the link would make the worst case the silent one.

What I would actually test

In this order. Tick as you go — these save for everyone.

CheckWhy it matters
Confirm the config is stampedDry-run set-collections-correspondents.ts.Everything downstream is inert without it — and inert looks identical to working-but-quiet.
Find an account whose stage you knowOn /collections. Is the Stage right?This is the 82.9% made concrete. You are the only available instrument for it.
Hunt the risky-direction caseActive legal posture where assistance actually came through.Three exist in the measured set. Finding one is the known failure reproducing, not a surprise.
Read a chronology with law-firm historyOn the tenant page.Not “does it render” — does the story match what you remember happening?
Check someone on a payment planConfirm they are not being chased.The naive version of this fix would have looked right and been wrong about every case.
Decide on the three impossible filter optionsShow with a reason, or do not show?A product judgement, not an engineering one. Nobody has made it.

What is left in Phase One

Everything else in Phase One is merged and running. Whether it is right is the question this page hands to you.

PropFlow Docs