browser/openspec/changes/integrate-real-scum-ops-workflows/tasks.md

1. Workflow A - Contracts and Safety Model

• 1.1 Positive prompt: Build the shared SCUM real-data and controlled-operation contract so platform, platform_web, and plugins agree on real observation records, typed write operations, workflow instances, and confirmation states.
• 1.2 Directional prompt: Update platform/domain, platform/dto, platform/validator, plugins/sdk, and manifest schemas using existing job, bridge, protected request, gift, and player-state patterns; verify with Go tests and plugin type/schema tests.
• 1.3 Boundary prompt: Do not add a run/ tree, raw SQL browser payloads, host paths, DSNs, sockets, credentials, billing, hosting sales, or unrelated SaaS marketplace behavior.
• 1.4 Define domain/DTO types for SCUM observations, projection freshness, workflow instances, workflow steps, operation requests, mutation guards, confirmation results, and safe summaries.
• 1.5 Extend validators to reject arbitrary SQL/RCON/terminal fields in browser/plugin payloads while accepting declared typed query and operation template keys.
• 1.6 Add tests proving raw SQL, host paths, direct sockets, credentials, and undeclared operation keys are rejected before job creation.

2. Workflow B - Real SCUM Data Observations

• 2.1 Positive prompt: Read real current-server SCUM facts from login logs and SCUM.db through the bound run/agent, then persist local projections without fake data.
• 2.2 Directional prompt: Extend existing log ingest, game player services, remote adapter/query template plumbing, and job result projection in platform/; verify with unit tests around stale observations and schema validation.
• 2.3 Boundary prompt: Do not query SCUM.db from platform_web, do not expose SQL text or machine paths, and do not overwrite last-known-good projections on failed observations.
• 2.4 Add projection repositories for players, live states, squads, squad members, vehicles, flags, current positions, and observation metadata.
• 2.5 Wire login/logout log parsing to player/session projection creation and update, preserving source evidence and unknown fields.
• 2.6 Add typed SCUM.db read-result projection handlers for player profile/economy, squads, squad members, vehicles, flags, and positions.
• 2.7 Add freshness/stale-state logic with sequence, observedAt, receivedAt, checksum, query key, and server/plugin binding validation.
• 2.8 Add tests for older observation rejection, failed-query stale marking, user_profile_id vs Steam/user ID separation, and last_save_time freshness-only behavior.

3. Workflow C - SCUM Plugin Read Templates

• 3.1 Positive prompt: Declare SCUM plugin read templates for users, squads, vehicles, flags, and coordinates using real SCUM.db tables and typed result schemas.
• 3.2 Directional prompt: Update plugins/examples/scum-server-plugin/manifest.json, schemas/bridge/queries, plugin tests, and manifest validation while keeping query declarations safe and route-scoped.
• 3.3 Boundary prompt: Do not copy scum_robot management-library fields as SCUM.db facts, do not infer missing fields, and do not let pages submit SQL text.
• 3.4 Add query templates for player profile/economy/position using user_profile, prisoner, prisoner_entity, entity, bank_account_registry, and bank_account_registry_currencies.
• 3.5 Add query templates for squads and members using squad, squad_member, and user_profile.
• 3.6 Add query templates for vehicles using vehicle_spawner and entity, with unknown/fallback vehicle labels when mapping is absent.
• 3.7 Add query templates for flags using base_element, user_profile, squad_member, and squad where available.
• 3.8 Add schema and validation tests for row bounds, typed result shape, page/template binding, and route permissions.

4. Workflow D - Controlled RCON Operations

• 4.1 Positive prompt: Support safe fame, normal currency, gold, player notification, and reward command workflows through typed RCON operations where SCUM supports commands.
• 4.2 Directional prompt: Build on existing source RCON/protected RCON dispatch and game client bridge command approval paths; verify with service tests for approval, redaction, and confirmation status.
• 4.3 Boundary prompt: Do not restore a product terminal or arbitrary RCON input box; do not mark queued commands as delivered or successful.
• 4.4 Declare typed RCON operation templates for player.fame.set, player.currency.normal.set, player.currency.gold.set, player.notify, and command-backed reward delivery.
• 4.5 Add platform services to create, approve, dispatch, and reconcile typed RCON operation requests with idempotency and audit references.
• 4.6 Add read-after-write confirmation using follow-up SCUM.db observation queries or typed companion results.
• 4.7 Add tests for permission denial, protected text redaction, command unknown state, confirmation failure, and duplicate prevention.

5. Workflow E - Controlled DB Mutations

• 5.1 Positive prompt: Support database-only player state edits such as field 855 through typed mutation templates with maintenance/offline safety and readback confirmation.
• 5.2 Directional prompt: Extend operation template schemas, platform operation services, and run job execution contracts without storing raw mutation SQL in browser-visible records; verify with stale-write and confirmation tests.
• 5.3 Boundary prompt: Do not use DB mutation for fame/currency when RCON exists, do not write more than declared row bounds, and do not proceed without before-value guards.
• 5.4 Add mutation template declarations for DB-only player fields with field key, table/identity mapping metadata, allowed range, safety level, confirmation query, and max affected rows.
• 5.5 Add platform approval flow requiring current projection, before match, offline/maintenance window, backup/snapshot evidence, and platform-admin approval.
• 5.6 Add run job result validation for affected rows, mutation checksum, confirmation rows, and unknown execution states.
• 5.7 Add tests for online-player blocking, missing maintenance window, stale before-value, over-bound affected rows, and successful confirmation.

6. Workflow F - Sequential Workflow Engine

• 6.1 Positive prompt: Create a SCUM workflow queue that can run real-data refreshes and controlled operations one by one with dependency tracking.
• 6.2 Directional prompt: Add platform workflow domain/repo/service/API code near existing job/game-client/gift/player-state services; keep run execution delegated through existing job channels.
• 6.3 Boundary prompt: Do not replace the generic run job scheduler, do not block control heartbeat/log/artifact channels, and do not expose protected payload text in workflow status.
• 6.4 Implement workflow instance and step state transitions: draft, queued, running, waiting, blocked, confirming, confirmed, failed, unknown, cancelled.
• 6.5 Implement per-server sequential dispatch for state-changing steps and bounded concurrency for read-only observation steps.
• 6.6 Add workflow templates for bootstrap real data, player refresh, world refresh, player correction, gift delivery, territory audit, vehicle audit, AI assist, and product cleanup.
• 6.7 Add idempotency, fencing, retry, confirmation-before-retry, and blocker-safe-summary behavior.
• 6.8 Add tests for ordered execution, dependency blocking, run-unavailable blocking, retry without duplicate effects, and terminal status projection.

7. Workflow G - Product APIs and Projection Views

• 7.1 Positive prompt: Expose safe SCUM APIs for projection-backed users, squads, vehicles, flags, map overlays, gifts, operations, workflows, and AI drafts.
• 7.2 Directional prompt: Add platform/api, platform/dto, and service handlers following existing resource handler patterns; verify authorization tests and DTO round trips.
• 7.3 Boundary prompt: Do not expose raw logs, terminal input, arbitrary config file editing, generic operation-history APIs, SQL text, DSNs, host paths, or raw protected request payloads.
• 7.4 Add list/detail APIs for SCUM players, squads, squad members, vehicles, flags, current positions, map overlays, and observation freshness.
• 7.5 Add workflow APIs for creating refresh/correction/gift/audit/AI workflows, listing workflow status, approving required steps, cancelling safe pending steps, and reading audit-safe summaries.
• 7.6 Update or remove legacy product APIs for raw logs, management terminal, raw config workbench, and generic operation history.
• 7.7 Add authorization tests for operator vs platform-admin actions and raw endpoint removal/denial.

8. Workflow H - SCUM Product Surfaces

• 8.1 Positive prompt: Replace SCUM plugin pages with real projection-backed user management, squad management, realtime map, vehicle/flag management, gift management, workflow status, and AI assistant surfaces.
• 8.2 Directional prompt: Update platform_web contracts and SCUM plugin feature pages while preserving the black mecha and crystal-moonlight theme system; run typecheck and frontend tests.
• 8.3 Boundary prompt: Do not introduce generic SaaS cards, page-local fixed decoration spans, raw terminal/log/config/history panels, or fake map/sample data.
• 8.4 Build user management UI showing identities, sessions, projection source, squad, fame, balances, coordinates, freshness, and typed edit workflow launchers.
• 8.5 Build squad/flag UI showing rosters, ranks, leaders, flags, ownership confidence, stale state, and refresh/audit workflow controls.
• 8.6 Build realtime map UI using local projections for players, vehicles, flags, squads, timestamps, stale status, and refresh controls.
• 8.7 Build gift UI for catalog versions, schedules, eligibility, claims, delivery workflow status, confirmation, unknown-state reconciliation, and player notifications.
• 8.8 Keep AI assistant UI for typed config diffs and workflow drafts, wired to approval flows rather than raw file editing.
• 8.9 Remove raw logs, management terminal, raw config workbench, and operation history routes from server detail navigation and plugin workspace contracts.

9. Workflow I - Run Integration Contract

• 9.1 Positive prompt: Define the browser-repo contract expected from the independent run repository for SCUM.db reads, RCON writes, DB mutations, confirmation reads, and log ingestion.
• 9.2 Directional prompt: Document and test platform/plugin protocol expectations in this repo; keep executable run implementation for git@git.npc0.com:admin343/run.git outside this repository.
• 9.3 Boundary prompt: Do not add run source code here, do not require deployment target/run endpoint at server creation time, and do not leak component auth keys or host paths.
• 9.4 Add protocol DTOs or contract docs for read observation inputs/results, mutation inputs/results, confirmation payloads, schema probes, and safe errors.
• 9.5 Add compatibility tests/mocks proving platform can process run-style read/mutation/RCON results without real run code in this repository.
• 9.6 Document external run tasks needed to execute SCUM.db query templates and controlled mutation templates on the service machine.

10. Workflow J - Verification, Cleanup, Commit

• 10.1 Positive prompt: Verify the full SCUM integration change with backend, frontend, plugin, structure, and OpenSpec checks before committing.
• 10.2 Directional prompt: Run targeted tests during implementation and final commands: (cd platform && go test ./...), (cd platform_web && npm run typecheck && npm run test && npm run build), (cd plugins && npm run typecheck && npm run test && npm run validate:manifest), scripts/check-structure.sh, and openspec validate integrate-real-scum-ops-workflows --strict.
• 10.3 Boundary prompt: Do not mark tasks complete without verification evidence, do not stage unrelated worktree changes, and do not push if required verification or credentials fail.
• 10.4 Sweep for forbidden raw SQL/RCON/terminal/config/history product surfaces and unsafe browser-visible fields.
• 10.5 Update documentation or comments only where they clarify new contracts and workflow behavior.
• 10.6 Stage only files changed for this task, commit on main, and push to the configured remote after verification succeeds.