[andife]

Summary: Include the field registry, HTML templates, and static assets as setuptools package data so installed wheels remain usable. Testing: uv build succeeds; the built wheel contains the registry, templates, CSS, JavaScript, and images.

[drk-ram]

Verified at head d113d79f70b183dccbcdac40622827efcfa050d4. The change is correct and minimal. I have a few non-blocking follow-ups below.

What I tested (Windows, Python 3.11, setuptools via pip wheel). I built the wheel from a clean tree for main (45851cb) and for this head, deleting build/ and *.egg-info between the two builds (a leftover build/lib otherwise masks the difference):

• main: the wheel contains only .py files. There is no src/models/field_registry.json, no src/templates/** and no src/static/**.
• This PR: the wheel contains src/models/field_registry.json, all five templates including includes/header.html and includes/footer.html, static/css/style.css, static/js/script.js and both images. python -m build --sdist also contains all of them.

I then installed the PR wheel into a fresh venv with --no-deps and ran Python from an unrelated directory, so the checkout could not shadow it: TEMPLATES_DIR exists and lists all templates, the registry sits next to models/registry.py's auto-detect location, and the static tree is present in site-packages/src/static. Since registry.py resolves field_registry.json from __file__, an installed main wheel fails at registry load, which the release workflow (wheel + sdist on every v* tag) would have shipped. This fixes it.

Follow-ups (not blocking this PR):

1. The web app still will not serve its static assets from an installed wheel. src/main.py:80-81 does os.makedirs("src/static", exist_ok=True) and StaticFiles(directory="src/static"), both relative to the current directory. I replayed those two lines from a directory outside any checkout against the installed wheel: it creates an empty src/static in the working directory and GET /static/css/style.css returns 404. Using BASE_DIR / "static" from config.py would let the packaged files be used. The CLI path (cli_controller.py) already resolves static relative to __file__, so it is fine.
2. Tool version in generated output. config.get_project_metadata() reads BASE_DIR.parent / "pyproject.toml", which is site-packages/pyproject.toml when installed, so it falls back to the hard-coded "1.0.2". It is correct today but will drift after the next version bump. importlib.metadata.version("owasp-aibom-generator") is the installed-distribution answer, and the version is stamped into the AIBOMs this tool emits.
3. A regression guard. CI installs with pip install -e ".[dev]", which cannot see missing package data. A small step or test that builds the wheel and asserts the registry, templates and static files are present would stop this returning.
4. The top-level package is named src, which installs as site-packages/src. That is pre-existing and not for this PR, but it is a collision risk worth a separate issue.

I did not run the full test suite, since the diff is limited to packaging metadata and the dependency set (torch, transformers) is large. The verification above is of the built artifacts. Approving.

Provenance note, as this tool's own output is an AIBOM: a release that ships the registry file as package data should also record its digest in the release SBOM. The existing release workflow already records artifact hashes, so a follow-up is easy.