Michał Kopeć
6c0d70976c
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>
96 lines
4.9 KiB
Markdown
96 lines
4.9 KiB
Markdown
# 2026-09-22 Session Summary
|
|
|
|
## [2026-09-22] Reset requested, then cancelled
|
|
|
|
`/ckb-reset` was invoked. Ran Step 0 (clean tree, restore point `2c4d57a`) and
|
|
the Step 2 inventory, which found this KB already effectively a clean template
|
|
— 0 entity pages, 0 project scopes, 0 decision records, 0 graph edges, nothing
|
|
in `raw/`, `outputs/`, `libs/`, `linked/` beyond `.gitadd` placeholders, no
|
|
modules installed, no `src/`. The only tier-1/2 content was 3 `wiki/log.md`
|
|
entries (the schema 1.5 migration trail) and one workload summary.
|
|
|
|
**Nothing was deleted.** The typed confirmation was never given — the user
|
|
moved on to merging and syncing instead. Flagged at the time: `main` was
|
|
already a clean template at schema 1.4, and clearing the log would leave the
|
|
scaffold declaring 1.5 with no in-wiki record of how it got there.
|
|
|
|
## [2026-09-22] Merge and sync
|
|
|
|
- Working tree was already clean; nothing to commit.
|
|
- `main` was an ancestor of `graft-ideas`, so the merge fast-forwarded — no
|
|
merge commit, both commits preserved individually, no conflicts.
|
|
- Pushed `main` (c998489 -> 2c4d57a) to **both** remotes: `origin`
|
|
(git.wierzbowa.cloud/michal/ckb) and `codeberg`
|
|
(codeberg.org/Valdec/llm-wiki-cascade).
|
|
- Schema 1.5 and template 1.8.0 are now the published state on both.
|
|
|
|
**Left alone deliberately:** branch `graft-ideas` (now identical to `main`,
|
|
safe to delete whenever), and branch `feature/external-source-connectors`,
|
|
which holds one commit (`f3dbce7`) not present on either remote and is
|
|
unrelated to this work.
|
|
|
|
## [2026-09-22] Reset executed — Tier 1
|
|
|
|
Re-ran `/ckb-reset` from the post-sync state (the earlier inventory could not
|
|
carry over: the counts had moved). Confirmed with the typed phrase, Tier 1 only.
|
|
|
|
- **Deleted:** 3 `wiki/log.md` entries — the schema 1.5 migration trail. That
|
|
was the whole of Tier 1; there were no entity pages, project scopes, decision
|
|
records or graph edges to remove.
|
|
- **Restored:** `wiki/log.md` to its header-and-format-example form. Nothing
|
|
else was rewritten — `index.md`, `overview.md`, `graph/index.md` and
|
|
`decisions/index.md` already matched what `ckb-init` produces at schema 1.5.
|
|
- **Deliberately not bumped:** `wiki/graph/edges.json` (`last_updated:
|
|
2026-09-20`, array already empty) and `wiki/overview.md` (`last_updated:
|
|
2026-09-21`). Both dates are accurate as they stand; bumping them would
|
|
assert changes that did not happen.
|
|
- **Preserved:** Tier 2 (both workload summaries), the entire template layer,
|
|
and schema 1.5 / template 1.8.0.
|
|
- **Verification:** lint returned 0 findings across `wiki/` and `libs/`.
|
|
- **Restore point:** `7d3fa54`, clean and pushed to both remotes before the
|
|
reset ran.
|
|
|
|
**Rule B exception.** The reset is a change inside `wiki/` and would normally
|
|
require a `wiki/log.md` entry. Logging "emptied the log" into the log it just
|
|
emptied defeats the purpose, so the record lives here instead — the same
|
|
reasoning `ckb-reset` applies to its Rule D exception. The migration this
|
|
removed from the log remains documented in `CHANGELOG.md` and in commits
|
|
`474630e`/`2c4d57a`, published on both remotes.
|
|
|
|
## [2026-09-22] Release channels — three branches, branch-aware init and upgrade
|
|
|
|
Added `test` and `experimental` branches alongside `main`, and taught
|
|
`ckb-init`/`ckb-upgrade` to source from any of them.
|
|
|
|
**Channel semantics:** `main` = stable/released, `test` = release candidate,
|
|
`experimental` = development. Default everywhere is `main`.
|
|
|
|
**Selection is per-invocation and sticky.** The user names a branch in words
|
|
("initialize from the test branch", "check experimental for updates", "switch
|
|
back to stable"); the choice is then persisted to `ckb.yaml`:
|
|
|
|
```yaml
|
|
template:
|
|
repo: https://git.wierzbowa.cloud/michal/ckb.git
|
|
branch: main
|
|
```
|
|
|
|
Persistence was a judgment call, not an explicit ask. Without it, a KB
|
|
bootstrapped from `experimental` would be silently pulled back to `main` by its
|
|
next upgrade — mixing channels without anyone noticing. Absent file or absent
|
|
block both mean `main`, so every pre-existing KB behaves exactly as before.
|
|
|
|
**The non-obvious consequence, handled explicitly:** a KB tracking `test` or
|
|
`experimental` can sit on a VERSION `main` has not released. Comparing against
|
|
`main` finds nothing newer, which the old code would have reported as "up to
|
|
date" — true but misleading. `ckb-upgrade` Step 2 now reports "ahead" instead,
|
|
and treats a move back to `main` as a downgrade requiring explicit
|
|
confirmation, blocked outright when `kb_schema_version` would drop below what
|
|
local content is written against.
|
|
|
|
**Files touched:** `ckb-init` (Step 3 channel table, Step 7 writes `ckb.yaml`,
|
|
Step 12 reports the channel), `ckb-upgrade` (new Step 0, Step 2 ahead-case,
|
|
Step 6 persists, Step 8 reports, 5 new edge cases), `ckb-module` (must not
|
|
clobber the `template:` block), `AGENTS.md` routing, both READMEs, both
|
|
MANUALs, both CHANGELOGs. VERSION 1.8.0 -> 1.9.0. Schema unchanged at 1.5 —
|
|
this is tooling, not a content contract.
|