release prep: v0.3.0 notes, OG/logo, announcement drafts, PyPI rename

* Rename PyPI package to `dcp-protocol` (the bare name `dcp` is taken by an
  unrelated package). Import name stays `dcp`.
* Bump @vitejs/plugin-vue to ^6.0.0 for Vite 7 compatibility.
* Add real OG image (1200x630) and a less-placeholder favicon/logo SVG
  via docs/site/scripts/og.py. Wire them into index.html meta tags.
* Add .github/RELEASE_NOTES_v0.3.0.md (used for the v0.3.0 release).
* Add .github/announce/{HN,twitter,zhihu,anthropic_outreach}.md drafts.

Author: WaylandYang

.github/RELEASE_NOTES_v0.3.0.md

@@ -0,0 +1,86 @@
+# DCP v0.3.0 — hardware-validated draft
+
+**The first release where every line of the protocol stack — Python Bridge,
+ESP32 firmware, conformance suite — runs end-to-end on a real
+$5 microcontroller, with an LLM at the other end of the wire.**
+
+This is a *draft* release: the spec is stable for v0.x but unsigned, the
+hardware matrix is still single-MCU, and the empirical safety study is
+future work (see `docs/RATIONALE.md §7` and `docs/paper/main.tex §7`).
+
+## Headline numbers
+
+- **88 / 88** Python unit and conformance tests pass
+- **10 / 10** round-trip tests pass against ESP32-WROOM-32 (CH340, 115 200 baud)
+- **Frame size:** 19 bytes for a typical `set_brightness(50)` call;
+  35 bytes with the optional HMAC tail
+- **Firmware footprint:** ~14 KB of pure DCP over an empty Arduino sketch
+- **Five transports** ship: loopback, UART (COBS + CRC-16), MQTT,
+  BLE GATT, in-process simulator. Plus the MCP server wrapper that
+  surfaces every intent to any MCP host
+
+## What's in this release
+
+### Wire & protocol
+- v0.3 spec at [SPEC.md](../../SPEC.md): 6-byte header + CBOR map +
+  optional 16-byte HMAC-SHA256, with all five status codes and the
+  manifest schema documented normatively.
+- Language-neutral [conformance suite](../../tests/conformance/) (golden
+  YAML + Python runner).
+
+### Reference implementations
+- **Python Bridge** (asyncio): manifest loader, range/type/capability
+  enforcement, dry-run wire bit, HMAC-SHA256 capability tokens, wire-level
+  HMAC.
+- **MCP server wrapper**: every manifest intent → MCP tool, zero code
+  per device.
+- **ESP32 firmware** (Arduino-compatible C++): hand-rolled CBOR subset,
+  self-contained SHA-256 (no mbedTLS dep), COBS framing, constexpr
+  `DCP_ID(name)` macro for compile-time intent IDs. Also includes BLE
+  GATT peripheral via NimBLE-Arduino.
+
+### Developer experience
+- [`dcp` CLI](../../README.md): `serve / inspect / codegen / token`.
+- [`docs/ADDING_FEATURES.md`](../../docs/ADDING_FEATURES.md): the
+  5-step loop to add a new intent (manifest → handler → test → flash →
+  LLM picks it up).
+- [`tools/test_uart_roundtrip.py`](../../tools/test_uart_roundtrip.py):
+  hardware integration harness.
+
+### Docs & design
+- [`docs/RATIONALE.md`](../../docs/RATIONALE.md): why not MCP-on-MCU,
+  why not WoT, why not Matter, why not Sparkplug B, why not OpenAPI.
+- [`docs/paper/main.tex`](../../docs/paper/main.tex): position paper
+  with figures, ready for arXiv submission.
+- [`docs/site/`](../../docs/site/): Vue 3 + Vite 7 + Tailwind v4 landing.
+
+### Release prep
+- MIT, CONTRIBUTING, CODE_OF_CONDUCT, SECURITY, issue / PR templates,
+  GitHub Actions CI (Linux + Windows × Python 3.11 / 3.12 / 3.13).
+
+## Honest caveats
+
+- Only one MCU validated so far (ESP32-WROOM-32). Cortex-M0+ port is
+  v0.4's headline.
+- No measured A/B against IoT-MCP — that's the follow-up paper.
+- Spec is **draft**: a v1.0 freeze is gated on a second-implementer
+  port (we're hoping for community C or Rust).
+- Wire-level HMAC has no in-band marker — deliberate, but means
+  configuration discipline matters. See `SPEC.md §7`.
+
+## Try it in five minutes
+
+```bash
+pip install -e ".[mcp,serial,dev]"        # all extras: ,mqtt,ble for those
+dcp inspect examples/lamp_manifest.yaml
+dcp serve   examples/lamp_manifest.yaml --simulator
+# in another shell, point any MCP host at the simulator
+```
+
+For real hardware, see [`firmware/esp32/README.md`](../../firmware/esp32/README.md).
+
+## Thanks
+
+To the IoT-MCP team (Yang et al., arXiv:2510.01260) for proving the
+direction; to the W3C WoT working group for the description-layer
+prior art; and to the MCP team at Anthropic for the upstream we extend.

.github/announce/HN.md

@@ -0,0 +1,71 @@
+# Hacker News submission
+
+## Title (under 80 chars, max 3 of these)
+
+Pick whichever you like best. **First one is my recommendation** — narrow,
+concrete, and avoids triggering HN's "Show HN" detector unfairly.
+
+1. **DCP: A compact protocol for letting LLM agents control $1 microcontrollers**
+2. **Show HN: DCP – Device Context Protocol, the last meter of MCP**
+3. **DCP: LLMs ↔ microcontrollers, with safety primitives at the wire format level**
+4. **Open protocol so Claude can dim your lamp through a $5 ESP32**
+
+## Body (optional first comment; HN allows you to leave the body empty
+## and put the explanation as a top-level self-comment instead — that
+## form gets more engagement)
+
+```
+Author here. Quick context for HN:
+
+DCP (Device Context Protocol) is a wire format + reference implementation
+for letting LLM agents safely control physical devices, scaling down to
+the cheapest microcontrollers you can buy.
+
+It's deliberately complementary to Anthropic's Model Context Protocol
+(MCP), which is designed for SaaS tools on host-class machines. A
+reference Bridge translates DCP <-> MCP so any MCP-compatible LLM
+(Claude Desktop, Claude Code, etc.) works zero-config.
+
+The pitch in three numbers:
+  - 19 bytes for a typical call frame (MCP JSON-RPC ~180 bytes)
+  - ~14 KB pure DCP code over an empty Arduino sketch on ESP32
+  - 88/88 Python tests + 10/10 round-trip tests pass against real ESP32
+
+The protocol-level safety primitives are the thing I most care about:
+  - Manifest declares units (no more F vs C confusion)
+  - Manifest declares ranges (Bridge rejects bad input pre-wire)
+  - Dry-run is a wire-format bit, not a convention
+  - Capability tokens scope what a session can do (HMAC-SHA256)
+  - All four enforced before any byte reaches the device
+
+The honest caveats are equally important and are spelled out in the
+design rationale (RATIONALE.md): only one MCU validated so far, no
+empirical A/B vs IoT-MCP yet, spec is draft.
+
+If you're skeptical: I'd most appreciate eyes on the spec
+(SPEC.md, ~250 lines), the conformance suite (golden frames in YAML),
+and the firmware (~450 lines of hand-rolled CBOR + COBS + SHA-256, no
+mbedTLS).
+
+MIT licensed. Repo: github.com/device-context-protocol/dcp
+```
+
+## When to post
+
+Tuesday or Wednesday morning, 7-10 AM Pacific. Avoid:
+- Weekends (lower traffic, gets buried)
+- Right after major Anthropic news (gets eaten by it)
+- Same week as a known competitor launch
+
+## Replying tips
+
+- **Don't be defensive.** If someone says "Why not just use MQTT?",
+  thank them and link the relevant section of RATIONALE.md. Don't argue.
+- **Engage with hostile comments politely.** HN rewards measured replies
+  even more than the original post.
+- **Pin one good clarifying comment** as your first reply — usually
+  "Here's the part most people don't grok about why this matters", with
+  a 3-paragraph explanation.
+- **Be honest about footprint numbers.** If someone asks "is that pure
+  DCP or includes the Arduino runtime?" — tell them: 294 KB total, ~14 KB
+  is the DCP delta. Don't claim the delta when the metric is total.

.github/announce/anthropic_outreach.md

@@ -0,0 +1,133 @@
+# Anthropic MCP team outreach
+
+Two channels. Use both — discussion post is high-signal-low-noise; email
+is in case the right person doesn't see GitHub Discussions.
+
+## Channel 1 — GitHub Discussion (PREFERRED, do this first)
+
+Open at: https://github.com/orgs/modelcontextprotocol/discussions
+
+**Category:** Show and Tell
+
+**Title:** `DCP: a complementary protocol for LLM-driven hardware control at MCU scale`
+
+**Body:**
+
+```markdown
+Hi MCP team and community 👋
+
+I built **[DCP — Device Context Protocol](https://github.com/device-context-protocol/dcp)**
+as a wire-format and architecture for the case MCP doesn't try to cover:
+LLM agents controlling physical devices on commodity microcontrollers
+(<16 KB flash, often without TCP/IP).
+
+I want to be **explicit about positioning**: DCP is downstream of MCP, not
+a competitor. The reference Bridge speaks MCP to the LLM and DCP to the
+device, so any MCP host (Claude Desktop, Claude Code, IDE assistants)
+works zero-config.
+
+**What's different at the wire level:**
+- 6-byte fixed header + CBOR map → typical call frame is 19 bytes (vs ~180 for MCP)
+- Static intent table — no runtime tool discovery; intent_id = CRC-16/CCITT(name)
+- Capability tokens for LLM-bounded permissions (HMAC-SHA256, scoped, expiring)
+- Dry-run as a wire-format kind, not a convention
+- Units declared in the manifest schema
+
+**What I'd love feedback on from you specifically:**
+
+1. **Is the "we extend MCP by translating" framing acceptable?** I want
+   to avoid any framing that competes with the MCP project. If there's
+   wording you'd prefer in the README and SPEC, please tell me.
+2. **Is there appetite within the MCP working groups to talk about a
+   downstream/embedded profile of MCP itself?** If so, DCP might inform
+   the design, or be a precursor that gets absorbed.
+3. **The 2026 roadmap centers on transport scalability and enterprise
+   readiness.** Confirming my read: there's no plan to descend to MCU-scale
+   devices upstream, so the gap DCP fills is real and stable.
+
+I'm not asking for anything formal — just want this to start in the
+right relationship with the MCP project rather than discovered
+adversarially later.
+
+A few additional artifacts:
+- Spec: [SPEC.md](https://github.com/device-context-protocol/dcp/blob/main/SPEC.md)
+- Design rationale (engages with the MCP gap explicitly):
+  [docs/RATIONALE.md](https://github.com/device-context-protocol/dcp/blob/main/docs/RATIONALE.md)
+- Paper draft (arXiv-ready):
+  [docs/paper/main.tex](https://github.com/device-context-protocol/dcp/blob/main/docs/paper/main.tex)
+
+Hardware-validated on ESP32-WROOM-32 (the kind that costs less than a coffee).
+MIT licensed.
+
+Thank you for MCP — it's been a huge step forward for the ecosystem.
+```
+
+## Channel 2 — Email (use only if the discussion goes ignored for 2+ weeks)
+
+**To:** Whichever MCP maintainer is most active in
+[modelcontextprotocol/specification](https://github.com/modelcontextprotocol/specification)
+recent commits/issues. Find their email from a commit
+(`git log --format='%an <%ae>'`) or LinkedIn.
+
+**Subject:** `Heads-up: an open complementary protocol for LLM control of microcontrollers`
+
+**Body:**
+
+```
+Hi <name>,
+
+I'm Wayland Yang. I work on infrastructure at deeplethe.
+
+Wanted to flag a project we just open-sourced that explicitly extends
+MCP into the hardware layer, in case it's of interest to the team:
+
+  https://github.com/device-context-protocol/dcp
+
+The short version: MCP's 2026 roadmap reasonably centers on enterprise
+SaaS scaling, not embedded devices. Meanwhile every "MCP server on
+ESP32" project ends up reinventing serial framing with no schema and no
+safety primitives. DCP is a small wire format (sub-50-byte frames,
+~14 KB MCU code) plus an architectural pattern where a Bridge process
+translates DCP <-> MCP and enforces all safety. The result is that any
+MCP-compatible LLM controls a $5 microcontroller without seeing any
+device-specific code.
+
+I'm not asking for endorsement; I just want to make sure if anyone on
+your end thinks about this layer of the stack, you know we exist and
+are aimed at being a downstream consumer, not a fork.
+
+The position paper draft (with explicit MCP relationship section) is at
+docs/paper/main.tex in the repo. Hardware-validated on ESP32. MIT.
+
+Happy to talk if useful, otherwise feel free to ignore — wanted you to
+hear about it from us first.
+
+Best,
+Wayland
+```
+
+## Things to avoid in any outreach
+
+- **Don't ask for code review.** That's not their job.
+- **Don't ask for amplification.** They can't, and asking would be tone-deaf.
+- **Don't claim "we filled MCP's gap".** Say "we extend MCP into a layer it
+  doesn't cover" — the framing matters.
+- **Don't conflate MCP team with Anthropic policy team.** This is a
+  protocol/engineering reach-out, not a partnership pitch.
+
+## If they engage
+
+Best-case outcomes, in order of value:
+
+1. They link DCP from an "ecosystem" section on the MCP site
+2. They open issues on DCP with feedback / disagreements (huge signal of seriousness)
+3. They suggest the project could become an MCP "device profile" in a future spec — start a real working-group conversation
+
+Anything beyond that is bonus.
+
+## Realistic timing
+
+- Discussion post → expect first reply 3-10 days, possibly never
+- Email → expect first reply 1-3 weeks, often never
+- Don't take silence as rejection; take silence as "they're busy, the
+  project speaks for itself."

.github/announce/twitter.md

@@ -0,0 +1,59 @@
+# Twitter / X thread
+
+## Hero tweet (post first)
+
+> 📡 Introducing DCP — Device Context Protocol.
+>
+> The protocol that lets LLM agents safely control a $5 microcontroller.
+>
+> Sub-50-byte frames. <16 KB MCU footprint. Capability-scoped.
+> Complementary to Anthropic's MCP — works zero-config with Claude.
+>
+> Open source, MIT.
+> 🧵 1/9
+>
+> [attach og.png]
+
+## Thread (one tweet per line; reply-chain them)
+
+> 2/9 ─ MCP is brilliant for SaaS tools. But it's JSON-RPC over WebSocket. ESP32 has 32 KB of RAM. The numbers don't work. The "MCP server on ESP32" projects out there are all hand-rolled serial protocols with no schema.
+
+> 3/9 ─ DCP keeps MCP's mental model (manifest + tool calls) but compiles to a 6-byte header + CBOR payload. A typical call: 19 bytes on the wire. MCP equivalent: ~180 bytes.
+
+> 4/9 ─ The host-side Bridge is the sole trust boundary. It speaks MCP to Claude, DCP to the device. Every safety check — capability, range, type, dry-run — happens *before* a byte reaches the MCU.
+>
+> Devices stay simple. LLMs never see raw GPIO.
+
+> 5/9 ─ Safety primitives the LLM gets *for free*:
+> • Units are part of the type (no F vs C confusion)
+> • Ranges are enforced pre-wire (no out-of-range slipping through)
+> • Dry-run is a wire bit (LLM can ask "what would this do?")
+> • Capability tokens scope what a session can touch
+
+> 6/9 ─ Validated on real hardware: ESP32-WROOM-32 over CH340 @ 115 200.
+> 10/10 round-trip tests, 88/88 Python tests. The full firmware (Arduino + FreeRTOS + DCP) is 294 KB; pure DCP delta is ~14 KB.
+
+> 7/9 ─ Five transports out of the box: loopback (testing), UART (COBS + CRC), MQTT, BLE GATT, plus the MCP server wrapper. Same frame format across all of them — your device's firmware doesn't change when you swap the wire.
+
+> 8/9 ─ Honest about what we have NOT done yet: only one MCU validated, no empirical A/B vs IoT-MCP (arXiv:2510.01260 — the closest prior art), spec is still draft. Everything we're sure of is in SPEC.md; everything we're not is in RATIONALE.md §7.
+
+> 9/9 ─ Spec, code, paper draft, firmware, conformance suite — all MIT-licensed:
+> 🔗 github.com/device-context-protocol/dcp
+>
+> If you have an ESP32 in a drawer and a Claude subscription, you have everything you need to reproduce the demo in 10 minutes.
+
+## Reply-back tweet to pin (after the thread)
+
+> One thing I keep wanting to add — DCP exists because the official MCP roadmap is going UP-stack toward enterprise SaaS, not DOWN to embedded. Both directions are right. We're the down version.
+>
+> Thanks to the IoT-MCP team for proving the direction first.
+
+## Tone notes
+
+- No emojis except the first 📡 and 🔗 — over-emoji'd announcements get
+  ignored on tech Twitter
+- The `og.png` is the make-or-break visual; if it doesn't show, the
+  thread dies
+- Reply to every @ mention for the first 48 hours
+- Don't engage with the bots that auto-quote-tweet announcements with
+  "have you considered X?" generated content