Questing Cosplayer's Role token is created and then immediately swept, so the trigger does nothing.
Two defects, one symptom
1. Parser drops the attach clause. Oracle text (verified from client/public/card-data.json):
When Questing Cosplayer enters the battlefield, create a Questing Role token and attach it to target creature.
parses to Effect::Token { name: "Questing Role", types: ["Enchantment","Aura","Role"], attach_to: null }. The and attach it to … clause is unbound. It is the only one of 48 Aura-typed Effect::Token specs in the shipped pool with no host.
2. Engine has no CR 303.4i guard on that path. apply_create_token_after_replacement (crates/engine/src/game/effects/token.rs:817-900) runs its entry tail with no CR 303.4f/303.4g/303.4i consult, so an Aura token whose host doesn't bind enters unattached and dies to the CR 704.5m SBA. resolve_attach_host (token.rs:2934) concedes this in its own doc: "the apply path then leaves the token unattached and the CR 704.5m SBA … moves the orphaned Aura to the graveyard."
CR 303.4i (docs/MagicCompRules.txt:1661) says the opposite must happen:
If an effect attempts to put an Aura onto the battlefield attached to either an object or player it can't legally enchant or an object or player that is undefined, the Aura remains in its current zone… If the Aura is a token, it isn't created.
Confirmed empirically: flipping a Role-token fixture to attach_to: None leaves zero Wicked Role permanents on the battlefield and raises no prompt.
Relation to #5904
Same symptom, different rule and different seam. #5904 is the copy-token path under CR 303.4f and is fixed by #7303; that change deliberately did not touch this one. The fix here is to hoist the entering_aura_hosts / apply_entering_aura_hosts consult into apply_create_token_after_replacement's per-token loop, gated on the spec's host being unbound — mirroring what the non-liminal copy loop now does at token_copy.rs:645-800.
Both defects need fixing: the parser one so the card works at all, the engine one so any future unbound Aura token follows CR 303.4i instead of vanishing.
Found by review during #5904.
Questing Cosplayer's Role token is created and then immediately swept, so the trigger does nothing.
Two defects, one symptom
1. Parser drops the attach clause. Oracle text (verified from
client/public/card-data.json):parses to
Effect::Token { name: "Questing Role", types: ["Enchantment","Aura","Role"], attach_to: null }. Theand attach it to …clause is unbound. It is the only one of 48 Aura-typedEffect::Tokenspecs in the shipped pool with no host.2. Engine has no CR 303.4i guard on that path.
apply_create_token_after_replacement(crates/engine/src/game/effects/token.rs:817-900) runs its entry tail with no CR 303.4f/303.4g/303.4i consult, so an Aura token whose host doesn't bind enters unattached and dies to the CR 704.5m SBA.resolve_attach_host(token.rs:2934) concedes this in its own doc: "the apply path then leaves the token unattached and the CR 704.5m SBA … moves the orphaned Aura to the graveyard."CR 303.4i (
docs/MagicCompRules.txt:1661) says the opposite must happen:Confirmed empirically: flipping a Role-token fixture to
attach_to: Noneleaves zeroWicked Rolepermanents on the battlefield and raises no prompt.Relation to #5904
Same symptom, different rule and different seam. #5904 is the copy-token path under CR 303.4f and is fixed by #7303; that change deliberately did not touch this one. The fix here is to hoist the
entering_aura_hosts/apply_entering_aura_hostsconsult intoapply_create_token_after_replacement's per-token loop, gated on the spec's host being unbound — mirroring what the non-liminal copy loop now does attoken_copy.rs:645-800.Both defects need fixing: the parser one so the card works at all, the engine one so any future unbound Aura token follows CR 303.4i instead of vanishing.
Found by review during #5904.