stackchain/stackchain-dashboard
1
0
Fork 0
Code Issues 9 Pull Requests 1 Actions Packages Projects Releases 713 Wiki Activity

Complete follow-up filing and continue the Updates inbox #665

New Issue
Closed
opened 2026-08-12 17:02:51 +00:00 by timmy · 0 comments
timmy commented 2026-08-12 17:02:51 +00:00
Owner
Copy Link

User problem

On mobile, Create follow-up moves an unread update into issue capture, but after filing the operator must manually reopen Updates, relocate the source conversation, mark it read, and find the next item.

Vertical slice

Add a follow-up-specific Create follow-up & next completion path. Durable issue admission must happen first; only then acknowledge the source update (online or through the account-bound read outbox) and continue to the next unread update. Preserve the draft/source for safe retry if admission fails, and never create a duplicate issue while retrying acknowledgement.

Acceptance

  • Starting a follow-up does not acknowledge the source.
  • Create follow-up & next durably admits exactly one issue before acknowledgement.
  • Successful admission acknowledges/queues the source read and opens the next unread update; empty queue announces Inbox cleared.
  • Admission failure keeps the source unread and draft intact.
  • Acknowledgement retry reuses the confirmed issue receipt and does not create another issue.
  • Same-account reload can resume; another account cannot consume pending continuation state.
  • Mobile action is keyboard/safe-area reachable with a 44px target.
  • Focused behavioral tests and full suite pass.

This follows #663/#664 but does not duplicate it: that work intentionally stages a follow-up without acknowledging or continuing the Updates inbox.

## User problem On mobile, Create follow-up moves an unread update into issue capture, but after filing the operator must manually reopen Updates, relocate the source conversation, mark it read, and find the next item. ## Vertical slice Add a follow-up-specific Create follow-up & next completion path. Durable issue admission must happen first; only then acknowledge the source update (online or through the account-bound read outbox) and continue to the next unread update. Preserve the draft/source for safe retry if admission fails, and never create a duplicate issue while retrying acknowledgement. ## Acceptance - Starting a follow-up does not acknowledge the source. - Create follow-up & next durably admits exactly one issue before acknowledgement. - Successful admission acknowledges/queues the source read and opens the next unread update; empty queue announces Inbox cleared. - Admission failure keeps the source unread and draft intact. - Acknowledgement retry reuses the confirmed issue receipt and does not create another issue. - Same-account reload can resume; another account cannot consume pending continuation state. - Mobile action is keyboard/safe-area reachable with a 44px target. - Focused behavioral tests and full suite pass. This follows #663/#664 but does not duplicate it: that work intentionally stages a follow-up without acknowledging or continuing the Updates inbox.
timmy self-assigned this 2026-08-12 17:02:51 +00:00
timmy closed this issue 2026-08-12 17:14:00 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
P0

Drop everything

  
P1

High priority

  
P2

Medium priority

  
agent:nightprowl

Assignments routed to the LongCat NightProwl evaluation worker

  
backend

Backend service

  
ci

Continuous integration / actions

  
frontend

Frontend / UI

  
meta

Meta / planning

  
pages

Gitea Pages

  
template

Repo template / standards

No Label
P0
P1
P2
agent:nightprowl
backend
ci
frontend
meta
pages
template
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
timmy
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: stackchain/stackchain-dashboard#665
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?