browser/openspec/changes/replace-scum-projections-with-real-data-management/evidence/scum-current-service-sqlite-diagnostic-2026-08-12.md

# SCUM Current-Service SQLite Diagnostic Evidence — 2026-08-12

## Scope

- Evidence kind: operator-directed, server-local, read-only diagnostic discovery.
- Execution target: `枣庄服务器` through the personal server-management MCP (`list_devices`, `test_connection`, `ssh_exec`).
- Product boundary: Platform/plugin did not download or parse `SCUM.db`. The diagnostic script executed on the game server host and emitted only schema metadata, aggregates, hashes, and redacted samples.
- Release boundary: this evidence supports adapter discovery. It does not replace the Platform durable Run job / typed Run envelope required before enabling database-backed production capabilities.

## Database Identity and Read Behavior

- One active `SCUM.db` candidate was found beside the running SCUM service metadata; no host path is recorded in this artifact.
- Read mode: Python `sqlite3` URI `mode=ro`, `PRAGMA query_only=ON`; initial probes used a 2s timeout, and the cadence/lock probe used a 0.75s connection timeout plus `busy_timeout=250ms`.
- Database size: initial schema probe `80,805,888` bytes; cadence probe `80,846,848` bytes.
- SQLite metadata: `schema_version=765`, `user_version=57`, `journal_mode=wal`, `page_size=4096`, `page_count=19728`, `freelist_count=1`.
- Object inventory: `293` schema objects, `161` tables.
- Safe-read timing observed: full schema inventory `61ms`; focused groups `3ms`, `13ms`, `3ms`; join/range metrics `25ms`; follow-up join/meaning probes `27.3ms` and `5.68ms`; cadence probe p95 timings were `15.576ms` for all-entity coordinate range, `0.603ms` for player coordinate range, `0.438ms` for bounded player-position fingerprint, `0.316ms` for vehicle coordinate range, and `0.069ms` for spawn-location range. No read lock/busy failure was observed during these diagnostics.
- Fingerprints: full schema objects `57e34ee72660d7e4334644ee70cd6d285ac7961a3964fafdc3956d74e88dfa4f`; focused table groups `12a34e49f851879ae71ba287719c8d95019909f3060e823be4ce0973ce764841`, `a856bc4e105ab0a5e34b758237d3f96cff0ba5a65b38e7cf1eb81ab16b40caf4`, `60c97a8c782086c4b2600eb3a9b29c3074b971d5fdc6cf54137ce48e0970b26e`; join/range metrics `4905d09b70303b42cfb8e7fc936fe0df2065d7100c43e92ef79a464958249af4`.

## Coordinate Cadence, Snapshot, and Safe Limits

- Cadence probe: `10` read-only samples over `27.175s` against the same single active database candidate; the database file modification time changed during `5` samples, but `schema_version`, `data_version`, all-entity coordinate range, player coordinate range, player position fingerprint, vehicle coordinate range, and spawn range remained stable. Aggregate digest: `59fe6dfd8c2dc41d3533a9a4d860e82c6a5486edf079049f5c66436d67d7b100`.
- Snapshot consistency: a repeated player coordinate aggregate inside one read transaction returned identical results (`repeat_equal=true`, digest `38b1865f062aa27181f4fb5c2301b2f52a5e312bd9b4f085c62b1df6d27284eb`).
- Current coordinate ranges in the cadence probe: all `entity` rows `63370`, x `-901009.4375..612580.0625`, y `-883992.5625..615977.375`, z `-3573.64990234375..102111.6640625`, null coordinate count `0`; joined prisoners `72`, x `-872217.6875..567603.0625`, y `-843655.8125..554482.125`, z `221.87356567382812..82958.546875`, `prisoner.last_save_time` `1773202437..1786549259`; vehicle entities `313`, x `-898438..601692.3125`, y `-881533.25..605226.5`, z `-84.04053497314453..98312.640625`, functional vehicles `303`, distinct asset IDs `15`.
- Base/flag coordinate support: `base` has `5` rows with x `-381908.21875..349512.28125` and y `-565472..538980.75`; `base_element` has `1533` rows with x `-382911.5..349512.28125`, y `-566506.125..538980.75`, and z `570.5759887695312..37294.0078125`; `base_element_flag` has `5` rows and no direct coordinate columns, so a flag/territory adapter must use the verified base/base-element relationship rather than inventing separate flag coordinates.
- Spawn-location range remains non-current-position evidence: `78` rows, x `-872218..567603`, y `-843656..554482`, z `223..115567`, `2` distinct observed types.
- Safe polling limits derived for adapter design: SQLite reads should use `mode=ro`, `PRAGMA query_only=ON`, `busy_timeout<=250ms`, operation timeout `<=2000ms`, single-query target `<=750ms`, result bytes `<=262144`, and initial row limits of `500` player positions, `1000` vehicle positions, and `200` flags/base rows unless a versioned adapter proves tighter or broader bounds.
- Realtime-map conclusion: SCUM.db writes occurred during the sample window, but the verified position aggregates/fingerprints did not change. The database source does not currently prove a sub-10s realtime-map cadence; any sub-10s claim requires a separately declared and verified companion position source. Until then, the product must present the measured database cadence honestly and avoid fabricated intermediate motion or unsafe polling.
- Non-blocking probe warnings: optional exploratory fingerprint/ownership subqueries that assumed unverified vehicle row and flag-owner column names were rejected safely. Those warnings did not affect the successful coordinate/cadence aggregates and do not enable vehicle ownership, flag ownership, or write capabilities.

## Evidence Matrix

| Area | Current-service evidence | Remaining ambiguity |
| --- | --- | --- |
| External player identity | `user` has `74` rows with `id TEXT` primary key, `id_type`, `provider`, `last_login_time`, `creation_time`, `is_banned`, and network-address field present but not persisted in this artifact. Follow-up aggregates show all `74` users have `id_type=Steam`, provider `Server`, and non-null identity/login/banned fields. | Product APIs must hash or fence external IDs where appropriate and must never expose IP/network material. |
| Player profile join | `user_profile` has `73` rows; all `73` join to `user` through `user_profile.user_id -> user.id`; all profiles have `type=1`. `user_profile.prisoner_id -> prisoner.id` and `prisoner.user_profile_id -> user_profile.id` both resolve `72` profiles. Indexes on `(user_id,type,name)`, `type`, and `prisoner_id` were observed. | Profile `type=1` is observed but not independently named; adapter labels must stay version-scoped rather than using reference-project meanings. |
| Character/prisoner join | `prisoner` has `72` rows and `prisoner_entity` has `72` rows mapping `prisoner_id -> prisoner.id` and `entity_id -> entity.id`. Join metrics: `73` profiles, `73` with user, `72` with prisoner, `72` with prisoner entity, `72` with entity; exactly one profile has null `prisoner_id`. | One profile has no current prisoner/entity. Online state must still come from authenticated login/session evidence, not database timestamps alone. |
| Character XML / payload | `user_profile.template_xml` is present and non-null for `73/73` profiles, length range `2541–2673`; samples were hash+length only. `prisoner_skill.xml` has `72/1656` non-null rows, length `15–65`; `item_entity.xml` has `42304/62844` non-null rows, length `136–4781`. | `user_profile.template_xml` is the verified profile-level XML source candidate, but write semantics, named attributes, and `855` mapping remain unverified. |
| Player coordinates | `entity` has `63364+` rows with `location_x/y/z`, `rotation_x/y/z`, scale, flags, class, and optional BLOB data. The cadence probe observed `72` joined prisoners with x `-872217.6875..567603.0625`, y `-843655.8125..554482.125`, z `221.87356567382812..82958.546875`; `prisoner.last_save_time` range `1773202437..1786549259`. | Database writes occurred during the cadence window, but verified player coordinates did not change; do not claim sub-10s realtime from SCUM.db without a companion source. |
| Squad | `squad` has `7` rows; `squad_member` has `18` rows with `squad_id`, `user_profile_id`, `rank`; all members join to both squad and profile. Rank distribution: `1:6`, `2:2`, `3:4`, `4:6`; squad sizes are `1` member for `3` squads, `2` members for `2` squads, `3` members for `1` squad, and `8` members for `1` squad. | Rank meanings / leader semantics are not present in the probed schema. Keep rank labels neutral and leader unknown unless a versioned adapter proves the mapping. |
| Vehicles | `vehicle_spawner.vehicle_entity_id -> vehicle_entity.entity_id -> entity.id` resolves all `313` vehicle spawners; `15` distinct `vehicle_asset_id` values and one redacted alias value were observed. `is_vehicle_functional` distribution is `303` true / `10` false and all spawners are marked automatically created. Vehicle entity coordinate range: x `-898438..601692.3125`, y `-881533.25..605226.5`, z `-84.04053497314453..98312.640625`. | Vehicle ownership meanings are absent from the verified join. Status can be limited to the probed functional/automatic-created fields; owner stays null. |
| Flags / bases | `base_element_flag.element_id -> base_element.element_id -> base.id` resolves all `5` flags. All `5` flags have an owner profile through the verified flag/base join from the join-meaning probe; the coordinate-cadence probe separately confirmed `base` and `base_element` coordinate ranges while `base_element_flag` itself has no direct coordinate columns. | Profile ownership and coordinate support are verified only through the probed joins. Squad territory ownership remains separately gated because one owner has no squad membership and membership may not be the same fact as base ownership. |
| Economy / balances | `bank_account_registry.account_owner_user_profile_id -> user_profile.id` resolves all `73` accounts; `bank_account_registry_currencies.bank_account_id -> bank_account_registry.id -> account_owner_user_profile_id` resolves all `146` currency rows. The nullable `user_profile_id` columns in both bank tables are entirely null. Currency distribution: type `1` has `73` rows, `account_balance` range `-3000..830328`; type `2` has `73` rows, range `0..14636`. | Currency type meanings, units, safe command/readback semantics, and gift item aliases remain unverified. Query adapters may expose numeric type only behind version-scoped labels until commands/readback are proven. |
| Spawn/location table | `prisoner_spawn_location` has `78` rows with `location_x/y/z`, rotation, velocity, `type`, optional `shelter_id`; coordinate range roughly matches player entity bounds. | This is spawn-location evidence, not current position evidence. |

## Redaction Notes

- Player names, squad names/messages, map names, aliases, XML, BLOB payloads, tokens, and network-address material were represented only as hash+type+length when sampled.
- Three player join samples were retained only as hash of external player id plus numeric profile/prisoner/entity IDs, timestamps, fame points, and coordinates.
- Follow-up probes returned only aggregate counts, distributions, nullable counts, column names, coordinate ranges, and timing; no raw rows, host paths, XML, player/squad names, IP/network material, commands, credentials, or sockets were recorded.
- No raw SQL, host database path, credentials, direct sockets, raw XML, raw player names, or raw IP/network identifiers are recorded here.

## Resulting Gates

- Task 2.5 schema capture is satisfied for discovery: `sqlite_schema`, read-only PRAGMA metadata, indexes, foreign keys, declared types, cardinalities, and redacted samples were captured for the candidate sources.
- Task 2.6 join/meaning verification is satisfied for discovery: external identity, profile/prisoner/entity joins, flag/base joins, vehicle identity joins, bank-account joins, nullable fields, and the profile XML source candidate are recorded. Unproven rank leader semantics, squad-territory ownership, currency labels/units, and write meanings remain explicitly gated rather than guessed.
- Task 2.7 cadence/safe-read discovery is satisfied: repeated read-only sampling measured coordinate ranges, latency, lock/busy behavior, snapshot consistency, safe limits, and the need for a companion position source before any sub-10s realtime-map claim.
- Task 2.8 remains open: map transform, gift aliases/transports, command confirmation, and `855` named-attribute mapping still require explicit verification.
- Database-backed SCUM read/write capabilities remain disabled until the corresponding versioned adapters and Run durable execution envelopes are implemented and accepted.