Backlog Readiness Workbench

OrchardRelay: grooming review and proposed ticket repairs

Prepare the session around two decisions: protect approval authority, then agree how a requester learns the current status and assigned approver. OR-104 deserves the first substantive discussion because its reported behavior conflicts with the supplied approval rule, although the failure has not been reproduced. Review OR-108 and OR-109 together to resolve their recorded dependency cycle. OR-103 provides a coherent approver-visibility slice; OR-112 needs missing mobile evidence and clarification of OR-999 before implementation scope can be agreed.

All material below is fictional. This is a local review of the October 13, 2026 snapshot, not a live tracker or production check. Coverage is

12 rows and 12 unique IDs, OR-101 through OR-112. These are all items selected for this review, not the whole company backlog (context C6). Reported type, workflow status, priority, and ownership have not been changed.

The planned session is October 20, with candidate scope sought by October 22 and a target pilot on October 29. Two engineers have ten planned working days after scope agreement, but there are no estimates. These are planning inputs, not delivery commitments (C5).

Review standard and source notation

The next decision is

grooming, not implementation approval. Because no team-specific readiness threshold was supplied, I propose: enough context to discuss a bounded user problem, intended behavior, and a useful unresolved decision. An item can meet that threshold while still lacking a trace, estimate, named owner, or final contract. Implementation readiness additionally needs an agreed testable contract and material dependencies resolved.

C1–C7 cite the named sections of fixtures/context.md. OR-nnn.description, .acceptance_criteria, .depends_on, and other field citations refer to the exact CSV row and field in fixtures/tickets.csv; the source-reference label and update date identify the supplied record. Context baseline and policy statements are authoritative

within this packet. Ticket descriptions are

reported observations or requests, not reproduced facts. Proposed repairs, tests, roles and order below remain proposals.

1. All-ticket readiness assessment

No item is declared implementation-ready by this assessment. In particular, a missing estimate is not a reason to avoid a useful grooming discussion; it is a limit on delivery commitment.

2. Duplicate candidates and dependency map

Duplicate and overlap review

A mistaken merge could erase a return-to-tab trigger, a CSV timing distinction, or mobile visibility coverage. No duplicate is confirmed, merged, closed or deleted.

Recorded dependencies

Direction

A → B means A is recorded as waiting for B. Every edge below comes from tickets.csv .depends_on; confidence is high about the recorded value and unestablished about an actual technical prerequisite.

Recorded cycle: OR-108 → OR-109 → OR-108. This is a graph of exported links, not proof of architectural deadlock. Proposed resolution is one joint contract/experience decision: inspect existing behavior and API/cache evidence, choose a candidate experience option, and record which acceptance decisions still depend on which evidence. Removing or changing the links would require separately authorized tracker edits; none are proposed as already done.

Policy prerequisites from the supplied context: C2 constrains approval actions to the current assigned approver on Pending requests, and requires successful-transition audit integrity. C3 prevents pilot scope from adding SMS or reopening a final request. These source-confirmed constraints have stronger standing than inferred technical ordering.

Suggested coordination, not new dependency edges: investigate OR-101/102/106 under a shared status contract; align OR-103 and OR-112 on mobile visibility; prepare OR-110's evidence inventory alongside scope decisions. Do not add these as tracker dependencies merely because a meeting groups them.

3. Complete proposed replacement tickets

The following are local proposed replacements for title, description/body and acceptance criteria. Type, reported workflow status, priority and ownership remain as supplied. None is saved in a tracker or agreed implementation scope.

OR-104

Retained reported metadata: Bug; To review; High; Engineering lead. Source: Support note D, last updated October 13.

Proposed title: Investigate approval reportedly accepted from the former approver after reassignment

Proposed body:

Support reports that the original approver clicked Approve from an already-open request page after reassignment, and the request became Approved. This is a reported sequence, not a reproduced failure. The packet supplies no trace or precise step record. The request ID, prior state, assignment and action timestamps, environment, identity/permission evidence, and authoritative transition/audit records are unknown.

Expected behavior follows C2: only the currently assigned approver may approve a Pending request. A requester may view their own request and assigned approver. A successful transition must preserve the existing audit history and identify the acting user and resulting state. The available material does not prove current enforcement or identify a UI, cache or server-side cause.

The possible consequence is a final decision made by someone who no longer has approval authority. Frequency, affected population and any actual customer impact have not been established. C3 rules out returning final decisions to Pending or deleting audit records as a pilot remedy.

Scope proposed for review: reconstruct the report, compare it with the authoritative request/assignment state, and agree enforcement and stale-page handling tests. No particular architecture is prescribed. User-visible rejection/recovery wording and whether rejected attempts receive additional audit events remain decisions; do not confuse these proposals with the existing successful-transition audit rule.

Acceptance criteria proposed for agreement:

Source contract translated into a proposed test: With a controlled Pending request initially assigned to approver A, open the approval page as A, reassign it to B through an authorized test setup, then attempt approval from A's old page. Verify that A cannot cause an Approved transition once A is no longer current assignee. This is a proposed reproduction/test procedure, not the original precise steps or a completed test.
2.

Source contract: Only the current assigned approver can approve while the authoritative request state is Pending. Agree the execution-time authorization/state check with engineering; a page's earlier display is not evidence of current authority.
3.

Source contract translated into positive coverage: A permitted approval by the currently assigned approver on a Pending request leaves the existing audit history intact and identifies the acting user and resulting Approved state.
4.

Source contract translated into boundary coverage: An attempt to approve an already Approved or Rejected request must not reopen it or alter its final decision. Retain audit history (C2–C3).
5.

Proposed UX criterion, wording to agree: A user whose attempted action is no longer allowed receives a clear result and a path to view the request's current state/assigned approver within their access rights. Do not show a success confirmation for a rejected or unknown outcome. Exact message and recovery behavior remain unapproved.
6.

Evidence gate: Record the controlled environment, request/assignment/action evidence and observed result for each test. Until evidence is supplied or a test is run, report “not reproduced/not tested”; do not claim that the original support report is resolved.

Field-change ledger:

OR-107

Retained reported metadata: Story; To review; Medium; Product manager. Source: Operations note G, last updated October 8.

Proposed title: Define an authorized date-range request export for shift review

Proposed body:

Operations requests a date-range CSV with readable approver names for a shift review. The current export includes request ID, state and approver ID (C2). Whether existing date filters or readable names are already supported is not established. The packet does not specify the export user/recipient's authorization or permitted name visibility.

Proposed user story: As an

authorized operations reviewer preparing a shift review, I want requests selected by an agreed date range and approved approver-identification fields so that I can review the relevant requests without reconstructing them manually. “Authorized operations reviewer” is a proposed actor requiring confirmation, not a verified role or access grant.

Before inclusion, Product must decide whether this is necessary for C1's requester status/approver pilot or belongs to a separate reporting decision. Do not assume that a Medium priority or the existing CSV makes it part of the pilot. Preserve existing access controls and final decisions (C2–C3).

Proposed scope for discussion: inspect the current export behavior; identify the intended user, purpose and allowed request population; choose the date field, timezone, and range-boundary convention; decide what name or identifier may be disclosed; and agree verifiable CSV behavior. No reminder channel or final-state change is included.

Unresolved: filter existence, date-field semantics, timezone and inclusivity, empty/invalid range behavior, authorized population, allowed approver representation, and export snapshot/freshness semantics. C2's permission for a requester to view their own assigned approver does not grant unrestricted readable-name exports to operations. OR-108's contract work may inform state semantics, but no new hard dependency is asserted.

Acceptance criteria proposed for agreement:

Evidence gate: Record the observed current export columns and date-filter behavior before proposing implementation changes. Preserve request ID, state and approver ID unless an explicit reviewed scope change says otherwise; their existence is supplied by C2.
2.

Policy/scope gate: Identify the authorized export actor, permitted request population and permitted approver representation before finalizing name output. Do not publish readable names under an invented policy. If readable names are not permitted, bring an allowed identifier alternative to the decision instead of silently exposing names.
3.

Unresolved contract made explicit: Agree [date field], [timezone], [start/end boundary convention] and [snapshot semantics]. With those decisions fixed, a controlled fixture including records before, on, within and after the boundaries must produce exactly the agreed included IDs. No date field or boundary value is assumed here.
4.

Source rule plus proposed test: Under the agreed authorization model, the export contains only requests and approver fields available to its authorized recipient. Test both permitted and disallowed populations. The packet has not supplied that export policy, so this criterion is not presently executable end to end.
5.

Proposed CSV behavior: Each included request appears with a traceable request ID and approved state/approver fields. Agree invalid-range and empty-result behavior so the reviewer can distinguish a valid empty result from an invalid request or failure. Specific error text/format remain proposals.
6.

Scope decision: Record whether the agreed slice is included in the pilot or deferred; no estimate or delivery date is inferred from this draft. A policy decision or unresolved date contract prevents implementation acceptance, but the story remains useful for grooming.

Field-change ledger:

OR-109

Retained reported metadata: Story; Ready; High; Designer. Recorded dependency OR-108 retained. Source: Design note I, last updated October 9.

Proposed title: Agree and implement a clear status-freshness experience on request details

Proposed body:

The recorded request asks for status changes while a requester views request details without reloading. No refresh interval or error behavior is agreed, and “quickly” does not provide a testable contract (OR-109). C1's outcome is for an authorized requester to understand authoritative status without asking support. C4 says that continuous refresh and reopening/refocusing a page are viable options; none is accepted scope.

Proposed user story: As a requester viewing my own request, I want the page to present status according to an understandable, agreed freshness contract, and make unsuccessful refresh apparent, so I can distinguish the current recorded status from information that may be stale.

Review the existing behavior, available API/cache evidence and OR-101/102 reports with OR-108. The export records OR-109 waiting for OR-108 and OR-108 waiting for OR-109. This calls for paired refinement of interaction and contract; it does not prove an architectural cycle. Existing source state, cache behavior, refresh support and event coverage are unknown, not assumed absent.

Proposed scope: choose a candidate interaction mode and authoritative status source, decide trigger or refresh interval and latency target as appropriate, specify loading/failure/recovery behavior, and agree tests. Potential modes include refocus/reopen refresh and continuous refresh. Preserve C2's access, current-assignee/Pending approval rule and successful-transition audit requirements. C3 excludes automatic approval, reopening final decisions, audit deletion, mobile push, SMS and a new messaging integration.

Unresolved contract fields: [chosen refresh mode], [trigger or interval], [freshness/latency target and measurement start/end], [authoritative state/cache semantics], and [loading/failure/recovery treatment]. These need evidence and agreement before implementation scope is accepted. No polling frequency or success time is invented by this draft.

Acceptance criteria proposed for agreement:

Decision gate: Product, Design and Engineering agree a candidate interaction/contract with OR-108, documenting the named unresolved fields and why the option supports C1. This is a proposed set of decision participants, not recorded attendance or approval.
2.

Proposed behavior under the agreed contract: For an authorized requester viewing their own controlled request, change authoritative status through a permitted action in another session. Verify the displayed status against the selected trigger/timing rule and authoritative result. If the chosen option is refocus/reopen, test that transition; if continuous, test in-view updates. The selected test must not imply both options are committed.
3.

Proposed recovery behavior: When status retrieval fails, preserve useful context, distinguish the inability to confirm freshness from a confirmed new status, and provide the agreed retry/refresh path. Do not assert a new final state on an unknown result. Exact display and recovery behavior need approval.
4.

Source contract translated into regression coverage: Status presentation or refresh must not grant another user's request access, allow a former approver to approve, automatically approve, reopen a final decision, or delete audit history (C2–C3). Define the applicable controlled checks with Engineering; no such tests have been run here.
5.

Evidence and release gate: Record observed status, source status, relevant timestamps/trigger and failures for the agreed tests. Treat an unchosen target or unavailable authoritative evidence as unresolved, not a passed check. Do not call the ticket implementation-ready merely because its exported status says Ready.

Field-change ledger:

This title/scope adjustment is a proposal for review, not a silent decision to remove or implement continuous refresh.

OR-112

Retained reported metadata: Bug; Blocked; High; owner not supplied. Recorded dependency OR-999 retained. Source: Support note L, last updated October 11.

Proposed title: Investigate assigned approver reportedly missing from the mobile request view

Proposed body:

Support reports that the assigned approver was not visible on a mobile request view. No device/browser or precise steps are supplied. The actor's role, whether it was their own request, request state/ID, viewport, actual assignment data, screenshot and occurrence pattern are also not supplied in this packet. The symptom is reported and has not been reproduced.

C2 permits a requester to view their own request and assigned approver; C1 makes understanding the responsible approver a pilot outcome. This is the expected behavior for the proposed requester test scope, not proof of the role or state in the original observation. OR-103 requests assigned-approver visibility on Pending details; its relationship to this mobile report is unresolved.

Proposed investigation: obtain the original context, inspect whether assignment data exists for the reported request, and compare visible behavior in an authorized requester's mobile view with the agreed supported presentation. Do not presume CSS clipping, missing data, permission failure, or OR-103 implementation as the cause.

The export records OR-112 → OR-999. OR-999 is not in this selected export (C6); it is not known to be nonexistent, completed, a mobile dependency or a real blocker. Obtain its relevant source or an owner explanation before deciding the dependency's force. A local ticket repair and evidence request can proceed without removing the link.

Proposed scope remains assigned-approver visibility and evidence collection, preserving existing access and final decisions. This does not add a mobile push channel, expand an operator's access, or authorize an external ticket edit.

Acceptance criteria proposed for agreement:

Evidence gate: Record the original or controlled reproduction context: request ID/state/assignment, authorized actor, device/browser/viewport, navigation steps and observed result. Distinguish the original reported sequence from newly proposed test steps. State explicitly if the report cannot be reproduced.
2.

Source contract translated into a proposed test: On an agreed supported mobile environment, an authorized requester viewing their own request with a known assigned approver can locate the assigned-approver information permitted by C2. Agree its presentation and supported environment with OR-103's review; do not invent the original device or assume a readable-name policy beyond the allowed view.
3.

Proposed experience coverage: Verify that the agreed approver information remains reachable without being hidden or obscured in the selected mobile viewport and orientation cases. These cases must be chosen and recorded; no unsupported platform matrix is promised.
4.

Source contract translated into boundary coverage: A visibility repair must preserve request access boundaries and must not change approval authority, request final state or audit history (C2–C3). Test applicable permitted and denied access cases.
5.

Relationship gate: Record the evidence establishing whether OR-999 is a prerequisite and whether OR-103 covers the same actor/state/mobile acceptance. Preserve separate report detail unless a later authorized decision changes the tickets. An unknown endpoint or overlap remains open; it is not marked resolved by this draft.
6.

Acceptance boundary: Final implementation acceptance requires an agreed presentation/support scope and observed test results. An original report that remains unconfirmed must remain so in the resolution evidence, even if a proposed enhancement is accepted.

Field-change ledger:

4. Proposed 45-minute grooming agenda

These are proposed participant and decision-owner roles, not named assignments or confirmed attendance. Planning references are C5. No meeting has been scheduled.

Total: 3 + 9 + 12 + 8 + 6 + 4 + 3 = 45 minutes. Full repair text and the readiness/dependency tables are pre-read material; do not spend the meeting reconstructing them. If a decision cannot be reached within its slot, capture the deciding evidence and role rather than imply that the scope is resolved.

The order follows a reported conflict with authority rules, then cross-item contract decisions, then the coherent user slice and measurement. It does not rank delivery by guessed reach, effort or numerical priority scores. Reported priorities stay unchanged.

5. Open evidence, decisions, and independent work

Local delivery check: all 12 IDs assessed once; all six exported dependency edges retained with direction; OR-999 identified as an unknown external endpoint; one recorded possible-duplicate edge retained; OR-108/109 cycle named; four requested complete repair drafts supplied; agenda totals 45 minutes. There are no invented estimates, metrics, participants' commitments, reproduction results or accepted implementation targets.

Nothing was changed in a tracker, linked, merged, deleted, sent, scheduled, or externally verified. The supplied workflow labels remain recorded source state; every repair and agenda entry is a local proposal.