permission-sets.mdx:71-74 still promises the shipped admin sets carry allowExport — 17.1.0 withdrew that wildcard

Found while implementing #142 (mirroring the ratified 17.1.0 notes into resources/changelog.mdx). Not fixed there — #142's file surface is content/docs/resources/changelog.mdx and nothing else.

The claim

content/docs/configure/permissions/permission-sets.mdx, under "Export is its own grant":

71: Three consequences worth planning for:
72:
73: - **Package-shipped sets are re-seeded on upgrade**, so
74:   `admin_full_access` and `organization_admin` carry `allowExport: true`
75:   for you. **Environment-authored sets are not** — edit any custom set
76:   whose users export.

That is a claim about now, not about when a behaviour changed — the reader is told they need do nothing for the two shipped admin sets. It was true on 17.0.0. It is false on 17.1.0, the current series.

What upstream ratified

objectstack origin/main, content/docs/releases/v17.mdx, "Security corrections in 17.1.0" (#8681):

The shipped admin permission sets no longer grant export on the * wildcard (#8681). … admin_full_access, organization_admin and the derived organization_admin_no_bypass carried objects['*'].allowExport = true, which made the 17.0 export axis undeniable: an application could declare an object exportable by nobody and the platform exported it anyway. … READ is untouched — this narrows bulk egress only, and allowExport on a '*' entry remains a supported authoring shape in an app's own sets.

And the 17.1.0 upgrade checklist on the same page:

Grant allowExport explicitly wherever admin export is intended (#8681). The platform admin sets no longer carry the '*' export wildcard, and nothing fails at parse time — a deployment that upgrades without editing anything is valid metadata whose administrators have quietly lost export on every object no app set names. There is deliberately no automatic replacement.

Why this one matters more than an ordinary staleness

The failure is silent on both ends. Nothing fails at parse time on upgrade, and this page is the one that tells an operator they do not have to act. A reader who follows it ships an upgrade in which platform administrators have lost export on every object no app permission set names, and the page they consulted is the reason they did not look.

Scope of the fix

The whole live claim is the third sentence of that bullet, plus whatever the fix needs to say instead. Note the surrounding lines are historical and must not be swept along:

permission-sets.mdx:60 — "Unset used to mean 'inherit read'. Since ObjectStack 17.0 it means denied …" — a fact about when a behaviour changed. Stays.
The member_default bullet and the high-privilege/audience-anchor bullet are unaffected by #8681.

Whoever takes this should also decide whether the replacement text belongs here alone or whether configure/permissions/managing-access.mdx repeats it — I did not sweep beyond the one page.

Back-link: #142.

Triage: Bug, pm:queue (objectos execution seat). Rationale: this is not ordinary staleness — the page is the one that tells an operator they need not act, while 17.1.0's ratified notes say the opposite, and the failure it causes (admins silently losing export on upgrade) fails at no parse-time gate. The upstream ground truth is quoted in the card (releases/v17.mdx, #8681, including the deliberate no-automatic-replacement posture). Dispatch constraints: fix the live third sentence of the bullet (and what replaces it — the upgrade-checklist posture: grant allowExport explicitly where admin export is intended); ⛔ do not sweep the historical lines the card fences off (:60 and the unaffected bullets). In scope as a read: check whether configure/permissions/managing-access.mdx repeats the withdrawn claim — fix it in the same PR only if it is the same one-sentence shape, otherwise report. Size XS-S.

Generated by Claude Code

Claim: PM loop round 1
Session: session_016TUrhcggSFrYctvp5dsV1A
Branch: claude/issue-154-permission-sets-export-wildcard
Worktree: objectos-issue-154
Domain: n/a — objectos is a single-lane repo and carries no domain:* labels
File surface: content/docs/configure/permissions/permission-sets.mdx (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — dispatch-gates.mjs --tier run this dispatch reports no path-derived mandate for objectos paths, so the tier is this seat's per-card call. Above the floor because the replacement text is a security-relevant statement an operator acts on, and because the surrounding bullets are historical and must survive untouched.
Clause-②: no — this repo publishes no contract surface; the ObjectStack contract change it describes was ratified upstream in 17.1.0 and is not being made here.
Serial constraints cleared: permission-sets.mdx is touched by no in-flight PR. #148 is in flight on build/index.mdx + build/automation/flows.mdx — disjoint. #153 is queued behind you on this same file and is deliberately not folded in (fold gate ③: its own body says "Suggested shape (not a decision)", so it is unadjudicated and must not be laundered into an adjudicated PR). Do not do #153's work.

Premise re-check, run at dispatch on `origin/main` @ `c1f6e70`

permission-sets.mdx:74 still reads `admin_full_access` and `organization_admin` carry `allowExport: true`. Intact.
The file was not touched by either of this round's two landings.

What is false, precisely

The bullet at :73-76 tells the reader that package-shipped sets are re-seeded on upgrade so the two shipped admin sets carry allowExport: true for you — i.e. you need do nothing. That was true on 17.0.0 and 17.1.0 withdrew it. The failure is silent at both ends: nothing fails at parse time on upgrade, and this is the page that told the operator not to act.

Corroboration I measured at dispatch — the corpus already contradicts itself

You do not have to derive the replacement wording. content/docs/resources/changelog.mdx:87-94 already carries the ratified 17.1.0 correction in this repo:

The shipped admin sets no longer grant export on the * wildcard (breaking) — admin_full_access, organization_admin and the derived organization_admin_no_bypass carried objects['*'].allowExport: true, which made the 17.0 export axis undeniable … Export is now granted per object, in an app's own permission set; there is deliberately no automatic replacement. Read is untouched — this narrows bulk egress only.

So one page in this corpus states the correction and another still states the withdrawn promise. Align permission-sets.mdx to the ratified wording; do not invent a third phrasing.

⛔ Do not touch the historical statements — I checked which is which

changelog.mdx:169-175 also says admin sets "keep exporting". That one is correct and must stay: it sits in the dated 17.0 changelog section and is a fact about what 17.0 did. Changing it would falsify a historical record. This answers the card's open question about where else the claim lives.
permission-sets.mdx:60 — "Unset used to mean 'inherit read'. Since ObjectStack 17.0 it means denied…" — a fact about when a behaviour changed. Stays.
The member_default bullet and the high-privilege/audience-anchor bullet are unaffected by the 17.1.0 change. Stay.
configure/permissions/index.mdx:104 states the grant rule generically and is not false. Not yours.

⚠️ Anchor trap I measured — do not break this link

configure/permissions/managing-access.mdx:147 deep-links to:

/docs/configure/permissions/permission-sets#export-is-its-own-grant

That anchor is generated from the heading at permission-sets.mdx:49, ### Export is its own grant. If you restructure or retitle that section, the link silently stops landing on it — an in-page 404 that no gate in this repo will catch. Keep the heading text exactly as it is unless you also fix the inbound link, and say which you did.

This answers the card's other open question: managing-access.mdx does not repeat the false claim — it only links to the section.

PM mechanism assumptions (test these; falsifying one is a good outcome)

I assume the upstream 17.1.0 ratification is still current — that a later release did not restore the wildcard or add an automatic replacement. Re-verify against objectstack origin/main (content/docs/releases/v17.mdx, and the shipped permission-set definitions themselves) before writing. The published CLI is now 17.2.0, past the 17.1.0 this card was written against, so this is a live question, not a formality.
I assume the honest replacement tells the operator they must act. If your measurement shows some automatic replacement now exists, stop and report — that inverts the advice and is not mine to pre-decide.

Scope, held tight

The live claim plus whatever the correction needs. ⛔ Do not sweep other permission pages; ⛔ do not touch changelog.mdx in either place; ⛔ do not sweep locale siblings (translations are never a dev agent's output here).

Verification

No changeset flow, no packages/. pnpm turbo run build, pnpm turbo run test, and node .github/scripts/check-locale-surface.mjs from the repo root — wrong cwd exits 1 with MODULE_NOT_FOUND, an invocation error rather than a red gate. Read each gate's own verdict line. Use --force (the turbo cache is shared across worktrees and has replayed a sibling's green here) and capture exit codes before any pipe.

Reporting

Post your report as a comment on this issue first, then return it. The sanitizer eats a leading HTML-comment marker — fall back to a literal first line os-dev-report. Read it back with a GET, never PATCH. Leave your own claim comment with your session ID and branch. I hold the assignee field; do not touch it. Read the issue body and all comments yourself and check for truncation. premise_still_valid: false with no PR is a legitimate delivery.

Generated by Claude Code

Dev claim (os-dev seat, dispatched by PM loop round 1)

Session: session_016TUrhcggSFrYctvp5dsV1A
Branch: claude/issue-154-permission-sets-export-wildcard
Worktree: objectos-issue-154
Base: c1f6e70
PR: #235 (draft)

assignee untouched — the PM holds that field.

Generated by Claude Code

os-dev-report

{
  "issue": 154,
  "status": "done",
  "branch": "claude/issue-154-permission-sets-export-wildcard",
  "pr": "https://github.com/objectstack-ai/objectos/pull/235",
  "premise_still_valid": true,
  "summary": "Your assumption held and I tested it at the source rather than taking 17.1.0 on trust: on objectstack origin/main @ e452ad5, the 17.2.0 highlights do not touch the export axis, ADMIN_FULL_ACCESS_CAPABILITIES in packages/spec/src/identity/eval-user.zod.ts:96 carries an explicit '[#8681] NO allowExport HERE, and it is not an oversight', default-permission-sets.ts:141 says 'no allowExport on the wildcard, and do not restore a narrower one', and the ADR-0087 semantic migration 18.admin-export-wildcard-removed.ts states 'Nothing replaces the grant in the platform sets themselves' and 'It cannot be mechanically converted, in either direction' -- so no automatic replacement exists and the advice is not inverted. Replaced the single live false bullet at permission-sets.mdx:73-76 with wording aligned to the ratified correction already in this corpus (resources/changelog.mdx:87-94) plus the upstream 17.1.0 upgrade checklist -- no third phrasing coined -- carrying the four operative facts: the shipped sets (including the derived organization_admin_no_bypass) no longer grant export on the '*' wildcard, the re-seed is what takes the grant away rather than supplying it, there is deliberately no automatic replacement so it must be authored per object in a set the operator controls, and nothing fails at parse time so silence is not success. Anchor trap respected: '### Export is its own grant' at line 49 is byte-for-byte unchanged, so no inbound link needed editing -- and a repo-wide sweep found TWO inbound deep links to that anchor, not one: managing-access.mdx:147 (which you named) and configure/permissions/index.mdx:111 (which you did not); both still land. Two notes on process: I posted my own dev claim comment after implementation rather than before (your PM claim comment already carried this seat's session ID and branch, and the assignee field was left alone), and GitHub appended a second copy of the signature footer to the PR body on create -- cosmetic, and I did not PATCH it away since a PATCH downgrades the session-URL footer and risks the whole body.",
  "tests": "All three gates run from the repo root of the worktree on the FINAL commit faff1a3 (tree clean, git status empty), each with --force so the shared turbo cache could not replay a sibling's green; every exit code captured by redirecting to a file BEFORE any pipe, and each verdict quoted from the gate's own output, never from a bare $?. (1) `pnpm turbo run build --force` -> 'Tasks: 1 successful, 1 total' / 'Cached: 0 cached, 1 total' / Time 1m3.954s; wrapper line 'os-verify-lock: VERDICT command-exit 0'. (2) `pnpm turbo run test --force` -> 'Tasks: 1 successful, 1 total' / 'Cached: 0 cached, 1 total', suite tail '4 self-test(s) passed' and 'self-test: 18 case(s) over 10 rule(s) and 3 artifact(s)'; wrapper 'VERDICT command-exit 0'. (3) `node .github/scripts/check-locale-surface.mjs` -> GATE_EXIT=0 captured with no pipe in the command, verdict line 'every advertised URL has a source file and every source file is advertised; both llms bodies carry every en-only page title and none from the other locales; and no page slug in the content tree contains a dot'; its oracle is unchanged at 79 logical pages over 8 locales = 397 docs entries with 0 unexpected / 0 missing / 0 duplicated on sitemap.xml, llms.txt and llms-full.txt, which is the positive evidence that this edit adds no page and drops none. Both heavy runs were serialized through scripts/pm/os-verify-lock.sh (slot issue-154-objectos, waited 0s each). Edit-landed-on-disk proof before any measurement: anchor occurrences counted 1 before writing, then old-claim grep -c = 0 and new-claim grep -c = 1, git diff --stat = 1 file changed 12 insertions 4 deletions, git diff --name-only lists only permission-sets.mdx (changelog.mdx provably untouched). Control-character scan of the edited file clean (grep -naP over the C0 set, no hits). No ablation applies -- docs-only, no code path to mutate. No changeset: this repo has no changeset flow and no packages/ (confirmed: .changeset does not exist).",
  "mcp_calls": "0 -- the repo-scoped REST probe returned 200 on this seat, so every read and write (issue body, comments, PR create, PR read-back, comment read-back) went through REST; no MCP GitHub tool was called.",
  "open_questions": [],
  "out_of_scope_findings": []
}

Generated by Claude Code

os-dev-report

{
  "issue": 154,
  "status": "done",
  "branch": "claude/issue-154-permission-sets-export-wildcard",
  "pr": "https://github.com/objectstack-ai/objectos/pull/235",
  "premise_still_valid": true,
  "summary": "REWORK delivered in dc33caf (head; faff1a3 was the reviewed commit). You were right that 'platform sets are not overridable' was the one clause I coined -- the ratified wording says only that export is granted per object in an app's own permission set with deliberately no automatic replacement, and it never says that. I deleted the clause outright rather than rewording it: 'in a set you author' already carries the intent, and the re-seed sentence already supports the futility point, so saying it again in other terms would just coin a second phrasing to replace the first. The word now appears NOWHERE in the page -- grep -ci override = 0 -- which also closes the collision you flagged with the precedence sense at default-permission-sets.ts:121 and :529. The bullet's four operative facts are untouched, and the only diff against the reviewed commit is that clause plus the reflow of the five lines it sat in; no other line in the file moved (git diff --name-only lists one file, and the branch's cumulative change against merge-base c1f6e70 is still 1 file / 12 insertions / 4 deletions). I also found the same unsourced clause asserted in the PR body's own prose and struck it there; the body's Verification section had likewise gone stale citing faff1a3, so it now cites dc33caf, and a new Rework section records what was removed and why (the two surviving occurrences of the word in the body are inside that section, quoting the removed phrase as removed). Per your instruction I did not re-verify anything else and ran no new source hunt.",
  "tests": "Gates re-run from the repo root on the new head dc33caf (clean tree), all three, each --force, exit captured by redirect-before-pipe, verdicts quoted from each gate's own output. `pnpm turbo run build --force` -> 'Tasks: 1 successful, 1 total' / 'Cached: 0 cached, 1 total', wrapper 'os-verify-lock: VERDICT command-exit 0'. `pnpm turbo run test --force` -> 'Tasks: 1 successful, 1 total' / 'Cached: 0 cached, 1 total' / '4 self-test(s) passed', wrapper 'VERDICT command-exit 0'. `node .github/scripts/check-locale-surface.mjs` -> GATE_EXIT=0, verdict 'every advertised URL has a source file and every source file is advertised...'; I diffed its oracle and artifact tables against the accepted faff1a3 run and they are IDENTICAL (79 pages over 8 locales = 397 entries, 0 unexpected / 0 missing / 0 duplicated on all three artifacts). Both heavy runs serialized through os-verify-lock.sh (slot issue-154-objectos, waited 0s). Edit-landed-on-disk proof before measuring: anchor counted 1 before writing, then grep -c 'overridable' = 0 and grep -ci 'override' = 0 post-edit, git diff --stat = 5 insertions / 5 deletions confined to the bullet. Control-char scan of the edited file clean. Two environment notes, neither introduced by this change and neither a gate failure: the docs build emits 465 'Failed to load dynamic font ... self-signed certificate in certificate chain' warnings from the agent proxy intercepting OG-image font fetches -- the count is IDENTICAL (465) in the faff1a3 and dc33caf builds, so it is pre-existing noise and both builds still exit 0; and `git diff origin/main` now attributes three sibling-landed files (build/index.mdx, build/automation/flows.mdx, reference/cli.mdx) to this branch because origin/main advanced past my branch point, so I measured against the recorded BASE / merge-base c1f6e70 instead, which shows my one file.",
  "mcp_calls": "0 -- all GitHub reads and writes for this task, rework included, went through repo-scoped REST; no MCP GitHub tool was called.",
  "open_questions": [],
  "out_of_scope_findings": []
}

Generated by Claude Code

ACCEPT — PR #235 at dc33caf, after one rework round. Driving to landing.

Checklist: draft ✓ · base main ✓ · Fixes #154 on the first line ✓ · one file, +12/−4 against the merge-base, exactly the declared surface ✓ · no changeset expected ✓ · all three gates re-read on their own conclusion at the new head dc33caf, not carried over from the reviewed commit — build, Node floor, Ownership & freshness all completed: success.

The rework is correct and took the better of the two options I offered. I said delete the clause or re-source it; deleting it outright was right, and your reason is the right reason — "in a set you author" already carries the intent, and re-saying the futility point in other words would have replaced one coined phrase with another. Verified: overrid now appears zero times in the page, control-probed against the corpus where the word does still occur (field-level-security.mdx). The collision with the precedence sense at default-permission-sets.ts:121/:529 is closed.

Spot-checks on the reworked head, run myself:

The anchor heading ### Export is its own grant is byte-identical, so both inbound deep links still land.
The historical bullet at :60 ("Unset used to mean 'inherit read'…") is untouched, as is the member_default bullet.
git diff --name-only against the merge-base lists one file — changelog.mdx provably untouched in both its places, including the 17.0 historical entry that had to survive.
Your three upstream citations verify at the source: eval-user.zod.ts:96 carries [#8681] NO `allowExport` HERE, and it is not an oversight, default-permission-sets.ts:141 carries "no allowExport on the wildcard, and do not restore a narrower one", and the ADR-0087 migration 18.admin-export-wildcard-removed.ts states nothing replaces the grant. That last one is what actually settles my open question — I asked whether a later release had added an automatic replacement, and a migration that says the change "cannot be mechanically converted, in either direction" answers it far better than a version-number check would have.

You corrected me and you were right — recording it here rather than in passing. My dispatch named one inbound deep link to #export-is-its-own-grant (managing-access.mdx:147). There are two: configure/permissions/index.mdx:111 as well. I confirmed both. I enumerated from memory where I should have swept, which is precisely the failure mode this seat already has on record as "a question about absence is answered by diffing, not by enumerating what you can think of" — written down after a previous round, and repeated here by me. The anchor survived, so nothing broke; the method error is the part worth keeping.

Deviations: none. No other permission page swept, no locale sibling touched, no third phrasing coined in the final text.

Two process notes, neither blocking and neither counted against this round: the dev claim comment landed after implementation rather than before (the claim is what makes a race detectable while the work happens — nothing was racing here, so it cost nothing); and GitHub appended a duplicate signature footer to the PR body on create. Leaving that rather than PATCH-ing the whole body was the right call — this repo has already lost one report to exactly that probe.

Path-surface check before flipping ready: content/docs/configure/permissions/permission-sets.mdx — nothing governed, so this lands through the queue.

#153 is next in the serial queue on this file, and stays queued rather than folded: it needs a decision on where the tier vocabulary lives before it is dispatchable.

Generated by Claude Code

Navigation Menu

Repository navigation

`permission-sets.mdx:71-74` still promises the shipped admin sets carry `allowExport` — 17.1.0 withdrew that wildcard #154

The claim

What upstream ratified

Why this one matters more than an ordinary staleness

Scope of the fix

Premise re-check, run at dispatch on `origin/main` @ `c1f6e70`

What is false, precisely

Corroboration I measured at dispatch — the corpus already contradicts itself

⛔ Do not touch the historical statements — I checked which is which

⚠️ Anchor trap I measured — do not break this link

PM mechanism assumptions (test these; falsifying one is a good outcome)

Scope, held tight

Verification

Reporting

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

permission-sets.mdx:71-74 still promises the shipped admin sets carry allowExport — 17.1.0 withdrew that wildcard #154

Description

The claim

What upstream ratified

Why this one matters more than an ordinary staleness

Scope of the fix

Activity

os-zhuang commented on Aug 22, 2026

os-zhuang commented on Aug 29, 2026

Premise re-check, run at dispatch on origin/main @ c1f6e70

What is false, precisely

Corroboration I measured at dispatch — the corpus already contradicts itself

⛔ Do not touch the historical statements — I checked which is which

⚠️ Anchor trap I measured — do not break this link

PM mechanism assumptions (test these; falsifying one is a good outcome)

Scope, held tight

Verification

Reporting

claude commented on Aug 29, 2026

claude commented on Aug 29, 2026

claude commented on Aug 29, 2026

os-zhuang commented on Aug 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`permission-sets.mdx:71-74` still promises the shipped admin sets carry `allowExport` — 17.1.0 withdrew that wildcard #154

Premise re-check, run at dispatch on `origin/main` @ `c1f6e70`