[Decision] The copilot's drafts: who sees a copilot change before publish, and where — preview-first (A), auto-publish additive edits (B), sticky author preview (C) or a dev environment (D); the frame #24298 waits on #24324

Ruled: 6250704607 · letter A · 2026-10-18T13:51Z

Filed by the director seat (summon #43 continuation 5, session_01QJC7i981TSs9L1CGJK59Ax) on the maintainer's words in this session's chat, verbatim: 「决裁 24298 AI 副驾 如果保存的是草稿的话，实际上不只是设计器，界面上也显示不出来。所以这个问题要综合评估。」 — the frame #24298 (per-key draft provenance for Studio's 草稿 chip; pm:dispatched, held on the maintainer's word) waits on. ⛔ Not a claim. Platform first (the maintainer's 口径 「平台相关的功能，应该尽量先改平台。」): the governing ADRs are this repository's.

维护者速读

今天的事实(源码读数,未实机走查): AI 副驾改一个已发布应用里的东西(字段、视图、页面)时,存的是草稿。草稿只有「搭建者」看得见:持有 studio.access / setup.access / manage_metadata 的人,在三个地方 —— 带 ?preview=draft 的预览模式(Live Canvas 和应用内的「草稿预览」水印条)、Studio 的「变更」抽屉、聊天里的「已存为草稿」卡片(带发布和查看变更按钮)。普通成员在应用里看到的永远是已发布的版本,一个字节都不差;这是 ADR-0033「AI 只写草稿,发布是人的闸门」定的,有测试钉住。整个应用的首次生成是例外:lint 干净就当场发布,只对非搭建者隐藏(ADR-0045)。增量修改不走这条路,所以一直是草稿。

您说的「界面上也显示不出来」成立,而且有两层。 一层是入口:聊天里的「预览」按钮只在草稿里含应用时才出现,改一个字段就没有预览入口,只能去 Studio 或者盲发布。另一层是本质:草稿字段没有存储(建表只在发布时做),/data 永远不读草稿,所以预览能看到新字段,却填不进数据。要「带数据看到」,只有发布。

要您定的: 副驾的改动在发布之前,应该让谁、在哪里看到。四个方向见下表。席位推荐 A:补齐预览入口与 Studio 标记,发布仍是人的闸门;B 是把「新增类」改动也当场发布。

What exists today (read at objectstack 3fed1eb00af6, objectui a8560b228527, cloud 837e24a4b8b4)

• Saving defaults to publish; the copilot's write tools choose mode: 'draft' (cloud service-ai-studio/tools/metadata-tools.ts:1523–1581); applyDraft returns changedKeys and the note 「NOT LIVE … ask them to publish」 (:1589–1636).
• autoPublishAiBuilds (cloud ADR-0012; default on unless OS_AI_AUTOPUBLISH_DISABLED) auto-publishes package-bound, lint-clean drafts only; incremental edits are not marked autoPublishable (:5157–5170).
• Drafts are environment-global with no actor or conversation tag (cloud ADR-0070); publishPackageDrafts is one atomic, revertible commit (ADR-0067).
• Governing: ADR-0033 (AI drafts, the human publishes), ADR-0037 (draft-overlay preview, accepted and implemented), ADR-0045 (additive builds publish behind _unpublished), cloud ADR-0084 (Proposed: publish only when everything passes).

Options

Recommendation: A, with B as the one widening worth its own letter

• Long-term fit. ADR-0033, 0037 and 0045 are one coherent model: new things go live hidden, changes to live things are drafts that builders preview and a human publishes. What the maintainer hit are entrances (no Preview for a field draft; no per-key mark in Studio), not the model. A completes the ruled design; objectui#12725 item 3 and metadata-protocol / spec: a draft carries no per-field provenance (which surface changed which key, and when), so Studio cannot mark a copilot's draft change with the ruled 草稿 chip and 来源 line #24298 are A's Studio half.
• Business pull. The maintainer's own walk; the AI building loop needs 「say it, see it」 (ADR-0037's design centre). The inherent limit stays under A and C: a draft field holds no data, so seeing it with data means publishing — which is B's pull.
• AI-error surface. A keeps the human gate for every change to a live app. B publishes additive edits in-turn: safe for data (nothing existing is touched) but visible to members at once, so it needs the 「live app with data」 posture rule (objectui#12725 change card v2) to stay honest. C and D add no AI risk.
• Startup, no spread. A: one objectui card plus the metadata-protocol / spec: a draft carries no per-field provenance (which surface changed which key, and when), so Studio cannot mark a copilot's draft change with the ruled 草稿 chip and 来源 line #24298 chain already graded; B: a cloud change plus a Tier H ADR amendment; D is a capability build.
• If the maintainer wants 见即所得 without a preview step, B is the letter; metadata-protocol / spec: a draft carries no per-field provenance (which surface changed which key, and when), so Studio cannot mark a copilot's draft change with the ruled 草稿 chip and 来源 line #24298 still applies to the drafts that remain.

Execution

• A: metadata-protocol / spec: a draft carries no per-field provenance (which surface changed which key, and when), so Studio cannot mark a copilot's draft change with the ruled 草稿 chip and 来源 line #24298 resumes as filed (its seat lifts the hold); the director files objectui p2 pm:queue — the chat's Preview button for any draft, deep-linked to the affected page in ?preview=draft; this card closes completed.
• B: metadata-protocol / spec: a draft carries no per-field provenance (which surface changed which key, and when), so Studio cannot mark a copilot's draft change with the ruled 草稿 chip and 来源 line #24298 resumes; the director files cloud p1 pm:queue (additive incremental edits autoPublishable behind lint, with the posture rule) and an objectstack Tier H card (the ADR-0045 amendment; the maintainer merges); A's objectui card too.
• C: metadata-protocol / spec: a draft carries no per-field provenance (which surface changed which key, and when), so Studio cannot mark a copilot's draft change with the ruled 草稿 chip and 来源 line #24298 resumes; one objectui card (sticky preview). D: a cloud capability card; metadata-protocol / spec: a draft carries no per-field provenance (which surface changed which key, and when), so Studio cannot mark a copilot's draft change with the ruled 草稿 chip and 来源 line #24298 resumes.

os-decision-facets
① 项目长远合理性:A —— ADR-0033/0037/0045 是一套自洽模型(新建即发布但隐藏;改动成草稿、搭建者预览、人来发布);您撞到的是入口缺口,不是模型错;#24298 是 A 在 Studio 的那一半。
② 实际业务拉动:您的走查;AI 搭建要「说了就看见」;「草稿字段没有数据」这层限制 A、C 都解不了,只有发布能解,这是 B 的拉动。
③ 防 AI 犯错:A 保留每个改动的人工闸门;B 把新增类改动当场发布,数据安全但成员立刻可见,需要「有数据的活应用」姿态规则;C、D 不新增风险。
④ 创业阶段不扩散:A 一张 objectui 卡加已评级的 #24298 链;B 多一处 cloud 改动和一次 Tier H ADR 修订;D 是能力建设。
Prior rulings read: ADR-0033(AI 只写草稿)· ADR-0037(草稿预览,已实现)· ADR-0045(新建即发布、_unpublished 隐藏)· ADR-0067(发布原子可回滚)· cloud ADR-0012 / 0070 / 0084 · objectui#12725 裁决(右栏二选一;草稿 chip 与来源行)· #24298 triage 6249057462 → 7 hits; thread: #24298 6249183877