Task: Publish evidence cards for verified CI adoption scenarios

[lbliii]

Parent: #318
Blocked by: #320

Goal

Package each accepted comparison fixture into a concise, durable adoption asset for the documentation site, package landing surfaces, Marketplace listing, and maintainer outreach.

Required card structure

• The concrete user problem and source link.
• A runnable reproduction and pinned fixture revision.
• The incumbent’s best-practice configuration.
• Kida’s observable result, with exact command/output excerpt or screenshot.
• A capability/tradeoff table.
• “Kida does not solve” boundaries.
• Provenance for every timing or free-threading statement.
• A one-step next action: use the Action, customize a report, or run kida check.

Acceptance and proof

• Three cards are reviewed against the fixture results and contain no unsupported headline metric.
• Site/package copy preserves the current product hierarchy: server-side component system first; checked-before-render proof second; pure Python/no runtime dependencies next; free-threading is bounded engineering evidence.
• Markdown output, screenshots, and snippets are checked for GitHub/site readability and current syntax.
• Every changed source link and command resolves from a clean checkout.

Boundaries

• No generic “replace Jinja” message.
• No invented customer quote, adoption count, or claim of industry prevalence.
• No claim that type annotations statically validate arbitrary context objects.
• No security/isolation promise or benchmark extrapolation.

Stewards and collateral

• Stewards: docs, site, public/readme, examples, markdown, templates, action, github, benchmarks, analysis, cli, tests.
• Collateral: published site/docs, README/PyPI/Marketplace copy only when the exact evidence supports each surface; changelog classification at implementation time.
• No downstream pilot: documentation of existing behavior; external pilot evidence belongs to the separate pilot task.

Stop and ask

Stop before publishing to Marketplace, adding new public promises, or changing the release listing. Those actions require the owner-authorized tasks below.