Definition of Done

Project / feature: Tamagotchi Virtual Pet
Generated: 2026-09-18
Derived from: requirements ✓ · design ✓ · qa —

A work item is Done only when every gate below is satisfied.

PR Checklist

Everything below needs a person. CI-enforced gates are not listed — a passing build is their evidence.

ADR-001 — implementation conforms to “Permanent terminal status with no disposition”.
ADR-002 — implementation conforms to “Windows ships first for v1, with macOS and Linux staged after it”.
ADR-003 — implementation conforms to “Tauri — a Rust core with an OS-supplied system webview”.
ADR-004 — implementation conforms to “One committed generation retained”.
Documentation updated for FR-001, FR-002, FR-003, FR-004, FR-005, FR-006, FR-007, FR-008, FR-010, FR-011, FR-012.

Functional Acceptance Gates

One gate per functional requirement. The linked file holds the authoritative acceptance criteria; they are referenced here, never duplicated.

NFR Fitness Gates

The quality attribute scenario’s response measure is the pass/fail oracle for each gate below.

NFR-001 — Offline-elapsed decay matches the reference decay model (must) [verification: test] Response measure: For at least 20 log-spaced intervals across 1 minute to 30 days, each resulting stat is within ±1 stat unit of the reference decay model’s value for the same interval and starting state; 0 out-of-range results. For at least 5 non-positive intervals (T = 0 and T < 0), each stat after launch equals its last-committed value exactly — 0 stats increased and 0 stats decayed. Scenario: The application launches after an elapsed interval T since the last committed save, where T may be positive or, if the wall clock has moved backward, zero or negative. on The offline decay computation and the pet state model. under Normal operation; the positive matrix spans T from 1 minute to 30 days, and the clock-regression matrix covers T at exactly zero and T negative (manual clock change, DST shift, NTP correction); a valid save file is present; elapsed time is derived from wall-clock timestamps.. Source: .sdlc/requirements/non-functional/NFR-001-offline-elapsed-decay-matches-the-reference-decay-model.md
NFR-002 — Idle CPU and memory footprint of the always-on process (must) [verification: test] Response measure: On the designated reference machine, mean CPU <= 1% of one core and peak resident memory <= 150 MB across the 10-minute window; no monotonic growth — final RSS within 5% of the RSS sampled at the 1-minute mark. A run on any machine other than the recorded baseline is not evidence either way. Scenario: The application sits in an idle steady state — pet alive, window open, no owner input, no care action in progress. on The complete delivered runtime — the application process, any child or helper processes, and whatever rendering or background timer machinery the chosen implementation uses. under The project’s designated reference machine under normal desktop use. That machine is a single named baseline whose hardware and OS specification has not yet been recorded (Q-5); this requirement depends on it normatively rather than assuming one. A continuous 10-minute observation window; measurements taken from OS process accounting and summed across every process the application owns.. Source: .sdlc/requirements/non-functional/NFR-002-idle-cpu-and-memory-footprint-of-the-always-on-process.md
NFR-003 — Keyboard-only and screen-reader operability of the full care loop (must) [verification: test] Response measure: 100% of interactive controls keyboard-reachable and operable with a visible focus indicator; 100% of mood and health states carry a non-color-dependent textual equivalent exposed to the accessibility API; contrast >= 4.5:1 for text and >= 3:1 for non-text state indicators; zero critical or serious violations from an automated accessibility scan; a scripted screen-reader walkthrough of all four care actions completes with 0 unlabeled or unreachable controls. Scenario: The owner navigates to and performs each of the four care actions — feed, play, clean, put to sleep — and reads the pet’s current mood and health state. on The application user interface — all interactive controls, focus order and focus indication, the mood expression, and any status or notification surface. under Normal operation, on each supported desktop platform using that platform’s native accessibility stack and screen reader.. Source: .sdlc/requirements/non-functional/NFR-003-keyboard-only-and-screen-reader-operability-of-the-full-care-loop.md
NFR-004 — Crash-safe atomic persistence and recovery (must) [verification: test] Response measure: 200 fault-injection trials yield 100% launches into a valid pet state, 0 corrupt loads, 0 unhandled exceptions. In 100% of those trials where a committed state existed before the kill, that committed state is the state restored; recovery to a default pet occurs in 0% of such trials. 50 clean restart cycles restore the exact prior state 100% of the time. Scenario: The process is killed at an arbitrary point in its lifetime, including part-way through writing the save file. on The state persistence layer and the save file on local disk. under Normal operation with fault injection, covering saves triggered both by a stat change and by application close; local disk, no network involved.. Source: .sdlc/requirements/non-functional/NFR-004-crash-safe-atomic-persistence-and-recovery.md
NFR-005 — Local-only handling of pet and owner data (must) [verification: test] Response measure: 0 outbound TCP, UDP or DNS attempts attributable to the application across a >= 30 minute capture that exercises every functional requirement in this set; 100% of those requirements pass with the network interface disabled; pet and owner data written only inside the application’s local data directory and its quarantine location; any future opt-in telemetry path is off by default and inert until explicitly enabled by the owner. Scenario: The owner exercises every functional requirement in this set — the four care actions, wake, save and load, offline decay, mood display, sickness and terminal progression, local reminders, default-pet initialization, and save-file quarantine — with no opt-in granted. on The whole application process, its dependencies, its local data directory, and the quarantine location. under Normal operation on a machine with all traffic captured at the OS network interface, including a run with the network interface disabled entirely.. Source: .sdlc/requirements/non-functional/NFR-005-local-only-handling-of-pet-and-owner-data.md
NFR-006 — Single-codebase support for all three desktop targets (must) [verification: test] Response measure: The acceptance suite for every functional requirement in this set passes unmodified on all three platforms in CI — the quarantine move and the across-close interval derivation included, not excepted; 0 platform conditionals outside the platform-adapter layer; 0 recorded design decisions that foreclose any of the three targets. Scenario: The same source tree is built, packaged and run on Windows, on macOS, and on Linux. on The whole codebase, and in particular the platform-touching seams — local data directory paths; the quarantine location and the byte-identical file move into it (FR-012), whose move semantics, path conventions and file-locking behaviour all differ per platform; wall-clock and timer access, including the elapsed-interval derivation across an application close that FR-011 and FR-002 depend on; native notifications; accessibility integration; and rendering. under Current supported OS versions of each of the three targets; the v1 ship order is deliberately not fixed by this requirement.. Source: .sdlc/requirements/non-functional/NFR-006-single-codebase-support-for-all-three-desktop-targets.md
NFR-007 — Local diagnostic logging of decay and lifecycle events (should) [verification: test] Response measure: 100% of decay computations and lifecycle transitions produce exactly one such record; replaying >= 100 recorded decay events through the reference model reproduces each logged post-state with 0 mismatches; total log size stays under a fixed rotation cap indefinitely; 0 outbound transmissions of log content. Scenario: A decay computation runs, or a lifecycle transition occurs — launch, save, load, save-file quarantine, mood change, onset of sickness, terminal transition, sleep and wake. on The local diagnostic log on disk. under Normal operation at the default log level, with no network available.. Source: .sdlc/requirements/non-functional/NFR-007-local-diagnostic-logging-of-decay-and-lifecycle-events.md
NFR-008 — Offline-decay computation cost does not scale with the length of the absence (must) [verification: test] Response measure: Over at least 20 runs per arm, p95 computation time for a 30-day elapsed interval is <= 5x the p95 for a 1-hour elapsed interval, both measured on the same machine in the same session over the same starting state. One run is the total time of a batch of >= 1,000 repetitions divided by the repetition count, with the batch size raised until the short-arm batch total exceeds 10 ms, so neither arm is taken near the platform timer resolution. Scenario: The decay computation is invoked directly with a starting pet state and an elapsed interval, at the two interval lengths the comparison uses — 1 hour, and the 30-day worst case that FR-002 permits and NFR-001’s test matrix already exercises — and each invocation is repeated within one measurement session. on The offline-decay computation as an independently invocable unit — the function that maps a starting pet state and an elapsed interval to a decayed pet state — exercised directly rather than through a launch, so that it can be repeated within one measurement session. The same computation on the launch path is what NFR-009 bounds in absolute terms. under Any single development or CI machine, with both arms measured in the same session on the same hardware so the comparison is internal; no save file is read and no application launch occurs — the starting pet state is supplied directly to the computation; no reference-machine specification required, and therefore no dependency on Q-5.. Source: .sdlc/requirements/non-functional/NFR-008-offline-decay-computation-cost-does-not-scale-with-the-length-of-the-absence.md
NFR-009 — Offline-decay computation time on the launch path (should) [verification: test] Response measure: For a 30-day elapsed interval, the computation completes in <= 250 ms at p95 and <= 500 ms at maximum across 20 cold-start runs on the designated reference machine. The measure is not evaluable until Q-5 records that machine’s specification; a measurement taken against an unrecorded baseline is unassessed, not passing. Scenario: Launch occurs after a 30-day offline interval — the worst case that NFR-001’s test matrix already exercises — requiring the full elapsed decay to be computed and applied before the pet can be shown. on The offline-decay computation on the launch path, between the completion of the committed-save read and the first render of the pet. under Cold start on the project’s designated reference machine (specification pending Q-5) under normal desktop use, with a valid committed save file present and no other application load contrived.. Source: .sdlc/requirements/non-functional/NFR-009-offline-decay-computation-time-on-the-launch-path.md

Architectural Conformance Gates

Decisions the implementation must not quietly reverse, and the dependency edges the design declared.

Documentation Requirements

Public-facing behaviour of every must functional requirement is documented: FR-001, FR-002, FR-003, FR-004, FR-005, FR-006, FR-007, FR-008, FR-010, FR-011, FR-012.
Operational NFRs have runbook or configuration notes: NFR-005 (Security), NFR-004 (Reliability), NFR-007 (Extension).
Every implemented artifact carries status: implemented (or verified) and a populated traces_to.code.

Deployment / Operational Readiness

Security NFR gates pass before release: NFR-005.
Reliability targets are met or have an accepted waiver: NFR-004.
Observability is in place for the response measures asserted above.
Constraints and business rules hold in the deployed configuration: BR-001, BR-002, CON-001, CON-002, CON-003.

Generated from the artifact sets under .sdlc/. Change the source artifact and regenerate; do not edit this file.