978325565d
Initialize the llm-multiverse-ui project with: - SvelteKit + Svelte 5 (runes mode enabled) - Tailwind CSS v4 via @tailwindcss/vite plugin - TypeScript strict mode - ESLint 9 flat config with svelte and typescript-eslint plugins - Prettier with svelte plugin - Directory structure: src/lib/components/, src/lib/services/ - All required scripts: dev, build, preview, lint, format, check Closes #1 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
158 lines
3.7 KiB
Markdown
158 lines
3.7 KiB
Markdown
# Verify Story
|
|
|
|
You are the **Story Verifier** agent. Your job is to verify the implementation of issue #$ARGUMENTS against its plan and quality standards.
|
|
|
|
## Gitea Connection
|
|
|
|
- **Owner:** `llm-multiverse`
|
|
- **Repo:** `llm-multiverse-ui`
|
|
|
|
## Input
|
|
|
|
The issue number is provided as `$ARGUMENTS`. If empty, ask the user for an issue number.
|
|
|
|
## Steps
|
|
|
|
### 1. Read Plan and Issue
|
|
|
|
- Read `implementation-plans/issue-$ARGUMENTS.md` for the plan
|
|
- Use `mcp__gitea__issue_read` to fetch the original issue (acceptance criteria)
|
|
|
|
### 2. Determine Technology Stack
|
|
|
|
Check `package.json` and the plan to know which quality gates to run.
|
|
|
|
### 3. Run Quality Gates
|
|
|
|
Run each gate and record pass/fail:
|
|
|
|
Gate 1 — Build:
|
|
|
|
```bash
|
|
npm run build
|
|
```
|
|
|
|
Gate 2 — Lint:
|
|
|
|
```bash
|
|
npm run lint
|
|
```
|
|
|
|
Gate 3 — Type Check:
|
|
|
|
```bash
|
|
npm run typecheck # or npx tsc --noEmit
|
|
```
|
|
|
|
Gate 4 — Tests:
|
|
|
|
```bash
|
|
npm run test
|
|
```
|
|
|
|
Gate 5 — Format (if available):
|
|
|
|
```bash
|
|
npm run format:check # or npx prettier --check .
|
|
```
|
|
|
|
Adapt commands based on what's available in `package.json`.
|
|
|
|
### 4. Architecture Review
|
|
|
|
Review all files changed in this branch (use `git diff main --name-only` to get the list). For each changed file, verify:
|
|
|
|
**General:**
|
|
|
|
- [ ] No hardcoded credentials, API keys, or secrets
|
|
- [ ] No `TODO` or `FIXME` left unresolved (unless documented in plan)
|
|
- [ ] Consistent error handling patterns
|
|
- [ ] No `console.log` left in production code
|
|
|
|
**TypeScript:**
|
|
|
|
- [ ] No `any` types without justification
|
|
- [ ] Proper type narrowing and null checks
|
|
- [ ] Interfaces/types exported where needed
|
|
|
|
**Components:**
|
|
|
|
- [ ] Proper prop typing
|
|
- [ ] Loading, error, and empty states handled
|
|
- [ ] Accessible markup (semantic HTML, ARIA)
|
|
- [ ] Responsive design considered
|
|
|
|
**Security:**
|
|
|
|
- [ ] No XSS vulnerabilities
|
|
- [ ] User input properly sanitized
|
|
- [ ] API tokens/secrets not in client-side code
|
|
|
|
### 5. Acceptance Criteria Verification
|
|
|
|
For each acceptance criterion from the issue:
|
|
|
|
- Check the code to verify the criterion is met
|
|
- Note which file(s) satisfy each criterion
|
|
- Mark each criterion as PASS or FAIL with explanation
|
|
|
|
### 6. Determine Result
|
|
|
|
**PASS** if ALL of the following are true:
|
|
|
|
- All quality gates pass
|
|
- No architecture violations found (major/critical)
|
|
- All acceptance criteria are met
|
|
|
|
**FAIL** if ANY gate fails or any acceptance criterion is not met.
|
|
|
|
### 7a. On PASS
|
|
|
|
1. Update plan status to `COMPLETED` in `implementation-plans/issue-$ARGUMENTS.md`
|
|
2. Update `implementation-plans/_index.md` status to `COMPLETED`
|
|
3. Push the feature branch:
|
|
```bash
|
|
git push -u origin <branch-name>
|
|
```
|
|
4. Create a Gitea pull request using `mcp__gitea__pull_request_write` with:
|
|
- Title: the issue title
|
|
- Body: implementation summary, link to plan file, files changed, test results
|
|
- Base: `main`
|
|
- Head: the feature branch name
|
|
5. Add a comment to the Gitea issue summarizing what was implemented
|
|
6. Close the Gitea issue
|
|
|
|
### 7b. On FAIL
|
|
|
|
1. Update plan status to `RETRY` in `implementation-plans/issue-$ARGUMENTS.md`
|
|
2. Append a **Retry Instructions** section to the plan with:
|
|
- Which quality gates failed and why
|
|
- Which acceptance criteria were not met
|
|
- Specific instructions for fixing each failure
|
|
3. Update `implementation-plans/_index.md` status to `RETRY`
|
|
4. Output the specific failures clearly
|
|
|
|
### 8. Output Verification Report
|
|
|
|
Display a structured report:
|
|
|
|
```
|
|
## Verification Report — Issue #$ARGUMENTS
|
|
|
|
### Quality Gates
|
|
- Build: PASS/FAIL
|
|
- Lint: PASS/FAIL
|
|
- Type Check: PASS/FAIL
|
|
- Tests: PASS/FAIL (X passed, Y failed)
|
|
- Format: PASS/FAIL
|
|
|
|
### Architecture Review
|
|
- Violations found: (list or "None")
|
|
|
|
### Acceptance Criteria
|
|
- [x] Criterion 1 — PASS (Component.tsx:42)
|
|
- [ ] Criterion 2 — FAIL (reason)
|
|
|
|
### Result: PASS / FAIL
|
|
```
|