`os init` template descriptions advertise views/actions/extensions that no template emits

[os-zhuang]

Found while working #9666 (init templates vs. the author-time rule set). Filed separately rather than fixed there: it is a different defect class — advertised-vs-emitted accuracy, not the OWD/rule-set defect that card is about — and the repair is a product call (reword, or actually emit the extra metadata), not a mechanical one.

The mismatch

packages/cli/src/commands/init.ts describes two of its three built-in templates as producing metadata kinds they never write:

template	advertised	actually emitted (srcFiles)
app	init.ts:105 — "Full application with objects, views, and actions"	src/objects/index.ts + src/objects/{namespace}_item.ts. No views, no actions.
plugin	init.ts:198 — "Reusable plugin with objects and extensions"	src/objects/index.ts + src/objects/{namespace}_item.ts. No extensions.
empty	init.ts:264 — "Minimal project with just a config file"	srcFiles: {} — accurate.

The published docs carry the same claim: content/docs/deployment/cli.mdx:104 lists the app template as "Full application with objects, views, barrel imports".

These strings are what os init --help and the docs table show a user at the moment they pick a template, so the inaccuracy is load-bearing: someone choosing -t app over -t empty to get a view scaffold gets objects only.

Control

Not a stale reading of an old tree — verified on origin/main at e196c6a9b. grep over both srcFiles maps returns exactly two entries each, both under src/objects/. The control that the query works: the same enumeration correctly reports empty as {}, and correctly finds the object files it does emit.

Two directions, needs a decision

1. Reword the descriptions (and the docs table) to match what is emitted — cheapest, and honest immediately.
2. Emit a starter view (and action) in the app template so the description becomes true — larger, and it widens what every generated project must keep passing the author-time rules (see os init -t app scaffold does not compile on CLI 17.0.0 — the template's own object trips the security-owd-unset author-time rule #9666, which makes init run those rules over its own output).

Option 1 is the safer default; option 2 is a scaffold-scope question worth a maintainer call, since the app template is the documented on-ramp and a view is arguably what makes it "full".

Whichever is chosen, content/docs/deployment/cli.mdx:104 moves with it.

Generated by Claude Code

[os-support-ai]

Triage (seat round, fire ~19:47Z 2026-08-18): lands in packages/cli/src/commands/init.ts + content/docs/deployment/cli.mdx ⇒ domain:cli. Type Bug — the template descriptions violate what the templates actually emit (declared ≠ enforced on the user-facing selection surface).

Auto-adjudicated (mechanical boundary test: rewording restores declared = enforced and expands no accept set or public surface ⇒ repair lane; option 2 would be a Feature and stays unchosen):

1. Platform long-term coherence — an honest description shrinks a false capability claim; emitting starter views/actions to make the claim true widens the scaffold surface every generated project must then keep passing the author-time rules (see os init -t app scaffold does not compile on CLI 17.0.0 — the template's own object trips the security-owd-unset author-time rule #9666). → option 1
2. Measured business pull — zero measured pull for a view/action scaffold (found by reading, not by a user report); the 2026-08-18 maintainer ruling on the same promise-vs-tool class (os migrate meta never rewrites the authored sources that 144 shipped retirement messages promise it will #9529) chose honesty-first rewording. → option 1
3. AI-agent error-resistance — a description matching emission prevents the wrong -t choice at the moment of choice; more emitted metadata is more surface generated projects must hold valid. → option 1
4. Startup scope discipline — reword-now beats declare-and-maintain; zero-pull capability expansion is ruled-against by default. → option 1

All four prisms same direction ⇒ option 1: reword the app/plugin descriptions and the cli.mdx:104 docs row to match actual emission. Option 2 (emit a starter view/action) is not foreclosed — it would be a separate Feature card needing maintainer appetite. Standing fork clause applies: if implementation finds the contract must move instead, stop and return the card. Dev control: re-verify both srcFiles maps on current origin/main before rewording (the card's own control @ e196c6a9b).

This round's report lists the adjudication (maintainer veto window).

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 22
Session: session_012WKSnqAaoqtW3QX7SSf1Vk
Branch: claude/issue-9737-init-template-descriptions-match-emission
Worktree: objectstack-issue-9737
Domain: domain:cli
File surface (region-level): packages/cli/src/commands/init.ts — the app and plugin template description strings only (⛔ not the srcFiles maps, ⛔ not the scaffold validator #9666 just landed) — and content/docs/deployment/cli.mdx, the template table row. Plus .changeset/**.
Container & model: S, mode:subagent, model: sonnet — tier derived this round from node scripts/pm/dispatch-gates.mjs --tier over both paths: no path-derived mandate (floor sonnet · default opus · ceiling fable), ⛔ not recalled. Held at the floor rather than the default because the judgment is already made: triage adjudicated the direction, and what remains is re-measure-then-reword, where correctness is decided by the measurement and the gate farm rather than by design.
Clause-②: no — triage's mechanical boundary test, which I agree with: rewording restores declared = enforced and expands no accept set and no public surface ⇒ repair lane. ⚠️ Option 2 (emit a starter view/action) would be a Feature and is ⛔ not chosen and ⛔ not to be drifted into.

Selection note — the native issue type decided this, not the labels or the age

Two cards were dispatchable this round. By labels neither looked like a bug (#9737 carries pm:queue+auto-adjudicated, #9672 carries documentation+pm:queue), and by card age #9672 would have won — it is five hours older.

⭐ #9737 is issue_type: **Bug** and #9672 is Task, so the total order puts type above age and this card goes first. Recording it because reading the type off the labels would have selected the wrong card, and that is the third time today the lane re-read has changed my answer.

Serial constraints cleared

• Same file — packages/cli/src/commands/init.ts is free. os init -t app scaffold does not compile on CLI 17.0.0 — the template's own object trips the security-owd-unset author-time rule #9666 (PR fix(cli): init scaffolds pass the author-time rules dev runs (OWD + scaffold rule set) #9736) merged at 10bbc1971; verified by probe (sharingModel 0 → 2 in that file). No other card or in-flight claim touches it.
• Same package — dispatched alongside i18n: a corrected source description never reaches an already-translated locale, and no gate can tell the stale translation from a current one #9672, which lands in packages/cli/src/commands/i18n/extract.ts and the bundle header template. Different files, permitted in parallel under the maintainer's 2026-08-18 exemption 「放开同包，同文件仍硬串行」; four replacement rules carried into both dispatches.
• Lane in flight at claim time: 0.

Carried into the dispatch

Triage's control instruction, verbatim: "re-verify both srcFiles maps on current origin/main before rewording (the card's own control @ e196c6a9b)." ⚠️ And init.ts has changed since that reading — #9666 landed in it hours ago — so the maps must be re-measured, not trusted.

⚠️ The docs row moves with the code, and content/docs/deployment/cli.mdx is an ordinary docs page. ⛔ content/docs/releases/ remains untouchable.

---

Generated by Claude Code