[/diagnosing-bugs] The comment says "right operand only (the potential dropped value)" but doesn't explain why ||/?? left operands are safe to skip. For cond || core.summary.write() the right operand is only evaluated when cond is falsy, which is still a dropped Promise worth flagging — yet for cond ?? write() the left would never be a write call, so right-only is always correct. A brief comment clarifying the reasoning would prevent future readers from second-guessing this choice.

// For all logical operators (&&, ||, ??), the right operand is the value that
// can be produced and immediately discarded as a bare ExpressionStatement.
// The left operand is always evaluated for its truthiness — it cannot itself
// be silently dropped — so right-only recursion is the correct conservative policy.

@copilot please address this.

[/tdd] The .then() chain detection checks callee.object.type === "CallExpression", but collectBareWriteCalls is not called recursively on the chain callee object — it calls it and only uses the result to decide whether to flag the outer expression. This means a doubly-chained case like write().then(f).catch(e) would NOT be flagged: catch's callee object is write().then(f), not a raw write(). Consider adding a test case to document whether this is intentional or a missed case.

// Should this be flagged? Currently it isn't:
{
  code: `async function f() { core.summary.write().then(() => {}).catch(e => {}); }`,
  errors: [...],
}

@copilot please address this.

[/tdd] The LogicalExpression test only covers &&. It's worth adding || and ?? cases to confirm right-operand-only recursion works correctly for all three logical operators, since the PR description doesn't explicitly state that ||/?? forms were considered.

// || form: right side dropped when left is falsy
{
  code: `async function f() { cond || core.summary.write(); }`,
  errors: [{ messageId: "requireAwait", suggestions: [{ messageId: "addAwait", output: `async function f() { cond || await core.summary.write(); }` }] }],
},
// ?? form: right side dropped when left is nullish
{
  code: `async function f() { val ?? core.summary.write(); }`,
  errors: [{ messageId: "requireAwait", suggestions: [{ messageId: "addAwait", output: `async function f() { val ?? await core.summary.write(); }` }] }],
},

@copilot please address this.

[/tdd] The void exemption test validates two patterns but neither covers a compound form like void (cond && core.summary.write()). If someone wraps a LogicalExpression in void, the current implementation still recurses into the logical and would flag it — but maybe the intent is to let void at the outer level exempt everything inside. A test verifying the edge case would clarify the intended semantics.

// void wrapping a compound — should it be exempt or still flagged?
valid: [
  `async function f() { void (cond && core.summary.write()); }`,
  // ^ currently: the ExpressionStatement expr IS the UnaryExpression,
  // so collectBareWriteCalls returns [] and this is already exempt.
  // Add as a valid case to lock in the behaviour.
]

@copilot please address this.

[/diagnosing-bugs] When collectBareWriteCalls returns multiple call expressions (e.g., both branches of a ConditionalExpression), each one gets its own insertTextBefore fix. However, if a user applies both suggestions sequentially, the second fix might produce invalid output because the offsets shift after the first insertion. ESLint suggestions are meant to be applied one at a time (not composed), but it's worth confirming that the test for the two-error conditional case (cond ? write() : write()) validates that applying each suggestion independently produces the correct output — the existing test does verify this, which is good. A comment in the code confirming the single-at-a-time assumption would be a helpful guard.

// Note: suggestions are applied one at a time by the ESLint editor;
// each fix operates on the original source independently.
// Applying both suggestions from a double-write conditional produces
// two separate corrected forms, not a single doubly-awaited form.

@copilot please address this.

The comment says "only the right operand can be the dropped promise", but the left operand of && is also evaluated and its Promise is discarded when it is a bare write call:

core.summary.write() && doSomething()  // left-side write() Promise silently dropped — not flagged

This is a known gap (the PR description focuses on right-operand / result-value drops), but the inline comment is misleading. Consider rewording to:

// Logical: only the right operand is unwrapped (it carries the statement's result value).
// Left-side write() drops (e.g. write() && cond) are a known out-of-scope gap.

Non-blocking suggestion. @copilot please address this.

Unlike rootsSummaryOrAlias (which has an explicit depth > 32 guard), collectBareWriteCalls has no recursion depth guard. AST nodes like deeply-nested ternaries or &&-chains could in theory recurse hundreds of levels deep:

cond1 ? cond2 ? cond3 ? ... ? core.summary.write() : x : y : z

In practice this is unlikely to cause a stack overflow with real source code, but a simple depth guard (e.g. if (depth > 32) return []) would make this explicit and consistent with the rest of the file.

Non-blocking suggestion. @copilot please address this.

The comment says "SequenceExpression always has ≥2 elements per the ECMAScript spec" — this is correct per spec, but the type definition (TSESTree.SequenceExpression.expressions: TSESTree.Expression[]) admits an empty array. The guard is the right call.

One additional edge: non-last elements of a sequence that are bare write calls are silently ignored:

(core.summary.write(), log())  // write() Promise dropped — not flagged (only last checked)

This is arguably correct (the caller may have intended fire-and-forget here), but is worth a comment acknowledging the gap:

// Note: non-last sequence elements are intentionally not unwrapped; their
// Promise drops are treated as deliberate (they cannot be the statement result).

Non-blocking suggestion. @copilot please address this.