The listing's MIT-0 next to the repository's Apache-2.0 was documented as a
drift to repair in the ClawHub listing itself. It is not repairable and not
drift: ClawHub's own client pins the platform skill license
(dist/schema/license.js sets PLATFORM_SKILL_LICENSE = "MIT-0", and the
version schema accepts only "MIT-0" or null), so every skill published there
is offered under MIT No Attribution. Publishing to ClawHub means offering
this skill on those terms in addition to Apache-2.0; the field is not
editable and the mismatch must not be read as drift.
pre-commit: 1) maintain.sh - exit 2 at the uv-secure gate, the three triaged
no-fix advisories in docs/development.md (rechecked 2026-09-09 against PyPI);
ruff check+format clean, pyright src/ 0 errors, 2368 passed 3 skipped run
separately; 2) /simplify - single pass, no fan-out available, prose-only
change, no findings; 3) docs sync - MIT-0/ClawHub grepped across docs/,
README, .claude/rules/, skills/: only release-and-distribution.md describes
the publish flow and stays accurate, the audit doc row is a dated snapshot,
no refs to update; 4) CLAUDE.md - audited against the structure rule, no
additions, revise-claude-md: no additions
pillow-heif's opener rewrites the EXIF orientation to 1 and stashes the real
value in info["original_orientation"], while libheif turns the raster on decode
exactly when the container declares an effective irot/imir transform. A camera
HEIC (stored raster, EXIF-only rotation) and a re-encoded one (rotation baked
as irot) both decode with Image.size matching the raster and the tag blanked,
so _read_display_tags dropped the turn for both (issue #105): a camera HEIC
went through erase and came out sideways with nothing on it saying so.
For HEIF the caller's orientation_applied claim is now ignored the way it is
for TIFF, and the container decides: isobmff.heif_transform_applied scans
meta/iprp/ipco for an irot with a non-zero angle or any imir, the orientation
comes from original_orientation, and a transform-bearing file drops the tag.
AVIF keeps the generic path: this plugin build neither blanks its tag nor
applies the transform there, and a camera-style AVIF's orientation stays
unreachable from Pillow (recorded in known-limitations).
Tests build the camera fixture without exiftool: a pillow-heif-written file
with its irot angle neutralized to the identity behaves like the reporter's
exiftool-built camera file. Mutation-checked in both directions: forcing the
detector either way fails exactly the tests whose property broke.
pre-commit: 1) maintain.sh - exit 2 at the uv-secure gate, the three triaged
no-fix advisories in docs/development.md (rechecked 2026-09-09: accelerate
1.15.0 and lightning 2.6.5 still carry no fix); ruff check+format clean,
pyright src/ 0 errors, 2368 passed 3 skipped run separately; 2) /simplify -
single pass, no fan-out available, one duplicate test helper inlined, no
other findings; 3) docs sync - heif_transform_applied, original_orientation,
irot, imir live only in module-internals.md and known-limitations.md, both
updated, no other refs; 4) CLAUDE.md - audited against the structure rule,
no additions; revise-claude-md: no CLAUDE.md changes
Both readers in the imread stack apply the TIFF orientation tag (cv2's
libtiff path under IMREAD_UNCHANGED too, and Pillow's TIFF plugin,
identically), so the visible path's blanket orientation_applied=False
carried the tag onto an already-turned raster. _read_display_tags now
ignores the explicit claim for TIFF and decides on the IFD's stored size,
which also keeps a hypothetical non-turning build correct: a stored-shape
raster still carries the tag. Guarded at the api seam, not just imwrite.
pre-commit: 1) maintain.sh - exit 2 at the uv-secure gate, the three
triaged no-fix advisories in docs/development.md (rechecked 2026-09-08);
ruff check+format clean, pyright src/ 0 errors, 2363 passed 3 skipped
run separately; 2) /simplify - single pass, no fan-out available, nothing
to fix (api-state plumbing rejected as disproportionate); 3) docs sync -
identifiers live only in docs/module-internals.md, updated, no other
refs; 4) CLAUDE.md - audited against the structure rule, no additions,
revise-claude-md: no additions
The previous commit recorded openclaw/clawhub#3643 as still open. It was
closed as completed at 17:29 UTC, minutes before that commit landed, so the
claim was already false when it was written: the state was read earlier in
the session and never re-read against the tracker.
The note now says the reporter closed it once 1.0.5 published, that nothing
upstream was confirmed fixed, and that this was the fifth report of the same
shape, so a future stalled submission gets a fresh report rather than an
assumption that the pipeline is repaired.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PrJja6MnncVhyWnmXPN4GM
docs/agent-skill.md still described the ClawHub surface as blocked: 1.0.3
and 1.0.4 stuck in pending.publication, with an instruction not to bump the
skill version until openclaw/clawhub#3643 resolved. The registry disagrees.
1.0.5, submitted by the clawhub job during the 0.39.0 release, is public:
clawhub search returns the row, and the public API reports tags.latest
1.0.5 with a single published version, which is also how the two earlier
submissions are shown never to have gone public. They were bypassed by the
next submission rather than recovered, and the pipeline issue stays open.
The note now says to read the catalog rather than the job log, since a
green job proves only a submission. It also records that the job fires on a
published release alone, so the 1.0.6 bump that landed after 0.39.0 reaches
ClawHub with the next release and must not be published by hand, and that
the listing carries MIT-0 where SKILL.md declares Apache-2.0, which the
publish command has no flag to set.
The awesome-openclaw entry loses its ClawHub prerequisite and stays
deferred on adoption alone: the listing reports no installs in 60 days.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PrJja6MnncVhyWnmXPN4GM
Round unsharp output in its existing buffer before uint8 conversion, preserving
constant images across OpenCV builds. Compare explicit stored WebP decodes.
Use host-absolute launcher fixtures and restrict Ubuntu Bash harnesses to POSIX.
Document the CI findings and the unresolved Dependabot Transformers/tokenizers
candidate conflict. Keep the existing model dependency constraints.
Repair image and metadata publication contracts, detection routing, research
artifact validation, release verification, and the published agent skill.
Refresh the dependency lock and reconcile documentation with verified behavior.
Add regression coverage and record the completed audit and corrected VideoSeal
measurements. Preserve the existing Accelerate and Lightning versions.
Validation: Ruff and Pyright pass; 2358 tests pass with 3 skipped. The maintenance
gate exits 2 on the documented Accelerate and Lightning security findings.
bytedance generator class (surgical six-head provider.pt), tc260 group
veto, stable-name receipt-gate.npz with the threshold inside the
artifact, snapshot-tolerant loader, weights pinned to revision
4c276376 (published via photo-classify-freeze-2026-09-07 release).
The Content Seal manifest named the production GPU worker in its provenance
column and in two row keys, several docstrings described their sources as user
uploads from the private corpus, and that corpus was called by the storage
product holding it. Each is now what a public reader can check: a pipeline and
strength, material that is not publication-cleared, and a private corpus. The
corpus test follows the renamed rows. Deployment and tier detail goes the same
way, since which backend each hosting tier can afford is a product decision,
not a library fact.
Twelve harnesses that need a cloud GPU account leave scripts/. The research
pages that cite their findings name them as harnesses kept outside this
repository and stop implying a reader can rerun them; the tracked inputs and
recorded verdicts remain the durable record, and the offline analysis step
stays here with its test. A development invariant states the rule so the next
harness is not added back.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Provider classes now name the GENERATOR that rendered the pixels, never
the brand. bytedance joins openai/google/muse-image as the shared
ByteDance lineage (Doubao and Jimeng render with one model family;
measured: separate heads cross-fire 32/22 at 3.5x mass, the surgical
union holds 83.9% on the frozen test cell while openai/google/meta/no_ai
stay byte-identical to run1). tc260 stops being a public value: its head
remains as the group veto for the rest of China's generators (without
it, 207/379 China test rows would be falsely named openai or
muse-image), and the loader tolerates provider snapshots that predate
bytedance. The receipt gate moves model-side: stable-name artifact
receipt-gate.npz carries its threshold, head and threshold always load
from one file, and the publish script stages the stable gate from the
weights source. Microsoft stays metadata-only: 144 of its 253 bank rows
name an OpenAI model as their C2PA softwareAgent and none names a
Microsoft renderer.
pre-commit: 1) maintain.sh - exit 1 (uv-secure: lightning 2.6.5 via
trustmark, PYSEC-2026-3624 no fix released; per docs/development.md the
core checks ran separately: ruff clean, pyright 0 errors, 2059 passed
3 skipped); 2) /simplify - single-pass four angles, clean, one noted
skip (gate-test npz staging duplication); 3) docs sync - grepped
bytedance/receipt-gate.npz/provider values over README, docs, skill,
rules: no stale references; 4) CLAUDE.md - improver: no changes,
revise: no additions (learnings live in canonical docs)
Three withheld zero-face carriers, all confirmed zero-face with the same YuNet
detector the adaptive arms gate on, first cleared at 0.045 / 0.06 / 0.11. The
zero-face operating point is 0.11 + (0.11 - 0.045) = 0.175, which the shipped
0.20 already covers, so that floor now rests on both content classes rather than
only the face-bearing carriers it was derived from.
The content split this cohort kept suggesting does not survive the measurement:
the two classes differ by 0.025 while the spread WITHIN each is 0.065 and
0.0625, so a face split would key on a variable explaining about a quarter of
the variation it leaves behind.
The methodological point is the durable half. The fixture-only view of zero-face
OpenAI content spans 0.015 of boundary; the real carriers span 0.065, four times
wider. A narrow fixture spread yields a small worst-clean-plus-one-spread margin
and a false impression of homogeneity, and that impression is what made a split
look justified twice.
Every verdict is the public verifier's separate SynthID line with Content
Credentials reported not detected alongside, over RGB-identical metadata-stripped
positive controls.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The ETI scoring program applies median blur and JPEG before decoding, so an
attack only wins if the watermark stays dead under ordinary handling. Our
removal paths are structural, so no driving question exists today; the note
records the hour-sized handling arm over removed-state artifacts as the
follow-up if removal durability under platform re-encoding ever becomes a
real question. Also records that participant attack code was never
published.
Verified against primary sources: the ETI Competition Data (NeurIPS 2024)
carries no license on the dataset card or in the evaluation repository and
stays off limits without organizer permission; the W-Bench dataset (ICLR
2025) is MIT while the VINE code is NTUITIVE non-commercial, so a profile
is buildable on our kernel without the VINE code. Also corrects two stale
internal notes: ETI attacked outputs are in the release, and W-Bench holds
10,000 instances, not 15k.
Extend the development-only benchmark family from images to audio and
video, and close four research directions from the watermark-landscape
map with local, revision-pinned evidence.
Benchmark schema: media_type audio and video rows, audioseal and
videoseal adapters with media-checked adapter binding, sample-domain
audio fidelity (SNR with unbounded_identical), frame-domain video
fidelity (mean PSNR, changed-frame fraction), and per-frame temporal
evidence in videoseal detection records. The report accepts all three
media types and carries SNR columns.
Audio: shared pinned AudioSeal oracle, synthetic and system-voice
speech cohorts with matched negatives, codec, noise, removed, and
forged arms, and the provenance experiment proving visual-only video
cleaning leaves the audio bitstream and watermark verdict invariant.
Video: TorchScript-only VideoSeal oracle (the pip package is unusable
on macOS arm64 and its loader resolves paths relative to cwd), video
cohort with crf/scale/fps attacks and four-state arms, temporal
evaluation measuring the crf decay curve, the frame-aggregation matrix
(computed locally after finding the TorchScript build ignores the
aggregation argument), and real provider clips as carriers.
Forgery: double-embedding study showing the last writer wins completely
under both oracles, scoped remover-trace probe, and the forged/
removed cohort arms encoding each scheme's correct expected verdict
(presence rule for audioseal, message rule for videoseal).
C2PA resolution: measured the five vendors' resolver contracts and the
C2PA 2.2 18.10.5 privacy gradient; product decision recorded that this
tool never resolves over the network. A registry guard pins the
published resolution-API set.
Gate: ruff and pyright src/ clean, 2114 passed / 3 skipped; maintain.sh
stops only on the known unfixed lightning 2.6.5 CVEs, pre-existing.
The clawhub job in distribute.yml compares the SKILL.md version with
the published one on every GitHub Release and submits an update when
they differ. Gated on the CLAWHUB_TOKEN secret: without it the job
skips with a notice, so the workflow lands safely before the secret
exists. A submitted update waits for ClawHub security scans, so a
green job means submitted, not listed.
The runtime's _weights_dir resolves the Hub snapshot offline through an
inline allow_patterns list, so a deployment that pre-caches the snapshot
for HF_HUB_OFFLINE=1 had to re-list the files by hand and silently
drifted when a release added one: the offline resolution then failed on
a four-fifths-present cache even though every missing piece had its own
fallback. Export the exact runtime request list as one public name, use
it in _weights_dir, and pin the seam with a test that captures the
snapshot_download call. Document the contract in photo-classify.md and
module-internals.md.
Victor Kuznetsov