Conversation
added 30 commits
August 27, 2026 11:48
TradingBotV18/LunaBot-specific names (board IDs, script paths, test fixtures) leaked into files headed for the public repo. Replace with the same generic placeholders (ExampleProject/ExampleApp/tools/project.py) already used elsewhere in this codebase for this exact purpose.
Replace NousResearch#96637's inline active_profile_homes() closure with NousResearch#96508's module-level _existing_profile_homes() filter (testable in isolation). Widen _ensure_cron_dir from 3 to 12 mkdir sites across cron/ so every directory creation fails closed for deleted named profiles, not just the 3 originally protected. Add _is_named_profile_path() that checks 'profiles' in path parts (works for subdirs like cron/output/<job> and scripts/ that the original parent.name heuristic couldn't reach). Co-authored-by: misterdas <das7514@gmail.com>
Check both resolved and unresolved path parts so a symlinked named profile (e.g. profiles/dev -> /mnt/data/dev) is still detected. Also use _ensure_cron_dir for output_dir in ensure_dirs() for consistency. Simplify-code Phase 2 finding (medium severity).
Live on both providers (verified 2026-08-28 against openrouter.ai/api/v1/models and inference-api.nousresearch.com/v1/models) but absent from both curated picker lists. Adds the entry directly below qwen3.8-max per newest-first family ordering, an explicit 1M DEFAULT_CONTEXT_LENGTHS entry (new family slug would otherwise fall through to the generic qwen 131072 catch-all — same class as NousResearch#69881), and regenerates model-catalog.json. Scoped rollout: only the named providers touched. Pricing snapshot skipped (both routes bill via official_models_api live pricing). Reasoning floor already fires via the qwen3 prefix entry (180s, verified).
…cker/ssh/modal backends (closes NousResearch#96873) (NousResearch#96991)
…load_config Test-pollution class: runtime_provider is usually imported lazily (inside switch_model's resolution path), so its first import in a pytest worker can happen while a test has hermes_cli.config.load_config patched. The module-level from-import then bound the MagicMock permanently — after the patch exited, every later caller in the process silently read the dead test's config. Live victim: MoA aggregator context-length resolution (resolve_runtime_provider -> AuthError 'Unknown provider custom:example'), making TestMoAContextLength::test_moa_custom_context_configures_compressor_threshold fail whenever it shared a process with TestLocalOllamaModelDiscovery::test_switch_model_on_current_ollama_custom_endpoint_keeps_base_url. Fix: load_config / get_compatible_custom_providers / normalize_extra_headers become late-bound delegates resolving hermes_cli.config attributes at call time. Both patch targets (config.load_config and runtime_provider.load_config) keep working. Regression tests pin the late-binding property and fail if the delegates revert to from-imports (sabotage-verified).
No Anthropic API key is configured for this install, so the built-in default-model catalogs (openai provider list, MOA reference/aggregator defaults, example configs, docstrings) still pointed at claude-* models that can never actually be reached. Point them at the equivalent openai-codex/gpt-5.5 models instead so a fresh setup doesn't default to a dead provider. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
added 2 commits
August 28, 2026 12:18
…upgrade-refreshed-20260827 # Conflicts: # tools/skills_guard.py
…upgrade-refreshed-20260827
Author
|
Fair concern, and noted for how I structure future PRs. This one isn't a good shape: the actual Kanban worker-context fix is a small, focused change (the original top commit), but the branch also carries this fork's full sync onto current upstream I don't have merge rights here, so I can't land the sync commit on its own to shrink this diff down to just the real change without either duplicating it across every other open PR from this fork or rebasing everything onto a landed sync first. Happy to point at the exact commit range that's the actual fix if that helps review, or take direction on how you'd rather these be structured going forward. |
_PROVIDER_STALL_RE only matched "waiting on ... no output yet", "unresponsive", "consecutive stale attempts", and "auto-reconnect" -- none of which match a live-observed failure mode where a provider connection drops mid-call and forces a full session reinitialize instead of a clean retry. The worker restarts from a fresh "Initializing agent..." banner every cycle and never accumulates enough of one turn to make progress, independent of its runtime budget, so the existing provider_stall_loop watchdog category (enabled via kanban.worker_watchdog.enabled) could never catch it.
Live false positive (2026-08-28): kanban workers across several unrelated tasks were hitting "LLM egress blocked: base64_payload" on ordinary system-prompt text, not secrets. Traced to _canonical_base64_candidate() -- any base64-alphabet string whose length is a multiple of 4 round-trips through decode/encode trivially, so short all-caps prose words (USER, MESSAGE, THIS, PATH -- e.g. from a "USER MESSAGE" section header) were getting flagged the same way a real encoded secret would. The existing short-word exclusion only covered lowercase/mixed-case alphabetic words (not all-uppercase), and the codebase already has a curated exact-token allowlist (_PROTOCOL_GRAMMAR_ATOMS) for exactly this class of false positive -- it already carries "user" (lowercase) plus other common uppercase prose words (HEAD, LAST, MUST, NOTE, ONLY). Added the four observed tokens there rather than broadening the isupper() exclusion: an earlier attempt at a blanket `candidate.isalpha()` exclusion regressed test_canonical_base64_payloads_are_rejected_even_when_decoded_content_is_benign because "AQID" (a genuine intentional encoding of b"\x01\x02\x03") is also purely alphabetic -- confirming the shape-based round-trip check is deliberately content-blind, so the fix has to be an exact allowlist entry, not a broadened case rule. This does not resolve the underlying structural issue (round-trip alone has near-zero discriminating power for any length-%4==0 alphabet-valid string) -- longer snake_case identifiers and path fragments still round-trip and can still trigger a block. That needs real design attention beyond an allowlist patch. Verification: 104 passed (test_llm_egress_firewall.py, full suite).
…nconditionally Live incident (2026-08-28): kanban.max_in_progress_per_model only counted tasks with an explicit provider_override/model_override. Most tasks just run their assignee's profile default, so the cap was silently a no-op for them -- and after fixing an unrelated routing bug, ~14 profiles all correctly resolving to the same single-concurrency local Ollama server (-np 1) started genuinely contending, timing out, and repeatedly re- blocking. The fallback that resolves a profile's local route for this accounting already existed (_resolve_local_first_route, explicitly documented as pure/read-only) but was gated behind kanban.local_first -- a flag that controls a different concern (local-route SUBSTITUTION preference at spawn time, which has its own history of surprises) than whether we accurately count what a task will actually run for capacity purposes. Made the fallback resolution unconditional; local_first's actual spawn-time substitution behavior is untouched. Also lowered max_in_progress_per_model 2 -> 1 in config.yaml to match the local server's real capacity (still per (provider, model) tuple, so cross-model contention on the same shared server is a known remaining gap, not fully closed by this alone). Added a regression test that specifically omits kanban.local_first to prove the fix doesn't depend on that flag (the existing local-route test happened to set it, which didn't actually exercise the new unconditional path). Verification: 6 passed (test_kanban_per_model_cap.py), 72 passed / 1 skipped (test_kanban_db.py + test_kanban_host_cap.py + test_kanban_blocked_sticky.py + test_kanban_memory_guard.py, serial).
…upgrade-refreshed-20260827
…the local_first resolver The per-model dispatch cap's fallback-resolution path reused _resolve_local_first_route for every unoverridden task regardless of kanban.local_first. That resolver's job is to find the first local route anywhere in a profile's config chain (primary, fallback_model, fallback_providers) for the separate local-first substitution feature -- not to report what a task will actually run. Live incident, 2026-08-28: six profiles were rebalanced onto openai-codex primaries for concurrency, each keeping ollama-launch/qwen3.5:4b as a sole fallback entry. With local_first off (the default -- no substitution happens), those tasks genuinely run on codex, but the resolver still reported their local fallback, miscounting them against Ollama's already-saturated cap and starving unrelated ready work that was never going to touch Ollama at all. Branch on local_first_enabled instead of ignoring it: substitution-on still uses _resolve_local_first_route (that IS what will run), but substitution-off now reads the profile's own model.provider/default directly, matching what actually gets dispatched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…rency local servers kanban.max_in_progress_per_model is one global scalar applied uniformly to every (provider, model) pair. That's fine for remote providers with no real concurrency ceiling, but the local llama-server behind ollama-launch runs with -np 1 -- one concurrent request, period. With the global cap at 4 (raised earlier today to unstall codex-shared profiles), up to 4 tasks were dispatching concurrently against the same local model and crashing each other with "No response for 180s, Reconnecting" -- exactly what took down t_66b176f0. Add kanban.max_in_progress_by_model, a dict of "provider/model" -> cap that tightens (never loosens) the global default for specific pairs, mirroring the existing max_in_progress_by_profile pattern. Configured ollama-launch's two local models to 1 each; every other (provider, model) pair keeps the global default of 4. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…emote-provider call Live incident, 2026-08-28: moving 22 profiles from ollama-launch (a local, loopback destination) to nous/upstage/solar-pro4:free (genuinely remote) exposed them to egress content scanning for the first time -- and every single one failed on message 1, before any real reasoning happened. Two distinct false-positive classes, both in content shared across nearly every profile (tool/skill descriptions, AGENTS.md): 1. base64_payload: the "ordinary word" exemption in _canonical_base64_candidate only covered lowercase-alpha words and a few narrow structural shapes, missing kebab-case tool/skill slugs (systematic-debugging), snake_case function names (get_symbols_overview), bare small integers (1800, 8787), and common all-caps emphasis words (TODO, WAIT, SKIP) -- all of which happen to round-trip as valid unpadded Base64. Widening the general exemption regex initially broke two existing tests that deliberately verify arbitrary kebab/snake-shaped strings are NOT blanket-exempted (only specifically vetted atoms) -- reverted that approach and added each discovered token to _PROTOCOL_GRAMMAR_ATOMS instead, consistent with the file's existing per-atom philosophy. Also widened _BOUNDED_SLASH_WORDS to accept mixed-case segments and a bare trailing slash (GitHub org/repo slugs, vault paths), fixing an off-by-one in the first attempt that accidentally made the slash requirement optional (caught by the AQID short-secret regression test). 2. secret_detected: AGENTS.md documented the PTY WebSocket auth query param as `?token=…` and pip's git-URL commit-pinning syntax as `git+https://...@<sha>` -- both are exactly the shapes the strict provider-egress redactor (_STRICT_URL_PARAM_RE, _STRICT_URL_USERINFO_RE) is deliberately built to catch, by design, for any real leaked credential. No placeholder text avoids the match since the check is shape-based, not value-based, so rephrased both passages in prose instead of weakening the redactor. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…nto hermes/live-worktree-upgrade-refreshed-20260827
mrkillbob
changed the title
This was referenced Aug 29, 2026
Author
|
Superseded as a cumulative upgrade train, including the fork/worktree sync called out in review. Focused replacements are #97866 (egress), #97868 (worker lifecycle/worktrees), #97869 (PR-feedback), and #97870 (specialist discovery), with their parent PRs linked in each description. The source branch is retained; no commits were deleted or force-pushed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This branch contains the Hermes safety and worker-lifecycle fixes split into four focused commits:
881a688996— bounded, sanitized matched terminal output may reach protected cloud workers; unmatched or forged output, secrets, private paths, encoded payloads, oversize payloads, and receipt failures remain blocked.6670e27e4d— preserve Kanban worker lifecycle and worktree environments, including terminal-transition enforcement.7bdfc37d3c— harden GitHub PR-feedback receipts and pooled worktree leases.7c248ba86f— preserve terminal truth and partial progress for PR-feedback workflows.No trading or live-execution code is changed. The local Hermes routing/profile/cron tuning is intentionally operator configuration under
~/.hermes, not repository state.Verification
BENCH_OKgit diff --check: cleanThe branch is based on the current upstream review branch and is ready for maintainer review.