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ć d66ebf6972 Reset wiki to clean template scaffold (Tier 1) 
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>
2026-09-22 06:55:19 +02:00

3.1 KiB
Raw 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.