rig 3.23.0

Add a timeline of how rig grew (#182)

Adds docs/timeline.md: rig's first ten days in six phases, each named by the capacity it added, with command, module and test counts at every major tag. Linked from the README's "Going deeper" list.

Docs-only branch, so no version bump.

Add a philosophy page: what rig's frictions taught (#183)

Adds docs/philosophy.md, linked from the README beside the timeline in place of the separate link to DESIGN.md's principles.

The timeline says how rig grew. This page says what those frictions taught, so someone deciding whether to use rig can read it in five minutes, and the next decision can be checked against it.

• One idea. What runs out first is the human's attention, and most of it goes either side of the implementation: deciding what to do next before it, and checking it got done after. rig spends less of it, and none on itself.
• Nine principles, each citing the friction or decision behind it: friction is the roadmap; trivial to start, deep to master; guide where you are; attention is the budget; facts in code, judgement in prompts; prove it or mark it, and say when; everything accretes; keep it refactorable; strong convictions, loosely held. The last two are DESIGN.md's principles, given one line each with a link to the full text there.
• What rig asks of an org. The same questions the page answers about rig: what you're trying to accomplish, what hurts now, what you believe, whose call it is.
• How it grows. By hand when a friction changes a belief, and from rig-learn at close. A dropped principle is struck through with the friction that killed it.

Docs only. No behaviour changes.

Unlink the symbolic HEAD in the gitfs test rather than rmSync it (#189)

On Node 25 on Windows, fs.rmSync returns without error on a dangling symbolic link and leaves it there. The test "a HEAD that is a symbolic link names the ref it links to" removes its first link that way, so the second symlinkSync fails with EEXIST. It fails on main on Windows with Node 25. CI runs Node 20 and 22, whose rmSync removes the link, so CI stayed green.

unlinkSync removes the link itself. Full suite: 1039 pass, 0 fail, 1 skipped, on Windows with Node 25.1.

Test only. No behaviour changes.

An org can say what it is trying to do, and every work reads it (#190)

An org can say what it is trying to do, and every work reads it

Tickets: #184

Direction

Agreed with Hugo, 2026-09-27.

• It lives at <data root>/orgs/<org>.md. It is a new top-level folder beside catalog/ and work/, because the doc is about the org and not about any repo. The org's name is its key in rig.json's orgs, the same name catalog/<org>/ already uses. Product areas can later go in orgs/<org>/ without touching the catalogue. The frontmatter holds only org:. Anything else would be state that git already answers, such as when the doc was last changed.
• A work reads the orgs of the repos attached to it. That is each distinct org among the work's repos, in the order they were attached. A work with no repos reads nothing. The next rig attach regenerates the file, so there is no gap to cover by also reading the ticket's org.
• The generated AGENTS.md inlines each doc in full. Each org gets a ## <org> section, with the doc's own headings nested one level below it and the file's path named as the only copy. The doc is meant to be short, and the point is that every session starts knowing it. A link is something agents skip. An org with no doc adds nothing to the file: no heading and no "none yet" line. A doc with nothing under its frontmatter counts as none. The doc's headings move so its shallowest lands under the org's, and a fence it leaves open is closed. A changed doc reaches a work on that work's next mutating command, like the catalogue lines beside it.
• rig status names each org's doc, or says there is none and where it would go. rig-learn reads this line to decide whether to ask the question. It also works once the work is closed and its folder is gone.
• #184 handles an org with no doc; #185 handles an org that has one. In #184, rig-learn asks one optional question, "what is this org trying to accomplish?", and only when the org has no doc. It asks in one line right after "Say go", naming every org with no doc, so there is no extra round-trip; a bare go skips it. An answer is written as a doc with only "What we're trying to accomplish" filled in. The other three headings are left out rather than stubbed, following the same rule as the context doc, and are written by hand until #185. The four headings are named exactly once, in AGENTS.md. A skip stores nothing, so the next review in that org asks again. Confirming, contradicting or adding to an existing doc, and the philosophy page as a home, belong to #185.
• The new-work prompt names the stated problem when a doc exists, once the repos are attached, because only then are the work's orgs known. It reads "What hurts now" and "What we're trying to accomplish" and says which one the work addresses, or says out loud that it addresses none. It never refuses a work on these grounds. Nothing changes when there is no doc.
• rig-data is not attached. rig-learn writes the doc into the data root the same way it writes catalogue corrections, and rig save --learned commits it. dotfiles is untouched.
• In the same PR: the "What rig asks of an org" section of docs/philosophy.md moves to the present tense, CONTEXT.md defines org doc, DESIGN.md §3 shows orgs/<org>.md, §7.4 shows the new part of the generated file, and a new decision records all of this.

Not done here: product areas, anything rig next, rig init or rig attach would offer, and any check in rig doctor.

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

Full changelog: v3.22.0...v3.23.0