I finished the work on all three and stopped at the same gate each time: none of it is pushed, because pushing is your call and each push costs a build. Question 1 is the real one — the rest only matter after it.
Where each one actually stands — all three are committed locally and verified, none is on GitHub:
215f3988 voice call ledger · e4063121 collections filter · 4c3d1c2e the TTL guard fix
The TTL guard one is different from the other two: its PR is already open and blocked, so until it is pushed the reviewer keeps looking at the version it correctly rejected.
Your standing rule is that I never push without you saying so, because every push triggers a build. That rule did its job — I stopped three times. But the work is done and sitting on this machine, and one of the three (the TTL guard) is a fix to an already-open PR whose reviewer is still reading the version it rejected. That one cannot progress at all without a push. Pushing all three is three builds. Pushing only the blocked one is one.
I finished three pieces of work and they were all sitting on this laptop, not on GitHub, because the old rule said wait for you to say “push”. One of them is a fix to a review that’s already open — so until it’s pushed, the reviewer keeps reading the version it already said no to. Pushing all three means three builds; pushing just the stuck one means one.
Against the live endpoint the default view returns 25 accounts and relaxing the filter returns 84 — exactly the 59 you could not reach before. So it does the thing. What I have not done is look at it: this is a visual change and your rule is a preview plus a screenshot before merge. I can only produce those after a push.
The filter works — I checked it against real data and it finds the 59 people who were invisible before. But nobody has actually looked at the page. It changes what you see on screen, and your rule is that someone eyeballs a screenshot before it goes live. I can only take that screenshot after it’s pushed.
The collections page now says “N accounts can’t be aged, so a days filter can’t include them” — so relaxing a filter never hides a group silently. Every query I ran returned zero for it, because every past-due account at that property currently has aging data. The logic behind it is tested; the counter itself has never been non-zero outside my head. I would rather tell you that than let it read as verified.
The page can now tell you “some accounts are missing from this filter, and here’s how many”. Every time I tested it, that number came out zero — not because it’s broken, but because every overdue account right now happens to have the date info it needs. So the message has never actually appeared on screen. It might read badly the first time it does, in front of someone using it for real.
You said do the full pass but inventory first. The inventory exists: one group of ~236 lines carries no rules and no incident history at all — the safest thing to move. Everything past that gets into sections where the lines were written after long debugging sessions, and moving those is a judgment call I do not want to make alone. Nothing has moved since; this is the same question, still open.
CLAUDE.md is the instructions file every session reads before it starts working. It’s long, so it costs time and money on every single session. About 236 lines of it are pure reference — no rules, no hard-won lessons — and those are safe to move somewhere else and link to. Past that, the lines start being things people learned the hard way, and moving those is a judgement call I’d rather not make alone.
Pick an option above and your answers will appear here, ready to copy.