Skip to content

diagnose: stderr-direct WARNs + conv-loop entry diag (refs #133)#136

Merged
PowerCreek merged 1 commit into
mainfrom
stderr-diagnostic-and-defense-133
May 27, 2026
Merged

diagnose: stderr-direct WARNs + conv-loop entry diag (refs #133)#136
PowerCreek merged 1 commit into
mainfrom
stderr-diagnostic-and-defense-133

Conversation

@PowerCreek

Copy link
Copy Markdown

Switches v0.18.7's logger.warning diagnostics to stderr-direct sys.stderr.write() so they always appear in 2>&1 captures. Adds conv-loop entry diagnostic just before the structural_empty guard. With 4 diagnostic lines emitted per response, operator can pinpoint exactly which layer drops the tool_calls. 39 tests green.

…p entry diag (refs #133)

Operator confirmed v0.18.7's logger.warning WARNs didn't appear in
``2>&1 | tee`` captures from the sandbox session. Either hermes
logging config routes the warning logger to a non-stderr sink, or
PYTHONPATH loads logging config from a different install than
transports/. Bypassing both via direct ``sys.stderr.write()``.

Also: sandbox wire-shape evidence (gist ada0e8370086) confirms
codestral emits PERFECT response (finish_reason=tool_calls,
content="" but not null, tool_calls_count=2 with type=function +
valid ids + function blocks). Hermes still treats as empty. The
swallow point is somewhere in the normalize chain OR the
conversation_loop's pre-line-3180 path.

## Changes

### chat_completions.py

- New ``_diag(msg)`` helper writes ``[hermes-diag] {msg}\n`` to
  ``sys.stderr`` directly + flushes. Bypasses logger config.
- normalize_response entry/recovery/exit diagnostics switched
  from ``logger.warning`` to ``_diag``.
- Entry diagnostic enhanced with per-tool-call shape preview
  (first 3 tool_calls: ``name:id:type=...``) so we can see
  EXACTLY what the SDK gave us at this layer.

### conversation_loop.py

- Added stderr-direct entry diagnostic in the empty-response
  detection block (just before the structural_empty guard).
  Logs: ``assistant.tool_calls=N finish_reason=R truly_empty=BOOL
  has_structured=BOOL tools_attached=BOOL prior_was_tool=BOOL
  model=M``.
- This is the first place we can see what the LOOP sees after
  normalize_response returns. If ``assistant.tool_calls=0`` here
  but ``normalize_response exit`` showed >0, the bug is between
  the two.

## Smoking-gun chain

Operator runs sandbox repro and captures the 4 diagnostic lines:

1. ``normalize_response entry: sdk_tool_calls=N ... shapes=[...]``
2. ``normalize_response recovery: ...`` (only if entry was 0)
3. ``normalize_response exit: tool_calls=N ...``
4. ``conv-loop empty-check: assistant.tool_calls=N ...``

The pattern of values across these 4 lines pinpoints the swallow
layer.

## No behavior change

Pure observability ship. The structural-empty guard is unchanged
(still requires finish_reason==stop). If operator's evidence
shows finish_reason=tool_calls reaches the conv-loop empty-check,
that's a contradiction in the conditions and a separate bug.
@PowerCreek PowerCreek merged commit 497b9e6 into main May 27, 2026
@PowerCreek PowerCreek deleted the stderr-diagnostic-and-defense-133 branch May 27, 2026 06:44
PowerCreek added a commit that referenced this pull request May 28, 2026
…143) (#145)

T3 of the #143 thin-client refactor scope. When the active provider
is ``devagentic-local``, augment ``disabled_toolsets`` with
``"clarify"`` before the ``get_tool_definitions`` call.

## Rationale

Per devagentic#203 §1.3 + the #143 scope: devagentic-side intent
classifier knows when clarification is actually needed and can
surface it via an OpenAI-shaped assistant message. Hermes' modal
TUI clarify-tool was a layered opinion fighting devagentic-side
classification — both rotation's debug evidence + sandbox UX
showed the dual-source as confusing (clarify modal popped even
with --yolo, ignoring devagentic-side intent signals).

This is the smallest of the T1-T3 sequence and the cleanest
revert path — purely a tool-registry adjustment for one provider.

## Behavior

| Setting | Before | After |
|---|---|---|
| provider=devagentic-local, no --enable-toolset | clarify enabled | clarify implicitly disabled |
| provider=devagentic-local, --enable-toolset clarify | clarify enabled | clarify enabled (explicit override) |
| provider=other | unchanged | unchanged |

A boot-line print informs operators of the implicit disable + how
to re-enable for legacy workflows. Composes naturally with the
existing ``HERMES_TOOLS_SUBSET`` narrowing (#75/#87) — disable
happens first, then subset narrows further if set.

## Tests

- 4 source-level tests in
  ``tests/agent/test_t3_clarify_default_out.py``: patch-landed,
  explicit-enable-overrides-implicit-disable, re-enable hint
  visible in print message, strict-equality on provider name
  (no prefix/alias matching to avoid surprise on related
  providers).
- 21 total green across affected suites (T3 + diag-env-gate).

## Composition

Per #143 sequencing (T3 → T1 → T2-gated → T2-default-flip):
- This PR: T3 (clarify default-out)
- Next: T1 (HERMES_DEFER_PERSONA default-flip for devagentic-local)
- Then: T2 (empty-content recovery removal, env-gated then default)
- Later: T4-T6 (tool list / iteration cap / summary fallback)

## Preserved through the refactor

- PR #119 (cascade_exhausted short-circuit) — hermes correctly
  deferring to devagentic; NOT recovery
- PR #122/#125 (raw tool_calls fallback) — pre-recovery wire
  parsing; belt-and-suspenders against future streaming-chunker
  regressions
- PR #131/#136/#138/#141 diagnostics — env-gated via
  HERMES_DIAG_RAW_CAPTURE; no-op when off
PowerCreek added a commit that referenced this pull request May 28, 2026
…MPTY_RECOVERY (refs #143) (#147)

T2 of the #143 thin-client refactor scope. Devagentic-side cascade
(NousResearch#324) + runaway detector (NousResearch#345-348) + exec-terminus (NousResearch#349-354)
now cover the empty-content recovery layer with full intent /
role / dispatch-trace context. Hermes-side recovery layered on top
caused 3×4 dispatch stacking (#118) + mode confusion + invisible
swallow points (#133 debug funnel).

This patch default-flips: the four hermes-side recovery paths are
short-circuited unless ``HERMES_LEGACY_EMPTY_RECOVERY`` is set to
a truthy value. Legacy users opt-in to keep the pre-T2 behavior.

## Gated paths (all skipped when env unset)

| Path | Source | Loc |
|---|---|---|
| ``_finish_wants_tools`` synthetic recovery | PR #108 / #99 | line ~3618 |
| ``_post_tool_empty_retried`` nudge | pre-existing NousResearch#9400-class | line ~3749 |
| ``_structural_empty`` synthetic recovery | PR #69 / #67 | line ~3880 |
| 3-retry empty-content loop | pre-#67 | line ~3927 |

When env unset (default), empty responses fall through to either
the fallback-chain provider switch (if configured) or the clean
``(empty)`` terminal with ``_empty_terminal_sentinel=True``.

## Preserved through T2 (verified by test_t2_legacy_empty_recovery_gate.py)

- **PR #119 cascade_exhausted short-circuit** — hermes correctly
  deferring to devagentic's sentinel; NOT recovery. Source-level
  test asserts the ``if _cascade_err:`` block is NOT prefixed by
  ``_legacy_recovery_on``.
- **PR #122/#125 raw tool_calls fallback** — pre-recovery wire
  parsing in transports/chat_completions.py. Source-level test
  asserts the helper name doesn't appear in conversation_loop
  (lives elsewhere; untouched).
- **PR #131/#136/#138/#141 diagnostics** — env-gated via
  ``HERMES_DIAG_RAW_CAPTURE`` (#140), independent of this env.

## Operator deploy

Default behavior changes: empty responses surface cleanly (no
synthetic re-prompt). To preserve pre-T2 behavior:

```bash
export HERMES_LEGACY_EMPTY_RECOVERY=1
```

The legacy escape hatch is intended as a temporary safety net
while operators validate the thin-client architecture. Once the
devagentic-side cascade is universally deployed + observed to
cover all empty-content cases, the legacy gate can be removed in
a follow-up (the env var stays as a no-op for backward compat).

## Tests

- 23 new tests in
  ``tests/agent/test_t2_legacy_empty_recovery_gate.py``:
  resolver default-false / empty-false / 6 truthy / 6 falsy-or-
  unknown; source-level gate assertions for each of the four
  recovery branches; preserved-path assertions for cascade_exhausted
  + raw tool_calls fallback location; default-off + opt-in
  resolver round-trip.
- 163 total green across affected suites (T2 + existing empty-
  terminal mirror tests + finish_reason_tools_recovery +
  cascade_exhausted + internal_marker_stripping +
  tool_call_type_default + tool_use_enforcement + T3 + T1 persona
  + doctor persona probe).

## Composition

Per #143 sequencing:
- T3 / PR #145 (clarify default-out) — merged ✓
- T1 / PR #146 (persona default-flip) — merged ✓
- **T2 / this PR (empty-content recovery removal, env-gated)**
- Later: T4-T6 (tool list / iteration cap / summary fallback)

The legacy escape hatch design choice (vs. full removal) lets
operators roll back per-deployment if a previously-recovered edge
case surfaces in the field. Diagnostic from #140
(HERMES_DIAG_RAW_CAPTURE) remains the observability tool to spot
any uncovered case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant