Found during: Phase 10 real-machine UAT, plan 10-17. Affects 9 of 12 checklist rows
(all /ultiext command-dependent rows); 3 more rows (data.delvisitor,
data.visit.neg-repeat, data.visitors.neg-empty) are blocked because their preconditions
depend on a prior command in this same broken chain.
Severity: high — this repository exists specifically to demonstrate the External Plugin API
working end-to-end for a non-UltiToolsPlugin Bukkit plugin. With this defect, the command half of
that demonstration does not work at all.
Symptom: Every /ultiext <sub-command> (hello, info, visit, visitors,
delvisitor) returns Bukkit's own "Unknown or incomplete command" — as if the command were never
registered — even though the plugin loads successfully, enabled is true, and the framework's own
SQLiteDataOperator-backed UltiToolsAPI.getDataOperator path works correctly (confirmed
independently: a real player join still triggers JoinListener's own Bukkit event handler, which
IS a plain Bukkit listener rather than a framework-scanned command, and correctly writes/increments
a visitor record via the External Plugin API — including surviving a full clean server restart,
confirmed by a read-only SQLite check of the persisted row).
Root cause (high confidence): GreetCommand still extends
com.ultikits.ultitools.abstracts.AbstractCommandExecutor, which was deleted outright from
UltiTools-API in the 6.3.0 milestone (Phase 7 plan 07-15, commit 5ca52468 on
UltiTools-Reborn) — not merely deprecated. The framework's command-registration scan silently
skips any class it cannot recognize as a valid command executor base, which is exactly what happens
here: the class fails to bind against the current framework's command-scanning contract, and no
error propagates because the scan treats it as "not a command class" rather than "broken command
class." This repository was never updated to migrate onto BaseCommandExecutor
(com.ultikits.ultitools.abstracts.command.BaseCommandExecutor), the framework's current base class
for exactly this generation — see the framework's own COMPATIBILITY.md "Migrating off
AbstractCommandExecutor" section for the guide.
Not fixed here — UAT-execution phases only record and file product defects. Full row evidence
(server logs, SQLite read-back confirmation, session receipt) is in this phase's local evidence
tree under UltiTools-External-Example/uat-verdicts.json and
UltiTools-External-Example/10-LEDGER-UltiTools-External-Example.md — not committed to any
repository, available on request.
Found during: Phase 10 real-machine UAT, plan 10-17. Affects 9 of 12 checklist rows
(all
/ultiextcommand-dependent rows); 3 more rows (data.delvisitor,data.visit.neg-repeat,data.visitors.neg-empty) areblockedbecause their preconditionsdepend on a prior command in this same broken chain.
Severity: high — this repository exists specifically to demonstrate the External Plugin API
working end-to-end for a non-
UltiToolsPluginBukkit plugin. With this defect, the command half ofthat demonstration does not work at all.
Symptom: Every
/ultiext <sub-command>(hello,info,visit,visitors,delvisitor) returns Bukkit's own "Unknown or incomplete command" — as if the command were neverregistered — even though the plugin loads successfully,
enabledis true, and the framework's ownSQLiteDataOperator-backedUltiToolsAPI.getDataOperatorpath works correctly (confirmedindependently: a real player join still triggers
JoinListener's own Bukkit event handler, whichIS a plain Bukkit listener rather than a framework-scanned command, and correctly writes/increments
a visitor record via the External Plugin API — including surviving a full clean server restart,
confirmed by a read-only SQLite check of the persisted row).
Root cause (high confidence):
GreetCommandstill extendscom.ultikits.ultitools.abstracts.AbstractCommandExecutor, which was deleted outright fromUltiTools-API in the 6.3.0 milestone (Phase 7 plan 07-15, commit
5ca52468onUltiTools-Reborn) — not merely deprecated. The framework's command-registration scan silentlyskips any class it cannot recognize as a valid command executor base, which is exactly what happens
here: the class fails to bind against the current framework's command-scanning contract, and no
error propagates because the scan treats it as "not a command class" rather than "broken command
class." This repository was never updated to migrate onto
BaseCommandExecutor(
com.ultikits.ultitools.abstracts.command.BaseCommandExecutor), the framework's current base classfor exactly this generation — see the framework's own
COMPATIBILITY.md"Migrating offAbstractCommandExecutor" section for the guide.Not fixed here — UAT-execution phases only record and file product defects. Full row evidence
(server logs, SQLite read-back confirmation, session receipt) is in this phase's local evidence
tree under
UltiTools-External-Example/uat-verdicts.jsonandUltiTools-External-Example/10-LEDGER-UltiTools-External-Example.md— not committed to anyrepository, available on request.