Depends on the apps/gittensory-miner-ui/ scaffold (sibling Phase 6 issue) landing first — there is no app shell to add a view to yet.
The data source already exists and is simple: packages/gittensory-miner/lib/run-state.js persists one row per repo in miner_run_state (repo_full_name PRIMARY KEY, state constrained to idle | discovering | planning | preparing, updated_at — run-state.js:6,52-63) in a local SQLite file resolved the same way every sibling store resolves its path (GITTENSORY_MINER_RUN_STATE_DB → GITTENSORY_MINER_CONFIG_DIR → XDG_CONFIG_HOME/~/.config, run-state.js:12-27). This view is a read-only table over that store (plus, if useful, the local claim ledger and event ledger for a fuller per-run picture) — no new state, no writes from the UI.
Since the UI shell (sibling issue) is a browser app and these stores are node:sqlite files on disk, this issue also needs a way for the UI to read them — most likely a small local read-only API/IPC layer (e.g. the miner CLI serving a local read-only JSON endpoint, or a Vite dev-server API route reading the SQLite file directly via the existing lib/run-state.js accessors) rather than duplicating the SQL. Whichever shape is chosen, it should call into the existing run-state.js/event-ledger.js exports rather than re-implementing the queries.
Deliverables
References
packages/gittensory-miner/lib/run-state.js:6,12-27,52-63 — the miner_run_state schema and path-resolution chain this view reads from.- Sibling Phase 6 issue:
feat(miner-ui): scaffold apps/gittensory-miner-ui/ dashboard shell — hard dependency.
packages/gittensory-miner/lib/event-ledger.js — optional richer per-run event trail, if the view wants more than the current-state snapshot.
Depends on the
apps/gittensory-miner-ui/scaffold (sibling Phase 6 issue) landing first — there is no app shell to add a view to yet.The data source already exists and is simple:
packages/gittensory-miner/lib/run-state.jspersists one row per repo inminer_run_state(repo_full_namePRIMARY KEY,stateconstrained toidle | discovering | planning | preparing,updated_at—run-state.js:6,52-63) in a local SQLite file resolved the same way every sibling store resolves its path (GITTENSORY_MINER_RUN_STATE_DB→GITTENSORY_MINER_CONFIG_DIR→XDG_CONFIG_HOME/~/.config,run-state.js:12-27). This view is a read-only table over that store (plus, if useful, the local claim ledger and event ledger for a fuller per-run picture) — no new state, no writes from the UI.Since the UI shell (sibling issue) is a browser app and these stores are
node:sqlitefiles on disk, this issue also needs a way for the UI to read them — most likely a small local read-only API/IPC layer (e.g. the miner CLI serving a local read-only JSON endpoint, or a Vite dev-server API route reading the SQLite file directly via the existinglib/run-state.jsaccessors) rather than duplicating the SQL. Whichever shape is chosen, it should call into the existingrun-state.js/event-ledger.jsexports rather than re-implementing the queries.Deliverables
apps/gittensory-miner-ui/listing local run-state rows (repo, state, last-updated), read-only.packages/gittensory-miner/lib/run-state.js's existing exports (no new SQL queries duplicated in the UI layer).References
packages/gittensory-miner/lib/run-state.js:6,12-27,52-63— theminer_run_stateschema and path-resolution chain this view reads from.feat(miner-ui): scaffold apps/gittensory-miner-ui/ dashboard shell— hard dependency.packages/gittensory-miner/lib/event-ledger.js— optional richer per-run event trail, if the view wants more than the current-state snapshot.