V0 candidate roadmap

Document version	Date	Summary
v1	2026-07-24	Capture the candidate v0.3.0 to v0.7.0 sequence after v0.2.0
v2	2026-08-01	Record v0.3.0 as delivered and reopen the roadmap at v0.4.0
v3	2026-08-01	Rewrite as release-agnostic candidate directions with readiness signals
v4	2026-08-02	Join the board runtime and the embedded asset pipeline behind a panel-first order
v5	2026-08-02	Hand the promoted persistence direction to the accepted documents
v6	2026-08-05	Hand the promoted board runtime direction to the accepted documents

Status: Planning note, not a commitment

Authority: None. This document preserves direction and reasoning only. A direction becomes a release only when it is accepted through the release planning process into milestones, version architecture, epics, and PBIs.

Related documents: release planning, milestones, general architecture, known limitations, and host support layer idea.

1. Purpose

This roadmap records the candidate directions that remain open inside the V0 milestone, why they are worth doing, and what should be true before each one is opened as a release.

It deliberately does not track project state. Which releases exist, which are completed, and which identifiers come next are recorded in milestones, epics, and PBIs. This document stays useful without being rewritten after every minor release, so it names directions rather than version numbers.

A direction is removed from this document when it has been delivered or abandoned, and the reasoning that survives moves into the accepted documents that now own it.

2. How to read this document

Each direction below states its outcome, the scope that would make it a small release, the scope it should refuse, and a readiness signal. The readiness signal is what makes the direction the right next step rather than a later one.

Directions are listed in the order the project currently expects to want them. The order is a judgement about risk and evidence, not a queue. A readiness signal that becomes true early moves its direction forward, and a signal that stays false holds it back regardless of position.

The V0 milestone in milestones defines what the milestone still owes. A direction that closes an unticked milestone exit criterion is a stronger candidate than one that does not.

3. Ordering principle

V0 alternates platform risk and product value rather than piling hardware, persistence, identity, and adapters into one release. A release that adds several of them at once cannot be verified independently, and one failure blocks the rest.

Platform work is preferred when the largest open unknown is whether the architecture survives a real environment. Product work is preferred when the platform evidence exists but the pet still does not feel like a companion. The release planning scope questions decide the individual case.

4. Local persistence foundation

This direction has been promoted. Its scope, format, boundaries, and compatibility promise are now owned by milestones, the accepted version architecture, and the active epic and PBI documents, so the description that used to sit here has been removed rather than duplicated.

The reasoning worth keeping is why it came first. A pet cannot feel persistent until identity survives process lifetime, so persistence blocks most later product work. It also creates the first real storage interface pressure, which the host support layer idea names as the first likely function-pointer boundary, and it settles the save format while the authoritative state is still small enough to change cheaply.

One question it deliberately left open belongs to a later direction. Where a save belongs on a packaged system is the hosted location question in section 10. Time spent outside the process was left open at first and then pulled back in, because the format is the part that cannot be changed cheaply later, so the release measures the absence and leaves only its product meaning to behaviour work.

5. Board runtime and embedded asset pipeline

This direction has been promoted. Its scope, ordering, frontend split, pack format direction, verification composition, and device evidence model are now owned by milestones, the accepted version architecture, and the active epic and PBI documents, so the description that used to sit here has been removed rather than duplicated.

The reasoning worth keeping is why it came when it did and why it carried two outcomes at once. Every embedded claim the project held was a build claim, so this is the point where embedded suitability stops being a link result and becomes runtime evidence on a named board. The asset pipeline rode along deliberately, because it is the work that makes the pet look like itself on hardware, and keeping it behind the panel evidence inside one release removed the guesswork without postponing the visible result by a whole release.

Two constraints survived promotion and are worth remembering as reasoning rather than as scope. The panel comes before the pipeline, because a generated artefact designed against vendor documentation is a guess with a file format. The fallback presentation is a safety valve for the frontend rather than for the release, so an overrunning converter can be deferred without dead work while a fallback-only outcome still fails the release criterion it was never allowed to satisfy.

The full frame buffer direction this document recorded was taken up as a decision rather than left as direction, and the release owns it through an ADR.

6. Early identity development

Outcome: the pet gains at least one lasting identity characteristic that survives save and restore.

Recommended scope:

• introduce one small lasting identity characteristic
• make its cause meaningful and non-punitive
• expose it through PetSnapshot only when it is deliberately presentable
• persist it through the save format
• update presentation roles or assets only for the visible slice of the feature

Expected exclusions:

• a broad trait engine
• a maturity tree
• a large cosmetic system
• a user-facing editor for every lasting detail
• an activity farming loop

Readiness signal: authoritative state already survives process lifetime, because lasting identity without persistence is not lasting.

Reasoning: the specification wants the pet to develop identity through shared history. One well-bounded characteristic proves the model without turning the Core into a content system, and it is the first release where the product stops being a presentation demo.

7. First activity or environment adapter

Outcome: one bounded adapter path reports a semantic event or capability without mutating authoritative state directly.

Recommended scope:

• choose one adapter source, either a physical board signal or a small digital activity source
• translate source-specific data into a semantic event or capability
• validate, bound, and rate-limit the input
• keep the adapter out of direct authoritative state mutation
• record whether physical and digital adapters need separate interfaces

Expected exclusions:

• a plugin marketplace
• a network service
• continuous activity surveillance
• a broad permission system
• support for every sensor or activity category

Readiness signal: enough host, persistence, and board evidence exists to choose one real source, so the adapter interface is designed against it rather than invented generically.

Reasoning: adapters are central to the long-term product, and the fastest way to design the wrong interface is to design it without a source.

8. Support layer evaluation

The host half of this direction is answered. components/ carries the frontend-neutral work that a pet_host_support library would have carried, one contract per responsibility, and ADR-010 records how those components are reused. The host support layer idea is closed on that basis and is kept only as the record of the reasoning.

What remains is the frontend half, which section 10 carries as an open question. A shared frontend support layer should still be earned by duplication between two real frontends rather than predicted. The TFT frontend is the second real frontend, so the observation this question waits on becomes possible for the first time once that frontend exists. The duplication to look for is the composition, scaling, placement, and asset selection each frontend performs before it hands pixels to its platform, and the answer should come from reading two implementations rather than from designing a third layer in advance.

9. Durable rejections

These shapes were considered and rejected. They are kept so that a later release does not rediscover the same argument.

One release that delivers a complete board runtime from nothing. Display driver choice, firmware stack, asset conversion, board input, upload tooling, runtime evidence, and the embedded build boundary would arrive together, and no part of it could be verified independently.

Lasting identity before persistence. It would make the pet feel more alive within one process and would lose that identity on exit, which contradicts the outcome it claims.

A generic host support library before duplicated host code exists. It would freeze an interface against one host and call it portability.

A Core allocator or arena without a version requirement that needs one. The fixed-capacity caller-owned model is a recorded decision, and relaxing it without evidence removes a property the allocation probe currently proves.

Non-volatile storage on the device inside the first board runtime release. It arrives with save timing, power-loss behaviour, wear policy, key layout, corruption handling, and factory reset, none of which the outcome needs. A pet that lives on a board and a pet that survives a power cycle are two outcomes, and the second one is worth its own release.

A generated pack that carries panel offsets, rotation, or colour order. It would make a second panel need a new artefact rather than a new board profile, and it would put a board fact in the one file that every board is supposed to share.

10. Open questions

These questions are open across the remaining V0 directions rather than owned by one of them.

• whether physical and digital adapters need separate interfaces or one bounded event surface
• which first adapter source produces the clearest product evidence
• whether the desktop application is ever distributed as a package, which decides whether the hosted location policy behind LIM-008 is solved by code or accepted as out of scope
• what a return after a long absence should feel like, now that the save format measures the absence and the world clock is the only thing that moves because of it
• how much identity content V0 needs before the v1.0.0 scope can be stated
• whether the frontend support layer question is answered by a second frontend or deferred past V0
• whether a device that keeps a pet across a power cycle wants non-volatile storage, a longer soak standard, or both, now that a board runs continuously without either
• whether partial display updates are ever worth their statefulness, which the first soak measurements are the earliest evidence for

The first two questions this section used to carry have been answered. The generated artefact form and its compatibility promise belong to the accepted v0.5.0 architecture and its pack ADR, and the first embedded runtime presents the canonical set rather than a reduced one, which is the criterion that closes LIM-013 rather than a preference.

11. Promotion

A direction leaves this document through the release planning process. That process selects the candidate, writes the milestone entry, accepts the version architecture, opens the epic map with its dependency diagram, and adds the PBIs.

After promotion, delete or rewrite the text here that the accepted documents now own. Two descriptions of the same scope will disagree eventually, and the accepted documents win.