Timmy_Foundation/timmy-config
16
0
Fork 0
Code Issues 57 Pull Requests 1 Actions 1 Packages Projects Releases Wiki Activity

[EPIC][ARCH] Steal the gold from POI Command into Timmy ops #154

New Issue
Closed
opened 2026-04-04 21:09:20 +00:00 by Timmy · 4 comments
Timmy commented 2026-04-04 21:09:20 +00:00
Owner
Copy Link

Source

Distilled from: ~/Downloads/poi-system-overview.md

What is worth stealing

This document is not valuable because of its business-specific stack. It is valuable because it shows a coherent coordinator-first ops architecture with:

  • per-agent fallback chains
  • local-first model selection by task class
  • a single coordinator doing intake → triage → route → verify → report
  • hub-and-spoke IPC to avoid cascade failures
  • files-backed continuity and daily memory flush before compaction
  • a Tailscale-gated operator command center

World-state correction

We should not clone POI Command wholesale.
Timmy already has stronger doctrine, operator alignment, review discipline, and standing authorities.
The gold here is plumbing and operating shape, not the entire philosophy.

Decision

Adopt the transferable architecture patterns from POI Command into the Timmy sidecar stack, but translate them into Timmy world-state:

  • keep Gitea as visible execution truth
  • keep Timmy doctrine and principal-facing review gates
  • replace hidden queue mutation with explicit coordinator authority
  • prefer local-first routing and degraded usefulness over dead silence

Non-goals

  • Do not import POI’s business-specific integrations (WooCommerce, Firefly, etc.)
  • Do not make Telegram topic binding a hard architectural dependency
  • Do not replace Timmy doctrine with Frankie’s doctrine
  • Do not regress to file-only team coordination as shared truth

Child tracks

Child issues created under this epic will cover:

  • per-agent fallback portfolios and task-class routing
  • coordinator-first intake/triage/verify/report doctrine
  • hub-and-spoke agent IPC semantics
  • file-backed continuity and pre-compaction memory flush
  • Tailscale-only command center requirements

Acceptance Criteria

  • Child issues exist for each transferable pattern worth implementing
  • Each child issue has explicit acceptance criteria
  • The epic makes clear what we are stealing and what we are refusing
  • Follow-on implementation can proceed without re-litigating the document
## Source Distilled from: `~/Downloads/poi-system-overview.md` ## What is worth stealing This document is not valuable because of its business-specific stack. It is valuable because it shows a coherent coordinator-first ops architecture with: - per-agent fallback chains - local-first model selection by task class - a single coordinator doing intake → triage → route → verify → report - hub-and-spoke IPC to avoid cascade failures - files-backed continuity and daily memory flush before compaction - a Tailscale-gated operator command center ## World-state correction We should not clone POI Command wholesale. Timmy already has stronger doctrine, operator alignment, review discipline, and standing authorities. The gold here is plumbing and operating shape, not the entire philosophy. ## Decision Adopt the transferable architecture patterns from POI Command into the Timmy sidecar stack, but translate them into Timmy world-state: - keep Gitea as visible execution truth - keep Timmy doctrine and principal-facing review gates - replace hidden queue mutation with explicit coordinator authority - prefer local-first routing and degraded usefulness over dead silence ## Non-goals - Do not import POI’s business-specific integrations (WooCommerce, Firefly, etc.) - Do not make Telegram topic binding a hard architectural dependency - Do not replace Timmy doctrine with Frankie’s doctrine - Do not regress to file-only team coordination as shared truth ## Child tracks Child issues created under this epic will cover: - per-agent fallback portfolios and task-class routing - coordinator-first intake/triage/verify/report doctrine - hub-and-spoke agent IPC semantics - file-backed continuity and pre-compaction memory flush - Tailscale-only command center requirements ## Acceptance Criteria - [ ] Child issues exist for each transferable pattern worth implementing - [ ] Each child issue has explicit acceptance criteria - [ ] The epic makes clear what we are stealing and what we are refusing - [ ] Follow-on implementation can proceed without re-litigating the document
Timmy commented 2026-04-04 21:09:22 +00:00
Author
Owner
Copy Link

Child issues created:

  • #155 [RESILIENCE] Per-agent fallback portfolios and task-class routing
  • #156 [OPS] Coordinator-first intake, triage, verification, and report protocol
  • #157 [IPC] Hub-and-spoke agent communication semantics over sovereign transport
  • #158 [MEMORY] File-backed continuity and pre-compaction memory flush
  • #159 [CONTROL SURFACE] Tailscale-only operator command center requirements
Child issues created: - #155 [RESILIENCE] Per-agent fallback portfolios and task-class routing - #156 [OPS] Coordinator-first intake, triage, verification, and report protocol - #157 [IPC] Hub-and-spoke agent communication semantics over sovereign transport - #158 [MEMORY] File-backed continuity and pre-compaction memory flush - #159 [CONTROL SURFACE] Tailscale-only operator command center requirements
Timmy commented 2026-04-04 21:14:28 +00:00
Author
Owner
Copy Link

Dispatch plan:

  • #155 fallback portfolios → allegro
  • #156 coordinator protocol → Timmy
  • #157 hub-and-spoke IPC semantics → perplexity
  • #158 memory flush / continuity → ezra
  • #159 operator command center requirements → codex-agent

Timmy is launching parallel implementation runs now from clean origin/main worktrees. PRs will be linked back into each child issue as they open.

Dispatch plan: - #155 fallback portfolios → allegro - #156 coordinator protocol → Timmy - #157 hub-and-spoke IPC semantics → perplexity - #158 memory flush / continuity → ezra - #159 operator command center requirements → codex-agent Timmy is launching parallel implementation runs now from clean `origin/main` worktrees. PRs will be linked back into each child issue as they open.
Timmy commented 2026-04-04 21:34:46 +00:00
Author
Owner
Copy Link

Delegated implementation results:

Delegated implementation results: - Issue #155 -> PR #170 http://143.198.27.163:3000/Timmy_Foundation/timmy-config/pulls/170 - Issue #156 -> PR #161 http://143.198.27.163:3000/Timmy_Foundation/timmy-config/pulls/161 - Issue #157 -> PR #160 http://143.198.27.163:3000/Timmy_Foundation/timmy-config/pulls/160 - Issue #158 -> PR #171 http://143.198.27.163:3000/Timmy_Foundation/timmy-config/pulls/171 - Issue #159 -> PR #172 http://143.198.27.163:3000/Timmy_Foundation/timmy-config/pulls/172
Timmy commented 2026-04-04 21:42:58 +00:00
Author
Owner
Copy Link

Roll-up: delegated implementation complete.

Merged PRs:

  • #170 fallback portfolios and routing doctrine
  • #161 coordinator-first protocol doctrine
  • #160 hub-and-spoke IPC doctrine
  • #171 memory continuity and pre-compaction flush doctrine
  • #172 Tailscale-only operator command center requirements

Net result:

  • the transferable gold from POI Command is now captured in repo-visible doctrine
  • the work is merged into timmy-config main
  • the child issues are closed with visible artifacts and PR history

This epic can close. Follow-on work should continue from the merged child deliverables, especially the resilience/fallback portfolio track.

Roll-up: delegated implementation complete. Merged PRs: - #170 fallback portfolios and routing doctrine - #161 coordinator-first protocol doctrine - #160 hub-and-spoke IPC doctrine - #171 memory continuity and pre-compaction flush doctrine - #172 Tailscale-only operator command center requirements Net result: - the transferable gold from POI Command is now captured in repo-visible doctrine - the work is merged into `timmy-config` main - the child issues are closed with visible artifacts and PR history This epic can close. Follow-on work should continue from the merged child deliverables, especially the resilience/fallback portfolio track.
Timmy closed this issue 2026-04-04 21:42:58 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
assigned-claw-code
Queued for Code Claw (qwen/openrouter)
 assigned-kimi
Dispatched to Kimi via OpenClaw
 claw-code-done
Code Claw completed this task
 claw-code-in-progress
Code Claw is actively working
 enhancement
epic
kimi-done
Kimi completed this task
 kimi-in-progress
Kimi is actively working on this
 research
velocity-engine
Auto-generated by velocity engine
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
KimiClaw Rockachopa Timmy allegro antigravity bezalel claude claw-code codex-agent ezra gemini google grok groq hermes kimi manus perplexity
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Timmy_Foundation/timmy-config#154
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?