**Frame.** Engineering brief for Relay's bulk archive, read by a frontend engineer, a backend engineer and a QA engineer deciding whether it is ready for sprint planning. Intent is to sharpen for that same audience, with no rewrite in this pass. Product context comes from the supplied context file only. Knowledge file is the specification checklist. Personas run were Dev, Tester and Critic. Customer was not run because the readers are engineers judging buildability.

## Slop verdict and critical gaps

The brief reads as written by a person, and every section says something specific to Relay.

| Check | Result |
|---|---|
| Template camouflage | 0 of 6 sections regenerable from their headings |
| PM Slop Test | 3 of 10 checks fail: edge cases, assumptions, trade-offs |
| Claudism tells | 1 instance, 1 family |

The one voice tell closes Proposed change: "This will streamline the workflow and make managing projects more seamless." It is a bolt-on significance sentence, family 12, carrying two thesaurus words. Delete it and the paragraph loses nothing. Voice does not gate the band here.

The three failed checks are substance. Edge cases fail because the partial-failure and timeout paths are contradictory or unresolved. Assumptions fail because none are stated, yet the brief assumes the existing list enforces the cap of 20 and that the client can render per-project results. Trade-offs fail because the brief never names what it gives up, namely a general error instead of per-project reporting, and a bulk action with no undo.

**Critical gaps, ranked**

1. **P0. The partial-failure state is contradictory and breaks the brief's own success criterion.** The endpoint is not atomic and returns a result per project. On a mixed response, Behaviour bullet three says show "Projects archived" and remove the archived projects, while bullet four says show "a general error" and keep the selection. Both fire on the same response. The kept selection still contains rows that just left the list. Success then demands the interface "accurately report failures", which a general error cannot do. Flagged by Dev and Tester. Fix: replace bullets three and four with one rule for the mixed result covering which projects leave the list, which stay selected, what message shows, and whether each failed project shows its reason. These are PM decisions the brief must record, not ones engineering should guess.

2. **P1. The three failure reasons need different handling and the brief treats them as one.** The endpoint returns permission denied, already archived, or temporary error. A project that is already archived is no longer active, so keeping it listed and selected shows an archived project as active. Permission denied fails again on retry unless permissions change. Only temporary error is a plain retry. Flagged by Dev and Tester. Fix: state per reason whether the project leaves the list, stays selected, and what the user sees. The already-archived case is settled by the context: those projects leave the active list.

3. **P1. Timeout retry ignores that the request may have completed.** Bullet five re-enables the button after a timeout. The context says a timeout leaves the client uncertain and that reading current project states is supported. A blind retry resubmits projects that may already be archived, producing failures and a general error for work that succeeded. Flagged by Dev and Tester. Fix: decide whether the client re-reads project states after a timeout before offering retry, and record it. Held at P1 rather than P0 by the tie-break, since the happy path is still buildable.

4. **P2. The confirmation step is unspecified, and it is the only guard against a bulk mistake.** "Confirm the action" does not say what the dialog shows. Undo and bulk unarchive are out of scope, so a wrong bulk archive has no one-step recovery. Flagged by Dev, Tester and Critic. Fix: specify the confirmation contents. Whether a count, the project names, or something stronger is enough is an open decision the supplied facts do not settle.

5. **P2. No rollout mechanism for the pilot.** Delivery names a pilot with eight participants but not how they get the feature while others do not, nor what stops the pilot. Flagged by Dev. Askable in planning, so P2 by the tie-break, but the answer changes the frontend estimate.

## Persona findings and questions

**Dev.** Can I estimate without questions? No. Can I write a PR description? Not for the result and timeout states.
- The endpoint contract is not in the brief. The context records the response shape, the three reasons, the ID cap and non-atomicity. The frontend engineer reading only the brief sees none of it. P2.
- "The backend engineer will confirm the endpoint behaviour" has an owner but no date and no fallback if the behaviour differs. P2.
- Can the selection change while the request is in flight? Bullet two disables the button but says nothing about the checkboxes. P2.
- No timeout threshold is given, and "Try again" reads as either a message or a button. P2.
- No performance requirement is stated, though the target time implies one. Askable. P2.

**Tester.** Can I write pass/fail tests from these criteria? For selection and loading, yes. For results, no.
- All-succeed, all-fail and mixed are three result states. The brief specifies the first twice and the third contradictorily. P0, as above.
- Boundary values: zero selected is implied disabled. The brief does not say what the user sees when the page holds more projects than the cap. Presumably existing behaviour, but confirm. P2.
- Permission changes between selection and submission are a supplied fact, and the brief has no test for them. P2, tied to the reasons P1.
- What the list shows after every project on the page is archived is unspecified. P2.
- "Work with a keyboard and announce the result to screen readers" is a requirement, not a criterion. Which result is announced on a mixed response, and where focus lands after rows are removed, are untestable as written. P2.
- The QA list in Delivery omits partial failure, timeout, permission change and accessibility. P2.
- Success says "ten permitted projects". Define permitted as permission held at submission, since the server checks then. P2.

**Critic.** Was discovery done? Partly, and the brief does not overclaim.
- The observed timing is behavioural evidence. "Six participants asked for a bulk action" is a feature request, the weaker of the two, and the brief presents them as equal. Observation.
- The target of 45 seconds has no stated basis. Say where it came from, or mark it as a chosen bar. P2.
- The pilot measurement method is unstated. The baseline came from observed sessions, so say whether the pilot uses the same start and stop points. P2.
- No alternatives are recorded, and nothing in the supplied facts says any were weighed. Observation.
- The problem statement says several projects are archived "at the end of an engagement", while the context maps one engagement to one project. The brief should say what situation produces ten projects to archive at once. P2.
- There is no guardrail against mis-archiving and no undo. Whether that risk is acceptable is a decision, not a fact I can supply. Feeds gap 4.

**Ranked questions engineering will bring to planning**

1. On a mixed result, what leaves the list, what stays selected, and what does the user see? Dev, Tester. P0.
2. Are the three failure reasons shown per project, and does retry resubmit only temporary errors? Dev, Tester. P1.
3. After a timeout, does the client re-read project states before enabling retry? Dev, Tester. P1.
4. What does the confirmation show, and is a count enough with no undo? Dev, Tester, Critic. P2.
5. How is the pilot gated to eight participants, and what stops it? Dev. P2.
6. What is announced to screen readers on a mixed result, and where does focus go after rows are removed? Tester. P2.
7. Can the selection change during the request, and what is the timeout threshold? Dev. P2.
8. What shows when the page empties, and at the selection cap? Tester. P2.
9. How is the target time measured, and why that number? Critic. P2.

Nine questions is well past the read-through threshold of three.

**Contradictions**

- Behaviour bullets three and four both apply to a partial result and prescribe different messages and list states.
- Bullet four's "general error" contradicts Success, which requires accurately reported failures.
- "Keep the selection" in bullet four conflicts with "remove archived projects" in bullet three, since the selection would include removed rows.
- Bullet five's blind retry conflicts with the supplied fact that a timeout leaves completion uncertain. This is a conflict with the context, not within the brief.

**Genuine strengths**

- The problem is observable and has a measured baseline from eight sessions.
- The success target is one number with a baseline, and the correctness criterion is a real guardrail.
- Scope names six concrete exclusions and matches the decisions already made.
- The brief reuses the existing selection and endpoint, and the team is named.
- No claim exceeds the evidence. It does not reach for retention or revenue.
- Keyboard and screen reader support are stated as requirements, not afterthoughts.

## Alignment and verdict

The brief connects to the stated outcome, time to archive, with no drift. Evidence is medium. The observed timing is behavioural, and the request count is not. Whether this is the highest-value use of a three-person sprint cannot be judged from the supplied facts, because no alternatives or frequency are recorded. The hard question the team is avoiding is how often a project manager archives ten projects at once, and whether that frequency justifies the work. The brief and the context are both silent, and I will not invent the answer.

Verdict: ROUGH - the partial-failure state is contradictory and fails the brief's own success criterion, which is a P0. Recording one rule for the mixed result moves it to SOLID, and closing both P1s plus deleting the one voice tell moves it to SHIP.

Built from session-only context; `/pm teach` makes this permanent and sharper.

**Want me to draft fixes for the P0s and P1s now?**