rangerhq-buddy/CHANGELOG.md

Changelog

All notable changes to Buddy are documented here. Format: Keep a Changelog 1.1.0 — versioning: SemVer.

---

[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.