Found during the new-developer first-run journey audit, #10264. This was the audit's only hard validation failure across the whole business-app build — one correction round, not a blocker.
What happened
The skills bundle enumerates defineStack keys as apps, actions, flows, pages, translations, views, functions, hooks, objectExtensions. permissions is never named. Having authored a permission set correctly from the skill, the dev guessed permissionSets from the type surface — the plausible guess, and wrong.
The gate caught it, and caught it beautifully
✗ (root): Unrecognized key(s) on this stack definition: `permissionSets`.
Did you mean `permissionSets` → `permissions`? Until #8687 closed this surface
(the outermost #4001 door), an unknown top-level stack key parsed green and its
value was silently dropped — a one-character typo could ship an artifact missing
a whole metadata family while `os validate` exited 0. The declared keys are
enumerated by `ObjectStackDefinitionSchema` (@objectstack/spec, stack.zod.ts).
Located, corrective, self-fixable in seconds, and it names its own ground truth. The audit called this out as the README's central claim about typed errors holding up under test.
Why file it anyway
The gate turns a guaranteed stumble into a cheap one — it does not remove it. Every author who reaches for permission sets from the skills alone will make this same guess, because the skill hands them a list of keys that does not contain the one they need. The fix is roughly one word in an enumeration.
Related but distinct
#9907 (closed) covered objectstack-platform still teaching that an unknown top-level key is silently stripped, which #8687 changed. This finding is the different half: not that the documented behaviour is stale, but that the key itself is missing from the list. Worth reading together.
Suggested landing (hint for triage, not a routing decision)
skills/objectstack-data/SKILL.md, security section — plus a check of whether the same enumeration is duplicated in objectstack-platform and elsewhere in the bundle, since a list that omits one key probably omits it in more than one file.
Filed by the PM loop from the audit in #10264. Not yet graded or routed.
Found during the new-developer first-run journey audit, #10264. This was the audit's only hard validation failure across the whole business-app build — one correction round, not a blocker.
What happened
The skills bundle enumerates
defineStackkeys asapps,actions,flows,pages,translations,views,functions,hooks,objectExtensions.permissionsis never named. Having authored a permission set correctly from the skill, the dev guessedpermissionSetsfrom the type surface — the plausible guess, and wrong.The gate caught it, and caught it beautifully
Located, corrective, self-fixable in seconds, and it names its own ground truth. The audit called this out as the README's central claim about typed errors holding up under test.
Why file it anyway
The gate turns a guaranteed stumble into a cheap one — it does not remove it. Every author who reaches for permission sets from the skills alone will make this same guess, because the skill hands them a list of keys that does not contain the one they need. The fix is roughly one word in an enumeration.
Related but distinct
#9907 (closed) covered
objectstack-platformstill teaching that an unknown top-level key is silently stripped, which #8687 changed. This finding is the different half: not that the documented behaviour is stale, but that the key itself is missing from the list. Worth reading together.Suggested landing (hint for triage, not a routing decision)
skills/objectstack-data/SKILL.md, security section — plus a check of whether the same enumeration is duplicated inobjectstack-platformand elsewhere in the bundle, since a list that omits one key probably omits it in more than one file.Filed by the PM loop from the audit in #10264. Not yet graded or routed.