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

58 lines
3.1 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.