Known limitations
| Document version | Date | Summary |
|---|---|---|
| v1 | 2026-07-18 | Initial limitation register |
| v2 | 2026-07-24 | Archive the v0.2.0 register and carry forward the open limitations |
| v3 | 2026-07-27 | Assign v0.3.0 owners to the release-scoped carried limitations |
| v4 | 2026-07-27 | Narrow LIM-012 after the first executed ESP-IDF cross-compile |
| v5 | 2026-07-28 | Record LIM-013 for the missing embedded asset storage and reader |
| v6 | 2026-07-28 | Narrow LIM-003 to probe depth after the allocation probe coverage check |
| v7 | 2026-07-28 | Close LIM-010 after the greet presentation rule |
This file records unresolved limitations that affect implementation, verification, portability, or supported behaviour. Planned release exclusions belong in milestones rather than this file.
Each limitation must link to a PBI or a BUG that resolves, evaluates, or explicitly accepts it. Identifiers are permanent and are not reused.
The limitation register as it stood at the close of v0.1.0 is archived in
release v0.1.0. The register as it stood at the close of
v0.2.0 is archived in release v0.2.0. That snapshot holds
LIM-001 through LIM-012, including the three that closed during v0.2.0. LIM-004, LIM-007,
and LIM-009 were resolved within the release and remain only in the archive. The nine limitations
still true at rollover were carried forward below with their original identifiers and wording.
Active rows are updated when later evidence closes or narrows them.
| ID | Area | Limitation | Impact | Tracking | Status |
|---|---|---|---|---|---|
LIM-001 | Windows | The MSVC and Windows Clang configurations have not been executed on Windows | Windows remains portable by design rather than build tested | PBI-013, PBI-030 | Open |
LIM-002 | Verification | The symbol scan does not parse MSVC dumpbin output and Valgrind does not run on Windows, so neither the Core boundary nor the runtime allocation check can execute there. The header check is toolchain neutral but has not been run on Windows | The three automated boundary checks produce evidence for Linux only. They are recorded as unavailable rather than passing, and do not block v0.1.0 because Windows is not a required environment | PBI-030, PBI-031, PBI-032 | Open |
LIM-003 | Verification | tools/verify/probe.py fails when a public Core operation is not called by tools/verify/alloc_probe.c, so the surface can no longer narrow silently. The check compares names, not depth, so it proves that every operation runs at least once and not that each one is driven over its interesting arguments and states | The runtime allocation evidence covers every public operation. How thoroughly one operation is exercised inside the probe remains a maintainer judgement rather than an enforced property | PBI-032, E21, PBI-080 | Narrowed |
LIM-005 | Dependencies | Resolved. cmocka and SDL retain pinned FetchContent defaults and accept prepared local source checkouts through PET_CMOCKA_SOURCE_DIR and PET_SDL_SOURCE_DIR | Prepared checkouts can configure without contacting the dependency hosts. The project does not claim package-manager support or guaranteed offline-first configuration without those checkouts | PBI-043, PBI-063, E19, PBI-069, PBI-070, PBI-071, PBI-072, ADR-008 | Closed |
LIM-006 | Dependencies | The optional SDL X11 extensions are pinned off, because SDL treats a missing one as a configure error rather than a lost feature, which made a clean configure depend on which X11 development packages a machine happened to carry. E15 keeps them off, because the base SDL window, keyboard, pointer, and event APIs cover the semantic input scope | Custom cursors, XRandR display mode switching, screensaver inhibition, and shaped or synchronised windows are unavailable to the SDL frontend until a PBI re-enables the extension it needs and records the system package that comes with it | PBI-054, PBI-058 | Open |
LIM-008 | Runtime assets | The default pet asset root is resolved relative to the process working directory. Development tests run from the build directory where pet_runtime_assets copies assets/pet, but an installed or packaged desktop app has no project-owned rule yet for discovering assets relative to the executable, bundle, install prefix, or user override | A packaged app launched from another working directory may fall back even when its assets are installed beside it. This does not block v0.2.0 because production packaging and installers are out of scope | PBI-063, future packaging PBI | Open |
LIM-010 | Presentation | Resolved. The greet presentation rule in ADR-011 shortens PET_HAPPY_FOR_MS to 10000 against an unchanged PET_ATTENTIVE_FOR_MS of 30000, so a greet presents a short happy reaction and then the attentive activity. The role priority is unchanged | The activity_attentive role and sprites/attentive.png reach the screen in a product run. A Core test asserts the dwell ordering rather than the two values, so a later dwell change cannot hide an activity role again | PBI-063, E22, PBI-081, PBI-082, ADR-011 | Closed |
LIM-011 | Verification | The automated desktop scenario runs under the SDL dummy video driver. Real-driver visible rendering and synthesised keyboard or pointer interaction are not automated verification | The automated suite proves the process lifecycle, the asset load, the update and render path, and the failure exit statuses, and nothing about what is drawn or what an input device produces. Visible rendering and interaction remain manual release evidence, to be accepted or carried forward as a release limitation rather than counted as an automated check. PBI-062 acknowledged it as a release limitation and carried it to PBI-063. The manual evidence recorded for v0.2.0 is bounded pet_desktop runs against the real Wayland and X11 drivers that exit zero after loading the canonical set, plus the maintainer’s observation on both drivers of the window with the pet drawn in it, a visible greet response to the space key and the left mouse button, and a clean exit through the window close button and Ctrl-C. Visible rendering and interaction are therefore evidenced for this release and remain manual, so they have to be repeated by hand for every release | PBI-063, future rendering automation PBI | Open |
LIM-012 | Embedded | ESP-IDF v6.0.2 now configures, compiles, and links the reusable firmware foundation for esp32s3, but the selected non-touch LILYGO T-Display S3 has not been flashed or run | Embedded support is cross-compile tested only. Display output, buttons, PSRAM, persistence, sensors, wireless facilities, and all other hardware runtime behaviour remain unverified until the candidate v0.5.0 T-Display S3 runtime work records device evidence | PBI-062, E20, PBI-076, candidate v0.5.0 runtime release | Narrowed |
LIM-013 | Embedded assets | The embedded build compiles components/assets without any reader, because pet_assets_stdio_reader is a desktop selection and no embedded storage path exists. There is no flash, packed binary, or generated array source for the canonical pet assets, and no reader implementation over one | Firmware can link the asset loading policy but cannot load an asset set on a device. Presenting the pet on hardware requires the build-time converter direction in architecture section 8.3 first, so the embedded asset path is deliberately absent rather than partially implemented | E21, PBI-078, future embedded asset converter and reader PBI | Open |
Add a limitation when work deliberately leaves a relevant constraint unresolved. Close it only when the linked evidence or decision exists.