4.1 KiB
Verified implementation blockers
Checked 2026-07-29 against the pinned read-only UE4SS reference at
bae91527355f14faa63c1df65f742cc48594ba1b (UE4SS 3.0.1). The accompanying
capability evidence is recorded in
plugins/examples/scum-server-plugin/companion/UE4SS_CAPABILITY.md.
The reference offers a fixed, online-recipient SendChat path, which is
already bounded by the supported player.notify adapter. It also removes one
leading # before dispatching a command, but its raw response is not a stable
operation acknowledgement. Under the separately authorized fixed-template
exception, the plugin's vehicle.spawn adapter can generate only
#spawnvehicle <vehicleCode> from its allowlist through a local authorized
transport port and maps its bounded receipt to success, failure, or unknown.
It is not a general RCON surface. The reference otherwise has no versioned
server-side schema, identity binding, acknowledgement contract, or isolated
non-production fixture for login/logout events, network correlation, position
or vehicle events, reward delivery, or state reads and writes.
Controlled read-only migration fixtures now verify configuration, player
history, gifts, state-patch audits, and trajectories in
plugins/tests/fixtures/scum-migration-parity.ts. They preserve only
allowlisted plugin fields and maintain transition provenance. The existing
isolated Companion tests continue to cover its safe command boundary. Neither
test set provides an end-to-end SCUM executor or event producer.
Consequently these tasks remain open and blocked rather than simulated:
- 4.1–4.4: no legitimate versioned event producer exists for semantic player, network, position, or vehicle data.
- 5.1 and 5.3: no documented, version-bound state-patch or reward-delivery adapter exists.
- 6.2: controlled read-only migration fixtures and isolated Companion typed-port coverage now exist for the supported configuration, notification, and vehicle-spawn adapters, but no legitimate versioned producer exists for the remaining player-history, reward, state-patch, or trajectory parity.
- 6.3: transitional SCUM APIs and models still have callers and cannot be removed before the parity and rollback evidence required by 6.2.
- 6.4: final full verification is deferred until the blocked adapters and isolated integration environment exist.
No fallback to raw RCON, credentials, SQL, direct game-database access, OCR, screenshots, keyboard/mouse injection, or desktop automation is permitted.
6.3 frontend cleanup and rollback evidence (2026-07-29)
The generic PluginPageHostPage has no hard-coded SCUM import or game.scum
branch. Static rg call-graph audit found zero non-test callers for the
following former platform_web implementation, so this batch removed it with
its private tests, contracts, schemas, API-client methods/types, and map-only
styles:
ScumOperationsPanel,ScumFileConfigWorkbench, and the privatescumOperationscontract/schema;GamePlayerIntelligencePanelandGameGiftCatalogPanel;ScumMapTrajectoryPanel.
Their plugin-owned replacement is features/page.ts, with typed bridge reads
and commands in features/api.ts, and the read-only provenance adapters in
features/migration.ts. The replacement remains capability-gated: missing
login/position event producers and missing state-patch/reward-delivery
handlers render unavailable controls and never synthesize records or enable a
fallback execution path.
The platform-side /game-players, /game-gifts, and /game-map-trajectories
routes, DTO/domain/model/service/repository implementations, and their
fixtures remain intentionally. plugins/tests/fixtures/scum-migration-parity.ts
continues to consume their historical record shapes through allowlisted,
transitional-read-only migration records. Rollback therefore consists of
disabling the exact server/version plugin authority flag, leaving those prior
records visible and read-only; it does not restore any deleted host panel or
re-enable an unsafe execution route. Backend removal remains blocked until 6.2
parity and the required versioned event/operation protocols exist.