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
v12	2026-08-04	Archive the v0.4.0 register and carry forward the open limitations

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, v0.3.0, and v0.4.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. v0.4.0 resolved none, so all twelve limitations still true after it 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 configures, compiles, and links the reusable firmware foundation for esp32, and the classic LILYGO T-Display has now been flashed, its panel brought up, observed, and measured, and its firmware run continuously for two hours with the pet presented on the panel from the world state. No other hardware facility on the board has been run	Embedded support is cross-compile tested, plus a measured panel path and an observed continuous runtime on the classic board, whose evidence is a two-hour run with a steady heap and a matching iteration pace. Buttons, persistence, sensors, wireless facilities, and all other hardware runtime behaviour remain unverified until the rest of the candidate v0.5.0 T-Display runtime work records device evidence. The panel now shows the canonical pet from the embedded pack rather than the procedural fallback, and the fallback stays reachable for a refused pack	PBI-062, E20, PBI-076, PBI-085, E31, PBI-107, E32, PBI-112, E33, PBI-116, PBI-127, PBI-128	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, E34, E35, PBI-117, PBI-122, PBI-128	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, a later hardware 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
LIM-019	Manifest grammar	The canonical manifest grammar has two readers. components/manifest parses it in C at run time and tools/assets/manifest.py parses it in Python at build time. The Python reader is isolated from pack encoding and both readers are exercised over the same acceptance and rejection cases	The first grammar change could make the two readers disagree unless it implements the single build-time reader accepted by ADR-015. That first change is the trigger for the deferred collapse rather than a reason to extend both readers	PBI-118, ADR-015, the first manifest grammar change	Open
LIM-020	Integrity check	CRC-32 as used by IEEE 802.3 is implemented twice, bitwise both times, in src/save.c for the save payload and in components/assets/src/pack.c for the asset pack, because a component does not depend on the Core	Two implementations of one polynomial can drift. A third binary artefact is the trigger for collapsing them into one shared place rather than a reason to extend either	PBI-120, ADR-013, ADR-019, a third binary artefact	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 owned none of the carried entries above. Windows verification, the SDL extension set, rendering automation, and the embedded runtime and asset gaps were outside a persistence release, so they stayed open by decision rather than by omission. LIM-008 is the one entry the release touched, and it touched 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.5.0 owns three of the entries above and carries the rest by decision. LIM-012 is closed by PBI-128 once the classic board has been flashed and observed, and only for that variant on esp32, so no claim reaches another board or target. LIM-013 is closed by the same PBI on the strength of a canonical frame reaching the panel through the generated pack, which is why a run that presents only the fallback fails that criterion rather than passing it quietly. LIM-015 stays open with its owner corrected, because the release deliberately adds no non-volatile storage and a later hardware runtime release owns that work with its layout and wear decisions.

The rest stay open and untouched by design. Windows verification, the SDL extension set, the desktop rendering automation gap, the allocation probe depth, the hosted location policy, the absence semantics, the desktop clock resolution, and desktop session continuity are all outside a board runtime release. LIM-008 is worth naming explicitly, because the embedded half of its question is now answered in practice rather than by argument. A firmware image decides where its data lives at build time, and v0.5.0 links the asset pack into the image rather than searching for it, which is exactly what that entry already predicted. Its hosted half is untouched and still waits on a product decision. LIM-011 is left exactly as it is, because it describes desktop rendering and interaction automation, and stretching it to cover a physical panel would blur two different gaps into one row.

The device verification gap therefore needs an entry of its own, and PBI-128 opens it once the evidence exists rather than in advance. v0.5.0 follows the practice below and opens a new entry when the work that creates it lands.

v0.4.0 opened its new entries as the work that created them landed 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.