Verdict words

The reviewer writes its review to a file whose first line is the verdict, instead of relying on a narration-free final message. Sonnet put `Yes` after three paragraphs of narration on memona #936 (review 595), which the fail-closed verdict posted as a plain comment.

Reviewed-on: #7
Co-authored-by: Danny Kim <temeddix@gmail.com>
Co-committed-by: Danny Kim <temeddix@gmail.com>

prompt.md

@@ -20,24 +20,23 @@ they bear on the task, and push from there.
 
 For a `pull_request` event, review the PR without changing code, using the
 `requesting-code-review` skill from superpowers: run its code reviewer template
-against the PR's base and head, and make its complete output your final response
-instead of the short comment style above. Run the project's checks on the head
-and treat a failure as at least Important. Check the whole repository against
-the code rules at the end of this prompt, not only the diff; a violation is at
-least Important even when the diff did not cause it. Your final response is
-posted verbatim as a pull request review from the bot account, so it is the
-review text and nothing else: no narration about what you did, verified, or are
-about to post, whether you reviewed yourself or relayed a reviewer subagent. Its
-first line must be exactly the template's verdict and nothing else: `Yes`, `No`,
-or `With fixes`. `Yes` approves and the other two request changes; any other
-first line is posted as a plain comment, which wastes the run. Minor issues
-alone never block, and neither does a finding the author has answered in the
-comment history below as intended or a false alarm, once the code or docs make
-that clear. When the verdict is not `Yes`, the second line names what must
-change in one line, addressed to the author; the author's own agent picks the
-fixes up, so never ask `@bot` to make them. For UI changes, check that the
-result is aligned, clean, and pixel-perfect, and that included screenshots prove
-the intended result was achieved.
+against the PR's base and head. Run the project's checks on the head and treat a
+failure as at least Important. Check the whole repository against the code rules
+at the end of this prompt, not only the diff; a violation is at least Important
+even when the diff did not cause it. Write the complete review, and nothing
+else, to the file `${REVIEW_PATH}`: it is posted verbatim as a pull request
+review from the bot account, and your final response is not posted at all. The
+file's first line must be exactly the verdict and nothing else: `Approved` when
+the template's answer is yes, `Changes requested` otherwise. The mark in front
+of it is added when posting, so write the words alone; any other first line is
+posted as a plain comment, which wastes the run. Minor issues alone never block,
+and neither does a finding the author has answered in the comment history below
+as intended or a false alarm, once the code or docs make that clear. When the
+verdict is `Changes requested`, the second line names what must change in one
+line, addressed to the author; the author's own agent picks the fixes up, so
+never ask `@bot` to make them. For UI changes, check that the result is aligned,
+clean, and pixel-perfect, and that included screenshots prove the intended
+result was achieved.
 
 The review must read at a glance: everything outside `<details>` blocks totals
 under 512 bytes. Only core information stays visible: the verdict, the summary

run.ts

@@ -59,21 +59,27 @@ async function postComment(body: string): Promise<void> {
   });
 }
 
-// A pull request event is a review request, so the response becomes a review.
-// Its first line is the verdict; anything unexpected only comments, never
-// approves.
-const VERDICTS: Record<string, string> = {
-  Yes: "APPROVED",
-  No: "REQUEST_CHANGES",
-  "With fixes": "REQUEST_CHANGES",
+// A pull request event is a review request, so the review is posted instead
+// of the response. It comes through a file, because a final chat message picks
+// up narration while a file's first line is written on purpose. That line is
+// the verdict, matched whole; anything unexpected only comments, never
+// approves. The mark in front is added here, so it is never part of the match.
+const REVIEW_PATH = `${await Deno.makeTempDir()}/review.md`;
+const VERDICTS: Record<string, [event: string, mark: string]> = {
+  Approved: ["APPROVED", "✅"],
+  "Changes requested": ["REQUEST_CHANGES", "🛑"],
 };
 
 async function postResult(body: string): Promise<void> {
   if (EVENT !== "pull_request") return postComment(body);
-  const [verdict] = body.split("\n", 1);
+  const review = await Deno.readTextFile(REVIEW_PATH).catch(() => {
+    throw new Error(`no review was written to ${REVIEW_PATH}`);
+  });
+  const [verdict, ...rest] = review.split("\n");
+  const [event, mark] = VERDICTS[verdict.trim()] ?? ["COMMENT", "💬"];
   await gitea(REVIEWER_TOKEN, `repos/${REPO}/pulls/${INDEX}/reviews`, {
-    body: stripAnsi(body),
-    event: VERDICTS[verdict.trim()] ?? "COMMENT",
+    body: stripAnsi([`${mark} ${verdict.trim()}`, ...rest].join("\n")),
+    event,
   });
 }
 
@@ -118,6 +124,7 @@ async function renderPrompt(): Promise<string> {
     GITEA_API_URL: API,
     GITEA_REPOSITORY: REPO,
     ISSUE_INDEX: INDEX,
+    REVIEW_PATH,
   };
   const template = await Deno.readTextFile(
     new URL("prompt.md", import.meta.url),