Synth Nova Manifest

ADR-0017: M4 Autonomous Development Loop — Concept Capture

4 min read

ADR-0017: M4 Autonomous Development Loop — Concept Capture

Status

proposed — This is a vision capture, not an implementation commitment. Status will move to accepted when M4 sprint is scheduled.

Context

The current development workflow requires the founder to act as a manual courier between three agent roles:

  1. Strategist (Claude chat / co-founder role) — formulates tasks, writes prompts, reviews results
  2. Developer (Claude Code on VPS) — implements code, runs tests, commits
  3. QA / Testers (Perplexity, Cowork, other LLM agents) — test the live product in browser, find bugs, produce reports

The founder manually copies prompts from strategist to developer, build results from developer to QA, bug reports from QA back to strategist, and fix prompts back to developer. This loop repeats until the quality target is met.

Estimated 60-70% of dev session time is spent on this mechanical courier work — the same class of problem that M3 Deliberation Chamber solved for strategic questions, but applied to the entire development cycle.

This vision was articulated on 2026-04-17 during a session where M3 Chamber UI was completed, and the pattern became clear: if Chamber can automate multi-LLM deliberation for strategic questions, the same orchestration pattern can automate the strategist→developer→QA loop.

Decision

Capture the M4 Autonomous Development Loop as a strategic roadmap document for future implementation. The concept introduces four agent types:

  • Health Agents — continuous quality monitoring per module (M1, M2, M3)
  • SOS Agents — emergency automated diagnosis and escalation when something breaks
  • QA Agents — multi-LLM browser-based testing replacing manual QA handoffs
  • Courier Agent (Orchestrator) — replaces the founder’s courier role, managing the full strategist→developer→QA loop

The founder’s role shifts from courier to decision-maker, vision-setter, and quality arbiter of last resort — intervening only per CriticalityPolicy Level 3.

Implementation is deferred to post-M2 completion. This ADR captures the vision so it is preserved across sessions and available to future sprints.

Alternatives Considered

(a) Keep manual workflow. The founder continues as courier indefinitely. Rejected because it caps development velocity at founder availability and wastes 60-70% of session time on mechanical work.

(b) Partial automation — QA only. Automate only the QA step (multi-LLM browser testing) while keeping manual strategist↔developer handoff. This is simpler to build and delivers the most immediate time savings (QA is the most tedious handoff). However, it leaves the strategist→developer handoff manual and doesn’t address the full courier problem. Could serve as a stepping stone toward full M4.

(c) Full autonomous loop (captured). Automate the entire strategist→developer→QA cycle with a Courier Agent orchestrator and specialized Health/SOS/QA agents. Most ambitious, highest payoff, highest implementation cost. This is the vision captured in this ADR.

Consequences

Positive:

  • Vision is preserved in manifest — future sessions have full context without founder re-explaining
  • Clear articulation of agent types (Health, SOS, QA, Courier) provides implementation targets
  • Relationship to existing modules (M1, M2, M3) and governance (Constitution, CriticalityPolicy) is documented
  • Open questions are explicitly captured for resolution before implementation begins

Negative / Risks:

  • Implementation is deferred — no immediate workflow improvement
  • Vision may evolve as M2 build reveals new patterns or constraints
  • Cost model for multi-LLM QA loops is unknown — could be expensive at scale
  • Security model for Courier Agent (VPS access, git, Streamlit) needs design

Neutral:

  • Does not affect current M2 sprint or any in-progress work
  • Does not create technical debt — this is a concept document only

References

Graph View

Backlinks