@howaboua/pi-pet 0.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +16 -0
- package/LICENSE +21 -0
- package/README.md +92 -0
- package/SECURITY.md +24 -0
- package/authoring/PET-GUIDE.md +65 -0
- package/authoring/hatch/HATCH-GUIDE.md +136 -0
- package/authoring/hatch/LICENSE.txt +201 -0
- package/authoring/hatch/NOTICE.md +5 -0
- package/authoring/hatch/pyproject.toml +8 -0
- package/authoring/hatch/references/animation-rows.md +29 -0
- package/authoring/hatch/references/final-assembly.md +67 -0
- package/authoring/hatch/references/look-directions.md +35 -0
- package/authoring/hatch/references/pet-contract.md +40 -0
- package/authoring/hatch/references/qa-rubric.md +34 -0
- package/authoring/hatch/references/reviewer-protocol.md +72 -0
- package/authoring/hatch/references/standard-assembly.md +21 -0
- package/authoring/hatch/references/visual-generation.md +59 -0
- package/authoring/hatch/scripts/approve_cardinals.py +110 -0
- package/authoring/hatch/scripts/assemble_extended_atlas.py +684 -0
- package/authoring/hatch/scripts/combine_direction_blind_verdicts.py +59 -0
- package/authoring/hatch/scripts/compose_atlas.py +171 -0
- package/authoring/hatch/scripts/compose_cardinal_anchor_strip.py +45 -0
- package/authoring/hatch/scripts/derive_running_left_from_running_right.py +164 -0
- package/authoring/hatch/scripts/despill_chroma_edges.py +312 -0
- package/authoring/hatch/scripts/extract_cardinal_anchors.py +153 -0
- package/authoring/hatch/scripts/extract_strip_frames.py +409 -0
- package/authoring/hatch/scripts/inspect_frames.py +278 -0
- package/authoring/hatch/scripts/make_contact_sheet.py +116 -0
- package/authoring/hatch/scripts/make_direction_blind_qa_sheet.py +179 -0
- package/authoring/hatch/scripts/make_direction_qa_sheet.py +172 -0
- package/authoring/hatch/scripts/measure_direction_continuity.py +201 -0
- package/authoring/hatch/scripts/prepare_pet_run.py +1207 -0
- package/authoring/hatch/scripts/render_animation_previews.py +80 -0
- package/authoring/hatch/scripts/validate_atlas.py +299 -0
- package/authoring/hatch/scripts/validate_direction_blind_verdicts.py +100 -0
- package/authoring/hatch/uv.lock +99 -0
- package/authoring/references/import-existing-pet.md +47 -0
- package/authoring/references/pet-format.md +88 -0
- package/changelog.ts +327 -0
- package/deploy/pi-pet-hyprland.conf +10 -0
- package/desktop/build.mjs +194 -0
- package/desktop/package-lock.json +887 -0
- package/desktop/package.json +16 -0
- package/dist/authoring/prepare.mjs +3 -0
- package/dist/authoring/rebuild.mjs +4 -0
- package/dist/authoring/validate.mjs +2 -0
- package/dist/desktop/main.mjs +5 -0
- package/dist/desktop/preload.cjs +1 -0
- package/dist/web/app.js +1 -0
- package/dist/web/catalog.json +1 -0
- package/dist/web/index.html +100 -0
- package/dist/web/manifest.webmanifest +16 -0
- package/dist/web/pet-icon.svg +6 -0
- package/dist/web/spritesheet.webp +0 -0
- package/dist/web/styles.css +592 -0
- package/docs/architecture.md +41 -0
- package/docs/pi-pet.png +0 -0
- package/docs/research.md +17 -0
- package/extensions/desktop-command.ts +249 -0
- package/extensions/desktop-config.ts +152 -0
- package/extensions/desktop-launcher.ts +380 -0
- package/extensions/gippity.ts +24 -0
- package/extensions/index.ts +110 -0
- package/extensions/remote-app.ts +61 -0
- package/package.json +101 -0
- package/pets/clawa/PET.md +27 -0
- package/pets/clawa/pet.json +7 -0
- package/pets/clawa/spritesheet.webp +0 -0
- package/pets/clawa/validation.json +808 -0
- package/src/desktop/attention.ts +87 -0
- package/src/desktop/bridge.ts +31 -0
- package/src/desktop/config.ts +145 -0
- package/src/desktop/cursor-provider.ts +150 -0
- package/src/desktop/main.ts +459 -0
- package/src/desktop/preload.ts +19 -0
- package/src/pet-image-size.ts +72 -0
- package/src/pet-loader.ts +278 -0
- package/src/pet-storage.ts +240 -0
- package/src/protocol/index.ts +81 -0
package/CHANGELOG.md
ADDED
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
# @howaboua/pi-pet
|
|
2
|
+
|
|
3
|
+
## 0.1.1
|
|
4
|
+
|
|
5
|
+
### Changes
|
|
6
|
+
|
|
7
|
+
- [#304](https://github.com/IgorWarzocha/howaboua-pi-stuff/pull/304) [`4b4e42f`](https://github.com/IgorWarzocha/howaboua-pi-stuff/commit/4b4e42f7659e42854ec81cb502bf69a48422d9eb) Thanks [@IgorWarzocha](https://github.com/IgorWarzocha)! - Run Pi Pet as a first-class GipPity companion.
|
|
8
|
+
|
|
9
|
+
- Meet Clawa through the browser, voice, desktop dictation, a transparent desktop window, or the headless pet-state feed.
|
|
10
|
+
- Import compatible Codex and ChatGPT pets or author new pets through free-form `/pet` requests.
|
|
11
|
+
- Keep authored pets and generated displays in durable Pi agent storage, with optional per-repository pet selection.
|
|
12
|
+
- Attach the local device directly or remote devices through Pi-owned SSH sessions, with each folder remembering where its sessions appear.
|
|
13
|
+
- Get exact install and reload guidance when GipPity Control is missing or outdated.
|
|
14
|
+
|
|
15
|
+
- Updated dependencies [[`4b4e42f`](https://github.com/IgorWarzocha/howaboua-pi-stuff/commit/4b4e42f7659e42854ec81cb502bf69a48422d9eb)]:
|
|
16
|
+
- @howaboua/pi-gippity-control@0.0.13
|
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Igor Warzocha
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
ADDED
|
@@ -0,0 +1,92 @@
|
|
|
1
|
+
# Pi Pet
|
|
2
|
+
|
|
3
|
+
Pi Pet turns [GipPity Control](../pi-gippity-control) into an animated companion. Its bundled Clawa miniapp receives Pi activity, prompts, final replies, and realtime voice through GipPity Remote's existing browser SDK; Pi Pet contributes only pet rendering, reactions, assets, and an optional transparent Electron shell.
|
|
4
|
+
|
|
5
|
+

|
|
6
|
+
|
|
7
|
+
## Install
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
pi install npm:@howaboua/pi-gippity-control
|
|
11
|
+
pi install npm:@howaboua/pi-pet
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
Run `/gippity server` or its configured shortcut. With Pi Pet loaded, GipPity serves Clawa at `/_gippity/apps/pi-pet/` on every announced server URL. GipPity's bundled or explicitly configured main remote UI remains at `/`.
|
|
15
|
+
|
|
16
|
+
Open `<gippity-url>/_gippity/apps/pi-pet/` and accept GipPity's local certificate. The same Clawa app provides:
|
|
17
|
+
|
|
18
|
+
- working, waiting, failure, and settled animation from Pi events;
|
|
19
|
+
- synchronized text prompts through `GippityRemote.send()`;
|
|
20
|
+
- realtime conversation through `GippityRemote.audio`;
|
|
21
|
+
- bounded final-reply bubbles;
|
|
22
|
+
- local action previews and sixteen pointer-look directions.
|
|
23
|
+
|
|
24
|
+
`pet_show` is the only model tool. It triggers an intentional named reaction; routine activity animates automatically and GipPity already owns speech and final text.
|
|
25
|
+
|
|
26
|
+
Electron is optional. With no attached device, Pi Pet still publishes its versioned `{ pet, revision, action, note? }` state through GipPity alongside the session activity and tool events used by any browser renderer.
|
|
27
|
+
|
|
28
|
+
## Transparent desktop pet
|
|
29
|
+
|
|
30
|
+
The Electron shell loads the same GipPity-hosted app in a transparent, frameless, always-on-top window. It adds local cursor tracking, size, quiet mode, and snooze without another agent runtime or remote protocol.
|
|
31
|
+
|
|
32
|
+
Attach the device running Pi directly:
|
|
33
|
+
|
|
34
|
+
```text
|
|
35
|
+
/pet attach local
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
For another device, give it an SSH alias and confirm key-based access once outside Pi:
|
|
39
|
+
|
|
40
|
+
```bash
|
|
41
|
+
ssh desktop true
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
The remote device needs npm and Node 22 or newer; runtime extraction uses PowerShell on Windows and standard `unzip` on macOS/Linux. Attach it from Pi:
|
|
45
|
+
|
|
46
|
+
```text
|
|
47
|
+
/pet attach desktop
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
Pi Pet starts GipPity for the active Pi session and uses its saved LAN settings unless `/pet attach <device> <gippity-url>` supplies an override. Local attachment runs the Pi-owned bootstrap directly; remote attachment sends it through SSH. Both keep the desktop source and build at `~/.pi/agent/pi-pet` on that device. On connection Pi Pet compares the loaded package version and source digest with the recorded build, runs the copy, `npm install`, and `npm run build` steps only when they differ, then starts Electron. Pi or Clawa exiting stops Electron and GipPity but does not discard the build. It creates no application installation, login item, or background service.
|
|
51
|
+
|
|
52
|
+
The global registry at `<pi-agent-directory>/pi-pet.json`, normally `~/.pi/agent/pi-pet.json`, retains reusable local and SSH device definitions. The current folder's `.pi/pi-pet.json` selects which devices receive that folder's Pi sessions. Later sessions opened in the same folder start only those devices automatically. Inspect them with `/pet status`, relaunch them with `/pet restart`, or remove one from the folder with `/pet detach desktop`. SSH options, keys, proxies, and host routing stay in `~/.ssh/config`.
|
|
53
|
+
|
|
54
|
+
```json
|
|
55
|
+
{
|
|
56
|
+
"schemaVersion": 1,
|
|
57
|
+
"devices": {
|
|
58
|
+
"local": { "kind": "local" },
|
|
59
|
+
"desktop": { "kind": "ssh", "target": "desktop" }
|
|
60
|
+
},
|
|
61
|
+
"defaultDevices": []
|
|
62
|
+
}
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
If attachment or a build fails, Pi reports the failing phase and error. Ask Pi to diagnose and repair `~/.pi/agent/pi-pet` on that device; no application reinstall or directory reset is normally needed.
|
|
66
|
+
|
|
67
|
+
Electron accepts GipPity's self-signed certificate only for the configured origin. The source-only `desktop/` package is also directly runnable with `npm install`, `npm run build`, and `npm start` from a source checkout.
|
|
68
|
+
|
|
69
|
+
## Pet authoring
|
|
70
|
+
|
|
71
|
+
Authoring guides are loaded only when requested rather than exposed as permanent skills. Pass a natural-language request to the same routed command:
|
|
72
|
+
|
|
73
|
+
```text
|
|
74
|
+
/pet add a catching-mouse animation
|
|
75
|
+
/pet hatch a fluorescent office ferret
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
Pi Pet resolves `authoring/PET-GUIDE.md` from its own source or npm installation and asks Pi to follow it. That guide routes one-action work or full character hatching into the bundled references, deterministic atlas tooling, and visual review process.
|
|
79
|
+
|
|
80
|
+
Pi resolves its installed package from the guide path and uses its npm/Node authoring commands without requiring Bun or a monorepo checkout. Bundled pets are templates: the first edit copies one to `~/.pi/agent/pi-pet/pets/`, authoring evidence stays under `~/.pi/agent/pi-pet/runs/`, and generated miniapp assets stay under `~/.pi/agent/pi-pet/web/`. Package updates therefore do not overwrite user pets.
|
|
81
|
+
|
|
82
|
+
A repository can select any generated durable pet and its devices without duplicating assets in `.pi/pi-pet.json`:
|
|
83
|
+
|
|
84
|
+
```json
|
|
85
|
+
{ "schemaVersion": 1, "pet": "office-ferret", "devices": ["local", "desktop"] }
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
Repository pet selection overrides the global default; otherwise Pi Pet uses the global selection and then bundled Clawa. Repository devices override the registry's defaults. `/pet attach` and `/pet detach` maintain the current folder's device list without changing its pet selection.
|
|
89
|
+
|
|
90
|
+
Run `/reload` after rebuilding to select the authored pet and refresh attached devices. Pet packages remain inert JSON and bounded PNG/WebP files; they cannot supply scripts, HTML, URLs, or commands.
|
|
91
|
+
|
|
92
|
+
See [`docs/architecture.md`](docs/architecture.md), [`SECURITY.md`](SECURITY.md), and [`docs/research.md`](docs/research.md).
|
package/SECURITY.md
ADDED
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# Security model
|
|
2
|
+
|
|
3
|
+
Pi Pet adds no listener, credential store, prompt endpoint, or remote session ownership. GipPity Control owns those boundaries.
|
|
4
|
+
|
|
5
|
+
## Miniapp
|
|
6
|
+
|
|
7
|
+
- GipPity confines static files to Pi Pet's registered realpath and reserves its SDK/API routes.
|
|
8
|
+
- Browser prompts and voice use the hosted `GippityRemote` client rather than a pet-specific transport.
|
|
9
|
+
- Custom reaction state is normalized and bounded by GipPity before browser delivery.
|
|
10
|
+
- Pet manifests are strict inert JSON. Assets are bounded regular PNG/WebP files; traversal, escaping symlinks, excessive decoded size, and out-of-frame geometry fail during builds.
|
|
11
|
+
- Authored pets stay under the Pi agent directory and reach the generated web root only after validation. Package updates refresh executable web-shell files without overwriting user pet sources or run evidence. Invalid durable state reports a warning and falls back to bundled Clawa.
|
|
12
|
+
|
|
13
|
+
## Electron
|
|
14
|
+
|
|
15
|
+
- Remote devices are reached only through the user's existing SSH authentication and host configuration. Pi Pet passes a bounded Node bootstrap over SSH stdin; SSH targets cannot contain command options. The same bootstrap runs as a direct child on the device running Pi.
|
|
16
|
+
- The extension copies a fixed, bounded set of desktop source files from its own installed package into `~/.pi/agent/pi-pet` on the device. It records the package version and source digest only after a successful npm build, reuses matching builds, and leaves the directory in place when Electron exits. An owner heartbeat closes Electron when its local or SSH channel ends. It creates no login item, service, or application installation.
|
|
17
|
+
- Dependency lifecycle scripts stay disabled. The npm build downloads the pinned Electron package's official current-platform archive and verifies the checksum bundled with that exact package before extraction. npm and Electron download caches remain governed by those tools.
|
|
18
|
+
- The configured GipPity URL must be a credential-free HTTPS origin.
|
|
19
|
+
- GipPity's self-signed certificate is accepted only for that exact configured origin and only for an unknown-authority error.
|
|
20
|
+
- Chromium sandboxing, context isolation, and web security remain enabled; Node integration is disabled.
|
|
21
|
+
- Navigation stays within the configured origin. New windows and permission requests fail closed.
|
|
22
|
+
- The preload bridge carries only validated cursor positions.
|
|
23
|
+
|
|
24
|
+
GipPity's trusted-LAN policy remains authoritative. Do not expose its server to an untrusted network or public reverse proxy.
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
# Pi Pet guide
|
|
2
|
+
|
|
3
|
+
This guide is the on-demand entry point for `/pet <request>`. Resolve every relative path from this file. Its installed package owns bundled templates and tools; durable user pets and authoring runs live under `<pi-agent-directory>/pi-pet/`, normally `~/.pi/agent/pi-pet/`.
|
|
4
|
+
|
|
5
|
+
## Route the request
|
|
6
|
+
|
|
7
|
+
- To import an existing Codex or ChatGPT pet package, read `references/import-existing-pet.md` and follow it instead.
|
|
8
|
+
- For live reactions, action catalogs, one additional animation, or repair of one existing action, continue below.
|
|
9
|
+
- For a complete new character, full atlas repair, nine standard animations, or sixteen look directions, read `hatch/HATCH-GUIDE.md` and follow it instead.
|
|
10
|
+
- To select a pet for the current repository, ensure that durable pet has been rebuilt, write the repository config described below, then tell the user to run `/reload`.
|
|
11
|
+
- Separate pet data from renderer behavior. An animation such as `catching-mouse` can be authored as inert data; automatically triggering it near a pointer requires a separate renderer change.
|
|
12
|
+
|
|
13
|
+
## Repository selection
|
|
14
|
+
|
|
15
|
+
The project Pi config directory is normally `.pi/`. Write or update `pi-pet.json` there:
|
|
16
|
+
|
|
17
|
+
```json
|
|
18
|
+
{ "schemaVersion": 1, "pet": "<pet-id>" }
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
This selects an existing durable pet without copying assets into the repository. Preserve an existing `devices` array exactly when changing only the pet; `/pet attach` and `/pet detach` own device selection. Repository selection overrides the global default; a missing repository selection uses the global default, then bundled Clawa. Do not claim success until `<pi-agent-directory>/pi-pet/web/<pet-id>/catalog.json` exists; if needed, rebuild that pet first.
|
|
22
|
+
|
|
23
|
+
## Live control
|
|
24
|
+
|
|
25
|
+
1. Use `pet_show` only when the reaction carries useful task state or personality; lifecycle states already update automatically.
|
|
26
|
+
2. Read the active pet's `PET.md` and manifests before choosing an unfamiliar action.
|
|
27
|
+
3. Unknown actions are a data-authoring task. Do not guess aliases repeatedly.
|
|
28
|
+
|
|
29
|
+
The bundled actions are `idle`, `running-right`, `running-left`, `waving`, `jumping`, `failed`, `waiting`, `running`, and `review`. Semantic aliases include `active→running`, `working→running`, `thinking→running`, `settled→review`, `success→jumping`, `error→failed`, and `hello→waving`. Sixteen pointer-direction poses are renderer-owned and are not agent actions.
|
|
30
|
+
|
|
31
|
+
## Extend a pet
|
|
32
|
+
|
|
33
|
+
Read `references/pet-format.md`, then:
|
|
34
|
+
|
|
35
|
+
1. Resolve the installed package from this guide's absolute path and use it as command working directory. If the repository config selects a pet, run `npm run pet:prepare -- <that-id>`; otherwise run `npm run pet:prepare` or pass an explicit ID. It copies a bundled template only when no durable user pet exists and prints the user pet and run paths. Read that pet's `PET.md`, `pet.json`, and optional `pet.pi.json`. For a complete new character, switch to `hatch/HATCH-GUIDE.md`.
|
|
36
|
+
2. Preserve character identity and every passing action. Prefer a separate bounded PNG/WebP atlas plus a `pet.pi.json` entry for one new action.
|
|
37
|
+
3. Define frame coordinates and durations explicitly. Names use lowercase letters, numbers, dots, underscores, or hyphens; `list` is reserved for action discovery.
|
|
38
|
+
4. Follow **Rebuild and load** below. The build validates manifests, traversal, assets, decoded dimensions, and frame geometry before producing the GipPity miniapp.
|
|
39
|
+
5. Inspect the animation at actual pet scale. Reject clipping, identity drift, static loops, frame popping, opaque backgrounds, and colored alpha fringe.
|
|
40
|
+
6. Update `PET.md` with personality, action semantics, and provenance, then exercise the action with `pet_show` after the user reloads Pi.
|
|
41
|
+
|
|
42
|
+
## Rebuild and load
|
|
43
|
+
|
|
44
|
+
The `/pet` prompt gives this guide's absolute installed path. Resolve the package root exactly two directories up from that path (`<package>/authoring/PET-GUIDE.md` → `<package>`), use it as the command working directory, and do not assume the current directory is a checkout or monorepo. After changing the durable user pet printed by `pet:prepare`, run there:
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
npm run pet:validate -- <absolute-user-pet-directory>
|
|
48
|
+
npm run pet:rebuild -- <pet-id>
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
The rebuild writes the generated miniapp under the durable Pi Pet directory and makes that pet the global default; it never modifies the npm package. A repository selection still takes precedence. The running extension keeps its catalog in memory, so after a successful rebuild tell the user to run `/reload`; slash commands are user actions. Reloading Pi resolves the repository, global, then bundled selection and restarts the folder's configured Electron devices. A separately opened browser window may also need a page refresh. Only then exercise new or repaired actions with `pet_show`.
|
|
52
|
+
|
|
53
|
+
## Boundaries
|
|
54
|
+
|
|
55
|
+
- Pet packages are inert data. Never add JavaScript, shell commands, remote URLs, HTML, or event handlers to a manifest.
|
|
56
|
+
- Asset paths stay relative to the pet directory and cannot use `..`, absolute paths, backslashes, or escaping symlinks.
|
|
57
|
+
- Do not mutate the original Codex rows merely to add a Pi-only action; use `pet.pi.json` and a separate asset unless a full repair is intended.
|
|
58
|
+
- Do not package a failing or visually unreviewed pet. Preserve source and licensing uncertainty explicitly.
|
|
59
|
+
|
|
60
|
+
## Recovery
|
|
61
|
+
|
|
62
|
+
- **GipPity unavailable:** report the concrete error; do not start another server or transport as fallback.
|
|
63
|
+
- **Unknown action:** inspect the active pet manifests and use or add valid data.
|
|
64
|
+
- **Build fails:** fix the reported package error and rerun the build once; do not bypass validation or ask the user to reload a failed build.
|
|
65
|
+
- **Image capability unavailable:** accept supplied artwork or stop at a validated plan; do not claim visual completion.
|
|
@@ -0,0 +1,136 @@
|
|
|
1
|
+
# Hatch a Pi Pet
|
|
2
|
+
|
|
3
|
+
Use this guide for a complete character, full Codex-v2 atlas repair, nine standard animations, or sixteen look directions. Deterministic tooling requires uv and Python 3.11+. Visual work requires an image-generation capability, supplied images, or an explicit external handoff. See `LICENSE.txt` for the authoring-tool license.
|
|
4
|
+
|
|
5
|
+
## Run boundary
|
|
6
|
+
|
|
7
|
+
1. The `/pet` prompt gives `PET-GUIDE.md`'s absolute installed path. Resolve `PI_PET_PACKAGE` to its package directory, `HATCH_DIR` to this guide's directory, `PET_DATA` to `<pi-agent-directory>/pi-pet`, and `RUN_DIR` to `$PET_DATA/runs/<pet-id>`. The Pi agent directory is `PI_CODING_AGENT_DIR` when set, otherwise `~/.pi/agent`.
|
|
8
|
+
2. Collect a concept, optional name/description, style, brand cues, and reference images. Infer omitted creative details; ask only when identity direction is genuinely ambiguous.
|
|
9
|
+
3. Keep generated work in `RUN_DIR`, outside `$PET_DATA/pets/`; reuse an existing run only when deliberately resuming it.
|
|
10
|
+
4. For an existing pet, preserve every passing row. Never overwrite its package until the replacement passes and the user requested replacement.
|
|
11
|
+
5. Keep this visible progression: **prepare → establish identity → generate poses → review and hatch**.
|
|
12
|
+
|
|
13
|
+
Variable names in command blocks are path placeholders, not required environment variables. Substitute their resolved absolute paths using the host's command/workdir syntax. Use available file and JSON operations; when none fit, use Python through the locked uv environment. Do not require a POSIX shell or utilities such as `jq` and `cp`.
|
|
14
|
+
|
|
15
|
+
Read `references/pet-contract.md` and `references/animation-rows.md` before preparing a run.
|
|
16
|
+
|
|
17
|
+
## Visual capability
|
|
18
|
+
|
|
19
|
+
Choose by capability, not vendor or tool name:
|
|
20
|
+
|
|
21
|
+
1. Prefer an available image-generation capability that can accept prompts, reference images, and produce downloadable PNG/WebP files.
|
|
22
|
+
2. Use one isolated generation worker per visual job when workers are available. Up to three independent standard-row jobs may run concurrently after the canonical base exists.
|
|
23
|
+
3. Every row job must receive every `input_images` entry from `visual-jobs.json`. Only the base may be prompt-only.
|
|
24
|
+
4. Never ask a generator for the complete atlas. Generate the base, standard strips, cardinal strip, and two coherent look strips as separate jobs; deterministic scripts own extraction and assembly.
|
|
25
|
+
5. If no native image generation exists, follow `references/visual-generation.md`. Offer a prompt-and-upload handoff for ChatGPT, Gemini, Grok Imagine, or another service. If authorized browser control is available, offer to operate the user's logged-in service without requesting credentials or purchasing anything.
|
|
26
|
+
6. A missing generator is not permission to draw, tile, rotate, or procedurally synthesize the missing art. Prepare the run and exact handoff, then resume when images exist.
|
|
27
|
+
|
|
28
|
+
## Prepare
|
|
29
|
+
|
|
30
|
+
Use the locked authoring environment:
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
uv run --project "$HATCH_DIR" --locked python "$HATCH_DIR/scripts/prepare_pet_run.py" \
|
|
34
|
+
--pet-name "<Name>" \
|
|
35
|
+
--description "<one sentence>" \
|
|
36
|
+
--reference /absolute/reference.png \
|
|
37
|
+
--pet-notes "<stable identity description>" \
|
|
38
|
+
--style-preset auto \
|
|
39
|
+
--style-notes "<optional constraints>" \
|
|
40
|
+
--output-dir "$RUN_DIR"
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Omit flags that have no input. For a bare brand/product request, first research 2–4 preferably official sources and save a compact brief; do not copy logos, slogans, UI, or readable marks. Pass the brief and source URLs to `prepare_pet_run.py`.
|
|
44
|
+
|
|
45
|
+
The command creates:
|
|
46
|
+
|
|
47
|
+
- `pet_request.json`: identity, style, chroma key, geometry, and provenance inputs.
|
|
48
|
+
- `visual-jobs.json`: dependency graph, prompts, references, output paths, and job status.
|
|
49
|
+
- `prompts/`: service-neutral prompts.
|
|
50
|
+
- `references/layout-guides/`: slot-count and safe-area guides; generated art must not reproduce guide marks.
|
|
51
|
+
|
|
52
|
+
Inspect `visual-jobs.json`. A pending job is ready only when every `depends_on` job is complete. Send only jobs with a non-null `generation_capability` to an image generator; `visual-approval-gate` jobs are evidence-backed parent transitions.
|
|
53
|
+
|
|
54
|
+
## Establish identity and standard rows
|
|
55
|
+
|
|
56
|
+
1. Generate `base`; inspect one centered, full-body pet on its flat chroma background. Copy the selected file to `decoded/base.png` and `references/canonical-base.png`; record its path and completion in `visual-jobs.json` atomically.
|
|
57
|
+
2. Generate `idle` and `running-right` first. Confirm identity, calm idle motion, and readable gait before spending the remaining jobs.
|
|
58
|
+
3. Mirror `running-left` only when markings, lighting, props, and handedness remain correct:
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
uv run --project "$HATCH_DIR" --locked python "$HATCH_DIR/scripts/derive_running_left_from_running_right.py" \
|
|
62
|
+
--run-dir "$RUN_DIR" --confirm-appropriate-mirror \
|
|
63
|
+
--decision-note "<why identity and meaning survive mirroring>"
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
The derivation leaves `running-left` staged, not complete. Run the same extraction and visual QA as any generated row, then mark it complete. Otherwise generate it independently. Generate all other standard rows independently from the canonical base.
|
|
67
|
+
|
|
68
|
+
4. After copying each selected strip to its declared `decoded/` path, immediately run:
|
|
69
|
+
|
|
70
|
+
```bash
|
|
71
|
+
uv run --project "$HATCH_DIR" --locked python "$HATCH_DIR/scripts/extract_strip_frames.py" \
|
|
72
|
+
--decoded-dir "$RUN_DIR/decoded" --output-dir "$RUN_DIR/qa/rows/<job-id>/frames" \
|
|
73
|
+
--states "<job-id>" --method auto
|
|
74
|
+
uv run --project "$HATCH_DIR" --locked python "$HATCH_DIR/scripts/inspect_frames.py" \
|
|
75
|
+
--frames-root "$RUN_DIR/qa/rows/<job-id>/frames" \
|
|
76
|
+
--json-out "$RUN_DIR/qa/rows/<job-id>/review.json" --states "<job-id>" --require-components
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
Do not mark the job complete until deterministic inspection and a quick visual check pass. Repair known clipping, extraction, identity, or semantics immediately. `stable-slots` is allowed only when the generated strip itself has stable scale and placement but component extraction introduces popping.
|
|
80
|
+
|
|
81
|
+
5. When all nine rows pass, extract all frames, inspect them, compose the intermediate 8×9 atlas, and create the contact sheet and previews using the commands in `references/standard-assembly.md`. Inspect every preview before look generation. The 8×9 atlas is never packageable.
|
|
82
|
+
|
|
83
|
+
## Look directions
|
|
84
|
+
|
|
85
|
+
Read `references/look-directions.md` before this stage.
|
|
86
|
+
|
|
87
|
+
1. Write `qa/look-mechanics.md`: what anchors, what leads the gaze, what follows, eye construction, body deformation, and prop constraints.
|
|
88
|
+
2. Generate one four-pose strip: `000 up`, `090 screen-right`, `180 down`, `270 screen-left`. Extract it with `extract_cardinal_anchors.py`, inspect at pet size, and compose `decoded/look-anchors-approved.png`. Regenerate an ambiguous cardinal before continuing. Complete the evidence gate only after those artifacts pass:
|
|
89
|
+
|
|
90
|
+
```bash
|
|
91
|
+
uv run --project "$HATCH_DIR" --locked python "$HATCH_DIR/scripts/approve_cardinals.py" \
|
|
92
|
+
--run-dir "$RUN_DIR" --reviewed-by "<agent or user identity>" \
|
|
93
|
+
--qa-note "<visible evidence that all four cardinals are correct>"
|
|
94
|
+
```
|
|
95
|
+
3. Generate row 9 as one coherent eight-pose family from approved cardinals. Register it immediately with `assemble_extended_atlas.py --look-row-9`; inspect its registered cells and edge report.
|
|
96
|
+
4. Generate row 10 only after row 9 passes. Attach the approved cardinals and completed row 9 so scale, registration, and the `157.5→180` / `337.5→000` boundaries remain coherent.
|
|
97
|
+
5. A failed direction regenerates its complete eight-pose row. Never patch one normalized final cell into a new pet.
|
|
98
|
+
|
|
99
|
+
## Assemble and review
|
|
100
|
+
|
|
101
|
+
Run the final commands in `references/final-assembly.md` in order:
|
|
102
|
+
|
|
103
|
+
1. Assemble both look rows into the 8×11 atlas.
|
|
104
|
+
2. Apply exactly one edge-local chroma despill pass.
|
|
105
|
+
3. Validate geometry, alpha, used cells, transparent unused cells, and chroma contamination.
|
|
106
|
+
4. Produce the extended contact sheet, focused direction sheet, blind A/B sheet, and continuity report.
|
|
107
|
+
5. Use three isolated vision-capable reviewers for the blind sheet, combine strict-majority verdicts, then run one independent final visual reviewer. Follow `references/reviewer-protocol.md`.
|
|
108
|
+
6. If isolated reviewers are unavailable, ask the user to inspect the blind and labeled sheets. Record reduced assurance and `reviewed_by: "user"`; never claim multi-agent consensus.
|
|
109
|
+
|
|
110
|
+
Deterministic success does not replace visual QA. Visual confidence does not waive deterministic failure.
|
|
111
|
+
|
|
112
|
+
## Package
|
|
113
|
+
|
|
114
|
+
Package only after `references/qa-rubric.md` passes:
|
|
115
|
+
|
|
116
|
+
```text
|
|
117
|
+
pets/<pet-id>/
|
|
118
|
+
├── PET.md
|
|
119
|
+
├── pet.json
|
|
120
|
+
├── spritesheet.webp
|
|
121
|
+
└── validation.json
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
- Copy only the final despilled `spritesheet-extended.webp` as `spritesheet.webp`.
|
|
125
|
+
- Write `pet.json` with `spriteVersionNumber: 2` and `spritesheetPath: "spritesheet.webp"`.
|
|
126
|
+
- Write `PET.md` with identity, personality, included actions, generation inputs, tool/service provenance, review method, and licensing uncertainty.
|
|
127
|
+
- Copy final deterministic validation as `validation.json`; retain full QA evidence in the run directory.
|
|
128
|
+
- Write the accepted package to `$PET_DATA/pets/<pet-id>`. From `PI_PET_PACKAGE`, run `npm run pet:validate -- $PET_DATA/pets/<pet-id>` and `npm run pet:rebuild -- <pet-id>`. Tell the user to run `/reload`, then inspect at display scale and exercise every standard action.
|
|
129
|
+
|
|
130
|
+
## Repair and stop conditions
|
|
131
|
+
|
|
132
|
+
- Classify failures as semantics, identity, source geometry, connectivity, extraction, chroma, continuity, or final visual QA.
|
|
133
|
+
- Prefer deterministic correction for deterministic failure. Regenerate only when source art is wrong.
|
|
134
|
+
- Preserve passing properties and regenerate the smallest package-eligible unit: one standard row or one complete coherent look row.
|
|
135
|
+
- If the same root failure recurs twice, change strategy rather than paraphrasing the same prompt.
|
|
136
|
+
- Stop when all acceptance gates pass, the user cancels, or an external capability is unavailable after producing a resumable handoff. Never package a partial pet as complete.
|
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
10
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
11
|
+
|
|
12
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
13
|
+
the copyright owner that is granting the License.
|
|
14
|
+
|
|
15
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
16
|
+
other entities that control, are controlled by, or are under common
|
|
17
|
+
control with that entity. For the purposes of this definition,
|
|
18
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
19
|
+
direction or management of such entity, whether by contract or
|
|
20
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
21
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
22
|
+
|
|
23
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
24
|
+
exercising permissions granted by this License.
|
|
25
|
+
|
|
26
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
27
|
+
including but not limited to software source code, documentation
|
|
28
|
+
source, and configuration files.
|
|
29
|
+
|
|
30
|
+
"Object" form shall mean any form resulting from mechanical
|
|
31
|
+
transformation or translation of a Source form, including but
|
|
32
|
+
not limited to compiled object code, generated documentation,
|
|
33
|
+
and conversions to other media types.
|
|
34
|
+
|
|
35
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
36
|
+
Object form, made available under the License, as indicated by a
|
|
37
|
+
copyright notice that is included in or attached to the work
|
|
38
|
+
(an example is provided in the Appendix below).
|
|
39
|
+
|
|
40
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
41
|
+
form, that is based on (or derived from) the Work and for which the
|
|
42
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
43
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
44
|
+
of this License, Derivative Works shall not include works that remain
|
|
45
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
46
|
+
the Work and Derivative Works thereof.
|
|
47
|
+
|
|
48
|
+
"Contribution" shall mean any work of authorship, including
|
|
49
|
+
the original version of the Work and any modifications or additions
|
|
50
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
51
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
52
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
53
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
54
|
+
means any form of electronic, verbal, or written communication sent
|
|
55
|
+
to the Licensor or its representatives, including but not limited to
|
|
56
|
+
communication on electronic mailing lists, source code control systems,
|
|
57
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
58
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
59
|
+
excluding communication that is conspicuously marked or otherwise
|
|
60
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
61
|
+
|
|
62
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
63
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
64
|
+
subsequently incorporated within the Work.
|
|
65
|
+
|
|
66
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
67
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
68
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
69
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
70
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
71
|
+
Work and such Derivative Works in Source or Object form.
|
|
72
|
+
|
|
73
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
74
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
75
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
76
|
+
(except as stated in this section) patent license to make, have made,
|
|
77
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
78
|
+
where such license applies only to those patent claims licensable
|
|
79
|
+
by such Contributor that are necessarily infringed by their
|
|
80
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
81
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
82
|
+
institute patent litigation against any entity (including a
|
|
83
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
84
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
85
|
+
or contributory patent infringement, then any patent licenses
|
|
86
|
+
granted to You under this License for that Work shall terminate
|
|
87
|
+
as of the date such litigation is filed.
|
|
88
|
+
|
|
89
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
90
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
91
|
+
modifications, and in Source or Object form, provided that You
|
|
92
|
+
meet the following conditions:
|
|
93
|
+
|
|
94
|
+
(a) You must give any other recipients of the Work or
|
|
95
|
+
Derivative Works a copy of this License; and
|
|
96
|
+
|
|
97
|
+
(b) You must cause any modified files to carry prominent notices
|
|
98
|
+
stating that You changed the files; and
|
|
99
|
+
|
|
100
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
101
|
+
that You distribute, all copyright, patent, trademark, and
|
|
102
|
+
attribution notices from the Source form of the Work,
|
|
103
|
+
excluding those notices that do not pertain to any part of
|
|
104
|
+
the Derivative Works; and
|
|
105
|
+
|
|
106
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
107
|
+
distribution, then any Derivative Works that You distribute must
|
|
108
|
+
include a readable copy of the attribution notices contained
|
|
109
|
+
within such NOTICE file, excluding those notices that do not
|
|
110
|
+
pertain to any part of the Derivative Works, in at least one
|
|
111
|
+
of the following places: within a NOTICE text file distributed
|
|
112
|
+
as part of the Derivative Works; within the Source form or
|
|
113
|
+
documentation, if provided along with the Derivative Works; or,
|
|
114
|
+
within a display generated by the Derivative Works, if and
|
|
115
|
+
wherever such third-party notices normally appear. The contents
|
|
116
|
+
of the NOTICE file are for informational purposes only and
|
|
117
|
+
do not modify the License. You may add Your own attribution
|
|
118
|
+
notices within Derivative Works that You distribute, alongside
|
|
119
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
120
|
+
that such additional attribution notices cannot be construed
|
|
121
|
+
as modifying the License.
|
|
122
|
+
|
|
123
|
+
You may add Your own copyright statement to Your modifications and
|
|
124
|
+
may provide additional or different license terms and conditions
|
|
125
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
126
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
127
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
128
|
+
the conditions stated in this License.
|
|
129
|
+
|
|
130
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
131
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
132
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
133
|
+
this License, without any additional terms or conditions.
|
|
134
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
135
|
+
the terms of any separate license agreement you may have executed
|
|
136
|
+
with Licensor regarding such Contributions.
|
|
137
|
+
|
|
138
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
139
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
140
|
+
except as required for reasonable and customary use in describing the
|
|
141
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
142
|
+
|
|
143
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
144
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
145
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
146
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
147
|
+
implied, including, without limitation, any warranties or conditions
|
|
148
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
149
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
150
|
+
appropriateness of using or redistributing the Work and assume any
|
|
151
|
+
risks associated with Your exercise of permissions under this License.
|
|
152
|
+
|
|
153
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
154
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
155
|
+
unless required by applicable law (such as deliberate and grossly
|
|
156
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
157
|
+
liable to You for damages, including any direct, indirect, special,
|
|
158
|
+
incidental, or consequential damages of any character arising as a
|
|
159
|
+
result of this License or out of the use or inability to use the
|
|
160
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
161
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
162
|
+
other commercial damages or losses), even if such Contributor
|
|
163
|
+
has been advised of the possibility of such damages.
|
|
164
|
+
|
|
165
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
166
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
167
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
168
|
+
or other liability obligations and/or rights consistent with this
|
|
169
|
+
License. However, in accepting such obligations, You may act only
|
|
170
|
+
on Your own behalf and on Your sole responsibility, not on behalf of
|
|
171
|
+
any other Contributor, and only if You agree to indemnify,
|
|
172
|
+
defend, and hold each Contributor harmless for any liability
|
|
173
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
174
|
+
of your accepting any such warranty or additional liability.
|
|
175
|
+
|
|
176
|
+
END OF TERMS AND CONDITIONS
|
|
177
|
+
|
|
178
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
179
|
+
|
|
180
|
+
To apply the Apache License to your work, attach the following
|
|
181
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
182
|
+
replaced with your own identifying information. (Don\'t include
|
|
183
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
184
|
+
comment syntax for the file format. We also recommend that a
|
|
185
|
+
file or class name and description of purpose be included on the
|
|
186
|
+
same "printed page" as the copyright notice for easier
|
|
187
|
+
identification within third-party archives.
|
|
188
|
+
|
|
189
|
+
Copyright [yyyy] [name of copyright owner]
|
|
190
|
+
|
|
191
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
192
|
+
you may not use this file except in compliance with the License.
|
|
193
|
+
You may obtain a copy of the License at
|
|
194
|
+
|
|
195
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
196
|
+
|
|
197
|
+
Unless required by applicable law or agreed to in writing, software
|
|
198
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
199
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
200
|
+
See the License for the specific language governing permissions and
|
|
201
|
+
limitations under the License.
|
|
@@ -0,0 +1,5 @@
|
|
|
1
|
+
# Source notice
|
|
2
|
+
|
|
3
|
+
The deterministic Python workflow in this directory derives from an Apache-2.0 Codex Hatch Pet skill snapshot inspected on 2026-07-21.
|
|
4
|
+
|
|
5
|
+
Pi Pet modifications replace Codex-specific generation, runtime, manifest, and packaging assumptions with capability-neutral visual jobs, an isolated uv runtime, Pi Pet packages, and external/browser-assisted generation handoffs. See `LICENSE.txt`.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Animation rows
|
|
2
|
+
|
|
3
|
+
| Row | Action | Used columns | Durations (ms) |
|
|
4
|
+
|---:|---|---:|---|
|
|
5
|
+
| 0 | idle | 0–5 | 280, 110, 110, 140, 140, 320 |
|
|
6
|
+
| 1 | running-right | 0–7 | 120 × 7, 220 |
|
|
7
|
+
| 2 | running-left | 0–7 | 120 × 7, 220 |
|
|
8
|
+
| 3 | waving | 0–3 | 140 × 3, 280 |
|
|
9
|
+
| 4 | jumping | 0–4 | 140 × 4, 280 |
|
|
10
|
+
| 5 | failed | 0–7 | 140 × 7, 240 |
|
|
11
|
+
| 6 | waiting | 0–5 | 150 × 5, 260 |
|
|
12
|
+
| 7 | running | 0–5 | 120 × 5, 220 |
|
|
13
|
+
| 8 | review | 0–5 | 150 × 5, 280 |
|
|
14
|
+
| 9 | look A | 0–7 | 000, 022.5, 045, 067.5, 090, 112.5, 135, 157.5° |
|
|
15
|
+
| 10 | look B | 0–7 | 180, 202.5, 225, 247.5, 270, 292.5, 315, 337.5° |
|
|
16
|
+
|
|
17
|
+
`000°` means up. Neutral/front is the pointer deadzone and falls back to idle.
|
|
18
|
+
|
|
19
|
+
## Semantics
|
|
20
|
+
|
|
21
|
+
- `idle`: calm breathing/blinking; first frame also works as reduced-motion still.
|
|
22
|
+
- `running-right` / `running-left`: lateral locomotion with alternating cadence and correct facing.
|
|
23
|
+
- `waving`: greeting with clear gesture and return.
|
|
24
|
+
- `jumping`: anticipation, lift, peak, descent, settle.
|
|
25
|
+
- `failed`: readable blocked/deflated response without detached decoration.
|
|
26
|
+
- `waiting`: expectant request for user input, distinct from idle and review.
|
|
27
|
+
- `running`: active task work or processing, not literal locomotion.
|
|
28
|
+
- `review`: focused inspection of ready output.
|
|
29
|
+
- look rows: one continuous clockwise family using pet-specific eyes, head, body, appendages, and props.
|