Skip to content

os generate scaffolds four more artifact kinds os validate refuses — object, view, action and app #14336

Description

@os-trump

Found while implementing #14087 (the flow scaffold's own refusal). Triage on that card fenced a census of the OTHER generator artifacts out of it explicitly, so this is that census, filed separately rather than folded in. Unassigned.

What was measured

Every GENERATORS entry in packages/cli/src/commands/generate.ts was scaffolded for the name probe_thing, materialized through the same bundle-require path loadConfig uses, and put through the two steps Validate.run() performs on an authored stack — ObjectStackDefinitionSchema.safeParse after normalizeStackInput, then runAuthoringRules('validate'). Measured on origin/main d63c8a2:

kind verdict
object parses, then FAILS the author-time rules — security-owd-unset
view parse fails — views[0].list.pageSize, plus type / objectName on the view container
action parse fails — type: 'custom' is not an Action type; handler is not an Action key
flow parse fails — fixed by #14087
dashboard clean
skill clean
app parse fails — apps[0].navigation expects an array, the scaffold writes an object

Verbatim, the four that this card is about:

  • objectsecurity-owd-unset at objects[0].sharingModel: "custom object probe_thing 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 same rule that closed 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 for the os init -t app template; the os generate template was not moved with it.
  • viewUnrecognized key(s) on this list view: pageSize and Unrecognized key(s) on this view container: type, objectName, whose own guidance says the container's keys are list / form / listViews / formViews and that a single view's type must be wrapped.
  • actionInvalid option: expected one of "script"|"url"|"modal"|"flow"|"api"|"form" at actions[0].type (the scaffold writes custom), and Unrecognized key(s) on this action: handler.
  • appInvalid input: expected array, received object at apps[0].navigation (the scaffold writes { type: 'sidebar', items: [] }).

Why it is worth its own card

The argument #14087 makes applies to all of them without weakening: the generator is the path the docs point at, and a .strict() refusal enumerates what is allowed rather than saying where a key moved to. Four kinds are the majority of the roster.

The object one is worth separating from the other three when this is triaged. The other three are pure shape drift; object parses fine and is refused one layer later by a rule that is asking the author for a security decision — so "make the scaffold pass" there means choosing a default OWD to emit, which is an authoring decision rather than a mechanical repair. The neighbouring precedent (#9666, os init) is where that decision was already taken once.

The harness already exists

#14087 landed packages/cli/test/generate-scaffold-validates.test.ts, which runs this exact measurement over the derived generator roster on every CI lap. These four are recorded there in KNOWN_UNVALIDATED_SCAFFOLDS, a shrink-only ledger with an anti-staleness assertion: a kind in the ledger must still FAIL, so whoever repairs one of these turns that test red and deletes its entry in the same PR. There is nothing to build here — repair the template, delete the line.

Filed unassigned, domain:* left blank per the single-producer rule.

Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions