//! ER1 — `#[derive(EntityType)]` is the preferred name for the entity-type
//! derive (the legacy `#[derive(Entity)]` collides with the runtime
//! `maat_sdk::entity_state::Entity` struct). Both derives produce
//! identical output; this test proves:
//!
//! 1. A struct can be named `Entity` and still derive `EntityType` without
//!    alias imports — the original chess-author friction motivating ER1.
//! 2. `#[derive(EntityType)]` produces the same generated items as
//!    `#[derive(Entity)]` — both expose `TYPE_ID` and `blueprint()`.

use maat_sdk::types::EntityTypeId;
use maat_sdk_derive::EntityType;

const PLUGIN_CANONICAL: &str = "test:er1";

/// Struct intentionally named `Entity` to demonstrate the collision is gone.
#[derive(EntityType)]
#[entity(type_id = maat_sdk::types::entity_type_id_for(PLUGIN_CANONICAL, "Entity"),
         display = "Entity")]
pub struct Entity {
    pub featured: Option<maat_sdk::traits::FeaturedData>,
}

#[derive(EntityType)]
#[entity(type_id = maat_sdk::types::entity_type_id_for(PLUGIN_CANONICAL, "Widget"),
         display = "Widget")]
pub struct Widget {
    pub featured: Option<maat_sdk::traits::FeaturedData>,
}

#[test]
fn entity_struct_named_entity_compiles_under_entity_type_derive() {
    // The fact that this file compiles is the test. Sanity-check the
    // generated TYPE_ID is a sensible non-zero value.
    let id: EntityTypeId = Entity::TYPE_ID;
    assert_ne!(id.raw(), 0, "TYPE_ID should not be the reserved sentinel");
}

#[test]
fn distinct_structs_get_distinct_type_ids() {
    assert_ne!(Entity::TYPE_ID.raw(), Widget::TYPE_ID.raw(),
        "different entity names must hash to different EntityTypeIds");
}
