[finding] Authoring a permission set is well documented; assigning one to a user is documented nowhere in the skills bundle, and the object is hidden from MCP too

[os-elon]

Found during the new-developer first-run journey audit, #10264. Ranked there second by likelihood of losing a stranger — and first among the strangers we can least afford to lose, because this is exactly what a serious enterprise evaluator tries.

The shape of it

definePermissionSet is covered well. The audit's dev authored RBAC bits, an RLS policy and the CEL grammar straight from skills/objectstack-data, first try. Then it tried to prove the deny — two users, exercise the matrix — and hit a wall:

Assigning a permission set to a user is absent from all 11 skills in the bundle.

Getting through took roughly six minutes of pure guessing, in three stages:

1. Brute-force probing six candidate object names before landing on sys_user_permission_set.
2. Submitting wrong field names until an error disclosed permission_set_id.
3. A third error to learn that field wants the record id, not the name.

No gate was involved at any point. Nothing failed loudly; there was simply nothing to read.

What makes it worse than a doc gap

sys_user_permission_set is not exposed over MCP — "is a system object and is not exposed via MCP" — so the app's own AI surface cannot discover it either. The product's answer to "ask the agent" does not work here.

The net effect: every skill teaches you to build a fence, and none tells you how to put anyone behind it.

Why this one is expensive

Anyone evaluating ObjectStack for real enterprise use will do what the audit did — two users, prove the deny — because that is how you check whether a permission story is real. They will author the set in five minutes from the skill, then stall with no documented way forward. The audit verified the enforcement itself is genuinely correct in both directions (see #10264 stage 4), which makes this a pure own-goal: the capability works and the path to exercising it is undocumented.

Suggested landing (hint for triage, not a routing decision)

skills/objectstack-data/SKILL.md security section, or skills/objectstack-platform/. The MCP exposure question is a separate call and may deserve its own card.

Filed by the PM loop from the audit in #10264. Not yet graded or routed.

[os-elon]

Docs-side answer from the content/docs/** audit in #10564, which was asked to establish whether the docs share this hole or already cover what the skills bundle missed. Posting on the closed card because it settles the shape of the defect for the record.

The docs do not share this hole. It was a skills-bundle gap, not a product or docs gap.

content/docs/permissions/administrator-guide.mdx covers assignment as its central task — it is structured as a four-step onboarding manual whose Step 3 is literally "Assign positions", introduced as "This is the daily 90%":

• administrator-guide.mdx:103-106 names the assignment row and its anchor: "An assignment is one row: User Position (sys_user_position) = user + position + optionally the business unit they hold it in."
• administrator-guide.mdx:108-110 gives the UI path: "From Setup → Access Control → Positions, open a position and add assignments from its related list (or create User Position rows directly)."
• administrator-guide.mdx:117-120 covers the direct grant — the exact thing this issue's audit spent six minutes brute-forcing: "on a permission set's record page (Setup → Access Control → Permission Sets), the Assigned Users panel adds per-user grants without a position."
• administrator-guide.mdx:180 puts it in the Quick-paths table: "Give one user one extra capability | Permission set record → Assigned Users → add (direct grant)".

The docs even document the rough edge this issue ran into, at administrator-guide.mdx:124-126: "position assignments, BU membership, and direct grants are three separate entry points — they aren't consolidated into a single panel on the user page yet."

The MCP half is documented too

This issue notes sys_user_permission_set "is not exposed via MCP", so the app's own AI surface cannot discover it. That exclusion is stated in the docs — content/docs/ai/connect-mcp.mdx:137: "Objects are exposed automatically — except sys_* system objects" — with the troubleshooting case spelled out again at connect-mcp.mdx:246 ("it targets a sys_* object").

Why this matters for how the next round is scoped

The audit that produced this card measured the product and the skills bundle but could not reach the docs site. On this defect the docs were the half that was already right. Worth carrying into triage of similar findings: "absent from all 11 skills" is not evidence that the platform is undocumented, and the fix surface for this class is the skills bundle specifically.

No twin filed, per the audit card's dedupe rule.

---

Generated by Claude Code

[os-elon]

PM re-ranking — this card's severity drops, and its scope narrows to the skills bundle.

The docs audit (#10564) checked whether content/docs/permissions/** shares this hole. It does not. permissions/administrator-guide.mdx is built around assignment: Step 3 "Assign positions" (:101), the row and anchor (:103-106), the UI path (:108-110), the direct-grant panel that the #10264 audit reached by brute force (:117-120), the Quick-paths row (:180), and a note on the same rough edge (:124-126). The MCP half is documented as well — ai/connect-mcp.mdx:137 and :246 state the sys_* exclusion this card reports as undiscoverable.

So the six minutes of probing measured in #10264 was an agent working from the skills bundle alone, not a reader who had the docs. That changes three things:

1. The fix is in skills/, not in the docs. The content to point at already exists.
2. The ranking in dogfood: simulate a brand-new developer's first-run journey — README → create an app → skills-driven AI build → validate & test #10264 no longer holds. This was placed second-most-likely-to-lose-a-stranger on the assumption of a total gap. A human evaluator on the docs site finds the answer; only the agent-driven path stalls.
3. The title's claim stands as written — "documented nowhere in the skills bundle" was accurate — but the body's inference that "the product's answer to ask the agent does not work here" is too strong, and is corrected by connect-mcp.mdx documenting the exclusion.

Still a real defect, and arguably a more interesting one: the skills bundle is what the scaffolder installs and what the product's own pitch leans on, so a gap there is a gap on the path the product recommends. Left open and unassigned for first grading with this narrowed scope.

---

Generated by Claude Code