Gundam Card Implementation
Use this when the unit of work is one card. Printed text and current rules are the behavior contract; generated structure and older implementations are evidence, not authority.
Required Context
- Read
references/glossary.mdin thegundam-tcg-rulesskill, then load the rules skill itself. - Read the card definition and sibling test.
- Find a current card of the same type with similar timing, cost, targeting, or zone behavior.
- Use
gundam-test-generationfor the behavior test shape.
Workflow
- Decompose each printed ability into timing, conditions, costs, choices, targets, effects, and duration.
- Compare that contract with the card's structured
effectsdata and the engine handlers that consume it. - Add the smallest failing observable behavior test. Cover every printed branch that changes legality or outcome.
- Fix the narrowest owner:
- Card data for card-specific structure.
- Engine for reusable rules behavior.
- Types only when the engine contract genuinely needs a new variant.
- Keep cards declarative. Card files must not import engine runtime internals.
- Run the targeted card test, close siblings, and engine tests when a shared primitive changed.
Boundaries
- Preserve deterministic runtime behavior and
GameLoggerownership. - Do not replace behavior coverage with
effectssnapshots. - Do not add a one-card special case to a shared handler when a typed primitive expresses the rule.
- Keep parser-generated output under review; non-trivial text can require a hand-corrected structured effect.
Report the printed contract, test path, owning root cause, files changed, exact checks, and any unsupported rules edge.