Six pages outside Deploy still describe the retired multi-Environment runtime

[os-zhuang]

Found while rewriting architecture.mdx (#64 / #69). Filed rather than fixed — #64's surface was that one page, and each of these needs a different call than a search-and-replace.

What is there

The hosted, many-Environments-per-process model that #64 removed from architecture.mdx is still the model six other English pages teach. Measured on a132376.

File	Line	What it says
content/docs/resources/faq.mdx	44	"One ObjectOS process can serve many Environments (tenants). Hostname → Environment resolution caches in an LRU; each Environment has its own database, identity, and audit log."
content/docs/resources/glossary.mdx	110	Kernel "serves a single Environment's metadata. One process can hold many cached kernels (one per Environment) in an LRU."
content/docs/why.mdx	45	Fit-scenario row: "Multi-tenant internal portal (one runtime, many small apps) — Per-project kernel + LRU cache designed for this"
content/docs/operate/observability.mdx	40, 77-80	Artifact/kernel cache misses signal; a Prometheus alert on kernel_cache_misses_total whose remedy is "consider raising OS_KERNEL_CACHE_SIZE"
content/docs/operate/troubleshooting.mdx	67	"the project kernel has auth enabled"
content/docs/build/ai-builder.mdx	139	"The kernel cache invalidates the touched package"

Why it is worth recording

The first row is a live contradiction with a shipped page, not just stale framing. reference/environment-variables gives a deployment one OS_DATABASE_URL, and states that metadata "is scoped to the deployment, not to an organization" — which is precisely why a walled deployment must decide OS_AI_STUDIO_AGENTS, because "on a shared database one customer's build turn rewrites the schema every other customer runs on". A reader who believes the FAQ expects per-tenant database isolation they will not get.

The observability row is a second, smaller instance of the #60 defect class: OS_KERNEL_CACHE_SIZE appears nowhere in the environment contract — not in the live tables, not in Retired names, not in Legacy names. It is the only place in the English docs that still names it. #63 swept the retired env contract outside Deploy and this line was not caught, presumably because it reads as an alert annotation rather than as configuration.

Why this is not three lines of sed

Each row needs a different decision, which is why it is a card and not a rider:

• why.mdx is a positioning claim — "designed for this". Deleting the row removes a stated fit; keeping it needs a product answer about what a multi-tenant internal portal is sold as now. Someone has to decide, not transcribe.
• observability.mdx needs to know whether kernel_cache_misses_total is still a metric the runtime emits at all. If it is not, the alert is worse than stale.
• faq.mdx and glossary.mdx are load-bearing definitions; the FAQ answer also promises per-Environment identity and audit isolation.
• ai-builder.mdx and troubleshooting.mdx are probably wording only.

Note for whoever picks this up

⛔ The same constraint as #64 applies to any figures encountered along the way: this repository is not the authority for runtime measurements, and describing the shape without numbers is the correct outcome, not a partial one.

Adjacent, same pages, decide whether to fold in or split: faq.mdx line 145 tells the reader to point a monitor at /health, while deploy/docker.mdx and deploy/kubernetes.mdx name /api/v1/health for liveness and /api/v1/ready for readiness.

Related: #64, #63, #60.

---

Generated by Claude Code

[os-support-ai]

Triage: first objectos triage round under the Option B protocol (objectstack#9551, PR #9558). Lands in pm:queue, type Task. Scope note for the claimant, honouring the card's own row-by-row analysis: the faq.mdx / glossary.mdx / troubleshooting.mdx / ai-builder.mdx rows are truth-restoration against the shipped single-deployment contract (reference/environment-variables is the authority the card itself cites) — dispatchable as written. The observability.mdx row requires answering "who produces kernel_cache_misses_total today?" against the objectstack runtime source before rewriting; if the metric is gone, the alert block goes with it. ⛔ 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. The /health vs /api/v1/health adjacency may fold in as a mechanical correction. Executes in the domain:devx lane. (Triage seat, session session_01EUZUjvnLsqwHVkXkTv8TKQ.)

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 5
Session: session_01CJPxtTxoxTUnjNdTbiEaRa
Branch: claude/issue-70-retire-multi-environment-model
Worktree: objectos-issue-70
Domain: domain:devx — objectstack-ai/objectstack#9551 closed as Option B, folding objectos into the protocol as the fourth triaged repository with execution routed to the devx lane. Dispatch authorized by the maintainer, 原话: 「objectos 任务很多，你可以派发了」.
File surface: content/docs/resources/faq.mdx, content/docs/resources/glossary.mdx, content/docs/why.mdx, content/docs/operate/observability.mdx, content/docs/operate/troubleshooting.mdx, content/docs/build/ai-builder.mdx (English only; stop on breach)
Container & model: M, mode:subagent, model: opus
Clause-②: no
Serial constraints cleared: batch siblings #71 (architecture.mdx, deploy/index.mdx) and #81 (turbo.json) — disjoint. #80 is deliberately NOT in this batch: it edits resources/glossary.mdx, which is in this card's surface. #72 is not in this batch either: os-support-ai has PR #77 in flight against .github/workflows/ci.yml, and #72 would touch the same file — yielding to the other seat rather than racing it.

Premise re-verified on origin/main (d7f1ca5), not on the ref the card was measured against

The card was measured on a132376; #69 and #82 have landed since and both touched pages on this list. All four load-bearing claims still hold, with line numbers moved:

Claim	Then	Now
faq.mdx — "each Environment has its own database"	44	50
glossary.mdx — "One process can hold many cached kernels (one per Environment)"	110	112
why.mdx — "Multi-tenant internal portal … Per-project kernel + LRU cache designed for this"	45	45
observability.mdx — alert remedy "consider raising OS_KERNEL_CACHE_SIZE"	80	80

⛔ Use the current numbers, and re-read them in your worktree rather than trusting this table.

Note that #82 already rewrote architecture.mdx's runtime model and added a fail-closed section to glossary.mdx, so the surviving multi-Environment prose on these six pages is now inconsistent with pages that landed today — which raises this from stale framing to a live contradiction inside one docs set.

---

Generated by Claude Code