docs(meta): fork-for-sidequests rule + wiki skill corrections from the cold test

The cold test worked as an experiment: a fresh agent with Skill(wiki) cited it first, refused to hand-edit body frontmatter, knew the corp regen-db stamp trap, and knew corp_specialization is missing from its own template. It also found four things the skill had wrong or missing, all verified before folding in: body frontmatter is a MIDDLE layer (atlas CLI -> systems.db -> scaffold writes the page -> import_economics reads it back), not the origin GOVERNANCE.md implies; the four empty categories are Q-118, an open scope question rather than an invitation; some bodies are visual-regression goldens and nothing in wiki/ says so; and status is editorial, not an import gate. Also: check current state before editing, since the test's own task described a change that was already true.

T-1244 corrected in the same pass — tectonics is derived from planet_class via a lookup (body_definition_parser.py:563), so the measured 68% 'low' is a projection of the class distribution, not an authoring choice. The ticket's question changed accordingly.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.claude/rules/fork-for-sidequests.md

@@ -0,0 +1,50 @@
+# Fork for side quests
+
+A side quest is work that is worth doing but is not the task in hand: filing a
+ticket, writing up a finding, chasing a tangent, a docs pass. Doing it inline
+costs the main thread its context — which is why forward intent tends to go
+unrecorded at all (T-1245).
+
+**Default: fork it.** Spawn an agent from the frozen context, keep working.
+
+## Fork when
+
+- Writing or appending a ticket, especially a long one.
+- Recording a finding that is real but off the current path.
+- An investigation whose ANSWER matters but whose SEARCH does not — "does X
+  exist", "who else calls this", "is this documented anywhere".
+- Anything you catch yourself deferring with "I'll note that later". Later is
+  where notes die.
+
+## Do NOT fork when
+
+- It is on the critical path — if the current task blocks on the answer, do it
+  inline and keep the reasoning visible.
+- It needs a judgement only the lead has context for (a design call, a trade-off
+  the user has been steering).
+- It is one command. A fork costs more than the work.
+
+## The report contract — required, and brief
+
+Every fork returns exactly this, in this order. Long reports defeat the purpose;
+the lead is mid-task.
+
+1. **STATUS** — one line: done / blocked / partial, and the outcome.
+2. **FILES TOUCHED** — every path created or modified, or `none`. This is not
+   optional. The lead has to know what is in the working tree before staging,
+   and an unreported edit turns into a mystery diff at commit time.
+3. **ISSUES** — anything found that is wrong, missing or surprising. One line
+   each. `none` is a valid and welcome answer.
+4. **FRICTION** — what was hard to find, misleading, or only found by luck. This
+   is the docs/skills feedback loop; a fork that hit a wall silently wastes the
+   evidence.
+
+## Git discipline
+
+Forks do not commit. `.claude/hooks/git-centralize-guard.sh` already blocks
+`.git`-mutating commands for teammates, so this is enforced rather than trusted —
+but the FILES TOUCHED line is what makes it workable, because the lead is the one
+who stages and has to know what changed and why.
+
+If a fork's work should not land in this branch at all, say so in STATUS rather
+than leaving the lead to discover it in `git status`.