Component kinds, and development that mimics production
Three component kinds say how a consumer gets use of a component:
installed— the user's machine runs it. A command on a person's PATH.online-service— something dialled. The api, the gateway, the identity server, the store.web-assets— a page's bytes, served from a CDN in production.
Each kind has a released deploy mode and a dev-loop mechanism, selected by a dev-loop flag on the deploy config — two declared facts and no third.
The one rule about how development differs
Divergence must be visible in the binding profile.
Where development genuinely differs, the difference is declared. The pattern this rules out is the common one: a stub workload claiming the cluster's serving point and its identity while the real process runs on a developer's machine. That state cannot be named, so everything built on it needs compensating machinery — stub lifecycle, session binding, health checks for "pod running, process dead." Under a service mesh it stops being cosmetic, because the policy authenticates the stub while an unverified process answers.
What this rules out is the pattern most platforms ship: a stub pod claiming the
Kubernetes serving point and the service-account identity while the real process runs on
the host behind an intercept. That is a state the model cannot name — the environment
said k8s and reality was a process on the host — and everything built on it needs
compensating machinery: stub lifecycle, host-session binding, health checks for "pod
Running, process dead." Under a service mesh it graduates from cosmetic to broken, as
mTLS and L4 policy authenticate the stub's identity while an unverified process answers.
The honest answers are first-class instead.
| Cell | Mechanism | What it costs |
|---|---|---|
online-service, flag off |
Real pod, real mesh identity, peers reach it exactly as in production | Inner-loop latency. Parity is a deploy config. |
online-service, flag on |
hot-reload-k3d-mirrord — workload in a local k3d cluster, process on the host, intercepted |
Declared as that, and never claiming to be k8s |
installed, flag on |
hot-reload-install — instant reload |
Links resolve to published ports rather than the production front, so the hop differs by exactly that |
web-assets, flag on |
Dev server in development, cdn in production |
Local TLS trust — see §9 |
In the intercepted cell, three things keep the component honestly in the cluster: peers dial the ordinary Service and the intercept delivers to the host process; the component's own connections leave through the pod's network namespace; and its projection directory resolves from the pod, so the coordinates it reads are the cluster's. What is not in the cluster is the source and the build cache — which is the point. The mechanism also never reports the pod's readiness as the component's, which is the direct cure for "pod Running, process dead."
Why this is a reliability argument, not a convenience one
A page's calls in the dev loop traverse the same ingress, the same router and the same policy as in production. A published port would dial the workload directly and route around all three.
So the Phantom Token exchange is exercised on a laptop, not only in production. A phantom-token exchange tested nowhere but production is exactly the dev-works-production-fails class this design refuses elsewhere by construction — and here it is refused by a rendering rather than by a rule.