v0.44.2

[0.44.2] — 2026-08-13

Added

• --close-session now warns, non-blockingly, when a completed task has zero mentions of its own id anywhere in EXECUTION_LOG.md (T-629, RC-2 of docs/rca/2026-08-operator-channel-state-artifacts.md) — wave 76 closed fourteen tasks across roughly ten-plus spawns and produced zero per-spawn EXECUTION_LOG.md entries, and nothing noticed. The sweep that moves merged/deployed_dev/deployed_prod/runtime_verified tasks out of TASK_STATUS.md's Active tasks now also checks each of those task ids against EXECUTION_LOG.md's full text and, before the results table, prints one line naming every id with zero occurrences — silent when all ids are present. deferred/deprecated entries are never checked. This is deliberately a total-omission detector, not a precise per-spawn-entry lint: a task id mentioned anywhere (e.g. at registration) already satisfies it, even if the mandatory tool_uses:/outcome: per-spawn record is still missing — a stricter check was explicitly ruled out, since a wave can legitimately have more merged tasks than spawns (the XS fast lane) or more spawns than tasks (retries). Never blocking: the exit code and session-commit contract are unaffected either way.
• Every mutating operator ritual command (new-task, quick-task, update-task, set-status, update-status, rename-task, rescope-task, merge-task, quick-merge, apply-decomposition, close-session, archive-merged, park-wave, unpark-wave, arm-recheck, ack-recheck, set-strategy-note, handoff) now refuses to run — exit 1, before any file write — against a "never-a-project" repo root (T-624) — a root is refused when either (a) its PROCESS_STATE.json exists and its mavericks_version field still carries the literal shipped placeholder (__MAVERICKS_VERSION__, from templates/PROCESS_STATE_TEMPLATE.json — a tree that has never been installed/adopted by mavp-install.js), or (b) the root resolves to $HOME/.mavericks, the machine-shared adopter-resolved framework-source clone. A missing PROCESS_STATE.json never triggers discriminator (a). The refusal message prints to BOTH stdout and stderr, naming the resolved path, the matched discriminator, and the override env var MAVERICKS_ALLOW_NEVER_PROJECT_ROOT — set it to a truthy value to permit the write for the rare sanctioned case. Read-only reporting surfaces (--agent, --snapshot, --validate, --emit-bundle, the dashboard, --check-sync) are unaffected. printRepoIdentityHeader() (scripts/mavp-operator-lib.js) additionally duplicates its identity line to stderr for these mutating commands, so a stdout-only pipe (e.g. tail) can no longer cut the one line naming the repo it is about to write to — the exact vector that defeated the header on 2026-08-05.
• --close-session now keeps this framework's own PROCESS_STATE.json mavericks_version field current automatically, in self-mode only (T-660) — nothing previously refreshed mavericks_version after a version bump in the framework's own repo, so a lagging value printed a false update-available notice at every session start and had to be hand-synced across two consecutive waves. --close-session now stamps mavericks_version to the current framework version during its existing PROCESS_STATE.json write, in both interactive and non-interactive modes and on both mid-wave and wave-complete closes — but strictly gated to self-mode, detected by comparing the resolved project root against the framework installation root scripts/mavp-version.js lives in (realpath-compared, so a symlink hop or trailing separator can't misclassify it). In any adopter project, where mavericks_version instead records the last version mavp-install.js installed, the field is left byte-unchanged — including staying absent when it was never set.
• --agent's permission_mode field no longer reports declared file config as if it were confirmed runtime truth (T-663) — three additive fields now carry its provenance: permission_mode_source (hook_payload | persisted_runtime | settings_file), permission_mode_verified (true only when the value was observed on THIS session's SessionStart hook stdin payload — reading more files can never make this true), and permission_mode_conflict (present only when a readable user-global ~/.claude/settings.json defaultMode differs from the project-file resolution; reports both values and never picks a winner, since precedence between them is harness-owned and has been observed to diverge from what this project's docs assert). The persisted runtime-mode cache (.mavp/permission-mode) is now session-scoped JSON ({mode, session_id?, written_at}) instead of a bare string; a SessionStart hook payload that omits permission_mode now deletes a stale cached value instead of leaving it to serve a confidently-wrong mode later, while a manual (no-payload) invocation leaves it untouched. --agent and --close-session now share one fallback order (hook payload > persisted > settings file), closing the prior asymmetry where --agent skipped the persisted cache and --close-session skipped the live hook payload — the --close-session push gate's bypassPermissions behavior is unchanged. The session-start skill no longer renders a bare mode value: it labels the verified/declared status, surfaces the conflict line when present, and — when the best-known mode isn't bypassPermissions — names the exact settings-file fix to restore prompt-free operation.

Changed

• next_action version-number rule is now enforced, not just suggested — an adopter's next_action value can now be rejected by a check that never blocked before (T-628) — this project's convention has always said next_action (a one-line field describing what happens next) must never contain a version number describing current state, like "we are at 0.42.1." Previously, writing that anyway only printed an informational note nobody was required to act on; three real slips got through exactly that way. Now a version number ASSERTING current state ("is/are/at/on/now/currently/already/still 0.44.3") makes the check fail outright — at edit time if hooks are active, otherwise on the next commit. A version number that is instead the actual TARGET of an instruction — "bump to 0.44.3," "the 0.44.3 section" — is explicitly allowed, so legitimate release instructions keep working. If your next_action reads like a status report instead of an instruction, rewrite it before your next commit, or the commit will be blocked. The same edit-time check now also watches PROCESS_STATE.json directly, not only the two task-tracking files it previously covered, so a version-number slip in any of the three state files surfaces immediately instead of waiting for someone to run a commit.

Fixed

• Closing a wave could silently carry its architect-review gate state into the freshly opened next wave, making the new wave falsely read as already past the gate it hasn't been through yet (T-653) — --close-session never wrote the wave_status field at all, so on wave advance the ending wave's value (e.g. architect_reviewed) survived byte-for-byte into the new wave via the existing carry-forward of unrecognized fields. Observed live: a wave closed at architect_reviewed and the next wave opened still reading architect_reviewed, skipping the mandatory review gate for waves with three or more planned tasks. The fix resets wave_status to planning inside the same wave-advance code path that already clears the previous wave's goal and working notes — a mid-wave (not-yet-complete) close still leaves wave_status untouched, since the wave it describes is still open. Docs correction alongside this fix: CLAUDE.md, docs/core/ORCHESTRATION_RULES.md, and the project-state template previously documented a closed value for wave_status, claiming --close-session sets it automatically — that was never reachable, since the close and the wave-counter increment happen as one atomic write, and persisting closed would have mislabeled the brand-new wave instead. closed is retired from the documented enum; wave_summary is the artifact that records what a closed wave accomplished.
• Framework version bumped 0.44.1 → 0.44.2 in both scripts/mavp-version.js and package.json (T-658) — a patch bump: wave 81 corrects existing behavior and adds no new command, flag, field, or schema.