intake: profile-bundle submissions cannot pass preflight (baseline drift + untested-state inventory gate)

[PerryLink]

Hello! First, thanks for the workshop — the intake pipeline is impressively strict. I'm reporting two issues that currently prevent any new profile-bundle submission from passing preflight. Evidence is from live runs and a local reproduction against main.

1. official-baseline.json has drifted from the public npm line

official-baseline.json still pins @deepseek-ai/dsh@0.1.0-rc.6 (checkedAt: 2026-08-14), while the npm latest tag has moved on (0.1.1-rc.2, now 0.1.2-rc.1). The weekly official-baseline job now fails every run, e.g. run 33380019719 (2026-08-31): Error: official runtime changed: expected 0.1.0-rc.6 sha512-..., received 0.1.1-rc.2 sha512-.... Every record currently in intake-queue.json (11) declares Exact @deepseek-ai/dsh@0.1.0-rc.6. Submissions honestly declaring the current public line (0.1.2-rc.1) therefore cannot align with the baseline.

2. A fresh profile-bundle record always breaks the public-site inventory gate

• createIntakeRecord (scripts/intake-lib.mjs) creates every new non-guided record with verification.state: 'untested'.
• check-public-site.mjs (line ~127) requires inventory.summary.verification.untested === catalog.packages.length - intake.records.length, but build-verification-inventory.mjs emits untested = catalog.packages.length - records_with_known_states — an off-by-one whenever any untested record is queued.
• Reproduction against main (Node 22): a manifest that passes node scripts/prepare-issue-intake.mjs cleanly then fails npm run check with verification inventory must cover every Catalog project, match exact Intake evidence, and grant no Registry admission; removing the new record from the queue makes npm run check green again (public site accepted: 680 catalog entries (11 reviewed)).
• Live effect: all 31 intake runs of 2026-09-02 and every run since failed at this gate (e.g. run 33641410450).

Questions

1. Will the official baseline be bumped to the current public line (0.1.2-rc.1), and is there a place to track it?
2. What is the intended path for profile-bundle submissions — wait for the baseline bump, or provide harness evidence to reach current-baseline-passed before the record is queued?
3. Should the untested-state counting be aligned between the inventory builder and the public-site check?

I have 100+ [Submission] issues already filed whose preflight failed (mostly on the restartRequired/lifecycle.activation consistency rules, which I've since corrected on my side); I'm holding resubmission until the pipeline can accept fresh profile-bundle records, to avoid generating more failing runs.

Thanks!

---

中文摘要：

1. official-baseline.json 仍钉 0.1.0-rc.6，npm latest 已到 0.1.2-rc.1，每周 official-baseline 定时任务持续失败（例：08-31 run 33380019719）。
2. 新 profile-bundle 记录初始 verification.state='untested'，而 check-public-site.mjs 与 build-verification-inventory.mjs 对 untested 的计数差 1，导致任何新 profile-bundle 提交必在 preflight 失败（本地 main 复现：prepare 通过、check 失败；移除新记录后 check 通过）。
3. 询问：基线何时更新到 0.1.2-rc.1？profile-bundle 提交的正确路径？untested 计数是否应统一？我方 100+ 个已投 issue 已自行修正清单错误，等管道恢复后再重投，避免产生更多失败 run。