QA-source: #21318 · path step ① (write metadata)
On a fresh npm create objectstack@17.6.0 tasks-app (namespace tasks_app) with objects tasks_app_project and tasks_app_task generated by os g object project / os g object task:
npx os g flow task_done writes src/flows/task_done.flow.ts whose start node has config.objectName: 'tasks_app_task_done' — derived from the flow name, an object that does not exist — and prints ✓ Reaches the stack. os validate then exits 0 with only a warning: flow "task_done_flow" › start node: targets object 'tasks_app_task_done', which this stack does not define — if the name is wrong, the flow will never fire (and the runtime stays silent about it). The generator itself wrote the silent failure.
npx os g view task writes a views container with top-level name, label, object and a list without label. os validate passes but flags "view tasks_app_task: sets name … no runtime effect (liveness: dead)" and the same for label; os lint exits 1: ✗ View "tasks_app_task" is missing a label required/label at views[0].list.label. The generated file's own comment says the server refuses a container whose name disagrees, while validate calls the key dead — the two cannot both be right.
npx os g action complete_task and npx os g app tasks derive the target object from the NAME (tasks_app_complete_task, tasks_app_tasks) and are refused by the cross-reference check (Action 'complete_task' references object 'tasks_app_complete_task' which is not defined in objects / references flow 'complete_task_flow'), exit 1, nothing written. os g --help offers no flag to name an existing object, so the generator can only scaffold an action or app for an object that shares its name.
Expected
Every os generate output passes os validate AND os lint on the project it was generated into, and targets real metadata (or asks / takes --object). A generator that writes a never-firing flow or a lint-refused view teaches the AI author the wrong shape on its first step.
Generated by Claude Code
QA-source: #21318 · path step ① (write metadata)
On a fresh
npm create objectstack@17.6.0 tasks-app(namespacetasks_app) with objectstasks_app_projectandtasks_app_taskgenerated byos g object project/os g object task:npx os g flow task_donewritessrc/flows/task_done.flow.tswhose start node hasconfig.objectName: 'tasks_app_task_done'— derived from the flow name, an object that does not exist — and prints✓ Reaches the stack.os validatethen exits 0 with only a warning:flow "task_done_flow" › start node: targets object 'tasks_app_task_done', which this stack does not define — if the name is wrong, the flow will never fire (and the runtime stays silent about it).The generator itself wrote the silent failure.npx os g view taskwrites a views container with top-levelname,label,objectand alistwithoutlabel.os validatepasses but flags "view tasks_app_task: sets name … no runtime effect (liveness: dead)" and the same for label;os lintexits 1:✗ View "tasks_app_task" is missing a label required/label at views[0].list.label. The generated file's own comment says the server refuses a container whosenamedisagrees, while validate calls the key dead — the two cannot both be right.npx os g action complete_taskandnpx os g app tasksderive the target object from the NAME (tasks_app_complete_task,tasks_app_tasks) and are refused by the cross-reference check (Action 'complete_task' references object 'tasks_app_complete_task' which is not defined in objects/references flow 'complete_task_flow'), exit 1, nothing written.os g --helpoffers no flag to name an existing object, so the generator can only scaffold an action or app for an object that shares its name.Expected
Every
os generateoutput passesos validateANDos linton the project it was generated into, and targets real metadata (or asks / takes--object). A generator that writes a never-firing flow or a lint-refused view teaches the AI author the wrong shape on its first step.Generated by Claude Code