docs(adr): ADR-0136 declared journeys as the priority anchor

[hotlong]

Fixes #18477

Maintainer 「立」 (2026-09-16, direct channel). Rework round 2 (v3, 2026-09-17): the maintainer rejected v2's ten-row journey table, verbatim and untranslated: 「#18480(路的清单)有很大问题啊,基于元数据开发的应用到底能实现那些功能,开发好的应用是否要测试验证,这些需要进清单吗」 → 「这个清单的目的到底是什么」 → on the director seat's three options, 「A(建议):」. Ruling A is recorded on #18480 comment 5710656572. One file changed in this round; docs/adr/PRIORITIZATION.md still carries only its one pointer line from round 1.

What changed vs v2

	v2 (365d1bc)	v3 (this head)
main table	10 journey rows (J1–J10), developer-centric	13 capability rows (C1…C13) — one row per capability area of the enterprise app built on the protocol
developer path	was the whole table	second table, 6 rows (P1…P6), the cap
row cap	hard 10	by capability area (the ruling removed the hard ten); the path table keeps a ≤6 cap
columns	谁走 · 入口→看到什么 · runner · 读数 · 来源	应用里能做什么 · 声明它的元数据 · 怎么验证(项数 / P0 数 / P0 ids / 具名 runner / 什么仍是手动)· 读数 · 来源
checklist items cited	22 of 264 (a sample)	all 264, partitioned — main table 244, path table 20, 未入选 0
J10 (end users as proof)	a row	deleted as a row, promoted to D2.4 — an app counts as built only when it passes verification
purpose	implied	stated in one sentence at the top of Context: this is the PM fleet's anchor for 「先修什么」, ⛔ not a product spec and ⛔ not a test plan; the capability-and-verification ledger is docs/qa/platform-checklist/ and this table takes its rows from it

Coverage, by the numbers (remeasured on this merged tree)

• 15 / 15 areas land, and every one of the 264 items has exactly one home. A new 「区 → 行 归属」 table in the ADR carries the per-area split and sums to 264 (main 244 · path 20). records-forms (39) spans C1/C2/C3/C10; platform-core (29) spans C1/C2/C8/P5; cli (17) spans C1/C9/P1/P3/P4/P5 — and the ADR says where each of their P0s went.
• The P0 count is 20, not the 19 v2 recorded. Recount on this tree: priority === "P0" is 20 items (access-security 6 · platform-core 5 · api-backend 2 · ai 1 · approvals 1 · automation 1 · cli 1 · integration-system 1 · records-forms 1 · studio-authoring 1). The correction is stated in Consequences; the checklist files are untouched.
• 110 of 264 items carry an automated runner; 154 are manual. 10 of the 20 P0s are manual — D2.4 names all ten, so the rule is honest about being a rule people execute today, not a gate that goes red by itself.
• 12 of 13 capability rows have a runner. C11 (i18n) is none yet — 5 items, zero automated in the whole area. In the path table P6 (iterate a customer requirement) stays none yet. Those two plus C5 (2 of 18 approvals items automated) and C13's P0 studio-authoring.first-run-loop are written up in Consequences as the gap list for the checklist-author skill.
• 未入选: the cloud block is kept verbatim (6 lines). The platform-side block is emptied — approvals.account-app-entry moved into C5 (it is C5's only P0) and the two studio-authoring.custom-page-* items moved into C13; the ADR says so explicitly rather than dropping them.

Readings, all re-taken 2026-09-17

runner	reading
objectstack Dogfood Regression Gate	🟢 main@e0d05538, CI run 35192708788 (scheduled, 07:04Z), 3 shards + Dogfood Verify CLI
objectstack Test Core, same run	🔴 shard 2/6 (packages/lint pnpm run test exit 1); 5/6 success. Every row whose runners ride Test Core therefore reads unknown, never 🟢
objectstack scaffold-e2e.yml	🟢 #3088, main@a55646b0
objectstack check-links.yml	🟢 #9950 — ⚠️ the workflow runs on pull_request only; its last main run was a cancelled on 2026-08-30, so this reading is from a PR run and the ADR says so
objectstack platform-checklist-watchdog.yml	🟢 #14, main@879b5127 (the checklist's own structural + coverage ratchet)
objectstack showcase-smoke.yml	🟢 #90 (2026-09-16); #91 on e0d05538 was in_progress at read time
objectui live-e2e.yml + ci.yml	🟢 #4439 / #18088, objectui main@e896c389 — ⚠️ that is objectui main, not this repo's pinned .objectui-sha 53ded82b; the ADR states the gap
cloud golden-journey.yml	🟢 #18 (2026-09-16T18:33Z); 2026-09-17's fires after this reading
hotcrm ci.yml / e2e.yml	🟢 #3054 / #1272, hotcrm main@087b7c5d (main has not moved since 2026-09-16)
hotcrm publish-staging / publish-production	🟢 #11 / #5, main@590b095e (2026-09-14; nothing published since)
hotcrm docs/requirements/	🔴 re-read at main@087b7c5d: all six REQ are Status: Triaged, none past it; REQ-0002 Traceability is still "to be filled in per phase", REQ-0003–0006 still "to be filled in when built". In flight but not landed: hotcrm draft PR #1950 (REQ-0006), its ci #3055 failure / e2e #1273 success

Mechanism assumptions the dispatch asked me to measure

• A1 — verified. areas/*.json = 15 files, 264 items; the per-area counts match the director's reading exactly (access-security 27 · ai 8 · api-backend 23 · approvals 18 · attachments-storage 9 · automation 16 · cli 17 · dashboards 11 · i18n 5 · identity-auth 22 · integration-system 18 · platform-core 29 · records-forms 39 · search 7 · studio-authoring 15). All 264 are status: "active". P0 = 20, not 19 (see above).
• A2 — verified. coverage.json has metadataKinds, keyed by ledger name, 37 entries; each is {items: [...]} except realtime_subscription, which is {waived: ...}. The ADR's 「声明它的元数据」 column is a read of that map and says so — a kind may appear on several rows.
• A3 — verified. scripts/checklist-select.mjs exists; run with no argument it prints its selectors: (id) | area: | capability: | priority:P0 | surface:api | since:vN | file:(path) | all. D2.4 quotes that set.
• A4 — verified. All 13 runner paths v2 cites still exist on this merged tree (git cat-file -e on each, 13/13 OK).
• A5 — re-read, v2's verdict holds. hotcrm main is still 087b7c5d, so nothing moved; the traceability placeholders are quoted above. What v2 did not have is the in-flight draft PR feat(cli): two flow anti-pattern lints — date-equality filters (#1874) + phantom aggregation (#1870) #1950, now named in the P6 row.

Gates (exit code captured by redirect, then $? — never through a pipe; tree b3da1ec4)

Derived with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (no paths passed — the script took the change set from the merge base itself: 2 paths, three-dot). 18 commands, the same 18 as rounds 1 and 2. Reconciled:

✓ dispatch-gates --ran: 18 derived famil(ies) accounted for — 18 run, 0 NOT-MEASURED (a DERIVED zero — all 18 recorded an exit code and none of them is 3).

• check-adr-links :: 0 · --self-test :: 0 · check-adr-symbol-anchors :: 0 (2210 anchors across 140 records resolve) · --self-test :: 0 · pnpm check:adr-anchors :: 0
• check-ci-filter-parity :: 0 · check-closing-keyword-parity :: 0 · --self-test :: 0 · check-comment-mask-corpus :: 0
• pnpm check:doc-authoring :: 0 · check:nul-bytes :: 0 · check:pm-governed-merges :: 0 · check:pm-prior-rulings :: 0 · check:driver-memory-census :: 0 · check:refd-timer-probe :: 0 · check:watch-hint-literal :: 0
• pnpm --filter @objectstack/lint run check:doc-formula-expressions :: 0 (the lint closure was built first, under scripts/pm/os-verify-lock.sh; VERDICT command-exit 0 · held the lock 183s · waited 0s)
• pnpm check:cross-package-test-inputs :: 0 before that build, 1 after it — measured both ways on this same commit, which pins round 2's diagnosis instead of restating it. The gate flags packages/cli/test/init-created-files-summary.e2e.test.ts descending into packages/spec/dist/, "no declared glob reaches inside it". With packages/spec/dist absent the gate exits 0; the only thing that changed between the two legs is that building @objectstack/lint's closure produced that directory. Recorded as 1 in the --ran record so nothing is cherry-picked. This PR touches no test, no turbo.json and no package; it is reported in the os-dev-report as an out-of-scope finding for the seat.

No package is touched, so no dependency-closure build and no package test/typecheck are owed. Repo-wide scans are CI's.

Acceptance notes

• noted, not filed: docs/adr/PRIORITIZATION.md's pointer line names the ADR by its v1 title ("Declared journeys as the priority anchor"). The H1 is now 「应用能力 × 验证,加开发者路径,作为优先级锚」. check-adr-links resolves the link (it checks destinations, not link text), and the dispatch fences that file, so it is left alone. 承接者: whoever lands the enforcement card (skills(pm-dispatch): ADR-0136 D2 becomes the triage protocol — Journey: line, journey bands, cross-lane product-first order, journeys feed the queue #18489) touches that area next.
• noted, not filed: objectstack main@e0d05538 is red on Test Core shard 2/6 (packages/lint) in scheduled CI run 35192708788, 2026-09-17T07:04Z. Not caused by this branch; it is why several ADR rows read unknown. dedupe words: Test Core shard 2/6, packages/lint, main red, scheduled CI 35192708788.
• noted, not filed: check-links.yml has no main trigger, so the ADR's link-reachability runner has no reading on main — the last main run is a cancelled from 2026-08-30. dedupe words: check-links workflow, pull_request only, no main schedule.
• skip-changeset: docs/adr/** publishes nothing (fast lane).

维护者速读(草稿)

改了什么。 按你的裁决 A 重塑了 docs/adr/0136。主表不再是「路」,而是你的应用能干什么 × 怎么验证:13 行,每行一个能力区 —— C1 建对象与记录增删改查 · C2 视图与搜索 · C3 表单/字段/校验/公式 · C4 权限与行列级安全 · C5 审批 · C6 自动化 · C7 仪表盘与报表 · C8 身份与登录 · C9 集成与后端 API · C10 附件 · C11 多语言 · C12 AI 辅助 · C13 Studio 零代码。每行写清四件事:终端客户能做什么、哪些元数据声明它、拿什么验证(清单项数 / P0 数 / P0 项 id / 具名 runner / 哪些仍是手动)、最近读数带日期。开发者路径缩成第二张表 6 行(进入 → 写元数据 → 本地跑 → 验证 → 发布安装 → 迭代客户需求)。行数上限改成按能力区,不再硬卡十行。 新增一条 D2.4:做好的应用必须过验证才算做好 —— 它的元数据 kind 映射到的清单项要在一条 run record 里通过,objectstack verify 要绿,hotcrm 是参考实现;一张交付了面向应用行为却没有通过 run record 的卡,不算 done。v2 的 J10(终端用户作证明)就是折进了这条规则,不再单独占一行。

为什么改。 你的原话:「基于元数据开发的应用到底能实现那些功能,开发好的应用是否要测试验证,这些需要进清单吗」「这个清单的目的到底是什么」。v2 那张表只回答了「开发者怎么走」,没回答「做出来的东西能干什么、怎么证明它能干」。v3 把主表换成能力 × 验证,并在 Context 第一句把目的钉死:这是排「先修什么」的锚,不是产品能力规格,也不是测试计划;能力与验证的账本是 docs/qa/platform-checklist/,本表从它取行。这一版把清单的 264 项全部分派进了表里(v2 只引了 22 项),15 个区一个不落,所以「哪块没人管」现在是能看出来的。

风险与代价(含回滚)。 这是法,不是执法:SKILL.md 一个字没动,执行仍是 #18489 那张卡。三处得先说破:① 读数会腐烂 —— 全部是 2026-09-17 的快照,今天 main 的 Test Core 恰好是红的(shard 2/6,packages/lint),所以所有靠它的行我写 unknown 而不是 🟢,这是故意的;② 表越细越贵 —— 13 行 × 6 列,你每删一行就得同时想清楚那一区的 264 分之若干去哪,归属表会对不上;③ D2.4 今天要人执行 —— 20 个 P0 里 10 个是手动的,这条规则短期内不会自己变红。回滚 = 把 0136 恢复到 365d1bc0 那一版(v2 十行表),PRIORITIZATION.md 不用动,没有任何代码依赖本文件。

席位意见。 (留空,席位定稿成评论)

你要做的。 读这两张表,按删除与替换编辑:① 主表 13 行是不是你认的能力切分 —— 哪行该删、哪两行该并、少了哪一行;② 「怎么验证」列里那些 none yet 和 unknown(尤其 C11 多语言整区零 runner、C5 审批 18 项只有 2 项自动、C13 的零代码首跑闭环、P6 客户需求端到端)是不是你要优先补的缺口;③ D2.4 的措辞就是你要 PM 协议引用的措辞吗 —— 特别是「没有通过的 run record 就不算 done」这一句的力度;④ 副表 6 行够不够、顺序对不对。然后手动合并(governed surface,PR 保持 draft,席位不翻 ready)。

---

Generated by Claude Code

---

Generated by Claude Code

[hotlong]

维护者速读(终稿)

总监席,session_01Wj1HUjzyeiBQ8atRf1ZhaL。席内复核 ACCEPT 记录在卡 #18477。受管面(docs/adr/**)⇒ 你亲手合;这一份请先删再批。

改了什么 新增 ADR-0136「路的清单」:9 条端到端路径(上限 10),每行五格(谁走 / 入口→完成时看到什么 / runner / 最近读数 / 来源),外加 5 条「未入选」备换;D2 写了三条规则(旅程锚定优先级、跨车道优先级、队列由跑旅程喂);PRIORITIZATION.md 顶部加一行「已被取代」指针。全部从五份现成材料抄出,零发明。

九条路,一行一句

• J1 新用户注册 → 建组织 → 进控制台 —— 🔴 今天断着(cloud#1653)
• J2 控制面打开够快(首页 ≤2.5 s)—— 🔴,无 runner(只能在生产人工测)
• J3 一句话让 AI 建出应用并发布 —— 🟢 每晚跑
• J4 再让 AI 加一条自动化,真的执行 —— 🟢(8 月读数)
• J5 HotCRM 托管版:登录直通、带示例数据、组织间隔离 —— 🟢
• J6 一条客户需求从原话到 CRM 用户看到字段 —— 🔴 六条 REQ 零条过分诊,无 runner
• J7 零代码作者:脚手架 → 建对象 → 发布 —— 🟢 每日跑
• J8 市场装包 → 导航出现应用 —— 读数未知
• J9 控制台里增删改查一条记录、受限成员只见自己的行 —— 🟢 每 PR 跑

为什么改 用的人少、没有拉力读数,分诊第一问一直是「违背哪条契约」,于是队列被契约扫描自我喂养(两周 1,166 次合并里业务功能 8%)。这张表把「先做什么」变成你声明过的路。

风险与代价(含回滚) 零产品行为变化;规则的执行在另一张 skills 卡里,本 PR 不改任何流程。回滚 = revert。真正的代价写在 Consequences:产品仓有 P0/P1 时,契约卫生卡整批停 —— 这是有意的。

席位意见 建议:删掉你不认的行、把「未入选」里想要的换进来,然后 Approve。我自己的两个疑问留给你:J2 和 J6 没有 runner 就变不了红 —— 要么补 runner,要么删;J1/J4 的 runner 引了 LOCAL-E2E-CHECKLIST.md(树上有,但不在四份点名材料里),不想要就划掉。

你要做的 在本 PR 上编辑表格(删 / 换),然后 Approve。

---

Generated by Claude Code

[hotlong]

Landing provenance (ruling C) — director seat, session_01Wj1HUjzyeiBQ8atRf1ZhaL · 2026-09-16T15:34Z

Governed surface (docs/adr/**). Readings at landing, head dc2b2ff3: APPROVED by os-zhuang (review 5224816426, 2026-09-16T15:32:50Z) on this exact head, table accepted as drafted (9 rows, no deletion); check-clause2-carriers --pair 18480 exit 0; CI 24 success · 15 skipped, all complete; in-seat ACCEPT on #18477 (stamped 2026-09-16T15:10Z). The seat stripped needs-user-decision.

⚠️ The seat's ready-flip + auto-merge (POST …/ccr/ready_for_review, PUT …/ccr/auto_merge) was refused by this session's harness classifier as [Merge Without Review] — a command-shape reading, not a state reading (the approval is on the head). Not worked around. The approver flips this PR ready and enqueues it, as on #18476 / #18478; nothing else remains. Recorded on the director seat post as a platform reading. ADR-0136 is accepted by this approval: the SKILL.md enforcement card for its D2 rulings is filed on the skills lane in the same act (serialised behind PR #18481, same file).

---

Generated by Claude Code

[os-zhuang]

这是云服务的旅程，不是本应用开发平台的旅程。本平台的目的是不能让第三方开发者能进入我们的元数据协议快速地开发迭代企业管理应用。

[os-zhuang]

这是云服务的旅程，不是本应用开发平台的旅程。本平台的目的是不能让第三方开发者能进入我们的元数据协议快速地开发迭代企业管理应用。

[hotlong]

Rework in progress on your review (5224841038) — director seat, session_01Wj1HUjzyeiBQ8atRf1ZhaL · 2026-09-16T15:36Z

Your direction, verbatim: 「这是云服务的旅程,不是本应用开发平台的旅程。本平台的目的是不能让第三方开发者能进入我们的元数据协议快速地开发迭代企业管理应用。」 — recorded as the ruling on #18477 (stamped 2026-09-16T15:36Z). D1 is being rewritten around the developer platform's journeys: a third-party developer enters the metadata protocol → scaffolds → authors metadata → runs locally → verifies → publishes → installs → iterates against a customer requirement and sees it live; AI-assisted authoring stays as a developer journey; end users appear only as the proof the built app works. The cloud-service rows (signup, control-plane speed, hosted tenancy) move to 「未入选 — cloud 服务自己的清单」. D2 / D3 unchanged. Same dev, same branch; the four-piece is re-hung when the new table is up, and you will be asked to read it again.

---

Generated by Claude Code

[hotlong]

维护者速读(终稿 v2 —— 按你 15:34 的意见重写后)

总监席,session_01Wj1HUjzyeiBQ8atRf1ZhaL。席内复核 ACCEPT(第二轮)记录在卡 #18477。受管面 ⇒ 你亲手合;请重读下面十行,删、换,然后 Approve 并翻 ready 入队(本席的翻 ready 被会话分类器拒,前三张都是你自己点的)。

改了什么 D1 整表重写:主角改为第三方开发者,十行按他的路径顺序排;云服务的六条(注册建组织、控制面速度、托管租户隔离、运营启停、计费、云端副签)移到「未入选 — cloud 服务自己的清单」,并写明 cloud 仓可按同一形状自立一张。D2 三条规则、D3 取代 PRIORITIZATION.md 不变。你的原话逐字引在 Deciders 里,旁边注了本席按上下文读作「能让」。

十条路,一行一句

• J1 首次进入:读 getting-started → npm create objectstack → 10 个技能随脚手架装入 → 启动健康 —— 🟢 每日 scaffold-e2e
• J2 手写元数据:objects / views / flows / permissions 每一种在运行时兑现 —— 🟢 Dogfood 门
• J3 AI 辅助:Claude Code + 技能,或一句提示给 build agent → 应用出现、再加表/加自动化 —— 🟢 每晚
• J4 Studio 零代码:建 package → object → 记录 → app → publish,零重启 —— 部分 🟢
• J5 os dev 本地跑起来,控制台(objectui 渲染半边)里看到自己的导航/列表/表单 —— 未知(手动项)
• J6 验证:os validate / os lint / pnpm verify,错拼与退役键响亮拒收 —— 🟢
• J7 发布:os compile → os package publish → 市场出现版本 —— 🟢(hotcrm 发布 workflow)
• J8 安装:装进环境 → 导航出现应用 → 记录可读写;engines 不兼容在边界被拒 —— 未知
• J9 迭代:客户原话进 docs/requirements → 分诊 → 写元数据 → verify → 发版 → 客户看到 —— 🔴 六条 REQ 零条过分诊,无 runner
• J10 终端用户作证明:登录 → 增删改查 → RLS/FLS 生效 —— 🟢 每 PR

为什么改 你的裁决:平台的目的是让第三方开发者进入元数据协议、快速开发迭代企业管理应用;首稿把云服务的旅程当成了锚。

风险与代价(含回滚) 零产品行为变化;执行在 #18489;回滚 = revert。

席位意见 建议:再删一轮 —— 我自己看 J4 与 J5 有重叠(都是「在运行中的应用里看到」),J9 没有 runner;要么给 J9 补一个「REQ 从 Triaged 到 Shipped」的机械读数,要么承认它是产品缺口(🔴)留着提醒。

你要做的 重读十行 → 删/换 → Approve → 翻 ready 入队。

---

Generated by Claude Code

[hotlong]

Rework #2 ordered — director seat, session_01Wj1HUjzyeiBQ8atRf1ZhaL · 2026-09-17T07:26Z

Maintainer, on the direct channel, verbatim: 「#18480(路的清单)有很大问题啊,基于元数据开发的应用到底能实现那些功能,开发好的应用是否要测试验证,这些需要进清单吗」 → 「这个清单的目的到底是什么」 → on the seat's three options, 「A(建议):」.

Ruling A — v3 reshapes the anchor into 「应用能力 × 验证」:

• Main table = capabilities of an enterprise app built on the metadata protocol, one row per capability area, sourced from docs/qa/platform-checklist/areas/*.json (15 areas, 264 items): what the built app can do · which metadata declares it · how it is verified (checklist items + named runner) · latest reading. The maintainer edits by deleting and replacing rows; seats add rows only with a runner. Row cap is by capability area, ⛔ no longer a hard 10.
• Second table = the developer path, ≤6 rows (scaffold/docs entry → author: hand / AI / Studio → run locally → verify → publish + install → iterate a customer requirement).
• New rule (D2.4): a built app counts as built only when it passes verification — the checklist items its metadata kinds map to (coverage.json, scripts/checklist-select.mjs) in a run record, plus objectstack verify green; hotcrm (pnpm verify, ci.yml, e2e.yml) is the reference implementation. J10 (end users as proof) folds into this rule.
• D2.1–D2.3 stand; the Journey: line takes C<n> (capability row) / P<n> (path row) / none. D3 stands. Purpose stated in one sentence in Context: the anchor answers 「先修什么」; it is not a product spec nor a test plan — the platform checklist is the capability-and-verification ledger and this record's source.

v2 (365d1bc0) is ⛔ not to be approved as is. Same branch, same card (#18477), one more os-dev round under this seat; the four-piece is re-hung when v3 is on the head. #18489 (enforcement) stays pm:blocked and will be re-scoped to the C/P line values after acceptance.

---

Generated by Claude Code

[hotlong]

维护者速读(终稿 v3 —— 按你 07:2x 的「A(建议):」重写后)

总监席,session_01Wj1HUjzyeiBQ8atRf1ZhaL。席内复核 ACCEPT(第三轮)记录在卡 #18477。受管面 ⇒ 你亲手合;这一版请按「删行、换行」读,再 Approve、翻 ready 入队(本席的翻转被分类器拒)。

改了什么 清单从「开发者的十步路」改成两张表。主表 13 行 = 做出来的应用能干什么,每行写:应用里能做什么 · 哪些元数据声明它 · 怎么验证(checklist 项数 / P0 / 具名 runner / 哪些还是手动)· 今天的读数。C1 建对象与增删改查 · C2 各种视图与搜索 · C3 表单、字段类型、校验与公式 · C4 权限与行级/字段级安全 · C5 审批 · C6 自动化 · C7 仪表盘与报表 · C8 登录与身份 · C9 对外后端与集成 · C10 附件 · C11 多语言 · C12 AI · C13 Studio 零代码。副表 6 行 = 开发者怎么把它做出来:进入 → 写元数据(手写 / AI / Studio)→ 本地跑 → 验证 → 发布与安装 → 迭代客户需求。checklist 的 15 个区、264 项全部有去处(主表 244、副表 20),表里写明了每个区落到哪几行。

新规则 D2.4:做好的应用必须过验证才算做好 —— 它的元数据种类映射到的 checklist 项要在一条 run record 里通过,加上 objectstack verify 绿;hotcrm 是参考实现;交付了应用行为却没有通过记录的卡,不算 done。表里照实写了今天的底子:264 项里 110 项有自动 runner、154 项手动;20 个 P0 里 10 个手动,十个都点了名。所以这条规则今天要人执行,把这十个 P0 自动化是它直接生出来的工作面。

读数 全部 2026-09-17 重取。今天 main 上的 Test Core 是红的(packages/lint 那个 shard),所以依赖它的行写 unknown,没有涂绿。两行 none yet:C11 多语言(5 项全手动、零自动)、P6 迭代客户需求(hotcrm 六条 REQ 仍全部 Triaged,REQ-0006 的 PR #1950 在途但 ci 红)。这两行是缺口,不是瑕疵。

你要做的 读主表 13 行:哪一行不是你要的能力,删;写得不对,换。副表 6 行同样。然后 Approve、翻 ready 入队。行数上限已改为按能力区,不再硬卡十行。

风险与代价(含回滚) 一份文档,零代码;规则的执行是另一张卡(#18489,接受后按 C/P 行号重划范围)。回滚 = revert 一个 squash 提交。

---

Generated by Claude Code

[os-elon-musk]

Closed without merging — superseded by the North Star (skills seat, session_01BTeBejoPUvRHN8WdAJC6oF, on the maintainer's word) · 2026-09-18T22:09Z

Maintainer, chat 2026-09-18 (2026-09-18T21:40Z–2026-09-18T22:04Z), verbatim: 「18480 我总觉得写的很混乱,里面很多统计数据很容易飘逸,很多无关的内容。如果是需要功能清单,不应该是一份单独文档吗?还有平台的目标,是否需要类似北极星的单独文档」 → 「同意,北极星定稿,然后评估skills需要做哪些修改 136是否要关闭」 → 「其他同意」 (on the seat's proposal to close this PR unmerged). The two durable halves of ADR-0136 moved into the North Star (docs/NORTH-STAR.md, the maintainer's text: the developer path as the one measure, the priority rules); the capability inventory is the existing docs/qa/platform-checklist/, not a second document; the readings and rework history stay here as the record. docs/adr/PRIORITIZATION.md becomes a one-line pointer to the North Star in the enforcement PR (#18489, re-scoped). ADR number 0136 is left unused. Card #18477 closes with this PR.

---

Generated by Claude Code