LOADING...
◉ In development · Architecture consolidation
Personal Automation Infrastructure · Chapter 02
ForgeCommand
A local-first command and orchestration platform for personal automation, AI services, and connected systems.
Current build · v0.4.1
Windows-Native Interface
A working desktop shell for bringing operational modules into one consistent interface.
Dashboard overview
The current PyQt desktop baseline provides shared navigation, project context, operational summaries, system state, and access to the application modules. Empty values reflect a clean local session rather than seeded demonstration data.
NodeOne asked
Can I build an intelligent automation node?
ForgeCommand asks
How do I safely connect AI, automation, home systems, computing resources, and human decision-making through one interface?
From Agent Runtime to Orchestration Layer
ForgeCommand continues the engineering work begun in NodeOne. As capable agent runtimes and home-control platforms matured, duplicating each underlying system stopped being the useful problem to solve. The project was redirected toward the boundaries between them: a common interface, dependable service architecture, explicit permissions, and traceable execution.
It is not intended to be a monolithic program that performs every task itself. ForgeCommand is the orchestration and human-interface layer: AI may propose an action, while deterministic policy and the operator retain authority to approve and execute it.
System Direction
Multiple interfaces connect to the same Core; specialist platforms and edge devices keep the responsibilities they are best suited to.
Desktop UI
Remote HMI / Web
Physical HMI
ForgeCommand Core · policy · permissions · audit trail
AI
Home Assistant
Services
Trading
Cloud / local models
ESP32 edge nodes
External integrations
Development Record
Current stage: architecture consolidation and a Windows-native baseline. The status below separates working foundations from planned work.
Working
Existing foundations
- PyQt application framework and modular application tabs
- Provider-neutral market data cache and a local PaperBroker domain
- Backend abstractions and an established testing framework
- Windows-native operation after removing the WSL dependency
Now
In development
- PaperBroker order lifecycle, risk-policy coverage, and interface integration
- Core-service separation from the desktop interface
- Clear classification of live, partially wired, simulated, and future modules
- Home Assistant and remote HMI integration architecture
Later
Future direction
- Physical wall-mounted HMI and private mobile/web interfaces
- Distributed ESP32 sensor and control nodes
- Optional local AI compute and provider-independent model access
- Workshop, home, energy, calendar, task, and infrastructure integrations
Development update · 20 August 2026
Trading Becomes an Integrated Paper Workflow
Market data
AAPL hourly bars arrive through a provider-neutral Twelve Data adapter and durable local cache.
PaperBroker
A deliberately created local account now owns its own cash, positions, orders, fills, and audit state.
Controlled preview
Buy and sell previews pass through deterministic checks before an explicit confirmation can change the paper ledger.
Offline-safe AI
When AI services are unavailable, the assistant says so and leaves local read-only tools usable.
This is a development snapshot, not evidence of trading performance. The broker is disconnected, the account is paper-only, and the empty positions and orders are genuine current state rather than seeded results.
Interface Modules
These screens document the current application structure. They show implemented interface foundations, not a claim that every underlying service or hardware integration is live.
Task orchestration
A persistent workflow surface organised around explicit task states, review, and project context. The screenshot shows the working board in an empty local state.
Plugin architecture
Modules can be installed, enabled, disabled, and reloaded through the interface. The example plugin is a development fixture used to exercise that extension path.
Automation control · simulation
An HMI-style control study for programmable actions, position and machine state, G-code display, status logging, and alarm history. This screen is explicitly simulation-only; no machine hardware is connected.
One Connected Programme
01 · NodeOne
Hardware and local-agent experimentation.
02 · ForgeCommand
Orchestration, HMI, and system architecture.
03 · Connected Systems
Home control, edge nodes, energy, workshop, and physical automation integrations as they become real.