Write a design handoff spec that survives contact with an engineer who wasn't in the design reviews

DESIGN BEING HANDED OFF
A multi-select dropdown filter component used across three list views in the app.

COMPONENT STATES THAT EXIST
Default (closed), open/focused, an option hovered, an option selected (shows a chip), disabled, no options available.

DESIGN SYSTEM TOKENS AVAILABLE
spacing-sm (8px), spacing-md (16px), color-border-default, color-border-focus, color-bg-disabled, text-body-sm.

KNOWN EDGE CASES OR UNUSUAL CONTENT
A filter option label 40+ characters long; zero options available; all options selected at once (10+ chips).

ENGINEER'S CONTEXT LEVEL
A contractor brought on for two weeks who has never worked in this codebase before.

Write the handoff spec assuming the engineer implementing this was not in any of the design discussions and cannot ask you a clarifying question in real time — every ambiguity has to be resolved in the document itself. For each item in COMPONENT_STATES (default, hover, focus, disabled, loading, error, empty, if applicable), specify exactly what changes visually and behaviorally — do not leave a state as "same as default" without confirming that's actually intended rather than simply undesigned. Reference DESIGN_TOKENS by name for every spacing, color, and typography value rather than describing them visually ("a bit of padding", "the usual blue") — a spec that isn't traceable to actual token names forces the engineer to eyeball values from a screenshot, which is exactly what a spec exists to prevent.

For EDGE_CASES specifically (very long text, zero items, a value at the maximum the field allows, an unusually small or large image), state what should happen, since these are the cases most likely to have been designed for the happy path only and never explicitly resolved — if you genuinely don't know the answer for a given edge case, say so explicitly and flag it as an open question for the designer rather than inventing a plausible-sounding answer that could quietly become the de facto spec if the engineer just codes what's written.

Describe responsive behavior as explicit breakpoint rules (what happens at each named breakpoint), not a vague "should adapt for mobile" — if the source design only shows one viewport, say so and flag every other viewport's behavior as undefined rather than implying it was designed when it wasn't. Calibrate the level of explanation to ENGINEER_CONTEXT — do not over-explain design-system fundamentals to someone who works in this codebase daily, but do not assume shared context with someone new to the project or an outside contractor.

WHAT NOT TO DO
Do not describe the static default state in exhaustive detail while waving at other states with "styled consistently with the rest of the app" — that phrase is where handoff specs actually fail, because "consistent" is not a value an engineer can implement without guessing. Do not invent an edge-case behavior that wasn't actually decided; flagging an open question is a better outcome than a wrong guess.

OUTPUT FORMAT
1. Component states table: state | visual changes | token references | behavioral notes.
2. Edge cases table: case | resolved behavior or 'open question — needs designer input'.
3. Responsive behavior by breakpoint, or explicit note on what's undefined.
4. A short list of every open question flagged, pulled together in one place so nothing gets missed in the body of the spec.