The work graph Descant runs on

Issuegraph puts dependencies and ordering into the issues teams already use. Its shared contract lets tools determine what is ready, propagate priority through dependencies, and present the same work as a graph, tree or ordered list.

  • 107 pull requests merged

    The public record follows the specification into working packages, with review-driven corrections to scheduling, editing and releases.

  • 8 packages published

    Tools can install the graph logic, read and write issues, manage pending edits, and present or edit the same work graph.

  • 7 fields describe the work graph

    Relationships, priority and evidence stay with the issues, so tools can determine what is ready and what blocks it.

  • 111 test source files

    Regression checks cover the graph and its interfaces, including the deadlock and edit-ordering failures shown below.

Relationships that tools can use

Blocked-by, decomposition and serialization relationships preserve the order of work as a backlog grows. Priority can flow through dependencies, so a low-priority item blocking urgent work receives the appropriate effective priority.

Shared data, distinct responsibilities

The reader interprets declarations; derivation computes graph behavior; the writer preserves the surrounding issue body. The store sequences edits through a host-provided data source; viewing and editing build on the same contracts. The CLI exposes the same packages to automation.

The recorded work

Issuegraph grew from an open specification into 8 published packages: core, reader, writer, derive, store, viewer, editor and CLI. Its public history contains 107 merged PRs and 354 automated review submissions across 353 distinct PR revisions.

  • 622 review reports raised concerns

    The examples connect review to deadlock handling, reliable edits and checks of the packages consumers actually install.

  • 108 review reports marked P1

    These are the reviewer’s highest-priority reports in this record, including repeated reports of a concern.

  • 354 reviews recorded against the code

    Review continued across changing PR revisions, with the findings and resulting fixes available in the public history.

  • 429 finding threads received an author reply

    The discussion preserves how the author answered concerns about graph behavior, editing and release reliability.

Public repository and package-registry snapshot · November 1, 2026

Work delivered over time

109 pull requests opened and 107 merged over the recorded project history.
The complete repository history, including implementation, documentation and releases. Lines stop at their last recorded event.

How the backlog changed

126 issues created, 63 closed as completed, 65 closed in total.
Closing an issue as unnecessary is different from completing it. The chart distinguishes the two and ends at the last recorded issue event.

What review put on the record

622 published finding reports grouped by the reviewer’s original priority.
Published reports, using the reviewer’s original P1/P2/P3 labels. Some reports revisit the same underlying defect; these totals are not presented as unique bugs or fixes.

What changed in the software

Remove the second ordering engine

The demo initially reimplemented grouping, dependency traversal, priority propagation and selection order. Its first 15 review rounds recorded 31 findings, including regressions introduced while repairing earlier findings.

Once the shared derive package shipped, the demo was reduced to a projection between its document and the library’s inputs and outputs. The duplicated graph logic was deleted.

At the intermediate rework (44619a2 → 2977a56), demo/src/order.ts fell from 997 to 801 total lines and order.test.ts from 1,042 to 504, including comments and blank lines. Later review changed both files again. Across the complete PR, 18 published review submissions raised 39 finding reports. The final disposition retained a source-state follow-up and carried three cycle findings into package issue #43.

Find a deadlock that individual issue checks missed

Three issues could wait forever when a blocking cycle passed through a together unit, while the cycle list and diagnostics remained empty and the pre-write guard returned false.

PR #46 made the schedulable unit the graph vertex, updated both cycle reporting and the write guard, and clarified the specification. Internal advisory edges and singleton self-loops remain distinct.

The PR records the three-issue reproduction, four deliberate reversions each caught by the relevant test suite, and the demo’s known-gap test failing as intended when the package caught up. Current reader and derive tests preserve the group-contraction and self-loop cases.

A write result says whether the requested edit landed

A null splice result conflated no block with an existing uneditable block, and successfully parsing the output did not establish that the requested relationship was written. Provenance relationships could also be set but not cleared.

PR #55 introduced distinct result types and a read-back check of the requested edit. PR #65 made omitted/set/clear ownership uniform across the four writable fields, keeping unrelated text unchanged.

Reintroducing the historical indentation bug changed false success into not-written. The PR records 25 tests failing when that check is removed with the old defect. The later compatibility check compared 23 unchanged CLI cases and four newly permitted cases; a review correction added stderr to stdout and exit-code comparison.

Verify what consumers can actually install

Workspace checks passed while published reader/writer packages imported an export missing from core 0.1.0. A static resolver audit then accumulated findings while trying to model package-manager and runtime behavior.

The release path now installs the exact intended versions in a fresh consumer, inspects the entire resolved dependency tree, imports every published package and exercises the command.

PR #51 records a seven-package release validation and one package needing six propagation attempts while another was immediately available. That is one historical registry observation, not a reliability benchmark. Current tests cover every publishable package, stale nested copies, absent packages and CLI failure. The inventory is now eight published packages.

A retry against fresh data is one operation

Hosts had to compose a refresh and retry across an asynchronous gap. A refresh failure or a second action during that gap could make the retry use stale state or race user intent.

PR #110 moved retry-on-latest into the store’s existing queue and reserved the edit before the read. A failed read restores the original record and sends nothing.

Current tests directly cover a failed refresh, discard and second-press attempts during a held read, a refreshed document that invalidates the edit, and ordering behind an in-flight write. The public PR records these cases and the existing pending state being reused rather than adding a new queue.

Test the runtime promise by calling the packages

All eight published packages declared Node 18 support, but their build assumed ES2023 and the compatibility check only imported package entry points. Unsupported built-ins inside a function could remain invisible.

PR #233 aligned the compiler with ES2022 and changed the existing smoke check to call a public function from every package with a declared runtime floor.

Lowering the compiler library found findLastIndex in an editor test. The PR records 32 smoke tests and three failures when the new call requirement was disabled. Current tests require a probe for every published package and fail a probe that throws. The public record explicitly says this exercises selected paths, not every possible runtime behavior.

One contract across the packages

The specification and shared types define the work graph. Separate packages read, derive, manage pending changes, display and edit it. A host supplies the data source that persists changes; the libraries own no tracker credentials.

The current tree contains 111 test source files, spanning parser behavior, graph derivation, state management, editing, accessibility, package isolation and published-consumer checks. The examples show the specific regressions these checks were written to catch.

A finding can lead beyond its original PR. The demo exposed a deadlock in the shared graph implementation; issue #43 carried the reproduction, and PR #46 corrected the specification, cycle reporting and write guard together. The demo’s regression test changed when the package caught up.

  • 8 packages available to install

    Registry records confirm releases across the shared contract, graph logic, reader, writer, store, interfaces and command line.

  • 111 test source files

    Tests exercise graph behavior, editing, accessibility and package boundaries; consumer checks also exercise the published releases.

Sources and method

Descant uses Issuegraph to coordinate its own work. This page reports the complete public repository history; it does not infer that every PR was a prototype run from the repository owner, branch name or review bot.

The package registry and main branch are separate evidence: the snapshot has newer editor and viewer versions on main than in the registry. The package inventory records both versions, so readers can distinguish merged work from released packages.

Counting rules and coverage
  • Repository totals include all authors, documentation, releases and maintenance. They are not a count of independently verified Descant runs.
  • A published finding is a root inline review comment carrying the reviewer’s priority. Repeated reports remain separate. Replies, resolved threads and outdated lines are not treated as proof that a defect was fixed.
  • Issue charts use creation dates and the final close date of currently closed issues. They do not reconstruct every reopen event. Each series ends at its own last event.
  • PR charts use creation and merge dates, not run durations. Neither open PRs nor merged PR counts establish simultaneous agent execution.
  • Test inventories describe files present in the pinned source tree. Historical test results are identified as reported results; this census did not rerun the entire product test suite.

Start with an issue worth solving

Give Descant a real piece of work. Inspect the code, review the result and see what delivering it cost.