Everything here is code-complete or blocked on a decision rather than a review round. Question 1 is the only one where a real prospect was already told something untrue — it is first for that reason, not because it is the biggest.
Since the last page: the message-routing bugs are fixed and merged, the link guard is on main, and the voice ledger (#5298) is approved and mergeable — it records every outbound call and arms nothing (verified at its head: 0 enforcement calls, 9 recording calls).
Correction — 2026-08-03 08:45 UTC. This page was written last night and several of the things it asks about have since finished. Nothing above has been rewritten, so you can see what changed; the paragraph directly above is itself now out of date, because #5298 is no longer “approved and mergeable” — it is merged.
Merged since this page was written: #5321 (the Saturday tour fix, merged 07:28 today), #5298, #5013, #5309, #5164, #5281.
Closed as superseded, each with evidence on main: #4264, #4826, #4969. #5260 is an issue, not a pull request, and is still open.
The practical consequence: any option below that offers to land one of those is now a no-op — in particular the option “Land #5309 as-is with #5317 as the follow-up”, because #5309 is already in. Question 1 also reads differently now: #5321 merged, so the code that asks each property which days it takes tours is live — but it is inert, because 0 of 17 properties have a policy row. The remaining decision there is whether to write Camellia’s row, which is a change to production data, not a merge.
Twelve of the nineteen pull requests referenced on this page are still open, so the page is worth a pass — it is stale, not dead.
Second correction — 10:47 UTC, and this one changes an option rather than a fact. Question 4 offers “All three, chokepoint first” for #5317, #4837 and #5033. #5033 should be closed, not landed. It repairs an alerts guard in .github/workflows/llm-runner-health.yml — and that workflow no longer exists: it was deleted from main by 5007d2339, the revert of #4987 (via #5015). Merging #5033 would bring back a file the team deliberately reverted away. So the honest shape of that question is now two guards to land and one to close, and “all three” is not a choice anyone should pick as written.
It is worth saying why this was easy to miss: #5033 is the only conflicted pull request in the batch carrying a formal approval against its exact current commit, so every quick signal reads healthy. Its one salvageable piece is the test it adds, which does not depend on the deleted workflow.
On Saturday 2026-08-01 at 1:36 PM a prospect called Camellia and Clara offered “las dos cuarenta y cinco, las tres…” — slots on a day the property does not take tours. The fix adds a per-property bookability policy and an honest decline. The judgement is not whether to fix it; it is what the default should be for a property that has not configured anything, because that default silently governs every property until someone sets one.
Someone rang up on a Saturday and Clara confidently offered them appointment times that were never available. The fix lets each property say which days it actually takes tours. The question is what happens for properties nobody has configured yet.
Unchanged from the last page and still draft on purpose — auto-merge had been armed on it, so a green re-review would have shipped it. Two live defects remain: a rate-capped resident is filed as “Opted out of texts (replied STOP)”, and a renewal letter reports sent with the PDF undelivered. A session is fixing both now with tests that are red on today’s code. One thing it raised and correctly refused to decide: a building-wide blast is currently capped too, so a resident at their limit could silently miss a water-shutoff notice.
This is the change that would actually stop the system contacting someone past their limit. It is deliberately parked because two bugs would make a resident's record say something untrue. A new question surfaced: should an emergency notice to the whole building be exempt from the limit?
Your words on the issue: “We don’t really use telegram anymore, so should we just kind of axe that entire funnel so it doesn’t confuse us down the line?” The answer was yes and the work exists: 51 files, −5,876 / +180. It is now conflicting with main and has sat long enough to drift. Also relevant: Telegram is one of the two uncapped outbound channels — removing the funnel closes that gap by deletion rather than by guarding it.
You said to delete the Telegram integration so it stops confusing things. That work is written — about 5,900 lines removed — but it has gone stale and now clashes with other changes. The longer it waits the worse that gets.
#5317 is the follow-up that landing #5309 was conditional on: one chokepoint for who may write the required Unit Tests check, after the same failure class — a required check green over a red guard — appeared three times in one PR. #4837 ships ADR-0123 plus a reconciler, and its author found the reconciler was dead on current main (exit 2) because six newer jobs lacked the field it introduces — fixed by verifying each against the live surface rather than deriving. #5033 repairs an alerts guard that went red on main. All three are the same theme: a check that cannot fail is not a check.
Three separate safety checks in the build system, each of which could quietly pass while the thing it guards was broken. One of them was literally unable to run at all and nobody noticed.
#5229 is a session correcting its own shipped memo: “My memo (#5164) is wrong about residual 1’s mechanism, and wrong in the direction that made my own recommendation look cheap.” It is documentation, it is conflicting with main, and it is titled [HANDOFF — needs a human]. #5236 retires the concession-watcher Lambda. ⚠️ Its central premise is false against live AWS, and three review rounds missed it because they read the diff. The PR asserts the EventBridge rule “was disabled”. I verified directly: propflow-concession-watcher-prod-schedule is State=ENABLED, cron(0 13 * * ? *), right now, and nothing in the diff disables it. Two consequences follow: it reverts the Vercel cron to 0 13 — the same minute, re-creating the double-Browserbase-scrape collision the :30 offset existed to prevent (per the PR’s own deleted instructions); and deleting that manifest entry while the rule still runs makes #4837’s new reconciler report [unregistered] and turn main red. The session posted the aws commands and three fix options, and deliberately did not disable the rule itself — a prod mutation, and the retirement ladder puts CloudTrail two rungs earlier. Auto-merge is null and CHANGES_REQUESTED blocks it, so there is no accidental-merge risk while you decide.
One is an agent publicly correcting a document it wrote, in the direction that makes its own earlier advice look worse. The other stopped after three rounds of review because it noticed its fixes were causing the next problem, and asked for a person instead of trying again.
#5309 moves the expensive test lane onto the reviewer’s verdict. Its owner reports the same failure class three times in one PR and asks: land as-is, or refactor to one chokepoint first? Their lean is land, with #5317 as the chokepoint follow-up. #5260’s guard merged as #5281, but its points 1–4 — the permanent occupancy and rent series — were never started. Today made that concrete: the money cards read a table that only goes back to 2026-02-28 while the permanent rows hold 98 months to 2018-05.
Two leftovers. One is a build-system change whose author found the same kind of bug three times while writing it and wants to know whether to tidy first or ship. The other is dashboard history that was planned, half-built, and then dropped.
These are finished-or-nearly-finished changes that no session is driving and no human has claimed. I could not determine an owner for any of them — two separate methods failed (branch-name-in-transcript, and matching a session’s working directory), and every commit is authored by the shared account, so “who owns this” is genuinely unanswerable from here.
Eight pieces of work are sitting finished on GitHub with nobody looking after them. The oldest has been waiting a month. They are not failing — they are just unattended, and every day they drift further from the code they were written against.
The eight, triaged — so this is a real choice rather than a shrug. “Still applies” means I checked today’s main, not the PR’s own description.
[DO NOT MERGE until cut day] and its body says merging “auto-deploys the 3 Temporal-env Lambdas and repoints the worker/harness workflows, which IS a production cutover action”, gated on ADR-0045 cut-day runbook Step 2. The 29 days are BY DESIGN. Still applies (80 files on main still carry the old reference), and it should stay open until the cutover. (I listed this as orphaned backlog. It is the opposite — and “close the stale ones” would have closed a staged production cutover.)arm-or-disarm run from 07-29 reading as a failure; I re-ran it and it passes. Genuinely conflicting though, so a rebase is its real blocker.cancel_tour’s no_upcoming as not-a-failure. Small (+45). Conflicting.arm-or-disarm, the auto-merge orchestration job, whose run had been cancelled (not failed) on 07-29 and never re-evaluated; a cancelled run reads as a failure in the checks list. I re-ran it: passes, and the PR is mergeable=true / clean. ⚠️ But it is a handoff doc listing three tooltip tasks for a successor, and task 1 is now obsolete: it asks to shorten the “class” tooltips, and EvalClass was deleted from types.ts by #4892 on 07-30. Tasks 2 and 3 still stand (EvalCadence and describeSafety both survive). So landing it as-is hands someone a list whose first item cannot be done. Cheap either way — land it with a note, or amend that line first.The corrected cost picture, after clearing two phantom failures and reading the holds:
main that moved. ⚠️ I first wrote “zero failing checks” here and that was a bad reading. A conflicting PR cannot have its merge ref built, so GitHub stops creating workflow runs — the check state freezes at whenever it last merged cleanly. #4851 and #4969 now carry NO real CI at all: one Vercel preview and one skipped gate, against #4826’s eight passing jobs. No type check, no tests, no lint. So their green is an absence, not a pass, and nobody knows whether they work until they are rebased. #4705 (65 files) and #4264/#4969 (4 and 3 files) differ hugely in rebase cost.What I checked, and where I stopped. “Still applies” was verified against today’s main for #3087 (80 files still carry the old reference), #4705 (main still reads “FAST_MODEL … always the latest Haiku”) and #4826 (one of its three tasks references a deleted type). For #4264 and #4851 I could confirm the surfaces still exist but not whether the defect persists — that needs reading the computation rather than grepping for a symbol, and doing it for five conflicting PRs is the work option 2 on this question authorises. I would rather say “not determined” than give you a confident guess: this page already carries six corrections where a cheap signal read as an answer.
⚠️ I originally wrote “seven of eight are conflicting” and left it there. That was true and useless: it lumped a PR needing one click, five needing a rebase, one needing design work, and one that must not be touched into a single number.
⚠️ And the reason it matters twice over: a conflicting PR gets no CI runs at all, silently. That is the same mechanism that had another PR burn four trigger attempts today convinced GitHub was broken. So for the five above, “no failing checks” is not reassurance — it is the absence of a measurement.
⚠️ “Not conflicting” is not the same as “nearly done”, and I got that wrong once already on this page. #4970 merges cleanly and still does not work; #4826 merges cleanly and is only held by a stale orchestration run. Mergeability describes the tree, never the feature.
.github/reviewer-core.md links ADR-0071 with a path that resolves to nothing from where the file sits, so a reviewer citing the PM-English standard hits a 404 at the moment of citing it. The change is ./docs/ → ../docs/. It needs you because that file defines how every review in this repo happens, and the merge guard held it on exactly that basis. I split it out of the link-guard PR rather than let one line put that whole change on your queue.
A single broken link, but it is in the document that tells the code reviewer how to review. The system deliberately refuses to let a robot merge changes to that file, which is why it is here rather than already done.
Pick an option above and your answers will appear here, ready to copy.