WikifitaGitHub live67e8de5
pesquisa · kaggle/pokemon_tcg_deck_strategy

Pokemon TCG - Deck Strategy Boundary

Deck selection and local self-play strategy under the immutable submission deck.csv contract.

Baixar raw

Pokemon TCG - Deck Strategy Boundary

Competition Contract

The submitted artifact contains main.py and deck.csv at archive root. deck.csv is the deck the Kaggle harness gives the agent for that submission. Once a submission archive is built and submitted, that deck composition is an immutable part of that submission artifact.

Runtime deck switching inside a submitted match is not part of the current legal contract. The agent reads deck.csv; it does not receive an alternate deck-selection channel or hidden state that would allow choosing a deck after seeing private opponent information.

Local Outer Loop

Deck optimization belongs outside the submitted match:

candidate decks
  -> local arena / self-play / matchup evidence
  -> select one deck
  -> write agent/deck.csv locally
  -> build submission.tar.gz

The current dashboard supports this local outer loop. The deck builder can save exact compositions, export CSV, compare a builder deck to agent/deck.csv, and write agent/deck.csv with a .bak backup. The arena tab ranks local decks and can replace agent/deck.csv with the locally best-ranked deck.

That is a local preparation mechanism, not a hidden runtime input.

Future suggested_deck.csv

suggested_deck.csv is a plausible future artifact for separating "what the local optimizer recommends" from "what the current submission actually ships." It is not implemented in the inspected code. Until it exists, agent/deck.csv is both the local default deck and the submission deck source.

If suggested_deck.csv is added later, it should remain an outer-loop artifact: the build process or dashboard may use it to update agent/deck.csv before a submission is packaged, but the submitted policy still must not receive illegal post-matchmaking deck choice or hidden opponent information.

Evidence Requirements

A candidate deck record should include:

  • exact composition fingerprint;
  • source and authoring path;
  • local tournament or self-play evidence;
  • opponent set and date;
  • model/checkpoint identity used during evaluation;
  • whether it was only suggested, locally active, or actually submitted.

This prevents deck evidence from being conflated with model evidence.

Related Pages