Greptile Summary

This PR bundles three separate fixes under the MiniMax title: (1) inverts usage_percent/usagePercent in the MiniMax fetcher since those fields report remaining quota, not consumed quota; (2) prevents Mattermost DM replies from creating threads by adding a required kind: ChatType guard to resolveMattermostReplyRootId; (3) escalates the generic-repeat loop detector to \"critical\" once criticalThreshold is reached.

The core MiniMax inversion logic in deriveUsedPercent is correct and well-tested. The one minor gap is that scoreUsageRecord doesn't check REMAINING_PERCENT_KEYS, so a record whose only usage field is usage_percent/usagePercent scores 0 and is skipped by the candidate finder — the flat-payload fallback rescues all current test cases, but deeply-nested responses with only those fields could be silently missed.

Confidence Score: 5/5

Safe to merge; all findings are P2 style/hardening suggestions that do not affect current tests or the primary MiniMax API shape.

The inversion logic is correct, fromCounts priority is preserved, and the flat-payload fallback handles all tested scenarios. The scoreUsageRecord gap is theoretical for MiniMax's actual API. The Mattermost and loop-detection changes are straightforward and well-covered by new tests.

src/infra/provider-usage.fetch.minimax.ts — scoreUsageRecord does not score REMAINING_PERCENT_KEYS, which could cause candidate-selection misses for deeply nested responses with only usage_percent.

This is a comment left during a code review.
Path: src/infra/provider-usage.fetch.minimax.ts
Line: 199-217

Comment:
**`scoreUsageRecord` doesn't account for `REMAINING_PERCENT_KEYS`**

`scoreUsageRecord` only checks `PERCENT_KEYS`, so a record whose only non-plan field is `usage_percent`/`usagePercent` now scores 0 and is invisible to the candidate finder. The flat-payload fallback on line 371 (`deriveUsedPercent(payload)`) rescues the case tested here, but a MiniMax response that buries `usage_percent` inside a nested object (with no sibling fields in `PERCENT_KEYS`/`TOTAL_KEYS`/etc.) would silently miss that record.

Adding a small weight for `REMAINING_PERCENT_KEYS` keeps candidate ranking consistent with `deriveUsedPercent`'s lookup order:

```ts
function scoreUsageRecord(record: Record<string, unknown>): number {
  let score = 0;
  if (hasAny(record, PERCENT_KEYS)) {
    score += 4;
  }
  if (hasAny(record, REMAINING_PERCENT_KEYS)) {
    score += 4;
  }
  // …rest unchanged
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(minimax): invert usage_percent when ..." | Re-trigger Greptile}

Landed via temp rebase onto main.

• Gate: OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test src/infra/provider-usage.fetch.minimax.test.ts; pnpm build; live MiniMax text smoke with MINIMAX_API_KEY via @mariozechner/pi-ai
• Land commit: 5c3a250
• Merge commit: 28021a0
• Source commit: jwchmodx@9a02183

I trimmed out unrelated Mattermost/tool-loop commits from the branch and landed only the MiniMax usage fix.

Thanks @jwchmodx.