NotesRecover proof boundary Exact proof ledger for repo truth, remote read-back, and manual tail.
Public proof

What you can prove today, what was read back remotely, and what still needs a human click.

Read this page like an accountant reads a ledger. Repo-side proof is the cash in hand, remote read-back is the bank statement, and the manual tail is the stuff still waiting on a human signature.

Repo-owned proof first Remote read-back second Manual tail explicit
Read order: start with the four-command proof path so you can see the workflow shape, the bounded AI layer, and the host boundary before you point the toolkit at a real copied-evidence run.
Proof path

Read it like a proof ledger

The command sequence below is the shortest honest route from curiosity to trust. 
notes-recovery demo
notes-recovery ai-review --demo
notes-recovery ask-case --demo --question "What should I inspect first?"
notes-recovery doctor
  1. 1
    demo

    Shows the case-root shape without touching live or private evidence.

  2. 2
    ai-review --demo

    Shows AI as a bounded review layer on derived artifacts.

  3. 3
    ask-case --demo

    Shows one evidence-backed question path with citations and uncertainty.

  4. 4
    doctor

    Shows the host boundary and whether to move from demo to a real run.

Proof router

Read this page through three reviewer questions.

This page gets stronger when it behaves like a ledger, not a wall of caveats. Start from the question you are actually asking.

What can the repo itself prove right now?

Stay on the repo-side proof cards and the shipped command path when you need repeatable evidence from tracked files and local commands.

What came back from a remote surface?

Read the remote read-back cards when the question becomes release feed, registry posture, or package boundary instead of repo implementation truth.

What still needs a human click or platform review?

Use the manual tail cards when the answer lives in GitHub settings, registry submission, social preview save, or a platform-side approval flow.

Layer 1

Repo-side proof

These are the facts the repository can prove on its own, without asking you to trust screenshots, folklore, or platform settings.

notes-recovery demo

Proves the public-safe case-root workflow shape without touching private evidence or a live Notes store.

notes-recovery ai-review --demo

Proves AI exists as a bounded review layer on derived artifacts.

notes-recovery ask-case --demo ...

Proves the repo can answer one bounded question with evidence refs, confidence, and uncertainty.

notes-recovery doctor

Proves the host boundary, optional surfaces, and safest next step are inspectable before a real run.

Layer 2

Remote read-back proof

This layer depends on fresh GitHub read-back. It is stronger than docs claims, but still weaker than repo-owned proof because platform state can drift.

Repository read-back

GitHub repository is public, points at the current Pages landing, and keeps the current product description aligned with the copy-first story.

Package and registry read-back

Fresh read-back exists for the PyPI package lane and the official MCP Registry entry that backs the current stdio-first MCP surface.

Secondary packet listing

The standalone public skill packet is live on ClawHub as a secondary lane. That supports discovery, but it does not replace the landing-first copy-first story.

Layer 3

Manual external tail

These are the truths that still require a human click, platform permissions, or owner-operated follow-through.

GitHub settings

Branch protection, discussions, social preview save state, and security settings still live in GitHub's own control plane.

Registry approval

Listing posture remains weaker than repo proof until the platform itself confirms the final state with fresh read-back.

Owner-operated follow-up

Anything that depends on marketplace submission, account ownership, or settings toggles stays outside the repo's self-proof envelope.

Reading aid

How to use this ledger without over-reading it

If you are arriving cold, do not read every paragraph. Read like a reviewer: prove the path, classify the claim, then decide if the question needs repo proof, remote proof, or a human click.

When the repo-side proof is enough

Use the repo-side layer whenever the question is about workflow shape, demo safety, AI review boundaries, case-root artifacts, or local MCP behavior.

When you should trust remote read-back instead

Use remote read-back when the question is about release feeds, registry posture, or public GitHub configuration that the repo itself cannot authoritatively store.

When the answer still lives in a manual tail

If the truth lives in settings, approval queues, or a platform-side button, keep it labeled as manual tail instead of pretending the repo already proved it.