I build the unglamorous layer underneath automation: the boards, engines, and audits that let agents and business processes run unattended — and that tell you exactly what happened when they don't. Two decks, both flying.

MISSION CONTROL · FASTAPI · REACT · MCP · POSTGRES

A coding agent doesn't need another chat window — it needs a deck. Flight Deck gives a fleet of agent sessions somewhere to take orders from, and gives you the instruments to see what they burned getting there.

• Missions board — a kanban of work with parent/child subtasks, held per session.
• Missions MCP — agents claim and update missions over MCP; the server shares the web backend's live store, so a claim in a terminal lands on the board within one poll.
• Token audit — spend accounting per session, so agent cost stops being a rumour.
• Warp fleet — an orchestrator that drives real Warp terminal panes as workers.
• FlightDeck Night & Day — an 18-component design system with a written visual contract: warm paper, charcoal ink, one coral signal, hairline rules, offset depth. Night is a cockpit after dark; Day is the same chart in daylight. Both ship in-repo.

donhat-dev/flight-deck.sh →

ODOO 18 · OWL 2 · PYTHON · POSTGRES

Odoo automation usually means leaving Odoo: an external builder, a sync layer, and two places to debug. Workflow Studio puts the whole loop inside the ERP — design on a node canvas, run on a real engine, inspect the run where the data already lives.

• Canvas editor — infinite canvas, orthogonal routing, multi-select, undo/redo with command batching.
• Execution engine — a stack-based state machine that handles branches, loops, and merges, with typed per-node runners, {{ expression }} evaluation, and step-level run history.
• Triggers — manual, ir.cron schedules, UUID-routed webhooks, and Odoo record events via base_automation.
• Security by construction — row-level rules, run_as_user execution instead of superuser, sandboxed expressions, and secrets brokered at runtime so credentials never sit in workflow JSON.
• Decisions on the record — the engine, node output format, loop mechanism, trigger architecture, and content-addressed storage are each argued in an ADR.

Still pre-production and honest about it: breaking changes are expected.

donhat-dev/workflow_automation_builder →

GITHUB @donhat-dev — issues and PRs on either deck are welcome.