OSL · owner review

Decisions waiting on you

The decisions you asked to see here rather than in chat, each reduced to the smallest honest question with the working shown. Two you asked for, plus two screens that turned out to have no design at all.

1 · The pack ladder

The question you were originally asked could not be answered. TASK 7794 says “approve 7788’s measured profitable pack ladder as written” — but 7788 produced an unpriced ladder on purpose. Its artifact records three capacity names, real Cloudflare R2 cost inputs, a price-floor formula, approved_prices: 0, and the note “No product price… is encoded by task 7788.” There was never a ladder to approve. Here is the missing half, computed from measured inputs.

Pack	Size	Msgs/day	Infra cost	Card fee	Floor	Proposed	You keep	Margin
Starter	5 GB	200	$0.11	$0.39	$0.70	$2.99	$2.50	84%
Standard	50 GB	500	$0.83	$0.47	$2.86	$5.99	$4.68	78%
Archive-capacity	150 GB	500	$2.33	$0.65	$7.32	$11.99	$9.01	75%

Infra cost is R2 storage at $0.015/GB-month plus the per-message operation costs measured in decision 0575; R2 charges no egress, which is the reason this works at all. The floor is 0575’s own rule — infrastructure may not exceed 35% of what a tier earns — with the card fee (2.9% + $0.30) on top. All three clear it.

The thing worth noticing: on Starter the card processor takes $0.39 while the infrastructure costs $0.11 — the rail is about four times the compute. A cheaper bottom tier loses money to Stripe, not to serving the customer. That, not storage, is what sets the floor price.

What I need: yes to all three prices, or name the one number to change. The sizes and the prices are proposals; the floors are arithmetic.

2 · The ship-or-not list

TASK 4402 asks you to read a disposition list and answer per item. As written that is 851 rows. It is one decision.

Classification	Rows
Stays a test tool	796
Neither	1
Ships	54
Distinct switches behind those 54 rows	1

All 54 shipping rows are the same switch, discord-qa-shell, appearing at 54 code sites across the Discord adapter, the overlay, the broker and the UI. It is a build feature that reaches the screen: Cargo feature discord-qa-shell → Vite define VITE_OSL_DISCORD_QA_SHELL → screen.

Does it currently ship? No — checked on both halves, not assumed.

Native. apps/osl-hub/Cargo.toml declares discord-qa-shell = [] and the default set is ["core", "whatsapp-qa-shell", "native-cover-writer"]. It is not in it. (whatsapp-qa-shell is, deliberately — that one is the shipped WhatsApp protected surface which kept a historical name, not a QA identity.)
Renderer. vite.config.ts sets the define to "1" only when mode === "discord-qa", and "0" in every other mode.

So “classified SHIPS” means the switch’s code reaches the reader path in source — not that it is present in a release binary. It is off in both places today.

What I need: confirm the rule that keeps it that way — discord-qa-shell never goes in the Cargo default feature set, and no release is ever built with --mode discord-qa. Recommended yes: it is already true, and saying so turns a property that happens to hold into one a check can enforce. The other 797 rows need nothing from you.

3 · Two screens with no design at all

These are not parity defects. The design package has nothing for them, so there is no target to match and no agent can fix them. Both need a decision from you.

033 — Settings → Window and sounds

The rendered Settings.dc.html has exactly eight sections: Account, Apps, Privacy, Security, Whitelist, Notifications, Appearance, About. Window & Sounds is not one of them. The app ships the section anyway.

Correction worth stating plainly: I earlier told you this screen was covered, because the word “window” appears 16 times in the file. Rendered, those are markup, not a section. I searched the text instead of looking at the page — the same mistake that produced the wrong settings answer in the first place.

What I need: does Window & Sounds ship? If yes it needs a design and there is nothing to compare it against until you make one. If no, the app should lose the section.

Security — a section the design has and the app does not

The reverse case. Settings.dc.html has a Security section. The app has no screen for it, and no task in the plan builds one.

This is the failure mode nothing catches on its own: there is no task to tick, so no report ever says it is missing. It surfaced only because every screen’s reference was re-checked against the rendered design.

What I need: does Security ship? If yes I will write the tasks for it; if no, it should come out of the design package so it stops looking like a gap.

Already answered, recorded as ruling D44

The eight performance limits (four measured, four provisional and labelled as such), delete-at-expiry for relay bytes with the sender warned first, and the second Signal / Instagram / Messenger / iCloud identities deferred at your request — deferred, not refused, and no lane may substitute a shared account for them.