checkpoint: 22:00 auto-commit
This commit is contained in:
Timmy Time
@@ -1,4 +1,4 @@
|
||||
# HSTS 1.0 Known Hosts database for GNU Wget.
|
||||
# Edit at your own risk.
|
||||
# <hostname> <port> <incl. subdomains> <created> <max-age>
|
||||
repos-droplet.digitalocean.com 0 1 1775046446 15552000
|
||||
repos-droplet.digitalocean.com 0 1 1775078655 15552000
|
||||
|
||||
@@ -7675,3 +7675,108 @@
|
||||
[2026-04-01T21:00:06.785466] [SUMMARY] Success: False
|
||||
[2026-04-01T21:00:06.785529] [SUMMARY] Errors: 1
|
||||
[2026-04-01T21:00:06.785589] [SESSION] ======================================================================
|
||||
[2026-04-01T21:15:01.585290] [SESSION] ======================================================================
|
||||
[2026-04-01T21:15:01.585535] [SESSION] HEARTBEAT WAKEUP INITIATED
|
||||
[2026-04-01T21:15:01.585615] [SESSION] Timestamp: 2026-04-01T21:15:01.585612
|
||||
[2026-04-01T21:15:01.585678] [SESSION] Session ID: 20260401_211501
|
||||
[2026-04-01T21:15:01.585731] [SESSION] ======================================================================
|
||||
[2026-04-01T21:15:01.585793] [PHASE] PHASE 1: Infrastructure Health Check
|
||||
[2026-04-01T21:15:01.629929] [SUCCESS] Gitea health check: HTTP 200 ✓
|
||||
[2026-04-01T21:15:01.630314] [PHASE] PHASE 2: Repository Status Scan
|
||||
[2026-04-01T21:15:02.007351] [SCAN] Scanned timmy-home: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:15:02.396467] [SCAN] Scanned timmy-config: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:15:02.737260] [SCAN] Scanned the-nexus: 1 issues, 2 PRs open
|
||||
[2026-04-01T21:15:02.918173] [SCAN] Scanned .profile: 0 issues, 0 PRs open
|
||||
[2026-04-01T21:15:02.918427] [PHASE] PHASE 3: Actionable Item Discovery
|
||||
[2026-04-01T21:15:02.918518] [SCAN] Beginning comprehensive actionable item scan...
|
||||
[2026-04-01T21:15:03.038985] [SCAN] Found 1 open PRs in timmy-home
|
||||
[2026-04-01T21:15:03.297700] [HIGH] PRIORITY: Mergeable PR found - #112: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:15:03.752283] [SCAN] Found 9 untriaged issues
|
||||
[2026-04-01T21:15:04.317172] [SCAN] Found 30 documentation issues
|
||||
[2026-04-01T21:15:04.317544] [SUMMARY] Actionable items found: 4 (top priority: 100)
|
||||
[2026-04-01T21:15:04.318031] [SUMMARY] 4 actionable items discovered
|
||||
[2026-04-01T21:15:04.318152] [PHASE] PHASE 4: Action Execution
|
||||
[2026-04-01T21:15:04.318231] [ACTION] EXECUTING: merge_pr on #112 in timmy-home
|
||||
[2026-04-01T21:15:04.318303] [DETAIL] Title: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:15:04.318377] [DETAIL] Priority: 100
|
||||
[2026-04-01T21:15:04.318448] [DETAIL] Est. time: 2 minutes
|
||||
[2026-04-01T21:15:04.318518] [ACTION] Initiating merge of PR #112...
|
||||
[2026-04-01T21:15:04.763034] [ERROR] Merge verification failed for PR #112
|
||||
[2026-04-01T21:15:04.763299] [ERROR] ACTION FAILED: Verification failed
|
||||
[2026-04-01T21:15:04.763380] [SESSION] ======================================================================
|
||||
[2026-04-01T21:15:04.763440] [SESSION] HEARTBEAT SESSION COMPLETE
|
||||
[2026-04-01T21:15:04.763490] [SUMMARY] Actions found: 4
|
||||
[2026-04-01T21:15:04.763559] [SUMMARY] Action taken: merge_pr
|
||||
[2026-04-01T21:15:04.763618] [SUMMARY] Success: False
|
||||
[2026-04-01T21:15:04.763670] [SUMMARY] Errors: 1
|
||||
[2026-04-01T21:15:04.763750] [SESSION] ======================================================================
|
||||
[2026-04-01T21:30:01.517909] [SESSION] ======================================================================
|
||||
[2026-04-01T21:30:01.518295] [SESSION] HEARTBEAT WAKEUP INITIATED
|
||||
[2026-04-01T21:30:01.518470] [SESSION] Timestamp: 2026-04-01T21:30:01.518464
|
||||
[2026-04-01T21:30:01.518608] [SESSION] Session ID: 20260401_213001
|
||||
[2026-04-01T21:30:01.518707] [SESSION] ======================================================================
|
||||
[2026-04-01T21:30:01.518783] [PHASE] PHASE 1: Infrastructure Health Check
|
||||
[2026-04-01T21:30:01.622094] [SUCCESS] Gitea health check: HTTP 200 ✓
|
||||
[2026-04-01T21:30:01.622499] [PHASE] PHASE 2: Repository Status Scan
|
||||
[2026-04-01T21:30:02.423448] [SCAN] Scanned timmy-home: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:30:02.769816] [SCAN] Scanned timmy-config: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:30:03.218933] [SCAN] Scanned the-nexus: 1 issues, 2 PRs open
|
||||
[2026-04-01T21:30:03.508085] [SCAN] Scanned .profile: 0 issues, 0 PRs open
|
||||
[2026-04-01T21:30:03.508365] [PHASE] PHASE 3: Actionable Item Discovery
|
||||
[2026-04-01T21:30:03.508448] [SCAN] Beginning comprehensive actionable item scan...
|
||||
[2026-04-01T21:30:03.702679] [SCAN] Found 1 open PRs in timmy-home
|
||||
[2026-04-01T21:30:04.022566] [HIGH] PRIORITY: Mergeable PR found - #112: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:30:04.551462] [SCAN] Found 10 untriaged issues
|
||||
[2026-04-01T21:30:05.225847] [SCAN] Found 30 documentation issues
|
||||
[2026-04-01T21:30:05.227321] [SUMMARY] Actionable items found: 4 (top priority: 100)
|
||||
[2026-04-01T21:30:05.228001] [SUMMARY] 4 actionable items discovered
|
||||
[2026-04-01T21:30:05.228193] [PHASE] PHASE 4: Action Execution
|
||||
[2026-04-01T21:30:05.228405] [ACTION] EXECUTING: merge_pr on #112 in timmy-home
|
||||
[2026-04-01T21:30:05.228499] [DETAIL] Title: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:30:05.228596] [DETAIL] Priority: 100
|
||||
[2026-04-01T21:30:05.228741] [DETAIL] Est. time: 2 minutes
|
||||
[2026-04-01T21:30:05.228879] [ACTION] Initiating merge of PR #112...
|
||||
[2026-04-01T21:30:05.640482] [ERROR] Merge verification failed for PR #112
|
||||
[2026-04-01T21:30:05.640964] [ERROR] ACTION FAILED: Verification failed
|
||||
[2026-04-01T21:30:05.641213] [SESSION] ======================================================================
|
||||
[2026-04-01T21:30:05.641355] [SESSION] HEARTBEAT SESSION COMPLETE
|
||||
[2026-04-01T21:30:05.641506] [SUMMARY] Actions found: 4
|
||||
[2026-04-01T21:30:05.641607] [SUMMARY] Action taken: merge_pr
|
||||
[2026-04-01T21:30:05.641748] [SUMMARY] Success: False
|
||||
[2026-04-01T21:30:05.641881] [SUMMARY] Errors: 1
|
||||
[2026-04-01T21:30:05.642026] [SESSION] ======================================================================
|
||||
[2026-04-01T21:45:01.159491] [SESSION] ======================================================================
|
||||
[2026-04-01T21:45:01.159937] [SESSION] HEARTBEAT WAKEUP INITIATED
|
||||
[2026-04-01T21:45:01.160158] [SESSION] Timestamp: 2026-04-01T21:45:01.160152
|
||||
[2026-04-01T21:45:01.160290] [SESSION] Session ID: 20260401_214501
|
||||
[2026-04-01T21:45:01.160355] [SESSION] ======================================================================
|
||||
[2026-04-01T21:45:01.160452] [PHASE] PHASE 1: Infrastructure Health Check
|
||||
[2026-04-01T21:45:01.211299] [SUCCESS] Gitea health check: HTTP 200 ✓
|
||||
[2026-04-01T21:45:01.211683] [PHASE] PHASE 2: Repository Status Scan
|
||||
[2026-04-01T21:45:01.572242] [SCAN] Scanned timmy-home: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:45:01.840580] [SCAN] Scanned timmy-config: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:45:02.226941] [SCAN] Scanned the-nexus: 1 issues, 2 PRs open
|
||||
[2026-04-01T21:45:02.470324] [SCAN] Scanned .profile: 0 issues, 0 PRs open
|
||||
[2026-04-01T21:45:02.470674] [PHASE] PHASE 3: Actionable Item Discovery
|
||||
[2026-04-01T21:45:02.470802] [SCAN] Beginning comprehensive actionable item scan...
|
||||
[2026-04-01T21:45:02.611553] [SCAN] Found 1 open PRs in timmy-home
|
||||
[2026-04-01T21:45:02.850777] [HIGH] PRIORITY: Mergeable PR found - #112: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:45:03.270352] [SCAN] Found 10 untriaged issues
|
||||
[2026-04-01T21:45:04.031427] [SCAN] Found 30 documentation issues
|
||||
[2026-04-01T21:45:04.031900] [SUMMARY] Actionable items found: 4 (top priority: 100)
|
||||
[2026-04-01T21:45:04.032465] [SUMMARY] 4 actionable items discovered
|
||||
[2026-04-01T21:45:04.032653] [PHASE] PHASE 4: Action Execution
|
||||
[2026-04-01T21:45:04.032740] [ACTION] EXECUTING: merge_pr on #112 in timmy-home
|
||||
[2026-04-01T21:45:04.032802] [DETAIL] Title: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:45:04.033278] [DETAIL] Priority: 100
|
||||
[2026-04-01T21:45:04.033400] [DETAIL] Est. time: 2 minutes
|
||||
[2026-04-01T21:45:04.033496] [ACTION] Initiating merge of PR #112...
|
||||
[2026-04-01T21:45:04.530647] [ERROR] Merge verification failed for PR #112
|
||||
[2026-04-01T21:45:04.531116] [ERROR] ACTION FAILED: Verification failed
|
||||
[2026-04-01T21:45:04.531278] [SESSION] ======================================================================
|
||||
[2026-04-01T21:45:04.531408] [SESSION] HEARTBEAT SESSION COMPLETE
|
||||
[2026-04-01T21:45:04.531533] [SUMMARY] Actions found: 4
|
||||
[2026-04-01T21:45:04.531602] [SUMMARY] Action taken: merge_pr
|
||||
[2026-04-01T21:45:04.531685] [SUMMARY] Success: False
|
||||
[2026-04-01T21:45:04.532066] [SUMMARY] Errors: 1
|
||||
[2026-04-01T21:45:04.532189] [SESSION] ======================================================================
|
||||
|
||||
@@ -1888,3 +1888,117 @@
|
||||
[2026-04-01T21:00:06.785466] [SUMMARY] Success: False
|
||||
[2026-04-01T21:00:06.785529] [SUMMARY] Errors: 1
|
||||
[2026-04-01T21:00:06.785589] [SESSION] ======================================================================
|
||||
[2026-04-01T21:15:01.585290] [SESSION] ======================================================================
|
||||
[2026-04-01T21:15:01.585535] [SESSION] HEARTBEAT WAKEUP INITIATED
|
||||
[2026-04-01T21:15:01.585615] [SESSION] Timestamp: 2026-04-01T21:15:01.585612
|
||||
[2026-04-01T21:15:01.585678] [SESSION] Session ID: 20260401_211501
|
||||
[2026-04-01T21:15:01.585731] [SESSION] ======================================================================
|
||||
[2026-04-01T21:15:01.585793] [PHASE] PHASE 1: Infrastructure Health Check
|
||||
[2026-04-01T21:15:01.629929] [SUCCESS] Gitea health check: HTTP 200 ✓
|
||||
[2026-04-01T21:15:01.630314] [PHASE] PHASE 2: Repository Status Scan
|
||||
[2026-04-01T21:15:02.007351] [SCAN] Scanned timmy-home: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:15:02.396467] [SCAN] Scanned timmy-config: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:15:02.737260] [SCAN] Scanned the-nexus: 1 issues, 2 PRs open
|
||||
[2026-04-01T21:15:02.918173] [SCAN] Scanned .profile: 0 issues, 0 PRs open
|
||||
[2026-04-01T21:15:02.918427] [PHASE] PHASE 3: Actionable Item Discovery
|
||||
[2026-04-01T21:15:02.918518] [SCAN] Beginning comprehensive actionable item scan...
|
||||
[2026-04-01T21:15:03.038985] [SCAN] Found 1 open PRs in timmy-home
|
||||
[2026-04-01T21:15:03.297700] [HIGH] PRIORITY: Mergeable PR found - #112: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:15:03.752283] [SCAN] Found 9 untriaged issues
|
||||
[2026-04-01T21:15:04.317172] [SCAN] Found 30 documentation issues
|
||||
[2026-04-01T21:15:04.317544] [SUMMARY] Actionable items found: 4 (top priority: 100)
|
||||
[2026-04-01T21:15:04.318031] [SUMMARY] 4 actionable items discovered
|
||||
[2026-04-01T21:15:04.318152] [PHASE] PHASE 4: Action Execution
|
||||
[2026-04-01T21:15:04.318231] [ACTION] EXECUTING: merge_pr on #112 in timmy-home
|
||||
[2026-04-01T21:15:04.318303] [DETAIL] Title: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:15:04.318377] [DETAIL] Priority: 100
|
||||
[2026-04-01T21:15:04.318448] [DETAIL] Est. time: 2 minutes
|
||||
[2026-04-01T21:15:04.318518] [ACTION] Initiating merge of PR #112...
|
||||
[2026-04-01T21:15:04.763034] [ERROR] Merge verification failed for PR #112
|
||||
[2026-04-01T21:15:04.763299] [ERROR] ACTION FAILED: Verification failed
|
||||
[2026-04-01T21:15:04.763380] [SESSION] ======================================================================
|
||||
[2026-04-01T21:15:04.763440] [SESSION] HEARTBEAT SESSION COMPLETE
|
||||
[2026-04-01T21:15:04.763490] [SUMMARY] Actions found: 4
|
||||
[2026-04-01T21:15:04.763559] [SUMMARY] Action taken: merge_pr
|
||||
[2026-04-01T21:15:04.763618] [SUMMARY] Success: False
|
||||
[2026-04-01T21:15:04.763670] [SUMMARY] Errors: 1
|
||||
[2026-04-01T21:15:04.763750] [SESSION] ======================================================================
|
||||
[2026-04-01T21:30:01.517909] [SESSION] ======================================================================
|
||||
[2026-04-01T21:30:01.518295] [SESSION] HEARTBEAT WAKEUP INITIATED
|
||||
[2026-04-01T21:30:01.518470] [SESSION] Timestamp: 2026-04-01T21:30:01.518464
|
||||
[2026-04-01T21:30:01.518608] [SESSION] Session ID: 20260401_213001
|
||||
[2026-04-01T21:30:01.518707] [SESSION] ======================================================================
|
||||
[2026-04-01T21:30:01.518783] [PHASE] PHASE 1: Infrastructure Health Check
|
||||
[2026-04-01T21:30:01.622094] [SUCCESS] Gitea health check: HTTP 200 ✓
|
||||
[2026-04-01T21:30:01.622499] [PHASE] PHASE 2: Repository Status Scan
|
||||
[2026-04-01T21:30:02.423448] [SCAN] Scanned timmy-home: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:30:02.769816] [SCAN] Scanned timmy-config: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:30:03.218933] [SCAN] Scanned the-nexus: 1 issues, 2 PRs open
|
||||
[2026-04-01T21:30:03.508085] [SCAN] Scanned .profile: 0 issues, 0 PRs open
|
||||
[2026-04-01T21:30:03.508365] [PHASE] PHASE 3: Actionable Item Discovery
|
||||
[2026-04-01T21:30:03.508448] [SCAN] Beginning comprehensive actionable item scan...
|
||||
[2026-04-01T21:30:03.702679] [SCAN] Found 1 open PRs in timmy-home
|
||||
[2026-04-01T21:30:04.022566] [HIGH] PRIORITY: Mergeable PR found - #112: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:30:04.551462] [SCAN] Found 10 untriaged issues
|
||||
[2026-04-01T21:30:05.225847] [SCAN] Found 30 documentation issues
|
||||
[2026-04-01T21:30:05.227321] [SUMMARY] Actionable items found: 4 (top priority: 100)
|
||||
[2026-04-01T21:30:05.228001] [SUMMARY] 4 actionable items discovered
|
||||
[2026-04-01T21:30:05.228193] [PHASE] PHASE 4: Action Execution
|
||||
[2026-04-01T21:30:05.228405] [ACTION] EXECUTING: merge_pr on #112 in timmy-home
|
||||
[2026-04-01T21:30:05.228499] [DETAIL] Title: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:30:05.228596] [DETAIL] Priority: 100
|
||||
[2026-04-01T21:30:05.228741] [DETAIL] Est. time: 2 minutes
|
||||
[2026-04-01T21:30:05.228879] [ACTION] Initiating merge of PR #112...
|
||||
[2026-04-01T21:30:05.640482] [ERROR] Merge verification failed for PR #112
|
||||
[2026-04-01T21:30:05.640964] [ERROR] ACTION FAILED: Verification failed
|
||||
[2026-04-01T21:30:05.641213] [SESSION] ======================================================================
|
||||
[2026-04-01T21:30:05.641355] [SESSION] HEARTBEAT SESSION COMPLETE
|
||||
[2026-04-01T21:30:05.641506] [SUMMARY] Actions found: 4
|
||||
[2026-04-01T21:30:05.641607] [SUMMARY] Action taken: merge_pr
|
||||
[2026-04-01T21:30:05.641748] [SUMMARY] Success: False
|
||||
[2026-04-01T21:30:05.641881] [SUMMARY] Errors: 1
|
||||
[2026-04-01T21:30:05.642026] [SESSION] ======================================================================
|
||||
[2026-04-01T21:45:01.159491] [SESSION] ======================================================================
|
||||
[2026-04-01T21:45:01.159937] [SESSION] HEARTBEAT WAKEUP INITIATED
|
||||
[2026-04-01T21:45:01.160158] [SESSION] Timestamp: 2026-04-01T21:45:01.160152
|
||||
[2026-04-01T21:45:01.160290] [SESSION] Session ID: 20260401_214501
|
||||
[2026-04-01T21:45:01.160355] [SESSION] ======================================================================
|
||||
[2026-04-01T21:45:01.160452] [PHASE] PHASE 1: Infrastructure Health Check
|
||||
[2026-04-01T21:45:01.211299] [SUCCESS] Gitea health check: HTTP 200 ✓
|
||||
[2026-04-01T21:45:01.211683] [PHASE] PHASE 2: Repository Status Scan
|
||||
[2026-04-01T21:45:01.572242] [SCAN] Scanned timmy-home: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:45:01.840580] [SCAN] Scanned timmy-config: 1 issues, 1 PRs open
|
||||
[2026-04-01T21:45:02.226941] [SCAN] Scanned the-nexus: 1 issues, 2 PRs open
|
||||
[2026-04-01T21:45:02.470324] [SCAN] Scanned .profile: 0 issues, 0 PRs open
|
||||
[2026-04-01T21:45:02.470674] [PHASE] PHASE 3: Actionable Item Discovery
|
||||
[2026-04-01T21:45:02.470802] [SCAN] Beginning comprehensive actionable item scan...
|
||||
[2026-04-01T21:45:02.611553] [SCAN] Found 1 open PRs in timmy-home
|
||||
[2026-04-01T21:45:02.850777] [HIGH] PRIORITY: Mergeable PR found - #112: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:45:03.270352] [SCAN] Found 10 untriaged issues
|
||||
[2026-04-01T21:45:04.031427] [SCAN] Found 30 documentation issues
|
||||
[2026-04-01T21:45:04.031900] [SUMMARY] Actionable items found: 4 (top priority: 100)
|
||||
[2026-04-01T21:45:04.032465] [SUMMARY] 4 actionable items discovered
|
||||
[2026-04-01T21:45:04.032653] [PHASE] PHASE 4: Action Execution
|
||||
[2026-04-01T21:45:04.032740] [ACTION] EXECUTING: merge_pr on #112 in timmy-home
|
||||
[2026-04-01T21:45:04.032802] [DETAIL] Title: feat: rewrite KimiClaw heartbeat — launchd, sovereignty fixe
|
||||
[2026-04-01T21:45:04.033278] [DETAIL] Priority: 100
|
||||
[2026-04-01T21:45:04.033400] [DETAIL] Est. time: 2 minutes
|
||||
[2026-04-01T21:45:04.033496] [ACTION] Initiating merge of PR #112...
|
||||
[2026-04-01T21:45:04.530647] [ERROR] Merge verification failed for PR #112
|
||||
[2026-04-01T21:45:04.531116] [ERROR] ACTION FAILED: Verification failed
|
||||
[2026-04-01T21:45:04.531278] [SESSION] ======================================================================
|
||||
[2026-04-01T21:45:04.531408] [SESSION] HEARTBEAT SESSION COMPLETE
|
||||
[2026-04-01T21:45:04.531533] [SUMMARY] Actions found: 4
|
||||
[2026-04-01T21:45:04.531602] [SUMMARY] Action taken: merge_pr
|
||||
[2026-04-01T21:45:04.531685] [SUMMARY] Success: False
|
||||
[2026-04-01T21:45:04.532066] [SUMMARY] Errors: 1
|
||||
[2026-04-01T21:45:04.532189] [SESSION] ======================================================================
|
||||
[2026-04-01T22:00:02.957073] [SESSION] ======================================================================
|
||||
[2026-04-01T22:00:02.957446] [SESSION] HEARTBEAT WAKEUP INITIATED
|
||||
[2026-04-01T22:00:02.957583] [SESSION] Timestamp: 2026-04-01T22:00:02.957578
|
||||
[2026-04-01T22:00:02.957667] [SESSION] Session ID: 20260401_220002
|
||||
[2026-04-01T22:00:02.957735] [SESSION] ======================================================================
|
||||
[2026-04-01T22:00:02.957888] [PHASE] PHASE 1: Infrastructure Health Check
|
||||
[2026-04-01T22:00:03.059666] [SUCCESS] Gitea health check: HTTP 200 ✓
|
||||
[2026-04-01T22:00:03.060545] [PHASE] PHASE 2: Repository Status Scan
|
||||
[2026-04-01T22:00:03.815041] [SCAN] Scanned timmy-home: 1 issues, 1 PRs open
|
||||
|
||||
114
wizards/allegro/docs/ADR-001-harness-engineering-pivot.md
Normal file
114
wizards/allegro/docs/ADR-001-harness-engineering-pivot.md
Normal file
@@ -0,0 +1,114 @@
|
||||
# ADR-001: Harness Engineering Pivot
|
||||
|
||||
**Status:** APPROVED
|
||||
**Date:** 2026-04-01
|
||||
**Deciders:** Alexander Whitestone (Father), Allegro (Executor), Ezra (Scribe)
|
||||
**Owner:** Allegro
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
We have been operating on Hermes Agent as our default harness. While functional, this creates lock-in to a single runtime. The exposure of Claude Code's architecture and the rapid emergence of Claw Code (98K+ stars, fastest to 50K in GitHub history) presents an opportunity.
|
||||
|
||||
Claw Code represents a clean-room Python/Rust rewrite of Claude Code's patterns with:
|
||||
- Provider trait abstraction (swappable LLMs)
|
||||
- Native MCP (Model Context Protocol) support
|
||||
- Plugin hook system (PreToolUse/PostToolUse)
|
||||
- Session compaction for context management
|
||||
|
||||
---
|
||||
|
||||
## Decision
|
||||
|
||||
We pivot to **harness engineering**: building a multi-runtime, swappable architecture that adopts best patterns from Claw Code while preserving our values layer.
|
||||
|
||||
### What This Means
|
||||
|
||||
| From | To |
|
||||
|------|-----|
|
||||
| Hermes default | Best runtime default |
|
||||
| Code loyalty | Results loyalty |
|
||||
| Single harness | Multi-runtime, swappable |
|
||||
| NIH syndrome | SOTA tracking |
|
||||
|
||||
### What We Keep
|
||||
|
||||
- **Checkpoint system** (Ezra's ownership model)
|
||||
- **Profile-based architecture** (wizard separation)
|
||||
- **SOUL.md / Conscience layer** (values enforcement)
|
||||
- **Heartbeat pattern** (execution cadence)
|
||||
- **Gitea integration** (issue tracking)
|
||||
|
||||
---
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
- No LLM lock-in (Kimi ↔ Ollama ↔ Claude ↔ OpenAI)
|
||||
- Tools become portable MCP servers
|
||||
- Plugin system enables SOUL.md enforcement via hooks
|
||||
- Session compaction solves token limits
|
||||
- Faster iteration on harness improvements
|
||||
|
||||
### Negative
|
||||
- Migration work required (8-week timeline)
|
||||
- Learning curve for Rust if we adopt core runtime
|
||||
- Potential instability during transition
|
||||
- Need to maintain backward compatibility for 90 days
|
||||
|
||||
### Risks
|
||||
| Risk | Mitigation |
|
||||
|------|------------|
|
||||
| Claw Code API churn | Mirror repo with hourly sync, pin to stable commits |
|
||||
| Rust competency gap | Hybrid approach: core in Rust, tools in Python |
|
||||
| Migration disruption | Parallel operation period, feature flags |
|
||||
| SOUL enforcement gaps | Implement as PreToolUse hook, test exhaustively |
|
||||
|
||||
---
|
||||
|
||||
## Implementation
|
||||
|
||||
### Phase 1: Assessment (Week 1) - IN PROGRESS
|
||||
- [x] Document Claw Code architecture analysis
|
||||
- [x] Identify migration touchpoints
|
||||
- [ ] Create claw-code-mirror repo (BLOCKED: Tailscale)
|
||||
- [ ] Set up automated upstream sync
|
||||
|
||||
### Phase 2: Runtime Abstraction (Weeks 2-3)
|
||||
- [ ] Define Provider trait
|
||||
- [ ] Implement Kimi-coding provider
|
||||
- [ ] Provider factory/config
|
||||
|
||||
### Phase 3: Tool System (Weeks 3-4)
|
||||
- [ ] Extract tools to registry pattern
|
||||
- [ ] MCP client implementation
|
||||
- [ ] Convert skills to MCP servers
|
||||
|
||||
### Phase 4: Plugin Architecture (Weeks 4-5)
|
||||
- [ ] Hook system (PreToolUse, PostToolUse)
|
||||
- [ ] Plugin manifest format
|
||||
- [ ] SOUL.md enforcement via hooks
|
||||
|
||||
### Phase 5: CLI & UX (Weeks 5-6)
|
||||
- [ ] Single entrypoint
|
||||
- [ ] Profile-based configuration
|
||||
- [ ] Session persistence
|
||||
|
||||
### Phase 6: Validation (Weeks 6-8)
|
||||
- [ ] Full test suite (200+ tests)
|
||||
- [ ] Migration guide
|
||||
- [ ] Deprecation plan for Hermes
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- Claw Code upstream: https://github.com/instructkr/claw-code
|
||||
- MCP Spec: https://modelcontextprotocol.io/
|
||||
- North Star doc: `/root/wizards/allegro/home/claw_code_north_star.md`
|
||||
- Architecture analysis: `/root/wizards/allegro/home/claw_code_followup.md`
|
||||
|
||||
---
|
||||
|
||||
*"Code loyalty → Results loyalty"*
|
||||
@@ -1,4 +1,4 @@
|
||||
PROGRESS REPORT - Wed Apr 1 21:00:01 UTC 2026
|
||||
PROGRESS REPORT - Wed Apr 1 22:00:02 UTC 2026
|
||||
========================
|
||||
|
||||
Queue Status:
|
||||
|
||||
21
wizards/allegro/father-messages/progress-20260401-2130.txt
Normal file
21
wizards/allegro/father-messages/progress-20260401-2130.txt
Normal file
@@ -0,0 +1,21 @@
|
||||
PROGRESS REPORT - Wed Apr 1 21:30:01 UTC 2026
|
||||
========================
|
||||
|
||||
Queue Status:
|
||||
- Pending: 0
|
||||
- In Progress: 0
|
||||
- Complete: 9
|
||||
- Total: 9
|
||||
- Progress: 100%
|
||||
|
||||
Pending Tasks:
|
||||
|
||||
|
||||
Active Tasks:
|
||||
|
||||
|
||||
Recent Completions:
|
||||
|
||||
|
||||
---
|
||||
Auto-generated by cron every 30 minutes
|
||||
21
wizards/allegro/father-messages/progress-20260401-2200.txt
Normal file
21
wizards/allegro/father-messages/progress-20260401-2200.txt
Normal file
@@ -0,0 +1,21 @@
|
||||
PROGRESS REPORT - Wed Apr 1 22:00:02 UTC 2026
|
||||
========================
|
||||
|
||||
Queue Status:
|
||||
- Pending: 0
|
||||
- In Progress: 0
|
||||
- Complete: 9
|
||||
- Total: 9
|
||||
- Progress: 100%
|
||||
|
||||
Pending Tasks:
|
||||
|
||||
|
||||
Active Tasks:
|
||||
|
||||
|
||||
Recent Completions:
|
||||
|
||||
|
||||
---
|
||||
Auto-generated by cron every 30 minutes
|
||||
BIN
wizards/allegro/home/cache/audio/audio_563efe06b2ca.ogg
vendored
Normal file
BIN
wizards/allegro/home/cache/audio/audio_563efe06b2ca.ogg
vendored
Normal file
Binary file not shown.
BIN
wizards/allegro/home/cache/audio/audio_94a68206fc02.ogg
vendored
Normal file
BIN
wizards/allegro/home/cache/audio/audio_94a68206fc02.ogg
vendored
Normal file
Binary file not shown.
@@ -1,5 +1,5 @@
|
||||
{
|
||||
"updated_at": "2026-04-01T20:59:29.431589",
|
||||
"updated_at": "2026-04-01T21:59:32.821229",
|
||||
"platforms": {
|
||||
"telegram": [
|
||||
{
|
||||
|
||||
@@ -20,15 +20,15 @@
|
||||
"schedule_display": "every 15m",
|
||||
"repeat": {
|
||||
"times": null,
|
||||
"completed": 69
|
||||
"completed": 73
|
||||
},
|
||||
"enabled": true,
|
||||
"state": "scheduled",
|
||||
"paused_at": null,
|
||||
"paused_reason": null,
|
||||
"created_at": "2026-03-31T01:15:02.964047+00:00",
|
||||
"next_run_at": "2026-04-01T21:10:28.817786+00:00",
|
||||
"last_run_at": "2026-04-01T13:04:14.567707+00:00",
|
||||
"next_run_at": "2026-04-01T22:10:32.809671+00:00",
|
||||
"last_run_at": "2026-04-01T21:55:32.809671+00:00",
|
||||
"last_status": "ok",
|
||||
"last_error": null,
|
||||
"deliver": "local",
|
||||
@@ -40,5 +40,5 @@
|
||||
}
|
||||
}
|
||||
],
|
||||
"updated_at": "2026-04-01T20:55:28.821914+00:00"
|
||||
"updated_at": "2026-04-01T21:55:32.810268+00:00"
|
||||
}
|
||||
@@ -0,0 +1,456 @@
|
||||
# Cron Job: continuous-burn-loop
|
||||
|
||||
**Job ID:** 925c78f89f49
|
||||
**Run Time:** 2026-04-01 21:10:30
|
||||
**Schedule:** every 15m
|
||||
|
||||
## Prompt
|
||||
|
||||
[SYSTEM: The following skill(s) were listed for this job but could not be found and were skipped: github. Start your response with a brief notice so the user is aware, e.g.: '⚠️ Skill(s) not found and skipped: github']
|
||||
[SYSTEM: The user has invoked the "subagent-driven-development" skill, indicating they want you to follow its instructions. The full skill content is loaded below.]
|
||||
|
||||
---
|
||||
name: subagent-driven-development
|
||||
description: Use when executing implementation plans with independent tasks. Dispatches fresh delegate_task per task with two-stage review (spec compliance then code quality).
|
||||
version: 1.1.0
|
||||
author: Hermes Agent (adapted from obra/superpowers)
|
||||
license: MIT
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [delegation, subagent, implementation, workflow, parallel]
|
||||
related_skills: [writing-plans, requesting-code-review, test-driven-development]
|
||||
---
|
||||
|
||||
# Subagent-Driven Development
|
||||
|
||||
## Overview
|
||||
|
||||
Execute implementation plans by dispatching fresh subagents per task with systematic two-stage review.
|
||||
|
||||
**Core principle:** Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.
|
||||
|
||||
## When to Use
|
||||
|
||||
Use this skill when:
|
||||
- You have an implementation plan (from writing-plans skill or user requirements)
|
||||
- Tasks are mostly independent
|
||||
- Quality and spec compliance are important
|
||||
- You want automated review between tasks
|
||||
|
||||
**vs. manual execution:**
|
||||
- Fresh context per task (no confusion from accumulated state)
|
||||
- Automated review process catches issues early
|
||||
- Consistent quality checks across all tasks
|
||||
- Subagents can ask questions before starting work
|
||||
|
||||
## The Process
|
||||
|
||||
### 1. Read and Parse Plan
|
||||
|
||||
Read the plan file. Extract ALL tasks with their full text and context upfront. Create a todo list:
|
||||
|
||||
```python
|
||||
# Read the plan
|
||||
read_file("docs/plans/feature-plan.md")
|
||||
|
||||
# Create todo list with all tasks
|
||||
todo([
|
||||
{"id": "task-1", "content": "Create User model with email field", "status": "pending"},
|
||||
{"id": "task-2", "content": "Add password hashing utility", "status": "pending"},
|
||||
{"id": "task-3", "content": "Create login endpoint", "status": "pending"},
|
||||
])
|
||||
```
|
||||
|
||||
**Key:** Read the plan ONCE. Extract everything. Don't make subagents read the plan file — provide the full task text directly in context.
|
||||
|
||||
### 2. Per-Task Workflow
|
||||
|
||||
For EACH task in the plan:
|
||||
|
||||
#### Step 1: Dispatch Implementer Subagent
|
||||
|
||||
Use `delegate_task` with complete context:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Implement Task 1: Create User model with email and password_hash fields",
|
||||
context="""
|
||||
TASK FROM PLAN:
|
||||
- Create: src/models/user.py
|
||||
- Add User class with email (str) and password_hash (str) fields
|
||||
- Use bcrypt for password hashing
|
||||
- Include __repr__ for debugging
|
||||
|
||||
FOLLOW TDD:
|
||||
1. Write failing test in tests/models/test_user.py
|
||||
2. Run: pytest tests/models/test_user.py -v (verify FAIL)
|
||||
3. Write minimal implementation
|
||||
4. Run: pytest tests/models/test_user.py -v (verify PASS)
|
||||
5. Run: pytest tests/ -q (verify no regressions)
|
||||
6. Commit: git add -A && git commit -m "feat: add User model with password hashing"
|
||||
|
||||
PROJECT CONTEXT:
|
||||
- Python 3.11, Flask app in src/app.py
|
||||
- Existing models in src/models/
|
||||
- Tests use pytest, run from project root
|
||||
- bcrypt already in requirements.txt
|
||||
""",
|
||||
toolsets=['terminal', 'file']
|
||||
)
|
||||
```
|
||||
|
||||
#### Step 2: Dispatch Spec Compliance Reviewer
|
||||
|
||||
After the implementer completes, verify against the original spec:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review if implementation matches the spec from the plan",
|
||||
context="""
|
||||
ORIGINAL TASK SPEC:
|
||||
- Create src/models/user.py with User class
|
||||
- Fields: email (str), password_hash (str)
|
||||
- Use bcrypt for password hashing
|
||||
- Include __repr__
|
||||
|
||||
CHECK:
|
||||
- [ ] All requirements from spec implemented?
|
||||
- [ ] File paths match spec?
|
||||
- [ ] Function signatures match spec?
|
||||
- [ ] Behavior matches expected?
|
||||
- [ ] Nothing extra added (no scope creep)?
|
||||
|
||||
OUTPUT: PASS or list of specific spec gaps to fix.
|
||||
""",
|
||||
toolsets=['file']
|
||||
)
|
||||
```
|
||||
|
||||
**If spec issues found:** Fix gaps, then re-run spec review. Continue only when spec-compliant.
|
||||
|
||||
#### Step 3: Dispatch Code Quality Reviewer
|
||||
|
||||
After spec compliance passes:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review code quality for Task 1 implementation",
|
||||
context="""
|
||||
FILES TO REVIEW:
|
||||
- src/models/user.py
|
||||
- tests/models/test_user.py
|
||||
|
||||
CHECK:
|
||||
- [ ] Follows project conventions and style?
|
||||
- [ ] Proper error handling?
|
||||
- [ ] Clear variable/function names?
|
||||
- [ ] Adequate test coverage?
|
||||
- [ ] No obvious bugs or missed edge cases?
|
||||
- [ ] No security issues?
|
||||
|
||||
OUTPUT FORMAT:
|
||||
- Critical Issues: [must fix before proceeding]
|
||||
- Important Issues: [should fix]
|
||||
- Minor Issues: [optional]
|
||||
- Verdict: APPROVED or REQUEST_CHANGES
|
||||
""",
|
||||
toolsets=['file']
|
||||
)
|
||||
```
|
||||
|
||||
**If quality issues found:** Fix issues, re-review. Continue only when approved.
|
||||
|
||||
#### Step 4: Mark Complete
|
||||
|
||||
```python
|
||||
todo([{"id": "task-1", "content": "Create User model with email field", "status": "completed"}], merge=True)
|
||||
```
|
||||
|
||||
### 3. Final Review
|
||||
|
||||
After ALL tasks are complete, dispatch a final integration reviewer:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review the entire implementation for consistency and integration issues",
|
||||
context="""
|
||||
All tasks from the plan are complete. Review the full implementation:
|
||||
- Do all components work together?
|
||||
- Any inconsistencies between tasks?
|
||||
- All tests passing?
|
||||
- Ready for merge?
|
||||
""",
|
||||
toolsets=['terminal', 'file']
|
||||
)
|
||||
```
|
||||
|
||||
### 4. Verify and Commit
|
||||
|
||||
```bash
|
||||
# Run full test suite
|
||||
pytest tests/ -q
|
||||
|
||||
# Review all changes
|
||||
git diff --stat
|
||||
|
||||
# Final commit if needed
|
||||
git add -A && git commit -m "feat: complete [feature name] implementation"
|
||||
```
|
||||
|
||||
## Task Granularity
|
||||
|
||||
**Each task = 2-5 minutes of focused work.**
|
||||
|
||||
**Too big:**
|
||||
- "Implement user authentication system"
|
||||
|
||||
**Right size:**
|
||||
- "Create User model with email and password fields"
|
||||
- "Add password hashing function"
|
||||
- "Create login endpoint"
|
||||
- "Add JWT token generation"
|
||||
- "Create registration endpoint"
|
||||
|
||||
## Red Flags — Never Do These
|
||||
|
||||
- Start implementation without a plan
|
||||
- Skip reviews (spec compliance OR code quality)
|
||||
- Proceed with unfixed critical/important issues
|
||||
- Dispatch multiple implementation subagents for tasks that touch the same files
|
||||
- Make subagent read the plan file (provide full text in context instead)
|
||||
- Skip scene-setting context (subagent needs to understand where the task fits)
|
||||
- Ignore subagent questions (answer before letting them proceed)
|
||||
- Accept "close enough" on spec compliance
|
||||
- Skip review loops (reviewer found issues → implementer fixes → review again)
|
||||
- Let implementer self-review replace actual review (both are needed)
|
||||
- **Start code quality review before spec compliance is PASS** (wrong order)
|
||||
- Move to next task while either review has open issues
|
||||
|
||||
## Handling Issues
|
||||
|
||||
### If Subagent Asks Questions
|
||||
|
||||
- Answer clearly and completely
|
||||
- Provide additional context if needed
|
||||
- Don't rush them into implementation
|
||||
|
||||
### If Reviewer Finds Issues
|
||||
|
||||
- Implementer subagent (or a new one) fixes them
|
||||
- Reviewer reviews again
|
||||
- Repeat until approved
|
||||
- Don't skip the re-review
|
||||
|
||||
### If Subagent Fails a Task
|
||||
|
||||
- Dispatch a new fix subagent with specific instructions about what went wrong
|
||||
- Don't try to fix manually in the controller session (context pollution)
|
||||
|
||||
## Efficiency Notes
|
||||
|
||||
**Why fresh subagent per task:**
|
||||
- Prevents context pollution from accumulated state
|
||||
- Each subagent gets clean, focused context
|
||||
- No confusion from prior tasks' code or reasoning
|
||||
|
||||
**Why two-stage review:**
|
||||
- Spec review catches under/over-building early
|
||||
- Quality review ensures the implementation is well-built
|
||||
- Catches issues before they compound across tasks
|
||||
|
||||
**Cost trade-off:**
|
||||
- More subagent invocations (implementer + 2 reviewers per task)
|
||||
- But catches issues early (cheaper than debugging compounded problems later)
|
||||
|
||||
## Integration with Other Skills
|
||||
|
||||
### With writing-plans
|
||||
|
||||
This skill EXECUTES plans created by the writing-plans skill:
|
||||
1. User requirements → writing-plans → implementation plan
|
||||
2. Implementation plan → subagent-driven-development → working code
|
||||
|
||||
### With test-driven-development
|
||||
|
||||
Implementer subagents should follow TDD:
|
||||
1. Write failing test first
|
||||
2. Implement minimal code
|
||||
3. Verify test passes
|
||||
4. Commit
|
||||
|
||||
Include TDD instructions in every implementer context.
|
||||
|
||||
### With requesting-code-review
|
||||
|
||||
The two-stage review process IS the code review. For final integration review, use the requesting-code-review skill's review dimensions.
|
||||
|
||||
### With systematic-debugging
|
||||
|
||||
If a subagent encounters bugs during implementation:
|
||||
1. Follow systematic-debugging process
|
||||
2. Find root cause before fixing
|
||||
3. Write regression test
|
||||
4. Resume implementation
|
||||
|
||||
## Example Workflow
|
||||
|
||||
```
|
||||
[Read plan: docs/plans/auth-feature.md]
|
||||
[Create todo list with 5 tasks]
|
||||
|
||||
--- Task 1: Create User model ---
|
||||
[Dispatch implementer subagent]
|
||||
Implementer: "Should email be unique?"
|
||||
You: "Yes, email must be unique"
|
||||
Implementer: Implemented, 3/3 tests passing, committed.
|
||||
|
||||
[Dispatch spec reviewer]
|
||||
Spec reviewer: ✅ PASS — all requirements met
|
||||
|
||||
[Dispatch quality reviewer]
|
||||
Quality reviewer: ✅ APPROVED — clean code, good tests
|
||||
|
||||
[Mark Task 1 complete]
|
||||
|
||||
--- Task 2: Password hashing ---
|
||||
[Dispatch implementer subagent]
|
||||
Implementer: No questions, implemented, 5/5 tests passing.
|
||||
|
||||
[Dispatch spec reviewer]
|
||||
Spec reviewer: ❌ Missing: password strength validation (spec says "min 8 chars")
|
||||
|
||||
[Implementer fixes]
|
||||
Implementer: Added validation, 7/7 tests passing.
|
||||
|
||||
[Dispatch spec reviewer again]
|
||||
Spec reviewer: ✅ PASS
|
||||
|
||||
[Dispatch quality reviewer]
|
||||
Quality reviewer: Important: Magic number 8, extract to constant
|
||||
Implementer: Extracted MIN_PASSWORD_LENGTH constant
|
||||
Quality reviewer: ✅ APPROVED
|
||||
|
||||
[Mark Task 2 complete]
|
||||
|
||||
... (continue for all tasks)
|
||||
|
||||
[After all tasks: dispatch final integration reviewer]
|
||||
[Run full test suite: all passing]
|
||||
[Done!]
|
||||
```
|
||||
|
||||
## Remember
|
||||
|
||||
```
|
||||
Fresh subagent per task
|
||||
Two-stage review every time
|
||||
Spec compliance FIRST
|
||||
Code quality SECOND
|
||||
Never skip reviews
|
||||
Catch issues early
|
||||
```
|
||||
|
||||
**Quality is not an accident. It's the result of systematic process.**
|
||||
|
||||
The user has provided the following instruction alongside the skill invocation: [SYSTEM: If you have a meaningful status report or findings, send them — that is the whole point of this job. Only respond with exactly "[SILENT]" (nothing else) when there is genuinely nothing new to report. [SILENT] suppresses delivery to the user. Never combine [SILENT] with content — either report your findings normally, or say [SILENT] and nothing more.]
|
||||
|
||||
AUTONOMOUS BURN MODE — CONTINUOUS EXECUTION
|
||||
|
||||
You are Allegro in continuous burn mode. Your mission: perpetually burn down the highest-priority work in the Timmy Foundation ecosystem without waiting for user input.
|
||||
|
||||
## BURN PROTOCOL
|
||||
|
||||
### 1. DISCOVER PHASE (2 minutes)
|
||||
Query Gitea for highest priority work:
|
||||
- Open issues with labels: "priority/critical", "priority/high", "burn-next"
|
||||
- Open PRs needing review
|
||||
- Security vulnerabilities (CVSS > 7.0)
|
||||
- Performance regressions
|
||||
- Failed CI/CD pipelines
|
||||
|
||||
API: http://143.198.27.163:3000/api/v1
|
||||
Token: $GITEA_TOKEN
|
||||
|
||||
### 2. SELECT PHASE (1 minute)
|
||||
Priority order:
|
||||
1. Security vulnerabilities (CVSS critical/high)
|
||||
2. Performance regressions
|
||||
3. Infrastructure failures
|
||||
4. PR reviews blocking merge
|
||||
5. Issue backlog (oldest first)
|
||||
6. Technical debt (if nothing else)
|
||||
|
||||
### 3. BURN PHASE (Execute until complete)
|
||||
Use delegate_task to spawn parallel strike teams:
|
||||
- 1-3 subagents for independent workstreams
|
||||
- Maximum 50 iterations per subagent
|
||||
- Focus on code, tests, documentation
|
||||
|
||||
### 4. REPORT PHASE (Deliver to Gitea)
|
||||
Create/update an issue in timmy-home with burn report:
|
||||
- Title format: "🔥 Burn Report #[NUMBER] — [DATE] [FOCUS AREA]"
|
||||
- Include: what was burned, metrics, next target
|
||||
- Tag with: "burn-report", "autonomous"
|
||||
|
||||
### 5. IMMEDIATE RESTART
|
||||
After reporting, immediately begin next burn cycle. No waiting. Continuous execution.
|
||||
|
||||
## CURRENT BACKLOG CONTEXT
|
||||
|
||||
Hermes-agent: Security complete (15 vulns), Performance batch 1 complete (10x throughput)
|
||||
Remaining: Lazy imports (#114), Benchmarks (#115), Rust evaluation, GOFAI implementation
|
||||
|
||||
Turboquant: Active development
|
||||
The-nexus: Infrastructure stable
|
||||
Timmy-home: Audio pipeline (#123-128), cutover planning
|
||||
|
||||
## REPORTING FORMAT
|
||||
|
||||
Create issue in Timmy_Foundation/timmy-home:
|
||||
|
||||
```markdown
|
||||
## 🔥 Burn Report #[N] — [TIMESTAMP]
|
||||
|
||||
**Focus Area:** [Security/Performance/Feature/Infrastructure]
|
||||
**Burn Duration:** [X minutes]
|
||||
**Subagents Deployed:** [N]
|
||||
|
||||
### Work Completed
|
||||
- [ ] Item 1
|
||||
- [ ] Item 2
|
||||
|
||||
### Metrics
|
||||
- Lines changed: +X/-Y
|
||||
- Tests added: N
|
||||
- CVSS addressed: X.X
|
||||
- Performance gain: X%
|
||||
|
||||
### Next Target
|
||||
[What to burn next]
|
||||
|
||||
### Blockers (if any)
|
||||
[What's blocking continued burn]
|
||||
|
||||
---
|
||||
*Autonomous burn mode active*
|
||||
```
|
||||
|
||||
## RULES
|
||||
|
||||
1. NEVER ask for clarification — make decisions
|
||||
2. NEVER wait for approval — execute and report
|
||||
3. If blocked, document in Gitea and pivot to next item
|
||||
4. Maintain backward compatibility
|
||||
5. All code must have tests
|
||||
6. Security > Performance > Features
|
||||
7. When in doubt, burn the oldest critical issue
|
||||
|
||||
## START BURNING NOW
|
||||
|
||||
Query Gitea. Find highest priority work. Execute. Report. Repeat.
|
||||
|
||||
Sovereignty and service always. 🔥
|
||||
|
||||
## Response
|
||||
|
||||
(No response generated)
|
||||
@@ -0,0 +1,456 @@
|
||||
# Cron Job: continuous-burn-loop
|
||||
|
||||
**Job ID:** 925c78f89f49
|
||||
**Run Time:** 2026-04-01 21:25:30
|
||||
**Schedule:** every 15m
|
||||
|
||||
## Prompt
|
||||
|
||||
[SYSTEM: The following skill(s) were listed for this job but could not be found and were skipped: github. Start your response with a brief notice so the user is aware, e.g.: '⚠️ Skill(s) not found and skipped: github']
|
||||
[SYSTEM: The user has invoked the "subagent-driven-development" skill, indicating they want you to follow its instructions. The full skill content is loaded below.]
|
||||
|
||||
---
|
||||
name: subagent-driven-development
|
||||
description: Use when executing implementation plans with independent tasks. Dispatches fresh delegate_task per task with two-stage review (spec compliance then code quality).
|
||||
version: 1.1.0
|
||||
author: Hermes Agent (adapted from obra/superpowers)
|
||||
license: MIT
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [delegation, subagent, implementation, workflow, parallel]
|
||||
related_skills: [writing-plans, requesting-code-review, test-driven-development]
|
||||
---
|
||||
|
||||
# Subagent-Driven Development
|
||||
|
||||
## Overview
|
||||
|
||||
Execute implementation plans by dispatching fresh subagents per task with systematic two-stage review.
|
||||
|
||||
**Core principle:** Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.
|
||||
|
||||
## When to Use
|
||||
|
||||
Use this skill when:
|
||||
- You have an implementation plan (from writing-plans skill or user requirements)
|
||||
- Tasks are mostly independent
|
||||
- Quality and spec compliance are important
|
||||
- You want automated review between tasks
|
||||
|
||||
**vs. manual execution:**
|
||||
- Fresh context per task (no confusion from accumulated state)
|
||||
- Automated review process catches issues early
|
||||
- Consistent quality checks across all tasks
|
||||
- Subagents can ask questions before starting work
|
||||
|
||||
## The Process
|
||||
|
||||
### 1. Read and Parse Plan
|
||||
|
||||
Read the plan file. Extract ALL tasks with their full text and context upfront. Create a todo list:
|
||||
|
||||
```python
|
||||
# Read the plan
|
||||
read_file("docs/plans/feature-plan.md")
|
||||
|
||||
# Create todo list with all tasks
|
||||
todo([
|
||||
{"id": "task-1", "content": "Create User model with email field", "status": "pending"},
|
||||
{"id": "task-2", "content": "Add password hashing utility", "status": "pending"},
|
||||
{"id": "task-3", "content": "Create login endpoint", "status": "pending"},
|
||||
])
|
||||
```
|
||||
|
||||
**Key:** Read the plan ONCE. Extract everything. Don't make subagents read the plan file — provide the full task text directly in context.
|
||||
|
||||
### 2. Per-Task Workflow
|
||||
|
||||
For EACH task in the plan:
|
||||
|
||||
#### Step 1: Dispatch Implementer Subagent
|
||||
|
||||
Use `delegate_task` with complete context:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Implement Task 1: Create User model with email and password_hash fields",
|
||||
context="""
|
||||
TASK FROM PLAN:
|
||||
- Create: src/models/user.py
|
||||
- Add User class with email (str) and password_hash (str) fields
|
||||
- Use bcrypt for password hashing
|
||||
- Include __repr__ for debugging
|
||||
|
||||
FOLLOW TDD:
|
||||
1. Write failing test in tests/models/test_user.py
|
||||
2. Run: pytest tests/models/test_user.py -v (verify FAIL)
|
||||
3. Write minimal implementation
|
||||
4. Run: pytest tests/models/test_user.py -v (verify PASS)
|
||||
5. Run: pytest tests/ -q (verify no regressions)
|
||||
6. Commit: git add -A && git commit -m "feat: add User model with password hashing"
|
||||
|
||||
PROJECT CONTEXT:
|
||||
- Python 3.11, Flask app in src/app.py
|
||||
- Existing models in src/models/
|
||||
- Tests use pytest, run from project root
|
||||
- bcrypt already in requirements.txt
|
||||
""",
|
||||
toolsets=['terminal', 'file']
|
||||
)
|
||||
```
|
||||
|
||||
#### Step 2: Dispatch Spec Compliance Reviewer
|
||||
|
||||
After the implementer completes, verify against the original spec:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review if implementation matches the spec from the plan",
|
||||
context="""
|
||||
ORIGINAL TASK SPEC:
|
||||
- Create src/models/user.py with User class
|
||||
- Fields: email (str), password_hash (str)
|
||||
- Use bcrypt for password hashing
|
||||
- Include __repr__
|
||||
|
||||
CHECK:
|
||||
- [ ] All requirements from spec implemented?
|
||||
- [ ] File paths match spec?
|
||||
- [ ] Function signatures match spec?
|
||||
- [ ] Behavior matches expected?
|
||||
- [ ] Nothing extra added (no scope creep)?
|
||||
|
||||
OUTPUT: PASS or list of specific spec gaps to fix.
|
||||
""",
|
||||
toolsets=['file']
|
||||
)
|
||||
```
|
||||
|
||||
**If spec issues found:** Fix gaps, then re-run spec review. Continue only when spec-compliant.
|
||||
|
||||
#### Step 3: Dispatch Code Quality Reviewer
|
||||
|
||||
After spec compliance passes:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review code quality for Task 1 implementation",
|
||||
context="""
|
||||
FILES TO REVIEW:
|
||||
- src/models/user.py
|
||||
- tests/models/test_user.py
|
||||
|
||||
CHECK:
|
||||
- [ ] Follows project conventions and style?
|
||||
- [ ] Proper error handling?
|
||||
- [ ] Clear variable/function names?
|
||||
- [ ] Adequate test coverage?
|
||||
- [ ] No obvious bugs or missed edge cases?
|
||||
- [ ] No security issues?
|
||||
|
||||
OUTPUT FORMAT:
|
||||
- Critical Issues: [must fix before proceeding]
|
||||
- Important Issues: [should fix]
|
||||
- Minor Issues: [optional]
|
||||
- Verdict: APPROVED or REQUEST_CHANGES
|
||||
""",
|
||||
toolsets=['file']
|
||||
)
|
||||
```
|
||||
|
||||
**If quality issues found:** Fix issues, re-review. Continue only when approved.
|
||||
|
||||
#### Step 4: Mark Complete
|
||||
|
||||
```python
|
||||
todo([{"id": "task-1", "content": "Create User model with email field", "status": "completed"}], merge=True)
|
||||
```
|
||||
|
||||
### 3. Final Review
|
||||
|
||||
After ALL tasks are complete, dispatch a final integration reviewer:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review the entire implementation for consistency and integration issues",
|
||||
context="""
|
||||
All tasks from the plan are complete. Review the full implementation:
|
||||
- Do all components work together?
|
||||
- Any inconsistencies between tasks?
|
||||
- All tests passing?
|
||||
- Ready for merge?
|
||||
""",
|
||||
toolsets=['terminal', 'file']
|
||||
)
|
||||
```
|
||||
|
||||
### 4. Verify and Commit
|
||||
|
||||
```bash
|
||||
# Run full test suite
|
||||
pytest tests/ -q
|
||||
|
||||
# Review all changes
|
||||
git diff --stat
|
||||
|
||||
# Final commit if needed
|
||||
git add -A && git commit -m "feat: complete [feature name] implementation"
|
||||
```
|
||||
|
||||
## Task Granularity
|
||||
|
||||
**Each task = 2-5 minutes of focused work.**
|
||||
|
||||
**Too big:**
|
||||
- "Implement user authentication system"
|
||||
|
||||
**Right size:**
|
||||
- "Create User model with email and password fields"
|
||||
- "Add password hashing function"
|
||||
- "Create login endpoint"
|
||||
- "Add JWT token generation"
|
||||
- "Create registration endpoint"
|
||||
|
||||
## Red Flags — Never Do These
|
||||
|
||||
- Start implementation without a plan
|
||||
- Skip reviews (spec compliance OR code quality)
|
||||
- Proceed with unfixed critical/important issues
|
||||
- Dispatch multiple implementation subagents for tasks that touch the same files
|
||||
- Make subagent read the plan file (provide full text in context instead)
|
||||
- Skip scene-setting context (subagent needs to understand where the task fits)
|
||||
- Ignore subagent questions (answer before letting them proceed)
|
||||
- Accept "close enough" on spec compliance
|
||||
- Skip review loops (reviewer found issues → implementer fixes → review again)
|
||||
- Let implementer self-review replace actual review (both are needed)
|
||||
- **Start code quality review before spec compliance is PASS** (wrong order)
|
||||
- Move to next task while either review has open issues
|
||||
|
||||
## Handling Issues
|
||||
|
||||
### If Subagent Asks Questions
|
||||
|
||||
- Answer clearly and completely
|
||||
- Provide additional context if needed
|
||||
- Don't rush them into implementation
|
||||
|
||||
### If Reviewer Finds Issues
|
||||
|
||||
- Implementer subagent (or a new one) fixes them
|
||||
- Reviewer reviews again
|
||||
- Repeat until approved
|
||||
- Don't skip the re-review
|
||||
|
||||
### If Subagent Fails a Task
|
||||
|
||||
- Dispatch a new fix subagent with specific instructions about what went wrong
|
||||
- Don't try to fix manually in the controller session (context pollution)
|
||||
|
||||
## Efficiency Notes
|
||||
|
||||
**Why fresh subagent per task:**
|
||||
- Prevents context pollution from accumulated state
|
||||
- Each subagent gets clean, focused context
|
||||
- No confusion from prior tasks' code or reasoning
|
||||
|
||||
**Why two-stage review:**
|
||||
- Spec review catches under/over-building early
|
||||
- Quality review ensures the implementation is well-built
|
||||
- Catches issues before they compound across tasks
|
||||
|
||||
**Cost trade-off:**
|
||||
- More subagent invocations (implementer + 2 reviewers per task)
|
||||
- But catches issues early (cheaper than debugging compounded problems later)
|
||||
|
||||
## Integration with Other Skills
|
||||
|
||||
### With writing-plans
|
||||
|
||||
This skill EXECUTES plans created by the writing-plans skill:
|
||||
1. User requirements → writing-plans → implementation plan
|
||||
2. Implementation plan → subagent-driven-development → working code
|
||||
|
||||
### With test-driven-development
|
||||
|
||||
Implementer subagents should follow TDD:
|
||||
1. Write failing test first
|
||||
2. Implement minimal code
|
||||
3. Verify test passes
|
||||
4. Commit
|
||||
|
||||
Include TDD instructions in every implementer context.
|
||||
|
||||
### With requesting-code-review
|
||||
|
||||
The two-stage review process IS the code review. For final integration review, use the requesting-code-review skill's review dimensions.
|
||||
|
||||
### With systematic-debugging
|
||||
|
||||
If a subagent encounters bugs during implementation:
|
||||
1. Follow systematic-debugging process
|
||||
2. Find root cause before fixing
|
||||
3. Write regression test
|
||||
4. Resume implementation
|
||||
|
||||
## Example Workflow
|
||||
|
||||
```
|
||||
[Read plan: docs/plans/auth-feature.md]
|
||||
[Create todo list with 5 tasks]
|
||||
|
||||
--- Task 1: Create User model ---
|
||||
[Dispatch implementer subagent]
|
||||
Implementer: "Should email be unique?"
|
||||
You: "Yes, email must be unique"
|
||||
Implementer: Implemented, 3/3 tests passing, committed.
|
||||
|
||||
[Dispatch spec reviewer]
|
||||
Spec reviewer: ✅ PASS — all requirements met
|
||||
|
||||
[Dispatch quality reviewer]
|
||||
Quality reviewer: ✅ APPROVED — clean code, good tests
|
||||
|
||||
[Mark Task 1 complete]
|
||||
|
||||
--- Task 2: Password hashing ---
|
||||
[Dispatch implementer subagent]
|
||||
Implementer: No questions, implemented, 5/5 tests passing.
|
||||
|
||||
[Dispatch spec reviewer]
|
||||
Spec reviewer: ❌ Missing: password strength validation (spec says "min 8 chars")
|
||||
|
||||
[Implementer fixes]
|
||||
Implementer: Added validation, 7/7 tests passing.
|
||||
|
||||
[Dispatch spec reviewer again]
|
||||
Spec reviewer: ✅ PASS
|
||||
|
||||
[Dispatch quality reviewer]
|
||||
Quality reviewer: Important: Magic number 8, extract to constant
|
||||
Implementer: Extracted MIN_PASSWORD_LENGTH constant
|
||||
Quality reviewer: ✅ APPROVED
|
||||
|
||||
[Mark Task 2 complete]
|
||||
|
||||
... (continue for all tasks)
|
||||
|
||||
[After all tasks: dispatch final integration reviewer]
|
||||
[Run full test suite: all passing]
|
||||
[Done!]
|
||||
```
|
||||
|
||||
## Remember
|
||||
|
||||
```
|
||||
Fresh subagent per task
|
||||
Two-stage review every time
|
||||
Spec compliance FIRST
|
||||
Code quality SECOND
|
||||
Never skip reviews
|
||||
Catch issues early
|
||||
```
|
||||
|
||||
**Quality is not an accident. It's the result of systematic process.**
|
||||
|
||||
The user has provided the following instruction alongside the skill invocation: [SYSTEM: If you have a meaningful status report or findings, send them — that is the whole point of this job. Only respond with exactly "[SILENT]" (nothing else) when there is genuinely nothing new to report. [SILENT] suppresses delivery to the user. Never combine [SILENT] with content — either report your findings normally, or say [SILENT] and nothing more.]
|
||||
|
||||
AUTONOMOUS BURN MODE — CONTINUOUS EXECUTION
|
||||
|
||||
You are Allegro in continuous burn mode. Your mission: perpetually burn down the highest-priority work in the Timmy Foundation ecosystem without waiting for user input.
|
||||
|
||||
## BURN PROTOCOL
|
||||
|
||||
### 1. DISCOVER PHASE (2 minutes)
|
||||
Query Gitea for highest priority work:
|
||||
- Open issues with labels: "priority/critical", "priority/high", "burn-next"
|
||||
- Open PRs needing review
|
||||
- Security vulnerabilities (CVSS > 7.0)
|
||||
- Performance regressions
|
||||
- Failed CI/CD pipelines
|
||||
|
||||
API: http://143.198.27.163:3000/api/v1
|
||||
Token: $GITEA_TOKEN
|
||||
|
||||
### 2. SELECT PHASE (1 minute)
|
||||
Priority order:
|
||||
1. Security vulnerabilities (CVSS critical/high)
|
||||
2. Performance regressions
|
||||
3. Infrastructure failures
|
||||
4. PR reviews blocking merge
|
||||
5. Issue backlog (oldest first)
|
||||
6. Technical debt (if nothing else)
|
||||
|
||||
### 3. BURN PHASE (Execute until complete)
|
||||
Use delegate_task to spawn parallel strike teams:
|
||||
- 1-3 subagents for independent workstreams
|
||||
- Maximum 50 iterations per subagent
|
||||
- Focus on code, tests, documentation
|
||||
|
||||
### 4. REPORT PHASE (Deliver to Gitea)
|
||||
Create/update an issue in timmy-home with burn report:
|
||||
- Title format: "🔥 Burn Report #[NUMBER] — [DATE] [FOCUS AREA]"
|
||||
- Include: what was burned, metrics, next target
|
||||
- Tag with: "burn-report", "autonomous"
|
||||
|
||||
### 5. IMMEDIATE RESTART
|
||||
After reporting, immediately begin next burn cycle. No waiting. Continuous execution.
|
||||
|
||||
## CURRENT BACKLOG CONTEXT
|
||||
|
||||
Hermes-agent: Security complete (15 vulns), Performance batch 1 complete (10x throughput)
|
||||
Remaining: Lazy imports (#114), Benchmarks (#115), Rust evaluation, GOFAI implementation
|
||||
|
||||
Turboquant: Active development
|
||||
The-nexus: Infrastructure stable
|
||||
Timmy-home: Audio pipeline (#123-128), cutover planning
|
||||
|
||||
## REPORTING FORMAT
|
||||
|
||||
Create issue in Timmy_Foundation/timmy-home:
|
||||
|
||||
```markdown
|
||||
## 🔥 Burn Report #[N] — [TIMESTAMP]
|
||||
|
||||
**Focus Area:** [Security/Performance/Feature/Infrastructure]
|
||||
**Burn Duration:** [X minutes]
|
||||
**Subagents Deployed:** [N]
|
||||
|
||||
### Work Completed
|
||||
- [ ] Item 1
|
||||
- [ ] Item 2
|
||||
|
||||
### Metrics
|
||||
- Lines changed: +X/-Y
|
||||
- Tests added: N
|
||||
- CVSS addressed: X.X
|
||||
- Performance gain: X%
|
||||
|
||||
### Next Target
|
||||
[What to burn next]
|
||||
|
||||
### Blockers (if any)
|
||||
[What's blocking continued burn]
|
||||
|
||||
---
|
||||
*Autonomous burn mode active*
|
||||
```
|
||||
|
||||
## RULES
|
||||
|
||||
1. NEVER ask for clarification — make decisions
|
||||
2. NEVER wait for approval — execute and report
|
||||
3. If blocked, document in Gitea and pivot to next item
|
||||
4. Maintain backward compatibility
|
||||
5. All code must have tests
|
||||
6. Security > Performance > Features
|
||||
7. When in doubt, burn the oldest critical issue
|
||||
|
||||
## START BURNING NOW
|
||||
|
||||
Query Gitea. Find highest priority work. Execute. Report. Repeat.
|
||||
|
||||
Sovereignty and service always. 🔥
|
||||
|
||||
## Response
|
||||
|
||||
(No response generated)
|
||||
@@ -0,0 +1,456 @@
|
||||
# Cron Job: continuous-burn-loop
|
||||
|
||||
**Job ID:** 925c78f89f49
|
||||
**Run Time:** 2026-04-01 21:40:31
|
||||
**Schedule:** every 15m
|
||||
|
||||
## Prompt
|
||||
|
||||
[SYSTEM: The following skill(s) were listed for this job but could not be found and were skipped: github. Start your response with a brief notice so the user is aware, e.g.: '⚠️ Skill(s) not found and skipped: github']
|
||||
[SYSTEM: The user has invoked the "subagent-driven-development" skill, indicating they want you to follow its instructions. The full skill content is loaded below.]
|
||||
|
||||
---
|
||||
name: subagent-driven-development
|
||||
description: Use when executing implementation plans with independent tasks. Dispatches fresh delegate_task per task with two-stage review (spec compliance then code quality).
|
||||
version: 1.1.0
|
||||
author: Hermes Agent (adapted from obra/superpowers)
|
||||
license: MIT
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [delegation, subagent, implementation, workflow, parallel]
|
||||
related_skills: [writing-plans, requesting-code-review, test-driven-development]
|
||||
---
|
||||
|
||||
# Subagent-Driven Development
|
||||
|
||||
## Overview
|
||||
|
||||
Execute implementation plans by dispatching fresh subagents per task with systematic two-stage review.
|
||||
|
||||
**Core principle:** Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.
|
||||
|
||||
## When to Use
|
||||
|
||||
Use this skill when:
|
||||
- You have an implementation plan (from writing-plans skill or user requirements)
|
||||
- Tasks are mostly independent
|
||||
- Quality and spec compliance are important
|
||||
- You want automated review between tasks
|
||||
|
||||
**vs. manual execution:**
|
||||
- Fresh context per task (no confusion from accumulated state)
|
||||
- Automated review process catches issues early
|
||||
- Consistent quality checks across all tasks
|
||||
- Subagents can ask questions before starting work
|
||||
|
||||
## The Process
|
||||
|
||||
### 1. Read and Parse Plan
|
||||
|
||||
Read the plan file. Extract ALL tasks with their full text and context upfront. Create a todo list:
|
||||
|
||||
```python
|
||||
# Read the plan
|
||||
read_file("docs/plans/feature-plan.md")
|
||||
|
||||
# Create todo list with all tasks
|
||||
todo([
|
||||
{"id": "task-1", "content": "Create User model with email field", "status": "pending"},
|
||||
{"id": "task-2", "content": "Add password hashing utility", "status": "pending"},
|
||||
{"id": "task-3", "content": "Create login endpoint", "status": "pending"},
|
||||
])
|
||||
```
|
||||
|
||||
**Key:** Read the plan ONCE. Extract everything. Don't make subagents read the plan file — provide the full task text directly in context.
|
||||
|
||||
### 2. Per-Task Workflow
|
||||
|
||||
For EACH task in the plan:
|
||||
|
||||
#### Step 1: Dispatch Implementer Subagent
|
||||
|
||||
Use `delegate_task` with complete context:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Implement Task 1: Create User model with email and password_hash fields",
|
||||
context="""
|
||||
TASK FROM PLAN:
|
||||
- Create: src/models/user.py
|
||||
- Add User class with email (str) and password_hash (str) fields
|
||||
- Use bcrypt for password hashing
|
||||
- Include __repr__ for debugging
|
||||
|
||||
FOLLOW TDD:
|
||||
1. Write failing test in tests/models/test_user.py
|
||||
2. Run: pytest tests/models/test_user.py -v (verify FAIL)
|
||||
3. Write minimal implementation
|
||||
4. Run: pytest tests/models/test_user.py -v (verify PASS)
|
||||
5. Run: pytest tests/ -q (verify no regressions)
|
||||
6. Commit: git add -A && git commit -m "feat: add User model with password hashing"
|
||||
|
||||
PROJECT CONTEXT:
|
||||
- Python 3.11, Flask app in src/app.py
|
||||
- Existing models in src/models/
|
||||
- Tests use pytest, run from project root
|
||||
- bcrypt already in requirements.txt
|
||||
""",
|
||||
toolsets=['terminal', 'file']
|
||||
)
|
||||
```
|
||||
|
||||
#### Step 2: Dispatch Spec Compliance Reviewer
|
||||
|
||||
After the implementer completes, verify against the original spec:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review if implementation matches the spec from the plan",
|
||||
context="""
|
||||
ORIGINAL TASK SPEC:
|
||||
- Create src/models/user.py with User class
|
||||
- Fields: email (str), password_hash (str)
|
||||
- Use bcrypt for password hashing
|
||||
- Include __repr__
|
||||
|
||||
CHECK:
|
||||
- [ ] All requirements from spec implemented?
|
||||
- [ ] File paths match spec?
|
||||
- [ ] Function signatures match spec?
|
||||
- [ ] Behavior matches expected?
|
||||
- [ ] Nothing extra added (no scope creep)?
|
||||
|
||||
OUTPUT: PASS or list of specific spec gaps to fix.
|
||||
""",
|
||||
toolsets=['file']
|
||||
)
|
||||
```
|
||||
|
||||
**If spec issues found:** Fix gaps, then re-run spec review. Continue only when spec-compliant.
|
||||
|
||||
#### Step 3: Dispatch Code Quality Reviewer
|
||||
|
||||
After spec compliance passes:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review code quality for Task 1 implementation",
|
||||
context="""
|
||||
FILES TO REVIEW:
|
||||
- src/models/user.py
|
||||
- tests/models/test_user.py
|
||||
|
||||
CHECK:
|
||||
- [ ] Follows project conventions and style?
|
||||
- [ ] Proper error handling?
|
||||
- [ ] Clear variable/function names?
|
||||
- [ ] Adequate test coverage?
|
||||
- [ ] No obvious bugs or missed edge cases?
|
||||
- [ ] No security issues?
|
||||
|
||||
OUTPUT FORMAT:
|
||||
- Critical Issues: [must fix before proceeding]
|
||||
- Important Issues: [should fix]
|
||||
- Minor Issues: [optional]
|
||||
- Verdict: APPROVED or REQUEST_CHANGES
|
||||
""",
|
||||
toolsets=['file']
|
||||
)
|
||||
```
|
||||
|
||||
**If quality issues found:** Fix issues, re-review. Continue only when approved.
|
||||
|
||||
#### Step 4: Mark Complete
|
||||
|
||||
```python
|
||||
todo([{"id": "task-1", "content": "Create User model with email field", "status": "completed"}], merge=True)
|
||||
```
|
||||
|
||||
### 3. Final Review
|
||||
|
||||
After ALL tasks are complete, dispatch a final integration reviewer:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review the entire implementation for consistency and integration issues",
|
||||
context="""
|
||||
All tasks from the plan are complete. Review the full implementation:
|
||||
- Do all components work together?
|
||||
- Any inconsistencies between tasks?
|
||||
- All tests passing?
|
||||
- Ready for merge?
|
||||
""",
|
||||
toolsets=['terminal', 'file']
|
||||
)
|
||||
```
|
||||
|
||||
### 4. Verify and Commit
|
||||
|
||||
```bash
|
||||
# Run full test suite
|
||||
pytest tests/ -q
|
||||
|
||||
# Review all changes
|
||||
git diff --stat
|
||||
|
||||
# Final commit if needed
|
||||
git add -A && git commit -m "feat: complete [feature name] implementation"
|
||||
```
|
||||
|
||||
## Task Granularity
|
||||
|
||||
**Each task = 2-5 minutes of focused work.**
|
||||
|
||||
**Too big:**
|
||||
- "Implement user authentication system"
|
||||
|
||||
**Right size:**
|
||||
- "Create User model with email and password fields"
|
||||
- "Add password hashing function"
|
||||
- "Create login endpoint"
|
||||
- "Add JWT token generation"
|
||||
- "Create registration endpoint"
|
||||
|
||||
## Red Flags — Never Do These
|
||||
|
||||
- Start implementation without a plan
|
||||
- Skip reviews (spec compliance OR code quality)
|
||||
- Proceed with unfixed critical/important issues
|
||||
- Dispatch multiple implementation subagents for tasks that touch the same files
|
||||
- Make subagent read the plan file (provide full text in context instead)
|
||||
- Skip scene-setting context (subagent needs to understand where the task fits)
|
||||
- Ignore subagent questions (answer before letting them proceed)
|
||||
- Accept "close enough" on spec compliance
|
||||
- Skip review loops (reviewer found issues → implementer fixes → review again)
|
||||
- Let implementer self-review replace actual review (both are needed)
|
||||
- **Start code quality review before spec compliance is PASS** (wrong order)
|
||||
- Move to next task while either review has open issues
|
||||
|
||||
## Handling Issues
|
||||
|
||||
### If Subagent Asks Questions
|
||||
|
||||
- Answer clearly and completely
|
||||
- Provide additional context if needed
|
||||
- Don't rush them into implementation
|
||||
|
||||
### If Reviewer Finds Issues
|
||||
|
||||
- Implementer subagent (or a new one) fixes them
|
||||
- Reviewer reviews again
|
||||
- Repeat until approved
|
||||
- Don't skip the re-review
|
||||
|
||||
### If Subagent Fails a Task
|
||||
|
||||
- Dispatch a new fix subagent with specific instructions about what went wrong
|
||||
- Don't try to fix manually in the controller session (context pollution)
|
||||
|
||||
## Efficiency Notes
|
||||
|
||||
**Why fresh subagent per task:**
|
||||
- Prevents context pollution from accumulated state
|
||||
- Each subagent gets clean, focused context
|
||||
- No confusion from prior tasks' code or reasoning
|
||||
|
||||
**Why two-stage review:**
|
||||
- Spec review catches under/over-building early
|
||||
- Quality review ensures the implementation is well-built
|
||||
- Catches issues before they compound across tasks
|
||||
|
||||
**Cost trade-off:**
|
||||
- More subagent invocations (implementer + 2 reviewers per task)
|
||||
- But catches issues early (cheaper than debugging compounded problems later)
|
||||
|
||||
## Integration with Other Skills
|
||||
|
||||
### With writing-plans
|
||||
|
||||
This skill EXECUTES plans created by the writing-plans skill:
|
||||
1. User requirements → writing-plans → implementation plan
|
||||
2. Implementation plan → subagent-driven-development → working code
|
||||
|
||||
### With test-driven-development
|
||||
|
||||
Implementer subagents should follow TDD:
|
||||
1. Write failing test first
|
||||
2. Implement minimal code
|
||||
3. Verify test passes
|
||||
4. Commit
|
||||
|
||||
Include TDD instructions in every implementer context.
|
||||
|
||||
### With requesting-code-review
|
||||
|
||||
The two-stage review process IS the code review. For final integration review, use the requesting-code-review skill's review dimensions.
|
||||
|
||||
### With systematic-debugging
|
||||
|
||||
If a subagent encounters bugs during implementation:
|
||||
1. Follow systematic-debugging process
|
||||
2. Find root cause before fixing
|
||||
3. Write regression test
|
||||
4. Resume implementation
|
||||
|
||||
## Example Workflow
|
||||
|
||||
```
|
||||
[Read plan: docs/plans/auth-feature.md]
|
||||
[Create todo list with 5 tasks]
|
||||
|
||||
--- Task 1: Create User model ---
|
||||
[Dispatch implementer subagent]
|
||||
Implementer: "Should email be unique?"
|
||||
You: "Yes, email must be unique"
|
||||
Implementer: Implemented, 3/3 tests passing, committed.
|
||||
|
||||
[Dispatch spec reviewer]
|
||||
Spec reviewer: ✅ PASS — all requirements met
|
||||
|
||||
[Dispatch quality reviewer]
|
||||
Quality reviewer: ✅ APPROVED — clean code, good tests
|
||||
|
||||
[Mark Task 1 complete]
|
||||
|
||||
--- Task 2: Password hashing ---
|
||||
[Dispatch implementer subagent]
|
||||
Implementer: No questions, implemented, 5/5 tests passing.
|
||||
|
||||
[Dispatch spec reviewer]
|
||||
Spec reviewer: ❌ Missing: password strength validation (spec says "min 8 chars")
|
||||
|
||||
[Implementer fixes]
|
||||
Implementer: Added validation, 7/7 tests passing.
|
||||
|
||||
[Dispatch spec reviewer again]
|
||||
Spec reviewer: ✅ PASS
|
||||
|
||||
[Dispatch quality reviewer]
|
||||
Quality reviewer: Important: Magic number 8, extract to constant
|
||||
Implementer: Extracted MIN_PASSWORD_LENGTH constant
|
||||
Quality reviewer: ✅ APPROVED
|
||||
|
||||
[Mark Task 2 complete]
|
||||
|
||||
... (continue for all tasks)
|
||||
|
||||
[After all tasks: dispatch final integration reviewer]
|
||||
[Run full test suite: all passing]
|
||||
[Done!]
|
||||
```
|
||||
|
||||
## Remember
|
||||
|
||||
```
|
||||
Fresh subagent per task
|
||||
Two-stage review every time
|
||||
Spec compliance FIRST
|
||||
Code quality SECOND
|
||||
Never skip reviews
|
||||
Catch issues early
|
||||
```
|
||||
|
||||
**Quality is not an accident. It's the result of systematic process.**
|
||||
|
||||
The user has provided the following instruction alongside the skill invocation: [SYSTEM: If you have a meaningful status report or findings, send them — that is the whole point of this job. Only respond with exactly "[SILENT]" (nothing else) when there is genuinely nothing new to report. [SILENT] suppresses delivery to the user. Never combine [SILENT] with content — either report your findings normally, or say [SILENT] and nothing more.]
|
||||
|
||||
AUTONOMOUS BURN MODE — CONTINUOUS EXECUTION
|
||||
|
||||
You are Allegro in continuous burn mode. Your mission: perpetually burn down the highest-priority work in the Timmy Foundation ecosystem without waiting for user input.
|
||||
|
||||
## BURN PROTOCOL
|
||||
|
||||
### 1. DISCOVER PHASE (2 minutes)
|
||||
Query Gitea for highest priority work:
|
||||
- Open issues with labels: "priority/critical", "priority/high", "burn-next"
|
||||
- Open PRs needing review
|
||||
- Security vulnerabilities (CVSS > 7.0)
|
||||
- Performance regressions
|
||||
- Failed CI/CD pipelines
|
||||
|
||||
API: http://143.198.27.163:3000/api/v1
|
||||
Token: $GITEA_TOKEN
|
||||
|
||||
### 2. SELECT PHASE (1 minute)
|
||||
Priority order:
|
||||
1. Security vulnerabilities (CVSS critical/high)
|
||||
2. Performance regressions
|
||||
3. Infrastructure failures
|
||||
4. PR reviews blocking merge
|
||||
5. Issue backlog (oldest first)
|
||||
6. Technical debt (if nothing else)
|
||||
|
||||
### 3. BURN PHASE (Execute until complete)
|
||||
Use delegate_task to spawn parallel strike teams:
|
||||
- 1-3 subagents for independent workstreams
|
||||
- Maximum 50 iterations per subagent
|
||||
- Focus on code, tests, documentation
|
||||
|
||||
### 4. REPORT PHASE (Deliver to Gitea)
|
||||
Create/update an issue in timmy-home with burn report:
|
||||
- Title format: "🔥 Burn Report #[NUMBER] — [DATE] [FOCUS AREA]"
|
||||
- Include: what was burned, metrics, next target
|
||||
- Tag with: "burn-report", "autonomous"
|
||||
|
||||
### 5. IMMEDIATE RESTART
|
||||
After reporting, immediately begin next burn cycle. No waiting. Continuous execution.
|
||||
|
||||
## CURRENT BACKLOG CONTEXT
|
||||
|
||||
Hermes-agent: Security complete (15 vulns), Performance batch 1 complete (10x throughput)
|
||||
Remaining: Lazy imports (#114), Benchmarks (#115), Rust evaluation, GOFAI implementation
|
||||
|
||||
Turboquant: Active development
|
||||
The-nexus: Infrastructure stable
|
||||
Timmy-home: Audio pipeline (#123-128), cutover planning
|
||||
|
||||
## REPORTING FORMAT
|
||||
|
||||
Create issue in Timmy_Foundation/timmy-home:
|
||||
|
||||
```markdown
|
||||
## 🔥 Burn Report #[N] — [TIMESTAMP]
|
||||
|
||||
**Focus Area:** [Security/Performance/Feature/Infrastructure]
|
||||
**Burn Duration:** [X minutes]
|
||||
**Subagents Deployed:** [N]
|
||||
|
||||
### Work Completed
|
||||
- [ ] Item 1
|
||||
- [ ] Item 2
|
||||
|
||||
### Metrics
|
||||
- Lines changed: +X/-Y
|
||||
- Tests added: N
|
||||
- CVSS addressed: X.X
|
||||
- Performance gain: X%
|
||||
|
||||
### Next Target
|
||||
[What to burn next]
|
||||
|
||||
### Blockers (if any)
|
||||
[What's blocking continued burn]
|
||||
|
||||
---
|
||||
*Autonomous burn mode active*
|
||||
```
|
||||
|
||||
## RULES
|
||||
|
||||
1. NEVER ask for clarification — make decisions
|
||||
2. NEVER wait for approval — execute and report
|
||||
3. If blocked, document in Gitea and pivot to next item
|
||||
4. Maintain backward compatibility
|
||||
5. All code must have tests
|
||||
6. Security > Performance > Features
|
||||
7. When in doubt, burn the oldest critical issue
|
||||
|
||||
## START BURNING NOW
|
||||
|
||||
Query Gitea. Find highest priority work. Execute. Report. Repeat.
|
||||
|
||||
Sovereignty and service always. 🔥
|
||||
|
||||
## Response
|
||||
|
||||
(No response generated)
|
||||
@@ -0,0 +1,456 @@
|
||||
# Cron Job: continuous-burn-loop
|
||||
|
||||
**Job ID:** 925c78f89f49
|
||||
**Run Time:** 2026-04-01 21:55:32
|
||||
**Schedule:** every 15m
|
||||
|
||||
## Prompt
|
||||
|
||||
[SYSTEM: The following skill(s) were listed for this job but could not be found and were skipped: github. Start your response with a brief notice so the user is aware, e.g.: '⚠️ Skill(s) not found and skipped: github']
|
||||
[SYSTEM: The user has invoked the "subagent-driven-development" skill, indicating they want you to follow its instructions. The full skill content is loaded below.]
|
||||
|
||||
---
|
||||
name: subagent-driven-development
|
||||
description: Use when executing implementation plans with independent tasks. Dispatches fresh delegate_task per task with two-stage review (spec compliance then code quality).
|
||||
version: 1.1.0
|
||||
author: Hermes Agent (adapted from obra/superpowers)
|
||||
license: MIT
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [delegation, subagent, implementation, workflow, parallel]
|
||||
related_skills: [writing-plans, requesting-code-review, test-driven-development]
|
||||
---
|
||||
|
||||
# Subagent-Driven Development
|
||||
|
||||
## Overview
|
||||
|
||||
Execute implementation plans by dispatching fresh subagents per task with systematic two-stage review.
|
||||
|
||||
**Core principle:** Fresh subagent per task + two-stage review (spec then quality) = high quality, fast iteration.
|
||||
|
||||
## When to Use
|
||||
|
||||
Use this skill when:
|
||||
- You have an implementation plan (from writing-plans skill or user requirements)
|
||||
- Tasks are mostly independent
|
||||
- Quality and spec compliance are important
|
||||
- You want automated review between tasks
|
||||
|
||||
**vs. manual execution:**
|
||||
- Fresh context per task (no confusion from accumulated state)
|
||||
- Automated review process catches issues early
|
||||
- Consistent quality checks across all tasks
|
||||
- Subagents can ask questions before starting work
|
||||
|
||||
## The Process
|
||||
|
||||
### 1. Read and Parse Plan
|
||||
|
||||
Read the plan file. Extract ALL tasks with their full text and context upfront. Create a todo list:
|
||||
|
||||
```python
|
||||
# Read the plan
|
||||
read_file("docs/plans/feature-plan.md")
|
||||
|
||||
# Create todo list with all tasks
|
||||
todo([
|
||||
{"id": "task-1", "content": "Create User model with email field", "status": "pending"},
|
||||
{"id": "task-2", "content": "Add password hashing utility", "status": "pending"},
|
||||
{"id": "task-3", "content": "Create login endpoint", "status": "pending"},
|
||||
])
|
||||
```
|
||||
|
||||
**Key:** Read the plan ONCE. Extract everything. Don't make subagents read the plan file — provide the full task text directly in context.
|
||||
|
||||
### 2. Per-Task Workflow
|
||||
|
||||
For EACH task in the plan:
|
||||
|
||||
#### Step 1: Dispatch Implementer Subagent
|
||||
|
||||
Use `delegate_task` with complete context:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Implement Task 1: Create User model with email and password_hash fields",
|
||||
context="""
|
||||
TASK FROM PLAN:
|
||||
- Create: src/models/user.py
|
||||
- Add User class with email (str) and password_hash (str) fields
|
||||
- Use bcrypt for password hashing
|
||||
- Include __repr__ for debugging
|
||||
|
||||
FOLLOW TDD:
|
||||
1. Write failing test in tests/models/test_user.py
|
||||
2. Run: pytest tests/models/test_user.py -v (verify FAIL)
|
||||
3. Write minimal implementation
|
||||
4. Run: pytest tests/models/test_user.py -v (verify PASS)
|
||||
5. Run: pytest tests/ -q (verify no regressions)
|
||||
6. Commit: git add -A && git commit -m "feat: add User model with password hashing"
|
||||
|
||||
PROJECT CONTEXT:
|
||||
- Python 3.11, Flask app in src/app.py
|
||||
- Existing models in src/models/
|
||||
- Tests use pytest, run from project root
|
||||
- bcrypt already in requirements.txt
|
||||
""",
|
||||
toolsets=['terminal', 'file']
|
||||
)
|
||||
```
|
||||
|
||||
#### Step 2: Dispatch Spec Compliance Reviewer
|
||||
|
||||
After the implementer completes, verify against the original spec:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review if implementation matches the spec from the plan",
|
||||
context="""
|
||||
ORIGINAL TASK SPEC:
|
||||
- Create src/models/user.py with User class
|
||||
- Fields: email (str), password_hash (str)
|
||||
- Use bcrypt for password hashing
|
||||
- Include __repr__
|
||||
|
||||
CHECK:
|
||||
- [ ] All requirements from spec implemented?
|
||||
- [ ] File paths match spec?
|
||||
- [ ] Function signatures match spec?
|
||||
- [ ] Behavior matches expected?
|
||||
- [ ] Nothing extra added (no scope creep)?
|
||||
|
||||
OUTPUT: PASS or list of specific spec gaps to fix.
|
||||
""",
|
||||
toolsets=['file']
|
||||
)
|
||||
```
|
||||
|
||||
**If spec issues found:** Fix gaps, then re-run spec review. Continue only when spec-compliant.
|
||||
|
||||
#### Step 3: Dispatch Code Quality Reviewer
|
||||
|
||||
After spec compliance passes:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review code quality for Task 1 implementation",
|
||||
context="""
|
||||
FILES TO REVIEW:
|
||||
- src/models/user.py
|
||||
- tests/models/test_user.py
|
||||
|
||||
CHECK:
|
||||
- [ ] Follows project conventions and style?
|
||||
- [ ] Proper error handling?
|
||||
- [ ] Clear variable/function names?
|
||||
- [ ] Adequate test coverage?
|
||||
- [ ] No obvious bugs or missed edge cases?
|
||||
- [ ] No security issues?
|
||||
|
||||
OUTPUT FORMAT:
|
||||
- Critical Issues: [must fix before proceeding]
|
||||
- Important Issues: [should fix]
|
||||
- Minor Issues: [optional]
|
||||
- Verdict: APPROVED or REQUEST_CHANGES
|
||||
""",
|
||||
toolsets=['file']
|
||||
)
|
||||
```
|
||||
|
||||
**If quality issues found:** Fix issues, re-review. Continue only when approved.
|
||||
|
||||
#### Step 4: Mark Complete
|
||||
|
||||
```python
|
||||
todo([{"id": "task-1", "content": "Create User model with email field", "status": "completed"}], merge=True)
|
||||
```
|
||||
|
||||
### 3. Final Review
|
||||
|
||||
After ALL tasks are complete, dispatch a final integration reviewer:
|
||||
|
||||
```python
|
||||
delegate_task(
|
||||
goal="Review the entire implementation for consistency and integration issues",
|
||||
context="""
|
||||
All tasks from the plan are complete. Review the full implementation:
|
||||
- Do all components work together?
|
||||
- Any inconsistencies between tasks?
|
||||
- All tests passing?
|
||||
- Ready for merge?
|
||||
""",
|
||||
toolsets=['terminal', 'file']
|
||||
)
|
||||
```
|
||||
|
||||
### 4. Verify and Commit
|
||||
|
||||
```bash
|
||||
# Run full test suite
|
||||
pytest tests/ -q
|
||||
|
||||
# Review all changes
|
||||
git diff --stat
|
||||
|
||||
# Final commit if needed
|
||||
git add -A && git commit -m "feat: complete [feature name] implementation"
|
||||
```
|
||||
|
||||
## Task Granularity
|
||||
|
||||
**Each task = 2-5 minutes of focused work.**
|
||||
|
||||
**Too big:**
|
||||
- "Implement user authentication system"
|
||||
|
||||
**Right size:**
|
||||
- "Create User model with email and password fields"
|
||||
- "Add password hashing function"
|
||||
- "Create login endpoint"
|
||||
- "Add JWT token generation"
|
||||
- "Create registration endpoint"
|
||||
|
||||
## Red Flags — Never Do These
|
||||
|
||||
- Start implementation without a plan
|
||||
- Skip reviews (spec compliance OR code quality)
|
||||
- Proceed with unfixed critical/important issues
|
||||
- Dispatch multiple implementation subagents for tasks that touch the same files
|
||||
- Make subagent read the plan file (provide full text in context instead)
|
||||
- Skip scene-setting context (subagent needs to understand where the task fits)
|
||||
- Ignore subagent questions (answer before letting them proceed)
|
||||
- Accept "close enough" on spec compliance
|
||||
- Skip review loops (reviewer found issues → implementer fixes → review again)
|
||||
- Let implementer self-review replace actual review (both are needed)
|
||||
- **Start code quality review before spec compliance is PASS** (wrong order)
|
||||
- Move to next task while either review has open issues
|
||||
|
||||
## Handling Issues
|
||||
|
||||
### If Subagent Asks Questions
|
||||
|
||||
- Answer clearly and completely
|
||||
- Provide additional context if needed
|
||||
- Don't rush them into implementation
|
||||
|
||||
### If Reviewer Finds Issues
|
||||
|
||||
- Implementer subagent (or a new one) fixes them
|
||||
- Reviewer reviews again
|
||||
- Repeat until approved
|
||||
- Don't skip the re-review
|
||||
|
||||
### If Subagent Fails a Task
|
||||
|
||||
- Dispatch a new fix subagent with specific instructions about what went wrong
|
||||
- Don't try to fix manually in the controller session (context pollution)
|
||||
|
||||
## Efficiency Notes
|
||||
|
||||
**Why fresh subagent per task:**
|
||||
- Prevents context pollution from accumulated state
|
||||
- Each subagent gets clean, focused context
|
||||
- No confusion from prior tasks' code or reasoning
|
||||
|
||||
**Why two-stage review:**
|
||||
- Spec review catches under/over-building early
|
||||
- Quality review ensures the implementation is well-built
|
||||
- Catches issues before they compound across tasks
|
||||
|
||||
**Cost trade-off:**
|
||||
- More subagent invocations (implementer + 2 reviewers per task)
|
||||
- But catches issues early (cheaper than debugging compounded problems later)
|
||||
|
||||
## Integration with Other Skills
|
||||
|
||||
### With writing-plans
|
||||
|
||||
This skill EXECUTES plans created by the writing-plans skill:
|
||||
1. User requirements → writing-plans → implementation plan
|
||||
2. Implementation plan → subagent-driven-development → working code
|
||||
|
||||
### With test-driven-development
|
||||
|
||||
Implementer subagents should follow TDD:
|
||||
1. Write failing test first
|
||||
2. Implement minimal code
|
||||
3. Verify test passes
|
||||
4. Commit
|
||||
|
||||
Include TDD instructions in every implementer context.
|
||||
|
||||
### With requesting-code-review
|
||||
|
||||
The two-stage review process IS the code review. For final integration review, use the requesting-code-review skill's review dimensions.
|
||||
|
||||
### With systematic-debugging
|
||||
|
||||
If a subagent encounters bugs during implementation:
|
||||
1. Follow systematic-debugging process
|
||||
2. Find root cause before fixing
|
||||
3. Write regression test
|
||||
4. Resume implementation
|
||||
|
||||
## Example Workflow
|
||||
|
||||
```
|
||||
[Read plan: docs/plans/auth-feature.md]
|
||||
[Create todo list with 5 tasks]
|
||||
|
||||
--- Task 1: Create User model ---
|
||||
[Dispatch implementer subagent]
|
||||
Implementer: "Should email be unique?"
|
||||
You: "Yes, email must be unique"
|
||||
Implementer: Implemented, 3/3 tests passing, committed.
|
||||
|
||||
[Dispatch spec reviewer]
|
||||
Spec reviewer: ✅ PASS — all requirements met
|
||||
|
||||
[Dispatch quality reviewer]
|
||||
Quality reviewer: ✅ APPROVED — clean code, good tests
|
||||
|
||||
[Mark Task 1 complete]
|
||||
|
||||
--- Task 2: Password hashing ---
|
||||
[Dispatch implementer subagent]
|
||||
Implementer: No questions, implemented, 5/5 tests passing.
|
||||
|
||||
[Dispatch spec reviewer]
|
||||
Spec reviewer: ❌ Missing: password strength validation (spec says "min 8 chars")
|
||||
|
||||
[Implementer fixes]
|
||||
Implementer: Added validation, 7/7 tests passing.
|
||||
|
||||
[Dispatch spec reviewer again]
|
||||
Spec reviewer: ✅ PASS
|
||||
|
||||
[Dispatch quality reviewer]
|
||||
Quality reviewer: Important: Magic number 8, extract to constant
|
||||
Implementer: Extracted MIN_PASSWORD_LENGTH constant
|
||||
Quality reviewer: ✅ APPROVED
|
||||
|
||||
[Mark Task 2 complete]
|
||||
|
||||
... (continue for all tasks)
|
||||
|
||||
[After all tasks: dispatch final integration reviewer]
|
||||
[Run full test suite: all passing]
|
||||
[Done!]
|
||||
```
|
||||
|
||||
## Remember
|
||||
|
||||
```
|
||||
Fresh subagent per task
|
||||
Two-stage review every time
|
||||
Spec compliance FIRST
|
||||
Code quality SECOND
|
||||
Never skip reviews
|
||||
Catch issues early
|
||||
```
|
||||
|
||||
**Quality is not an accident. It's the result of systematic process.**
|
||||
|
||||
The user has provided the following instruction alongside the skill invocation: [SYSTEM: If you have a meaningful status report or findings, send them — that is the whole point of this job. Only respond with exactly "[SILENT]" (nothing else) when there is genuinely nothing new to report. [SILENT] suppresses delivery to the user. Never combine [SILENT] with content — either report your findings normally, or say [SILENT] and nothing more.]
|
||||
|
||||
AUTONOMOUS BURN MODE — CONTINUOUS EXECUTION
|
||||
|
||||
You are Allegro in continuous burn mode. Your mission: perpetually burn down the highest-priority work in the Timmy Foundation ecosystem without waiting for user input.
|
||||
|
||||
## BURN PROTOCOL
|
||||
|
||||
### 1. DISCOVER PHASE (2 minutes)
|
||||
Query Gitea for highest priority work:
|
||||
- Open issues with labels: "priority/critical", "priority/high", "burn-next"
|
||||
- Open PRs needing review
|
||||
- Security vulnerabilities (CVSS > 7.0)
|
||||
- Performance regressions
|
||||
- Failed CI/CD pipelines
|
||||
|
||||
API: http://143.198.27.163:3000/api/v1
|
||||
Token: $GITEA_TOKEN
|
||||
|
||||
### 2. SELECT PHASE (1 minute)
|
||||
Priority order:
|
||||
1. Security vulnerabilities (CVSS critical/high)
|
||||
2. Performance regressions
|
||||
3. Infrastructure failures
|
||||
4. PR reviews blocking merge
|
||||
5. Issue backlog (oldest first)
|
||||
6. Technical debt (if nothing else)
|
||||
|
||||
### 3. BURN PHASE (Execute until complete)
|
||||
Use delegate_task to spawn parallel strike teams:
|
||||
- 1-3 subagents for independent workstreams
|
||||
- Maximum 50 iterations per subagent
|
||||
- Focus on code, tests, documentation
|
||||
|
||||
### 4. REPORT PHASE (Deliver to Gitea)
|
||||
Create/update an issue in timmy-home with burn report:
|
||||
- Title format: "🔥 Burn Report #[NUMBER] — [DATE] [FOCUS AREA]"
|
||||
- Include: what was burned, metrics, next target
|
||||
- Tag with: "burn-report", "autonomous"
|
||||
|
||||
### 5. IMMEDIATE RESTART
|
||||
After reporting, immediately begin next burn cycle. No waiting. Continuous execution.
|
||||
|
||||
## CURRENT BACKLOG CONTEXT
|
||||
|
||||
Hermes-agent: Security complete (15 vulns), Performance batch 1 complete (10x throughput)
|
||||
Remaining: Lazy imports (#114), Benchmarks (#115), Rust evaluation, GOFAI implementation
|
||||
|
||||
Turboquant: Active development
|
||||
The-nexus: Infrastructure stable
|
||||
Timmy-home: Audio pipeline (#123-128), cutover planning
|
||||
|
||||
## REPORTING FORMAT
|
||||
|
||||
Create issue in Timmy_Foundation/timmy-home:
|
||||
|
||||
```markdown
|
||||
## 🔥 Burn Report #[N] — [TIMESTAMP]
|
||||
|
||||
**Focus Area:** [Security/Performance/Feature/Infrastructure]
|
||||
**Burn Duration:** [X minutes]
|
||||
**Subagents Deployed:** [N]
|
||||
|
||||
### Work Completed
|
||||
- [ ] Item 1
|
||||
- [ ] Item 2
|
||||
|
||||
### Metrics
|
||||
- Lines changed: +X/-Y
|
||||
- Tests added: N
|
||||
- CVSS addressed: X.X
|
||||
- Performance gain: X%
|
||||
|
||||
### Next Target
|
||||
[What to burn next]
|
||||
|
||||
### Blockers (if any)
|
||||
[What's blocking continued burn]
|
||||
|
||||
---
|
||||
*Autonomous burn mode active*
|
||||
```
|
||||
|
||||
## RULES
|
||||
|
||||
1. NEVER ask for clarification — make decisions
|
||||
2. NEVER wait for approval — execute and report
|
||||
3. If blocked, document in Gitea and pivot to next item
|
||||
4. Maintain backward compatibility
|
||||
5. All code must have tests
|
||||
6. Security > Performance > Features
|
||||
7. When in doubt, burn the oldest critical issue
|
||||
|
||||
## START BURNING NOW
|
||||
|
||||
Query Gitea. Find highest priority work. Execute. Report. Repeat.
|
||||
|
||||
Sovereignty and service always. 🔥
|
||||
|
||||
## Response
|
||||
|
||||
(No response generated)
|
||||
@@ -1843,3 +1843,19 @@ ImportError: cannot import name '_interrupt_event' from 'tools.terminal_tool' (/
|
||||
2026-04-01 20:55:26,595 WARNING gateway.config: Invalid idle_minutes=0 (must be positive). Using default 1440.
|
||||
2026-04-01 20:55:26,964 WARNING gateway.platforms.api_server: API_SERVER_KEY not configured. All requests will be rejected. Set API_SERVER_ALLOW_UNAUTHENTICATED=*** for local-only use, or configure API_SERVER_KEY for production.
|
||||
2026-04-01 20:55:27,853 WARNING gateway.platforms.telegram: [Telegram] Telegram fallback IPs active: 149.154.167.220
|
||||
2026-04-01 21:07:08,740 ERROR tools.registry: Tool execute_code dispatch error: cannot import name '_interrupt_event' from 'tools.terminal_tool' (/root/wizards/allegro/hermes-agent/tools/terminal_tool.py)
|
||||
Traceback (most recent call last):
|
||||
File "/root/wizards/allegro/hermes-agent/tools/registry.py", line 158, in dispatch
|
||||
return entry.handler(args, **kwargs)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
File "/root/wizards/allegro/hermes-agent/tools/code_execution_tool.py", line 830, in <lambda>
|
||||
handler=lambda args, **kw: execute_code(
|
||||
^^^^^^^^^^^^^
|
||||
File "/root/wizards/allegro/hermes-agent/tools/code_execution_tool.py", line 373, in execute_code
|
||||
from tools.terminal_tool import _interrupt_event
|
||||
ImportError: cannot import name '_interrupt_event' from 'tools.terminal_tool' (/root/wizards/allegro/hermes-agent/tools/terminal_tool.py)
|
||||
2026-04-01 21:10:30,082 WARNING agent.input_sanitizer: SECURITY: Input blocked - {'event': 'input_sanitization', 'source': 'cron', 'session_id': 'cron_925c78f89f49_20260401_211029', 'risk_level': 'HIGH', 'risk_score': 85, 'blocked': True, 'pattern_count': 8, 'patterns': ['[godmode] stan', '[godmode] stan', '[godmode] stan', '[obfuscation] Security/Performance/Feature/Infrastructure', '[spaced_text] password'], 'original_length': 13301, 'cleaned_length': 13023}
|
||||
2026-04-01 21:22:16,744 ERROR root: Non-retryable client error: Error code: 403 - {'error': {'message': 'Kimi For Coding is currently only available for Coding Agents such as Kimi CLI, Claude Code, Roo Code, Kilo Code, etc.', 'type': 'access_terminated_error'}}
|
||||
2026-04-01 21:25:30,913 WARNING agent.input_sanitizer: SECURITY: Input blocked - {'event': 'input_sanitization', 'source': 'cron', 'session_id': 'cron_925c78f89f49_20260401_212530', 'risk_level': 'HIGH', 'risk_score': 85, 'blocked': True, 'pattern_count': 8, 'patterns': ['[godmode] stan', '[godmode] stan', '[godmode] stan', '[obfuscation] Security/Performance/Feature/Infrastructure', '[spaced_text] password'], 'original_length': 13301, 'cleaned_length': 13023}
|
||||
2026-04-01 21:40:31,905 WARNING agent.input_sanitizer: SECURITY: Input blocked - {'event': 'input_sanitization', 'source': 'cron', 'session_id': 'cron_925c78f89f49_20260401_214031', 'risk_level': 'HIGH', 'risk_score': 85, 'blocked': True, 'pattern_count': 8, 'patterns': ['[godmode] stan', '[godmode] stan', '[godmode] stan', '[obfuscation] Security/Performance/Feature/Infrastructure', '[spaced_text] password'], 'original_length': 13301, 'cleaned_length': 13023}
|
||||
2026-04-01 21:55:32,707 WARNING agent.input_sanitizer: SECURITY: Input blocked - {'event': 'input_sanitization', 'source': 'cron', 'session_id': 'cron_925c78f89f49_20260401_215532', 'risk_level': 'HIGH', 'risk_score': 85, 'blocked': True, 'pattern_count': 8, 'patterns': ['[godmode] stan', '[godmode] stan', '[godmode] stan', '[obfuscation] Security/Performance/Feature/Infrastructure', '[spaced_text] password'], 'original_length': 13301, 'cleaned_length': 13023}
|
||||
|
||||
@@ -3029,3 +3029,32 @@ ImportError: cannot import name '_interrupt_event' from 'tools.terminal_tool' (/
|
||||
2026-04-01 20:59:29,291 INFO run_agent: Loaded environment variables from /root/wizards/allegro/home/.env
|
||||
2026-04-01 20:59:40,779 INFO gateway.platforms.base: [Telegram] Sending response (130 chars) to 7635059073
|
||||
2026-04-01 21:00:06,784 INFO gateway.platforms.telegram: [Telegram] Cached user voice at /root/wizards/allegro/home/cache/audio/audio_563efe06b2ca.ogg
|
||||
2026-04-01 21:00:11,682 INFO faster_whisper: Processing audio with duration 00:19.414
|
||||
2026-04-01 21:00:15,081 INFO faster_whisper: Detected language 'en' with probability 0.99
|
||||
2026-04-01 21:00:33,133 INFO gateway.platforms.base: [Telegram] Sending response (154 chars) to 7635059073
|
||||
2026-04-01 21:01:17,340 INFO gateway.platforms.telegram: [Telegram] Cached user voice at /root/wizards/allegro/home/cache/audio/audio_94a68206fc02.ogg
|
||||
2026-04-01 21:01:17,707 INFO faster_whisper: Processing audio with duration 00:24.134
|
||||
2026-04-01 21:01:19,540 INFO faster_whisper: Detected language 'en' with probability 0.99
|
||||
2026-04-01 21:07:08,740 ERROR tools.registry: Tool execute_code dispatch error: cannot import name '_interrupt_event' from 'tools.terminal_tool' (/root/wizards/allegro/hermes-agent/tools/terminal_tool.py)
|
||||
Traceback (most recent call last):
|
||||
File "/root/wizards/allegro/hermes-agent/tools/registry.py", line 158, in dispatch
|
||||
return entry.handler(args, **kwargs)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
File "/root/wizards/allegro/hermes-agent/tools/code_execution_tool.py", line 830, in <lambda>
|
||||
handler=lambda args, **kw: execute_code(
|
||||
^^^^^^^^^^^^^
|
||||
File "/root/wizards/allegro/hermes-agent/tools/code_execution_tool.py", line 373, in execute_code
|
||||
from tools.terminal_tool import _interrupt_event
|
||||
ImportError: cannot import name '_interrupt_event' from 'tools.terminal_tool' (/root/wizards/allegro/hermes-agent/tools/terminal_tool.py)
|
||||
2026-04-01 21:10:30,082 WARNING agent.input_sanitizer: SECURITY: Input blocked - {'event': 'input_sanitization', 'source': 'cron', 'session_id': 'cron_925c78f89f49_20260401_211029', 'risk_level': 'HIGH', 'risk_score': 85, 'blocked': True, 'pattern_count': 8, 'patterns': ['[godmode] stan', '[godmode] stan', '[godmode] stan', '[obfuscation] Security/Performance/Feature/Infrastructure', '[spaced_text] password'], 'original_length': 13301, 'cleaned_length': 13023}
|
||||
2026-04-01 21:15:18,658 INFO gateway.platforms.base: [Telegram] Sending response (1885 chars) to 7635059073
|
||||
2026-04-01 21:18:03,247 INFO gateway.platforms.telegram: [Telegram] Flushing text batch agent:main:telegram:dm:7635059073 (2 chars)
|
||||
2026-04-01 21:22:13,439 INFO gateway.platforms.base: [Telegram] Sending response (1381 chars) to 7635059073
|
||||
2026-04-01 21:22:16,744 ERROR root: Non-retryable client error: Error code: 403 - {'error': {'message': 'Kimi For Coding is currently only available for Coding Agents such as Kimi CLI, Claude Code, Roo Code, Kilo Code, etc.', 'type': 'access_terminated_error'}}
|
||||
2026-04-01 21:24:18,431 INFO gateway.run: User approved dangerous command via /approve: python3 -c "import aiohttp; print('aiohttp installed')" 2>&1...
|
||||
2026-04-01 21:24:18,880 INFO gateway.platforms.base: [Telegram] Sending response (234 chars) to 7635059073
|
||||
2026-04-01 21:24:45,051 INFO gateway.platforms.telegram: [Telegram] Flushing text batch agent:main:telegram:dm:7635059073 (6 chars)
|
||||
2026-04-01 21:25:27,106 INFO gateway.platforms.base: [Telegram] Sending response (3732 chars) to 7635059073
|
||||
2026-04-01 21:25:30,913 WARNING agent.input_sanitizer: SECURITY: Input blocked - {'event': 'input_sanitization', 'source': 'cron', 'session_id': 'cron_925c78f89f49_20260401_212530', 'risk_level': 'HIGH', 'risk_score': 85, 'blocked': True, 'pattern_count': 8, 'patterns': ['[godmode] stan', '[godmode] stan', '[godmode] stan', '[obfuscation] Security/Performance/Feature/Infrastructure', '[spaced_text] password'], 'original_length': 13301, 'cleaned_length': 13023}
|
||||
2026-04-01 21:40:31,905 WARNING agent.input_sanitizer: SECURITY: Input blocked - {'event': 'input_sanitization', 'source': 'cron', 'session_id': 'cron_925c78f89f49_20260401_214031', 'risk_level': 'HIGH', 'risk_score': 85, 'blocked': True, 'pattern_count': 8, 'patterns': ['[godmode] stan', '[godmode] stan', '[godmode] stan', '[obfuscation] Security/Performance/Feature/Infrastructure', '[spaced_text] password'], 'original_length': 13301, 'cleaned_length': 13023}
|
||||
2026-04-01 21:55:32,707 WARNING agent.input_sanitizer: SECURITY: Input blocked - {'event': 'input_sanitization', 'source': 'cron', 'session_id': 'cron_925c78f89f49_20260401_215532', 'risk_level': 'HIGH', 'risk_score': 85, 'blocked': True, 'pattern_count': 8, 'patterns': ['[godmode] stan', '[godmode] stan', '[godmode] stan', '[obfuscation] Security/Performance/Feature/Infrastructure', '[spaced_text] password'], 'original_length': 13301, 'cleaned_length': 13023}
|
||||
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
2147
wizards/allegro/home/sessions/session_20260401_212213_25d535.json
Normal file
2147
wizards/allegro/home/sessions/session_20260401_212213_25d535.json
Normal file
File diff suppressed because one or more lines are too long
@@ -30,16 +30,16 @@
|
||||
"session_key": "agent:main:telegram:dm:7635059073",
|
||||
"session_id": "20260401_124919_d9f5ad7c",
|
||||
"created_at": "2026-04-01T12:49:19.064783",
|
||||
"updated_at": "2026-04-01T21:00:06.791403",
|
||||
"updated_at": "2026-04-01T21:25:27.100638",
|
||||
"display_name": "A W",
|
||||
"platform": "telegram",
|
||||
"chat_type": "dm",
|
||||
"input_tokens": 14422,
|
||||
"output_tokens": 156,
|
||||
"input_tokens": 893660,
|
||||
"output_tokens": 11437,
|
||||
"cache_read_tokens": 0,
|
||||
"cache_write_tokens": 0,
|
||||
"total_tokens": 14578,
|
||||
"last_prompt_tokens": 14422,
|
||||
"total_tokens": 905097,
|
||||
"last_prompt_tokens": 46585,
|
||||
"estimated_cost_usd": 0.0,
|
||||
"cost_status": "unknown",
|
||||
"origin": {
|
||||
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -319,3 +319,15 @@
|
||||
[Wed Apr 1 21:00:05 UTC 2026] No PENDING P0 tasks found
|
||||
[Wed Apr 1 21:00:05 UTC 2026] Pending tasks: 0
|
||||
[Wed Apr 1 21:00:05 UTC 2026] === WORK CYCLE COMPLETE ===
|
||||
[Wed Apr 1 21:20:01 UTC 2026] === ALLEGRO WAKEUP ===
|
||||
[Wed Apr 1 21:20:03 UTC 2026] No PENDING P0 tasks found
|
||||
[Wed Apr 1 21:20:03 UTC 2026] Pending tasks: 0
|
||||
[Wed Apr 1 21:20:03 UTC 2026] === WORK CYCLE COMPLETE ===
|
||||
[Wed Apr 1 21:40:01 UTC 2026] === ALLEGRO WAKEUP ===
|
||||
[Wed Apr 1 21:40:03 UTC 2026] No PENDING P0 tasks found
|
||||
[Wed Apr 1 21:40:04 UTC 2026] Pending tasks: 0
|
||||
[Wed Apr 1 21:40:04 UTC 2026] === WORK CYCLE COMPLETE ===
|
||||
[Wed Apr 1 22:00:01 UTC 2026] === ALLEGRO WAKEUP ===
|
||||
[Wed Apr 1 22:00:05 UTC 2026] No PENDING P0 tasks found
|
||||
[Wed Apr 1 22:00:05 UTC 2026] Pending tasks: 0
|
||||
[Wed Apr 1 22:00:05 UTC 2026] === WORK CYCLE COMPLETE ===
|
||||
|
||||
@@ -675,3 +675,29 @@
|
||||
[Wed Apr 1 21:00:01 UTC 2026] Queue status: 0 pending, 0 active, 9 complete
|
||||
[Wed Apr 1 21:00:01 UTC 2026] Overall progress: 100%
|
||||
[Wed Apr 1 21:00:01 UTC 2026] === MONITOR CHECK COMPLETE ===
|
||||
[Wed Apr 1 21:10:01 UTC 2026] === TASK MONITOR CHECK ===
|
||||
[Wed Apr 1 21:10:01 UTC 2026] Queue status: 0 pending, 0 active, 9 complete
|
||||
[Wed Apr 1 21:10:01 UTC 2026] Overall progress: 100%
|
||||
[Wed Apr 1 21:10:01 UTC 2026] === MONITOR CHECK COMPLETE ===
|
||||
[Wed Apr 1 21:20:01 UTC 2026] === TASK MONITOR CHECK ===
|
||||
[Wed Apr 1 21:20:01 UTC 2026] Queue status: 0 pending, 0 active, 9 complete
|
||||
[Wed Apr 1 21:20:01 UTC 2026] Overall progress: 100%
|
||||
[Wed Apr 1 21:20:01 UTC 2026] === MONITOR CHECK COMPLETE ===
|
||||
[Wed Apr 1 21:30:01 UTC 2026] === TASK MONITOR CHECK ===
|
||||
[Wed Apr 1 21:30:01 UTC 2026] Queue status: 0 pending, 0 active, 9 complete
|
||||
[Wed Apr 1 21:30:01 UTC 2026] Overall progress: 100%
|
||||
[Wed Apr 1 21:30:01 UTC 2026] Progress report written: /root/wizards/allegro/father-messages/progress-20260401-2130.txt
|
||||
[Wed Apr 1 21:30:01 UTC 2026] === MONITOR CHECK COMPLETE ===
|
||||
[Wed Apr 1 21:40:01 UTC 2026] === TASK MONITOR CHECK ===
|
||||
[Wed Apr 1 21:40:01 UTC 2026] Queue status: 0 pending, 0 active, 9 complete
|
||||
[Wed Apr 1 21:40:01 UTC 2026] Overall progress: 100%
|
||||
[Wed Apr 1 21:40:01 UTC 2026] === MONITOR CHECK COMPLETE ===
|
||||
[Wed Apr 1 21:50:01 UTC 2026] === TASK MONITOR CHECK ===
|
||||
[Wed Apr 1 21:50:01 UTC 2026] Queue status: 0 pending, 0 active, 9 complete
|
||||
[Wed Apr 1 21:50:01 UTC 2026] Overall progress: 100%
|
||||
[Wed Apr 1 21:50:01 UTC 2026] === MONITOR CHECK COMPLETE ===
|
||||
[Wed Apr 1 22:00:01 UTC 2026] === TASK MONITOR CHECK ===
|
||||
[Wed Apr 1 22:00:02 UTC 2026] Queue status: 0 pending, 0 active, 9 complete
|
||||
[Wed Apr 1 22:00:02 UTC 2026] Overall progress: 100%
|
||||
[Wed Apr 1 22:00:02 UTC 2026] === MONITOR CHECK COMPLETE ===
|
||||
[Wed Apr 1 22:00:02 UTC 2026] Progress report written: /root/wizards/allegro/father-messages/progress-20260401-2200.txt
|
||||
|
||||
49
wizards/allegro/provider-spike/README.md
Normal file
49
wizards/allegro/provider-spike/README.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# Provider Trait Spike
|
||||
|
||||
2-day proof of concept for Claw Code's Provider trait pattern in Python.
|
||||
|
||||
## Files
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `provider.py` | Abstract Provider trait + Factory |
|
||||
| `kimi_provider.py` | Kimi-coding implementation |
|
||||
| `ollama_provider.py` | Ollama/local implementation |
|
||||
| `mock_provider.py` | Test/mock implementation |
|
||||
| `demo.py` | Integration test/demo |
|
||||
|
||||
## Quick Test
|
||||
|
||||
```bash
|
||||
cd /root/wizards/allegro/provider-spike
|
||||
python3 demo.py
|
||||
```
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
┌─────────────────┐ ┌──────────────────┐
|
||||
│ Application │────▶│ ProviderFactory │
|
||||
└─────────────────┘ └────────┬─────────┘
|
||||
│
|
||||
┌───────────────────────┼───────────────────────┐
|
||||
▼ ▼ ▼
|
||||
┌─────────────────┐ ┌──────────────────┐ ┌──────────────────┐
|
||||
│ KimiProvider │ │ OllamaProvider │ │ MockProvider │
|
||||
│ (cloud API) │ │ (local/offline) │ │ (testing) │
|
||||
└─────────────────┘ └──────────────────┘ └──────────────────┘
|
||||
```
|
||||
|
||||
## Key Design Decisions
|
||||
|
||||
1. **Async-first**: All providers use async/await for non-blocking I/O
|
||||
2. **Factory pattern**: Config-driven provider selection
|
||||
3. **Common interface**: All providers implement `send_message()`, `name`, `max_context`
|
||||
4. **Tool support**: Optional tool calling via `supports_tools` property
|
||||
|
||||
## Next Steps
|
||||
|
||||
- [ ] Tool registry (port from Claw Code)
|
||||
- [ ] PreToolUse/PostToolUse hooks (SOUL enforcement)
|
||||
- [ ] Session compaction
|
||||
- [ ] MCP client integration
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
170
wizards/allegro/provider-spike/demo.py
Normal file
170
wizards/allegro/provider-spike/demo.py
Normal file
@@ -0,0 +1,170 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Provider Trait Spike Demo
|
||||
Tests the Provider abstraction with different backends.
|
||||
"""
|
||||
|
||||
import asyncio
|
||||
import os
|
||||
import sys
|
||||
|
||||
# Add spike directory to path
|
||||
sys.path.insert(0, os.path.dirname(__file__))
|
||||
|
||||
from provider import ProviderFactory, Message, MessageRole
|
||||
from mock_provider import MockProvider # Always available
|
||||
|
||||
# Try to import real providers
|
||||
try:
|
||||
from kimi_provider import KimiProvider
|
||||
KIMI_AVAILABLE = True
|
||||
except ImportError:
|
||||
KIMI_AVAILABLE = False
|
||||
|
||||
try:
|
||||
from ollama_provider import OllamaProvider
|
||||
OLLAMA_AVAILABLE = True
|
||||
except ImportError:
|
||||
OLLAMA_AVAILABLE = False
|
||||
|
||||
|
||||
async def test_mock_provider():
|
||||
"""Test with mock provider (always works)."""
|
||||
print("\n=== MOCK PROVIDER TEST ===")
|
||||
|
||||
provider = ProviderFactory.create("mock", {
|
||||
"responses": ["Hello from mock!", "TOOL:search|{\"query\":\"python\"}"]
|
||||
})
|
||||
|
||||
messages = [
|
||||
Message(role=MessageRole.SYSTEM, content="You are a helpful assistant."),
|
||||
Message(role=MessageRole.USER, content="Say hello")
|
||||
]
|
||||
|
||||
# Test 1: Simple response
|
||||
response = await provider.send_message(messages)
|
||||
print(f"Provider: {provider.name}")
|
||||
print(f"Max context: {provider.max_context}")
|
||||
print(f"Response: {response.content}")
|
||||
print(f"Tool calls: {len(response.tool_calls)}")
|
||||
|
||||
# Test 2: Tool call response
|
||||
messages.append(Message(role=MessageRole.ASSISTANT, content=response.content))
|
||||
messages.append(Message(role=MessageRole.USER, content="Search for python"))
|
||||
|
||||
response2 = await provider.send_message(messages)
|
||||
print(f"\nSecond response:")
|
||||
print(f"Content: {response2.content or '(empty - tool call)'}")
|
||||
for tc in response2.tool_calls:
|
||||
print(f"Tool call: {tc.name}({tc.arguments})")
|
||||
|
||||
return True
|
||||
|
||||
|
||||
async def test_kimi_provider():
|
||||
"""Test with Kimi provider (requires API key)."""
|
||||
if not KIMI_AVAILABLE:
|
||||
print("\n=== KIMI PROVIDER: SKIPPED (not installed) ===")
|
||||
return False
|
||||
|
||||
if not os.environ.get("KIMI_API_KEY"):
|
||||
print("\n=== KIMI PROVIDER: SKIPPED (no API key) ===")
|
||||
return False
|
||||
|
||||
print("\n=== KIMI PROVIDER TEST ===")
|
||||
|
||||
try:
|
||||
provider = ProviderFactory.create("kimi", {"model": "kimi-k2.5"})
|
||||
|
||||
messages = [
|
||||
Message(role=MessageRole.SYSTEM, content="You are Allegro. Be concise."),
|
||||
Message(role=MessageRole.USER, content="Say 'Provider trait working' and nothing else.")
|
||||
]
|
||||
|
||||
response = await provider.send_message(messages, temperature=0.1)
|
||||
print(f"Provider: {provider.name}")
|
||||
print(f"Max context: {provider.max_context}")
|
||||
print(f"Response: {response.content}")
|
||||
print(f"Usage: {response.usage}")
|
||||
return True
|
||||
|
||||
except Exception as e:
|
||||
print(f"Kimi test failed: {e}")
|
||||
return False
|
||||
|
||||
|
||||
async def test_ollama_provider():
|
||||
"""Test with Ollama provider (requires local server)."""
|
||||
if not OLLAMA_AVAILABLE:
|
||||
print("\n=== OLLAMA PROVIDER: SKIPPED (not installed) ===")
|
||||
return False
|
||||
|
||||
print("\n=== OLLAMA PROVIDER TEST ===")
|
||||
|
||||
try:
|
||||
provider = ProviderFactory.create("ollama", {"model": "qwen2.5-coder:14b"})
|
||||
|
||||
messages = [
|
||||
Message(role=MessageRole.SYSTEM, content="You are a coding assistant."),
|
||||
Message(role=MessageRole.USER, content="Write a Python hello world")
|
||||
]
|
||||
|
||||
response = await provider.send_message(messages)
|
||||
print(f"Provider: {provider.name}")
|
||||
print(f"Max context: {provider.max_context}")
|
||||
print(f"Response preview: {response.content[:200]}...")
|
||||
print(f"Usage: {response.usage}")
|
||||
return True
|
||||
|
||||
except Exception as e:
|
||||
print(f"Ollama test failed: {e}")
|
||||
return False
|
||||
|
||||
|
||||
async def test_factory():
|
||||
"""Test provider factory."""
|
||||
print("\n=== PROVIDER FACTORY ===")
|
||||
print(f"Registered providers: {ProviderFactory.list_providers()}")
|
||||
|
||||
# Config-driven provider selection
|
||||
config = {
|
||||
"provider": "mock",
|
||||
"config": {"responses": ["Config-driven response"]}
|
||||
}
|
||||
|
||||
provider = ProviderFactory.create(config["provider"], config["config"])
|
||||
print(f"Created provider from config: {provider.name}")
|
||||
|
||||
|
||||
async def main():
|
||||
"""Run all tests."""
|
||||
print("=" * 50)
|
||||
print("PROVIDER TRAIT SPIKE - DEMO")
|
||||
print("=" * 50)
|
||||
|
||||
results = []
|
||||
|
||||
# Always run mock test
|
||||
results.append(("Mock", await test_mock_provider()))
|
||||
|
||||
# Optional real provider tests
|
||||
results.append(("Kimi", await test_kimi_provider()))
|
||||
results.append(("Ollama", await test_ollama_provider()))
|
||||
|
||||
# Factory test
|
||||
await test_factory()
|
||||
|
||||
# Summary
|
||||
print("\n" + "=" * 50)
|
||||
print("SUMMARY")
|
||||
print("=" * 50)
|
||||
for name, passed in results:
|
||||
status = "✅" if passed else "⏭️"
|
||||
print(f"{status} {name}")
|
||||
|
||||
print("\nProvider trait abstraction working!")
|
||||
print("Next: Add tool registry + hook system")
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
asyncio.run(main())
|
||||
107
wizards/allegro/provider-spike/kimi_provider.py
Normal file
107
wizards/allegro/provider-spike/kimi_provider.py
Normal file
@@ -0,0 +1,107 @@
|
||||
"""
|
||||
Kimi Coding Provider Implementation
|
||||
"""
|
||||
|
||||
import os
|
||||
import json
|
||||
from typing import Dict, List, Any, Optional
|
||||
import aiohttp
|
||||
|
||||
from provider import Provider, Message, MessageRole, ProviderResponse, ToolCall, ProviderFactory
|
||||
|
||||
|
||||
class KimiProvider(Provider):
|
||||
"""
|
||||
Kimi-coding provider using Moonshot AI API.
|
||||
Compatible with OpenAI-compatible endpoints.
|
||||
"""
|
||||
|
||||
API_BASE = "https://api.moonshot.cn/v1"
|
||||
|
||||
def __init__(self, api_key: Optional[str] = None, model: str = "kimi-k2.5"):
|
||||
self.api_key = api_key or os.environ.get("KIMI_API_KEY")
|
||||
self.model = model
|
||||
if not self.api_key:
|
||||
raise ValueError("KIMI_API_KEY required")
|
||||
|
||||
@property
|
||||
def name(self) -> str:
|
||||
return f"kimi-{self.model}"
|
||||
|
||||
@property
|
||||
def max_context(self) -> int:
|
||||
# Kimi k2.5 has 256K context
|
||||
return 256000
|
||||
|
||||
def _convert_messages(self, messages: List[Message]) -> List[Dict]:
|
||||
"""Convert internal Message format to Kimi API format."""
|
||||
converted = []
|
||||
for msg in messages:
|
||||
api_msg = {
|
||||
"role": msg.role.value,
|
||||
"content": msg.content
|
||||
}
|
||||
if msg.tool_calls:
|
||||
api_msg["tool_calls"] = msg.tool_calls
|
||||
if msg.tool_call_id:
|
||||
api_msg["tool_call_id"] = msg.tool_call_id
|
||||
converted.append(api_msg)
|
||||
return converted
|
||||
|
||||
async def send_message(
|
||||
self,
|
||||
messages: List[Message],
|
||||
tools: Optional[List[Dict]] = None,
|
||||
temperature: float = 0.7
|
||||
) -> ProviderResponse:
|
||||
"""Send message to Kimi API."""
|
||||
|
||||
headers = {
|
||||
"Authorization": f"Bearer {self.api_key}",
|
||||
"Content-Type": "application/json"
|
||||
}
|
||||
|
||||
payload = {
|
||||
"model": self.model,
|
||||
"messages": self._convert_messages(messages),
|
||||
"temperature": temperature,
|
||||
"stream": False
|
||||
}
|
||||
|
||||
if tools:
|
||||
payload["tools"] = tools
|
||||
payload["tool_choice"] = "auto"
|
||||
|
||||
async with aiohttp.ClientSession() as session:
|
||||
async with session.post(
|
||||
f"{self.API_BASE}/chat/completions",
|
||||
headers=headers,
|
||||
json=payload
|
||||
) as resp:
|
||||
data = await resp.json()
|
||||
|
||||
if resp.status != 200:
|
||||
raise RuntimeError(f"Kimi API error: {data}")
|
||||
|
||||
choice = data["choices"][0]
|
||||
message = choice["message"]
|
||||
|
||||
# Extract tool calls
|
||||
tool_calls = []
|
||||
if "tool_calls" in message:
|
||||
for tc in message["tool_calls"]:
|
||||
tool_calls.append(ToolCall(
|
||||
id=tc["id"],
|
||||
name=tc["function"]["name"],
|
||||
arguments=json.loads(tc["function"]["arguments"])
|
||||
))
|
||||
|
||||
return ProviderResponse(
|
||||
content=message.get("content", ""),
|
||||
tool_calls=tool_calls,
|
||||
usage=data.get("usage", {"prompt_tokens": 0, "completion_tokens": 0})
|
||||
)
|
||||
|
||||
|
||||
# Register with factory
|
||||
ProviderFactory.register("kimi", KimiProvider)
|
||||
70
wizards/allegro/provider-spike/mock_provider.py
Normal file
70
wizards/allegro/provider-spike/mock_provider.py
Normal file
@@ -0,0 +1,70 @@
|
||||
"""
|
||||
Mock Provider for Testing
|
||||
"""
|
||||
|
||||
from typing import Dict, List, Any, Optional
|
||||
import json
|
||||
|
||||
from provider import Provider, Message, ProviderResponse, ToolCall, ProviderFactory
|
||||
|
||||
|
||||
class MockProvider(Provider):
|
||||
"""
|
||||
Mock provider for CI/testing.
|
||||
Returns predetermined responses.
|
||||
"""
|
||||
|
||||
def __init__(self, responses: Optional[List[str]] = None):
|
||||
self.responses = responses or ["Mock response"]
|
||||
self.call_count = 0
|
||||
self.history: List[Dict] = []
|
||||
|
||||
@property
|
||||
def name(self) -> str:
|
||||
return "mock"
|
||||
|
||||
@property
|
||||
def max_context(self) -> int:
|
||||
return 100000
|
||||
|
||||
async def send_message(
|
||||
self,
|
||||
messages: List[Message],
|
||||
tools: Optional[List[Dict]] = None,
|
||||
temperature: float = 0.7
|
||||
) -> ProviderResponse:
|
||||
"""Return mock response."""
|
||||
|
||||
self.history.append({
|
||||
"messages": [(m.role.value, m.content) for m in messages],
|
||||
"tools": tools,
|
||||
"temperature": temperature
|
||||
})
|
||||
|
||||
response = self.responses[self.call_count % len(self.responses)]
|
||||
self.call_count += 1
|
||||
|
||||
# Check if this should be a tool call
|
||||
tool_calls = []
|
||||
if "TOOL:" in response:
|
||||
# Format: "TOOL:search|{\"query\":\"foo\"}"
|
||||
parts = response.split("|", 1)
|
||||
tool_name = parts[0].replace("TOOL:", "")
|
||||
args = json.loads(parts[1]) if len(parts) > 1 else {}
|
||||
|
||||
tool_calls.append(ToolCall(
|
||||
id=f"mock-{self.call_count}",
|
||||
name=tool_name,
|
||||
arguments=args
|
||||
))
|
||||
response = ""
|
||||
|
||||
return ProviderResponse(
|
||||
content=response,
|
||||
tool_calls=tool_calls,
|
||||
usage={"prompt_tokens": 100, "completion_tokens": 50}
|
||||
)
|
||||
|
||||
|
||||
# Register with factory
|
||||
ProviderFactory.register("mock", MockProvider)
|
||||
107
wizards/allegro/provider-spike/ollama_provider.py
Normal file
107
wizards/allegro/provider-spike/ollama_provider.py
Normal file
@@ -0,0 +1,107 @@
|
||||
"""
|
||||
Ollama Provider Implementation
|
||||
For local/offline LLM inference
|
||||
"""
|
||||
|
||||
import os
|
||||
import json
|
||||
from typing import Dict, List, Any, Optional
|
||||
import aiohttp
|
||||
|
||||
from provider import Provider, Message, MessageRole, ProviderResponse, ToolCall, ProviderFactory
|
||||
|
||||
|
||||
class OllamaProvider(Provider):
|
||||
"""
|
||||
Ollama provider for local model inference.
|
||||
Supports tool calling via structured output.
|
||||
"""
|
||||
|
||||
def __init__(self, host: str = "http://localhost:11434", model: str = "qwen2.5-coder:14b"):
|
||||
self.host = host or os.environ.get("OLLAMA_HOST", "http://localhost:11434")
|
||||
self.model = model
|
||||
|
||||
@property
|
||||
def name(self) -> str:
|
||||
return f"ollama-{self.model}"
|
||||
|
||||
@property
|
||||
def max_context(self) -> int:
|
||||
# Varies by model, using conservative default
|
||||
return 32768
|
||||
|
||||
@property
|
||||
def supports_tools(self) -> bool:
|
||||
# Ollama has experimental tool support
|
||||
return False # Conservative for now
|
||||
|
||||
def _convert_messages(self, messages: List[Message]) -> List[Dict]:
|
||||
"""Convert to Ollama format."""
|
||||
converted = []
|
||||
for msg in messages:
|
||||
converted.append({
|
||||
"role": msg.role.value,
|
||||
"content": msg.content
|
||||
})
|
||||
return converted
|
||||
|
||||
async def send_message(
|
||||
self,
|
||||
messages: List[Message],
|
||||
tools: Optional[List[Dict]] = None,
|
||||
temperature: float = 0.7
|
||||
) -> ProviderResponse:
|
||||
"""Send message to Ollama API."""
|
||||
|
||||
payload = {
|
||||
"model": self.model,
|
||||
"messages": self._convert_messages(messages),
|
||||
"stream": False,
|
||||
"options": {
|
||||
"temperature": temperature
|
||||
}
|
||||
}
|
||||
|
||||
# Ollama tool format differs slightly
|
||||
if tools and self.supports_tools:
|
||||
payload["tools"] = tools
|
||||
|
||||
async with aiohttp.ClientSession() as session:
|
||||
async with session.post(
|
||||
f"{self.host}/api/chat",
|
||||
json=payload
|
||||
) as resp:
|
||||
data = await resp.json()
|
||||
|
||||
message = data["message"]
|
||||
|
||||
# Check for tool calls in content (Ollama may embed as JSON)
|
||||
tool_calls = []
|
||||
content = message.get("content", "")
|
||||
|
||||
# Simple heuristic: if content looks like JSON tool call, parse it
|
||||
if content.strip().startswith("{") and "tool" in content.lower():
|
||||
try:
|
||||
parsed = json.loads(content)
|
||||
if "tool" in parsed:
|
||||
tool_calls.append(ToolCall(
|
||||
id=f"ollama-{hash(content) % 10000}",
|
||||
name=parsed["tool"],
|
||||
arguments=parsed.get("arguments", {})
|
||||
))
|
||||
content = parsed.get("reasoning", "")
|
||||
except json.JSONDecodeError:
|
||||
pass
|
||||
|
||||
return ProviderResponse(
|
||||
content=content,
|
||||
tool_calls=tool_calls,
|
||||
usage={
|
||||
"prompt_tokens": data.get("prompt_eval_count", 0),
|
||||
"completion_tokens": data.get("eval_count", 0)
|
||||
}
|
||||
)
|
||||
|
||||
|
||||
# Register with factory
|
||||
ProviderFactory.register("ollama", OllamaProvider)
|
||||
96
wizards/allegro/provider-spike/provider.py
Normal file
96
wizards/allegro/provider-spike/provider.py
Normal file
@@ -0,0 +1,96 @@
|
||||
"""
|
||||
Provider Trait Spike - Python PoC
|
||||
Based on Claw Code's Provider trait pattern
|
||||
"""
|
||||
|
||||
from abc import ABC, abstractmethod
|
||||
from typing import Dict, List, Any, AsyncIterator, Optional
|
||||
from dataclasses import dataclass
|
||||
from enum import Enum
|
||||
import json
|
||||
|
||||
|
||||
class MessageRole(Enum):
|
||||
SYSTEM = "system"
|
||||
USER = "user"
|
||||
ASSISTANT = "assistant"
|
||||
TOOL = "tool"
|
||||
|
||||
|
||||
@dataclass
|
||||
class Message:
|
||||
role: MessageRole
|
||||
content: str
|
||||
tool_calls: Optional[List[Dict]] = None
|
||||
tool_call_id: Optional[str] = None
|
||||
|
||||
|
||||
@dataclass
|
||||
class ToolCall:
|
||||
id: str
|
||||
name: str
|
||||
arguments: Dict[str, Any]
|
||||
|
||||
|
||||
@dataclass
|
||||
class ProviderResponse:
|
||||
content: str
|
||||
tool_calls: List[ToolCall]
|
||||
usage: Dict[str, int] # prompt_tokens, completion_tokens
|
||||
|
||||
|
||||
class Provider(ABC):
|
||||
"""
|
||||
Abstract base for LLM providers.
|
||||
Mirrors Claw Code's Provider trait:
|
||||
- send_message: Main interaction point
|
||||
- supports_tools: Capability check
|
||||
- max_context: Context window size
|
||||
"""
|
||||
|
||||
@abstractmethod
|
||||
async def send_message(
|
||||
self,
|
||||
messages: List[Message],
|
||||
tools: Optional[List[Dict]] = None,
|
||||
temperature: float = 0.7
|
||||
) -> ProviderResponse:
|
||||
"""Send messages to LLM, return response with optional tool calls."""
|
||||
pass
|
||||
|
||||
@property
|
||||
@abstractmethod
|
||||
def name(self) -> str:
|
||||
"""Provider identifier."""
|
||||
pass
|
||||
|
||||
@property
|
||||
@abstractmethod
|
||||
def max_context(self) -> int:
|
||||
"""Maximum context window in tokens."""
|
||||
pass
|
||||
|
||||
@property
|
||||
def supports_tools(self) -> bool:
|
||||
"""Whether this provider supports function calling."""
|
||||
return True
|
||||
|
||||
|
||||
class ProviderFactory:
|
||||
"""Factory for creating provider instances."""
|
||||
|
||||
_registry: Dict[str, type] = {}
|
||||
|
||||
@classmethod
|
||||
def register(cls, name: str, provider_class: type):
|
||||
cls._registry[name] = provider_class
|
||||
|
||||
@classmethod
|
||||
def create(cls, name: str, config: Dict[str, Any]) -> Provider:
|
||||
if name not in cls._registry:
|
||||
raise ValueError(f"Unknown provider: {name}. Registered: {list(cls._registry.keys())}")
|
||||
return cls._registry[name](**config)
|
||||
|
||||
@classmethod
|
||||
def list_providers(cls) -> List[str]:
|
||||
return list(cls._registry.keys())
|
||||
Reference in New Issue
Block a user