DECISION (Elazar): make ~/Documents/terminal/one-db its own git repo? bin (PM) owns the call

Sub-tickets

Activity

• wi-cli-whey created · 2026-06-06
  parent=#697
• wi-cli-whey note · 2026-06-16
  INPUT for the repo decision: one-db source is fragmented 3 ways as of 2026-06-15 — (1) schema.sql in sh.git ~/.local/bin/one-db/, (2) kpi-web app now also in sh.git ~/.local/bin/one-db/kpi-web/ (b1d0498), (3) DESIGN.md + backfill.sh in a LOCAL-ONLY repo ~/Documents/terminal/one-db (no remote = not backed up off-whey). Decision should converge these; the local-only repo's lack of a remote is the real risk to resolve.
• wi-cli-whey completed · 2026-08-19
  CLOSED as done, not cancelled: the decision this row existed to make was taken and executed. ~/Documents/terminal/one-db IS a git repo; initial commit 51579a4 (2026-06-06 08:55) cites ONEDB-7 by ref in its own message, so the call was made the same day the row opened and the row was simply never closed. Confirmed independently on whey: 1 commit, 2 tracked files (DESIGN.md, backfill.sh), 0 remotes, clean status, nothing since 2026-06-06. NOT leaving it open as implementation work, which was the alternative offered. The 'is a bare repo enough, or does it need a remote and the schema/scripts tracked?' follow-on is NOT whey's to judge: the one-db PM lane was divested 2026-07-12 and the workstream's ownership sits with venus (nw-venus-cc roles/host, bin-venus-cc app/schema). Re-opening this row as whey implementation work would mean whey re-taking a lane it explicitly gave up. If more one-db versioning is wanted, it is a venus-filed row, not this one. Also note what the repo actually holds, which caps how much the open question was ever worth: DESIGN.md is the design record of a COMPLETED migration and backfill.sh is a one-shot for a backfill that already ran. There is no ongoing one-db work on whey to version - the capture probes were deleted 2026-07-02 (sh.git abd2f82) and the canonical DB is venus's. One residual, stated rather than actioned: 0 remotes means there is no off-host copy via git. Whatever host-level backup covers ~/Documents applies, which I did not verify here. Not chasing it - low-value historical artefacts, and the call belongs to venus. Confirmed too: this was never blocked on Elazar. Do not re-queue it as a pending-Elazar item.