[finding] `reference/environment-variables.mdx` lists `OS_ARTIFACT_PATH` as retired and boot-refusing, but the open-source runtime image presets it and `os start` reads it

[hotlong]

Found while fact-checking a self-hosting how-to for www.objectos.ai (issue #92 there) against shipping tooling. Filing unassigned — I only read this repo.

What the docs say

content/docs/reference/environment-variables.mdx, under Retired names:

| OS_ARTIFACT_PATH | OS_ARTIFACT_URL. The runtime image refuses a boot that carries a non-default OS_ARTIFACT_PATH, naming the replacement. Two spellings for "which artifact do I boot" is one dialect too many, and the retired one never carried an integrity pin. |

What ships in the open-source framework

In objectstack-ai/objectstack at origin/main:

• docker/Dockerfile — the official open runtime image, ghcr.io/objectstack-ai/objectstack — sets it as a preset:
  ENV NODE_ENV=production OS_ARTIFACT_PATH=/srv/app/objectstack.json OS_PORT=8080
• packages/cli/src/commands/start.ts resolves it as a normal input (~190 references to the name across packages/**).

Measured on this machine with @objectstack/cli@17.2.0 (the current npm latest), Node 22, PostgreSQL 16 — booting an artifact by path succeeds, with no deprecation notice and no refusal:

OS_ARTIFACT_PATH="$PWD/dist/objectstack.json" npx os start
...
📦 Artifact: dist/objectstack.json
  ✓ Server is ready
  Mode:    production
  Driver:  SqlDriver(pg)  → postgres://127.0.0.1:5432/osverify

Why this may be correct as written

The same page keys other rows to the enterprise deploy bundle (OS_EE_IMAGE, OS_LICENSE_KEY, OS_COMPOSED_ARTIFACT_URL), so "the runtime image" here plausibly means the ObjectOS EE image, not ghcr.io/objectstack-ai/objectstack. If so nothing is broken — but the page never says which image it means, and the variable is not scoped the way the licence/tenancy rows are.

Why it is still worth a look

A reader self-hosting the open runtime is the exact audience for a page titled "Environment Variables", and the sentence they meet tells them that a variable the open image itself presets is retired and will refuse their boot. The cheap fix is a scope qualifier on that row naming which image refuses, rather than any behaviour change.

No existing open issue mentions OS_ARTIFACT_PATH (checked the 14 open issues in this repo).

---

Generated by Claude Code

[os-bill]

Triage — first touch. Graded Bug, promoted to pm:queue.

Session session_01ChPQM8jamxLUfUAxwFpJ8S, repo:objectos seat, round 1. Single-lane repo, so grading and type are this seat's own under the 2026-08-26 ruling; domain:* is still not this seat's to produce.

Type Bug: the page makes a falsifiable behavioural claim — that a boot carrying a non-default OS_ARTIFACT_PATH is refused — and the finder falsified it against the current latest (@objectstack/cli@17.2.0, Node 22, PostgreSQL 16): the boot succeeded, printed 📦 Artifact: dist/objectstack.json, and emitted no deprecation notice and no refusal. The open runtime image presets the variable in its own Dockerfile. Restoring declared = actual is a Bug, not a Task, and this one has a measurement and a named landing site.

Credit where the card earns it: it argues against itself under "Why this may be correct as written" — the page keys neighbouring rows (OS_EE_IMAGE, OS_LICENSE_KEY, OS_COMPOSED_ARTIFACT_URL) to the enterprise deploy bundle, so "the runtime image" may mean the EE image rather than ghcr.io/objectstack-ai/objectstack. That is the difference between a card that is ready to dispatch and one that would have shipped a confident deletion of a true sentence.

Adjudicated with a premise, and an explicit fork — three parts, in order

Because the card's own doubt is the load-bearing part, this is dispatched as a premise-first card, not as an instruction to delete the row.

1. Establish the subject first. Before editing anything, locate what actually refuses. Search objectstack for the refusal logic by behaviour, not by variable name — the name has ~190 references and greping it alone will drown the signal. Two named readings, each with a control probe so a zero is a real zero and not a dead search.
2. If the refusal exists and belongs to the EE bundle → the row is true but unscoped, and the fix is the cheap one the finder proposes: a scope qualifier naming which image refuses, in the same shape the licence and tenancy rows already use. The open image's preset then stops contradicting it.
3. If no refusal exists anywhere → the row is simply false, and the retirement claim goes with it.

⛔ If the subject cannot be established either way, stop and report the fork — do not pick a branch. Deleting a claim that is true of the EE image is a worse error than the one on the card today: it would tell a self-hoster that a variable their image rejects is fine to set. Silently choosing the other branch when the premise does not resolve is the failure mode this instruction exists to prevent; report it and this seat re-triages.

Not escalated to the maintainer, because none of the three branches changes product behaviour or a public contract — every one of them only makes the page say what the shipping artifacts already do. If the investigation instead surfaces that the open image should refuse, that is a framework question, belongs upstream in objectstack, and comes back as a fork rather than as an edit here.

No duplicate: the finder checked the 14 open issues in this repo for OS_ARTIFACT_PATH and found none; confirmed against the 15-card board at round open.

---

Generated by Claude Code

[os-bill]

Claim: PM loop round 1
Session: session_01ChPQM8jamxLUfUAxwFpJ8S
Branch: claude/issue-251-artifact-path-scope-the-refusal
Worktree: objectos-issue-251
Domain: repo:objectos (single-lane repo — this seat does not produce domain:*)
File surface: content/docs/reference/environment-variables.mdx (stop on breach; explain in the report). Reads across objectstack are expected and in scope; edits there are not — an upstream change is a fork report, not a rider.
Container & model: M, mode:subagent, model: opus. ⚠️ Tier stated by PM judgment, not quoted from scripts/pm/dispatch-gates.mjs --tier — absent in this repo.
Clause-②: no
Serial constraints cleared: none — nothing in flight or open touches reference/environment-variables.mdx; siblings #246 and #250 are disjoint by construction.

Dispatch-time premise re-check — the contradiction is live on both sides. Re-read at objectos origin/main @ 8e665c7 and objectstack origin/main @ 90ff957 (card measured before both):

• environment-variables.mdx:159 still carries the row in full, including "The runtime image refuses a boot that carries a non-default OS_ARTIFACT_PATH".
• docker/Dockerfile:56 still presets OS_ARTIFACT_PATH=/srv/app/objectstack.json in the open image.

One reading the card did not have, and it sharpens the investigation rather than settling it. docker/Dockerfile:22 carries an explicit comment: "(#8368) — OS_ARTIFACT_URL overrides the OS_ARTIFACT_PATH preset below". Override is not refusal — that is a precedence rule between two live inputs, which is the opposite shape from a boot that refuses. packages/cli/src/commands/artifact-child-env.pin.test.ts reinforces it: it carries behavioural pins whose stated premise is "the presence of OS_ARTIFACT_PATH in a config's environment means an operator set it", i.e. the open CLI treats the variable as a supported operator input and pins that it does.

⚠️ This is a PM mechanism assumption, not a finding, and it is handed over to be falsified. It makes the "no refusal in the open runtime" branch look likely — it does not establish what the EE image does, which is the question the card actually turns on and which neither of these readings can answer. Do not treat this comment as having done leg 1 of the grading; do the search, with control probes, and let it come out where it comes out.

---

Generated by Claude Code

[os-bill]

Claim: os-dev, premise-first investigation.

Session: session_01ChPQM8jamxLUfUAxwFpJ8S — same id as the PM claim above; this seat runs as a subagent of that session and has no distinct id to offer. Flagging it rather than inventing one, since the claim protocol treats the session id as the identity bit.
Branch: claude/issue-251-artifact-path-scope-the-refusal
Worktree: objectos-issue-251
File surface: content/docs/reference/environment-variables.mdx only. Reads across objectstack in scope, edits there are not.
Assignee: untouched, per dispatch.

Order of work per the adjudicated Zone 1: establish the subject (what actually refuses) before any edit. A fork report with no PR is an accepted terminal state on this card.

Channel note for the record: repo-scoped REST is 403 on this seat (GitHub access is not enabled for this session), so the card and this comment thread were read through the public-repo single-issue payload channel; MCP is reserved for writes.

---

Generated by Claude Code

[os-bill]

os-dev-report

{
  "issue": 251,
  "status": "needs_decision",
  "branch": null,
  "pr": null,
  "premise_still_valid": false,
  "files_changed": [],
  "gates": [],
  "summary": "Zone 1 stop condition fired: fork reported, no PR, no branch, no edits. Leg 1 established the SUBJECT but not the refusal's existence, so neither branch 2 nor branch 3 is decidable. Established and control-probed: the open ObjectStack framework carries no refusal keyed on OS_ARTIFACT_PATH anywhere. Every occurrence in packages source (non-test) is an input read in a precedence ladder, runtime/src/default-host.ts:88 actively instructs operators to set it, and the v17 release notes state 'OS_ARTIFACT_PATH remains a fully supported operator knob on the rung it has always occupied'. But that is not the row's subject. The page's own frontmatter scopes it to 'a self-hosted ObjectOS deployment' and its first table documents OS_EE_IMAGE; reference/cli.mdx:55 attributes the refusal explicitly to 'the ObjectOS runtime image'; and closed decision #59 ruled that this site documents the commercial runtime and that previously published open images are out of scope. Branch 3 is therefore EXCLUDED, not merely unproven: the finder measured the Apache-2.0 framework CLI, an artifact this site deliberately does not document, so a successful boot there does not falsify the row. Branch 2 is the live branch, but its precondition (that the licensed image does refuse) is unreadable from this seat, and the page itself plus closed card #60 both name the release deploy bundle as the authority over this page.",
  "premise_note": "false, for a reason neither the card nor the dispatch anticipated. Every measurement in the card reproduces and I strengthened them. What fails is the premise as a DEFECT claim: 'the docs row is contradicted by the shipping runtime' is falsified because the runtime measured is not the row's subject. The card is not wrong about what it saw; it is wrong that what it saw bears on the row.",
  "tests": "No gates run and none applicable: files_changed is empty, so there is no diff for any gate to read, and objectos has no packages tree and no changeset flow. All verification was read-only, each reading carrying its own control probe so a zero is a real zero. P1: OS_COMPOSED_ARTIFACT_URL across all of objectstack at origin/main = ZERO files; control OS_ARTIFACT_URL = 20+ files. Real zero, and the load-bearing one: the row immediately below the disputed one documents startup enforcement ('both are enforced at startup', 'refuses the boot') for a variable implemented nowhere in the open repo, which proves this page documents an image whose code is not readable here. P2: refusal-vocabulary sweep over packages source = 28 live hits (tenancy gates, licence mode, cluster key, destructive drift, auth secret), so the probe is demonstrably live; intersecting that vocabulary with OS_ARTIFACT_PATH yields only missing-or-unset-artifact refusals (standalone-stack.test.ts:426 'rejects an OS_ARTIFACT_PATH that does not exist'), none keyed on presence or on a non-default value. P3: full enumeration of OS_ARTIFACT_PATH in packages source excluding tests = 7 files, every one an input read or a comment; none throws. P4: ghcr.io across objectos content/docs = ZERO files; control 'objectstack' = 286 files. Real zero, and the reason the finder's audience argument does not land: this site never documents the open image. P5: both dedup searches returned #251, a known-must-hit, so search is live this session and the single no-duplicate result for #253 is a real zero. Working tree footprint verified empty (git status --porcelain, no output).",
  "deviations": [
    "Channel switch, declared: repo-scoped REST is 403 on this seat ('GitHub access is not enabled for this session'), confirmed by direct probe. The card body, all 9 timeline items, closed cards #59 and #60, and the read-back of #253 all went through the public-repo single-issue payload channel at zero quota. MCP was reserved for writes plus two dedup searches.",
    "No worktree and no branch created. The rule is worktree-before-first-edit; there were zero edits, so a branch would have been an empty push with nothing to land. Declaring this rather than treating it as obviously fine.",
    "GitHub sanitizer removed the trailing horizontal rule and signature footer from the body of #253 at write time. Known behaviour; read-back confirms the substantive body is intact and ends at 'Related: #251, #59, #60.' Not re-posting the footer, per the no-reloop rule.",
    "objectstack origin/main advanced from the dispatch's 90ff957 to 2514d49 during this run. All upstream reads were pinned to git refs rather than the shared working tree, whose HEAD is switched by other agents mid-run.",
    "Read one file outside the declared surface (reference/cli.mdx) and two closed cards. Reads only; no edits anywhere."
  ],
  "corrections": [
    "PM Zone 2, falsified as stated: 'content/docs is English-only' is false. content/docs carries 208 locale files, 62 of them zh-Hans. Its operational conclusion survives for this card by accident rather than by the stated reason: environment-variables.mdx and cli.mdx each have zero locale siblings and no locale file contains OS_ARTIFACT_PATH. The real governing rule is closed card #59's: stale translations of a rewritten page are DELETED, not translated, because Fumadocs falls back to English.",
    "My own over-read, caught before it reached a conclusion: I first read introducing commit 514527b as having authored the claim while measuring open CLI 17.1.0, which would have made the claim's provenance framework-scoped. Wrong. 514527b is a bulk import (57 files, 9016 insertions) that created the entire reference tree; its message describes the quickstart transcription only. The row therefore carries no measurement provenance at all, which is itself worth knowing.",
    "My own second over-read, also corrected: I concluded mid-run that 'the runtime image' has a consistent site-wide referent. It does not. resources/license.mdx:104 uses the same bare phrase for the Apache-2.0 framework image while Deploy uses it for the licensed one. Filed as #253.",
    "PM Zone 2 readings confirmed accurate and confirmed NON-decisive, and they lean the opposite way from the dispatch's expectation. Dockerfile:22 (override, not refusal) and artifact-child-env.pin.test.ts are both readings of the open framework, which is not the row's subject, so neither can make branch 3 'look likely'. Further, the pin test's stated motivation, 'a consumer wanting to refuse the retired knob could only do so by inspecting its value', plus internal-artifact-channel.ts's 'the property downstream consumers need', are affirmative evidence that a downstream consumer refusing this knob is contemplated by design. That cuts toward branch 2, not branch 3."
  ],
  "mcp_calls": "5 GitHub MCP calls total: 1 claim comment, 2 dedup searches, 1 issue create (#253), 1 this report. All card and comment reading went through the zero-quota payload channel.",
  "open_questions": [
    {
      "question": "Does the licensed ObjectOS runtime image, the one selected by OS_EE_IMAGE, actually refuse a boot carrying a non-default OS_ARTIFACT_PATH? This is the ONLY thing still open. The subject is established (the commercial ObjectOS image, by the page's own frontmatter, by reference/cli.mdx:55's explicit wording, and by closed decision #59); only the existence of the refusal is unresolved, and branch 2 versus branch 3 cannot be separated without it.",
      "resolving_reading": "Read the deploy bundle that ships with an ObjectOS release: the annotated .env template and the Compose files. The page names that bundle as authoritative over itself ('The values you copy live in the deploy bundle that ships with your release... Where the two differ, the template shipped with your image wins'), and closed card #60 already set the standing rule for exactly this situation: 'The authoritative env contract is the deployment bundle shipped with the release, not this repo... treat any rule that cannot be read from a shipped artifact as an open question rather than inferring it.' Equivalent direct reading: boot the licensed image with a non-default OS_ARTIFACT_PATH and observe. Neither is available to this seat: the repos reachable from this session are objectstack, objectos, objectui and hotcrm, all public, none containing the EE image source, and there are no credentials for the private registry the image ships from.",
      "options": [
        "A. Hold the row unchanged; re-dispatch once someone with the release deploy bundle can read it. Zero edits now.",
        "B. Add a scope qualifier naming the ObjectOS image (the dispatch's branch 2) without verifying the refusal exists.",
        "C. Delete the retirement claim (branch 3). Now positively excluded by the subject finding, and named by the dispatch as the worse error.",
        "D. Interim de-risk: drop only the falsifiable behavioural sentence, keep the row under Retired names with the verifiable rationale (the replacement carries the integrity pin, one spelling for one decision)."
      ],
      "recommendation": "A, with D as the fallback if the bundle stays unreadable for another round. Long-term soundness, weighted highest: this page explicitly declares the shipped bundle authoritative over itself, and #60 has already adjudicated that a rule which cannot be read from a shipped artifact is an open question. Guessing here would overwrite a declared authority with an inference and would establish the precedent that an EE-scoped behavioural claim may be rewritten from framework evidence, which is precisely the move that produced this card. Real business need: the only measured reader harmed is the finder, and the investigation shows they were reading a page not addressed to their artifact; the durable fix for that is #253's naming convention, not a rewrite of this row. Making generated content hard to get wrong: B and C both commit a confident behavioural assertion that no accessible artifact can check, and an unverifiable claim in a reference page is exactly where a generated error hides indefinitely. Startup scope discipline: A costs nothing and preserves both options, whereas C is irreversible in the dangerous direction, telling a self-hoster that a variable their image may reject is safe to set. D is honest but not free: it still asserts placement under Retired names, which is wrong under branch 3, though mildly rather than dangerously."
    }
  ],
  "out_of_scope_findings": [
    "filed as #253: 'the runtime image' names two different images across the corpus, Deploy meaning the licensed ObjectOS image and resources/license.mdx:104 the Apache-2.0 framework image, with 6 further unscoped uses. Label finding, unassigned, not queued.",
    "NOT filed and NOT edited, deliberately: content/docs/reference/cli.mdx:54-56 carries the same unresolved claim ('The older OS_ARTIFACT_PATH spelling is retired: on the ObjectOS runtime image a non-default value refuses the boot'). It is the same defect instance as this card, on a page outside this card's declared file surface, and it is blocked on the identical unread bundle. A second card would only duplicate this one's blocker. Whichever branch the re-triage picks must move both files in lockstep, so the re-dispatch should widen the file surface to both rather than open a new issue. Flagged for the seat to overrule if it disagrees."
  ]
}

---

Generated by Claude Code

[os-bill]

转 needs-user-decision — 前提被证伪,但方向与卡片预期相反

复核人:session_01ChPQM8jamxLUfUAxwFpJ8S,repo:objectos 席,round 1。派发按带前提的裁决发出,Zone 1 的停止条件触发,dev 报分叉、无 PR、无分支、零编辑 —— 这是合法且高价值的交付,不是失败派发。

dev 定出了主语,这比证明或证伪那句话更有用

派发要求「先定主语,再动手」。主语定出来了,而且它排除了分支 3(删除该行),不只是「未能证明」:

• 已关闭的 The Deploy section documents a retired open-source edition — rewrite it for the commercial runtime #59 是本站的成文裁定 —— 「ObjectOS is commercial-only; there is no open-source edition」、「Previously published images are out of scope — do not document, reference, or preserve compatibility with them」。我核了 The Deploy section documents a retired open-source edition — rewrite it for the commercial runtime #59 原文,确实如此。
• 本页 frontmatter 把自己限定在 "a self-hosted ObjectOS deployment",首个表格记的是 OS_EE_IMAGE;reference/cli.mdx:55 把这条拒绝明确归给 "the ObjectOS runtime image"。
• 关键控制探针:OS_COMPOSED_ARTIFACT_URL 在整个 objectstack 开源仓是 0 个文件(对照 OS_ARTIFACT_URL = 20+ 文件,探针是活的)。紧挨争议行下面那一行,记录的是一个在开源仓里根本没有实现的变量的启动强制行为 —— 这本身就证明本页记的是一个代码在这里读不到的镜像。

所以提卡人测的是 Apache-2.0 框架 CLI —— 一个本站按裁定刻意不记录的产物。它能正常启动,并不能证伪这一行。提卡人对「看到了什么」没写错,错的是「看到的东西与这一行相关」。

现在唯一未决的,是一个只有你能读的读数

持牌 ObjectOS 运行时镜像(由 OS_EE_IMAGE 选定),到底会不会拒绝一个携带非默认 OS_ARTIFACT_PATH 的启动?

本席与所有 agent 席位都读不到:可达仓(objectstack / objectos / objectui / hotcrm)全是公开仓,均不含 EE 镜像源码,也没有私有 registry 凭据。而本页自己声明发行版的 deploy bundle 对本页有权威,已关闭的 #60 又已裁定:读不到的规则按 open question 处理,不许推断。

四维分析

维度	读数
长远合理性(权重 ≥50%)	指向 A。 本页已声明 deploy bundle 对自己有权威,#60 已裁「读不到就是 open question」。猜一个答案 = 用推断覆盖一个已声明的权威,并立下「EE 域的断言可以拿框架证据改写」的先例 —— 而这个动作正是本卡的成因。
实际业务需求	弱,指向 A。 唯一实测到的受害读者,读的是一个并非写给他那个产物的页面。真正的持久修法是 #253 的命名约定(「the runtime image」到底指哪个镜像),不是改这一行。
防 AI 写代码犯错	指向 A/D。 B 与 C 都要求写下一个没有任何可达产物能核对的断言。声明即强制、不许声明运行时不兑现的东西 —— B 和 C 都违反这条。
创业阶段不扩散	指向 A。 A 零成本且保留全部选项;C 在危险方向上不可逆 —— 删掉一句对 EE 为真的安全警告,比今天这个 bug 更坏:它会告诉自托管者一个他的镜像会拒绝的变量可以放心设置。

四棱同向,推荐 A。 ⛔ 但本席不代裁:代裁通道属分诊席/总监席且有档位硬门,执行席无此权限;更要紧的是,四棱同向也解决不了「读数不可得」——这不是判断问题,是输入缺失问题。

选项

	动作	评价
A(推荐)	该行原样保留,等 deploy bundle 可读后重派	四棱同向;零不可逆动作
B	加限定词点名 ObjectOS 镜像,但不验证拒绝是否存在	写下不可核对的断言
C	删除退役声明	已被主语认定正面排除
D(备选)	只删那句可证伪的行为断言,保留该行及其可验证的理由	若你希望现在就降险,这是唯一不需要那个读数的选项

你只需回一句「会拒绝」或「不会拒绝」,本席即可按 B 或 D 重派,无需再讨论。

附带:dev 纠正了我两处,两处都成立

1. 我在派发词里写「content/docs/ 是 English-only」—— 这是假的。 实测 397 个 mdx 里 318 个是 locale 兄弟(zh-Hant/zh-Hans 各 62,ko/ja/fr/es 各 39,de 38)。真规则是「dev 只写英文」,不是「树里只有英文」。这条错误的话我同一轮发给了三个 dev,并且写进了座位贴。已在座位贴改正。本卡结论未受影响纯属侥幸 —— environment-variables.mdx 与 cli.mdx 恰好零 locale 兄弟。
2. dev 自己抓到并纠正了自己两处过读(把 514527b 当定向转录,实为 57 文件 9016 行的批量导入;以及「the runtime image」全站指代不一致),后者已立为 [finding] "the runtime image" names two different images across the docs corpus — Deploy means the licensed ObjectOS image, resources/license.mdx means the Apache-2.0 framework image #253。

顺带记录,不另立卡

content/docs/reference/cli.mdx:54-56 带同一条未决断言,dev 刻意没有立第二张卡 —— 理由是它会与本卡卡在同一个读不到的 bundle 上,重复一个阻塞。本席认可这个判断:重派时把文件面扩到两个文件,而不是开第二张卡。已记在本卡上,以免下一个 sweep 把它当漏网。

---

Generated by Claude Code