release: close the gaps that stop agentdeck reading as a professional open-source project

[sagi5060]

Problem

The repository is public and about to carry a stable tag, but several things a reader or packager expects are missing or wrong. None of them affect what the package does; all of them affect whether it is takeable seriously.

Concretely, verified against the tree at 64a1619:

• pyproject.toml declares no license. A LICENSE file exists, but nothing in the package metadata names it — so every tool that reads metadata (pip, PyPI, SBOM scanners, corporate review) sees an unlicensed package. This is the one item with real consequences: an unlicensed dependency is a blocker in most companies.
• No SECURITY.md. There is nowhere to report a vulnerability, and no statement of what is in scope. For a package that executes model-chosen tool calls and runs code in sandboxes, that absence is conspicuous.
• No CODE_OF_CONDUCT.md, which GitHub's community-standards check surfaces and contributors look for.
• README is 4.4K and opens on a code snippet. It does not say what agentdeck is for, who it is for, what it does not do, or how it relates to the Agents SDK and LangGraph it sits on. It is the first thing anyone reads.
• No examples directory. .agentdeck/ at the repo root is a test fixture that Compose happens to mount, not something a reader can learn from — see the cleanup: remove legacy, dead code, and redundant files (Wave 6 gate) #71 inventory, which flags exactly that ambiguity.
• Docs-site coverage is v1-shaped. docs/delivery/docs-site-plan.md has DS-1 open and nothing documents the v2 surfaces a 2.0.0 user actually meets: the event log, run control, the store backends, status/progress.

Proposed shape

Take them in that order — the license metadata is a one-line fix with the largest consequence, and the README rewrite is the largest job with the widest reach.

• pyproject.toml: license and license-files per current packaging metadata, matching the existing LICENSE exactly. Add the classifiers a package this size normally carries.
• SECURITY.md: where to report, expected response window, and what is in scope. Say plainly that a model-chosen tool call is trusted-by-design and that sandboxing is opt-in — those are the two things a reader will want to know before they ask.
• CODE_OF_CONDUCT.md: adopt Contributor Covenant rather than writing one.
• README: what it is, the smallest real example, what it deliberately does not do, and where the docs are. Link CONTRIBUTING.md rather than restating it.
• examples/: two decks a reader can copy — one chat agent with a tool, one workflow with an approval. They should be exercised by a test so they cannot rot, which is the mistake that let the install instructions pin v1.2.1 for months (docs: the install instructions pinned v1.2.1 on a 2.0.0b4 package #125).
• docs-site: a page each for the event log, run control, and choosing a store backend.

Notes

CONTRIBUTING.md is in good shape and already carries the docs-are-part-of-the-change rule; this issue should not duplicate it. The PR template and both issue templates exist.

The lesson from #125 applies to everything here: anything that states a version, a command or an install path must be exercised by a test or checked in the release preflight, or it rots silently. The release skill's preflight now greps docs-site/ for pinned versions; extend that habit rather than trusting review.

Related: #71 (the repo-root .agentdeck/ ambiguity), #125 (the rot this is meant to prevent), #129 (protocol surfaces, which will want the README to have said what agentdeck is first).

Done when

• python -m build produces a wheel whose metadata names the license, verified by reading the built metadata rather than the source.
• SECURITY.md and CODE_OF_CONDUCT.md exist and GitHub's community-standards checklist is complete.
• README answers what/who/why and does not open on code.
• examples/ has two runnable decks, each exercised by a test.
• docs-site documents the event log, run control and store selection.
• Every version string and install command in the repo is either tested or in the release preflight.