Product Backlog Items

Document version	Date	Summary
v1	2026-07-17	Create the V0 backlog
v2	2026-07-20	Add and refine the v0.2.0 backlog
v3	2026-07-24	Archive v0.2.0 and open the next backlog
v4	2026-07-27	Add v0.3.0 and complete E17 planning
v5	2026-07-27	Record completed v0.3.0 PBIs through E20
v6	2026-07-27	Clarify the T-Display family and selected S3 variant contract
v7	2026-08-01	Archive the completed v0.3.0 backlog and open the next release backlog
v8	2026-08-02	Add the v0.4.0 local persistence foundation backlog
v9	2026-08-03	Bring the wall-clock stamp and bounded absence into v0.4.0 scope

1. Purpose

This document defines the Product Backlog Items for V0. It decomposes the epics in epics into independently verifiable increments.

The backlog is ordered by dependency and risk. A PBI may be refined before implementation, but its outcome and acceptance criteria must remain aligned with the specification, milestones, the general architecture, and the active version architecture document.

2. PBI structure

Each PBI contains:

• an epic reference
• an intended outcome
• the work included in the PBI
• acceptance criteria
• dependencies

Implementation details may change when evidence supports a better solution. Acceptance criteria describe required behaviour and evidence rather than a preferred internal implementation.

3. Shared Definition of Done

Every completed PBI must satisfy all applicable acceptance criteria and the following shared rules.

3.1 Required strict quality gate

The strict quality gate must run after every PBI that changes code, build configuration, tests, or developer tooling. It includes:

1. formatting verification with clang-format
2. a clean GCC build using ISO C99 without compiler extensions
3. the complete unit test suite built and run with GCC
4. a clean Clang build using ISO C99 without compiler extensions
5. the complete unit test suite built and run with Clang
6. the agreed GCC and Clang warnings treated as errors for project code
7. Cppcheck analysis of project code
8. parallel Clang-Tidy analysis of project code
9. an AddressSanitizer build and test run
10. an UndefinedBehaviourSanitizer build and test run
11. a Pet Core symbol scan against the allowlist for the toolchain that built the archive
12. a self-containment compilation of every public header, alone, for GCC and Clang

A documentation-only PBI does not require compiler checks unless it changes a technical contract that can be verified immediately.

If a required check cannot run, the PBI is not complete unless the maintainer explicitly accepts and records the exception.

The canonical strict gate runs on Linux. A Windows developer runs the native Windows gate before handover. The PBI remains incomplete until the canonical Linux strict gate also passes. This keeps the completion rule consistent without requiring Linux-only tools on Windows.

The native Windows gate includes formatting verification, MSVC warnings, an MSVC build, CTest, and Cppcheck. An optional Windows Clang and Ninja gate adds parallel Clang-Tidy, ASan, and UBSan where the selected toolchain supports them. Valgrind is not a Windows requirement.

3.2 Audit quality gate

The audit quality gate includes the strict gate plus:

• branch coverage generation
• Valgrind memory analysis
• runtime allocation verification of Pet Core, requiring zero heap usage
• clean rebuilds from empty build directories
• release support matrix verification

The audit gate runs:

• before a version release
• before closing a milestone
• after material ownership, storage layout, capacity, or lifetime changes
• when requested by the assigned PBI

Coverage and Valgrind do not need to run after every ordinary PBI.

3.3 Scope and documentation

Before a PBI is complete:

• its acceptance criteria must be checked
• relevant tests must be added or updated
• affected component knowledge files must be updated when required by agent rules
• progress and last development must be updated according to agent rules
• newly discovered deferred work must be recorded in the appropriate backlog or limitation file
• unrelated behaviour must not be added to the PBI

3.4 Portability status

Linux GCC and Linux Clang are the verified host toolchains for v0.1.0.

Windows compatibility is a design requirement from the first PBI. Project code, public headers, paths, CMake logic, tests, and developer workflows must avoid unnecessary POSIX assumptions. Windows must not be described as build tested until the project has been built and tested using an actual Windows developer environment or Windows CI runner.

Embedded portability is also a design requirement. It does not mean that v0.1.0 supports an embedded deployment. Pet Core must remain independent from operating system windows, filesystems, sockets, threads, sensors, and platform clocks.

MSVC is the native Windows compatibility compiler. Windows uses C17 mode to compile the C99 Core because MSVC does not provide a C99 language mode. GCC and Clang remain the strict C99 conformance toolchains. An optional Windows Clang and Ninja configuration owns compilation database analysis and sanitiser checks.

4. Quality tooling policy

4.1 Tool names

Project configuration and commands use unversioned executable names:

gcc
clang
clang-format
clang-tidy
run-clang-tidy
cppcheck
gcovr
valgrind
cmake
ninja
nm
python3

Local environments may select a specific installed version outside project files when required.

4.2 Formatting baseline

The initial .clang-format configuration is:

Language:        C
BasedOnStyle:    LLVM
IndentWidth:     4
UseTab:          Never
ColumnLimit:     100
PointerAlignment: Right
 
BreakBeforeBraces:          Attach
SpaceBeforeParens:          ControlStatements
SpaceAfterCStyleCast:       false
IndentCaseLabels:           true
BreakBeforeBinaryOperators: None
SortIncludes:               Never
 
KeepEmptyLinesAtTheStartOfBlocks: false
MaxEmptyLinesToKeep:              1
 
AlignConsecutiveAssignments:
  Enabled:          true
  AcrossEmptyLines: false
  AcrossComments:   false
  AlignCompound:    true
  PadOperators:     false
 
AlignConsecutiveDeclarations:
  Enabled:          true
  AcrossEmptyLines: false
  AcrossComments:   false

4.3 Clang-Tidy baseline

The initial .clang-tidy configuration is based on:

Checks: >
  clang-analyzer-*,
  bugprone-*,
  cert-*,
  misc-*,
  performance-*,
  portability-*,
  readability-*,
  -readability-magic-numbers,
  -readability-identifier-length,
  -readability-function-cognitive-complexity,
  -readability-braces-around-statements,
  -misc-include-cleaner,
  -bugprone-easily-swappable-parameters,
  -performance-enum-size
 
WarningsAsErrors: '*'
HeaderFilterRegex: '.*/(src|include|frontends|tests)/.*'
ExcludeHeaderFilterRegex: '.*/(build|_deps|third_party)/.*'
SystemHeaders: false
FormatStyle: file

Clang-Tidy must analyse only project translation units and project headers. Dependencies may still be parsed when required to understand project code, but diagnostics from system headers, generated files, fetched dependencies, and third-party code must not be treated as project findings.

The check list may be refined when a check is demonstrably unsuitable for C99 or conflicts with an explicit project rule. Disabling a check requires a short recorded reason.

5. Archived releases

Completed v0.1.0 PBIs are archived in release v0.1.0. That archive holds PBI-001 through PBI-034 with their outcomes, included work, acceptance criteria, and dependencies, grouped by epic E01 through E07.

Completed v0.2.0 PBIs are archived in release v0.2.0. That archive holds PBI-035 through PBI-063 with their outcomes, included work, acceptance criteria, and dependencies, grouped by epic E08 through E16.

Completed v0.3.0 PBIs are archived in release v0.3.0. That archive holds PBI-064 through PBI-085 with their outcomes, included work, acceptance criteria, and dependencies, grouped by epic E17 through E23.

PBI identifiers continue after PBI-085. They are permanent and are not reused, so a future release never restarts the sequence.

6. Release v0.4.0 PBIs

The release goal and expected capabilities are recorded in milestones. The epics are recorded in epics. The architecture is recorded in architecture for v0.4.0. PBI identifiers continue from PBI-086.

A new PBI is added under its epic heading and follows the structure in section 2, the shared Definition of Done in section 3, and the quality tooling policy in section 4.

E24 v0.4.0 architecture and release scope

PBI-086 Accept the v0.4.0 version architecture [+]

Epic: E24 v0.4.0 architecture and release scope

Outcome: The v0.4.0 release has an accepted architecture document that defines the save format, the validation rules, the Core and storage ownership split, the host policy, and the support-claim limits before implementation begins.

Included work:

• review docs/arch/arch-v0.4.0.md against the milestone and the epic map
• keep the required arc42 top level structure
• confirm that the Core owns the format and that storage owns platform access
• confirm that no file, path, stream, or platform interface appears in the Core surface
• confirm that the rejection order leaves a destination world untouched on every failure
• confirm that the support matrix separates hosted file evidence from embedded and device evidence
• mark the document accepted and link it from the milestone entry

Acceptance criteria:

• every required architecture section exists
• the format table, the validation rules, and the rejection order are recorded
• the architecture states that the Core names no platform interface
• the architecture records components/storage ownership and the hosted build selection
• the architecture distinguishes hosted file evidence from embedded and device evidence
• the milestone entry links the accepted document and the release status reflects it

Dependencies: None

PBI-087 Record the compatibility promise and the excluded time semantics [+]

Epic: E24 v0.4.0 architecture and release scope

Outcome: The promise the project makes about format version 1, and the deliberate absence of wall-clock time, are written down where a later release will look for them.

Included work:

• record that version 1 is written and that only version 1 is read
• record that no migration, downgrade, or forward compatibility is promised
• record that a development build payload is not a supported artefact
• record why a wall-clock stamp and catch-up behaviour are excluded from the format
• open the limitation entry for the absent time handling with its future owner
• update roadmap or idea notes that conflict with the accepted architecture

Acceptance criteria:

• the compatibility promise is stated rather than implied
• the exclusion of wall-clock time carries its technical and product reason
• the limitation register holds the absent time handling with a linked owner
• no forward compatibility or migration behaviour is described as available
• no planning note contradicts the accepted architecture

Dependencies: PBI-086

Superseded in part by PBI-102. The compatibility promise stands as recorded. The excluded time semantics did not, and PBI-102 reversed that exclusion within the same epic. This entry keeps its original wording, because it records what was decided at the time rather than what is true now.

PBI-102 Adopt the wall-clock stamp and the bounded absence semantics [+]

Epic: E24 v0.4.0 architecture and release scope

Outcome: What the specification and the general architecture ask for regarding time between sessions is designed into v0.4.0 before the format exists, rather than deferred behind a format revision.

Included work:

• reverse the recorded exclusion of a wall-clock stamp and catch-up behaviour
• decide the stamp field, its unit, its epoch, and the value that means unknown
• decide how the absence is derived, bounded, and applied, and what it must never do
• decide PET_ABSENCE_MAX_MS and record why it is separate from PET_TIME_DELTA_MAX_MS
• keep a host without an absolute time source fully supported, including one that gains a clock later
• write the ADR for the decision and its alternatives
• update the version architecture, the milestone, the epic map, and the affected backlog entries

Acceptance criteria:

• the payload carries a host-supplied UTC save stamp with a documented unknown value
• the Core reads no clock, and both wall-clock values arrive as explicit parameters
• a load adds a bounded absence to simulation time and replays no missed update
• a backwards, equal, wrong, or extreme clock produces a clamped absence rather than a failure
• an implausible stamp is never a rejection reason
• a host with no clock is described as supported rather than degraded, and needs no Core change when it gains one
• the ADR records the alternatives, including the exclusion this decision reverses
• SPEC-FR-015 and SPEC-FR-016 appear in the version architecture requirement mapping
• no document still describes the wall-clock stamp as excluded

Dependencies: PBI-087

E25 Core save format and encoder

PBI-088 Define the save payload format [+]

Epic: E25 Core save format and encoder

Outcome: The byte layout of format version 1 is decided, recorded, and justified against its alternatives, so that every later reader on any platform has one definition to follow.

Included work:

• fix the magic value, the format version field, and the field order
• fix the width, signedness, and byte order of every field
• fix the name encoding, including the length field and the padding rule
• fix the save stamp field, its unit, its epoch, and its unknown value
• select the integrity check and record why it was chosen over the alternatives
• record which world fields are encoded and which are derived by the loader
• write the ADR for the format, the integrity check, and the compatibility promise

Acceptance criteria:

• every payload field has a documented offset, width, and encoding
• every payload of format version 1 has one documented length
• the marker that describes storage rather than the pet is derived and not encoded
• the save stamp is documented as host-supplied, never derived and never corrected
• the integrity check is described as damage detection and not as tamper protection
• the ADR records the alternatives that were considered and the reason for the choice
• the recorded layout matches the format table in the version architecture

Dependencies: PBI-086, PBI-102

PBI-089 Implement the payload encoder [+]

Epic: E25 Core save format and encoder

Outcome: Pet Core turns a valid world into a complete payload in caller-owned storage, using explicit field-by-field encoding that no compiler layout decision can reach.

Included work:

• add include/pet/save.h with the capacity, the format version, and pet_world_save
• add PetWallClockMs and PET_WALL_CLOCK_UNKNOWN to the public types
• include the new header from include/pet/pet.h
• implement the encoder and the integrity check without a lookup table
• validate the source world before anything is written
• reject a capacity below the format length before anything is written
• add the operation to the runtime allocation probe
• add encoder tests over the complete supported state, including capacity and null handling

Acceptance criteria:

• a world is encoded field by field, with no structure storage copied into the payload
• the produced payload matches the recorded format byte for byte
• the supplied wall-clock value is written unchanged, including the unknown value
• an invalid source world or an insufficient capacity is rejected and produces no payload
• the operation performs no dynamic allocation and retains no caller pointer
• the public header compiles alone under the self-containment check
• the allocation probe exercises the operation and reports no allocation
• the Core archive still names no file or allocation dependency

Dependencies: PBI-088

E26 Core load validation and restore

PBI-090 Implement the payload decoder and candidate validation [+]

Epic: E26 Core load validation and restore

Outcome: Pet Core accepts a payload only when every structural and semantic rule holds, and a rejected payload leaves the destination world byte for byte unchanged.

Included work:

• implement pet_world_load and the decoder, reporting the applied absence through an optional output, because nothing outside the Core can derive it
• apply the rejection order for magic, version, length, integrity, fields, and world invariants
• add PET_ABSENCE_MAX_MS to the public types, where the absence rule first uses it
• derive the bounded absence from the two wall-clock values and apply it to the candidate
• build the candidate world in Core-owned automatic storage and validate it before assignment
• derive the initialised marker rather than decoding it
• add the operation to the runtime allocation probe
• add round-trip tests over worlds that were updated and acted upon, not only initialised
• add absence tests over unknown, equal, backwards, ordinary, and extreme wall-clock pairs
• add rejection tests for every documented failure class, each asserting an untouched destination

Acceptance criteria:

• a payload produced by the encoder restores a world that compares byte for byte with the original when no absence applies
• the round trip holds after updates and actions
• an unknown stamp on either side produces no absence
• an absence advances simulation time only, leaving the update count unchanged
• a backwards or equal clock produces a zero absence rather than a failure
• an absence beyond PET_ABSENCE_MAX_MS is clamped to it
• a candidate that would overflow the world clock is rejected with the destination untouched
• an implausible save stamp is never a rejection reason
• wrong magic, unknown version, wrong length, and failed integrity checks are rejected
• out-of-domain activity, expression, name length, and name padding are rejected
• a payload whose dwell stamps or update count exceed its elapsed time is rejected
• every rejection leaves the destination world byte for byte unchanged
• the destination is written once, after every check has passed
• the operation performs no dynamic allocation and retains no caller pointer
• the allocation probe exercises the operation and reports no allocation

Dependencies: PBI-089

PBI-091 Decide the error surface for an unsupported format version [+]

Epic: E26 Core load validation and restore

Outcome: A host can tell a payload it cannot support from a payload that is damaged, or the project records why it deliberately does not distinguish them.

Included work:

• decide whether an unsupported format version needs its own PetStatus value
• weigh the cost of widening a public enumeration against the value of the distinction
• place the identification checks ahead of any length rule that belongs to one version
• implement the decision, including every switch over PetStatus if the enumeration grows
• record the decision and its reason in the version architecture
• add tests for the chosen behaviour

Acceptance criteria:

• an unsupported format version produces a documented and tested result
• a payload of an unsupported version is reported as unsupported even when its length is not the length this version expects
• every exhaustive switch over PetStatus handles the surface as it stands after the decision
• the version architecture records the decision and closes it in the open decision table
• the headless status reporting continues to name every reachable status
• no unsupported version is interpreted rather than rejected

Dependencies: PBI-090

E27 Storage boundary and desktop implementation

PBI-092 Define the storage contract [+]

Epic: E27 Storage boundary and desktop implementation

Outcome: A frontend-neutral contract describes how a payload reaches a platform and returns from it, without describing what a payload means.

Included work:

• add components/storage with its contract header and build file
• define the read and write operations and their outcome values
• define the context rule, the name rule, and the buffer ownership rule
• follow the shape already established by the asset reader contract
• keep the component free of Core, app, frontend, and format dependencies

Acceptance criteria:

• the contract carries bytes without inspecting them and owns no format knowledge
• the outcomes report why a payload could not be delivered rather than how a platform failed
• names arrive resolved, so an implementation joins nothing and interprets no separator
• the component compiles with no implementation selected
• the public header compiles alone under the self-containment check
• the include boundary check accepts the new component

Dependencies: PBI-086

PBI-093 Implement the desktop storage over standard C file operations [+]

Epic: E27 Storage boundary and desktop implementation

Outcome: A hosted implementation carries payloads to and from files without ever leaving a partially written payload where a valid one used to be.

Included work:

• add src/desktop/storage_stdio.c and the PET_STORAGE_STDIO build selection, off for cross builds
• write through a temporary file beside the target, then replace the target
• attempt replacement with a single rename first and fall back only when it fails
• mark the unverified platform path with a TODO comment carrying its technical reason
• write the ADR for the write and replacement strategy
• add implementation tests including replacement of an existing file and a failed write
• correct the stale @file path in components/assets/src/desktop/reader_stdio.c

Acceptance criteria:

• the implementation is a build selection that defaults off for a cross build
• a write does not modify the target until a complete temporary file exists
• a failed write leaves any previous payload intact
• the temporary file is created beside the target rather than in a system location
• the unverified fallback carries a TODO with its reason and claims no platform support
• the ADR records the alternatives and the reason for the choice
• the corrected file header matches the path the file actually has

Dependencies: PBI-092

PBI-094 Add the storage test double and contract tests [+]

Epic: E27 Storage boundary and desktop implementation

Outcome: Every test that is not about the hosted implementation can exercise storage without touching a filesystem.

Included work:

• add a memory-backed double under the component test doubles, mirroring the asset reader double
• add contract tests that both the double and the hosted implementation satisfy
• cover the missing, too large, and failed outcomes
• keep the double usable by app tests

Acceptance criteria:

• the double satisfies the same contract tests as the hosted implementation
• the contract tests run without a writable working directory
• every outcome value is produced by at least one test
• the double is not linked into a production target

Dependencies: PBI-092

PBI-095 Record embedded build evidence for the storage contract [+]

Epic: E27 Storage boundary and desktop implementation

Outcome: The embedded build compiles the storage boundary with no implementation selected, and the resulting gap is recorded as a gap rather than as support.

Included work:

• add the component to the ESP-IDF build through the shared build interfaces
• confirm that the hosted implementation is excluded from the cross build
• run the embedded boundary check over the new sources
• open the limitation entry for the absent non-volatile implementation with its future owner
• record the evidence in the version architecture

Acceptance criteria:

• the cross toolchain compiles the contract and no implementation
• the embedded boundary check holds over the new sources
• the support matrix claims no embedded storage capability
• the limitation register holds the absent implementation beside the embedded asset gap
• no firmware target gains a storage dependency in this release

Dependencies: PBI-093

E28 Application persistence options

PBI-096 Add persistence options to the headless application [+]

Epic: E28 Application persistence options

Outcome: The headless diagnostic application can restore a world before its scenario and save one after it, when an operator supplies a path.

Included work:

• add argument parsing, which the application does not have today
• add the load and save options and their path handling
• add the wall-clock option, defaulting to the unknown value so a run stays reproducible
• make a load replace initialisation rather than follow it
• report load and save failures through the existing app diagnostic ranges
• add option parsing and diagnostic mapping tests

Acceptance criteria:

• the application reads and writes nothing when its options are absent
• a requested load that cannot be satisfied is a startup failure rather than a silent new world
• a restored world replaces initialisation rather than overwriting an initialised world
• failures map to the documented diagnostic ranges and exit statuses
• the existing scenario output is unchanged when no option is supplied
• the application reads no clock unless an option asks it to, so a run stays reproducible
• no default path or implied file name is introduced

Dependencies: PBI-090, PBI-093

PBI-097 Add persistence options to the desktop application [+]

Epic: E28 Application persistence options

Outcome: The desktop reference application accepts the same explicit options, and keeps starting a new world when it is given none.

Included work:

• add the load and save options to the existing argument parsing
• supply the wall clock from the standard C time facility, with the option to override it
• reuse the load and save flow established by the headless application
• keep the existing lifecycle, including quit handling, unchanged
• add option parsing and diagnostic mapping tests

Acceptance criteria:

• the application reads and writes nothing when its options are absent
• the application still starts a new world when no option is supplied
• it does not save on quit, on a timer, or on any implicit event
• failures map to the documented diagnostic ranges and exit statuses
• the SDL frontend is unchanged

Dependencies: PBI-096

PBI-098 Add the process-level round trip check [+]

Epic: E28 Application persistence options

Outcome: The gate proves that a world survives a process boundary rather than only a function boundary.

Included work:

• add a check that runs the headless application to save a world and runs it again to load that world
• assert that the reported state matches across the two runs
• add a second pair of runs that supplies both wall-clock values and asserts the expected absence
• keep the check independent of SDL and of a real display driver
• register the check so the required gate runs it

Acceptance criteria:

• the check writes and reads a real file through the hosted implementation
• the two runs report the same state when no wall clock is supplied
• a supplied wall-clock pair moves the restored world’s clock by exactly the expected absence
• the check fails when the payload is removed or damaged between the runs
• the check runs in the headless composition
• the check leaves no file behind in the source tree

Dependencies: PBI-096

E29 Release verification and hardening

PBI-099 Record the release limitations and their owners [+]

Epic: E29 Release verification and hardening

Outcome: Everything the release deliberately did not do is written down with the work that would undo it.

Included work:

• record the absent non-volatile storage implementation
• record the absent handling of time spent closed
• record that the desktop application does not preserve the pet across launches
• link each limitation to a future release, epic, or PBI
• link the session continuity entry to LIM-008, because the asset root and the save location are one hosted location policy with two clients
• review the carried limitations that this release touched

Acceptance criteria:

• every new limitation has an identifier, an impact, and a linked owner
• no limitation is described as resolved without evidence
• carried limitations that the release did not touch keep their original wording
• the session continuity limitation names the future product frontend as its owner
• the hosted location policy is described once and linked from both entries rather than twice
• the register agrees with the version architecture

Dependencies: PBI-095, PBI-098

PBI-100 Run the release audit gate and record the evidence [+]

Epic: E29 Release verification and hardening

Outcome: The release has one evidence file that records what was run, what passed, and what was not available.

Included work:

• run the audit gate from a clean tree over the supported compositions
• run the ESP-IDF build with the storage contract compiled and no implementation selected
• record the round-trip, rejection, allocation probe, and boundary results
• record the process-level round trip
• write docs/releases/v0.4.0/evidence.md following the release process structure
• record any check that could not run as unavailable rather than as passing

Acceptance criteria:

• the audit gate result comes from a clean tree
• every gate step and release check has a recorded result
• the allocation probe covers both new public operations and reports no allocation
• unavailable checks are recorded as unavailable with their reason
• the evidence belongs to the commit that will be tagged
• no check is reported as passing unless it was run

Dependencies: PBI-098, PBI-099

PBI-101 Harden the release documentation and support claims [+]

Epic: E29 Release verification and hardening

Outcome: Every claim the release makes is bounded by what the evidence shows.

Included work:

• review the support matrix against the recorded evidence
• confirm that no Windows claim changed
• confirm that no embedded storage or device runtime capability is claimed
• update the version architecture where implementation differs from its documented design
• tick the milestone exit criteria that the evidence supports
• close the open decisions that the release resolved

Acceptance criteria:

• support claims match executed evidence exactly
• no excluded capability is described as available
• the version architecture reflects the implemented system
• resolved open decisions are closed and unresolved ones keep an owner
• the milestone exit criteria are ticked only where evidence supports them
• the release is ready for the documentation rollover in the release process

Dependencies: PBI-100

7. Deferred backlog areas

The following areas remain outside the active PBI set:

• durable saves
• digital adapters such as Git activity
• physical sensor adapters
• networking and local device discovery
• multiple pets and household relationships
• long-term traits, marks, memories, and maturity
• embedded display runtime and hardware validation beyond the v0.3.0 ESP-IDF build proof
• embedded asset storage, a generated asset converter, and an embedded asset reader
• a Core allocator or arena without evidence from a later version requirement
• Windows build verification without a Windows environment or runner

These areas must be introduced through a version architecture document and its PBIs rather than being added opportunistically to the current release.

A visual frontend was deferred throughout v0.1.0 and is the subject of v0.2.0, so it is no longer listed here. The list as it stood at the close of v0.1.0 is preserved in release v0.1.0.

The list as it stood at the close of v0.2.0 is preserved in release v0.2.0, and the list at the close of v0.3.0 is preserved in release v0.3.0.