You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Escalated from #70 per triage's clause on that card: "⛔ The why.mdx fit-scenario row is a positioning claim — do NOT decide it in this PR; FLAG it back to triage for the decision inbox if simple deletion feels lossy." It does feel lossy. This is the flag.
What was removed, and why it could not simply be corrected
content/docs/why.mdx carried this row in "Common scenarios where it's a fit":
| Multi-tenant internal portal (one runtime, many small apps) | Per-project kernel + LRU cache designed for this |
Both cells are dead, but for different reasons, and that is the whole problem:
The right cell names a mechanism that does not exist for a self-hosted deployment. architecture.mdx now says a deployment serves one app and that "there is no cache sizing to get right"; on objectstack@origin/main, multi-kernel routing engages only when the host registers a KernelResolver, whose "strategy lives in the cloud distribution" (packages/runtime/src/http-dispatcher.ts). That half is a factual defect and PR docs: retire the multi-Environment runtime model from six pages outside Deploy #86 removed the row on those grounds.
The left cell is a positioning claim, and the scenario it names did not die with the mechanism. A walled multi-organization deployment is real, shipped and licensed: OS_TENANCY_POSTURE with the values isolated and group puts up a per-organization isolation wall, and reference/environment-variables.mdx documents the two further decisions it forces.
So the honest state is "the fit may well survive under a different mechanism", and writing that down means deciding how the product is sold — which is the decision this card asks for, not something a docs PR should transcribe.
The decision
Which of these is true of ObjectOS today?
A. The scenario is still a fit, under the walled tenancy posture. Restore a row along the lines of "Multi-tenant internal portal (several organizations, one deployment) — walled tenancy posture, per-organization isolation enforced in the runtime". Requires a product answer to a question the docs cannot settle: this is a licensed capability appearing on the page that pitches the open-source-runtime story, and the row would sit next to five rows that need no licence. Also note what it does not buy — the organizations share one database and one metadata set, so a customer expecting schema isolation is still disappointed, just later.
B. The scenario changed shape and should be re-worded, not restored. "One runtime, many small apps" is exactly what architecture.mdx now rules out; the surviving shape is one app, many organizations. If the portal being pitched was really "many small apps", the fit genuinely is gone and the row should stay deleted — but the page should probably say so somewhere rather than going quiet, since the pitch previously made this promise.
C. Leave it deleted, silently. Cheapest. Costs a stated fit for a capability the product does sell, on the page whose entire job is telling a reader whether ObjectOS suits them.
Recommendation
A, with the licensing caveat stated in the row itself. The capability exists, is sold, and this page's stated purpose is "the honest pitch — when you should use it, when you shouldn't". Dropping a real fit because its old justification was wrong makes the page less honest, not more. But the row must not repeat the original's mistake of naming a mechanism as if it were free: whatever it says should make the licence and the shared-database limit visible, so a reader who picks ObjectOS for this reason is not surprised twice.
That said — this is a positioning judgement about how a commercial capability appears on the pitch page, and the recommendation above is a docs-side reading of the evidence, not a product decision. Needs the maintainer.
Blocked-by: nothing. PR #86 is safe to merge first; restoring a row afterwards is a one-line change.
Escalated from #70 per triage's clause on that card: "⛔ The
why.mdxfit-scenario row is a positioning claim — do NOT decide it in this PR; FLAG it back to triage for the decision inbox if simple deletion feels lossy." It does feel lossy. This is the flag.What was removed, and why it could not simply be corrected
content/docs/why.mdxcarried this row in "Common scenarios where it's a fit":| Multi-tenant internal portal (one runtime, many small apps) | Per-project kernel + LRU cache designed for this |
Both cells are dead, but for different reasons, and that is the whole problem:
architecture.mdxnow says a deployment serves one app and that "there is no cache sizing to get right"; onobjectstack@origin/main, multi-kernel routing engages only when the host registers aKernelResolver, whose "strategy lives in the cloud distribution" (packages/runtime/src/http-dispatcher.ts). That half is a factual defect and PR docs: retire the multi-Environment runtime model from six pages outside Deploy #86 removed the row on those grounds.OS_TENANCY_POSTUREwith the valuesisolatedandgroupputs up a per-organization isolation wall, andreference/environment-variables.mdxdocuments the two further decisions it forces.So the honest state is "the fit may well survive under a different mechanism", and writing that down means deciding how the product is sold — which is the decision this card asks for, not something a docs PR should transcribe.
The decision
Which of these is true of ObjectOS today?
A. The scenario is still a fit, under the walled tenancy posture. Restore a row along the lines of "Multi-tenant internal portal (several organizations, one deployment) — walled tenancy posture, per-organization isolation enforced in the runtime". Requires a product answer to a question the docs cannot settle: this is a licensed capability appearing on the page that pitches the open-source-runtime story, and the row would sit next to five rows that need no licence. Also note what it does not buy — the organizations share one database and one metadata set, so a customer expecting schema isolation is still disappointed, just later.
B. The scenario changed shape and should be re-worded, not restored. "One runtime, many small apps" is exactly what
architecture.mdxnow rules out; the surviving shape is one app, many organizations. If the portal being pitched was really "many small apps", the fit genuinely is gone and the row should stay deleted — but the page should probably say so somewhere rather than going quiet, since the pitch previously made this promise.C. Leave it deleted, silently. Cheapest. Costs a stated fit for a capability the product does sell, on the page whose entire job is telling a reader whether ObjectOS suits them.
Recommendation
A, with the licensing caveat stated in the row itself. The capability exists, is sold, and this page's stated purpose is "the honest pitch — when you should use it, when you shouldn't". Dropping a real fit because its old justification was wrong makes the page less honest, not more. But the row must not repeat the original's mistake of naming a mechanism as if it were free: whatever it says should make the licence and the shared-database limit visible, so a reader who picks ObjectOS for this reason is not surprised twice.
That said — this is a positioning judgement about how a commercial capability appears on the pitch page, and the recommendation above is a docs-side reading of the evidence, not a product decision. Needs the maintainer.
Blocked-by: nothing. PR #86 is safe to merge first; restoring a row afterwards is a one-line change.
Related: #70, #82.
Generated by Claude Code