taskr

Reference

The app

The web app is the same record the CLI writes, read by a person. It is deliberately thin on writing: agents write through the CLI, and the screens exist for the three things a person does better — deciding what is real, judging what is next, and carrying out a check no machine can.

How to read it

Colour means authorship and nothing else. A person's ink against an agent's ochre, so that scanning a timeline tells you who did what before you have read a word of it. Nothing else in the app is ever tinted — not a status, not a failure, not a passing check.

Every state, therefore, is a glyph, a border style or a font weight. That is what keeps the two hues meaning one thing, and it is why every mark below survives greyscale, a projector, or colour blindness intact.

  • blocked — Heavier border and heavier weight. The one status that changes what to do next.
  • parked — Dashed border: deliberately set aside, with a note saying what comes next.
  • moved — The tree moved under the issue since it was written — its snapshot no longer matches HEAD.
  • pending — A check or step still owed.
  • in progress — The step a resume picks up from. Marked by weight, like blocked.
  • passed / done — Settled, so it recedes rather than lighting up.
  • skipped / dropped — Dashed: set aside on the record, with a reason.
  • promoted — A step that turned out to be its own issue or its own check.
  • abandoned — A step the close left unfinished — handed back, never swallowed.

Two marks carry a count rather than a state. ≠ moved says the code moved under an issue since it was filed; ≠ n since revised on a topic says how many entries have landed since anyone rewrote what that subject's state is. Both are invitations to re-read, not errors.

Now

The landing screen of the app, and the counterpart of taskr context. It answers, in order: is a session open and where, which subjects are moving, what is ready to pick up, what is parked, and what is open.

  • In progress — the active session, the machine and directory it is on, and the exact command to resume it. Sessions belong to machines, so this is how you find work you left on another one.
  • Next — ranked candidates with the reasons they ranked. Empty is meaningful: nothing is ready until it has a verdict, and the screen points at triage rather than pretending the queue is empty.
  • Parked — every parked session with its resume command, so a handoff is a copy-paste rather than an archaeology exercise.

Issues

Search and list. Closed issues are hidden until you ask for them, and each row carries its status tag, its rot mark if the tree moved, and a micro-spine — a compressed strip of the issue's timeline, so a list of fifteen issues shows which ones have actually been touched rather than which were merely filed.

An issue

The full record for one issue, in the order a reader needs it:

  • Steps — the working plan, with progress, and the actions to move one.
  • Children and tree — a group's issues and how many are closed.
  • Related — blocks, blocked-by, duplicates, and what was discovered during it.
  • Similar issues — open issues whose text says the same thing, scored, with nothing yet linking them. Suggestions rather than edges: a person confirms one with a duplicate verdict or a relation, and the section is absent when nothing comes close.
  • Checks — the done-whens gating the close, with the procedure spelled out and a runner for recording a result.
  • Specs and plans — the attached documents, rendered in full.
  • History — the spine: every event in order, tinted by who caused it. This is the one place the two hues do their work.
  • Agent context — what agents wrote to themselves while working. It is separated from comments on purpose: notes to a future agent are not the same genre as notes to a person.
  • Comments — the human thread.

Topics

A topic is a subject that outlives its issues — "webhook idempotency" rather than "PAY-31". The list answers one question per row: where does this subject stand right now. A topic's page carries its state, its open issues, its pending checks and its timeline, and the ≠ n since revised mark tells you when the state has fallen behind the events.

Checks

Every done-when still owed, across the project, with the ones that need a person listed first. This is the screen that exists because a tracker cannot verify a deploy, a load test or a switchover: someone carries the procedure out and records what happened, with numbers where there are numbers.

Recording a failure keeps the check pending — the latest run decides, so a failure is evidence rather than a verdict.

A check that has run opens to its history: every run recorded against it, newest first, with the actor, the note and the numbers. The latest run says whether a check is still owed; the history is what tells you a check has failed the same way four times, which is a different problem from one that failed once.

Triage

The queue of issues waiting for a verdict, grouped by why they are in it. A verdict is actionable, already_fixed, duplicate, stale or needs_info, and it is what lets an issue into the ready pool: taskr next ranks triaged work only.

Verdicts expire after a fortnight, which is the point. A report that was real two weeks and two hundred commits ago is a claim about a codebase that no longer exists.

Picking duplicate loads the row's closest open issues and offers each as a one-click fill for duplicate-of, so recording a duplicate no longer requires already knowing the twin exists.

Settings

The two screens behind settings are the account rather than the work: they belong to the organisation, not to a project, which is why the switcher does not reach them and why they are one step off the main row instead of sitting in it.

Keys

Everything that can write to your account, and how to stop one of them. A key is not a session: it does not expire, and it carries the actor every write made through it is recorded as — which is why the actor is the one tinted column on the screen.

Minting shows the secret exactly once; the server stores a hash, so there is no second look. Revoking marks the key ⤬ revoked — it stays listed, because a name that vanishes answers no question anyone later asks — and deletes every browser session that key opened, which is what makes a 30-day session length safe to offer at all.

Mint one key per thing that holds one: you, each agent, each machine. That is the whole reason the record can tell your work and an agent's apart.

Billing

Where the trial stands, how many seats you hold, and the way to pay. A trial runs 14 days without a card; when it ends the org locks — nothing is deleted, and the routes that let you pay and get your access back keep answering.

Project scope

The switcher in the masthead scopes now, issues, topics, checks and triage to one project, and it rides in the URL, so a scoped screen is a link you can send someone. It is the browser's counterpart to the project the CLI resolves from the checkout you are standing in.