openproj 0.39.0__tar.gz

openproj-0.39.0/.gcloudignore

@@ -0,0 +1,30 @@
+# What NOT to upload to Cloud Build. Without this file gcloud uploads the whole
+# directory — .git is 20 MB and .venv is 101 MB, none of which the image uses,
+# on every single build.
+#
+# Deliberately not the default gcloudignore behaviour of honouring .gitignore:
+# .venv is git-ignored and would be excluded, but so is nothing else that
+# matters, and an ignore file that silently follows another file is one more
+# place a build can lose something it needed. Everything here is explicit.
+
+.git/
+.gitignore
+.worktrees/
+.venv/
+**/__pycache__/
+**/*.pyc
+.pytest_cache/
+.ruff_cache/
+
+# Not part of the running service.
+#
+# `docs/` was here and is not: the Help page reads those files off the disk at
+# render time, so they ARE part of the running service now. The build failed at
+# `COPY docs/` with "file not found in build context or excluded by
+# .dockerignore" — on a commit whose whole test suite was green, because nothing
+# in CI builds an image. `test_the_container_carries_the_documents` reads this
+# file as well as the Dockerfile for exactly that reason: two files decide
+# whether a document reaches production and only one of them was being checked.
+tests/
+deploy/RUNBOOK.md
+gcloud_deploy.sh

openproj-0.39.0/.gitattributes

@@ -0,0 +1 @@
+uv.lock merge=binary

openproj-0.39.0/.github/shards/coedit

@@ -0,0 +1,43 @@
+# coedit — 106.5s exact, anchored on tests/test_coedit.py (76.4s).
+#
+# Seconds are per FILE and EXACT, from docs/probes/ci-durations-4core.txt — every
+# phase of every test on the 4-core public runner, run 32754826551. The older
+# tables in docs/probes/ were taken on the 2-core box a PRIVATE repository gets,
+# AND at `--durations-min=0.05`, and both halves of that were wrong for this cut:
+# the leg order inverted when the cores doubled, and the 50ms floor hid 37s of
+# the suite on exactly the leg that had 1103 tests. Modelling that hidden cost
+# was tried and the fit did not hold — see docs/probes/ci-speed.md § 0b. The
+# threshold is zero here, so there is nothing left to model.
+#
+# The cut is what a longest-first pass makes of those numbers, and it lands at
+# 106.4-106.5s a leg: a 0.1s spread, against 93.0-119.8s on the cut it replaces.
+# `tests/test_editor.py` is 101.6s of the 106.4s it sits in, so this is 5s off
+# the floor and there is nothing further to win by moving files.
+#
+# **Balance is not what to spend the next hour on.** Runs of the SAME lists put a
+# leg 44s apart — `views` measured 76.57s and 120.37s across four — so no re-cut
+# is visible in one run, and four were not enough to separate this cut from the
+# one it replaced (120.4s against 122.8s, in either direction depending on which
+# runs you take). What would actually move the gate is the floor, and the floor
+# is one file.
+#
+# Real sockets, a real uvicorn on a real port, and literal `sleep(0.5)` budgets.
+# This leg exists so those stay serial, in file order, in one process, on a
+# machine nothing else is running AT THE SAME TIME — the condition every one of
+# those margins was measured under. Ballast is fine and always was: the other
+# files here run before or after it in the same process, never beside it.
+#
+# **What must never happen is this leg being internally parallelised**, and that
+# is also why `pytest-xdist` cannot help the gate even where it helps a leg: the
+# critical path is bounded by a leg that is not allowed to split, so making the
+# other four faster buys total machine seconds and zero wall clock. Measured, in
+# docs/probes/ci-speed.md § 0b.
+tests/test_coedit.py
+tests/test_hill.py
+tests/test_deck.py
+tests/test_gitdoor.py
+tests/test_cli.py
+tests/test_headers.py
+tests/test_product.py
+tests/test_identity.py
+tests/test_socket_offer.py

openproj-0.39.0/.github/shards/editor

@@ -0,0 +1,39 @@
+# editor — 106.4s exact, anchored on tests/test_editor.py (101.6s).
+#
+# Seconds are per FILE and EXACT, from docs/probes/ci-durations-4core.txt — every
+# phase of every test on the 4-core public runner, run 32754826551. The older
+# tables in docs/probes/ were taken on the 2-core box a PRIVATE repository gets,
+# AND at `--durations-min=0.05`, and both halves of that were wrong for this cut:
+# the leg order inverted when the cores doubled, and the 50ms floor hid 37s of
+# the suite on exactly the leg that had 1103 tests. Modelling that hidden cost
+# was tried and the fit did not hold — see docs/probes/ci-speed.md § 0b. The
+# threshold is zero here, so there is nothing left to model.
+#
+# The cut is what a longest-first pass makes of those numbers, and it lands at
+# 106.4-106.5s a leg: a 0.1s spread, against 93.0-119.8s on the cut it replaces.
+# `tests/test_editor.py` is 101.6s of the 106.4s it sits in, so this is 5s off
+# the floor and there is nothing further to win by moving files.
+#
+# **Balance is not what to spend the next hour on.** Runs of the SAME lists put a
+# leg 44s apart — `views` measured 76.57s and 120.37s across four — so no re-cut
+# is visible in one run, and four were not enough to separate this cut from the
+# one it replaced (120.4s against 122.8s, in either direction depending on which
+# runs you take). What would actually move the gate is the floor, and the floor
+# is one file.
+#
+# THE FLOOR. 105 tests, 53 of the suite's real-Chrome call sites, each a fresh
+# browser laying out a page carrying 594 KB of inlined Ace. 101.6s on its own, so
+# no arrangement of these lists puts a leg below it and the gate cannot go under
+# about 102s of pytest however many machines it is given. It is also the reason
+# `pytest-xdist` was measured and refused: `-n 2` on this leg is 27% SLOWER, not
+# faster, because the cost is process startup and two Chromes on four cores
+# contend. Going below 101.6s means splitting the file, and its natural seam is
+# still `?editor=ace` against `?editor=plain`.
+tests/test_editor.py
+tests/test_writes.py
+tests/test_notes.py
+tests/test_issues.py
+tests/test_harness.py
+tests/test_config.py
+tests/test_model.py
+tests/test_auth.py

openproj-0.39.0/.github/shards/graph

@@ -0,0 +1,36 @@
+# graph — 106.5s exact, anchored on tests/test_graph_layout.py (32.2s).
+#
+# Seconds are per FILE and EXACT, from docs/probes/ci-durations-4core.txt — every
+# phase of every test on the 4-core public runner, run 32754826551. The older
+# tables in docs/probes/ were taken on the 2-core box a PRIVATE repository gets,
+# AND at `--durations-min=0.05`, and both halves of that were wrong for this cut:
+# the leg order inverted when the cores doubled, and the 50ms floor hid 37s of
+# the suite on exactly the leg that had 1103 tests. Modelling that hidden cost
+# was tried and the fit did not hold — see docs/probes/ci-speed.md § 0b. The
+# threshold is zero here, so there is nothing left to model.
+#
+# The cut is what a longest-first pass makes of those numbers, and it lands at
+# 106.4-106.5s a leg: a 0.1s spread, against 93.0-119.8s on the cut it replaces.
+# `tests/test_editor.py` is 101.6s of the 106.4s it sits in, so this is 5s off
+# the floor and there is nothing further to win by moving files.
+#
+# **Balance is not what to spend the next hour on.** Runs of the SAME lists put a
+# leg 44s apart — `views` measured 76.57s and 120.37s across four — so no re-cut
+# is visible in one run, and four were not enough to separate this cut from the
+# one it replaced (120.4s against 122.8s, in either direction depending on which
+# runs you take). What would actually move the gate is the floor, and the floor
+# is one file.
+#
+# The files whose cost is starting something — a fresh headless Chrome per canvas
+# assertion, a fresh node per injection census — rather than rendering. This is
+# the group that gained most from four cores: it was 131.2s on two and 93.0s on
+# four, which is most of why the old cut inverted.
+tests/test_graph_layout.py
+tests/test_facets.py
+tests/test_injection.py
+tests/test_web.py
+tests/test_themes.py
+tests/test_payload.py
+tests/test_records.py
+tests/test_exclusion.py
+tests/test_credential.py

openproj-0.39.0/.github/shards/rest

@@ -0,0 +1,44 @@
+# rest — 106.4s exact, anchored on tests/test_table.py (38.9s).
+#
+# Seconds are per FILE and EXACT, from docs/probes/ci-durations-4core.txt — every
+# phase of every test on the 4-core public runner, run 32754826551. The older
+# tables in docs/probes/ were taken on the 2-core box a PRIVATE repository gets,
+# AND at `--durations-min=0.05`, and both halves of that were wrong for this cut:
+# the leg order inverted when the cores doubled, and the 50ms floor hid 37s of
+# the suite on exactly the leg that had 1103 tests. Modelling that hidden cost
+# was tried and the fit did not hold — see docs/probes/ci-speed.md § 0b. The
+# threshold is zero here, so there is nothing left to model.
+#
+# The cut is what a longest-first pass makes of those numbers, and it lands at
+# 106.4-106.5s a leg: a 0.1s spread, against 93.0-119.8s on the cut it replaces.
+# `tests/test_editor.py` is 101.6s of the 106.4s it sits in, so this is 5s off
+# the floor and there is nothing further to win by moving files.
+#
+# **Balance is not what to spend the next hour on.** Runs of the SAME lists put a
+# leg 44s apart — `views` measured 76.57s and 120.37s across four — so no re-cut
+# is visible in one run, and four were not enough to separate this cut from the
+# one it replaced (120.4s against 122.8s, in either direction depending on which
+# runs you take). What would actually move the gate is the floor, and the floor
+# is one file.
+#
+# NO LONGER "everything else". It is the table, the query language, the hover
+# card and the resolved cascade, plus what balances them. The name is kept
+# anyway: renaming a matrix value renames a status check, the one check branch
+# protection requires is `check`, which fans these in, and a rename is a
+# branch-protection edit in exchange for a word.
+#
+# **Where a new test file goes.** It used to be "here, unless it is slow enough
+# to be worth naming", and that rule went with the property that justified it. It
+# goes on whichever leg the newest table in docs/probes/ says is cheapest, and
+# `test_every_test_file_is_in_exactly_one_ci_shard` in tests/test_harness.py is
+# what stops it going on no leg at all.
+tests/test_table.py
+tests/test_mermaid.py
+tests/test_search.py
+tests/test_card.py
+tests/test_cascade.py
+tests/test_edges.py
+tests/test_teaching.py
+tests/test_index.py
+tests/test_parse.py
+tests/test_store.py

openproj-0.39.0/.github/shards/views

@@ -0,0 +1,35 @@
+# views — 106.4s exact, anchored on tests/test_render.py (76.4s).
+#
+# Seconds are per FILE and EXACT, from docs/probes/ci-durations-4core.txt — every
+# phase of every test on the 4-core public runner, run 32754826551. The older
+# tables in docs/probes/ were taken on the 2-core box a PRIVATE repository gets,
+# AND at `--durations-min=0.05`, and both halves of that were wrong for this cut:
+# the leg order inverted when the cores doubled, and the 50ms floor hid 37s of
+# the suite on exactly the leg that had 1103 tests. Modelling that hidden cost
+# was tried and the fit did not hold — see docs/probes/ci-speed.md § 0b. The
+# threshold is zero here, so there is nothing left to model.
+#
+# The cut is what a longest-first pass makes of those numbers, and it lands at
+# 106.4-106.5s a leg: a 0.1s spread, against 93.0-119.8s on the cut it replaces.
+# `tests/test_editor.py` is 101.6s of the 106.4s it sits in, so this is 5s off
+# the floor and there is nothing further to win by moving files.
+#
+# **Balance is not what to spend the next hour on.** Runs of the SAME lists put a
+# leg 44s apart — `views` measured 76.57s and 120.37s across four — so no re-cut
+# is visible in one run, and four were not enough to separate this cut from the
+# one it replaced (120.4s against 122.8s, in either direction depending on which
+# runs you take). What would actually move the gate is the floor, and the floor
+# is one file.
+#
+# `tests/test_render.py` draws every page and then measures it, and it is the
+# second-largest file in the suite. `tests/test_seats.py` is beside it rather
+# than on `coedit` because a seat band is drawn by the same rendering path, and
+# because `coedit` had no room for it.
+tests/test_render.py
+tests/test_help.py
+tests/test_seats.py
+tests/test_delete.py
+tests/test_status_gate.py
+tests/test_schedule.py
+tests/test_remote.py
+tests/test_validate.py

openproj-0.39.0/.github/workflows/ci.yml

@@ -0,0 +1,257 @@
+name: CI
+
+# Pull requests before the merge, and `main` after it. Gating only the PR leaves
+# the branch everything is cut from unverified the moment two separately-green
+# PRs land and interact.
+#
+# EVERY pull request, and not only the ones based on `main`. The filter that used
+# to be here was `branches: [main]`, and what it did to a stacked PR is the worst
+# available failure: #92 was opened against the `thinking` branch, GitHub matched
+# no trigger, and `gh pr checks` answered "no checks reported" — which is the same
+# answer it gives while a run is still queuing. A branch built on an unmerged one
+# therefore sat un-gated and looked exactly like a branch waiting its turn.
+#
+# AGENTS.md already documents the sibling trap, where a `CONFLICTING` PR has no
+# `refs/pull/<n>/merge` for the workflow to check out, and says to ask
+# `gh pr view <n> --json mergeable` before asking anything else. That question
+# answers `MERGEABLE`/`CLEAN` here, so the documented check does not find this
+# one. Removing the filter is what makes the check trustworthy again.
+#
+# `push` stays pinned to `main`: a push run gates the branch everything is cut
+# from, and every other branch already reaches this workflow through its PR.
+on:
+  pull_request:
+  push:
+    branches: [main]
+
+# A PR's third push makes the first two runs' answers worthless, and they go on
+# holding a runner while the answer that matters queues behind them. With six
+# jobs per run instead of one this matters six times as much.
+concurrency:
+  group: ci-${{ github.ref }}
+  cancel-in-progress: true
+
+# Three job kinds, and the reason there are three is measured in
+# `docs/probes/ci-speed.md`: a job on this repository costs about a dozen seconds
+# of setup, not the ninety everybody assumes, so buying a whole extra machine is
+# cheaper than any arrangement of processes on one machine.
+#
+# **The runner is probed, not assumed, and the answer changed under this file.**
+# It said 2-core / 8 GB, citing run 32633361097, and added "`ubuntu-latest` is
+# 4-core only for public repositories and this one is private". The repository
+# went public on 2026-08-23 and the box is now **4-core / 15.6 GB**, probed again
+# in run 32753487844 — the probe step below prints it on every leg, because "the
+# runner" is five runners and nothing promises they stay the same size.
+#
+# That did not change the answer and it did change the sums. Five machines still
+# beat processes on one, and the shard cut was re-made from
+# `docs/probes/ci-durations-4core.txt` because the old one had INVERTED: the leg
+# order on 2 cores was editor > views > graph > rest > coedit and on 4 cores it
+# is rest > views > coedit > editor > graph. The Chrome-heavy legs took the extra
+# cores and the plain-Python one did not.
+jobs:
+  # Ruff alone, on its own machine, finishing in about twenty-five seconds.
+  #
+  # Worth ZERO seconds of wall clock on a green run, and that is worth saying
+  # plainly because the theory it looks like it comes from — "ruff runs serially
+  # in front of a twenty-minute suite" — was measured at 0s and is false. What it
+  # buys is how fast a RED run answers: a misplaced import is reported in
+  # twenty-five seconds instead of after the whole suite. The shards deliberately
+  # do NOT `needs: [lint]`; a lint error and a test failure are different
+  # questions and you want both answers from one push.
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+
+      # Pinned to an exact release rather than a major, and alone in that: astral
+      # stopped publishing moving major tags after v7, so `@v10` is a 404 and not
+      # a pin. Bump this deliberately; the other two follow their major.
+      - uses: astral-sh/setup-uv@v10.0.1
+        with:
+          # 3.12 because that is what the Dockerfile ships and what ruff targets.
+          # A gate that is green on a version the deploy never runs is not a gate.
+          python-version: "3.12"
+          enable-cache: true
+
+      # `--locked`, as in the Dockerfile: it fails on a `pyproject.toml` edited
+      # without relocking, instead of quietly testing a resolution that will
+      # never be the one deployed. Doing it here as well as in the shards is not
+      # duplication for its own sake — this is the job that reaches the sync step
+      # first, so a bump-without-relock is red in twenty-five seconds instead of
+      # in whatever the slowest shard costs.
+      - run: uv sync --locked --group dev
+
+      - run: uv run ruff check .
+
+      # No `ruff format --check` yet, on purpose: 32 of the 103 files predate any
+      # formatter and would fail it today, so adding it now commits a gate that
+      # is red on arrival — and a gate that is red on arrival teaches everybody
+      # to read past red. One `uv run ruff format .`, as its own commit touching
+      # nothing else, is what makes this line safe to add.
+      #
+      # Nothing here checks the shard lists, on purpose. They are hand-written
+      # and a hand-written list of files fails OPEN — add `tests/test_new.py`,
+      # forget the list, and it runs on no machine at all while every job stays
+      # green — but that is already held, once, by
+      # `test_every_test_file_is_in_exactly_one_ci_shard` in `tests/test_harness.py`,
+      # which reads the same files and answers on a laptop as well as here. An
+      # invariant written twice gets guarded once.
+
+  # The suite, cut five ways across five machines.
+  #
+  # The cut is in `.github/shards/<name>`, one path per line, and it is made from
+  # `docs/probes/ci-durations-4core.txt` — this hardware's table, not either of
+  # the 2-core ones, because the legs did not merely shrink when the cores
+  # doubled, they changed order. And at `--durations-min=0`, because the 0.05
+  # threshold the older tables used hid 37s of the suite, almost none of it
+  # evenly: 16s of that was on the leg with 1103 tests. 532.3s of exact rows over
+  # 42 files. Per leg the cut is 106.4-106.5s, a spread of 0.1s, against
+  # 93.0-119.8s for the lists it replaces.
+  #
+  # **That is a 13s improvement in expectation and it is invisible in any single
+  # run.** Two runs of identical lists put one leg 23s apart. Quote a median over
+  # several runs or quote nothing, and do not spend an afternoon re-cutting: what
+  # bounds this gate is `tests/test_editor.py` at 101.6s, which is one file.
+  #
+  # FIVE, and five is still the ceiling on four cores — re-derived rather than
+  # inherited. The break-even for a shard is `T/(K·(K−1)) > setup`; at T≈501s of
+  # attributed cost and ~12s of setup that allows six, and balance stops it
+  # first, exactly as it did before. `tests/test_editor.py` is 94.4s on its own —
+  # 105 tests, 53 of the suite's real-Chrome call sites, every one laying out a
+  # page carrying 594 KB of inlined Ace — and no file-level scheme goes below
+  # that floor. A perfect five-way is 100.3s of attributed cost; a perfect
+  # six-way would be 83.6s and cannot be reached, because the sixth machine lands
+  # on this one file at 94.4s. Six machines to save six seconds, and a seventh
+  # billing rounding to pay for it. Going below 94.4s means splitting that one
+  # file, and its natural seam is still `?editor=ace` against `?editor=plain`.
+  #
+  # `coedit` is a shard for the opposite reason to `editor`: it is the only leg
+  # with real sockets, a real uvicorn on a real port, and literal `sleep(0.5)`
+  # budgets. It must not be reordered or internally parallelised, and its own
+  # machine is how that stays true for free. That is also the one constraint the
+  # re-cut was not allowed to optimise away, and it is why a `-n 2` inside each
+  # shard could never be a blanket answer even if it paid on the other four.
+  suite:
+    strategy:
+      # One red shard must not cancel the other four. The whole point of a
+      # three-minute gate is getting every piece of bad news from one push.
+      fail-fast: false
+      matrix:
+        # Longest first: legs start roughly in this order, and `editor` is the
+        # critical path, so it should never be the one waiting for a runner.
+        shard: [editor, views, graph, coedit, rest]
+    runs-on: ubuntu-latest
+    steps:
+      # Full checkout, never sparse — the obvious optimisation here is wrong. 27
+      # of the 47 files in `tests/` import from another file in `tests/`
+      # (`test_editor.py` alone imports `test_web`, `test_store`,
+      # `test_injection`, `pages` and `browser`), and `tests/test_remote.py:375`
+      # asks for a fixture defined in `test_store` by name. A shard missing an
+      # import hub fails at COLLECTION, which is a shard reporting nothing rather
+      # than a shard reporting a failure. The whole tree is one second.
+      - uses: actions/checkout@v7
+
+      # Pinned to an exact release rather than a major, and alone in that: astral
+      # stopped publishing moving major tags after v7, so `@v10` is a 404 and not
+      # a pin. Bump this deliberately; the other two follow their major.
+      - uses: astral-sh/setup-uv@v10.0.1
+        with:
+          # 3.12 because that is what the Dockerfile ships and what ruff targets.
+          # A gate that is green on a version the deploy never runs is not a gate.
+          python-version: "3.12"
+          enable-cache: true
+
+      # Thirty-four tests drive the shipped JavaScript through `tests/js/drive.js`
+      # and skip themselves when node is missing, so without this step the suite
+      # goes green by not running them — green for the wrong reason, which is the
+      # one failure a gate must never have. node is needed to test, never to
+      # build or run: nothing here is a build step, and there is no npm. Every
+      # shard installs it, including the ones nobody thinks need it: a shard that
+      # silently stops driving JS is exactly the failure this step exists to
+      # prevent, and eight seconds of cached tarball is not worth reasoning about
+      # per leg.
+      - uses: actions/setup-node@v7
+        with:
+          node-version: "24"
+
+      # WHAT THIS MACHINE ACTUALLY IS. The paragraph above `jobs:` said 2-core /
+      # 8 GB and cited a run id, which was the right way to settle it and is now
+      # the wrong answer: that measurement was taken while this repository was
+      # PRIVATE, and a public repository gets a different box. The number decided
+      # the whole shape of this file — five machines rather than `-n auto` on one
+      # — so it is not a number to inherit from a document. It is printed on
+      # every leg rather than probed once, because "the runner" is five runners
+      # and nothing promises they are the same size.
+      - run: |
+          echo "nproc:      $(nproc)"
+          echo "memory:     $(awk '/MemTotal/{printf "%.1f GB", $2/1048576}' /proc/meminfo)"
+          echo "chrome:     $(google-chrome --version 2>/dev/null || echo absent)"
+          echo "node:       $(node --version)"
+          echo "runner:     ${RUNNER_OS} ${RUNNER_ARCH}"
+
+      # `--locked`, as in the Dockerfile: it fails on a `pyproject.toml` edited
+      # without relocking, instead of quietly testing a resolution that will
+      # never be the one deployed.
+      - run: uv sync --locked --group dev
+
+      # The pixel tests look for `google-chrome` on PATH and ubuntu-latest ships
+      # one, so headless Chrome needs no step of its own here. If that stops
+      # being true they skip with a stated reason rather than fail, and `-ra`
+      # (set in pyproject, deliberately not `-q`) prints every skip — so a suite
+      # that has quietly stopped checking pixels says so in the log instead of
+      # just looking green.
+      #
+      # `$files` is unquoted on purpose: the shard file is one path per line and
+      # the words are meant to split into separate pytest arguments. `sed` strips
+      # the `#` commentary the lists carry, matching what the census test in
+      # `tests/test_harness.py` accepts — a shard file the test reads and this
+      # line cannot is a trap set for whoever adds the next comment. It is a
+      # command substitution rather than `xargs` because `xargs` is allowed to
+      # split a long list into two invocations, and two pytest runs in one step
+      # would report two summary lines and one exit code. The emptiness check is
+      # what makes a missing or all-comment list red here: bare `pytest` with no
+      # paths falls back to `testpaths` and runs the WHOLE suite in every shard,
+      # which is slow rather than wrong, and therefore invisible.
+      #
+      # `--durations=25` stays after the measurement flags came out. The probe
+      # was `--durations=0 --durations-min=0.05`, which is 732 rows and is what
+      # `docs/probes/ci-durations*.txt` hold; 25 is the number that keeps this
+      # line useful without keeping the probe. What decides the critical path is
+      # shard BALANCE, and balance drifts every time a test file is added — 25
+      # rows per leg is enough to see which file grew and re-cut the lists,
+      # without anybody having to re-run a measurement workflow to find out. It
+      # is display-only: pytest times every phase whether or not it prints them.
+      - run: |
+          files=$(sed 's/#.*//' .github/shards/${{ matrix.shard }})
+          [ -n "$files" ] || { echo "shard ${{ matrix.shard }} names no test files"; exit 1; }
+          uv run pytest -q --durations=25 $files
+
+  # The one required status check, and the reason it is a separate job.
+  #
+  # Branch protection on `main` requires exactly one context, literally `check`,
+  # with `enforce_admins: true`. A `strategy.matrix` on a job named `check`
+  # renames the contexts to `check (editor)`, `check (views)` and so on, and
+  # separate jobs remove the name entirely. GitHub does not fail a PR for a
+  # required context that stopped existing in the way people expect: the PR sits
+  # pending for ever, or — if the old name is dropped from the required list
+  # without the new ones being added — every shard is red and the merge button is
+  # green. That is the sharding failure mode that ships a bug instead of blocking
+  # one, so the name does not move. The shards are called `suite`, and this job
+  # keeps the name the protection rule already knows.
+  check:
+    needs: [suite, lint]
+    # `!cancelled()` and NOT `always()`. `always()` runs this gate even while the
+    # run is being torn down, which is precisely what `cancel-in-progress` above
+    # does on every second push — reporting a red required check on a run nobody
+    # was waiting for. `!cancelled()` still runs when a shard FAILS, which is the
+    # case that has to be caught.
+    if: '!cancelled()'
+    runs-on: ubuntu-latest
+    steps:
+      # `needs.suite.result` on a matrix job is the aggregate: `success` only if
+      # every leg succeeded. Skipped and cancelled are not `success`, so both
+      # `[ … ]` tests fail closed on anything that is not a clean green.
+      - run: |
+          [ "${{ needs.suite.result }}" = success ] || exit 1
+          [ "${{ needs.lint.result }}" = success ] || exit 1

openproj-0.39.0/.github/workflows/release.yml

@@ -0,0 +1,83 @@
+name: Release
+
+# Publish to PyPI, so that `uvx openproj new …` is the whole of what somebody has
+# to type. It already works without this file — `uvx --from
+# git+https://github.com/jcanton/openproj openproj new …` builds the wheel from
+# a public clone in about four seconds — and the difference PyPI buys is only
+# that a person or an agent does not have to know the repository URL to reach
+# the tool. That is a real difference for a command whose whole reason to exist
+# is that nobody should have to look anything up first.
+#
+# On a tag and nothing else. `main` is pushed to many times a day and a version
+# on PyPI cannot be replaced or re-used — deleting a release only burns the
+# number — so the thing that publishes has to be a deliberate act, and a tag is
+# the deliberate act this project already makes.
+on:
+  push:
+    tags: ["v*"]
+  # Publishing by hand, for the first release, and for the day a tag's run is
+  # cancelled by an outage after the tag exists and cannot be pushed again.
+  workflow_dispatch:
+
+# One at a time, and never cancelled mid-flight: `cancel-in-progress` on a job
+# that uploads to an index is a way to produce half a release.
+concurrency:
+  group: release
+  cancel-in-progress: false
+
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    environment: pypi
+    permissions:
+      # Trusted Publishing: PyPI is told to trust *this workflow in this
+      # repository*, and the job exchanges a GitHub OIDC token for a
+      # short-lived upload token at publish time. Nothing long-lived is stored,
+      # so there is no API token in this repository's secrets to leak, to
+      # rotate, or to forget to rotate.
+      #
+      # It needs one thing done by hand, once, by somebody signed in to PyPI:
+      # add a pending publisher at https://pypi.org/manage/account/publishing/
+      # naming project `openproj`, owner `jcanton`, repository `openproj`,
+      # workflow `release.yml`, environment `pypi`. Until that exists this job
+      # fails at the last step with `invalid-publisher`, having built and
+      # checked the distributions perfectly well.
+      id-token: write
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: astral-sh/setup-uv@v10.0.1
+        with:
+          # 3.12, as in `ci.yml` and the Dockerfile. The wheel is pure Python and
+          # `requires-python = ">=3.12"`, so the building interpreter does not
+          # end up in the artefact — this is here so the whole repository agrees
+          # about one version rather than because this job needs a specific one.
+          python-version: "3.12"
+          enable-cache: true
+
+      # The tag and the version in `pyproject.toml` are two copies of one fact,
+      # and the failure when they disagree is the expensive kind: a `v0.39.0` tag
+      # publishing 0.38.2, with the number now spent and 0.39.0 never on the
+      # index. Checked before anything is built, because after the upload there
+      # is nothing to do about it.
+      - name: The tag and the version must agree
+        if: startsWith(github.ref, 'refs/tags/v')
+        run: |
+          tagged="${GITHUB_REF_NAME#v}"
+          declared="$(uv run --no-project python -c \
+            'import tomllib,pathlib;print(tomllib.loads(pathlib.Path("pyproject.toml").read_text())["project"]["version"])')"
+          if [ "$tagged" != "$declared" ]; then
+            echo "tag $GITHUB_REF_NAME says $tagged and pyproject.toml says $declared" >&2
+            exit 1
+          fi
+          echo "both say $declared"
+
+      - run: uv build
+
+      # Read back before it is published, the refusal every write path in this
+      # project makes. `twine check` is what catches a README that renders as
+      # plain text on the project page — which cannot be fixed in place
+      # afterwards, only in the next version.
+      - run: uvx twine check dist/*
+
+      - uses: pypa/gh-action-pypi-publish@release/v1

openproj-0.39.0/.gitignore

@@ -0,0 +1,22 @@
+__pycache__/
+*.pyc
+.venv/
+.env
+.DS_Store
+
+out/
+.worktrees/
+
+# What `uv build` writes. The release workflow builds these on a runner and
+# uploads them from there; a copy on somebody's laptop is a build artefact, and
+# one committed by accident is a wheel in the repository that nothing rebuilds.
+dist/
+
+# The writer's flock (store.LOCK_FILE). A running server writes its pid into
+# one of these beside the plan it is serving, and a copy of seed/ was carrying a
+# committed one — see the commit that removed it.
+openproj.lock
+
+# The subagent-driven-development workspace: ledger, briefs and review packages for a
+# plan in flight. Scratch by construction — git log is the record once the branch lands.
+.superpowers/

openproj-0.39.0/.pre-commit-config.yaml

@@ -0,0 +1,40 @@
+# `uvx pre-commit install` turns these on. Deliberately not run from CI: CI runs
+# ruff out of the locked dev group, and two ruffs on two versions disagreeing
+# about one file is a worse failure than either check missing.
+#
+# There is no hook here that runs the test suite. It takes four and a half
+# minutes, and a pre-commit hook that slow does not get waited for — it gets
+# `--no-verify`d, and then uninstalled, by exactly the person it was written to
+# help. The suite is the merge gate's job; this file is only for what is cheap
+# enough to never think about.
+repos:
+  # Same version as the ruff resolved in `uv.lock` for the dev group. Bump the
+  # two together: a hook that formats a file the way CI's ruff then rejects is
+  # the whole problem this is supposed to prevent.
+  - repo: https://github.com/astral-sh/ruff-pre-commit
+    rev: v0.16.2
+    hooks:
+      - id: ruff-check
+        args: [--fix]
+      # This repo is not format-clean yet (32 files of 103), and the hook only
+      # touches what you staged — so the first commit to an old file carries
+      # that file's reformat into an unrelated diff. `uv run ruff format .` as
+      # its own commit gets the noise out of everybody's review at once, and is
+      # the same commit that lets CI start checking format.
+      - id: ruff-format
+
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v6.0.0
+    hooks:
+      - id: trailing-whitespace
+      - id: end-of-file-fixer
+      # Conflict markers reach a branch that two other worktrees are cut from,
+      # and history here does not move — so a marker committed is a marker
+      # fixed forward, in public, forever.
+      - id: check-merge-conflict
+      # 1000, not the default 500. Vendoring libraries is policy here rather
+      # than an accident (`static/VENDOR.md`), and `static/cytoscape.min.js` is
+      # already 365K; a guard that fires on the documented practice is a guard
+      # people learn to skip. This is for the stray screenshot or database dump.
+      - id: check-added-large-files
+        args: [--maxkb=1000]