consolidate

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Consolidate

A hypothesis is a claim the base does not yet hold: a refused reading, a proposal not yet approved, a branch's record, a what-if. Nothing here decides for a person; the dry run tests, the fold and the refutation are the person's acts, recorded so the question never returns. Run `kpop` or `kpopper` from the native runtime and prefer the canonical executable in `KPOPPER_AGENT_CONTEXT.command`. Do not guess a path or silently use PATH.

In ordinary conversation, name the product **kpopper** and describe the action in the user's language. Reserve the exact skill name `kpopper:consolidate` for invocation instructions, technical documentation, debugging, or explaining this specific skill. Fold the product name into the explanation of the action; no extra announcement is needed.

One record is written by everyone, from any session or branch, as long as the write is consistent
with it. **A contradiction opens a hypothesis**, and the reader tells one by the id and the day.
`set` of a reading no newer than the base's (its `of:`, else its source's read date) that differs is
refused - two readings of one day that disagree are two writers, not the world moving; a newer
reading updates the base and flags what rests on it. `add` of an id the base holds is refused, and
with a different value or verdict it is a contradiction: a standing judgment is replaced in the base
only when its own `wrong_if` holds now, and otherwise the rewrite waits beside the record until a
person takes it by name at the fold (`--take <id>`). The same verdict on other grounds - another
why, other dependencies, another condition - is a decision written again and goes the same way. A
replacement that rests on less names each dependency it drops, with the reason: `--drop "<id>:
<why>"`. Every replacement leaves a trail - one `replaced:` line on the judgment, and the body it
replaced kept whole in `.kpopper/replaced.yaml` - so `open` and `check` say *reversed on <day>*
until someone reviews it, `set` of a reading only a replaced judgment listened to says so, and
`pull <id> --history` shows what stood before. A reading dated after today is refused: a day is
the record's clock. Nothing written into the body opens that door - every session's first write is a
source carrying what it was asked, so a field read as a person's authority would be a key every
session already holds. `request: s.<date>_<slug>` - a session source whose `asked:` is the person's
request verbatim, rested on - still names whose asking the change was taken from, said *on the word
of* on every surface: provenance the person weighs at the fold, and permission for nothing.
A write resting on what only a hypothesis holds belongs in that hypothesis. Each refusal names the
command that writes the same thing into `.kpopper/hypotheses/<name>.yaml` beside the record - the base
untouched - named after the id contradicted and a mark of the claim written, unless `--hypothesis
NAME` on `set`, `add` or `review` names it. The first write stamps `born` in the head; `claim:`, a
head `wrong_if:` and `folds: never` are the one thing a hand writes there. Three uses: a concurrent
writer whose reading was refused; a proposal not yet approved - a branch's record *is* this, and
travels with the branch; a what-if, `folds: never`, evaluated at every dry run and never written.

**The consolidation walk.** `consolidate --dry-run` lays the hypotheses named - every one, when none
is - over the base by id and runs the reader's own `check` on it, reported in a fixed order:
arrived, updates (the readings a hypothesis replaces, and what rests on each), reversed (a verdict,
or other grounds, over a standing judgment - both sides' because, rests_on and wrong_if beside each
other), moved / falsified, contested, candidates, new subjects. Three lists ask three answers, each
recorded by a command so the question
never returns: a candidate pair is the **same** subject (`same a b`) or **different** (`distinct a b
"why"`); a **contradictory** id - two hypotheses on one, or a reading the door refuses - is read
again on a later day, `set` in the base, or in the hypothesis that read it when the newer reading
bears its claim out but not its number, so the fold still carries what else it brought; or it is
refuted. The run exits non-zero on a contested id, a falsifier that holds, a hole, or a head
`wrong_if` it cannot decide; a premise that moved under a judgment leaves it green and blocks only
the fold, and `review <id> --hypothesis NAME` refreshes the snapshot against the record as it stands
under the hypothesis. `consolidate` runs the same test and, only when it is clean, writes the union
through the write path: every replacement passes the one door a `set` passes, asked with the base's
own readings, so a reading born of a same-day refusal waits until someone reads again on a later
day. A verdict, or other grounds, over a standing judgment is **reversed**: it folds when the base's
own condition has broken the judgment on what the base holds - a hypothesis that brings the reading
that breaks a judgment together with the verdict that repairs it has not broken it here, and the
report says its readings would - or when a person names it, `consolidate NAME --take <id>`; until
then the run is red and nothing folds. Taking by name is the person's act, and the session's part is
to put the decision in front of them in the words of the work - which verdict would replace which, on
what grounds, what it stops resting on - and ask whether it stands. On their word the session runs the
take itself and reports what folded. The command is the session's to run, never a request to the
person: a session that hands it over as their task has hidden the decision behind the mechanism. And
never take on the session's own word, the way the refusal into a hypothesis was built for. A
replacement that rests on less names each dropped dependency at the fold too, `--drop "<id>: <why>"`,
asked of the person the same way - why the decision stops resting on it - and run by the session.
A subject does not change kind at the fold - an entry under a judgment's id or the reverse, an
arrangement replaced by what is not one or a judgment that would become one - and no name takes
those: write it as its own decision. Across
the branch line a reading from another source than the base's, with another value, is contested the
same way; a review - the same decision, its seen refreshed - does not travel; a branch's record folds
onto a committed base only, and the fold ends with the commit that makes it a commit of its own. The
result is read back and undone whole if `check` then says anything new; what the fold replaced is
kept beside the record; the folded files go, and what to commit is printed.

**Pending findings, in the same run.** In an Advanced project a live dry run over every hypothesis -
none named, no `--from` - then lays each active finding of the pending ledger over the base alone,
under its own `pending` heading: the ids two findings hold differently, what accepting each would
change and break, and what only all of them together break. A finding that would falsify a judgment,
leave a hole, bring a reading the door refuses or reverse a standing verdict makes the run red, and
so does one the base cannot read as written, or would read its own judgments otherwise beside
(`check` names why a finding cannot be read at all); a premise it moves leaves it green. Nothing
adopts a finding and nothing else waits on it - the fold, commits and merges go on - and a frozen
run, which CI makes, has no pending part. Put what breaks in front of the person in the work's words
and ask whether the finding is right: a wrong one is rejected with their reason (`kpop pending reject
<revision> --reason "<why>"`, the revision from `kpop pending status`), run by the session; one that
stands is read again and `set` in the base, or accepted in the knowledge PR.

Before accepting a material consolidation, examine affected judgments for a failure that arises
only when the changes are combined, even if each change passes separately. Use the same
[failure search](../kpopper/references/falsifiers.md#look-for-a-failure-the-current-check-would-miss) to expose shared assumptions
or newly incompatible decisions. Record any resulting objection or additional condition, and
repeat the dry run after changing the record; a passing dry run covers the declared checks.

**One rule, two containers.** What stands is contested only by something recorded: a rival claim, in
a hypothesis; or a doubt with no rival value yet, an open question that names the id. The page says
*a hypothesis contests this arrangement*, or *a question* does, `check` notes the same, and both
stand until a person consolidates, or answers the question with `answer`. Deleting the file is neither,
and `correct` is no way around the fold: it refuses anything already landed.

**How a merge goes.** git merges the files: additions in id order rarely meet, and hypothesis files
meet only when two branches claim the same thing under one id, since the name carries both - two
readings that agree, and either head is the whole of them; two that disagree are two files git
merges, and which of them stands is the dry run's question for a person. The dry run tests the
result: the pull request runs it on the merged tree, and the push to `main` runs it again as the
second net, for two pull requests each consistent alone that contradict together. Fold a hypothesis
the dry run proves *before* the pull request, so `main` receives base changes; let an unproven one
merge as a file, and `main` carries an open hypothesis the opener counts. Nothing crosses branches
unasked: `pull <seed> --from <ref>` lays what another branch committed beside your pull, and
`consolidate --from <ref> --dry-run` tests its record as one more hypothesis named after the ref - a
pull, never a push, and how a dead branch's facts are harvested. Every write - `set`, `add`,
`review`, `same`, `distinct`, the fold, the refutation - takes an exclusive lock on the record's
directory where the platform has one - Windows has none - so two sessions on one file take turns
instead of the last one discarding the first. In the tree each worktree writes its own copy and git
merges them; out of the tree every worktree writes the one file, and only the lock stands between
them.

## The tree, measured against the record

`remeasure` is how the tree answers for the record. `check` compares `seen` against the record's
own stored value and never against the tree, so a count that is wrong about the tree passes as
long as it agrees with itself. An entry whose value is a fact about the tree - lines of a file,
files a package ships, places in the code where something is decided - names the recipe that
takes it, `measure: <name>`, and `.kpopper/measure.yaml` beside the record holds that name's

From ilanbm/kpopper, MIT.

More from ilanbm/kpopper