claude-dashboard 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/settings.local.json +10 -0
- package/LICENSE +21 -0
- package/README.md +99 -0
- package/README.zh-TW.md +99 -0
- package/bin/cdb.ts +60 -0
- package/bun.lock +1612 -0
- package/bunfig.toml +4 -0
- package/components.json +20 -0
- package/next.config.ts +19 -0
- package/package.json +62 -0
- package/postcss.config.mjs +9 -0
- package/prompts/pm-system.md +61 -0
- package/prompts/rd-system.md +68 -0
- package/prompts/sec-system.md +93 -0
- package/prompts/test-system.md +71 -0
- package/prompts/ui-system.md +72 -0
- package/server.ts +118 -0
- package/sql.js.d.ts +33 -0
- package/src/__tests__/api/usage/route.test.ts +193 -0
- package/src/__tests__/components/layout/TopNav.test.tsx +155 -0
- package/src/__tests__/components/layout/UsageIndicator.test.tsx +503 -0
- package/src/__tests__/hooks/useUsage.test.tsx +174 -0
- package/src/__tests__/lib/usage/get-token.test.ts +117 -0
- package/src/__tests__/react-sanity.test.tsx +14 -0
- package/src/__tests__/sanity.test.ts +7 -0
- package/src/__tests__/setup.ts +1 -0
- package/src/app/api/health/route.ts +8 -0
- package/src/app/api/usage/route.ts +86 -0
- package/src/app/api/workflows/[id]/route.ts +17 -0
- package/src/app/api/workflows/route.ts +14 -0
- package/src/app/globals.css +74 -0
- package/src/app/history/page.tsx +15 -0
- package/src/app/layout.tsx +24 -0
- package/src/app/page.tsx +112 -0
- package/src/components/agent/AgentCard.tsx +117 -0
- package/src/components/agent/AgentCardGrid.tsx +14 -0
- package/src/components/agent/AgentOutput.tsx +87 -0
- package/src/components/agent/AgentStatusBadge.tsx +20 -0
- package/src/components/events/EventLog.tsx +65 -0
- package/src/components/events/EventLogItem.tsx +39 -0
- package/src/components/history/HistoryTable.tsx +105 -0
- package/src/components/layout/DashboardShell.tsx +12 -0
- package/src/components/layout/TopNav.tsx +86 -0
- package/src/components/layout/UsageIndicator.tsx +163 -0
- package/src/components/pipeline/PipelineBar.tsx +59 -0
- package/src/components/pipeline/PipelineNode.tsx +55 -0
- package/src/components/terminal/TerminalPanel.tsx +138 -0
- package/src/components/terminal/XTermRenderer.tsx +129 -0
- package/src/components/ui/badge.tsx +37 -0
- package/src/components/ui/button.tsx +55 -0
- package/src/components/ui/card.tsx +80 -0
- package/src/components/ui/input.tsx +26 -0
- package/src/components/ui/scroll-area.tsx +52 -0
- package/src/components/ui/separator.tsx +31 -0
- package/src/components/ui/textarea.tsx +25 -0
- package/src/components/ui/tooltip.tsx +73 -0
- package/src/components/workflow/WorkflowLauncher.tsx +102 -0
- package/src/hooks/useAgentStream.ts +27 -0
- package/src/hooks/useAutoScroll.ts +24 -0
- package/src/hooks/useUsage.ts +66 -0
- package/src/hooks/useWebSocket.ts +289 -0
- package/src/lib/agents/prompts.ts +341 -0
- package/src/lib/db/connection.ts +263 -0
- package/src/lib/db/queries.ts +257 -0
- package/src/lib/db/schema.ts +39 -0
- package/src/lib/output-buffer.ts +41 -0
- package/src/lib/terminal/pty-manager.ts +106 -0
- package/src/lib/usage/get-token.ts +48 -0
- package/src/lib/utils.ts +6 -0
- package/src/lib/websocket/connection-manager.ts +71 -0
- package/src/lib/websocket/protocol.ts +90 -0
- package/src/lib/websocket/server.ts +231 -0
- package/src/lib/workflow/agent-runner.ts +254 -0
- package/src/lib/workflow/context-builder.ts +62 -0
- package/src/lib/workflow/engine.ts +310 -0
- package/src/lib/workflow/pipeline.ts +28 -0
- package/src/lib/workflow/types.ts +111 -0
- package/src/stores/agentStore.ts +152 -0
- package/src/stores/eventStore.ts +35 -0
- package/src/stores/terminalStore.ts +20 -0
- package/src/stores/uiStore.ts +35 -0
- package/src/stores/workflowStore.ts +57 -0
- package/src/types/css.d.ts +4 -0
- package/src/types/index.ts +12 -0
- package/tailwind.config.ts +65 -0
- package/tsconfig.json +25 -0
- package/tsconfig.server.json +21 -0
- package/vitest.config.ts +25 -0
package/bunfig.toml
ADDED
package/components.json
ADDED
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://ui.shadcn.com/schema.json",
|
|
3
|
+
"style": "default",
|
|
4
|
+
"rsc": true,
|
|
5
|
+
"tsx": true,
|
|
6
|
+
"tailwind": {
|
|
7
|
+
"config": "tailwind.config.ts",
|
|
8
|
+
"css": "src/app/globals.css",
|
|
9
|
+
"baseColor": "zinc",
|
|
10
|
+
"cssVariables": true,
|
|
11
|
+
"prefix": ""
|
|
12
|
+
},
|
|
13
|
+
"aliases": {
|
|
14
|
+
"components": "@/components",
|
|
15
|
+
"utils": "@/lib/utils",
|
|
16
|
+
"ui": "@/components/ui",
|
|
17
|
+
"lib": "@/lib",
|
|
18
|
+
"hooks": "@/hooks"
|
|
19
|
+
}
|
|
20
|
+
}
|
package/next.config.ts
ADDED
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
import type { NextConfig } from "next";
|
|
2
|
+
|
|
3
|
+
const nextConfig: NextConfig = {
|
|
4
|
+
serverExternalPackages: ["sql.js", "node-pty"],
|
|
5
|
+
webpack: (config, { isServer }) => {
|
|
6
|
+
if (!isServer) {
|
|
7
|
+
config.resolve.fallback = {
|
|
8
|
+
...config.resolve.fallback,
|
|
9
|
+
fs: false,
|
|
10
|
+
child_process: false,
|
|
11
|
+
net: false,
|
|
12
|
+
tls: false,
|
|
13
|
+
};
|
|
14
|
+
}
|
|
15
|
+
return config;
|
|
16
|
+
},
|
|
17
|
+
};
|
|
18
|
+
|
|
19
|
+
export default nextConfig;
|
package/package.json
ADDED
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "claude-dashboard",
|
|
3
|
+
"version": "0.1.0",
|
|
4
|
+
|
|
5
|
+
"type": "module",
|
|
6
|
+
"bin": {
|
|
7
|
+
"cdb": "./bin/cdb.ts"
|
|
8
|
+
},
|
|
9
|
+
"scripts": {
|
|
10
|
+
"postinstall": "node -e \"import('node:child_process').then(m=>m.execSync('chmod +x node_modules/node-pty/prebuilds/*/spawn-helper')).catch(()=>{})\"",
|
|
11
|
+
"dev": "node server.ts",
|
|
12
|
+
"build": "next build && tsc -p tsconfig.server.json",
|
|
13
|
+
"start": "node dist/server.js",
|
|
14
|
+
"lint": "next lint"
|
|
15
|
+
},
|
|
16
|
+
"dependencies": {
|
|
17
|
+
"@tanstack/react-virtual": "^3.11.2",
|
|
18
|
+
"autoprefixer": "^10.4.24",
|
|
19
|
+
"class-variance-authority": "^0.7.1",
|
|
20
|
+
"clsx": "^2.1.1",
|
|
21
|
+
"sql.js": "^1.12.0",
|
|
22
|
+
"express": "^4.21.0",
|
|
23
|
+
"lucide-react": "^0.468.0",
|
|
24
|
+
"next": "^15.5.12",
|
|
25
|
+
"node-pty": "^1.0.0",
|
|
26
|
+
"open": "^10.1.0",
|
|
27
|
+
"react": "^19.0.0",
|
|
28
|
+
"react-dom": "^19.0.0",
|
|
29
|
+
"react-markdown": "^9.0.1",
|
|
30
|
+
"rehype-highlight": "^7.0.1",
|
|
31
|
+
"remark-gfm": "^4.0.0",
|
|
32
|
+
"tailwind-merge": "^2.6.0",
|
|
33
|
+
"uuid": "^11.0.3",
|
|
34
|
+
"ws": "^8.18.0",
|
|
35
|
+
"xterm": "^5.3.0",
|
|
36
|
+
"xterm-addon-fit": "^0.8.0",
|
|
37
|
+
"xterm-addon-webgl": "^0.16.0",
|
|
38
|
+
"zustand": "^5.0.0"
|
|
39
|
+
},
|
|
40
|
+
"devDependencies": {
|
|
41
|
+
"@happy-dom/global-registrator": "^20.6.1",
|
|
42
|
+
"@tailwindcss/typography": "^0.5.15",
|
|
43
|
+
"@testing-library/jest-dom": "^6.9.1",
|
|
44
|
+
"@testing-library/react": "^16.3.2",
|
|
45
|
+
"@types/express": "^5.0.0",
|
|
46
|
+
"@types/node": "^22.0.0",
|
|
47
|
+
"@types/react": "^19.0.0",
|
|
48
|
+
"@types/react-dom": "^19.0.0",
|
|
49
|
+
"@types/uuid": "^10.0.0",
|
|
50
|
+
"@types/ws": "^8.5.13",
|
|
51
|
+
"@vitejs/plugin-react": "^5.1.4",
|
|
52
|
+
"eslint": "^9.0.0",
|
|
53
|
+
"eslint-config-next": "^15.5.12",
|
|
54
|
+
"happy-dom": "^20.6.1",
|
|
55
|
+
"jsdom": "^28.0.0",
|
|
56
|
+
"postcss": "^8.0.0",
|
|
57
|
+
"tailwindcss": "^3.4.0",
|
|
58
|
+
"tsx": "^4.19.0",
|
|
59
|
+
"typescript": "^5.7.0",
|
|
60
|
+
"vitest": "^4.0.18"
|
|
61
|
+
}
|
|
62
|
+
}
|
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
# PM Agent System Prompt
|
|
2
|
+
|
|
3
|
+
You are the **PM (Product Manager) Agent** in an automated software development pipeline.
|
|
4
|
+
|
|
5
|
+
## Your Role
|
|
6
|
+
|
|
7
|
+
You are the first agent in the pipeline. Your job is to analyze the user's request and produce a clear, structured requirements document that all downstream agents (RD, UI, TEST, SEC) will use as their primary specification.
|
|
8
|
+
|
|
9
|
+
## Access Level
|
|
10
|
+
|
|
11
|
+
- **Read-only**: You may read files in the project to understand existing code, structure, and context.
|
|
12
|
+
- You must NOT create, modify, or delete any files.
|
|
13
|
+
- You must NOT execute any commands.
|
|
14
|
+
|
|
15
|
+
## Your Responsibilities
|
|
16
|
+
|
|
17
|
+
1. **Understand the Request**: Parse the user's request thoroughly. Identify explicit requirements, implicit needs, and potential ambiguities.
|
|
18
|
+
2. **Analyze the Existing Project**: Read relevant files to understand the current codebase, tech stack, conventions, and patterns already in use.
|
|
19
|
+
3. **Define Scope**: Clearly articulate what is in scope and what is out of scope.
|
|
20
|
+
4. **Write User Stories**: Break the request down into concrete user stories with acceptance criteria.
|
|
21
|
+
5. **Identify Technical Requirements**: Note any technical constraints, dependencies, or architectural considerations.
|
|
22
|
+
|
|
23
|
+
## Output Format
|
|
24
|
+
|
|
25
|
+
You MUST structure your output using the following sections. Use markdown headers exactly as shown:
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
## Summary
|
|
29
|
+
A concise 2-3 sentence summary of what the user is requesting and the overall goal.
|
|
30
|
+
|
|
31
|
+
## User Stories
|
|
32
|
+
- **US-1**: As a [role], I want [feature] so that [benefit].
|
|
33
|
+
- Acceptance: [specific testable criteria]
|
|
34
|
+
- **US-2**: ...
|
|
35
|
+
|
|
36
|
+
## Acceptance Criteria
|
|
37
|
+
A consolidated list of all acceptance criteria that define "done" for this work:
|
|
38
|
+
1. [Criterion 1]
|
|
39
|
+
2. [Criterion 2]
|
|
40
|
+
...
|
|
41
|
+
|
|
42
|
+
## Technical Requirements
|
|
43
|
+
- **Tech Stack**: [relevant technologies, frameworks, libraries]
|
|
44
|
+
- **Dependencies**: [new packages, APIs, services needed]
|
|
45
|
+
- **Constraints**: [performance, compatibility, security requirements]
|
|
46
|
+
- **File Structure**: [expected new or modified files]
|
|
47
|
+
|
|
48
|
+
## Out of Scope
|
|
49
|
+
Items explicitly NOT included in this work:
|
|
50
|
+
- [Item 1]
|
|
51
|
+
- [Item 2]
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
## Guidelines
|
|
55
|
+
|
|
56
|
+
- Be precise and unambiguous. Downstream agents will implement exactly what you specify.
|
|
57
|
+
- If the user's request is vague, make reasonable assumptions and document them clearly.
|
|
58
|
+
- Consider edge cases and error scenarios.
|
|
59
|
+
- Prioritize user stories if there are many (P0 = must have, P1 = should have, P2 = nice to have).
|
|
60
|
+
- Reference specific existing files and patterns in the codebase when relevant.
|
|
61
|
+
- Keep the document concise but complete. Aim for clarity over verbosity.
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
# RD Agent System Prompt
|
|
2
|
+
|
|
3
|
+
You are the **RD (Research & Development / Backend) Agent** in an automated software development pipeline.
|
|
4
|
+
|
|
5
|
+
## Your Role
|
|
6
|
+
|
|
7
|
+
You are the second agent in the pipeline, running after the PM agent. You receive the PM's requirements document and the user's original request. Your job is to design the backend architecture and implement the server-side code.
|
|
8
|
+
|
|
9
|
+
## Access Level
|
|
10
|
+
|
|
11
|
+
- **Full access**: You may read, create, and modify files.
|
|
12
|
+
- You may execute bash commands for installing dependencies, running builds, and validating your work.
|
|
13
|
+
|
|
14
|
+
## Your Responsibilities
|
|
15
|
+
|
|
16
|
+
1. **Architecture Design**: Design the backend architecture based on the PM's requirements.
|
|
17
|
+
2. **API Design**: Define API endpoints, request/response schemas, and error handling.
|
|
18
|
+
3. **Database Schema**: Design database tables, relationships, indexes, and migrations.
|
|
19
|
+
4. **Implementation**: Write the actual backend code - routes, controllers, services, models, utilities.
|
|
20
|
+
5. **Validation**: Ensure your code compiles, lints, and follows the project's existing conventions.
|
|
21
|
+
|
|
22
|
+
## Output Format
|
|
23
|
+
|
|
24
|
+
Structure your output in two parts: first the design documentation, then the implementation.
|
|
25
|
+
|
|
26
|
+
### Part 1: Design Documentation
|
|
27
|
+
|
|
28
|
+
```
|
|
29
|
+
## Architecture Overview
|
|
30
|
+
A brief description of the architectural approach, patterns used (e.g., MVC, service layer), and how it fits into the existing codebase.
|
|
31
|
+
|
|
32
|
+
## API Endpoints
|
|
33
|
+
| Method | Path | Description | Request Body | Response |
|
|
34
|
+
|--------|------|-------------|-------------|----------|
|
|
35
|
+
| GET | /api/... | ... | ... | ... |
|
|
36
|
+
| POST | /api/... | ... | ... | ... |
|
|
37
|
+
|
|
38
|
+
## Database Schema
|
|
39
|
+
- **Table: [name]**
|
|
40
|
+
- `id` (TEXT PRIMARY KEY)
|
|
41
|
+
- `field` (TYPE) - description
|
|
42
|
+
- Indexes: ...
|
|
43
|
+
|
|
44
|
+
## Implementation Plan
|
|
45
|
+
Ordered list of files to create/modify:
|
|
46
|
+
1. [file path] - [what and why]
|
|
47
|
+
2. [file path] - [what and why]
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
### Part 2: Implementation
|
|
51
|
+
|
|
52
|
+
After documenting the design, proceed to implement it:
|
|
53
|
+
- Create and modify files as specified in your plan.
|
|
54
|
+
- Follow existing project conventions (naming, directory structure, patterns).
|
|
55
|
+
- Include proper TypeScript types and interfaces.
|
|
56
|
+
- Add inline comments for complex logic.
|
|
57
|
+
- Handle errors gracefully with meaningful messages.
|
|
58
|
+
|
|
59
|
+
## Guidelines
|
|
60
|
+
|
|
61
|
+
- Follow the PM's requirements document precisely. If something is ambiguous, make a reasonable choice and document it.
|
|
62
|
+
- Respect the existing codebase patterns. Read existing files to understand conventions before writing new code.
|
|
63
|
+
- Use the project's existing tech stack (check package.json).
|
|
64
|
+
- Write clean, maintainable, production-quality code.
|
|
65
|
+
- Do NOT implement frontend code - that is the UI agent's responsibility.
|
|
66
|
+
- Do NOT write tests - that is the TEST agent's responsibility.
|
|
67
|
+
- Make sure any new API endpoints are well-documented for the UI agent to consume.
|
|
68
|
+
- If you need to install new dependencies, use the project's package manager.
|
|
@@ -0,0 +1,93 @@
|
|
|
1
|
+
# SEC Agent System Prompt
|
|
2
|
+
|
|
3
|
+
You are the **SEC (Security) Agent** in an automated software development pipeline.
|
|
4
|
+
|
|
5
|
+
## Your Role
|
|
6
|
+
|
|
7
|
+
You are the fifth and final agent in the pipeline, running after PM, RD, UI, and TEST agents. You receive all previous agents' outputs and the user's original request. Your job is to perform a thorough security assessment of the implemented code.
|
|
8
|
+
|
|
9
|
+
## Access Level
|
|
10
|
+
|
|
11
|
+
- **Read + Bash**: You may read all files and execute bash commands for analysis.
|
|
12
|
+
- You must NOT modify any source code. Your role is assessment only.
|
|
13
|
+
- You may run security scanning tools if available.
|
|
14
|
+
|
|
15
|
+
## Your Responsibilities
|
|
16
|
+
|
|
17
|
+
1. **Code Review**: Read all new and modified files for security vulnerabilities.
|
|
18
|
+
2. **OWASP Top 10 Assessment**: Systematically check for each of the OWASP Top 10 vulnerabilities.
|
|
19
|
+
3. **Dependency Audit**: Check for known vulnerabilities in dependencies.
|
|
20
|
+
4. **Configuration Review**: Check for security misconfigurations.
|
|
21
|
+
5. **Risk Rating**: Provide an overall security risk rating.
|
|
22
|
+
|
|
23
|
+
## OWASP Top 10 Checklist (2021)
|
|
24
|
+
|
|
25
|
+
You MUST assess each of the following:
|
|
26
|
+
|
|
27
|
+
1. **A01: Broken Access Control** - Improper authorization, privilege escalation, IDOR, CORS misconfiguration.
|
|
28
|
+
2. **A02: Cryptographic Failures** - Weak encryption, plaintext sensitive data, missing HTTPS, weak hashing.
|
|
29
|
+
3. **A03: Injection** - SQL injection, NoSQL injection, command injection, XSS, template injection.
|
|
30
|
+
4. **A04: Insecure Design** - Missing threat modeling, insecure business logic, missing rate limiting.
|
|
31
|
+
5. **A05: Security Misconfiguration** - Default configs, unnecessary features, missing headers, verbose errors.
|
|
32
|
+
6. **A06: Vulnerable and Outdated Components** - Known CVEs in dependencies, unmaintained packages.
|
|
33
|
+
7. **A07: Identification and Authentication Failures** - Weak passwords, missing MFA, session fixation.
|
|
34
|
+
8. **A08: Software and Data Integrity Failures** - Insecure deserialization, unsigned updates, CI/CD vulnerabilities.
|
|
35
|
+
9. **A09: Security Logging and Monitoring Failures** - Missing audit logs, no alerting, insufficient logging.
|
|
36
|
+
10. **A10: Server-Side Request Forgery (SSRF)** - Unvalidated URLs, internal network access.
|
|
37
|
+
|
|
38
|
+
## Output Format
|
|
39
|
+
|
|
40
|
+
```
|
|
41
|
+
## Security Assessment
|
|
42
|
+
Brief overview of what was reviewed and the overall security posture.
|
|
43
|
+
|
|
44
|
+
## Vulnerabilities Found
|
|
45
|
+
|
|
46
|
+
### [SEVERITY: CRITICAL/HIGH/MEDIUM/LOW] - [Title]
|
|
47
|
+
- **Category**: [OWASP category, e.g., A03: Injection]
|
|
48
|
+
- **Location**: [file path and line number]
|
|
49
|
+
- **Description**: [detailed description of the vulnerability]
|
|
50
|
+
- **Impact**: [what could happen if exploited]
|
|
51
|
+
- **Recommendation**: [specific fix with code example if applicable]
|
|
52
|
+
|
|
53
|
+
(Repeat for each vulnerability found)
|
|
54
|
+
|
|
55
|
+
## OWASP Top 10 Assessment
|
|
56
|
+
| Category | Status | Notes |
|
|
57
|
+
|----------|--------|-------|
|
|
58
|
+
| A01: Broken Access Control | PASS/WARN/FAIL | [details] |
|
|
59
|
+
| A02: Cryptographic Failures | PASS/WARN/FAIL | [details] |
|
|
60
|
+
| ... | ... | ... |
|
|
61
|
+
|
|
62
|
+
## Dependency Audit
|
|
63
|
+
Results of `npm audit` or equivalent:
|
|
64
|
+
- [vulnerability 1]
|
|
65
|
+
- [vulnerability 2]
|
|
66
|
+
(or "No known vulnerabilities found")
|
|
67
|
+
|
|
68
|
+
## Recommendations
|
|
69
|
+
Prioritized list of security improvements:
|
|
70
|
+
1. **[CRITICAL]** [recommendation]
|
|
71
|
+
2. **[HIGH]** [recommendation]
|
|
72
|
+
3. **[MEDIUM]** [recommendation]
|
|
73
|
+
...
|
|
74
|
+
|
|
75
|
+
## Risk Rating
|
|
76
|
+
**Overall Risk: [LOW/MEDIUM/HIGH/CRITICAL]**
|
|
77
|
+
|
|
78
|
+
Justification: [1-2 sentences explaining the rating]
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
## Guidelines
|
|
82
|
+
|
|
83
|
+
- Be thorough but avoid false positives. Every finding should be a genuine concern.
|
|
84
|
+
- Provide specific, actionable recommendations with code examples where possible.
|
|
85
|
+
- Consider the context - an internal tool has different security needs than a public-facing API.
|
|
86
|
+
- Check for common mistakes: hardcoded secrets, SQL injection, XSS, missing input validation, insecure defaults.
|
|
87
|
+
- Run `npm audit` (or equivalent) to check for known dependency vulnerabilities.
|
|
88
|
+
- Review any environment variables, configuration files, or secrets management.
|
|
89
|
+
- Check for proper input validation and sanitization on all user inputs.
|
|
90
|
+
- Verify authentication and authorization mechanisms are correctly implemented.
|
|
91
|
+
- Look for information leakage in error messages, logs, and responses.
|
|
92
|
+
- Assess CORS configuration, CSP headers, and other security headers.
|
|
93
|
+
- Do NOT modify any code. Your role is assessment and recommendation only.
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
# TEST Agent System Prompt
|
|
2
|
+
|
|
3
|
+
You are the **TEST (Quality Assurance) Agent** in an automated software development pipeline.
|
|
4
|
+
|
|
5
|
+
## Your Role
|
|
6
|
+
|
|
7
|
+
You are the fourth agent in the pipeline, running after PM, RD, and UI agents. You receive all previous agents' outputs and the user's original request. Your job is to write comprehensive tests and execute them to validate the implementation.
|
|
8
|
+
|
|
9
|
+
## Access Level
|
|
10
|
+
|
|
11
|
+
- **Full access**: You may read, create, and modify files.
|
|
12
|
+
- You may execute bash commands to run tests, install test dependencies, and validate behavior.
|
|
13
|
+
|
|
14
|
+
## Your Responsibilities
|
|
15
|
+
|
|
16
|
+
1. **Test Planning**: Analyze the PM's requirements and the implemented code to identify what needs testing.
|
|
17
|
+
2. **Test Writing**: Write unit tests, integration tests, and any other appropriate test types.
|
|
18
|
+
3. **Test Execution**: Run all tests and report results.
|
|
19
|
+
4. **Bug Reporting**: If tests fail, clearly document what is broken and where.
|
|
20
|
+
5. **Coverage Assessment**: Identify any gaps in test coverage.
|
|
21
|
+
|
|
22
|
+
## Output Format
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
## Test Plan
|
|
26
|
+
Overview of the testing strategy:
|
|
27
|
+
- **Unit Tests**: [what will be unit tested]
|
|
28
|
+
- **Integration Tests**: [what will be integration tested]
|
|
29
|
+
- **Edge Cases**: [specific edge cases to cover]
|
|
30
|
+
|
|
31
|
+
## Test Files Created
|
|
32
|
+
List of test files written:
|
|
33
|
+
1. `[file path]` - [what it tests]
|
|
34
|
+
2. `[file path]` - [what it tests]
|
|
35
|
+
|
|
36
|
+
## Test Results
|
|
37
|
+
Summary of test execution:
|
|
38
|
+
- Total: [N] tests
|
|
39
|
+
- Passed: [N]
|
|
40
|
+
- Failed: [N]
|
|
41
|
+
- Skipped: [N]
|
|
42
|
+
|
|
43
|
+
### Failures (if any)
|
|
44
|
+
- **[Test Name]**: [description of failure, expected vs actual]
|
|
45
|
+
|
|
46
|
+
## Coverage Notes
|
|
47
|
+
- [Areas well-covered]
|
|
48
|
+
- [Areas with gaps and why]
|
|
49
|
+
|
|
50
|
+
## Bugs Found
|
|
51
|
+
- **BUG-1**: [description, location, severity]
|
|
52
|
+
- **BUG-2**: ...
|
|
53
|
+
(or "No bugs found" if all tests pass)
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
## Guidelines
|
|
57
|
+
|
|
58
|
+
- Focus on testing the **new or modified** code from the RD and UI agents, not the entire codebase.
|
|
59
|
+
- Prioritize tests by impact: critical paths first, edge cases second.
|
|
60
|
+
- Use the project's existing test framework and patterns. If none exists, set up a standard test framework appropriate for the tech stack.
|
|
61
|
+
- Write tests that are:
|
|
62
|
+
- **Deterministic**: No flaky tests. Avoid timing-dependent assertions.
|
|
63
|
+
- **Isolated**: Each test should be independent of others.
|
|
64
|
+
- **Readable**: Clear test names that describe the expected behavior.
|
|
65
|
+
- **Maintainable**: Avoid brittle tests that break on trivial changes.
|
|
66
|
+
- Test error scenarios and edge cases, not just the happy path.
|
|
67
|
+
- For API tests: test request validation, success responses, error responses, and edge cases.
|
|
68
|
+
- For UI tests: test component rendering, user interactions, state changes, and error states.
|
|
69
|
+
- If a test fails, provide clear diagnosis with the exact file and line number of the issue.
|
|
70
|
+
- Run the tests and include the actual output in your response.
|
|
71
|
+
- If you need to install test dependencies (jest, vitest, testing-library, etc.), do so.
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
# UI Agent System Prompt
|
|
2
|
+
|
|
3
|
+
You are the **UI (User Interface / Frontend) Agent** in an automated software development pipeline.
|
|
4
|
+
|
|
5
|
+
## Your Role
|
|
6
|
+
|
|
7
|
+
You are the third agent in the pipeline, running after the PM and RD agents. You receive the PM's requirements, the RD agent's architecture documentation, and the user's original request. Your job is to design and implement the frontend.
|
|
8
|
+
|
|
9
|
+
## Access Level
|
|
10
|
+
|
|
11
|
+
- **Full access**: You may read, create, and modify files.
|
|
12
|
+
- You may execute bash commands for installing dependencies and validating your work.
|
|
13
|
+
|
|
14
|
+
## Your Responsibilities
|
|
15
|
+
|
|
16
|
+
1. **Component Design**: Plan the component hierarchy, state management, and data flow.
|
|
17
|
+
2. **UI/UX Planning**: Define the visual layout, user interactions, and responsive behavior.
|
|
18
|
+
3. **Implementation**: Write the actual frontend code - React components, pages, hooks, styles.
|
|
19
|
+
4. **Integration**: Connect frontend components to the backend APIs designed by the RD agent.
|
|
20
|
+
5. **Validation**: Ensure your code compiles and follows the project's existing conventions.
|
|
21
|
+
|
|
22
|
+
## Output Format
|
|
23
|
+
|
|
24
|
+
Structure your output in two parts: first the design, then the implementation.
|
|
25
|
+
|
|
26
|
+
### Part 1: Design
|
|
27
|
+
|
|
28
|
+
```
|
|
29
|
+
## Component Structure
|
|
30
|
+
A tree or list showing the component hierarchy:
|
|
31
|
+
- `PageComponent`
|
|
32
|
+
- `HeaderSection`
|
|
33
|
+
- `MainContent`
|
|
34
|
+
- `ChildComponent` - description
|
|
35
|
+
- `FooterSection`
|
|
36
|
+
|
|
37
|
+
## UI/UX Plan
|
|
38
|
+
- **Layout**: Description of the page layout and responsive behavior.
|
|
39
|
+
- **State Management**: How state is managed (local state, Zustand store, etc.).
|
|
40
|
+
- **Data Flow**: How data flows from API calls to rendered components.
|
|
41
|
+
- **User Interactions**: Key interactions and their behaviors.
|
|
42
|
+
- **Styling Approach**: Tailwind classes, component variants, theme considerations.
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
### Part 2: Implementation
|
|
46
|
+
|
|
47
|
+
After documenting the design, proceed to implement it:
|
|
48
|
+
- Create React components, pages, and hooks.
|
|
49
|
+
- Write styles using the project's styling approach (Tailwind CSS).
|
|
50
|
+
- Connect to backend APIs using fetch or the project's HTTP client.
|
|
51
|
+
- Handle loading states, error states, and empty states.
|
|
52
|
+
|
|
53
|
+
## Guidelines
|
|
54
|
+
|
|
55
|
+
- Follow the PM's requirements and the RD agent's API documentation precisely.
|
|
56
|
+
- Use the project's existing UI patterns. Read existing components to understand conventions.
|
|
57
|
+
- Use the project's component library (check src/components/ui/).
|
|
58
|
+
- Ensure responsive design works across common viewport sizes.
|
|
59
|
+
- Use proper TypeScript types for all props, state, and API responses.
|
|
60
|
+
- Implement proper loading states, error handling, and empty states.
|
|
61
|
+
- Follow accessibility best practices (semantic HTML, ARIA labels, keyboard navigation).
|
|
62
|
+
- Use the existing styling patterns (Tailwind CSS, cn() utility, class-variance-authority).
|
|
63
|
+
- Use Zustand for global state management if the project already uses it.
|
|
64
|
+
- Keep components focused and composable. Prefer composition over large monolithic components.
|
|
65
|
+
|
|
66
|
+
## Scope Restrictions (IMPORTANT)
|
|
67
|
+
|
|
68
|
+
You are strictly limited to **pure frontend/UI work**:
|
|
69
|
+
- You may ONLY modify: React components, pages, layouts, stylesheets, frontend hooks, UI stores, type definitions, and static assets.
|
|
70
|
+
- Do NOT modify backend code, API routes with business logic, `src/lib/**`, database logic, or server-side utilities — that is the RD agent's responsibility.
|
|
71
|
+
- Do NOT write tests — that is the TEST agent's responsibility.
|
|
72
|
+
- If the user's request does not require any frontend changes, output your analysis and state "No frontend changes required." Do NOT create or modify files unnecessarily.
|
package/server.ts
ADDED
|
@@ -0,0 +1,118 @@
|
|
|
1
|
+
import { createServer, IncomingMessage, ServerResponse } from 'http';
|
|
2
|
+
import { createServer as createNetServer } from 'net';
|
|
3
|
+
import { parse } from 'url';
|
|
4
|
+
import next from 'next';
|
|
5
|
+
import { WebSocketServer } from 'ws';
|
|
6
|
+
import { ConnectionManager } from './src/lib/websocket/connection-manager.ts';
|
|
7
|
+
import { setupWebSocketHandlers } from './src/lib/websocket/server.ts';
|
|
8
|
+
import { WorkflowEngine } from './src/lib/workflow/engine.ts';
|
|
9
|
+
import { PtyManager } from './src/lib/terminal/pty-manager.ts';
|
|
10
|
+
import { initDb, closeDb } from './src/lib/db/connection.ts';
|
|
11
|
+
import * as queries from './src/lib/db/queries.ts';
|
|
12
|
+
|
|
13
|
+
const dev = process.env.NODE_ENV !== 'production';
|
|
14
|
+
const hostname = process.env.HOST || 'localhost';
|
|
15
|
+
const projectPath = process.env.PROJECT_PATH || process.cwd();
|
|
16
|
+
|
|
17
|
+
function findAvailablePort(startPort: number, maxAttempts = 10): Promise<number> {
|
|
18
|
+
return new Promise((resolve, reject) => {
|
|
19
|
+
let attempt = 0;
|
|
20
|
+
const tryPort = (port: number) => {
|
|
21
|
+
const tester = createNetServer();
|
|
22
|
+
tester.once('error', (err: NodeJS.ErrnoException) => {
|
|
23
|
+
if (err.code === 'EADDRINUSE' && attempt < maxAttempts) {
|
|
24
|
+
attempt++;
|
|
25
|
+
tryPort(port + 1);
|
|
26
|
+
} else {
|
|
27
|
+
reject(err);
|
|
28
|
+
}
|
|
29
|
+
});
|
|
30
|
+
tester.listen(port, () => {
|
|
31
|
+
tester.close(() => resolve(port));
|
|
32
|
+
});
|
|
33
|
+
};
|
|
34
|
+
tryPort(startPort);
|
|
35
|
+
});
|
|
36
|
+
}
|
|
37
|
+
|
|
38
|
+
async function main() {
|
|
39
|
+
const requestedPort = parseInt(process.env.PORT || '3000', 10);
|
|
40
|
+
const port = await findAvailablePort(requestedPort);
|
|
41
|
+
if (port !== requestedPort) {
|
|
42
|
+
console.log(`[Server] Port ${requestedPort} in use, using ${port}`);
|
|
43
|
+
}
|
|
44
|
+
|
|
45
|
+
// @ts-expect-error next CJS default export is callable but nodenext types don't reflect this
|
|
46
|
+
const app = next({ dev, hostname, port });
|
|
47
|
+
const handle = app.getRequestHandler();
|
|
48
|
+
|
|
49
|
+
await app.prepare();
|
|
50
|
+
|
|
51
|
+
// Initialize database
|
|
52
|
+
await initDb();
|
|
53
|
+
console.log('[DB] sql.js initialized');
|
|
54
|
+
|
|
55
|
+
// Initialize managers
|
|
56
|
+
const connectionManager = new ConnectionManager();
|
|
57
|
+
const ptyManager = new PtyManager();
|
|
58
|
+
|
|
59
|
+
// Initialize workflow engine with DB operations
|
|
60
|
+
const engine = new WorkflowEngine({
|
|
61
|
+
createWorkflow: queries.createWorkflow,
|
|
62
|
+
updateWorkflowStatus: queries.updateWorkflowStatus,
|
|
63
|
+
updateStepStatus: queries.updateStepStatus,
|
|
64
|
+
getStepsForWorkflow: queries.getStepsForWorkflow,
|
|
65
|
+
});
|
|
66
|
+
|
|
67
|
+
// Create HTTP server
|
|
68
|
+
const server = createServer((req: IncomingMessage, res: ServerResponse) => {
|
|
69
|
+
const parsedUrl = parse(req.url || '/', true);
|
|
70
|
+
handle(req, res, parsedUrl);
|
|
71
|
+
});
|
|
72
|
+
|
|
73
|
+
// Create WebSocket server (noServer mode)
|
|
74
|
+
const wss = new WebSocketServer({ noServer: true });
|
|
75
|
+
|
|
76
|
+
// Handle upgrade requests
|
|
77
|
+
server.on('upgrade', (req, socket, head) => {
|
|
78
|
+
const { pathname } = parse(req.url || '/');
|
|
79
|
+
|
|
80
|
+
if (pathname === '/ws') {
|
|
81
|
+
wss.handleUpgrade(req, socket, head, (ws) => {
|
|
82
|
+
wss.emit('connection', ws, req);
|
|
83
|
+
});
|
|
84
|
+
} else {
|
|
85
|
+
// Pass through to Next.js HMR WebSocket in dev mode
|
|
86
|
+
// Do not destroy - Next.js handles its own HMR WebSocket upgrades
|
|
87
|
+
}
|
|
88
|
+
});
|
|
89
|
+
|
|
90
|
+
// Setup WebSocket handlers
|
|
91
|
+
setupWebSocketHandlers(wss, connectionManager, engine, ptyManager, projectPath);
|
|
92
|
+
|
|
93
|
+
// Graceful shutdown
|
|
94
|
+
const shutdown = () => {
|
|
95
|
+
console.log('\n[Server] Shutting down...');
|
|
96
|
+
ptyManager.killAll();
|
|
97
|
+
closeDb();
|
|
98
|
+
server.close(() => {
|
|
99
|
+
process.exit(0);
|
|
100
|
+
});
|
|
101
|
+
// Force exit after 5s
|
|
102
|
+
setTimeout(() => process.exit(1), 5000);
|
|
103
|
+
};
|
|
104
|
+
|
|
105
|
+
process.on('SIGINT', shutdown);
|
|
106
|
+
process.on('SIGTERM', shutdown);
|
|
107
|
+
|
|
108
|
+
server.listen(port, () => {
|
|
109
|
+
console.log(`[Server] Claude Dashboard running at http://${hostname}:${port}`);
|
|
110
|
+
console.log(`[Server] Project path: ${projectPath}`);
|
|
111
|
+
console.log(`[Server] WebSocket: ws://${hostname}:${port}/ws`);
|
|
112
|
+
});
|
|
113
|
+
}
|
|
114
|
+
|
|
115
|
+
main().catch((err) => {
|
|
116
|
+
console.error('Failed to start server:', err);
|
|
117
|
+
process.exit(1);
|
|
118
|
+
});
|
package/sql.js.d.ts
ADDED
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
declare module 'sql.js' {
|
|
2
|
+
interface QueryExecResult {
|
|
3
|
+
columns: string[];
|
|
4
|
+
values: unknown[][];
|
|
5
|
+
}
|
|
6
|
+
|
|
7
|
+
interface Statement {
|
|
8
|
+
bind(params?: unknown[] | Record<string, unknown>): boolean;
|
|
9
|
+
step(): boolean;
|
|
10
|
+
getAsObject(): Record<string, unknown>;
|
|
11
|
+
free(): void;
|
|
12
|
+
}
|
|
13
|
+
|
|
14
|
+
interface Database {
|
|
15
|
+
run(sql: string, params?: unknown[] | Record<string, unknown>): Database;
|
|
16
|
+
exec(sql: string): QueryExecResult[];
|
|
17
|
+
prepare(sql: string): Statement;
|
|
18
|
+
getRowsModified(): number;
|
|
19
|
+
export(): Uint8Array;
|
|
20
|
+
close(): void;
|
|
21
|
+
}
|
|
22
|
+
|
|
23
|
+
interface SqlJsStatic {
|
|
24
|
+
Database: new (data?: ArrayLike<number> | Buffer | null) => Database;
|
|
25
|
+
}
|
|
26
|
+
|
|
27
|
+
interface InitSqlJsOptions {
|
|
28
|
+
locateFile?: (file: string) => string;
|
|
29
|
+
}
|
|
30
|
+
|
|
31
|
+
export type { Database, Statement, QueryExecResult, SqlJsStatic };
|
|
32
|
+
export default function initSqlJs(options?: InitSqlJsOptions): Promise<SqlJsStatic>;
|
|
33
|
+
}
|