Every one has been driven as far as an agent can take it. What is left in each case is a judgement — about money, about what a resident receives, about what you want to look at with your own eyes. Question 1 is the only one with a resident on the other end of it.
What I verified today, because it changes question 1: voice is an entirely uncapped outbound channel. Four files dial residents directly and none of them records or checks anything — confirmed on main, with a control to prove the zero was real.
So a resident who has hit their text limit can still be called about their renewal, and no row anywhere says it happened.
These are two different decisions and it matters that they are not confused. #5298 records every outbound call into the touch ledger — I checked the diff and it adds zero enforcement calls; it cannot refuse anything. Its value is that the nightly reconciliation could not see voice at all, so the coverage measurement meant to justify arming was being taken with a whole channel missing. #5232 is the arming — it is drafted on purpose, and the session that owns it found two live defects: a rate-capped resident gets filed as “Opted out of texts (replied STOP)”, and a renewal letter reports sent with the PDF undelivered.
Right now the system can phone a resident as many times as it likes, and nothing writes it down. One change starts writing it down but still can't stop anything. A second, separate change would actually start refusing — and that one still has two bugs where a resident's record ends up saying something untrue about them.
Neither is blocked on code. #5299 came back “all seven verified fixed, no blockers remain”. #5308 builds the first operator tour view — before it, tours only existed inside one prospect’s conversation. Its author says the thing worth repeating: “I reviewed both screenshots; a human has not. That is the review that matters here.” It also found and fixed a real cross-org leak on the way, so the diff is larger than the feature.
Two finished pieces of work. Every automated check passes on both. The only thing left is that nobody has actually looked at the pages with their eyes — and numbers being right tells you nothing about whether a page reads well.
I measured the real number today: CLAUDE.md is ~40,500 tokens, not the ~62k on the issue (two independent encoders agreeing within 0.5%). #5301 moves nine sections out and is a 5.8% cut — real, but it does not close the issue, and it is currently blocked on five dead links it introduced. #5310 is the guard that catches exactly that class. I also had to retract my own advice here: I claimed the next batch of sections was “already duplicated” in their linked docs, and when I checked, 93–100% of that content exists nowhere else.
The instructions file every session reads is long, and there is a plan to shorten it by moving parts into other documents. The first batch accidentally broke five links while moving them. A separate change adds a check that catches that automatically. Which lands first decides whether the broken links get caught by a machine or by another review round.
It moves the costly suite off every push and onto the reviewer’s verdict. The session that built it solved the dangerous part properly — a lane that never ran now reports pending rather than green, so it cannot pass by not running. It left two trade-offs open on purpose and said they are yours: every inline review comment still starts a run, and PRs touching only workflows or evals never get a verdict at all. Both close by firing the lane on PR-open instead, which trades away part of the saving.
Right now the full test suite runs on every single push, including the ones that were always going to pass. This change waits until a reviewer has actually looked. The open question is whether to also run it the moment a PR opens — safer and simpler, but it gives back some of the saving.
#5311 re-pins an eval row count (17→21) and is a ten-line change under review. #5312 is one character: .github/reviewer-core.md links an ADR with a path that resolves to nothing from where it sits, so a reviewer citing the standard hits a 404 at the moment of citing it. It is one line, but that file defines how every review in this repo happens, so the merge guard correctly held it “for Fede — security-relevant path”. I split it out of #5310 rather than let one line put a whole PR on your queue.
Two small ones. The second is a single broken link, but it is in the file that tells the reviewer how to review, so the system deliberately refuses to let a robot merge it.
The guard from this one merged (#5281), but its points 1–4 — the permanent occupancy and rent series — were never started. Today a session verified what that costs, and I re-checked every citation on main: money and occupancy cards read METRIC# daily snapshots, which are TTL-bounded at 400 days and populated only from 2026-02-28. The permanent rows exist — FINANCIAL# has 98 months back to 2018-05 — but nothing reads them. So “All time” is selectable on every card, exactly one card honours it, and the rest quietly render a trailing slice.
On the dashboard you can pick “All time” on rent income and occupancy, and it looks like it worked. It didn’t — those cards only have about five months of data behind them, because they read from a table that expires. The full history is sitting in a different table nobody wired up. One card was fixed; the others still quietly show you less than you asked for.
Pick an option above and your answers will appear here, ready to copy.