The web half of the rule in #263: anything a Crew Captain or seat needs from me goes to my Inbox, not inline in that thread. The one exception is the initial roster approval card, which stays inline above the Captain's composer.
Depends on #263 for the read and answer routes.
Where it breaks:
ChatView.tsx:2902-2916 feeds every pending approval and user-input request to ChatComposer, which renders them inline (ComposerPendingApprovalPanel, ComposerPendingApprovalActions, ComposerPendingUserInputPanel, around ChatComposer.tsx:5271-5330). For a Captain or seat, that means a question I only see if I happen to open that thread.HumanInboxPage.tsx and HumanInboxBell.tsx show agent asks and Crew requests only.
What should change:
- The Inbox page gets a section for provider requests from Crew threads. Each item names the Crew and seat (or Captain), links to the thread, and can be answered in place: approve or decline for approvals, and the question form for user-input requests. The bell counts them.
- On a live Captain or seat thread, the inline approval and question panels are replaced by a short note that the request is waiting in the Inbox, with a link to it. The roster gate is unaffected. This is one appended J5 hook where
ChatView hands pending requests to the composer (for example a useJ5CrewRoutedRequests(threadId) filter), recorded as a new FORK.md case beside cases 27 and 29. The upstream panel components stay untouched and may be reused from the J5 Inbox.
- Mobile has no J5 Inbox, so mobile keeps its inline cards (
ThreadDetailScreen.tsx:1070-1077) for now. Say so in the user docs.
- Docs: crews.md (Definition, near the gate-placement rule, and AC9) and the Crews section of
docs/user/personas.md state where a Captain's or seat's approvals and questions appear.
Tests to ship:
- a Crew thread's pending approval is answered from the Inbox and the thread resumes; the bell count goes up and back down
- a non-Crew thread keeps its inline panels
- the roster gate still renders inline on the Captain's thread
- no static-markup assertions
Done when a Captain's or seat's provider approvals and questions appear only in the Inbox on web and desktop, can be answered there, and the roster gate is still inline.
Related criteria: crews.md AC9.
The web half of the rule in #263: anything a Crew Captain or seat needs from me goes to my Inbox, not inline in that thread. The one exception is the initial roster approval card, which stays inline above the Captain's composer.
Depends on #263 for the read and answer routes.
Where it breaks:
ChatView.tsx:2902-2916feeds every pending approval and user-input request toChatComposer, which renders them inline (ComposerPendingApprovalPanel,ComposerPendingApprovalActions,ComposerPendingUserInputPanel, aroundChatComposer.tsx:5271-5330). For a Captain or seat, that means a question I only see if I happen to open that thread.HumanInboxPage.tsxandHumanInboxBell.tsxshow agent asks and Crew requests only.What should change:
ChatViewhands pending requests to the composer (for example auseJ5CrewRoutedRequests(threadId)filter), recorded as a new FORK.md case beside cases 27 and 29. The upstream panel components stay untouched and may be reused from the J5 Inbox.ThreadDetailScreen.tsx:1070-1077) for now. Say so in the user docs.docs/user/personas.mdstate where a Captain's or seat's approvals and questions appear.Tests to ship:
Done when a Captain's or seat's provider approvals and questions appear only in the Inbox on web and desktop, can be answered there, and the roster gate is still inline.
Related criteria: crews.md AC9.