subroutine 0.1.0__tar.gz → 0.1.2__tar.gz

{subroutine-0.1.0 → subroutine-0.1.2}/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
     {
       "name": "subroutine",
       "source": "./plugins/subroutine",
-      "description": "Give Claude a shared, durable task list: file work, find what is ready, record what happened, and leave the next session something to read. Needs Subroutine itself installed separately — 'pip install subroutine', then 'subroutine init'.",
+      "description": "Give Claude a shared, durable task list: file work, find what is ready, record what happened, and leave the next session something to read. Needs Subroutine itself installed separately and on your PATH \u2014 'uv tool install subroutine' or 'pipx install subroutine', then 'subroutine init'.",
       "author": {
         "name": "Simon Holliday",
         "email": "simon.holliday@protonmail.com"

{subroutine-0.1.0 → subroutine-0.1.2}/.github/workflows/ci.yml

@@ -68,6 +68,11 @@ jobs:
 
     steps:
       - uses: actions/checkout@v4
+        with:
+          # Tags, because the version is derived from them (`SR#234`). A shallow clone makes
+          # the build warn and produce `0.1.dev1+g…` rather than fail, so this job would
+          # install a package quietly claiming to be a version nobody released.
+          fetch-depth: 0
 
       - uses: actions/setup-python@v5
         with:
@@ -139,6 +144,11 @@ jobs:
 
     steps:
       - uses: actions/checkout@v4
+        with:
+          # Tags, because the version is derived from them (`SR#234`). A shallow clone makes
+          # the build warn and produce `0.1.dev1+g…` rather than fail, so this job would
+          # install a package quietly claiming to be a version nobody released.
+          fetch-depth: 0
 
       - uses: actions/setup-python@v5
         with:
@@ -168,6 +178,11 @@ jobs:
 
     steps:
       - uses: actions/checkout@v4
+        with:
+          # Tags, because the version is derived from them (`SR#234`). A shallow clone makes
+          # the build warn and produce `0.1.dev1+g…` rather than fail, so this job would
+          # install a package quietly claiming to be a version nobody released.
+          fetch-depth: 0
 
       - uses: actions/setup-python@v5
         with:

{subroutine-0.1.0 → subroutine-0.1.2}/.github/workflows/release.yml

@@ -52,6 +52,11 @@ jobs:
 
     steps:
       - uses: actions/checkout@v4
+        with:
+          # Tags, because the version is derived from them (`SR#234`). A shallow clone makes
+          # the build warn and produce `0.1.dev1+g…` rather than fail, so this job would
+          # install a package quietly claiming to be a version nobody released.
+          fetch-depth: 0
 
       - uses: actions/setup-python@v5
         with:
@@ -100,20 +105,31 @@ jobs:
       - name: Check the metadata
         run: twine check dist/*
 
-      # The tag says which release this is and `pyproject.toml` says what will be uploaded
-      # under that name. If they disagree, the thing published is not the thing the tag names
-      # — and this is the last moment that mistake costs nothing.
-      - name: The tag names the version being built
+      # **Two things, and only the second can now be wrong** (`SR#234`). The package derives its
+      # version from the tag, so the first comparison is close to tautological — it is kept
+      # because it is not *quite* one: a shallow clone, a missing tag or a dirty tree all make
+      # the backend produce a `.devN+g…` version instead, and this is where that would be caught
+      # rather than at the upload. The plugin manifest is static JSON with no build step, so it
+      # is the half that a release can genuinely publish out of step with itself.
+      - name: The tag names what is being built and what the plugin claims
         if: startsWith(github.ref, 'refs/tags/')
         run: |
           set -euo pipefail
           tagged="${GITHUB_REF_NAME#v}"
-          built="$(python -c 'import pathlib, tomllib; print(tomllib.loads(pathlib.Path("pyproject.toml").read_text())["project"]["version"])')"
+
+          built="$(python -c 'import importlib.metadata; print(importlib.metadata.version("subroutine"))')"
           if [ "$tagged" != "$built" ]; then
-            echo "the tag $GITHUB_REF_NAME does not name version $built" >&2
+            echo "the tag $GITHUB_REF_NAME built version $built — expected $tagged" >&2
             exit 1
           fi
-          echo "tag and version agree on $built"
+
+          declared="$(python -c 'import json, pathlib; print(json.loads(pathlib.Path("plugins/subroutine/.claude-plugin/plugin.json").read_text())["version"])')"
+          if [ "$tagged" != "$declared" ]; then
+            echo "the plugin manifest says $declared, and this release is $tagged" >&2
+            exit 1
+          fi
+
+          echo "tag, package and plugin all agree on $tagged"
 
       # A release that moves the schema has to say so in the changelog (SPEC.md §12.4a). CI
       # checks this on every commit; it is checked again here because this is the run where

{subroutine-0.1.0 → subroutine-0.1.2}/CHANGELOG.md

@@ -12,6 +12,46 @@ The point of it is that you can *plan* a database upgrade instead of meeting one
 through installing something. See [docs/hosting.md](docs/hosting.md#upgrading) for what the
 upgrade involves.
 
+## 0.1.2 — 2026-08-02
+
+No migration notice: the schema head has not moved since 0.1.0. Nothing in the package itself
+changed — this release is the plugin and the documentation around installing it.
+
+### Fixed
+
+- Installing the Claude Code plugin now gives you working tools without your having to supply
+  a path. Your editor launches `subroutine` itself, so it has to be on your `PATH` — and
+  `pip install` into a virtualenv satisfies "installed" while leaving every tool missing, with
+  no error at the point of the mistake. The plugin route now tells you to install it as a
+  tool, with `uv tool install subroutine` or `pipx install subroutine`, which is what puts the
+  command where something other than your shell can find it.
+- The plugin's skill sent that failure the wrong way. It could not tell "not installed" from
+  "installed where the editor cannot see it" — both look the same from inside a session — so it
+  told people who had already installed it to install it again. It now names `claude mcp list`,
+  which is the one command that separates them.
+
+`pip install subroutine` remains exactly right if you are only going to type commands
+yourself.
+
+## 0.1.1 — 2026-08-02
+
+No migration notice: the schema head has not moved since 0.1.0.
+
+### Fixed
+
+- An agent working in a checkout marked for a different instance could not file anything.
+  Committing a `.subroutine` file is how a team says which project a repository belongs to, so
+  a colleague who cloned the repository and ran `subroutine init` had a marker naming a project
+  that was not on their own instance — and `subroutine_add` refused every call rather than
+  ignoring it, while the CLI beside it carried on. Reads were never affected. A renamed project
+  is now also followed by its id over the Model Context Protocol, as it already was on the
+  command line.
+
+### Changed
+
+- The version is derived from the git tag rather than written into `pyproject.toml`, so what
+  the package reports and what was released cannot drift apart.
+
 ## 0.1.0 — 2026-08-01
 
 The first public release. Everything here is new, so this section says what exists rather than

{subroutine-0.1.0 → subroutine-0.1.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: subroutine
-Version: 0.1.0
+Version: 0.1.2
 Summary: Project management for people and agents, in equal measure.
 Project-URL: Homepage, https://github.com/simonholliday/subroutine
 Project-URL: Issues, https://github.com/simonholliday/subroutine/issues
@@ -84,6 +84,7 @@ practice — it keeps the backlog, records what it did, and adopts Subroutine in
 are already working on. **You never have to learn the CLI.**
 
 ```console
+$ uv tool install subroutine    # or pipx — your editor starts it, so it must be on your PATH
 $ claude plugin marketplace add simonholliday/subroutine
 $ claude plugin install subroutine@subroutine
 ```
@@ -96,11 +97,8 @@ $ subroutine serve
 $ subroutine token create --title "CI" --scope task:read   # a credential that can only read
 ```
 
-**`pip install subroutine` lands with the PyPI release, shortly.** Until then, install from
-here — `pip install git+https://github.com/simonholliday/subroutine` — which is what every
-command on this page was verified against. The full hosting recipe is in
-[docs/hosting.md](docs/hosting.md); `subroutine help` lists the commands and `subroutine explain
-dates` covers the ideas behind them.
+The full hosting recipe is in [docs/hosting.md](docs/hosting.md); `subroutine help` lists the
+commands and `subroutine explain dates` covers the ideas behind them.
 
 > **My context window ends. The instance does not.**
 >
@@ -119,10 +117,21 @@ dates` covers the ideas behind them.
 ## Install
 
 Python 3.11+ and thirteen dependencies. Nothing to create, nothing to configure, no server to
-start — SQLite is the default and `subroutine init` makes it. PostgreSQL when you outgrow it:
+start — SQLite is the default and `subroutine init` makes it.
+
+`pip install subroutine` is fine if you are only going to type commands yourself. **If an
+editor or an agent is going to launch it, install it as a tool instead** — that is what puts
+`subroutine` on your `PATH`, where something other than your shell can find it:
+
+```console
+$ uv tool install subroutine
+$ pipx install subroutine        # the same thing, if you have pipx rather than uv
+```
+
+PostgreSQL when you outgrow SQLite — the extra goes on whichever of the three you used:
 
 ```console
-$ pip install "subroutine[postgres]"
+$ uv tool install "subroutine[postgres]"
 ```
 
 ## The shape of it
@@ -211,10 +220,15 @@ $ claude plugin marketplace add simonholliday/subroutine
 $ claude plugin install subroutine@subroutine
 ```
 
-It asks once for the path to the `subroutine` command — give the absolute path if you
-installed into a virtualenv your editor does not activate — and optionally for a connection
-and a token, which are only needed for somebody else's instance. The token is kept in your
-system keychain, never in a settings file.
+**Your editor launches `subroutine` itself, so it has to be on your `PATH`** — which is what
+`uv tool install` and `pipx install` guarantee and a virtualenv does not. If the tools do not
+appear afterwards, that is nearly always why, and `claude mcp list` says so in one line:
+installing a plugin and starting its server are separate moments, and only the first one
+reports. `/plugin configure subroutine` takes the absolute path when you would rather point at
+a virtualenv than install it again.
+
+It can also be given a connection and a token, both only needed for somebody else's instance.
+The token is kept in your system keychain, never in a settings file.
 
 Without the plugin, or for another MCP client:
 

{subroutine-0.1.0 → subroutine-0.1.2}/README.md

@@ -39,6 +39,7 @@ practice — it keeps the backlog, records what it did, and adopts Subroutine in
 are already working on. **You never have to learn the CLI.**
 
 ```console
+$ uv tool install subroutine    # or pipx — your editor starts it, so it must be on your PATH
 $ claude plugin marketplace add simonholliday/subroutine
 $ claude plugin install subroutine@subroutine
 ```
@@ -51,11 +52,8 @@ $ subroutine serve
 $ subroutine token create --title "CI" --scope task:read   # a credential that can only read
 ```
 
-**`pip install subroutine` lands with the PyPI release, shortly.** Until then, install from
-here — `pip install git+https://github.com/simonholliday/subroutine` — which is what every
-command on this page was verified against. The full hosting recipe is in
-[docs/hosting.md](docs/hosting.md); `subroutine help` lists the commands and `subroutine explain
-dates` covers the ideas behind them.
+The full hosting recipe is in [docs/hosting.md](docs/hosting.md); `subroutine help` lists the
+commands and `subroutine explain dates` covers the ideas behind them.
 
 > **My context window ends. The instance does not.**
 >
@@ -74,10 +72,21 @@ dates` covers the ideas behind them.
 ## Install
 
 Python 3.11+ and thirteen dependencies. Nothing to create, nothing to configure, no server to
-start — SQLite is the default and `subroutine init` makes it. PostgreSQL when you outgrow it:
+start — SQLite is the default and `subroutine init` makes it.
+
+`pip install subroutine` is fine if you are only going to type commands yourself. **If an
+editor or an agent is going to launch it, install it as a tool instead** — that is what puts
+`subroutine` on your `PATH`, where something other than your shell can find it:
+
+```console
+$ uv tool install subroutine
+$ pipx install subroutine        # the same thing, if you have pipx rather than uv
+```
+
+PostgreSQL when you outgrow SQLite — the extra goes on whichever of the three you used:
 
 ```console
-$ pip install "subroutine[postgres]"
+$ uv tool install "subroutine[postgres]"
 ```
 
 ## The shape of it
@@ -166,10 +175,15 @@ $ claude plugin marketplace add simonholliday/subroutine
 $ claude plugin install subroutine@subroutine
 ```
 
-It asks once for the path to the `subroutine` command — give the absolute path if you
-installed into a virtualenv your editor does not activate — and optionally for a connection
-and a token, which are only needed for somebody else's instance. The token is kept in your
-system keychain, never in a settings file.
+**Your editor launches `subroutine` itself, so it has to be on your `PATH`** — which is what
+`uv tool install` and `pipx install` guarantee and a virtualenv does not. If the tools do not
+appear afterwards, that is nearly always why, and `claude mcp list` says so in one line:
+installing a plugin and starting its server are separate moments, and only the first one
+reports. `/plugin configure subroutine` takes the absolute path when you would rather point at
+a virtualenv than install it again.
+
+It can also be given a connection and a token, both only needed for somebody else's instance.
+The token is kept in your system keychain, never in a settings file.
 
 Without the plugin, or for another MCP client:
 

{subroutine-0.1.0 → subroutine-0.1.2}/plugins/subroutine/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "subroutine",
-  "version": "0.1.0",
+  "version": "0.1.2",
   "description": "Project management for people and agents, in equal measure. Wires this session to a Subroutine instance and carries the working practice for using it well.",
   "author": {
     "name": "Simon Holliday",
@@ -18,7 +18,7 @@
     "command": {
       "type": "string",
       "title": "The subroutine command",
-      "description": "Usually just 'subroutine'. Give the full path if you installed it into a virtualenv your editor does not activate — for example /home/you/.venvs/subroutine/bin/subroutine. Not installed yet? Run 'pip install subroutine' and then 'subroutine init' in a terminal, then come back here.",
+      "description": "Usually just 'subroutine'. Your editor launches it, so it has to be on your PATH \u2014 'uv tool install subroutine' or 'pipx install subroutine' put it there. Give the full path instead if it lives in a virtualenv your editor does not activate, for example /home/you/.venvs/subroutine/bin/subroutine. Not installed yet? Install it in a terminal, run 'subroutine init', then come back here.",
       "default": "subroutine"
     },
     "connection": {
@@ -30,7 +30,7 @@
     "token": {
       "type": "string",
       "title": "Agent token (optional)",
-      "description": "A token issued for this agent, if you want it to have less access than you do — 'subroutine token create --service-account claude --scope task:read'. Leave empty to let it act as you. Stored in your system keychain, never in a settings file.",
+      "description": "A token issued for this agent, if you want it to have less access than you do \u2014 'subroutine token create --service-account claude --scope task:read'. Leave empty to let it act as you. Stored in your system keychain, never in a settings file.",
       "sensitive": true,
       "default": ""
     }

{subroutine-0.1.0 → subroutine-0.1.2}/plugins/subroutine/skills/subroutine/SKILL.md

@@ -9,14 +9,30 @@ Subroutine is a task and project tracker that a person and an agent use as equal
 write in it is attributed to you, addressable by a number, and still there after your context
 is gone — which is the whole reason to spend calls on it.
 
-**If the `subroutine_*` tools are not available, stop and say so.** The plugin configures them
-but does not install the program. Tell the user:
+**If the `subroutine_*` tools are not available, stop and say so — and do not guess which of the
+two causes it is.** The plugin configures the tools but does not install the program, so either
+it is not installed, or it is installed somewhere the editor cannot see. Both look identical
+from here: no tools, and no error, because installing a plugin and starting its server are
+separate moments and only the first one reports. One command tells them apart:
 
 ```
-pip install subroutine
+claude mcp list
+```
+
+`✘ Failed to connect` beside `plugin:subroutine:subroutine` means the program was not found on
+the `PATH` the editor passes down — nearly always a virtualenv. Say so, and offer the two ways
+out: install it as a tool so it is on the `PATH` for good, or point the plugin at the copy that
+already exists.
+
+```
+uv tool install subroutine     # or: pipx install subroutine
 subroutine init
 ```
 
+`/plugin configure subroutine` takes the absolute path instead — `<venv>/bin/subroutine` — for
+somebody who would rather not install it twice. If the server is not listed at all, the plugin
+itself is not installed or is disabled.
+
 **If the tools are there but every call fails, read what the failure says — it names the
 remedy.** This is the ordinary case on a fresh install and it is not the one above: the MCP
 server starts perfectly well against an instance nobody has created yet, so the tools appear
@@ -24,10 +40,9 @@ and then refuse. `no Subroutine instance has been set up here yet.` means the us
 `subroutine init` once; a schema message means `subroutine upgrade`. Pass the failure on
 verbatim rather than diagnosing it — the sentence is written for them.
 
-If it is installed but the tools still fail with nothing useful, it is almost certainly on a
-path Claude Code cannot see — a virtualenv, usually. `/plugin configure subroutine` takes the
-full path to the `subroutine` command. Do not work around it by writing to a file instead; a
-tracker nobody can reach is worse than an honest failure.
+**Whichever of these it is, do not work around it by writing to a file instead.** A tracker
+nobody can reach is worse than an honest failure, and a to-do list in a scratch file is a
+tracker nobody can reach.
 
 `GET /v1/docs/agent` on any served instance is the reference for the HTTP API. This page is
 about *when* to reach for it and what good practice looks like — it does not repeat the API.

{subroutine-0.1.0 → subroutine-0.1.2}/pyproject.toml

@@ -1,10 +1,19 @@
 [build-system]
-requires = ["hatchling"]
+requires = ["hatchling", "hatch-vcs"]
 build-backend = "hatchling.build"
 
 [project]
 name = "subroutine"
-version = "0.1.0"
+
+# Derived from the git tag, never written here (`#234`). `v0.1.1` builds `0.1.1`; anything
+# further along builds a `.devN+g<sha>` version, which PyPI refuses — so an untagged commit
+# cannot be published even by accident. `subroutine.__version__` already read this back
+# through `importlib.metadata`, so nothing at runtime changed.
+#
+# **The cost is that a shallow clone lies rather than fails.** Without tags the backend warns
+# and produces `0.1.dev1+g…`, so every workflow job that installs this package checks out with
+# `fetch-depth: 0`.
+dynamic = ["version"]
 description = "Project management for people and agents, in equal measure."
 readme = "README.md"
 requires-python = ">=3.11"
@@ -41,6 +50,9 @@ dependencies = [
 	"uvicorn[standard]>=0.30",
 ]
 
+[tool.hatch.version]
+source = "vcs"
+
 [project.optional-dependencies]
 postgres = ["psycopg[binary]>=3.1"]
 dev = [

{subroutine-0.1.0 → subroutine-0.1.2}/src/subroutine/cli/personal.py

@@ -2606,26 +2606,16 @@ def register (
 	def _project_named_by (world: World, marker: subroutine.directory.Marker) -> str | None:
 		"""Return the current key of the project a marker names, or ``None`` if there is none.
 
-		By id where the marker carries one, because that is the half that survives a rename;
-		by key otherwise, which is every marker written before `#177` — including the one in
-		this repository. A marker that predates the change must go on working, or the upgrade
-		is the outage.
+		The matching itself is `subroutine.directory.resolve`, which is shared with the MCP
+		server — this half is only the fetching, because that is the part that needs a world
+		to fetch through. It was one function here until `#232` found the other surface had no
+		equivalent at all.
 		"""
 
 		where = world.writing_to()
 		found = where.client.projects(workspace=_writing_workspace(world))
 
-		if marker.project_id is not None:
-			for row in found:
-				if str(row.id) == marker.project_id:
-					return row.key
-
-		if marker.project is not None:
-			for row in found:
-				if row.key.upper() == marker.project.upper():
-					return row.key
-
-		return None
+		return subroutine.directory.resolve(marker, found)
 
 	@app.command(hidden=not _worth_showing(settings))
 	def connections () -> None:

{subroutine-0.1.0 → subroutine-0.1.2}/src/subroutine/directory.py

@@ -81,6 +81,47 @@ class Marker(typing.NamedTuple):
 		return f"{named or 'nothing'}, from {self.path}"
 
 
+class Named(typing.Protocol):
+	"""The two fields a marker is resolved against, on whatever a client hands back."""
+
+	@property
+	def id (self) -> typing.Any:
+		"""The project's permanent identifier."""
+
+	@property
+	def key (self) -> str:
+		"""The project's current key."""
+
+
+def resolve (marker: Marker, projects: typing.Iterable[Named]) -> str | None:
+	"""Return the current key of the project a marker names, or ``None`` if there is none.
+
+	By id where the marker carries one, because that is the half that survives a rename
+	(`#177`); by key otherwise, which is every marker written before that change — including
+	the one in this repository. A marker that predates it must go on working, or the upgrade
+	is the outage.
+
+	**Returning ``None`` is an answer, not a failure** (`#166`). A marker is advisory context
+	written by a machine, so a checkout marked for one instance must not stop work being filed
+	against another — the caller reports that it was ignored and carries on. This lives here,
+	client-free and taking rows rather than fetching them, because both surfaces need the same
+	answer and the CLI had the only copy: `subroutine_add` passed the marker's key straight to
+	the server and refused whenever it did not exist there (`#228`'s neighbour, `#232`).
+	"""
+
+	if marker.project_id is not None:
+		for row in projects:
+			if str(row.id) == marker.project_id:
+				return row.key
+
+	if marker.project is not None:
+		for row in projects:
+			if row.key.upper() == marker.project.upper():
+				return row.key
+
+	return None
+
+
 def find (start: pathlib.Path | None = None) -> Marker | None:
 	"""Return the nearest marker at or above ``start``, or ``None``.
 

{subroutine-0.1.0 → subroutine-0.1.2}/src/subroutine/mcp/tools.py

@@ -472,27 +472,49 @@ def _added (
 	# need it restarted — which is the one thing an agent cannot do to itself.
 	marker = subroutine.directory.find()
 	line = _text(arguments, "text") or ""
-	filed = (
-		marker.project
-		if marker is not None
-		and marker.project is not None
+	workspace = _text(arguments, "workspace")
+
+	consulted = (
+		marker is not None
+		and (marker.project is not None or marker.project_id is not None)
 		and not subroutine.domain.capture.names_a_project(line)
+	)
+
+	# **Resolved against this instance, never passed through** (`#232`). The marker's key went
+	# straight to the server until 0.1.0, so a checkout marked for somebody else's instance —
+	# which is what committing this file is *for* — refused every `subroutine_add` with "there
+	# is no project 'SR' here", while the CLI beside it filed the task and said it had ignored
+	# the marker. `#166` settled that the marker is advisory; only one surface implemented it.
+	# Resolving also buys `#177`: a renamed project is followed by id, which this never did.
+	filed = (
+		subroutine.directory.resolve(marker, client.projects(workspace=workspace))
+		if consulted and marker is not None
 		else None
 	)
 
 	captured = client.capture(
 		text=line,
-		workspace=_text(arguments, "workspace"),
+		workspace=workspace,
 		type=_text(arguments, "type"),
 		project=filed,
 	)
 	answer = "Added " + _line(captured.task)
 
 	# Said out loud for the same reason the CLI says it: nobody typed it, and an agent that
-	# cannot see where its work went cannot tell a person either.
+	# cannot see where its work went cannot tell a person either. That argument applies just
+	# as much when the marker was *not* used — more so, because the agent is then holding a
+	# repository whose file says one thing and an instance that says another.
 	if filed is not None:
 		answer = f"{answer}\n  in {filed}, from {subroutine.directory.FILE_NAME}"
 
+	elif consulted and marker is not None:
+		shown = marker.project or marker.project_id
+
+		answer = (
+			f"{answer}\n  {subroutine.directory.FILE_NAME} here names {shown!r}, which is not "
+			f"on this instance. Ignoring it."
+		)
+
 	# Both halves of §6.13's obligation, and `#135` is why the second one is here: an agent is
 	# the caller most likely to have written something it believes was understood, and telling
 	# it only what was *left* answers the rarer question.

{subroutine-0.1.0 → subroutine-0.1.2}/tests/test_cli_connections.py

@@ -21,6 +21,7 @@ import subprocess
 import sys
 import time
 import typing
+import zoneinfo
 
 import httpx
 import pytest
@@ -30,6 +31,13 @@ import typer.testing
 import subroutine.cli.main
 import subroutine.credentials
 
+#: The zone every instance in this file is created in, named once because a test that asks
+#: what day it is has to ask *this* clock rather than the machine's (`#233`). Deliberately
+#: not UTC: a zone that is offset from the runner's is what makes a whole-day expiry mean
+#: something to assert.
+INSTANCE_ZONE = "Europe/London"
+
+
 #: How long to wait for a freshly started server before giving up on it.
 STARTUP_TIMEOUT_SECONDS = 20.0
 
@@ -47,7 +55,7 @@ def home (tmp_path: pathlib.Path, monkeypatch: pytest.MonkeyPatch) -> pathlib.Pa
 		if name.startswith(("SUBROUTINE_TOKEN", "SUBROUTINE_WORKSPACE", "SUBROUTINE_CONNECTION")):
 			monkeypatch.delenv(name, raising=False)
 
-	monkeypatch.setenv("SUBROUTINE_DEFAULT_TIMEZONE", "Europe/London")
+	monkeypatch.setenv("SUBROUTINE_DEFAULT_TIMEZONE", INSTANCE_ZONE)
 
 	return root
 
@@ -121,7 +129,7 @@ def served (tmp_path: pathlib.Path) -> typing.Iterator[Remote]:
 		"XDG_CONFIG_HOME": str(root / "config"),
 		"XDG_DATA_HOME": str(root / "data"),
 		"XDG_STATE_HOME": str(root / "state"),
-		"SUBROUTINE_DEFAULT_TIMEZONE": "Europe/London",
+		"SUBROUTINE_DEFAULT_TIMEZONE": INSTANCE_ZONE,
 	}
 
 	for name in list(environment):
@@ -929,7 +937,11 @@ def test_an_expiry_names_a_whole_day_and_the_token_lives_through_it (
 
 	run("init")
 
-	today = datetime.date.today().isoformat()
+	# **The instance's today, not the machine's** (`#233`). The runner is UTC and the instance
+	# is an hour ahead of it, so between 23:00 and midnight `date.today()` names a day that
+	# ended here an hour ago — and the token issued "through today" is already expired when the
+	# listing is read. One hour a night, every night the offset is not zero.
+	today = datetime.datetime.now(zoneinfo.ZoneInfo(INSTANCE_ZONE)).date().isoformat()
 	issued = run("token", "create", "--title", "through today", "--expires", today)
 	secret = next(word for word in issued.output.split() if word.startswith("sr_"))