Trust the package's own distribution name, and add the artefact smoke test

[n1ckyb]

The defect that forced 0.0.1 to be pulled from PyPI.

The package omitted its own distribution name from its first-party trust list, so all 78 bundled parsers were refused as untrusted third-party code and every invocation printed ~69 Failed to catalog parser plugin errors. Results were still correct, so the exit code said everything was fine.

No test in the repo could have caught it. In a source checkout the distribution resolves differently and the check passes. The bug exists only in an installed wheel, and nothing in CI ever installed one.

Also in this change:

• src/intentumdiff/__main__.py — python -m intentumdiff failed outright; nothing invoked it
• The error message pointed at docs.intentumdiff.dev, an unregistered domain. Now points at real documentation
• scripts/smoke_published_wheel.py — installs the artefact into a clean venv and does what a user does in their first five minutes: install, import, console script, python -m, a real diff, clean stderr, and every URL resolves

That last script is the durable part. It closes the gap this PR exists because of: CI proves the code builds; only this proves the artefact works.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[n1ckyb]

Do not merge yet — this fix exposes a deeper problem

CI: 20 failed, 2194 passed. The failures are caused by this change, and they are not
stale test data. The RC branch is green (the docs-only #11 passed the same suite on the same
base), so these are new.

Two representative failures:

test_certified_python_change_path_uses_rust_finalizer_not_python_engine
  AssertionError: assert 'rust_finalize_review_v1' == 'rust_finalized_v1'

test_intent_facts_are_sufficient[python-validator]
  facts['behavior_category'] = None, expected 'validator'
  Full facts: {'param_count': 1, 'returns': 'value', 'return_kind': None,
               'body': 'substantive', 'side_effects': None, ...}

What this means

Until now every parser was refused as untrusted, so every diff took the fallback path —
and that is the path the suite has been validating. Trusting the parsers moves execution onto
the certified path for the first time, and on that path the intent facts come back
less populated: behavior_category, return_kind and side_effects are all None
where the fallback produced real values.

So the 78 catalogue errors were not merely noise. They were routing every user away from the
certified path, and the certified path has a gap in fact derivation that no test could see,
because no test ever reached it.

That reframes 0.0.1: the suite was green because it was exercising the fallback. Fixing the
trust list is necessary but not sufficient — it makes the real path reachable, and the real
path is not yet correct.

What has to happen before this merges

• Establish why behavior_category, return_kind and side_effects are None on the
  certified path. Facts derivation lives in the Rust core, so this is very likely an
  engine gap rather than a binding one
• Decide whether rust_finalize_review_v1 is the correct finalizer for this path, or a
  routing mistake. If it is correct, that assertion is stale and should be updated —
  but only once we know, not to make the suite quiet
• Re-run and confirm all 20 pass for the right reason

Related

• Correct the diff header, and stop warning on every run #14 fails on exactly one test, test_a_successful_diff_logs_nothing_at_warning_or_above,
  because it is based on the RC branch which still has this bug. That test is doing its job:
  it reproduces the 0.0.1 defect as a hard failure. It goes green once this lands
• file command labels both sides with the NEW filename #12, Every run prints an OSV advisory warning to stderr #13 are unaffected and merge independently

[n1ckyb]

Closing as superseded — but not because this PR was unnecessary. It was carrying a fix the release branch needed, and the fact that it sat here behind a conflict is the more interesting part.

Measured against release/v0.0.2-rc today

File	vs RC
src/intentumdiff/__main__.py	identical blob — landed via dfbad9e (#16)
src/intentumdiff/plugins/registry.py	identical blob — same
README.md	differs — this PR's version runs (exit 0); the RC's was broken
scripts/smoke_published_wheel.py	differs — this PR has no README gate; the RC now does

The part worth recording

The RC's README.md had its triple quotes collapsed to single quotes, so the headline example died with SyntaxError: unterminated string literal at parse time — the first code a user copies, rendering on PyPI. That is 0.0.1 defect #4 recurring.

The correct README was in this PR the entire time. It was found and fixed again from scratch in #19, because a conflicting PR on the release branch is invisible to everything: CI does not run it, the release checklist does not read it, and nobody diffs an open PR against the branch it targets.

The likely mechanism is a bad conflict resolution putting a mangled README on the RC while the good copy stayed stranded here.

Why closing rather than rebasing

• Two of the four files are byte-identical to the RC — no content to land.
• The README fix is equivalent to what The README example doesn't run, and the gate tests a private copy of it #19 landed; both produce exit 0 and the documented output.
• This PR's smoke script is now behind the RC. Merging it would remove the gate that executes the README, which is the check that stops this recurring.

#19 carries both the repair and the gate.

Follow-up

The release skill now requires draining open PRs that target an RC — especially conflicting ones — before tagging, since this one proved a stranded PR can hold the fix for a defect that ships.