0.4.4

Release 0.4.4: close reviewed Share Copy acceptance gaps (#143)

[skip ci]

0.4.3

Fixed

• Hovering a captured web page offers the element under your cursor again, not the page's own layout containers (#134)
• manifest.schema.json said its semantics stopped at format 0.6.0 while packs were already declaring 0.8.0

Added

• Every capture records how long it took to reach a usable editor — the pixels frozen, the pack durable, the editor painted — so a slow capture can be diagnosed instead of guessed at

Improved

• capture-e2e, the CI job that records a real capture and asserts on the pack, is now required rather than advisory. It went red inside a green run once already

---

The picking fix, in one paragraph. On a captured browser window, object picking had begun answering most hover points with a wrapper — a section, a nav, a div holding a chat log — instead of the thing you were pointing at. Measured on a real capture: 94.5% of hover points, with a median offered rectangle covering 32.22% of the frame where a healthy capture sits under 0.4%. The cause was a premise that quietly stopped being true: an exemption written for one element a human had explicitly picked started applying to every element of the whole page once a still began recording the entire visible document. Containers are now judged by the same rule as any other enumerated rectangle and are offered one rung back; an element you actually pick still wins. Nothing is lost — the page is still recorded in full, and a container remains reachable on the refinement rung.

The Windows installer is unsigned, so SmartScreen may warn on first run. SHA256SUMS.txt is published beside it for manual verification, and electron-updater verifies the sha512 in latest.yml.

Full detail: CHANGELOG.md

0.4.2

v0.4.2

release: prepare v0.4.2

0.4.1

qa: a replay whose rate nobody measured may decline to name its backend

CI caught this on the 0.4.1 candidate, which is what CI is for. The assertion
added with #135 read "a pack that carries a replay names its backend", reasoning
that the writer always knows which path it chose. It does. It has nowhere legal
to put it.

`backend` rides INSIDE `media.cadence`, and SPEC §5.3 makes `achieved_fps` and
`worst_stall_ms` REQUIRED members of it. `cadenceSummary()` therefore returns null
when nothing could be measured, because the same section forbids reporting a rate
nobody measured. A 1144 ms replay with two fragments on a hosted runner measured
no rate, wrote no cadence, and turned the job red over a perfectly good pack.

The comment beside the writer said exactly this — "a backend with no measured rate
to sit next to has nowhere legal to go" — and the assertion contradicted it. The
code was right and the check was wrong.

What survives is the invariant the writer really guarantees: every cadence it
builds carries a backend, unconditionally. So an absent cadence is accepted, and a
cadence WITHOUT a backend is rejected — which is the shape a regression would
actually produce, and the shape the old fixture was not testing. The fixture is
now two: one pack with no cadence at all, one with a cadence stripped of its
backend.

#62's fallback story keeps its machine-checkable end wherever a rate exists, which
is every capture long enough to measure one. The captures too short to measure a
rate were never the interesting case for "which path produced this".

Gate: PASSED. check:pack-assertions 46 passed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

0.4.0

release: 0.4.0

Two format versions in one app release, because they arrived together and neither
is useful without the reader knowing about it.

Pack format 0.7.0: media.displays is always present, so N screens stops being a
special case a reader can forget to ask about. 0.8.0: the timeline records mouse
and window movement — and never a keystroke, which is the part of this release
worth saying in a user's own language rather than as a technical footnote.

Version, ROADMAP baseline, the nine READMEs, the site in nine languages, the site
validator's release pins, docs/README.md and the handoff move together.

The v0.4.0 milestone is empty. Three issues that the format work made READABLE but
could not PROVE moved to a new milestone named for what they are actually blocked
on — #76 needs three real screens, #134 needs a picking threshold argued from
measurement, #135 needs a CI pack whose keyframes were rendered. None of them is
blocked on code, and filing them under a version number would have read as "not
done yet" rather than "waiting on evidence this desk cannot produce".

Public state in the handoff still names 0.3.5 — true until the release workflow
finishes, and filled in from the published artefacts afterwards.

Gate: PASSED, 0 failed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

0.3.5

release: 0.3.5

One process, captures that clean up after themselves, and a pin number the user
types. CHANGELOG gets a Removed section for the first time, because a watchdog
disappearing is something a user sees in Task Manager rather than an internal
tidy-up.

Version, ROADMAP baseline, the nine READMEs, the site in nine languages, the
site validator's release pins, docs/README.md and the handoff all move together.

docs/README.md was stale from before the 0.3.4 release — it still described
0.3.4 as unreleased work on a branch, at rc.33, with 0.3.3 as the public build.
The gate caught it, which is what the gate is for.

The Chrome extension is unchanged in 0.3.5, so its manifest stays at 0.3.4 and
frame-geometry-check keeps pinning that: a version bump the extension did not
earn would ask every browser to reload for nothing.

Public state in the handoff still names 0.3.4 — that is true until the release
workflow finishes, and it is filled in from the published artefacts afterwards.

Gate: PASSED, 0 failed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

0.3.4

v0.3.4

docs: the whole product says what it actually does, and 0.3.4 goes pu…

0.3.3

CapturePack 0.3.3

CapturePack 0.3.3 improves replay reliability, past-object picking,
multi-display capture and portable pack inspection.

Highlights

• Double-click viewer.html inside a generated CapturePack to inspect declared
  images, videos, annotations and plugin context fully offline.
• Reopen and past-frame paths preserve available Windows UI Automation and
  Chrome DOM evidence.
• Mixed-DPI, portrait, negative-origin and cross-monitor geometry share one
  display model across capture, editing, rendering and generated documents.
• Replay buffers and recorder ownership are bounded, with explicit health and
  cadence evidence instead of inferred success.
• Capture FPS is constrained to the supported 5–30 range.
• The Chrome extension now consumes expected native messaging disconnect errors
  while its bounded reconnect path recovers from transient host startup.

Known issue

Issue #89 remains open.
When startup calibration does not observe enough motion, context overlays can
lead encoded video by a display-specific amount. This release does not apply a
hard-coded offset: the pack records ambiguous timing evidence and keeps the
unmeasured alignment visible as a known limitation.

Integrity

The Windows build is currently unsigned, so SmartScreen may warn. The release
contains the installer, blockmap, updater metadata and SHA256SUMS.txt; the
release workflow publishes them only after local and downloaded bytes match.

CapturePack 0.3.3-rc.1 (Release Candidate)

CapturePack 0.3.3-rc.1

Public release candidate for direct testing. The current stable release remains
0.3.2, and this RC is not offered through the stable automatic-update channel.

What to test

• Rewind to an earlier frame and select several child controls in succession.
• Reopen a saved video or image pack and select the same objects again.
• Capture and pick objects across mixed-DPI and negative-origin monitors.
• Drag a still-image region across a monitor boundary and use full-screen
  capture across the complete virtual desktop.
• Confirm that a small image opens at native 1:1 and a larger image opens fitted
  with the whole capture visible.
• Watch CapturePack recording CPU while scrolling or using an application whose
  accessibility provider is slow.

Candidate fixes

• Preserves window, UI Automation and Chrome DOM object identity at past times
  and after reopening a pack.
• Uses physical display geometry for video, image and cross-monitor selection.
• Prioritizes foreground and changed UI Automation windows while keeping the
  long-running idle collection budget near 3%.
• Isolates a hanging or crashing accessibility provider by HWND so healthy
  applications continue to provide selectable objects.
• Replaces the landing-page demo with localized time-machine and still-context
  motion in all nine supported languages.

Verification

• 50/50 deterministic RC checks passed.
• Isolated Electron smoke test passed.
• Strict forensics on CapturePack_2026-07-30_092847 passed with no errors or
  warnings.
• Production dependency audit reported zero vulnerabilities.

Windows builds are currently unsigned, so SmartScreen may warn on first run.
If a test fails, keep the original CapturePack folder and report its path with
the exact frame, monitor and object that could not be selected.

0.3.2

v0.3.2

Make source contracts newline agnostic