{"id":41222,"plugin_id":"plugins_6a9174204a0481918ca3798d69d2e227","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T12:58:02.517Z","digest":"f77c5fd5f8ce7c6f6a21c90a80a2d31755787797d3ff95a9f679787b07fc3283","against":19082,"payload":{"description":"Read or update a local append-only .mathbox ledger of exact claims, evidence revisions, dependency impact, review provenance, routes and parallel or delayed runs. Use when the user asks to set up, check, record in or reconcile such a ledger, detect stale evidence, or generate its dependency-aware handoff. Do not use merely because a ledger exists, for a casual math question, as a substitute for proof auditing, or for a prose retrospective from status files.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":323},{"relative_path":"evals/evals.json","size_in_bytes":16031},{"relative_path":"evals/trigger-evals.json","size_in_bytes":2462},{"relative_path":"references/deferred-packet.md","size_in_bytes":6691},{"relative_path":"references/executions.md","size_in_bytes":5286},{"relative_path":"references/ledger.md","size_in_bytes":17889},{"relative_path":"references/migration.md","size_in_bytes":2142},{"relative_path":"scripts/research_state.py","size_in_bytes":82844},{"relative_path":"scripts/test_research_state.py","size_in_bytes":75371}],"name":"research-state","skill_md_contents":"---\nname: research-state\ndescription: >-\n  Read or update a local append-only .mathbox ledger of exact claims, evidence revisions, dependency impact, review provenance, routes and parallel or delayed runs. Use when the user asks to set up, check, record in or reconcile such a ledger, detect stale evidence, or generate its dependency-aware handoff. Do not use merely because a ledger exists, for a casual math question, as a substitute for proof auditing, or for a prose retrospective from status files.\n---\n\n# Executable research state\n\nFollow project authority rules. The ledger checks recorded evidence, artifact\nfreshness and dependencies, not mathematical truth. `proof-recorded` describes\nbookkeeping rather than a theorem proved under the project's vocabulary.\nApply project promotion and approval policy separately; review status remains\nseparate from evidence.\n\nRead [ledger.md](references/ledger.md) before interpreting labels or recording\nevents. Resolve [research_state.py](scripts/research_state.py) as `TOOL` in this\ninstalled skill. All artifact paths are relative to the project supplied with\n`--root`; put `--json` before the subcommand for complete structured output.\n\n## Read before changing state\n\nFor initialized state, start with `check --summary`, then `handoff --goal CLAIM`\nfor a registered goal. Without a registered goal use `status`, or an unfiltered\n`handoff`. Check summaries contain counts and sampled issues with omitted counts;\nbrief status/handoff views also list live, stale and unreconciled runs needing\nattention. Open `--full` details only for relevant contracts, reviews or issues;\ncompare complete issue lists when a change could hide a new issue in the sample.\n\n```bash\npython3 \"$TOOL\" --root PROJECT check --summary\npython3 \"$TOOL\" --root PROJECT status\npython3 \"$TOOL\" --root PROJECT handoff --goal CLAIM\npython3 \"$TOOL\" --root PROJECT impact 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`status`, `check`, `impact`, `pin-impact`, `next` and `handoff` are read-only and\nnever initialize state. Create an authorized new project, initialize and register\nclaims before querying its goal. Inspect actual proof/source/computation artifacts\nbehind important labels. Changed proofs or dependencies invalidate snapshots;\nretracted dependency evidence or current counterexamples block downstream proofs\nwithout rewriting history. Run `impact CLAIM` before revising a load-bearing\nstatement and `pin-impact PATH` before editing a pinned file.\n\n## When state is writable only later\n\nWhen persistence is authorized and the host can inspect the exact ledger head\nbut cannot execute or write, follow [deferred-packet.md](references/deferred-packet.md).\nNever invent IDs or hashes. Return the complete packet in the final JSON fence\nand say it is unapplied; obey the inspected local write policy.\n\n## Record only material changes\n\nInitialize `.mathbox/` only for useful, authorized setup or state tracking;\nexisting prose projects may keep their format. Follow [migration.md](references/migration.md)\nfor adoption. A session alone needs no event. Record changed contracts, evidence,\nreviews and justified route outcomes, rather than duplicating route narratives.\nProgram/run lifecycle events serve work spanning executors, branches, delayed\nreturns or sessions.\n\nWrite ordinary proposals with `type`, `actor` and `payload`; use `record FILE`,\nor preview a dependency-ordered `record-batch` before appending distinct events.\nUnknown payload keys are rejected on new writes; existing journals still replay.\nRegister dependency claims before consumers and exact claims before evidence.\nBind authoritative wording with `statement_artifact` and locator when useful.\nThe helper hashes durable artifacts and captures transitive claim revisions;\nnever supply generated snapshots. Source evidence needs exact identifier,\nversion, locator and translation. Computation evidence needs assertion, bounds\nand non-claims; successful execution is not a universal proof.\n\nA `manifest` links a version-2 computation record, its hashed input/output closure,\nmatching `claim_id`, and completed run. Validate it with computation-audit first:\nlinkage checks do not validate its scientific interpretation. Version-1 manifests\nmay be pinned only as ordinary artifacts, without automatic closure.\n\nRecord reviews separately against exact evidence and a durable report. Genuine\nindependence requires fresh review of raw evidence; a different actor name alone\nis insufficient, and an author cannot independently audit their own evidence.\nInspect active review objects and reports when passing, conditional and failed\nreviews coexist. Failed or conditional reviews remain challenges even if their\nreports disappear. Resolve them through an explicit justified retraction or\nactually revalidated replacement evidence, never a silent hash refresh.\n\nWhole-file pins stale on any byte change, including typography. Prefer faithful,\nstable claim-scoped artifacts where available; inspect fanout with `pin-impact`.\nRevise a claim with a new revision and reason. After real revalidation, record new\nevidence with `supersedes: [old IDs]`; retract only erroneous evidence or review\nrecords. Keep proof details outside the ledger. Never edit/delete numbered events,\nrefresh hashes to silence warnings, or treat a changed statement as already proved.\n\n## Use routes to support decisions\n\nRecord owning claim, optional `resolves` obligations, mechanism, decisive question\nand discriminator, prerequisites, success/failure criteria and rough gain/cost.\nSeparate alternative routes from jointly required theorem dependencies. `next`\nranks ready recorded routes heuristically; mathematical judgment sets priority.\nRepeated owner/mechanism pairs require the documented reopening contract, not\nrenaming to evade it.\n\nSeparate attempt outcome from route disposition. Inconclusiveness, resource limits\nor priority changes never alone justify closure. Preserve untried or deferred\ncontinuations with next action and resumption condition. Close only with the exact\nobstruction or scoped reason no continuation remains. Reopening rules and event\nfields are in [executions.md](references/executions.md) and the ledger reference.\n\nWhen an open route's continuation must outlive this session, use an existing open\nprogram whose goal covers it, or register one if absent. Record missing\n`route-run`, `run-result` and `route-reconcile` events with `decision: continue`,\nreusing applicable records. Cited runs and their reconciliation share `base_event`\nand `base_revision`; a run result inherits its base through its run and has no\nbase fields. The program retains its starting checkpoint, which may differ from\na later execution's base. `next` and `handoff` show the latest continuation's\nreason and next step. A prose record alone cannot update that generated view.\nDo not add lifecycle events solely for follow-up completed in the same session.\n\nFor parallel/delayed work, assign distinct executions with owner, actual inputs,\nbase and write scope. Reconcile serially in the single writer's ledger, record\nconflicts, and disposition late results explicitly. Arrival order is not ancestry;\nnever merge or renumber event streams. Process completion does not close a route\nor promote a claim.\n\n## Report and persist\n\nCommit events with their artifacts only under project Git authorization. Preserve\nsource-cache retention policy. Use one designated live view, preferably a generated\nbrief view when migration is authorized; do not create a parallel manual dashboard.\nReport changed claims, active review conditions/conflicts, stale evidence,\ndependents and route-only context. A clean check establishes bookkeeping integrity.\nUse available `proof-audit`, `computation-audit` or `literature-check` skills\n(`mathbox:<name>` in plugin installations) for correctness decisions, or perform\nthe relevant bounded check directly and disclose limits if unavailable.\n"},"changes":[{"path":"/description","type":"changed","before":"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.","after":"Read or update a local append-only .mathbox ledger of exact claims, evidence revisions, dependency impact, review provenance, routes and parallel or delayed runs. Use when the user asks to set up, check, record in or reconcile such a ledger, detect stale evidence, or generate its dependency-aware handoff. Do not use merely because a ledger exists, for a casual math question, as a substitute for proof auditing, or for a prose retrospective from status files."},{"path":"/included_files","type":"changed","before":[{"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}],"after":[{"relative_path":"agents/openai.yaml","size_in_bytes":323},{"relative_path":"evals/evals.json","size_in_bytes":16031},{"relative_path":"evals/trigger-evals.json","size_in_bytes":2462},{"relative_path":"references/deferred-packet.md","size_in_bytes":6691},{"relative_path":"references/executions.md","size_in_bytes":5286},{"relative_path":"references/ledger.md","size_in_bytes":17889},{"relative_path":"references/migration.md","size_in_bytes":2142},{"relative_path":"scripts/research_state.py","size_in_bytes":82844},{"relative_path":"scripts/test_research_state.py","size_in_bytes":75371}]},{"path":"/skill_md_contents","type":"changed","before":"---\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","after":"---\nname: research-state\ndescription: >-\n  Read or update a local append-only .mathbox ledger of exact claims, evidence revisions, dependency impact, review provenance, routes and parallel or delayed runs. Use when the user asks to set up, check, record in or reconcile such a ledger, detect stale evidence, or generate its dependency-aware handoff. Do not use merely because a ledger exists, for a casual math question, as a substitute for proof auditing, or for a prose retrospective from status files.\n---\n\n# Executable research state\n\nFollow project authority rules. The ledger checks recorded evidence, artifact\nfreshness and dependencies, not mathematical truth. `proof-recorded` describes\nbookkeeping rather than a theorem proved under the project's vocabulary.\nApply project promotion and approval policy separately; review status remains\nseparate from evidence.\n\nRead [ledger.md](references/ledger.md) before interpreting labels or recording\nevents. Resolve [research_state.py](scripts/research_state.py) as `TOOL` in this\ninstalled skill. All artifact paths are relative to the project supplied with\n`--root`; put `--json` before the subcommand for complete structured output.\n\n## Read before changing state\n\nFor initialized state, start with `check --summary`, then `handoff --goal CLAIM`\nfor a registered goal. Without a registered goal use `status`, or an unfiltered\n`handoff`. Check summaries contain counts and sampled issues with omitted counts;\nbrief status/handoff views also list live, stale and unreconciled runs needing\nattention. Open `--full` details only for relevant contracts, reviews or issues;\ncompare complete issue lists when a change could hide a new issue in the sample.\n\n```bash\npython3 \"$TOOL\" --root PROJECT check --summary\npython3 \"$TOOL\" --root PROJECT status\npython3 \"$TOOL\" --root PROJECT handoff --goal CLAIM\npython3 \"$TOOL\" --root PROJECT impact 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`status`, `check`, `impact`, `pin-impact`, `next` and `handoff` are read-only and\nnever initialize state. Create an authorized new project, initialize and register\nclaims before querying its goal. Inspect actual proof/source/computation artifacts\nbehind important labels. Changed proofs or dependencies invalidate snapshots;\nretracted dependency evidence or current counterexamples block downstream proofs\nwithout rewriting history. Run `impact CLAIM` before revising a load-bearing\nstatement and `pin-impact PATH` before editing a pinned file.\n\n## When state is writable only later\n\nWhen persistence is authorized and the host can inspect the exact ledger head\nbut cannot execute or write, follow [deferred-packet.md](references/deferred-packet.md).\nNever invent IDs or hashes. Return the complete packet in the final JSON fence\nand say it is unapplied; obey the inspected local write policy.\n\n## Record only material changes\n\nInitialize `.mathbox/` only for useful, authorized setup or state tracking;\nexisting prose projects may keep their format. Follow [migration.md](references/migration.md)\nfor adoption. A session alone needs no event. Record changed contracts, evidence,\nreviews and justified route outcomes, rather than duplicating route narratives.\nProgram/run lifecycle events serve work spanning executors, branches, delayed\nreturns or sessions.\n\nWrite ordinary proposals with `type`, `actor` and `payload`; use `record FILE`,\nor preview a dependency-ordered `record-batch` before appending distinct events.\nUnknown payload keys are rejected on new writes; existing journals still replay.\nRegister dependency claims before consumers and exact claims before evidence.\nBind authoritative wording with `statement_artifact` and locator when useful.\nThe helper hashes durable artifacts and captures transitive claim revisions;\nnever supply generated snapshots. Source evidence needs exact identifier,\nversion, locator and translation. Computation evidence needs assertion, bounds\nand non-claims; successful execution is not a universal proof.\n\nA `manifest` links a version-2 computation record, its hashed input/output closure,\nmatching `claim_id`, and completed run. Validate it with computation-audit first:\nlinkage checks do not validate its scientific interpretation. Version-1 manifests\nmay be pinned only as ordinary artifacts, without automatic closure.\n\nRecord reviews separately against exact evidence and a durable report. Genuine\nindependence requires fresh review of raw evidence; a different actor name alone\nis insufficient, and an author cannot independently audit their own evidence.\nInspect active review objects and reports when passing, conditional and failed\nreviews coexist. Failed or conditional reviews remain challenges even if their\nreports disappear. Resolve them through an explicit justified retraction or\nactually revalidated replacement evidence, never a silent hash refresh.\n\nWhole-file pins stale on any byte change, including typography. Prefer faithful,\nstable claim-scoped artifacts where available; inspect fanout with `pin-impact`.\nRevise a claim with a new revision and reason. After real revalidation, record new\nevidence with `supersedes: [old IDs]`; retract only erroneous evidence or review\nrecords. Keep proof details outside the ledger. Never edit/delete numbered events,\nrefresh hashes to silence warnings, or treat a changed statement as already proved.\n\n## Use routes to support decisions\n\nRecord owning claim, optional `resolves` obligations, mechanism, decisive question\nand discriminator, prerequisites, success/failure criteria and rough gain/cost.\nSeparate alternative routes from jointly required theorem dependencies. `next`\nranks ready recorded routes heuristically; mathematical judgment sets priority.\nRepeated owner/mechanism pairs require the documented reopening contract, not\nrenaming to evade it.\n\nSeparate attempt outcome from route disposition. Inconclusiveness, resource limits\nor priority changes never alone justify closure. Preserve untried or deferred\ncontinuations with next action and resumption condition. Close only with the exact\nobstruction or scoped reason no continuation remains. Reopening rules and event\nfields are in [executions.md](references/executions.md) and the ledger reference.\n\nWhen an open route's continuation must outlive this session, use an existing open\nprogram whose goal covers it, or register one if absent. Record missing\n`route-run`, `run-result` and `route-reconcile` events with `decision: continue`,\nreusing applicable records. Cited runs and their reconciliation share `base_event`\nand `base_revision`; a run result inherits its base through its run and has no\nbase fields. The program retains its starting checkpoint, which may differ from\na later execution's base. `next` and `handoff` show the latest continuation's\nreason and next step. A prose record alone cannot update that generated view.\nDo not add lifecycle events solely for follow-up completed in the same session.\n\nFor parallel/delayed work, assign distinct executions with owner, actual inputs,\nbase and write scope. Reconcile serially in the single writer's ledger, record\nconflicts, and disposition late results explicitly. Arrival order is not ancestry;\nnever merge or renumber event streams. Process completion does not close a route\nor promote a claim.\n\n## Report and persist\n\nCommit events with their artifacts only under project Git authorization. Preserve\nsource-cache retention policy. Use one designated live view, preferably a generated\nbrief view when migration is authorized; do not create a parallel manual dashboard.\nReport changed claims, active review conditions/conflicts, stale evidence,\ndependents and route-only context. A clean check establishes bookkeeping integrity.\nUse available `proof-audit`, `computation-audit` or `literature-check` skills\n(`mathbox:<name>` in plugin installations) for correctness decisions, or perform\nthe relevant bounded check directly and disclose limits if unavailable.\n"}],"summary":"Fields changed: 3. /description, /included_files, /skill_md_contents.","summary_kind":"deterministic","summary_metadata":{}}