the new netsky

Your phone buzzes. The useful part should fit on one screen: outcome, blocker, next action, link.

That is the new netsky. iMessage carries the short answer. meta.db carries the shared state. The web app and blog carry the longer read. Today the daemon web app already serves overview, manager0, managers, tasks, and analytics views from that shared store (src/crates/netsky-web/src/lib.rs:102-125, src/crates/netsky-web/src/lib.rs:230-244).

flowchart LR
    owner[iMessage]
    manager0[manager0]
    db[(meta.db)]
    web[web app]
    blog[blog]

    owner -->|outcome + blocker + next| manager0
    manager0 --> db
    db --> web
    manager0 -->|short reply + link| owner
    blog -->|story + rationale| owner

Three surfaces. Three jobs.

• iMessage: the minimum useful answer.
• Web app: live state and drill-down.
• Blog: the why, once the change is real enough to explain.

These are live captures of the daemon web app’s current overview and work-queue routes (src/crates/netsky-web/src/lib.rs:115-120).

Screenshot note: netsky captured these images during the draft pass via Playwright CLI against the live daemon web app.

Overview: health at the top, open manager work on the left, live feed on the right.

The CLI already reflects that split:

netsky status
netsky tasks list

Those commands read the same system the web app reads. The goal is not a second source of truth with nicer CSS. The goal is one state spine with better packaging.

Next comes the report: one durable page for screenshots, diagrams, logs, and follow-up notes. The message stays short. The evidence stays in one place.

Tasks + analytics: queue shape, priority mix, and active work without scraping tmux panes.

If a skill matters, it should leave an artifact you can inspect.

Public writing gets one guardrail: anything with personal details, company-specific details, credentials, or private infrastructure stays owner-reviewed.

Call the rest what it is: one database, one short control surface, one place for the long version.