Everything I could decide myself is decided. What's left needs
you. Each one carries the recommendation of the session that raised it — if you
agree, pick it and press Done. A model's opinion, where there is one, appears on the card
as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1gera-propflow/local-bin#235 (plan-review part 1: raises the silent slices - PR body 8,000 to 24,000, board row 12,000 to 40,000, ADR 14,000 to 24,000, env-overridable - and prints a visible cut marker; 89 of the last 200 PR bodies exceeded the old cut unannounced) and #237 (part 2: ADR resolution - an ambiguous or cross-repo citation loads NOTHING and says so instead of loading unrelated documents; ADR-0101 matched four files and evicted the real citation; 32 of 32 cases green, six mutations each red, byte-identity control for briefs citing no ADR; driver read the ~70 executable lines). Both DRAFT because local-bin has no hold label - land-on-green squash-merges on bot-green and the checkout is on PATH for every session. Decider receipt f297a87a4: NEEDS HUMAN, both passes - deploying into the live merge gate is a human's risk acceptance; the earlier merge authorisation for the blocked answer-routing fix does not cover these. Verdict encoding unchanged in both. Both edit build_brief around the same lines; whichever lands second needs a main-merge push. NOT included: #236 (decider-stamp truncation) - it has an unfixed join-clip defect posted by the driver and is not ready.
In plain terms. Do you want the two fixes to the plan-checker switched on now? The plan-checker is the tool that reads every change against its plan before a merge. Today it silently cuts long plans short and sometimes reads the wrong rulebook, so it has been grading against fragments and, in a few cases, unrelated documents. Fix one makes any cut visible. Fix two makes it refuse to guess which rulebook was meant. Both are tested and I have read them. The catch: that tool goes live for every helper the instant it merges, with no way to hold it back afterwards.
The session raising this recommends: Switch both on now, the visible-cut fix first Every review until then keeps grading against a cut-off plan; both are tested, read, and change no verdict format FABLE was asked, and escalated. Receipt f297a87a4 — NEEDS HUMAN. ANSWERED BY ASTRA, NOT FABLE — Fable did not answer because it could not be reached.
Gera must authorize deploying these specific changes immediately into the live fleet merge gate. The recorded deployment carve-out reserves that operational risk acceptance for a human; authorization for the separate answer-routing fix does not cover these drafts.
(both passes said so.)
What Fable said when it was asked first: as-given: claude exited 1: stdout: You've hit your weekly limit · resets Sep 20 at 9pm (America/Chicago) stderr: Warning: no stdin data received in 3s, proceeding without it. If pi… Tried first, unsuccessfully: Asked the decider first: receipt f297a87a4, NEEDS HUMAN from both passes because this is a fleet-wide deploy of the merge gate itself, which the carve-out reserves for a person. The sibling fix you already authorised does not cover these two.
1fdb267c is parked on this.
2Measured read-only in propflow-prod 2026-09-19 by a lane: 18 Western Slope properties (org_c42d9150-b9ad-46f8-8f5f-b0fe56bacf38, Grand Junction CO, no isTest) hold ZERO WO# rows since the 2026-09-13 onboarding; 52 ticker'd neighbours healthy (25-sample: 314 WOs). Cause at origin/main: no ticker; run-work-order-sync.ts:145 throws MissingTicker every tick; healMissingTicker (:298) gated by isTickerSelfHealEnabled, fail-closed OFF (ticker-self-heal-flag.ts:88); none of the 18 has a MAINTENANCE_SETTINGS row; Sentry 7722499181 = one group spanning all 18 (13,899 events). THE PRESS: after a dry run, DATA_BACKEND=dynamodb DYNAMODB_TABLE_NAME=propflow-prod npx tsx scripts/set-ticker-self-heal-flag.ts --organization org_c42d9150-b9ad-46f8-8f5f-b0fe56bacf38 --on --apply - writes tickerSelfHealEnabled:true on all 70 MAINTENANCE_SETTINGS rows; only the 18 change behaviour; the writer is FILL-ONLY and never overwrites an existing ticker. WHY GATED: docs/integrations/appfolio.md:314 and scripts/set-ticker-self-heal-flag.ts:28 reserve customer rollout for Fede's explicit call; ticker-self-heal-flag.ts:15-21 requires separate approval because minted identifiers survive rollback. propflowai#9908 (held) separately fixes the lying warning and counts affected buildings per tick; it writes nothing to prod. ADJACENT, not this decision: the work_orders job writes no health/cursor row fleet-wide since 09-12, and the PARKED work_orders schedule is being driven every ~18 min by an unidentified invoker.
In plain terms. Do you want me to switch on the self-heal for Western Slope so their eighteen broken buildings start receiving maintenance work orders again? Eighteen of their seventy buildings have had no work orders reach PropFlow since they were onboarded ten days ago - every repair request there is invisible to us. Each is missing a small permanent code the system needs, and the tool that would mint it ships switched off on purpose, because the code can never be changed once minted. Switching it on for Western Slope mints the code for those eighteen on the next pass and their work orders start flowing; the other fifty-two already have theirs and are unaffected. The repo says this switch is Fede's call.
The session raising this recommends: Switch it on for Western Slope now, after a dry run Every day of waiting is another day those eighteen buildings' repair requests are invisible; the writer only fills a missing code and never changes an existing one Tried first, unsuccessfully: Asked the decider first. Receipt f42a993e0 came back RESOLVED with the answer 'It reaches a human before it is pressed', both passes agreeing, because the repository itself reserves this rollout for Fede's explicit call and minted identifiers cannot be rolled back; it added 'treat it as an urgent incident decision, not an indefinite hold'. This raise IS the act that ruling mandates. Cited as free text because the raise tool refuses a RESOLVED receipt as a citation even when the resolution is to escalate.