Subroutine 0.9.12

• A deferral given with a new repeat defers its first occurrence. An item made with a repeat
  and a deferral in one request showed at once, since the deferral went on the repeat itself,
  where nothing reads it. It goes on the first occurrence now, the one the request answers with.
• A narrowed credential cannot act on its owner's account. A token given only the read
  scopes, or narrowed to some projects or pinned to one workspace, could revoke its owner's
  calendar feed, sign its owner out of every browser, and revoke its owner's other tokens,
  including the unrestricted one. All three are refused now, as resetting and listing feeds
  already were, and a narrowed token may still revoke itself.
• A checkout's .subroutine file is read one way by the terminal and by the agent's tools.
  A file naming its workspace as it is shown, Projects, or with an id gone stale beside a name
  that matches, or naming the connection by a teammate's name for it, filed the agent's work in
  the Inbox while the terminal filed it in the project; and an agent whose session named no
  workspace was refused its first capture there. use --here now writes the workspace as it is
  stored, with the id of the connection it names.
• A project named by its bare key goes to that project or nowhere. A checkout, or an
  address's ?project=, naming web beside alpha/web filed into whichever was made first,
  and a key two projects share filed into one of them in silence. The whole address is matched
  first, a bare key only where one project has it, and a key several share is ignored, naming
  them. And the terminal takes a checkout's project only in the workspace the checkout names.
• delete, restore, link, unlink and move act on the item the address names. Given
  an address on another connection, delete and restore acted on this machine's item with
  the same number, and said they had acted on the one named; and an item named in another
  workspace or connection was read, as the second end of a link or the parent of a move, as
  whatever wore its number beside the first. delete and restore go where the address points
  now, and a link or a move across two workspaces is refused by name, since each joins two
  items in one.
• Continuing as another account from a sign-in link works in the browser. The confirmation
  page told the browser to send its form with no origin, which the instance refuses, so
  Continue as … ended in raw JSON. It sends the origin now, and still never the link.
• An agent given task:read and task:write can file in a project. Naming the project it
  files in, moves to or narrows a listing by needed project:read too, so an agent made as the
  hosting guide recommends could file nothing in one. Asking for the list of projects still
  needs project:read, and a project named wrongly is refused without listing the others.
• The guides no longer send a reader the wrong way: subroutine use work/<workspace>
  where they said subroutine use work, which is refused; the connection's own
  SUBROUTINE_TOKEN_WORK where they offered a bare SUBROUTINE_TOKEN; the desktop and web
  apps named as needing a sign-in flow that is not built yet; and pipx named as serving the
  terminal, since the plugin needs uv either way.
• An agent's tools say why their connection cannot be reached. subroutine mcp naming a
  connection that does not exist, or one with no token, exited before the handshake with its
  reason where no client shows it, so the tools were simply missing. It now answers every
  message, the first included, with that reason.
• token create --store and connections add --url check what they write. A name no
  connection could have, such as My Laptop, and an address whose port is not a number up to
  65535, each broke every command after them. Both are refused now, before anything is minted
  or stored, and a capital in a name is lower-cased as it is everywhere else.
• serve on a port already in use says so and starts nothing, where it announced its
  address and then printed uvicorn's own error.
• A credential narrowed to some projects, or pinned to one workspace, can no longer reset its
  owner's calendar feeds or list them. A reset hands back a working address that reads with
  the owner's own sight, so such a credential could read everything its owner can see through
  it. Minting one was refused already, and resetting and listing now are too.
• A command with a --workspace of its own takes -w as well, before the command or after
  it. token create, agent create, calendar create, user create and user list ignored
  a -w given before them, and the refusal for a missing workspace advised exactly that -w,
  so following its advice was refused again. They take it now - and still never from
  subroutine use or a checkout's marker, because each binds what it makes or shows to the
  workspace - and the refusal quotes the command back with -w in place. So
  subroutine -w projects token create pins the token to projects, where it used to make one
  for every workspace. user add, user role and user remove take -w after the command
  too, and a -w and a --workspace naming two different workspaces are refused.
• Each entry of subroutine://conventions names the project it belongs to, so an agent
  reading what binds it can tell a rule for its own project from one for another.
• A write made with a browser's session cookie has to say which page sent it. A browser
  sends Origin or Sec-Fetch-Site with every write, so the browser pages are unaffected; a
  write from a neighbouring site, or one carrying neither header, is refused and told to use an
  API token, as agents and the terminal already do. It matters where several instances share
  one domain, whose pages a browser treats as one site.
• Two people acting at once can no longer remove the last of something between them.
  Deleting the last two workspaces, removing or demoting a workspace's last two administrators,
  or deactivating the instance's last two superusers could each succeed when done at the same
  moment, because each counted the other as staying. The second now waits for the first and is
  refused, as it would be one after the other.
• On a local instance, the agent tools file into the project a checkout is marked for. In
  a checkout marked with subroutine use --here --project web, subroutine add filed into
  web while the agent's subroutine_add filed into the Inbox, because the tools compared the
  marker with the instance's own name rather than the connection's. The plugin now says where
  it is standing on a local instance, as it already did on a served one.
• A served instance no longer reads a .subroutine file in its own directory. Started
  inside a marked checkout, it filed writes from everybody else's sessions by its own marker,
  ahead of the ?project= in their address.
• A token holding a character no header can carry is refused rather than crashing. A token
  pasted with a no-break space, or another character outside ASCII, crashed the plugin and the
  terminal at start-up. Both now say that nothing was sent and ask for the token again, copied
  whole, without quoting it.
• subroutine_show says the status an item starts in - open, or draft - where it said
  nothing, so the full record of an open item never said it was open.
• subroutine_update says what it saved when its dates are refused. It saves the other
  fields first, so a title sent with an end before the start was saved while the answer read
  as though nothing had been. Only a busy database said so before.
• A time beside a date written without on sets nothing, and says so. Dentist 2 October
  at 3pm was an appointment today at 15:00, with 2 October left in the title and nothing
  said. The time now stays in the title, and the note names the day with it and says that
  day was not read, since a date or a weekday is read after on, by or from; beside a
  bare weekday the note says the same. Dentist on 2 October at 3pm is read as before. And a
  time after at left as written for any other reason, such as a day the calendar has not or
  a second time on the line, is no longer told that a time is read after at.
• Four digits after a written date are always its year, and one outside the years read
  leaves the date unread. File the return by 31 January 2024 was due on 31 January 2027,
  with 2024 left in the title and called a time. A year from last year to fifty years ahead
  is read; any other leaves the whole date, and any span it is part of, in the title with
  nothing set, and the note says which years are read. A time or a quantity written as four
  digits after a date loses the date too: Standup on 5 March 0930 sets nothing.
• A timestamp no clock could have written is refused by name. One too near the calendar's
  first or last day answered with a server error, and one with an offset outside -12:00 to
  +14:00 was taken at its word, moving the moment to another day. A date field now refuses
  both, naming the field, and a captured line leaves them in its title with a note - a date
  written without a time included, so Deliver by 9999-12-31 is filed with the date in its
  title. An offset is asked of only where it was written, so a date before a zone kept standard
  time, such as 1800-06-01T12:00 in Anchorage, is not refused for its local mean time.
• An end year from 2068 to 2076 is read as written, so from 2 October to 12 October 2070
  is a span in 2070 in a captured line and in plan --until alike, where one refused it and
  the other stored 2026 to 2070. And a span refused with a weekday in it names the weekday
  among what a span needs.
• Projects after the fiftieth can be found. A lookup read one page of projects, so a
  checkout marked for a later one filed into the Inbox, ?project= in an address could not
  name it, and use --here --project answered that it did not exist. project list and
  subroutine_project stopped at fifty too, without saying so. They read every project now,
  and the agents' listing cuts its summaries, saying so, rather than grow past a few pages.
• A sub-task goes where its parent is. Added without a project, it was refused on every
  surface, because it was filed where an item with no parent would go and a sub-task has to
  share its parent's project. It takes its parent's project now, ahead of a checkout's; a
  project named in the line still decides, and is refused if it is not the parent's. The
  browser's add form sends its Project control beside a parent only where the reader changed
  it, so the project a page offers no longer turns a sub-task away.
• Deferring a repeating item works against a 0.9.10 instance, which refused a deferral of
  an occurrence that did not say it was for that one.
• A ring of links stored before rings were refused is harmless. An item's tree drew the
  item again below itself and counted it, and sending one of the ring's links again was
  refused as a cycle; the tree marks the item as drawn above, and the link is answered.
• A page left on a second screen keeps up with an agent's work. The browser checked for
  changes every five seconds only while somebody used the page, and every thirty once it had
  gone two minutes untouched - which is how a page on a second screen is left. A change
  arriving counts as activity now on a page that shows it - the list, the board, the agenda
  and the journal - so the faster pace holds while work is landing, and the page still slows
  down after two quiet minutes. The People and Settings pages keep the slower pace.
• A search naming a project that does not exist leaves the page's own project in place.
  Typed on a project's page, project: and a name no project has said the page's own project
  was gone and showed the whole workspace. It says the search was refused now, and the page
  stays where it was.
• Emptying an item's Until day clears its end. The edit form lent the end the start's day,
  as the add form does for an end given only a time, so the end moved to the day the item
  starts - and one ending after midnight was refused as ending before it starts. The start's
  day is lent only where the form opened with no end.
• An address naming a project that has since been renamed opens its item on the agenda
  too. A project's page opens on its agenda, and there such an address showed the failure
  page, where the list said the project was gone, showed the whole workspace and opened the
  item. The agenda does the same now, and both leave the old name out of the address, so a
  reload goes straight to the workspace rather than asking for the project again.
• A line to capture is limited to 1,000 characters, five times a title's limit, and a
  longer one is refused before it is read. Reading one took seconds to minutes, holding a worker
  and a database connection all the while, before its title was refused anyway.
• A repeat's end written in any spelling works. A rule ending UNTIL=20261210T0000Z, or
  with an offset, was saved and then answered with a server error when an occurrence was
  completed, where only UNTIL=20261210T000000Z worked. Every spelling is stored that way now
  and read as before, and an end in a year no clock reaches is refused when it is written.
• A deferral given to a new repeat can be cleared. It was stored on the repeat itself,
  where nothing reads it, and could then be neither cleared nor saved from the edit form. A
  deferral set on the repeat itself is still refused, naming the occurrence to defer instead.
• An agenda that answers after the reader has moved on stays off the page they moved to.
  Choosing another view or page while an agenda was still loading could put That could not be
  shown over the new one when that agenda was refused.
• An agenda view saved with its project in quotes is drawn on that project in the browser.
  The server reads project:"web" as web and saved such a view, while the browser took the
  quotes as part of the name and found no project.