Difficulty: Expert | Type: Architecture / Refactor
Background: The admin dashboard is growing a fixed set of first-party modules (overview, member list, role assignment, policies, analytics, governance, rewards — several proposed above), all hardcoded into the app's route tree and nav.
Problem: Every new admin capability currently requires directly modifying core app files (components/nav.tsx, route tree, lib/features.ts), which doesn't scale well as the module count grows and makes it hard for downstream forks/community deployments to add custom modules without maintaining a diverging fork.
Expected Outcome: A documented plugin interface lets an admin module (nav entry + route + required permissions) be registered from a single, self-contained definition, with the core nav and routing rendering registered modules dynamically rather than each being individually hardcoded.
Suggested Implementation: Define a AdminModule interface (id, navLabel, route, featureFlag, requiredRole, component), refactor existing modules (role assignment, policies, and any of the new modules proposed above) to register through this interface via a central registry, and update components/nav.tsx and the admin route tree to render from the registry instead of hardcoded entries.
Acceptance Criteria:
- All existing admin modules are migrated to the plugin interface with zero behavior change (verified against existing tests).
- A new admin module can be added by implementing the interface and registering it, with no changes required to
nav.tsx or core routing files.
- Feature-flag and role-based gating continue to work correctly through the registry.
Likely Affected Files/Directories: app/admin/*, components/nav.tsx, lib/admin-modules/ (new), lib/features.ts
Labels: architecture, refactor, GrantFox OSS, Maybe Rewarded, Official Campaign | FWC26
Difficulty: Expert | Type: Architecture / Refactor
Background: The admin dashboard is growing a fixed set of first-party modules (overview, member list, role assignment, policies, analytics, governance, rewards — several proposed above), all hardcoded into the app's route tree and nav.
Problem: Every new admin capability currently requires directly modifying core app files (
components/nav.tsx, route tree,lib/features.ts), which doesn't scale well as the module count grows and makes it hard for downstream forks/community deployments to add custom modules without maintaining a diverging fork.Expected Outcome: A documented plugin interface lets an admin module (nav entry + route + required permissions) be registered from a single, self-contained definition, with the core nav and routing rendering registered modules dynamically rather than each being individually hardcoded.
Suggested Implementation: Define a
AdminModuleinterface (id,navLabel,route,featureFlag,requiredRole,component), refactor existing modules (role assignment, policies, and any of the new modules proposed above) to register through this interface via a central registry, and updatecomponents/nav.tsxand the admin route tree to render from the registry instead of hardcoded entries.Acceptance Criteria:
nav.tsxor core routing files.Likely Affected Files/Directories:
app/admin/*,components/nav.tsx,lib/admin-modules/(new),lib/features.tsLabels:
architecture,refactor,GrantFox OSS,Maybe Rewarded,Official Campaign | FWC26