Skip to content

fix(standards): the datastore claim asserts a path that is not wired - #83

Merged
stxkxs merged 1 commit into
mainfrom
fix/the-datastore-claim-overstates-what-is-wired
Aug 5, 2026
Merged

fix(standards): the datastore claim asserts a path that is not wired#83
stxkxs merged 1 commit into
mainfrom
fix/the-datastore-claim-overstates-what-is-wired

Conversation

@stxkxs

@stxkxs stxkxs commented Aug 5, 2026

Copy link
Copy Markdown
Member

PLATFORM_TENANT_CONTRACT stated as present-tense fact that the tenant-substrate module provisions a Platform CR's declared datastores.

The module does provision them, and the operator does generate the scoped IAM. What does not exist is the step that carries a Platform CR's spec.datastores into that module's var.tenants input — and that map is {} in development, staging and production.

Verified against landing-zone main rather than taken from a plan: all three live leaves declare tenants = {}, and no renderer exists anywhere in the repo. (scripts/e2e.sh matches on the word "tenants" but deals with the tenants GitOps repo, not this input.)

Why this one matters most in fab

FACTORY_PREAMBLE puts this in front of every agent session fab runs. The factory was instructing every agent to declare datastores on the strength of a claim false in all three environments — and an agent could reasonably go on to build an app that assumes its database exists at deploy time.

What changed

The instruction is unchanged and still correct: declare stores in spec.datastores, never hand-write a per-app landing-zone component. What's added is the state — declared is not provisioned yet, so don't build against one.

Deliberately not softened into "may not be provisioned". It is not provisioned, in any environment, today.

Companion changes

The same correction lands in nanohype/standards/platform-tenant-contract.json (which this repo vendors — standards:check will follow the pin) and in the three landing-zone live leaves whose comment claims the map is "rendered from the Platform CRs by the factory".

Building the renderer is the separate, larger piece of work; this stops the factory asserting it already happened.

Verified

typecheck, standards:check, biome, and the full suite — 502 tests across 33 files — all pass.

`PLATFORM_TENANT_CONTRACT` stated as present-tense fact that the tenant-substrate
module provisions a Platform CR's declared datastores. The module does provision
them, and the operator does generate the scoped IAM — but nothing carries a
Platform CR's `spec.datastores` into that module's `var.tenants` input, and that
map is `{}` in development, staging and production. Verified against
landing-zone main: all three live leaves declare `tenants = {}`, and no renderer
exists anywhere.

This is the one that matters most in this repo, because `FACTORY_PREAMBLE` puts
it in front of every agent session fab runs. The factory was instructing every
agent to declare datastores on the strength of a claim false in all three
environments — an agent could reasonably build an app that assumes its database
exists at deploy time.

The instruction is unchanged and still correct: declare stores in
spec.datastores, never hand-write a per-app landing-zone component. What is
added is the state — declared is not provisioned yet, so do not build against
one.

Same correction lands in nanohype/standards/platform-tenant-contract.json, which
this repo vendors, and in the three live leaves whose comment says the map is
"rendered from the Platform CRs by the factory".
@stxkxs
stxkxs merged commit 2549106 into main Aug 5, 2026
11 checks passed
@stxkxs
stxkxs deleted the fix/the-datastore-claim-overstates-what-is-wired branch August 5, 2026 23:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant