docs: the update how-to says the 10.0.0 settings migration is owed per checkout, so a second clone runs config migrate after its pull (#208 close)
CI / verify (push) Successful in 8m47s
CI / pwsh (push) Successful in 2m40s

Files changed:
- docs/how-to/update-an-instance.md

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2
This commit is contained in:
torbenandClaude Opus 5.5 committed 2026-10-11 10:23:05 +02:00
1 parent 7c8e9cea55
commit 298b514119
1 file changed
+9
+9
View File
@@ -93,6 +93,15 @@ old form. `doctor` keeps warning until the migration is done, and a later sessio
`tools/wikitool migrate status`. The agent never records a migration it did not carry out, because `tools/wikitool migrate status`. The agent never records a migration it did not carry out, because
the content's version would then describe a shape the pages are not in. the content's version would then describe a shape the pages are not in.
**A migration can also be owed per checkout.** Most migrations rewrite pages: they are done once,
and every other clone of the instance receives the result with its next pull. The 10.0.0 migration
moves settings instead, out of gitignored files that belong to one checkout, so a pull does not
carry it. After another clone has pulled the new release, run `tools/wikitool config migrate`
there too. Until then `doctor` reports each leftover file as a `FAIL`, and a command that needs
one of those settings stops with exit 42 and names that command. `migrate done` is still recorded
only once per instance
([10.0.0-settings-tiers.md](../../instructions/migrations/10.0.0-settings-tiers.md)).
If a step fails for a reason that isn't obvious, the agent stops and offers you a bug report rather If a step fails for a reason that isn't obvious, the agent stops and offers you a bug report rather
than improvising ([Troubleshoot](troubleshoot.md)). than improvising ([Troubleshoot](troubleshoot.md)).