ledger-disposition
Skill0 starsChanged 58 days agoMITView on GitHub
Use when populating or reviewing the contract-check ledger, when a row's check flips, when choosing among CONFORMS, GAP, VIOLATION, OPEN-PINNED, NOT-ASSERTABLE, EXCLUDED (or DIVERGED, for someone else's contract), or when a red row must point at a queue item. Reports each row in the five plain words a person reads — Kept · Not yet · Broken · Pinned open · Can't check. Applies documents.v1 §10 and PROTOCOL.md §3.3; full syntax in docs/LEDGER-FORMAT.md.
In this repository6 other files it gives its agents.
- AGENTS.mdAGENTS.md
- conformance/documents/fixtures/sample-good/AGENTS.mdAGENTS.md
- freeze-barSkill
- lane-briefSkill
- proposing-a-changeSkill
- seam-testSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 68
Coverage tripwires: run every time: every required clause of every locked contract is cited by at least one row.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Verdicts on the contract check
The contract check — the ledger — is one row per checkable promise, derived from the contracts themselves and re-run after every change lands. It is the ratchet: progress only clicks forward.
Rows are derived from contracts. Never invent a row that no clause backs.
Semantics live in docs/PROTOCOL.md §3.3; syntax and invariants in
docs/LEDGER-FORMAT.md. This skill summarizes; those govern.
The verdicts, and what a person reads
The ledger keeps precise internal words. Everything shown to the intent steward uses the five plain ones.
| Internal | Plain word | Meaning | Consequence |
CONFORMS | Kept | the check passes | none |
GAP | Not yet | the contract requires it; nothing implements it | a queue item |
VIOLATION | Broken | what exists contradicts a locked promise | a queue item — or a proposal to change the contract, if the evidence says the promise is wrong |
OPEN-PINNED | Pinned open | undecided; current behavior is pinned by a check without pretending a decision was made | a row, revisited when the direction is next discussed |
NOT-ASSERTABLE | Can't check | no machine check is possible; judgment only, named as such | reviewed on a cadence, never silently trusted |
EXCLUDED | Kept while absent, Broken the moment it appears | the contract forbids it | presence is a violation |
For contracts someone else owns, docs/LEDGER-FORMAT.md §3 adds DIVERGED
— a decided, recorded departure from an upstream spec this team does not
control. It needs a cited decision, and it reads to a person as Broken, on
purpose, with the decision attached. It is illegal for a contract we own: if
we own it and disagree with it, the move is a proposal
(<contract>.vN-candidate.md), not a recorded divergence.
Drift runs both ways
Moving away from a locked promise is drift. Silently moving back toward it from a pinned behavior is also drift — the second kind is the one everyone forgets. Any change in the relationship between contract and reality that cannot be traced to a ratified proposal or a filed item gets a row.
What a row carries
id— stable forever; never renumbered, never reused. Queue items and proposals cite it.contract.quote— the binding anchor. Verbatim, checked against the contract's actual bytes. Line numbers are informational, never asserted.assertion.kind—probe(its own check; prefer this wherever the row matters) ·indexed(cites existing tests, verified to exist) ·absence(makesEXCLUDEDrunnable) ·none(legal only forNOT-ASSERTABLE).justification— required forOPEN-PINNEDandNOT-ASSERTABLE.work— the queue ref, required forGAPandVIOLATION. A red row with no filed item is a ledger that lies.
Two standing integrity rules
- The SYNC row (
<PREFIX>-000) pins the contract files by content hash. A mismatch means the whole ledger is re-reviewed — never a silent hash bump. - Coverage tripwires run every time: every required clause of every locked contract is cited by at least one row; every divergence and every ratified proposal is cited; every quote still verifies; every Not yet and Broken row carries a live queue ref.
The honest limit
Verifying a quote proves the text exists, not that the row reads it correctly. Verifying a cited test proves the test exists, not that it still asserts the claim. Where a row is load-bearing, give it its own check.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.