docs(openspec): add OpenSpec changes for FN-005, FN-006, FN-008, FN-009, FN-010
- Add frontend-foundation change (FN-005) with 46 tasks - Add deployment-config change (FN-006) with 27 tasks - Add runfusion-poc/opencode-poc change (FN-008) with 25 tasks - Add config-secrets change (FN-009) with 31 tasks - Add codeserver-spawn change (FN-010) with 38 tasks - Include project specsheet and configuration - Archive completed deployment-config change
This commit is contained in:
@@ -0,0 +1,28 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: API client handles all backend endpoints
|
||||
The system SHALL provide a typed HTTP client for all backend API endpoints.
|
||||
|
||||
#### Scenario: GET request
|
||||
- **WHEN** the client calls api.get('/projects')
|
||||
- **THEN** it sends a GET request to /api/v1/projects
|
||||
- **AND** returns typed Project[] data
|
||||
- **AND** includes the Authorization header with the current access token
|
||||
|
||||
#### Scenario: POST request
|
||||
- **WHEN** the client calls api.post('/projects', data)
|
||||
- **THEN** it sends a POST request with JSON body
|
||||
- **AND** returns typed Project data
|
||||
|
||||
#### Scenario: Error handling
|
||||
- **WHEN** a request returns 4xx or 5xx
|
||||
- **THEN** the client throws an ApiError with status code and message
|
||||
- **AND** the error can be caught and displayed to the user
|
||||
|
||||
### Requirement: API client supports request/response types
|
||||
The system SHALL use TypeScript interfaces matching the backend Pydantic schemas.
|
||||
|
||||
#### Scenario: Type safety
|
||||
- **WHEN** a developer uses the API client
|
||||
- **THEN** request and response types are checked at compile time
|
||||
- **AND** mismatches produce TypeScript errors
|
||||
@@ -0,0 +1,36 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: User can authenticate via Authentik OIDC
|
||||
The system SHALL provide an authentication flow using Authentik as the OIDC provider.
|
||||
|
||||
#### Scenario: Successful login
|
||||
- **WHEN** an unauthenticated user clicks "Sign In"
|
||||
- **THEN** the system redirects to Authentik's authorization endpoint with PKCE parameters
|
||||
- **AND** after successful authentication, Authentik redirects back with an authorization code
|
||||
- **AND** the system exchanges the code for tokens
|
||||
- **AND** the user is redirected to the dashboard
|
||||
|
||||
#### Scenario: Automatic user provisioning
|
||||
- **WHEN** a user authenticates for the first time
|
||||
- **THEN** the backend creates a User record automatically
|
||||
- **AND** the user can access their projects immediately
|
||||
|
||||
#### Scenario: Logout
|
||||
- **WHEN** an authenticated user clicks "Sign Out"
|
||||
- **THEN** the system clears all session data
|
||||
- **AND** redirects to Authentik's end_session_endpoint
|
||||
- **AND** the user is redirected back to the login page
|
||||
|
||||
### Requirement: Auth state is managed globally
|
||||
The system SHALL maintain authentication state accessible throughout the application.
|
||||
|
||||
#### Scenario: Auth context available
|
||||
- **WHEN** the application loads
|
||||
- **THEN** an auth context provider wraps the component tree
|
||||
- **AND** child components can read the current auth state (loading, authenticated, unauthenticated, error)
|
||||
|
||||
#### Scenario: Token refresh
|
||||
- **WHEN** an API request returns 401 due to expired token
|
||||
- **THEN** the system attempts token refresh
|
||||
- **AND** retries the original request with the new token
|
||||
- **AND** if refresh fails, redirects to login
|
||||
@@ -0,0 +1,28 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Dashboard provides responsive layout
|
||||
The system SHALL provide a consistent layout with header, navigation, and content area.
|
||||
|
||||
#### Scenario: Layout structure
|
||||
- **WHEN** the user views any authenticated page
|
||||
- **THEN** a header displays the application name and user avatar
|
||||
- **AND** a sidebar shows navigation links (Dashboard, Projects, Repositories, Tools, Settings)
|
||||
- **AND** the main content area renders the current route's component
|
||||
|
||||
#### Scenario: Collapsible sidebar
|
||||
- **WHEN** the user is on a mobile device
|
||||
- **THEN** the sidebar is initially collapsed
|
||||
- **AND** a hamburger menu toggles the sidebar visibility
|
||||
|
||||
### Requirement: Navigation reflects auth state
|
||||
The system SHALL show/hide navigation items based on authentication status.
|
||||
|
||||
#### Scenario: Authenticated navigation
|
||||
- **WHEN** the user is authenticated
|
||||
- **THEN** all navigation links are visible
|
||||
- **AND** "Sign Out" is available in the user menu
|
||||
|
||||
#### Scenario: Unauthenticated navigation
|
||||
- **WHEN** the user is not authenticated
|
||||
- **THEN** only "Sign In" is shown
|
||||
- **AND** accessing protected routes redirects to login
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: User can view their projects
|
||||
The system SHALL display a list of projects belonging to the authenticated user.
|
||||
|
||||
#### Scenario: Project list page
|
||||
- **WHEN** the user navigates to /projects
|
||||
- **THEN** the system fetches projects from /api/v1/projects
|
||||
- **AND** displays each project with name, description, and created date
|
||||
- **AND** shows an empty state when no projects exist
|
||||
|
||||
#### Scenario: Project detail
|
||||
- **WHEN** the user clicks on a project
|
||||
- **THEN** the system navigates to /projects/:id
|
||||
- **AND** displays project details including repositories and tool instances
|
||||
|
||||
### Requirement: User can create a project
|
||||
The system SHALL allow authenticated users to create new projects.
|
||||
|
||||
#### Scenario: Create project form
|
||||
- **WHEN** the user clicks "New Project"
|
||||
- **THEN** a form appears with name and description fields
|
||||
- **AND** the name field validates for non-empty and URL-friendly slug generation
|
||||
- **AND** submitting the form POSTs to /api/v1/projects
|
||||
- **AND** on success, the user is redirected to the new project
|
||||
|
||||
### Requirement: User can edit and delete projects
|
||||
The system SHALL allow project owners to modify or remove their projects.
|
||||
|
||||
#### Scenario: Edit project
|
||||
- **WHEN** the user clicks "Edit" on a project
|
||||
- **THEN** a pre-filled form appears
|
||||
- **AND** submitting updates the project via PUT /api/v1/projects/:id
|
||||
|
||||
#### Scenario: Delete project
|
||||
- **WHEN** the user clicks "Delete" on a project
|
||||
- **THEN** a confirmation dialog appears
|
||||
- **AND** confirming sends DELETE /api/v1/projects/:id
|
||||
- **AND** the project is removed from the list
|
||||
@@ -0,0 +1,24 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Protected routes require authentication
|
||||
The system SHALL prevent unauthenticated users from accessing protected pages.
|
||||
|
||||
#### Scenario: Unauthenticated access attempt
|
||||
- **WHEN** an unauthenticated user navigates to /projects
|
||||
- **THEN** the system redirects to /login
|
||||
- **AND** stores the intended destination for post-login redirect
|
||||
|
||||
#### Scenario: Authenticated access
|
||||
- **WHEN** an authenticated user navigates to /projects
|
||||
- **THEN** the route renders normally
|
||||
|
||||
### Requirement: Public routes are accessible
|
||||
The system SHALL allow unauthenticated access to public pages.
|
||||
|
||||
#### Scenario: Login page
|
||||
- **WHEN** an unauthenticated user navigates to /login
|
||||
- **THEN** the login page renders without redirect
|
||||
|
||||
#### Scenario: Health/status pages
|
||||
- **WHEN** any user navigates to /health
|
||||
- **THEN** the page renders without authentication
|
||||
Reference in New Issue
Block a user