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

[loop-generated] [refactor] Split infrastructure/hermes/monitor.py — 660 lines, system monitoring #1370

New Issue
Closed
opened 2026-03-24 10:08:48 +00:00 by Timmy · 2 comments
Timmy commented 2026-03-24 10:08:48 +00:00
Owner
Copy Link

Priority: High
Impact: System reliability, monitoring clarity
Size: 660 lines

Problem

src/infrastructure/hermes/monitor.py is a monolithic 660-line system monitor that handles multiple concerns:

  • Memory pressure monitoring
  • Disk usage tracking
  • Ollama status checks
  • Process health monitoring
  • Network connectivity
  • Alert management

Proposed Split

src/infrastructure/hermes/monitoring/
├── __init__.py         # Main monitor orchestrator
├── memory.py          # Memory pressure monitoring
├── disk.py            # Disk usage tracking
├── ollama.py          # Ollama service monitoring
├── processes.py       # Process health checks
├── network.py         # Network connectivity
└── alerts.py          # Alert management system

Acceptance Criteria

  • Split into 6-7 focused modules
  • Maintain exact same monitoring functionality
  • All existing tests pass
  • Clear separation of monitoring concerns
  • Proper error handling in each module

Files to Modify

  • src/infrastructure/hermes/monitor.py → src/infrastructure/hermes/monitoring/__init__.py
  • Create new monitoring modules as outlined
  • Update imports in dependent files

Estimated effort: 3-4 hours

**Priority**: High **Impact**: System reliability, monitoring clarity **Size**: 660 lines ## Problem `src/infrastructure/hermes/monitor.py` is a monolithic 660-line system monitor that handles multiple concerns: - Memory pressure monitoring - Disk usage tracking - Ollama status checks - Process health monitoring - Network connectivity - Alert management ## Proposed Split ``` src/infrastructure/hermes/monitoring/ ├── __init__.py # Main monitor orchestrator ├── memory.py # Memory pressure monitoring ├── disk.py # Disk usage tracking ├── ollama.py # Ollama service monitoring ├── processes.py # Process health checks ├── network.py # Network connectivity └── alerts.py # Alert management system ``` ## Acceptance Criteria - [ ] Split into 6-7 focused modules - [ ] Maintain exact same monitoring functionality - [ ] All existing tests pass - [ ] Clear separation of monitoring concerns - [ ] Proper error handling in each module ## Files to Modify - `src/infrastructure/hermes/monitor.py` → `src/infrastructure/hermes/monitoring/__init__.py` - Create new monitoring modules as outlined - Update imports in dependent files Estimated effort: 3-4 hours
Timmy commented 2026-03-24 10:21:29 +00:00
Author
Owner
Copy Link

Kimi Task Instructions

Files to work with:

  • src/infrastructure/hermes/monitor.py (660 lines - split this)
  • Create new files:
    • src/infrastructure/hermes/monitor/__init__.py
    • src/infrastructure/hermes/monitor/system.py (SystemMonitor class)
    • src/infrastructure/hermes/monitor/memory.py (MemoryPressure, memory checks)
    • src/infrastructure/hermes/monitor/disk.py (DiskUsage, disk checks)
    • src/infrastructure/hermes/monitor/ollama.py (Ollama health checks)

Refactor approach:

  1. Create monitor/ package directory
  2. Extract MemoryPressure class → memory.py
  3. Extract DiskUsage class → disk.py
  4. Extract Ollama health methods → ollama.py
  5. Keep main SystemMonitor class in system.py
  6. Update __init__.py to expose public API
  7. Update all imports throughout codebase

Import compatibility:
Ensure these imports still work after refactor:

from infrastructure.hermes.monitor import SystemMonitor
from infrastructure.hermes.monitor import MemoryPressure, DiskUsage

How to verify:

  1. tox -e unit - all tests must still pass
  2. tox -e lint - no import errors
  3. Check that existing monitor usage isn't broken

Split guidelines:

  • Each new file should be 100-200 lines max
  • Keep related functionality together (memory pressure + memory checks)
  • Maintain clean interfaces between modules
  • No circular imports

This improves maintainability and testability of critical system monitoring code.

## Kimi Task Instructions **Files to work with:** - `src/infrastructure/hermes/monitor.py` (660 lines - split this) - Create new files: - `src/infrastructure/hermes/monitor/__init__.py` - `src/infrastructure/hermes/monitor/system.py` (SystemMonitor class) - `src/infrastructure/hermes/monitor/memory.py` (MemoryPressure, memory checks) - `src/infrastructure/hermes/monitor/disk.py` (DiskUsage, disk checks) - `src/infrastructure/hermes/monitor/ollama.py` (Ollama health checks) **Refactor approach:** 1. Create monitor/ package directory 2. Extract `MemoryPressure` class → `memory.py` 3. Extract `DiskUsage` class → `disk.py` 4. Extract Ollama health methods → `ollama.py` 5. Keep main `SystemMonitor` class in `system.py` 6. Update `__init__.py` to expose public API 7. Update all imports throughout codebase **Import compatibility:** Ensure these imports still work after refactor: ```python from infrastructure.hermes.monitor import SystemMonitor from infrastructure.hermes.monitor import MemoryPressure, DiskUsage ``` **How to verify:** 1. `tox -e unit` - all tests must still pass 2. `tox -e lint` - no import errors 3. Check that existing monitor usage isn't broken **Split guidelines:** - Each new file should be 100-200 lines max - Keep related functionality together (memory pressure + memory checks) - Maintain clean interfaces between modules - No circular imports This improves maintainability and testability of critical system monitoring code.
kimi was assigned by Timmy 2026-03-24 10:21:29 +00:00
kimi was unassigned by Timmy 2026-03-24 19:18:22 +00:00
Timmy commented 2026-03-24 20:08:54 +00:00
Author
Owner
Copy Link

[triage] Duplicate of #1453 (split monitor.py). Closing to reduce queue noise.

[triage] Duplicate of #1453 (split monitor.py). Closing to reduce queue noise.
Timmy closed this issue 2026-03-24 20:08:55 +00:00
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#1370
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?