mascot-intake

# Mascot Intake Produce a factual handoff; do not design or render. This node handles original mascots for projects, products, brands, accounts and folders. A request for a photo-based portrait, avatar or reusable asset set of the user or an authorized person belongs to `personal-ip-image-pack`. ## Input contract Accept conversation history plus any local project/account/folder path, URL, attachment, screenshot or 1–3 sentence project description. Read accessible materials before asking anything. Reuse confirmed context and never make the user repeat it. ## Procedure 1. Read the supplied materials and confirm project context, purpose, audience, personality, must-keep, must-avoid, references and explicitly requested exaggeration. Record facts separately from assumptions. 2. If the materials are readable, infer the mascot role and useful subject constraints for the design director. Do not ask the user to choose a species or visual style merely because the materials do not name one; those are director decisions unless the user has explicitly constrained them. 3. Ask only one concise question when unreadable or missing information would materially change the next stage. Do not ask a delivery-scope question. 4. Apply the fixed project output: three different square full-body candidate images A/B/C. A/B/C are internal planning/rendering labels and are not a user approval gate. 5. After delivery, a bare A/B/C choice routes revision/continued feedback only; it cannot create a final asset. Explicit final wording is handled only after QA by the root/review flow. ## Output contract Return `project_context`, `confirmed_brief`, unresolved conflicts and `next_stage`. Return `next_stage: direction_planning` when ready. If context is missing, return `next_stage: intake`.