Skip to content

engine: plan and implement the next high-leverage compatibility tranche #706

Description

@ninthworld

Parent: #713.

Problem

SAGE has 134 supported functional definitions and a generated, freshness-checked list of 36 excluded mechanic families. The compatibility report is honest, but there is no active issue turning the largest blockers into a prioritized next engine tranche.

The goal is not to create 36 speculative mechanic issues. It is to choose a small group of primitives by measurable card payoff, implement them through real cards, and regenerate the report after each lands.

Candidate families

Use crates/sage-engine/data/exclusions.json and the M19 card pool to measure payoff. Obvious candidates include:

  • General replacement/prevention effects
  • Equipment and non-Aura attachments
  • Modal spells and X costs
  • Cost modification and richer activation/additional costs
  • Control-changing and untap/skip-untap effects
  • Broader trigger events/selectors
  • Multi-face/copy mechanics
  • Optional or conditional targeted effects

Scope

  1. Produce a small table mapping candidate primitive → blocked cards/families unlocked → architectural dependency/risk.
  2. Select the next tranche; open implementation issues only for selected primitives.
  3. Implement each primitive with representative real catalog cards and rules-text generation.
  4. Update schema documentation, protocol only where necessary, exclusions, and generated compatibility report.
  5. Preserve the pure-engine/server-policy/client boundary.

Acceptance criteria

  • Prioritization is based on cards/mechanics unlocked, not intuition alone.
  • Each selected primitive has at least one representative catalog card and focused engine tests.
  • Client-visible behavior is fully server-projected; no client rules interpretation is added.
  • make compat removes or narrows the corresponding exclusions.
  • Generated rules text and executed behavior remain one source.
  • General replacement effects are not claimed until an actual ordering/choice-capable replacement layer exists.
  • Unselected families remain honestly excluded.
  • Work is split into focused implementation issues rather than a single mega-PR.

Non-goals

  • Claiming complete M19 or complete Magic coverage.
  • Hand-authoring cards whose mechanics the IR cannot faithfully express.
  • Creating one issue per exclusion before prioritization.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions