cctally 1.6.3 → 1.7.0

package/CHANGELOG.md

@@ -5,6 +5,21 @@ based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [1.7.0] - 2026-05-13
+
+### Added
+- `cctally doctor` — read-only diagnostic subcommand consolidating install / hooks / OAuth / DB / freshness / safety state into one severity-ranked report (human + JSON; exit 0 unless any check FAILs, then 2); the dashboard exposes the same diagnostic via an aggregate-health header chip and a full-report modal opened by clicking the chip or pressing `d`, backed by `GET /api/doctor`.
+
+### Changed
+- `share`: Detail templates for `weekly` / `daily` / `monthly` / `blocks` now ship cross-tab data (per-week × per-model, per-day × per-project, per-month × per-model, per-block × per-project) in their MD and HTML exports — resolves the per-project narrowing landed in M2.1 ([#33](https://github.com/omrikais/cctally-dev/issues/33)). SVG output for these templates continues to omit the table body and is tracked separately at [#38](https://github.com/omrikais/cctally-dev/issues/38).
+
+### Fixed
+- `update`: Dashboard version label and CLI banner no longer stay frozen on the pre-upgrade version after an out-of-band install (`npm install -g cctally@X` outside `cctally update`) — a new self-heal compares the running binary's CHANGELOG against `update-state.json` on every CLI command and every dashboard tick, re-stamping `current_version` when they disagree. Also fixed the underlying bug where `cctally update` (without `--version`) stamped the cached `latest_version` as the just-installed version: a stale probe from before the registry advanced caused `current_version` to land on the wrong value even though npm had actually fetched a newer release. `_stamp_install_success_to_state` now prefers the freshly-installed CHANGELOG, falling back to `latest_version` only when CHANGELOG is unreadable.
+- `update` (brew): `cctally update` on a brew install no longer stamps the pre-upgrade version into `update-state.json` when no `--version` is supplied. The running Python process has `CHANGELOG_PATH` bound to the OLD Cellar, so the CHANGELOG read returned the pre-upgrade version and `current_version` landed on the wrong value until the next dashboard self-heal (up to 30 min on the worker thread). `_stamp_install_success_to_state` now takes the resolved `InstallMethod` and short-circuits to `state.latest_version` (the freshly-probed value that drove the install) on the brew + no-explicit-version path; npm and explicit-`--version` paths are unchanged so the prior stale-probe regression (1.6.0-after-installing-1.6.3) stays fixed.
+- `doctor`: `safety.update_suppress` no longer warns "bad types: remind_after" against the canonical producer shape. `cctally update --remind-later` writes `remind_after` as a dict `{"version", "until_utc"}` and the banner predicate consumes that shape — but the doctor validator only accepted `None`/str/numeric and flagged every legitimate deferral as a corrupt file, recommending the user delete `update-suppress.json`. The validator now accepts the dict shape alongside the legacy scalar form.
+- `dashboard` (keymap): Doctor-modal global-key guard. `q` (quit), `r` (sync), `1`-`9` (panel modals), and `n`/`N` (search step) now skip when the Doctor modal is open — previously they fired underneath the modal, popping panel modals into ModalRoot or quitting the dashboard behind a still-visible Doctor card. Update modal's symmetric guard was already in place; this folds `doctorModalOpen` into the same predicate.
+- `doctor`: Symlink check no longer reports `0/N present; missing …` when the running cctally invocation belongs to a different install than the one that owns `~/.local/bin/cctally-*` (e.g., source-tree dev iteration with a parallel npm/brew install). The strict equality check in `_setup_compute_symlink_state` compared each symlink's target to `<repo_root>/bin/<name>` derived from `__file__`, so launching the dashboard via `python3 <source>/bin/cctally dashboard` against an npm-installed user's symlinks would classify all 13 entries as `wrong`, render them under the "missing" label, and falsely prompt the user to re-run `cctally setup`. The diagnostic now asks the right question — "is `cctally-X` invokable from PATH?" — by accepting any symlink whose target is reachable; `_setup_create_symlinks` keeps its own strict equality for install-management decisions. Also flips dangling symlinks from the previously-conflated "missing" classification to the correct "wrong" state.
+
 ## [1.6.3] - 2026-05-12
 
 ### Fixed