# 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
```