rig 3.24.0

Check that every list of a data root's contents names all of it (#191)

rig lists what a data root holds in six places: AGENTS.md's three roots, DESIGN.md §3 and §9, the README diagram, the README rig init writes into a new data root, and the rig skill. When #190 added orgs/, four of them were missed, and only an adversarial review caught it.

test/data-root-lists.test.mjs now checks each one. Every list is found by an anchor in the text around it and must name the catalogue, the org docs, the work records and rig.json, as paths or as prose depending on the list. A list the test can't find fails, rather than passing on nothing, so rewording one means pointing the test at it again in the same PR.

Checked against the README as it was before #190: the diagram test fails.

Test only, so the test/ branch asks for no release.

A lesson from the rig work that shipped #184.

rig-learn grows the org doc, and rig's own philosophy, from what a work taught (#194)

rig-learn grows the org doc, and rig's own philosophy, from what a work taught

Tickets: #185

Direction

Agreed with Hugo, 2026-09-28.

• The org doc is the one place rig-learn writes prose that every session reads, and the exception is stated. rig-learn's rule is "never add a rule to an AGENTS.md", and the org doc is inlined into every generated one. It is allowed because it is the org speaking about itself rather than rig inventing a rule, and because every review corrects it: a line a work showed wrong is retired then and there. The rule it borrows from checks still holds: when a proposed org doc edit could be a check, the check is offered first, in the repo or the catalogue, and only a belief nothing can check goes in the doc. rig-learn and DESIGN.md both say so.
• In the review, proposed edits plus one optional line. The agent reads the story against each org doc the work touches and proposes concrete edits as ordinary lessons, under an Org doc section: retire a "What hurts now" line the work resolved, reword a belief the work had to bend, add what it taught. They can be in the TL;DR and ride on "go". Then one optional line, below "Say go…", for what only the user knows: "Did this work confirm, contradict or add to anything in the org doc? A bare go skips it." It is asked only where a doc exists; #184's one-sentence question still covers an org without one, and the two are never both asked for the same org. Corrected before appended to, like the catalogue.
• docs/philosophy.md is for beliefs about rig the tool, never about the repos a work used. A lesson about rig that changes a belief, rather than reporting a bug, goes there instead of the tracker. When rig is attached, the edit goes in the work's rig PR like any repo lesson. When it is not, it becomes an issue on rig titled "Philosophy: …" carrying the proposed wording, and the page is edited from it later. Either way the tracker's rule applies: rig alone, no private names. A dropped principle is struck through with the friction that killed it.
• The public/private split in an org doc is just prose. rig-learn reads the doc whole and the agent applies it; rig does not model repo visibility. Product areas (#188) are where that would go.
• No code change is expected. rig status already names each org's doc. What changes is the skill, the philosophy page's "How this page grows", AGENTS.md's lesson-review paragraph (rule 4 lists the homes) and DESIGN.md.

Not done here: anything rig next offers, product areas, and machine-checking a belief (that is step 6 of #187).

Context doc: https://github.com/hugoforte/rig-data/blob/main/work/org-doc-grows/context.md

Full changelog: v3.23.0...v3.24.0