admin343/browser
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(scum): add read-only migration flags

Browse Source
This commit is contained in:
npc0-hue
2026-07-29 11:57:41 +08:00
parent 47738acfd6
commit 6c503e567c
5 changed files with 105 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/changes/move-scum-feature-ownership-to-plugin/implementation-blockers.md
+28
View File
@@ -0,0 +1,28 @@
# 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 only a fixed, online-recipient `SendChat` path, which is
already bounded by the supported `player.notify` adapter. It 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.
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.
- 5.5 and 6.2: the required adapter coverage and isolated non-production
fixtures do not exist.
- 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.
openspec/changes/move-scum-feature-ownership-to-plugin/tasks.md
+1 -1
View File
@@ -36,7 +36,7 @@
## 6. Migrate transitional platform behavior safely
- [ ] 6.1 Introduce feature/version flags and read-only migration adapters so existing platform records remain visible with provenance while plugin-owned records become authoritative per server.
- [x] 6.1 Introduce feature/version flags and read-only migration adapters so existing platform records remain visible with provenance while plugin-owned records become authoritative per server.
- [ ] 6.2 Verify plugin parity for configuration, player history, gifts, state-patch audits, and trajectories against controlled fixtures and an isolated Companion integration environment.
- [ ] 6.3 Remove SCUM-named platform APIs, models, services, routes, and frontend components only after no callers remain and migration/rollback evidence is recorded.
- [ ] 6.4 Run full platform, plugin, frontend, manifest, OpenSpec strict, structure, and isolated end-to-end verification; commit and push only the scoped migration files.