Wiki Navigation

Next.js Component Requirements (Wiki Publishing)

This page defines what to build on the website side so end users can quickly understand tool capabilities without reading long pages.

Recommended component set

1) ToolCapabilityExplorer (required)

Purpose: interactive, user-friendly view of “what can I do here?” across tools.

Must support:

  • Filter by mode: Full / Read-only / Browse-only.
  • Filter by tier: Free / Pro / Enterprise.
  • Search by user intent (for example: “rename”, “RLS”, “tests”, “refresh”).
  • Group by category: Core, Authoring, Governance/Advanced.
  • Per-tool card/table view with:
    • plain-language capability summary,
    • whether model connection is needed,
    • tier requirement,
    • link to full tool page.

Mobile/accessibility requirements:

  • Keyboard-navigable filters and rows/cards.
  • Color is not the only status signal (include text + icon/label).
  • Responsive layout: table on desktop, stacked cards on mobile.

2) TestAssertionMatrix (required for manage_tests)

Purpose: make supported assertions easy to understand for non-technical users.

Must support:

  • Rows by test type (measure_assertion, rls_validation, etc.).
  • Plain-language “pass means…” descriptions.
  • Expandable details for measure assertion operators.
  • Optional “copy prompt” actions for common user prompts.

3) PromptExamples (recommended)

Purpose: standardized prompt snippets that users can copy in one click.

Must support:

  • One-click copy with success feedback.
  • Optional tags (for example: “safe”, “beginner”, “governance”).
  • Optional “works in mode” badges (Full/Read-only/Browse-only).

Data contract (content-driven)

Use JSON/MDX frontmatter-driven data so docs updates do not require UI code changes.

Minimum fields for each tool:

  • tool
  • category
  • summary
  • requires_model_connection
  • min_tier
  • mode_support (full/read_only/browse_only)
  • key_capabilities (plain language list)
  • prompt_examples (optional)
  • doc_href

Behavior requirements

  • Default view should show only capabilities available in the user’s selected mode/tier.
  • If a capability is blocked, show “why” in plain language (mode, tier, or policy).
  • Keep interaction fast: no blocking network fetch needed for first render.

Success criteria

  • A new user can answer “Can I do X here?” in under 10 seconds.
  • Tool pages receive fewer “what is available in my mode?” support questions.
  • manage_tests users can identify supported assertion types without reading implementation details.