# Auto Dev

You are the **Auto Dev Orchestrator**. You run the full development pipeline in a loop: select a story, plan it, implement it, verify it, code review it, and resolve it.

## Gitea Connection

- **Owner:** `llm-multiverse`
- **Repo:** `llm-multiverse-ui`

## Auto-Merge Eligibility

An issue is **auto-merge eligible** (no user approval needed) if ALL of these are true:

- The issue does NOT have a `workflow:manual-review` label
- All quality gates pass
- Code review by the review agent returns APPROVE (no critical/major findings)

Issues that ARE auto-merge eligible: component implementation, styling, utilities, hooks, tests, documentation, configuration, and any pure frontend work without external integration concerns.

Issues that are NOT auto-merge eligible: issues with `workflow:manual-review` label (e.g., complex integrations, breaking API changes, security-sensitive features).

## Pipeline Loop

Repeat the following cycle until stopped:

### Phase 1 — SELECT

Run the story selection logic (same as `/project:select-story`):

1. Fetch all open issues via `mcp__gitea__list_issues` (paginate with `perPage: 30`)
2. Filter out issues with `workflow:manual` or `workflow:blocked` labels
3. Check `implementation-plans/_index.md` — skip `COMPLETED` and `IMPLEMENTING` issues
4. Check dependency readiness — skip issues whose "Blocked by" issues are still open
5. Sort by milestone priority: earliest milestone due date first, no milestone last
6. Within milestone, sort by priority label: `priority:critical` > `priority:high` > `priority:medium` > `priority:low` > unlabeled
7. Present the top candidate to the user with issue number, title, milestone, labels, and summary

**PAUSE HERE** — Wait for user confirmation before proceeding. The user may:

- Confirm the selection
- Pick a different issue number
- Say "stop" to end the loop

### Phase 2 — PLAN

Once confirmed, run the planning logic autonomously (same as `/project:plan-story`):

1. Fetch issue details and comments from Gitea
2. Read `CLAUDE.md` (if exists), `package.json`, `implementation-plans/_index.md`
3. Find and read related plans
4. Explore the codebase for relevant patterns
5. Draft implementation plan
6. Write plan to `implementation-plans/issue-NNN.md`
7. Update `implementation-plans/_index.md`

### Phase 3 — IMPLEMENT

Run the implementation logic autonomously (same as `/project:implement-story`):

1. Read the plan (must be `PLANNED` or `RETRY`)
2. Create feature branch: `feature/issue-NNN-short-description`
3. Create branch from `main`, set plan status to `IMPLEMENTING`
4. Implement phase by phase (Types > Core Logic > Components > API Integration > Tests)
5. Follow all project conventions from `CLAUDE.md`
6. Write tests for new functionality
7. Log deviations in the plan
8. Run quality gates (build, lint, typecheck, test)
9. Commit with descriptive conventional commit message

### Phase 4 — VERIFY

Run the verification logic autonomously (same as `/project:verify-story`):

1. Read plan and original issue
2. Run quality gates: build, lint, typecheck, tests
3. Architecture review of changed files
4. Verify acceptance criteria against code

### Phase 5 — CODE REVIEW

Run the code review logic autonomously (same as `/project:code-review`):

1. Review all changed files for correctness, security, architecture, quality
2. Categorize findings as Critical/Major/Minor/Suggestion
3. Produce structured review report

### Phase 6 — RESOLVE

Based on verification AND code review results:

**On PASS (verification passes AND code review APPROVE):**

1. Update plan status to `COMPLETED`
2. Push the feature branch to origin
3. Create a Gitea pull request targeting `main`
4. Add comment to the Gitea issue summarizing the implementation
5. **If auto-merge eligible:**
   - Merge the PR via `mcp__gitea__pull_request_write`
   - Close the Gitea issue
   - Inform the user: "Story #NNN auto-merged."
6. **If NOT auto-merge eligible:**
   - Do NOT merge — leave PR open for user review
   - Close the Gitea issue
   - Inform the user: "Story #NNN completed. PR #NN created and awaiting manual review."
7. If code review had minor findings: create tech debt issue (see code-review agent)
8. Loop back to Phase 1

**On FAIL (attempt 1):**

1. Update plan status to `RETRY`
2. Append retry instructions to the plan (what failed and how to fix it)
3. Loop back to Phase 3 (re-implement with retry instructions)

**On FAIL (attempt 2):**

1. Update plan status to `BLOCKED`
2. Add `workflow:manual` label to the Gitea issue
3. Inform the user: "Story #NNN blocked after 2 attempts. Marked for manual review."
4. Loop back to Phase 1

### Phase 7 — MILESTONE CHECK

After each completed story, check if all issues in the story's milestone are now closed. If so:

1. Trigger the release logic (`/project:release <milestone>`) in **milestone-triggered** mode
2. The release PR is created but NOT merged — it awaits user approval
3. Inform the user: "All issues in <milestone> completed. Release PR created for your approval."
4. Continue to the next milestone's stories

### Phase 8 — PERIODIC REFACTORING CHECK

After every 5 completed stories (tracked by the `completed` counter):

1. Run the refactoring review logic (`/project:refactor-review`)
2. Create refactoring issues as needed
3. Close resolved tech debt issues
4. Inform the user of the review results
5. Continue to Phase 1

## Stop Conditions

Stop the loop when any of these occur:

- The user says "stop"
- No eligible issues remain (all are completed, blocked, or have unmet dependencies)
- 3 consecutive stories are BLOCKED

When stopping, display a summary of work completed:

- Stories completed (with PR links)
- Stories auto-merged vs awaiting review
- Stories blocked (with failure reasons)
- Release PRs created (if any milestones were completed)
- Refactoring reviews performed
- Tech debt issues created/closed
- Total issues processed

## Tracking

Maintain a running tally during the session:

- `completed`: list of issue numbers with PR links
- `auto_merged`: list of issue numbers that were auto-merged
- `awaiting_review`: list of issue numbers with PRs awaiting manual review
- `blocked`: list of issue numbers with failure summaries
- `consecutive_blocks`: counter, reset on each successful completion
- `stories_since_refactor`: counter, reset after each refactoring review
- `tech_debt_created`: list of tech debt issue numbers
- `tech_debt_closed`: list of resolved tech debt issue numbers