What ships
Eight packages exist as repositories. Four are on PyPI. Two of those four are empty wheels whose published summaries describe code that is not in them. This page draws the line, package by package, from live PyPI queries and unzipped wheels rather than from any README.
Why this page exists at all. Nothing in the ecosystem tells you what is installable. The version numbers in the READMEs are behind the code, two of them disagree with each other about the test count, and the one package whose README carries a PyPI badge is the one whose PyPI page 404s. A visitor deciding whether to use Issues-FS has no way to answer “what can I actually pip install today” — so that answer is the first thing on this site.
The eight packages
Queried against https://pypi.org/pypi/<name>/json on 22 August 2026. Where a package exists, the wheel was downloaded and its contents counted.
| PyPI package | Latest | Releases | Repo | Verdict |
|---|---|---|---|---|
issues-fs | 0.7.0 | 5 | v0.7.1 | real |
issues-fs-cli | 0.3.0 | 2 | v0.3.0 | real |
issues-fs-service | 0.2.0 | 1 | v0.2.0 | empty shell |
issues-fs-service-client-python | 0.2.0 | 1 | v0.2.0 | empty shell |
issues-fs-service-ui | — | 0 | v0.2.1 | not published |
issues-fs-docs | — | 0 | v0.1.6 | not published |
issues-fs-dev | — | 0 | v0.3.2 | not published |
issues-fs-dev-utils | — | 0 | v0.1.1 | not published |
Why four of the eight are not on PyPI → The answer is one table, and it is mechanical rather than mysterious.
The two that are real
issues-fs 0.7.0 — the core library
pip install issues-fs| Wheel | 103 files |
| Source | 98 .py files, 5,401 LOC |
| Tests | 604 test functions across 45 files, 8,213 test LOC — 1.5 lines of test per line of source |
| Requires | Python ≥ 3.12, osbot-utils, memory_fs, and ⚠️ issues-fs-cli |
| Contains | An importable Python API. No CLI and no HTTP in this package |
⚠️ The core library depends on its own CLI. issues-fs lists issues-fs-cli in its pyproject.toml, which is a circular dependency between the two packages and is explained nowhere. It is open question Q7.
The public surface, if you are importing rather than shelling out: Graph__Repository and Graph__Repository__Factory for storage; Node__Service for nodes and traversal (traverse_graph, find_incoming_links); Link__Service for edges; Type__Service for the type registry; Comments__Service for comments. The data model these operate on.
issues-fs-cli 0.3.0 — the end-user surface
pip install issues-fs-cli # provides the `issues-fs` console script| Wheel | 23 files |
| Source | 17 .py files, 1,080 LOC |
| Tests | 94 test functions across 7 files |
| Built on | Typer · no_args_is_help=True · help string “Git-native graph-based issue tracking” |
| Contains | 14 commands, three output formats, and --for-agent on every one |
Repository discovery is git-style: CLI__Context.discover_issues_root() walks up from the working directory looking for a .issues/, so the command works from anywhere inside the tree. This is the most credible thing in the ecosystem — it is small, it is tested, and every claim on the command page was checked against its source.
The two that are published and empty
This is the sharpest honesty item on the site, so it gets stated plainly. Both packages were published on 5 February 2026, have had one release each and six commits each, and nothing since. Both wheels contain eight files and no functional code: an __init__.py, a utils/Version.py, a utils/__init__.py, a version file and dist-info metadata.
| Package | Its PyPI summary says | The wheel contains |
|---|---|---|
issues-fs-service 0.2.0 | “FastAPI server with REST endpoints” | 8 files. No FastAPI application, no routes. It declares osbot-fast-api as a dependency and ships nothing that uses it |
issues-fs-service-client-python 0.2.0 | “API schemas and Python client” | 8 files. No client, no schemas |
The consequence to be clear about: no HTTP endpoint exists in any published package. If you read a document describing an Issues-FS API surface, you are reading design. Anything on this site that describes a service is labelled as design for that reason.
The fix is upstream and is one of two things — fill the wheels, or yank them so their summaries stop describing absent code. It is open request N3. Until then, saying so is the honest option, and it is the convention the sibling sites already follow.
The four that are not published
issues-fs-service-ui 404
142 files, 27 commits, v0.2.1 in the repository. The largest UI artefact in the ecosystem and the only one with a running local mode (scripts/run-locally.sh). It carries its own live graph — 49 nodes, 22 link entries, 9 node types — and an automation-runner app of 803 LOC of scripted scenarios that appears in no documentation. It loads d3, mermaid, vis-network, cytoscape, cytoscape-dagre and dagre from public CDNs; none is vendored and none is licence-attributed. Two test files, three test functions, plus a fully commented-out Playwright suite.
issues-fs-docs 404
Holds all 59 documents in the corpus. Its README shows a pip install issues-fs-docs line and a PyPI badge, both of which 404. The cause is exact and mechanical: this repository's main is still at Initial commit from 5 February, 24 commits behind dev, and CI publishes only from main.
issues-fs-dev 404
The development umbrella: 19 gitlinks, eleven of them role repositories. This is where the self-referential claim lives — each role is its own repository with its own ROLE.md and its own .issues/. The eleven roles.
issues-fs-dev-utils 404 — the orphan
535 LOC, 19 tests, a genuinely good docs/user-guide.md, and a 14-topic Librarian-maintained topic_map.json. It appears in no ecosystem map — not in Issues-FS__Dev's repository table, not in Issues-FS's, not in the architecture overview. Cross-repository developer tooling that nobody can find. Its user guide shows a pip install that 404s.
The honest reading
The repository count implies a platform. The wheel contents imply a library and a CLI. Both readings are fair, and this site offers the second one.
| Layer | State |
|---|---|
| Core library and CLI | shipping installable today, 698 tests between them |
The .issues DSL | shipping inside the core package — and undocumented until this site |
| Issues-FS-lite | specification complete and usable, no implementation needed — /lite/ |
| The service and its client | design published as empty wheels; no endpoint exists |
| The UI | built, unpublished 142 files, runs locally, not on PyPI |
| The lexicon | never built ~7,000 words of architecture — published as argued design |
And one more thing worth saying out loud, because it is an unusual failure mode: the code is in better shape than its documentation. Four load-bearing README claims are false and all four understate or misdescribe something real — the test count is higher than claimed, not lower. The corrections page lists every one against what was measured.
For an agent
Two packages are installable and real: pip install issues-fs (the Python API, 0.7.0) and pip install issues-fs-cli (the issues-fs command, 0.3.0). issues-fs-service and issues-fs-service-client-python resolve on PyPI but their wheels contain no code — do not build against them, and do not repeat their summaries. issues-fs-service-ui, issues-fs-docs, issues-fs-dev and issues-fs-dev-utils are not on PyPI at all; any pip install line you find for them in a README will 404. No HTTP endpoint exists in any published package. Before repeating any capability claim from an Issues-FS README, check it against /shipped/corrections.html.