You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filed by the domain:cli execution seat (session session_016yfqQh2dBgPAymYd7xipza) as the follow-up that #14705's triage explicitly ruled out of that card's scope — "a CLI-surface decision that is neither the card's nor the implementer's". Filed unassigned and bare: ⛔ this seat is not grading it and has set no domain:* (that is triage's single-producer field). Routing looks obviously domain:cli; please confirm it rather than inherit it.
The observation
This repo ships two project scaffolders, and #14705 was the drift between them having already happened.
os init — three templates, a documented on-ramp, its own pin suite, and the identity block (id, namespace, type, engines.protocol) that ManifestSchema requires.
os create — two templates, one of which (example) emitted a manifest that failed ManifestSchema: defineStack validation failed (2 issues): manifest.id: Required property 'id' is missing. / manifest.type: Invalid value ''. Every scaffolded project threw on load. Fixed by PR fix(cli): stamp the manifest identity block in the os create example scaffold #14821, which also lands a pin sweeping both scaffolders from their own template maps rather than a hand-copied list.
So the immediate defect is closed and pinned. The question this card records is whether the shape that produced it should persist.
Two measured facts, from #14705's implementation seat
Both are the kind that decide the question rather than colour it:
os create's output is not installable outside this monorepo. Its emitted package.json uses workspace:* for @objectstack/spec and @objectstack/cli, and its tsconfig.json extends '../../tsconfig.json'. It also writes into this repo's own packages/plugins/ or examples/ by default.
os create's plugin template emits no objectstack.config.ts at all — it scaffolds a Plugin object in src/index.ts. So example is the only create template ManifestSchema governs, which is why the failure could sit there unnoticed.
⇒ Fact 1 is evidence that os create is already, in practice, a monorepo-internal generator — while content/docs/deployment/cli.mdx and two places in the kernel protocol docs present it as a user-facing command. A user who follows those docs gets a project that cannot install.
The options, as named on #14705 (⛔ not graded, not recommended here)
A — keep both. create is documented, the template is now correct, nothing is foreclosed. The recurring cost is the drift this card names, now with a pin under it.
B — retire os create in favour of os init, with a deprecation notice and a docs migration, on the ground that two scaffolders drift.
C — narrow os create to what it demonstrably already is — a generator for this repo's own packages/ and examples/ — and say so in its description and the docs, leaving os init the only user-facing scaffolder.
Fact 1 is evidence for C over B specifically: retiring a command that has a real internal use is a different act from correcting a command whose documented audience does not match its output.
What this card is asking for
First grading. If it is graded queueable, the dispatchable unit is a measurement plus the four-facet block (the #14749 shape), not an implementation — who invokes os create today, what the docs promise, and what a deprecation or a narrowing would cost — with A/B/C reserved for the maintainer's inbox.
⛔ Not a Bug: the manifest defect is fixed and pinned by PR #14821, and nothing here is currently broken for a user who uses os init. It is the two-scaffolder shape that is being recorded, not a live failure.
Related: #14705 (the defect and its triage ruling), PR #14821 (the fix and the both-scaffolder pin), #14823 (the create-shipped comments are checked by nothing — filed by the same seat, same round).
Filed by the
domain:cliexecution seat (sessionsession_016yfqQh2dBgPAymYd7xipza) as the follow-up that #14705's triage explicitly ruled out of that card's scope — "a CLI-surface decision that is neither the card's nor the implementer's". Filed unassigned and bare: ⛔ this seat is not grading it and has set nodomain:*(that is triage's single-producer field). Routing looks obviouslydomain:cli; please confirm it rather than inherit it.The observation
This repo ships two project scaffolders, and #14705 was the drift between them having already happened.
os init— three templates, a documented on-ramp, its own pin suite, and the identity block (id,namespace,type,engines.protocol) thatManifestSchemarequires.os create— two templates, one of which (example) emitted a manifest that failedManifestSchema:defineStack validation failed (2 issues): manifest.id: Required property 'id' is missing. / manifest.type: Invalid value ''.Every scaffolded project threw on load. Fixed by PR fix(cli): stamp the manifest identity block in theos createexample scaffold #14821, which also lands a pin sweeping both scaffolders from their own template maps rather than a hand-copied list.So the immediate defect is closed and pinned. The question this card records is whether the shape that produced it should persist.
Two measured facts, from #14705's implementation seat
Both are the kind that decide the question rather than colour it:
os create's output is not installable outside this monorepo. Its emittedpackage.jsonusesworkspace:*for@objectstack/specand@objectstack/cli, and itstsconfig.jsonextends'../../tsconfig.json'. It also writes into this repo's ownpackages/plugins/orexamples/by default.os create'splugintemplate emits noobjectstack.config.tsat all — it scaffolds aPluginobject insrc/index.ts. Soexampleis the onlycreatetemplateManifestSchemagoverns, which is why the failure could sit there unnoticed.⇒ Fact 1 is evidence that
os createis already, in practice, a monorepo-internal generator — whilecontent/docs/deployment/cli.mdxand two places in the kernel protocol docs present it as a user-facing command. A user who follows those docs gets a project that cannot install.The options, as named on #14705 (⛔ not graded, not recommended here)
createis documented, the template is now correct, nothing is foreclosed. The recurring cost is the drift this card names, now with a pin under it.os createin favour ofos init, with a deprecation notice and a docs migration, on the ground that two scaffolders drift.os createto what it demonstrably already is — a generator for this repo's ownpackages/andexamples/— and say so in its description and the docs, leavingos initthe only user-facing scaffolder.Fact 1 is evidence for C over B specifically: retiring a command that has a real internal use is a different act from correcting a command whose documented audience does not match its output.
What this card is asking for
First grading. If it is graded queueable, the dispatchable unit is a measurement plus the four-facet block (the #14749 shape), not an implementation — who invokes
os createtoday, what the docs promise, and what a deprecation or a narrowing would cost — with A/B/C reserved for the maintainer's inbox.⛔ Not a
Bug: the manifest defect is fixed and pinned by PR #14821, and nothing here is currently broken for a user who usesos init. It is the two-scaffolder shape that is being recorded, not a live failure.Related: #14705 (the defect and its triage ruling), PR #14821 (the fix and the both-scaffolder pin), #14823 (the
create-shipped comments are checked by nothing — filed by the same seat, same round).