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.
1settings-resolver.ts::resolveObserverBccForProperty (PR #9001, merged 9bcffb.., unused/dead code — nothing calls it yet, staged for PR 3/4) does 'propSettings?.observerBcc ?? org?.settings?.observerBcc' — a direct property-then-org fallback inside settings-resolver.ts. This is the exact shape the E19-b assertion's code comment calls out as previously wrong: #8369 did the same thing for tour-length settings, tripped this same DRIFTED verdict, and was reverted same-day by #8371 ('wrong behavior and ahead of the settings refactor'). The migration-proof harness (scripts/portfolio-harness/migration-proof) is red on main because E19-b's committed baseline (0 hits on 'organizationId' in settings-resolver.ts, 2026-09-15) no longer matches reality (3 hits, 2026-09-17) — this is DRIFTED, not ERROR, meaning the harness is working as designed and flagging real architecture movement. Two paths: (A) re-grade E19-b's committed baseline to accept the new hits, on the reasoning that PR #9001's code is currently dead (nothing calls it yet) so it's inert until PR 3/4 wires it in, and re-grade again then; (B) treat this as the same anti-pattern as #8369 and ask the settings-refactor owner to rework it to go through the sanctioned ladder-step-2 mechanism (HOW §3.2 attachment rows + §4.4 walk) before PR 3/4 wires it up. I don't have the standing to grade which one is architecturally correct — that's the portfolio-architecture migration owner's call.
In plain terms. Should a new email-BCC setting stay as-built, or get reworked before it goes live? It uses a shortcut for reading company-wide settings that we already reverted once for being ahead of the redesign — a self-check test caught it happening again.
The session raising this recommends: Have it reworked before it goes live The exact same shortcut was reverted a week ago on a different setting for being ahead of the redesign — accepting it now just because it's unused today risks the same mistake going live once the next PR wires it up. Tried first, unsuccessfully: Read the failing CI run, the harness's own README (a DRIFTED verdict means real product movement or a rotted assertion), the assertion's code comment (which documents the exact prior revert), and the actual new code. Confirmed no existing decision-page block already covers this.