# Changelog

All notable changes to **Buddy** are documented here.
Format: [Keep a Changelog 1.1.0](https://keepachangelog.com/en/1.1.0/) — versioning: [SemVer](https://semver.org/).

---

## [Unreleased]

---

## [0.1.5] — 2026-06-08

### Fixed — WordPress.org reviewer feedback (inline asset cleanup)

First-round review from the WordPress.org Plugin Directory team flagged the About page for using an inline `<style>` block. The fix-pass went broader than the single flagged file — a full audit caught three more inline `style="…"` attributes elsewhere in the admin UI, all of which moved to proper CSS classes in the enqueued stylesheet.

The only inline style that intentionally remains is the dynamic stat-bar `width:%d%%` value in the Dashboard widget, which is runtime data computed from per-user state — that one is allowed under wp.org rules because the value cannot be precomputed in a static stylesheet.

- **`inc/about.php`**: removed the 40-line `<style>` block at the top of the file. Replaced `<span style="color:#646970; font-weight:400;">` with `class="buddy-about-intro__version"`. Replaced `<p style="margin-bottom:0;">` with `class="buddy-about-intro__cta"`.
- **`inc/settings.php`**: replaced the long inline `style="max-width: 720px; background:#fff; padding:18px 22px; …"` form-wrapper attribute with `class="buddy-settings-form"`. Removed inline `<h2 style="margin-top:0;">` on the Name heading.
- **`inc/admin-page.php`**: replaced `<p class="description" style="max-width: 720px;">` with `class="description buddy-admin-description"`.
- **`assets/css/buddy.css`**: appended ~40 lines covering the About page intro classes, the Settings form wrapper, and the admin-page description max-width rule. All visual styling now lives in one enqueued stylesheet.

No user-visible behaviour changes. Functionality and layout identical to v0.1.4.

---

## [0.1.4] — 2026-06-07

### Changed — WordPress.org submission prep (plugin family renaming + PCP cleanup)

This release prepares Buddy for the WordPress.org Plugin Directory and aligns it with the RangerHQ plugin family naming convention. No user-visible behaviour changes; existing Buddy state is preserved across the rename.

- **Plugin renamed** from "Buddy" to "RangerHQ Buddy". Plugin header `Plugin Name` updated. The text domain moved from `buddy` to `rangerhq-buddy` and every `__()`, `_e()`, `esc_html__()` etc. call across the codebase was updated to match.
- **Plugin URI** and **Author URI** updated to `davidtkeane.com` (RangerHQ family standard, locked 2026-05-30).
- **Slug stays as `buddy`** internally — directory name, admin-menu slug, `BUDDY_*` constants and `buddy_*` function prefixes all unchanged. Only the user-facing brand and text domain moved.
- **Self-hosted Gitea updater removed.** WordPress.org-hosted plugins use the core update system; a custom updater is forbidden under wp.org rules. The `require_once BUDDY_PATH . 'inc/updater.php';` line was removed from `buddy.php`. The `inc/updater.php` file itself stays in the Gitea repo (defensive `function_exists()` checks keep it inert if not loaded) so the self-hosted build path is recoverable.
- **`LICENSE` file added** containing the full GPL v2 text from gnu.org (required by wp.org).
- **`readme.txt` added** in WordPress.org format — header, Description, Installation, FAQ, Screenshots, Changelog, Upgrade Notice sections. Stable tag pinned to 0.1.4.

### Fixed — Plugin Check (PCP) cleanup pass

Resolved every PCP warning ahead of submission (from 15 errors down to zero):

- Text domain alignment across all translation calls (`buddy` → `rangerhq-buddy`).
- Output escaping tightened — `esc_html__()`, `esc_attr__()`, `esc_html_e()` applied wherever user-facing strings reach the page.
- Translator comments added next to every `printf`/`sprintf`-style string with placeholders.
- Replaced `mt_rand()` with `wp_rand()` for better randomness (wp.org best-practice).

---

## [0.1.3] — 2026-05-27

### Fixed — Wink no longer gets stuck

The v0.1.1 wink was implemented as a static SVG render (left eye drawn as a closed curved line). Once the random 5% chance picked the `wink` tone, the page rendered with one eye closed and stayed that way until the next page reload — and 95% of subsequent reloads went back to a non-wink tone, but if the dashboard sat idle, Buddy was stuck mid-wink indefinitely. David reported it as *"buddy has the wink face but the eye does not unblink."*

v0.1.2's lower probability (30% → 5%) reduced how often you'd see the stuck state but did not fix the underlying issue.

v0.1.3 makes the wink a real CSS animation:

- **sprite.php** no longer renders the left eye as a closed path when tone is `wink` — both eyes are always open circles in the SVG.
- **buddy.css** has a new `@keyframes buddyWink` that briefly closes the left eye (`scaleY(0.1)`) for ~250 ms every 2.5 s. The right eye keeps its normal 5 s blink. That asymmetric pattern is what makes it read as a wink rather than a synchronised blink.
- The wink animation only runs when the parent has the `buddy-sprite--wink` class, which is still controlled by the same 5% probability gate from v0.1.2.
- The mouth (asymmetric smirk), cheek opacity (rosier), and mood label (`Cheeky 😉`) all still differ for the wink tone — those are valid static state changes. Only the eye behaviour moved from static-state to transient-animation.

Net effect: when the 5% chance fires, Buddy now actually winks (closes left eye, opens it, closes it, opens it, etc., every 2.5 s) instead of freezing one-eye-shut.

---

## [0.1.2] — 2026-05-26

### Tuned — Wink probability lowered from 30% to 5%
The wink Easter-egg added in v0.1.1 fired at 30% per page render
when Buddy's mood was ≥ 75. Default mood is 80, so most admin
visits hit the gate and ~30% of those flipped to wink. Stacked
across the main admin page + dashboard widget visible on the same
screen, Buddy ended up looking like he had one eye closed all the
time — "stuck" rather than "playful".

Dropped to 5%. Same wink visuals when it fires; just rare enough
to feel magical instead of constant. Refresh ~20 times when mood
is high and you'll catch one.

### Changed
- **`inc/state.php`**: `buddy_mood_label()` probability gate
  `mt_rand( 1, 100 ) <= 30` changed to `<= 5`. Docstring updated
  to reflect new ~5% rate.
- **Plugin version bumped**: header + `BUDDY_VERSION` constant
  0.1.1 → 0.1.2.
- **About page** version-history card leads with v0.1.2; v0.1.1
  demoted.

### Not changed
- Wink visuals (`inc/sprite.php`) — same closed-eye arc, smirk,
  rosy cheeks when it fires. Just rarer.
- All other behavior identical to v0.1.1.

---

## [0.1.1] — 2026-05-25

### Added — Wink expression 😉
Buddy now has a fourth mood tone: **`wink`** — one eye closed, an
asymmetric smirk, and rosier cheeks. Rendered as a small variant
inside the existing inline-SVG sprite (still zero image files, no
new assets). When Buddy's overall mood is ≥ 75, there's a ~30%
chance on each page render that the wink replaces the standard
happy face. Refresh a few times when Buddy is content and you'll
catch it.

Why this commit exists: the v0.1.0 sprite had three tones
(happy / neutral / sad). Adding `wink` was the smallest possible
demo that the SVG expression engine is properly extensible — every
future mood/state/species can be added the same way. ~20 lines of
PHP, ~2 lines of CSS, no bundle weight, no dependencies.

### Changed
- **`inc/sprite.php`**: added `wink` to the allowed-tones list.
  Left eye renders as a closed-eye curve (a small downward arc)
  instead of the open circle. Right eye stays normal. Mouth shifts
  to an asymmetric smirk curve. Cheek opacity bumped from 0.55 to
  0.75 for extra cheekiness.
- **`inc/state.php`**: `buddy_mood_label()` now has a 30% chance of
  returning the wink tone when the overall mood score is ≥ 75.
- **`assets/css/buddy.css`**: new `.buddy-widget__mood--wink` and
  `.buddy-main__mood--wink` rules — warm amber pill matching the
  cheeky vibe.
- **About page** version-history card leads with v0.1.1; v0.1.0
  demoted to the previous entry.
- **Plugin version bumped**: header + `BUDDY_VERSION` constant
  0.1.0 → 0.1.1.

---

## [0.1.0] — 2026-05-25

**Buddy is born.** First release of a new standalone WordPress plugin extracted-and-rebuilt from the tamagotchi feature that once lived inside A-WP-Notes v1.1.5 (now gracefully retired). Buddy stands on its own as a focused, charming companion plugin for the WordPress dashboard.

### Added — Phase A complete (pet exists)
- **Dashboard widget** at WP Admin → Dashboard showing the SVG character, the pet's name, a mood label ("Thriving" / "Content" / "Okay" / "Hungry" / "Distressed"), and four stat bars (Hunger / Happiness / Health / Energy).
- **Dedicated admin page** at WP Admin → Buddy → My Buddy showing the same data in a larger format with the pet's age and a placeholder note describing what's coming next.
- **About page** at WP Admin → Buddy → About with the side-by-side intro pattern, "What Buddy does" / "Who Buddy is for" / "Version history" cards, and a link to this CHANGELOG.md.
- **Settings page** at WP Admin → Buddy → Settings with a name-rename form and the Updates panel.
- **Per-user state storage** via `user_meta` (key: `buddy_state`). Each WP admin gets their own Buddy with its own name, species, and stats.
- **SVG sprite renderer** with three mood tones (happy / neutral / sad) and three sizes (sm / md / lg). Pure inline SVG with CSS keyframe animations (bobbing motion + periodic blinking). No GIFs, no sprite sheets, no image files for the character.
- **Self-hosted update checker** wired up to the Gitea repo from commit 1. Polls `/api/v1/repos/ranger/a-buddy/releases/latest` with a `/tags?limit=1` fallback. 12h success cache, 1h negative cache. UI surface lives on the Settings page.
- **Custom admin-menu icon** (`dashicons-pets`, a paw print) reinforcing the pet identity.

### Architecture (locked from day one)
- **Single-word brand name `Buddy`** — no "WP" prefix, no marketplace trademark hurdle.
- **Public GPL v2+ Gitea repo** at `ranger/a-buddy` on `git.davidtkeane.com`.
- **All persistent notice dismissals** to use `user_meta` + AJAX pattern (port from Logbook when first notice appears).
- **CSS-only animations, all assets local** — bundle stays small.
- **Single H1 per admin page**, no nested toggle boxes, no duplicate sections — Tier-1 discipline carried forward from Logbook.

### Not in this release (planned)
- Phase B — Feed / Play / Clean / Sleep interactions with cooldown timers.
- Phase C — WP-cron stat decay, "Buddy is hungry" dismissible admin notices.
- Phase D — Multiple species (dog, dragon, sprite), per-species personality phrases.
- Phase E — Site-health integration: pet stats react to `wp_get_site_health()` results, outdated plugins drain health, published posts feed hunger, cleared spam boosts happiness.
- Phase F — Pro tier with custom skins, multi-pet farm, social visits.