Conjecture Dashboard

Use this skill when a campaign needs a compact visual status tree that can be opened in a browser and linked from a homepage. The dashboard is not a ledger replacement; it is a navigation surface that summarizes the current route tree and points to the authoritative artifacts.

When to use

• You have several live or recently closed routes and want a readable branch-status view.
• You need a browser-friendly page that links each branch to its ledger, draft, or TeX source.
• The active ledger has become hard to scan, but the route structure is still best understood as a tree.
• You want a stable HTML summary that can be linked from the repo homepage or site index.

Dashboard contract

• The dashboard lives as generated HTML rendered from an authored JSON manifest.
• The manifest is the source of truth for the current route tree. Update it when a displayed claim or route status changes; a scratch result or unrelated ledger edit does not require a refresh.
• Every dashboard should have two top-level narrative sections before the tree:
  1. the current goal and an honest assessment of where the campaign stands relative to that goal;
  2. advances toward the original target and substantive reusable theory, with their round/date when known, plus decision-changing learning. Label local results and verification separately. Do not replace the last goal advance with the latest activity. If the essential obstacle remains unchanged, keep that visible even when a new lemma or counterexample has been verified. A general theory branch or standalone paper can be a major research achievement while that obstacle remains open. Give it its own question, results, and status rather than marking it parked solely because its return to the conjecture is unknown.
• These two sections are current-state summaries, not append-only logs. Keep them succinct and rewrite them in place at each substantive update; do not accumulate chronology, round-by-round notes, or stale progress claims there. Put history in the ledger and keep only the latest honest state/progress on the dashboard.
• The manifest should describe proof routes, reductions, closed conjectures, counterexamples, verification branches, and helper tools. It is a synthetic route tree, not a file tree.
• When helpful, give nodes a method_role field such as exact reformulation, native invariant, census, proxy, local test, global compatibility, side import, counterexample search, tombstone, or publication consolidation. This is distinct from status: it says what kind of mathematical work the branch is doing.
• Dashboard descriptions, node labels, and node descriptions may contain inline markdown and LaTeX math. Use $...$, $$...$$, \(...\), or \[...\] directly in those fields when a title or description needs math.
• The renderer may normalize inline $...$ math to explicit \(...\) in the generated HTML so it stays inline and typesets consistently.
• If a node points at a local markdown file through a content field, render that file as markdown in the dashboard rather than as escaped plaintext.
• If a link target is a local markdown file, the renderer should rewrite it automatically to the generated HTML preview page; the manifest should still name the original .md file.
• Markdown previews should support ordinary GitHub-style pipe tables, including inline markdown and math inside table cells. Preview pages and dashboard pages should use the browser width rather than a narrow fixed content column; tables should default to width: 100% and wrap long cells within the available viewport, with horizontal scrolling only as a fallback for genuinely unbreakable content.
• Keep link groups tidy: render 1-3 links directly, but collapse longer link groups into a disclosure section so dense nodes do not dominate the dashboard.
• When a markdown file is meant to be read in the dashboard preview, write equations in normal LaTeX math delimiters such as $...$, $$...$$, \(...\), or \[...\]. Do not fence mathematical content inside code blocks unless the intention is to show the literal source.
• Do not wrap reader-facing mathematical statements in backticks just to make them stand out. A span such as `NCTD<=VC` is rendered as literal code and MathJax will intentionally skip it; write $NCTD \le VC$ or \(NCTD \le VC\) instead. Reserve backticks and fenced blocks for filenames, shell commands, JSON keys, literal identifiers, and source snippets.
• Current renderers may best-effort coerce obvious relation-style code spans in Markdown previews into inline math for legacy files, but do not rely on that compatibility path when writing new Markdown.
• The generated HTML should be static, linkable, and readable on mobile.
• The dashboard should show the current structure, not a chronology of every past attempt.
• Separate the unrestricted goal from the hypotheses of a proved subfamily. A special-case construction must not appear to be an equivalent reduction of the whole target. Keep an uncovered input as supporting evidence unless a named structural claim makes it a decisive adversary. In latest_progress, lead with scope or mechanism changes and place verification counts in supporting evidence rather than using them as progress metrics.

Recommended manifest shape

• title: dashboard title.
• description: paragraph or short description of the campaign. This replaces the older subtitle field, which remains supported as a backwards-compatible alias.
• version: optional monotonically increasing integer campaign-state version.
• updated: optional date stamp.
• goal: markdown string stating the current exact goal.
• honest_assessment: markdown string giving the current candid status relative to the goal, including what is proved, what remains open, and what is only evidence or a proxy.
• latest_progress: markdown string distinguishing advances on the original target, reusable theory, subsequent learning, and local activity. State what each achieved; a new theorem label, route closure, sharper falsifier, or equivalent reformulation is not automatically such an advance. Use honest-conjecture-resolution for progress accounting; no new manifest fields are required.
• In existing summary fields, distinguish the mathematical contribution, confidence in its proof, and effect on the target or independent theory objective. Keep task completion separate. An independent audit updates confidence at its received scope; it does not move the discovery date. State the first unproved indispensable implication and what next result would change effort.
• goal_assessment: optional backwards-compatible alternative. It may be a markdown string, or an object with goal and assessment fields. Prefer the separate goal and honest_assessment fields for new manifests.
• nodes: top-level tree nodes.
• Each node may contain:
  • label
  • kind such as classification, problem, route, reduction, conjecture, counterexample, lemma, tool, or archive
  • status
  • updated_version: optional integer recording the dashboard version at which this node was last materially touched
  • method_role: optional compact phrase identifying the branch's current methodological role
  • description: paragraph or short markdown description of the node. The older summary, summary_md, and summary_file fields remain supported as aliases for existing manifests.
  • description_md or description_file for longer markdown prose or source-backed descriptions
  • links as {label, href} objects
  • children as nested nodes

Dashboard language discipline

• Dashboard labels and summaries are mathematical communication, not internal scratchpad shorthand. Keep them compact, but make every compact phrase precise enough for a reader who has not followed the whole chat history.
• Use the most precise node kind available. Prefer classification for a branch that classifies a family of objects, and problem for a branch that records a named open problem or subproblem. Use route only when the node really is a proof approach rather than a mathematical object, problem, classification, or reduction.
• Avoid generic proof-process words in labels or summaries unless they are qualified, contextualized, or formally defined in the linked ledger/TeX file. Terms that often become unclear include "gate", "obstruction", "proof debt", "proof obligation", "assay", "certificate", "finite certificate", "boundary", "sector", "mechanism", "proof spine", "proof package", "route", "pipeline", and "stratum".
• These words are not banned. Use them when they are standard or precise: for example a topological boundary, graph boundary, boundary operator, boundary condition, defined geometric sector, parameter sector, named obstruction, or formal certificate. Otherwise replace them with the actual mathematical content, such as "remaining lemma to prove", "necessary condition", "counterexample family", "main reduction", "induction step", "comparison lemma", "auxiliary construction", or "case split".
• Prefer node labels that name the mathematical state directly: Alexander-dual CM criterion proved, endpoint-separation lemma stalled, or rank-3 counterexample search active is better than CM gate, boundary obstruction, or finite certificate route.
• Use method_role to expose risk when a branch is only a census, proxy, or local test. Such active nodes should have a linked stop rule, native-structure audit, or local-to-global compatibility gate in the ledger.

Status semantics

• Use stable status words such as active, stalled, proved, refuted, draft, tool, verification, historical, or closed.
• Keep the status vocabulary small and consistent across the tree.
• A proved construction leaf should display its input hypotheses. Proved assembly leaves do not prove their parent existence target while joint input availability remains open. Link shared dependencies to one proof owner rather than counting each appearance as another advance.
• If a route changes status, update the manifest and regenerate the HTML in the same pass.

Rendering workflow

• Maintain the manifest in the repo next to the route artifacts, typically as dashboard.json.
• Render it with scripts/render_conjecture_dashboard.py.
• For active multi-leaf campaigns, prefer version staleness over wall-clock staleness:
  • bump the top-level version when the displayed campaign state changes;
  • set updated_version on each active node materially changed by that round;
  • use version - updated_version as a navigation aid, not as a measure of mathematical progress or an instruction to revisit low-priority leaves. Route reviews use cumulative effort and the time since the last goal advance; cosmetic touches do not renew a route.
• If the renderer supports it, use an explicit command such as scripts/render_conjecture_dashboard.py --bump-version --touch "Leaf label" so version bumps and node touches are reproducible. Do not bump the version for a render-only refresh.
• Commit the manifest and the generated HTML together when the dashboard is part of the repo record.
• Do not commit generated Markdown preview pages such as notes.md.html; they are reproducible side outputs and should be ignored by .gitignore.
• Link the generated dashboard.html from the repo homepage or site index.

Maintenance rules

• When the shared knowledge index is configured, link relevant stable result cards and their source owners. Use research-knowledge to check prior results, corrections and freshness before promoting a dashboard claim. Keep the dashboard a summary rather than another result database.
• Before adding a result node or rewriting latest_progress, compare the claim with the campaign's existing-result map, earlier rounds, and relevant related-repo results. Follow source links to the actual statements and corrections; the dashboard alone is not an exhaustive search index. Use honest-conjecture-resolution for the search procedure.
• Reuse an existing node for the same result; link imported results to their originating proof and record the original round/date when known. Label rediscovery or rechecking as reuse/verification, preserving the last genuine advance. For an extension, new proof, or application, state the precise addition over the earlier result. A new label or a move between repos does not establish novelty.
• Link the campaign's compact result map or inventory from an appropriate existing description or link group. Keep detailed search coverage and provenance in that record; no new manifest fields or duplicate chronological log are needed.
• Keep the tree shallow enough to scan quickly.
• Avoid duplicating the ledger; link to it instead.
• Keep goal, honest_assessment, and latest_progress accurate when displayed claims change. These fields are the dashboard's executive summary and should be readable before opening any tree node. They should usually fit in a few short paragraphs total; if they start to sprawl, compress them into the current target, current status, and latest proof-contract delta.
• If literature packets materially affect a route, use shared-literature and link to the shared index or canonical packet, using a compatibility view when needed for existing URLs.
• Put durable status changes in the ledger or TeX file first, then reflect them in the dashboard.
• Use the dashboard to answer three questions quickly: what is alive, what is dead, and where does each branch live in the route tree.