Name: admin-page-required
Author: Zynapses

Prompt file imported from Zynapses/Radiant (.windsurf/workflows/admin-page-required.md). Copyright stays with the author.

Admin Page Required Policy

The Rule

EVERY admin-configurable feature MUST have:

A dedicated detail page in apps/admin-dashboard/app/(dashboard)/

A sidebar entry in components/layout/sidebar.tsx

Widget summaries on other pages are ENCOURAGED but MUST link to the detail page

When This Applies

This policy applies when:

Creating any new admin API endpoint
Adding any new Lambda handler in lambda/admin/
Adding any new feature that administrators can configure, monitor, or manage
Adding any new database tables that administrators interact with
Creating any widget or summary card on a dashboard page

Requirements

1. Detail Page (Required)

Every admin feature MUST have a dedicated page at an appropriate route:

apps/admin-dashboard/app/(dashboard)/<section>/<feature>/page.tsx

The page MUST include:

Full configuration controls (not just read-only display)
Data tables/lists with filtering and sorting where applicable
Action buttons (create, update, delete, toggle) where applicable
Status indicators and health checks where applicable
Links back to related pages

2. Sidebar Entry (Required)

Every detail page MUST have a corresponding entry in:

apps/admin-dashboard/components/layout/sidebar.tsx

The entry MUST:

Be placed in the correct section (AI & Models, Orchestration, Security, etc.)
Have an appropriate Lucide icon
Have a clear, concise name (max 20 characters recommended)
Use the correct href matching the page route

3. Widget Links (Required for Widgets)

If a feature has a widget/summary card on a parent or dashboard page:

The widget MUST include a "View Details" or similar link to the detail page
The widget MUST NOT be the only way to access the feature
The detail page MUST contain ALL functionality, not just what the widget shows

4. No Widget-Only Features

NEVER implement a feature as only a widget on another page. This creates:

❌ Hidden functionality that users can't find
❌ Incomplete access to configuration
❌ Lost detail when the parent page changes
❌ No deep-link capability for documentation/support

Verification

Before completing any admin feature implementation:

□ Detail page exists at correct route
□ Page has full CRUD/configuration capabilities
□ Sidebar entry exists with correct icon and section
□ If widgets exist, they link to the detail page
□ Page is accessible via sidebar navigation
□ Page follows existing dashboard design patterns

Existing Violations (To Be Fixed)

The following features currently lack sidebar entries despite having pages:

Platform features: bedrock-settings, cartridge-operations, crucible, deployer-sync, livs, organism, pki, rnir, snapshots, system-cartridges, uds, vault
Orchestration: consensus, inference-cache, model-weights
Memory: anticipatory, retention
Cato: cognitive-precision, governance, livs-policy, safety, war-room
Settings: collaboration, connected-apps, security, urls
Other: api-keys, axiom, blackboard, cato-twilight, domain-experts, model-registry, neural-operations, safety-matrix

The following admin APIs lack any page:

council, mls, dynamic-reports, scheduled-reports, cato-dialogue, orchestration-user-templates, state-registry

Install admin-page-required and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# Admin Page Required Policy ## The Rule > **EVERY admin-configurable feature MUST have:** > 1. A dedicated detail page in `apps/admin-dashboard/app/(dashboard)/` > 2. A sidebar entry in `components/layout/sidebar.tsx` > 3. Widget summaries on other pages are ENCOURAGED but MUST link to the detail page ## When This Applies This policy applies when: - Creating any new admin API endpoint - Adding any new Lambda handler in `lambda/admin/` - Adding any new feature that administrators can configure, monitor, or manage - Adding any new database tables that administrators interact with - Creating any widget or summary card on a dashboard page ## Requirements ### 1. Detail Page (Required) Every admin feature MUST have a dedicated page at an appropriate route: ``` apps/admin-dashboard/app/(dashboard)/<section>/<feature>/page.tsx ``` The page MUST include: - Full configuration controls (not just read-only display) - Data tables/lists with filtering and sorting where applicable - Action buttons (create, update, delete, toggle) where applicable - Status indicators and health checks where applicable - Links back to related pages ### 2. Sidebar Entry (Required) Every detail page MUST have a corresponding entry in: ``` apps/admin-dashboard/components/layout/sidebar.tsx ``` The entry MUST: - Be placed in the correct section (AI & Models, Orchestration, Security, etc.) - Have an appropriate Lucide icon - Have a clear, concise name (max 20 characters recommended) - Use the correct href matching the page route ### 3. Widget Links (Required for Widgets) If a feature has a widget/summary card on a parent or dashboard page: - The widget MUST include a "View Details" or similar link to the detail page - The widget MUST NOT be the only way to access the feature - The detail page MUST contain ALL functionality, not just what the widget shows ### 4. No Widget-Only Features **NEVER** implement a feature as only a widget on another page. This creates: - ❌ Hidden functionality that users can't find - ❌ Incomplete access to configuration - ❌ Lost detail when the parent page changes - ❌ No deep-link capability for documentation/support ## Verification Before completing any admin feature implementation: ``` □ Detail page exists at correct route □ Page has full CRUD/configuration capabilities □ Sidebar entry exists with correct icon and section □ If widgets exist, they link to the detail page □ Page is accessible via sidebar navigation □ Page follows existing dashboard design patterns ``` ## Existing Violations (To Be Fixed) The following features currently lack sidebar entries despite having pages: - Platform features: bedrock-settings, cartridge-operations, crucible, deployer-sync, livs, organism, pki, rnir, snapshots, system-cartridges, uds, vault - Orchestration: consensus, inference-cache, model-weights - Memory: anticipatory, retention - Cato: cognitive-precision, governance, livs-policy, safety, war-room - Settings: collaboration, connected-apps, security, urls - Other: api-keys, axiom, blackboard, cato-twilight, domain-experts, model-registry, neural-operations, safety-matrix The following admin APIs lack any page: - council, mls, dynamic-reports, scheduled-reports, cato-dialogue, orchestration-user-templates, state-registry

{ "prompt": "# Admin Page Required Policy\n\n## The Rule\n\n> **EVERY admin-configurable feature MUST have:**\n> 1. A dedicated detail page in `apps/admin-dashboard/app/(dashboard)/`\n> 2. A sidebar entry in `components/layout/sidebar.tsx`\n> 3. Widget summaries on other pages are ENCOURAGED but MUST link to the detail page\n\n## When This Applies\n\nThis policy applies when:\n- Creating any new admin API endpoint\n- Adding any new Lambda handler in `lambda/admin/`\n- Adding any new feature that administrators can configure, monitor, or manage\n- Adding any new database tables that administrators interact with\n- Creating any widget or summary card on a dashboard page\n\n## Requirements\n\n### 1. Detail Page (Required)\n\nEvery admin feature MUST have a dedicated page at an appropriate route:\n\n```\napps/admin-dashboard/app/(dashboard)/<section>/<feature>/page.tsx\n```\n\nThe page MUST include:\n- Full configuration controls (not just read-only display)\n- Data tables/lists with filtering and sorting where applicable\n- Action buttons (create, update, delete, toggle) where applicable\n- Status indicators and health checks where applicable\n- Links back to related pages\n\n### 2. Sidebar Entry (Required)\n\nEvery detail page MUST have a corresponding entry in:\n```\napps/admin-dashboard/components/layout/sidebar.tsx\n```\n\nThe entry MUST:\n- Be placed in the correct section (AI & Models, Orchestration, Security, etc.)\n- Have an appropriate Lucide icon\n- Have a clear, concise name (max 20 characters recommended)\n- Use the correct href matching the page route\n\n### 3. Widget Links (Required for Widgets)\n\nIf a feature has a widget/summary card on a parent or dashboard page:\n- The widget MUST include a \"View Details\" or similar link to the detail page\n- The widget MUST NOT be the only way to access the feature\n- The detail page MUST contain ALL functionality, not just what the widget shows\n\n### 4. No Widget-Only Features\n\n**NEVER** implement a feature as only a widget on another page. This creates:\n- ❌ Hidden functionality that users can't find\n- ❌ Incomplete access to configuration\n- ❌ Lost detail when the parent page changes\n- ❌ No deep-link capability for documentation/support\n\n## Verification\n\nBefore completing any admin feature implementation:\n\n```\n□ Detail page exists at correct route\n□ Page has full CRUD/configuration capabilities\n□ Sidebar entry exists with correct icon and section\n□ If widgets exist, they link to the detail page\n□ Page is accessible via sidebar navigation\n□ Page follows existing dashboard design patterns\n```\n\n## Existing Violations (To Be Fixed)\n\nThe following features currently lack sidebar entries despite having pages:\n- Platform features: bedrock-settings, cartridge-operations, crucible, deployer-sync, livs, organism, pki, rnir, snapshots, system-cartridges, uds, vault\n- Orchestration: consensus, inference-cache, model-weights\n- Memory: anticipatory, retention\n- Cato: cognitive-precision, governance, livs-policy, safety, war-room\n- Settings: collaboration, connected-apps, security, urls\n- Other: api-keys, axiom, blackboard, cato-twilight, domain-experts, model-registry, neural-operations, safety-matrix\n\nThe following admin APIs lack any page:\n- council, mls, dynamic-reports, scheduled-reports, cato-dialogue, orchestration-user-templates, state-registry", "variables": [], "notes": "Policy - Every admin feature MUST have a dedicated detail page and sidebar entry. No widget-only features allowed.", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/Zynapses/Radiant", "path": ".windsurf/workflows/admin-page-required.md", "ref": "dfcafdfbbf2191ee48921207c5c8a8ca77da957b", "url": "https://github.com/Zynapses/Radiant/blob/dfcafdfbbf2191ee48921207c5c8a8ca77da957b/.windsurf/workflows/admin-page-required.md", "key": "Zynapses/Radiant/.windsurf/workflows/admin-page-required.md" } } }

admin-page-required

About