Docs: establish consumer requirements tracking

docs/BACKLOG.md

@@ -1,6 +1,6 @@
 ---
 status: Active
-updated: 2026-10-18
+updated: 2026-10-29
 summary: Active planning surface for Reploy design and implementation gaps.
 ---
 
@@ -20,6 +20,9 @@ This file is the day-to-day queue for design and implementation gaps.
 - Keep each item small enough for one focused change.
 - Put only the most urgent items in `Now`.
 - Prefer richer items with brief context and concrete acceptance checks.
+- Keep detailed consumer requirements, evidence and progress in
+  [the consumer directory](consumers/README.md). Link to those records where
+  possible; keep backlog entries focused on priority and the next action.
 - Move completed items out instead of keeping a long archive here.
 - Treat install, packaging, deployment, and blueprint items as operator-facing
   product work, not only as internal refactors.
@@ -281,7 +284,7 @@ This file is the day-to-day queue for design and implementation gaps.
       from two differently located user homes without editing the published
       blueprint or adding a preparation script; cover custom XDG roots
       (including XDG_STATE_HOME) and invalid/missing sources. Extend the portable-checkout need in
-      [Dingo gaps](DINGO_GAPS.md#portable-local-checkout-binding), keeping
+      [Dingo needs](consumers/dingo.md#portable-local-checkout-binding), keeping
       checkout-relative and per-user storage resolution distinct. Define the
       resolution base for each supported relative path and its behavior when
       checkout or staging locations change; never assume a fixed relationship
@@ -303,14 +306,10 @@ This file is the day-to-day queue for design and implementation gaps.
       fresh stage, restage, install, update, missing values, and precedence.
 
 - [ ] `P2` Evaluate and prioritize the Dingo development-environment gaps.
-      Use `docs/DINGO_GAPS.md` as the needs and evidence record for portable
-      checkout binding, development execution, shell initialization, pinned
-      source workspaces, ROS dependencies, robot hardware and networking, and
-      ARM64 handoff. Confirm each boundary against current behavior, separate
-      broadly useful Reploy capabilities from ROS-specific integration, and
-      turn accepted priorities into focused follow-up backlog items without
-      treating this document as an implementation plan. Portable host
-      bind-source resolution is tracked separately above.
+      Revalidate [the consumer needs and evidence](consumers/dingo.md) against
+      current behavior and turn accepted priorities into focused follow-ups.
+      Keep general Reploy capabilities distinct from ROS-specific integration;
+      portable host bind-source resolution remains tracked separately above.
 
 - [ ] `P2` Implement Reploy repository schemas and publication tooling.
       Follow `docs/REPOSITORY_DESIGN.md` as the policy source. Define strict

docs/consumers/README.md

@@ -0,0 +1,27 @@
+# Consumer requirements and progress
+
+Record concrete consumer needs here. Start with one document per consumer; split
+it into a subdirectory only when that improves navigation.
+
+| Consumer | Current need | Status | Next step |
+| --- | --- | --- | --- |
+| [Dingo](dingo.md) | Development workspace and robot deployment capabilities | Historical needs recorded; current gaps need revalidation | Evaluate and prioritize against current Reploy behavior |
+
+## What belongs here
+
+Each consumer document should describe its use cases, requirements and acceptance
+checks, current support and gaps, delivery decisions and explicit deferrals, and
+progress with links to designs, backlog items, PRs and qualified releases.
+Distinguish consumer-reported needs, verified behavior and proposed solutions.
+Date observations and retain their source and limitations. An implementation or
+approved PR does not by itself prove consumer acceptance on a released version.
+
+Keep shared Reploy capability designs in their existing locations and link to
+them. Consumer documents explain why a capability is needed and whether delivery
+unblocks that consumer; they do not create a second specification for it.
+
+Use [the backlog](../BACKLOG.md) for priority and the next action. Where a consumer
+document owns the requirements, link to it instead of repeating a large
+requirements list in the backlog. Keep consumer-specific policy with its owner,
+and link multiple consumers to the same shared capability rather than duplicating
+delivery work.

docs/DINGO_GAPS.md → docs/consumers/dingo.md

@@ -4,7 +4,16 @@ updated: 2026-08-02
 summary: Specific Reploy capability and usability gaps exposed by the Dingo ROS 2 development workspace.
 ---
 
-# Dingo Gaps
+# Dingo
+
+## Current tracking status
+
+The needs and observations below were recorded on 2026-08-02. Moving this
+document into the consumer directory on 2026-10-29 does not revalidate those
+historical gaps against current Reploy behavior. Evaluation and prioritization
+remain queued in [the backlog](../BACKLOG.md). No new implementation, delivery
+approval or qualified release is claimed by this move. Link future shared
+designs and delivery evidence here as the needs are evaluated.
 
 ## Purpose