0.6.0 is not fit to publish: README documents an editable install and two APIs that do not exist

[fsecada01]

Audited the 0.6.0 wheel the way a stranger would: built it, installed it into a clean venv, and checked every documented import against the installed package rather than the source tree. Four things a first-time consumer hits, plus three metadata gaps.

Found while preparing #47 / #48. None of these are regressions — they have been true for a while and only become visible the moment the package is installable from PyPI, because the README is the PyPI landing page.

1. The README is written for someone who cloned the repo

Every install instruction is an editable install from a checkout:

uv pip install -e ".[fastapi]"
pip install -e ".[all]"

There is no pip install component-framework[fastapi] anywhere in the file, and the Installation section opens with "Not on PyPI yet — install from source", which becomes false the moment 0.6.0 uploads. The one instruction a PyPI visitor needs is the one that is missing.

2. Two documented imports do not exist

Checked against the clean install:

Where	Documented	Reality
README.md	from component_framework.core.composition import SlotComponent, CompositeComponent	Neither name exists. composition exports compose and SlotRenderer
docs/LOCKED_FIELDS.md	from component_framework import Component, registry	The top-level __init__ exports only CorruptStateError and StateSigner; both live in component_framework.core

The README one is worse than a wrong name — the whole example is invented. It subclasses SlotComponent/CompositeComponent and sets components = {"card": Card, ...}, an attribute nothing reads. The real API is a Component with a slots ClassVar, filled via fill_slot() or assembled with compose().

3. component_framework.testing needs pytest, which nothing declares

testing.py imports pytest at module scope. pytest appears only in dev-base, so a consumer who runs pip install component-framework[fastapi] and follows the README's

from component_framework.testing import ComponentTestCase

gets ModuleNotFoundError: No module named 'pytest'. The dependency is legitimate — the module ships pytest fixtures — but it should be declared as an extra rather than left to be discovered.

4. No py.typed

The codebase is type-checked in CI with ty, and the package even ships component-client.d.ts so TypeScript consumers get types for the client JS. But there is no PEP 561 marker, so Python consumers running mypy or pyright see the entire package as untyped and every symbol as Any. The types exist; they just are not advertised.

5. Classifier set is thin

Seven classifiers, missing License :: OSI Approved :: MIT License (what PyPI's sidebar reads) and any Framework :: / Topic :: entries. cf-ui ships thirteen.

Why these survived

There is no test that reads the docs. cf-ui has tests/unit/test_docs_samples.py, written after ComponentCatalog and <CfCard> sat in its README for two releases — it parses every fenced block, resolves every documented import against the real package, and fails the build. Porting it is the part that stops the next one, and it is the only reason findings 2 and 3 above were found by a tool rather than by a user.

Acceptance criteria

• README's Installation section leads with pip install component-framework[extra]; the "Not on PyPI yet" claim is gone; editable install is kept but demoted to a contributor note
• README's composition example uses the API that exists, and renders
• docs/LOCKED_FIELDS.md imports resolve
• A testing extra declares pytest, and the README says so where it documents ComponentTestCase
• src/component_framework/py.typed ships in the wheel
• Classifiers include the license, and the frameworks the adapters target
• A docs-sample guard ported from cf-ui: every fenced python block parses, and every from component_framework… import … names something that exists
• The guard is proven non-vacuous — it must go red against the current README

Not in scope

The 22 relative links in the README resolve on GitHub and 404 on PyPI. Real, but the Documentation project URL points at the live docs site, so a PyPI visitor is one click from working links. Leaving it.