From b28a20ad64928f79a23c197784f6090a235869c3 Mon Sep 17 00:00:00 2001 From: Wishmaster117 <140754794+Wishmaster117@users.noreply.github.com> Date: Sun, 30 Aug 2026 16:23:02 +0100 Subject: [PATCH] Update README and roadmap after lifecycle merge --- README.md | 971 +++++++------------------------------------- docs/ROADMAP.md | 1018 ++++++++++++++++++++--------------------------- 2 files changed, 580 insertions(+), 1409 deletions(-) diff --git a/README.md b/README.md index f2b2dfc..74c4c8e 100644 --- a/README.md +++ b/README.md @@ -1,143 +1,117 @@

- Gemini_Generated_Image_s1mnq6s1mnq6s1mn + MultiBot Chatless

# MultiBot Chatless -### Bridge-first client addon for AzerothCore `mod-playerbots` +### Bridge-first Playerbots control for World of Warcraft 3.3.5a -MultiBot-Chatless is the client-side World of Warcraft 3.3.5a addon for controlling and inspecting Playerbots through a cleaner, mostly chatless UI workflow. +MultiBot Chatless is a client addon for AzerothCore `mod-playerbots`. +It keeps the familiar MultiBot UI while moving more bot reads and actions away from automatic chat commands and into a structured server bridge.
-Repository -Bridge Module WoW Version Architecture - -

- - - - - - - - - - - - - - - - - -
ComponentRepositoryInstall Location
Client Addon - - MultiBot-Chatless - - - World of Warcraft/Interface/AddOns/MultiBot -
Server Bridge Module - - mod-multibot-bridge - - - azerothcore/modules/mod-multibot-bridge -
+Status
--- -## Important Notice +## Companion Bridge Required -`MultiBot-Chatless` is the **addon-side repository only**. +This repository contains the **client addon**. -To get the new bridge-first / mostly chatless behavior, you also need the server-side AzerothCore module: +For the bridge-first features you also need: -
+### [`mod-multibot-bridge`](https://github.com/Wishmaster117/mod-multibot-bridge) -### 👉 mod-multibot-bridge +Install the addon as: -
+```text +World of Warcraft/Interface/AddOns/MultiBot +``` -Without the bridge module, the addon cannot use the new structured `MBOT GET~...` data flow. +The folder must be named `MultiBot`. --- -# What is MultiBot Chatless? - -MultiBot is a user interface addon for the AzerothCore [`mod-playerbots`](https://github.com/mod-playerbots/mod-playerbots) module. +# What the Addon Does -This fork focuses on removing automatic bot chat spam from the main UI refresh paths by using a dedicated AzerothCore bridge module instead of relying on legacy chat parsing. +MultiBot Chatless provides a UI for controlling, inspecting and managing Playerbots without flooding normal gameplay with automatic bot chat replies. -The addon now requests structured data from the server through `mod-multibot-bridge`. - -Examples of bridge request families (arguments omitted here for readability): +The addon still supports intentional manual Playerbots commands where they are useful, but the main direction is: ```text -MBOT HELLO -MBOT PING -GET~ROSTER -GET~STATES -GET~WEAPON_ENCHANT -GET~DETAILS -GET~STATS -GET~PVP_STATS -GET~TALENT_SPEC_LIST -GET~INVENTORY -GET~BANK -GET~GBANK -GET~SPELLBOOK -GET~BOT_SKILLS -GET~BOT_REPUTATIONS -GET~BOT_EMBLEMS -GET~PROFESSION_RECIPES -GET~ENCHANT_TRADE -GET~GLYPHS -GET~OUTFITS -GET~QUESTS -GET~GAMEOBJECTS -GET~FORMATIONS -RUN~CRAFT_RECIPE -RUN~CRAFT_RECIPE_TARGET -RUN~ITEM_ACTION -RUN~ITEM_EQUIP -RUN~ITEM_UNEQUIP -RUN~ITEM_TRADE -RUN~QUEST_ABANDON -RUN~OUTFIT -RUN~RTI -RUN~COMBAT -RUN~POSITION -RUN~LOOT -RUN~STRATEGY -RUN~FORMATION -RUN~GROUP_ROLL -RUN~ENCHANT_TRADE +UI action + -> structured addon message + -> mod-multibot-bridge + -> validated server-side action/read + -> structured result + -> authoritative UI refresh ``` -The Formation family uses the following complete party/raid-wide contracts: +The project is currently **bridge-first / mostly chatless** rather than fully chatless. Remaining automatic chat paths are migrated only after targeted audit and runtime validation. -```text -RUN~FORMATION~GROUP~~~ -FORMATION_ACK~GROUP~~~~~ +--- -GET~FORMATIONS~GROUP~~ -FORMATIONS_BEGIN~~ -FORMATIONS_ITEM~~~ -FORMATIONS_END~~ -``` +# Main Features + +| Area | Current behavior | +| --- | --- | +| **Bot rosters** | My Bots / Altbots, Group, Guild, Friends and Favorites with online/offline presence and structured lifecycle handling. | +| **Bot connect / disconnect** | `ALT_ROSTER_V1`, `BOT_LIFECYCLE_V1` and `BOT_TARGET_RESOLVE_V1` provide structured discovery, target resolution and lifecycle control. Offline EveryBars stay collapsed; online EveryBars expand consistently. | +| **Bot state & strategies** | Framed bot-state reads and structured strategy mutations for migrated controls, including Warlock selectors. | +| **Inventory** | Bag-aware exact inventory for Backpack, Bag 1..4 and Keyring, including empty slots and container filtering. | +| **Item movement** | Whole-stack drag/drop between supported physical inventory slots through the Bridge. | +| **Equipment** | Structured equip and unequip workflows with authoritative refresh. | +| **Trade & item use** | Exact-item Trade, item use and item destruction through dedicated structured actions. | +| **Vendor** | Single-item sale, bulk Sell Vendor, Buyback and Open Items bridge workflows. | +| **Bank / Guild Bank** | Bridge-backed views and actions; exact physical BANK/GBANK deposits are implemented. | +| **Talents** | Premade specialization apply and editable custom talent apply with server verification. | +| **Glyphs** | Glyph display and apply-related workflows integrated with the character UI. | +| **Professions** | Profession recipe browsing/crafting plus targeted item recipes. | +| **Enchanting** | Dedicated Enchanting Trade Service using the native WoW Trade workflow. | +| **Quests** | Bridge-backed quest list and structured bot quest abandon. Native quest sharing remains available. | +| **Loot** | Structured loot profiles and exact persistent always-loot item add/remove. | +| **Group tools** | Formation, Roll, RTI, Pull Control, Disperse and other migrated group controls. | +| **Character information** | Bot skills, reputations, currencies/emblems, spellbook, stats and PvP stats. | +| **Outfits** | Outfit listing and actions through the Bridge. | +| **SelfBot** | Dedicated enable/disable, strategy and selected action support. | +| **Localization** | Eight runtime locales: `enUS`, `enGB`, `frFR`, `esES`, `deDE`, `ruRU`, `zhCN` and `koKR`. | + +--- -`GROUP` covers every controllable bot in the player's current party or raid. It does not target individual raid subgroups. +# Recent Milestone — Alt Roster & Bot Lifecycle -## Current state and strategy capabilities +The roster/lifecycle work was merged and post-merge audited on **30 August 2026**. -The addon and bridge negotiate dedicated capabilities so newer write/read paths are used only when both sides support them: +It standardizes lifecycle behavior across: + +- My Bots / Altbots; +- Group; +- Guild; +- Friends; +- Favorites. + +User-facing behavior now follows the same rule everywhere: + +- **offline bot** → EveryBar collapsed; +- **online bot** → EveryBar expanded; +- roster-specific UI state must not leak into another roster. + +The companion Bridge also gained the server-side lifecycle authorization and hardening required for these flows. + +--- + +# Bridge Capabilities + +The addon negotiates feature capabilities with the Bridge before using newer paths. + +Important current capabilities include: ```text STATE_FRAMING_V1 @@ -154,395 +128,58 @@ ITEM_SELL_SINGLE_V1 VENDOR_BUYBACK_V1 INVENTORY_BULK_SELL_V1 INVENTORY_OPEN_V1 +ITEM_DEPOSIT_EXACT_V1 GROUP_ROLL_V1 ENCHANT_TRADE_V1 CRAFT_RECIPE_TARGET_V1 QUEST_ABANDON_V1 +LOOT_RULE_ITEM_V1 +TALENT_APPLY_V1 +TALENT_SPEC_APPLY_V1 SELF_BOT_V1 SELF_STRATEGY_V1 SELF_ACTION_V1 +ALT_ROSTER_V1 +BOT_LIFECYCLE_V1 +BOT_TARGET_RESOLVE_V1 ``` -`STATE_FRAMING_V1` uses tokenized `STATE` / `STATES` transactions with framed responses, bounded payloads, cleanup on terminal errors/timeouts, and stale-response protection. Per-bot requests use a 5-second timeout; global state requests use a 15-second timeout. - -`STRATEGY_MUTATION_V1` provides structured `co/nc` mutations through `RUN~STRATEGY` and completion through `STRATEGY_ACK`. The bridge reports matched, succeeded and failed bot counts, while the addon applies explicit timeout and rejection diagnostics. - -`INVENTORY_V1` provides the established native inventory read/refresh path. `INVENTORY_EXACT_V1` complements it with exact physical topology for Backpack, Bag 1..4 and Keyring, including empty slots and per-container filtering in the inventory UI. `ITEM_MOVE_V1` adds server-authoritative whole-stack drag/drop between allowed physical slots. The addon keeps only synthetic drag state: it does not call `PickupContainerItem`, `PickupInventoryItem`, `GetCursorInfo` or `ClearCursor`, and it does not mutate the displayed inventory optimistically; an exact snapshot refresh follows the server result. Stack splitting remains outside this capability. `ITEM_EQUIP_V1` equips an exact item from Backpack or Bag 1..4 through a structured bridge request and waits for the authoritative result before refreshing. `ITEM_UNEQUIP_V1` routes Inspect right-click through the exact equipment slot plus item ID, converts client Inspect slots 1..19 to Core slots 0..18, waits for the structured result and then refreshes. `ITEM_TRADE_V1` routes Inventory -> Trade through an exact source identity, preserves the native WoW Trade UI, waits for the structured `INVENTORY_ITEM_TRADE` result and keeps the historical give path behind the explicit compatibility fallback flag. The historical `ue` whisper fallback is used only when `MultiBot.allowLegacyChatFallback == true`; normal bridge-first configuration keeps that fallback disabled. `ITEM_USE_V1` uses the exact physical source, waits for the structured `INVENTORY_ITEM_USE` result and delegates execution to the native use-item path. `ITEM_DESTROY` is a specialized exact-item destruction path with server-side source revalidation and an authoritative result. `ITEM_SELL_SINGLE_V1` validates the exact source and nearby vendor before native single-item sale and returns `INVENTORY_ITEM_SELL`. `VENDOR_BUYBACK_V1` exposes a structured Buyback list/result flow and uses the native Buyback handler before authoritative inventory/list refreshes. `INVENTORY_BULK_SELL_V1` gates the current bulk-sell path. Normal `SELL_VENDOR` operation is bridge-first; the historical `s vendor` whisper is reachable only when `MultiBot.allowLegacyChatFallback == true`. The validated Bridge path accepts `ITEM_USAGE_VENDOR` only for `SELL_VENDOR` and excludes `ITEM_USAGE_AH`. `INVENTORY_OPEN_V1` gates the current `OPEN_ITEMS` bridge path. `GROUP_ROLL_V1` gates the group Roll workflow; normal rolls and item-linked rolls are tokenized and completed through a structured `GROUP_ROLL_ACK`. `ENCHANT_TRADE_V1` gates the Enchanting Trade Service: the addon lists only known Enchanting spells exposed by the bot, uses the native WoW Trade window and the non-traded item slot, then requests one validated numeric spell ID through the bridge. `QUEST_ABANDON_V1` routes bot quest abandon through a tokenized structured request/result; the player still abandons locally with the native WoW quest API, while the legacy `drop` group-chat fallback is available only when `MultiBot.allowLegacyChatFallback == true`. Quest sharing remains intentionally native through `QuestLogPushQuest()` and does not require a `QUEST_SHARE_V1` bridge capability. - -`CRAFT_RECIPE_TARGET_V1` handles profession recipes that require an exact bot-owned item target. Normal `RUN~CRAFT_RECIPE` remains unchanged for ordinary crafting and returns `TARGET_REQUIRED` for exact-item recipes. The addon then reuses the selected bot's Inventory and Inspect views, sends the exact `bag` / `slot` / `itemId` identity, keeps at most 8 pending target requests with a 5-second timeout and consumes `CRAFT_RECIPE_TARGET_RESULT` through the structured opcode dispatcher. Target selection is limited to equipment, Backpack and equipped Bag 1..4; Bank, Keyring and player Trade items are outside this capability. Recipes with `craftable > 0` are highlighted with a bright-green name, while non-craftable recipes keep their existing difficulty color. - -`SELF_BOT_V1` controls the player's own SelfBot mode with explicit ENABLE/DISABLE requests and authoritative state/result replies. `SELF_STRATEGY_V1` reads and mutates only the active SelfBot's whitelisted combat/non-combat strategies through framed state plus `SELF_STRATEGY_ACK`; it is not a generic strategy executor. `SELF_ACTION_V1` exposes only the audited SelfBot actions `AUTOGEAR`, `MAINTENANCE` and `WAIT_ATTACK_TIME`, with server-side SelfBot/security/rate-limit checks. These SelfBot paths are a separate completed workstream inherited by the Jellypowered v2 branch; normal-bot Maintenance/Autogear paths that still use legacy chat are not implicitly migrated by these capabilities. - -The migration is intentionally incremental. The Warlock stone, soulstone, pet and curse selectors are now migrated to structured `RUN~STRATEGY` mutations. When those selectors use the bridge, the addon waits for authoritative server `STATE` data before committing the selected UI state instead of applying an optimistic local state. Other specialized legacy UI paths still issue Playerbots chat commands directly and must be migrated before the addon can be described as fully chatless. - -Manual playerbot commands are still intentionally preserved for diagnostics and gameplay actions. - -Commands such as: - -```text -who -co ? -nc ? -ss ? -``` - -still work when the player explicitly wants to inspect a bot state. - -The goal is not to remove useful manual commands. -The goal is to remove automatic UI-refresh spam. - -The remaining legacy Playerbots Trade inventory dump is also suppressed locally by the addon. The filter recognizes the exact `=== Inventory ===` dump from known bots and hides that automatic dump for Inventory -> Trade, Enchanting -> Trade and the native WoW client Trade action, while leaving the Trade workflow itself unchanged. - -### Warlock weapon-enchant diagnostic - -For targeted runtime diagnostics, the addon exposes: - -```text -/mbdebug enchant [bot] -``` - -If the bot name is omitted, the current target is used. The command sends a single `GET~WEAPON_ENCHANT` request and displays the structured `WEAPON_ENCHANT` response with main-hand/off-hand item entries, temporary enchant IDs and remaining durations. This path is diagnostic only: it is on-demand, server-authorized and rate-limited, and is not used for polling or normal selector state synchronization. - -The endpoint and safe Firestone/Spellstone switching code are present, but the project-level final revalidation of the real `TEMP_ENCHANTMENT_SLOT` behavior is intentionally deferred until the end of the normal roadmap. +The exact protocol is an implementation detail of the addon and Bridge. The normal user experience should remain UI-driven. --- -# Features - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AreaStatus
Bridge handshakeImplemented — HELLO, HELLO_ACK, PING, PONG
Roster refreshBridge-first
Bot statesBridge-first, framed — STATE_FRAMING_V1, tokenized STATE/STATES transactions, bounded payloads, timeout cleanup and stale-response protection
Strategy mutationsBridge-first where migrated — STRATEGY_MUTATION_V1, RUN~STRATEGY, STRATEGY_ACK and explicit rejection/timeout diagnostics
Warlock strategy selectorsBridge-first and runtime validated — Stones, Soulstones, Pets and Curses use structured strategy mutations; bridge-backed selections wait for authoritative state, invalid Warlock dps/dps debuff controls and the disabled Buff placeholder were removed, and the selector layout was compacted
Bot detailsBridge-first
StatsBridge-first
PvP statsBridge-first
Talent spec templatesBridge-first and runtime validated — GET~TALENT_SPEC_LIST lists server-side premade templates; TALENT_SPEC_CURRENT returns the authoritative active slot/tree totals, and TALENT_SPEC_APPLY_V1 applies a server-revalidated template index to slot 1 or 2 with dual-spec handling, glyph initialization and structured verification without normal chat commands
Custom talent applyBridge-first and runtime validated — TALENT_APPLY_V1 validates the complete custom talent build against the bot class/DBC/available points, applies it through the audited Playerbots factory path and confirms success only after authoritative tree-point verification
InventoryBridge-first, exact and bag-aware — INVENTORY_V1 remains the established read/refresh path, while INVENTORY_EXACT_V1 exposes Backpack, Bag 1..4 and Keyring with physical locations, empty slots and container filters
Inventory item moveBridge-first and runtime validated — ITEM_MOVE_V1 moves one whole stack by synthetic addon drag/drop between allowed physical slots, waits for the structured server result and refreshes the exact snapshot without using the native player cursor APIs
Inventory item equipBridge-first and runtime validated — ITEM_EQUIP_V1 equips one exact item from Backpack or Bag 1..4 through the Bridge, waits for the structured result and refreshes authoritatively without optimistic UI mutation
Inspect item unequipBridge-first and runtime validated — ITEM_UNEQUIP_V1 routes Inspect right-click by exact equipment slot and item ID; the legacy ue whisper is available only when MultiBot.allowLegacyChatFallback == true and is disabled in normal bridge-first configuration
Inventory item useBridge-first and runtime validated — ITEM_USE_V1 revalidates the exact physical source, executes through the native use-item path, returns a structured result and refreshes authoritatively
Inventory item destroyBridge-first and runtime validated — ITEM_DESTROY uses a specialized exact-item request with server-side source revalidation and an authoritative result
Inventory item single sellBridge-first and runtime validated — ITEM_SELL_SINGLE_V1 revalidates the exact source and nearby vendor, performs the native sale and returns a structured INVENTORY_ITEM_SELL result
Vendor BuybackBridge-first and runtime validated — VENDOR_BUYBACK_V1 lists authoritative Buyback entries, executes one native buyback after server validation and refreshes inventory and Buyback state
Inventory bulk sellBridge-first and runtime revalidated — INVENTORY_BULK_SELL_V1 routes SELL_VENDOR and the existing SELL_GREY action through the bridge. For SELL_VENDOR, the legacy s vendor path is available only when MultiBot.allowLegacyChatFallback == true; the Bridge accepts ITEM_USAGE_VENDOR only and excludes ITEM_USAGE_AH. Runtime regression tests preserved Symbol of Kings and Gold Ore. Further SELL_GREY work remains deferred.
Open itemsBridge-first and validated — INVENTORY_OPEN_V1 / OPEN_ITEMS with structured result handling and no silent chat fallback in normal bridge-first use
Group RollBridge-first and runtime validated — GROUP_ROLL_V1 supports normal 0–100 rolls and Shift+click item rolls with tokenized pending state, duplicate-send protection and structured ACK handling
SpellbookBridge-first combat spell listing separated from profession recipe data
Character Info frameBridge-first Blizzard-style tabs for skills, reputations and currencies/emblems
Bot bank / guild bank / vendor buyBridge-first bank and guild-bank snapshots plus vendor buy actions. `BANK_DEPOSIT` and `GBANK_DEPOSIT` use negotiated ITEM_DEPOSIT_EXACT_V1 when available, carrying exact bag/slot/itemId/count source identity and whole-stack semantics. Bank and guild-bank withdrawals remain on the existing non-exact-stack path; exact withdrawals are deferred.
Profession recipe frameBridge-first and runtime validated — recipe listing and normal crafting remain on RUN~CRAFT_RECIPE; item-target recipes return TARGET_REQUIRED and continue through CRAFT_RECIPE_TARGET_V1 with exact Inventory/Inspect selection by bag/slot/itemId. Recipes currently craftable are highlighted with a bright-green name.
Enchanting Trade ServiceBridge-first and runtime validated — ENCHANT_TRADE_V1 exposes known Enchanting services, reagent/tool availability and native Trade-slot execution without a generic cast/chat executor; the same dedicated window is available from the enchanter EveryBar and Character Info, with UI text localized in all eight runtime locales. Enchantments for which all reagents and required tools are present are highlighted with a bright-green name.
Trade inventory chat suppressionRuntime validated — the legacy Playerbots === Inventory === Trade-start dump is hidden for Inventory, Enchanting and native client Trade openings; the filter is limited to the exact dump sequence from known bots and does not modify Playerbots or the Bridge
GlyphsBridge-first with glyph icons and tooltips
Loot rulesBridge-first and runtime validated — loot enable/disable and loot-list profiles remain on RUN~LOOT; exact always-loot item add/remove uses negotiated LOOT_RULE_ITEM_V1 with structured results and no normal chat/whisper path.
Loot Master frameImplemented optional auto-opening master-loot UI with candidate scoring, preferences and recent loot history
Units / EveryBarsImproved login, reload and AddClass refresh behavior
Random bot visibilityImproved bridge-visible grouped randombots alongside AddClass bots and altbots
Party / raid formation controlsBridge-first and chatless — left-click applies one formation to every controllable bot in the current party or raid through RUN~FORMATION; right-click reads each bot's effective formation through GET~FORMATIONS and displays a localized tooltip
Legacy automatic chat fallbackDisabled by default
OutfitsBridge-first listing, create/update, reset, equip and replace
QuestsBridge-first incompleted, completed and all quest lists with dark result frames and per-bot abandon buttons
Game object searchBridge-first results and copy frame without localized chat parsing
RTI controlsBridge-first icon assignment and RTI target actions
Pull ControlBridge-first wait, focus, DPS assist, AoE and RTI pull/attack controls
Combat strategy fine tuningBridge-first avoid AoE, save mana, threat and behind controls
Disperse controlsBridge-first distance set and disable actions through RUN~POSITION
Loot Master frameImplemented optional auto-opening master-loot UI with candidate scoring, preferences and recent loot history
Units / EveryBarsImproved login, reload and AddClass refresh behavior
Random bot visibilityImproved bridge-visible grouped randombots alongside AddClass bots and altbots
Legacy automatic chat fallbackDisabled by default
- ---- - -# Requirements - -## Client +# Compatibility & Legacy Chat -- World of Warcraft 3.3.5a / Wrath of the Lich King client. -- Tested with: - - English / US client - - German client - - French client - - Spanish client -- Localization files included for enUS, enGB, frFR, esES, deDE, ruRU, zhCN and koKR. +The addon deliberately keeps some manual Playerbots commands for diagnostics and explicit gameplay use. -## Server +Automatic compatibility fallback is disabled by default: -- [`AzerothCore WotLK`](https://github.com/mod-playerbots/azerothcore-wotlk/tree/Playerbot). -- [`mod-playerbots`](https://github.com/mod-playerbots/mod-playerbots). -- [`mod-multibot-bridge`](https://github.com/Wishmaster117/mod-multibot-bridge). - ---- - -# Installation - -## 1. Install the server-side bridge module - -Clone the bridge module inside your AzerothCore `modules` directory: - -```bash -cd /path/to/azerothcore/modules -git clone https://github.com/Wishmaster117/mod-multibot-bridge.git mod-multibot-bridge -``` - -Expected structure: - -```text -azerothcore/ -└── modules/ - └── mod-multibot-bridge/ - ├── conf/ - └── src/ +```lua +MultiBot.allowLegacyChatFallback = false ``` -Then: - -1. Re-run CMake if required by your build workflow. -2. Rebuild AzerothCore. -3. Copy/install the generated configuration file if required. -4. Start the server. -5. Check that `mod-multibot-bridge` is loaded. - -When the addon connects successfully, the server console should show messages similar to: - -```text -MBOT HELLO -MBOT HELLO_ACK -MBOT PING -MBOT PONG -GET~ROSTER -GET~STATES -GET~DETAILS -``` +When a migrated Bridge feature is available, the addon should prefer the structured path and wait for authoritative server state instead of pretending an action succeeded locally. --- -## 2. Install the client addon - -Clone this repository into your World of Warcraft AddOns directory. - -```bash -cd "World of Warcraft/Interface/AddOns" -git clone https://github.com/Wishmaster117/MultiBot-Chatless.git MultiBot -``` - -Expected structure: - -```text -World of Warcraft/ -└── Interface/ - └── AddOns/ - └── MultiBot/ - ├── MultiBot.toc - ├── Core/ - ├── Data/ - ├── Features/ - ├── Icons/ - ├── Libs/ - ├── Locales/ - ├── Strategies/ - ├── Textures/ - └── UI/ -``` - -> The GitHub repository is named `MultiBot-Chatless`, but the local addon folder must be named `MultiBot`. - -Do not install it like this: - -```text -Interface/AddOns/MultiBot/MultiBot/MultiBot.toc -``` +# Installation -The `.toc` file must be directly here: +1. Install and configure AzerothCore with `mod-playerbots`. +2. Install [`mod-multibot-bridge`](https://github.com/Wishmaster117/mod-multibot-bridge) on the server and rebuild AzerothCore. +3. Copy or clone this repository as: ```text -Interface/AddOns/MultiBot/MultiBot.toc -``` - ---- - -# Updating - -## Update the addon - -```bash -cd "World of Warcraft/Interface/AddOns/MultiBot" -git pull +World of Warcraft/Interface/AddOns/MultiBot ``` -## Update the bridge module - -```bash -cd /path/to/azerothcore/modules/mod-multibot-bridge -git pull -``` - -Then rebuild your AzerothCore server if the module code changed. - ---- - -# Recommended Configuration - -For normal bridge-first usage, keep legacy automatic chat fallback disabled: - -```lua -MultiBot.allowLegacyChatFallback = false -``` - -Only enable it temporarily for debugging or compatibility testing: - -```lua -MultiBot.allowLegacyChatFallback = true -``` +4. Start the server and log into the WoW 3.3.5a client. +5. Confirm the addon and Bridge handshake successfully. --- # Usage -Start World of Warcraft and use one of the following commands: +Open MultiBot with any of these slash commands: ```text /multibot @@ -550,414 +187,84 @@ Start World of Warcraft and use one of the following commands: /mb ``` -You can also use the minimap button. - -When the bridge is available, the addon automatically uses structured bridge messages for the main UI refresh paths instead of legacy chat replies. - -Manual commands are still available when you intentionally want them. - -Examples: - -```text -/w BotName who -/w BotName co ? -/w BotName nc ? -/w BotName ss ? -``` - ---- +You can also open the addon from its minimap button. -# Bridge-First Architecture - -
- - - - - - - - - - - - - - - - - - - - - - -
Old behaviorNew behavior
Addon triggers bot commandsAddon sends structured MBOT GET~... requests
Bots answer with chat textBridge returns structured addon messages
Addon parses localized chat linesAddon consumes stable protocol payloads
Automatic UI refresh creates chat spamMain UI refresh paths are mostly chatless
- -
+When the Bridge is available, supported UI actions automatically use the structured bridge-first path; you do not need to type protocol commands manually. --- # Current Status -Implemented bridge-first / chatless areas: - -- Bridge handshake: `HELLO`, `HELLO_ACK`, `PING`, `PONG`. -- Roster refresh. -- Bot states through `STATE_FRAMING_V1`, with tokenized per-bot/global transactions, framed responses, bounded state payloads, timeout cleanup and stale-response protection. -- Strategy mutations through `STRATEGY_MUTATION_V1` for migrated controls, with `RUN~STRATEGY`, `STRATEGY_ACK`, result counters and explicit rejection/timeout diagnostics. -- Bot details refresh. -- Stats refresh. -- PvP stats refresh. -- Talent spec list refresh. -- Inventory read/refresh through `INVENTORY_V1`, complemented by `INVENTORY_EXACT_V1` for bag-aware physical topology across Backpack, Bag 1..4 and Keyring, including empty slots and per-container filters. -- Whole-stack inventory drag/drop through `ITEM_MOVE_V1`, with synthetic addon drag state, no native player cursor APIs, no optimistic inventory mutation and an exact snapshot refresh after the structured server result. Stack splitting remains out of scope. -- Exact inventory equip through `ITEM_EQUIP_V1`, with source identity revalidation, authoritative result handling and no optimistic UI mutation. -- Exact Inspect unequip through `ITEM_UNEQUIP_V1`, with exact equipment slot/item identity and legacy `ue` fallback disabled unless explicitly enabled. -- Generic exact-item Trade through `ITEM_TRADE_V1`, with exact source identity, native WoW Trade UI preservation, native AzerothCore trade handling, structured `INVENTORY_ITEM_TRADE` completion and legacy give fallback only when compatibility fallback is explicitly enabled. Runtime validation passed in both trade directions. -- Exact item use through `ITEM_USE_V1`, with native use-item execution, source revalidation, structured result handling and localized failure reasons. -- Exact item destruction through the specialized `ITEM_DESTROY` path with server-side source revalidation. -- Exact single-item vendor sale through `ITEM_SELL_SINGLE_V1`, with nearby-vendor validation, protected-item guards, replay/rate limiting and structured result handling. -- Vendor Buyback through `VENDOR_BUYBACK_V1`, with structured list/result messages, native Buyback execution and authoritative inventory/list refreshes. -- Bulk inventory sell through `INVENTORY_BULK_SELL_V1` when supported; `SELL_VENDOR` is bridge-first in normal operation, its historical `s vendor` fallback is reachable only when `MultiBot.allowLegacyChatFallback == true`, and the validated Bridge action accepts `ITEM_USAGE_VENDOR` only while excluding `ITEM_USAGE_AH`. Runtime regression testing preserved Symbol of Kings and Gold Ore; SELL_GREY follow-up remains deferred. -- `OPEN_ITEMS` through `INVENTORY_OPEN_V1`, with structured result handling and no silent chat fallback in the normal bridge-first path. -- Group Roll through `GROUP_ROLL_V1`: normal 0–100 roll and Shift+click item roll, tokenized pending state, duplicate-send protection, timeout/cleanup handling and structured `GROUP_ROLL_ACK`. -- SelfBot enable/disable through `SELF_BOT_V1`, with explicit desired state, authoritative server verification and legacy `.playerbot bot self` fallback only when compatibility fallback is explicitly enabled. -- SelfBot strategy state/mutation through `SELF_STRATEGY_V1`, restricted to the player's active SelfBot and server-side class/state allowlists. -- SelfBot EveryBar actions through `SELF_ACTION_V1` for `AUTOGEAR`, `MAINTENANCE` and `WAIT_ATTACK_TIME`; this does not migrate equivalent normal-bot legacy chat paths. -- Spellbook refresh, with profession/crafting spells separated from the combat spellbook path. -- Character Info frame through the bridge with Blizzard-style tabs for class, profession, secondary, weapon and armor skills, reputations and currencies/emblems. -- Bot bank and guild bank snapshots through the bridge, plus vendor buy and bank/guild-bank item actions. Exact deposits use `ITEM_DEPOSIT_EXACT_V1`: the addon sends the selected inventory `bag/slot/itemId/count`, waits for the authoritative structured result and refreshes after success. Runtime validation confirmed only the clicked physical stack moves for both BANK and GBANK; stale source identity is rejected with `SOURCE_STALE`. Exact BANK/GBANK withdrawals are deferred because their current snapshots do not expose a selectable physical source stack end to end. -- Profession recipe frame through the bridge, opened from profession and secondary skill rows. Normal recipes use `RUN~CRAFT_RECIPE`; exact-item recipes continue through the runtime-validated `CRAFT_RECIPE_TARGET_V1` flow after `TARGET_REQUIRED`, using exact Inventory/Inspect `bag/slot/itemId` selection. Recipes with `craftable > 0` use a bright-green name. -- Enchanting Trade Service through `ENCHANT_TRADE_V1`: dedicated enchanter-only UI from EveryBar/Character Info, known-spell listing, reagent/tool availability, native `TRADE_SLOT_NONTRADED` targeting and validated numeric spell execution without generic Playerbots command/chat dispatch. Entries with all required reagents and tools available use a bright-green name. -- Glyph refresh with icons and glyph tooltips. -- Outfits refresh and actions through the bridge. -- Outfit equip/replace without detailed `Equipping [item] ...` chat spam. -- Quest list refresh through the bridge. -- Quest abandon through `QUEST_ABANDON_V1`: right-click keeps the player's native `SetAbandonQuest()` / `AbandonQuest()` path, sends a structured bot-abandon request through the bridge and emits no legacy `drop` chat in normal bridge-first configuration. Runtime validation with one controlled bot passed with zero chat spam and zero Lua errors; the mixed multi-bot scenario is explicitly deferred until suitable bots are available. -- Quest sharing remains intentionally native/chatless through `QuestLogPushQuest()`; no `QUEST_SHARE_V1` endpoint is required for the current behavior. -- Game object search results and copy frame through the bridge. -- RTI controls through the bridge. -- Pull Control frame through the bridge. -- Combat strategy fine tuning through the bridge. -- Disperse controls through the bridge with `disperse set ` and `disperse disable`. -- Party/raid-wide formation application through `RUN~FORMATION`, with per-bot effective formation inspection through `GET~FORMATIONS` and no PARTY/RAID chat output. -- Localized formation status tooltip for all eight addon locale files. -- Loot rules through the bridge with `nc +loot` and `nc -loot`. For the audited Playerbots build, the verified loot-list modes are `all`, `normal`, `gray` and `disenchant`; the older Quest/Skill wording is not treated as a validated capability. The audited Playerbots profile set is `all`, `normal`, `gray` and `disenchant`; the Quest/Skill versus Disenchant decision is closed in favor of `disenchant`. Exact always-loot item add/remove is handled by `LOOT_RULE_ITEM_V1`. -- Loot Master UI for master-loot distribution with item tooltips, candidate scoring, profession/spec hints, saved preferences and recent loot history. -- Bridge-visible bot discovery for AddClass bots, altbots and grouped randombots. -- Custom glyph socket mapping and apply order. -- Talent tab navigation stability after switching between tabs. -- Automatic bot reconnect on login/reload for bots already present in the group or raid. -- Units bar refresh after adding a bot through AddClass. - -Validated development milestones on the current line: - -- PR #49 — bridge synchronization, strategy controls, persistent/offline favorites and STATE stabilization. -- PR #50 — explicit strategy-command rejection diagnostics. -- PR #51 — mechanical deduplication of shared roster workflow helpers. -- PR #53 — prevent silent chat fallback for strategy mutations. -- PR #54 — outfit actions migrated to the negotiated bridge capability. -- PR #55 — strict bridge routing for inventory read/refresh. -- PR #58 — single-bot inventory Sell Vendor migrated to the bridge. -- PR #60 — bridge-first `OPEN_ITEMS`. -- PR #61 — chatless Group Roll UI, merged as `106074c3c93f80812f73af27e746860c7c8a4dcf`. -- PR #67 — Jellypowered chatless/inventory integration merged into `main`, merge commit `70e72ba6cb9a7170497b201e0dbe469bb29e6be9`. -- PR #72 — `Complete SelfBot chatless integration`, merged into `main`; current audited Addon baseline is merge commit `833d541063f207354c4131cf6a614c7df176348d`. -- The current `jellypowered-chatless-integration-v2` branch was created from that `main` baseline on 2026-08-20 and initially matched `main`/`origin/main`/its remote tracking branch at 0/0 ahead-behind. -- Final static STATE/strategy audit on 2026-08-07: 57 checks, 0 failures; final manual runtime matrix remains pending. -- Warlock selector batch is migrated to bridge strategy mutations; final project-level real TEMP_ENCHANT revalidation and the four remaining LuaLint warnings are explicitly deferred. -- Group Roll runtime validation on 2026-08-14: normal roll, item roll, eligibility, no chat spam, duplicate protection, invalid/empty item rejection and pending cleanup all validated. -- Enchanting Trade Service runtime validation on 2026-08-14: enchanter-only button, list/search/tooltips, localized 440 px frame, normal WoW Trade flow and real item enchant application all validated with no automatic chat executor. - - -## Talent migration progress — 2026-08-21 - -- `TALENT_APPLY_V1` is implemented, compiled and runtime validated for the editable **Custom Talents** flow. The Bridge validates the complete build, reuses the audited Playerbots parse/apply path, verifies the resulting three talent-tree totals with `BuildTalentTabPoints`, resets strategies only after successful verification, and the Addon displays localized success only after the structured server `OK`. -- `TALENT_SPEC_APPLY_V1` is implemented, compiled and runtime validated for the EveryBar premade specialization selector. `TALENT_SPEC_CURRENT` replaces the normal current-spec whisper, left-click applies slot 1, right-click applies slot 2 including dual-spec creation/validation where eligible, the server reproduces cast interruption, revalidates the premade spec index, applies talents, resets `custom_glyphs`, runs `InitGlyphs(false)`, verifies final tree totals and returns one structured result. -- Normal Bridge operation no longer needs `talents`, `talents spec list`, `stopcasting`, `talents switch ` or `talents spec ` for these selector flows. The historical chat path remains available only when `MultiBot.allowLegacyChatFallback == true`. -- Both talent success/failure messages are localized in the 8 currently loaded locales; successful operations are shown in white only after authoritative server confirmation. -- `mod-playerbots` remains strictly read-only and no generic Playerbots command executor was introduced. - -`CRAFT_RECIPE_TARGET_V1` is now implemented, compiled and runtime validated. - -`SELL_VENDOR` safety hardening was completed and runtime revalidated on 2026-08-23. The Addon remains bridge-first and exposes the historical `s vendor` whisper only when `MultiBot.allowLegacyChatFallback == true`; the Bridge accepts `ITEM_USAGE_VENDOR` only for this action and excludes `ITEM_USAGE_AH`. Symbol of Kings and Gold Ore were both preserved in the runtime regression test while `SELL_VENDOR` remained functional. Validated commits: Addon `fe2c807785219b82ca885f1a95d7c1dc27f0eed0`, Bridge `3ccf5047f7994218b742312fe1437f4b303f7159`. - -The bank / guild-bank comparison produced the completed `ITEM_DEPOSIT_EXACT_V1` P3A path. Exact BANK withdrawal (P3B) and exact GBANK withdrawal (P3C) remain intentionally deferred because their current read models do not expose a physical source stack end to end. `LOOT_RULE_ITEM_V1` is now also complete, runtime validated, persistent and localized. The Quest/Skill versus Disenchant decision is now closed from the audited Playerbots implementation: `disenchant` is retained, while `Quest` and `Skill` are not exposed as validated loot profiles. The next normal-roadmap work is the selector audit for collective `follow` / `attack` / `stay` orders. -`LOOT_RULE_ITEM_V1` adds or removes one exact `itemId` from the audited Playerbots `always loot list` value. The protocol supports `ALL`, `RAID`, `GROUP`, `PARTY` and `BOT` scopes; the current Loot menu intentionally sends `ALL`. The Bridge revalidates requester/session/world state, strict scope/target syntax, visible controllable bots, Playerbots security, bot session/world/alive/context and the item template before mutation, with a maximum of 128 matched bots. Requests are bounded to 8 per requester per 2 seconds with 10-second replay protection, 32 recent tokens and 512 requester states. Only bots whose list actually changes are persisted, and a global budget of 128 bot saves per 10 seconds rejects the whole operation with `PERSISTENCE_BUSY` before mutation when insufficient capacity remains. Runtime validation covered ADD, idempotent ADD, REMOVE, idempotent REMOVE, invalid input/item rejection, item-link input, disconnect/reconnect persistence, full worldserver-restart persistence, localized results in the eight existing locale files and the corrected clickable/editable prompt, with no chat/whisper spam observed. - -Known migration remaining: - - -- Remaining direct `SendChatMessage` occurrences outside migrated paths still need to be classified as manual command, diagnostic fallback, information message, UI mechanism to migrate, compatibility fallback, or dead code. -- Item enchanting is now **implemented and runtime validated** through the closed `ENCHANT_TRADE_V1` Trade Service; it does not expose a generic cast or arbitrary Playerbots command executor. -- `ITEM_MOVE_V1` already covers whole-stack movement between allowed Backpack / Bag 1..4 / Keyring physical slots, including inter-container moves. A future `BAG_MOVE` item must therefore mean moving/re-equipping the **bag objects themselves** in equipped bag slots, not moving ordinary inventory items. -- Generic exact-item Trade is now implemented and runtime validated through `ITEM_TRADE_V1`; it remains distinct from the specialized `ENCHANT_TRADE_V1` service and does not expose a generic command executor. -- Quest abandon is now implemented through `QUEST_ABANDON_V1` and runtime validated with one bot. Quest sharing remains native through `QuestLogPushQuest()`. The mixed multi-bot Quest Abandon runtime scenario is deferred until suitable bots are available. -- `TALENT_APPLY_V1`, `TALENT_SPEC_APPLY_V1`, `CRAFT_RECIPE_TARGET_V1`, P3A `ITEM_DEPOSIT_EXACT_V1` and `LOOT_RULE_ITEM_V1` are complete and runtime validated. `ITEM_DEPOSIT_EXACT_V1` moves only the selected physical inventory stack for BANK/GBANK deposits and rejects stale `bag/slot/itemId/count` identity before mutation. `LOOT_RULE_ITEM_V1` performs exact persistent always-loot add/remove with structured results and bounded persistence. P3B/P3C exact withdrawals are deferred. The Quest/Skill versus Disenchant decision is complete: `disenchant` is the verified Playerbots loot profile retained by the UI, while `Quest` and `Skill` are not exposed as validated loot profiles. The next normal-roadmap item is the collective `follow` / `attack` / `stay` selector audit. -- The project should be described as **bridge-first / mostly chatless**, not fully chatless, until these remaining paths are classified/migrated and the final runtime matrix is closed. - -Kept intentionally: - -- Manual whisper/playerbot commands for diagnostics. -- Commands such as `who`, `co ?`, `nc ?`, `ss ?`. -- Gameplay write actions that still rely on existing playerbot commands. -- Optional legacy fallback behavior only for debugging or compatibility. - ---- - -# Remaining Work - -The previous `jellypowered-chatless-integration-v2` line is now historical baseline context. Current audited development is on `feature/loot-disenchant-mainbar` in both the Addon and Bridge. That branch carries the completed Quest/Skill-to-Disenchant profile change and MainBar loot-profile synchronization. Normal-roadmap development now continues from the updated `main` baselines; no new functional work should be stacked onto the historical v2 branches. - -Immediate normal-roadmap work: - -1. Audit the exact Playerbots selectors and semantics for collective `follow`, `attack` and `stay` before any structured group-order migration. - -Completed on the historical `jellypowered-chatless-integration-v2` line: `TALENT_APPLY_V1`, `TALENT_SPEC_APPLY_V1`, `CRAFT_RECIPE_TARGET_V1`, the 2026-08-23 `SELL_VENDOR` safety hardening, P3A `ITEM_DEPOSIT_EXACT_V1` and `LOOT_RULE_ITEM_V1`. P3A was runtime validated for BANK and GBANK with two identical physical stacks: only the selected stack moved, while a deliberately stale `count` returned `SOURCE_STALE` and left the real stack unchanged. `LOOT_RULE_ITEM_V1` was validated for exact ADD/REMOVE, idempotence, persistence across reconnect and worldserver restart, localized UI/results and no chat/whisper spam. - -Low-priority residual: moving/re-equipping the **equipped bag objects themselves** (`BAG_MOVE`) only if the need remains; ordinary item moves between Backpack / Bag 1..4 / Keyring are already covered by `ITEM_MOVE_V1`. - -Explicitly deferred until the normal roadmap is complete: - -- P3B — exact BANK withdrawal; current bank withdrawal snapshot is aggregated and needs a wider protocol/UI design. -- P3C — exact GBANK withdrawal; physical source selection is not exposed end to end to the addon. -- Dedicated localized UI text for `SOURCE_STALE`; the current generic error text is non-blocking. -- SELL_GREY / sell-grey core API / bridge-first follow-up. -- Final real Firestone/Spellstone `TEMP_ENCHANTMENT_SLOT` revalidation. -- Four remaining LuaLint warnings in `Strategies/MultiBotWarlock.lua`. -- Other small items that were explicitly deferred during previous validated batches. - -Ongoing finalization work remains unchanged: regression testing, classification of residual `SendChatMessage` paths, removal of dead legacy parsers only after proof of non-regression, and documentation/screenshot cleanup after wider testing. - ---- - -# Troubleshooting +The major read paths and a large part of the action surface are now bridge-first and runtime validated. -
-The addon does not load +The project is **not declared fully chatless yet**. Remaining `SendChatMessage` paths are handled family by family so that useful manual commands are not removed accidentally and legacy compatibility is not broken without testing. -Check that the folder is named exactly: +The next normal roadmap item is a targeted audit of collective: ```text -Interface/AddOns/MultiBot +follow +attack +stay ``` -and that the `.toc` file is here: - -```text -Interface/AddOns/MultiBot/MultiBot.toc -``` +No generic arbitrary Playerbots command executor is planned. -If the `.toc` file is inside another nested `MultiBot` folder, the addon is installed incorrectly. +Detailed development history, audits, deferred work and technical residuals are tracked in the project documentation. -
- -
-The addon loads but the bridge does not connect - -Check that: - -- `mod-multibot-bridge` is installed in the AzerothCore `modules` directory. -- AzerothCore was rebuilt after installing the module. -- The server was restarted after rebuilding. -- The bridge module is visible in server logs. -- Your client is logged into a character connected to the server. +--- -
+# Documentation -
-I still see some chat messages +- [`docs/ROADMAP.md`](docs/ROADMAP.md) — technical source of truth, completed milestones, audit references, next work and deferred backlog. +- [`docs/DEBUG_RUNBOOK.md`](docs/DEBUG_RUNBOOK.md) — in-game debug commands, observability guidance and bug-report procedure. -This project removes automatic UI-refresh spam where the bridge path has been implemented. +--- -Manual commands and gameplay actions may still produce intentional messages. +# Deferred / Lower-Priority Work -Make sure this value is disabled unless you are debugging: +The active roadmap currently keeps these items outside the next normal feature batch: -```lua -MultiBot.allowLegacyChatFallback = false -``` +- exact BANK withdrawal (P3B); +- exact Guild Bank withdrawal (P3C); +- dedicated localized `SOURCE_STALE` UI text; +- moving/re-equipping the equipped bag objects themselves (`BAG_MOVE`); +- `SELL_GREY` follow-up; +- final real Firestone/Spellstone `TEMP_ENCHANTMENT_SLOT` revalidation; +- remaining Warlock LuaLint warnings; +- selected lifecycle/idempotence hardening for older pending-command flows. -
+--- -
-The formation tooltip does not appear or is incomplete +# Credits -Check that the bridge is connected and that the bots are controllable members of the same party or raid as the player. +MultiBot Chatless builds on the AzerothCore and `mod-playerbots` ecosystem. -A right-click on the Formation button should produce structured bridge traffic similar to: +Special thanks to **Macx-Lio** for the original MultiBot Module that this project builds upon. -```text -GET~FORMATIONS~GROUP~~ -FORMATIONS_BEGIN~~ -FORMATIONS_ITEM~~~ -FORMATIONS_END~~ -``` +The project also retains attribution for the external **Jellypowered** bridge work that was audited and selectively adapted during the chatless migration. Details and commit references are preserved in the project roadmap. -The query is raid-wide: it includes all controllable bots in the current party or raid and does not target individual raid subgroups. +--- -
+# Troubleshooting -
-Inventory, spellbook, glyphs or outfits do not update +### The addon does not load -Check the server console for bridge requests such as: +Confirm the folder is named exactly: ```text -GET~INVENTORY -GET~BANK -GET~GBANK -GET~SPELLBOOK -GET~GLYPHS -GET~OUTFITS -GET~BOT_SKILLS -GET~BOT_REPUTATIONS -GET~BOT_EMBLEMS -GET~PROFESSION_RECIPES -GET~QUESTS -GET~GAMEOBJECTS +MultiBot ``` -If these requests do not appear, the addon may not be connected to the bridge. - -
- -
-The Loot Master frame does not open - -Check that: - -- The Loot Master UI option is enabled in the addon options. -- The group loot method is set to Master Loot. -- Your character is the detected master looter. -- The opened loot contains relevant loot slots. - -The frame uses the client master-loot candidate API and enriches candidates with cached bridge details when available. - -
- -
-The Loot Master frame does not open - -Check that: - -- The Loot Master UI option is enabled in the addon options. -- The group loot method is set to Master Loot. -- Your character is the detected master looter. -- The opened loot contains relevant loot slots. - -The frame uses the client master-loot candidate API and enriches candidates with cached bridge details when available. - -
- ---- - -# Project Documentation - -The active project documentation is intentionally limited to two files: - -- [Development roadmap](docs/ROADMAP.md) — current phases, priorities, risks and acceptance criteria. -- [Debug and observability runbook](docs/DEBUG_RUNBOOK.md) — in-game debug commands, performance counters and bug-report procedure. - ---- - -# Repository Layout +and is located under: ```text -MultiBot-Chatless/ -├── Core/ -├── Data/ -├── Features/ -├── Icons/ -├── Libs/ -├── Locales/ -├── Strategies/ -├── Textures/ -├── UI/ -├── docs/ -│ ├── DEBUG_RUNBOOK.md -│ └── ROADMAP.md -└── MultiBot.toc +World of Warcraft/Interface/AddOns/ ``` ---- - -# Related Repositories - - - - - - - - - - - - - - - - - - - - - - -
RepositoryDescription
- - MultiBot-Chatless - - - Client-side World of Warcraft addon. -
- - mod-multibot-bridge - - - AzerothCore server-side bridge module. -
- - MultiBot-Standalone - - - Deprecated combined repository kept for history. -
- - mod-playerbots - - - Original AzerothCore Playerbots module. -
- ---- - -# Credits - -MultiBot is built for use with AzerothCore `mod-playerbots`. - -Thanks to Macx-Lio for the original MultiBot Module. +### Bridge features are unavailable -Thanks to the Playerbots team and the AzerothCore community. +Confirm `mod-multibot-bridge` is installed, configured, compiled and loaded by the same AzerothCore server used by the client. ---- - -
+### I still see some Playerbots chat -## MultiBot Chatless - -Less automatic chat spam. Cleaner UI refreshes. Bridge-first bot data. - -

- - - Client Addon - - â€˘  - - Bridge Module - - -
+That does not automatically mean the Bridge is broken. Manual commands and a small number of intentionally retained or not-yet-migrated paths still exist while the project remains **mostly chatless**. diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index a90984e..f288a17 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -1,654 +1,518 @@ -# Multibot Chatless + Bridge — Roadmap de reprise - -Statut : roadmap active issue de l'audit initial v1c du 1er août 2026, resynchronisée le 27 août 2026 après clôture de P3A `ITEM_DEPOSIT_EXACT_V1`, de `LOOT_RULE_ITEM_V1` et de la décision Quest/Skill versus Disenchant. Le lot `jellypowered-chatless-integration-v2` est désormais une baseline historique. Le chantier courant est `feature/loot-disenchant-mainbar` dans l'Addon et le Bridge. `disenchant` est le profil Playerbots retenu ; `Quest` et `Skill` ne sont pas traités comme profils de loot validés. Le prochain chantier normal est l'audit des ordres collectifs `follow`, `attack`, `stay`. -Dernière mise à jour : 27/08/2026 — le commit Addon `9e5d28ba0d20c68924e1adaec22fd20dd8f9c895` remplace les profils UI `Quest`/`Skill` par `Disenchant` et synchronise l'état visuel MainBar ; le commit Bridge `c2c48b604a10b619d08f27c39cc5ecf6e3f174a6` remplace la whitelist `Quest`/`Skill` par `Disenchant`. L'audit Playerbots en lecture seule confirme `DisenchantLootStrategy`, `GetName() == "disenchant"` et les alias `d`, `e`, `disenchant`, `enchant`. Le prochain chantier normal est l'audit ciblé des sélecteurs Playerbots pour `follow`, `attack`, `stay`. P3B/P3C, `SOURCE_STALE` UI, `BAG_MOVE`, SELL_GREY, Firestone/Spellstone et LuaLint restent différés ; `TODO.md` reste séparé et inchangé. -Cette roadmap est la source de vérité active du projet. `TODO.md` reste un fichier de notes local séparé et est volontairement exclu de cette synchronisation documentaire. - -## Baseline auditée - -Synchronisation documentaire fondée sur : - -- `audit-multibot-jellypowered-docs-baseline-v2-2026-08-20-172627.zip` ; -- `audit-multibot-jellypowered-git-state-supplement-v1-2026-08-20-173756.zip` ; -- `audit-multibot-jellypowered-bag-move-item-trade-v1-2026-08-20-174218.zip`. - -- Addon : `L:\ChromieCraft_3.3.5a\Interface\AddOns\MultiBot` - - branche `jellypowered-chatless-integration-v2`, créée depuis `main` le 20/08/2026 ; - - HEAD = `main` = `origin/main` = `origin/jellypowered-chatless-integration-v2` au baseline audité : `833d541063f207354c4131cf6a614c7df176348d` ; - - ahead/behind versus `main` : `0/0` avant cette synchronisation documentaire ; - - PR Jellypowered #67 déjà mergée, merge commit `70e72ba6cb9a7170497b201e0dbe469bb29e6be9` ; - - PR SelfBot #72 **Complete SelfBot chatless integration** déjà mergée ; le chantier SelfBot reste séparé du développement Jellypowered ; - - seul `TODO.md` est modifié localement et non stagé ; il est explicitement hors scope de cette synchronisation. -- Bridge : `L:\AC_PB\azerothcore-wotlk\modules\mod-multibot-bridge` - - branche `jellypowered-chatless-integration-v2`, créée depuis `main` le 20/08/2026 ; - - HEAD = `main` = `origin/main` = `origin/jellypowered-chatless-integration-v2` au baseline audité : `d42b23dd288b6ff0871c57bedd98856b705594da` ; - - ahead/behind versus `main` : `0/0` avant cette synchronisation documentaire ; - - PR Jellypowered #28 déjà mergée, merge commit `5e5ff7594ec8afedf40926605a60848dbc14991e` ; - - PR SelfBot #30 **Complete SelfBot chatless bridge support** déjà mergée ; le worktree Bridge est propre au baseline audité. -- Playerbots : `L:\AC_PB\azerothcore-wotlk\modules\mod-playerbots` - - **lecture seule stricte** ; fingerprints source identiques avant/après les audits ciblés du 20/08/2026. -- Communication actuelle : bridge-first pour les principaux rafraîchissements UI et pour plusieurs actions d'écriture explicitement bornées ; des occurrences `SendChatMessage` subsistent et doivent être classées/migrées famille par famille. -- Fallback automatique legacy désactivé par défaut : `MultiBot.allowLegacyChatFallback = false`. Certains chemins de compatibilité historiques restent toutefois explicitement documentés jusqu'à leur migration ou leur suppression validée. - -## Règles de progression - -Audit → Analyse → Proposition → Validation utilisateur → Patch minimal → Vérifications → Compilation → Tests en jeu → Audit final → Archivage - -- Aucun patch à l'aveugle. -- Aucun changement dans `mod-playerbots`. -- Un patch = un objectif. -- Rollback et hashes obligatoires. -- Ne jamais ajouter d'exécuteur bridge générique acceptant une commande Playerbots arbitraire. - -## Contribution externe Jellypowered — RÉFÉRENCE CONSERVÉE, ATTRIBUTION OBLIGATOIRE - -Deux sources Jellypowered sont conservées comme références de recherche. **Aucune ne doit être fusionnée directement dans `main`.** - -### Contribution initiale reçue le 04/08/2026 - -- auteur : Jellypowered `` ; -- commits : `13059a9f334d1e5aaa8560ab29a1814e48b07054`, `7ff1347535be6d5a3256d933731c11c4b3f3b38e`, `04061f084bd189487f1ac0e99892316146f1bea0` ; -- cette contribution reste une source historique à comparer avec l'état actuel. - -### Fork `Extended` audité le 15/08/2026 — REPRISE SÉLECTIVE PRIORITAIRE - -- fork : `Jellypowered/mod-multibot-bridge`, branche `Extended` ; -- commit `89da6a9dd15be77c3cbfe9be88a9885b632d606a` — extension générale du bridge ; -- commit `40bc0e378b1723d746d3425d4ee0818fd01531c6` — utilisation native d'item ; -- commit `7f9027faf6126bd2854d9f5e84f9a7fa82549077` — resynchronisation partielle avec les fonctions upstream ; -- audit : `audit-multibot-jellypowered-extended-v1-2026-08-15-025145.zip` ; -- SHA-256 réel : `88a64500cb339fe8842d1f3b5a0553145d12f5eff34bbe9e30bd0fed04ed2d7b` ; -- `mod-playerbots` est resté strictement en lecture seule. - -La branche `Extended` est divergente et ne doit pas être mergée en bloc. Chaque fonction suit obligatoirement cette matrice : - -`Fonction Jellypowered` -→ `Déjà présente chez nous ?` -→ `Absente / partielle / différente ?` -→ `Compatible avec notre sécurité ?` -→ `Utile à la roadmap ?` -→ `REPRENDRE / ADAPTER / REJETER` - -### Fonctions à ajouter ou adapter après audit sémantique ciblé - -1. **Support multi-préfixes addon configurables — TERMINÉ / VALIDÉ** - - audit ciblé initial : `audit-multibot-multiprefix-v1c-2026-08-15-133152.zip` ; - - `MBOT` reste le préfixe MultiBot par défaut ; l'Addon peut utiliser les préfixes configurés et le Bridge applique une whitelist stricte et bornée ; - - le Bridge répond sur le même préfixe que la requête reçue et n'accepte aucun préfixe arbitraire ; - - le budget des messages addon reste borné à 255 octets et a été revalidé pendant la stabilisation CAPS. - -2. **Inventaire à emplacements exacts, UI bag-aware et déplacement natif — TERMINÉ / VALIDÉ EN JEU** - - audits ciblés de conception terminés : - - `audit-multibot-inventory-exact-locations-v1-2026-08-15-135528.zip` ; - - `audit-multibot-inventory-bag-ui-v1-2026-08-15-142637.zip` ; - - `INVENTORY_EXACT_V1` est implémenté comme fondation complémentaire à l'`INVENTORY_V1` historique : le chemin legacy `INV_BEGIN` / `INV_ITEM` reste conservé pour les fonctions déjà validées ; - - le Bridge expose la topologie réelle des conteneurs avec `INV_BAG` et les piles physiques avec `INV_ITEM_LOC`, en utilisant les coordonnées AzerothCore réelles comme référence canonique ; - - les coordonnées et métadonnées permettent de distinguer sans ambiguïté Backpack, sacs équipés, Keyring et piles identiques situées dans des emplacements physiques différents ; - - `INV_EQUIP_LOC` n'a pas été nécessaire pour la V1 `ITEM_EQUIP_V1` validée et reste différé jusqu'à l'apparition d'un consommateur réel ; - - `INVENTORY_BULK_SELL_V1` et `INVENTORY_OPEN_V1` restent préservés ; - - les données exactes ne sont jamais une autorisation : joueur, contrôle du bot, session/map, coordonnées, item, quantité et état runtime restent revalidés côté Bridge. - - **UI bag-aware réalisée et validée :** - - taille générale de la fenêtre conservée ; zone grille/scroll réduite pour réserver la barre basse ; - - barre basse : **Backpack + Sac 1 + Sac 2 + Sac 3 + Sac 4 + Keyring** ; - - aucune sélection = vue globale ; clic sur un conteneur = filtre local ; second clic sur le même conteneur = retour à la vue globale ; - - changement de bot = retour à la vue globale ; rafraîchissement du même bot = filtre conservable ; - - les emplacements vides sont dessinés et les items sont placés dans leurs coordonnées physiques réelles ; - - les quatre sacs équipés utilisent leurs vraies icônes ; un emplacement de sac absent reste visible mais désactivé ; - - Backpack utilise la texture client 3.3.5a validée ; Keyring utilise une icône verticale étroite `13x28` sans cadre carré, avec une zone cliquable `32x32` ; - - les tooltips Backpack / Sac 1..4 / Keyring sont couverts dans les 8 locales Addon auditées ; - - tests en jeu validés : `/reload`, rendu initial, slots vides, vue globale, filtres Backpack/Sac 1/Sac 2/Sac 3/Sac 4/Keyring, retour à Tous, traductions FR et rendu final Keyring ; - - le trafic exact reste lié au consommateur UI : l'Addon conserve le chemin legacy puis demande le snapshot exact pour la fenêtre d'inventaire ; aucun polling global n'est introduit. - - **`ITEM_MOVE_V1` réalisé et validé :** - - endpoint spécialisé `RUN~ITEM_MOVE` pour déplacer une pile entière entre slots physiques autorisés ; le split-stack reste explicitement hors scope ; - - drag/drop synthétique côté Addon avec `RegisterForDrag("LeftButton")`, résolution de la destination via `GetMouseFocus()` / `__mbExactSlot`, sans `PickupContainerItem`, `PickupInventoryItem`, `GetCursorInfo` ni `ClearCursor` ; - - aucune mutation optimiste de l'UI : le résultat structuré `INVENTORY_ITEM_MOVE` déclenche un nouveau snapshot exact ; - - le Bridge revalide bot contrôlable, sessions/monde, source/destination, `itemId`, quantité et positions autorisées Backpack / sacs équipés / Keyring ; - - protection serveur : **8 requêtes / 2 s / requester**, TTL anti-rejeu **10 s**, **32** tokens récents maximum par requester, état requester borné à **512**, quantité bornée à **1000** ; - - exécution native par **un seul `Player::SwapItem`**, puis relecture autoritative de la source et de la destination ; succès uniquement si l'état réel a changé ; - - aucun `SplitItem`, `HandleCommand`, `DoSpecificAction`, exécuteur Playerbots générique ni dépendance chat/whisper sur le chemin `ITEM_MOVE_V1` ; - - tests en jeu validés : drag/drop même conteneur et inter-conteneurs, rafraîchissement exact après résultat, absence de spam chat et absence de régression constatée ; - - UI finale validée : groupes visuels par conteneur en vue globale, titres repositionnés, nom jaune redondant supprimé, panneau actions gauche **120 px**, espacement des actions **36/38**, grille inventaire conservée à **8 colonnes** ; - - audit final : `audit-multibot-item-move-final-v1b-2026-08-15-195912.zip` — `FINAL_STATUS=OK`, `FAILURE_COUNT=0`, `WARNING_COUNT=0` ; - - attribution Jellypowered à conserver pour les parties réellement reprises ou substantiellement adaptées depuis `Extended`. - -3. **Lectures bulk — AUDITÉ / NON INTÉGRÉ** - - audit ciblé : `audit-multibot-jellypowered-bulk-reads-v1-2026-08-15-205840.zip` — `FINAL_STATUS=OK`, `FAILURE_COUNT=0`, `WARNING_COUNT=0` ; - - `GET~INVENTORY_BULK` : **rejeter/différer dans sa forme Extended** ; - - il recouvre partiellement les données déjà fournies par `INVENTORY_EXACT_V1`, qui reste la source autoritative pour la topologie physique Backpack / sacs / Keyring et pour `ITEM_MOVE_V1` ; - - Extended réutilise `INV_BAG` et `INV_ITEM_LOC` avec des schémas incompatibles avec ceux déjà validés dans notre protocole exact ; - - aucun consommateur Addon actuel ne nécessite une snapshot d'inventaire multi-bot ; - - la boucle sur tous les bots visibles n'est pas explicitement bornée et peut amplifier fortement le trafic addon et les logs ; - - aucun framing générique, comptage de complétude, pagination, ACK ou rate-limit dédié n'est fourni par Extended pour cette famille ; - - `GET~BOT_SKILLS_BULK` : **différer jusqu'à l'apparition d'un consommateur multi-bot réel** ; - - `GET~BOT_SKILLS` unitaire et `BuildBotSkillEntries` couvrent déjà le besoin actuel de Character Info ; - - le format Extended inverse `skillId` et `category` par rapport au schéma `BOT_SKILLS_ITEM` déjà utilisé ; - - toute reprise future devra conserver le schéma unitaire existant et ajouter des limites explicites de bots/entrées/octets, rate-limit, token/timeout et contrôle de complétude ; - - aucun besoin de modifier `mod-playerbots` et aucun exécuteur générique/chat Playerbots n'est requis pour ces lectures ; - - décision : **aucun patch C++/Lua pour ce point** ; le chantier est clos par documentation uniquement. - -4. **Équipement et déséquipement natifs d'un item précis — TERMINÉ / VALIDÉ EN JEU** - - `ITEM_EQUIP_V1` utilise l'endpoint spécialisé `RUN~ITEM_EQUIP~bot~token~srcBag~srcSlot~srcItemId~srcCount` et le résultat structuré `INVENTORY_ITEM_EQUIP` ; - - la source est limitée au Backpack et aux sacs équipés, avec identité exacte `bag/slot/itemId/count`, revalidation serveur du bot, des droits, sessions, état runtime et source avant exécution ; - - l'exécution passe par l'auto-équipement natif AzerothCore ; aucun `HandleCommand`, `DoSpecificAction`, exécuteur Playerbots générique ni mutation optimiste Addon n'est utilisé ; - - le résultat autoritatif déclenche le rafraîchissement de l'inventaire et les tests en jeu ont validé Backpack, sacs 1..4, remplacement d'un slot occupé, interactions 2H/offhand, double-clic rapide, refus d'un objet non équipable et absence de whisper/chat parasite ; - - `ITEM_UNEQUIP_V1` utilise l'endpoint spécialisé `RUN~ITEM_UNEQUIP~bot~token~srcSlot~srcItemId` et le résultat structuré `INVENTORY_ITEM_UNEQUIP` ; - - le clic droit Inspect convertit le slot client `1..19` en slot Core `0..18`, puis le Bridge revalide le slot équipé et l'`itemId`, capture le GUID et utilise la voie native `CMSG_AUTOSTORE_BAG_ITEM` vers l'inventaire ; - - le succès n'est annoncé que si le même GUID est retrouvé hors équipement dans un emplacement physique autorisé Backpack/Sac 1..4 ; aucun appel à `UnequipAction` Playerbots n'est utilisé ; - - protections `ITEM_UNEQUIP_V1` : **8 requêtes / 2 s / requester**, TTL anti-rejeu **10 s**, **32** tokens récents maximum par requester et état requester borné à **512** ; - - le fallback legacy `ue` n'est possible que lorsque `MultiBot.allowLegacyChatFallback == true`; avec la configuration bridge-first normale (`false`), aucun whisper automatique n'est émis ; - - tests en jeu validés : slot simple, main hand, 2H/offhand, inventaire plein, double clic rapide, aucune perte/duplication, rafraîchissement cohérent et zéro chat parasite. - -5. **Utilisation native d'un item précis — TERMINÉ / VALIDÉ EN JEU** - - `ITEM_USE_V1` utilise une source physique exacte et un résultat structuré `INVENTORY_ITEM_USE` ; - - le Bridge revalide le bot, l'identité de la source et l'état runtime avant d'emprunter le chemin natif `HandleUseItemOpcode` ; - - aucune mutation optimiste Addon ; le snapshot est rafraîchi après le résultat autoritatif ; - - la postcondition des objets démarrant une quête a été corrigée ; le cas négatif « quête déjà acceptée » reste un test runtime différé, pas un chantier `ITEM_USE_V1` à réimplémenter. - -6. **Déplacement/rééquipement des sacs équipés eux-mêmes — À ADAPTER, priorité faible** - - `ITEM_MOVE_V1` couvre déjà les piles d'items dans Backpack / sacs 1..4 / Keyring, y compris les déplacements inter-conteneurs ; - - le résiduel `BAG_MOVE` concerne uniquement l'objet sac placé dans un emplacement de sac équipé ; - - les emplacements d'équipement des sacs ne font pas partie de la whitelist actuelle `ITEM_MOVE_V1` et ne doivent pas être ajoutés sans audit dédié ; - - ne jamais présenter ce point comme un déplacement générique des objets d'inventaire. - -7. **Échange générique d'un item précis — TERMINÉ / VALIDÉ EN JEU — `ITEM_TRADE_V1`** - - l'UI Inventory -> Trade utilise désormais un endpoint structuré bridge-first avec identité de source exacte et résultat `INVENTORY_ITEM_TRADE` ; - - le workflow natif WoW Trade est préservé et le Bridge emprunte le handler AzerothCore natif pour placer l'item exact dans le Trade ; - - le fallback historique de don/échange reste derrière `MultiBot.allowLegacyChatFallback == true` et n'est pas utilisé en configuration bridge-first normale ; - - `ENCHANT_TRADE_V1` reste un service spécialisé distinct et n'a pas été généralisé ; - - validation runtime du 20/08/2026 : Trade natif validé dans les deux sens, aucune régression de l'UI Trade et aucun exécuteur générique de commande Playerbots. - -8. **Abandon et partage de quête — TERMINÉ POUR LE BESOIN ACTUEL** - - `QUEST_ABANDON_V1` utilise `RUN~QUEST_ABANDON~token~questId` et un résultat structuré `QUEST_ABANDON_RESULT` ; - - le Bridge limite l'exécution aux bots visibles du requester appartenant au même groupe, revalide la sécurité Playerbots, la session/l'état monde et recherche la quête dans les slots bornés `0..MAX_QUEST_LOG_SIZE-1` ; - - l'abandon bot passe par `WorldPackets::Quest::QuestLogRemoveQuest`, `Read()` puis `WorldSession::HandleQuestLogRemoveQuest`, avec vérification de postcondition ; - - protections : **4 requêtes / 2 s / requester**, TTL anti-rejeu **10 s**, **32** tokens récents maximum et **512** états requester maximum ; - - côté Addon, le joueur conserve l'abandon WoW natif `SetAbandonQuest()` / `AbandonQuest()` ; le fallback historique `drop ` n'est disponible que si `MultiBot.allowLegacyChatFallback == true` ; - - test runtime 1 bot du 20/08/2026 : joueur et bot abandonnent correctement, zéro chat/whisper parasite, zéro erreur Lua ; - - **test différé roadmap** — `DEFERRED_RUNTIME_TEST_NO_BOTS_AVAILABLE` : scénario avec plusieurs bots dont au moins un sans la quête, faute de bots disponibles au moment de la validation ; - - `QUEST_SHARE` est déjà natif/chatless via `QuestLogPushQuest()` : aucun endpoint `QUEST_SHARE_V1` n'est créé ni nécessaire pour le comportement actuel. - -9. **Application/reset de talents — TERMINÉ / VALIDÉ EN JEU — `TALENT_APPLY_V1` / `TALENT_SPEC_APPLY_V1`** - - `TALENT_APPLY_V1` applique un build personnalisé complet après validation serveur de la classe, des DBC et des points disponibles, puis confirme le résultat par vérification autoritative des points d'arbres ; - - `TALENT_SPEC_APPLY_V1` applique un modèle prémade revalidé côté serveur au slot 1 ou 2, avec gestion de la double spécialisation et initialisation des glyphes ; - - ces chemins utilisent des résultats structurés et ont été validés en jeu sans commande chat normale. - -10. **Artisanat ciblé — TERMINÉ / COMPILÉ / VALIDÉ EN JEU — `CRAFT_RECIPE_TARGET_V1`** - - `RUN~CRAFT_RECIPE` reste inchangé pour le craft normal et renvoie `TARGET_REQUIRED` lorsqu'une recette exige une cible item exacte ; - - l'Addon réutilise Inventory + Inspect du bot pour sélectionner exactement `bag/slot/itemId`, avec au plus **8** requêtes ciblées en attente et un timeout de **5 s** ; - - scope cible autorisé : équipement, Backpack et sacs équipés 1..4 ; Bank, Keyring et objet Trade joueur sont exclus de `CRAFT_RECIPE_TARGET_V1` ; - - le Bridge revalide requester/session, contrôle du bot, profession/recette, matériaux/outils, position autorisée et identité courante de l'item avant exécution ; - - la cible est re-résolue par `GetItemByPos`, contrôlée par `Spell::InitExplicitTargets()` / `CheckCast(true)` puis exécutée sur l'`Item*` exact ; - - protections serveur validées pour ce service : **4 requêtes / 2 s / requester**, TTL anti-rejeu **10 s**, **32** tokens récents maximum et **512** états requester maximum ; - - résultat structuré `CRAFT_RECIPE_TARGET_RESULT`, sans fallback chat normal ; `ENCHANT_TRADE_V1` reste le service séparé pour l'objet joueur dans `TRADE_SLOT_NONTRADED` ; - - tests runtime : craft simple **OK**, enchantement d'un objet exact appartenant au bot **OK**, aucun spam chat observé ; - - amélioration UI validée : recette `craftable > 0` en vert vif, sinon couleur de difficulté conservée ; dans la fenêtre Enchantements, `entry.available ~= 0` (tous réactifs + outils requis présents) affiche également le nom en vert. - -11. **Banque / banque de guilde / vendeur — COMPARER PUIS ADAPTER** - - ces familles existent déjà dans notre Bridge ; - - ne reprendre que les améliorations démontrables : emplacement exact, quantités, droits, proximité, validation ; - - ne considérer aucun endpoint vendeur supplémentaire comme acquis sans preuve dans le code. - -12. **Comptage d'inventaire / restauration de sélection — COMPARER PUIS ADAPTER** - - ne reprendre que les corrections démontrées par audit comparatif. - -### Fonctions et modèles explicitement rejetés - -- **`RUN~CAST_SPELL` générique : REJETER.** - - un `spellId` arbitraire avec cible élargit trop la surface d'action ; - - préférer des endpoints spécialisés et bornés comme `ENCHANT_TRADE_V1`. - -- **Tout exécuteur Bridge générique de commande Playerbots ou de texte libre : REJETER.** - - aucun nouvel endpoint ne doit transmettre une commande Playerbots arbitraire ; - - les helpers de type `HandleCommand()` ne sont pas un modèle pour les nouvelles fonctions. - -- **Toute logique contournant les validations serveur : REJETER.** - - permissions, contrôle du bot, session/map/Trade, longueurs, nombres, emplacements, quantités, rate limiting, erreurs structurées et timeouts restent obligatoires. - -- **Toute modification de `mod-playerbots` : INTERDITE.** - -### Règle d'intégration Extended - -Audit ciblé → Analyse comparative → classification `REPRENDRE` ou `ADAPTER` → validation utilisateur → patch minimal → vérifications → compilation si C++ → tests en jeu → audit final → archivage. - -Aucune fonction Extended ne doit être marquée comme intégrée avant validation runtime. - -### Attribution obligatoire - -- conserver le nom de Jellypowered et les hashes des commits réellement étudiés ; -- chaque PR précise ce qui est repris, adapté, réécrit ou rejeté ; -- reprise substantielle, lorsque pertinent : - `Co-authored-by: Jellypowered ` ; -- réécriture seulement inspirée : - `Design inspired by the Jellypowered bridge contribution.` ; -- les crédits sont ajoutés uniquement pour les parties réellement intégrées et validées. - -Statut : **audit Extended validé ; reprise sélective réalisée et historique conservé ; merge direct du fork toujours interdit.** L'ancienne branche `feature/jellypowered-chatless-integration` et la ligne `jellypowered-chatless-integration-v2` restent des références historiques. Le développement courant audité est `feature/loot-disenchant-mainbar`, créé depuis les `main` mis à jour et à un commit devant `origin/main` dans l'Addon et le Bridge au pré-patch V1c du 27/08/2026. - - -## Phase 0 — Assainissement documentaire — TERMINÉE - -Objectif : repartir avec une documentation courte, actuelle et non contradictoire. - -Réalisé par `patch-multibot-docs-cleanup-roadmap-v1-2026-08-01-162227` : - -- les 18 anciens trackers ont été sauvegardés puis retirés du dossier actif ; -- `TODO.md` a été consolidé dans cette roadmap puis retiré ; -- `docs/ROADMAP.md` est la source de vérité active ; -- `docs/DEBUG_RUNBOOK.md` consolide le guide de debug et d'observabilité ; -- le README référence les deux documents actifs ; -- le package contient un rollback intégral et vérifiable. +# Multibot Chatless + Bridge — Roadmap -Critère de sortie : phase validée par `verify.ps1`, avec hashes post-patch conformes et aucun ancien document actif. +**Statut : active** +**Dernière synchronisation : 30/08/2026** -## Validation livrée — Formations chatless — APPLICATION ET CONSULTATION VALIDÉES LE 03/08/2026 +Cette roadmap est la **source de vérité technique** du projet. +Les README Addon/Bridge servent de vitrine fonctionnelle et restent volontairement plus courts. -Patches fonctionnels validés : +`TODO.md` est un fichier local séparé et n'est pas utilisé comme source de vérité de cette roadmap. -- application : `patch-multibot-formation-chatless-v1c-2026-08-01-181300` ; -- consultation : `patch-multibot-formation-query-chatless-v1-2026-08-03-195340` ; -- localisation : `patch-multibot-formation-query-i18n-v1b-2026-08-03-210300`. +--- -Périmètre validé : +## 1. Baseline actuelle -- les clics gauche `arrow`, `queue`, `near`, `melee`, `line`, `circle`, `chaos` et `shield` utilisent désormais `RUN~FORMATION~GROUP` ; -- le bridge applique directement `FormationValue::Load()` sans passer par `HandleCommand()` ni par l'action Playerbots `set formation` ; -- le fonctionnement est validé avec la stratégie `passive`, en groupe et pour l'ensemble des bots contrôlables d'un raid ; -- aucun fichier de `mod-playerbots` n'a été modifié ; -- l'icône de l'addon n'est mise à jour qu'après un `FORMATION_ACK` complet ; -- aucun message `formation ...` n'est envoyé dans PARTY ou RAID pour ces clics ; -- le clic droit utilise `MultiBot.Comm.RequestFormations()` puis `GET~FORMATIONS~GROUP` ; -- le bridge lit la valeur effective de chaque bot avec `FormationValue::Save()` et renvoie `FORMATIONS_BEGIN/ITEM/END` ; -- le résultat est affiché localement, une ligne par bot, dans un tooltip traduit pour les huit locales supportées ; -- aucun message PARTY, RAID, WHISPER ou `TellMaster` n'est produit par la consultation. +### Addon -Preuves de validation : +```text +Repo: L:\ChromieCraft_3.3.5a\Interface\AddOns\MultiBot +Branch: main +HEAD: 09e0233c1f2e17d03c191d1be67da926767c955d +Remote: origin/main = même HEAD +``` -- compilation `worldserver` validée par l'utilisateur ; -- audit runtime : `audit-multibot-runtime-tests-v1c-2026-08-03-184046.zip` ; -- SHA-256 de l'audit : `7E3FBD948C51FAE34351B97B416BDFA663061F4577932F6AC251C79ECE933F25` ; -- 11 requêtes `RUN~FORMATION`, 11 réponses `FORMATION_ACK`, 55 applications réussies et 0 échec ; -- les huit formations ont provoqué visuellement le déplacement attendu des bots ; -- l'icône a été mise à jour visuellement sans message chat visible ; -- aucune erreur Lua MultiBot ni ancien blocage `PassiveMultiplier` observé ; -- audit de consultation : `audit-multibot-runtime-tests-v1c-2026-08-03-203219.zip` ; -- SHA-256 de cet audit : `44627A920618C747BD9EEB0384D118FFFA13157828677172E46A642436677CB5` ; -- 9 requêtes `GET~FORMATIONS`, 9 séquences `FORMATIONS_BEGIN/END` et 23 réponses individuelles `FORMATIONS_ITEM` ; -- tooltip local et traductions validés visuellement par l'utilisateur, sans sortie chat. +- PR #75 **Feature/alt roster bot lifecycle** mergée. +- `TODO.md` reste une modification locale séparée et hors scope des patches documentaires. -Reste explicitement hors périmètre : +### Bridge -- la formation Playerbots `far` existe dans le module de référence mais n'est pas exposée par l'interface actuelle. +```text +Repo: L:\AC_PB\azerothcore-wotlk\modules\mod-multibot-bridge +Branch: main +HEAD: 24cef0badfde0c06fc0b917b7510f8f15220a775 +Remote: origin/main = même HEAD +``` -## Validation intermédiaire — STATE framing + Strategy Mutation — STATIQUE VALIDÉE LE 07/08/2026, RUNTIME FINAL À TERMINER +- PR #34 **Feature/alt roster bot lifecycle** mergée. +- Baseline post-merge auditée et propre. -Baseline intégrée : +### Playerbots -- PR #49 : synchronisation bridge, contrôles stratégies, favoris persistants et stabilisation STATE ; -- PR #50 : diagnostics explicites des rejets `RunStrategyCommand` ; -- PR #51 : déduplication mécanique des helpers partagés de workflow roster ; -- addon `main` : `270911305acf3e806d389712a34a9433131db981`. +```text +Repo: L:\AC_PB\azerothcore-wotlk\modules\mod-playerbots +HEAD: 2f7d9f774987d0157c6a0d0cc08c40bec3db3945 +Mode: STRICT READ ONLY +``` -État STATE validé statiquement : +**Règle absolue :** aucune modification de `mod-playerbots` dans ce projet. -- capacité `STATE_FRAMING_V1` présente côté addon et bridge ; -- requêtes unitaires `GET~STATE` et globales `GET~STATES` gérées par transactions tokenisées ; -- framing `STATE_BEGIN/STATE_ITEM/STATE_END` et framing global `STATES_BEGIN/.../STATES_END` ; -- `STATE_ABORT` pris en compte comme échec de la requête concernée ; -- timeout par bot à 5 s et timeout global à 15 s ; -- limite de 32 requêtes STATE actives, 128 bots, 256 stratégies par scope, 192 caractères par stratégie et 32768 octets cumulés ; -- nettoyage des transactions sur timeout/erreur/déconnexion ; -- garde d'ordre par bot pour empêcher une réponse ancienne de remplacer un état plus récent. +### Architecture -État mutations stratégies validé statiquement : +Le projet est actuellement : -- capacité `STRATEGY_MUTATION_V1` présente côté addon et bridge ; -- mutations `co/nc` structurées via `RUN~STRATEGY` pour les chemins utilisant `MultiBot.Comm.RunStrategyCommand()` ; -- résultat serveur via `STRATEGY_ACK` avec compteurs `matched/succeeded/failed` ; -- limites de taille, nombre d'opérations et requêtes actives ; -- timeout à 5 s ; -- neuf diagnostics de rejet explicites ajoutés par F07 ; -- `RunStrategyCommand()` ne contient aucun `SendChatMessage`. +```text +bridge-first / mostly chatless +``` -Preuve d'audit final statique : +Le Bridge doit rester la couche principale d'adaptation entre l'Addon et Playerbots. -- archive : `audit-multibot-state-strategy-final-v1-2026-08-07-224000-2026-08-07-224709.zip` ; -- SHA-256 : `B00DBE597F554F9E20F2ABEFDC22097BC2A06DCDD3F07FD9F6522F98A7DF38DA` ; -- 57 contrôles, 0 échec ; -- addon, bridge et `mod-playerbots` ont des empreintes avant/après identiques pendant l'audit ; -- `mod-playerbots` reste strictement en lecture seule. +Le fallback automatique legacy reste désactivé par défaut : -Reste à terminer avant de fermer définitivement ce bloc : +```lua +MultiBot.allowLegacyChatFallback = false +``` -- le lot Warlock Stones/Soulstones/Pets/Curses est validé pour sa migration chatless et ne fait plus partie des reliquats `co/nc` prioritaires ; -- le comportement sans fallback silencieux des mutations stratégies a été durci et mergé après cette baseline intermédiaire ; -- exécuter/consolider la matrice runtime finale : zéro/un/plusieurs bots, listes longues, fragment manquant/dupliqué/désordonné, réponse tardive, timeouts, déconnexion en cours de transaction, mutations valides/invalides, bot absent, plusieurs bots, smoke test toutes classes, zéro erreur Lua, contrôle chat et logs ; -- classifier puis migrer les autres familles legacy réellement automatiques avant de déclarer le projet entièrement chatless. +--- -## Validation livrée — Sélecteurs Warlock chatless + Stones — MIGRATION CHATLESS VALIDÉE, RELIQUATS SUSPENDUS +## 2. Protocole de progression obligatoire -Périmètre validé et mergé : +Toujours suivre : -- les sélecteurs Warlock Stones, Soulstones, Pets et Curses utilisent le transport structuré `STRATEGY_MUTATION_V1` / `RUN~STRATEGY` lorsque le bridge est disponible ; -- le chemin bridge attend l'état serveur autoritatif au lieu de valider localement une mutation avant l'ACK ; -- les contrôles Warlock invalides `dps` et `dps debuff` ainsi que le placeholder Buff désactivé ont été retirés et le layout a été compacté ; -- le bridge contient le mécanisme de bascule Firestone/Spellstone et l'endpoint diagnostique à la demande `GET~WEAPON_ENCHANT` / `WEAPON_ENCHANT` ; -- aucun fichier de `mod-playerbots` n'est modifié. +```text +Audit +→ Analyse +→ Proposition +→ Validation utilisateur +→ Patch minimal +→ Vérifications +→ Compilation si C++ +→ Tests en jeu +→ Audit final +→ Archivage +``` -Décision de roadmap au 14/08/2026 : +Règles permanentes : -- la **vérification réelle finale du `TEMP_ENCHANTMENT_SLOT` Firestone/Spellstone** reste un chantier suspendu à reprendre seulement à la fin de la roadmap normale ; -- les **quatre warnings LuaLint restants dans `Strategies/MultiBotWarlock.lua`** restent également suspendus ; -- ces reliquats ne doivent pas interrompre le chantier suivant de la Phase 5. +- aucun patch à l'aveugle ; +- aucun changement dans `mod-playerbots` ; +- un patch = un objectif précis ; +- backup + rollback + hashes obligatoires ; +- ne jamais écraser les changements locaux ; +- ne jamais ajouter d'exécuteur Bridge générique acceptant une commande Playerbots arbitraire ; +- toute donnée reçue depuis l'Addon est non fiable et doit être revalidée côté Bridge. -## Synchronisation post-merge — État livré et validations consolidées jusqu'au 26/08/2026 +--- -Les jalons suivants, postérieurs à la mise à jour du 08/08, sont présents dans les branches `main` auditées : +## 3. État fonctionnel livré -- mutations stratégies : suppression du fallback chat silencieux lorsque le chemin structuré est requis ; -- Outfits : transport bridge-first et négociation `OUTFIT_V1` ; -- inventaire : lecture/rafraîchissement natifs via `INVENTORY_V1` ; -- banque, banque de guilde et achat vendeur : durcissements serveur des actions `ITEM_ACTION` ; -- vente inventaire `SELL_VENDOR` : bridge-first lorsque `INVENTORY_BULK_SELL_V1` est négocié ; le fallback legacy `s vendor` n'est accessible que si `MultiBot.allowLegacyChatFallback == true` ; côté Bridge, `SELL_VENDOR` accepte uniquement `ITEM_USAGE_VENDOR` et exclut `ITEM_USAGE_AH` ; validation runtime du 23/08/2026 : Symbol of Kings et Gold Ore conservés, vente vendeur toujours fonctionnelle ; -- `OPEN_ITEMS` : bridge-first via `INVENTORY_OPEN_V1`, avec traitement résiduel borné côté serveur ; -- `GROUP ROLL` : bridge-first via `GROUP_ROLL_V1`, avec mode normal et mode item, filtrage aux bots visibles/contrôlables du groupe, rate-limit serveur et ACK structuré. +Les blocs suivants ne doivent plus être présentés comme backlog actif. -Jalons de merge principaux : +### Fondation Bridge / état / stratégies -- Addon PR #58 — **Migrate inventory Sell Vendor to the bridge** ; -- Bridge PR #24 — **Add safe bridge-first SELL_VENDOR inventory action** ; -- Addon PR #60 — **Add bridge-first OPEN_ITEMS inventory action** ; -- Bridge PR #25 — **Add residual auto-safe OPEN_ITEMS handling** ; -- Addon PR #61 — **Add chatless group Roll UI** — merge `106074c3c93f80812f73af27e746860c7c8a4dcf` ; -- Bridge PR #26 — **Add chatless group Roll support** — merge `210bd1f4f6597fe4f0691ec729ec4904ebe2d463`. +- handshake et détection Bridge ; +- `STATE_FRAMING_V1` ; +- `STRATEGY_MUTATION_V1` ; +- migration progressive des sélecteurs UI vers des réponses structurées ; +- fallback legacy automatique désactivé par défaut. -Validation `GROUP ROLL` : +### Inventory / items -- roll normal 0–100 : OK ; -- roll avec objet par Shift+clic : OK ; -- seuls les bots éligibles au contexte Playerbots invoqué participent au roll item ; -- aucun whisper/chat parasite sur le workflow ; -- protection contre double envoi et refus d'un item vide/invalide ; -- pending nettoyé sur déconnexion/changement de monde ; -- UI finale validée : `240x245`, fond opaque style inventaire, padding horizontal `10 px`, padding vertical haut `10 px` ; -- compilation Bridge déjà validée sans erreur. +Livré et validé : -## Phase 1 — Baseline de compilation et tests de non-régression +- `INVENTORY_V1` ; +- `INVENTORY_EXACT_V1` ; +- UI bag-aware Backpack / Bag 1..4 / Keyring ; +- `ITEM_MOVE_V1` pour les piles d'items ordinaires ; +- `ITEM_EQUIP_V1` ; +- `ITEM_UNEQUIP_V1` ; +- `ITEM_TRADE_V1` ; +- `ITEM_USE_V1` ; +- destruction exacte d'item ; +- `ITEM_SELL_SINGLE_V1` ; +- `VENDOR_BUYBACK_V1` ; +- `INVENTORY_BULK_SELL_V1` / Sell Vendor ; +- `INVENTORY_OPEN_V1`. -Objectif : prouver le fonctionnement de l'état actuel avant toute correction source. +### Bank / Guild Bank -### Serveur / bridge +Livré : -- Compiler l'état Git audité sans modification. -- Vérifier le chargement de `mod-multibot-bridge` et de sa configuration. -- Vérifier `HELLO/HELLO_ACK`, `PING/PONG`, erreurs et logs. +- vues et actions Bridge existantes ; +- P3A `ITEM_DEPOSIT_EXACT_V1` pour dépôt exact BANK et GBANK ; +- validation de source physique et rejet `SOURCE_STALE`. -### Addon / jeu +P3B/P3C restent différés, voir section backlog. -Tester avec zéro, un et plusieurs bots : +### Talents / glyphes -- chargement initial, `/reload`, déconnexion/reconnexion ; -- bots personnels, AddClass bots et randombots groupés ; -- roster, states, details, stats et PVP stats ; -- inventaire, banque bot, banque de guilde, vendeur ; -- spellbook, talents, glyphes et outfits ; -- quêtes, objets de jeu, character info, réputations, monnaies ; -- recettes, craft et trainer ; -- RTI, Pull Control, Combat Strategies, Disperse et Loot Rules. +Livré et runtime validé : -Mesurer le chat visible avec `MultiBot.allowLegacyChatFallback = false`. +- `TALENT_APPLY_V1` ; +- `TALENT_SPEC_APPLY_V1` ; +- application custom ; +- application premade ; +- dual-spec/slot 1/2 selon le chemin validé ; +- vérification autoritative avant succès. -Critère de sortie : matrice de tests remplie, baseline compilée, bugs reproductibles séparés des impressions anciennes. +### Professions / Enchanting -## Phase 2 — Durcissement du bridge +Livré : -Objectif : traiter les risques de sécurité et de blocage avant de développer de nouvelles fonctions. +- listing des recettes ; +- craft normal ; +- `CRAFT_RECIPE_TARGET_V1` pour les recettes nécessitant un item cible exact ; +- `ENCHANT_TRADE_V1` et workflow Enchanting Trade Service. -- Ajouter des parseurs numériques stricts : chaîne entière valide, absence de signe négatif, contrôle d'overflow et bornes métier. -- Borner la taille totale des messages et la longueur de chaque champ. -- Borner les quantités d'actions item, notamment l'achat vendeur. -- Ajouter un rate limiting par joueur et par famille de requêtes `HELLO`, `PING`, `GET` et `RUN`. -- Revalider joueur, session, carte, propriété du bot, proximité PNJ et état du bot au moment de l'exécution. -- Borner les logs et désactiver les logs console par défaut même si la configuration est absente. -- Retourner des erreurs structurées et distinctes pour message malformé, limite dépassée, permission refusée et état incompatible. +### Quêtes -Critère de sortie : patch compilé, tests de messages malformés/volumineux, aucune boucle longue pilotable par le client. +Livré : -## Phase 3 — Stabilisation du protocole addon/bridge +- listing Bridge ; +- `QUEST_ABANDON_V1` ; +- partage de quête conservé comme comportement natif client quand applicable. -Objectif : fiabiliser les transactions et supprimer les ambiguïtés d'ACK. +### Loot -- Documenter chaque commande `GET` et `RUN`, ses champs, bornes, réponses et erreurs. -- Identifier les payloads non bornés ; fragmenter notamment le roster si les limites client l'exigent. -- Uniformiser les séquences `BEGIN/ITEM/END` et les tokens de transaction. -- Ajouter timeout, annulation, déduplication et gestion des réponses hors ordre côté addon. -- Distinguer : requête reçue, commande transmise à Playerbots et résultat effectivement vérifié. -- Vérifier perte, duplication, réponses tardives, changement de carte et déconnexion du bot. +Livré : -Critère de sortie : protocole documenté, transactions déterministes, aucune frame bloquée sur une requête perdue. +- profils de loot Bridge ; +- décision Quest/Skill versus Disenchant clôturée en faveur du profil Playerbots vérifié `disenchant` ; +- `LOOT_RULE_ITEM_V1` pour ADD/REMOVE exact et persistant de la liste always-loot. -## Phase 4 — Corrections runtime prioritaires +### SelfBot -Traiter un problème par patch, dans cet ordre : +Livré : -1. Reconnexion : bots inconnus dans l'UI de groupe Blizzard jusqu'à `/reload`. -2. AddClass bots créés ou sélectionnés au niveau 1 pour un joueur niveau 80. -3. Vérification fonctionnelle de Disperse. -4. Lenteur de l'affichage des glyphes et recentrage des icônes. -5. ID de quête affiché temporairement à la place du titre ; étudier l'avancement de quête par bot. -6. Inventaire au-delà de 16 emplacements. -7. Outfit avec deux armes à deux mains. -8. Compatibilité de l'UI talents/glyphes avec la configuration actuelle. -9. Quick Hunter/Shaman : croix stable et absence de quick bars pour un joueur humain. -10. Raidus : rafraîchissement ouverture/fermeture et purge des bots inconnus/SavedVariables. -11. Respect global du frame strata configuré. -12. Harmonisation de la frame PVP Stats. +- `SELF_BOT_V1` ; +- `SELF_STRATEGY_V1` ; +- `SELF_ACTION_V1` pour les actions explicitement auditées. -Critère de sortie : chaque correction possède reproduction avant, test après et non-régression ciblée. +### Group / combat tools -## Phase 5 — Migration des commandes chat restantes +Livré ou déjà migré selon les familles validées : -Objectif : réduire le chat par familles fonctionnelles, sans toucher à Playerbots. +- Formation ; +- Group Roll ; +- RTI ; +- Pull Control ; +- Disperse ; +- plusieurs contrôles combat/non-combat. -Avant chaque migration, classer l'occurrence `SendChatMessage` comme : +--- -- commande manuelle volontaire ; -- fallback diagnostic ; -- message d'information ; -- mécanisme UI à migrer ; -- code mort à supprimer. +## 4. Clôture Alt roster / bot lifecycle — 30/08/2026 -Ordre recommandé et état réel : +### Capacités livrées -1. **Formations — application par clic gauche : TERMINÉ / VALIDÉ** via `RUN~FORMATION~GROUP`. -2. **Consultation de la formation actuelle par clic droit : TERMINÉ / VALIDÉ** via `GET~FORMATIONS~GROUP`, `FORMATIONS_BEGIN/ITEM/END` et tooltip local traduit. -3. **Infrastructure mutations stratégies `co/nc` : TERMINÉE pour les chemins migrés** via `STRATEGY_MUTATION_V1`, `RUN~STRATEGY`, `STRATEGY_ACK`, timeouts, limites et diagnostics explicites. -4. **Sélecteurs Warlock Stones/Soulstones/Pets/Curses : TERMINÉS pour la migration chatless validée**. Les reliquats TEMP_ENCHANT réel et LuaLint sont suspendus et ne bloquent pas la roadmap normale. -5. **`s *` / `SELL_GREY` : SUSPENDU** — le chemin actuel existe, mais le chantier `SELL_GREY / sell-grey core API / bridge-first` est explicitement reporté à la fin de la roadmap. -6. **`s vendor` / `SELL_VENDOR` : TERMINÉ / VALIDÉ EN JEU / SYNCHRONISÉ 23/08/2026** — `INVENTORY_BULK_SELL_V1`, validation serveur et résultat structuré ; fallback legacy conservé uniquement sous `MultiBot.allowLegacyChatFallback == true` ; le Bridge accepte seulement `ITEM_USAGE_VENDOR` et exclut `ITEM_USAGE_AH` pour cette action. Tests runtime : Symbol of Kings conservé, Gold Ore conservé, `SELL_VENDOR` fonctionnel. Commits validés : Addon `fe2c807785219b82ca885f1a95d7c1dc27f0eed0`, Bridge `3ccf5047f7994218b742312fe1437f4b303f7159`. -7. **`open items` / `OPEN_ITEMS` : TERMINÉ / VALIDÉ / MERGÉ** — `INVENTORY_OPEN_V1`, Addon PR #60, Bridge PR #25. -8. **`roll` et `roll [item]` : TERMINÉ / VALIDÉ / MERGÉ** — `GROUP_ROLL_V1`, Addon PR #61, Bridge PR #26. -9. **Enchantement d'objet : TERMINÉ / VALIDÉ EN JEU / MERGÉ — Addon #63 / Bridge #27** — `ENCHANT_TRADE_V1`, UI dédiée aux enchanteurs, liste des enchantements réellement connus, composants/outils, Trade WoW natif via le slot « ne sera pas échangé », exécution par ID de sort numérique validé côté bridge, sans exécuteur générique de cast/chat ; layout 440 px et i18n des 8 locales validés. -10. **Spam inventaire automatique à l'ouverture Trade : TERMINÉ / VALIDÉ EN JEU — PR ADDON #64 EN COURS** — réutilisation puis généralisation du filtre addon existant : détection du header exact `=== Inventory ===` pour un bot connu, suppression du dump lors des chemins Inventory → Trade, Enchanting → Trade et du menu natif WoW « Échanger », sans modification de Playerbots ni du Bridge. -11. **TERMINÉ / VALIDÉ EN JEU / COMMITÉ / PUSHÉ — `LOOT_RULE_ITEM_V1`** : ajout/retrait exact d'un `itemId` dans l'`always loot list`, résultats structurés, idempotence, persistance bornée et UI localisée. -12. **PROCHAIN CHANTIER NORMAL — Décision sur `Quest`/`Skill` versus `Disenchant`**, uniquement à partir des capacités réellement présentes dans Playerbots ; ne pas réintroduire des modes issus de documentation historique non vérifiée. -13. **À FAIRE — Ordres collectifs `follow`, `attack`, `stay`**, seulement après validation manuelle exacte des sélecteurs Playerbots ; ne pas réintroduire `RUN~ORDER` générique. +```text +ALT_ROSTER_V1 +BOT_LIFECYCLE_V1 +BOT_TARGET_RESOLVE_V1 +``` -Les commandes informatives `who`, `co ?`, `nc ?` et `ss ?` restent manuelles tant qu'aucune UI structurée ne les remplace. Les mutations UI automatiques `co/nc`, en revanche, doivent passer par le bridge dès qu'un contrat structuré validé existe. +### Roster coverage -### Validation Enchanting Trade Service — 14/08/2026 +Validé pour : -- audit Trade/Cast et interfaces Playerbots réalisé en lecture seule ; -- capacité négociée `ENCHANT_TRADE_V1` ; -- `GET~ENCHANT_TRADE` liste uniquement les sorts d'Enchanting connus et valides du bot avec disponibilité des composants/outils ; -- `RUN~ENCHANT_TRADE` accepte uniquement un bot contrôlable, un token et un ID de sort numérique ; aucun GUID d'objet arbitraire, texte de commande ou exécuteur Playerbots générique n'est exposé ; -- cible réelle via le Trade WoW natif et `TRADE_SLOT_NONTRADED`, avec revalidation Core au cast puis à l'acceptation finale du Trade ; -- rate-limit bridge : 4 requêtes par fenêtre de 2 secondes ; -- UI dédiée visible uniquement pour les bots enchanteurs, accessible depuis l'EveryBar et Character Info ; -- fenêtre réduite à 440 px, champ de recherche corrigé et textes Enchant Trade localisés dans les 8 locales runtime ; -- test en jeu : ouverture, liste, recherche, tooltips, Trade et enchantement réel **OK** ; -- spam chat automatique lié au service Enchanting : **aucun après correctif Trade validé le 15/08/2026** ; -- l'ouverture du Trade par l'UI Enchanting réutilise le filtre de dump inventaire déjà employé par Inventory → Trade. - -### Validation suppression du dump Inventory à l'ouverture Trade — 15/08/2026 - -- cause auditée dans Playerbots en lecture seule : `TradeStatusAction::BeginTrade()` envoie automatiquement `=== Inventory ===` puis le contenu de l'inventaire au maître lors du démarrage d'un échange ; -- `mod-playerbots` reste strictement inchangé ; -- le filtre addon existant du bouton Inventory → Trade a d'abord été exporté puis réutilisé par les deux appels `InitiateTrade()` de l'UI Enchanting ; -- le filtre a ensuite été généralisé côté addon pour reconnaître automatiquement le header exact `=== Inventory ===` provenant d'un bot connu uniquement lorsqu'une fenêtre Trade est ouverte, ce qui couvre aussi le menu contextuel natif WoW « Échanger » sans masquer la sortie manuelle `item count` hors Trade ; -- le matching large sur le simple mot `Inventory` a été retiré afin d'éviter de masquer un whisper normal ; -- tests en jeu : Inventory → Trade silencieux, Enchanting → Trade silencieux, menu natif WoW « Échanger » silencieux ; -- enchantement réel et workflow Trade conservés ; -- aucune régression observée par l'utilisateur ; -- Bridge inchangé, Playerbots inchangé, aucun rebuild worldserver requis. - -### Chantiers suspendus — à reprendre seulement après la roadmap normale - -- `SELL_GREY` / sell-grey core API / bridge-first ; -- vérification réelle finale Firestone/Spellstone `TEMP_ENCHANTMENT_SLOT` ; -- quatre warnings LuaLint restants dans `Strategies/MultiBotWarlock.lua` ; -- autres petits reliquats explicitement reportés lors des étapes précédentes. - -Ces sujets restent enregistrés mais **ne doivent pas modifier l'ordre du prochain chantier**. - -Critère de sortie : chaque famille migrée fonctionne bridge-first et ne génère plus de réponse chat automatique. - -## Phase 6 — Backlog UI et fonctions secondaires - -À traiter après sécurité, protocole et bugs prioritaires : - -- argent de guilde dans la frame banque de guilde ; -- options de taille des icônes MainBar et Quick Bars ; -- options de déplacement restantes ; -- traductions AceLocale des tooltips Quick Hunter/Shaman ; -- chargement des skins de familiers chasseur ; -- harmonisation de la frame Reward ; -- amélioration Loot Master : tri d'éligibilité, filtres de rôle/classe, recommandation, avertissements, mode compact, historique et debug discret. - -Ces fonctions doivent rester séparées des patches de correction et de sécurité. - -## Phase 7 — Finalisation - -- Compilation complète sans erreur ni nouvel avertissement lié au bridge. -- Tests en jeu complets avec zéro/un/plusieurs bots et groupes importants. -- Audit final des dépendances chat, de la sécurité, des performances et des logs. -- Nettoyage des fallbacks legacy devenus inutiles seulement après preuve de non-régression. -- Mise à jour du README et de la roadmap. -- Création d'un checkpoint et d'une archive ZIP avec manifeste SHA-256 et rollback vérifié. - -Critère de sortie : version stabilisée, documentée et reproductible du projet Multibot Chatless + Bridge. - - - - -## État consolidé Jellypowered / inventaire — 20/08/2026 - -> **Référence de progression actuelle.** Ce bloc supplante les anciens libellés « prochain chantier Jellypowered » conservés plus haut à titre historique. Il ne modifie pas l'ordre de la roadmap normale après clôture du lot Jellypowered. - -### Intégré, vérifié et validé - -- **Support multi-préfixes addon configurable** : `MBOT` reste le préfixe MultiBot par défaut ; le Bridge utilise une whitelist configurée et répond sur le même préfixe que la requête reçue ; aucun préfixe arbitraire n'est accepté. -- **Inventaire exact / bag-aware** : `INVENTORY_EXACT_V1`, identité exacte `itemId + bag + slot`, vue globale sans sac sélectionné, Backpack + 4 sacs équipés + Keyring ; l'icône Keyring reste étroite et sans cadre carré spécifique. -- **Déplacement exact d'item** : `ITEM_MOVE_V1`, source/destination revalidées côté serveur, pas de mutation optimiste côté Addon, rafraîchissement autoritatif après résultat Bridge. -- **UX drag & drop de `ITEM_MOVE_V1`** : source atténuée pendant le drag, fantôme 32x32 suivant le curseur, `EnableMouse(false)`, détection `GetMouseFocus()` préservée, aucune API native de curseur détournée. Test en jeu validé le 16/08/2026 ; audit final `audit-multibot-item-move-drag-ghost-final-v1-2026-08-16-183942.zip`, SHA-256 `2f149a2cae53fd839fb077c4e2e1298e389038af4737f061eac5e594d05d1c3a`. -- **Équipement exact** : `ITEM_EQUIP_V1` validé. -- **Déséquipement exact** : `ITEM_UNEQUIP_V1` validé. -- **Utilisation native d'un item exact** : `ITEM_USE_V1` validé via endpoint spécialisé et chemin natif `HandleUseItemOpcode`, avec revalidation de la source et résultat serveur autoritatif. -- **Destruction d'un item exact** : `ITEM_DESTROY` validé via endpoint spécialisé. -- **Vente unitaire exacte** : `ITEM_SELL_SINGLE_V1` validé avec source exacte, vendeur proche revalidé, protections des objets non vendables/protégés, rate limit/replay et absence de mutation optimiste. -- **Rachat vendeur** : `VENDOR_BUYBACK_V1` validé avec liste structurée, vendeur proche revalidé, exécution via le handler natif de Buyback et rafraîchissements autoritatifs de l'inventaire et de la liste de rachat. -- **Échange générique exact** : `ITEM_TRADE_V1` validé en jeu dans les deux sens, avec source exacte, Trade WoW natif préservé, résultat structuré et fallback historique explicitement conditionné. -- **Abandon de quête** : `QUEST_ABANDON_V1` compilé et validé avec un bot, via le paquet Quest AzerothCore typé et le handler natif ; zéro spam chat et zéro erreur Lua. Le test multi-bots mixte reste différé faute de bots disponibles. -- **Partage de quête** : déjà natif/chatless via `QuestLogPushQuest()` ; aucun endpoint Bridge additionnel n'est nécessaire. -- **Application de talents personnalisés** : `TALENT_APPLY_V1` compilé et validé en jeu ; validation classe/DBC/points côté Bridge, réutilisation du chemin Playerbots audité, vérification serveur des trois arbres via `BuildTalentTabPoints`, reset des stratégies uniquement après succès et confirmation visuelle localisée côté Addon après `OK`. -- **Sélecteur de spécialisations prémontées** : `TALENT_SPEC_APPLY_V1` compilé et validé en jeu en clic gauche/slot 1 et clic droit/slot 2. `TALENT_SPEC_CURRENT` fournit l'état courant sans whisper normal ; le Bridge revalide l'index du modèle, gère le dual spec, interrompt le cast, applique talents + glyphes, vérifie les totaux finaux et renvoie un résultat structuré. Les anciens `talents`, `talents spec list`, `stopcasting`, `talents switch` et `talents spec` ne restent que dans le fallback explicitement activé. - -Toutes ces intégrations conservent `mod-playerbots` en **lecture seule stricte** et n'introduisent aucun exécuteur générique de commande Playerbots. - -### Merges validés et nouvelle baseline v2 — 20/08/2026 - -- Addon : le lot Jellypowered est déjà intégré à `main` via la PR #67, merge commit `70e72ba6cb9a7170497b201e0dbe469bb29e6be9`. -- Bridge : le lot Jellypowered est déjà intégré à `main` via la PR #28, merge commit `5e5ff7594ec8afedf40926605a60848dbc14991e`. -- Le chantier SelfBot, traité séparément, est lui aussi déjà intégré à `main` via Addon PR #72 et Bridge PR #30 ; les capacités héritées sont `SELF_BOT_V1`, `SELF_STRATEGY_V1` et `SELF_ACTION_V1`. -- Les nouvelles branches `jellypowered-chatless-integration-v2` ont été créées directement depuis ces `main` le 20/08/2026 et étaient à `0/0` ahead/behind au baseline audité. -- Les résiduels SelfBot Bridge déjà identifiés (`dps aoe` -> stratégie native `aoe`, robustesse du rollback différé Warlock) restent un chantier séparé et ne doivent pas être corrigés pendant Jellypowered. +- My Bots / Altbots ; +- Group ; +- Guild ; +- Friends ; +- Favorites. -### Stabilisation validée avant merge — historique du 17/08/2026 - -- CAPS : fragmentation/budget wire bornés et corrigés. -- `ITEM_MOVE_V1` : postcondition de déplacement de pile entière corrigée. -- `ITEM_USE_V1` : postcondition des objets démarrant une quête corrigée ; le cas négatif « quête déjà acceptée » reste différé faute de cas runtime dédié. -- `INVENTORY_EXACT_V1` : autorisation explicite côté Bridge corrigée. -- `ITEM_EQUIP_V1` : fallback chat legacy remis sous le flag explicite de compatibilité. -- Inventaire : recyclage de la frame et sécurité item/link en cold-cache corrigés ; les cas runtime cold-cache réel et Unequip exact sans cas reproductible restent différés. -- `ITEM_USE_V1` : namespace locale et raisons d'échec localisées ; tooltip Inspect localisé dans les 8 locales auditées. -- `VENDOR_BUYBACK_V1` : garde nil de création de frame ajoutée sans changement de protocole. -- LuaLint : variable inutilisée `BUYBACK_ROWS` supprimée. -- Ces contrôles constituaient la porte de sortie du lot avant son merge ; les futurs patches Jellypowered v2 devront à nouveau passer les contrôles applicables avant tout nouveau merge. +### Invariant UI canonique -### Audité et différé / non intégré +```text +bot offline -> EveryBar repliée +bot online -> EveryBar dépliée +``` -- `GET~INVENTORY_BULK` : audité ; la forme Extended reste rejetée/différée tant qu'elle duplique sans bénéfice démontré `INVENTORY_EXACT_V1`. -- `GET~BOT_SKILLS_BULK` : audité ; différé jusqu'à l'apparition d'un consommateur multi-bot réel. +Les flags propres à un roster ne doivent pas faire fuiter l'état de repli vers un autre roster. -### Clôture banque / banque de guilde — P3A validé le 24/08/2026 +### Stabilisations Addon validées -- **P3A — TERMINÉ / VALIDÉ EN JEU / COMMITÉ / PUSHÉ — `ITEM_DEPOSIT_EXACT_V1`** : `BANK_DEPOSIT` et `GBANK_DEPOSIT` utilisent désormais l'identité physique exacte `bag/slot/itemId/count` issue de l'inventaire exact et déplacent uniquement la pile entière sélectionnée. -- Le Bridge revalide la position source, l'`itemId` et le `count` avant mutation. Le test négatif runtime avec un faux `count` a renvoyé `SOURCE_STALE` et la pile réelle est restée inchangée. -- Les tests runtime avec deux piles distinctes du même objet ont validé que BANK et GBANK déplacent uniquement la pile cliquée, sans déplacer l'autre pile identique, sans erreur Lua, spam chat ou crash observé. -- Protections du service exact-deposit : **8 requêtes / 2 s / requester**, TTL anti-rejeu **10 s**, **32** tokens récents maximum et **512** états requester maximum. -- Commits P3A validés : Addon `b13ff797ab96144f2ae51cc4adf6a0d4a1c4e464`, Bridge `15abaae7adc6b983f25e9c4b5dec13ca314d5727`. -- **P3B — DIFFÉRÉ : retrait exact BANK**. Le snapshot de retrait actuel est agrégé par `itemId`; exposer une pile source physique exacte nécessite une évolution protocole/UI plus large. -- **P3C — DIFFÉRÉ : retrait exact GBANK**. Le Bridge manipule déjà des coordonnées physiques lors de l'exécution, mais la sélection source exacte n'est pas exposée de bout en bout jusqu'à l'Addon ; la refonte est reportée. -- **Résiduel UI basse priorité, non bloquant :** `SOURCE_STALE` utilise encore le libellé générique d'erreur d'action d'objet. -- **Résiduel basse priorité, non bloquant :** `BAG_MOVE` concerne uniquement le déplacement/rééquipement des **sacs équipés eux-mêmes**. Les déplacements d'items entre Backpack / sacs 1..4 / Keyring sont déjà terminés via `ITEM_MOVE_V1`. +Le chantier a couvert notamment : -Le lot banque/GBANK prioritaire est clos pour la roadmap courante. `LOOT_RULE_ITEM_V1` est lui aussi clos et validé. La décision Quest/Skill versus Disenchant est désormais résolue à partir du code Playerbots audité : `disenchant` est retenu ; `Quest` et `Skill` ne sont pas exposés comme profils de loot validés. La roadmap normale passe à l'audit des ordres collectifs `follow`, `attack`, `stay`. +- présence online/offline cohérente ; +- reconnexion/déconnexion via clic roster ; +- cache social réappliqué lors des changements de roster ; +- nettoyage lifecycle lors des transitions monde/session ; +- gestion des pending/timeout ; +- pagination Guild/Friends avec ordre canonique online-first ; +- non-régression des autres rosters. -### Clôture règles de loot exactes — `LOOT_RULE_ITEM_V1` validé le 24/08/2026 +### Hardening Bridge validé -- **TERMINÉ / VALIDÉ EN JEU / AUDITÉ / ARCHIVÉ / COMMITÉ / PUSHÉ** : ajout ou retrait d'un `itemId` exact dans la valeur Playerbots auditée `always loot list`, sans modification de `mod-playerbots`. -- Contrat : `RUN~LOOT_RULE_ITEM~~~~~` et résultat structuré `LOOT_RULE_ITEM_RESULT`; scopes protocole `ALL`, `RAID`, `GROUP`, `PARTY`, `BOT`, l'UI actuelle envoyant volontairement `ALL`. -- Prévalidation avant mutation : requester/session/world, scope/target, bots visibles et contrôlables, sécurité Playerbots, session/world/alive/context du bot, `ItemTemplate` valide ; maximum **128 bots**. -- Protections : **8 requêtes / 2 s / requester**, anti-rejeu **10 s**, **32** tokens récents et **512** états requester. -- Persistance : seuls les bots réellement modifiés sont sauvegardés ; budget serveur global **128 sauvegardes de bots / 10 s**. Un budget insuffisant renvoie `PERSISTENCE_BUSY` avant toute mutation. -- Sémantique idempotente validée : `ADDED`, `REMOVED`, `ALREADY_PRESENT`, `ALREADY_ABSENT`, avec `PARTIAL` prévu pour les résultats mixtes et erreurs structurées côté Bridge. -- Runtime validé : ADD/REMOVE et répétitions, itemId numérique, Shift+clic lien d'objet, entrée locale invalide sans envoi Bridge, item serveur invalide, persistance déconnexion/reconnexion, persistance après restart worldserver, nettoyage final de l'item de test 6948. -- UI/i18n validée : prompt cliquable/éditable corrigé localement sans modifier AceGUI global, `/reload` sans erreur Lua, boutons/résultats localisés dans les huit locales présentes (`deDE`, `enGB`, `enUS`, `esES`, `frFR`, `koKR`, `ruRU`, `zhCN`), aucun spam chat/whisper observé. -- **Décision Quest/Skill versus Disenchant — TERMINÉE / VALIDÉE** : l'audit du build Playerbots courant confirme une vraie `DisenchantLootStrategy` nommée `disenchant` avec alias `d`, `e`, `disenchant`, `enchant`. L'Addon expose donc `Disenchant` à la place des anciens profils UI `Quest`/`Skill`, et le Bridge n'autorise plus ces anciens libellés dans sa whitelist loot. `mod-playerbots` reste strictement en lecture seule. +Le Bridge lifecycle a été durci sur : -### Stabilisation de clôture PR Addon #73 — 27/08/2026 - -- **Lifecycle structuré Addon durci** — commit `ae5cd9695dfc93b81872d2a95e1ce840b3d1ebfc` : les requêtes `LOOT_RULE_ITEM` et `STRATEGY_MUTATION` ne sont plus effacées avant `MarkDisconnected()` lors de `PLAYER_ENTERING_WORLD`; le craft normal `PROFESSION_RECIPE_CRAFT` possède désormais une limite de **8** requêtes actives, un timeout de **5 s**, une validation stricte de la réponse et une terminaison `DISCONNECTED` déterministe. -- **Feedback `QUEST_ABANDON` structuré** — commit `bd79fab8636d728401e64690899121a09bdc398d` : les erreurs Bridge, timeout, déconnexion et échec d'envoi sont remontés à l'utilisateur au lieu d'être silencieux. -- **Resynchronisation inventaire après erreurs exactes** — commit `d3e0d6cd7f7da9775ff37619932fe525969a2732` : `BANK_DEPOSIT`, `GBANK_DEPOSIT` et `ITEM_TRADE` redemandent un snapshot autoritatif sur `SOURCE_STALE`, `BAD_RESPONSE`, `RESPONSE_MISMATCH` ou `TIMEOUT`; les succès et `DISCONNECTED` restent inchangés. -- **Bridge indisponible pour `QUEST_ABANDON`** — commit `c84441ecabb7b124d4547d17118bc73bf05c69a1` : lorsque `QUEST_ABANDON_V1` n'est pas disponible et que le fallback chat est désactivé, l'Addon signale explicitement `BRIDGE_UNAVAILABLE` au lieu de laisser croire que les bots ont abandonné la quête. -- Ces correctifs de clôture ne modifient ni `mod-playerbots`, ni le Bridge, ni la politique de fallback legacy. Ils ne nécessitent aucun rebuild C++. +- autorisation de contrôle ; +- anti-rejeu ; +- rate limiting ; +- cible offline/online ; +- conservation des connexions asynchrones in-flight. -### Chantiers suspendus — à reprendre seulement après la roadmap normale +La simple appartenance au même groupe ne suffit pas à autoriser le contrôle lifecycle d'un personnage offline. -À ne pas reprendre pendant la roadmap normale sauf demande explicite : +Les relations retenues par le chemin audité sont : -- **P3B** — retrait exact BANK, avec snapshot/protocole/UI de sélection physique à concevoir ; -- **P3C** — retrait exact GBANK, avec sélection physique de source à exposer de bout en bout ; -- libellé UI dédié pour `SOURCE_STALE`, actuellement générique et non bloquant ; -- `SELL_GREY` / sell-grey core API / bridge-first ; -- diagnostic réel final Firestone / Spellstone `TEMP_ENCHANTMENT_SLOT` ; -- quatre warnings LuaLint restants dans `Strategies/MultiBotWarlock.lua` ; -- autres petits reliquats déjà explicitement reportés. +```text +sameAccount +sameGuild +addClassBot +linked/trusted account +``` -### Reliquats techniques confirmés pendant la revue PR #73 — différés - -Ces points sont **préexistants ou hors objectif fonctionnel de la PR #73**. Ils sont enregistrés pour audit/hardening ultérieur et ne modifient pas l'ordre de reprise normal de la roadmap : +### In-flight connect retention -- **Lifecycle Trainer** : `RunTrainerLearn` crée un pending `trainerCommands` sans timeout dédié; `MarkDisconnected()` efface actuellement cette table sans livrer de résultat `DISCONNECTED` à `TrainerUI`. Une déconnexion pendant `Learning...` peut donc laisser `TrainerUI.pending` actif jusqu'à une action manuelle. À auditer puis durcir avec timeout borné et terminaison déterministe. -- **Lifecycle Outfit** : le chemin Bridge verrouille `OutfitUI.commandBusy`, mais le disconnect efface `outfitCommands` sans passer par `HandleBridgeCommandResult`. Une perte de connexion pendant une commande peut laisser le verrou UI actif. À auditer puis durcir avec timeout/résultat de déconnexion. -- **Lifecycle Formation** : `formationCommands` possède callback et timeout, mais la table est effacée au disconnect et également pendant `PLAYER_ENTERING_WORLD`; un callback pending peut donc être perdu avant son timeout. À auditer avec le même modèle de drain déterministe utilisé pour les commandes structurées récentes. -- **Idempotence / anti-rejeu du craft normal `PROFESSION_RECIPE_CRAFT`** : l'Addon dispose désormais d'un timeout de 5 s, mais le chemin Bridge normal doit encore être audité pour vérifier/ajouter si nécessaire rate-limit, token replay et sémantique d'idempotence comparables à `CRAFT_RECIPE_TARGET_V1`. Une réponse perdue ne doit pas permettre qu'un retry manuel déclenche ambiguëment un second craft. - -### Reprise de la roadmap normale - -Le **prochain chantier fonctionnel** est : **audit ciblé des ordres collectifs `follow`, `attack`, `stay` et de leurs sélecteurs Playerbots exacts**. Aucun endpoint générique `RUN~ORDER` ne doit être conçu ; les API/actions/sélecteurs réellement présents doivent être vérifiés en lecture seule avant toute proposition. - -Le lot fonctionnel `jellypowered-chatless-integration-v2` reste une baseline historique terminée. Le développement courant est `feature/loot-disenchant-mainbar` dans l'Addon et le Bridge ; il clôt la décision Quest/Skill versus Disenchant et la synchronisation MainBar associée. La roadmap normale reprend maintenant avec l'audit de `follow`, `attack`, `stay`. P3B/P3C, le libellé `SOURCE_STALE`, `BAG_MOVE`, `SELL_GREY`, Firestone/Spellstone TEMP_ENCHANT, LuaLint et les reliquats techniques explicitement différés ci-dessus restent hors du prochain chantier. +Le timeout court sert au **reporting**, mais ne doit pas faire oublier une connexion Playerbots asynchrone encore en cours. + +Le pending reste donc réservé jusqu'à : + +- observation de la fin de connexion ; ou +- expiration de la fenêtre de rétention longue. + +Cela évite : + +- duplicate connect ; +- perte de l'état CONNECTING ; +- libération prématurée du budget `maxBots`. + +### Validation finale + +- compilation `worldserver` réussie ; +- serveur redémarré ; +- matrice runtime validée ; +- aucune nouvelle régression de roster/EveryBar signalée ; +- aucun nouveau spam chat signalé ; +- reviews Addon #75 et Bridge #34 fermées ; +- merges effectués ; +- audit post-merge propre ; +- arbres `main` identiques aux feature heads validés ; +- Playerbots resté strictement inchangé. + +--- + +## 5. Prochain chantier normal + +### Audit ciblé `follow` / `attack` / `stay` + +Le prochain chantier fonctionnel recommandé est : + +```text +audit ciblé des ordres collectifs follow / attack / stay +``` + +Avant toute conception : + +- vérifier les sélecteurs/actions/API Playerbots réels ; +- vérifier les scopes réellement supportés ; +- vérifier le comportement groupe/raid ; +- identifier les dépendances chat actuelles ; +- vérifier permissions et états runtime ; +- ne pas concevoir d'endpoint générique `RUN~ORDER` à l'aveugle. + +Aucun nouveau code avant audit + analyse + validation utilisateur. + +--- + +## 6. Backlog différé + +Ces éléments ne doivent pas interrompre le prochain chantier normal sauf demande explicite. + +### P3B — exact BANK withdrawal + +Le snapshot actuel ne fournit pas encore un modèle physique de source exploitable de bout en bout pour un retrait exact. + +### P3C — exact GBANK withdrawal + +Même problème : la sélection physique exacte de la source doit être conçue de bout en bout. + +### `SOURCE_STALE` UI + +Ajouter un libellé localisé dédié. +Le texte générique actuel est fonctionnel et non bloquant. + +### `BAG_MOVE` + +Important : + +`ITEM_MOVE_V1` couvre déjà le déplacement des **items ordinaires** entre Backpack / Bag 1..4 / Keyring. + +Le backlog `BAG_MOVE` signifie uniquement : + +```text +déplacer / rééquiper les objets sacs eux-mêmes +dans les slots de sacs équipés +``` + +### `SELL_GREY` + +Audit/implémentation bridge-first dédié à reprendre plus tard. + +### Firestone / Spellstone + +Faire la revalidation réelle finale du comportement : + +```text +TEMP_ENCHANTMENT_SLOT +``` + +Le diagnostic et le code de support existants ne suffisent pas à déclarer ce point définitivement fermé. + +### LuaLint Warlock + +Quatre warnings historiques restent à nettoyer après les chantiers fonctionnels prioritaires. + +--- + +## 7. Reliquats techniques à auditer + +Ces points sont enregistrés mais ne sont pas le prochain chantier fonctionnel. + +### Lifecycle Trainer + +`trainerCommands` doit être audité pour : + +- timeout borné ; +- résultat `DISCONNECTED` déterministe ; +- aucun pending UI bloqué après perte de connexion. + +### Lifecycle Outfit + +Le verrou UI / pending doit être audité afin qu'une déconnexion ne laisse pas `commandBusy` bloqué. + +### Lifecycle Formation + +Les callbacks/pending doivent être drainés de façon déterministe lors des transitions/disconnects. + +### Craft normal — idempotence / anti-rejeu + +Le chemin `PROFESSION_RECIPE_CRAFT` doit être comparé aux protections de `CRAFT_RECIPE_TARGET_V1` : + +- rate limit ; +- replay token ; +- retry ambigu ; +- résultat perdu ; +- risque de double craft. + +--- + +## 8. Reliquats chat / finalisation globale + +Le projet ne doit pas être décrit comme **fully chatless** tant que les occurrences restantes de `SendChatMessage` n'ont pas été classées. + +Chaque occurrence doit finir dans une catégorie claire : + +```text +manual command volontaire +diagnostic +compatibility fallback +information message +UI mechanism à migrer +dead code +``` + +Après preuve de non-régression : + +- supprimer les parsers legacy devenus morts ; +- conserver les commandes manuelles utiles ; +- conserver un fallback seulement lorsqu'il est explicitement justifié ; +- continuer les tests de spam chat après chaque migration. + +--- + +## 9. Contribution Jellypowered — historique conservé + +Les contributions Jellypowered ont servi de référence pendant la migration chatless. + +### Contribution initiale + +Auteur : + +```text +Jellypowered +``` + +Commits historiques étudiés : + +```text +13059a9f334d1e5aaa8560ab29a1814e48b07054 +7ff1347535be6d5a3256d933731c11c4b3f3b38e +04061f084bd189487f1ac0e99892316146f1bea0 +``` + +### Fork Extended étudié + +Référence historique : + +```text +Jellypowered/mod-multibot-bridge +branch: Extended +``` + +Commits notamment étudiés : + +```text +89da6a9dd15be77c3cbfe9be88a9885b632d606a +40bc0e378b1723d746d3425d4ee0818fd01531c6 +7f9027faf6126bd2854d9f5e84f9a7fa82549077 +``` + +Politique conservée : + +- ne jamais merger aveuglément le fork ; +- auditer fonction par fonction ; +- reprendre / adapter / rejeter selon l'état réel ; +- conserver les crédits uniquement pour les parties réellement reprises. + +Lorsque la reprise substantielle le justifie : + +```text +Co-authored-by: Jellypowered +``` + +Pour une simple inspiration de design : + +```text +Design inspired by the Jellypowered bridge contribution. +``` + +Les anciennes branches Jellypowered sont désormais des références historiques, pas les branches de développement actives. + +--- + +## 10. Historique récent de clôture + +Repères principaux conservés : + +- PR Jellypowered Addon #67 mergée dans `main` ; +- PR Jellypowered Bridge #28 mergée dans `main` ; +- PR SelfBot Addon #72 mergée ; +- PR SelfBot Bridge #30 mergée ; +- stabilisation Addon PR #73 ; +- P3A `ITEM_DEPOSIT_EXACT_V1` clôturé ; +- `LOOT_RULE_ITEM_V1` clôturé ; +- décision Disenchant clôturée ; +- Alt roster / lifecycle Addon PR #75 mergée ; +- Alt roster / lifecycle Bridge PR #34 mergée ; +- audit post-merge lifecycle final : propre. + +Les détails de branches anciennes ne doivent plus être présentés comme état courant dans les README. + +--- + +## 11. Références d'audit et checkpoints + +Cette section conserve uniquement les preuves structurantes utiles à la reprise. Les détails exhaustifs restent dans les archives de travail. + +| Référence | SHA-256 | Portée | +| --- | --- | --- | +| `audit-multibot-alt-roster-lifecycle-post-merge-v1-2026-08-30-143746.zip` | `4FCF642996BDC8B279155EF9018637AA44E4D83F1B0109CC4065A62441B91B8A` | Clôture post-merge Addon #75 / Bridge #34, `main` synchronisés et Playerbots intact. | +| `checkpoint-multibot-friends-favorites-lifecycle-v1-2026-08-29-232823.zip` | `CB90287ED1FCD7D808D83FD22607D1420061642F1478FDCA3278CF1C13271512` | Checkpoint roster Friends/Favorites avant clôture lifecycle. | +| `audit-multibot-item-move-drag-ghost-final-v1-2026-08-16-183942.zip` | `2F149A2CAE53FD839FB077C4E2E1298E389038AF4737F061EAC5E594D05D1C3A` | Validation finale UX drag/drop `ITEM_MOVE_V1`. | +| `audit-multibot-state-strategy-final-v1-2026-08-07-224000-2026-08-07-224709.zip` | `B00DBE597F554F9E20F2ABEFDC22097BC2A06DCDD3F07FD9F6522F98A7DF38DA` | Audit statique final STATE framing / strategy mutations. | +| `audit-multibot-runtime-tests-v1c-2026-08-03-203219.zip` | `44627A920618C747BD9EEB0384D118FFFA13157828677172E46A642436677CB5` | Validation runtime de consultation des formations. | + +--- + +## 12. Maintenance documentaire + +Après chaque gros merge : + +1. mettre à jour les HEAD `main` ; +2. déplacer les fonctions terminées hors du backlog actif ; +3. ajouter les nouveaux différés réellement confirmés ; +4. conserver les audits/hashes utiles dans la roadmap ; +5. garder les README centrés sur les fonctionnalités et nouveautés visibles ; +6. vérifier que `TODO.md` local n'a pas été écrasé ; +7. vérifier à nouveau l'intégrité Playerbots read-only.