Numerisect 0.13.0

Source-only pre-release. Install from source; no binary packages are published.

• Corrected the capability index's API total, which read 212 while the application
  served 221, and added the guard that would have caught it. The route reference was
  already held equal to the running app; the summary page a reader meets first was not.

• Gave job search facets and a memory, which closes roadmap item 135 and with it the
  last of the five closeable presentation gaps. GET /api/jobs/facets counts the
  matches by status, engine and digit band under the same shared WHERE clause the
  result list uses, so a chip reading "failed 2" means two of these jobs rather than
  two in the database, and a band that matches nothing is absent rather than zero. The
  chips are the filter controls. Saved searches live in their own SQLite table, hold
  only the fields GET /api/jobs accepts, validate each on the way in, drop blanks,
  and replace by name while keeping their id and creation time.

• Drew the engine decision path, which closes roadmap item 129. PARI/GP already computed
  the path and returned it as explicit steps; the interface rendered them as table rows.
  Each question is now a node with the engine's answer beside it, the consequence labels
  the connector to the next node, the recommendation is the terminal node, and small
  factors appear on the question that found them. The table stays below the diagram for
  reading and copying. tests/decision_diagram.js runs the shipped drawing over a
  captured strategy result and checks the node and connector counts, the terminal
  marking and the escaping.

• Made CADO-NFS's own stages runnable one at a time, which closes roadmap item 17 and
  corrects what that entry claimed. It said isolating a stage would mean reproducing
  CADO's upstream Python harness's bookkeeping. It does not: every CADO task takes a
  run parameter, and disabling the task after the one wanted makes the harness stop
  there, log Stopping at <task>, exit cleanly and leave the finished work in its
  working directory. The new cado_stage backend runs up to a chosen stage on that
  basis; GET /api/factor/cado-stages lists the twelve in CADO's own order;
  POST /api/jobs/{id}/cado-stage moves the gate forward and CADO's state database
  continues the work. Verified against CADO-NFS 3.0.0 on a 60-digit input in three
  passes over one working directory, the last returning both 30-digit primes, and again
  with the exact argument array this code builds.

  A staged run is recorded as a report — the stages that ran and the figures CADO
  printed for them — and only the square root yields factors. A gated run that ends
  without CADO's stop marker fails rather than reporting a stage it may not have
  reached. An earlier stage cannot be re-run, because that work is already done. The
  report-status list now lives in outputs.py and is shared with the job manager, so
  one definition decides both what the exporter prints and where the completeness check
  applies.

• Drew the factor tree, which closes roadmap items 1 and 116. The job view had always
  been a flat root-plus-leaves list, because nothing computed the numbers between the
  factors. GET /api/jobs/{id}/tree returns the chain PARI/GP builds in
  fl_factor_tree: the input, each factor in the order the engines printed it, and the
  cofactor left after every division, with isprime run on each part. Every division is
  the engine's — dividing a hundred-digit cofactor is arithmetic, and a node's label has
  to come from a proof rather than from whichever engine printed the factor. The browser
  places boxes and edges and computes nothing; its layout is exercised against a known
  chain by tests/factor_tree_layout.js, which reads the shipped code rather than a
  copy of it. A cofactor continued as a child job carries that job's id, so the drawing
  spans runs, and a chain that does not reach 1 is reported as the part of the
  decomposition the engines established.

• Captured when each factor was first printed. The job manager notes every number of
  four or more digits as engine output streams past, and stamps the final factor list
  from that record. This is an observation of the engine's log and is labelled as one:
  it includes whatever buffering the engine does, shorter factors are not timed at all
  because small numbers appear in output for every other reason, and a factor the
  engines never printed as a whole number carries no time rather than inheriting the
  job's elapsed time. The tree's peeling order follows these times where every factor
  has one, and the response says which ordering it used.

• Added a guard that derives the roadmap's summary counts from the ledger's own entries.
  The table once read 131/12/4/0 — 147 of 150 items — and two files can no longer
  disagree about how much is left.

• Made CI install the distribution instead of the checkout. Every platform job — Linux
  ARM64, macOS ARM64 and Intel, Ubuntu under WSL — now runs python -m build and installs
  the resulting wheel into a fresh environment, so what is exercised is the artifact a
  user would install. The suite still runs from the checkout, because many tests read
  repository files, but it imports the installed wheel.

• Found that the existing wheel smoke test proved nothing. It ran python -c from the
  source directory, which puts the working directory first on sys.path, so every
  assertion about the packaged resources was satisfied by the checkout and would have
  passed with an empty wheel. scripts/check_installed_distribution.py replaces it: it
  asserts the import came out of site-packages before checking anything, then checks the
  packaged GP programs, C sources, browser assets and engine manifest, and finally factors
  8051 and proves 32416190071 through the installed console script — a wheel that imports
  but cannot compute is not an installation. pari-gp was added to the packaging job for
  that last part.

• Recorded the author's answers to the four open questions about 1.0 (2026-10-05): the
  version will not promise a stable API, the five closeable presentation gaps are to be
  built rather than declined, the permanent limits are to be restated outside the ledger,
  and platform CI is to install the published distribution rather than the checkout. The
  roadmap overview now carries them as decisions instead of questions.

• Stated in the capability index which searches are bounded by nature. A finite bound —
  SQUFOF below 2^62, the Fermat-quotient ceilings at 2^32 and 2,642,246, Coppersmith's
  proven window, the Mersenne k ceiling, a Brun truncation — reads as an unfinished
  feature unless the index says it is the shape of the question. A guard reads the
  ceilings out of fermat_quotients.py, so raising one without saying so fails the
  suite; it was verified by weakening the row and watching it fail.

• Added three guards against documentation drift, after two summary pages were found
  lagging behind the code in one day. Each time the feature's own guide was thorough and
  nothing failed when the summaries were not.

  • Every mathematical route must be described in a narrative guide. The reference table
    is deliberately excluded, since another test already holds it equal to the running
    application, so counting it would make this pass trivially. 181 routes are checked,
    and a prose name counts: a guide may say "NTT primes" where the route says
    ntt-primes.
  • Every /api/verify/* cross-check must be described on the verification page, which is
    where a reader goes looking for exactly that.
  • Every pinned engine must be named in the README and in a guide, and every C helper in
    a guide.
    Each guard was verified by introducing the failure it exists for — an undocumented
    route, a renamed cross-check, an engine pinned but never described — and confirming the
    assertion names the offender. CONTRIBUTING.md points at them, because writing a
    feature's own guide is not the whole job.

• Swept every markdown file against ground truth computed from the code, after the roadmap
  counts turned out to be wrong. The per-group tool counts in the capability index all
  check out (11 groups summing to 139, plus 22 zeta pages), as do the version strings, the
  engine and C-helper counts and the route tables. Four descriptions did not:

  • The README's feature list omitted NFS polynomial selection, the second proof engine
    and the two new cross-checks, and the landing page's factorization and primality rows
    omitted the same work.
  • docs/concepts/engines.md described YAFU as a factoring pipeline only, though it is
    now also a proof engine (APR-CL) and a second Lucas-Lehmer; and primesieve as an
    enumerator only, though its n-th prime and R(x) now cross-check primecount.
  • "Which engine answers which question" still answered "Is this prime?" with one prover,
    and its factoring answer predated Msieve's standalone selection and the classical
    methods. It also gained the question Coppersmith answers: "I know part of a factor."

• Made the roadmap summary verifiable. The table read "Fully implemented 131 / Working
  with a named gap 12 / Declined 4 / Deferred 0", which sums to 147 rather than 150 and
  mixed two units: the gap row counted ledger entries while the implemented row counted
  proposal items. It now reports both columns — 17 items in 12 entries carry a gap,
  3 items in 4 entries were declined, 130 are implemented with no caveat — and the rows
  partition the 150 exactly. The note explains why the columns differ: an entry can cover
  several items (29, 30 and 37 share one), item 16 is split into a delivered half and a
  declined half, and items 4 and 14 appear in both the implemented narrative and the gap
  list because part of each shipped.

• Fixed two defects introduced when item 10 was closed in 0.11.0: its entry was marked
  "now complete" but left sitting under Partially implemented, and the note about
  YAFU's -np switch was added as a second entry numbered 17. Item 10 now has its own
  "Closed after the original ledger" section, and the YAFU note is folded into the single
  item-17 entry.

• Cross-linked the two roadmap files, which have confusingly similar names.
  docs/ROADMAP_STATUS.md (the 150-item ledger) now opens with a note saying which file
  holds what and links to the 1.0 questions, and its partial-items list points at the
  section that weighs those twelve gaps. docs/about/roadmap.md (the overview) names the
  ledger by path and marks that the 1.0 section lives there rather than in the ledger.
  Looking for the 1.0 questions in the larger, more obvious file found nothing, with no
  hint of where they were.

• Corrected the roadmap's 1.0 section, which overstepped. It had been written in 0.11.0 as
  four numbered commitments — a stable API, the closeable gaps built or declined, the
  permanent limits restated, the artifact exercised per platform — and closed with "this
  section is the author's standing position". The author had agreed to none of that; the
  criteria were the assistant's and were published as policy. The section is now titled
  "What stands between 0.x and 1.0", states plainly that the bar for 1.0 has not been
  set, and puts the same four points as open questions rather than commitments. The
  factual half, which comes from the ledger — twelve named gaps, none of them a missing
  computation, split into closeable presentation items and permanent bounded searches —
  is unchanged, because it is verifiable.

• Recorded the Zenodo version DOI 10.5281/zenodo.23172885 for the v0.12.1
  source release across CITATION.cff, the README, the installation guides, the
  capability index, the citation page, the FAQ, the publishing guide and the release
  history. Earlier version DOIs stay listed on the citation page.