From 39e6abca4d2daad47fdeca8c3faa1a174b11cb9e Mon Sep 17 00:00:00 2001 From: Omry Yadan Date: Fri, 30 Oct 2026 16:52:21 +0800 Subject: [PATCH] Docs: establish consumer requirements tracking Create the consumer requirements and progress directory and move the historical Dingo needs record into it. Keep backlog entries concise by linking to consumer-owned context. Retain the original Dingo observation date and explicit need for revalidation. Keep OmegaFlow-specific records and backlog/index entries for a separate commit. Validation: current-agent scoped review, UTF-8 and relative-link checks, exact move and partition-boundary checks. Internal documentation only. --- docs/BACKLOG.md | 19 ++++++++------- docs/consumers/README.md | 27 ++++++++++++++++++++++ docs/{DINGO_GAPS.md => consumers/dingo.md} | 11 ++++++++- 3 files changed, 46 insertions(+), 11 deletions(-) create mode 100644 docs/consumers/README.md rename docs/{DINGO_GAPS.md => consumers/dingo.md} (96%) diff --git a/docs/BACKLOG.md b/docs/BACKLOG.md index b593b88c..cd927702 100644 --- a/docs/BACKLOG.md +++ b/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 diff --git a/docs/consumers/README.md b/docs/consumers/README.md new file mode 100644 index 00000000..315fc1e1 --- /dev/null +++ b/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. diff --git a/docs/DINGO_GAPS.md b/docs/consumers/dingo.md similarity index 96% rename from docs/DINGO_GAPS.md rename to docs/consumers/dingo.md index 8c2373de..69650b08 100644 --- a/docs/DINGO_GAPS.md +++ b/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