Kuberan Grocery Store Operating System

A development-ready Software Requirements Specification for a simple, local-first grocery POS and store-management platform serving Canadian stores with approximately CAD $10–20 million in annual sales.

DocumentKUB-SRS-001

Version1.0 Baseline

DateAugust 7, 2026

StatusReady for estimation

Implementation interpretation. The HTML suite is an interactive product prototype and specification. “Shall” statements in this SRS are binding development requirements once approved. The production Flutter, Java/Spring Boot, SQLite, device-driver, payment and deployment code remains roadmap work and must pass the acceptance gates defined here.

1. Document control

Ownership and approval

Product owner: Kuberan product leadership
Business approvers: grocery owner, store manager, finance lead
Technical approvers: engineering lead, security lead, QA lead
Specialist reviewers: accountant/tax advisor, payment integrator, privacy advisor, accessibility reviewer

Change policy

Each approved change receives a requirement ID, rationale, owner, target version, acceptance criteria and impact assessment. Completed sales, tenders, inventory, stored value, cash and accounting evidence are corrected with explicit reversal or adjustment—not destructive history edits.

Precedence: this SRS → approved architecture decisions and API/event contracts → acceptance test catalogue → UI prototypes → original handoff and legacy prototype. The original documents remain historical context.

2. Product vision and success measures

Vision

Kuberan lets non-technical grocery operators run checkout, inventory, purchasing, people, cash, finance, food safety and store infrastructure through plain-language workflows. Store trading continues locally when internet or Wi-Fi is unavailable. AI reduces typing and explains evidence but never silently changes controlled ledgers.

Business outcomes

Fewer checkout and cash exceptions
Lower stock loss and out-of-stocks
Recovered vendor credits
Faster, evidenced month-end
Safer recalls and cold chain

User outcomes

One obvious next action
Offline work without re-entry
Role-appropriate information
Source-backed explanations
Guided recovery during failure

Release measures

≥99.95% lane availability during open hours
p95 local scan-to-line ≤150 ms
Zero duplicate financial effects in retry testing
Verified restore within 60 minutes
≥90% pilot-task completion without help

3. Scope and product boundaries

Included

Checkout and lanes; tills and cash office; products, pricing and labels; inventory, receiving, fresh production and recalls; purchasing and vendor claims; staff scheduling/time/payroll handoff; customer, loyalty, stored value and privacy; bank reconciliation, AP evidence and HST working reports; loss prevention; maintenance; emergency continuity; appliance setup; synchronization; local AI; security, audit, migration, training and support.

Integrated or later unless selected

Full general ledger, payroll calculation and employee banking, payment acquiring, e-commerce fulfilment, pharmacy, fuel, lottery, tobacco, alcohol compliance, advanced warehouse management and enterprise multi-entity consolidation. Kuberan may integrate these without misrepresenting them as core V1 capabilities.

4. Users, roles and permissions

Cashier

Builds sales, tenders, receipts and approved returns; sees minimal customer and employee data.

Supervisor

Controls lane exceptions, overrides, pickups and shift/till completion within limits.

Receiver / Department Lead

Receives, counts, produces, labels, records temperatures, waste and corrective action.

Buyer / AP / Bookkeeper

Orders, follows claims, matches documents, reconciles banks and prepares exports.

Store Manager / Owner

Controls people, safety, cash, risk, approvals, configuration and forward decisions.

Support / Security / Accountant

Receives explicitly scoped, time-limited access with full audit and separation of duties.

Permission rule: deny by default; assign by role and store; apply monetary/action limits; require fresh approval for high-risk work; never use AI as the approving identity.

5. Critical end-to-end journeys

Open store
Safety, server, lanes, safe, staffing and exceptions

Trade locally
Scan, price, tender, receipt and offline queue

Receive and replenish
Cold chain, quantity, lot, cost, claim and shelf

Close and reconcile
Blind tills, batches, deposit, bank, stock and HST

Recover safely
Incident, replacement box, replay, reconcile and resume

6. System architecture

Flutter clientsRegister, handheld, manager, owner; SQLite + outbox

Store LANTLS device identity, discovery and local availability

Store serverJava/Spring Boot, store SQLite, ordered synchronization and device control

Kuberan License CloudMandatory registration, signed entitlement leases, downloads and account administration; never in the sale path

Optional providersOpenAI, Anthropic, billing, payroll, accounting and future multi-store services

Local-first command path

Validate command against cached policy and signed local entitlements.
Commit business record and outbox event in one client SQLite transaction.
Render success from local durable state.
Send immutable event with globally unique ID and payload hash.
Server validates, applies exactly once, assigns sequence and returns result.
Client applies ordered changes and advances cursor atomically.

Cloud separation

Registration and licensing require the Kuberan License Cloud, but checkout, tenders, inventory and other store-critical operations do not call the cloud. The store box caches a signed, time-bounded entitlement lease and locally enforces register/device/feature limits. Cloud or internet failure enters an explicit grace policy rather than immediately stopping trade.

7. Functional requirements

The catalogue below is filterable and constitutes the baseline delivery scope. P0 blocks the version; P1 is required before general availability unless explicitly waived; P2 improves the product and is scheduled by milestone.

8. Data and ledger requirements

Authoritative ledgers

Sale, sale line, tender attempt and receipt
Till, safe, cash movement, terminal batch and deposit
Inventory movement, count, lot, expiry, production and waste
Purchase order, receipt, invoice, claim and vendor credit
Points, gift card and store-credit value movements
Time punches, adjustments, approvals and payroll exports
Bank evidence, matches, HST workpapers and close approvals
Security, permission, device, AI and sensitive-access audit

Shared data policies

UUID/ULID-class origin IDs and stable external references
Money in integer minor units or documented fixed decimal
Quantity precision configured by UOM and department
UTC timestamp plus store business date/time-zone context
Effective-dated master data and permissions
Hash and immutable metadata for imported evidence
Retention, legal hold, anonymization and deletion policy by record type
No direct editing of completed controlled history

Core ownership and conflict rules

Client owns unacknowledged local work; server owns acknowledged shared state and global sequences. Financial and quantity ledgers merge by unique movement/event, not last-write-wins. Master data changes use version/base-version checks. Human queues resolve ambiguous customer merges, count conflicts, price overlaps, payment unknown states and document matches. Resolution itself is audited.

9. Non-functional requirements and capacity gates

Reference store load

Acceptance benchmarking shall model: up to 24 registers, 40 handheld/manager devices, 250,000 active SKUs/PLUs, 150,000 customer profiles, 75,000 sale lines/day, 1.5 million sync events/day including projections, 250 GB retained attachments, and 14 days of disconnected client operation.

Performance and resilience

Local barcode lookup p95 ≤100 ms; scan-to-visible-line p95 ≤150 ms; local sale completion p95 ≤500 ms excluding processor; server command p95 ≤300 ms at reference load; ordered catch-up of 100,000 events ≤15 minutes; cold appliance boot ≤5 minutes; RPO ≤15 minutes for off-box backup; RTO ≤60 minutes for replacement-box restoration.

10. AI and agent requirements

Execution choices

Disabled: all core workflows remain available
Local: supported model runs on store-controlled hardware without a provider key
Connected: store supplies an OpenAI or Anthropic API key
Hybrid: each agent has an explicitly selected local or connected provider
No silent provider switching or cloud fallback

Permitted agents

Invoice, receipt and bank-document extraction
Three-way-match and reconciliation suggestions
Order and markdown recommendations with evidence
Exception prioritization and plain-language explanation
Draft customer case summaries and training help
Semantic search across authorized store records

Prohibited autonomous actions

Posting tenders, inventory, cash or accounting entries
Sending POs or paying vendors without approval
Filing HST or representing tax/legal advice
Accusing or disciplining employees
Changing permissions, retention or security policy
Sending data outside the store without explicit policy

Provider and credential control: an authorized owner or administrator selects Local, OpenAI, Anthropic or Disabled; enters the provider API key through a masked setup flow; tests the connection; selects permitted models/agents; and configures data classes, retention, monthly spend/rate limits and network egress. The key is encrypted at rest on the store box, never sent to Flutter clients, never displayed again or written to logs, and can be rotated or revoked. Backups include the credential only under an explicit encrypted recovery policy. Core workflows remain available when AI is disabled, the key is invalid, a budget is exhausted or the provider is unavailable.

11. Security, privacy, accessibility and compliance

Payment boundary

Use certified EMV-capable terminals and tokenization/P2PE where available. Kuberan shall not store sensitive authentication data. Payment callbacks and inquiries are authenticated and idempotent. PCI scope and responsibility are documented with the integrator.

Platform security

Full-disk encryption, TLS, per-device certificates, revocation, secret storage, signed updates, rollback, secure boot where supported, vulnerability response, audit retention, least privilege and time-limited support access.

People and privacy

PIPEDA-aligned consent/purpose, access/correction, breach process and retention; CASL-aware marketing consent; AODA/WCAG 2.2 AA target for supported client surfaces; restricted HR, LP, health and privacy data.

12. External interfaces

Interface	V1 responsibility	Failure policy
Kuberan License Cloud	Mandatory owner registration, installation claim, signed entitlement lease, aggregate usage, downloads, plan/billing state and administrative actions	Initial activation needs connectivity; thereafter a cached lease and explicit grace policy preserve store operation
Payment terminal / processor	Initiate, inquire, reverse/refund, callback, batch reference	Unknown result blocks unsafe retry and enters recovery
Scanners, printers, scales, drawers, displays	Certified driver/profile matrix and guided tests	Degraded lane mode plus plain-language help
Payroll provider	Approved hours/earnings-code export and acceptance result	Reject employee/record without losing approved period
Accounting package	Versioned control-total export, not full GL	Record acceptance/rejection and corrections
Bank statements	CSV/OFX/QFX/PDF evidence import with preservation	Never silently skip or duplicate a source line
Vendor catalogues/documents	Import, PO delivery adapters, OCR/local extraction	Retain original and route uncertain fields to review
OpenAI / Anthropic AI API	BYO-key connection test, selected model/agent calls, usage/cost metadata and provider-specific error mapping	No silent fallback; core workflow continues without AI and work remains reviewable
Billing provider	Customer/subscription reference, checkout portal, invoice and payment-status webhook; no raw card storage in Kuberan	Billing outage does not interrupt checkout; license state changes follow notice and grace policy
Optional Kuberan services	Signed updates, support and future multi-store aggregation	Store continues to trade when unavailable

13. Migration, installation, training and go-live

Discover
Hardware, OS, network, drivers, integrations, policies

Map
Legacy IDs, data quality, balances and retention

Rehearse
Repeatable import, totals, restore and rollback

Certify
Role scenarios, hardware and continuity tests

Pilot
Limited lanes, hypercare, exit criteria and go-live

Mandatory control totals

Opening quantity and value by department; regular/promo prices and effective dates; customer/loyalty count and balances; gift-card/store-credit liability; open POs/receipts/claims/credits; vendor bills; employee/time-period totals; tills/safe/bank balances; historical transaction counts/value/tax; unresolved cases; source-to-Kuberan ID mapping. Any difference requires documented disposition before go-live.

14. Product roadmap, milestones and versions

V0.1 • COMPLETESpecification baseline

Consolidated SRS, review trace, licensing policy and interactive prototypes.

Scope and acceptance catalogue
Architecture and entitlement decisions
Prototype usability review

V0.2 • FOUNDATIONTechnical proof

Prove store and cloud architecture before broad development.

Store/cloud SQLite load and restore benchmarks
Sync, payment and signed-license lease simulators
Device PKI, entitlement signing and key-rotation spike

V0.5 • CONTROLLED PILOTTrade, stock and registration

One store, limited lanes and mandatory cloud registration with daily support.

Checkout, cash, inventory and purchasing
Owner account, installation claim and signed downloads
Starter plan, aggregate usage and device entitlements

V0.8 • OPERATIONAL PILOTWhole-store and paid licensing

Complete operational controls and commercial administration.

Safety, people, finance, customer and maintenance
Paid-plan/billing-provider adapter and transition notices
Super-admin License Manager and audited overrides

V1.0 • SINGLE-STORE GAProduction launch

Supportable appliance and License Cloud with security, continuity and SQLite schema-migration certification.

All P0/P1 acceptance and licensing gates
30-day stable store/cloud pilot
Runbooks, SLA, signing-key and billing recovery

V1.1 • ASSISTED INTELLIGENCEConfigurable local or connected AI

Agents can run locally, through a store-supplied OpenAI or Anthropic key, or remain disabled.

Provider/key onboarding, rotation and budgets
Model lifecycle and evaluation
Receipt, bank, order and exception assistance

V1.5 • MULTI-STOREOwner portfolio

Optional cloud aggregation and central catalogue while stores remain independent.

Organization/store licensing and portfolio views
Cross-store owner reporting
Controlled configuration distribution

V2.0–V5.x • SQLITE SCALEScale and harden SQLite

All clients, store servers and Kuberan-operated cloud services remain on SQLite through at least Version 5.x.

Measured writer, storage, integrity and restore optimization
Operational partitioning where benchmarks require it
No second-database adapter or database cutover work

15. Verification and release acceptance

Automated

Domain unit and invariant/property tests
Schema migration and backward-compatibility tests
Sync fault, replay, duplication and ordering simulation
Payment unknown/partial/reversal contract tests
Performance, storage growth and soak tests
Security scans, dependency/signature and permission tests
Flutter offline UI and accessibility automation

Operational

Role-based end-to-end scenario certification
Hardware matrix and power-loss testing
Backup restoration to replacement appliance
Migration rehearsal and control-total sign-off
Recall, emergency and one-person cash drills
Accounting/payroll export acceptance
AI evaluation, prompt-injection and no-AI fallback

GA gate: zero unresolved severity-1 defects; all P0 and approved P1 requirements passed; no duplicate effects across the fault suite; 30 consecutive pilot days without unplanned inability to trade; restore, security, migration, support and accessibility sign-off complete.

16. Operations, support and business continuity

The store box reports plain-language health for database, disk, backup, restore test, queues, clients, certificates, updates, hardware and AI. Support receives consented diagnostic bundles that redact or exclude customer/payment/HR content. Updates are signed, staged, reversible and blocked when compatibility or recovery prerequisites fail.

Target support model: severity 1 inability to trade—15 minute response, active restoration and replacement-box path; severity 2 material department/control impairment—1 business hour; severity 3 normal defect/question—next business day. Owners receive a printable failure card and an offline local runbook.

17. User-interface reference screenshots

These embedded references are captured from the interactive HTML prototypes and establish information hierarchy and workflow intent. Flutter implementation may adapt to platform conventions while preserving task order, visible controls, evidence and recovery states.

Kuberan complete feature workbench overview — **Complete feature workbench.** Application navigation, current health, workflow stages, exceptions, requirements and controlled decision panel.

Kuberan checkout with review and controls — **Checkout reference.** Fast first viewport, visible local/sync status and simple action hierarchy.

Kuberan food safety and recall workflow — **Food safety and recall.** Stop-sale, quarantine, notification, disposition and verified-close sequence.

Kuberan responsive product specification — **Responsive reading.** SRS and operational surfaces remain usable on smaller manager devices.

Screenshots are embedded in this HTML file after browser verification so the SRS remains portable and creates no separate image files.

18. Independent-review traceability

Business Owner: checkout and cash.
Resolved by CHK, CASH, FIN and emergency requirements plus V0.5/V0.8 gates.

Business Owner: receiving, recalls and fresh.
Resolved by INV, SAFE and FRESH requirements plus food-safety operational tests.

Business Owner: pricing, vendor claims and maintenance.
Resolved by PRICE, PO and MAINT requirement groups.

Business Owner: people, customers and owner decisions.
Resolved by STAFF, CUST, FIN and OWNER requirements and role-based training.

Business Owner: non-technical setup and AI control.
Resolved by SETUP, CONT, AI and security requirements plus owner-visible controls.

Technical Product Manager: payment states and synchronization.
Resolved by PAY and SYNC P0 requirements and V0.2 fault simulator.

Technical Product Manager: restore and capacity.
Resolved by NFR-CONT and NFR-CAP requirements with GA benchmark gates.

Technical Product Manager: security and migration.
Resolved by SEC and MIG groups, specialist approval and rehearsed rollback.

Technical Product Manager: pricing, inventory and finance invariants.
Resolved by deterministic PRICE, INV and FIN ledger/approval requirements.

Document conflicts and prototype maturity.
This SRS is the new source of truth; the review register remains the detailed audit.

Open the original 43-observation review register →

19. Engineering implementation blueprint

Architecture decision: Version 1 is a monorepo containing a Java modular monolith for each store box, a separately deployed Java cloud license service, and eight deployable Flutter applications built from shared Dart packages. Store-critical commands, ledgers, synchronization and authorization remain local. Registration, licensing and downloads use the cloud but are never placed in the checkout transaction path. Exact dependency patch versions are pinned in repository-controlled toolchain/version files and updated only through tested pull requests; this SRS remains version 1.0.

19.1 Repository and project-folder structure

kuberan/
├── docs/
│   ├── srs.html                         # This approved SRS
│   ├── architecture-decisions/          # Numbered ADR HTML files
│   ├── operations/                      # Install, backup, restore and support runbooks
│   └── ui-prototypes/                   # Approved HTML workflow references
├── contracts/
│   ├── openapi/                         # OpenAPI 3.1 REST contracts by API major
│   ├── events/                          # Versioned JSON Schemas for sync/domain events
│   ├── errors/                          # Stable problem codes and recovery guidance
│   └── compatibility/                   # Client/server/schema support manifest
├── server/
│   ├── settings.gradle.kts
│   ├── build.gradle.kts                 # Java 21 toolchain, common quality/test policy
│   ├── gradle/libs.versions.toml         # Pinned dependency versions
│   ├── app/                             # Spring Boot executable and module assembly
│   ├── platform/
│   │   ├── database/                    # SQLite connection, migrations, backup, integrity
│   │   ├── security/                    # Device PKI, sessions, permissions, secret vault
│   │   ├── sync/                        # Inbox, change log, cursor, snapshot and repair engine
│   │   ├── files/                       # Content-addressed attachments and evidence hashes
│   │   ├── observability/               # Health, audit, metrics and diagnostic bundle
│   │   └── integrations/                # Payment, payroll, accounting and AI provider ports
│   └── modules/
│       ├── identity/                    ├── catalog/       ├── pricing/
│       ├── sales/                       ├── payments/      ├── cash/
│       ├── inventory/                   ├── purchasing/    ├── food-safety/
│       ├── fresh-production/            ├── workforce/     ├── customers/
│       ├── finance/                     ├── loss-prevention/
│       ├── maintenance/                 ├── incidents/     └── reporting/
├── cloud/
│   ├── license-server/                  # Java/Spring Boot cloud application
│   │   ├── app/                         # HTTPS API and module assembly
│   │   ├── platform/                    # Identity, signing, email, billing and audit adapters
│   │   └── modules/
│   │       ├── accounts/                ├── organizations/ ├── stores/
│   │       ├── registrations/           ├── installations/ ├── licensing/
│   │       ├── entitlements/            ├── usage/         ├── billing/
│   │       ├── downloads/               ├── notifications/ └── administration/
│   ├── database/                        # Initial cloud SQLite, migrations and backup policy
│   └── deployment/                      # TLS, signing-key custody, backup and single-instance service
├── clients/
│   ├── pubspec.yaml                     # Native Dart workspace and pinned SDK range
│   ├── toolchains/flutter.version       # Approved Flutter stable release
│   ├── apps/
│   │   ├── register/                    # Lane checkout and till app
│   │   ├── store_ops/                   # Receive, stock, fresh, safety, labels, assets
│   │   ├── manager/                     # Daily command, cash, purchasing, finance, LP
│   │   ├── staff/                       # Schedule, availability, punches and training
│   │   ├── owner/                       # Decisions, cash outlook, risk and reports
│   │   ├── setup_support/               # Store-box install, pairing, health and recovery
│   │   ├── account_portal/              # Owner registration, plans, billing, downloads and licenses
│   │   └── license_admin/               # Kuberan super-admin License Manager
│   └── packages/
│       ├── design_system/               ├── domain_models/ ├── permissions/
│       ├── local_database/              ├── sync_engine/   ├── api_client/
│       ├── secure_credentials/          ├── device_io/     ├── diagnostics/
│       └── feature_*/                   # Reusable bounded-context UI/application packages
├── deployment/
│   ├── appliance/                       # Hardened store-box image and first-boot setup
│   ├── updates/                         # Signed manifest, migration and rollback metadata
│   ├── installers/                      # Desktop, Android and supported mobile packages
│   └── monitoring/                      # Local dashboards and support-safe alert definitions
├── tests/
│   ├── contract/                        # OpenAPI/event/provider compatibility tests
│   ├── integration/                     # Cross-module server and client/server scenarios
│   ├── fault/                           # Offline, duplication, reordering, disk/power failures
│   ├── performance/                     # Reference-store capacity and soak workloads
│   ├── hardware-simulators/             # Scanner, scale, printer, drawer and terminal doubles
│   └── acceptance/                      # Requirement-ID-based business scenarios
├── tooling/                              # Code generation, release, signing and migration tools
└── .github/workflows/                    # Build, test, package, sign and promotion pipelines

19.2 Backend technology and implementation style

Area	Decision	Implementation rule
Runtime	Java 21 LTS toolchain	Compile and test through the Gradle wrapper; no developer-machine JDK drift.
Application framework	Spring Boot supported production line, Spring MVC, Validation, Security, JDBC and Actuator/Micrometer	One local process with explicit module boundaries; no service discovery, Kafka or container orchestrator in V1.
Build	Gradle Kotlin DSL multi-module build	Dependency locking, version catalogue, reproducible archives, automated licence/SBOM checks.
Database	Bundled SQLite 3 runtime through a pinned JDBC driver through at least Version 5.x	WAL, foreign keys, busy timeout, short transactions, integrity/disk checks and one controlled command-writer executor. No alternate database runtime is in the current roadmap.
Persistence	Spring JDBC with explicit SQLite repositories	No general-purpose ORM in V1. Repository boundaries support module ownership, tests and SQLite-specific tuning; no second-database adapter is built or maintained through Version 5.x.
Migrations	Checksum-verified, ordered SQLite schema migrations recorded in a schema-history table	Backup and compatibility check before migration; startup fails safely on checksum or unsupported downgrade.
Serialization	JSON with versioned OpenAPI/JSON Schema contracts	Unknown additive fields are tolerated inside the support window; breaking changes require a new major/schema version.
Testing	JUnit 5, module boundary tests, temporary SQLite databases, integration/provider simulators and property/fault tests	Every acceptance test references one or more SRS requirement IDs.

Module anatomy

Every server business module uses the package root ca.kuberan.<module> and contains four explicit areas:

api: HTTP request/response mapping only.
application: use cases, commands, queries, permissions and transaction boundaries.
domain: aggregates, policies, value objects, invariants and domain events with no Spring dependency.
infrastructure: SQLite repositories, external adapters and projections.

Transaction and event model

A command authenticates the user/device, checks permission and expected version, executes one application use case, and commits business rows, audit evidence and server change-log entries in one SQLite transaction. Internal module notifications run in process. External/sync effects use the durable inbox/outbox/change-log model; no critical side effect depends on an in-memory event.

19.3 API architecture and endpoint families

API style: contract-first REST over TLS using UTF-8 JSON. The authoritative OpenAPI 3.1 files live under contracts/openapi. V1 does not use GraphQL. Server-sent events may notify connected manager screens, but business truth is obtained through REST and ordered synchronization. Payment/provider callbacks use dedicated authenticated webhook endpoints.

API family	Representative endpoints	Purpose
Session and device	`POST /api/v1/auth/sessions` `POST /api/v1/devices/pair` `POST /api/v1/devices/{id}/revoke`	User sessions, offline credential policy, device certificate issue and revocation.
Catalogue and pricing	`GET /api/v1/products` `POST /api/v1/price-batches` `POST /api/v1/price-batches/{id}:publish`	Effective products, tax, promotions, labels, signed snapshots and rollback.
Sales and returns	`POST /api/v1/sales` `POST /api/v1/sales/{id}:complete` `POST /api/v1/returns`	Server acknowledgement/projection of locally committed lane events and controlled corrections.
Payments	`POST /api/v1/payment-attempts` `POST /api/v1/payment-attempts/{id}:inquire` `POST /webhooks/v1/payments/{provider}`	Stable payment state, inquiry-before-retry, reversals/refunds and idempotent callbacks.
Cash and close	`POST /api/v1/tills/{id}:open` `POST /api/v1/cash-movements` `POST /api/v1/deposits`	Till/safe custody, blind counts, terminal batches, deposit and close controls.
Inventory and receiving	`POST /api/v1/receipts` `POST /api/v1/inventory-movements` `POST /api/v1/counts`	Receiving, ledger movements, counts, lots, production, waste and valuation.
Purchasing and finance	`POST /api/v1/purchase-orders` `POST /api/v1/vendor-claims` `POST /api/v1/bank-statements`	PO lifecycle, claims/credits, evidence, matching, reconciliation and HST workpapers.
Safety and operations	`POST /api/v1/recalls` `POST /api/v1/temperature-checks` `POST /api/v1/incidents`	Recall stop-sale, quarantine, food safety, maintenance and emergency command.
People and customers	`POST /api/v1/time-punches` `POST /api/v1/payroll-exports` `POST /api/v1/privacy-requests`	Workforce, payroll handoff, service cases, consent, privacy and stored value.
AI providers and agents	`PUT /api/v1/ai/providers/{provider}/credential` `POST /api/v1/ai/providers/{provider}:test` `POST /api/v1/ai/agents/{id}/runs`	Write-only encrypted keys, OpenAI/Anthropic/local selection, policy, budget and reviewed agent runs.
Synchronization	`POST /sync/v1/events:push` `GET /sync/v1/changes?after=…` `POST /sync/v1/ack` `GET /sync/v1/snapshots/latest`	Idempotent push, ordered pull, cursor acknowledgement, bootstrap/snapshot and repair.

Common API conventions

Client-originated UUID/ULID-class IDs and Idempotency-Key for retryable commands.
Device certificate plus short-lived user session token; authorization is rechecked in the use case.
ETag/If-Match or explicit base version for mutable master data.
UTC ISO-8601 timestamps plus store business date; money as integer minor units; quantities as fixed-scale strings.
Cursor pagination; stable sort; server-assigned ordered sequence for sync changes.
Problem-details response containing stable code, correlation ID, safe message, retryability and suggested action.

Compatibility and security

URL major version changes only for breaking REST changes.
Event type and payload schema versions are independent and recorded with every event.
Server supports the current and previous approved client train; exact window is published in the compatibility manifest.
Provider credentials are write-only, encrypted and never returned by an API.
Logs contain identifiers and outcomes, not payment secrets, AI keys, raw customer/HR documents or tender data.
Rate, size and attachment limits are defined per endpoint and enforced before persistence.

19.4 Flutter client architecture and application count

Eight deployable Flutter applications are produced from one Dart workspace. Six operate the store; Kuberan Account & Licensing handles public owner registration/self-service; Kuberan License Manager is the restricted super-admin application. They share design, domain, API, security and common account components. The HTML pages remain interaction references; production clients are Flutter and do not embed the prototypes.

App	Primary platforms	Included responsibilities	Release identifier
1. Kuberan Register	Windows, Linux, macOS; certified Android lane where selected	Cashier session, sale, customer attach, tender, receipt, return, device state, till and offline queue.	`ca.kuberan.register`
2. Kuberan Store Operations	Android/iOS handheld and tablet; desktop where needed	Receiving, stock, counts, purchasing tasks, fresh production, safety/recall, pricing/labels and maintenance.	`ca.kuberan.storeops`
3. Kuberan Manager	Android/iOS tablet and Windows/macOS desktop	Daily command, approvals, cash office, staff administration, purchasing, customers, finance, HST and loss prevention.	`ca.kuberan.manager`
4. Kuberan Staff	Android and iOS	Schedule, availability, leave, shifts, call-outs, punches, corrections, training and policy acknowledgement.	`ca.kuberan.staff`
5. Kuberan Owner	Android, iOS and desktop	Decision queue, cash outlook, performance, risk, evidence drill-down and multi-store-ready oversight.	`ca.kuberan.owner`
6. Kuberan Setup & Support	Windows/macOS/Linux and authorized tablet	Claim box, compatibility, pairing, hardware tests, health, backup/restore, updates and consented diagnostics.	`ca.kuberan.setup`
7. Kuberan Account & Licensing	Flutter Web plus Android/iOS where required	Owner account, organization/store registration, installation claim, plan, aggregate usage, billing, licensed devices and downloads.	`ca.kuberan.account`
8. Kuberan License Manager	Restricted Flutter Web/desktop	Super-admin search, license/usage/device/billing review, grants, limits, grace, suspension, key rotation and immutable audit.	`ca.kuberan.licenseadmin`

Flutter structure

Each app contains only platform bootstrap, routing and app-specific composition. Reusable bounded-context screens live in clients/packages/feature_*. Shared packages may not depend on an app. A dependency-boundary test prevents circular feature imports.

State and data

Store apps use a unidirectional presentation model with typed immutable models, explicit use cases and repository interfaces. Store apps use local SQLite and sync; the two cloud-facing licensing apps use the License Cloud API and store only minimal cached session state.

Offline and devices

Every store mutation writes domain data and outbox event in one SQLite transaction. A background sync isolate performs bounded retries. Platform plugins for scanner, scale, printer, drawer and payment terminal are hidden behind device_io interfaces and have simulators.

Client security and distribution

Device identity and refresh material use the OS secure keystore; OpenAI/Anthropic keys never leave the appropriate server. Desktop and Android packages may be installed from the authenticated store box when platform policy permits. iOS distribution uses Apple-approved channels. License Manager requires MFA, restricted super-admin role and fresh reauthentication for high-risk changes. Apps verify signed configuration/update metadata before applying it.

19.5 Environments, build pipeline and release artifacts

Development environments

Local: developer server, seeded SQLite and hardware/provider simulators.
Integration: automated cross-module and API/event contract environment.
Appliance staging: production-like store-box hardware, power/disk/network fault tests.
Pilot: named stores on a controlled release channel with rollback and daily review.
Stable production: signed, approved releases only; no direct developer access.

Source-control policy

Use trunk-based development on main with short-lived branches and required pull-request review. Every change links requirement/defect IDs, includes tests and passes module/API compatibility checks. Release candidates are immutable Git tags. Production hotfixes branch from the affected release tag, merge back to main, and follow the same signing and evidence gates.

CI/CD stages

1. Validate
Formatting, static analysis, dependency boundaries, contracts and secret scan

2. Test
Java, Flutter, database migration, contract and golden tests

3. Stress
Sync faults, payment states, power/disk recovery, performance and soak

4. Package
Reproducible JAR, apps, appliance/update bundle, schemas and migrations

5. Secure
SBOM, licence/vulnerability report, checksums, signatures and provenance

6. Promote
Internal → pilot → stable after signed approval and compatibility gates

Artifact	Contents	Distribution
Store-box appliance image	Hardened OS baseline, first-boot setup, server runtime, local database directory policy and recovery tools.	Factory image and authorized replacement-box media.
Server application	Versioned executable JAR plus configuration schema and health manifest.	Included in signed store-box update bundle.
Flutter client packages	Per-app/per-platform signed installers or store-approved mobile packages.	Store box for supported desktop/Android; approved platform channel for iOS.
Contract bundle	OpenAPI, event schemas, error catalogue and compatibility manifest.	Published with SDK/client generation and release evidence.
Database bundle	Ordered checksummed migrations, compatibility check, backup requirement and recovery notes.	Applied by the store-box updater before server activation.
Release evidence	SBOM, dependency/licence/vulnerability reports, checksums, signatures, test results, known issues and rollback decision.	Retained centrally and summarized for store owner/support.

19.6 Versioning, release channels and rollback

Version numbers

Product artifacts use MAJOR.MINOR.PATCH+BUILD. All artifacts in a coordinated release share a release-train identifier, while each app/server also records its own build. Database schema uses a monotonically increasing integer; API and event schemas carry independent major/version fields.

Channels

Nightly: engineering only.
Internal: QA/support certification.
Pilot: selected stores and explicit window.
Stable: general production.
Hotfix: narrow critical correction from a signed production tag.

Release cadence

Internal builds may occur daily. Pilot trains are planned every two to four weeks. Stable releases are promoted only after pilot evidence, normally every six to twelve weeks. Security or trading-critical hotfixes use the emergency channel and the same signature/audit controls.

Compatibility and rollback policy

The release manifest states supported server, client, API, event and database combinations before installation.
Server and client binaries may roll back only when the active database/event schema is declared backward compatible.
Before an irreversible migration, the updater verifies backup, restore key access, disk capacity and a rollback/forward-fix plan.
Client rollout is staged by device group; failed health gates stop further promotion automatically.
No release may strand offline devices: the server keeps the documented event/schema compatibility window and exposes upgrade deadlines.
Release completion requires store health, queue convergence, device versions, database integrity and backup verification.

19.7 Definition of done for an engineering feature

A feature is complete only when its SRS IDs and acceptance examples are linked; domain rules and permissions are implemented; OpenAPI/event contracts and generated clients are current; server/client/database migrations are tested; offline, retry, reversal and audit behaviour is covered; accessibility and plain-language errors are reviewed; metrics/runbook/support impacts are documented; security/privacy threat review is satisfied; and the feature has passed the applicable internal, appliance and pilot gates.

20. Cloud registration, licensing and super-admin management

Commercial policy baseline: every store-box installation must be registered to a verified Kuberan owner account. A configurable Starter plan is free while qualifying weekly sales remain at or below CAD $2,500 and the store remains within the Starter device/feature entitlements. The $2,500 value and included device counts are configuration, not hard-coded constants. “Weekly sales” means sales value, not number of transactions. Final pricing, tax treatment and contract language require product-owner/legal approval before paid launch.

20.1 Registration and activation journey

1. Download
Owner or helper obtains signed store-box/client installers from the public account portal

2. Verify owner
Create account, verify email and MFA, accept terms/privacy and create organization

3. Register store
Business name, address, timezone, currency and authorized administrators

4. Claim installation
Store box generates keypair and short-lived claim code; cloud binds installation to store

5. Issue lease
Cloud signs plan, limits, dates and store/install identity; box verifies and caches it

6. Pair clients
Local server enforces register/device entitlements while devices pair on the store LAN

Who may install

The owner may complete installation personally or authorize a friend, technician, reseller or support person. The installer receives a time-limited invitation and installation role; ownership, billing authority and super-admin rights are not implied. The owner can revoke the helper immediately after installation.

Registration availability

Initial permanent activation requires the License Cloud. The installer may issue a locally generated 72-hour provisional installation state only from an authentic signed installer, allowing hardware tests and data import but not bypassing registration. The provisional state cannot renew itself and cannot be used to create additional stores.

20.2 Free-tier measurement and plan transition

Rule	Baseline definition	Reason
Qualifying weekly sales	Net merchandise sales before sales tax, after discounts and returns, in store currency; exclude gift-card/store-credit issuance, cash back, refundable deposits, tips and configured pass-through/regulated sales.	Avoid counting money movement that is not grocery merchandise revenue.
Week	Monday 00:00 through Sunday 23:59:59 in the store’s registered timezone; week definition remains configurable for future plans.	Provides a stable, auditable boundary.
Free threshold	Default CAD $2,500 per completed week, evaluated using the average of the latest four completed weeks after sufficient history exists.	Reduces plan flapping caused by one event or seasonal week.
New store	Starter entitlement is issued during the first four completed weeks, subject to device limits and honest usage reporting.	Allows a real new store to begin without premature billing.
Upgrade trigger	Four-week average exceeds the plan threshold, or an entitlement such as register/device count is exceeded.	Separates usage value from licensed capacity.
Transition	Owner receives usage evidence, plan recommendation and at least 14 days to select/pay for a plan; policy duration is configurable.	Prevents surprise interruption.
Downgrade	Paid-to-free eligibility requires the configured number of qualifying weeks below threshold and compliance with Starter entitlements.	Prevents weekly plan oscillation.

Usage privacy: the default license report contains store ID, installation ID, store week, qualifying sales total, transaction count, returns total, active licensed-device counts, app/server versions and a signed statement hash. It does not contain product lines, customer identities, employee details, tenders, bank data or AI documents. A store owner can view exactly what was submitted.

20.3 Plans, entitlements and device counting

Plan and entitlement model

A plan is a versioned commercial template. A store license resolves it into signed entitlements such as maximum active registers, printers, scales, handhelds, manager/owner devices, staff users, stores, attachment storage, retention, integrations, AI agents, reporting and support level. Super-admin overrides are explicit entitlements with reason, start/end date and audit—not silent edits to the plan template.

Active device definition

A register/device consumes a seat when it is paired and has authenticated or reported health within the plan’s rolling activity window, default 30 days. A shared network printer counts once by stable printer identity, not once per client. Replacement devices may transfer a seat through a controlled revoke/replace workflow. Duplicate hardware fingerprints alone never establish identity.

Entitlement	Local enforcement	When limit is reached
Registers	Store box permits pairing/activation only up to `max_active_registers`.	Existing lanes continue; new lane pairing is blocked with upgrade/release-seat guidance.
Printers/scales/handhelds	Stable paired device records are counted by type and activity window.	Existing licensed devices continue; another device requires replacement, override or plan change.
Applications/features	Signed feature codes enable modules locally; critical historical data remains readable.	Disabled premium actions are hidden/blocked with plan explanation; no historical deletion.
Storage/retention	Store box warns before limit and applies approved archival policy, never silent evidence deletion.	Uploads may pause after grace; trading ledgers continue.
Store count	Cloud account controls the number of registered stores/installations.	Creating another store requires entitlement or super-admin grant.

20.4 Signed license lease and offline enforcement

Lease content

License ID, organization/store/installation IDs, plan/version, entitlements, issue/not-before/expiry/grace dates, usage-policy version, minimum compatible server version, lease sequence, signing-key ID and signature. No billing card or owner password is stored in the lease.

Cryptography

The cloud signs a canonical entitlement document with a protected asymmetric signing key. The store box contains only trusted public verification keys and its own installation private key. Signing-key rotation supports overlapping verification keys and revocation/compromise procedures.

Refresh

The store box attempts refresh daily and after plan/entitlement change. Each request authenticates the installation, includes the previous lease sequence and signed aggregate usage, and receives a new lease or an actionable status. Retries are idempotent.

State	Store behaviour	Cloud/admin behaviour
Active	All signed entitlements available.	Normal refresh and usage review.
Refresh due	Normal operation plus owner reminder; automatic retries.	Notify only when repeated refresh failure approaches expiry.
Grace	Existing checkout and safety-critical workflows continue; no new register/device pairing or new premium activation.	Show reason, remaining grace and owner resolution path.
Commercial hold	Existing lanes retain a configurable safety window; administrative/premium changes are restricted. Store records remain accessible/exportable.	Requires notice, reason and audited owner/support action; no instant remote kill of an active sale.
Security revocation	Revoked installation stops lease refresh and follows the documented security response; completed records remain recoverable.	Restricted super-admin action with MFA, fresh reauthentication and immutable audit.
Cloud outage	Cached signed lease and grace policy apply; store-critical operation does not require a cloud round trip.	Status page/support incident; lease duration must cover the recovery objective.

No checkout kill switch: billing, license-server availability or ordinary lease expiry must not interrupt an in-progress transaction. Enforcement acts at controlled boundaries such as device pairing, feature activation, shift opening after notice or administrative configuration. Exact extended non-payment behaviour is a commercial/legal policy, must be visible in the owner agreement, and must preserve export/recovery of store-owned data.

20.5 License Cloud services and APIs

The License Cloud is a separate Java 21/Spring Boot modular application using encrypted SQLite through at least Version 5.x. Its capacity plan uses a controlled single-writer model, short transactions, indexed read paths, measured storage growth, online backup, restore drills and operational partitioning when benchmarks require it. No alternative database or database-migration project is part of the current roadmap; any reconsideration after Version 5 requires a new product and architecture decision.

API family	Representative endpoints	Notes
Public account	`POST /license/v1/accounts` `POST /license/v1/accounts/{id}:verify` `POST /license/v1/sessions`	Email verification, MFA enrollment/recovery and abuse/rate controls.
Organization/store	`POST /license/v1/organizations` `POST /license/v1/stores` `POST /license/v1/invitations`	Owner, installer/helper and administrator roles are distinct.
Installation claim	`POST /license/v1/installations:claim` `POST /license/v1/installations/{id}:replace` `POST /license/v1/installations/{id}:revoke`	Short-lived claim code plus installation public key; replacement preserves store identity.
License and lease	`GET /license/v1/stores/{id}/license` `POST /license/v1/leases:refresh` `GET /license/v1/plans`	Signed entitlement document, sequence and compatibility information.
Usage	`POST /license/v1/usage-statements` `GET /license/v1/stores/{id}/usage`	Idempotent aggregate statements with owner-visible calculation and hash.
Billing	`POST /license/v1/billing:checkout` `POST /webhooks/v1/billing/{provider}`	Provider-hosted payment flow; Kuberan stores references/status, not raw card data.
Downloads	`GET /license/v1/releases` `POST /license/v1/download-tokens`	Signed manifests and short-lived authorized download URLs.
Super admin	`GET /admin/v1/licenses` `POST /admin/v1/licenses/{id}:grant` `POST /admin/v1/licenses/{id}:extend-grace`	Separate restricted API surface, MFA/fresh authentication, reason and full audit.

20.6 License Cloud data model

Entity	Purpose and important fields
Account / membership	Verified identity, MFA state, organization role, status and security history.
Organization / store	Legal/display identity, timezone/currency, owners, addresses and commercial status.
Installation	Store-box public key, claim/replacement lineage, version, last contact, status and revocation.
Device registration	Stable device ID/type, paired/revoked/replaced state, last active time and seat class.
Plan / plan version	Price, currency, effective dates, sales threshold, entitlements and policy references.
License / entitlement override	Store plan, lifecycle state, signed limits, grants, reason, start/end and approver.
License lease	Sequence, canonical payload hash, issue/expiry/grace, signing-key ID and status.
Usage statement	Store week, qualifying sales, transaction/return totals, device counts, calculation policy and statement hash.
Billing reference	External customer/subscription/invoice IDs, status and effective plan; no raw card data.
Release/download	Artifact manifest, platform, version, channel, compatibility, signature and download authorization.
Admin action/audit	Actor, MFA/fresh-auth context, target, before/after, reason, correlation ID and time.

20.7 Owner self-service and super-admin License Manager

Owner account portal

Register and verify account, organization and stores.
Invite/revoke installer, accountant or technical administrator.
Claim/replace/revoke store boxes and view current lease health.
See free-tier calculation, weekly aggregate statements and threshold trend.
View/upgrade plan, billing status, invoices and licensed capacity.
Manage registered devices, release seats and download signed installers.
Export account/license/usage data and submit correction/support requests.

Open registration prototype →

Super-admin License Manager

Dashboard for registered, free, paid, grace, hold, revoked and offline installations.
Search by organization, owner, store, license, installation or external billing reference.
Review plans, usage evidence, devices, versions, refresh health, billing and audit.
Grant/override entitlements, change plan, extend grace and replace/revoke installation.
Create plan versions and thresholds without rewriting historical licenses.
View anomalies such as clock rollback, duplicate install key or missing usage.
No invisible impersonation; support access requires consented, time-limited workflow.

Open License Manager prototype →

20.8 Security, privacy and administrative control

Super admins require phishing-resistant MFA where supported, fresh reauthentication for license/revocation/billing changes and no shared accounts.
Cloud signing private keys are isolated from the application database, rotated by key ID and never exposed through the License Manager.
Passwords use an approved adaptive password hash; session, recovery, invitation and claim tokens are short-lived, one-time and rate-limited.
Tenant authorization is enforced by organization/store membership; super-admin APIs and audit storage are logically separated from owner APIs.
Every entitlement, plan, grace, suspension, revocation, usage correction and device replacement records before/after, reason and actor.
Aggregate licensing telemetry follows data minimization, explicit policy/version, retention and owner access/correction processes.
Account deletion cannot erase license, invoice or security evidence that must be retained; personal fields are anonymized where allowed.

21. Implementation plan from V0.1 through V1.0

Autonomous execution approved

The Product Owner approved the bounded Autonomous Execution Plan on August 8, 2026. Ordinary engineering may continue through implementable V1.0 release-candidate work without repeated approval. Physical hardware, provider credentials, representative users, independent specialists, pilots and publication decisions are parked under the exact accountable validation label shown on each task; they do not stop unrelated engineering work.

Live implementation status—updated August 8, 2026: V0.2 and P05-1 are complete. P05-2.1 through P05-2.5a and P05-3.1–P05-3.5 are Done & tested. P05-3.5 passed 30/30 payment, 221/221 sales and 20/20 Store Server tests plus independent business, technical and adversarial reviews. Its accepted slice includes real SQLite-backed transactional authorization, exact atomic settlement, immutable receipt/tender/outbox evidence, caller-scope receipt lookup, deterministic LIVE/TRAINING printable content, current printer-route reauthorization and crash-safe no-auto-reprint handling. Readable evidence. P05-2.5b controlled returns/exchanges is active: R1 closed P05-2.5b.a.1 and d.1; R2.1 closed P05-2.5b.h.2; and independently accepted R2.2 now closes exactly P05-2.5b.c.7 and P05-2.5b.h.5. R2.2 passed 11/11 current-control tests, 18/18 schema tests, 2/2 absence-codec tests, 29/29 repository tests, 313/313 complete-sales tests and 50 scenarios across 100 durable authorization attempts; both independent audits reported PASS with no open P0/P1 issue. Readable R2.2 evidence. The next active unit is R2.3 tamper/restart verification. Race and lifecycle/fault matrices remain separate R2.4–R2.5 tasks; the broader schema-tamper, reservation/custody, no-receipt, refund and inventory rows remain unchecked. In parallel, the V0.8 offline emergency guide and all eleven incident playbooks are Done & tested and independently available offline: their accepted evidence is now shown as 18 separate checked outcomes. Readable emergency-guide evidence. The visible register presents P05-3.6 as 18 named refund/reconciliation workstreams containing 189 individual checkboxes, V0.8 as 47 named subfeatures containing 461 individual checkboxes, and V1.0 as 35 named subfeatures containing 581 individual checkboxes. V0.5 remains 4 of 11 because the P05-2 and P05-3 parent capabilities are still open. Every status-bearing child keeps its own ID and receives a check only after implementation, repeatable tests, linked evidence and independent verification.

Latest dependency-safe V1.0 completion: P10-4.3.a.1–a.6 and P10-4.3.b.1–b.13 are Done & tested. The Training Centre contains 65 observable tasks across Cashier, Receiver, Manager, Owner, Staff and Installer roles, dynamic 90%-plus-Mandatory thresholds, honest non-certification wording, six normal/recovery guide packages and seven exact application links. Browser, mobile, keyboard, security, business-owner and technical/accessibility gates passed with zero P0/P1 findings. Readable role-training evidence. P10-4.3.c.1–c.13 isolated practice storage, role datasets and live-effect blocks remain open, and representative-user certification remains parked for the owner.

What is being built right now

Active dependency-safe lane: V1.0 support-readiness verification. The Support Centre exists and focused static/browser checks have passed; the exact rows marked Verification pending below remain unchecked until the complete interaction, mobile and two-reviewer gates pass. Temporarily paused source lane: P05-2.5b R2.3, because the current iCloud workspace has evicted Java/Flutter sources; its recovered R2 files are preserved in /tmp/kuberan-r2-recovery and must be resumed from a non-iCloud working copy.

Done and checked — R1 domain contracts: P05-2.5b.a.1 and P05-2.5b.d.1 define the authorized return-credit aggregate and honest no-receipt types.
Done and checked — R2.1 no-money boundary: P05-2.5b.h.2 has trusted same-writer controls, exact normalized SQLite persistence and close/reopen proof.
Done and checked — R2.2 exact replay and current denial: P05-2.5b.c.7 and P05-2.5b.h.5 passed the focused and full regression gates plus both independent audits.
Paused safely — R2.3 tamper/restart matrix: no further Java/Flutter materialization or build is safe in the current iCloud tree. The recovered seven-file overlay and reconstruction manifest are preserved.
Done and checked — V0.8 emergency continuity: P08-5.4.b.1–b.6 and P08-5.6.a–l provide the self-contained guide, its six verified quality outcomes and eleven incident playbooks.
Done and checked — V1.0 role standards and guides: P10-4.3.a.1–a.6 and P10-4.3.b.1–b.13 provide 65 observable role tasks, six guide packages and seven contextual guide routes.
Verification pending — V1.0 support readiness: P10-4.4.a.1–a.6, P10-4.4.c.1, P10-4.4.c.2.4, P10-4.4.c.3, P10-4.4.c.4 and P10-4.4.c.5.2 are the current bounded verification set. No check is awarded until all remaining gates pass.
Next after this gate: continue the next dependency-safe HTML/product/operational slice. P10-4.3.c.1–c.13 stay unchecked until deterministic isolated practice workflows exist.

Owner validation required—parked: representative training sessions, accounting/tax acceptance, real terminal/acquirer semantics, privacy/food-safety/loss-prevention policy, physical hardware, emergency-policy approval and physical drills. These do not undo the completed software/document evidence.

Validation parking rule: hardware/vendor/credential, real-store/pilot, independent-specialist, owner-decision and publication-authorization work is left unchecked under its exact label. Codex prepares the validation package and immediately continues the next dependency-safe item. A parked gate becomes a blocking question only when every remaining V1.0 item depends on it.

Owner-readable implementation progress

This checklist describes product capabilities in grocery-store language. A green check means the individual capability is implemented, repeatably tested, linked to evidence and independently verified. An empty box means it is not complete; the adjacent status distinguishes active work, verification pending, the accountable parked validation kind, or not started. The parent summaries are followed by a complete owner-readable small-task register covering every remaining item through V1.0. Use each section's Expand all tasks button to see every checkbox at once, or open only the named subfeature you want to review.

V0.1 • Product definition2 of 4Two complete; execution readiness active; usability needs representative users.

V0.2 • Technical foundation6 of 6Complete, tested and evidenced.

V0.5 • Core store pilot4 of 11P05-1 complete; P05-2/P05-3 child work is active.

V0.8 • Whole-store operationCalculating small tasks…Each operation and accountable sign-off is tracked separately.

V1.0 • General availabilityCalculating small tasks…Each certification, pilot interval and release decision is tracked separately.

✓ Done & tested Building or verification pending Parked validation—row names who must act Not started

Overall: 12 of 36 owner-level capability groups are checked; 5 are in engineering, 2 are parked for decision/external validation and 17 have not started. P08-5 is building because its emergency-guide slice is complete; P10-4 is building because its role standards and contextual guides are complete while install, migration, runnable practice, support and representative-session gates remain. These are capability counts, not effort percentages.

Detailed owner task checklists

V0.1 — Product definition and delivery readiness2 of 4 checked

Done	Feature or outcome	Status	What the status means now
✓	Complete product requirementsP01-1 • 132 traced requirements	Done & approved	The consolidated SRS, roles, permissions, workflows, scope and acceptance catalogue are the approved source of truth.
✓	Architecture and system boundariesP01-2	Done & approved	Flutter + SQLite clients, Java/Spring Boot + SQLite services, offline synchronization and separate License Cloud boundaries are defined.
	Prototype usability with real store rolesP01-3	Owner validation required	Interactive HTML prototypes exist. Observed cashier, receiver, manager, owner, installer and administrator sessions still require representative users; this is parked while engineering continues.
	Execution backlog and golden-store test dataP01-4	In progress	The autonomous plan and phase backlog are approved. The complete golden-store fixture and formal V0.1 gate record remain open.

V0.2 — Tested technical foundation6 of 6 checked • version complete

Done	Feature or outcome	Status	What is proven
✓	Buildable engineering foundationP02-1	Done & tested	Java, Flutter, contracts, CI controls and signed internal artifacts build from the same source baseline.
✓	Durable SQLite storage and recoveryP02-2	Done & tested	Migrations, restart recovery, capacity, integrity checking, encrypted backup and restore were independently verified.
✓	Offline-to-online synchronizationP02-3	Done & tested	Duplicate, reordered, rejected, restored and 100,000-event catch-up scenarios converge without lost or duplicated business effects.
✓	Secure installation claim and signed licencesP02-4	Done & tested	Claim identity, cached signed leases, expiry, device binding, key handling and role-gated access passed independent review.
✓	Payment and hardware simulatorsP02-5	Done & tested	The payment state machine plus printer, scanner, scale, cash-drawer and payment-terminal simulators passed their test suites.
✓	Complete store-box recovery journeyP02-6	Done & tested	Real services completed install, claim, offline work, Cloud outage, safe update rejection, encrypted backup, replacement restore and exact replay with RPO 0 and measured local RTO 1,678 ms.

V0.5 — Core trading and controlled single-store pilot4 of 11 checked • P05-2/P05-3 active

Done	Feature or outcome	Status	What remains before the box can be checked
✓	Shared, accessible Flutter interfaceP05-1.1	Done & tested	Loading, empty, offline, error/retry, keyboard, semantics, contrast, narrow-width and 200% text-scale tests passed with evidence.
✓	Local sign-in, permissions and safe offline policyP05-1.2	Done & tested	Independent second-remediation audit accepted 16/16 focused authorization tests, 24/24 local-data tests and 5/5 security tests, with linked SEC-001 contribution evidence.
✓	Eight separately identifiable macOS applicationsP05-1.5	Done & tested	Eight source identities/builds, canonical-version rejection, deterministic icons, independent re-audit and linked FLT-001 evidence passed. Developer ID/notarization/Gatekeeper remain Owner validation gates.
✓	Device pairing and offline client synchronizationP05-1.3, P05-1.4, P05-1.6	Done & tested	The final combined clean-shell audit passed 147/147 deterministic tests, eight isolated app builds, 8/8 fresh artifact inspections, 7/7 packaging checks and complete evidence/contract validation. Open combined evidence.
	Products, pricing, checkout and receipts — parent summaryP05-2 • split into 93 visible child outcomes below	10 of 93 children done	Do not use this parent row to judge daily progress. Open the P05-2 child checklist to see catalogue, pricing, promotions, sale lifecycle, eligibility, 82 controlled-return and exchange tasks and each Store API/Register integration slice separately.
	Cash, debit, credit, settlement and refunds — parent summaryP05-3 • split into 201 visible child outcomes below	12 of 201 children done; refunds remain	Open the P05-3 child checklist for separate check marks on cash, card, split, recovery, every completed settlement slice and 189 atomic refund, reversal, capture, reconciliation, API and acceptance outcomes.
	Tills, safe, deposits and daily cash closeP05-4	Not started	Opening float, pickups/drops, blind counts, variances, deposit bags, terminal batches and cash/deposit reconciliation remain.
	Inventory, receiving, vendors and purchase ordersP05-5	Not started	Movement-derived stock, case/unit/catch weight, counts, expiry, PO suggestions, receiving, shortages, claims and credits remain.
	Owner registration, Starter licence and device limitsP05-6	Not started	Owner MFA, helper invitation, store claim, CAD $2,500 weekly threshold, four-week decision, signed refresh, owner portal and device seats remain.
	Nontechnical appliance setup, migration and recoveryP05-7	Not started	First boot, hardware profiles, repeatable import, signed update, support bundle, replacement restore, offline recall/emergency cards and training remain.
	Shadow trial and controlled live-lane pilotP05-8	Owner validation later	Engineering must first close P05-1 through P05-7. Then a real approved store, hardware/payment readiness and daily owner reconciliation are required; the gate will be parked while later dependency-safe work continues.

P05-2 — Products, pricing, checkout and receipts: child progress10 of 93 checked

Done	Small feature	Status	Owner-readable result
✓	Product catalogue and identifiersP05-2.1	Done & tested	UPC, PLU, product, unit-of-measure and deterministic catalogue evidence are implemented and independently verified.
✓	Exact price, tax and deposit calculationP05-2.2	Done & tested	Effective price, tax and refundable-deposit snapshots produce exact repeatable CAD totals.
✓	Promotions and basket totalsP05-2.3	Done & tested	Promotion precedence, discounts and basket totals are frozen into sale evidence.
✓	Authorized sale lifecycle before paymentP05-2.4	Done & tested	Create, freeze, suspend/retrieve, void and cancel behavior is versioned, audited and restart-safe.
✓	Trusted receipt lookup and read-only return eligibilityP05-2.5a	Done & tested	Return eligibility can read trusted paid-sale evidence but cannot authorize or create a return.
	Controlled returns and exchangesP05-2.5b • 82 separately checkable rows	Loading detailed tasks	The canonical fine-grained register below contains five checked tasks, 11 building tasks, 59 not-started autonomous tasks and seven parked owner validations.
	Settlement and receipt application use casesP05-2.6a	Not started	Add authenticated command construction, settlement service/port and restart-safe receipt query; client input cannot mint actor, store, namespace or server time.
	OpenAPI sale, settlement and receipt contractsP05-2.6b	Not started	Version commands, optimistic evidence, idempotency, final receipt response and lost-response receipt lookup before controller code.
	Cashier-safe settlement error contractsP05-2.6c	Not started	Map not-ready, unresolved, stale, idempotency conflict, authorization, missing receipt and integrity failure to truthful recovery guidance.
	Store Server wiring, security and boot migrationP05-2.6d	Not started	Wire repository/service/controller, device plus user permission checks, deterministic schema startup and HTTP restart/idempotency tests.
	Receipt print worker and controlled reprintP05-2.6e	Not started	Dispatch exact verified receipt content from durable jobs; retry/reprint cannot change sale or payment and approval rules remain explicit.
	Offline Register checkout-to-receipt journeyP05-2.6f	Not started	Flutter Register and local SQLite complete scan, total, tender, settle, lost-response lookup, receipt display and reconnect without loss or duplicate effect.

P05-3 — Payments, settlement and reconciliation: child progress12 of 201 checked • P05-3.6 has 18 named workstreams / 189 leaf tasks

Done	Small feature	Status	Owner-readable result
✓	Exact full-cash tenderP05-3.1	Done & tested	Trusted till assignment, Canadian rounding, received/change/net and cash custody are exact and restart-safe.
✓	Authenticated debit and credit terminal decisionsP05-3.2	Done & tested	Sale-bound approvals, declines, disconnects and signed raw provider evidence are isolated and replay-safe.
✓	Split and partial tenderP05-3.3	Done & tested	Ordered cash/card portions, exact balance and durable partial approvals passed clean independent gates.
✓	Inquiry-before-retry recoveryP05-3.4	Done & tested	Timeout, unknown, callback/inquiry convergence and restart replay passed the clean 205-test gate.
✓	Authorized settlement command and trusted control adapterP05-3.5a	Done & tested	Real Store Server wiring rechecks persisted device, session, permission version, till/lane/shift/cashier and printer controls in the SQLite writer transaction; every tested revoke/version change fails closed.
✓	Exact settlement readiness blockersP05-3.5b	Done & tested	Unresolved, unknown, unallocated partial, quarantined, wrong-version and wrong-scope payment states block settlement.
✓	Receipt number and identityP05-3.5c	Done & tested	Store/mode numbering is monotonic and restart/concurrency safe; caller namespace/mode and cross-scope identity are verified.
✓	Immutable final receipt and ordered tender evidenceP05-3.5d	Done & tested	Every scalar and ordered tender row binds the canonical receipt; deletion, alteration and two-tenant payload swaps fail closed.
✓	One-transaction completion, audit and outboxP05-3.5e	Done & tested	Sale, tender session, receipt, audit and exact terminal outboxes commit or roll back together; swapped payloads are rejected.
✓	Replay, crash, concurrency, restart and tamper gateP05-3.5f	Done & tested	Replay reauthorizes current controls; concurrency has one winner; restart detects missing, altered, deleted, swapped and route-rewritten evidence.
✓	Paid receipt presentation and printer simulator handoffP05-3.5g	Done & tested	Deterministic LIVE/TRAINING printable bytes, exact CAD/tenders, route reauthorization and durable pre-I/O uncertainty prevent false paid/printed claims and automatic duplicate prints.
✓	Clean combined settlement acceptance and evidenceP05-3.5h	Done & tested	30/30 payment, 221/221 sales and 20/20 Store Server tests plus business, technical and adversarial reviews passed. Open evidence.
	P05-3.6 refund and processor reconciliation18 workstreams / 189 status-bearing leaf tasks	0 of 189 checked • 13 parked validation	Open the small workstream groups immediately below. Every implementation and test outcome has its own checkbox.

Loading the 18 P05-3.6 workstream checklists…

V0.8 — 47 named subfeatures / 461 whole-store and paid-licensing tasksEvery leaf has its own checkbox

Loading the V0.8 subfeature checklists…

V1.0 — 35 named subfeatures / 581 general-availability tasksEvery leaf has its own checkbox

Loading the V1.0 subfeature checklists…

Status vocabulary and roll-up

Status	Meaning
Done & tested	Code, repeatable tests, linked evidence and an independent verifier have all passed.
In progress	Implementation or integration is actively changing; no completion claim is made.
Verification pending	Implementation exists and focused tests may pass, but the combined evidence or independent gate is not yet complete.
Owner / accountable-role decision required	The store owner, product owner or named accountable role must approve a policy, business rule, risk or go/no-go choice.
Real-store / pilot validation required	A representative user, live operating cycle or approved pilot store must demonstrate the outcome.
Independent specialist required	A qualified accountant, security, privacy, accessibility or release auditor must provide independent acceptance.
Operational staffing / readiness required	Named primary/backup staff, coverage intervals, handovers or support capacity must be exercised and accepted.
Hardware / vendor / credential required	Completion needs real devices, provider behavior, production credentials or secret custody.
Publication authorization required	The accountable release authorities must explicitly approve public or Stable-channel publication.
Not started	No implementation credit is claimed.

The six parked labels roll up together as decision/external validation; they identify who must act instead of implying the grocery owner personally performs every certification. A parent phase becomes Done & tested only when every required child is complete.

Engineering phase register

This table retains the technical phase roll-up behind the owner-readable checklist. It is updated at each accepted gate. Detailed evidence is linked from the HTML evidence index.

Phase	Status	Current acceptance position
P01-1	Done & approved	The final 132-requirement SRS, scope and trace baseline were approved by the Product Owner.
P01-2	Done & approved	The Java/Flutter/SQLite architecture, boundaries and initial contract baseline are accepted.
P01-3	Not complete	HTML prototypes exist; observed representative-user usability sessions and signed acceptance are still required.
P01-4	In progress	The execution plan is approved and V0.2 was authorized; the complete golden-store fixture and formal V0.1 gate evidence remain open.
P02-1	Done & tested	Engineering spine, generated contracts, CI and signed internal proof passed independent re-audit.
P02-2	Done & tested	macOS SQLite ownership, migrations, restart, capacity and encrypted continuity proof passed isolated independent re-audit.
P02-3	Done & tested	Server/client SQLite sync, exact replay receipts, immutable poison/changed-payload evidence, authorized repair, restart/restore and 100,000-event convergence passed independent re-audit.
P02-4	Done & tested	Claim security, signed leases, controlled SQLite restart state, Java/Dart Ed25519 and role-gated HTTP flow passed isolated independent re-audit.
P02-5	Done & tested	Payment state machine and all five hardware simulators passed focused tests and independent re-audit.
P02-6	Done & tested	The complete real-JAR install/claim/offline/Cloud-outage/update/backup/replacement/snapshot/replay journey passed with three effects exactly once, RPO 0, measured local RTO 1,678 ms, passed HTML/JSON evidence and an unqualified independent final audit.
P05-1	Done & tested	All six children and the complete clean-shell integration gate passed independent audit with 147/147 deterministic tests, eight app builds, exact artifact checks and linked combined evidence.
P05-2	Building	P05-2.1–P05-2.5a are Done & tested with independent evidence; settlement-dependent P05-2.5b and P05-2.6 remain.
P05-3	Building	P05-3.1 through P05-3.5 are Done & tested; 189 atomic P05-3.6 capture, refund, reversal, reconciliation, API and acceptance tasks remain before this owner-level capability closes.
P05-4	Not started	Queued after P05-2.
P05-5	Not started	Queued after P05-1.
P05-6	Not started	Queued after the V0.2 licensing foundation.
P05-7	Not started	Queued alongside the V0.5 domain work.
P05-8	Not started	Waits for P05-1 through P05-7 and external readiness.
P08-1	Not started	Queued after the V0.5 gate.
P08-2	Not started	Queued after the V0.5 gate.
P08-3	Not started	Queued after the V0.5 gate.
P08-4	Not started	Queued after the V0.5 gate.
P08-5	Building	The printable offline emergency card and all eleven incident playbooks are Done & tested with independent evidence. Loss cases, maintenance, executable continuity controls, recovery tasking and owner/store drills remain open.
P08-6	Not started	Queued after P05-6 and the V0.5 gate.
P08-7	Not started	Waits for stable P08-1 through P08-6 read contracts.
P08-8	Not started	Waits for P08-1 through P08-7.
P10-1	Not started	Queued after the V0.8 feature freeze.
P10-2	Not started	Queued after the V0.8 feature freeze.
P10-3	Not started	Queued for release-candidate appliance certification.
P10-4	Building	Role competency standards P10-4.3.a.1–a.6 and guide/link outcomes P10-4.3.b.1–b.13 are Done & tested. Eleven support-standard/simulation rows are Verification pending; installation, migration, practice datasets, remaining support tooling and representative-user sessions remain open.
P10-5	Not started	Queued for release-candidate continuity and release operations.
P10-6	Not started	Waits for P10-1 through P10-5 and requires a real approved 30-day store pilot.
P10-7	Not started	Waits for the completed 30-day release pilot and all GA sign-offs.

21.1 How the plan is executed

Phase independence

Every phase produces a bounded deployable, simulator, test harness or operational package that can be accepted without waiting for every other phase in the same version. “Independently testable” does not mean independently releasable to a store; the version integration gate still proves the combined system.

Parallel-agent rule

Sub-agents may work concurrently only after the applicable contracts and ownership boundaries are frozen for that wave. Each phase has one implementation owner and a different verification owner. Shared SQLite migration order, money/quantity types, payment states, signing keys and public contracts retain one integration owner.

Evidence rule

A phase closes with linked SRS IDs, source and build provenance, automated results, a repeatable demonstration, security/permission review, observable failure behaviour, recovery notes and an HTML acceptance index. Evidence—not reported activity—determines completion.

Trial states and data authority

State	Permitted use	Authority and exit rule
Lab certification	Synthetic/golden data, simulators and certified test hardware; no live customer or money.	Kuberan test ledgers only. Exit when the bounded phase evidence passes.
Shadow trial	Observe/replay selected real-store activity without controlling checkout, money or stock.	The named legacy process remains authoritative. Every source feed, comparison and deletion/retention rule is documented.
Limited production pilot	Only named lanes, tenders, users, departments and effective cutover times are authoritative in Kuberan.	A signed coexistence matrix names the authority for product, price, promotion, sale, tender, cash, inventory and customer value. No untested dual posting; rollback covers unsent events and control totals.
Whole-store operational pilot	All selected V1 functions are authoritative and used through complete business cycles.	Requires V0.8 integrated controls, reconciliation, role sign-off and an approved rollback/continuity position.

Technology and scope controls: every concurrency, migration, restore, sync, licensing, performance and pilot acceptance test uses the pinned production SQLite runtime and production pragmas—not an in-memory substitute. No callable AI runtime, provider adapter, credential flow, model, agent endpoint or AI evaluation enters V0.1–V1.0; AI remains explicitly disabled until the separately approved V1.1 plan.

Suggested parallel delivery lanes

Lane	Primary ownership	May run in parallel with	Controlled integration points
A • Platform and SQLite	Repository, Java foundation, SQLite schema/migrations, backup, restore, performance	B, C, G and simulator work after contracts exist	Migration sequence, transaction boundaries, shared identifiers
B • Contracts and synchronization	OpenAPI, event schemas, idempotency, inbox/outbox, snapshots, compatibility	A, C, D, E and G using frozen contract versions	Public API/event version, cursor and restore epoch
C • Flutter foundation	Workspace, design system, local SQLite, authentication, pairing, outbox and shared UI	Server, cloud and domain lanes through mocks/generated clients	Generated clients, offline policy and shared packages
D • Trading and money	Checkout, tenders, payment recovery, receipts, till and cash office	E and G after product/tax/payment contracts freeze	Money/tax rules, receipt finality and payment state machine
E • Product and operations	Catalogue, pricing, inventory, receiving, purchasing, fresh, safety and maintenance	D, F and G with explicit ledger/event ownership	Product/UOM identity, inventory movements, price publication
F • People, customer and finance	Staff/time, customer/value, banking, HST, accounting and owner decisions	E and G after permission and ledger contracts freeze	Privacy boundaries, liabilities, close periods and exports
G • Cloud licensing and security	Registration, License Cloud SQLite, signing, plans, usage, billing and super administration	Store development because the cloud is not in the checkout path	Lease schema, key rotation, device identity and compatibility
H • Appliance, quality and release	Store-box image, installers, hardware lab, CI evidence, updater, observability and pilot operations	All lanes continuously as an independent verification stream	Release manifest, environment promotion and go/no-go decision

21.2 V0.1 phases — specification and delivery readiness

Version purpose: create a trusted product and engineering baseline before production code. These phases may use prototypes, specifications and executable examples; V0.1 does not deliver a production POS.

Phase	Deliverable and scope	Dependencies / parallel work	Independent verification	Exit evidence
P01-1 Scope, authority and traceability	Freeze personas, permissions, workflows, 132 requirements, priorities, acceptance examples, explicit V1 exclusions and the data-authority/coexistence matrix for lab, shadow, limited-production and rollback states.	Starts first; business, technical and pilot-authority reviewers may inspect different requirement groups in parallel.	Automated duplicate/link checks plus an opening-to-close walkthrough proving every critical handoff and authoritative system is named.	Approved trace matrix, pilot-authority matrix, decision log and zero unresolved scope contradictions.
P01-2 Architecture and contracts	Confirm Java/Spring Boot + SQLite, Flutter + SQLite, module boundaries, API/event rules, security zones, License Cloud separation and release topology.	After P01-1 vocabulary stabilizes; architecture, threat modelling and contract examples run in parallel.	Architecture review uses checkout-offline, duplicate-event, unknown-payment, lease-outage and restore scenarios.	Accepted architecture decisions, context diagrams, contract examples and risk register.
P01-3 Prototype usability	Validate the HTML flows with cashier, receiver, manager, owner, staff, installer and Kuberan super-admin representatives.	Parallel with P01-2 after task language is stable.	Observed task completion, comprehension, accessibility and recovery-message sessions; findings tied to requirements.	Resolved critical usability findings and signed prototype acceptance record.
P01-4 Execution readiness	Convert requirements into phase backlogs, identify vendor/certification dependencies, create the golden-store dataset and test-data policy, and approve V0.2 entry. Fixtures cover tax, deposits, weighted/embedded barcodes, promotions, coupons, returns, tenders, tills, POs, inventory and migration totals.	Depends on P01-1 through P01-3; test-data and delivery-evidence work may run in parallel.	Another reviewer calculates expected sale, tax, tender, stock and close results from the fixtures without developer explanation; every V0.2 item has owner, acceptance, dependency and evidence location.	Versioned fixtures/expected results and V0.1 gate signed by Product Owner, Technical Lead, QA and Security.

V0.1 exit gate: the SRS remains the source of truth; no unresolved critical business/technical review item; V0.2 backlog and acceptance harnesses are ready. Current document status indicates V0.1 specification work is complete, subject to product-owner confirmation of this implementation plan.

21.3 V0.2 phases — technical foundation

Version purpose: prove the high-risk architecture with production-shaped code and simulators before feature breadth. P02-2 through P02-5 may run concurrently after P02-1 freezes repository and contract conventions; P02-6 is the integration gate.

Phase	Deliverable and scope	Dependencies / parallel work	Independent verification	Exit evidence
P02-1 Engineering spine	Monorepo, Gradle/Dart workspaces, Java and Flutter skeletons, generated-contract pipeline, CI, quality/security checks, artifact provenance and environment conventions. Release manifests explicitly mark AI unavailable through V1.0.	Depends on V0.1; lanes A, B, C, G and H collaborate, then separate.	Clean-machine build produces server, cloud and eight client skeleton artifacts from one commit; forbidden dependency test fails deliberately; dependency/API scan finds no callable AI provider/runtime surface.	Reproducible build, CI evidence, module-boundary report and signed internal artifact.
P02-2 SQLite durability	Store/cloud SQLite connection ownership, migration history, controlled writer, integrity checks, backup, encrypted off-box copy, restore epoch and capacity harness.	After P02-1; parallel with P02-3, P02-4 and P02-5.	Power/process interruption, migration checksum, disk-full, corruption detection, RPO/RTO restore and reference-load tests.	SQLite benchmark with ≥30% headroom and verified RPO ≤15 minutes / RTO ≤60 minutes.
P02-3 Sync protocol	Versioned push/pull/snapshot contracts, client outbox, server inbox/change log, idempotency, cursor acknowledgement, quarantine and restore reconciliation simulator.	After P02-1; consumes P02-2 transaction primitives and may mock them until stable.	Duplicate, changed-payload replay, reordering, partial batch, poison event, 14-day offline, 100,000-event catch-up and restored-server tests.	Deterministic convergence report with no lost or duplicated business effect.
P02-4 Identity and signed leases	Device PKI, claim identity, signed entitlement lease format, offline verification, key identifiers, rotation overlap, compromise/revocation and minimal License Cloud SQLite service.	After P02-1; parallel with store foundation; coordinates with P02-3 identity fields.	Tampered/expired/wrong-installation lease, clock edge, key rotation, revoked device, cloud outage and stale sequence tests.	Cryptographic test report and cached-lease demonstration without checkout cloud calls.
P02-5 Payment and hardware simulators	Payment-attempt state machine, inquiry/idempotent callback simulator, and interfaces/simulators for scanner, printer, scale, drawer and customer display.	After P02-1; parallel with P02-2 through P02-4; no live processor certification yet.	Every legal/illegal payment transition, lost response, duplicate callback, partial approval and simulated device disconnect/reconnect.	Contract suite proves one financial effect and platform-neutral hardware behavior.
P02-6 Foundation integration	Bootable test appliance joining Java server, cloud, one Flutter harness, SQLite, sync, identity, signed lease, update manifest, health and restore tooling.	Depends on P02-2 through P02-5; lane H owns integration.	Fresh install, claim, local commit, offline queue, reconnect, lease outage, update rejection, backup and replacement-box restore scenario.	V0.2 technical-proof report; zero unresolved architecture-blocking defect.

V0.2 exit gate: ENG, API, SYNC, PAY-001/002, LIC-001/002, SEC-LIC-001, CLOUD-001 and applicable NFR foundation evidence pass. The result is an engineering proof, not a live-store release.

21.4 V0.5 phases — controlled single-store pilot

Version purpose: safely trade on limited lanes and operate core stock/purchasing with mandatory registration. Product/inventory/licensing streams may develop in parallel against the V0.2 contracts; all converge before the controlled pilot.

Phase	Deliverable and scope	Dependencies / parallel work	Independent verification	Exit evidence
P05-1 Flutter/store foundation	Shared design system, accessibility/error components, local SQLite, authentication, permissions, pairing, policy cache and outbox/pull engine. Produce eight signed, independently identifiable app artifacts; Register, Store Operations, Setup & Support and Account & Licensing carry their assigned V0.5 workflows, while Manager supplies minimum approvals/cash close. Other shells are packaging proofs, not claimed functional completion.	Depends on V0.2; lane C leads while D/E/G use mock screens and generated clients.	All eight artifacts build and install; offline mutation atomicity, restart recovery, revoked session/device, permission change, golden/accessibility, dependency-boundary and cross-platform smoke tests pass.	Certified shared packages, eight artifact identities and only the explicitly assigned V0.5 applications approved for pilot use.
P05-2 Catalogue-to-receipt	Product/UPC/PLU/UOM, price/tax/deposit/promotion snapshots, sale building, suspend/retrieve, void/cancel, return-policy contracts, paid receipt, controlled receipt-linked/no-receipt return and exchange.	After P05-1; parallel with P05-5 and P05-6. P05-2.1–P05-2.4 freeze merchandise evidence for P05-3; P05-2.5b then depends on P05-3.5 final-paid-receipt evidence.	Representative basket/golden paid-receipt suite, weighed item, promotion precedence, tax, return and offline restart scenarios within latency budgets.	Simulator sale, tender, return, refund and inventory-intent ledgers reconcile exactly without treating an unpaid merchandise copy as proof of purchase.
P05-3 Tenders and recovery	Cash, debit, credit, split tender, payment terminal adapter, inquiry-before-retry, sale settlement/final paid receipt, reversal/refund and tender reconciliation.	Depends on frozen P05-2.1–P05-2.4 merchandise contracts and P02-5; P05-3.5 unlocks P05-2.5b; may run beside P05-4.	Processor sandbox/certified simulator covers decline, timeout, unknown, duplicate callback, partial approval, disconnect, recovery, exact settlement and final-receipt identity.	No duplicate/lost financial effect; a sale becomes paid only after exact tender settlement; processor and POS totals reconcile.
P05-4 Till, deposit and cash controls	Till issuance, opening float, pickup/drop, blind count, variance, close, safe book, numbered deposit bags, terminal-batch reconciliation, deposits-in-transit exceptions and controlled approvals sufficient for pilot tenders.	Depends on P05-2; parallel with P05-3 and P05-5.	Cash chain-of-custody, one-person exception, over/short, recount, no-sale, unknown terminal result, deposit mismatch, late bank credit and disconnected register close.	Sale/tender/till/safe/terminal/deposit totals reconcile or remain named, owned exceptions with complete audit evidence.
P05-5 Inventory and purchasing core	Inventory movement ledger, receiving, count/adjustment, lot/expiry basics, vendors, order suggestions, PO approval/send simulator, acknowledgement, claims and credits.	After P05-1; parallel with P05-2, P05-4 and P05-6; integrates sale movements after P05-2.	Case/unit, catch weight, concurrent sale/count, duplicate receipt, short/over delivery, PO/receipt/invoice and claim ageing tests.	Movement-derived stock and purchase control totals reproduce source scenarios.
P05-6 Registration and Starter licensing	Owner verification/MFA, organization/store, installer invitation, installation claim, Starter policy, aggregate usage, signed refresh, device entitlements, owner portal and signed downloads.	Builds on P02-4; parallel with store functions because lease enforcement is local.	New-store, $2,500 threshold, excluded value, four-week calculation, limit/replacement, privacy payload, duplicate statement and cloud-outage tests.	Owner reproduces eligibility decision; existing lanes continue while excess pairing is blocked.
P05-7 Safety, coexistence and pilot readiness	First-boot setup, hardware profiles, signed updater, health, backup/restore, repeatable import, coexistence/rollback authority, locally cached recall stop-sale, power/refrigeration/robbery/injury/server/network failure cards, quick guides, competency tests and support bundle. V0.8 may deepen these modules, but minimum live-trading controls cannot wait.	Lane H runs throughout P05-1 through P05-6; recall consumes product/lane contracts, while authority/import/training work can proceed in parallel.	Non-technical install, repeat import/no duplicates, recall issued with an offline lane, power/network/disk/refrigeration failure, update rollback/forward-fix, replacement restore, hardware matrix and role training exercises.	Certified pilot image, signed authority/control totals, tested rollback/recovery, available offline emergency instructions and trained pilot users.
P05-8 Shadow then limited-lane pilot	Progress through staff sandbox, non-authoritative shadow comparison, one training/employee lane, then only the specifically authorized customer lanes/tenders. Record daily reconciliation, hypercare, issue triage, authority cutover time and rollback window.	Depends on P05-1 through P05-7 and legal/payment/hardware readiness. Production authority is forbidden until checkout, payment recovery, cash/deposit, minimum safety and migration/coexistence evidence pass together.	Shadow comparison plus opening-to-close, peak trade, offline interval, payment recovery, receiving/count/claim, recall stop-sale, emergency card, backup verification and daily owner sign-off.	Agreed pilot duration completed with no severity-1 data loss/duplication, no unexplained dual-posting/authority gap and all exit variances resolved.

V0.5 exit gate: core checkout, payment, cash, stock, purchasing, registration, Starter licensing, appliance setup and limited-store support are accepted. The version does not advance while daily sale/tender/cash/inventory totals fail to reconcile.

21.5 V0.8 phases — whole-store operational pilot

Version purpose: complete operational breadth and paid-license administration. P08-1 through P08-6 are parallel domain streams with separate schema/event ownership; P08-7 and P08-8 integrate and validate the whole store.

Phase	Deliverable and scope	Dependencies / parallel work	Independent verification	Exit evidence
P08-1 Food safety and fresh	Temperature/sanitation checks, certificates, recall stop-sale/quarantine/trace, fresh recipes/batches/yield, labels, allergen, markdown, donation and waste.	Depends on V0.5 product/inventory/price ledgers; parallel with P08-2 through P08-6.	Recall drill from notice to verified close, cold-chain breach, lot sale block, allergen/date label and yield/waste tests.	Food-safety lead signs trace, disposition and corrective-action evidence.
P08-2 Staff, time and payroll	Employee profile/role, availability, schedule, shifts, offline punches, breaks, corrections, approvals, freeze and payroll export/acceptance.	Uses shared identity/permissions; parallel domain lane with restricted HR schema.	Offline clock reconciliation, missed punch, rule boundary, reopen/correction, rejected payroll ID and control-total tests.	Approved hours and provider export reconcile for a full test period.
P08-3 Customer and stored value	Customer service cases, loyalty, points, gift card/store credit, consent, privacy request, marketing preference, fraud hold and liability controls.	Depends on checkout customer/tender hooks; parallel with other P08 domains.	Identity merge, consent version, offline redemption limit, replacement, refund, privacy access/correction/export and liability reconciliation.	Value ledgers reconcile and minimum-necessary access/privacy evidence passes.
P08-4 Finance, bank and HST	Vendor invoice matching, terminal/deposit settlement, bank CSV/OFX/QFX/PDF import, reconciliation, close workpapers, HST working report and accounting export.	Depends on V0.5 sale/tender/cash/purchasing ledgers; parallel with P08-1/2/3/5/6.	Duplicate statement, unmatched line, deposit in transit, vendor credit, tax classification, locked period/correction and export acceptance tests.	Accountant-approved test close with source-preserving reconciliation and HST workpapers.
P08-5 Loss, maintenance and continuity	Exception review, case evidence, asset/service incidents, maintenance schedules, emergency modes, one-person controls and recovery tasking.	Consumes read models from D/E/F; parallel implementation with strict sensitive-access boundaries.	Loss case authorization, device outage, power/network failure, emergency price/payment policy, one-person cash and maintenance escalation drills.	Manager completes drills without bypassing audit, safety or role separation.
P08-6 Paid licensing and administration	Plan versions, threshold notices, hosted billing adapter/webhooks, grace/hold, License Manager, grants/overrides, replacement/revocation and consented support.	Builds on P05-6; parallel with store domains; integrates plan-controlled features only at explicit boundaries.	Payment success/failure/duplicate webhook, transition/downgrade, expired grace, MFA/fresh-auth, tenant separation and historical lease reproduction.	Paid/free lifecycle is auditable and no billing/cloud event interrupts an active sale.
P08-7 Manager and owner integration	Unified queues, approvals, evidence drill-down, period/department status, cash outlook, risk and operational dashboards across all completed domains.	Depends on stable P08-1 through P08-6 read contracts; can begin with mocks.	Role-based end-to-end scenarios prove correct totals, restricted data, actionable exceptions and source links.	Manager/owner sign off daily, weekly and month-end decision journeys.
P08-8 Whole-store pilot	Run all selected departments, staff workflows, safety, finance and licensing in the pilot store with measured support and reconciliation.	Depends on P08-1 through P08-7 and V0.5 stability.	Full business-cycle rehearsal including recall, payroll period, bank/HST close, paid-plan event, continuity drill and restore verification.	No unresolved severity-1 issue; every material ledger/control total and operational drill passes.

V0.8 exit gate and feature freeze: the whole store can operate and close under controlled pilot conditions; paid licensing is administrable; safety, payroll, customer value, finance and continuity evidence are accepted by their accountable business roles. All planned V1 operational workflows are integrated before entering V1.0 certification. New business scope after this gate requires explicit re-planning and restarts every affected certification clock.

21.6 V1.0 phases — general-availability certification

Version purpose: harden the accepted operational product into a supportable single-store general-availability release. P10-1 through P10-5 run as parallel certification streams; all must close before the 30-day release pilot.

Phase	Deliverable and scope	Dependencies / parallel work	Independent verification	Exit evidence
P10-1 Correctness and defect closure	Complete all V1 P0 and approved P1 requirements, including final period lock/reopen/prior-period adjustments, reversible customer deduplication/merge and owner cash/risk outlook; trace code/tests/runbooks, reconcile deferrals and remove prototype-only assumptions.	Starts after the V0.8 feature freeze; finance, customer/owner controls and defect teams may run in parallel with other certification streams.	Locked-write/adjustment-lineage, merge/reversal/value-preservation, outlook reproducibility, requirement evidence audit, regression suite and severity/waiver review.	Zero open severity-1 defect and explicit disposition for every V1 requirement.
P10-2 Security, privacy and accessibility	Threat remediation, dependency/SBOM/signature review, device/account/admin penetration tests, privacy procedures and WCAG 2.2 AA/AODA assessment.	Parallel with P10-1/3/4/5; fixes return to owning lane and rerun certification.	Independent security testing, tenant/permission abuse suite, privacy scenarios and manual assistive-technology review.	Security, privacy and accessibility sign-offs with accepted residual risk.
P10-3 Capacity, offline and availability	Reference-load optimization, latency, storage growth, 14-day offline, queue catch-up, 30-day soak, thermal/disk monitoring and availability measurement.	Parallel certification using release-candidate hardware/software.	Published p95/p99, 24-register/40-device load, 1.5M events/day, 250GB attachment policy, catch-up and failure-injection tests.	All section 9 budgets pass with ≥30% sustained appliance headroom.
P10-4 Install, migration, training and support	Factory/replacement images, owner/helper installation, legacy import mappings/control totals, role curricula, knowledge base, escalation and support tooling.	Parallel with certification; uses frozen release candidate for final rehearsal.	Non-technical fresh install, repeatable import/rollback, competency assessment and support-ticket simulations.	Signed migration totals, ≥90% critical-task completion and staffed support readiness.
P10-5 Continuity and release operations	Backup/restore, replacement box, signing-key/billing recovery, staged update, incompatible rollback block, forward fix, hotfix and incident communications.	Parallel with P10-1 through P10-4; lane H owns drills independently of feature teams.	Power/disk/server/cloud failures, RPO/RTO restore, revoked key, failed update, emergency hotfix and store-data export exercises.	Recovery objectives, release controls and owner-visible continuity runbooks pass.
P10-6 Thirty-day release pilot	Deploy the signed release candidate to the approved store, monitor scheduled open hours, reconcile daily/weekly/month-end and operate normal support/on-call. The 30-day clock restarts after any material ledger, sync, payment, licensing, security-boundary or SQLite schema/migration change.	Requires P10-1 through P10-5 sign-off; only controlled critical fixes enter the candidate, and every accepted fix has an explicit clock/re-certification decision.	Thirty consecutive days without unplanned inability to trade, measured availability, live restore verification and owner/role acceptance.	Pilot report, change/clock log, defect disposition, operational metrics and explicit store-owner acceptance.
P10-7 GA release decision	Freeze artifacts, publish compatibility/support policy, sign evidence, approve rollback/forward-fix position and authorize Stable channel.	Depends on P10-6 and closure of all GA gate conditions.	Independent release audit verifies artifact signatures, SBOM, schemas, migrations, support docs, pilot evidence and reproducibility.	Product Owner, Engineering, QA, Security, Operations and pilot owner sign the V1.0 go/no-go record.

V1.0 GA gate: zero unresolved severity-1 defects; all P0 and approved P1 requirements accepted; no duplicate effects across fault tests; 30 consecutive stable pilot days; security, privacy, accessibility, performance, restore, migration, payment/hardware, support and licensing recovery approved.

21.6A Technical task-ID source appendix — every task through V1.0

This is the technical source behind the owner-readable register above: every row remains a small execution unit with its exact ID, status and independent acceptance result. Use the owner-readable task checklists for normal progress review. The browser calculates the exact completed, active, parked and not-started child counts below.

V0.2 technical appendix V0.5 technical appendix V0.8 technical appendix V1.0 technical appendix

P02-6 completed integration checkpoint — 12 child packages

Child	Bounded outcome	Status	Independent acceptance
P02-6.1	Real Store and License Cloud JAR boot, authenticated health and stable service identity.	Done & tested	Lifecycle, identity and restart assertions passed and are included in the consolidated evidence.
P02-6.2	One-time claim, installation identity and cached signed lease.	Done & tested	Claim, reuse, expiry, binding and offline lease tests passed.
P02-6.3	Flutter SQLite, atomic outbox, durable lease pins and snapshot state.	Done & tested	Restart, clock rollback, cursor, snapshot and replay suites passed independent review.
P02-6.4	Separate trusted-device and short-lived user-session authorization.	Done & tested	Missing, revoked, expired and stale-permission sessions fail closed; independent re-audit passed.
P02-6.5	Bounded, content-addressed attachment upload/download.	Done & tested	Integrity, idempotency, authorization, restart and canonical-error tests passed.
P02-6.6	Replaceable payroll/accounting simulators and explicitly disabled AI adapter.	Done & tested	Provider-swap/boundary tests passed; no AI SDK, key, network client or service exists.
P02-6.7	Signed update compatibility windows and invalid-update rejection.	Done & tested	Signed exact-source packaging and 22 release/compatibility tests passed independent re-audit.
P02-6.8	Verified backup and explicitly empty replacement-root restore harness.	Done & tested	Integrity, encryption, secret-scrubbing, restore-epoch and path-safety tests passed.
P02-6.9	Real online Flutter claim and Store push/pull synchronization.	Done & tested	Real services accepted the claim and converged the local effects exactly once.
P02-6.10	Cached-lease operation during an actual License Cloud outage.	Done & tested	Cloud stop/restart and cached-lease offline-ready behavior passed in the real-JAR journey.
P02-6.11	Replacement-box epoch change, snapshot and retained-event replay.	Done & tested	Epoch advanced; three client effects became three acknowledged Store effects, with zero missing and zero duplicate.
P02-6.12	Sanitized JSON/HTML proof, traceability, final independent audit and SRS closure.	Done & tested	Evidence, traceability, contracts, provenance, security scan and final independent gate all passed.

Technical task-ID appendix — V0.5 canonical source rows (closed by default)

This appendix supplies the exact task IDs used by the owner-readable checklists above. It is closed by default to avoid showing every status twice.

Child	Bounded outcome	Status	Plain-language acceptance
P05-1.1	Shared Flutter design, accessibility and safe error components.	Done & tested	Independent audit, 11/11 tests, clean analysis, golden/keyboard/semantics/contrast/text-scale checks and NFR-A11Y-001 evidence passed.
P05-1.2	Client SQLite, authentication and permission/policy cache.	Done & tested	Independent re-audit accepted all delayed-policy/concurrent-session adversarial cases, 16/16 focused tests, 24/24 local-data tests, 5/5 security tests, clean analysis and linked evidence.
P05-1.3	Pairing, revocation and device policy refresh.	Done & tested	Independent audit accepted 12/12 focused tests, 36/36 local-data tests, 5/5 security tests, clean analysis, durable terminal revocation, restart/concurrency/corruption checks and linked SEC-001 contribution evidence.
P05-1.4	Atomic outbox/pull engine and restart recovery.	Done & tested	Final independent audit accepted 51/51 local-data, 21/21 sync and 5/5 database-routing tests, exact receipt/migration/pull/snapshot/restart behavior, clean analysis, linked evidence and zero dependency cycles.
P05-1.5	Eight uniquely identified and signed Flutter application artifacts.	Done & tested	Eight source identities and initial isolated bundles, canonical-version preflight rejection, a fresh Register build, 56 icon checks, independent re-audit and linked evidence passed. Production signing/notarization is a later Owner validation gate.
P05-1.6	Register, Store Operations, Setup/Support, Account/Licensing and minimum Manager compositions.	Done & tested	Final independent re-audit accepted 56/56 unique checks, clean analysis, exact fail-closed Setup status, all denial/sync states, true 390×844 layout at 200% scaling, bounded feature claims and linked evidence.
P05-2.1	Product, UPC, PLU, unit-of-measure and weighed-item catalogue.	Done & tested	Final independent audit passed 35/35 catalogue, SQLite and architecture checks, including GTIN, search and fail-closed total schema loss. Evidence.
P05-2.2	Effective price, tax and refundable-deposit snapshots.	Done & tested	Final independent audit passed 18/18, exact arithmetic, impossible-snapshot rejection and fail-closed schema history. Accountant validation remains parked. Evidence.
P05-2.3	Promotion/coupon precedence and basket construction.	Done & tested	Final independent audit passed 21/21 sales, 3/3 architecture and the 100-case exact arithmetic/forged-evidence matrix. Evidence.
P05-2.4	Suspend/retrieve, authorized void/cancel and immutable pre-tender merchandise evidence.	Done & tested	Final gates passed 51/51 sales tests and the 58-task combined rebuild; corrections retain exact reason/approval, unpaid merchandise remains AWAITING_TENDER, and customer copies cannot imply payment. Evidence.
P05-2.5a	Trusted paid-sale evidence and read-only deterministic return eligibility/proration.	Done & tested	15/15 focused and 66/66 complete sales tests plus independent business/technical gates passed; exact cancellation-safe segments create no refund, inventory effect or spendable authorization. Evidence.
P05-2.5b.a.1	Freeze the controlled-return boundary.	Done & tested	The closed domain makes authorization, exact quantity/disposition intent and later custody responsibilities explicit while creating no cash, card, stored-value or inventory posting. Durable reservation/custody remain later rows. 20/20 tests and the independent gate passed. Evidence.
P05-2.5b.a.2	Define controlled-return case types.	Not started	Receipt-linked, no-receipt, recall, quality-guarantee and exchange cases remain explicitly distinct.
P05-2.5b.a.3	Version the return policy.	Building — R2 SQLite policy evidence	Every decision preserves an immutable policy ID, version, effective period and source. Canonical schema, fingerprint and immutability tests are active.
P05-2.5b.a.4	Apply explicit policy precedence.	Not started	Mandatory remedy, sale-disclosed policy, current policy and approved exception are evaluated in a defined order.
P05-2.5b.a.5	Calculate the return window.	Building — R3 trusted-source integration	Store-local calendar and Toronto daylight-saving boundary tests now pass; the production paid-receipt adapter must still supply and transactionally bind the authoritative business date and zone.
P05-2.5b.a.6	Configure item and policy restrictions.	Not started	Item, category, department, condition, packaging, fee and tender rules change through versioned policy rather than code.
P05-2.5b.b.1	Load trusted paid-receipt evidence.	Not started	Only an immutable final paid receipt qualifies; an unpaid merchandise copy never does.
P05-2.5b.b.2	Bind the original sale scope.	Building — R3 production receipt source	Domain tests now deny wrong store, namespace, mode, currency and source fingerprints; the production adapter and same-transaction reload remain.
P05-2.5b.b.3	Validate requested receipt lines.	Building — R3 authoritative recalculation	Domain tests bind original line, product, unit, scale and quantity; the repository must still recalculate from the final paid receipt and current return history.
P05-2.5b.b.4	Recalculate authoritatively.	Not started	The transaction reloads receipt and active return history; the read-only quote is never spendable authority.
P05-2.5b.b.5	Reserve exact quantity segments.	Not started	Reservations use exact non-overlapping original-line quantity segments.
P05-2.5b.b.6	Enforce cumulative ceilings.	Not started	All prior and parallel returns cannot exceed the original quantity or payable value.
P05-2.5b.b.7	Reject stale return evidence.	Not started	Expired or changed quote, policy, receipt or returned-state evidence fails closed.
P05-2.5b.b.8	Reject invalid receipt scope.	Not started	Wrong-store, TRAINING, forged, corrupt and cross-namespace evidence is denied without sensitive detail.
P05-2.5b.c.1	Reauthorize current operating context.	Building — R2 trusted-control contract	Device, user, session, permission policy and service-lane assignment are rechecked in the writer transaction; caller fields cannot establish authority.
P05-2.5b.c.2	Add return-specific permissions.	Building — R2 default-deny permissions	Creating, approving, no-receipt handling and disposition use separate least-privilege authorities.
P05-2.5b.c.3	Evaluate approval thresholds.	Building — R2/R3 threshold completion	Inclusive amount boundaries plus allowed reason/disposition tests pass; age, receipt state and category inputs still need trusted-source integration.
P05-2.5b.c.4	Require reason and condition evidence.	Not started	Every controlled return retains a bounded reason, item condition and evidence class.
P05-2.5b.c.5	Bind one-use approval evidence.	Building — R2 approval contract and schema	Approval binds exact return/version/amount/lines/policy/actor and is short-lived and one-use.
P05-2.5b.c.6	Separate requester and approver.	Building — R2 separation controls	Self-approval is denied and configurable employee or related-party separation is enforced.
P05-2.5b.c.7	Reauthorize replay and audit denial.	Done & tested	Exact replay rechecks current trusted authority; revoked, stale or mismatched controls fail closed and create one durable denial audit without repeating an effect. The 50-case matrix completed 100 durable attempts; repository 29/29, complete sales 313/313 and both independent audits passed. R2.2 evidence.
P05-2.5b.d.1	Model no-receipt cases explicitly.	Done & tested	Separate sealed no-receipt command, source and valued-line types carry no fabricated original sale, receipt or tender identity and accept no caller-supplied money. 20/20 tests and the independent gate passed. Evidence.
P05-2.5b.d.2	Default no-receipt returns off.	Not started	No-receipt returns remain disabled until an owner-approved versioned policy is active.
P05-2.5b.d.3	Prove store product provenance.	Not started	The item must belong to the store catalogue and retain bounded provenance evidence.
P05-2.5b.d.4	Value no-receipt merchandise deterministically.	Not started	A policy-selected price source preserves exact price, version, period and calculation.
P05-2.5b.d.5	Enforce no-receipt limits.	Not started	Period, value, quantity, category and privacy-safe customer-token limits are atomic.
P05-2.5b.d.6	Restrict no-receipt value route.	Not started	Only an approved non-cash route is allowed; the system never infers an original tender.
P05-2.5b.d.7	Require no-receipt manager approval.	Not started	The customer receives a truthful explanation of valuation and restrictions before approval.
P05-2.5b.d.8	Minimize identity verification.	Not started	Purpose and consent are recorded without storing an identity-document number, image or unnecessary attributes.
P05-2.5b.d.9	Keep no-receipt tax treatment explicit.	Not started	The system never automatically claims an HST reduction without approved accounting policy and source evidence.
P05-2.5b.e.1	Separate credited and received quantities.	Not started	Credited quantity and physically received quantity remain independently visible and reconcilable.
P05-2.5b.e.2	Receive into a non-saleable location.	Not started	A physical return enters controlled return intake before any later disposition.
P05-2.5b.e.3	Capture grocery condition evidence.	Not started	Seal/open state, damage/spoilage, lot/batch, date and temperature evidence are retained when applicable.
P05-2.5b.e.4	Authorize safe restock.	Not started	Only a policy-eligible, safely inspected item can move back to saleable stock.
P05-2.5b.e.5	Protect against unsafe perishable restock.	Not started	Opened, spoiled or unsafe perishables move to quarantine or waste, never saleable stock.
P05-2.5b.e.6	Control unknown cold-chain returns.	Not started	An item with unknown required temperature history cannot return to saleable inventory.
P05-2.5b.e.7	Quarantine recalled returns.	Not started	Every recalled item links to its recall and remains segregated regardless of receipt status.
P05-2.5b.e.8	Support no-physical-item quality credit.	Not started	An approved quality-guarantee credit creates no phantom received stock.
P05-2.5b.e.9	Post inventory movement once.	Not started	Custody and disposition movements occur exactly once; correction uses an explicit adjustment, never deletion.
P05-2.5b.e.10	Reconcile returned-item disposition.	Not started	Credited, received, restocked, quarantined, wasted and vendor-return quantities reconcile exactly.
P05-2.5b.f.1	Link two explicit exchange legs.	Not started	An exchange is an authorized return plus a distinct replacement sale; the original sale is never rewritten.
P05-2.5b.f.2	Price the replacement sale.	Not started	Current price and tax rules apply unless a versioned approved even-exchange rule says otherwise.
P05-2.5b.f.3	Control even-exchange price protection.	Not started	Price protection retains exact policy and approval evidence.
P05-2.5b.f.4	Consume exchange return credit once.	Not started	The linked replacement sale can reserve and consume the exact return credit only once.
P05-2.5b.f.5	Tender a higher exchange balance.	Not started	Any additional customer balance enters normal sale tendering.
P05-2.5b.f.6	Route a lower exchange residual.	Not started	Residual value uses only an allowed P05-3.6 refund or credit route.
P05-2.5b.f.7	Resume an interrupted exchange.	Not started	Interruption cannot leave an orphaned return, duplicate credit or free replacement sale.
P05-2.5b.f.8	Cancel an incomplete exchange safely.	Not started	Immutable transitions release unspent reservations without erasing either leg.
P05-2.5b.g.1	Exclude high-risk sensitive data.	Not started	No PAN, sensitive authentication data, full identity-document number or identity image is stored.
P05-2.5b.g.2	Bind privacy purpose and retention.	Not started	Notice or consent, collection purpose, retention and role access accompany personal return evidence.
P05-2.5b.g.3	Minimize cashier-visible review data.	Not started	The cashier sees the minimum decision and next action; restricted review facts remain hidden.
P05-2.5b.g.4	Detect objective return-risk facts.	Not started	Copied receipts, repeated no-receipt patterns, product mismatch and limit evasion produce neutral evidence.
P05-2.5b.g.5	Place a neutral review hold.	Not started	A hold requests authorized review without accusing the customer or silently denying from a score.
P05-2.5b.g.6	Review employee and related-party returns.	Not started	Configured employee or related-party transactions receive required independent review.
P05-2.5b.g.7	Emit a loss-prevention case link.	Not started	A privacy-minimized source link can feed the later loss-prevention workflow.
P05-2.5b.h.1	Define the return-credit lifecycle.	Building — R2 durable transitions	Domain balance and partial-spend terminal-release tests pass; durable writer-transaction transitions and restart reconstruction remain under repository implementation.
P05-2.5b.h.2	Prove the no-money boundary.	Done & tested	Return authorization creates no cash, card, stored-value or inventory effect. Schema 17/17, codec 12/12, repository 17/17 and full sales 296/296 passed; exact refund and exchange authorizations, rollback and two independent no-P0/P1 reviews are linked in the R2.1 evidence.
P05-2.5b.h.3	Create constrained SQLite return schema.	Building — schema accepted; tamper gate remains	The schema passed 17/17 focused and the complete sales module passed 296/296 plus independent audit; the repository binds decoded payloads to normalized projections and round-trips after restart. The separate restart tamper matrix remains before this product row can be checked.
P05-2.5b.h.4	Commit controlled-return evidence atomically.	Not started	Authorization, reservation, custody, audit and outbox all commit or all roll back.
P05-2.5b.h.5	Make commands idempotent.	Done & tested	Exact replay returns the stored authorization without another write or business effect; changed input under the same command ID conflicts before controls or writes. Current-denial evidence is durable and integrity-checked. Repository 29/29, complete sales 313/313 and both independent audits passed. R2.2 evidence.
P05-2.5b.h.6	Converge return races.	Not started	Same-command and competing-return races yield one ceiling-preserving winner.
P05-2.5b.h.7	Recover and detect tamper after restart.	Not started	Durable state resumes safely and altered or missing evidence fails closed.
P05-2.5b.h.8	Enforce safe offline return behavior.	Not started	WAN outage works through the local server; an isolated lane without a bounded reservation cannot authorize an over-return.
P05-2.5b.i.1	Preserve exact credit components.	Not started	Original selling, discount, taxable selling, deposit, tax and payable credits remain exact per line.
P05-2.5b.i.2	Preserve sale and return business dates.	Not started	Original sale date and current return-authorization date remain distinct and reproducible.
P05-2.5b.i.3	Prepare compliant refund source data.	Not started	P05-3.6 receives exact refund or credit-note source data; intake is never labelled paid or refunded.
P05-2.5b.i.4	Preserve promotion-funding recovery intent.	Not started	Store-funded and vendor-funded promotion components remain available to later recovery workflows.
P05-2.5b.i.5	Emit loyalty-correction intent.	Not started	A deterministic intent describes later earned or redeemed loyalty correction without mutating that ledger.
P05-2.5b.i.6	Time qualifying-sales reduction correctly.	Not started	License usage includes the return only after its financial effect becomes final.
P05-2.5b.i.7	Integrity-bind audit and outbox.	Not started	Source, actor, approver, reason, policy, totals, target and payload are bound to the exact aggregate.
P05-2.5b.j.1	Map truthful operator states.	Not started	Eligible, approval-required, denied, reserved, expired and refund-pending each show one safe next action.
P05-2.5b.j.2	Render honest intake acknowledgement.	Not started	Authorization evidence cannot be mistaken for a completed refund receipt.
P05-2.5b.j.3	Pass focused controlled-return tests.	Not started	Domain, SQLite, concurrency, retry, restart, tamper and grocery scenarios pass deterministically.
P05-2.5b.j.4	Pass clean sales and Store regression.	Not started	Every affected module and booted Store Server test passes from a clean build.
P05-2.5b.j.5	Pass independent acceptance and evidence gate.	Not started	Business, technical and adversarial reviews report no open P0/P1 issue and published evidence agrees with the checklist.
P05-2.5b.o.1	Validate store return policy and legal disclosure.	Owner validation required	Owner or legal reviewer accepts windows, exclusions, fees, proof, mandatory remedies and customer disclosure.
P05-2.5b.o.2	Validate GST/HST and deposit treatment.	Owner validation required	Accountant accepts tax-inclusive, partial, fee, deposit, no-receipt and exchange treatment.
P05-2.5b.o.3	Validate return privacy policy.	Owner validation required	Privacy reviewer accepts identity checks, notice or consent, tokenization, retention and role access.
P05-2.5b.o.4	Validate grocery food-safety disposition.	Owner validation required	Food-safety lead accepts perishable, cold-chain, recall, quarantine, restock and disposal rules.
P05-2.5b.o.5	Validate loss-prevention controls.	Owner validation required	Loss-prevention owner accepts limits, employee controls and neutral review triggers.
P05-2.5b.o.6	Validate cashier and service-desk usability.	Owner validation required	Representative staff complete return, exchange and recovery journeys accessibly.
P05-2.5b.o.7	Validate regulated-goods and container boundaries.	Owner validation required	Owner confirms exclusions or separate handling for regulated goods and container-deposit redemption.
P05-2.6a	Settlement and receipt application use cases.	Not started	Trusted server context constructs the command, invokes a settlement port and provides restart-safe receipt lookup without accepting client-minted authority or time.
P05-2.6b	OpenAPI sale, settlement and receipt contracts.	Not started	Contract-first settle and receipt-lookup operations preserve idempotency, optimistic versions, evidence hashes and truthful LIVE/TRAINING response fields.
P05-2.6c	Cashier-safe settlement error catalogue and mappings.	Not started	Every not-ready, unresolved, stale, conflict, denial, missing-receipt and integrity failure has stable code, correlation, retryability and safe next action.
P05-2.6d	Store Server controller, security, wiring and schema boot.	Not started	Device plus user authorization, repository/service/controller wiring, deterministic migrations and HTTP replay/restart/security tests run in the booted Store JAR.
P05-2.6e	Receipt print worker and controlled reprint integration.	Not started	The worker dispatches verified immutable content from durable jobs; retry or approved reprint cannot create another sale/payment effect.
P05-2.6f	Offline Flutter Register checkout-to-receipt integration.	Not started	Register local SQLite completes and recovers scan, tender, settle, lost response, receipt display and reconnect with no lost or duplicate effect.
P05-3.1	SQLite-backed full-cash tender ledger/simulator and exact change.	Done & tested	14/14 tender SQLite, 12/12 cash domain/rounding and 95/95 clean sales tests plus independent business/technical gates passed. Sale remains TENDERING. Evidence.
P05-3.1a	Frozen-sale and exact full-cash allocation.	Done & tested	One positive CAD sale/version/snapshot is bound to one tender session; allocation equals the exact merchandise/tax/deposit payable and cannot be duplicated.
P05-3.1b	Trusted Canadian cash rounding, received cash and exact change.	Done & tested	The caller policy is only an expected value; the transaction loads the trusted effective policy. Five-cent and 1¢/2¢ zero-cash cases reconcile without changing the sale allocation.
P05-3.1c	Transactional cashier, till and policy authorization.	Done & tested	The same open SQLite connection resolves authorization/current till/rounding, defaults to deny, rejects caller-minted policy and serializes till close versus tender safely.
P05-3.1d	Atomic sale, tender, custody, audit, idempotency and outbox evidence.	Done & tested	Every effect commits together or rolls back; exact replay is stable, changed replay conflicts and concurrent second tender creates no duplicate cash.
P05-3.1e	LIVE/TRAINING cash-custody isolation and truthful zero-cash presentation.	Done & tested	LIVE stores exact physical drawer delta only when cash changes hands; TRAINING and zero-rounded live totals create no physical effect.
P05-3.1f	Restart, schema/tamper, scope and settlement-handoff verification.	Done & tested	Restart/DDL/history/relational tamper fails closed; raw IDs are namespace/mode scoped; later sync uses a separate globally unique event ID; settlement mapping preserves exact allocation/gross/change/net/policy/time.
P05-3.2	Authenticated debit/credit terminal binding before settlement.	Done & tested	The clean 131/131 payment and sales gate plus independent business, technical and adversarial reviews passed. Approval, decline, definitely-not-sent, uncertain dispatch and partial states are durable, truthful and create at most one effect. Sale remains TENDERING. Evidence.
P05-3.2a	Exact frozen-sale, lane, till, cashier, provider and terminal binding.	Done & tested	Every request binds namespace/mode, store/lane/device/till/shift/cashier, business date, sale/version/snapshot, tender identity, amount, terminal/provider/merchant and configuration version; changed or cross-tenant binding fails closed.
P05-3.2b	Closed signed raw wire contract and authoritative local timestamps.	Done & tested	The response carries binding/effect, signedAt and detached Ed25519 signature; the strict decoder rejects unknown/missing/mismatched fields. Terminal decision, server receive and later verification times are separate and ordered.
P05-3.2c	Atomic decision, processor effect, tender mutation, audit and outbox evidence.	Done & tested	Verified response, payment transition/effect and card tender command/audit/outbox commit once or roll back together. Exact replay is stable; global LIVE callback, transaction and provider-reference reuse is rejected.
P05-3.2d	Decline and definitely-not-sent basket release and fresh retender.	Done & tested	The exact frozen basket/totals survive; unpaid session becomes ABANDONED, the sale returns to AWAITING_TENDER and a fresh debit/credit attempt succeeds, including after restart.
P05-3.2e	Unknown, partial, replay and cashier-safe presentation.	Done & tested	Unknown and partial block another tender with exact approved/remaining values and safe action text; every outcome replays after restart without another terminal call and no state produces a final paid receipt.
P05-3.2f	LIVE/TRAINING isolation, cash/card coexistence and schema upgrade.	Done & tested	Training creates no LIVE or physical processor effect. A genuine P05-3.1 tender V1 store migrates transactionally to V2 with cash evidence preserved, and cash/card sessions coexist across restart.
P05-3.2g	Restart cryptographic verification, concurrency and bounded command transactions.	Done & tested	Restart re-verifies persisted signatures against the authoritative key; wrong-key/tamper fails. An in-flight duplicate returns PRESENTED without a second charge or false UNKNOWN, terminal I/O holds no SQLite transaction and normal writes use constant-work readiness checks.
P05-3.3	Split tender and partial approval.	Done & tested	The clean 172/172 payment and sales gate plus independent business, technical and adversarial reviews passed. Ordered cash/debit/credit portions equal the frozen payable exactly; sale remains TENDERING and no final receipt is issued. Evidence.
P05-3.3a	Ordered immutable tender ledger and exact balance.	Done & tested	Up to 100 portions retain stable sequence and identity; confirmed plus remaining always equals the frozen CAD payable, with zero over- or under-collection.
P05-3.3b	Partial approval and multi-card continuation.	Done & tested	A processor partial becomes its exact allocation once; two-card and three-card journeys continue from the authoritative remaining amount and survive restart.
P05-3.3c	Cash/card ordering, custody and Canadian rounding.	Done & tested	Persisted cash→card and card→cash paths reconcile. Non-final cash is exact with zero rounding; only final residual cash uses the trusted rounding policy, received cash and change.
P05-3.3d	Concurrency, replay and recovery blocking.	Done & tested	A concurrent continuation has one terminal/financial winner. Exact replay is stable; stale/overpay fails before terminal I/O; PRESENTED and UNKNOWN block every further tender.
P05-3.3e	SQLite migration, indexed scale and tamper-safe restart.	Done & tested	Payment V3 and tender V1/V2 migrations use frozen identities; a 10,000-attempt plan uses covering indexes; adoption is one-time/rollback-safe and altered history/bindings fail closed.
P05-3.3f	Truthful CAD cashier presentation and TRAINING isolation.	Done & tested	The session-aware view shows values such as CAD $6.03, cash received/change/rounding and safe pending/recovery text. TRAINING is explicit and effect-free; no state claims a final receipt.
P05-3.3g	Combined clean evidence and independent acceptance.	Done & tested	172/172 clean tests, 61/61 focused adversarial checks, repository validation and all three independent closure gates passed with linked readable and machine evidence.
P05-3.4	Unknown outcome, inquiry-before-retry and duplicate callback control.	Done & tested	A timeout only permits a signed status inquiry; it never authorizes repayment. Verified terminal decisions or provider-guaranteed final-no-charge proof converge once. Evidence.
P05-3.4a	Durable original terminal request and response deadline.	Done & tested	The exact request identity, digest and server deadline commit atomically with PRESENTED before terminal I/O and survive restart. Fault injection proves all related rows roll back together; expiry permits inquiry only.
P05-3.4b	Signed closed inquiry outcomes.	Done & tested	FOUND, PENDING and provider-guaranteed NO_EFFECT_FINAL bind the original attempt, route, configuration, request, time and historical verification key. Outer and nested FOUND signatures reverify independently at restart.
P05-3.4c	Payment SQLite V4 recovery evidence and migration.	Done & tested	Request, legacy candidate, inquiry claim/result, supersession, conflict, transition-root and recovery-application evidence are immutable and migration-safe. Bidirectional restart checks reject missing or paired-deleted evidence.
P05-3.4d	Inquiry-before-retry service and prior-split preservation.	Done & tested	UNKNOWN and expired PRESENTED inquire outside SQLite transactions. Approval/partial appends once; decline/final no-charge releases only a zero-value session; every earlier portion remains exact.
P05-3.4e	Callback/inquiry race and duplicate convergence.	Done & tested	One payment compare-and-swap plus an immutable supersession tombstone converges races. An exact callback winner replays after restart before any late inquiry envelope, with no second terminal call.
P05-3.4f	Cashier/manager recovery presentation and permissions.	Done & tested	Typed WAIT/Check payment status/continue/new-session actions, authoritative CAD balance, cashier permission plus escalation, no manual override, plain LIVE/TRAINING wording and no paid/final receipt claim passed business review.
P05-3.4g	Crash, restart, tamper, key-rotation and scale acceptance.	Done & tested	Restart, wrong-key/scope/config, migration rollback, provider-breach, 10,000-row index, missing evidence, paired deletion and callback-winner crash-window tests pass.
P05-3.4h	Combined clean evidence and independent acceptance.	Done & tested	205/205 clean payment and sales tests, repository validation, business acceptance and the final focused adversarial re-audit passed with no remaining P0/P1 finding. Evidence.
P05-3.5	Exact sale settlement and immutable final paid receipt.	Done & tested	Exact successful tender allocations complete the sale and issue immutable final-paid-receipt evidence. Evidence.
P05-3.5a	Authorized settlement command and trusted transactional controls.	Done & tested	Store Server controls independently reauthorize device, user, cashier, till, lane, shift, permission version and entitled printer.
P05-3.5b	Exact readiness and unresolved-payment blockers.	Done & tested	Only exact, resolved, authorized tender allocations can complete.
P05-3.5c	Store-scoped final receipt number allocation.	Done & tested	Monotonic store/mode identity is restart, rollback and concurrency safe.
P05-3.5d	Immutable final receipt and ordered tender evidence.	Done & tested	Receipt scalars, merchandise and ordered tender rows are integrity-bound and tenant swaps fail closed.
P05-3.5e	Atomic sale/session settlement, audit and outbox.	Done & tested	Sale, tender session, receipt, audit and exact outboxes commit once together or all roll back.
P05-3.5f	Replay, concurrency, restart and tamper acceptance.	Done & tested	Replay reauthorizes current controls; one-winner and missing, altered, deleted, swapped and route-rewritten evidence cases pass.
P05-3.5g	Truthful paid receipt and printer handoff.	Done & tested	Deterministic LIVE/TRAINING content, printer-route authorization and durable pre-I/O uncertainty prevent false printed claims and auto-reprints.
P05-3.5h	Combined clean evidence and independent acceptance.	Done & tested	30/30 payment, 221/221 sales and 20/20 Store Server tests plus three independent reviews passed. Evidence.
P05-3.6a.1	Load approved return-credit identity.	Not started	Load one approved return-credit ID and its immutable version.
P05-3.6a.2.1	Bind refund namespace.	Not started	The refund uses the approved return credit's exact tenant namespace.
P05-3.6a.2.2.1	Bind refund store	Not started	The refund store exactly matches the approved return-credit store.
P05-3.6a.2.2.2	Bind refund operating mode	Not started	The refund cannot cross LIVE and TRAINING modes.
P05-3.6a.2.3	Bind refund currency.	Not started	The refund currency exactly matches the approved return credit.
P05-3.6a.2.4.1	Bind original sale lineage	Not started	The refund identifies exactly one immutable originating sale.
P05-3.6a.2.4.2	Bind final receipt lineage	Not started	The refund identifies exactly one immutable final receipt for the originating sale.
P05-3.6a.3.1	Reauthorize current user identity.	Not started	The writer transaction verifies the current authenticated user before refund authority is used.
P05-3.6a.3.2	Reauthorize current session.	Not started	An expired, replaced or mismatched session cannot authorize the refund.
P05-3.6a.3.3	Reauthorize current device.	Not started	An untrusted, revoked or wrong-store device cannot authorize the refund.
P05-3.6a.3.4	Reauthorize refund permission.	Not started	The user's current effective role must grant the required refund permission.
P05-3.6a.3.5	Reauthorize refund amount limit.	Not started	The approved amount remains within the user's current refund limit.
P05-3.6a.4.1	Reject a spent return credit.	Not started	A fully consumed credit cannot fund another refund.
P05-3.6a.4.2	Reject a revoked return credit.	Not started	A currently revoked credit cannot move money.
P05-3.6a.4.3	Reject an expired return credit.	Not started	A credit beyond its trusted expiry cannot fund a refund.
P05-3.6a.4.4	Reject a stale return-credit version.	Not started	A command using an older credit version fails closed.
P05-3.6a.4.5.1	Reject changed return-credit identity	Not started	An altered return-credit identifier fails integrity verification.
P05-3.6a.4.5.2	Reject changed return-credit amount	Not started	An altered approved return-credit amount fails integrity verification.
P05-3.6a.4.5.3	Reject changed return-credit lineage	Not started	Altered sale or receipt lineage fails integrity verification.
P05-3.6b.1	Define original-tender allocation rule.	Not started	Use one versioned deterministic rule for refunding original tenders.
P05-3.6b.2	Cap each tender refund.	Not started	Original settled value less prior effects is the hard maximum for each tender.
P05-3.6b.3	Reconcile split allocations.	Not started	All partial and split allocations add exactly to the approved return credit.
P05-3.6b.4.1	Reject allocation overflow.	Not started	An allocation above the available original tender value fails closed.
P05-3.6b.4.2	Reject a zero allocation.	Not started	A zero-value tender allocation cannot enter the refund plan.
P05-3.6b.4.3	Reject a wrong-currency allocation.	Not started	Every tender allocation must use the refund currency.
P05-3.6b.4.4	Reject a wrong-mode allocation.	Not started	An allocation cannot cross LIVE and TRAINING payment evidence.
P05-3.6b.4.5	Reject a reordered allocation plan.	Not started	Changed tender order is detected as a changed refund request.
P05-3.6c.1.1	Reauthorize the current till.	Not started	The payout uses the cashier's current assigned till.
P05-3.6c.1.2	Reauthorize the current lane.	Not started	An inactive, expired or different lane cannot pay the refund.
P05-3.6c.1.3	Reauthorize the current shift.	Not started	The cash payout requires the current open shift.
P05-3.6c.1.4	Reauthorize the current cashier assignment.	Not started	The current user must remain the cashier assigned to the till.
P05-3.6c.1.5	Reauthorize the current drawer route.	Not started	The payout targets the currently authorized physical or simulated drawer.
P05-3.6c.2	Persist cash custody reduction.	Not started	Record one exact cash refund custody movement with source and actor.
P05-3.6c.3	Apply cash refund rounding.	Not started	Trusted Canadian rounding and customer payout evidence reproduce exactly.
P05-3.6c.4	Validate physical cash payout.	Owner validation required	A real drawer and observed payout complete without a duplicate effect.
P05-3.6d.1	Load original card reference.	Not started	Read the immutable original card attempt and approved provider reference.
P05-3.6d.2.1.1	Bind original payment provider	Not started	The refund uses the provider that accepted the original payment.
P05-3.6d.2.1.2	Bind original merchant route	Not started	The refund uses the merchant account that accepted the original payment.
P05-3.6d.2.2	Bind original terminal route.	Not started	The refund targets the terminal identity permitted by the original provider route.
P05-3.6d.2.3.1	Bind original card-refund store	Not started	The card refund cannot cross the original store.
P05-3.6d.2.3.2	Bind original card-refund mode	Not started	The card refund cannot cross LIVE and TRAINING modes.
P05-3.6d.3.1	Reject a revoked terminal route before I/O.	Not started	A revoked terminal cannot receive an external refund request.
P05-3.6d.3.2	Reject a changed terminal route before I/O.	Not started	A route changed after authorization must be approved again before transport.
P05-3.6d.3.3	Reject an unentitled terminal route before I/O.	Not started	A route outside the current signed terminal entitlement cannot move money.
P05-3.6d.4	Create privacy-safe signed refund request.	Not started	The canonical signed request contains no PAN or sensitive authentication data.
P05-3.6d.5.1	Certify real terminal refund routing	Owner validation required	A real terminal and provider accept the exact bound refund route.
P05-3.6d.5.2.1	Certify real terminal refund-request privacy.	Owner validation required	Observed processor refund requests expose no PAN, authentication secret or prohibited payment material.
P05-3.6d.5.2.2	Certify real terminal refund-receipt privacy.	Owner validation required	Customer and merchant refund receipts expose only the approved masked payment evidence.
P05-3.6d.5.2.3	Certify real terminal refund-log privacy.	Owner validation required	Application, terminal and support logs expose no prohibited payment material.
P05-3.6e.1	Evaluate reversal eligibility.	Not started	Only trusted current provider evidence may make the original effect reversible.
P05-3.6e.2	Verify signed reversal decision.	Not started	Signed reversal requests and responses bind the original provider effect.
P05-3.6e.3	Control refund fallback.	Not started	Refund is allowed only after definite evidence that reversal did not move money.
P05-3.6e.4	Prevent reversal/refund double effect.	Not started	Retries and races can produce only one reversal-or-refund financial winner.
P05-3.6f.1.1	Simulate an approved refund.	Not started	A deterministic signed script returns one approved refund outcome.
P05-3.6f.1.2	Simulate a declined refund.	Not started	A deterministic signed script returns one declined refund outcome without moving value.
P05-3.6f.2.1	Simulate a definitely-not-sent refund.	Not started	The simulator proves transport rejected the request before the provider could accept it.
P05-3.6f.2.2	Simulate an unknown refund outcome.	Not started	The simulator produces an uncertain transport result that requires inquiry.
P05-3.6f.3.1	Simulate an eligible reversal.	Not started	The provider script identifies an original effect that remains reversible.
P05-3.6f.3.2	Simulate an ineligible reversal.	Not started	The provider script rejects reversal eligibility without moving money.
P05-3.6f.3.3	Simulate an approved reversal.	Not started	The provider script returns one signed approved reversal.
P05-3.6f.3.4	Simulate a declined reversal.	Not started	The provider script returns a definite signed decline without a financial effect.
P05-3.6f.3.5	Simulate an unknown reversal.	Not started	The provider script returns an uncertain reversal that requires inquiry.
P05-3.6f.4.1	Simulate signed refund inquiry.	Not started	A deterministic authenticated inquiry resolves the scripted provider state.
P05-3.6f.4.2	Simulate a provider callback.	Not started	A deterministic authenticated callback reports the scripted provider state.
P05-3.6f.4.3	Simulate a late provider response.	Not started	A response arriving after the transport timeout remains attributable to the original request.
P05-3.6f.4.4.1	Reorder inquiry and callback fixtures	Not started	Inquiry and callback fixtures converge in either arrival order.
P05-3.6f.4.4.2	Reorder inquiry and late-response fixtures	Not started	Inquiry and late-response fixtures converge in either arrival order.
P05-3.6f.4.4.3	Reorder callback and late-response fixtures	Not started	Callback and late-response fixtures converge in either arrival order.
P05-3.6g.1	Persist uncertainty before transport.	Not started	In-flight or uncertain state is durable before an external request can be accepted.
P05-3.6g.2	Block retry until inquiry.	Not started	No second money-moving request is permitted while outcome remains unknown.
P05-3.6g.3	Verify inquiry outcome.	Not started	Authenticated inquiry evidence is verified and stored before state changes.
P05-3.6g.4.1	Converge inquiry and callback race.	Not started	Simultaneous inquiry and callback evidence produce one terminal refund result.
P05-3.6g.4.2	Converge inquiry and operator-recovery race.	Not started	Simultaneous inquiry and authorized recovery produce one terminal refund result.
P05-3.6g.4.3	Converge callback and operator-recovery race.	Not started	Simultaneous callback and authorized recovery produce one terminal refund result.
P05-3.6g.5	Allow resend only after definite no-effect.	Not started	A new request is allowed only when trusted evidence proves no prior effect.
P05-3.6h.1.1.1	Constrain refund identity	Not started	Duplicate or invalid refund identity is rejected by SQLite.
P05-3.6h.1.1.2.1	Constrain refund tenant scope.	Not started	SQLite rejects a missing, invalid or cross-tenant refund namespace.
P05-3.6h.1.1.2.2	Constrain refund store scope.	Not started	SQLite rejects a missing, invalid or cross-store refund scope.
P05-3.6h.1.1.2.3	Constrain refund operating mode.	Not started	SQLite permits only an explicit valid LIVE or TRAINING refund mode and prevents cross-mode linkage.
P05-3.6h.1.1.3	Constrain refund state	Not started	Only allowed refund states can persist.
P05-3.6h.1.1.4	Constrain refund version	Not started	Invalid or stale refund aggregate versions are rejected.
P05-3.6h.1.2	Create constrained refund-effect schema.	Not started	The SQLite migration constrains each tender or provider effect to one refund.
P05-3.6h.1.3	Create constrained refund-receipt schema.	Not started	The SQLite migration constrains immutable refund receipt identity and lineage.
P05-3.6h.1.4	Create constrained refund-audit schema.	Not started	The SQLite migration constrains append-only refund audit identity and ownership.
P05-3.6h.1.5	Create constrained refund-outbox schema.	Not started	The SQLite migration constrains refund outbox identity, target and aggregate ownership.
P05-3.6h.2	Commit refund core atomically.	Not started	Refund state, return credit and payment effect commit together or roll back.
P05-3.6h.3.1.1	Preserve refund-receipt amounts	Not started	All canonical refund-receipt amounts reconstruct exactly.
P05-3.6h.3.1.2	Preserve refund-receipt scope	Not started	Refund-receipt tenant, store and mode reconstruct exactly.
P05-3.6h.3.1.3	Preserve refund-receipt times	Not started	Refund event and business times reconstruct exactly.
P05-3.6h.3.1.4	Preserve refund-receipt lineage	Not started	Sale, return and tender lineage reconstructs exactly.
P05-3.6h.3.2	Preserve ordered refund tender effects.	Not started	Refund tender-effect rows retain their exact deterministic order after restart.
P05-3.6h.3.3	Integrity-bind the complete refund receipt.	Not started	The receipt checksum binds its scalars and ordered tender effects as one immutable result.
P05-3.6h.4.1	Bind the refund audit payload.	Not started	The audit identity, type, target and payload bind the exact refund aggregate.
P05-3.6h.4.2	Bind the refund outbox payload.	Not started	The outbox identity, type, target and payload bind the exact refund aggregate.
P05-3.6h.5.1	Roll back a fault before refund-core persistence.	Not started	A pre-core fault leaves no refund or financial evidence.
P05-3.6h.5.2	Roll back a fault between refund core and effect.	Not started	A mid-core fault leaves neither a partial refund nor a partial tender effect.
P05-3.6h.5.3	Roll back a fault before receipt persistence.	Not started	A pre-receipt fault leaves no committed financial effect without its receipt.
P05-3.6h.5.4.1	Roll back a fault before refund-audit persistence	Not started	No committed refund can lack its required audit record.
P05-3.6h.5.4.2	Roll back a fault before refund-outbox persistence	Not started	No committed refund can lack its required outbox record.
P05-3.6h.5.5	Roll back a fault immediately before commit.	Not started	A final transaction fault leaves every refund table unchanged.
P05-3.6i.1	Return stored result on exact replay.	Not started	An identical command returns its durable result without reissuing money.
P05-3.6i.2	Reject changed-payload replay.	Not started	Reusing an idempotency key with changed input fails and is audited.
P05-3.6i.3	Reauthorize safe replay.	Not started	Replay rechecks current authorization while never repeating the financial effect.
P05-3.6j.1	Enforce same-command one winner.	Not started	Concurrent copies of one command yield one financial winner.
P05-3.6j.2	Enforce competing-credit ceiling.	Not started	Competing commands cannot exceed the remaining return credit or tender value.
P05-3.6j.3.1	Converge command and callback concurrency.	Not started	A refund command racing its callback produces one stored outcome.
P05-3.6j.3.2	Converge command and inquiry concurrency.	Not started	A refund command racing inquiry produces one stored outcome.
P05-3.6j.3.3	Converge callback and inquiry concurrency.	Not started	Callback and inquiry racing each other produce one stored outcome.
P05-3.6k.1	Preserve processor batch source.	Not started	Authorized upload retains original bytes, checksum, source and batch metadata.
P05-3.6k.2	Quarantine malformed batch lines.	Not started	Unsupported or invalid lines are explicit and never silently posted.
P05-3.6k.3.1	Reject a duplicate processor file.	Not started	A stable file identity prevents the same batch from posting twice.
P05-3.6k.3.2	Reject an overlapping processor line.	Not started	A stable line identity prevents an effect shared by two batches from posting twice.
P05-3.6k.4	Reproduce source control totals.	Not started	Parsed line counts and amounts reproduce the immutable source totals.
P05-3.6k.5	Accept real processor batch fixture.	Owner validation required	A real redacted provider batch is imported and reconciled as documented.
P05-3.6l.1.1	Match processor provider reference	Not started	The provider reference matches its exact POS counterpart.
P05-3.6l.1.2	Match processor merchant reference	Not started	The merchant reference matches its exact POS counterpart.
P05-3.6l.1.3	Match processor terminal reference	Not started	The terminal reference matches its exact POS counterpart.
P05-3.6l.1.4	Match processor payment-attempt reference	Not started	The payment-attempt reference matches its exact POS counterpart.
P05-3.6l.1.5	Match processor effect reference	Not started	The provider-effect reference matches its exact POS counterpart.
P05-3.6l.2.1	Classify a missing processor difference.	Not started	A POS effect without its expected processor entry remains a named missing exception.
P05-3.6l.2.2	Classify a duplicate processor difference.	Not started	A repeated processor effect remains a named duplicate exception.
P05-3.6l.2.3	Classify an amount difference.	Not started	Unequal POS and processor amounts remain a named amount exception.
P05-3.6l.2.4	Classify a status difference.	Not started	Conflicting POS and processor final states remain a named status exception.
P05-3.6l.2.5	Classify a business-date difference.	Not started	An effect assigned to different business dates remains a named date exception.
P05-3.6l.2.6	Classify a processor-route difference.	Not started	Conflicting merchant or terminal attribution remains a named route exception.
P05-3.6l.3.1	Compare sale totals with the processor batch.	Not started	Settled card-sale totals reproduce on both POS and processor sides.
P05-3.6l.3.2	Compare refund totals with the processor batch.	Not started	Final card-refund totals reproduce on both POS and processor sides.
P05-3.6l.3.3	Compare reversal totals with the processor batch.	Not started	Final reversal totals reproduce on both POS and processor sides.
P05-3.6l.4.1	Correct reconciliation without rewriting source.	Not started	A correction appends new evidence and never changes the imported processor source.
P05-3.6l.4.2	Rerun reconciliation idempotently.	Not started	Rerunning unchanged inputs produces the same matches and exceptions once.
P05-3.6l.4.3	Preserve prior reconciliation evidence.	Not started	Each rerun retains the prior result and lineage needed to explain the change.
P05-3.6m.1	Persist exception facts.	Not started	Every exception retains amount, age, reason and source links.
P05-3.6m.2	Assign exception workflow.	Not started	Each exception has owner, due date, status and next action.
P05-3.6m.3	Control exception resolution.	Not started	Authorized resolve and reopen actions preserve immutable history.
P05-3.6n.1	Map truthful cashier states.	Not started	Durable refund states map to accurate wording and safe next actions.
P05-3.6n.2	Render final refund receipt.	Not started	Receipt links original receipt, returned value and exact tender effects.
P05-3.6n.3.1	Protect refund-screen privacy	Not started	Refund screens expose only the minimum necessary payment data.
P05-3.6n.3.2	Protect refund-receipt privacy	Not started	Refund receipts expose only the minimum necessary payment data.
P05-3.6n.3.3	Protect refund-log privacy	Not started	Refund logs expose only the minimum necessary payment data.
P05-3.6n.4.1	Validate cashier refund accessibility.	Owner validation required	Representative cashiers complete the supported refund flow with the required assistive features.
P05-3.6n.4.2	Validate cashier refund-recovery usability.	Owner validation required	Representative cashiers recover an uncertain refund safely without developer help.
P05-3.6n.4.3	Validate cashier refund-receipt usability.	Owner validation required	Representative cashiers find, explain and provide the correct final refund receipt.
P05-3.6o.1	Resume pending inquiry after restart.	Not started	Restart continues recovery without automatically resending money.
P05-3.6o.2	Preserve completed replay after restart.	Not started	Completed results remain exactly replayable after process restart.
P05-3.6o.3.1	Reject tampered refund-core evidence.	Not started	A missing or altered refund aggregate fails closed after restart.
P05-3.6o.3.2	Reject tampered refund-effect evidence.	Not started	A missing or altered tender or provider effect fails closed after restart.
P05-3.6o.3.3	Reject tampered refund-receipt evidence.	Not started	A missing or altered final refund receipt fails closed after restart.
P05-3.6o.3.4	Reject tampered refund-audit evidence.	Not started	A missing or altered required refund audit fails closed after restart.
P05-3.6o.3.5	Reject tampered refund-outbox evidence.	Not started	A missing or altered required refund outbox record fails closed after restart.
P05-3.6o.4.1.1	Preserve refund totals through backup and restore	Not started	Restored refund totals exactly match the backup checkpoint.
P05-3.6o.4.1.2	Preserve reconciliation totals through backup and restore	Not started	Restored reconciliation totals exactly match the backup checkpoint.
P05-3.6o.4.2.1	Preserve refund totals through migration	Not started	Every supported migration reproduces exact refund totals.
P05-3.6o.4.2.2	Preserve reconciliation totals through migration	Not started	Every supported migration reproduces exact reconciliation totals.
P05-3.6p.1.1	Define authorized-to-captured transition	Not started	The allowed AUTHORIZED-to-CAPTURED transition is explicit and testable.
P05-3.6p.1.2	Define provider capture finality	Not started	Final and uncertain provider capture evidence is explicitly distinguished.
P05-3.6p.2.1	Verify signed capture request	Not started	The signed capture request binds the original authorization.
P05-3.6p.2.2	Verify signed capture response	Not started	The signed response binds the request and payment and verifies successfully.
P05-3.6p.3	Recover unknown capture by inquiry.	Not started	Unknown capture uses authenticated inquiry before any retry.
P05-3.6p.4.1	Bind captured evidence to final settlement.	Not started	Exact final settlement requires the atomic CAPTURED provider evidence.
P05-3.6p.4.2	Bind captured evidence to reconciliation.	Not started	Processor reconciliation traces every captured amount to its atomic provider evidence.
P05-3.6p.5.1	Certify real acquirer capture finality.	Owner validation required	The real acquirer confirms when a capture is final and how inquiry reports it.
P05-3.6p.5.2	Certify real acquirer reversal finality.	Owner validation required	The real acquirer confirms when a reversal moves or releases value.
P05-3.6p.5.3	Certify real acquirer refund finality.	Owner validation required	The real acquirer confirms when a refund is final and safe to report.
P05-3.6p.5.4	Certify real acquirer settlement finality.	Owner validation required	The real acquirer confirms how final effects appear in settlement evidence.
P05-3.6q.1.1	Publish the refund command API contract.	Not started	Versioned OpenAPI defines refund command requests, responses and stable failures.
P05-3.6q.1.2	Publish the reversal command API contract.	Not started	Versioned OpenAPI defines reversal command requests, responses and stable failures.
P05-3.6q.1.3	Publish the refund-inquiry API contract.	Not started	Versioned OpenAPI defines inquiry requests, responses and stable failures.
P05-3.6q.1.4	Publish the processor-batch import API contract.	Not started	Versioned OpenAPI defines batch-import requests, responses and stable failures.
P05-3.6q.2.1	Enforce authenticated refund API permissions.	Not started	Every Store API refund operation rechecks its required current permission.
P05-3.6q.2.2	Return truthful refund API problem details.	Not started	Stable problem details fail closed and provide safe recovery without sensitive data.
P05-3.6q.3.1	Prove refund HTTP restart recovery.	Not started	Restart during an HTTP refund preserves one durable financial outcome.
P05-3.6q.3.2	Prove refund HTTP lost-response recovery.	Not started	A lost HTTP response can be recovered without sending money twice.
P05-3.6q.3.3	Prove exact refund HTTP replay.	Not started	An identical HTTP retry returns the stored result without a second effect.
P05-3.6q.3.4	Prove concurrent refund HTTP commands.	Not started	Concurrent HTTP commands obey the command and remaining-credit winner rules.
P05-3.6q.4	Keep clients safe offline.	Not started	Clients may read status offline but never execute an external refund offline.
P05-3.6r.1.1	Pass the clean payment-module regression.	Not started	The complete affected payment suite passes from a clean build.
P05-3.6r.1.2	Pass the clean sales-module regression.	Not started	The complete affected sales suite passes from a clean build.
P05-3.6r.1.3	Pass the clean Store Server regression.	Not started	The complete affected Store Server suite passes from a clean build.
P05-3.6r.2.1	Pass the refund migration gate.	Not started	Every supported refund schema path preserves exact evidence and totals.
P05-3.6r.2.2	Pass the refund restart gate.	Not started	Every durable refund state resumes safely after process restart.
P05-3.6r.2.3	Pass the refund fault-injection gate.	Not started	Every money-moving boundary fails atomically under the clean fault suite.
P05-3.6r.2.4	Pass the refund tamper gate.	Not started	Every required refund evidence class fails closed when missing or altered.
P05-3.6r.3.1	Pass independent business acceptance review.	Not started	The business reviewer reports no open P0/P1 issue.
P05-3.6r.3.2	Pass independent technical acceptance review.	Not started	The technical reviewer reports no open P0/P1 issue.
P05-3.6r.3.3	Pass independent adversarial acceptance review.	Not started	The adversarial reviewer reports no open P0/P1 issue.
P05-3.6r.4.1	Publish machine-readable refund evidence.	Not started	The evidence record identifies the exact build, tests, results and hashes.
P05-3.6r.4.2	Publish the readable refund evidence report.	Not started	An owner-readable HTML report explains the accepted result and remaining gates.
P05-3.6r.4.3	Link refund traceability evidence.	Not started	Every closed refund requirement resolves to its exact acceptance evidence.
P05-3.6r.4.4	Promote each accepted refund checkbox.	Not started	The SRS status changes only for tasks proven by the published accepted evidence.
P05-4.1	Till issuance, opening float and production cash-control projection.	Not started	Only the assigned cashier can accept/open the till; the durable production projection implements the transaction-aware control port proven by P05-3.1.
P05-4.2	Pickup, drop and no-sale audit.	Not started	Every movement shows amount, person, time, reason and approval.
P05-4.3	Blind count, recount, variance and close.	Not started	Physical cash reconciles or remains an owned over/short exception.
P05-4.4	Safe book, numbered deposit bags and chain of custody.	Not started	Every bag and handoff is traceable end to end.
P05-4.5	Terminal batches, deposits in transit and late/mismatched credits.	Not started	Nothing is silently balanced; late/mismatched deposits remain visible.
P05-5.1	Inventory movement ledger and exact stock derivation.	Not started	Stock changes only through a visible, reproducible movement.
P05-5.2	Case/unit/catch-weight, lot/expiry and idempotent receiving.	Not started	Duplicate receiving cannot double stock.
P05-5.3	Counts, adjustments and concurrent sale/count handling.	Not started	Expected and counted stock reconcile with explicit adjustment evidence.
P05-5.4	Vendors, order suggestions and PO approval/send simulator.	Not started	An owner can see why an item was suggested and who approved the order.
P05-5.5	Short/over delivery, claims, credits and purchase reconciliation.	Not started	A claim remains open until the matching credit is received.
P05-6.1	Owner MFA, organization/store setup and helper invitation.	Not started	Helpers can install without receiving ownership or billing authority.
P05-6.2	Installation claim, replacement and device seats.	Not started	Replacement is controlled and excess pairing is blocked without stopping checkout.
P05-6.3	Privacy-minimized qualifying-weekly-sales calculation.	Not started	Owner reproduces the CAD $2,500 result and sees excluded tax/deposit/value issuance.
P05-6.4	Four-week Starter decision and transition notices.	Not started	Free/paid eligibility is stable, explainable and not based on one unusual week.
P05-6.5	Signed refresh, Cloud outage, owner portal and signed downloads.	Not started	Existing lanes continue offline and every submitted aggregate is owner-visible.
P05-7.1	Nontechnical first boot and hardware profiles.	Not started	An owner or friend reaches Ready by following the guide.
P05-7.2	Repeatable import, control totals, coexistence authority and rollback.	Not started	Repeating import creates no duplicates and the authoritative system is always named.
P05-7.3	Signed update, rollback/forward-fix and support bundle.	Not started	An unsafe update is refused and support receives a consented, redacted bundle.
P05-7.4	Backup/replacement restore and recovery runbook.	Not started	A replacement box restores the same store without duplicate effects.
P05-7.5	Cached recall stop-sale and offline emergency cards.	Not started	An offline lane blocks recalled goods; staff find power/network/refrigeration steps offline.
P05-7.6	Quick guides, competency checks and simulator hardware matrix.	Not started	Each pilot role demonstrates its critical tasks before authority is granted.
P05-8.1	Entry audit, staff sandbox and non-authoritative shadow comparison.	Not started	The legacy authority remains explicit and comparison variances are owned.
P05-8.2	Training/employee lane.	Not started	Opening-to-close and failure drills pass without customer authority.
P05-8.3	Named customer lanes/tenders and cutover matrix.	Not started	Only approved lanes, tenders, users and times become authoritative.
P05-8.4	Daily reconciliation, hypercare and rollback/exit report.	External validation pending	Requires a real approved pilot, daily owner sign-off and no unexplained variance.

Technical task-ID appendix — V0.8 canonical source rows (461 tasks, closed by default)

The owner-readable register above is the primary progress view. Open this appendix only when exact technical task IDs are needed.

Child	Bounded outcome	Status	Plain-language acceptance
P08-1.1.a	Check schedule	Not started	Each required temperature or sanitation check appears for the correct location and time.
P08-1.1.b	Temperature entry	Not started	Staff can record the reading, unit, equipment, person and time in one simple action.
P08-1.1.c	Range validation	Not started	An out-of-range reading is immediately marked failed against the effective safety limit.
P08-1.1.d	Missed-check alert	Not started	An overdue check remains visible until a named person addresses it.
P08-1.1.e	Corrective action	Not started	A failed check cannot close without action, disposition and responsible-person evidence.
P08-1.1.f	Certificate expiry	Not started	Expired or missing safety certificates create a visible manager exception.
P08-1.1.g	Pest-control evidence	Not started	Each pest-control inspection or treatment preserves provider, location, finding, action and source evidence.
P08-1.1.h	Safety inspection evidence	Not started	Every inspection records the checklist version, inspector, result, exceptions and corrective-action links.
P08-1.1.i	Safety evidence authorization	Not started	Only authorized roles can read safety inspection, pest-control, certificate and corrective-action evidence.
P08-1.1.j	Safety evidence retention	Not started	Expiry never removes safety evidence protected by the active retention, legal-hold or corrective-action rule.
P08-1.2.a	Recall notice intake	Not started	A recall notice preserves the source, affected identifiers, dates and instructions.
P08-1.2.b	Affected-stock search	Not started	The system identifies affected on-hand lots and locations from the recall criteria.
P08-1.2.c	Offline stop-sale	Not started	A disconnected register blocks a recalled item using its cached recall rules.
P08-1.2.d	Quarantine movement	Not started	Quarantined quantity moves to a restricted location without disappearing from inventory.
P08-1.2.e	Customer-sale trace	Not started	Authorized staff can identify affected receipt population by item, lot and date.
P08-1.2.f	Recall disposition	Not started	Returned, destroyed or released stock retains quantity, reason, approval and evidence.
P08-1.2.g	Recall closure	Not started	A recall closes only when affected stock, sales, actions and remaining exceptions reconcile.
P08-1.3.a	Recipe definition	Not started	A fresh-item recipe lists each input, output unit and expected yield.
P08-1.3.b	Effective recipe version	Not started	Every production batch retains the exact recipe version used.
P08-1.3.c	Batch input consumption	Not started	Starting a batch records the exact inventory quantities consumed.
P08-1.3.d	Batch output	Not started	Finished output quantity is recorded without silently changing the recipe or consumed inputs.
P08-1.3.e	Markdown disposition	Not started	Every markdown preserves the batch, quantity, old price, new price, reason, actor and effective time.
P08-1.3.f	Production waste	Not started	Waste records quantity, reason, person and batch without changing prior history.
P08-1.3.g	Donation disposition	Not started	Every donation records batch, quantity, recipient or program, reason, actor and inventory movement.
P08-1.3.h	Tare capture	Not started	A production batch records the approved tare separately from gross and net quantity.
P08-1.3.i	Batch-cost reconciliation	Not started	Consumed ingredient cost reconciles exactly to finished output, loss, donation and waste cost.
P08-1.3.j	Actual batch yield	Not started	Actual yield reproduces from consumed net input and finished output using the approved units.
P08-1.4.a	Label template version	Not started	Every printed label retains the effective template version.
P08-1.4.b	Ingredient declaration	Not started	The label ingredient list reproduces the approved recipe declaration.
P08-1.4.c	Allergen warning	Not started	Required allergens appear prominently and missing allergen data blocks printing.
P08-1.4.d	Pack date	Not started	The label pack date reproduces from the batch production time and store timezone.
P08-1.4.e	Label printer simulator	Not started	The simulator receives the exact approved label and reports print or recoverable failure.
P08-1.4.f	Expired-label protection	Not started	An expired or superseded label cannot be reused without an audited correction.
P08-1.4.g	Best-before date	Not started	The label best-before date reproduces from the approved shelf-life rule version.
P08-1.4.h	Expiry date	Not started	The label expiry date reproduces from the approved safety rule version.
P08-2.1.a	Restricted employee profile	Not started	Only authorized roles can view private employee information.
P08-2.1.b	Employment role assignment	Not started	Each employee receives effective-dated roles without changing earlier history.
P08-2.1.c	Availability entry	Not started	Employees can submit availability without directly changing a published schedule.
P08-2.1.d	Schedule drafting	Not started	A manager can build shifts against employee availability and role eligibility.
P08-2.1.e	Schedule conflict warning	Not started	Overlap, unavailable time and missing-role conflicts are shown before publishing.
P08-2.1.f	Schedule publishing	Not started	Employees see only the latest published shifts and receive a visible change notice.
P08-2.2.a	Shift assignment check	Not started	A punch clearly identifies whether the employee has an expected shift.
P08-2.2.b	Clock-in	Not started	A valid clock-in creates one ordered punch with employee, device and store identity.
P08-2.2.c	Offline punch storage	Not started	A punch made offline remains available after app or network interruption.
P08-2.2.d	Punch synchronization	Not started	Reconnecting sends each offline punch exactly once.
P08-2.2.e	Break recording	Not started	Paid and unpaid breaks remain separately visible in worked-time calculations.
P08-2.2.f	Punch exception warning	Not started	Early, late, missed and overlapping punches create understandable exceptions.
P08-2.2.g	Clock-out	Not started	A valid clock-out creates one ordered punch and closes only the intended open work interval.
P08-2.3.a	Missed-punch request	Not started	An employee can request a correction without changing the original time record.
P08-2.3.b	Correction evidence	Not started	Every correction includes the requested time, reason and supporting note.
P08-2.3.c	Separate approval	Not started	An employee cannot approve their own time correction.
P08-2.3.d	Hours recalculation	Not started	An approved correction recalculates regular, break and overtime totals exactly.
P08-2.3.e	Pay-period freeze	Not started	Approved time becomes read-only when the pay period is frozen.
P08-2.3.f	Controlled reopening	Not started	Reopening frozen time requires authority, reason and visible before-and-after totals.
P08-2.4.a	Payroll-period selection	Not started	The export includes only employees and approved time from the selected frozen period.
P08-2.4.b	Earnings-code mapping	Not started	Each exported hour maps to an approved payroll earnings code.
P08-2.4.c	Payroll control totals	Not started	Employee and period totals equal the frozen totals shown before export.
P08-2.4.d	Payroll file generation	Not started	The generated file follows the selected provider version and can be reproduced.
P08-2.4.e	Provider response intake	Not started	Accepted and rejected payroll records retain the provider response.
P08-2.4.f	Payroll rejection queue	Not started	A rejected employee record remains visible without losing the accepted records.
P08-2.5.a	Leave request	Not started	An employee can request dated leave without changing the published schedule or approved time.
P08-2.5.b	Open-shift publishing	Not started	A manager can publish an eligible unfilled shift once with role, location and response deadline.
P08-2.5.c	Shift-swap request	Not started	A proposed swap records both employees and cannot change the schedule before manager approval.
P08-2.5.d	Call-out recording	Not started	A call-out records shift, employee, time, reason category and resulting coverage exception.
P08-2.5.e	Schedule-change notification	Not started	Each affected employee receives one visible notice for an approved leave, swap, call-out or shift change.
P08-2.6.a	Effective time-rule version	Not started	Every hours calculation retains the jurisdiction, store and effective rule version used.
P08-2.6.b	Regular-hours golden cases	Not started	Published regular-hours examples reproduce exactly at shift and pay-period boundaries.
P08-2.6.c	Overtime golden cases	Not started	Daily and weekly overtime examples reproduce exactly without double counting.
P08-2.6.d	Holiday-hours golden cases	Not started	Configured holiday examples reproduce the correct eligible hours and rule version.
P08-2.6.e	Break-rule golden cases	Not started	Paid, unpaid, missed and corrected break examples reproduce the approved totals.
P08-2.6.f	Correction-rule golden cases	Not started	Approved punch corrections recalculate each affected hours category once and preserve the former result.
P08-2.7.a	Employee onboarding checklist	Not started	A new employee cannot reach Ready until each required identity, role and onboarding step is complete.
P08-2.7.b	Policy acknowledgement	Not started	Each acknowledgement retains employee, policy version, response and time.
P08-2.7.c	Employee certificate control	Not started	Required certificates retain issuer, effective dates and evidence and create an exception before expiry.
P08-2.7.d	Employee offboarding record	Not started	Offboarding records effective time, responsible manager, outstanding tasks and retained audit evidence.
P08-2.7.e	Immediate access expiry	Not started	A terminated employee loses active sessions and future access within the configured policy target.
P08-3.1.a	Minimal customer identity	Not started	A customer profile can be created with only the information needed for the selected service.
P08-3.1.b	Duplicate-customer review	Not started	Possible duplicates are suggested for review and are never merged automatically.
P08-3.1.c	Consent grant	Not started	Consent records purpose, channel, wording version, person and time.
P08-3.1.d	Consent withdrawal	Not started	Opting out takes effect immediately without deleting prior consent history.
P08-3.1.e	Communication preferences	Not started	Contact occurs only through currently permitted channels.
P08-3.1.f	Customer service case	Not started	A service case retains owner, status, notes and linked source transactions.
P08-3.2.a	Points ledger foundation	Not started	The displayed points balance equals the immutable points movements.
P08-3.2.b	Points earning	Not started	An eligible sale earns points once using the effective rule.
P08-3.2.c	Points redemption	Not started	Redemption cannot exceed the available balance and is linked to the sale.
P08-3.2.d	Redemption reversal	Not started	Reversing a sale restores only the points consumed by that sale.
P08-3.2.e	Points expiry	Not started	Expiry uses the applicable rule and retains the expired movement.
P08-3.2.f	Points adjustment approval	Not started	Manual points changes require authority, reason and before-and-after balances.
P08-3.2.g	Points statement	Not started	Authorized staff can explain the balance from dated earn, redeem, reverse and expiry entries.
P08-3.3.a	Gift-card issuance	Not started	Issuing a gift card creates an identifiable zero-value card without activating value.
P08-3.3.b	Gift-card activation	Not started	Activation adds value exactly once after the related tender succeeds.
P08-3.3.c	Gift-card redemption	Not started	Redemption reduces value once and cannot exceed the available balance.
P08-3.3.d	Gift-card refund	Not started	An authorized refund restores the exact approved value once.
P08-3.3.e	Store-credit issuance	Not started	Store credit is linked to its approved return or adjustment source.
P08-3.3.f	Lost-card hold	Not started	A held card cannot be redeemed while ownership is reviewed.
P08-3.3.g	Card replacement	Not started	Replacement transfers the remaining balance once and permanently disables the old card.
P08-3.3.h	Stored-value balance inquiry	Not started	An inquiry displays the authoritative balance without changing it.
P08-3.4.a	Fraud hold placement	Not started	An authorized hold records reason, evidence, person and expiry.
P08-3.4.b	Fraud hold release	Not started	Releasing a hold requires authority and preserves the complete hold history.
P08-3.4.c	Customer access request	Not started	A privacy request receives an identity-verified case and due date.
P08-3.4.d	Customer data export	Not started	The export contains the authorized customer's data and records what was disclosed.
P08-3.4.e	Customer correction request	Not started	Approved corrections preserve the previous value and correction reason.
P08-3.4.f	Customer-data retention	Not started	Customer data reaches removal or permitted anonymization only under its effective retention rule.
P08-3.4.g	Stored-value liability total	Not started	Gift-card and store-credit ledger balances add exactly to the reported liability.
P08-3.4.h	Customer-data legal hold	Not started	Data under an active legal hold cannot be deleted or anonymized by normal retention work.
P08-3.5.a	Offline stored-value reservation	Not started	An offline redemption reserves a bounded amount locally before the sale can complete.
P08-3.5.b	Offline redemption ceiling	Not started	A disconnected register rejects a redemption above its signed local limit.
P08-3.5.c	Concurrent redemption reconciliation	Not started	Concurrent offline reservations reconcile after reconnect without creating unbounded negative liability.
P08-3.6.a	Customer-case category	Not started	A complaint, quality, injury, property, return, loyalty, gift-card or privacy case retains one explicit category.
P08-3.6.b	Customer-case service level	Not started	Each case receives an accountable owner and due time from its category and severity.
P08-3.6.c	Customer-case approval	Not started	A restricted remedy cannot be issued without the required independent approval.
P08-3.6.d	Customer-case resolution	Not started	Closing a case records resolution, evidence, actor and time without removing earlier notes.
P08-3.6.e	Customer follow-up	Not started	A promised follow-up remains visible until its outcome and completion time are recorded.
P08-4.1.a	Invoice source preservation	Not started	Every vendor invoice retains its original file, source identity and checksum.
P08-4.1.b	Duplicate-invoice protection	Not started	Reimporting the same vendor invoice cannot create a second payable.
P08-4.1.c	Purchase-order line match	Not started	Invoice quantities and prices are compared with the approved purchase order lines.
P08-4.1.d	Receiving line match	Not started	Invoiced quantities are compared with the quantities actually received.
P08-4.1.e	Vendor-credit match	Not started	A vendor credit is linked to the invoice, claim or return it resolves.
P08-4.1.f	Match variance calculation	Not started	Quantity, price, tax and total differences are shown separately.
P08-4.1.g	Variance approval	Not started	An outside-tolerance difference cannot close without named approval and reason.
P08-4.2.a	Terminal batch intake	Not started	Each processor batch retains terminal, processor, date, reference and source totals.
P08-4.2.b	POS tender total	Not started	The system calculates the exact POS tender total for the batch window.
P08-4.2.c	Processor fee separation	Not started	Fees remain separate from gross sales and deposited cash.
P08-4.2.d	Bank deposit linkage	Not started	A processor settlement can be linked to its matching bank deposit.
P08-4.2.e	Late deposit tracking	Not started	An expected deposit remains visible until it reaches the bank.
P08-4.2.f	Batch difference exception	Not started	A POS, processor or bank difference remains named and assigned until resolved.
P08-4.3.a	CSV statement parser	Not started	A supported CSV statement imports every valid source line with its original row number.
P08-4.3.b	OFX statement parser	Not started	A supported OFX statement preserves account, transaction and statement identities.
P08-4.3.c	QFX statement parser	Not started	A supported QFX statement produces the same canonical transaction fields as OFX.
P08-4.3.d	Statement source evidence	Not started	The original statement file and checksum remain available after import.
P08-4.3.e	Transaction normalization	Not started	Dates, signs, amounts, descriptions and references normalize without losing source values.
P08-4.3.f	Statement duplicate protection	Not started	Importing the same statement or source transaction twice creates no duplicate bank entry.
P08-4.3.g	Import rejection report	Not started	Invalid lines are reported explicitly and are never silently skipped.
P08-4.4.a	PDF statement upload	Not started	An uploaded PDF is stored as immutable source evidence before extraction.
P08-4.4.b	Source-page preservation	Not started	Every extracted transaction links to the exact PDF page image.
P08-4.4.c	Deterministic extraction	Not started	Local parsing or OCR proposes transaction fields without connected AI.
P08-4.4.d	Confidence warning	Not started	Uncertain dates, descriptions or amounts are clearly highlighted.
P08-4.4.e	Human correction	Not started	A reviewer can correct proposed fields while retaining the original extracted value.
P08-4.4.f	Mandatory confirmation	Not started	No PDF-extracted transaction becomes a bank entry until an authorized person confirms it.
P08-4.5.a	Exact-reference matching	Not started	Exact amount, date and reference matches are identified reproducibly.
P08-4.5.b	Suggested matching	Not started	A suggested match explains the evidence and never posts automatically.
P08-4.5.c	Match confirmation	Not started	Only an authorized confirmation links bank and store records.
P08-4.5.d	Unmatched-item queue	Not started	Every unmatched bank line remains visible with age and amount.
P08-4.5.e	Exception assignment	Not started	An unresolved item has a named owner and next review date.
P08-4.5.f	Deposit-in-transit tracking	Not started	A store deposit remains outstanding until the corresponding bank credit arrives.
P08-4.5.g	Match reversal	Not started	An incorrect match can be reversed without deleting either original record.
P08-4.6.a	Close checklist	Not started	The month-end checklist shows each required reconciliation and responsible person.
P08-4.6.b	Pre-close validation	Not started	Missing statements, open exceptions and unbalanced controls block final close.
P08-4.6.c	Period lock	Not started	Closing a period prevents ordinary edits to its controlled records.
P08-4.6.d	Late-entry rejection	Not started	A normal transaction cannot silently post into a locked period.
P08-4.6.e	Prior-period correction	Not started	A correction posts as a visible adjustment with source and reason.
P08-4.6.f	Controlled reopen	Not started	Reopening a period requires authority and records who reopened it and why.
P08-4.7.a	Sales HST calculation	Not started	Collected HST totals reproduce from the exact taxable sales evidence.
P08-4.7.b	Purchase ITC calculation	Not started	Eligible input tax credits reproduce from confirmed purchase evidence.
P08-4.7.c	HST adjustment ledger	Not started	Tax corrections and prior-period adjustments remain separate and traceable.
P08-4.7.d	HST working summary	Not started	The report clearly shows collected tax, credits, adjustments and resulting balance.
P08-4.7.e	Source drill-down	Not started	Every HST total opens to its contributing sales, invoices and adjustments.
P08-4.7.f	HST variance warning	Not started	A difference from reconciled source controls remains visible before filing.
P08-4.8.a	Accounting mapping	Not started	Each exported category maps to an approved accounting account and tax code.
P08-4.8.b	Accounting export batch	Not started	One versioned export contains only the selected closed period.
P08-4.8.c	Export control totals	Not started	Export debit, credit, tax and source totals equal the approved close totals.
P08-4.8.d	Accounting response intake	Not started	Acceptance and rejection responses remain linked to the export batch.
P08-4.8.e	Safe export retry	Not started	Retrying an unchanged export cannot create a second accounting posting.
P08-4.8.f	Accountant test-close acceptance	Owner validation required	A qualified accountant confirms the test-period workpapers, HST treatment and accounting totals.
P08-4.9.a	Effective costing-policy version	Not started	Every inventory valuation retains the approved costing policy and effective version used.
P08-4.9.b	Inventory-movement costing	Not started	Each inventory movement receives one reproducible cost from its source and effective policy.
P08-4.9.c	Negative-stock exception	Not started	A negative on-hand balance remains visible with item, location, quantity, cause and accountable owner.
P08-4.9.d	Month-end inventory valuation	Not started	The selected closed period produces one reproducible inventory quantity and value by approved category.
P08-4.9.e	Inventory-valuation reconciliation	Not started	Opening value plus costed movements equals closing value or a named exception remains open.
P08-4.10.a	Purchase backorder	Not started	An unfilled purchase-order quantity remains open with vendor, expected date and current disposition.
P08-4.10.b	Vendor substitution	Not started	A substituted item cannot be accepted without the configured approval and source-order link.
P08-4.10.c	Missed-delivery exception	Not started	A missed promised delivery remains assigned with vendor response and next action.
P08-4.10.d	Delivery-shortage claim	Not started	A shortage claim preserves ordered, received and claimed quantity and remains open until disposition.
P08-4.10.e	Delivery-damage claim	Not started	A damage claim preserves affected quantity, evidence and stock disposition.
P08-4.10.f	Invoice dispute	Not started	A disputed invoice amount cannot be silently approved and retains reason, owner and vendor response.
P08-4.10.g	Debit memo	Not started	A debit memo is issued once from an approved claim and retains its source and amount.
P08-4.10.h	Vendor-credit ageing	Not started	Expected vendor credits remain visible by amount and age until matched or dispositioned.
P08-4.10.i	Purchase-claim resolution	Not started	A claim closes only after credited, replaced or explicitly disposition-approved evidence is linked.
P08-5.1.a	Loss-case record.	Not started	A new case keeps its type, store, reporter, severity, time and immutable case number after restart.
P08-5.1.b	Restricted case access.	Not started	Staff without loss-prevention permission cannot list, search, open or export sensitive cases.
P08-5.1.c.1	Intake sale exceptions.	Not started	Each approved sale exception enters the queue once with its source sale and named owner.
P08-5.1.c.2	Intake cash exceptions.	Not started	Each approved cash exception enters the queue once with its till or safe source and named owner.
P08-5.1.c.3	Intake stock exceptions.	Not started	Each approved stock exception enters the queue once with its inventory source and named owner.
P08-5.1.c.4	Intake staff exceptions.	Not started	Each approved staff exception enters the queue once with its workforce source and named owner.
P08-5.1.d.1	Preserve case-note evidence.	Not started	Every note preserves author, time and correction history without silent replacement.
P08-5.1.d.2	Preserve case-attachment evidence.	Not started	Every attachment preserves author, time, content hash and correction history.
P08-5.1.d.3	Preserve case source-record evidence.	Not started	Every linked source record remains attributable and cannot be silently replaced.
P08-5.1.d.4	Detect changed case evidence.	Not started	Missing, altered or substituted notes, attachments and source links fail integrity verification.
P08-5.1.e.1	Triage a case.	Not started	An authorized user records category, severity and the first required action.
P08-5.1.e.2	Assign a case.	Not started	An authorized transition names one current case owner and due point.
P08-5.1.e.3	Escalate a case.	Not started	An allowed escalation records reason, recipient and next response time.
P08-5.1.e.4	Close a case.	Not started	Closure requires an allowed transition, disposition, resolution evidence and closing actor.
P08-5.1.e.5	Complete the full case lifecycle.	Not started	One case proceeds from intake through triage, assignment, escalation and closure with no skipped or rewritten state.
P08-5.1.f	Loss review drill.	Owner validation required	The accountable manager confirms a realistic case can be investigated without exposing it to ordinary staff.
P08-5.2.a	Asset register.	Not started	Every maintained asset has a stable ID, location, owner, safety class, warranty and service history.
P08-5.2.b	Preventive schedule.	Not started	Due dates are generated from the active schedule once and overdue work appears in the responsible manager’s queue.
P08-5.2.c	Service incident.	Not started	A fault records impact, downtime, evidence, work performed, cost and return-to-service decision.
P08-5.2.d	Unsafe asset control.	Not started	An unsafe asset is visibly blocked from normal use until an authorized release is recorded.
P08-5.2.e	Maintenance escalation.	Not started	Missed safety-critical work escalates to a named manager and cannot be cleared by deleting the task.
P08-5.2.f	Maintenance workflow review.	Owner validation required	The manager confirms alerts, language and escalation timing are practical for store staff.
P08-5.3.a	Device-outage mode.	Not started	A failed lane device produces a plain-language degraded option without changing completed sales or hiding the outage.
P08-5.3.b	Network-loss continuity.	Not started	Supported local work remains available during network loss and exposes queued or stale state plainly.
P08-5.3.c	Emergency price policy.	Not started	Emergency price use requires an active policy, reason, actor and expiry and remains visible in audit.
P08-5.3.d	Emergency payment policy.	Not started	Disallowed or uncertain payment states stay blocked and cannot become a paid sale through an emergency override.
P08-5.3.e	One-person cash controls.	Not started	When separation is impossible, the approved fallback adds reason, limits and mandatory later review instead of removing controls.
P08-5.3.f	Emergency-policy sign-off.	Owner validation required	The owner approves the exact actions staff may take during price, payment, device and staffing emergencies.
P08-5.3.g	Power-interruption recovery.	Not started	Restart after power interruption preserves every committed effect and exposes every incomplete command as not completed.
P08-5.3.h	Emergency-command atomicity.	Not started	An interrupted emergency command commits exactly once or rolls back fully.
P08-5.4.a	Recovery task ledger.	Not started	Every incident creates owned recovery tasks with due time, evidence and completion status that survive restart.
P08-5.4.b.1	Self-contained offline emergency guide	Done & tested	The guide uses no external runtime assets. Open evidence.
P08-5.4.b.2	Static emergency-guide fallback	Done & tested	Core emergency content remains usable without script. Open evidence.
P08-5.4.b.3	Emergency contact readiness	Done & tested	Required contacts are visibly ready or identified as missing. Open evidence.
P08-5.4.b.4	Emergency-guide CSP and network isolation	Done & tested	CSP holds and the guide makes no external request. Open evidence.
P08-5.4.b.5	Emergency-guide mobile and print layout	Done & tested	The narrow-screen and printable layouts pass. Open evidence.
P08-5.4.b.6	Emergency-guide independent acceptance	Done & tested	Technical, accessibility and business reviews report no P0 or P1 issue. Open evidence.
P08-5.4.c	Device-failure rehearsal.	Not started	A simulated lane-device failure finishes with no lost or duplicated ledger effect.
P08-5.4.d	Combined store drill.	Owner validation required	A manager completes the approved continuity drill without bypassing safety, cash or audit rules.
P08-5.4.e	Network-failure rehearsal.	Not started	A simulated network failure and reconnect preserve each accepted effect exactly once.
P08-5.4.f	Power-failure rehearsal.	Not started	A simulated power loss and restart preserve committed ledgers and leave no partial command marked complete.
P08-5.4.g	Process-crash rehearsal.	Not started	A process crash at each durable boundary restarts without a missing or duplicate business effect.
P08-5.5.a	Refund exception alert.	Not started	A refund matching an effective review rule creates one neutral alert linked to the refund evidence.
P08-5.5.b	Void exception alert.	Not started	A void matching an effective review rule creates one neutral alert linked to the void evidence.
P08-5.5.c	Discount exception alert.	Not started	A discount matching an effective review rule creates one neutral alert linked to the discount evidence.
P08-5.5.d	No-sale exception alert.	Not started	A no-sale event matching an effective review rule creates one neutral alert linked to the till evidence.
P08-5.5.e	Cash-difference alert.	Not started	A cash variance matching an effective review rule creates one neutral alert linked to the count evidence.
P08-5.5.f	Waste exception alert.	Not started	A waste movement matching an effective review rule creates one neutral alert linked to the stock evidence.
P08-5.5.g	Adjustment exception alert.	Not started	An inventory or financial adjustment matching an effective review rule creates one neutral source-linked alert.
P08-5.5.h	Alert explanation.	Not started	Every alert shows the rule version, triggering facts and source links without unsupported inference.
P08-5.5.i	Non-accusatory alert language.	Not started	Deterministic wording describes observed evidence and never asserts intent, guilt or misconduct.
P08-5.5.j	Human-only discipline decision.	Not started	No alert or automated path can determine discipline; every outcome requires an authorized human decision.
P08-5.6.a	Offline power-failure playbook.	Done & tested	People, electrical/food stop conditions, approved degraded work, evidence and controlled utility/electrical recovery are available offline. Evidence.
P08-5.6.b	Offline refrigeration-failure playbook.	Done & tested	Temperature checks, stock segregation, stop-sale, refrigeration/public-health contacts and controlled return to service are available offline. Evidence.
P08-5.6.c	Offline fire playbook.	Done & tested	Alarm, 911, evacuation, accountability, evidence and mandatory fire-service re-entry authority are available offline. Evidence.
P08-5.6.d	Offline flood playbook.	Done & tested	Electrical/structural safety, food quarantine, property/public-health contacts, evidence and area-by-area recovery are available offline. Evidence.
P08-5.6.e	Offline robbery playbook.	Done & tested	Life-first response, no-chase rules, police contact, evidence preservation, two-person value control and police release are available offline. Evidence.
P08-5.6.f	Offline injury playbook.	Done & tested	Emergency response, trained first aid, privacy, bodily-fluid/product control, reporting evidence and safe reopening are available offline. Evidence.
P08-5.6.g	Offline contamination playbook.	Done & tested	Immediate stop-sale, quarantine, scope/trace evidence, food-safety escalation and controlled disposition/release are available offline. Evidence.
P08-5.6.h	Offline boil-water playbook.	Done & tested	Affected-process stops, safe-water rules, sanitation evidence and mandatory official rescission plus internal release are available offline. Evidence.
P08-5.6.i	Offline evacuation playbook.	Done & tested	Alarm/order, exits, assembly accountability, no-re-entry rules, evidence and public-authority re-entry gate are available offline. Evidence.
P08-5.6.j	Offline server-failure playbook.	Done & tested	Permitted local work, stale-control stops, no SQLite/queue tampering, Kuberan support and exact recovery reconciliation are available offline. Evidence.
P08-5.6.k	Offline network-failure playbook.	Done & tested	Failure-boundary checks, permitted offline work, stale-authority stops, ISP/Kuberan contacts and replay-safe reconnect checks are available offline. Evidence.
P08-5.6.l	Offline playbook availability.	Done & tested	All eleven embedded playbooks are individually readable and printable without server, cloud, internet or external runtime assets; the complete static fallback remains available if interactive startup fails. Evidence.
P08-5.7.a	Incident declaration.	Not started	An authorized declaration records incident type, severity, time, scope and incident commander.
P08-5.7.b	Incident contacts.	Not started	Required internal and external contacts remain assigned with notification time and outcome.
P08-5.7.c	Incident stop-sale control.	Not started	An authorized incident stop-sale identifies affected items, locations, start time and release authority.
P08-5.7.d	Incident stock protection.	Not started	Protected or quarantined stock remains visible with quantity, location and permitted disposition.
P08-5.7.e	Offline incident record.	Not started	An incident action recorded offline survives restart and synchronizes once after reconnect.
P08-5.7.f	Incident recovery tasks.	Not started	Recovery tasks retain owner, due time, evidence and completion status.
P08-5.7.g	Resume approval.	Not started	Normal operation cannot resume until the authorized role records required checks and approval.
P08-5.7.h	Incident after-action close.	Not started	Closing an incident links declaration, actions, recovery, remaining risks and corrective owners.
P08-5.8.a	Maintenance work-order lifecycle.	Not started	A work order follows assigned, accepted, in-service, blocked and closed transitions without losing history.
P08-5.8.b	Maintenance vendor assignment.	Not started	A vendor assignment records provider, scope, authorization, appointment and source work order.
P08-5.8.c	Maintenance stock impact.	Not started	An asset failure records affected stock quantity, protection action and inventory disposition links.
P08-5.8.d	Asset-alarm linkage.	Not started	An alarm creates one source-linked service incident with time, asset, severity and acknowledgment.
P08-6.1.a	Versioned plan record.	Not started	Every plan version is immutable, effective-dated and reproducible after later plan changes.
P08-6.1.b	Feature entitlement matrix.	Not started	Each plan states exact feature, register, device and printer limits with no hidden defaults.
P08-6.1.c	Aggregate usage measurement.	Not started	Billable and threshold usage is counted once from source evidence and never blocks an active sale.
P08-6.1.d	Threshold notices.	Not started	Owners receive deduplicated approaching and exceeded notices showing the measured period and next action.
P08-6.1.e	Historical lease reproduction.	Not started	A saved signed lease verifies against the plan and limits that applied when it was issued.
P08-6.1.f	Commercial wording approval.	Owner validation required	The product owner approves plan names, limits, notice wording and the free-to-paid explanation.
P08-6.2.a	Billing-provider port.	Not started	Commercial use cases depend on a replaceable billing-provider boundary rather than a provider SDK.
P08-6.2.b	Hosted checkout handoff.	Not started	Kuberan creates a provider-hosted payment session without receiving or storing raw card details.
P08-6.2.c	Authenticated webhook intake.	Not started	Invalid signatures, stale events and wrong accounts are rejected before commercial state changes.
P08-6.2.d	Idempotent billing events.	Not started	The same provider event delivered repeatedly changes subscription state only once.
P08-6.2.e	Provider-state mapping.	Not started	Paid, past-due, cancelled and incomplete provider states map to explicit Kuberan states with source references.
P08-6.2.f	Provider sandbox checkout certification.	Owner validation required	The billing-account holder confirms the provider sandbox checkout creates the expected test subscription.
P08-6.2.g	Live provider checkout certification.	Owner validation required	The billing-account holder confirms the approved live hosted checkout without exposing raw card data to Kuberan.
P08-6.2.h	Provider invoice certification.	Owner validation required	The owner confirms the provider invoice identity, amount, tax treatment and Kuberan subscription link.
P08-6.2.i	Provider failed-payment certification.	Owner validation required	The owner confirms failed payment and notice behavior in the real billing account.
P08-6.2.j	Billing-provider simulator.	Not started	Success, failure, timeout and replay can be reproduced without a live billing account.
P08-6.2.k	Provider payment-recovery certification.	Owner validation required	The owner confirms authenticated recovery restores the expected subscription and entitlements in the real account.
P08-6.3.a	Grace-policy engine.	Not started	A signed cached lease applies the documented grace dates consistently while cloud or billing is unavailable.
P08-6.3.b	Commercial-hold enforcement.	Not started	A commercial hold blocks only the documented future actions and never interrupts an active sale.
P08-6.3.c	Upgrade transition.	Not started	An upgrade issues the new entitlements once without disconnecting already licensed devices.
P08-6.3.d	Downgrade transition.	Not started	A downgrade preserves existing trading, explains over-limit resources and blocks only new excess activation.
P08-6.3.e	Checkout isolation fault test.	Not started	Billing, webhook and License Cloud failure during checkout causes no sale loss or duplicate effect.
P08-6.3.f	Commercial-notice policy approval.	Owner validation required	The product owner approves threshold wording, delivery timing and resolution path.
P08-6.3.g	Commercial-hold policy approval.	Owner validation required	The product owner approves which future commercial actions a hold may block and how recovery clears it.
P08-6.3.h	Humane-downgrade policy approval.	Owner validation required	The product owner approves over-limit wording, preserved trading and the prohibition on surprise active-sale lockout.
P08-6.3.i	Commercial-hold recovery.	Not started	Authenticated recovery evidence clears only the intended hold and issues the resulting signed state once.
P08-6.3.j	Grace-duration approval.	Owner validation required	The product owner approves the exact grace duration and start/end calculation.
P08-6.4.a	Super-admin authentication.	Not started	License Manager requires MFA, fresh authentication for sensitive actions and records the authenticated admin.
P08-6.4.b	Tenant-safe license search.	Not started	An authorized admin can find the intended organization, owner, store or installation without cross-tenant leakage.
P08-6.4.c	Grant workflow.	Not started	A feature or capacity grant records scope, reason, approver, start, expiry and resulting lease.
P08-6.4.d	Override workflow.	Not started	An override records before and after values, reason and expiry and automatically returns to normal policy.
P08-6.4.e	Admin audit search.	Not started	Every sensitive read and change is searchable by actor, tenant, action, time and correlation identity.
P08-6.4.f	License lookup usability review.	Owner validation required	The super admin finds a store and explains its plan, usage, devices and current license without engineering help.
P08-6.4.g	Grant usability review.	Owner validation required	The super admin creates an approved time-bounded grant without engineering help.
P08-6.4.h	Override usability review.	Owner validation required	The super admin creates an audited, expiring override without engineering help.
P08-6.4.i	Expiry-review usability.	Owner validation required	The super admin identifies upcoming grant and override expiries and confirms the resulting normal policy.
P08-6.4.j	Tenant-safe license detail.	Not started	Authorized detail shows license, plan, usage, device and billing sources only for the selected tenant.
P08-6.4.k	Admin audit export.	Not started	An authorized export reproduces the selected immutable audit records without hidden sensitive fields.
P08-6.5.a	Replacement installation.	Not started	A verified replacement transfers approved capacity while preserving the old installation history.
P08-6.5.b	Device revocation.	Not started	Device revocation reaches the intended installation and never disables another tenant's device.
P08-6.5.c	Consented support session.	Not started	Support access shows purpose, scope and expiry to the owner and cannot start without recorded consent.
P08-6.5.d	Support-session expiry.	Not started	An expired support session loses access immediately and leaves a complete audit.
P08-6.5.e	Replacement-process wording approval.	Owner validation required	The owner confirms replacement-installation consequences and recovery wording are understandable.
P08-6.5.f	Revocation wording approval.	Owner validation required	The owner confirms device and license revocation warnings and effects are understandable.
P08-6.5.g	Support-consent wording approval.	Owner validation required	The owner confirms support purpose, scope, expiry and immediate termination language are acceptable.
P08-6.5.h	License revocation.	Not started	License revocation produces a new signed state for only the intended tenant and installation.
P08-6.5.i	Emergency support termination.	Not started	Owner termination removes active support access immediately and records the complete termination audit.
P08-7.1.a	Versioned cross-domain read contracts.	Not started	Each module exposes stable totals, exceptions and source IDs without another module writing its ledger.
P08-7.1.b	Unified work queue.	Not started	Every actionable exception appears once with priority, due time, owner and source link.
P08-7.1.c	Approval inbox.	Not started	Approvers see the evidence, policy and effect before deciding and cannot approve their own restricted action.
P08-7.1.d	Evidence drill-down.	Not started	Every queue item opens the exact source records and returns to the same filtered context.
P08-7.1.e	Queue workflow review.	Owner validation required	Managers confirm the queue makes the next action obvious and does not hide urgent work.
P08-7.1.f	Approval workflow review.	Owner validation required	Approvers confirm evidence, policy and effect are understandable before a decision.
P08-7.2.a.1	Daily sales owner view.	Not started	Accepted sales and returns reconcile to the selected business day.
P08-7.2.a.2	Daily tender owner view.	Not started	Cash, card and stored-value tenders reconcile to the selected business day.
P08-7.2.a.3	Daily cash owner view.	Not started	Till, safe and deposit cash positions reconcile to the selected business day.
P08-7.2.a.4	Daily stock owner view.	Not started	Stock movements and count exceptions reconcile to the selected business day.
P08-7.2.a.5	Daily staffing owner view.	Not started	Scheduled coverage, punches and attendance exceptions reconcile to the selected business day.
P08-7.2.a.6	Daily safety owner view.	Not started	Required checks, failures and corrective actions reconcile to the selected business day.
P08-7.2.a.7	Daily exception owner view.	Not started	Every unresolved daily exception shows its source, owner and current status.
P08-7.2.b	Weekly operating view.	Not started	Weekly trends retain department and store filters and open every total to source evidence.
P08-7.2.c.1	Month-end bank status view.	Not started	Each bank account shows its reconciliation owner, status and blocking reason.
P08-7.2.c.2	Month-end HST status view.	Not started	The HST working report shows its accountable owner, status and blocking reason.
P08-7.2.c.3	Month-end payables status view.	Not started	Open payables and vendor credits show their owner, status and blocking reason.
P08-7.2.c.4	Month-end payroll-handoff status view.	Not started	The payroll handoff shows its accountable owner, status and blocking reason.
P08-7.2.c.5	Month-end unresolved-close view.	Not started	Every remaining close item shows its owner, due action and blocking reason.
P08-7.2.d	Business-period correctness.	Not started	Overnight trade and corrected records remain in the intended store business period.
P08-7.2.e.1	Owner accepts the daily decision view.	Owner validation required	A representative owner confirms the daily view answers the store-opening, trading and close questions without developer help.
P08-7.2.e.2	Owner accepts the weekly decision view.	Owner validation required	A representative owner confirms the weekly view supports staffing, purchasing, cash and exception decisions.
P08-7.2.e.3	Owner accepts the month-end decision view.	Owner validation required	A representative owner confirms the month-end view exposes every material total, exception and source link.
P08-7.2.e.4	Bookkeeper accepts the daily decision view.	Owner validation required	A representative bookkeeper confirms daily cash, tender, deposit and source links support routine bookkeeping.
P08-7.2.e.5	Bookkeeper accepts the weekly decision view.	Owner validation required	A representative bookkeeper confirms weekly sales, purchasing, payroll and bank exceptions are complete and traceable.
P08-7.2.e.6	Bookkeeper accepts the month-end decision view.	Owner validation required	A representative bookkeeper confirms the close, bank, HST and accounting views reproduce the approved period totals.
P08-7.2.f	Store-timezone correctness.	Not started	Every displayed business period derives from the effective store timezone rather than the viewing device timezone.
P08-7.3.a.1	Forecast thirteen-week cash balances.	Not started	Each weekly cash balance reconciles to its source opening balance and dated movements.
P08-7.3.a.2	Forecast thirteen-week commitments.	Not started	Each known commitment appears once in its expected payment week.
P08-7.3.a.3	Forecast payroll payment dates.	Not started	Expected payroll outflows appear on their accountable payment dates.
P08-7.3.a.4	Forecast HST payment dates.	Not started	Expected HST outflows appear on their accountable remittance dates.
P08-7.3.a.5	Expose cash-outlook assumptions.	Not started	Every forecast assumption is visible with its source, value and effective date.
P08-7.3.a.6	Export the thirteen-week cash outlook.	Not started	The export reproduces the displayed weeks, values, sources and assumptions.
P08-7.3.b.1	Show current safety risks.	Not started	Each safety risk shows severity, owner, age and next action.
P08-7.3.b.2	Show current maintenance risks.	Not started	Each maintenance risk shows severity, owner, age and next action.
P08-7.3.b.3	Show current loss-prevention risks.	Not started	Each loss-prevention risk shows severity, owner, age and next action.
P08-7.3.b.4	Show current stock risks.	Not started	Each stock risk shows severity, owner, age and next action.
P08-7.3.b.5	Show current licensing risks.	Not started	Each licensing risk shows severity, owner, age and next action.
P08-7.3.c	Restricted-data projection.	Not started	Owner views expose only the minimum HR, customer and loss-case detail allowed for the signed-in role.
P08-7.3.d	Reproducible decision snapshot.	Not started	A saved decision view records filters, source versions and generated time so another authorized user can reproduce it.
P08-7.3.e	Decision-view privacy review.	Owner validation required	Accountable users confirm dashboards do not unnecessarily expose employee, customer or loss-case data.
P08-7.3.f.1	Manager accepts the daily risk view.	Owner validation required	A representative manager identifies the daily cash, staffing, safety and exception actions without developer help.
P08-7.3.f.2	Owner accepts the daily risk view.	Owner validation required	A representative owner identifies the daily cash position and highest store risks without developer help.
P08-7.3.f.3	Manager accepts the weekly outlook.	Owner validation required	A representative manager uses the weekly view to assign stock, staffing and operational follow-up.
P08-7.3.f.4	Owner accepts the weekly outlook.	Owner validation required	A representative owner uses the weekly outlook for cash, purchasing, payroll and risk decisions.
P08-7.3.f.5	Owner accepts the month-end outlook.	Owner validation required	A representative owner confirms the month-end outlook explains cash, liabilities, tax and open risks.
P08-7.3.f.6	Bookkeeper accepts the month-end outlook.	Owner validation required	A representative bookkeeper confirms the month-end outlook reconciles to accepted accounting and tax sources.
P08-8.1.a	Pilot scope approval.	Owner validation required	The approved store, departments, lanes, workflows and excluded scope are named before pilot authority begins.
P08-8.1.b	Pilot authority plan.	Owner validation required	Each pilot workflow has one declared system of record and exact authority cutover time.
P08-8.1.c	Pilot data-load rehearsal.	Not started	A repeatable rehearsal loads the approved pilot data once with a readable import result.
P08-8.1.d.1	Simulate store opening.	Not started	The simulator opens the approved lanes, tills and operating day with exact opening controls.
P08-8.1.d.2	Simulate the trading interval.	Not started	The simulator completes the frozen basket and exception workload with exact sale totals.
P08-8.1.d.3	Simulate tender settlement.	Not started	Every simulated cash and electronic tender reaches one truthful terminal state and exact settlement total.
P08-8.1.d.4	Simulate final receipt production.	Not started	Every paid simulated sale produces one immutable receipt with exact tender and tax evidence.
P08-8.1.d.5	Simulate trading-day close.	Not started	The simulator closes the approved period with sale, tender and receipt control totals reconciled exactly.
P08-8.1.d.6	Reconcile the complete trading cycle.	Not started	Opening plus accepted activity equals closing across sale, tender and receipt controls with no unexplained difference.
P08-8.1.e.1	Name the live department and participants.	Owner validation required	The owner records the approved pilot department, representative roles and named store users.
P08-8.1.e.2	Record the live-cycle start boundary.	Owner validation required	The pilot record freezes the opening time, lanes, tills, stock scope and starting control totals.
P08-8.1.e.3	Record the live-cycle end boundary.	Owner validation required	The pilot record freezes the closing time and the exact sale, tender, stock and cash ending totals.
P08-8.1.e.4	Reconcile live-cycle variances.	Owner validation required	Every live-cycle variance has its source, amount, accountable owner and disposition recorded.
P08-8.1.e.5	Record live-cycle help requests.	Owner validation required	Each participant's help request records role, task, time, assistance and resolution.
P08-8.1.e.6	Accept the whole-store live cycle.	Owner validation required	The pilot owner accepts the reconciled opening, operation, close, variance and help record for the same authority interval.
P08-8.1.f	Receiving-cycle simulation.	Not started	The simulator receives an approved delivery and reconciles accepted, rejected and source quantities.
P08-8.1.g	Count-cycle simulation.	Not started	The simulator completes a count and posts only the approved inventory variance.
P08-8.1.h	Purchase-claim simulation.	Not started	The simulator opens, ages and resolves a vendor claim without losing its source evidence.
P08-8.1.i.1	Simulate staff scheduling.	Not started	The frozen role and availability fixture produces the expected schedule and assigned hours.
P08-8.1.i.2	Simulate staff punches.	Not started	Clock-in, break and clock-out events produce exact worked time.
P08-8.1.i.3	Simulate a punch correction.	Not started	An authorized correction preserves the original punch, reason, actor and exact revised hours.
P08-8.1.i.4	Simulate timesheet approval.	Not started	The authorized approver accepts the exact employee and period control totals.
P08-8.1.i.5	Simulate timesheet freeze.	Not started	The approved period becomes immutable except through the controlled reopen path.
P08-8.1.i.6	Simulate payroll handoff.	Not started	The frozen period exports once with exact employee, hour and pay-code totals.
P08-8.1.i.7	Reconcile the complete staff cycle.	Not started	Schedule, punch, correction, frozen and exported hours agree for every fixture employee.
P08-8.1.j.1	Simulate a customer-service case.	Not started	The case completes intake, ownership, response and closure with preserved customer evidence.
P08-8.1.j.2	Simulate a stored-value movement.	Not started	One issue, redemption or correction produces the exact customer and liability balances.
P08-8.1.j.3	Reconcile customer-value liability.	Not started	Opening value plus the simulated movement equals the reported closing liability.
P08-8.1.k	Safety-cycle simulation.	Not started	The simulator completes a safety exception, corrective action and verified close with retained evidence.
P08-8.1.l.1	Simulate finance-source import.	Not started	The frozen bank or accounting source imports once with exact source totals and identity.
P08-8.1.l.2	Simulate finance matching.	Not started	Deterministic matches preserve both source records and exact matched amounts.
P08-8.1.l.3	Simulate finance-exception resolution.	Not started	Every unmatched or differing item receives an owner, evidence and approved disposition.
P08-8.1.l.4	Simulate finance-period close.	Not started	The test period closes only when imported, matched, exception and closing totals reconcile exactly.
P08-8.1.l.5	Reconcile the complete finance cycle.	Not started	Opening plus accepted imported activity equals the calculated closing total with every exception retained.
P08-8.1.m.1	Simulate a paid-plan upgrade.	Not started	The signed entitlement changes to the approved paid plan without interrupting active trading.
P08-8.1.m.2	Simulate a billing failure.	Not started	A failed charge records one truthful billing state and does not abruptly stop an active sale.
P08-8.1.m.3	Simulate the paid-plan grace interval.	Not started	The signed lease enforces the exact configured grace rights, notices and expiry.
P08-8.1.m.4	Simulate paid-plan recovery.	Not started	Successful payment restores the correct entitlements once with complete audit evidence.
P08-8.1.m.5	Prove checkout remains isolated from billing.	Not started	A sale opened during every simulated billing state completes without loss or duplicate effect.
P08-8.1.m.6	Reconcile the licensing lifecycle.	Not started	Plan, billing, grace, entitlement and notice history explain the complete simulated lifecycle.
P08-8.1.n	Combined cycle reconciliation.	Not started	All simulated domain outputs reconcile together with no unexplained cross-domain variance.
P08-8.1.o	Pilot role map approval.	Owner validation required	Every pilot user and accountable role is named with permitted workflows before authority begins.
P08-8.1.p.1	Approve pilot coexistence authority	Owner validation required	Each pilot workflow has one authoritative system and prohibits unexplained dual posting.
P08-8.1.p.2	Approve pilot rollback plan	Owner validation required	Rollback trigger, owner, steps and post-rollback reconciliation are signed.
P08-8.1.q	Pilot opening-total rehearsal.	Not started	Every opening pilot control total reconciles to the approved source before authority begins.
P08-8.2.a.1	Rehearse period time approval.	Not started	Every employee timesheet is approved by an authorized role with exact period hours.
P08-8.2.a.2	Rehearse payroll export.	Not started	The frozen approved period exports once with the expected schema and identity.
P08-8.2.a.3	Reconcile payroll control totals.	Not started	Employee, hour, pay-code and period export totals reconcile exactly to approved time.
P08-8.2.a.4	Preserve payroll-provider rejection evidence.	Not started	A simulated provider rejection preserves file, reason, response time and corrected resubmission lineage.
P08-8.2.a.5	Reconcile period payroll totals.	Not started	The exported period total equals the frozen approved period total.
P08-8.2.a.6	Complete the payroll-period rehearsal.	Not started	Approval, export, provider response and employee/period totals reconcile for the same frozen period.
P08-8.2.b	Payroll-period sign-off.	Owner validation required	The payroll accountable person accepts the real-role export and correction workflow.
P08-8.2.c.1	Rehearse bank-statement import.	Not started	The frozen statement imports once with preserved source identity and exact opening, movement and closing totals.
P08-8.2.c.2	Rehearse bank matching.	Not started	Approved deterministic matches preserve the exact statement and store-side records.
P08-8.2.c.3	Rehearse bank-exception resolution.	Not started	Every unmatched, fee, timing or amount difference receives an owner and approved disposition.
P08-8.2.c.4	Rehearse bank-period close.	Not started	The bank period closes only when reconciled store and preserved statement totals agree exactly.
P08-8.2.c.5	Complete the bank-close rehearsal.	Not started	The test bank period closes with exact totals or explicitly retained exceptions.
P08-8.2.d	Bank-close sign-off.	Owner validation required	The accountable bookkeeper accepts the bank workpapers, variances and correction path.
P08-8.2.e.1	Rehearse collected-HST calculation.	Not started	Collected HST reproduces exactly from preserved taxable-sale and return evidence.
P08-8.2.e.2	Rehearse input-tax-credit calculation.	Not started	Eligible input tax credits reproduce exactly from preserved approved vendor evidence.
P08-8.2.e.3	Rehearse HST adjustments.	Not started	Every included HST adjustment preserves reason, source, actor and exact signed amount.
P08-8.2.e.4	Rehearse HST working balance.	Not started	The working HST balance equals collected tax less input credits plus signed adjustments.
P08-8.2.e.5	Preserve HST source drill-down.	Not started	Every working-report total opens to the contributing sales, purchases and adjustments.
P08-8.2.f	HST-close sign-off.	Owner validation required	A qualified accountant accepts the test-period HST workpapers, variances and correction path.
P08-8.3.a	Safety-control drill.	Owner validation required	Store staff complete a failed safety check, corrective action and verified close with accountable sign-off.
P08-8.3.b.1	Drill a paid-plan upgrade.	Not started	The frozen pilot build accepts one approved signed upgrade without interrupting active trading.
P08-8.3.b.2	Drill a paid-plan payment failure.	Not started	The simulated failed payment records one truthful auditable state without stopping an active sale.
P08-8.3.b.3	Drill paid-plan grace behavior.	Not started	The appliance enforces the exact signed grace rights and notices throughout the configured interval.
P08-8.3.b.4	Drill paid-plan recovery.	Not started	A successful simulated payment restores the correct entitlements once with complete audit evidence.
P08-8.3.b.5	Verify sale continuity during the licence drill.	Not started	An active sale completes safely during each commercial-state transition.
P08-8.3.b.6	Accept the complete paid-licence drill.	Not started	Upgrade, failure, grace, recovery, notices and audit reconcile for one lifecycle.
P08-8.3.c.1	Freeze the continuity incident fixture.	Not started	The rehearsal names the exact outage, starting state, affected services and expected degraded behavior.
P08-8.3.c.2	Freeze the continuity recovery boundary.	Not started	The rehearsal names the recovery trigger, target state, authoritative data and completion condition.
P08-8.3.c.3	Reconcile continuity outcomes.	Not started	The frozen pilot build reaches the target state with exact ledgers, queues and zero lost or duplicate business effects.
P08-8.3.c.4	Reconcile continuity control totals.	Not started	Pre-incident, offline and recovered totals agree across every affected ledger.
P08-8.3.c.5	Accept the complete continuity scenario.	Not started	The named scenario finishes with no lost or duplicated effect and every exception has an owner.
P08-8.3.d	Physical power-failure drill.	Owner validation required	Store staff complete the approved power-failure drill using the offline runbook.
P08-8.3.e	Restore acceptance.	Owner validation required	The store owner confirms the restored environment is understandable, complete and ready to resume operation.
P08-8.3.f	Recall drill.	Owner validation required	Store staff execute recall stop-sale, trace, quarantine, disposition and verified close with accountable sign-off.
P08-8.3.g	Physical network-failure drill.	Owner validation required	Store staff complete the approved network-failure and reconnect drill using the offline runbook.
P08-8.3.h	Physical device-failure drill.	Owner validation required	Store staff complete the approved lane-device failure and recovery drill using the offline runbook.
P08-8.3.i	One-person-control drill.	Owner validation required	Store staff use the approved one-person exception without removing limits, later review or audit evidence.
P08-8.3.j.1	Restore the frozen pilot build to a replacement.	Not started	The approved backup creates exactly one replacement environment at the expected recovery point.
P08-8.3.j.2	Measure replacement recovery time.	Not started	Start, service-ready and business-ready times are captured and meet the approved target.
P08-8.3.j.3	Reconcile replacement ledgers.	Not started	Every authoritative ledger agrees with the backup and replay control totals.
P08-8.3.j.4	Reconcile replacement queues.	Not started	Every sync, outbox and operational queue agrees with the expected recovery state without duplicate work.
P08-8.3.j.5	Preserve store identity and retire the old box.	Not started	The replacement retains the store identity while the old installation cannot become authoritative again.
P08-8.3.j.6	Accept replacement readiness.	Not started	Store identity, ledgers, queues and recovery timing pass before operation resumes.
P08-8.4.a	Pilot issue register.	Not started	Every pilot issue has severity, owner, workaround, fix version and retest evidence.
P08-8.4.b	Sales-ledger reconciliation.	Not started	Pilot sales totals reproduce from accepted sale and return evidence with no unexplained difference.
P08-8.4.c	Severity-one exit check.	Not started	The exit report cannot pass while any severity-one issue or unexplained authority gap remains.
P08-8.4.d.1.1	Publish pilot scope section	Not started	The report names the exact included and excluded store scope.
P08-8.4.d.1.2	Publish pilot authority-date section	Not started	The report names the exact pilot start, end and authority dates.
P08-8.4.d.2	Publish pilot metrics section.	Not started	The exit report reproduces the approved operational and support metrics.
P08-8.4.d.3	Publish pilot reconciliation section.	Not started	The exit report links each material ledger to its accepted reconciliation result.
P08-8.4.d.4	Publish pilot drill section.	Not started	The exit report lists every required drill and its accepted evidence.
P08-8.4.d.5	Publish pilot defect section.	Not started	The exit report gives every pilot defect its severity and disposition.
P08-8.4.d.6	Publish pilot change section.	Not started	The exit report identifies every accepted build, configuration or authority change.
P08-8.4.d.7	Publish remaining-risk section.	Not started	The exit report names each residual risk, owner and accepted next action.
P08-8.4.d.8	Assemble the whole-store exit report gate.	Not started	The final report contains all seven accepted sections for the same pilot identity.
P08-8.4.e	Owner acceptance.	Owner validation required	The store owner signs the completed operating-cycle result, accepted variances and decision to exit V0.8.
P08-8.4.f	Tender-ledger reconciliation.	Not started	Pilot tender totals reproduce from settled cash, card and stored-value evidence.
P08-8.4.g	Cash-ledger reconciliation.	Not started	Pilot till, safe and deposit totals reconcile or retain a named accepted exception.
P08-8.4.h	Inventory-quantity reconciliation.	Not started	Pilot on-hand quantities reproduce from inventory movements and approved counts.
P08-8.4.i	Purchasing-ledger reconciliation.	Not started	Pilot orders, receipts, invoices, claims and credits reconcile to source commitments.
P08-8.4.j	Customer-value reconciliation.	Not started	Pilot points, gift-card and store-credit movements reproduce the reported liabilities.
P08-8.4.k	Payroll-handoff reconciliation.	Not started	Pilot approved hours and export responses reconcile for every included employee.
P08-8.4.l	Bank reconciliation.	Not started	Pilot bank opening, transactions, matches and closing balance reconcile to source statements.
P08-8.4.m	HST reconciliation.	Not started	Pilot HST collected, credits and adjustments reproduce the accepted working balance.
P08-8.4.n	Licensing reconciliation.	Not started	Pilot usage, plan, entitlements and billing state reproduce from owner-visible source evidence.
P08-8.4.o	Cross-ledger reconciliation gate.	Not started	Every material V0.8 ledger passes its individual reconciliation with no unexplained authority gap.
P08-8.4.p	Pilot hypercare cadence.	Not started	Every planned hypercare interval records staffing, health, open issues and next review time.
P08-8.4.q	Inventory-valuation reconciliation.	Not started	Pilot inventory value reproduces from approved costed movements and the effective valuation policy.

Technical task-ID appendix — V1.0 canonical source rows (581 tasks, closed by default)

The owner-readable register above is the primary progress view. Open this appendix only when exact technical task IDs are needed.

Child	Bounded outcome	Status	Plain-language acceptance
P10-1.1.a	Freeze the V1 requirement inventory and version.	Not started	The register contains every approved V1 requirement once, with no orphan or duplicate.
P10-1.1.b	Link each requirement to owning code or configuration.	Not started	Opening a requirement shows the exact implementation that provides it.
P10-1.1.c.1	Link positive acceptance tests	Not started	Each P0 and P1 success path links to repeatable proof.
P10-1.1.c.2	Link negative acceptance tests	Not started	Each P0 and P1 denial or failure path links to repeatable proof.
P10-1.1.c.3	Link recovery acceptance tests	Not started	Each recoverable P0 and P1 fault links to repeatable recovery proof.
P10-1.1.d	Link each operational requirement to its owner-facing runbook.	Not started	Store staff can find the operating or recovery instruction without developer help.
P10-1.1.e.1	Produce missing-evidence report	Not started	Every missing implementation, test or runbook link has severity, owner, due action and release effect.
P10-1.1.e.2	Produce contradiction report	Not started	Every conflicting requirement, implementation, test or status has sources and a resolution owner.
P10-1.1.f	Close all release-blocking P0/P1 trace gaps.	Not started	The trace audit reports zero unresolved release-blocking gap.
P10-1.2.a	Enforce close-period lock on every posting path.	Not started	No sale, purchase, payroll, bank or tax posting can silently change a locked period.
P10-1.2.b	Implement authorized period reopen with reason and approval.	Not started	A permitted reopen records who, why, when and the exact period affected.
P10-1.2.c	Implement prior-period adjustment entries without rewriting history.	Not started	A correction preserves the original entry and posts a visible linked adjustment.
P10-1.2.d.1	Prove initial close totals	Not started	Initial close totals balance from immutable activity.
P10-1.2.d.2	Prove reopened-period totals	Not started	Reopened-period totals balance without rewriting closed history.
P10-1.2.d.3	Prove correction totals	Not started	Approved correction totals balance and retain their source.
P10-1.2.d.4	Prove re-close totals	Not started	Re-closed totals balance after the approved correction.
P10-1.3.a.1	Define customer-merge eligibility	Not started	Deterministic rules deny every ineligible customer merge.
P10-1.3.a.2	Preview customer-merge conflicts	Not started	Identity, consent and stored-value conflicts are visible before commit.
P10-1.3.b.1	Preserve loyalty history during customer merge.	Not started	Loyalty activity and points appear once under the surviving identity.
P10-1.3.b.2	Preserve gift-card links during customer merge.	Not started	Every linked gift card remains linked once with its unchanged value ledger.
P10-1.3.b.3	Preserve store-credit links during customer merge.	Not started	Every linked store credit remains linked once with its unchanged balance.
P10-1.3.b.4	Preserve customer-case history during merge.	Not started	Authorized case history remains traceable to the surviving and original identities.
P10-1.3.c	Implement authorized merge reversal.	Not started	Reversal restores both identities and ownership links without losing or duplicating value.
P10-1.3.d.1	Prove exact customer-merge replay.	Not started	An identical merge command returns the stored result without merging twice.
P10-1.3.d.2	Prove concurrent customer merges.	Not started	Simultaneous conflicting merge commands produce one auditable winner.
P10-1.3.d.3	Prove customer-merge crash recovery.	Not started	An interrupted merge resumes or rolls back without partial identity or value movement.
P10-1.3.d.4	Prove exact merge-reversal replay.	Not started	An identical reversal command returns the stored result without reversing twice.
P10-1.3.d.5.1	Prove merge-reversal concurrency.	Not started	Simultaneous reversal commands converge to one authorized complete auditable winner.
P10-1.3.d.5.2	Prove merge-reversal crash recovery.	Not started	An interrupted reversal restarts to one complete auditable result without lost or duplicate value.
P10-1.4.a.1	Freeze cash-outlook source inputs.	Not started	Every displayed cash input names its source ledger, source field and effective date.
P10-1.4.a.2	Freeze risk-outlook source inputs.	Not started	Every displayed risk names its source record, effective date and status version.
P10-1.4.a.3	Freeze owner outlook formulas.	Not started	Every displayed cash or risk result names the exact versioned calculation formula.
P10-1.4.b.1	Calculate recorded cash separately.	Not started	The owner sees source-backed cash without estimates mixed into the amount.
P10-1.4.b.2	Calculate known obligations separately.	Not started	The owner sees dated source-backed obligations without cash or estimates mixed in.
P10-1.4.b.3	Calculate overdue and unresolved exceptions separately.	Not started	The owner sees each overdue or unresolved item outside confirmed cash and obligations.
P10-1.4.b.4	Calculate outlook confidence separately.	Not started	The displayed confidence identifies estimates and missing evidence that affect reliability.
P10-1.4.c.1	Add owner-outlook source drill-down	Not started	Every owner-outlook total opens to its source rows.
P10-1.4.c.2	Reconcile owner-outlook source totals	Not started	Opened source rows add exactly to the displayed owner-outlook amount.
P10-1.4.d	Independently reproduce the outlook from source ledgers.	Owner validation required	An owner or accountant reproduces the result without developer explanation.
P10-1.5.a	Run the frozen full regression suite from a clean build.	Not started	All required suites pass with zero unexplained failure, error or skip.
P10-1.5.b	Reconcile every open defect to severity and affected requirement.	Not started	No defect lacks an owner, severity, reproduction and release disposition.
P10-1.5.c	Close every severity-1 defect and release-blocking severity-2 defect.	Not started	The release register shows zero open severity-1 and no unaccepted blocker.
P10-1.5.d	Record each waiver with risk, compensating control and expiry.	Not started	No waiver is permanent, ownerless or hidden from the release decision.
P10-1.5.e	Accept final defect and waiver disposition.	Owner validation required	Product Owner, Engineering and QA sign the exact residual-risk list.
P10-2.1.a.1	Freeze trust-boundary inventory	Not started	Every device, client, server, cloud, database and provider boundary is named.
P10-2.1.a.2	Refresh the V1 threat model	Not started	Threats and controls map to every frozen trust boundary.
P10-2.1.b.1	Run the release dependency scan.	Not started	Every shipped dependency is identified and no prohibited dependency remains unexplained.
P10-2.1.b.2	Run the release secret scan.	Not started	No raw credential or private key appears in source, artifacts or evidence.
P10-2.1.b.3	Run the dependency-license scan.	Not started	Every shipped component has an accepted software-license disposition.
P10-2.1.b.4	Run the vulnerable-component scan.	Not started	No critical vulnerability or unaccepted release blocker remains.
P10-2.1.c.1	Generate release SBOMs	Not started	Each shipped artifact receives an exact machine-readable component inventory.
P10-2.1.c.2	Verify release SBOMs	Not started	SBOM identity and completeness reproduce from each artifact.
P10-2.1.d.1	Verify release-artifact signatures.	Not started	Tampered, unsigned or wrong-key release artifacts are rejected.
P10-2.1.d.2	Verify update-manifest signatures.	Not started	Tampered, unsigned, expired or wrong-key update manifests are rejected.
P10-2.1.d.3	Verify signed licence leases.	Not started	Tampered, unsigned, expired or wrong-key licence leases are rejected.
P10-2.1.d.4	Verify signed release evidence.	Not started	Tampered, unsigned or wrong-key release evidence is rejected.
P10-2.1.e.1	Remediate every fixable high-risk threat.	Not started	Each high-risk finding selected for correction has a verified control and regression test.
P10-2.1.e.2	Accept any residual high-risk threat explicitly.	Owner validation required	Security and Product record accountable, time-bounded acceptance with compensating controls and expiry.
P10-2.2.a	Prepare isolated penetration-test environments and accounts.	Not started	Testers receive safe tenants, roles, devices, reset steps and evidence-capture instructions.
P10-2.2.b.1.1	Test device-identity forgery	Owner validation required	An independent tester cannot forge a trusted device identity.
P10-2.2.b.1.2	Test cross-store device reuse	Owner validation required	A device identity trusted by one store is rejected by another.
P10-2.2.b.2.1	Test unauthorized or expired pairing	Owner validation required	Unauthorized or expired pairing creates no trusted device.
P10-2.2.b.2.2	Test pairing replay	Owner validation required	A reused claim or nonce creates no second trusted device.
P10-2.2.b.3	Independently test device revocation.	Owner validation required	A revoked or stolen device cannot resume protected work with cached material.
P10-2.2.b.4.1	Test expired user sessions	Owner validation required	Expired sessions fail closed without protected-data leakage.
P10-2.2.b.4.2	Test replaced user sessions	Owner validation required	Replaced sessions fail closed without protected-data leakage.
P10-2.2.b.4.3	Test copied or stolen user sessions	Owner validation required	Copied sessions fail closed without protected-data leakage.
P10-2.2.c.1	Independently test owner-account abuse.	Owner validation required	Owner authority cannot silently cross organizations, stores or fresh-approval boundaries.
P10-2.2.c.2	Independently test staff-role privilege escalation.	Owner validation required	A staff user cannot obtain manager, finance, installer or owner authority.
P10-2.2.c.3	Independently test support-access abuse.	Owner validation required	Support cannot gain invisible, unconsented or overlong access.
P10-2.2.c.4	Independently test super-admin abuse.	Owner validation required	Super-admin actions require the documented MFA, reauthentication and immutable audit.
P10-2.2.d.1	Independently test tenant-isolation boundaries.	Owner validation required	No role can read or mutate another store or organization through any supported surface.
P10-2.2.d.2	Independently test object-identifier substitution.	Owner validation required	Changing a resource identifier never bypasses store, role or ownership checks.
P10-2.2.e.1.1	Test exact API replay	Owner validation required	An exact API retry returns the original result without a second effect.
P10-2.2.e.1.2	Test changed-payload idempotency conflict	Owner validation required	Changed input under the same key fails without changing or duplicating an effect.
P10-2.2.e.2	Independently test injection attacks.	Owner validation required	SQL, command, template and structured-payload injection fail without code or data execution.
P10-2.2.e.3.1	Test request-rate exhaustion	Owner validation required	Abusive request rates remain bounded and normal service recovers.
P10-2.2.e.3.2	Test resource exhaustion	Owner validation required	Memory, storage or worker pressure fails safely and service recovers.
P10-2.2.e.4	Independently test unsafe uploads.	Owner validation required	Oversized, malformed, executable and misleading uploads are refused or quarantined safely.
P10-2.2.e.5	Independently test error and diagnostic leakage.	Owner validation required	Errors expose no secret, personal data, payment material, filesystem path or internal stack.
P10-2.2.f.1	Remediate independent penetration-test findings.	Not started	Each release-blocking finding has a verified correction and focused regression evidence.
P10-2.2.f.2	Obtain independent security acceptance.	Owner validation required	The independent reviewer confirms no unresolved critical or high release blocker.
P10-2.3.a.1	Freeze the personal-data inventory.	Not started	Every personal field, copy, derived value and transfer is inventoried with its owning application.
P10-2.3.a.2	Freeze personal-data purposes.	Not started	Every inventoried personal field has one approved collection and use purpose.
P10-2.3.a.3	Freeze personal-data role access.	Not started	Every personal field names the roles allowed to view, create, change or export it.
P10-2.3.a.4	Freeze personal-data retention.	Not started	Every personal field has an approved retention trigger, duration and legal-hold treatment.
P10-2.3.a.5	Freeze personal-data export and deletion treatment.	Not started	Every personal field names its access/export format, deletion or anonymization action and lawful exception.
P10-2.3.b.1	Build customer access package	Not started	A customer access request returns only authorized, readable and source-linked information.
P10-2.3.b.2	Build customer export package	Not started	A customer export contains only authorized, readable and source-linked information.
P10-2.3.b.3	Build employee access package	Not started	An employee access request returns only authorized, readable and source-linked information.
P10-2.3.b.4	Build employee export package	Not started	An employee export contains only authorized, readable and source-linked information.
P10-2.3.c.1	Implement authorized personal-data correction.	Not started	A correction preserves the original value, reason, actor, time and downstream effect.
P10-2.3.c.2	Implement authorized processing restriction.	Not started	A restriction preserves its reason, actor, time, scope and downstream enforcement.
P10-2.3.c.3	Implement consent withdrawal.	Not started	Withdrawal preserves the prior consent, actor, time and downstream effect.
P10-2.3.c.4	Audit every privacy-rights action.	Not started	Each correction, restriction or withdrawal has an immutable authorized audit record.
P10-2.3.d.1	Run retention-expiry job	Not started	Eligible expired personal data is removed according to policy.
P10-2.3.d.2	Enforce personal-data legal hold	Not started	Held data survives expiry and deletion jobs.
P10-2.3.d.3	Run safe anonymization job	Not started	Personal identity is removed while required financial and security evidence remains.
P10-2.3.e.1	Prove cross-store privacy denial.	Not started	A user or device from another store receives no personal content or identifying error detail.
P10-2.3.e.2	Prove wrong-role privacy denial.	Not started	A signed-in user without the required role receives no personal content or identifying error detail.
P10-2.3.e.3	Prove unauthorized support-access denial.	Not started	Support access without current consent, scope and purpose receives no personal content or identifying error detail.
P10-2.3.e.4	Hide identifying privacy-denial details.	Not started	Every refused privacy request reveals no personal value, existence signal or identifying error detail.
P10-2.3.f	Complete representative privacy-request walkthrough.	Owner validation required	The owner/privacy reviewer accepts the request, correction, export and retention experience.
P10-2.4.a.1	Run automated semantic-label checks.	Not started	Every supported critical control has an understandable accessible name and role.
P10-2.4.a.2	Run automated contrast checks.	Not started	Every supported critical screen meets the approved contrast threshold.
P10-2.4.a.3	Run automated focus-order checks.	Not started	Keyboard focus reaches each critical control once in meaningful task order.
P10-2.4.a.4	Run automated text-scale checks.	Not started	Critical screens remain readable and operable at every supported text scale.
P10-2.4.b.1	Complete the sale journey using only a keyboard.	Owner validation required	A representative cashier completes a sale and recovery path without a pointer.
P10-2.4.b.2	Complete the return journey using only a keyboard.	Owner validation required	A representative authorized user completes a controlled return without a pointer.
P10-2.4.b.3	Complete the receiving journey using only a keyboard.	Owner validation required	A representative receiver records and corrects a delivery without a pointer.
P10-2.4.b.4	Complete the store-close journey using only a keyboard.	Owner validation required	A representative manager reviews exceptions and closes the day without a pointer.
P10-2.4.b.5	Complete the setup journey using only a keyboard.	Owner validation required	A representative helper completes supported setup and recovery without a pointer.
P10-2.4.c.1	Complete screen-reader task assessment	Owner validation required	Labels, order, status and recovery guidance are understandable with a screen reader.
P10-2.4.c.2	Complete spoken-error assessment	Owner validation required	Each supported error is announced with a safe next action.
P10-2.4.d.1	Test critical journeys at 200% text size.	Owner validation required	Text remains readable without hiding, clipping or blocking critical actions.
P10-2.4.d.2	Test critical journeys at supported zoom levels.	Owner validation required	Content reflows and every critical control remains reachable.
P10-2.4.d.3	Test colour-independent meaning and status.	Owner validation required	No warning, state or required action depends on colour alone.
P10-2.4.d.4	Test reduced-motion behaviour.	Owner validation required	Motion can be reduced without losing status, focus or task completion.
P10-2.4.e.1	Remediate accessibility blockers	Not started	Every accessibility blocker has a verified fix and regression test.
P10-2.4.e.2	Publish accessibility assistance guide	Not started	Remaining assistance has a clear, non-discriminatory path.
P10-2.4.f	Obtain WCAG 2.2 AA/AODA acceptance.	Owner validation required	The manual assessor signs the supported-platform accessibility result.
P10-3.1.a.1	Freeze the representative store-load fixture.	Not started	Another tester can recreate the same catalogue, staff, stock and operating-day load.
P10-3.1.a.2	Freeze the representative basket-load fixture.	Not started	Another tester can recreate the same basket mix, rate and expected sale/tender totals.
P10-3.1.a.3	Freeze the representative device-load fixture.	Not started	Another tester can recreate the same client, printer, scanner, scale and terminal traffic.
P10-3.1.a.4	Publish expected load control totals.	Not started	Versioned expected totals reproduce every generated business and device effect.
P10-3.1.b.1	Publish lane latency budgets.	Not started	Each critical lane action has stated p95 and p99 response-time budgets.
P10-3.1.b.2	Publish Store Box latency budgets.	Not started	Each critical Store Box command and query has stated p95 and p99 budgets.
P10-3.1.b.3	Publish performance measurement rules.	Not started	The clock source, start/end boundaries, warm-up, sample size and percentile calculation are versioned.
P10-3.1.c.1.1	Measure barcode-scan latency	Not started	Barcode scan-to-line response meets p95 and p99 budgets with the correct product.
P10-3.1.c.1.2	Measure PLU-entry latency	Not started	PLU entry-to-line response meets p95 and p99 budgets with the correct product.
P10-3.1.c.2	Measure basket recalculation latency.	Not started	Price, promotion, tax and deposit recalculation meets its p95/p99 budget exactly.
P10-3.1.c.3.1	Measure cash-tender latency	Not started	Cash-tender completion meets its published budget without duplicate value.
P10-3.1.c.3.2	Measure simulated-card decision latency	Not started	Simulated-card decisions meet their published budget without duplicate value.
P10-3.1.c.3.3	Measure atomic settlement latency	Not started	Atomic sale settlement meets its published commit budget without duplicate value.
P10-3.1.c.4.1	Measure final-receipt lookup latency	Not started	Final-receipt lookup meets its published budget.
P10-3.1.c.4.2	Measure final-receipt rendering latency	Not started	Final-receipt rendering meets its published budget.
P10-3.1.c.5.1	Measure synchronization push latency	Not started	Synchronization push meets its budget without lost or duplicate effects.
P10-3.1.c.5.2	Measure synchronization pull latency	Not started	Synchronization pull meets its budget without lost or duplicate effects.
P10-3.1.c.5.3	Measure synchronization catch-up latency	Not started	Backlog catch-up meets its budget without lost or duplicate effects.
P10-3.1.d.1	Measure SQLite writer contention.	Not started	Writer wait, busy and transaction-duration measurements remain within the published budget.
P10-3.1.d.2	Verify hot SQLite query plans.	Not started	Every identified hot query uses the approved index or records an accepted plan exception.
P10-3.1.e	Publish the reproducible latency report.	Not started	Results name hardware, build, fixture, duration, p50/p95/p99 and failures.
P10-3.2.a	Build the 24-register/40-device load topology.	Not started	All simulated identities, stores, lanes and workloads are reproducible from configuration.
P10-3.2.b	Generate the 1.5-million-event business-day workload.	Not started	Generated sales, stock, staff and finance totals match the frozen expected control totals.
P10-3.2.c	Prove concurrent convergence and exact control totals.	Not started	Every accepted effect appears once and all clients/server totals reconcile.
P10-3.2.d.1	Measure sustained CPU headroom.	Not started	Reference peak load retains at least 30% approved CPU headroom.
P10-3.2.d.2	Measure sustained memory headroom.	Not started	Reference peak load retains at least 30% approved memory headroom without leak growth.
P10-3.2.d.3	Measure SQLite writer headroom and wait time.	Not started	Writer utilization and waits remain inside the approved sustained-load budget.
P10-3.2.d.4	Measure sustained network headroom.	Not started	Reference traffic retains at least 30% approved network headroom.
P10-3.2.d.5.1	Measure sustained disk throughput.	Not started	Reference writes remain within the approved sustained disk-throughput budget.
P10-3.2.d.5.2	Measure spare disk capacity.	Not started	Reference peak load retains at least the approved free disk margin.
P10-3.2.d.5.3	Measure spare queue capacity.	Not started	Sustained reference load does not create unsafe queue growth and retains approved queue headroom.
P10-3.2.e	Prove overload protection and recovery.	Not started	Excess work queues or fails safely and normal service resumes without data repair.
P10-3.3.a	Prepare a deterministic fourteen-day offline workload.	Not started	The fixture names every local action, expected queue item and final source total.
P10-3.3.b.1	Operate the supported offline checkout workflow.	Not started	Local sales remain durable and clearly show queued synchronization status.
P10-3.3.b.2.1	Operate offline receiving	Not started	Committed receiving survives locally with visible policy limits.
P10-3.3.b.2.2	Operate offline inventory movements	Not started	Committed inventory movements survive locally with visible policy limits.
P10-3.3.b.3.1	Operate offline inventory counts	Not started	Counts remain durable and expose conflicts after reconnect.
P10-3.3.b.3.2	Operate offline fresh-production records	Not started	Fresh-production records remain durable and expose conflicts after reconnect.
P10-3.3.b.4.1	Operate offline time punches	Not started	Time punches remain durable without exposing restricted staff data.
P10-3.3.b.4.2	Operate offline staff acknowledgements	Not started	Staff acknowledgements remain durable without exposing restricted staff data.
P10-3.3.b.5.1	Operate offline safety records	Not started	Store-critical safety evidence remains available and queues once.
P10-3.3.b.5.2	Operate offline incident records	Not started	Store-critical incident evidence remains available and queues once.
P10-3.3.c	Restart clients repeatedly during the offline interval.	Not started	Every committed local action survives restart and no half-commit is shown as complete.
P10-3.3.d	Catch up all queues after reconnect.	Not started	The backlog drains once in order without a lost or duplicated business effect.
P10-3.3.e.1.1	Resolve exact replays after reconnect.	Not started	An exact retried event converges to its original result without a second business effect.
P10-3.3.e.1.2	Reject changed-payload replays after reconnect.	Not started	A reused event identity with changed payload fails closed and preserves the original effect.
P10-3.3.e.2	Resolve synchronization conflicts after reconnect.	Not started	Each conflict follows its deterministic merge rule or becomes an owned review item.
P10-3.3.e.3	Resolve quarantined poison events.	Not started	Poison events remain isolated with authorized, replay-safe repair evidence.
P10-3.3.e.4	Reconcile clients with a restored server epoch.	Not started	Clients refresh safely and retained local effects reappear exactly once.
P10-3.3.f	Publish before/after offline control totals.	Not started	Local, server and source totals agree after catch-up.
P10-3.4.a.1	Project SQLite database growth	Not started	The report predicts database capacity and retention at reference-store volume.
P10-3.4.a.2	Project attachment growth	Not started	The report predicts attachment capacity and retention at reference-store volume.
P10-3.4.b.1	Prove storage soft-limit warnings.	Not started	The owner receives actionable notice while enough capacity remains for safe operation.
P10-3.4.b.2	Prove storage hard-limit enforcement.	Not started	Noncritical growth is blocked at the configured boundary without corrupting records.
P10-3.4.b.3	Prove disk-full failure and recovery.	Not started	Writes fail atomically and service recovers after space is restored.
P10-3.4.c.1	Verify thermal monitoring and alert guidance.	Not started	Simulated unsafe temperature creates an owner-readable alert and recovery action.
P10-3.4.c.2	Verify memory-pressure monitoring and alert guidance.	Not started	Simulated memory pressure creates an owner-readable alert before service becomes unsafe.
P10-3.4.c.3	Verify disk-health monitoring and alert guidance.	Not started	Simulated disk-health degradation creates an actionable replacement warning.
P10-3.4.c.4	Verify queue-backlog monitoring and alert guidance.	Not started	Unsafe backlog growth creates an alert naming the queue, age and recovery action.
P10-3.4.d.1	Exercise thermal monitoring on release-candidate hardware.	Owner validation required	Real hardware detects and reports induced thermal pressure.
P10-3.4.d.2	Exercise memory-pressure monitoring on release-candidate hardware.	Owner validation required	Real hardware detects and reports controlled memory pressure.
P10-3.4.d.3	Exercise disk-health monitoring on release-candidate hardware.	Owner validation required	Real hardware reports induced disk-health or capacity pressure accurately.
P10-3.4.d.4	Exercise queue monitoring under release-candidate hardware load.	Owner validation required	Real hardware reports sustained unsafe queue growth with the correct recovery guidance.
P10-3.4.e	Accept the capacity replacement/expansion thresholds.	Owner validation required	The owner/operations reviewer approves when storage or hardware must be serviced.
P10-3.5.a	Freeze the soak build, configuration and reset criteria.	Not started	The exact candidate and every condition that restarts the clock are published before start.
P10-3.5.b.1	Automate continuous workload generation.	Not started	Every scheduled interval runs the exact versioned transaction and device workload.
P10-3.5.b.2	Automate continuous health capture.	Not started	Every scheduled interval records availability, latency, queue, storage and resource measurements.
P10-3.5.b.3	Automate soak-incident capture.	Not started	Every detected failure records time, impact, evidence, owner and recovery disposition.
P10-3.5.c	Complete the thirty-day release-candidate soak.	Owner validation required	The unchanged candidate runs for 30 elapsed days under the approved workload.
P10-3.5.d.1	Reconcile each soak-test day	Owner validation required	Every soak day has accepted control totals.
P10-3.5.d.2	Classify each soak-test interruption	Owner validation required	Every interruption has accepted cause, duration and disposition.
P10-3.5.e.1	Publish measured soak availability	Not started	The report reproduces the thirty-day measurements and exclusions.
P10-3.5.e.2	Accept the soak-test result	Owner validation required	The accountable reviewer signs the result and every excluded interval.
P10-4.1.a.1	Build a reproducible factory image.	Not started	Rebuilding the factory image from frozen inputs produces the same signed hash.
P10-4.1.a.2	Build a reproducible replacement-box image.	Not started	Rebuilding the replacement image from frozen inputs produces the same signed hash.
P10-4.1.b.1	Verify appliance-image signature	Not started	An altered or unsigned appliance image is refused.
P10-4.1.b.2	Verify appliance-image compatibility	Not started	An incompatible appliance image is refused.
P10-4.1.b.3	Verify first-boot image integrity	Not started	Incomplete or inconsistent first boot stops before store data changes.
P10-4.1.c.1	Implement owner-helper installation wizard	Not started	Plain-language steps complete a clean installation.
P10-4.1.c.2	Implement installer recovery messages	Not started	Every installer failure offers a safe retry or support reference.
P10-4.1.d.1	Complete the automated fresh-install journey.	Not started	A clean Mac reaches Ready from the frozen installer with one valid registration.
P10-4.1.d.2	Complete the automated reinstall journey.	Not started	A supported reinstall preserves or safely recovers identity and creates no duplicate data.
P10-4.1.e	Complete replacement-box identity and restore journey.	Not started	The replacement becomes the same store while the replaced installation is safely retired.
P10-4.1.f	Run a nontechnical helper installation session.	Owner validation required	A representative helper reaches Ready without developer intervention.
P10-4.2.a	Inventory each supported legacy source and export version.	Not started	Every accepted source names required files, fields, encoding, timezone and known limitation.
P10-4.2.b.1	Freeze legacy field mappings	Not started	Every accepted source field maps exactly once.
P10-4.2.b.2	Freeze legacy transformations	Not started	Every accepted transformation is versioned and reproducible.
P10-4.2.b.3	Freeze legacy rejection rules	Not started	Every unsupported source value receives an explicit stable rejection reason.
P10-4.2.c	Produce pre-import counts, values and control totals.	Not started	The owner sees what will import, skip, merge and fail before anything changes.
P10-4.2.d.1.a	Migrate catalogue records into an empty target.	Not started	Products and identifiers equal approved source counts and values.
P10-4.2.d.1.b	Migrate price records into an empty target.	Not started	Prices and effective dates equal the approved source records.
P10-4.2.d.1.c	Migrate tax records into an empty target.	Not started	Tax categories, rules and effective dates equal the approved source records.
P10-4.2.d.2.a	Migrate inventory records into an empty target.	Not started	On-hand quantities, costs and lots equal approved source totals.
P10-4.2.d.2.b	Migrate receiving records into an empty target.	Not started	Receipts, shortages and open receiving exceptions equal approved source totals.
P10-4.2.d.2.c	Migrate purchasing records into an empty target.	Not started	Vendors, orders and open claims equal approved source totals.
P10-4.2.d.3.a	Migrate staff records into an empty target.	Not started	Authorized employees and assignments equal approved source records.
P10-4.2.d.3.b	Migrate schedule records into an empty target.	Not started	Published and future schedules equal approved source records.
P10-4.2.d.3.c	Migrate time records into an empty target.	Not started	Approved and open time items equal approved source records and totals.
P10-4.2.d.4.a	Migrate customer identities into an empty target.	Not started	Customer identities and consent records equal approved source records once.
P10-4.2.d.4.b	Migrate loyalty records into an empty target.	Not started	Loyalty activity and point balances equal approved source totals once.
P10-4.2.d.4.c	Migrate stored-value records into an empty target.	Not started	Gift-card and store-credit ledgers equal approved source totals once.
P10-4.2.d.5.a	Migrate cash opening balances into an empty target.	Not started	Approved till, safe and deposit opening balances reproduce exactly.
P10-4.2.d.5.b	Migrate finance opening balances into an empty target.	Not started	Approved bank, tax and payable opening balances reproduce exactly.
P10-4.2.d.5.c	Migrate remaining open items into an empty target.	Not started	Every supported outstanding item retains its amount, owner and source evidence.
P10-4.2.e	Repeat the identical import.	Not started	Repeating the migration creates zero duplicate record or value.
P10-4.2.f.1	Inject malformed import records.	Not started	Malformed records are rejected with source identity and readable reason.
P10-4.2.f.2	Inject incomplete source files and partial datasets.	Not started	Missing required content blocks activation and preserves a complete exception report.
P10-4.2.f.3	Interrupt and resume the import.	Not started	The interrupted import rolls back or resumes deterministically without duplicate value.
P10-4.2.g	Prove rollback to the pre-import checkpoint.	Not started	The store returns to the exact approved pre-import state without manual database editing.
P10-4.2.h	Accept migrated sample records and totals.	Owner validation required	The owner confirms representative records and signed control totals match the legacy source.
P10-4.3.a.1	Define cashier competency threshold.	Done & tested	Twelve observable grocery-checkout tasks cover identity, scanning, weight, totals, tender, receipt/return, offline operation, age authorization and recall stop-sale. The dynamic threshold is 11/12 plus every Mandatory task. Evidence.
P10-4.3.a.2	Define receiver competency threshold.	Done & tested	Eleven observable tasks cover purchase-order and unplanned delivery holds, units, traceability, temperature, document review, exact posting, recall and close. The threshold is 10/11 plus every Mandatory task. Evidence.
P10-4.3.a.3	Define manager competency threshold.	Done & tested	Eleven observable tasks cover authority, cash, payment, time, price, recall, finance, health, emergencies and staffing recovery without self-approval or duplicate notice. The threshold is 10/11 plus every Mandatory task. Evidence.
P10-4.3.a.4	Define owner competency threshold.	Done & tested	Ten observable tasks cover licence identity, business health, margin, cash outlook, close, plan change, access/privacy, recovery, risk and release decisions. The threshold is 9/10 plus every Mandatory task. Evidence.
P10-4.3.a.5	Define staff competency threshold.	Done & tested	Ten observable tasks cover identity/privacy, schedule, availability, punches, breaks, corrections, leave/swap/call-out, policies and offline replay. The threshold is 9/10 plus every Mandatory task. Evidence.
P10-4.3.a.6	Define installer competency threshold.	Done & tested	Eleven plain-language observable tasks cover identity, local network, claim, devices, simulators, backup/restore, update, support, runbooks and final owner handoff/old-box retirement. The threshold is 10/11 plus every Mandatory task. Evidence.
P10-4.3.b.1	Publish Cashier normal and recovery guide	Done & tested	Cashier normal and recovery guidance renders and prints. Open evidence.
P10-4.3.b.2	Publish Receiver normal and recovery guide	Done & tested	Receiver normal and recovery guidance renders and prints. Open evidence.
P10-4.3.b.3	Publish Manager normal and recovery guide	Done & tested	Manager normal and recovery guidance renders and prints. Open evidence.
P10-4.3.b.4	Publish Owner normal and recovery guide	Done & tested	Owner normal and recovery guidance renders and prints. Open evidence.
P10-4.3.b.5	Publish Staff normal and recovery guide	Done & tested	Staff normal and recovery guidance renders and prints. Open evidence.
P10-4.3.b.6	Publish Installer normal and recovery guide	Done & tested	Installer normal and recovery guidance renders and prints. Open evidence.
P10-4.3.b.7	Link Checkout to Cashier training	Done & tested	The link lands on Cashier training and Back returns to Checkout. Open evidence.
P10-4.3.b.8	Link Inventory to Receiver training	Done & tested	The link lands on Receiver training and Back returns to Inventory. Open evidence.
P10-4.3.b.9	Link Purchasing to Receiver training	Done & tested	The link lands on Receiver training and Back returns to Purchasing. Open evidence.
P10-4.3.b.10	Link Manager app to Manager training	Done & tested	The link lands on Manager training and Back returns to Manager. Open evidence.
P10-4.3.b.11	Link Owner app to Owner training	Done & tested	The link lands on Owner training and Back returns to Owner. Open evidence.
P10-4.3.b.12	Link Staff-Time to Staff training	Done & tested	The link lands on Staff training and Back returns to Staff-Time. Open evidence.
P10-4.3.b.13	Link Server Setup to Installer training	Done & tested	The link lands on Installer training and Back returns to Server Setup. Open evidence.
P10-4.3.c.1	Create isolated training storage	Not started	No training write can address a LIVE record identifier.
P10-4.3.c.2	Seed Cashier practice dataset	Not started	Cashier practice receives a complete and repeatable fixture set.
P10-4.3.c.3	Seed Receiver practice dataset	Not started	Receiver practice receives a complete and repeatable fixture set.
P10-4.3.c.4	Seed Manager practice dataset	Not started	Manager practice receives a complete and repeatable fixture set.
P10-4.3.c.5	Seed Owner practice dataset	Not started	Owner practice receives a complete and repeatable fixture set.
P10-4.3.c.6	Seed Staff practice dataset	Not started	Staff practice receives a complete and repeatable fixture set.
P10-4.3.c.7	Seed Installer practice dataset	Not started	Installer practice receives a complete and repeatable fixture set.
P10-4.3.c.8	Enter practice mode safely	Not started	Practice mode is unmistakable and uses only training storage.
P10-4.3.c.9	Reset and reseed practice data	Not started	Reset returns the exact fixture baseline without changing LIVE data.
P10-4.3.c.10	Block practice money effects	Not started	Practice leaves LIVE money control totals unchanged.
P10-4.3.c.11	Block practice stock effects	Not started	Practice leaves LIVE inventory control totals unchanged.
P10-4.3.c.12	Block practice staff effects	Not started	Practice leaves LIVE staff records and totals unchanged.
P10-4.3.c.13	Block practice licensing effects	Not started	Practice leaves LIVE licensing state unchanged.
P10-4.3.d.1	Run the cashier competency session.	Owner validation required	A representative cashier completes at least 90% of assigned critical tasks without developer coaching.
P10-4.3.d.2	Run the receiver competency session.	Owner validation required	A representative receiver completes at least 90% of assigned critical tasks without developer coaching.
P10-4.3.d.3	Run the manager competency session.	Owner validation required	A representative manager completes at least 90% of assigned critical tasks without developer coaching.
P10-4.3.e.1	Run the owner competency session.	Owner validation required	A representative owner completes decision, close and recovery tasks to the approved score.
P10-4.3.e.2	Run the installer competency session.	Owner validation required	A representative installer completes setup and recovery tasks to the approved score.
P10-4.3.e.3	Run the support competency session.	Owner validation required	A representative support user completes diagnostic and escalation tasks to the approved score.
P10-4.3.f.1	Remediate failed competency tasks	Not started	Each failed critical task receives a verified correction.
P10-4.3.f.2	Repeat competency assessment	Owner validation required	A representative user successfully re-demonstrates every corrected critical task.
P10-4.3.g	Sign role-training readiness.	Owner validation required	The accountable store and support owners approve who is ready for pilot authority.
P10-4.4.a.1	Publish plain-language support categories.	Verification pending	Installation, sync, payment, device, recovery, access and product tickets each have one clear primary category.
P10-4.4.a.2	Define Severity 1 and its 15-minute target.	Verification pending	A store-wide unsafe no-trade fixture receives the correct Severity 1 classification and human-response target.
P10-4.4.a.3	Define Severity 2 and its one-business-hour target.	Verification pending	A material impairment with a limited safe workaround receives the correct Severity 2 classification and target.
P10-4.4.a.4	Define Severity 3 and its next-business-day target.	Verification pending	A normal question, planned installation or safely bypassed peripheral issue receives Severity 3.
P10-4.4.a.5	Define a real first response.	Verification pending	The first response requires a person, the impact, a safe next action, an owner and the next update time; an automatic receipt does not count.
P10-4.4.a.6	Publish category escalation routes.	Verification pending	Every ticket category has a frontline owner, relevant specialist and clear engineering/vendor escalation point.
P10-4.4.b.1	Preview diagnostic-bundle contents.	Not started	The manager sees every included and excluded data class before collection or export.
P10-4.4.b.2	Record informed manager consent.	Not started	The bundle records who consented, when, for what ticket, scope and expiry.
P10-4.4.b.3	Remove unnecessary customer information.	Not started	Seeded customer names, contacts and purchase details do not appear unless explicitly required and approved.
P10-4.4.b.4	Remove unnecessary employee information.	Not started	Seeded HR, schedule and employee contact details do not appear in an ordinary technical bundle.
P10-4.4.b.5	Exclude payment details and every secret.	Not started	Seeded card numbers, authentication data, passwords, tokens, API keys and private keys never appear in preview or export.
P10-4.4.b.6	Export an audited diagnostic bundle.	Not started	The integrity-bound export carries the ticket reference, consent record, content list and accountable audit event.
P10-4.4.b.7	End or revoke support access.	Not started	Time-limited support access expires or is revoked independently of the exported bundle.
P10-4.4.c.1	Simulate an installation support ticket.	Verification pending	The fixture replaces an expired one-time claim without changing store identity or creating a duplicate store.
P10-4.4.c.2.1	Simulate a delayed sync queue.	Not started	Support recognizes a temporary retryable delay and preserves the queued events.
P10-4.4.c.2.2	Simulate a record conflict.	Not started	Support identifies concurrent business versions and sends them to authorized resolution.
P10-4.4.c.2.3	Simulate an invalid record placed aside for help.	Not started	Support recognizes a quarantined invalid event and never clears or silently retries it.
P10-4.4.c.2.4	Simulate reconciliation after a Store Box restore.	Verification pending	The fixture preserves all 17 queued events and CAD $412.38 while the supported restore-version reconciliation produces zero duplicates.
P10-4.4.c.3	Simulate an uncertain payment support ticket.	Verification pending	One processor inquiry adopts the CAD $86.42 approval once and produces one paid receipt with no retry authorization.
P10-4.4.c.4	Simulate an uncertain receipt-printer ticket.	Verification pending	The original job is not blindly resubmitted; one audited duplicate uses the same receipt ID on the alternate printer.
P10-4.4.c.5.1	Simulate a failed backup check.	Not started	Support refuses an unverified recovery point and records the failed verification evidence.
P10-4.4.c.5.2	Simulate a replacement Store Box restore.	Verification pending	Support selects the newest verified backup, retains STORE-014 and replays all 37 client events exactly once.
P10-4.4.d.1	Exercise Severity-1 escalation.	Owner validation required	Support, incident lead and engineering contain a representative store-wide incident within the published model.
P10-4.4.d.2	Exercise owner update messages.	Owner validation required	The owner receives the impact, safe action, named owner and promised next-update time throughout the drill.
P10-4.4.e.1	Verify the primary on-call contact.	Owner validation required	The published primary contact is staffed, reachable and owns the response interval.
P10-4.4.e.2	Verify the backup on-call contact.	Owner validation required	The backup contact is reachable when the primary does not respond.
P10-4.4.e.3	Verify contact handover through a release period.	Owner validation required	Every supported interval has one named accountable contact and a tested handover.
P10-4.4.f.1	Publish known support limitations.	Not started	Coverage hours, excluded hardware/providers, response limitations and owner responsibilities are visible before launch.
P10-4.4.f.2	Operations accepts support readiness.	Owner validation required	Operations signs the staffing, tools, escalation routes and known limitations.
P10-4.4.f.3	Pilot owner accepts support readiness.	Owner validation required	The pilot owner accepts the support model and limitations before live use.
P10-4.5.a.1	Freeze the barcode-scanner simulator profile.	Not started	The versioned scanner profile defines every supported command, response, timeout and failure fixture.
P10-4.5.a.2	Freeze the scale simulator profile.	Not started	The versioned scale profile defines every supported command, response, timeout and failure fixture.
P10-4.5.a.3	Freeze the receipt-printer simulator profile.	Not started	The versioned printer profile defines every supported command, response, timeout and failure fixture.
P10-4.5.a.4	Freeze the cash-drawer simulator profile.	Not started	The versioned drawer profile defines every supported command, response, timeout and failure fixture.
P10-4.5.b.1	Run barcode-scanner simulator matrix	Not started	Known, unknown, duplicate, malformed and disconnected scans produce deterministic safe results.
P10-4.5.b.2	Run barcode-scanner configuration preflight	Not started	Unsupported or missing scanner configuration blocks readiness.
P10-4.5.c.1	Run scale simulator matrix	Not started	Stable, unstable, negative, overweight, tare and disconnect cases cannot create false weight.
P10-4.5.c.2	Run scale configuration preflight	Not started	Unsupported or missing scale configuration blocks readiness.
P10-4.5.d.1	Run receipt-printer simulator matrix	Not started	Success, paper-out, jam, disconnect and uncertain dispatch preserve truthful job evidence.
P10-4.5.d.2	Run receipt-printer configuration preflight	Not started	A wrong, revoked or missing printer route blocks dispatch.
P10-4.5.e.1	Run cash-drawer simulator matrix	Not started	Authorized open, denied open, disconnect and duplicate command produce one auditable result.
P10-4.5.e.2	Run cash-drawer configuration preflight	Not started	A wrong, revoked or missing drawer route blocks opening.
P10-4.5.f	Run the combined simulated lane-hardware fault matrix.	Not started	Mixed device failures degrade safely without losing or duplicating a sale or custody effect.
P10-4.5.g	Validate an approved physical barcode scanner.	Owner validation required	The real scanner passes the supported barcode, disconnect and recovery matrix.
P10-4.5.h	Validate an approved physical scale.	Owner validation required	The real scale passes certified weight, tare, instability, disconnect and recovery checks.
P10-4.5.i	Validate an approved physical receipt printer.	Owner validation required	The real printer passes content, paper-out, jam, disconnect, spool and recovery checks.
P10-4.5.j	Validate an approved physical cash drawer.	Owner validation required	The real drawer opens only on the approved route and passes disconnect and recovery checks.
P10-4.6.a.1	Run payment-terminal purchase simulators.	Not started	Approval, decline, partial and unknown purchase fixtures converge without duplicate value.
P10-4.6.a.2.1	Run payment-terminal refund simulator	Not started	Refund fixtures converge without duplicate value.
P10-4.6.a.2.2	Run payment-terminal reversal simulator	Not started	Reversal fixtures converge without duplicate value.
P10-4.6.b	Run simulated processor-batch reconciliation preflight.	Not started	Matched, missing, duplicate, amount and status differences produce exact owned results.
P10-4.6.c.1	Validate real terminal purchase behaviour.	Owner validation required	The approved terminal/provider proves purchase finality and inquiry-before-retry behavior.
P10-4.6.c.2	Validate real terminal reversal behaviour.	Owner validation required	The approved terminal/provider proves reversal eligibility and finality semantics.
P10-4.6.c.3	Validate real terminal refund behaviour.	Owner validation required	The approved terminal/provider proves original-payment-linked refund finality.
P10-4.6.d	Validate real acquirer batch and settlement reconciliation.	Owner validation required	Real processor evidence matches POS effects or produces complete named exceptions.
P10-5.1.a.1	Verify scheduled backup creation	Not started	A complete source-identified backup is created within the RPO.
P10-5.1.a.2	Verify backup encryption	Not started	Plaintext or incorrect-key access to a backup is denied.
P10-5.1.b.1	Verify encrypted backup transfer.	Not started	Each completed backup reaches the approved off-box destination without plaintext exposure.
P10-5.1.b.2	Verify backup retention and expiry.	Not started	Required generations remain available and expired copies are removed according to policy.
P10-5.1.b.3	Verify backup integrity monitoring.	Not started	Missing, stale, truncated or corrupt copies create a visible actionable alert.
P10-5.1.c	Restore to an explicitly empty replacement root.	Not started	Restore refuses unsafe targets and recreates the expected store without outside files.
P10-5.1.d.1	Verify restore epoch	Not started	Stale client authority is rejected after replacement.
P10-5.1.d.2	Verify restored snapshots	Not started	Restored snapshots reproduce the backup checkpoint.
P10-5.1.d.3	Verify client reconciliation after restore	Not started	Retained client events replay exactly once after restore.
P10-5.1.e.1	Reconcile the sales ledger after restore.	Not started	Completed, open and corrected sale totals match the backup checkpoint exactly.
P10-5.1.e.2	Reconcile the tender ledger after restore.	Not started	Cash and card tender effects match the backup checkpoint without duplication.
P10-5.1.e.3	Reconcile cash custody after restore.	Not started	Till, safe, pickup and deposit balances match the backup checkpoint.
P10-5.1.e.4	Reconcile inventory after restore.	Not started	On-hand and movement totals match the backup checkpoint for every item.
P10-5.1.e.5	Reconcile workforce records after restore.	Not started	Staff, schedule and time totals match the authorized backup checkpoint.
P10-5.1.e.6	Reconcile finance records after restore.	Not started	Purchasing, bank, HST and open finance totals match the backup checkpoint.
P10-5.1.f.1.1	Measure RPO after Store Server process failure	Not started	Recovery after Store Server process failure meets RPO of fifteen minutes or less.
P10-5.1.f.1.2	Measure RTO after Store Server process failure	Not started	Recovery after Store Server process failure meets RTO of sixty minutes or less.
P10-5.1.f.2.1	Measure RPO after store-box disk failure	Not started	Recovery after store-box disk failure meets RPO of fifteen minutes or less.
P10-5.1.f.2.2	Measure RTO after store-box disk failure	Not started	Recovery after store-box disk failure meets RTO of sixty minutes or less.
P10-5.1.f.3.1	Measure RPO after complete store-box failure	Not started	Recovery after complete store-box failure meets RPO of fifteen minutes or less.
P10-5.1.f.3.2	Measure RTO after complete store-box failure	Not started	Recovery after complete store-box failure meets RTO of sixty minutes or less.
P10-5.1.g	Complete a release-candidate replacement-box drill.	Owner validation required	The owner/operations reviewer resumes store service with no missing or duplicate effect.
P10-5.2.a.1	Document the signing-key inventory.	Not started	Every active, standby and retired signing key has a unique purpose and fingerprint.
P10-5.2.a.2	Document signing-key custody.	Not started	Every signing key names its accountable owner, protected location and authorized custodians.
P10-5.2.a.3	Document signing-key rotation.	Not started	Every signing key has a versioned scheduled and emergency rotation procedure.
P10-5.2.a.4	Document signing-key compromise actions.	Not started	Every signing key states how compromise is contained, revoked, replaced and communicated.
P10-5.2.a.5	Document signing-key recovery roles.	Not started	Every recovery action names the required custodians, approval separation and client-recovery responsibility.
P10-5.2.b	Simulate signing-key rotation and overlap.	Not started	Supported clients accept the new key while valid old material remains usable only in its window.
P10-5.2.c	Simulate compromised-key revocation and unaffected-store continuity.	Not started	Compromised material is refused without disabling valid unrelated stores.
P10-5.2.d	Exercise cached-license and License Cloud outage recovery.	Not started	Store-critical work continues under the documented lease/grace policy.
P10-5.2.e.1	Exercise billing-provider outage	Not started	Provider outage never interrupts an active sale.
P10-5.2.e.2	Exercise billing-event replay	Not started	Duplicate or delayed billing events change commercial state at most once.
P10-5.2.e.3	Exercise billing-provider recovery	Not started	Recovered provider state converges to the correct commercial state.
P10-5.2.f.1	Restore the License Cloud database	Not started	Restored licensing state is complete and monotonic.
P10-5.2.f.2	Verify signing continuity after cloud restore	Not started	Only valid, owner-visible leases are issued after restore.
P10-5.2.g.1	Complete real signing-key custody exercise	Owner validation required	Authorized custodians recover key operations without exposing production secrets.
P10-5.2.g.2	Complete real billing-vendor custody exercise	Owner validation required	Authorized provider custodians recover service without exposing production secrets.
P10-5.3.a.1	Download the exact trusted staged update.	Not started	The appliance obtains the expected update identity only from the authorized channel.
P10-5.3.a.2	Verify the staged-update package.	Not started	The downloaded digest, signature, signer and manifest all match the approved update.
P10-5.3.a.3	Verify staged-update build provenance.	Not started	The accepted artifact links to the exact approved source commit, build inputs and reproducible release evidence.
P10-5.3.b.1	Reject an altered update package.	Not started	Checksum or payload alteration is refused before migration or activation.
P10-5.3.b.2	Reject an unsigned or wrong-key update package.	Not started	Missing or untrusted signatures are refused before any store data change.
P10-5.3.b.3	Reject a stale update package.	Not started	Superseded or replayed update identities cannot replace a newer trusted release.
P10-5.3.b.4	Reject an incompatible update package.	Not started	Unsupported server, client, schema or platform combinations fail before activation.
P10-5.3.c.1	Require a current verified pre-update backup.	Not started	Update cannot begin until the required backup exists and passes integrity checks.
P10-5.3.c.2	Require adequate pre-update disk capacity.	Not started	Update cannot begin without space for staging, migration and safe recovery.
P10-5.3.c.3	Require compatible pre-update database schemas.	Not started	Unknown, altered or unsupported schema history blocks migration.
P10-5.3.c.4.1	Check connected-client update compatibility	Not started	An incompatible connected client blocks or safely stages the update.
P10-5.3.c.4.2	Check offline-client update compatibility	Not started	An incompatible retained offline client blocks or safely stages the update.
P10-5.3.d.1	Interrupt and recover update download.	Not started	A partial download resumes or restarts without becoming installable.
P10-5.3.d.2	Interrupt and recover update installation.	Not started	An install interruption retains the prior runnable candidate or resumes safely.
P10-5.3.d.3	Interrupt and recover database migration.	Not started	A migration interruption resumes or fails closed without partial committed schema state.
P10-5.3.d.4	Interrupt and recover post-update restart.	Not started	Restart interruption preserves committed data and reaches one truthful active version.
P10-5.3.e	Block incompatible rollback after forward-only data change.	Not started	The system refuses a downgrade that cannot read the current database.
P10-5.3.f	Apply and verify the documented forward fix.	Not started	The replacement build restores service and preserves the migrated data exactly.
P10-5.3.g	Complete staged canary-to-store rollout simulation.	Not started	Promotion stops automatically when health, compatibility or control totals fail.
P10-5.4.a	Build a reproducible signed emergency hotfix.	Not started	The hotfix identifies source commit, tests, SBOM, signer and affected versions.
P10-5.4.b	Exercise emergency approval and restricted release path.	Not started	Only authorized roles can promote the hotfix and every exception is audited.
P10-5.4.c.1	Verify emergency hotfix installation.	Not started	The authorized hotfix installs only on affected compatible versions.
P10-5.4.c.2	Verify the documented hotfix rollback or forward-fix path.	Not started	Recovery resolves the defect without losing or rewriting committed store data.
P10-5.4.c.3	Verify hotfix traceability and evidence updates.	Not started	Requirements, tests, SBOM, signatures and affected release records point to the hotfix.
P10-5.4.d.1	Prepare owner-visible incident notice	Not started	The notice plainly states impact, workaround, data status and support contact.
P10-5.4.d.2	Prepare incident-update cadence	Not started	Next-update time, channel and accountable owner are explicit.
P10-5.4.e	Prove owner data export during service degradation.	Not started	The owner can retrieve readable store-owned records without unsafe direct database access.
P10-5.4.f.1	Run severity-one hotfix exercise	Owner validation required	The technical hotfix promotion and recovery path is accepted.
P10-5.4.f.2	Run severity-one communication exercise	Owner validation required	Owner-facing incident messages and timing are accepted.
P10-5.4.g.1	Publish post-incident review	Not started	The review records cause, timeline and control gaps.
P10-5.4.g.2	Track post-incident corrective actions	Not started	Every corrective action has owner, due date, status and evidence.
P10-5.5.a.1	Run macOS signature rejection preflight	Not started	Unsigned, altered or wrong-identity artifacts are rejected.
P10-5.5.a.2	Run Gatekeeper and quarantine preflight	Not started	Quarantined or untrusted launch is rejected predictably.
P10-5.5.b.1	Inventory every distributed macOS executable.	Not started	The manifest lists every server helper, Flutter app, installer, updater and nested executable.
P10-5.5.b.2	Assign each macOS signing identity.	Not started	Every distributed executable has exactly one approved signer identity.
P10-5.5.b.3	Assign each macOS entitlement set.	Not started	Every executable has the minimum approved entitlements required for its role.
P10-5.5.b.4	Assign notarization and stapling requirements.	Not started	Every distributable package states its notarization, stapling and offline Gatekeeper-verification requirement.
P10-5.5.c.1	Verify macOS update preflight	Not started	Compatibility, signature and schema checks pass before activation.
P10-5.5.c.2	Verify rollback-safe macOS launch	Not started	Unsafe downgrade or launch is blocked.
P10-5.5.d.1	Verify credentials stay out of source.	Not started	Test signing and notarization credentials do not appear in tracked or packaged source files.
P10-5.5.d.2	Verify credentials stay out of logs.	Not started	Test signing and notarization credentials do not appear in build, application or support logs.
P10-5.5.d.3	Verify credentials stay out of artifacts.	Not started	Test signing and notarization credentials do not appear in installers, applications, manifests or debug artifacts.
P10-5.5.d.4	Verify credentials stay out of store backups.	Not started	Test signing and notarization credentials do not appear in appliance or store-data backups.
P10-5.5.d.5	Verify the approved credential store.	Not started	Test credentials are accessible only through the approved custodian-controlled secret boundary.
P10-5.5.e	Sign every release-candidate macOS artifact with production identity.	Owner validation required	Authorized custodians sign the exact frozen artifacts without exposing production credentials.
P10-5.5.f.1	Notarize every distributed macOS artifact	Owner validation required	Apple notarization succeeds for every frozen artifact.
P10-5.5.f.2	Staple and offline-verify every notarization ticket	Owner validation required	Each stapled ticket verifies offline.
P10-5.5.g.1	Validate Gatekeeper installation on a clean Mac.	Owner validation required	A clean supported Mac installs only the notarized release.
P10-5.5.g.2	Validate first launch on a clean Mac.	Owner validation required	Gatekeeper permits first launch only for the correctly signed and notarized release.
P10-5.5.g.3	Validate a Gatekeeper-protected update.	Owner validation required	A clean supported Mac accepts only the authorized notarized update.
P10-5.5.h.1	Validate production signing-key custody.	Owner validation required	Named custodians prove controlled signing-key access without revealing key material.
P10-5.5.h.2	Validate notarization-credential custody.	Owner validation required	Named custodians prove controlled notarization access without revealing credentials.
P10-5.5.h.3	Validate production credential rotation.	Owner validation required	Named custodians rotate the selected credential while preserving authorized release continuity.
P10-5.5.h.4	Validate production credential revocation.	Owner validation required	Named custodians revoke compromised signing or notarization access as documented.
P10-5.5.h.5	Validate production credential recovery.	Owner validation required	Named custodians restore authorized release capability without exposing key material.
P10-6.1.a	Complete release-pilot dependency and evidence entry audit.	Not started	The checklist shows every prerequisite passed or explicitly blocks pilot start.
P10-6.1.b.1	Freeze and sign the pilot Store Box build.	Not started	The exact Store Box artifact has an immutable digest, signature and source identity.
P10-6.1.b.2	Freeze and sign the pilot License Cloud build.	Not started	The exact License Cloud artifact has an immutable digest, signature and source identity.
P10-6.1.b.3	Freeze and sign the pilot client builds.	Not started	Each exact Flutter client artifact has an immutable digest, application identity and source identity.
P10-6.1.b.4	Freeze the pilot schema versions.	Not started	Every client, Store Box and License Cloud SQLite schema has one immutable migration identity.
P10-6.1.b.5	Freeze the pilot test fixtures.	Not started	Every pilot seed, simulator and expected-control fixture has an immutable version and digest.
P10-6.1.b.6	Freeze the pilot configuration.	Not started	Every non-secret pilot policy and setting has an immutable approved manifest identity.
P10-6.1.b.7	Freeze the pilot hardware profile.	Not started	Every approved lane, printer, scanner, scale, drawer and terminal model/firmware combination is versioned.
P10-6.1.b.8	Sign the complete pilot manifest.	Not started	One approved signature binds the same source, artifacts, schemas, fixtures, configuration and hardware profile.
P10-6.1.c	Approve store, lanes, tenders, users and authority cutover matrix.	Owner validation required	The pilot owner signs exactly what Kuberan controls and when legacy authority ends.
P10-6.1.d.1	Verify opening backup readiness	Owner validation required	A current restorable backup is accepted before opening.
P10-6.1.d.2	Verify opening rollback readiness	Owner validation required	The rollback path and authority are accepted before opening.
P10-6.1.d.3	Verify opening support coverage	Owner validation required	Primary and backup support are reachable before opening.
P10-6.1.d.4	Verify severity-one contacts	Owner validation required	Every severity-one contact and escalation path works before opening.
P10-6.1.e.1	Accept Day-one users	Owner validation required	Assigned users are ready before trade.
P10-6.1.e.2	Accept Day-one tills	Owner validation required	Assigned tills are ready before trade.
P10-6.1.e.3	Accept Day-one devices	Owner validation required	Assigned devices are ready before trade.
P10-6.1.e.4	Accept Day-one prices	Owner validation required	Published prices are ready before trade.
P10-6.1.e.5	Accept Day-one tenders	Owner validation required	Enabled tenders are ready before trade.
P10-6.1.e.6	Accept Day-one stock	Owner validation required	Opening stock is accepted before trade.
P10-6.1.e.7	Accept Day-one health checks	Owner validation required	All required health checks pass before trade.
P10-6.1.f.1	Reconcile Day-one sales	Owner validation required	Day-one sales have no unexplained variance.
P10-6.1.f.2	Reconcile Day-one tenders	Owner validation required	Day-one tenders have no unexplained variance.
P10-6.1.f.3	Reconcile Day-one cash	Owner validation required	Day-one cash has no unexplained variance.
P10-6.1.f.4	Reconcile Day-one stock	Owner validation required	Day-one stock has no unexplained variance.
P10-6.1.f.5	Reconcile Day-one exceptions	Owner validation required	Every Day-one exception has an accepted disposition.
P10-6.2.day-01	Complete and accept release-pilot Day 1.	Owner validation required	Day 1 opens, trades, closes and reconciles on the unchanged candidate with no unexplained variance.
P10-6.2.day-02	Complete and accept release-pilot Day 2.	Owner validation required	Day 2 opens, trades, closes and reconciles on the unchanged candidate with no unexplained variance.
P10-6.2.day-03	Complete and accept release-pilot Day 3.	Owner validation required	Day 3 opens, trades, closes and reconciles on the unchanged candidate with no unexplained variance.
P10-6.2.day-04	Complete and accept release-pilot Day 4.	Owner validation required	Day 4 opens, trades, closes and reconciles on the unchanged candidate with no unexplained variance.
P10-6.2.day-05	Complete and accept release-pilot Day 5.	Owner validation required	Day 5 opens, trades, closes and reconciles on the unchanged candidate with no unexplained variance.
P10-6.2.day-06	Complete and accept release-pilot Day 6.	Owner validation required	Day 6 opens, trades, closes and reconciles on the unchanged candidate with no unexplained variance.
P10-6.2.day-07	Complete and accept release-pilot Day 7.	Owner validation required	Day 7 opens, trades, closes and reconciles on the unchanged candidate with no unexplained variance.
P10-6.2.c	Maintain daily incident, support and workaround logs for Days 1–7.	Owner validation required	Every user-impacting event has time, owner, impact, action and resolution status.
P10-6.2.d	Decide every material-change clock impact for Days 1–7.	Owner validation required	Any material ledger, sync, payment, security or schema change explicitly restarts the clock.
P10-6.2.e	Sign the Day-7 interval gate.	Owner validation required	Pilot owner and Operations accept reconciliation, incidents and candidate continuity through Day 7.
P10-6.3.day-08	Complete and accept release-pilot Day 8.	Owner validation required	Day 8 opens, trades, closes and reconciles on the unchanged candidate with accepted support coverage.
P10-6.3.day-09	Complete and accept release-pilot Day 9.	Owner validation required	Day 9 opens, trades, closes and reconciles on the unchanged candidate with accepted support coverage.
P10-6.3.day-10	Complete and accept release-pilot Day 10.	Owner validation required	Day 10 opens, trades, closes and reconciles on the unchanged candidate with accepted support coverage.
P10-6.3.day-11	Complete and accept release-pilot Day 11.	Owner validation required	Day 11 opens, trades, closes and reconciles on the unchanged candidate with accepted support coverage.
P10-6.3.day-12	Complete and accept release-pilot Day 12.	Owner validation required	Day 12 opens, trades, closes and reconciles on the unchanged candidate with accepted support coverage.
P10-6.3.day-13	Complete and accept release-pilot Day 13.	Owner validation required	Day 13 opens, trades, closes and reconciles on the unchanged candidate with accepted support coverage.
P10-6.3.day-14	Complete and accept release-pilot Day 14.	Owner validation required	Day 14 opens, trades, closes and reconciles on the unchanged candidate with accepted support coverage.
P10-6.3.c.1	Review Days eight-to-fourteen performance	Owner validation required	Every degraded performance interval is measured and dispositioned.
P10-6.3.c.2	Review Days eight-to-fourteen offline intervals	Owner validation required	Every offline interval is measured and dispositioned.
P10-6.3.c.3	Review Days eight-to-fourteen recovery events	Owner validation required	Every recovery event is measured and dispositioned.
P10-6.3.d.1	Reconcile weekly commercial totals	Owner validation required	Commercial totals agree with owner-visible calculations.
P10-6.3.d.2	Reconcile weekly licensing totals	Owner validation required	Licensing totals agree with owner-visible calculations.
P10-6.3.d.3	Reconcile weekly store-activity totals	Owner validation required	Store-activity totals agree with owner-visible calculations.
P10-6.3.e	Sign the Day-14 interval gate.	Owner validation required	Pilot owner and Operations accept the first two weeks without hidden variance.
P10-6.4.day-15	Complete and accept release-pilot Day 15.	Owner validation required	Day 15 opens, trades, closes and reconciles on the unchanged candidate.
P10-6.4.day-16	Complete and accept release-pilot Day 16.	Owner validation required	Day 16 opens, trades, closes and reconciles on the unchanged candidate.
P10-6.4.day-17	Complete and accept release-pilot Day 17.	Owner validation required	Day 17 opens, trades, closes and reconciles on the unchanged candidate.
P10-6.4.day-18	Complete and accept release-pilot Day 18.	Owner validation required	Day 18 opens, trades, closes and reconciles on the unchanged candidate.
P10-6.4.day-19	Complete and accept release-pilot Day 19.	Owner validation required	Day 19 opens, trades, closes and reconciles on the unchanged candidate.
P10-6.4.day-20	Complete and accept release-pilot Day 20.	Owner validation required	Day 20 opens, trades, closes and reconciles on the unchanged candidate.
P10-6.4.day-21	Complete and accept release-pilot Day 21.	Owner validation required	Day 21 opens, trades, closes and reconciles on the unchanged candidate.
P10-6.4.c	Exercise an approved continuity scenario during Days 15–21.	Owner validation required	Staff follow the runbook and recover without duplicate effects or unsafe bypass.
P10-6.4.d	Review support workload and staffing sustainability.	Owner validation required	Primary and backup coverage meets the published support model for the interval.
P10-6.4.e	Sign the Day-21 interval gate.	Owner validation required	Pilot owner and Operations accept reconciliation, continuity and support through Day 21.
P10-6.5.day-22	Complete and accept release-pilot Day 22.	Owner validation required	Day 22 opens, trades, closes and reconciles with accepted material-ledger totals.
P10-6.5.day-23	Complete and accept release-pilot Day 23.	Owner validation required	Day 23 opens, trades, closes and reconciles with accepted material-ledger totals.
P10-6.5.day-24	Complete and accept release-pilot Day 24.	Owner validation required	Day 24 opens, trades, closes and reconciles with accepted material-ledger totals.
P10-6.5.day-25	Complete and accept release-pilot Day 25.	Owner validation required	Day 25 opens, trades, closes and reconciles with accepted material-ledger totals.
P10-6.5.day-26	Complete and accept release-pilot Day 26.	Owner validation required	Day 26 opens, trades, closes and reconciles with accepted material-ledger totals.
P10-6.5.day-27	Complete and accept release-pilot Day 27.	Owner validation required	Day 27 opens, trades, closes and reconciles with accepted material-ledger totals.
P10-6.5.day-28	Complete and accept release-pilot Day 28.	Owner validation required	Day 28 opens, trades, closes and reconciles with accepted material-ledger totals.
P10-6.5.day-29	Complete and accept release-pilot Day 29.	Owner validation required	Day 29 opens, trades, closes and reconciles with accepted material-ledger totals.
P10-6.5.day-30	Complete and accept release-pilot Day 30.	Owner validation required	Day 30 closes and reconciles, completing thirty consecutive accepted days.
P10-6.5.d	Complete a live backup/restore verification.	Owner validation required	A current backup restores within objective and reconciles without changing store authority unexpectedly.
P10-6.5.e.1	Complete required daily closes	Owner validation required	Every required daily ledger reconciles or has an accepted exception.
P10-6.5.e.2	Complete required weekly closes	Owner validation required	Every required weekly ledger reconciles or has an accepted exception.
P10-6.5.e.3	Complete applicable month-end close	Owner validation required	Every required month-end ledger reconciles or has an accepted exception.
P10-6.5.f	Confirm no material change invalidated the clock.	Owner validation required	The change log proves the full accepted interval used one eligible release candidate.
P10-6.5.g	Sign the Day-30 interval gate.	Owner validation required	Pilot owner, Operations and QA accept the full elapsed interval.
P10-6.6.a.1	Freeze final pilot dataset	Owner validation required	The final pilot dataset is immutable and traceable to each day.
P10-6.6.a.2	Freeze final pilot incident register	Owner validation required	The incident register is immutable and traceable to each day.
P10-6.6.a.3	Freeze final pilot support metrics	Owner validation required	Support metrics are immutable and traceable to each day.
P10-6.6.b.1	Summarize pilot availability.	Owner validation required	Published availability reproduces daily evidence and discloses every excluded interval.
P10-6.6.b.2	Summarize pilot performance.	Owner validation required	Published latency and capacity results reproduce the accepted pilot measurements.
P10-6.6.b.3	Summarize pilot reconciliations.	Owner validation required	Published reconciliation totals reproduce the accepted daily and period evidence.
P10-6.6.b.4	Summarize pilot recovery results.	Owner validation required	Published recovery results reproduce each accepted incident and restore exercise.
P10-6.6.c.1	Disposition every pilot defect	Owner validation required	Each defect has severity, owner, release decision and remaining risk.
P10-6.6.c.2	Disposition every pilot variance	Owner validation required	Each variance has severity, owner, release decision and remaining risk.
P10-6.6.c.3	Disposition every pilot workaround	Owner validation required	Each workaround has severity, owner, release decision and remaining risk.
P10-6.6.d	Publish the material-change and clock-restart history.	Owner validation required	Every candidate change shows whether and why the 30-day clock restarted.
P10-6.6.e	Obtain store-owner pilot acceptance.	Owner validation required	The pilot owner signs the results, limitations and production-readiness position.
P10-6.6.f.1	Obtain Operations pilot-exit approval	Owner validation required	Operations signs that pilot evidence may enter the GA decision.
P10-6.6.f.2	Obtain Product pilot-exit approval	Owner validation required	Product signs that pilot evidence may enter the GA decision.
P10-7.1.a.1	Freeze the V1.0 version	Not started	The release version identifies one immutable candidate.
P10-7.1.a.2	Freeze the V1.0 source commit	Not started	Every deployable resolves to the frozen source commit.
P10-7.1.a.3	Freeze the V1.0 release manifest	Not started	Every deployable and schema appears once in the immutable manifest.
P10-7.1.b.1	Build the Store Server from frozen source.	Not started	A clean build produces the exact required Store Server artifact without hidden state.
P10-7.1.b.2	Build the License Cloud from frozen source.	Not started	A clean build produces the exact required License Cloud artifact without hidden state.
P10-7.1.b.3	Build Kuberan Register from frozen source.	Not started	A clean build produces the uniquely identified Register artifact.
P10-7.1.b.4	Build Kuberan Store Operations from frozen source.	Not started	A clean build produces the uniquely identified Store Operations artifact.
P10-7.1.b.5	Build Kuberan Manager from frozen source.	Not started	A clean build produces the uniquely identified Manager artifact.
P10-7.1.b.6	Build Kuberan Staff from frozen source.	Not started	A clean build produces the uniquely identified Staff artifact.
P10-7.1.b.7	Build Kuberan Owner from frozen source.	Not started	A clean build produces the uniquely identified Owner artifact.
P10-7.1.b.8	Build Kuberan Setup & Support from frozen source.	Not started	A clean build produces the uniquely identified Setup & Support artifact.
P10-7.1.b.9	Build Kuberan Account & Licensing from frozen source.	Not started	A clean build produces the uniquely identified Account & Licensing artifact.
P10-7.1.b.10	Build Kuberan License Manager from frozen source.	Not started	A clean build produces the uniquely identified License Manager artifact.
P10-7.1.c.1	Publish release artifact hashes.	Not started	Every downloadable artifact has the exact audited checksum.
P10-7.1.c.2	Publish release artifact signatures.	Not started	Every downloadable artifact has its exact approved signature and signer identity.
P10-7.1.c.3	Publish release provenance.	Not started	Every downloadable artifact resolves to its audited source and build evidence.
P10-7.1.c.4	Publish stable download identities.	Not started	Each public download name resolves to one exact approved artifact.
P10-7.1.d.1	Freeze the API compatibility window.	Not started	Supported API versions are explicit and unsupported clients fail before mutation.
P10-7.1.d.2	Freeze the event compatibility window.	Not started	Supported event versions are explicit and incompatible events fail before application.
P10-7.1.d.3	Freeze the database compatibility window.	Not started	Supported database versions and migrations are explicit before activation.
P10-7.1.d.4	Freeze the licence-lease compatibility window.	Not started	Supported lease versions are explicit and incompatible leases fail closed.
P10-7.1.d.5	Freeze the update compatibility window.	Not started	Supported update paths are explicit and unsafe combinations fail before activation.
P10-7.1.e.1	Publish the supported-platform policy.	Not started	Owners can see every supported operating system and hardware baseline.
P10-7.1.e.2	Publish the upgrade policy.	Not started	Owners can see supported upgrade paths, prerequisites and known exclusions.
P10-7.1.e.3	Publish the data-retention policy.	Not started	Owners can see supported retention periods and accountable exceptions.
P10-7.1.e.4	Publish the release-support policy.	Not started	Owners can see the support duration, channels and known exclusions.
P10-7.1.f	Verify Stable-channel content without enabling it.	Not started	The staged channel contains only the frozen audited candidate.
P10-7.2.a.1	Validate machine-readable release evidence	Not started	Every mandatory phase resolves to passing immutable evidence.
P10-7.2.a.2	Validate requirement-and-phase trace matrix	Not started	Every mandatory requirement and phase has a complete passing trace.
P10-7.2.b.1	Verify release SBOM completeness and identity.	Not started	Every frozen release artifact resolves to its exact complete component inventory.
P10-7.2.b.2	Verify vulnerability disposition for the exact release.	Not started	No critical vulnerability or unaccepted release blocker remains.
P10-7.2.b.3.1	Verify exact-release signatures	Not started	Every distributed artifact matches its audited signer.
P10-7.2.b.3.2	Verify exact-release provenance	Not started	Every distributed artifact matches its audited source and build evidence.
P10-7.2.c.1	Verify every database migration from a fresh install.	Not started	A clean database reaches the exact published schema and seed state.
P10-7.2.c.2	Verify every supported database upgrade path.	Not started	Each supported prior version upgrades with preserved data and exact control totals.
P10-7.2.c.3	Verify unsupported database downgrade rejection.	Not started	An incompatible downgrade is refused before changing the current database.
P10-7.2.d	Reproduce the release from a clean independent environment.	Owner validation required	An independent reviewer rebuilds matching artifacts from the frozen source and instructions.
P10-7.2.e.1	Independently audit release-pilot evidence.	Owner validation required	The audit reproduces all accepted pilot days, totals, incidents and clock decisions.
P10-7.2.e.2	Independently audit support-readiness evidence.	Owner validation required	The audit confirms staffing, escalation, diagnostics and known limitations.
P10-7.2.e.3	Independently audit security evidence.	Owner validation required	The audit finds no hidden critical or high security release blocker.
P10-7.2.e.4	Independently audit privacy evidence.	Owner validation required	The audit confirms the approved data inventory, rights workflows, retention and denials.
P10-7.2.e.5	Independently audit accessibility evidence.	Owner validation required	The audit confirms supported critical journeys and accepted residual limitations.
P10-7.2.e.6	Independently audit continuity evidence.	Owner validation required	The audit reproduces backup, restore, replacement, update and incident recovery claims.
P10-7.2.f.1	Resolve independent release-audit findings.	Not started	Each release-blocking finding has a verified correction and updated evidence.
P10-7.2.f.2	Obtain independent release-audit acceptance.	Owner validation required	The reviewer signs the final package with no open critical or P1 blocker.
P10-7.3.a.1	Freeze supported rollback position	Not started	Every component states when rollback is safe.
P10-7.3.a.2	Freeze supported forward-fix position	Not started	Every component states when only forward repair is allowed.
P10-7.3.b	Product Owner go/no-go decision.	Owner validation required	Product accepts scope, known limitations, pilot result and customer impact.
P10-7.3.c	Engineering go/no-go decision.	Owner validation required	Engineering accepts build integrity, migrations, operability and remaining technical risk.
P10-7.3.d	QA go/no-go decision.	Owner validation required	QA accepts regression, defect, traceability and evidence completeness.
P10-7.3.e.1	Security go/no-go decision.	Owner validation required	The accountable security reviewer accepts the assessment and residual security risk.
P10-7.3.e.2	Privacy go/no-go decision.	Owner validation required	The accountable privacy reviewer accepts the procedures and residual privacy risk.
P10-7.3.e.3	Accessibility go/no-go decision.	Owner validation required	The accountable accessibility reviewer accepts supported journeys and limitations.
P10-7.3.f.1	Operations go/no-go decision.	Owner validation required	Operations accepts monitoring, recovery, updates and incident readiness.
P10-7.3.f.2	Support go/no-go decision.	Owner validation required	Support accepts staffing, escalation, diagnostics and owner communication readiness.
P10-7.3.g	Pilot-owner go/no-go decision.	Owner validation required	The pilot owner accepts real-store results and published operating limitations.
P10-7.3.h	Record the consolidated GA decision.	Owner validation required	Every required role signs the same candidate, evidence set and release decision.
P10-7.4.a	Run the final automated GA gate over the frozen release.	Not started	The gate reports every mandatory item passed and detects any changed artifact or evidence.
P10-7.4.b.1	Confirm zero unresolved severity-one defects	Owner validation required	The release chair accepts that no severity-one defect remains unresolved.
P10-7.4.b.2	Confirm zero unaccepted P0 or P1 blockers	Owner validation required	The release chair accepts that no P0 or P1 blocker remains unaccepted.
P10-7.4.c	Authorize Stable-channel publication.	Owner validation required	Product and Operations explicitly authorize only the signed frozen candidate.
P10-7.4.d.1	Publish the approved V1.0 packages.	Owner validation required	The public channel exposes only the exact signed and approved release artifacts.
P10-7.4.d.2	Publish the V1.0 release notes and known limitations.	Owner validation required	The notes identify the same release and disclose every accepted material limitation.
P10-7.4.d.3.1	Publish owner installation guidance.	Owner validation required	The installation guide identifies the approved build and supported fresh-install path.
P10-7.4.d.3.2	Publish owner upgrade guidance.	Owner validation required	The upgrade guide identifies the approved build and each supported prior version.
P10-7.4.d.3.3	Publish owner support guidance.	Owner validation required	The support guide identifies the release, help contacts and escalation path.
P10-7.4.e.1	Verify post-publication downloads.	Owner validation required	Each fresh download exactly matches the approved release identity and expected file.
P10-7.4.e.2.1	Verify post-publication artifact signatures	Owner validation required	Fresh downloads verify under the published signer.
P10-7.4.e.2.2	Verify post-publication notarization	Owner validation required	Fresh downloads verify under the published platform trust chain.
P10-7.4.e.3.1	Verify a post-publication fresh installation.	Owner validation required	A fresh install from the public channel reaches the exact authorized version.
P10-7.4.e.3.2	Verify post-publication release health.	Owner validation required	Every required health check passes on the freshly installed public release.
P10-7.4.f.1	Close the GA decision record.	Owner validation required	The signed decision and exact evidence snapshot are permanently recorded.
P10-7.4.f.2	Start supported-release monitoring.	Owner validation required	The monitoring owner and support window are active for the published release.

Autonomous execution boundary: coding, SQLite schemas, simulators, automated tests, macOS builds, HTML documentation/evidence and headless integration may proceed autonomously. Physical payment/hardware certification, accountant/legal acceptance, representative usability sessions, real-store pilots and elapsed 30-day gates remain explicitly external and cannot be self-certified by development agents.

21.7 Dependency and parallel-execution map

Wave	May execute concurrently	Must wait	Integration checkpoint
W1 • V0.1	P01-2 architecture and P01-3 usability after P01-1 vocabulary freeze	P01-4 waits for both reviews	Approved SRS/backlog and V0.2 entry decision
W2 • V0.2	P02-2 SQLite, P02-3 sync, P02-4 licensing security and P02-5 adapters after P02-1	P02-6 waits for all technical proofs	Boot/claim/commit/sync/update/restore appliance scenario
W3 • V0.5 build	P05-2 trade, P05-5 stock, P05-6 licensing and P05-7 appliance scaffolding after P05-1	P05-3/4 need sale contracts; P05-8 waits for P05-1–7	Limited-lane opening-to-close and stock reconciliation
W4 • V0.8 build	P08-1 through P08-6 domain lanes	P08-7 needs stable read contracts; P08-8 needs all domains	Whole-business-cycle pilot rehearsal
W5 • V1 certification	P10-1 through P10-5 certification streams	P10-6 waits for all sign-offs; P10-7 waits for pilot	Signed release-candidate and final GA evidence audit

21.8 Rules for future multi-agent implementation

Safe delegation

Delegate a bounded phase or module with explicit SRS IDs, files, contracts and acceptance commands.
Assign a separate verification agent for invariant, negative, offline and recovery tests.
Freeze contract/schema versions for each parallel wave; proposed changes go through the integration owner.
Require every agent to preserve unrelated work and report migrations, public contracts and remaining risks.
Merge only green, reviewable increments; do not combine several unverified phase branches into one test event.

Work that is deliberately serialized

SQLite migration numbering and destructive/irreversible migration approval.
Canonical money, quantity, tax, business-date and identifier semantics.
Payment-attempt transition rules and receipt finalization.
License signing-key operations and entitlement/lease schema changes.
Stable release promotion, production data migration and go-live command.
Any change that can prevent trading, alter completed ledgers or weaken audit evidence.

21.9 Phase start and completion checklist

Ready to start

Product Owner approves phase scope and exclusions.
Referenced requirements and acceptance examples are unambiguous.
Dependencies/contracts/test fixtures and environment are available.
Implementation owner, verification owner and integration owner are named.
Security/privacy, hardware/provider and migration risks are identified.
Rollback or safe abandonment path is documented.

Ready to close

Deliverable runs from a reproducible build with no hidden manual state.
Positive, negative, permission, offline, retry and recovery tests pass as applicable.
SQLite integrity, migrations, resource growth and backup impact are checked.
Plain-language UI/error/help and observability are demonstrated.
SRS traceability, support/runbook and release evidence are current.
Independent verifier and accountable business role accept the phase.

Independent plan review incorporated

Technical Product Manager review: strengthened executable fault evidence, SQLite-only representative testing, eight-artifact interpretation, contract ownership, no AI scope leakage before V1.1, continuity proof and certification sequencing.

Business Owner review: added trial/authority states, coexistence and rollback controls, golden store fixtures, minimum recall/emergency/deposit/vendor-claim protection before live lanes, shadow-first adoption and restart of the GA stability clock after material changes.

Current execution decision: P02-1 through P02-6, the complete P05-1 parent, P05-2.1 through P05-2.5a and P05-3.1–P05-3.5 are done, evidenced and independently tested. Within active P05-2.5b, R2.2 exact replay/current-denial is accepted and R2.3 tamper/restart is now the dependency-safe unit. The sequence then continues through the remaining controlled-return gates → P05-3.6 capture/refund/reversal/reconciliation → P05-2.6 combined Store API/Register gate. The P05-2/P05-3 owner-level capabilities remain unchecked until their complete evidence gates pass. Real terminal/provider finality, accountant rounding, PCI/receipt, hardware and cashier-usability validations remain parked Owner gates and do not stop dependency-safe engineering.