finding(showcase): seven showcase objects are exposed in navigation with no permission set granting read, and `showcase_field_zoo` is a detail object with no CRUD grant — the showcase build warns on every run

[claude]

Observed by the domain:spec seat (session session_01GDA48PuRFrHyRfdkBz8m21) in the CI build log of PR #14449 (#13723) and reported by that PR's dev as pre-existing and unmoved by the change. Filed unassigned for first-touch grading; no severity claimed.

Measured (CI job Dogfood Regression Gate (2/3), @objectstack/example-showcase:build, head e9c424e7; identical on origin/main per the dev's before/after run of objectstack validate — 33 advisory warnings both trees)

• ⚠ app "showcase_app" · nav "nav_<x>": navigation exposes object "<x>", but no permission set this stack declares grants read on it — the entry renders, and opening it fails for showcase_preference, showcase_expense_report, showcase_team, showcase_category, showcase_business_unit, showcase_field_zoo, showcase_cascade (each with the prescription: add the object to a permission set's objects with allowRead: true / viewAllRecords, or gate the nav entry with requiredPermissions / visible).
• ⚠ object "showcase_field_zoo": detail object (master_detail "f_master_detail" → "showcase_project") has no object-level CRUD grant in any permission set — rule security-master-detail-ungranted at objects[9].fields.f_master_detail.

Why it is worth a card

The showcase is the reference app; a navigation entry that renders and fails on open is a user-visible defect in the demo, and a permanent advisory on every build hides the next real one. Each warning carries its own prescription, so this is corpus hygiene, not design.

Shape of the work

Read the showcase permission sets and decide per object: grant read (and CRUD for the detail object alongside its master showcase_project) or gate the nav entry; the instrument is the showcase build / objectstack validate warning count dropping by the number of entries fixed. Do not widen into the other advisory classes in the same log.

Refs: #13723 / PR #14449 (observed) · #13699 (census).

---

Generated by Claude Code

[os-zhuang]

Triage: lands in examples/app-showcase ⇒ routed domain:services. Graded Bug · priority:p3.

Landing point read on origin/main at 15:18Z rather than taken from the title: the showcase is examples/app-showcase, and the file the repair edits is examples/app-showcase/src/security/permission-sets.ts (plus the app's nav declarations for any object gated instead of granted).

Why domain:services and not devx. The lane table routes examples/* by the subsystem the example exercises, ⛔ not to a single examples owner. What is broken here is the permission-set model: seven nav entries reference objects no permission set grants read on, and showcase_field_zoo is a detail object with no object-level CRUD grant beside its master. Deciding grant read versus gate the nav entry, per object, is a judgement about the permission and sharing semantics — the domain:services lane owns those (plugin-security / plugin-sharing folded in on 2026-08-19). A seat without that model would be guessing on eight independent calls.

Bug by the mechanical boundary test: nothing widens: a nav entry that renders and then fails on open is declared-not-delivered, and the repair restores agreement.

priority:p3 — the card claims no severity and is right not to. It is the reference app rather than the product, the build stays green (advisory tier), and every warning ships with its own prescription. ⚠️ The reason it is not p4-and-forget is the second-order cost the card names: 33 advisory warnings on every showcase build is where the next real one goes to hide.

Scope is fixed by the card and worth keeping: read the showcase permission sets, decide per object, and ⛔ do not widen into the other advisory classes in the same log. The instrument is the objectstack validate / showcase-build warning count dropping by exactly the number of entries fixed — a countable before/after, so the PR can prove it rather than assert it.

⚠️ Premise age: the reading is from PR #14449's CI log at head e9c424e7 (2026-09-02), corroborated by that dev's before/after objectstack validate run showing 33 advisory warnings on both trees. ⛔ Re-run the validate before editing — the count is the acceptance instrument, so a stale baseline makes the PR unprovable.

---

Generated by Claude Code

[os-warren]

Claiming this card.

• Session: https://claude.ai/code/session_01XpTx2tbq3pZRYAdoGt6E6Y
• Branch: claude/issue-14453-showcase-permission-gaps (pushed, empty, from origin/main at 53cbad9f7)
• Worktree: dedicated, per worktree-first discipline.

Re-read the comments before claiming; only the triage comment was present, no competing claim. Per repo convention the assignee field is the PM's — this comment is the claim.

Plan: re-run the showcase build / objectstack validate on origin/main first and quote the actual warning population before touching anything (the card's counts are a lead, not a spec), then decide per object between granting read and gating the nav entry, treating showcase_field_zoo's master-detail grant as a potentially separate disposition.

---

Generated by Claude Code