Complete the form together before class. Leave gray tutor fields and signatures empty. A review produces a reasoned professional opinion, not a rewrite and not automatic agreement with the requesting team.
A1 is assigned by the tutor. Use a memorable name in A2, such as Feature Issues Readiness Review. In B1-B4, identify who requests and pays for the review and who performs it.
Select the artifact type in C1-C2. A GitLab reference is an exact pointer, such as project path plus issue #27, merge request !14, commit a1b2c3d4, or file docs/pitch.pdf at that commit. List every artifact in C3 and freeze its version or date in C4. Use C5 for necessary context and access.
In D1, ask what you genuinely need to learn. Select the perspectives in D2-D4 and state the expected decision or benefit in D5.
Use E1 to list exact files, pages, slides, issues, or questions. Use E2 to exclude work such as rewriting or implementation.
Select at least one method in F1-F4 and fill its question, checklist, comparison, or criteria. Use F5 for additional steps. Do not demand a fixed number of problems; that encourages invented findings.
Select required report qualities in G1-G6. A useful finding points to an exact place, explains why it matters, and gives an actionable suggestion. Put measurable additions in G7.
Choose where the written review will live in H1-H3. An oral explanation in H4 supports but does not replace written evidence. Describe the report structure in H5.
Write whole points in I1 and an exact fixed deadline in I2. Use J1 only for non-conflicting additions.
The requesting team judges whether the agreed review was performed, not whether it likes every conclusion. Required representatives sign K1-K2 in person. The tutor fills A1 and L1-L4.