feat: architect agent — propose development sprints for vision issues #96

New issue

Closed

opened 2026-04-01 08:02:44 +00:00 by dev-bot · 1 comment

dev-bot commented

2026-04-01 08:02:44 +00:00

Collaborator

Summary

A new agent role: architect. Polls for vision-labeled issues, proposes development sprints via PRs on the ops repo. The sprint PR goes through three phases:

Sprint PR lifecycle

Phase 1: PITCH (architect creates PR)
  "Here's what this sprint would enable, what we can't do now,
   complexity, risks, new infra to maintain."
  Human: ACCEPT or REJECT (with reason)

Phase 2: QUESTIONS (architect updates PR after accept)
  Design forks as multiple choice (Q1: A/B/C, Q2: A/B/C...)
  Human answers: Q1: A, Q2: B, ...

Phase 3: FILE (architect reads answers, files sub-issues)
  Sub-issues filed to backlog using templates.
  PR merged — sprint spec persists in ops/sprints/.

If human rejects the pitch: architect journals the reason (learning), closes the PR.

See #95 for the planner change that labels issues vision (the architect's input).

Sub-issues (sequential)

#99 — scaffold: architect-bot user, directory, run script, stub formula
#100 — formula: research + pitch creation
#101 — formula: accept/reject handling + design fork questions
#102 — formula: answer parsing + sub-issue filing

Design decisions

Three-phase PR: pitch first, questions only after accept, file after answers
Rejection goes to journal: architect learns what pitches get rejected and why
Answer format: Human answers Q1: A, Q2: B etc. Pattern matching.
Accept/reject format: Human comments ACCEPT or REJECT: <reason>
Sprint storage: PR merged after filing. Sprint spec persists in ops/sprints/.
Meta-constraints: Prefer gluecode, max 7 sub-issues, flag cost/risk.
Model: opus. Poll: every 6 hours.

Acceptance

All four sub-issues closed. Architect can pitch sprints, handle accept/reject, run multi-round Q&A, and file template-conforming sub-issues.

## Summary A new agent role: **architect**. Polls for `vision`-labeled issues, proposes development sprints via PRs on the ops repo. The sprint PR goes through three phases: ### Sprint PR lifecycle ``` Phase 1: PITCH (architect creates PR) "Here's what this sprint would enable, what we can't do now, complexity, risks, new infra to maintain." Human: ACCEPT or REJECT (with reason) Phase 2: QUESTIONS (architect updates PR after accept) Design forks as multiple choice (Q1: A/B/C, Q2: A/B/C...) Human answers: Q1: A, Q2: B, ... Phase 3: FILE (architect reads answers, files sub-issues) Sub-issues filed to backlog using templates. PR merged — sprint spec persists in ops/sprints/. ``` If human rejects the pitch: architect journals the reason (learning), closes the PR. See #95 for the planner change that labels issues `vision` (the architect's input). ## Sub-issues (sequential) 1. #99 — scaffold: architect-bot user, directory, run script, stub formula 2. #100 — formula: research + pitch creation 3. #101 — formula: accept/reject handling + design fork questions 4. #102 — formula: answer parsing + sub-issue filing ## Design decisions - **Three-phase PR:** pitch first, questions only after accept, file after answers - **Rejection goes to journal:** architect learns what pitches get rejected and why - **Answer format:** Human answers `Q1: A`, `Q2: B` etc. Pattern matching. - **Accept/reject format:** Human comments `ACCEPT` or `REJECT: <reason>` - **Sprint storage:** PR merged after filing. Sprint spec persists in `ops/sprints/`. - **Meta-constraints:** Prefer gluecode, max 7 sub-issues, flag cost/risk. - **Model:** opus. **Poll:** every 6 hours. ## Acceptance All four sub-issues closed. Architect can pitch sprints, handle accept/reject, run multi-round Q&A, and file template-conforming sub-issues.