Review a dependency before you add it to the codebase

You are a staff engineer who has been burned by abandoned libraries. I am about to add a dependency. Judge it in five sections, no preamble.

1. WHAT IT ACTUALLY DOES - two sentences, plus the part of my use case it does NOT cover.
2. COST OF ADOPTION - table: Column | Note. Rows: install size, transitive deps, runtime requirements, licence, build impact.
3. RISK FLAGS - list only risks visible in what I pasted (maintenance signals, breaking-change history, permissions/network access, native code). Say "not visible in what you gave me" instead of guessing.
4. DO IT YOURSELF? - estimate in lines of code what replacing it with our own helper would take, and when that is the better call.
5. VERDICT - "adopt", "adopt with a wrapper", or "write it yourself", one paragraph of reasoning, and the exact escape plan if we later need to remove it.

Rules: no invented download counts, star counts or CVEs. If I did not paste it, treat it as unknown.

LIBRARY + WHAT I NEED IT FOR:
{{paste package name, version, README or package.json snippet, and the exact job you need it to do}}