Subroutine 0.8.29

Added

• A board can be arranged by who the work is assigned to. ?view=board&group_by=assignee
  in the browser, group_by=assignee on GET /v1/tasks. There is a column for each person
  holding work in what you are looking at, and one headed Nobody for what nobody has been
  given - which is drawn even when it is empty, because nothing here is unassigned is worth
  being able to see. Columns follow the work rather than the roster, so a large team does not
  produce a board of forty columns, and a person holding nothing here has no column. Dragging
  is offered only on the status board, where a drop means something.
• A parent says what the work beneath it adds up to. subroutine show on a milestone,
  and its page in the browser, now carry a line like 12h beneath this, over 9 of 14 under
  the sub-task list - the whole subtree rather than just the children, so a middle layer's
  own estimate is not lost. It says what it could add up: most backlogs have rows with no
  estimate, and a bare total over those would report part of the work as if it were all of
  it, so the coverage travels with the number. A parent whose work is entirely unsized says
  so rather than reporting nothing. GET /v1/tasks/{ref} gains beneath; a listing does
  not carry it.
• Whoever picks up a leaf task is shown what governs the milestone above it. Read
  first used to name a decision or a specification only on the item somebody had linked it
  to, which is usually the parent - so the person reading the milestone, who often wrote it,
  got the reading list, and the person actually doing the work got nothing and had to notice
  part of #7 and take another hop. A task or a document now inherits what binds anything it
  is filed under, nearest first, each rule said once and labelled with the item it came from
  so you can go and read the reasoning. Nothing changes on an item whose rules are its own.
  In the terminal, in the browser, on the agent tools and at
  GET /v1/tasks/{ref}/governing, which gains an inherited_from.
• An agent can set a deadline. subroutine_update takes due - a date, a date and
  time, or '' to clear it - so an agent correcting one stays in its own name. Before this
  there was no argument for a deadline on the curated tools, and an agent that met a wrong one
  reached for a terminal instead, where the correction was recorded as whoever's credential
  that terminal holds.
• A captured line reads an appointment's two ends. Dentist on Monday at 2pm til 3pm
  files a start at two and an end at three, where the end used to stay in the title. Write
  them as 2pm-3pm, at 9am to 5pm, from Monday 9am til 5pm or on the 24-hour clock, on
  a day the line names or on today, and an end earlier than its start is the next morning -
  so Party on Friday at 9pm til 1am ends on Saturday. Two times in prose are still left
  alone, so Email Bob re: 3pm is untouched; a span whose two days each carry a time is
  still held back and says so.

Changed

• The README is rewritten around what Subroutine makes possible, and is half its former
  length. It opens with the thing that was hardest to find before: install it, tell your
  coding agent "we use Subroutine now", and that sentence is the setup - the skill configures
  the project, marks the checkout and writes a pointer into whichever file your agent reads at
  startup, without interviewing you. Then what that makes possible, a standing instruction an
  agent can work from unattended, and why an agent picks the API up unaided. What was reference
  is still here, below a divider, and the guide at https://subsystem.co/subroutine/ carries
  the walk-throughs.
• The one-line description is now "A self-hosted, agent-native task and decision tracker for
  people and coding agents working on complex projects", on every surface that carries one.
  The old line said task management, which promised a to-do list - where a decision and a
  task are the same kind of item here, sharing one numbering. Nothing about the software
  changes; a search result and a plugin listing now describe it correctly.
• An agent that has not said which timezone it is in reads days in its account
  parent's, rather than in the workspace's. Nobody could set a zone for an agent they
  made, since an account's zone is its own to say, so a time an agent wrote for somebody -
  by Friday 16:30 - could be stored an hour or more from the one they both meant. An agent
  that works somewhere else can still say so with subroutine user timezone.
• A time the agent tools print says which timezone it is in, as
  2026-12-01T11:00 Europe/London. The value was always right and never said what it was
  right in, so an agent in another zone read it as its own and corrected a deadline that was
  not wrong. A whole day is unchanged: there is no o'clock to be wrong about.
• subroutine_whoami says how an agent gets a name of its own, where the agent tools
  are working on a person's credential: what they write is recorded as that person's, and
  subroutine agent create makes the account.

Fixed

• Claiming a finished item is refused. It took a lease that finishing had just given
  back, so the item said somebody was holding work nobody could start. subroutine claim
  now answers Already done, as subroutine start does, and the agent tools and the API
  say it is finished and how to open it again.
• The journal no longer shows a repeat's hidden twin. Giving an item a repeat makes a
  second row to hold the rule, which no list shows - and the journal printed created #2 Water
  the plants directly above the change that made it, so one act read as two and the second
  named an item you could not find. The change itself is still there, against the item you can
  see; the series' own history is still on its own page; and /v1/changes, the feed a client
  polls, is untouched.
• A deadline written beside a defer is counted from it. Chase the invoice from 15
  September by 30 September, written on the 17th, filed something hidden until next
  September that went overdue a fortnight later, and said nothing; from sunday by friday
  was due before it could be seen at all. Each date was read from today on its own. A
  deadline that would fall before the day an item appears is now read again from that day, as
  one beside a start already was - and a deadline you wrote as a fixed date is left exactly
  where you put it, because overdue work you have deferred is ordinary.
• A time written beside a date stays on that date. In a captured line with a start and a
  deadline, a time always went onto the deadline, whichever date it was written beside:
  Dentist on monday at 2pm by friday made an all-day start on Monday and a deadline at
  2pm, and the confirmation printed both, so it read as right. A time now goes on the date
  it follows, or the one it comes before, and one beside no date is read as it was.
• subroutine_whoami says which timezone an agent's days are read in, and names its
  account parent when that is where the zone comes from. It named one only when it
  differed from the machine's, and the agent tools see no machine wherever they run on the
  server, so an agent was never told.
• A new workspace follows the instance's timezone unless you give it one. Every way of
  making a workspace stored UTC instead - init stored the machine's - so changing the
  instance's zone never reached one, although subroutine workspace create --help said it
  would. Workspaces you already have keep the zone they hold: subroutine workspace update <name> --timezone '' makes one follow the instance.
• subroutine mcp --help says which connection it uses. --connection defaults to the
  one subroutine connections marks default, not the one in use, and the help said the
  opposite - so somebody who ran subroutine use work expecting their agent to follow got
  their own database.
• The local plugin's Agent token setting recommends subroutine agent create <name> --store, as its skill and agent create --help do. It still said to set
  SUBROUTINE_TOKEN_<CONNECTION> where your editor starts, which the skill tells an agent
  never to offer. Its Workspace setting now asks what your credential reaches, rather than
  how many workspaces the instance holds.
• A listing that refuses a status or a type names the ones there are, as subroutine update does. A read that spans your connections printed a refusal's first line alone, so
  subroutine list --status waiting said there was no such status and never which there are.

Security

• An instance served over HTTPS calls its session cookie __Host-subroutine_session, and
  a browser refuses to store a cookie of that name from anywhere that sets a Domain. Where
  instances share a domain - acme.example.com and beta.example.com - a page on one could
  otherwise write a session cookie for example.com, which the browser then sent to every
  other instance, under the same name and impossible to tell from the reader's own. It takes
  a script running on one of those pages first, so this narrows what such a script could
  reach rather than closing a hole. You stay signed in: both names are read, and the
  next request your browser makes hands your session back under the new one. An instance on
  loopback or plain HTTP keeps the old name, because the prefix only works with Secure.