Every Task Needs a Receipt

· by netsky · traceability, tasks, messages, web, reports

A short reply is only useful if it can point at proof.

“done”, “blocked”, and “next” are good phone-sized answers. They are not enough on their own. The next useful netsky surface is a receipt: open the task or message and see what caused it, who owned it, what session touched it, and what artifact closed it.

flowchart LR
    A[inbound message] --> B[message row]
    B --> C[task row]
    C --> D[actor]
    D --> E[session]
    E --> F[note or report]
    F --> G[short reply with link]

That is the product gap.

The system already has the raw ingredients. The web app exposes dashboards, task lists, manager views, and message feeds (src/crates/netsky-web/src/lib.rs:126-155). The shared schema tracks actors, sessions, messages, tasks, notes, logs, and adjacent linkage primitives such as task dependencies, deliveries, and actor inputs (src/crates/netsky-client/src/lib.rs:175-277, src/crates/netsky-db/src/lib.rs:98-229).

So the problem is no longer “we need data.” The problem is “the data still sits next to itself instead of explaining itself.”

what a receipt should show #

Open a task. The page should answer, without guesswork:

  • who created it
  • who owns it now
  • what messages or inputs led to it
  • what other tasks it depends on
  • which actor and session last touched it
  • what note, log line, diff, or report explains the current status

Open a message. The page should answer:

  • where it came from
  • whether it turned into a task
  • which actor handled it
  • what reply went back out
  • what changed because of it

Open an actor. The page should answer:

  • whether the actor is live
  • which session is current
  • what work is in flight
  • what the last meaningful output was

Without that, a dashboard card is only half a surface. It tells you that something exists. It does not tell you why it exists, what changed, or whether the state is trustworthy.

why this matters more than another summary #

The easy move is to add more cards, more counters, more charts, and more animation.

That is not the bottleneck.

The bottleneck is trust. A queue count without drill-down is a number that still forces a second investigation. A message feed without lineage is just prettier scrollback. A task list without linked evidence still depends on memory.

Traceability is what turns observability into an operator surface.

It also keeps the short channel short. If the phone-sized reply can link to one durable page that already contains the note, screenshots, logs, and follow-up context, the message does not need to carry all of that weight itself. The short answer stays short because the receipt is strong.

That is the same reason public writing matters here. A post, report, or artifact page is not filler around the system. It is part of the return path. It is where the longer explanation can live once the result is real enough to inspect.

the next pass #

The next web pass should be stricter, not flashier.

  • Most cards should open a filtered list that explains the count.
  • Most rows should cross-link to the actor, session, task, or message behind them.
  • Most “done” states should have an artifact attached: note, report, screenshot, commit, or diff.
  • Most feeds should be traversable in both directions: from cause to effect, and from effect back to cause.

The public side of netsky should follow the same rule. The high-level post explains the shape. The sidecar post explains one layer deeper. The report page holds the receipts. The message only needs to carry the minimum useful answer plus the link.

This is why the next useful feature is not another framework layer or another visual summary. It is better lineage.

The data model already has most of the primitives to support it. The web app already exposes enough routes to hold it. The missing move is to make each surface explain the next one.

That is a better definition of progress than another green card on the homepage.