Phase 1.1 done, and it was not the task that was written down

An object-store provision, proven against a real store with seven
assertions.

The finding is worth more than the task: the control plane
special-cases nothing. provides, requires, contributes and grants are
name-agnostic, so asking for a bucket needed no change to the mesh at
all. What was missing was a provider and the last step on the machine —
"add an object-store provision" was never mesh work, and the breakdown
now says so rather than leaving the next person to rediscover it.

Named s3-bucket by 0027: the coupling is to the API, not the product,
because swapping one store for another does not break a consumer. A
database is the other case and names its engine.

Records the assertion a database does not need, because it is the one
that will be forgotten when somebody writes the next provider: one store
holds every bucket behind one endpoint, so isolation is a policy rather
than a property, and a policy granting everything passes every test that
only checks a consumer can reach its own bucket.

03-DESIGN/01-to-be/00-work-breakdown.md

@@ -57,16 +57,36 @@ Found by taking real modules and asking what they would require. Each is a gap i
 
 | # | task | done when |
 |---|---|---|
-| 1.1 | An **object-store provision** — a module can ask for a bucket ([ADR 0028](../../02-DECISIONS/0028-the-substrate-supplies-the-control-plane-and-nothing-else.md)) | a module requiring it is refused where nothing provides it, and given credentials where something does |
+| ~~1.1~~ | ~~An **object-store provision**~~ — **done 2026-08-31**, and it needed no change to the mesh: see below | seven assertions against a real store |
 | 1.2 | **A session as a consumer of a licence** | the two sessions on one machine hold different licences and each uses its own ([`14-model-access.md`](14-model-access.md), [ADR 0026](../../02-DECISIONS/0026-the-mesh-has-a-session-of-its-own.md)) |
 | 1.3 | A **network** shape, and ordering within a module | a module of several containers reaches itself, and one that must start after another does |
 | 1.4 | **Public certificate issuance** | a name reachable from outside is served with a certificate from a public authority, obtained against a **staging** endpoint unless told otherwise ([`04-ISSUES/004`](../../04-ISSUES/004-certificate-issuance-targets-production/00-report.md)) |
 
-**1.1 blocks the first module; 1.3 and 1.4 block later ones** and are listed now so they are not
-met as surprises. 1.3 is what a mail system needs and nothing else so far does.
+**1.3 and 1.4 block later ones** and are listed now so they are not met as surprises. 1.3 is what
+a mail system needs and nothing else so far does.
 
 **Checkpoint:** each is demonstrated in the lab before the module needing it is attempted.
 
+### 1.1, and what it turned out to be
+
+*Done 2026-08-31. Worth recording because the task was not the one written down.*
+
+**The control plane special-cases nothing.** `provides`, `requires`, `contributes` and `grants`
+are name-agnostic — asking for a bucket needed no change to the mesh at all. What was missing was
+a provider, and the last step where something on the machine turns a delivered secret into a key
+that works. So "add an object-store provision" was never mesh work.
+
+The provision is `s3-bucket`: a consumer's code is written against the S3 API and swapping one
+store for another does not break it, so by
+[ADR 0027](../../02-DECISIONS/0027-a-provision-names-what-the-consumer-is-coupled-to.md) the name
+says the protocol. A database is the other case, and names the engine.
+
+**One assertion here that a database does not need.** One PostgreSQL server holds separate
+databases and the product enforces the boundary; one object store holds every bucket behind one
+endpoint, so *a consumer cannot reach another consumer's bucket* is a policy somebody wrote — and
+a policy granting everything would pass every other test. **What is asserted is what the policy
+does not say.**
+
 ## Phase 2 — the first real module
 
 | # | task | done when |