Correct the diff header, and stop warning on every run - #14
Merged
Conversation
Two defects that each produced a CORRECT diff and still made the tool look broken. Neither could fail a diff test, so neither was caught. 1. 'intentumdiff file a.py b.py' labelled both sides 'b.py', so the header said a file had been compared with itself — directly above the right answer. Source.get_content returns one filename because that is what language detection needs, and for a git diff one name genuinely covers both sides. FileSource is the exception and knew both names all along, so it now surfaces them via display_names(). 2. Every run wrote an OSV advisory warning to stderr naming an 'allow vulnerable' override. Nothing was actionable: first-party plugins ship inside the wheel and third-party ones stay blocked either way. It is now debug. The deliberate-override warning stays a warning, since disabling a safety check is worth saying, but fires once per process rather than once per plugin — there are 78 plugins. Also drops 'Scope: working tree' from diffs where no working tree exists; it was a renderer default printed for file, string and patch diffs alike, and is now shown only when a staging status is actually known. Fixes #12 Fixes #13 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This was referenced Aug 8, 2026
n1ckyb
added a commit
that referenced
this pull request
Aug 9, 2026
* fix: land the verified 0.0.1 fixes in the repo that publishes the wheel This repo publishes intentumdiff-python to PyPI, and it did not have the fixes for the defects that got 0.0.1 pulled. They were stranded in PR #15 (now conflicting) and #14. Two were missing outright: - src/intentumdiff/__main__.py — `python -m intentumdiff` failed in 0.0.1 because this file did not exist. It still did not exist here. - scripts/smoke_published_wheel.py — the release gate itself: installs the artefact into a clean venv and checks install, import, console script, `python -m`, a real diff, clean stderr, and that every URL resolves. The engine fixes, all verified against a green build in the experiments repo: - rust_core.py: canonicalise the distribution-qualified parser plugin id. The wheel publishes as intentumdiff-python while the import package is intentumdiff, so the certified parser arrived as 'intentumdiff-python:python:python' and failed an allowlist that only knew 'intentumdiff:python:python'. The certified batch path declined with "unsupported parser plugin" and fell through to routed finalize — Rust to Rust, so no gate fired and nothing looked wrong, while the certification and the facts only that path derives were silently absent. - registry.py: trust the package's own distribution name. THE 0.0.1 defect. - loader.py: the OSV advisory notice is debug, not warning. It fired on every ordinary run and put alarming text on stderr beside correct results. - _shared.py: `file a.py b.py` labelled both sides with the NEW filename, and claimed a "working tree" scope for diffs with no working tree. - sources/: a source that compares two differently named files now says so; get_content returns one filename because that is what language detection needs, and both sides inherited it. - core/models.py: facts_trace, populated only under INTENTUMDIFF_TRACE_FACTS. - live_server.py: the perceptual asset_diff op. - differ.py: display names applied at the boundary that knows both. Verified before syncing: Rust 266 passed, extension 260 passed, Python suite running. The experiments repo has no CI (Actions disabled on billing), so this repo's own CI is the gate — which is the point of syncing here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(build): resolve the core from the RC, not main CORE_REF was "main". But main only moves when a release is cut, so a consumer pinned to it cannot verify against an unreleased engine change — which is exactly what a release candidate exists to allow. That gap is not theoretical. The provenance tests in this PR assert facts_trace, added to the engine, and failed in CI while passing locally: CI was building an engine that predated the feature under test. The tests were right; the pin was wrong. Now follows release/v0.0.2-rc, and reads INTENTUMDIFF_CORE_REF so a one-off build can point elsewhere without editing the file. Tracking a branch does make the build unreproducible, so this becomes a TAG the moment intentumdiff-core cuts one. The comment says so where the next person will read it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * release: 0.0.2b1 PEP 440 spells the prerelease 0.0.2b1 — no hyphen, no dot — where Cargo and npm use 0.0.2-beta.1. Same release, three spellings, and the publish workflow asserts the tag matches this string exactly. Beta because 0.0.1 was published without anyone installing the artefact and using it. A version without a beta marker is a claim of stability, and that claim follows use rather than preceding it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test: derive the version instead of hardcoding it Three tests asserted the literal "0.0.1", so bumping to 0.0.2b1 failed them — for a reason that has nothing to do with what any of them checks. Two assert CLI BRANDING and one asserts IMPORT PURITY; none is about which version is current. A hardcoded version in a test is the same defect the release skill names for workflows: "derive the expected version, never a literal. A hardcoded version goes stale silently and fails at the very end of a release, blaming the artefact when the gate was wrong." They now read __version__. Importing it into the purity test is safe: that test's subject is a subprocess, so the parent's imports are not what it measures. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: n1ckyb <nicknuxton@icloud.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…header-and-stderr
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #12 and #13. Both produced a correct diff and still made the tool look broken, which is why no diff test caught either.
The header said a file was compared with itself
Source.get_content()returns one filename because that is what language detection needs, and for a git diff one name genuinely covers both sides — same path, two revisions.FileSourceis the exception: it knew both names and threw one away. It now surfaces them through a newdisplay_names()hook that defaults toNone("one name applies to both"), so no other source changes behaviour.Scopewas a renderer default printed forfile,stringandpatchdiffs alike. It now appears only when a staging status is actually known — which is the commit path, where it means something.Every run wrote a warning to stderr
Naming
INTENTUMDIFF_ALLOW_VULNERABLE_WASMTIME, beside correct results. Nothing was actionable: first-party plugins ship inside the wheel and third-party ones stay blocked either way. Now debug.The deliberate-override warning stays a warning — disabling a safety check is worth saying — but fires once per process rather than once per plugin load. There are 78 plugins.
Verified
stderr: empty. Five new tests, all passing, including one asserting a successful diff logs nothing at warning or above — the assertion that would have caught 0.0.1's 69 error lines.
🤖 Generated with Claude Code