The template repo now keeps three branches with fixed meanings — main is
stable, test is the release candidate, experimental is development — and
ckb-init/ckb-upgrade can source from any of them instead of only main.
Selection is per-invocation, in words the user already uses ("initialize
from the test branch", "check experimental for updates", "switch back to
stable"), and sticky: the resolved repo and branch are written to a
template: block in ckb.yaml. Without persistence, a KB bootstrapped from
experimental would be silently pulled back to main by its next upgrade.
A missing file or missing block both mean main, so every KB predating
this convention behaves exactly as before.
One consequence needed explicit handling. A KB tracking test or
experimental can sit on a VERSION main has not released yet, so comparing
it against main finds nothing newer — which the version check would have
reported as "up to date". That is true and misleading. ckb-upgrade now
reports it as "ahead", and treats a move back to main as a downgrade:
explicitly confirmed, with the specific losses named, and blocked
outright where kb_schema_version would drop below what local pages are
already written against.
ckb-module is told not to clobber the template: block — a module install
that silently reset a KB's channel would change what its next upgrade
pulls, which is not a module's business.
Documented in both READMEs, both MANUALs and both CHANGELOGs. VERSION
1.8.0 -> 1.9.0; kb_schema_version stays 1.5, since this is tooling rather
than a content contract.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Clears the 3 wiki/log.md entries recording the schema 1.4 -> 1.5 migration.
That was the entirety of Tier 1 content: no entity pages, project scopes,
decision records or graph edges existed to remove.
Only wiki/log.md changed. The other scaffold files already matched what
ckb-init produces at schema 1.5, and edges.json/overview.md keep their
existing last_updated dates because those dates are accurate — bumping them
would assert changes that did not happen.
Rule B would normally require a wiki/log.md entry for a change inside wiki/,
but writing "emptied the log" into the log it just emptied defeats the
reset. The record is in workload/2026-09-22_summary.md instead, and the
migration itself remains documented in CHANGELOG.md and in commits 474630e
and 2c4d57a.
Tier 2 (workload summaries), the template layer, schema 1.5 and template
version 1.8.0 are all preserved. Lint: 0 findings.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Records the cancelled reset (inventory run, nothing deleted) and the
fast-forward merge of graft-ideas into main pushed to both remotes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
