feat(bootstrap): grant project-create to org member role

[whoAbhishekSah]

What

1. Grants app_organization_projectcreate to the predefined organization viewer ("Member") role, so an org Member can create projects rather than only reading the org.
2. Removes a duplicate PredefinedRoles entry titled "Group Viewer" that reused the same Name (RoleOrganizationViewer = app_organization_viewer).

Why the duplicate removal

PredefinedRoles defined RoleOrganizationViewer twice — "Member" and "Group Viewer" — with the same Name, so it never created a distinct role. MigrateRoles reconciled the same role twice (last write winning), which meant any edit to the Member role had to be mirrored in both entries or the second would reset it. The "Group Viewer" copy traces back to #399 and looks like a copy/paste that reused the org-viewer name instead of a dedicated group-viewer constant. Removing it is functionally inert (same Name, no separate role) and makes the role single-sourced.

Impact

Additive for permissions — Member gains projectcreate, nothing is removed. The dedupe changes no runtime behavior (the duplicate was a redundant reconcile of the same role). Applied via the normal boot-time role reconcile.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
frontier	Ready	Preview, Comment	Jun 19, 2026 9:08am

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 7e583925-5d1c-434c-a77a-533f93821148

📥 Commits

Reviewing files that changed from the base of the PR and between 906620b and 94688fe.

📒 Files selected for processing (1)

• internal/bootstrap/schema/schema.go

✅ Files skipped from review due to trivial changes (1)

• internal/bootstrap/schema/schema.go

---

📝 Walkthrough

Summary by CodeRabbit

• Chores
  • Updated organization member role permissions to include the ability to create projects (app_organization_projectcreate).
  • This change expands what “Member” can do within organizations, enabling project creation where previously it was restricted.

Walkthrough

The PredefinedRoles slice in internal/bootstrap/schema/schema.go is updated to include app_organization_projectcreate in the Permissions list of the RoleOrganizationViewer role entry. No other logic, structures, or exported API signatures are changed.

Changes

Permission Grant Update

Layer / File(s)	Summary
Add app_organization_projectcreate to RoleOrganizationViewer internal/bootstrap/schema/schema.go	The RoleOrganizationViewer entry in the PredefinedRoles slice gains app_organization_projectcreate appended to its Permissions list (line 347).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coveralls]

Coverage Report for CI Build 27816531053

Coverage remained the same at 43.804%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	37058
Covered Lines:	16233
Line Coverage:	43.8%
Coverage Strength:	12.39 hits per line

---

💛 - Coveralls

[whoAbhishekSah]

Closing — adding app_organization_projectcreate to the base Member role over-grants: service users (and all members) hold Member by default, so this would let every member/service-user create projects, which the serviceusers regression tests correctly guard against. The intended model is to grant project creation via the Manager role or an explicit policy; the read-only Member role is correct. The duplicate-role cleanup can be done separately if wanted.