screengraft 0.42.0 → 0.43.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "screengraft",
-  "version": "0.42.0",
+  "version": "0.43.0",
   "description": "Put a UI screenshot or screen recording onto a photographed device screen with the perspective exactly right \u2014 a homography you confirm by hand, not a generative guess.",
   "keywords": [
     "mockup",

package/scripts/detect.py

@@ -635,7 +635,30 @@ def _finalize(candidates, img_area: float, refine: bool = True, img_shape=None,
     # project has never had the number. Off unless asked for, and it must not
     # change the answer: it observes the same lists the walk below uses.
     walked = {}
-    for cand in sorted(candidates, key=lambda c: c[0], reverse=True):
+    # Walk order: by score -- EXCEPT when the best-scoring candidate has no
+    # shape evidence at all (tier 0: sharp, unmeasurable, or inconsistent
+    # corners) while a tier-2 candidate exists in the same list. A tier-0
+    # winner cannot be corroborated and ends in an abstention or a refusal, so
+    # nothing is lost by looking past it; a tier-2 candidate has four corners
+    # agreeing on a radius, which on the labelled corpus has meant "on the
+    # screen" for every channel-accepted result. Deliberately NOT tier-first
+    # ordering of the whole list: that was tried on 11 Sep 2026 and broke three
+    # photographs, because a tier-2 WRONG candidate sits deeper in the list on
+    # each. This only moves when score alone would have handed the answer to a
+    # quad with nothing to say for itself.
+    def _tier_of(cand):
+        _score, quad, contour, _tag = cand
+        q = order_quad(refine_corners(contour, quad, rail_band)[0]) if refine else quad
+        return shape_tier({"corner_radius": measure_corner_radius(contour, q)})
+
+    order = sorted(candidates, key=lambda c: c[0], reverse=True)
+    if order and _tier_of(order[0]) == 0:
+        # Identity, not equality: candidates hold numpy arrays.
+        strong = [c for c in order if _tier_of(c) == 2]
+        if strong:
+            strong_ids = {id(c) for c in strong}
+            order = strong + [c for c in order if id(c) not in strong_ids]
+    for cand in order:
         # NOT necessarily `cand`: pick_innermost steps inward from it while a
         # comparably screen-like quad nests inside, so the quad that gets
         # validated -- and returned -- can belong to a different candidate.
@@ -927,6 +950,18 @@ def has_rounded_corners(result) -> bool:
     if float(cr["photo_px"]) <= MIN_ROUNDING_PX:
         return False
     per = [float(v) for v in cr["per_corner_px"]]
+    # ALL FOUR corners, not most of them. A per-corner estimate of exactly 0.0
+    # is the estimator saying "no arc here", and a rounded rectangle does not
+    # have corners with no arc. The spread test alone let [0, 0, 56, 56]
+    # through -- a quad rounded at two corners and square at the other two,
+    # a shape no screen has -- because its spread lands at exactly 2.00 and the
+    # comparison is <=. That quad shipped as a CONFIDENT answer 124% off
+    # (iPhone-8, 12 Sep 2026): the only confidently wrong result the labelled
+    # bench has ever produced. Categorical rather than a threshold: on the 14
+    # labelled photographs every on-screen quad this accepts has all four
+    # corners measured (smallest 1.6px); the wrong one had two at 0.0.
+    if min(per) <= 0.0:
+        return False
     r = float(cr["photo_px"])
     spread = (max(per) - min(per)) / max(r, 1e-6)
     return spread <= MAX_RADIUS_SPREAD

package/skills/inject-screenshot/SKILL.md

@@ -5,7 +5,7 @@ description: Injects a UI screenshot OR a screen recording onto a photographed d
 
 # Inject a screenshot onto a photographed device
 
-**What ships (v0.42):** a local browser UI (`scripts/ui.py`) that walks the designer through the whole job — pick the photo and the screen source, which may be an image **or a video** (recent Desktop/Downloads images, drag-drop, browse, path, or a **Figma frame link**), auto-detect the screen as a starting position — and when detection cannot tell which region is a screen, **Point at screen**: one click inside it and the detector uses that point — or, if this photograph has been fitted before, **the fit it was saved with comes back** as the starting position instead of a detection, recognised by the photo's own pixels so a rename or a drag-drop still match — and every save also writes a **portable `.fit.json` beside the mockup** that can be dropped back onto the page later, which is how a fit survives a re-export, another machine, or someone else's hands — then **match the four edges** (drag an edge's middle to slide it, near an end to pivot; corners still draggable) with canvas navigation that follows the usual conventions — **hold ⌘ and scroll to zoom to the pointer, hold space and drag to pan** — and a rectified strip loupe. The fit and the composite sit **side by side and always have** — the result pane re-renders as you drag, which is how a corner gets judged, so it is the layout rather than a mode you can switch off. Then an on-by-default realism pass that colour-matches the source to the photo's light, **Save** (or **Render**, for a video) into the project folder (`--out-dir`), and a **Send to Claude** button that reaches you through the plugin's own MCP server. The UI is a hand port of the project's Figma design file — dark only.
+**What ships (v0.43):** a local browser UI (`scripts/ui.py`) that walks the designer through the whole job — pick the photo and the screen source, which may be an image **or a video** (recent Desktop/Downloads images, drag-drop, browse, path, or a **Figma frame link**), auto-detect the screen as a starting position — and when detection cannot tell which region is a screen, **Point at screen**: one click inside it and the detector uses that point — or, if this photograph has been fitted before, **the fit it was saved with comes back** as the starting position instead of a detection, recognised by the photo's own pixels so a rename or a drag-drop still match — and every save also writes a **portable `.fit.json` beside the mockup** that can be dropped back onto the page later, which is how a fit survives a re-export, another machine, or someone else's hands — then **match the four edges** (drag an edge's middle to slide it, near an end to pivot; corners still draggable) with canvas navigation that follows the usual conventions — **hold ⌘ and scroll to zoom to the pointer, hold space and drag to pan** — and a rectified strip loupe. The fit and the composite sit **side by side and always have** — the result pane re-renders as you drag, which is how a corner gets judged, so it is the layout rather than a mode you can switch off. Then an on-by-default realism pass that colour-matches the source to the photo's light, **Save** (or **Render**, for a video) into the project folder (`--out-dir`), and a **Send to Claude** button that reaches you through the plugin's own MCP server. The UI is a hand port of the project's Figma design file — dark only.
 
 The geometry is exact (`warp.py`); the detection is advisory (`detect.py`) and the human corrects it. **When a detection is wrong and you want to know why**, ask for the candidate list: `POST /api/detect {"trace": true}` writes `<session>/candidates.json`, or run `python3 scripts/detect.py --photo P --out-corners /tmp/c.json --trace /tmp/t.json` (add `--click X,Y`). Every candidate quad is in there with its score and whether it was accepted, rejected, never reached, or filtered out by the click — which is what separates "the screen was never proposed" from "it was proposed and something else won".