//! LINT-1 — `maat-sdk-types` must not transitively pull
//! `maat-engine`.
//!
//! Parallel to `maat-sdk-traits`'s test of the same name. This
//! one is structurally lighter because `sdk-types` is the leaf data
//! crate — every type in here is a pure data definition, and any
//! engine import would be a cycle break of the CS-1 / PTM-1 4-layer
//! crate model.
//!
//! The test is satisfied iff this file compiles. The integration-
//! test crate gets `sdk-types`'s `[dependencies]`, plus the
//! `[dev-dependencies]` block — both are inspected manually below.
//! If a future PR adds a `maat-engine` dep to `sdk-types`'s
//! `[dependencies]`, this file will not catch it directly; the
//! `deny.toml` workspace-graph guard will. But the test stays as a
//! fast-feedback structural assertion.

use maat_sdk_types::artifact::Artifact;
use maat_sdk_types::blueprint::EntityBlueprint;
use maat_sdk_types::events::GameEvent;
use maat_sdk_types::types::EntityTypeId;

#[test]
fn sdk_types_compiles_in_isolation() {
    // The presence of these imports in a binary that does NOT
    // declare `maat-engine` as a dep is the assertion.
    let _: Option<&str> = None;
    let _: fn() -> EntityTypeId = || EntityTypeId::from_raw(0);
    let _: Option<EntityBlueprint> = None;
    let _: Option<GameEvent> = None;

    // The Artifact trait is part of sdk-types' public surface
    // (UC-16). Reference it here so a future move to engine would
    // also surface as a test failure.
    fn _take<T: Artifact>() {}
}
