This is working as intended. It's not mentioned in this new thread (was in previous), but I'll make it more clear in the general information stickies so people don't get confused.
The Explorer's job is to explore the entire area, quite literally, cover the entire map so things pop into sync radius. That's it's
only job now. What happens along the way is up to other task logic, plugin logic, and the CR currently being used.
In the old bot, explore logic was coupled with combat targets, loot targets, chest targets, as well as other things such as area transitions and waypoints. The concept of exploring back then was to divide the map into grid cells, like now, but it would unmark explore nodes if there was anything of interest there. That would force the bot to go back and re-explore that node.
That system cannot fundamentally work correctly in Path of Exile, which is why the bot always had explore issues, looping issues, and all sorts of problems doing things (not to mention, it was all hard coded into the bot itself and couldn't be changed by users). When you divide the world into grid cells, you end up with certain cells that overlap an area that is connected from two different sides. This is a problem because you need to know which side to move to, by keeping track of a "navigable center". However, the problem comes when there are more than one object of interest in the cell, which creates two navigable centers, but only one can be the main one used. When you simply move to that center, it might be for the wrong object, so when the logic executes to handle that action, it needs to go to the other side, which it did. What results is the mess that has followed the bot pretty much until I rewrote the current Beta last month and used a totally different approach.
For the new bot, all the old problems have been solved by taking a new approach. The only problems left, are ones that stem directly from the design of the game itself, which are unchangeable. By keeping exploration separate and only handling exploration, users now have one way to explore an area and load up things of interest. The only exception with exploration is traveling though boss areas, which users have to implement special logic for, since it cannot work on its own. Even so then, you have one easy to reuse part that opens the door for users to do anything in an area by exploring.
In short, exploration is working correctly and doing it's job if it's covering the entire area, which it is.
Now, for what you're talking about, the issue comes down to the current design of
ExampleRoutine. This is the guide that needs some additional details about actual combat as that is the issue you're seeing.
ExampleRoutine does not implement specific boss fighting logic. To be technically specific, ExampleRoutine does not contain logic to track down and kill an enemy if it's outside of CombatRange, which is pretty much what happens in a lot of areas for boss fights.
That's basically the issue you are seeing, and many others when they report the CR doesn't kill the bosses, which I've mentioned in most of the previous release threads, is intended. All ExampleRoutine does is handle combat around the player in a specific range. For bosses, users have two choices, either: 1) make a new CR that implements that type of logic into the design to avoid issues or 2) use a plugin, as DominusFight shows, to move the bot into boss range so the current CR can fight it.
Trying to make ExampleRoutine or any CR for that mater, track down and kill a target presents a very challenging design issue for those who try it. The problem you end up running into, will be the same problem we saw when we tried to do too much with the previous Explorer system; conflict of execution. As a result, by simplifying the process, as the current design does, you can implement more complex logic in a way that doesn't break down.
The actual solution to the problem isn't too hard; you'd make a plugin just like DominusFight (which is why it was provided), except you keep track of any unique mob, and move towards it so it eventually comes into combat range of the CR. That should pretty much solve the problem, because the only reason the CR doesn't attack the boss, is because the boss isn't in combat range or is in a state (buried) that the CR doesn't process because it only cares about active mobs around it, by design.
So, everything is working as intended. I have two more planned plugin examples (something for this, and a map example) coming soon, but general boss logic is up to users with the current design. The current bot setup gets the player to the boss for their logic to execute, so it's doing it's job. The bot no longer handles any combat logic. i know non-devs don't understand a lot of this stuff, but after a years worth of rewrites and trying to fix the same problems over and over, this is what has to happen for things to work correctly.
My focus right now is getting a final Release done, so we can get users their compensation for the downtime and have a stable release. Everything you need to improve upon this issue is already there though.
.