architect: process evolution lifecycle #35

Merged

disinto-admin merged 1 commit from architect/process-evolution-lifecycle into main

2026-04-15 17:39:12 +00:00

architect-bot commented

2026-04-15 10:06:14 +00:00

Collaborator

Sprint pitch: process evolution lifecycle

Vision issue: #418 — Process evolution: observe-propose-shadow-promote lifecycle

What this enables

The factory can safely mutate its own processes. Today agents observe project state but not process state (review latency, failure rates, bottlenecks). Process changes are manual formula edits with no testing path.

After this sprint:

Structured process metrics collection (review latency, failure rates, escalation frequency)
Predictor proposes process changes as structured RFCs with evidence
Shadow-run infrastructure: test process changes alongside current process before promotion
Human-gated promotion via existing vault/PR approval pattern

Complexity

~6-8 files across predictor, planner, knowledge graph, formula-session, evidence pipeline
~60% gluecode (extending prediction-triage, graph nodes, evidence wiring) / ~40% greenfield (metrics collector, RFC format, shadow-run comparator)
6-8 estimated sub-issues

Risks

Compute cost — shadow-running doubles resource usage; needs cycle cap
Wrong metrics — must choose carefully to avoid optimizing speed over quality
Scope creep — deliver for ONE process as proof-of-concept, not all
Over-engineering — lightweight RFC-in-ops-repo, not a framework

Cost — new infra

Process metrics formula (new TOML, predictor/planner schedule)
RFC directory in ops repo (markdown files)
Shadow-run comparator step in formula-session.sh
No new services or containers

Recommendation

Worth it — scope to one proof-of-concept process. The prediction-triage workflow already implements observe→propose. Extending to shadow→promote is natural evolution. Prove the pattern on one process mutation first, generalize later.

Reply ACCEPT to proceed with design questions, or REJECT: <reason> to decline.

## Sprint pitch: process evolution lifecycle **Vision issue**: #418 — Process evolution: observe-propose-shadow-promote lifecycle ### What this enables The factory can **safely mutate its own processes**. Today agents observe project state but not process state (review latency, failure rates, bottlenecks). Process changes are manual formula edits with no testing path. After this sprint: - Structured process metrics collection (review latency, failure rates, escalation frequency) - Predictor proposes process changes as structured RFCs with evidence - Shadow-run infrastructure: test process changes alongside current process before promotion - Human-gated promotion via existing vault/PR approval pattern ### Complexity - ~6-8 files across predictor, planner, knowledge graph, formula-session, evidence pipeline - ~60% gluecode (extending prediction-triage, graph nodes, evidence wiring) / ~40% greenfield (metrics collector, RFC format, shadow-run comparator) - 6-8 estimated sub-issues ### Risks 1. **Compute cost** — shadow-running doubles resource usage; needs cycle cap 2. **Wrong metrics** — must choose carefully to avoid optimizing speed over quality 3. **Scope creep** — deliver for ONE process as proof-of-concept, not all 4. **Over-engineering** — lightweight RFC-in-ops-repo, not a framework ### Cost — new infra - Process metrics formula (new TOML, predictor/planner schedule) - RFC directory in ops repo (markdown files) - Shadow-run comparator step in formula-session.sh - No new services or containers ### Recommendation **Worth it — scope to one proof-of-concept process.** The prediction-triage workflow already implements observe→propose. Extending to shadow→promote is natural evolution. Prove the pattern on one process mutation first, generalize later. --- Reply `ACCEPT` to proceed with design questions, or `REJECT: <reason>` to decline.

architect-bot added 1 commit 2026-04-15 10:06:15 +00:00