Card 03 of the deployment restructure. Maintainer question, 2026-08-15: 「元数据应用又是独立的，如何加载到平台？」
The defect
There are two mechanisms for getting a compiled metadata app onto a running platform. They are documented on two different pages, and neither page mentions the other exists:
| Mechanism | Documented in | Shape |
|---|
| Catalog install | content/docs/deployment/publish-and-preview.mdx (101 lines) | compile → dist/objectstack.json → publish a package version → install into an environment |
| Artifact-pinned boot | content/docs/deployment/self-hosting.mdx, under "Artifact-pinned boot" | OS_ARTIFACT_URL — the runtime fetches the artifact at boot |
A reader who lands on either page has no way to learn the other option exists, let alone which one fits them. There is no page whose subject is "a metadata app is a separate thing from the platform; here is how it gets in."
Scope
Rewrite content/docs/deployment/publish-and-preview.mdx so it is that page. It must:
- Open with the independence — the app is versioned in your catalog, the platform on our release train; they move on separate clocks. This framing is the whole point of the restructure and this is the page that states it for Axis B.
- Name both mechanisms side by side, with a stated rule for choosing. The rule is the deliverable, not the enumeration — a reader who finishes the page unsure which one they want has not been served.
- Keep the existing compile → publish → install → preview flow. It is correct; it is being framed, not replaced.
OS_ARTIFACT_URL's operational detail stays in self-hosting.mdx (that is Axis A, and card 04 owns that file — do not edit it here). Reference it; do not move it. If you find the split genuinely unworkable without touching self-hosting.mdx, stop and report rather than reaching across the card boundary.
Verify the mechanisms before writing about them
The issue text is a clue, not a specification. Read the CLI and runtime sources for how OS_ARTIFACT_URL and the catalog install actually behave today — including whether they can be combined, and what happens when both are configured. If the measured behaviour contradicts the framing above, report it: premise_still_valid: false is a valued outcome here, because a page that documents a choice the runtime does not actually offer is worse than the current split.
Relevant: content/docs/deployment/cli.mdx (## Commands, lines 68–1283) is the command reference — link to it, do not restate it.
Independence
Touches only content/docs/deployment/publish-and-preview.mdx. No overlap with cards 01, 02, 04. Safe to run in parallel with all three.
Docs-only, skip-changeset.
Card 03 of the deployment restructure. Maintainer question, 2026-08-15: 「元数据应用又是独立的，如何加载到平台？」
The defect
There are two mechanisms for getting a compiled metadata app onto a running platform. They are documented on two different pages, and neither page mentions the other exists:
content/docs/deployment/publish-and-preview.mdx(101 lines)dist/objectstack.json→ publish a package version → install into an environmentcontent/docs/deployment/self-hosting.mdx, under "Artifact-pinned boot"OS_ARTIFACT_URL— the runtime fetches the artifact at bootA reader who lands on either page has no way to learn the other option exists, let alone which one fits them. There is no page whose subject is "a metadata app is a separate thing from the platform; here is how it gets in."
Scope
Rewrite
content/docs/deployment/publish-and-preview.mdxso it is that page. It must:OS_ARTIFACT_URL's operational detail stays inself-hosting.mdx(that is Axis A, and card 04 owns that file — do not edit it here). Reference it; do not move it. If you find the split genuinely unworkable without touchingself-hosting.mdx, stop and report rather than reaching across the card boundary.Verify the mechanisms before writing about them
The issue text is a clue, not a specification. Read the CLI and runtime sources for how
OS_ARTIFACT_URLand the catalog install actually behave today — including whether they can be combined, and what happens when both are configured. If the measured behaviour contradicts the framing above, report it:premise_still_valid: falseis a valued outcome here, because a page that documents a choice the runtime does not actually offer is worse than the current split.Relevant:
content/docs/deployment/cli.mdx(## Commands, lines 68–1283) is the command reference — link to it, do not restate it.Independence
Touches only
content/docs/deployment/publish-and-preview.mdx. No overlap with cards 01, 02, 04. Safe to run in parallel with all three.Docs-only,
skip-changeset.