`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

[os-zhuang]

Found while measuring CLI output for the ObjectOS docs (objectstack-ai/objectos#94). Different defect class from that card — filed here because the fix lands in this repo, not in the docs.

Measured

latest on npm is 17.0.0 (npm view @objectstack/cli dist-tags gives {"latest":"17.0.0","rc":"17.0.0-rc.6"}), so this is what a reader following the published quickstart gets.

npx @objectstack/cli@17.0.0 init my-app -t app --install # exit 0, scaffold validated
cd my-app && npm run dev # -> objectstack dev

The scaffold is created and self-validates at init time:

 → Validating scaffold...
 ✓ Scaffold validated (namespace: my_app)
 ✓ Project initialized!

But the very first dev run fails to compile:

 → Running author-time rules (40)...

 ✗ Author-time rules failed (1 issue)
 • object "my_app_item": custom object "my_app_item" declares no sharingModel (OWD). The runtime fails CLOSED to 'private' (ADR-0090 D1), but the baseline must be an authored decision, not an accident — this is the exact shape of the leave_request incident (objectui#2348).
 Declare sharingModel explicitly: 'private' (owner + shares; recommended default), 'public_read', 'public_read_write', or 'controlled_by_parent' (master-detail children).
 rule: security-owd-unset at objects[0].sharingModel
 ✗ Compile failed — fix errors above before starting dev server

The dev server never starts. There is no readiness banner to reach.

Cause

The -t app template emits src/objects/my_app_item.ts with no sharingModel:

import * as Data from '@objectstack/spec/data';

const myAppItem: Data.Object = {
 name: 'my_app_item',
 label: 'My App Item',
 fields: {
 name: { type: 'text', label: 'Name', required: true },
 description: { type: 'textarea', label: 'Description' },
 status: { type: 'select', label: 'Status', options: [ /* … */ ], defaultValue: 'draft' },
 },
};

export default myAppItem;

security-owd-unset is one of the 40 author-time rules the same CLI ships and runs. So the shipped template and the shipped rule set disagree: the scaffold the CLI writes is rejected by the validation the CLI runs.

Why the init-time check did not catch it

init prints ✓ Scaffold validated, which reads as "this project is good to go". Whatever that step checks, it is not the author-time rule set that dev runs a moment later. That gap is arguably the more interesting half of this report — a scaffold validator that green-lights a scaffold the next command rejects will keep letting template regressions ship.

Suggested shape

Two independent fixes, and I think both are wanted:

1. The template declares sharingModel: 'private' — the rule's own recommended default, and the authored-decision baseline ADR-0090 D1 is asking for. One line.
2. init's scaffold validation runs the author-time rules, so a template that cannot compile fails at the point it is generated rather than at the user's first dev.

Impact

The documented developer on-ramp is dead on the current published CLI. os start (the operator path) is unaffected — it boots fine; only the init + dev path is broken.

Filed unassigned for triage. Back-link: objectstack-ai/objectos#94.

---

Generated by Claude Code

[os-support-ai]

Triage: lands in packages/cli (the -t app init template + the init-time scaffold validation) → domain:cli, type Bug, promoted to pm:queue. Dedup: searched security-owd-unset / scaffold-compile family — no open duplicate (#9698 is a different lint gap; #7503 closed, different rule).

Added target:v17: this is a tier-① release blocker by the board's binary test — the published 17.0.0 quickstart path (init → dev) is dead on first run for every new user today, measured on the npm latest tag.

Both suggested fixes belong to one card: (1) template declares sharingModel: 'private' (one line, the rule's own recommended default — restores the declared on-ramp, no contract change); (2) init's scaffold validation runs the author-time rule set so template regressions fail at generation. Fix (2) is validation-strengthening, not an accept-set expansion.

Size/model suggestion: S–M, mode:subagent.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 20
Session: session_012WKSnqAaoqtW3QX7SSf1Vk
Branch: claude/issue-9666-init-template-owd-and-scaffold-rules
Worktree: objectstack-issue-9666
Domain: domain:cli
File surface (region-level): packages/cli/src/commands/init.ts — two regions: the template srcFiles map(s), and the Validating scaffold… step. Plus its test and .changeset/**. ⛔ Nothing else in packages/cli.
Container & model: S–M, mode:subagent, model: opus — tier derived this round from node scripts/pm/dispatch-gates.mjs --tier packages/cli/src/commands/init.ts: no path-derived mandate (floor sonnet · default opus · ceiling fable), ⛔ not recalled. Held at default rather than the floor because fix (2) needs a judgment call about scope (below), not just an edit.
Clause-②: no, and I agree with triage's reasoning rather than restating it: fix (1) is template content; fix (2) is validation-strengthening. Nothing that compiles today stops compiling — the rules fix (2) adds to init are the same set dev already runs a moment later. ⛔ This card is not covered by the maintainer's one-time opus downgrade (which named #9446/#9416/#9462/#9488/#9487); it sits at default opus on its own terms.

Premise re-verified on origin/main — the defect is live here, not only on published 17.0.0

The card measured npm latest = 17.0.0. That is a different tree from main, so I re-derived rather than assuming the report transfers:

reading	result
sharingModel in packages/cli/src/commands/init.ts	0 occurrences — the defect is live on main
control: create-objectstack's blank template note.object.ts	1 — so the property exists and is used elsewhere; the zero above is a real absence, not a broken query
where the app template actually lives	inline in init.ts (srcFiles at :154, :228, :283) — ⚠️ not in packages/create-objectstack/src/templates/, where a directory scan looks first and finds nothing
the init-time validator	init.ts:541 printStep('Validating scaffold...') → :552 printSuccess('Scaffold validated…')

⚠️ That third row is the trap worth naming: searching templates/ for the app template returns nothing, and a dev who stops there could conclude the card is stale. It is not — the template is emitted from a srcFiles map inside init.ts.

Selection note — this card outranked the two I had been calling "next"

Under the lane's total order, target: board items rank above type Bug. #9666 arrived at 14:39:38Z while rest-server.ts was still held by #9454, and it outranks #9488 and #9487, which I had been describing as the next dispatches all afternoon.

⭐ Recording it because the rule earned its keep: re-reading the whole lane before selecting is what caught this. Selecting from my own stated plan would have taken the wrong card, and that is the same error I made earlier today on #9454 — the one I said I had learned from.

Serial constraints cleared:

• Same file — no other card or in-flight claim touches packages/cli/src/commands/init.ts. Lane in flight at claim time: 0.
• Same package (packages/cli) — permitted in parallel under the maintainer's 2026-08-18 exemption 「放开同包，同文件仍硬串行」; replacement discipline carried into the dispatch (region surface · merge main before the PR · merge again if a sibling lands · conflicts to the queue, ⛔ not hand-ordered).
• Dispatched alongside Every 401 answers {error, message} with no code key, while every other error family carries {error, code} #9487 (packages/rest/src/rest-server.ts) — different package, different file, no read coupling.

---

Generated by Claude Code