feat(renderer): add AppProviders and PermissionsProvider

[peppescg]

Summary

• Extract the provider tree from renderer.tsx into a composable AppProviders component (app-providers.tsx), reducing duplication and improving maintainability
• Add a PermissionsProvider with a usePermissions() hook and canShow() helper to conditionally render UI features based on permission keys
• All permissions default to true (no behavioral changes); individual keys can be overridden to false via the permissions prop on <AppProviders>
• Permission keys are defined in a single file (permission-keys.ts) with full TypeScript safety and IDE autocompletion

How it works

1. Define a feature key in permission-keys.ts
2. Use canShow(PERMISSION_KEYS.MY_FEATURE) in any component to gate visibility
3. Downstream builds can pass <AppProviders permissions={{ 'my-feature': false }}> to selectively disable features

Test plan

• TypeScript compiles without errors
• Lint passes
• Unit tests cover: default behavior (all visible), single override (feature hidden), selective override (mix of enabled/disabled)
• Pre-existing tests unaffected

Closes #1706
Closes #1708

[Copilot]

Pull request overview

This PR refactors the renderer entrypoint by extracting the provider tree into a reusable AppProviders component and introduces a new permissions context intended to gate UI features behind typed permission keys (defaulting to “allowed” for OSS behavior parity).

Changes:

• Extract provider composition from renderer.tsx into renderer/src/app-providers.tsx.
• Add a new permissions context (PermissionsProvider, usePermissions(), and canShow() helper) plus a central permission-keys.ts.
• Add initial unit tests for the permissions provider behavior.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
renderer/src/renderer.tsx	Replaces inline provider tree with <AppProviders> wrapper.
renderer/src/app-providers.tsx	New composable provider stack, adds PermissionsProvider and permissions overrides prop.
renderer/src/common/contexts/permissions/index.ts	Defines permissions types, default permissions, context, and usePermissions() hook.
renderer/src/common/contexts/permissions/permissions-provider.tsx	Implements provider that merges overrides onto defaults.
renderer/src/common/contexts/permissions/permission-keys.ts	Introduces centralized permission key definitions (currently empty).
renderer/src/common/contexts/permissions/tests/permissions-provider.test.tsx	Adds tests for default allow + overrides (currently bypasses public API/types).

[peppescg]

@claude succinct review

[claude]

Claude finished @peppescg's task in 41s —— View job

---

Review

AppProviders extraction — clean, no issues.

Permissions system — the scaffold is solid but has a few problems to address before or when keys are added:

1. Empty PERMISSION_KEYS makes the type system degenerate (permission-keys.ts:13)
PermissionKey resolves to never → Permissions is {} → canShow() accepts no valid args and DEFAULT_PERMISSIONS is {}. As a placeholder this is fine, but it means the "default allows all" test passes for the wrong reason: permissions['local-mcp-run'] is undefined (not true), and the guard checks === false, so it falls through. When real keys are added, behaviour will change subtly.

2. Tests don't exercise the public API (__tests__/permissions-provider.test.tsx:8-11)
FeatureGuard reads PermissionsContext directly and casts with as never, bypassing usePermissions()/canShow(). These tests won't catch regressions in the hook. When keys land, replace with usePermissions().canShow(PERMISSION_KEYS.X).

3. canShow fallback is dead code (index.ts:25)
?? true can never be reached once the type system is healthy — permissions[key] will always be a boolean for a valid PermissionKey. Harmless now, but misleading.

4. PermissionsProvider not re-exported from index.ts (index.ts)
Consumers importing from @/common/contexts/permissions can't get the provider. Fix this →

Overall the approach is good — the issues in 1–3 are acceptable as a scaffold if the intent is to fill in keys immediately in a follow-up, but they should be noted. Point 4 is a small omission worth fixing now.

[samuv]

nice, let's just remember to add some tests