Use inactive for ignored auth surface state

The second state bullet is mislabeled as active even though the description says the SecretRef is ignored when another auth surface wins or remote auth is disabled, which is the inactive state. In this zh-CN translation, both states now appear as active, so operators cannot distinguish required refs from ignored refs when reading startup/reload diagnostics and may misinterpret whether a reference must resolve.

Useful? React with 👍 / 👎.

The second bullet here is labeled `active` but the English source clearly uses `inactive`:

- `inactive`: the SecretRef is ignored for this runtime because another auth surface wins, or
  because remote auth is disabled/not active.

Since these two bullet points define mutually exclusive states (active vs. inactive), having both labeled `active` is factually incorrect and will confuse readers trying to understand when a credential is active vs. ignored.

This is a comment left during a code review.
Path: docs/zh-CN/gateway/secrets.md
Line: 59-60

Comment:
The second bullet here is labeled `` `active` `` but the English source clearly uses `` `inactive` ``:

```
- `inactive`: the SecretRef is ignored for this runtime because another auth surface wins, or
  because remote auth is disabled/not active.
```

Since these two bullet points define mutually exclusive states (`active` vs. `inactive`), having both labeled `` `active` `` is factually incorrect and will confuse readers trying to understand when a credential is active vs. ignored.

```suggestion
- `inactive`：SecretRef 在该运行时被忽略，因为另一个认证表面获胜，或
  因为远程认证被禁用/未激活。
```

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

Thanks for the review! I've fixed the translation error on line 59 - changed the second 'active' to 'inactive' as suggested.

Match session-key assertions to agent-prefixed format

resolveSessionKey builds keys via buildAgentMainSessionKey, which formats them as agent:<agentId>:<mainKey>, so the regex expecting test-agent:main:... can never match. This makes the new tests fail immediately in CI and blocks the PR despite no runtime regression in the implementation.

Useful? React with 👍 / 👎.

Assert voice wake defaults from current runtime values

normalizeVoiceWakeTriggers falls back to defaultVoiceWakeTriggers(), whose current defaults are openclaw/claude/computer, not hey claw/okay claw. The hard-coded expectation here causes deterministic test failures for undefined/empty/invalid input cases, so this commit introduces a broken test suite rather than validating behavior.

Useful? React with 👍 / 👎.

Stop importing non-exported cron helpers

server-cron.test.ts imports trimToOptionalString, redactWebhookUrl, resolveCronWebhookTarget, and buildCronWebhookHeaders, but src/gateway/server-cron.ts does not export these symbols. In ESM this causes a module-link error (does not provide an export named ...), so the test file cannot execute and CI fails before any assertions run.

Useful? React with 👍 / 👎.

Mock tailnet exec with the expected stdout shape

resolveTailnetDnsHint forwards exec into getTailnetHostname, which reads stdout from the exec result object. This mock resolves to a plain string, so stdout is undefined and the function falls into the error path, making the hostname expectation fail deterministically.

Useful? React with 👍 / 👎.

Match webhook URL assertion to actual normalization behavior

resolveCronWebhookTarget uses normalizeHttpWebhookUrl, and that helper currently returns the trimmed input string (it does not lowercase scheme/host). With input HTTP://EXAMPLE.COM/WEBHOOK, the result stays uppercase, so this assertion is guaranteed to fail.

Useful? React with 👍 / 👎.

Fix undefined-format expectation in formatError test

formatError returns JSON.stringify(err, null, 2) for non-error/non-string values, and JSON.stringify(undefined) returns undefined (not the string "undefined"). This expectation cannot pass with the current implementation, so it introduces a deterministic test failure.

Useful? React with 👍 / 👎.

Configure SecretRef provider defaults correctly in test setup

This setup puts "my-password": "resolved-password" under secrets.defaults, but that field only defines provider aliases (env/file/exec), not secret values. As a result, ${SECRET:my-password} still resolves through the env provider and, with env: {}, resolveGatewayPasswordSecretRef rejects instead of returning "resolved-password", so the new resolution tests fail deterministically.

Useful? React with 👍 / 👎.

Use supported envelope fixtures in sanitize assertions

stripEnvelopeFromMessage only strips recognized leading envelope headers via stripEnvelope (channel/timestamp forms), not inline tokens like [envelope:123] embedded in content. With this fixture the content remains unchanged, so expecting "Hello world" fails and the same pattern causes multiple added cases in this suite to fail.

Useful? React with 👍 / 👎.

Pass an avatar-path value when expecting avatar URL rewrite

resolveAssistantAvatarUrl rewrites to /avatar/<agentId> only when looksLikeAvatarPath(avatar) is true (contains a path separator or image extension). "default-avatar" does not satisfy that predicate, so the function returns the original string and this assertion fails.

Useful? React with 👍 / 👎.

Assert formatError object fallback using JSON output

For non-Error, non-string inputs, formatError first returns JSON.stringify(err, null, 2) when serialization succeeds; it does not call custom toString() methods on plain objects. This object serializes to {}, so expecting "Custom error" is a deterministic mismatch.

Useful? React with 👍 / 👎.

Import beforeEach from vitest before invoking it

The suite calls beforeEach(...) but the symbol is no longer imported from vitest. In this repo’s Vitest setup, test APIs are imported rather than globally enabled, so this leaves beforeEach undefined at runtime and the file fails before assertions execute.

Useful? React with 👍 / 👎.