hermes-portable-rescue/TASK-GRAPH.md

Hermes Portable Rescue — Task Graph

This is the decomposition of the Hermes Portable Rescue project. The board is active at hermes-portable-rescue.

Phase 1: Foundation

research:boot-env  ──┐
                     ├── workstream:arch-decision
research:llm-strat ──┘

Phase 2: Core Agent Build

research:arch-decision ──> build:hermes-runtime ──> build:hardware-inventory

Phase 3: Diagnostic Modules (parallel after hardware-inventory)

build:hardware-inventory ─┬──> build:bsod-analyzer
                          ├──> build:driver-updater
                          ├──> build:backup-restore
                          └──> build:stress-tests

Phase 4: Integration & Polish

build:bsod-analyzer   ──┐
build:driver-updater  ──┤
build:backup-restore  ──┤──> build:usb-image
build:stress-tests    ──┘

build:usb-image ──> test:real-hardware

test:real-hardware ──> fix:issues (may loop)

Task Descriptions

T1 — research:boot-env [research profile]

What boots? Evaluate WinPE vs Linux live (Alpine/Arch) vs hybrid Ventoy approach for hosting a portable Python + Hermes agent. Key questions: Can Hermes run in WinPE? What's the minimum Linux live environment? What about driver support for NTFS access? Deliverable: comparison matrix in research/boot-env.md.

T2 — research:llm-strat [research profile]

How does the agent think? Options: local GGUF model on the USB (4-bit quantized ~4GB), API-based (needs network), or hybrid (local for diagnosis, API for complex reasoning). Evaluate memory constraints, speed, offline capability. Deliverable: recommendation in research/llm-strategy.md.

T3 — workstream:arch-decision [kanban/orchestrator]

Synthesize T1+T2 findings into a concrete architecture document. Define: boot env, LLM stack, USB filesystem layout, tool packaging, auto-launch flow. Deliverable: docs/architecture.md.

T4 — build:hermes-runtime [coder profile]

Build the portable Hermes agent package for USB. Includes: minimal Python venv, Hermes core, diagnostic tool collection, auto-launch script, config. Deliverable: src/ with build scripts.

T5 — build:hardware-inventory [coder profile]

Hardware enumeration and health checks: CPU model/speed, RAM capacity/slots, GPU model/VRAM, disk SMART health. Wraps smartmontools, dmidecode, lshw. Deliverable: src/diagnostics/hardware.py.

T6 — build:bsod-analyzer [coder profile]

Parse Windows minidump files, extract stop codes and parameters, feed to LLM for interpretation, correlate with known fixes. Deliverable: src/diagnostics/bsod.py.

T7 — build:driver-updater [coder profile]

Hardware ID inventory → vendor API or database lookup → find latest driver → guided download/install. Deliverable: src/diagnostics/drivers.py.

T8 — build:backup-restore [coder profile]

Disk imaging (DD/Clonezilla orchestration), file-level backup, restore with LLM-guided workflow. Deliverable: src/diagnostics/backup.py.

T9 — build:stress-tests [coder profile]

RAM (MemTest86+ execution/report parsing), CPU (stress-ng), GPU (basic stress/info). Deliverable: src/diagnostics/stress.py.

T10 — build:usb-image [coder profile]

Assemble the final USB image: combine boot env + Hermes runtime + all tools. Build script, Ventoy config, ISO generation. Deliverable: build/usb-image.sh.

T11 — test:real-hardware [kanban/orchestrator]

Test on Shawn's gaming PC and other Windows machines. BSOD injection, simulated drive failures, RAM errors. Bug reports → fix loop.

T12 — research:windows-pc-repair-workflows [research profile]

Research common Windows PC repair workflows and how to automate them with the agent. What are the most common BSODs? What repair sequences do techs follow? Common failure patterns for gaming vs business PCs.