carlos / platform Public

Summary. Schedule docs/superpowers/specs/2026-09-02-scan-on-demand-design.md: draft 7, "final, cleared to plan from". Its §1 states the gap exactly: the shipped scanner answers "is this bucket clean?" on a sweep, not "is this object clean, now?", which is the question an app has when someone has just uploaded a file it is about to serve.

Who is asking:

• rastrillo's upload flow (rastrillo#59): staged key, then verify, then promote. The promote step is where an app wants a verdict before it publishes the object, or shows it to anyone other than the uploader.
• Without a per-object door, an app has three options, and none is good: - publish unscanned and let the sweep catch up; - poll the object's tags on a sweep's schedule; - read the carlos-scan tags itself. It cannot verify their HMAC, since the key is console-only (internal/objstore/scantag.go), so it would trust a tag that an upload could have attempted to set.
• Tito Go proxies uploads today. It would move to direct uploads with the rest once bucket CORS exists (filed alongside this).

What the spec already provides, as far as an app needs it:

• A priority scan door.
• A long-polling status door that returns a verdict the app can trust without the tag key.
• An opt-in signed webhook.

The honest claim in §1.1 ("scanned at T against <engine>/<db> and found clean", plus the count of unscanned objects) is the wording rastrillo would surface.

One ask beyond the spec. Please confirm how an app, as opposed to a member or operator, reaches the status door. The spec's svcrole.Service is the authority it names, and rastrillo would call it with whatever credential an instance holds.