Skip to content

Implement Workspace Settings UI (Providers tab: LLM keys, Tenderly, RPC endpoints) #275

@Hyperkit-dev

Description

@Hyperkit-dev

🎯 Layer 1: Intent Parsing

What needs to be done?

Task Title:

Implement Workspace Settings UI (Providers tab: LLM keys, Tenderly, RPC endpoints)

Area: frontend | Repos: apps/

Primary Goal:

Successfully implement workspace settings UI (Providers tab: LLM keys, Tenderly, RPC endpoints) with full functionality

User Story / Context:

As a user, I want to configure workspace providers (LLM keys, Tenderly, RPC endpoints) through the UI so that I can effectively use HyperAgent features without manual API configuration

Business Impact:

Improves user experience and onboarding. Enables self-service provider configuration as part of the multi-tenant workspace model described in the Business Model

Task Metadata:

  • Sprint: Sprint 2
  • Related Epic/Project: GitHub Project 9 - Phase 1 Foundation
  • Issue Type: Feature
  • Area: Frontend
  • Related Documentation:

📚 Layer 2: Knowledge Retrieval

What information do I need?

Required Skills / Knowledge:

  • UI/UX design (Figma, design systems)
  • Frontend (React/Next.js, TS)

Estimated Effort:

M (Medium - 3-5 days)

Knowledge Resources:

  • Review .cursor/skills/ for relevant patterns
  • Check .cursor/llm/ for implementation examples
  • Read Platform Blueprint: docs/draft.md
  • Read Scope Definition: docs/planning/3-Scope-Definition.md
  • Read System Architecture: docs/planning/4-System-Architecture-Design.md
  • Review design files / Figma (if available)
  • Study tech docs / ADRs in docs/adrs/ directory
  • Review API / schema references for relevant services

Architecture Context:

According to the Platform Blueprint, the web application is built with Next.js/React/TypeScript and exposes project workflows, pipeline runs, and dashboards. This UI component is part of the workspace settings flow, enabling users to configure providers for their workspace.

System Architecture Diagram:

graph TB
    subgraph "Frontend Layer"
        Pages[Next.js Pages<br/>App Router]
        Components[React Components<br/>shadcn/ui]
        State[State Management<br/>Zustand]
        API_Client[API Client<br/>TanStack Query]
    end
    
    subgraph "Backend"
        API[FastAPI Gateway]
        Services[Backend Services]
    end
    
    Pages --> Components
    Components --> State
    Components --> API_Client
    API_Client --> API
    API --> Services
Loading

Code Examples & Patterns:
Next.js Server Component Example:

// app/settings/providers/page.tsx
export default async function ProvidersSettingsPage() {
  const providers = await fetchProviders();
  
  return (
    <div>
      <h1>Workspace Providers</h1>
      {providers.map(provider => (
        <ProviderCard key={provider.id} provider={provider} />
      ))}
    </div>
  );
}

Client Component with State:

// components/settings/ProviderForm.tsx
"use client";

import { useProviderForm } from "@/hooks/useProviderForm";

export function ProviderForm({ providerType }: { providerType: string }) {
  const { form, onSubmit } = useProviderForm(providerType);
  
  return (
    <form onSubmit={onSubmit}>
      {/* Form fields for provider configuration */}
    </form>
  );
}

⚠️ Layer 3: Constraint Analysis

What constraints and dependencies exist?

Known Dependencies:

Technical Constraints:

Out of scope: Backend API changes (track separately). Focus on UI implementation only.

Current Blockers:

None identified (update as work progresses)

Risk Assessment & Mitigations:

Standard development risks; follow best practices, code review, and testing. Ensure proper handling of sensitive data (API keys) in the UI.

Resource Constraints:

  • Deadline: Feb 18–Mar 2
  • Effort Estimate: M (Medium - 3-5 days)

💡 Layer 4: Solution Generation

How should this be implemented?

Solution Approach:

Create a new settings page at app/settings/providers/page.tsx with:

  1. Tabs for different provider types (LLM, Tenderly, RPC)
  2. Forms for adding/editing provider configurations
  3. List view of configured providers
  4. Validation and error handling
  5. Integration with TS SDK methods

Design Considerations:

  • Follow established patterns from .cursor/skills/
  • Maintain consistency with existing codebase
  • Consider scalability and maintainability
  • Ensure proper error handling
  • Plan for testing and validation
  • Follow shadcn/ui design system patterns
  • Ensure responsive design for mobile devices
  • Implement proper security for sensitive data display

Acceptance Criteria (Solution Validation):

  • Providers settings page implemented
  • LLM provider configuration form working
  • Tenderly provider configuration form working
  • RPC endpoint configuration form working
  • Provider list view displays all configured providers
  • Edit/delete functionality for providers
  • Form validation and error messages
  • UI/UX matches design specifications
  • Responsive design verified
  • Accessibility standards met (WCAG 2.1 AA)
  • Integration tests with backend API
  • Code reviewed and approved
  • Documentation updated

📋 Layer 5: Execution Planning

What are the concrete steps?

Implementation Steps:

  1. Define detailed requirements / confirm acceptance criteria
  2. Review design specifications (Figma if available)
  3. Create providers settings page structure
  4. Implement LLM provider form component
  5. Implement Tenderly provider form component
  6. Implement RPC endpoint form component
  7. Implement provider list view component
  8. Integrate with TS SDK methods
  9. Implement form validation
  10. Implement responsive design
  11. Write/update tests (unit/integration/e2e as relevant)
  12. Update docs (README, runbook, in-app help, etc.)
  13. Demo in sprint review and gather feedback

Environment Setup:
Repos / Services:

  • Backend repo: hyperagent/
  • Frontend repo: hyperagent/apps/hyperagent-web/

Required Environment Variables:

  • DATABASE_URL= (get from internal vault)
  • REDIS_URL= (get from internal vault)
  • NEXT_PUBLIC_API_URL= (get from internal vault)

Access & Credentials:

  • API keys: Internal vault (1Password / Doppler)
  • Access request: Contact @devops or project lead

✅ Layer 6: Output Formatting & Validation

How do we ensure quality delivery?

Ownership & Collaboration:

Quality Gates:

  • Code follows project style guide
  • All tests pass (unit, integration, e2e)
  • No critical lint/security issues
  • Documentation updated (README, code comments, ADRs)
  • Meets all acceptance criteria
  • TypeScript strict mode compliance
  • Accessibility audit passed

Review Checklist:

  • Code review approved by @JustineDevs
  • CI/CD pipeline passes
  • Performance benchmarks met (if applicable)
  • Security scan passes
  • UI/UX review completed

Delivery Status:

  • Initial Status: To Do
  • Progress Tracking: Use issue comments for updates
  • Sign-off: Approved by @Hyperionkit on 2026-02-06
  • PR Link: [Link to merged PR(s)]

Related Issues:

Documentation References:

Metadata

Metadata

Assignees

Type

No type

Projects

Status

Todo

Relationships

None yet

Development

No branches or pull requests

Issue actions