Find the work you already repeat, and run it as a checked workflow.
polyness reads the journals an agent already writes, finds the steps you keep taking, proposes each one as a polyflow workflow carrying the rules your own history supports, and lets the admission gate decide whether it may run.
A proposal is not a description of what you do. It is what the rest of your history says you meant to.
The load-bearing words are the rest of your history. A rule with no support in your own work is not something you meant to do; it is something somebody else thinks you should. polyness will not propose one.
npm install
npx polyness auditNothing is installed, nothing is configured, and nothing leaves the machine. Journals are opened read-only.
$ polyness audit code-polysec
code-polysec · 12 sessions · 4,909 tool calls
git push 69 times
⚠ no-git-push-without-a-passing-verify
you did this 68 of 69 times, and it would have stopped the other 1
— measured across the session; 27 of 69 runs already did it inside one run
⚠ at-most-one-git-push-per-run
you did this 59 of 64 times, and it would have stopped the other 5
polyness audit --show git-push the 5, with what came before each
polyness audit --correct git-push if that is wrong for this project
git reset 2 times — under the floor of 5, so nothing is proposed
2 steps worth proposing as a workflow: git-push.
Then polyness propose git-push writes the contract, the mined rules and the
effect surface; polygen authors
the machine; polyflow's gate admits it or refuses it.
Getting started → · A worked example →
Measured over one machine's own Claude Code transcripts, of the 18 projects that push, 11 run a verification five or more times — and 8 of those 11 verify before pushing at or above the own-evidence floor.
Read the middle filter carefully, because it is doing the work. It separates "you forgot to test" from "this project has no tests". One project here pushes 8 times and runs zero verifications: it is not skipping a guard, it has no guard, and proposing one there would be importing an opinion rather than reporting a finding.
Among the projects that do test, verifying before pushing is already the norm — 99%, 98%, 100%, 88%. That is what makes the rule mineable as your standard rather than somebody's advice.
These are a snapshot of one machine on one day, and they move. Run
node scripts/table12.mjsfor yours.
The workflow worth proposing is the one you already run. The rule worth enforcing is the one your own majority already keeps.
| audit | what you repeat, and where the repetition already goes wrong |
| replay | score any rule — mined, admitted, or somebody else's — against your history |
| propose | emit a workflow proposal with the rules your history supports |
| suggest | notice you are inside a workflow you already have (an MCP tool) |
Every number is traceable. --show turns any figure into the journal
records behind it, in one command — timestamp, session, episode, the command,
and what came before it. §1.3 is why: one change to the regular expression
deciding what counts as a verification once moved a project from "7 pushes, 0
verified" to "14 pushes, 12 verified". The first number you see may be wrong,
and the only thing that makes the second believable is being able to check the
first.
Silence is an answer. Of 31 projects with tool calls on the machine this was built against, 5 have a step worth proposing and 26 do not — which the report says in those words. A tool that manufactures a finding for a project with nothing to say is worse than one that stays quiet.
A rule can be wrong, and your corpus is what says so. replay scores any
rule against your history before you adopt it, and re-scores it afterwards. A
rule in a prompt or a memory file cannot be checked against anything; a rule
that is a predicate over a path can. That is also what lets a rule be
retired — nobody ever deletes a line from a memory file, which is why they
rot.
$ polyness replay no-git-push-without-a-passing-verify
holds of verdict would block blocked-then-clean project
10 10 OWN 0 0 code-puffin
68 69 OWN 1 1 code-polysec
34 52 OWN 18 10 code-polysim
0 48 neither 48 41 code-kanjo
4 project(s) keep this rule; 6 do not.
Same rule, same corpus, opposite verdicts. §4.4.1 refuses to propose it on the
six; replay scores it on all ten — because proposing is a claim and scoring
is an observation.
src/reader.mjs journal files in, parsed lines out
src/normalise.mjs the alphabet (§4.2.1), redaction (§7), outcome classification
src/episodes.mjs a session is not a task
src/corrections.mjs what counts as a verification HERE — built before any number
src/subjects.mjs consequential events, and the two windows a rule is measured in
src/rules.mjs the four patterns, as a table
src/provenance.mjs own · borrowed · neither (§4.4.1)
src/replay.mjs score a rule; notice when it has gone stale
src/propose.mjs the proposal, minus the machine
src/recognise.mjs workflow_suggest, and the number it fails to beat
bin/polyness.mjs audit · replay · propose
proposals/verified-push/ is a workflow written by hand to exactly the shape
the miner emits, so the far end of the pipeline could be tested before the
mining existed. It is admitted by polyflow's gate at 5 paths, 8 states,
exhaustive — and test/step0.test.mjs weakens it the one way a careless author
would, so the gate has to refuse it and name the path.
polyflow's certificate says an admitted workflow will never order an
unverified push. That is true, and it is not the sentence a reader hears: the
machine is a checked advisor to an unchecked executor. polyflow's
adapters/claude-code/gate.mjs
closes it — a PreToolUse gate that denies a guarded step when no run is
waiting for it, so "unreachable in the machine" and "cannot happen" become one
statement. Its journal records every allow, every deny, and every override; a
denial you override is a labelled false positive, and it is the only
observation in the system that can tell a rule it is wrong.
- It does not author state machines. polygen does that; polyflow's gate rules on the result. polyness proposes and decides nothing.
- It does not read any journal but Claude Code's yet. The reader is an interface, and polyflow's own journal needs no reader at all.
- Recognition is weak, measured, and says so. §5.5 asks for right more often than wrong from a three-step prefix; on this corpus it is 1 right against 15. That number is in a test rather than in a sentence, so the v1 hooks have something to beat.
polyness depends on polyflow and never on polycrew: mining is a read-only batch with nothing to coordinate. polycrew enters at run time, if several sessions work the workflow polyness proposed.
npm install
npm test # 164 tests
node scripts/baseline.mjs --write # optional: measure your own corpustest/baseline.json is gitignored on purpose. It names every project directory
on the machine that produced it — which is nobody else's business, and no use
to anyone else either, because their corpus is a different one. The smoke test
skips without it.