BABUNI.DEV

FlourishForever / Roadmap

FlourishForever: Roadmap

Flourish Forever — verified baseline and roadmap

What exists in current source

P0 — gameplay event correctness

  1. Install all three Lua files and TOC on intended WoW: Forever client interface 16001, and confirm /flourish opens without Lua errors.
  2. Select one spell and verify that the client actually fires UNIT_SPELLCAST_SUCCEEDED with parameters the addon expects (unit, _, spellID); record version and event payload.
  3. Distinguish successful cast from actual target hit/effect application. Test a cast that succeeds but misses/resists or doesn't affect its target; the current listener may still emote.
  4. Test interrupts, failed casts, duplicate cast-success events, triggered/proc spells, different ranks with one name, channelled casts, spells on cooldown and abilities that cannot be selected from the spellbook.
  5. Verify the passive filter and dropdown's available spell list under both new and legacy API paths. Test changed talent/spellbook lists while the window remains open via SPELLS_CHANGED.
  6. Confirm math.random chance with 0%, 100% and intermediate values across repeated casts; distinguish probability from deterministic “every nth cast.”
  7. Confirm cooldown per normalized ability name, independence of two configured spells, and zero/6/120-second intervals.
  8. Specifically test first eligible cast shortly after login: lastFireByAbility[key] or 0 may suppress it if GetTime() < cooldown. Decide whether to repair only after reproducing or designing the intended behavior.
  9. Confirm cooldown timestamps reset on /reload and relog; the source doesn't save them. Document whether that is acceptable for play.

P1 — saved character profiles and emote behavior

  1. Test fresh character GUID binding and settings after reload, logout/login and switching characters. Confirm no selections leak across characters.
  2. Test old ROARitFOREVERStorage migration using backed-up SavedVariables, including name-keyed or old name-realm-keyed entries. The old root must actually have been loaded; current TOC declaring a new root doesn't automatically load a missing old file.
  3. Test character setup when UnitGUID is briefly unavailable; EnsureDB creates a fallback session table and rebinds when the GUID returns. Ensure early edits aren't lost.
  4. Test no emotes checked, one enabled, several enabled and a token unsupported by DoEmote. Inspect actual client chat/sound/animation and behavior with other emote addons.
  5. Inspect status printing the raw character GUID and decide whether diagnostic privacy/readability should change.
  6. Test saved chance/cooldown values outside slider bounds or in nonnumeric legacy formats; source converts with tonumber but does not clamp on load.
  7. Test duplicate spell names, spell localization changing the persisted ability key, and spell IDs changing rank/specialization.
  8. Test dropdown menu templates and their optional dynamic load; CreateUI still assumes several globals exist after attempting to load them.

P2 — packaging and portfolio evidence

  1. Confirm CurseForge packager successfully processes .pkgmeta, includes only intended Lua/TOC files and uses the manual CHANGELOG; not verified by the existence of the metadata file.
  2. Consider adding a small mocked Lua harness for spellcast matching, cooldown, chance boundaries, GUID migration and UI creation, then run it and record output.
  3. Verify public GitHub beta release entries: currently v0.3.0-beta and v0.3.1-beta have no uploaded release assets. Do not advertise a ZIP at their release URLs.
  4. Decide on an explicit repository license; no LICENSE was found in the inspected main tree.
  5. Obtain actual client screenshots/recordings of the config panel and sample in-world emote, recording consent/character names appropriately.
  6. Test UI legibility and keyboard accessibility for the ability/emote scroll frames at common display scales.

Open creative directions requiring creator approval

Would per-ability preview help select the right flourish? Should emotes triggered close together be globally rate limited to keep chat quieter? Should cooldowns survive reload? Should the addon distinguish cast success from actual hit? Should a user be able to supply custom text or keep the native emote-only boundary? Are certain class/proc spells too noisy? These are proposals, not implemented features or accepted decisions.

Document information

Creative decision authority: Babuni.dev. Release: 0.3.1-beta, October 22, 2026.
Status of this roadmap: proposed checks and unapproved alternatives, not implementation instructions.

View source