The live graphs
Four real graphs exist in the ecosystem, holding 147 nodes between them. Every number on this page was measured by walking every issue.json — nothing is quoted from a README and nothing is estimated. One of the four is a genuinely good specimen; the other three are more useful than they look, because they show what partial adoption produces.
All four, side by side
| Repository | Nodes | Link entries | Layout | .issues DSL files |
|---|---|---|---|---|
SGraph-AI__App__Send | 71 | 141 | Fully hierarchical, max depth 8 | 0 |
Issues-FS__Service__UI | 49 | 22 | Mixed data/ + issues/ | 0 |
Issues-FS | 24 | 0 | Flat data/ | 3 |
Issues-FS__CLI | 3 | 0 | Flat data/ | 0 |
Issues-FS__Docs · __Dev · __Dev__Utils | 0 | 0 | Config scaffolding only | 0 |
The specimen: the SGraph Send graph
This is the graph to look at, and it is worth being precise about why. It is not the biggest tracker in the world; it is the one where every property the design claims is actually exercised.
Root node Repo-1 is “SGraph Send — Zero-Knowledge Encrypted File Sharing”. Authored between 8 and 22 February 2026.
| By node type | By status | Top tags |
|---|---|---|
| task 54 · feature 9 · phase 5 · project 1 · git-repo 1 · bug 1 | done 21 · backlog 21 · pending 14 · in-progress 8 · deferred 4 · active 2 · confirmed 1 | frontend 17 · ui 17 · incident-handling 16 · api 15 · backend 14 |
One bug against fifty-four tasks is itself a finding: this graph is being used for planning work, not for triaging defects. Whether that is the intended use is a question for its owners; it is what the data says.
What the other three show
Issues-FS__Service__UI — 49 nodes, 22 link entries
Nine node types including three not in the shipped default set — release, user-story, cli — so the type registry is genuinely being extended per project rather than accepted as given. Its layout is mixed: 44 nodes under data/, 4 under issues/, 1 at the root, which is what a migration that was started and not finished looks like.
Issues-FS — 24 nodes, 0 link entries
Sixteen tasks and eight bugs, flat, with no edges at all. A graph-based tracker being used as a list. It also holds the only three .issues DSL files in existence, and a stale _index.json claiming 22 issues and 6 bugs — the cache-not-a-source case.
Issues-FS__CLI — 3 nodes
One task, one feature, one bug. Enough to prove the tool ran here, not enough to be a tracker.
Three repositories with zero
Issues-FS__Docs, __Dev and __Dev__Utils have .issues/ directories containing config scaffolding and no nodes. Worth knowing before repeating the claim below.
So handle “the issue tracker tracks its own development” carefully. It is a good claim and it is partly true: three repositories have real graphs, three have none, and the largest graph in the ecosystem belongs to a different product — SGraph Send, the flagship consumer — rather than to Issues-FS itself. The honest version is that Issues-FS's best evidence comes from somebody using it, which is better evidence than self-use anyway.
The configs, and what is not yet published here
The two config files from the flagship graph — node-types.json (12 node types with their statuses and properties) and link-types.json (10 verb/inverse pairs with domain and range constraints) — are the cheapest credibility available to this site and the most directly reusable thing in it. They are not yet published here as downloads.
They are not, because publishing a reconstruction of a live file as though it were that file would be exactly the kind of thing this site was built to correct. The contents are summarised faithfully on the model page from the same source the summary came from; the files themselves need an export from the live repository. That is task T6, and it also answers an open task on graphs.sgit.ai.
Reproducing these numbers
Every figure above comes from walking a tree, and you can rerun it on any graph you have:
# node count
find .issues -name issue.json | wc -l
# by type
find .issues -name issue.json -exec grep -h '"node_type"' {} + | sort | uniq -c | sort -rn
# link entries (remember: each relationship is stored on both endpoints)
find .issues -name issue.json -exec grep -hc '"verb"' {} + | paste -sd+ | bc
# max depth
find .issues -name issue.json | awk -F/ '{print NF}' | sort -n | tail -1That the numbers on this page are checkable with four shell commands is not incidental — it is the same property that makes the tracker legible in the first place.
For an agent
Four live graphs exist, holding 147 nodes. The reference specimen is SGraph-AI__App__Send: 71 nodes, 141 link entries (~70 logical relationships, each stored on both endpoints), 84 files, max depth 8, all 13 schema fields on all 71 nodes. To measure any graph yourself, walk for issue.json rather than reading _index.json. Expect link entries to be roughly twice the number of relationships. Note that node types are extended per project — one live graph adds release, user-story and cli to the shipped twelve — so read .issues/config/node-types.json rather than assuming the defaults.