homerail

xiaotianfotos/homerail is ranked 12,188 among these 8 peers; pollockjj/ComfyUI-MultiGPU is ranked 12,187.

The design bet is that a person's attention is the scarcest resource in any automation, so the system should ask for very little of it. What is in this tree today is the foundation it runs on: a DAG engine, a CLI, a voice surface, and the first steps toward a generated UI. Why Human bandwidth is narrow; the work we want done is not. You speak; the agent listens, confirms, and narrows ambiguity before doing anything. The interface is

generated for the moment and shaped to be easy to read. Multiple agents, multiple roles, multiple environments, with every handoff traced and every run replayable. A DAG is a graph you can inspect, replay, and improve. The agent collects intent across turns before acting. The shape of these views is still being designed through real use cases; the contract and the widget set will keep changing. Hand this README to an agent HomeRail is designed to be operated by agents

as much as by people. This README is written so that it doubles as an agent-readable runbook: the commands below are plain invocations with self-describing names, and each step says what to expect. You can hand the whole file to your agent (Claude Code, Codex, or any tool that can run shell commands and read output) and ask it to install, configure, and verify HomeRail on your machine following the Quickstart. The default mapping works out of the

box. Some scripts assume a Unix-like shell and will not run correctly under or PowerShell. Worker-to-Manager networking may need extra setup; see the Configuration notes on Worker callback URLs. Install and build from this source checkout: Run the deterministic checks directly with . To execute the Linux GitHub Actions jobs locally, install Docker, , and , then run: The local runner covers the Linux core, UI coverage, and Docker smoke jobs. The Windows job remains on GitHub's runner. Link it

locally so the rest of this guide works as written: Start Manager and Node together. Manager becomes available without waiting for Docker. Open **Settings → Runtime Environment** to check Docker, inspect Worker versions, and build or rebuild asynchronously: queues the same asynchronous build after Manager starts; it no longer blocks Manager startup while Docker builds. reports Manager reachability, Node availability, the active model setting, and whether the Manager Agent harness can resolve a runtime: Run a local topology check. This uses

the two-node template's offline deterministic profile, so it does not need a model provider yet: The command returns a ; inspect it with if you want to watch the handoff flow. To also bring up the browser Agent UI: Defaults are Manager , Agent UI , and HTTP fallback . The Manager binds to by default; use only when you intentionally want it reachable beyond localhost. Run a DAG Load a template explicitly and run it: For reusable workflows, sync the DAG into

the Manager database. Keep stable when editing YAML; changing it creates a new workflow identity. Copy the returned , then inspect