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
v8	2026-08-01	Archive the v0.3.0 register and carry forward the open limitations
v9	2026-08-03	Record LIM-015 for the absent non-volatile storage implementation
v10	2026-08-03	Record LIM-016 for the whole-second resolution of the hosted wall clock
v11	2026-08-04	Record LIM-017 for the absent session continuity in the desktop application

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 register as it stood at the close of each release is archived with that release, in v0.1.0, v0.2.0, and v0.3.0. LIM-004, LIM-007, and LIM-009 were resolved within v0.2.0, and LIM-005 and LIM-010 within v0.3.0, so those five remain only in their archives. The eight limitations still true after v0.3.0 are 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-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	Hosted data location	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. The v0.4.0 save location shares the same gap and avoids it the same way, by requiring an explicit path rather than choosing one, so this is one policy question with two clients rather than two problems	A packaged app launched from another working directory may fall back even when its assets are installed beside it, and would have the same trouble finding a save file if it ever chose one for the user. This blocks nothing today because production packaging and installers are out of scope, and because no supported deployment resolves either location on the user’s behalf. An embedded deployment never meets this, because a firmware image decides where its data lives at build and flash time through a linked symbol or a partition entry, rather than searching for it at run time. Choosing that layout is a separate decision and does not resolve this entry	PBI-063, PBI-099, a desktop packaging release if one is planned	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 v0.2.0 and remain manual, so they have to be repeated by hand for every release. The v0.3.0 review repeated the observation on both drivers and added a greet settling from the happy expression into the attentive activity, which is the first on-screen evidence for the ADR-011 dwell ordering	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 esp32, but the selected classic LILYGO T-Display has not been flashed or run	Embedded support is cross-compile tested only. Display output, buttons, persistence, sensors, wireless facilities, and all other hardware runtime behaviour remain unverified until the candidate v0.5.0 T-Display runtime work records device evidence	PBI-062, E20, PBI-076, PBI-085, 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
LIM-014	Time semantics	Format version 1 carries a host-supplied save stamp and a load adds a bounded absence to elapsed_time_ms, which ADR-012 decided. What that absence changes is limited to the world clock and to the presentation that follows from it, because the world holds no state that decays and no reunion behaviour exists. An absence is also zero whenever either side had no absolute time, which is every host that has not been given a clock	The mechanism required by SPEC-FR-015 and by general architecture section 6.4 is in place, and the product meaning of a long absence is not. A pet that returns after a week finds its dwell stamps stale and settles, and nothing else about it acknowledges that the user was away. This is a deliberate boundary rather than an unfinished feature, because what an absence should feel like is a product decision that belongs with the behaviour work that has state to act on. A classic T-Display with neither a battery-backed clock nor a network still supplies the unknown value and loses only the absence, and it needs no Core, format, or storage change when it gains a clock	PBI-102, PBI-090, PBI-099, a later behaviour release that decides what a return should feel like	Open
LIM-015	Embedded storage	The embedded build compiles components/storage with no implementation, because pet_storage_stdio is a desktop selection and no non-volatile implementation of the contract exists. ESP-IDF v6.0.2 for esp32 compiles the contract and the firmware links no storage dependency	Firmware can carry the storage boundary but cannot keep a pet across a power cycle. A device that should remember its pet needs an implementation over a flash partition or NVS, together with the wear and layout decisions that come with it, and that work belongs to a later hardware runtime release with device evidence behind it	PBI-095, PBI-099, candidate v0.5.0 runtime release	Open
LIM-016	Time resolution	The desktop application reads its wall clock through the standard C time facility, which promises whole seconds, so a stamp and an absence are both rounded down to a second. The headless application reads no clock at all and takes the value from --now	An absence is accurate to a second rather than to a millisecond, and a save and a load inside the same second report no absence even though time passed. Nothing in the format limits this, so a host with a finer source may supply one without a format revision	PBI-097, candidate later host release	Open
LIM-017	Session continuity	The desktop application persists a world only when an operator supplies --load or --save, so a launch without options starts a new pet and a quit keeps nothing. It saves on no timer, on no quit, and on no other implicit event. Choosing a location for the operator is the hosted location policy question that LIM-008 already describes, and this entry links to that description rather than repeating it	A pet does not survive a launch by itself, which is what a product user would expect of it, and every existing pet reaches its next run through an operator who names a file. This is a deliberate boundary rather than an unfinished feature, because deciding when a real product saves, what it does on a quit, and where it puts the file is a product frontend decision that the reference application must not make on that frontend’s behalf	PBI-097, LIM-008, the future product frontend as its owner	Open

Add a limitation when work deliberately leaves a relevant constraint unresolved. Close it only when the linked evidence or decision exists.

The v0.4.0 backlog owns none of the carried entries above. Windows verification, the SDL extension set, rendering automation, and the embedded runtime and asset gaps are outside a persistence release, so they stay open by decision rather than by omission. LIM-008 is the one entry the release touches, and it touches its wording rather than its status, because v0.4.0 shares the location question and answers it by requiring an explicit path. LIM-017 is the other client of that question and links to it here rather than describing it again.

Whether LIM-008 is ever solved depends on a product question rather than an engineering one. It is solved by code only if the desktop application becomes a distributed package. If the product surface stays on hardware, the entry should be accepted rather than resolved, because no supported deployment meets it. The roadmap carries that question.

v0.4.0 opens its new entries when the work that creates them lands rather than in advance. PBI-087 opened LIM-014 for the absent handling of time spent closed, and PBI-102 then narrowed it to what an absence does not yet mean, by bringing the stamp and the bounded transition into the release rather than deferring them behind a format revision. PBI-095 opened LIM-015 for the absent non-volatile storage implementation once the embedded build compiled the contract without one. PBI-097 opened LIM-016 for the whole-second resolution of the hosted wall clock when the desktop application began reading one. PBI-099 then opened LIM-017 for the desktop application not preserving a pet across launches, and left the location half of that gap where it already lives, in LIM-008.