Known limitations
| Document version | Date | Summary |
|---|---|---|
| v1 | 2026-07-18 | Initial limitation register |
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. LIM-001, LIM-002, and LIM-003 were all
still true at rollover, so every one of them is carried forward below with its original identifier
and wording. No limitation was resolved by v0.1.0.
| 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 | Nothing enforces that tools/verify/alloc_probe.c exercises every public operation, so an operation added later can go unmeasured by the runtime allocation check | The allocation evidence can silently narrow as the public surface grows | PBI-032 | Open |
LIM-004 | Build | The desktop entry was declared in config/compositions.json before apps/desktop existed. apps/desktop now exists and defines pet_desktop. compositions.py check-paths runs in every gate and fails when a declared component directory or its CMakeLists.txt is absent, and CMake fails when a configured directory does not define the target the registry names | Closed. Every registry app and frontend reference resolves to a real directory, a real build file, and a real CMake target, and a future entry declared before its component exists now fails the gate rather than being skipped silently | PBI-045 | Closed |
LIM-005 | Dependencies | Third-party dependencies fetched by CMake do not yet have a project-owned local override policy. This is true for cmocka and for SDL, which follows the same pinned FetchContent-only model in E10 | A clean first configure can require network access even when a developer has an equivalent dependency available locally, which limits offline rebuilds and some constrained CI environments | PBI-043, PBI-063, future dependency PBI | Open |
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-007 | Dependencies | cmake/pet_sdl.cmake left the SDL GPU and Vulkan paths enabled while disabling every other unused subsystem. SDL_GPU, SDL_RENDER_VULKAN, and SDL_VULKAN are now all OFF, verified from a removed build/ tree | Closed. The generated config defines SDL_GPU_DISABLED with no Vulkan define, the OpenGL video driver and 2D renderer remain, and pet_desktop links no undefined Vulkan symbol and no libvulkan, so the renderer backend is a build decision rather than a run-time one | PBI-043 | Closed |
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-009 | Frontend input | Closed. pet_desktop drains pet_frontend_sdl_poll_event every loop turn, dispatches a product action through pet_world_apply_action, ends the loop on a host control quit, and offers a --until-quit live mode that runs until that quit | Closed. A space press and a left click greet the pet through the Core and snapshot path, and the window close button, Ctrl-C, and SIGTERM all exit cleanly through the one quit event, verified against the real OpenGL driver. Dispatch and host control separation are covered by pet_desktop_tests | PBI-059 | Closed |
LIM-010 | Presentation | The role priority answers expression_happy ahead of every activity, and PET_HAPPY_FOR_MS outlasts PET_ATTENTIVE_FOR_MS. A greet is the only route into the attentive activity and sets the happy expression in the same call, so happy covers the whole attentive dwell | The activity_attentive role and sprites/attentive.png never reach the screen in a product run. This does not block v0.2.0, because each layer behaves as its own contract documents and a fix has to change either the Core dwell times or the documented role priority | PBI-063, future presentation PBI | Open |
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 | Open |
LIM-012 | Embedded | No embedded build exists for this release. ESP-IDF, Raspberry Pi Pico SDK, and Arduino host suitability rests on the Core, asset, and dependency boundary choices rather than on an executed build or run | Embedded suitability is an architectural hypothesis, not a support claim. It is recorded as unverified and does not block v0.2.0, because no embedded environment is a required target for it | PBI-062, future embedded PBI | Open |
Add a limitation when work deliberately leaves a relevant constraint unresolved. Close it only when the linked evidence or decision exists.