Update to Mathbox

{
  "description": "Track exact mathematical claims, evidence revisions, dependency impact, audit provenance, research routes, and parallel or delayed executions in a local append-only ledger. Use when a project has a .mathbox ledger or the user asks for executable research-state tracking, stale-evidence detection, run reconciliation, or a dependency-aware handoff generated from recorded events. Do not initialize state for a casual math question, replace proof auditing with metadata validation, or write a prose project retrospective from status files.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 318
    },
    {
      "relative_path": "evals/evals.json",
      "size_in_bytes": 14519
    },
    {
      "relative_path": "evals/trigger-evals.json",
      "size_in_bytes": 1666
    },
    {
      "relative_path": "references/deferred-handoff.md",
      "size_in_bytes": 6760
    },
    {
      "relative_path": "references/ledger.md",
      "size_in_bytes": 21987
    },
    {
      "relative_path": "references/migration.md",
      "size_in_bytes": 3051
    },
    {
      "relative_path": "scripts/research_state.py",
      "size_in_bytes": 80493
    },
    {
      "relative_path": "scripts/test_research_state.py",
      "size_in_bytes": 73836
    }
  ],
  "name": "research-state",
  "skill_md_contents": "---\nname: research-state\ndescription: >-\n  Track exact mathematical claims, evidence revisions, dependency impact, audit provenance, research routes, and parallel or delayed executions in a local append-only ledger. Use when a project has a .mathbox ledger or the user asks for executable research-state tracking, stale-evidence detection, run reconciliation, or a dependency-aware handoff generated from recorded events. Do not initialize state for a casual math question, replace proof auditing with metadata validation, or write a prose project retrospective from status files.\n---\n\n# Executable research state\n\nUse the project's existing authority rules. The ledger checks recorded evidence,\nnot mathematical truth. Its generated labels say only what evidence was\nrecorded: for example, `proof-recorded` is not a declaration that a theorem is\nproved under the project's vocabulary. Review status remains separate. Apply\nthe project's promotion and approval policy outside this mechanical projection.\n\nRead [ledger.md](references/ledger.md) before recording events. The portable,\nstandard-library helper is [research_state.py](scripts/research_state.py).\nResolve its installed location; all artifact paths are relative to the research\nproject supplied with `--root`, never to the installed skill.\n\n## Read before changing state\n\nFor an existing initialized ledger, run `--root PROJECT check --summary`, then\n`--root PROJECT handoff --goal CLAIM` when that goal has been registered. These default\nreports are brief: they give counts, actionable IDs, and an explicit omitted\ncount, including runs that are live, `stale-result`, or awaiting\nreconciliation. Use `--full` after the subcommand or `--json` before it when the exact\nclaim contract, review, route result, or complete issue list is needed. Do not\npaste a full projection into the live dashboard. For an authorized new project,\ncreate its directory, initialize and register claims first; do not run handoff\nagainst nonexistent state. `status`, `check`, `impact`, `pin-impact`, `next`, and\n`handoff` are read-only and never initialize a ledger. `--json` goes before the\nsubcommand.\n\nAfter resolving this skill's script as `TOOL`, use this small command map:\n\n```bash\npython3 \"$TOOL\" --root PROJECT check --summary\npython3 \"$TOOL\" --root PROJECT handoff --goal CLAIM\npython3 \"$TOOL\" --root PROJECT pin-impact PATH\npython3 \"$TOOL\" --root PROJECT record PROPOSAL.json\npython3 \"$TOOL\" --root PROJECT record-batch PROPOSALS.json --dry-run\npython3 \"$TOOL\" --root PROJECT record-batch PROPOSALS.json\npython3 \"$TOOL\" --root PROJECT ingest PACKET.json --dry-run\npython3 \"$TOOL\" --root PROJECT ingest PACKET.json\n```\n\n`pin-impact` is read-only; use it before editing a file pinned by many claims.\nThe two batch calls preview and then append distinct events. Read the compact\nbatch contract in [ledger.md](references/ledger.md) before using them.\n\n## When state is writable only later\n\nIf the host can inspect the repository and exact ledger head but cannot execute\nthe helper or write project files, and persistence is authorized, follow the\n[deferred handoff contract](references/deferred-handoff.md). Return one complete\n`mathbox-deferred-v1` packet with every new durable artifact needed by the\nproposed events, at most one guarded index entry, and a batch of proposals.\nCreate files and append entries only where the project's `.mathbox/config.json`\nopens them to deferred packets. Pin the packet to the exact inspected ledger\nevent ID and hash. Use batch aliases for new event references. Never invent\nevent IDs, artifact hashes, timestamps, or snapshots; the local ingest command\ngenerates them. Put the packet in the\nlast fenced `json` block, with no omissions or text after it. Distinguish the\nmathematical finding reached from the state actually recorded: until local\ningest succeeds, say explicitly that the packet has not been applied.\n\nInspect the actual evidence behind important statuses. A changed proof or\ndependency invalidates the affected evidence snapshot. A retracted dependency\nor current counterexample record blocks downstream proofs without rewriting\nhistory. Run `impact CLAIM` before revising a load-bearing statement.\n\n## Record only material changes\n\nInitialize `.mathbox/` only when the user has authorized useful project setup or\nstate tracking. Existing prose projects can keep their current format; the\nledger is optional. For a migration, follow [migration.md](references/migration.md).\n\nWrite a proposal JSON and use `record FILE`. A research session is not itself\nan event: record only mathematical state that changed. An already registered\nbounded route can close with one route-result when closure is justified;\nan unfinished attempt alone does not justify closure. Program/run lifecycle\nevents are for work that actually spans executors, branches, delayed returns,\nor sessions. Do not revise claims, repeat evidence, or add a review merely to\nmirror a route record.\nFor several necessary events, use `record-batch FILE` after its dry-run; this\nkeeps the event types separate while avoiding repeated whole-journal reads.\nRegister exact claims before their evidence and dependencies before consumers.\nWhen a manuscript or theorem file controls the claim wording, bind it with an\noptional `statement_artifact` and locator. Evidence needs durable artifact\npaths; the helper hashes them and\nrecords all transitive claim revisions. A source record needs an exact\nidentifier, version, locator and translation. A computation needs its\nassertion, bounds and non-claims. It never becomes a\nuniversal proof merely because its command succeeded.\n\nFor a computation manifest that declares hashed inputs and outputs, use the\noptional `manifest` field. The ledger then pins the manifest and its declared\nfile closure and checks that `claim_id` matches and the run completed. This is a\nfreshness/linkage check, not a replacement for the computation manifest\nvalidator or an audit of the mathematical interpretation.\n\nRecord separate review events linked to the exact evidence event and a durable\nreport. An independence declaration must describe a real fresh review; a\ndifferent actor name alone does not establish independence. The author cannot\ndeclare an independent audit of their own evidence. A failed review remains\nactive until explicitly retracted with a reason or replaced by new evidence.\nInspect the projected active review events and report paths, especially when\nconditional, failed and passing reviews coexist; a one-line review label is not\na substitute for those conditions.\n\nWhole-file bindings stale on any byte change, including typography. Prefer a\nstable claim-scoped artifact when it faithfully states the authoritative claim;\nuse `pin-impact` to see the declared fanout of an existing whole-file pin.\nNever refresh a hash on the strength of a formatting label alone.\n\nCorrect a claim by recording a new claim revision with a reason. Correct bad\nevidence/reviews with a retraction and new events. Never edit/delete numbered\nevents, refresh hashes merely to silence a warning, or reinterpret a changed\nstatement as already proved. Keep proof details outside the ledger.\n\n## Use routes to support decisions\n\nRecord a route's owning claim and, when different, the exact obligations it\n`resolves`, plus its mechanism, decisive question/test, prerequisites,\nsuccess/failure criteria and rough gain/cost estimates. Keep alternative routes\ndistinct from jointly required claim dependencies. `next` orders ready\nroutes by a transparent heuristic; use mathematical judgment over its ordering.\nSeparate an attempt's outcome from route closure. Close a route with its exact\noutcome, obstruction or scoped reason, and next question. Before closing an\nunresolved route, account for known continuations and explain why none remains\nexecutable within the route's stated scope. An inconclusive attempt, resource\nlimit or priority change alone does not justify closure. Keep untried or\ndeferred continuations in the route record and current handoff with their next\nsteps and resumption conditions. Reopening a closed route requires its prior\nresult and a `changed_input` addressing any recorded obstruction; resuming an\nopen route's unfinished work does not require a new mathematical input.\n\nFor sustained or parallel work, record a program and a distinct route run for\neach executor. Pin the ledger base event and external revision at which each run\nstarted; observations supply the last-seen revision, and run results close or\nabandon executions without automatically closing the mathematical route.\nReconcile an inconclusive run with `continue` when the route remains open,\nincluding when its next action is deferred; `next` and `handoff` show that\nreconciliation's next step and reason under the route. A later run uses the\nsame route ID. A route event cannot hold a deferred step: when a ledger route's\nunfinished continuation must survive to a later session, record the attempt as\na run with its result and a `continue` reconciliation. A prose record alone\nleaves the generated handoff showing only the route's original question. Do not\nadd run events to mirror an attempt whose follow-up finishes in the same\nsession. To correct an earlier premature closure that recorded no obstruction,\nuse the append-only reopening contract in [ledger.md](references/ledger.md);\nidentify the overlooked continuation rather than inventing new mathematics.\nRelabelling a `failed` result or recorded obstruction as premature does not\nreopen it.\nReconcile completed runs serially in the one writer's ledger. Record conflicts\nand give delayed results an explicit late disposition rather than reconstructing\nor merging numbered event streams. See [ledger.md](references/ledger.md) for the\nevent contracts.\n\n## Report and persist\n\nCommit ledger events with the corresponding proof/source/report artifacts only\nunder the project's Git authorization. Keep licensed/private source caches\nunder their own existing retention policy; the ledger stores references only.\nDo not create a second manually maintained claims dashboard. Prefer a generated\nview in the designated live status location when migration is authorized.\n\nReport changed claims, active review conditions and conflicts, stale evidence,\naffected dependents, and route-only context kept outside the theorem dependency\ngraph. A clean `check` means bookkeeping integrity and current artifact hashes,\nnot a proof audit.\nFor genuine correctness decisions, use the mathematical specialist workflow.\n"
}