feat(spec)!: remove SkillSchema.permissions — it never gated anything (#3686) - #3704
Merged
Conversation
…#3686) Owner decision on the enforce-or-prune call: prune. skill.permissions was declared, surfaced in the Studio form under an "Access — Required permissions to use this skill" section, and echoed by the objectui preview — but no runtime read it. The cloud SkillRegistry selects skills by active/triggerConditions/tools only. A security-shaped field that enforces nothing invites an author (or an AI) to believe a skill is gated when it is not — same disposition as agent `visibility` (#1901) and PolicySchema (#2387). Removed: the schema property; the form's whole Access section (it existed only for this field); its generated i18n keys (surgically, not via a full extract rerun, which would drag in unrelated drift); the liveness-ledger entry + count table row; and the `permissions` line from the objectstack-ai skill doc — both its prop table (replaced by a migration note) and its os:check TS block, which compiles against the spec and would otherwise fail check:skill-examples. Added a regression test pinning that an authored `permissions` key is stripped (SkillSchema is non-strict, so it degrades silently rather than breaking boot). Verified: 6688 spec tests; check:liveness / check:docs / check:api-surface / check:skill-docs / check:skill-examples all green. Refs #3686, #1878. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
github-actions
Bot
added
documentation
Contributor
📓 Docs Drift CheckThis PR changes 2 package(s): 104 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
…ssions line Removing the `permissions` row from the objectstack-ai skill doc dropped its role-word count 6 -> 5; the ratchet requires the baseline to follow. Only that one entry changed (verified: no other file was whitewashed by --update). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ess section removal I removed the en keys by hand but left the other three locales stale; the translation-bundle drift gate caught it. Regeneration touched ONLY the skill access/permissions keys in the three locales (24 deletions, verified line by line — no unrelated blocks were rewritten). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Owner decision on the enforce-or-prune call filed in #3686: prune. Companion objectui PR: objectstack-ai/objectui#chore/drop-skill-permissions-preview.
Why prune rather than enforce
skill.permissionswas declared in the spec, surfaced in the Studio authoring form under a section labelled "Access — Required permissions to use this skill", and echoed by the objectui preview as a "N required perms" pill — while no runtime read it. The cloudSkillRegistryselects skills byactive/triggerConditions/toolsonly.That combination is the worst case for this platform's audience: an author (or an AI writing metadata) sees a security-shaped field with a security-shaped label and reasonably concludes the skill is gated. It is not. Same disposition as agent
visibility(#1901) and thePolicySchematree (#2387) — a security-shaped field that lies is dropped, not carried marked.Skill-level gating was a documented intent (cloud has a comment "Layer permissions via
Skill.permissionsindependent of the agent's permissions"), never an implementation. If it is wanted later it returns as a designed, enforced feature — the schema shape is trivial to re-add.Removed
permissionsproperty onSkillSchemaAccesssection (it existed only for this field)accesssection +permissionsfield keys, removed surgically — a fullextractrerun regenerates every existing block against the current schema and drags in unrelated driftskill 9/–/1→9/–/–)permissionsline inside theos:checkTypeScript block — that block compiles against the spec, so leaving it would failcheck:skill-examplesMigration — gate where it is actually enforced
access/permissionsondefineAgentare enforced at the chat route (403 when the caller lacks any, [P0][security] Agent access control is a no-op (permissions/visibility/access) #1884). Bind a restricted skill only to a restricted agent.SkillSchemais non-strict, so an existingpermissions:key is silently stripped on parse — no boot break. A new regression test pins that behaviour.Verification
6688 spec tests ·
check:liveness/check:docs/check:api-surface/check:skill-docs/check:skill-examplesall green.Not in this PR
agent.knowledge(the other half of #3686) is paused — not a priority this phase. It keeps the honestdead+authorWarnstate set in #3685, so authors get a warning rather than a false promise.Refs #3686, #1878, #3685.
🤖 Generated with Claude Code