hkblockchaintechnology
/

tiny-computer-agent

@@ -24,7 +24,7 @@ Python standard library.
 > **Status 0.3.0: it drives a real desktop — on Linux and on Windows.** Screen capture,
 > an OCR element index with real coordinates, a real mouse click, and a *verified*
-> outcome. **All 73 capabilities have a real screenshot** in the [capability gallery](#capability-gallery).
 > The loop can be driven from a [marimo console](#the-marimo-console) with a live preview, an
 > action log and pause / resume / step; elements can come from the
 > [accessibility tree](#what-the-machine-already-knows-the-accessibility-tree) instead of OCR;
@@ -271,6 +271,12 @@ The Windows claims in this card are not taken on faith. A full Windows guest was
 and the harness installed inside it, on a headless Linux host with **no KVM** — the same
 kind of sandbox the Linux runs above were produced in.
 **What was built.**
 ```
@@ -585,11 +591,11 @@ eleven tasks are a sample, not a survey.
 ## Capability gallery
-**68 capabilities, one screenshot each - and every one of the 141 public callables in the package (functions, methods, classes and protocols) appears in at least one of them**, together with 6 of its public constants.
 Nothing here is a mock-up. Each picture is produced by [`showcase.py`](showcase.py): a command or a call is run for real, and its actual output - or the real desktop it acted on - is what you see. The desktop shots are real screen captures on a real X server (Xvfb, 1280x800), including a real mouse click verified by the target application's own reaction.
-> **An honest note on the platform.** These were captured on Linux, because the sandbox that builds this card has no Windows: no KVM, no QEMU and no Windows image. The harness is OS-agnostic (pyautogui uses `SendInput` on Windows, and `GrabScreen` falls back to Pillow's `ImageGrab`), so these are the same code paths - but they are not Windows pixels. The Windows twins are generated by the same script in [`.github/workflows/live-desktop.yml`](.github/workflows/live-desktop.yml).
 Regenerate it with `python showcase.py` (`--list` to see the ids, `--only <id>` for a subset, `--card` to rewrite this section). It runs the calls for real, so a broken capability fails loudly instead of shipping a stale picture.
@@ -1248,7 +1254,9 @@ when no verifier is given.
 - [ ] Windows run of the *live desktop* test: the workflow is committed, but it needs a
       GitHub mirror with Actions enabled — Hugging Face does not run GitHub Actions
 - [ ] A **Windows** run of the gallery: the workflow builds it on `windows-latest` (job
-      `gallery-windows`), with the same GitHub-mirror caveat
 ## License

 > **Status 0.3.0: it drives a real desktop — on Linux and on Windows.** Screen capture,
 > an OCR element index with real coordinates, a real mouse click, and a *verified*
+> outcome. **All 74 capabilities have a real screenshot** in the [capability gallery](#capability-gallery) (Linux captures).
 > The loop can be driven from a [marimo console](#the-marimo-console) with a live preview, an
 > action log and pause / resume / step; elements can come from the
 > [accessibility tree](#what-the-machine-already-knows-the-accessibility-tree) instead of OCR;
 and the harness installed inside it, on a headless Linux host with **no KVM** — the same
 kind of sandbox the Linux runs above were produced in.
+> **Provenance.** The numbers below are quoted from that run, not re-measured here, and no
+> picture from it survives: the guest, its disk image and its screenshots went with the
+> container that had produced them. Everything above - the gallery, the live click, the
+> traces - is reproducible from this repository; the Windows results below are a record of
+> what that guest reported.
 **What was built.**
 ```
 ## Capability gallery
+**74 capabilities, one screenshot each - and every one of the 141 public callables in the package (functions, methods, classes and protocols) appears in at least one of them**, together with 6 of its public constants.
 Nothing here is a mock-up. Each picture is produced by [`showcase.py`](showcase.py): a command or a call is run for real, and its actual output - or the real desktop it acted on - is what you see. The desktop shots are real screen captures on a real X server (Xvfb, 1280x800), including a real mouse click verified by the target application's own reaction.
+> **An honest note on the platform.** These were captured on Linux, because the sandbox that builds this card has no Windows: no KVM, no QEMU and no Windows image. The harness is OS-agnostic (pyautogui uses `SendInput` on Windows, and `GrabScreen` falls back to Pillow's `ImageGrab`), so these are the same code paths - but they are not Windows pixels. There are no Windows pictures here, and that workflow does not by itself produce any: its `windows-latest` job does build the same gallery on real Windows pixels, but it uploads them as a CI **artifact** (`gallery-windows`) - nothing downloads it, re-prefixes the files `win-*`, or appends a section to this card, so an artifact is as far as they get. The Windows screenshots from the guest described [below](#verified-on-real-windows) were lost with the build container that produced them.
 Regenerate it with `python showcase.py` (`--list` to see the ids, `--only <id>` for a subset, `--card` to rewrite this section). It runs the calls for real, so a broken capability fails loudly instead of shipping a stale picture.
 - [ ] Windows run of the *live desktop* test: the workflow is committed, but it needs a
       GitHub mirror with Actions enabled — Hugging Face does not run GitHub Actions
 - [ ] A **Windows** run of the gallery: the workflow builds it on `windows-latest` (job
+      `gallery-windows`), with the same GitHub-mirror caveat - and when it runs, its
+      artifact still has to be imported into `gallery/` as `win-*` and spliced in here;
+      no step does that yet
 ## License