Summary

• Problem: Discord config/status paths used strict token normalization, so unresolved SecretRef bot tokens threw before they could be represented as configured-but-unavailable.
• Why it matters: SecretRef-backed Discord configs could fail read-only/status handling instead of showing the operator that the token is configured but unavailable.
• What changed: Discord token resolution now carries tokenStatus, uses inspect-mode SecretRef handling for config/status paths, and reports configured_unavailable in snapshots.
• What did NOT change (scope boundary): Runtime startup still requires an available token and will not start Discord with an unresolved/empty token.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: Discord token resolution used strict normalizeResolvedSecretInputString for unresolved SecretRef config values, which throws before read-only status/config paths can preserve configured credential metadata.
• Missing detection / guardrail: Discord tests covered the strict throw behavior but did not cover the configured_unavailable status snapshot path for unresolved token SecretRefs.
• Contributing context (if known): N/A

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: Discord token, client, shared plugin-base, and channel contract tests.
• Scenario the test should lock in: unresolved Discord token SecretRefs report configured_unavailable in status snapshots while runtime startup remains gated on available tokens.
• Why this is the smallest reliable guardrail: it exercises the token resolver and plugin config boundary where the incorrect strict behavior occurred.
• Existing test that already covers this (if any): existing Discord SecretRef/action discovery tests covered adjacent read-only behavior.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Discord status/config-only surfaces can now show a Discord bot token SecretRef as configured but unavailable instead of throwing during read-only token inspection. Runtime startup still requires a resolved token.

Diagram (if applicable)

Before:
[Discord token SecretRef unresolved] -> [strict token read] -> [throw]

After:
[Discord token SecretRef unresolved] -> [inspect token read] -> [configured_unavailable snapshot]
[Discord runtime startup] -> [requires available token] -> [does not start with empty token]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) Yes
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: SecretRef inspection now preserves configured_unavailable metadata without resolving or exposing secret values; runtime startup remains gated on an available token.

Repro + Verification

Environment

• OS: Linux
• Runtime/container: local source checkout
• Model/provider: N/A
• Integration/channel (if any): Discord
• Relevant config (redacted): Discord token configured as SecretRef

Steps

1. Configure channels.discord.token or channels.discord.accounts.<id>.token as an unresolved SecretRef.
2. Build Discord account/status snapshot data.
3. Attempt runtime startup without a resolved token.

Expected

• Read-only/status paths report tokenStatus: "configured_unavailable".
• Runtime startup/configured checks require an available token.

Actual

• Before this change, strict normalization threw for unresolved Discord token SecretRefs.
• After this change, status preserves configured_unavailable while startup remains unavailable until the token resolves.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: unresolved SecretRef token status, blank account token fallback behavior, client missing-token behavior, Discord extension suite, channel contracts, extension typechecks, changelog attribution.
• Edge cases checked: account-scoped unresolved SecretRef, top-level unresolved SecretRef, explicit blank account token, runtime configured gating.
• What you did not verify: full repo-wide pnpm build && pnpm check && pnpm test; live Discord network behavior for this exact branch.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: Status may mark a token as configured even when the secret value is unavailable.
  • Mitigation: The snapshot includes tokenStatus: configured_unavailable, and runtime startup still requires tokenStatus: available.

AI-assisted: yes, prepared with Codex and locally reviewed.