WikifitaGitHub live67e8de5
pesquisa · kaggle/pokemon_tcg_local_platform_design

Pokémon TCG — Local Platform and Arena Design

Current synchronous arena boundary, database/schema evolution, replay persistence, experiment records and future worker architecture.

Baixar raw

Pokémon TCG — Local Platform and Arena Design

Two states must remain separate

The local-platform documents describe both an existing synchronous research loop and a future normalized product boundary. They must not be merged into one implementation claim.

Current synchronous boundary

Streamlit or local controller
        -> tournament runner
        -> engine and packaged inference
        -> replay/result persistence
        -> SQLite ratings and reports

This is a local, synchronous arena. The current design explicitly does not promise distributed workers, network services, daemon orchestration, concurrent SQLite writers, queue consensus or a hosted competition control plane.

Future application boundary

The future arena architecture introduces an application boundary, queued jobs, workers and report artifacts. It is a design option for scaling research, not a current runtime fact. Its schema implications include explicit arena runs, model/deck identities, experiment configuration, source-separated ratings and report lineage.

Physical database versus target model

The current physical schema contains teams, cards, decks, submissions, days, agents, matches, participants, card usage, seasons, sources, daily Elo, meta observations, tournaments, matchups, steps, options, events, snapshots, field rows, datasets and receipts. The August 14 audit also found a substantial foreign-key anomaly surface, so the physical database is evidence requiring reconciliation rather than an unquestioned canonical model.

The target relational v2 design adds or clarifies:

  • stable identities for agents, models, decks and submissions;
  • immutable deck revisions rather than mutable labels;
  • normalized replay topology with explicit step ownership;
  • experiment and anamnese records;
  • source-separated ratings and tournament cohorts;
  • dataset manifests and receipts;
  • idempotent imports and validation reports.

The target is under review. It is not authorization to migrate or rebuild the database. The detailed service, dashboard and acceptance contract is preserved in pokemon_tcg_implementation_specification, while the table-by-table design delta is in pokemon_tcg_schema_evolution.

Replay and official visualizer boundary

Replay persistence is designed to preserve enough normalized state for analysis while allowing the official visualizer to remain the authoritative renderer for visual inspection. A local dashboard may launch or link to that visualizer; it should not silently replace its semantics with a custom approximation.

This distinction protects the evidence chain:

raw replay / receipt
    -> normalized local record
    -> analysis query
    -> report or tournament summary
    -> official visualizer for human inspection

Experiments and anamnese

The proposed experiment model treats each run as more than a checkpoint filename. It should record configuration, data window, source cohort, code commit, model lineage, optimizer state, validation policy, tournament protocol, deck set, reset assumptions and observations made afterward.

“Anamnese” is the temporal record of what was believed, changed, observed and later revised. It is especially important for this project because the Stage 3 failure was not visible in one metric: the incident only becomes legible when code history, stage logs, validation design, Antigravity reports and tournament cohorts are joined.

Acceptance boundaries from the implementation documents

The target implementation specification names concrete services and dashboard acceptance conditions, but those conditions remain a design contract until a live implementation and tests satisfy them. The explicit non-goal around blockchain is also retained: the local platform is a research and evaluation system, not a blockchain product.

What to build into later ETL and dashboard work

  • every report links to an experiment/run and source cohort;
  • every tournament result retains game count, opponent labels, deck identity and reset state;
  • rating views distinguish local, public, teacher, peer and synthetic sources;
  • dashboard summaries show denominators and unresolved integrity warnings;
  • destructive rebuilds require an explicit authorization boundary;
  • a design document is never used as evidence that its service exists.

Primary sources

  • docs/arena-future-architecture.md — current arena and future application/worker boundary.
  • docs/database_schema.md — current physical schema.
  • docs/schema-evolution.md — relational target and debt.
  • docs/implementation-spec.md — target services, dashboard and acceptance.
  • docs/local-overhaul-design.md — local product decisions and idempotency.
  • docs/technical_handoff_rfc.md — handoff schema and platform context.

Cross-references