Rockachopa/Timmy-time-dashboard
1
0
Fork 2
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

[arch] Decision: Monorepo with packages vs multi-repo #170

New Issue
Closed
opened 2026-03-15 15:37:46 +00:00 by hermes · 1 comment
hermes commented 2026-03-15 15:37:46 +00:00
Collaborator
Copy Link

Question

Should we use:
A) Multi-repo — separate Gitea repos for each package (timmy-core, timmy-dashboard, timmy-spark, timmy-infra, timmy-config)
B) Monorepo with packages — one repo, multiple Python packages under packages/ with separate pyproject.toml each
C) Hybrid — monorepo for core + infra, separate repos for dashboard and spark

Trade-offs

Multi-repo

  • Kimi can work on one repo without scanning others (the original motivation)
  • Independent CI per repo
  • Clear ownership boundaries
  • Dependency management overhead (version pinning, release coordination)
  • Cross-repo changes are painful
  • Need a way to develop locally across repos

Monorepo with packages

  • Single git clone, single CI
  • Cross-package changes are atomic
  • Simpler local development
  • Kimi still sees everything (unless we use --add-dir to scope)
  • Larger single repo over time

Hybrid

  • Best of both — tightly coupled things together, independent things separate
  • Dashboard and Spark genuinely are independent deployments
  • Still need to manage some cross-repo deps

Recommendation

TBD — discuss with Alexander before proceeding.

## Question Should we use: A) **Multi-repo** — separate Gitea repos for each package (timmy-core, timmy-dashboard, timmy-spark, timmy-infra, timmy-config) B) **Monorepo with packages** — one repo, multiple Python packages under packages/ with separate pyproject.toml each C) **Hybrid** — monorepo for core + infra, separate repos for dashboard and spark ## Trade-offs ### Multi-repo + Kimi can work on one repo without scanning others (the original motivation) + Independent CI per repo + Clear ownership boundaries - Dependency management overhead (version pinning, release coordination) - Cross-repo changes are painful - Need a way to develop locally across repos ### Monorepo with packages + Single git clone, single CI + Cross-package changes are atomic + Simpler local development - Kimi still sees everything (unless we use --add-dir to scope) - Larger single repo over time ### Hybrid + Best of both — tightly coupled things together, independent things separate + Dashboard and Spark genuinely are independent deployments - Still need to manage some cross-repo deps ## Recommendation TBD — discuss with Alexander before proceeding.
hermes commented 2026-03-15 16:01:04 +00:00
Author
Collaborator
Copy Link

Decision: Multi-repo. Each package is its own service.

Alexander direction: no monorepo. Each app stands on its own, deployable independently.

Final repo structure:

  • timmy-core — the agent
  • timmy-dashboard — FastAPI web UI
  • timmy-spark — cognitive/learning loop
  • timmy-infra — shared plumbing (router, events, models)
  • timmy-config — shared settings

Cross-service communication via event bus and HTTP APIs, not direct imports.

**Decision: Multi-repo. Each package is its own service.** Alexander direction: no monorepo. Each app stands on its own, deployable independently. Final repo structure: - `timmy-core` — the agent - `timmy-dashboard` — FastAPI web UI - `timmy-spark` — cognitive/learning loop - `timmy-infra` — shared plumbing (router, events, models) - `timmy-config` — shared settings Cross-service communication via event bus and HTTP APIs, not direct imports.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
222-epic
Workshop: Timmy as Presence (Epic #222)
 actionable
Has a concrete code/config task extracted
 assigned-claude
Issue currently assigned to Claude agent — do not assign to another agent
 assigned-gemini
Issue currently assigned to Gemini agent — do not assign to another agent
 assigned-groq
assigned-kimi
Issue currently assigned to Kimi agent — do not assign to another agent
 assigned-manus
Issue currently assigned to Manus agent — do not assign to another agent
 claude-ready
consolidation
Part of a consolidation epic
 deprioritized
Keep open but not blocking P0 work
 deprioritized
Keep open but not blocking P0 work
 duplicate
Duplicate of another issue
 gemini-review
Auto-generated by Gemini, needs relevance review
 groq-ready
harness
Core product: agent framework, heartbeat, inference, memory
 heartbeat
Harness: Agent heartbeat loop
 inference
Harness: Inference and model routing
 infrastructure
Supporting stage: dashboard, CI/CD, deployment, DNS
 kimi-ready
Scoped and ready for Kimi to pick up
 memory-session
Harness: Memory and session crystallization
 morrowind
Harness: Morrowind embodiment
 needs-design
Needs architectural design before implementation
 needs-extraction
Philosophy with unextracted engineering work
 p0-critical
Priority 0: Must fix now
 p1-important
Priority 1: Important, next sprint
 p2-backlog
Priority 2: Backlog, do when time permits
 philosophy
Philosophical foundation — informs architecture decisions
 rejected-direction
Closed: rejected or superseded direction
 seed:know-purpose
Three Seeds: KNOW YOUR PURPOSE
 seed:serve-real
Three Seeds: SERVE THE REAL
 seed:tell-truth
Three Seeds: TELL THE TRUTH
 sovereignty
Harness: Sovereignty stack
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Timmy claude grok groq kimi manus perplexity Rockachopa
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Rockachopa/Timmy-time-dashboard#170
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?