# Changelog ## Unreleased No unreleased changes. ## 0.7.0: Automatic Wakeup Ownership - `[Runtime]` Added automatic uncontested ownership: session start now acquires wake-up delivery when no live owner exists or the stored owner is stale, while live external owners remain sticky. Impact: normal single-session use no longer requires remembering `/wakeup-start`, and multi-session use avoids lock ping-pong. - `[Scheduling]` Let passive live sessions append schedule entries to the shared `WAKEUP.md` without stealing delivery ownership. Impact: any active Pi instance can schedule future prompts, while the singleton owner remains responsible for timer reload and delivery. - `[Controls]` Demoted `/wakeup-start` and `/wakeup-stop` to advanced manual takeover/release controls. Impact: operators still have recovery handles without making manual start part of the primary onboarding path. - `[Docs]` Updated README, architecture, and project context for shared-file scheduling, sticky live owners, automatic ownerless acquisition, and the distinction between schedule mutation and delivery ownership. - `[Tests]` Added runtime regressions for ownerless startup acquisition, live-owner passivity, shared schedule writes without ownership theft, and owner-presence status behavior. - `[Packaging]` Bumped package metadata to `0.7.0` for the minor release. ## 0.6.0: Wakeup Ownership Status - `[Status]` Restored visible singleton ownership in the footer: the active owner now shows `wakeup` even when no future countdown is running, while active future tasks still show `wakeup [hh:mm:ss]`. Impact: operators can see which terminal currently owns the shared `WAKEUP.md` delivery lock without waiting for a countdown. - `[Runtime]` Kept non-owner and inactive sessions quiet in the footer. Impact: singleton ownership is visible only where it is operationally relevant, avoiding multi-terminal status clutter. - `[Docs]` Reworked the root README as a Rhythm Extension onboarding entrypoint with clearer product positioning, first-run path, product model, feature showcase, scheduling semantics, runtime ownership, status rhythm, and safety boundary. Impact: operators can understand wake-up rhythm, ownership, and schedule-only behavior without starting in architecture docs. - `[Context]` Added a durable README/status standard to `AGENTS.md` and closed the ownership-status backlog slice. Impact: future edits preserve both the wake-up rhythm positioning and the operational singleton visibility contract. - `[Packaging]` Bumped package metadata to `0.6.0` for the minor release. ## 0.5.4: Wakeup Prompt Polish Hotfix - `[Delivery]` Updated fired wake-up prompts and actionable startup notices to use `⏰ Wakeup!` consistently. Impact: wake-up delivery reads as an explicit event prompt while preserving existing task payload format. - `[Docs]` Removed a stale README line that implied the `wakeup` tool is owner-only; delivery remains singleton-locked, but the tool remains available to the agent. Impact: docs now match the 0.5.1+ tool availability contract. - `[Tests]` Updated delivery regression expectations for the polished wake-up prompt. - `[Packaging]` Bumped package metadata to `0.5.4` for the hotfix release. ## 0.5.3: Scheduling Semantics Hotfix - `[Guidance]` Clarified injected wakeup tool guidance: scheduling a future action means creating the wake-up and confirming it, not performing the scheduled action immediately. Impact: agent behavior now matches the scheduler contract during ordinary scheduling requests. - `[Context]` Added the scheduling-is-not-execution rule to project context and README usage. Impact: future prompt and docs changes preserve the separation between scheduling and fired-task execution. - `[Tests]` Added a prompt-guidance regression for the no-immediate-execution scheduling rule. Impact: the LLM-facing scheduler semantics are covered by tests. - `[Packaging]` Bumped package metadata to `0.5.3` for the hotfix release. ## 0.5.2: Wakeup Edit Trigger Hotfix - `[Runtime]` Made direct `WAKEUP.md` edits a legitimate activation path: an open session watches the schedule file, acquires local delivery when no live external owner blocks it, and rebuilds timers from the edited file. Impact: both scheduling paths now work — agent tool calls and direct Markdown edits. - `[Tooling]` Tightened wakeup prompt guidance to describe tool scheduling as the preferred agent path and direct file edits as a valid schedule-edit path that requires active or acquirable local delivery. Impact: injected guidance now matches the two-path scheduler model. - `[Tests]` Added watcher-domain smoke regressions for direct `WAKEUP.md` edit reload and external-owner blocking. Impact: file-edit activation behavior is covered independently of tool scheduling. - `[Packaging]` Bumped package metadata to `0.5.2` for the hotfix release. ## 0.5.1: Wakeup Tool Availability Hotfix - `[Tooling]` Kept the `wakeup` tool available to the agent and made `wakeup schedule` acquire local delivery when no live external owner blocks it. Impact: agents can schedule their own future prompts after reload instead of relying on manual `WAKEUP.md` edits or pre-existing ownership. - `[Runtime]` Preserved singleton safety by continuing to reject mutations while another live pi instance owns delivery. Impact: the hotfix restores agent scheduling without allowing silent takeover of live external owners. - `[Docs]` Updated README, architecture docs, and project context to document schedule-triggered local delivery acquisition. Impact: the tool availability contract matches the user-facing scheduler model. ## 0.5.0: Dynamic Wakeup Status - `[Status]` Hid the `wakeup` footer status while the scheduler is inactive, idle, due, or overdue, and kept the footer visible only for active future countdowns as `wakeup [hh:mm:ss]`. Impact: wake-up status now behaves as a presence-based mode indicator and preserves terminal status-line width when no countdown is active. - `[Tests]` Added status-domain regressions for hidden off/idle/due states and active countdown rendering. Impact: dynamic status behavior is covered at the owning domain boundary. - `[Docs]` Updated README, architecture docs, locks guidance, and project context for the dynamic footer-status contract. Impact: release documentation matches the new status semantics. - `[Packaging]` Bumped package metadata to `0.5.0` for the minor release. ## 0.4.1: Pi SDK Scope Hotfix - `[Packaging]` Migrated the pi SDK peer dependency and extension type imports from the legacy `@mariozechner/pi-coding-agent` scope to `@earendil-works/pi-coding-agent`. Impact: package metadata matches the current Endrilla/Earendil pi package namespace. ## 0.4.0 - `[Context Hygiene]` Scoped the `wakeup` tool to the singleton owner session by enabling it when `/wakeup-start` acquires/resumes ownership and disabling it in inactive or stopped sessions. Impact: non-owner pi instances keep `/wakeup-start` and `/wakeup-stop` available without injecting wakeup tool prompt guidance or encouraging schedule checks that dump `WAKEUP.md` state into unrelated contexts. - `[Docs]` Documented singleton-scoped tool activation in README, architecture, and project context, synchronized `docs/locks.md` to the extension-neutral shared Locks Standard, and bumped package metadata to `0.4.0`. Impact: release documentation matches the new context-activation boundary and the singleton lock standard is portable bit-for-bit across participating extensions. ## 0.3.0 - `[Architecture]` Decomposed the monolithic extension entrypoint into a flat `/lib` Domain DAG with `index.ts` as a small namespace-import composition root, then collapsed over-split schedule, lock, and prompt helper files back into cohesive owning domains. Impact: schedule state, locks, delivery timers, file watching, footer status, reports, runtime coordination, commands, tools, and time formatting now have explicit ownership without helper-category file proliferation. - `[Validation]` Added `npm run check`, `npm test`, `npm run pack:dry`, architecture invariant tests, schedule/lock/delivery/status/tool domain tests, and removed the runtime `typebox` dependency from the tool schema path. Impact: a fresh checkout can validate import sanity, regressions, package contents, timer/status behavior, and entrypoint boundaries without hidden peer-dependency assumptions. - `[Docs]` Added the architecture overview and synchronized README, docs index, and project context with the Domain DAG topology. Impact: future maintainers can navigate runtime flow and domain ownership without reading the full scheduler implementation first. - `[Context]` Initialized the project context split with `AGENTS.md`, `BACKLOG.md`, `CHANGELOG.md`, and `docs/README.md`, and linked the control plane from README. Impact: future work has a durable protocol, canonical backlog, delivery history, and discoverable docs index. ## 0.2.1 - `[Notifications]` Refined runtime notification behavior around scheduler resume and inactive-delivery states. Impact: operators get clearer actionable notices without implicit lock takeover. ## 0.2.0 - `[Schedule Format]` Standardized `WAKEUP.md` entries as monotonic indexed lines with `[ ]`, `[x]`, and `[~]` status markers, removed priority from the active format, and retained completed entries until remaining work closes. Impact: wake-up messages and manual schedule edits can refer to stable task numbers. - `[Singleton Runtime]` Moved delivery ownership to the shared `locks.json` registry under `@llblab/pi-wakeup`, with explicit start/stop commands, interactive takeover, stale same-directory resume, lock-mismatch shutdown, and footer countdown status. Impact: one pi instance owns delivery while other sessions can inspect schedule state safely. - `[Scheduling]` Streamlined timer rebuilds from `WAKEUP.md`, overdue handling, and `wakeup` tool schedule/done flows. Impact: pending tasks fire sequentially and schedule edits synchronize without a daemon or cron. ## 0.1.1 - `[Stability]` Shipped post-initial scheduler fixes. Impact: the initial wake-up workflow became more reliable for daily use. ## 0.1.0 - `[Initial Release]` Shipped the singleton wake-up scheduler extension with `WAKEUP.md`, `/wakeup-start`, `/wakeup-stop`, the `wakeup` tool, footer status, and local timer delivery through pi follow-up messages. Impact: agents can schedule their own future prompts without external cron infrastructure.