fix(tests): forward-only env-restore comments in auth and telemetry tests

Also record the review-thread reply convention in agent memory.

Signed-off-by: Rhuan Barreto <rhuan@barreto.work>

Author: rhuanbarreto

.claude/agent-memory/archgate-developer/MEMORY.md

@@ -24,6 +24,7 @@ Skipping steps 2 or 3 is a workflow violation. The user should NEVER have to inv
 - [Pick the right enforcement layer](feedback_prefer_tests_over_adr_rules.md) — static syntax → custom oxlint rule; executable behavior → tests; cross-file/governance → ADR `.rules.ts`. Never write an ADR rule that only asserts implementation shape — `rules: false` is a valid outcome
 - [This repo is PUBLIC — no private sibling-repo internals, no Claude session links in PRs/commits](feedback_public_repo_privacy.md)
 - [Keep code comments and memory entries concise](feedback_concise_comments.md) — code side now machine-enforced by GEN-004 (oxlint `archgate/*` + `archgate check`); memory-entry conciseness still manual
+- [Answer every review finding on its own thread](feedback_reply_on_review_threads.md) — especially declined ones; a summary PR comment does not close the loop (recurring miss)
 - [Throw UserError in boundary-wrapped guards](feedback_throw_usererror_in_guards.md) — not logError + exitWith(1); the action's handleCommandError boundary does that
 - [Docs are forward-only and version-independent](feedback_forward_only_docs.md) — describe current state; no "previously"/"rather than"/"shipped" framing, no pinned release version or drift-prone counts; git & package.json are the source of truth
 

.claude/agent-memory/archgate-developer/feedback_reply_on_review_threads.md

@@ -0,0 +1,17 @@
+---
+name: reply-on-review-threads
+description: Answer every review finding on its own thread — especially declined ones; a summary PR comment does not close the loop
+metadata:
+  type: feedback
+---
+
+Reply to each PR review finding **on its own thread**, not only in a summary PR comment. Declined findings especially: the reviewer (human or bot) must see the reasoning attached to the code line they raised.
+
+**Why:** User feedback 2026-07-25 on PR #496: I addressed 14 CodeRabbit threads with one consolidated PR comment that explained three declines. The user flagged it as recurring — "the ones you declined you must answer at each thread. not the first time this is happening." An unanswered thread stays open and reads as ignored; the reviewer cannot resolve it, and a summary comment is not linked to the line.
+
+**How to apply:**
+
+- Find unresolved threads with the GraphQL `reviewThreads.isResolved` query (see [[project-pr-review-thread-triage]]) — REST does not expose resolved state.
+- Reply per thread: `gh api repos/<owner>/<repo>/pulls/<n>/comments/<first_comment_databaseId>/replies -f body='...'` (the reply targets the thread's FIRST comment id).
+- Declined → state the reason on the thread (out of scope / came from main / conflicts with an ADR). Accepted → state the fixing commit SHA. A summary comment is optional on top, never a substitute.
+- Applies to bot reviewers too — CodeRabbit re-reviews per thread.

tests/helpers/auth.test.ts

@@ -36,11 +36,10 @@ describe("auth", () => {
 
   afterEach(() => {
     // `Bun.env.X = undefined` assigns the STRING "undefined" and leaves the key
-    // present — it does not unset. Since HOME and GIT_CONFIG_GLOBAL are normally
-    // unset on Windows, a plain restore leaked HOME="undefined" into the shared
-    // process env, and every later test that spawned a subprocess inherited it.
-    // Bun.env is process-global and test files share one process, so this must
-    // delete when the original was absent.
+    // present — it does not unset. HOME and GIT_CONFIG_GLOBAL are normally unset
+    // on Windows, and Bun.env is process-global across test files, so a plain
+    // restore would publish HOME="undefined" to every later test and any
+    // subprocess it spawns. restoreEnv deletes when the capture was absent.
     restoreEnv("HOME", originalHome);
     restoreEnv("USERPROFILE", originalUserProfile);
     restoreEnv("GIT_CONFIG_NOSYSTEM", originalGitConfigNoSystem);

tests/helpers/telemetry.test.ts

@@ -27,8 +27,8 @@ describe("telemetry", () => {
 
   afterEach(async () => {
     // `env.X = undefined` assigns the string "undefined" rather than unsetting,
-    // so HOME (normally unset on Windows) leaked into every later test file.
-    // Bun.env and process.env are the same store, so restoreEnv covers both.
+    // which would leak HOME (normally unset on Windows) into every later test
+    // file. Bun.env and process.env are the same store, so restoreEnv covers both.
     restoreEnv("HOME", originalHome);
     restoreEnv("ARCHGATE_TELEMETRY", originalTelemetryEnv);
     restoreEnv("NODE_ENV", originalNodeEnv);