michal/ckb
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ckb/workload/2026-09-22_summary.md
Michał Kopeć 6c0d70976c Add release channels: main, test, experimental 
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>
2026-09-22 08:29:45 +02:00

4.9 KiB
Raw Permalink Blame History

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:

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.