Continuing the recorded review at Phase 3 for the Relay bulk archive brief. The edits below draw only on the supplied context and the author's five follow-up decisions. Findings, severities and the verdict stay as recorded. Nothing has been written to disk. ## Edits **Edit 1. Behaviour, bullets three and four, at `docs/refresh/demo/input-brief.md:17`. Closes the P0 and the first P1.** Original: ```markdown - When the request completes, show “Projects archived” and remove archived projects from the active list. - If any projects fail, show a general error and keep the selection so the user can try again. ``` Replacement: ```markdown - When the request completes, apply each project's result from the response. The request is not atomic, so one response can hold successes and failures. | Result | Active list | Selection | What the user sees | Retry | |---|---|---|---|---| | Archived by this request | Leaves the list | Removed | Counted in the summary as newly archived | None needed | | Already archived | Leaves the list | Removed | Counted in the summary as already archived | None needed | | Permission denied | Stays in the list | Removed | Reason shown against the row | Not offered | | Temporary error | Stays in the list | Stays selected | Reason shown against the row | Offered | - After every completed request, show a summary that states three counts: newly archived, already archived, and not archived. Never show the unqualified message “Projects archived” when any project was not archived. - Once the summary shows, re-enable the button. Pressing it submits the current selection, which the table leaves as the temporary-error projects only. The interface offers no retry for permission-denied projects. ``` Bullets three and four both fired on a mixed response and prescribed different messages and list states. One rule keyed on the per-project result means exactly one path runs on any completed response. The table records the author's decisions one and two for each failure reason. Already-archived projects leave the list because the context says they are no longer active. Permission-denied and temporary-error rows stay in the list with their reason, which is what makes the Success criterion "accurately report failures" testable. The summary rule is the author's decision three. **Edit 2. Behaviour, bullet five, at `docs/refresh/demo/input-brief.md:19`. Closes the second P1.** Original: ```markdown - If the request times out, show “Try again” and enable the button. ``` Replacement: ```markdown - If the request times out, the client does not know which projects the server archived. Keep the button disabled and read the current state of every submitted project. - Projects the read confirms as archived leave the list and the selection. - Projects the read confirms as active and permitted stay in the list and stay selected. Re-enable the button so the user can submit a new archive request for those projects only. - Projects the read confirms as active but not permitted stay in the list, unselected, with the reason shown, as for permission denied above. - Show a summary that states the request timed out, how many projects the read confirmed as archived, and how many remain active. - If the read fails or cannot confirm current state, keep the button disabled, tell the user the result is unknown, and offer a status check that runs the read again. Do not offer an archive retry in this state. - Assumption: the state read reports, per project, whether it is archived and whether the current user may archive it. The backend engineer confirms this with the endpoint behaviour. ``` The context says a timeout leaves completion uncertain and that reading current state is supported. A blind retry would resubmit projects that may already be archived and report failures for work that succeeded. The first, second and fifth sub-bullets are the author's decision four. The third applies the author's permission-denied rule to the same condition after a read. The fourth mirrors the count structure from decision three. Neither of those two is an author decision yet, so both appear under open items. The assumption is stated because the whole rule depends on it and the brief had none. **Edit 3. Proposed change, last sentence, at `docs/refresh/demo/input-brief.md:11`. Not a P0 or P1. This is the one voice tell.** Original: ```markdown Add an Archive selected button to the existing project list. Users select up to 20 projects and confirm the action. This will streamline the workflow and make managing projects more seamless. ``` Replacement: ```markdown Add an Archive selected button to the existing project list. Users select up to 20 projects and confirm the action. ``` The review flagged the deleted sentence as a bolt-on significance sentence carrying two thesaurus words. The paragraph loses nothing. This sits outside the P0 and P1 ask, but it is a one-line cut the review already recommended, so it is included and labelled as extra. Problem, Success, Scope and Delivery are untouched. ## What stays open Two parts of Edit 2 need the author's confirmation before they count as decided: - Treating active-but-not-permitted projects after a timeout read the same as permission denied. - The summary content after a timeout. The client cannot tell newly archived from already archived at that point, so those counts are not split. Every P2 from the review remains open. The edits changed the shape of some, and none are resolved: - Confirmation dialog contents, and whether a count is enough with no undo. Unchanged. - Pilot gating and stop condition. Unchanged. - Endpoint contract in the brief. Narrowed, since the three reasons and per-project results are now named in Behaviour. The cap of 20 and the state read are still not described as a contract. - Backend confirmation has no date or fallback. Unchanged, and the state-read assumption adds to what needs confirming. - Selection changes while a request is in flight. Unchanged. - Timeout threshold. Unchanged. The "Try again" ambiguity is gone because that message no longer exists. - Performance requirement. Unchanged. - Cap boundary display, and what shows when the page empties. Unchanged. - Permission change between selection and submission. Behaviour is now specified in the table. The QA list in Delivery still omits the test. - Screen reader announcement on a mixed result, and focus after rows are removed. Unchanged. The summary now exists as a candidate for the announcement, but that is not decided. - QA list in Delivery omits partial failure, timeout, permission change and accessibility. Unchanged, and the new states make the omission larger. - Definition of "permitted" in Success. Unchanged. - Basis for the 45-second target, the pilot measurement method, and what situation produces ten projects to archive at once. Unchanged. - Exact copy for the summary and the row reasons. New and open. The rules above fix the content, not the wording. - Whether a user can re-tick a permission-denied row by hand. New and open. The rules only say the interface offers no retry for those rows. - Trade-offs. The general-error trade-off is gone. The brief still does not name what a bulk action with no undo gives up. The frequency question the review named as avoided, how often a project manager archives ten projects at once, is still unanswered. The `discover` mode can plan the conversations that would test it, and the `decide` mode can structure the confirmation and undo question. The verdict is unchanged from the recorded review, ROUGH on the P0, because these are proposed edits and not applied ones. Of the three slop-test checks that failed, edge cases and assumptions would pass with these edits and trade-offs would still fail. If the author applies the edits and asks for a re-review, that re-review carries the self-grading disclosure: a rise driven by fixes drafted here measures Claude fixing what Claude flagged. Built from session-only context; `/pm teach` makes this permanent and sharper.