Han Demo

Archived demo project for exploring agent-native developer tooling, local daemons, transcription workflows, sandboxed worktrees, and live service routing.

Status

This project is archived and not maintained.

Han was an experimental R&D project, not a product. I built it to explore what a human-centered, agent-native computing environment could look like: a local daemon, coding-agent workflows, voice transcription, dynamic service routing, Docker-backed workspaces, and editor integrations.

The project was eventually aborted. The repository is kept public as a portfolio artifact and technical proof of work, not as software I recommend others install or run.

Do Not Use This In Production

This repository contains experimental code paths that can:

• start local daemons and IPC servers
• run shell commands
• create git worktrees
• start Docker containers
• invoke AI coding agents
• pass local environment variables into containers
• copy local agent configuration into containers
• record and archive voice transcripts

Those choices made sense for a private prototype where speed mattered more than hardening. They are not safe defaults for a public, production, or multi-user tool.

If you clone this repository, treat it as source material to read, not software to run. Audit it carefully before executing anything.

What I Was Exploring

Han started from a broad question:

What would a computing environment look like if text, code, data, voice, and AI agents were part of the same programmable workspace?

The prototype explored several ideas:

• Agent-native development: agents as first-class workers that can receive tasks, operate inside isolated worktrees, run validation, and return patches.
• Local daemon architecture: a TypeScript daemon coordinating workflow, transcription, archiving, eventing, IPC, and prototype features.
• Sandboxed execution: Docker-backed environments for agent work, validation, and repeatable development sessions.
• Voice-to-workflow loops: Rust-based local transcription feeding transcripts into local project archives and future agent workflows.
• Live service routing: an earlier router/service system for experimenting with swappable implementations and capability contracts.
• Editor integration: Neovim-side experiments for surfacing agent context and interacting with the daemon.

What Was Implemented

The current codebase is a pnpm monorepo with a TypeScript-first architecture and some Rust prototypes.

Important areas:

• daemon/ - current daemon-centered architecture.
• apps/cli/ - command-line interface for workspace, task, and transcription commands.
• apps/nvim/ - Neovim integration experiments.
• packages/ - shared libraries for transport, shell execution, sandboxing, state machines, contracts, terminal handling, and test utilities.
• services/ - earlier router/orchestrator/infrastructure-manager services.
• crates/transcriber-v2/ - Rust transcription prototype.
• prototypes/ - experimental UI and speech-to-text explorations.
• .archive/ and .v1/ - older research, reference material, and abandoned implementation paths.

The daemon became the primary direction near the end of the project. The older router/service model still exists in the repo, but it should be read as legacy prototype work.

Technical Highlights

• TypeScript monorepo using pnpm workspaces.
• Local JSON-RPC style daemon transport over Unix sockets.
• SQLite-backed workflow queue for agent tasks and attempts.
• Git worktree orchestration for isolated patch attempts.
• Docker sandbox management for local agent execution.
• Rust audio transcription prototype using local model infrastructure.
• Event-driven transcription and transcript archiving flow.
• Contract-oriented service/router experiments.
• Neovim and Tauri prototype surfaces.

Why It Was Stopped

The project was useful as a research vehicle, but the scope became too broad: editor surface, local daemon, agent runtime, sandboxing, transcription, workflow orchestration, service routing, and product UX were all being explored at once.

The useful outcome was the set of architectural lessons, not a finished app.

Key lessons:

• Agent workflows need strict permission boundaries from the beginning.
• "Local-only" is not the same as secure.
• Sandboxes are only useful if credential and filesystem boundaries are narrow.
• Voice-driven workflows are compelling, but transcript handling needs careful privacy and command-safety design.
• A single daemon is easier to reason about than a distributed service graph during early prototyping.
• Public demos should be honest about what is production-ready and what is only evidence of exploration.

Security And Privacy Notes

I do not intend this repository to contain real secrets. Environment files with real values are ignored, and the committed env files are examples/placeholders.

That said, this project was originally developed as a private prototype. Before running it, assume you need to review:

• shell execution paths
• Docker mounts
• environment variable loading
• local credential copying
• daemon IPC access
• transcript storage
• dependency advisories

The safest way to evaluate this repo is to read the source and architecture, not to execute the workflows.

Recommended Review Path

For a quick understanding, start with:

1. daemon/src/index.ts
2. daemon/docs/DAEMON_ARCHITECTURE.md
3. daemon/src/features/workflow/
4. daemon/src/features/transcription/
5. packages/sandboxing/src/docker.ts
6. services/router/
7. report.md

Reuse

This repository is available under the MIT License. No production use is recommended. If you are reviewing this as a portfolio artifact, the value is in the architecture, experiments, and tradeoffs rather than the repository as a drop-in reusable package.