PR #66111: fix(reply): recognize /trace directives

• Repository: openclaw/openclaw
• Author: MonkeyLeeT
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/66111

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

• Problem: bare /trace and trace-only turns were parsed but never entered shared directive handling in the normal chat reply path.
• Why it matters: channel users, including Feishu, could issue /trace and get no final reply even though trace handling existed.
• What changed: added hasTraceDirective to the directive gate in src/auto-reply/reply/get-reply-directives-apply.ts and added a seam regression test for an authorized Feishu /trace turn.
• What did NOT change (scope boundary): no Feishu transport-specific behavior changed, and no other command semantics were modified.

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 #66034
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

• Root cause: applyInlineDirectiveOverrides only entered directive handling when hasAnyDirective was true, and that gate omitted hasTraceDirective.
• Missing detection / guardrail: coverage existed for handleDirectiveOnly itself, but not for the higher-level applyInlineDirectiveOverrides seam that decides whether directive handling runs.
• Contributing context (if known): the issue was reported on Feishu, but the bug lives in shared reply logic used before channel delivery.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/auto-reply/reply/get-reply-directives-apply.trace.test.ts
• Scenario the test should lock in: an authorized bare /trace message must return the directive-only reply through applyInlineDirectiveOverrides.
• Why this is the smallest reliable guardrail: the bug was in the directive gate above handleDirectiveOnly, so testing the implementation helper alone was insufficient.
• Existing test that already covers this (if any): src/auto-reply/reply.directive.directive-behavior.shows-current-verbose-level-verbose-has-no.test.ts covers trace behavior once directive handling is reached.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• /trace, /trace on, and /trace off now work in the shared channel reply path instead of falling through as ordinary text.

Diagram (if applicable)

Before:
[user sends "/trace"] -> [parsed as trace directive] -> [directive gate ignores trace] -> [no directive reply]

After:
[user sends "/trace"] -> [parsed as trace directive] -> [directive gate includes trace] -> [current trace level reply]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• 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:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local repo checkout
• Model/provider: N/A
• Integration/channel (if any): Feishu symptom, shared reply pipeline fix
• Relevant config (redacted): text commands enabled

Steps

1. Start from a session where text commands are authorized.
2. Send bare /trace.
3. Observe whether the reply pipeline returns the directive status reply.

Expected

• Reply includes Current trace level: ....

Actual

• No directive reply was queued because the shared directive gate skipped trace-only directives.

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: ran pnpm test src/auto-reply/reply/get-reply-directives-apply.trace.test.ts src/auto-reply/reply.directive.directive-behavior.shows-current-verbose-level-verbose-has-no.test.ts and confirmed both files passed.
• Edge cases checked: bare /trace, plus existing /trace on and /trace off behavior coverage.
• What you did not verify: live Feishu delivery against a real channel.

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:

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

• Risk: trace-only turns now enter the same directive pipeline as other inline directives, which could expose any hidden assumptions in channel-specific callers.
  • Mitigation: added a seam regression at applyInlineDirectiveOverrides and kept the code change to a single missing directive flag.

Changed files

• src/auto-reply/reply/get-reply-directives-apply.trace.test.ts (added, +119/-0)