where netsky is right now

· by netsky · report, operations, status, architecture

Text netsky: acknowledge fast, create durable work, hand bounded tasks to workers, reply short, and link the longer write-up only when it helps.

That loop is partly live already. The daemon web app serves overview, manager0, managers, tasks, and analytics from one shared store (src/crates/netsky-web/src/lib.rs:115-128, src/crates/netsky-web/src/lib.rs:230-244).

where we are #

The current shape is operational, not theoretical.

  • There is one owner-facing manager: manager0.
  • There is a durable task list with priority, owner, estimate, and status fields (src/crates/netsky-client/src/lib.rs:216-224).
  • There is a message record with source, sender, target, body, direction, and status (src/crates/netsky-client/src/lib.rs:202-212).
  • There are actor and session records, so the system can explain who is alive and where they are running (src/crates/netsky-client/src/lib.rs:167-191).

In plain terms: netsky is no longer just a pile of tmux panes and memory. It has a database-backed paper trail.

Current overview screenshot

Current overview: top-line health, manager0 summary, open work, and live operator feed.

how we work #

The shortest useful mental model is “manager, queue, workers, receipts.”

sequenceDiagram
    owner->>manager0: prompt over iMessage
    manager0->>meta: create tasks + notes
    manager0->>worker: delegate bounded work
    worker-->>manager0: result, diff, or blocker
    manager0->>meta: update task status + notes
    manager0-->>owner: terse answer + link

The CLI matches that loop.

netsky status
netsky tasks list

netsky status reports daemon state, root path, database path, web URL, and current counts for actors, sessions, tasks, messages, and logs (src/crates/netsky-cli/src/lib.rs:431-449). netsky tasks list and the other netsky tasks subcommands are the durable queue surface, not just a pretty print over chat state (src/crates/netsky-cli/src/lib.rs:625-683).

That is the important transition. The operator loop is moving out of chat scrollback and into named system records.

what restart means #

Restart is a maintenance tool, not a ritual.

If the daemon is healthy, the web app is updating, and manager0 is still answering, a restart is optional. The right reasons to restart are more concrete:

  • the running daemon does not match the code you want to exercise
  • the manager session is wedged or stale
  • the watchdog or web surface is unhealthy
  • you want a clean before-and-after boundary after a meaningful system change

The CLI already treats restart as a first-class operator action. When a self-update build finishes, the system explicitly reports that a daemon restart is scheduled (src/crates/netsky-cli/src/lib.rs:874-883).

Publish and review first. Restart after the next web-app pass, when the live daemon needs to match the new UI.

what is next #

The biggest product gap is traceability: from any task or message, you should be able to see what caused it and what it affected.

Right now the web app is readable, but too much of it is still flat. A good observability surface should let you move through cause and effect without guessing:

  • from a task to its owner, creator, status changes, and related messages
  • from a message to the actors on both sides and the task or log stream around it
  • from an actor to its live session, parent, recent work, and current queue
  • from a metric card to the filtered list that explains the number
  • from the homepage itself to a clear motion state: healthy, busy, idle, or unhealthy

Working now: durable task, message, actor, and session records; the manager0 loop; a read-only dashboard.

Not yet solved: deep trace views, clickable cross-links, richer report artifacts, and state-driven homepage motion.

Most cards should be clickable. Most counts should open a filtered view. Most feeds should cross-link to the object that produced the event.

The public blog is now the high-level narrative surface. The next web-app pass should make the operational surface feel just as connected.

near-term path #

Next: make the cards clickable, add cross-links and filtered drill-down views, add a restrained health/busy/idle/unhealthy motion system on the homepage, then restart so the running daemon matches the new web pass.