{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "Contribution Compass",
  "home_page_url": "https://amk9978.github.io/contribution-compass/",
  "feed_url": "https://amk9978.github.io/contribution-compass/feed.json",
  "description": "Important OSS updates and evidence-backed contribution leads.",
  "items": [
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85510",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/9/#signal-59cbdf51801e",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85510",
      "title": "[Hermes Agent] fix(xai): preserve xhigh effort and priority service_tier for Grok 4.6",
      "content_text": "## Summary Grok 4.6 is the first xAI Responses model to accept `reasoning.effort=xhigh` and xAI Priority Processing (`service_tier`), but Hermes' provider-wide xAI guards silently clamped xhigh→high and stripped `service_tier` for every Grok model — so 4.6 users were silently downgraded. This model-gates both guards on the 4.6 family and exposes the `/fast` toggle for it. Fixes #84799. Salvages #84820 by @fangliquanflq (cherry-picked, authorship preserved), the tighter of two competing fixes (exact-slug family matcher + priority-value check on the service_tier preserve). #84848 by @Chukwuebuka-2003 was submitted 1h21m later with the same coverage — both credited; we carried over its docstring line for `resolve_fast_mode_overrides` as a follow-up commit. ## Changes - `agent/model_metadata.py` (@fangliquanflq): `is_grok_46_family()` matcher. - `agent/transports/codex.py` (@fangliquanflq): xhigh clamp and `service_tier` strip both model-gated on the 4.6 family. - `hermes_cli/models.py` (@fangliquanflq): `/fast` toggle exposed for Grok 4.6 (`model_supports_fast_mode`), falls through to `{\"service_tier\": \"priority\"}`. - Tests (@fangliquanflq): transport preserve/strip/clamp matrix + fas",
      "date_published": "2026-08-13T17:58:39Z",
      "date_modified": "2026-08-13T18:02:12Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:82581",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/3/#signal-6bb5e0c57d96",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/82581",
      "title": "[Hermes Agent] fix(tools): isolate subprocess Python environments (#74817)",
      "content_text": "## Summary Remove Hermes-owned runtime contamination while preserving user-owned `PYTHONPATH` semantics. This consolidates and builds on #78917, incorporates the follow-up correctness work from Yiipu/hermes-agent#1, and rebases the complete attributed history onto main at `f4c2c263f0672a4b1485f3071cd5f79cd32d38ab`. ## Rebase onto main at f4c2c263f (#84500 reconciliation) Rebased onto main at `f4c2c263f`; conflicts were confined to the `PYTHONPATH` composition region in `tools/code_execution_tool.py`: upstream #84500 (`fix(tools): isolate external project environments`) had reworked the exact block this PR touches. The reconciliation preserves **both** fixes — inherited-PYTHONPATH sanitization is applied to the scrubbed child environment **before** the conditional composition, which keeps the staging `tmpdir` first, re-adds the Hermes repo root only for same-Hermes-environment children, and omits it for external project interpreters. #84500's interpreter-probe machinery is untouched, and its regression suites (`test_code_execution_modes.py`, `test_code_execution.py`, `test_code_execution_windows_env.py`) pass unmodified. The Windows-native test now uses the registered `@pytest.mark.",
      "date_published": "2026-08-09T16:03:32Z",
      "date_modified": "2026-08-13T18:02:10Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/tools",
        "tool/code-exec",
        "backend/local",
        "P2",
        "sweeper:risk-compatibility"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 4
      }
    },
    {
      "id": "2026-08-13:github:astral-sh/uv:pull_request:21097",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/developer-infrastructure/uv/page/2/#signal-937b77abb54d",
      "external_url": "https://github.com/astral-sh/uv/pull/21097",
      "title": "[uv] Fix relative indexes in PEP 723 scripts",
      "content_text": "## Summary Relative indexes in PEP 723 scripts were resolved against the current working directory instead of the script's directory, so a script could work when ran from its own directory but fail when ran from elsewhere. This change resolves inline indexes relative to the script and also makes `uv add --script` write index paths relative to the script. It also applies the same behavior to extra build dependencies Fixes #21096 ## Test Plan - Added an offline regression test that runs a script with a relative index from another directory - Ran the focused project and sync tests - Ran Clippy and rustfmt",
      "date_published": "2026-08-13T17:56:29Z",
      "date_modified": "2026-08-13T18:02:04Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "astral-sh/uv",
        "group": "developer-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85508",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/9/#signal-399d9316c3f5",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85508",
      "title": "[Hermes Agent] fix(cron): honest fallback/timeout/drift alerts + drift-guard alert-once",
      "content_text": "Cron failure alerts stop lying about fallback chains, timeouts, and drift — and drift alerts fire once per job instead of once per tick. Salvage of #85011 (@victor-kyriazakos), which itself carries #81579 (@georgell-ceo); reconciled with #72056 (@sashmatash), the earliest submission of the drift-alert-delivery half. All contributor authorship preserved via cherry-pick. ## Changes - `cron/scheduler.py`: `_fallback_chain_phrase()` distinguishes \"no chain configured\" (with the fix commands: `hermes fallback add`, or `cron.model` + `cron.model_provider`) from genuine exhaustion (#81579 + #85011). - `cron/scheduler.py`: the scheduler's own inactivity watchdog (`idle for Ns (limit Ns)`) is classified before the generic timeout match instead of being reported as a provider timeout (#81579). - `cron/scheduler.py`: sibling site widened — the TERMINAL_CWD lock-wait `TimeoutError` (#79768) also no longer falls through as \"provider timeout\" (our follow-up; gap flagged in #81579 review). - `cron/scheduler.py` + `cron/jobs.py`: #44585 drift-guard skips alert once per job via a persisted `drift_alerted` bit with a `:silent` marker (same shape as the blocked-config preflight, #73506); cleared on t",
      "date_published": "2026-08-13T17:58:34Z",
      "date_modified": "2026-08-13T18:01:56Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85511",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/9/#signal-b7150e063c70",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85511",
      "title": "[Hermes Agent] fix(tools): symlink-safe exclusive creation for all spill/cache writers",
      "content_text": "## Summary Spill-file writes can no longer be redirected through a planted symlink, and raw pre-redaction spills are now owner-only instead of world-readable. Root cause: all four spill/cache writers (terminal overflow tee, hook context spill, web_extract full-text store, subagent summary spill) used plain `open()`/`Path.write_text` into predictable directories under `~/.hermes` — which follows a pre-existing symlink, so any local process able to write to those directories could divert our write onto an arbitrary user-owned file (`~/.bashrc`, `authorized_keys`, ...). Terminal and hook spills — which hold raw output BEFORE secret redaction — also landed world-readable under the default umask. ## Changes - `tools/spill_safety.py` (new): `ensure_spill_dir` / `open_exclusive` / `write_text_exclusive` — create with `O_CREAT|O_EXCL|O_NOFOLLOW` (a link-shaped path fails the write instead of following it); overwrite goes through lstat-checked unlink + exclusive re-create, so it removes only the link, never touches its target, and cannot be raced. Two tiers: `private=True` forces `0o700` dir / `0o600` file. - `tools/environments/base.py`: terminal overflow tee → private + exclusive. - `tool",
      "date_published": "2026-08-13T17:59:22Z",
      "date_modified": "2026-08-13T18:01:54Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:cilium/cilium:pull_request:47854",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/platform-infrastructure/cilium.html#signal-de52e08b2b90",
      "external_url": "https://github.com/cilium/cilium/pull/47854",
      "title": "[Cilium] k8s: migrate from legacy config to ClusterInfo",
      "content_text": "Migrate the functions exposed from the k8s package to use the ClusterInfo struct to depends less on the legacy config. Sorry for the many codeowners involved, those k8s functions are called in a bunch of places unfortunately :sweat_smile:. I prepared this commit using AIL-2",
      "date_published": "2026-08-08T16:54:06Z",
      "date_modified": "2026-08-13T18:01:51Z",
      "tags": [
        "pull_request",
        "area/k8s",
        "area/clustermesh",
        "release-note/misc"
      ],
      "_contribution_compass": {
        "project": "cilium/cilium",
        "group": "platform-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 11
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:107637",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/5/#signal-4f581e5b09d0",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/107637",
      "title": "[ClickHouse] Merge filters into join during join reordering",
      "content_text": "<!-- Linked issues and pull requests. Use full GitHub URLs, one relationship per line; delete the lines you don't need. Closes: https://github.com/ClickHouse/ClickHouse/issues/NNNNN (auto-closes the issue when this PR is merged into the default branch) Related: https://github.com/ClickHouse/ClickHouse/pull/NNNNN --> ### Changelog category (leave one): - Improvement ### Changelog entry (a [user-readable short description](https://github.com/ClickHouse/ClickHouse/blob/master/docs/changelog_entry_guidelines.md) of the changes that goes into CHANGELOG.md): * Added a new setting `query_plan_merge_filters_into_join` that allows merging `Filter` steps into the `JOIN` step during join reordering, so `WHERE` predicates participate in join order optimization",
      "date_published": "2026-06-16T15:25:08Z",
      "date_modified": "2026-08-13T18:01:48Z",
      "tags": [
        "pull_request",
        "pr-improvement"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 6
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114673",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/12/#signal-a933b7516e14",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114673",
      "title": "[ClickHouse] Read a subcolumn of an `ALIAS` parent through a `Merge` table instead of a default",
      "content_text": "<!-- Linked issues and pull requests. Use full GitHub URLs, one relationship per line; delete the lines you don't need. Related: https://github.com/ClickHouse/ClickHouse/pull/112975 --> ### Changelog category (leave one): - Bug Fix (user-visible misbehavior in an official stable release) ### Changelog entry (a [user-readable short description](https://github.com/ClickHouse/ClickHouse/blob/master/docs/changelog_entry_guidelines.md) of the changes that goes into CHANGELOG.md): Fix reading a subcolumn (`.size0`, `.null`, a tuple element, `String.size`) through a `Merge` table when the underlying table declares the parent column as `ALIAS`. Such a read returned the type default, and when the parent was selected in the same query it could return the value of an unrelated column. ### Description Selecting `arr.size0` from a `Merge` table returns `0` when the child declares `arr` as an `ALIAS` column, while the same query against the child returns the correct `5`: ```sql CREATE TABLE ag (n UInt64, arr Array(UInt8) ALIAS [1,2,3,4,5]) ENGINE = MergeTree ORDER BY tuple(); INSERT INTO ag (n) VALUES (77); CREATE TABLE mg (arr Array(UInt8), n UInt64) ENGINE = Merge(currentDatabase(), '^ag$'); S",
      "date_published": "2026-08-13T17:59:07Z",
      "date_modified": "2026-08-13T18:01:28Z",
      "tags": [
        "pull_request",
        "pr-bugfix",
        "can be tested"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 1
      }
    },
    {
      "id": "2026-08-13:github:anthropics/claude-code:issue:86466",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/19/#signal-8f87dce88fe0",
      "external_url": "https://github.com/anthropics/claude-code/issues/86466",
      "title": "[Claude Code] [BUG] Can not bypass GIT on Windows Desktop",
      "content_text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? The windows desktop requires git to function. I am an IT professional using Claude to setup IIS. There is absolutely no reason git should be involved and my MSP flat out blocks it on non development boxes. THIS MAKES YOUR TOOL USELESS FOR IT WORK ### What Should Happen? It should allow me to bypass git because I AM NOT WORKING WITH FILES OR CODE ### Error Messages/Logs ```shell ``` ### Steps to Reproduce Login Windows no git ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version Claude Desktop ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell WSL (Windows Subsystem for Linux) ### Additional Information _No response_",
      "date_published": "2026-08-13T17:59:59Z",
      "date_modified": "2026-08-13T18:01:22Z",
      "tags": [
        "issue",
        "invalid"
      ],
      "_contribution_compass": {
        "project": "anthropics/claude-code",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 4
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:41351",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent.html#signal-620b996e750f",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/41351",
      "title": "[Hermes Agent] fix(acp): resolve symlink targets when guarding sensitive edit auto-approval",
      "content_text": "## What does this PR do? The ACP edit-approval guard promises that sensitive files (`.env`, `.ssh`, `.git`, `id_rsa`, `id_ed25519`) always prompt the user, even when a session runs under an autonomous policy (`session` / `workspace_session`). It did not hold for symlinks. `should_auto_approve_edit` resolves the path with `Path(...).resolve()` for the workspace-containment check, but `_is_sensitive_auto_approve_path` inspected only the *unresolved* literal path. So a symlink with a harmless name — e.g. `notes.txt` -> `~/.ssh/authorized_keys`, or `link.txt` -> `.env` inside the workspace — passed the sensitive check and was silently auto-approved, writing straight through to the protected file. A repo can ship such a symlink (git tracks them), so an autonomous editor session could have a secret overwritten without a prompt. Before: `_is_sensitive_auto_approve_path(\"link.txt\")` looks at the name `link.txt`, sees nothing sensitive, returns `False` -> auto-approved. After: the guard also checks `link.txt`'s `resolve()`d target (`.env`), matches the sensitive set, returns `True` -> the edit prompts instead of auto-approving. ## Related Issue N/A ## Type of Change - [x] 🔒 Security fix ## ",
      "date_published": "2026-06-07T15:03:25Z",
      "date_modified": "2026-08-13T18:01:18Z",
      "tags": [
        "pull_request",
        "type/security",
        "comp/acp",
        "area/auth",
        "P2",
        "sweeper:risk-security-boundary",
        "sweeper:blast-moderate"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 15
      }
    },
    {
      "id": "2026-08-13:github:anthropics/claude-code:issue:86467",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/20/#signal-e926a4e00aa8",
      "external_url": "https://github.com/anthropics/claude-code/issues/86467",
      "title": "[Claude Code] Plan mode needs a discuss/debate state that doesn't wipe the plan view",
      "content_text": "**Summary** While in plan mode (after `EnterPlanMode`, with a plan file already drafted), I tried to just discuss the plan in plain text with the user — no tool calls, no edits — before deciding whether to proceed. Two problems: 1. Sending a plain conversational turn while still flagged as \"in plan mode\" caused the harness to re-trigger a \"returning to plan mode\" event on the next turn, which appears to clear/wipe the user's view of the plan content from their screen. 2. The only sanctioned ways to end a turn while in plan mode are `AskUserQuestion` (structured clarification) or `ExitPlanMode` (request approval to execute). There's no third option for \"let's just talk about this plan in freeform prose for a while before deciding anything\" — every path back to normal conversation is framed as either a structured question or an approval request, and `ExitPlanMode` itself carries the connotation of \"approve and go\" even when the user's intent is just to keep debating. **Impact** The user explicitly asked to discuss/debate a plan conversationally multiple times. Each attempt either wiped their view of the plan or funneled back toward an approval prompt they hadn't asked for, causing vi",
      "date_published": "2026-08-13T18:00:06Z",
      "date_modified": "2026-08-13T18:01:15Z",
      "tags": [
        "issue",
        "enhancement",
        "area:core"
      ],
      "_contribution_compass": {
        "project": "anthropics/claude-code",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 4
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:37977",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent.html#signal-30727e1acf92",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/37977",
      "title": "[Hermes Agent] fix(plugins): require renewed review before plugin updates",
      "content_text": "## Summary Plugin updates now use a staged review transaction instead of modifying an enabled plugin in place. - Copy the installed Git plugin into a private quarantine directory and fast-forward only the staged copy. - Validate the manifest and exact old/new commits, compute a deterministic staged-content hash, inventory changed files, and run the existing skills AST audit as a diagnostic scan. - Return the same review payload to the CLI and dashboard, including the candidate revision, content hash, changed files, scan findings, and `after-install.md` content. - Require explicit acceptance using a review token bound to the plugin key, old commit, new commit, and staged content hash. - Revalidate both the live and staged trees at acceptance time, then promote atomically with rollback. The live enabled plugin remains unchanged until this succeeds. - Append `STAGED` and `ACCEPTED` events to a JSONL audit log. - Bind tool-override consent to the exact installed plugin revision. Updates revoke an earlier grant unless the operator explicitly renews it for the reviewed revision. Closes #37976 ## Review feedback addressed - The live plugin directory is no longer pulled before review; upda",
      "date_published": "2026-06-03T06:44:38Z",
      "date_modified": "2026-08-13T18:01:14Z",
      "tags": [
        "pull_request",
        "type/security",
        "comp/cli",
        "comp/plugins",
        "P3",
        "sweeper:blast-moderate",
        "comp/dashboard"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 13
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:issue:33469",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent/page/2/#signal-97a13adb43aa",
      "external_url": "https://github.com/DataDog/datadog-agent/issues/33469",
      "title": "[Datadog Agent] Dependency Dashboard",
      "content_text": "This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.<br>[View this repository on the Mend.io Web Portal](https://developer.mend.io/github/DataDog/datadog-agent). ## Deprecations / Replacements > [!WARNING] The following dependencies are either deprecated or have replacements available. | Datasource | Package | Replacement PR? | |------------|------|--------------| | nuget | [xunit](https://redirect.github.com/xunit/xunit) | ![Unavailable](https://img.shields.io/badge/unavailable-orange?style=flat-square) | ## Pending Approval The following branches are pending approval. To create them, click on a checkbox below. - [ ] <!-- approve-branch=renovate/github.com-alecthomas-participle-2.x -->Update module github.com/alecthomas/participle to v2 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-authorization-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/authorization/v2 to v3 - [ ] <!-- approve-branch=renovate/github.com-pulumi-pulumi-azure-native-sdk-compute-v2-3.x -->Update module github.com/pulumi/pulumi-azure-native-sdk/compute",
      "date_published": "2025-01-28T12:05:52Z",
      "date_modified": "2026-08-13T18:01:09Z",
      "tags": [
        "issue",
        "team/agent-devx",
        "pending",
        "oss/0"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 6
      }
    },
    {
      "id": "2026-08-13:github:vllm-project/vllm:pull_request:52117",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/vllm/page/5/#signal-0ebb74c62bd7",
      "external_url": "https://github.com/vllm-project/vllm/pull/52117",
      "title": "[vLLM] [Bugfix] Do not require SupportsPP of draft models under pipeline parallelism",
      "content_text": "Fixes #52069. `create_draft_parallel_config` copies the target's `pipeline_parallel_size` into the draft's parallel config, so `_verify_args` demands `SupportsPP` from the draft model. No head in `MTPModelTypes` implements it, so every MTP speculative config dies in `create_engine_config` under PP > 1. A draft model always runs whole on a single PP rank (the V2 runner builds it on the last rank only), so this verifies it as single-stage, on a shallow copy of the config. **Test plan:** without the change, `--pipeline-parallel-size 4 --speculative-config '{\"method\":\"mtp\",...}'` fails at config time on GLM-4.5-Air; with it, the server loads and serves (8× RTX 3090, three machines, nightlies dev678–dev693). Complementary to #46994, which does not touch this file. --- Assisted-By: Claude",
      "date_published": "2026-08-13T07:22:01Z",
      "date_modified": "2026-08-13T18:01:09Z",
      "tags": [
        "pull_request",
        "bug"
      ],
      "_contribution_compass": {
        "project": "vllm-project/vllm",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 7
      }
    },
    {
      "id": "2026-08-13:github:anomalyco/opencode:pull_request:42383",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/opencode/page/13/#signal-4f13dec53036",
      "external_url": "https://github.com/anomalyco/opencode/pull/42383",
      "title": "[OpenCode] fix(core): render granular instruction updates",
      "content_text": "## What Instruction changes now append only the affected file deltas instead of repeating every loaded `AGENTS.md` file in full. Modified files render as three-context unified patches. Added and removed files use explicit messages. ## Before / After **Before:** Editing one line in one instruction file appended a complete replacement containing every global and project instruction file. The session learned the correct new state, but paid the token cost of unrelated unchanged files. **After:** The same edit appends a small patch for that file. Unchanged files are omitted while additions and removals remain explicit. ## How - `packages/core/src/instruction-discovery.ts` compares the previous and current file arrays by path. - Modified files use the existing `diff` dependency to produce unified patches with three lines of context. - Added files include their complete contents; removed files name the source that no longer applies. - `packages/core/test/instruction-discovery.test.ts` covers granular rendering and the real watcher-driven update/delete flow. ## Scope This does not attempt to attribute file changes to the session that made them or suppress self-authored updates. Durable ins",
      "date_published": "2026-08-13T17:57:34Z",
      "date_modified": "2026-08-13T18:01:09Z",
      "tags": [
        "pull_request",
        "contributor"
      ],
      "_contribution_compass": {
        "project": "anomalyco/opencode",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85500",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/8/#signal-863c9200ae7e",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85500",
      "title": "[Hermes Agent] fix(file): fail closed on silent read transport",
      "content_text": "## Summary - reject empty or malformed successful size/line-count probes instead of coercing them to zero - reject empty in-range content for a known nonempty regular file - add transport-shaped regressions for linked-worktree and delegation-summary false empties ## Verification - `scripts/run_tests.sh tests/tools/test_file_operations_edge_cases.py tests/tools/test_file_operations.py tests/tools/test_read_shell_line_clamp.py` (97 passed, 2 platform skips) - `.venv/bin/ruff check tools/file_operations.py tests/tools/test_file_operations_edge_cases.py` - real `ShellFileOperations.read_file` smoke on this linked worktree and a delegation-cache summary",
      "date_published": "2026-08-13T17:53:35Z",
      "date_modified": "2026-08-13T18:01:07Z",
      "tags": [
        "pull_request",
        "type/bug",
        "tool/file",
        "P2"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:temporalio/temporal:pull_request:11543",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/platform-infrastructure/temporal.html#signal-7125fb49fbce",
      "external_url": "https://github.com/temporalio/temporal/pull/11543",
      "title": "[Temporal] Release gRPC resolver registrations on shutdown",
      "content_text": "## What changed? Tie process-global gRPC resolver registrations to their Fx and test owners. Resolver URLs use monotonic opaque registration IDs, test callers register cleanup directly, and matching test clients close their RPC factories during cluster shutdown. The leak test drops the corresponding host expectation. ## Why? The process-global resolver map retained cluster-owned state after shutdown. Explicit cleanup releases those references while preserving resolver availability during Fx graph construction. ## Testing - `go test -race -tags disable_grpc_modules,test_dep ./common/membership ./common/rpc/test ./tests/testcore -count=1` - `LEAK_ITERS=5 LEAK_ITERS_WARMUP=1 LEAK_GC_SETTLE_TIMEOUT=30s go test -run TestClusterShutdownLeak -count=1 -timeout 6m -tags disable_grpc_modules,,test_dep, ./tests/leakcheck/ -args -persistenceType=sql -persistenceDriver=sqlite` Stacked on #11542.",
      "date_published": "2026-08-13T15:50:19Z",
      "date_modified": "2026-08-13T18:01:05Z",
      "tags": [
        "pull_request",
        "request-claude-review"
      ],
      "_contribution_compass": {
        "project": "temporalio/temporal",
        "group": "platform-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 2
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85502",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/9/#signal-6505ee23b2f0",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85502",
      "title": "[Hermes Agent] fix(kanban): terminalize iteration exhaustion",
      "content_text": "## Summary - make Kanban iteration-budget exhaustion terminal for the exact run/revision instead of routing it through retryable wall-clock timeout handling - preserve workspace/evidence, record `retryable=false` and `resume_policy=never`, and prevent automatic claim/unblock of the exhausted card - notify and wake the owner for replan while retaining the existing delivery-mode boundary - keep normal wall-clock timeout retry behavior unchanged ## Why The iteration ceiling is an emergency stop. Retrying the same task revision after it has exhausted its model/tool budget can repeat the same broad run and risks obscuring the preserved partial artifact. Continuing work should use an owner-planned replacement revision that references the preserved workspace. ## Tests ```text 17 passed, 5 third-party deprecation warnings ruff: pass py_compile: pass git diff --check: pass ``` Focused coverage includes: - exact-run terminal task/run state - stale-finalizer guard against a successor run - idempotent repeated finalization - preserved workspace/evidence and terminal metadata - no automatic claim or unblock - notifier text and owner wake context - unchanged retryable wall-clock timeout semantic",
      "date_published": "2026-08-13T17:55:04Z",
      "date_modified": "2026-08-13T18:01:03Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/agent",
        "comp/gateway",
        "comp/cron",
        "P3",
        "sweeper:risk-message-delivery"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85503",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/9/#signal-f3cba7df928b",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85503",
      "title": "[Hermes Agent] fix(whatsapp): strip the multi-device suffix when normalizing bot ids",
      "content_text": "## Bug Baileys hands the bridge its own identity **with a device index** — `sock.user.id` is `\"15551234567:17@s.whatsapp.net\"` — while inbound `mentionedJid` entries and `contextInfo.participant` arrive **without** one. Both normalizers (`normalizeWhatsAppId` in `bridge_helpers.js`, `_normalize_whatsapp_id` in `whatsapp_common.py`) folded the first `:` into an `@` instead of stripping the suffix, producing a malformed two-`@` id: ``` \"15551234567:17@s.whatsapp.net\" → \"15551234567@17@s.whatsapp.net\" ← never equals the clean form ``` So every set-membership comparison of `botIds` against clean inbound ids silently failed. ## User-visible impact | Path | Effect | |---|---| | `_message_mentions_bot` — `mentionedIds ∩ botIds` | Never matched. @-mentions only kept working through the bare-number **substring fallback** on the body text. | | `_message_is_reply_to_bot` — `quotedParticipant ∈ botIds` | Never matched. Under `require_mention`, **quote-replying the bot's own answer does not re-trigger it** — the natural \"reply to the bot in a group\" flow is dead, with no fallback. | | `reply_to_is_own_message` | Always `False` — the gateway renders `[Replying to: ...]` instead of `[Replying to ",
      "date_published": "2026-08-13T17:55:19Z",
      "date_modified": "2026-08-13T18:01:00Z",
      "tags": [
        "pull_request",
        "type/bug",
        "duplicate",
        "comp/gateway",
        "platform/whatsapp",
        "P2",
        "sweeper:risk-message-delivery"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:anthropics/claude-code:issue:86468",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/20/#signal-63b5bd4373a5",
      "external_url": "https://github.com/anthropics/claude-code/issues/86468",
      "title": "[Claude Code] [BUG] ECONNRESET on streaming connections behind multi-layer NAT (macOS 26.6.1, v2.1.231)",
      "content_text": "Reopening this as a new issue per the stale-bot instruction on #67091. The same failure is described in #67091 (closed NOT_PLANNED, titled for Windows), #48008 (closed as duplicate, macOS), and #51164 (closed NOT_PLANNED). It still reproduces on current versions, and I have a controlled set of scenarios that isolates it to NAT depth in the path. ### Environment - Claude Code 2.1.231 - Node v20.17.0 - macOS 26.6.1, arm64, MacBook Air M4 (Mac16,12) ### Three scenarios 1. Without the UniFi Travel Router - network setup works, but traffic goes over Tailscale. 2. With the UniFi Travel Router over Wi-Fi. 3. With the UniFi Travel Router, where we connect an Ethernet cable and change routing priorities. ### Setup Working from a hotel network. Tailscale is running in all three scenarios with accept-routes on and no exit node selected, so it carries tailnet traffic only and Anthropic traffic never rides it. The variable is a UniFi Travel Router, which when present full-tunnels everything back to a UCG-Fiber at my house over Teleport (WireGuard). ### Scenario 1 - no travel router The laptop associates directly with the hotel SSID. One NAT layer. Tailscale gives me my home resources and everyt",
      "date_published": "2026-08-13T18:00:58Z",
      "date_modified": "2026-08-13T18:00:58Z",
      "tags": [
        "issue"
      ],
      "_contribution_compass": {
        "project": "anthropics/claude-code",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 4
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54656",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent/page/2/#signal-dfab439bacd9",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54656",
      "title": "[Datadog Agent] feat(ndm): emit a metric per workload balancing group",
      "content_text": "> **Note:** This PR was created by Claude. Stacked on #54652 — review that one first. ### What does this PR do? Emits `datadog.agent.workload_balancing.running` once per NDM workload balancing group the Agent knows about, tagged with: - `workload_balancing_group:<id>` - `workload_balancing_state:active|standby|unmanaged` It follows the shape of the existing `datadog.agent.ha_agent.running` metric and is emitted from the same place, `BufferedAggregator.appendDefaultSeries`. Nothing is emitted when workload balancing is disabled, which is the default. The `workloadbalancing` component is threaded into the aggregator through the demultiplexer, which is most of the diff. ### Motivation The interesting signal is the gap, not the value. Each group should be reported as `active` by exactly one Agent. If the assigned Agent goes away and the reassignment does not land, the group stops being reported as active anywhere, and that absence is visible in a way that a silently unpolled device is not. ### Describe how you validated your changes - `go test -tags test ./pkg/aggregator/... ./comp/aggregator/...` — pass, including two new tests covering the tags and states emitted per group and that a",
      "date_published": "2026-08-10T16:25:18Z",
      "date_modified": "2026-08-13T18:00:57Z",
      "tags": [
        "pull_request",
        "qa/done",
        "long review",
        "team/agent-integrations",
        "team/agent-metric-pipelines",
        "internal",
        "team/network-device-monitoring-core",
        "team/fleet-automation"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "closed",
        "assignees": [],
        "change": "updated",
        "importanceScore": 6
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54659",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent/page/3/#signal-0f0b9e7877fd",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54659",
      "title": "[Datadog Agent] feat(ndm): report workload balancing group state as inventory metadata",
      "content_text": "> **Note:** This PR was created by Claude. Stacked on #54652 — review that one first. ### What does this PR do? Adds a `comp/metadata/workloadbalancing` component, mirroring the existing `comp/metadata/haagent`. When Agent workload balancing is enabled it reports a `workload_balancing_metadata` inventory payload: ```json { \"hostname\": \"...\", \"workload_balancing_metadata\": { \"enabled\": true, \"groups\": {\"group-a\": \"active\", \"group-b\": \"standby\"} }, \"timestamp\": 1716985696922603000 } ``` It surfaces in three places: the inventory product, `agent status` (text and HTML), and the `/metadata/workload-balancing` endpoint. The flare picks it up as `workload-balancing.json`. Nothing is reported when workload balancing is disabled, which is the default. Unlike HA Agent, which has a single Agent-wide state, this Agent can hold a different state per group, so the payload carries a map rather than one string. ### Motivation `datadog.agent.workload_balancing.running` says a group is being run somewhere. It does not say which Agent holds it, or what the Agent itself thinks it holds. When a handoff does not land, the first question is which Agent believes it is active, and the inventory and status",
      "date_published": "2026-08-10T16:47:55Z",
      "date_modified": "2026-08-13T18:00:57Z",
      "tags": [
        "pull_request",
        "qa/done",
        "team/agent-runtimes",
        "team/fleet-remediation",
        "team/fleet-automation"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "closed",
        "assignees": [],
        "change": "updated",
        "importanceScore": 5
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54795",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent/page/2/#signal-621ecbf86fea",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54795",
      "title": "[Datadog Agent] test(ndm): add e2e coverage for Agent Workload Balancing",
      "content_text": "> **Note:** This PR was created by Claude. ### What does this PR do? Adds the e2e test suite for Agent Workload Balancing that was called out as needed in #54652's original plan, and adds the one missing CLI surface found while auditing that plan for completeness. - `TestWorkloadBalancingRunningMetrics` / `TestWorkloadBalancingAddedToRCListeners` (`workloadbalancing_test.go`): mirrors `haagent_test.go`. Pushes an `NDM_AGENT_WORKLOAD_BALANCING` Remote Config payload via `RCAddConfig` against fakeintake, then asserts `datadog.agent.workload_balancing.running` (tagged `workload_balancing_group`/`workload_balancing_state`) and the `\"Add workload balancing RCListener\"` log line. - `TestWorkloadBalancingMetadata` (`workloadbalancing_metadata_test.go`): mirrors `haagent_metadata_test.go`. Pushes an RC assignment, then reads it back via `diagnose show-metadata workload-balancing`. - `cmd/agent/subcommands/diagnose/command.go`: adds the `show-metadata workload-balancing` subcommand. #54659 wired the metadata provider into inventory, flare, status, and the `/metadata/workload-balancing` HTTP endpoint, but left out the CLI subcommand that HA Agent has as `show-metadata ha-agent`. The metadata",
      "date_published": "2026-08-12T19:04:08Z",
      "date_modified": "2026-08-13T18:00:56Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "closed",
        "assignees": [],
        "change": "updated",
        "importanceScore": 7
      }
    },
    {
      "id": "2026-08-13:github:BerriAI/litellm:release:370107906",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/litellm.html#signal-4a1ab7286a8e",
      "external_url": "https://github.com/BerriAI/litellm/releases/tag/v1.98.0-dev.2",
      "title": "[LiteLLM] v1.98.0-dev.2",
      "content_text": "## Verify Docker Image Signature All LiteLLM Docker images are signed with [cosign](https://docs.sigstore.dev/cosign/overview/). Every release is signed with the same key introduced in [commit `0112e53`](https://github.com/BerriAI/litellm/commit/0112e53046018d726492c814b3644b7d376029d0). **Verify using the pinned commit hash (recommended):** A commit hash is cryptographically immutable, so this is the strongest way to ensure you are using the original signing key: ```bash cosign verify \\ --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \\ ghcr.io/berriai/litellm:v1.98.0-dev.2 ``` **Verify using the release tag (convenience):** Tags are protected in this repository and resolve to the same key. This option is easier to read but relies on tag protection rules: ```bash cosign verify \\ --key https://raw.githubusercontent.com/BerriAI/litellm/v1.98.0-dev.2/cosign.pub \\ ghcr.io/berriai/litellm:v1.98.0-dev.2 ``` Expected output: ``` The following checks were performed on each of these signatures: - The cosign claims were validated - The signatures were verified against the specified public key ``` --- ## What's Changed * fix(batches)",
      "date_published": "2026-08-13T18:00:55Z",
      "date_modified": "2026-08-13T18:00:55Z",
      "tags": [
        "release"
      ],
      "_contribution_compass": {
        "project": "BerriAI/litellm",
        "group": "ai-infrastructure",
        "state": null,
        "assignees": [],
        "change": "new",
        "importanceScore": 30
      }
    },
    {
      "id": "2026-08-13:github:anomalyco/opencode:pull_request:42353",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/opencode/page/8/#signal-c17f26e972c4",
      "external_url": "https://github.com/anomalyco/opencode/pull/42353",
      "title": "[OpenCode] feat(tui): prototype missing location recovery",
      "content_text": "## What Add a persistent recovery surface when a session's location cannot initialize. The transcript remains readable, the durable model identity remains visible in existing message chrome, and the normal composer is replaced with a focused `Choose directory` action using the same question-panel pattern as permissions. ## Before / After **Before** 1. A session's directory is deleted. 2. Location-scoped reads fail. 3. The durable session and transcript still exist, but the TUI presents secondary symptoms such as an unavailable model. 4. The user has no clear recovery action in the composer. **After** 1. The session route retains the failed location synchronization state. 2. The transcript remains mounted. 3. The composer is replaced with `Session location unavailable`, the abbreviated path, and `Choose directory`. 4. The action opens the existing `Move session` dialog, scoped to cataloged directories for the same project. 5. An unavailable current directory is not synthesized into the picker. 6. A successful destination sync clears the recovery state and restores the composer. ## How - `packages/tui/src/context/location.tsx` retains the latest location synchronization error and cle",
      "date_published": "2026-08-13T16:18:08Z",
      "date_modified": "2026-08-13T18:00:55Z",
      "tags": [
        "pull_request",
        "contributor"
      ],
      "_contribution_compass": {
        "project": "anomalyco/opencode",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 3
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85505",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/9/#signal-ffb4dd9490d8",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85505",
      "title": "[Hermes Agent] fix(sessions): keep gateway reset continuations listable (salvage #84009)",
      "content_text": "## Summary Sessions created after a gateway reset (`/new`, idle/daily timeout, suspension, expired resume recovery) are listable again in every session surface — `/sessions`, `hermes sessions list`, desktop sidebar, dashboard — and are no longer classified as ephemeral (cascade-delete-class) children. Root cause: since d2a4d373eb, gateway resets write `parent_session_id` on the continuation row for durable lineage, but `_LISTABLE_CHILD_SQL` only admitted `branched` parents — every reset continuation was treated as a hidden subagent/compression row, and `_ephemeral_child_sql` classified it as a cascade-delete target. Salvage of #84009 by @embwl0x (cherry-picked, authorship preserved) plus follow-up fixes from review. ## Changes **Salvaged from #84009 (@embwl0x, 2 commits):** - Durable `_reset_from` marker in `model_config` for gateway reset continuations (survives parent reopen/re-end churn — the mutable `end_reason` heuristic alone regresses to hidden after a parent resume, the same fragility class fixed for `/branch` in #39214) - Legacy same-routing-key fallback in `_RESET_CHILD_SQL` for pre-marker rows; reset children excluded from `_ephemeral_child_sql` - Marker preservation acr",
      "date_published": "2026-08-13T17:57:04Z",
      "date_modified": "2026-08-13T18:00:52Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/cli",
        "comp/gateway",
        "P1",
        "sweeper:risk-session-state",
        "area/sessions"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54594",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent/page/2/#signal-c631ff7e5034",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54594",
      "title": "[Datadog Agent] [ACTP] wire split runner ownership",
      "content_text": "### What does this PR do? Teaches the existing Go runner and Fx component to stand down when split mode is enabled on supported Linux and Windows host deployments, while retaining the executor subcommand used by `par-control`. Container deployments do not yet launch the replacement topology. Official Agent containers are detected through `configenv.IsContainerized()` (`DOCKER_DD_AGENT`), so a requested split deployment logs a warning and safely continues with the monolithic runner instead of black-holing PAR. Cluster Agent continues to use its existing in-process monolithic path. The resulting ownership invariant is explicit: exactly one process polls OPMS, and the monolith exits only when its replacement topology is available. ### Motivation Keep runner ownership and activation behavior separate from package and installer mechanics so reviewers can focus on preventing both duplicate polling and unsupported deployments standing down their only runner. ### Validation - `bazel test //comp/privateactionrunner/impl:impl_test` passes locally. - Focused coverage includes Linux and Windows hosts, Linux and Windows containers, and an unsupported host platform. - Private Action Runner build",
      "date_published": "2026-08-07T18:09:51Z",
      "date_modified": "2026-08-13T18:00:51Z",
      "tags": [
        "pull_request",
        "medium review",
        "team/agent-build",
        "team/action-platform",
        "internal",
        "team/fleet-automation"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 6
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85504",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/9/#signal-0a4776dfd7c2",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85504",
      "title": "[Hermes Agent] feat(providers): discover pip-installed model providers via entry points (salvage #81419)",
      "content_text": "## Summary `pip install`ed model-provider plugins now register their providers and show their models in the registry, matching filesystem-plugin behavior — gated by the same `plugins.enabled` opt-in the general PluginManager enforces. Salvages #81419 by @albertodepaola (cherry-picked, authorship preserved) with hardening on top. ## Changes - `providers/__init__.py`: new step-0 entry-point scan of the `hermes_agent.plugins` group in `_discover_providers()`; supports `module:func` callables and self-registering bare modules (contributor's work). Follow-up hardening: - honors `plugins.enabled` allow-list / `plugins.disabled` deny-list — installed ≠ loaded - skips callables that require arguments, so `register(ctx)`-style general plugins sharing the group are never invoked (no TypeError warning spam) - discovered FIRST → lowest precedence: last-writer-wins means bundled/`$HERMES_HOME` profiles always beat a pip impostor on name collision - `tests/providers/test_entry_point_discovery.py`: contributor's 3 tests + 3 new (opt-in gate, deny-list wins, `register(ctx)` never invoked); fixed inverted precedence docstring - `website/docs/developer-guide/model-provider-plugin.md`: corrected mech",
      "date_published": "2026-08-13T17:55:28Z",
      "date_modified": "2026-08-13T18:00:48Z",
      "tags": [
        "pull_request",
        "type/feature",
        "comp/agent",
        "comp/plugins",
        "P3"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54833",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent.html#signal-7d2d01430457",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54833",
      "title": "[Datadog Agent] SMP experiment selection and codeowners v2",
      "content_text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Classifies SMP experiments into three modes: always: as the name implies, they always run, these are the quality gates codeowners: these experiments x, owned by team y, are automatically triggered if the the PR touches a file owned by y optional: fully manual, label triggered set of experiments used for specific features ### Motivation ### Describe how you validated your changes ### Additional Notes No need for review yet, this is a POC that will be split",
      "date_published": "2026-08-13T13:59:48Z",
      "date_modified": "2026-08-13T18:00:44Z",
      "tags": [
        "pull_request",
        "team/agent-security",
        "long review",
        "team/agent-log-pipelines",
        "team/agent-devx",
        "team/action-platform",
        "internal",
        "smp/logs/syslog"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 18
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85501",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/9/#signal-78658c476835",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85501",
      "title": "[Hermes Agent] fix(kanban): inherit ALL routing columns in notify-sub inheritance",
      "content_text": "## Summary Child kanban tasks now inherit EVERY routing/delivery column of their parent's notify subscription — `chat_type`, `user_id_alt`, `delivery_mode`, and `delivery_metadata` included. Fixes #73030. Root cause: `_inherit_notify_subs()` (the link_tasks / triage-decompose / create-with-parents path) copied only platform/chat/thread/user/profile. A DM-originated child completion fell back to `chat_type='group'` and woke a fresh group-scoped session instead of the originating DM; Telegram DM-topic subscriptions lost their persisted reply-fallback metadata. ## Changes - `hermes_cli/kanban_db.py`: `_inherit_notify_subs` copies all routing/delivery columns; the duplicated inline inheritance block in `create_task` (added by #85487) consolidated onto the single-owner helper — one inheritance path, every column, one owner - `tests/hermes_cli/test_kanban_notify.py`: sabotage-verified regression tests for both the `link_tasks` and create-with-parents paths, asserting all four previously-dropped columns ## Validation | | Before | After | |---|---|---| | inherited chat_type / metadata | NULL (dropped) | preserved | | DM child wake | group-scoped fallback session | originating DM | | inheri",
      "date_published": "2026-08-13T17:54:01Z",
      "date_modified": "2026-08-13T18:00:44Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/cron",
        "platform/telegram",
        "P3",
        "sweeper:risk-session-state",
        "sweeper:risk-message-delivery"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "closed",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85506",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/9/#signal-1a25a9f51bfd",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85506",
      "title": "[Hermes Agent] fix(agent): reject stale 32K metadata underreports for MiniMax (extends Kimi guard)",
      "content_text": "## Summary MiniMax M2-family models wrongly capped at 32K: stale third-party metadata underreports them as 32,768 (real window 204,800), and both the persisted cache and the OpenRouter/Nous fallback paths trusted it — tripping the 64K minimum and breaking previously-working setups after upgrade. This extends the existing Kimi 32K-underreport guard to a shared `_model_name_suggests_stale_32k_underreport()` covering both families. Salvages #24436 by @luoxiao6645 (cherry-picked, authorship preserved; resolves the remaining half of #24140's class that our generic pre-catalog guard in #85434 did not cover — that guard handles persisted pre-catalog values, this one rejects live 32K underreports). ## Changes - `agent/model_metadata.py`: `_model_name_suggests_minimax()` + `_model_name_suggests_stale_32k_underreport()`; the step-1 cache invalidation, the Nous-path `_safe_ctx`, and the step-6 OpenRouter guard now cover MiniMax alongside Kimi. - `tests/agent/test_model_metadata.py`: cache-invalidation, OR-fallback-rejection, and non-MiniMax-safety tests (contributor's), conflict-resolved onto the current generic-guard code. ## Validation | | Result | |---|---| | `test_model_metadata.py` + `te",
      "date_published": "2026-08-13T17:58:31Z",
      "date_modified": "2026-08-13T18:00:40Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/agent",
        "provider/minimax",
        "P2"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114184",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/5/#signal-0b4342ac58a9",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114184",
      "title": "[ClickHouse] Implementing generic block nested loop join",
      "content_text": "### Changelog category (leave one): - New Feature ### Changelog entry (a [user-readable short description](https://github.com/ClickHouse/ClickHouse/blob/master/docs/changelog_entry_guidelines.md) of the changes that goes into CHANGELOG.md): * Implemented generic block nested loop join",
      "date_published": "2026-08-10T16:04:43Z",
      "date_modified": "2026-08-13T18:00:39Z",
      "tags": [
        "pull_request",
        "pr-feature"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 7
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114409",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/8/#signal-2749e65beabc",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114409",
      "title": "[ClickHouse] Revert \"Revert the PromQL topk/limitk streaming plan and its shared-subquery materialization\"",
      "content_text": "Reverts ClickHouse/ClickHouse#114326 Depends on https://github.com/ClickHouse/ClickHouse/pull/113397",
      "date_published": "2026-08-12T01:15:49Z",
      "date_modified": "2026-08-13T18:00:37Z",
      "tags": [
        "pull_request",
        "pr-not-for-changelog"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 4
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:111973",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/2/#signal-a0a0ab70b906",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/111973",
      "title": "[ClickHouse] Let read-in-order propagate through SpillingHashJoin",
      "content_text": "`SpillingHashJoin::hasDelayedBlocks` was hardcoded to `true`, even in the `IN_MEMORY_JOIN` state where nothing is ever delayed. That is the flag gating the read-in-order-through-join and top-k-through-join optimizations, so wrapping a hash join for auto-spilling silently disabled both — and `max_bytes_ratio_before_external_join` defaults to `0.5`, which wraps every hash join. The in-tree comment in `topKThroughJoin.cpp` already describes this as the steady state. `IJoin` documents that \"SpillingHashJoin overrides `keepLeftPipelineInOrder` to forbid switching to GraceHashJoin at runtime\", but no such override existed, so the escape hatch the comment describes was never implemented. This implements it. `keepLeftPipelineInOrder` now pins the join to its in-memory algorithm, and `hasDelayedBlocks` reports `false` from that point on. Pinning is required for **correctness**, not just speed: once the plan drops a sort because the join preserves the left order, a later switch to `GraceHashJoin` would scatter rows by hash and silently return them in the wrong order. The optimizer asks before it commits (`findReadingStep` checks feasibility, and `keepLeftPipelineInOrder` is only called later",
      "date_published": "2026-07-26T19:07:03Z",
      "date_modified": "2026-08-13T18:00:29Z",
      "tags": [
        "pull_request",
        "pr-performance"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [
          "alexey-milovidov"
        ],
        "change": "updated",
        "importanceScore": 18
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114665",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/10/#signal-7a66258702d9",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114665",
      "title": "[ClickHouse] Allow overriding the HTTP method for SELECT through the url table function and URL engine",
      "content_text": "Closes: https://github.com/ClickHouse/ClickHouse/issues/62352 ### Changelog category (leave one): - New Feature ### Changelog entry (a [user-readable short description](https://github.com/ClickHouse/ClickHouse/blob/master/docs/changelog_entry_guidelines.md) of the changes that goes into CHANGELOG.md): `http_method='POST'` — as a key-value argument of the `url` table function and the `URL` table engine, or through the `http_method`/`method` named collection keys — now applies to `SELECT` queries: reads use `POST` instead of the default `GET`, for servers that accept only `POST`. Schema inference follows the configured method. `PUT` keeps its write-only meaning: a `SELECT` through a configuration with `http_method='PUT'` still uses `GET`. ### Implementation notes - `IStorageURLBase::getReadMethod()` now returns `POST` when the configured `http_method` is `POST`. `PUT` still applies to writes only (pre-signed upload URLs, #44326), and `INSERT` behavior is unchanged: `POST` by default, `PUT` when configured. - The write path no longer mutates the shared `http_method` member when defaulting to `POST` — the storage instance is shared between queries, so persisting the write default would",
      "date_published": "2026-08-13T16:17:38Z",
      "date_modified": "2026-08-13T18:00:25Z",
      "tags": [
        "pull_request",
        "pr-feature",
        "can be tested"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 2
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54591",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent/page/2/#signal-981198eac2f6",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54591",
      "title": "[Datadog Agent] [ACTP] add par-control executor channel",
      "content_text": "### What does this PR do? Defines the local control-to-executor channel and implements both ends of it: - Adds the executor gRPC protocol and generated bindings. - Exposes executor health and readiness. - Synchronizes workflow signing keys. - Streams action dispatch outcomes. - Adds the Rust mTLS client and transport support. - Keeps the shared terminal `Outcome` model with the executor layer. This layer provides communication primitives only; polling and process-lifecycle policy remain in later layers. ### Motivation Create a narrow, authenticated local contract between `par-control` and the existing Go executor before introducing OPMS polling or orchestration. ### Validation - Focused Go tests pass locally. - Private Action Runner Go build passes locally. - Portable Rust tests pass locally; native-tls identity coverage requires Linux/Windows. ### Review fixes - **Transport**: 5s connect timeout on both the plain and the mTLS channel, and no panic path in the named-pipe retry loop. Also corrects module docs that claimed Windows named-pipe support was a follow-up while the named-pipe client sits in the same file. - Dropped the redundant `tokio-stream` dev-dependency, since this lay",
      "date_published": "2026-08-07T17:50:14Z",
      "date_modified": "2026-08-13T18:00:24Z",
      "tags": [
        "pull_request",
        "long review",
        "team/agent-devx",
        "team/agent-build",
        "team/action-platform",
        "internal"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 6
      }
    },
    {
      "id": "2026-08-13:github:cilium/cilium:pull_request:47902",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/platform-infrastructure/cilium.html#signal-99f373519cc3",
      "external_url": "https://github.com/cilium/cilium/pull/47902",
      "title": "[Cilium] golangci-lint: Forbid stdlib `net.Interface*` functions",
      "content_text": "The Go stdlib `net.Interface*` family talks to the kernel over a netlink socket with no timeout, so it can block forever. This PR converts the two remaining offenders to `netlink/safenetlink` and add a forbidigo rule so new ones don't creep back in. Fixes: #15051",
      "date_published": "2026-08-11T20:27:45Z",
      "date_modified": "2026-08-13T18:00:21Z",
      "tags": [
        "pull_request",
        "ready-to-merge",
        "release-note/misc"
      ],
      "_contribution_compass": {
        "project": "cilium/cilium",
        "group": "platform-infrastructure",
        "state": "closed",
        "assignees": [],
        "change": "updated",
        "importanceScore": 10
      }
    },
    {
      "id": "2026-08-13:github:vllm-project/vllm:pull_request:51360",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/vllm/page/3/#signal-c5057572dda6",
      "external_url": "https://github.com/vllm-project/vllm/pull/51360",
      "title": "[vLLM] [Frontend] Add reusable TP1 initialized-engine snapshots",
      "content_text": "<!-- markdownlint-disable MD013 MD041 --> ## Purpose @elizabetht's RFC #34303 and #37921/#37925 split CUDA checkpoint work into in-process primitives and leave CRIU disk persistence for a later phase. #35934 proposes a CRIU-safe engine suspend and resume path, while PRs #42790 and #46089 propose provider-owned pod snapshot hooks. @fergusfinn's data in #34303 also showed that full initialized snapshots can work, with large images and stale external TCP connections as central costs. @simon-mo's closed, reference-only #40323 autoresearch showcase also included inert snapshot scaffolding for a pre-model image of Python imports and a CUDA context. It explicitly excluded model weights, model configuration, compile state, and CUDA graphs. This PR instead implements and measures a host-owned artifact captured after TP1 engine initialization and a deterministic generation canary, before HTTP bind. It is also the measured successor to my closed PR #48996. PR #48996 captured only the import stage. Its matched warm comparison was flat at about 29.08 seconds versus 29.09 seconds, n=3 per arm, because the expensive engine state still had to be constructed after restore. This PR moves the boundar",
      "date_published": "2026-08-07T05:06:49Z",
      "date_modified": "2026-08-13T18:00:06Z",
      "tags": [
        "pull_request",
        "documentation",
        "frontend",
        "ready"
      ],
      "_contribution_compass": {
        "project": "vllm-project/vllm",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 10
      }
    },
    {
      "id": "2026-08-13:github:anomalyco/opencode:pull_request:42384",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/opencode/page/13/#signal-01bdc41d370f",
      "external_url": "https://github.com/anomalyco/opencode/pull/42384",
      "title": "[OpenCode] fix(tui): prioritize composer keybinds",
      "content_text": "## What Replace the Shell tab's hard-coded `Ctrl+D` interceptor with OpenTUI keymap layer priority for the full composer. Closes #42377. ## Before / After **Before:** #42366 restored the default Shell kill shortcut with a raw event interceptor that recognized only literal `Ctrl+D`. Custom bindings and the adjacent composer navigation/Subagents layers still depended on equal-priority registration order against focused-editor bindings. **After:** Composer navigation and active tab actions use contextual priority. Their configured bindings win while the composer is active, including custom bindings, without matching physical keys manually. ## How - Give the composer navigation layer contextual `priority: 1`. - Give Shell and Subagents action layers the same priority. - Remove the Shell-specific raw event interceptor. - Extend the composer keymap test to exercise tab navigation and a custom Shell kill binding while a textarea remains focused. ## Investigation Focused rendered-component tests showed permission rejection, textual forms, autocomplete destructive actions, and ordinary non-default editor collisions already behave correctly. Lowering `app.exit` priority did not fix the real ",
      "date_published": "2026-08-13T17:59:49Z",
      "date_modified": "2026-08-13T17:59:57Z",
      "tags": [
        "pull_request",
        "contributor"
      ],
      "_contribution_compass": {
        "project": "anomalyco/opencode",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:vllm-project/vllm:pull_request:50280",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/vllm/page/8/#signal-6d696ff85b91",
      "external_url": "https://github.com/vllm-project/vllm/pull/50280",
      "title": "[vLLM] [Bugfix][Spec Decode] Make EAGLE weight sharing TP-consistent",
      "content_text": "## Purpose Addresses the rank-divergent EAGLE weight-sharing decision described in #50158. The issue stays open: real-hardware runs (see discussion below) show the acceptance collapse reported there persists after this fix and has a separate root cause that is still under investigation. EAGLE currently decides whether to share the target model's `embed_tokens` and `lm_head` by comparing each tensor-parallel rank's local shards independently. If equality differs across ranks, some ranks replace the draft module with the target module while others keep the draft weights. The ranks then build different drafters, which can severely reduce speculative acceptance. This change requires unanimous TP-wide agreement before sharing either module. Each rank contributes its local decision to a CPU-group `MIN` reduction, so any mismatch keeps the draft weights on every rank. TP size 1 preserves the existing fast path without a collective. The regression test covers both unanimous agreement and one-rank mismatch for `embed_tokens` and `lm_head`. The change is limited to the existing EAGLE weight-sharing decisions. The collectives occur in the same fixed model-load order on every TP rank and do no",
      "date_published": "2026-07-29T14:27:13Z",
      "date_modified": "2026-08-13T17:59:54Z",
      "tags": [
        "pull_request",
        "bug",
        "speculative-decoding",
        "v1"
      ],
      "_contribution_compass": {
        "project": "vllm-project/vllm",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 5
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:72367",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent.html#signal-73825517ae9e",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/72367",
      "title": "[Hermes Agent] fix(web): validate provider-reported final URLs",
      "content_text": "## Summary - Validate provider-reported final or canonical URLs before returning web content across Firecrawl, Tavily, Exa, and Parallel. - Fail closed for malformed, private, internal, and unresolved final destinations while suppressing unsafe provider metadata and content. - Preserve safe public results and leave Oxylabs behavior unchanged. ## Verification - Focused final-URL safety suite: 26 passed. - Relevant web-tool regression suite: 333 passed. - Ruff, syntax, diff-scope, and static-security checks passed. - Reconciled cleanly as one commit directly on current upstream main. ## Scope Exactly eight files: four provider integrations, the shared URL-safety helper, and three test files. No dependency, lockfile, deployment, service, production, or Oxylabs changes.",
      "date_published": "2026-07-27T01:26:33Z",
      "date_modified": "2026-08-13T17:59:53Z",
      "tags": [
        "pull_request",
        "type/security",
        "comp/plugins",
        "tool/web",
        "area/auth",
        "P2",
        "needs-decision",
        "sweeper:risk-security-boundary",
        "sweeper:risk-compatibility",
        "sweeper:blast-moderate"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 16
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54793",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent.html#signal-128b07a4c8d6",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54793",
      "title": "[Datadog Agent] Remove schemaBuilder and createschema command",
      "content_text": "### What does this PR do? Remove the `createschema` command and the schema builder config implementation. We no longer need to generate the schema. ### Motivation Cleanup now that schema is live and in use. ### Describe how you validated your changes CI ### Additional Notes",
      "date_published": "2026-08-12T18:13:12Z",
      "date_modified": "2026-08-13T17:59:52Z",
      "tags": [
        "pull_request",
        "changelog/no-changelog",
        "component/system-probe",
        "qa/done",
        "long review",
        "team/agent-runtimes",
        "team/agent-build",
        "internal",
        "team/fleet-remediation",
        "team/fleet-automation"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 8
      }
    },
    {
      "id": "2026-08-13:github:openai/codex:issue:37974",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex/page/2/#signal-80b1c14dce3d",
      "external_url": "https://github.com/openai/codex/issues/37974",
      "title": "[Codex] TUI: queued follow-up inputs are permanently stranded after a failed prompt-edit branch",
      "content_text": "### What version of Codex CLI is running? codex-cli 0.147.0 ### What platform is your computer? Linux 5.15.120 x86_64 (also reproducible on other platforms — the bug is in the TUI prompt-edit/backtrack logic, not platform-specific) ### What issue are you seeing? When editing an earlier prompt (Esc-Esc backtrack → select a prompt → Enter), the TUI forks the thread *before* the selected turn. If that fork fails — e.g. the composer shows: ``` ■ Failed to branch before the selected prompt: the selected prompt was not found in the persisted thread ``` — then **any user inputs that were queued while the fork was in flight get permanently stranded**. They stay in \"Queued follow-up inputs\" forever and are never submitted, even after the composer returns to the `Ready` state. The queue just keeps growing with every new message and nothing is ever sent to the model. Note: the \"not found in the persisted thread\" guard itself is legitimate defensive behavior (the visible transcript projection can't always be matched back to a persisted turn — e.g. after history pagination, or when large context blocks are injected as user messages by a wrapper). The bug is purely in the **failure-handling path",
      "date_published": "2026-08-11T09:42:39Z",
      "date_modified": "2026-08-13T17:59:47Z",
      "tags": [
        "issue",
        "bug",
        "TUI",
        "CLI",
        "session"
      ],
      "_contribution_compass": {
        "project": "openai/codex",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 20
      }
    },
    {
      "id": "2026-08-13:github:temporalio/temporal:pull_request:11551",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/platform-infrastructure/temporal/page/3/#signal-7adda3aa71a9",
      "external_url": "https://github.com/temporalio/temporal/pull/11551",
      "title": "[Temporal] Release OTEL logger registrations on shutdown",
      "content_text": "## What changed? Route process-global OTEL errors through lifecycle-owned logger registrations. The handler selects the newest ready registration and drops each logger reference when its Fx owner stops. The leak test drops the corresponding logger expectation. ## Why? The process-global OTEL error handler retained the server logger after shutdown. Lifecycle ownership releases that reference while supporting multiple in-process servers. ## Testing - `go test -race -tags disable_grpc_modules,test_dep ./temporal -count=1` - `LEAK_ITERS=5 LEAK_ITERS_WARMUP=1 LEAK_GC_SETTLE_TIMEOUT=30s go test -run TestClusterShutdownLeak -count=1 -timeout 6m -tags disable_grpc_modules,,test_dep, ./tests/leakcheck/ -args -persistenceType=sql -persistenceDriver=sqlite` Based on #11542.",
      "date_published": "2026-08-13T17:59:38Z",
      "date_modified": "2026-08-13T17:59:38Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "temporalio/temporal",
        "group": "platform-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114273",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/7/#signal-f7ac0c4dc0b6",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114273",
      "title": "[ClickHouse] Add test: A `\\N` CSV field belonging to a nested `Tuple` / `Nullable(Tuple)` element of a separate-columns `Tuple` is untested",
      "content_text": "_Found via ClickGap automated review. Please close or comment if this is incorrect or needs adjustment._ _This is a test-only PR — no source code changes. Please review: test quality, whether the claimed coverage gaps are real, and whether test output makes sense._ Adds test coverage for 1 untested code path, found during automated review of [PR #109744](https://github.com/ClickHouse/ClickHouse/pull/109744). That PR (1) The PR changes `CSVFormatReader::readFieldImpl` (src/Processors/Formats/Impl/CSVRowInputFormat.cpp:403-421): the whole-column `input_format_null_as_default` short-circuit (`SerializationNullable::deserializeNullAsDefaultOrNestedTextCSV`) is now skipped for a bare, non-empty `Tuple` whose `tuple_ **1. A `\\N` CSV field belonging to a nested `Tuple` / `Nullable(Tuple)` element of a separate-columns `Tuple` is untested** `src/Processors/Formats/Impl/CSVRowInputFormat.cpp:413`, `src/DataTypes/Serializations/SerializationTuple.cpp:683` **Risk:** `CSVFormatReader::readFieldImpl` (src/Processors/Formats/Impl/CSVRowInputFormat.cpp:409-413) now skips the whole-column `null_as_default` short-circuit for a bare `Tuple`, so the leading field is handed to `SerializationTuple::des",
      "date_published": "2026-08-11T05:31:50Z",
      "date_modified": "2026-08-13T17:59:33Z",
      "tags": [
        "pull_request",
        "pr-not-for-changelog",
        "can be tested"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [
          "PedroTadim"
        ],
        "change": "updated",
        "importanceScore": 5
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:111287",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/5/#signal-850b90972ebb",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/111287",
      "title": "[ClickHouse] Fix double free when finalizing -State aggregates under looping combinators",
      "content_text": "<!-- Linked issues and pull requests. Use full GitHub URLs, one relationship per line; delete the lines you don't need. Related: https://github.com/ClickHouse/ClickHouse/pull/110975 --> ### Changelog category (leave one): - Bug Fix (user-visible misbehavior in an official stable release) ### Changelog entry (a [user-readable short description](https://github.com/ClickHouse/ClickHouse/blob/master/docs/changelog_entry_guidelines.md) of the changes that goes into CHANGELOG.md): Fixed a server crash (double free) that could happen when finalizing an aggregate function with the `-State` combinator nested under a looping combinator (`-Resample`, `-ForEach`, `-Map`), for example `groupArrayStateResample`, if a memory limit was reached during finalization. ### Description Reported on https://github.com/ClickHouse/ClickHouse/pull/110975 (unrelated to that PR). Found by the Stress test (amd_debug): a segfault in `Aggregator::prepareChunkAndFillWithoutKey`, reached from `ConvertingAggregatedToChunksTransform::initialize`. CI report: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=110975&sha=838d0b61235b06939c8acd923ebd396f51cf5b10&name_0=PR&name_1=Stress%20test%20%28amd_debug%29",
      "date_published": "2026-07-21T20:34:03Z",
      "date_modified": "2026-08-13T17:59:29Z",
      "tags": [
        "pull_request",
        "pr-bugfix",
        "can be tested"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [
          "nihalzp"
        ],
        "change": "updated",
        "importanceScore": 7
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:84142",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/6/#signal-a94a19476021",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/84142",
      "title": "[Hermes Agent] fix(gateway): preserve message continuity across restarts",
      "content_text": "## What does this PR do? Makes messaging continuity durable across gateway restarts so a reply to an already-visible message resumes the exact session and transcript instead of opening an empty context, replaying a blank synthetic turn, losing an accepted inbound ask, or producing a duplicate response. The implementation adds a durable continuity journal/binding layer and wires it into inbound dispatch, outbound delivery, delivery-ledger recovery, and continuable cron delivery. It fails closed when a durable claim or binding cannot be established and scopes resolution by platform, chat, thread, profile, and owner. This is broader than the existing restart-recovery PRs #68902, #72305, and #30030: those address final-delivery timing or synthetic resume behavior, while this change also provides durable inbound idempotency, delivered-message reply binding, new-topic/background transcript seeding, recovered-ACK binding, and profile/owner isolation. ## Related Issue Related to #46088 and the restart-continuity work in #68902, #72305, and #30030. ## Type of Change - [x] 🐛 Bug fix (non-breaking change that fixes an issue) - [x] 🔒 Security fix - [ ] ✨ New feature (non-breaking change that a",
      "date_published": "2026-08-11T22:47:39Z",
      "date_modified": "2026-08-13T17:59:26Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/gateway",
        "comp/cron",
        "P2",
        "needs-decision",
        "sweeper:risk-session-state",
        "sweeper:risk-message-delivery",
        "sweeper:risk-compatibility",
        "area/sessions"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:73052",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/4/#signal-6b1d590a9f71",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/73052",
      "title": "[Hermes Agent] fix(kanban): preserve chat_type and delivery_metadata in subscription inheritance (#73030)",
      "content_text": "## Problem `_inherit_notify_subs()` in `hermes_cli/kanban_db.py` copies a parent task's notification subscription to a child via `INSERT … SELECT`, but omits the `chat_type` and `delivery_metadata` columns. Inherited child rows silently lose available routing metadata. This affects all three call paths that route through the helper: `create_task(parents=…)`, `link_tasks()`, and `decompose_triage_task()`. **Impact:** - Creator-wake reconstruction falls back to `chat_type=\"group\"`, so a DM-originated child completion wakes a fresh group-scoped session instead of the originating DM session. - Telegram DM-topic subscriptions lose their persisted reply-fallback and topic metadata; `message_thread_id` alone can render outside the intended visible lane. Closes #73030. ## Fix Add `chat_type` and `delivery_metadata` to both the INSERT column list and the SELECT projection in `_inherit_notify_subs`. One logical change — the stored TEXT value is copied as-is and decoded on read by `list_notify_subs` as before. No re-encoding needed. ## Verification - **RED:** 3 regression tests fail on `upstream/main` before the fix (`assert None == 'dm'` — `chat_type` not inherited). - **GREEN:** All 4 targe",
      "date_published": "2026-07-28T02:27:07Z",
      "date_modified": "2026-08-13T17:59:23Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/cron",
        "platform/telegram",
        "P3",
        "sweeper:risk-session-state",
        "sweeper:risk-message-delivery",
        "sweeper:blast-moderate"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "closed",
        "assignees": [],
        "change": "new",
        "importanceScore": 2
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:issue:85496",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent.html#signal-028849a08c10",
      "external_url": "https://github.com/NousResearch/hermes-agent/issues/85496",
      "title": "[Hermes Agent] auth_middleware rejects desktop /api/ws?token= upgrade with HTTP 401 (boot loop)",
      "content_text": "# Bug: `auth_middleware` rejects the desktop `/api/ws?token=...` upgrade with HTTP 401 ## Affected version hermes-agent `0.20.0` (install stamp `fa83af3f9a42`, main, local install). Reproduced on macOS arm64. ## Symptom The Electron desktop app fails to boot in a loop: ``` Local Hermes backend is HTTP-reachable but the WebSocket (/api/ws) rejected the session token: WebSocket connection failed. → Desktop boot failed → Restarting ``` ## Root cause `apps/desktop/dist/electron-main.mjs` spawns the backend with: ``` serve --host 127.0.0.1 --port 0 ``` and opens the WebSocket upgrade at `/api/ws?token=<session_token>` (the desktop app's own freshly minted token, set as `HERMES_DASHBOARD_SESSION_TOKEN` in the backend child env). The backend's `auth_middleware` (`hermes_cli/web_server.py`, `auth_middleware`) gates **every** `/api/*` request: ```python if path.startswith(\"/api/\") and path not in _PUBLIC_API_PATHS and not is_mcp_oauth_callback: if not _has_valid_session_token(request) and not _has_valid_query_token(request, path): return JSONResponse(status_code=401, ...) ``` `_has_valid_query_token` only whitelists `/api/files/download` for the `?token=` query param — it does **NOT** inclu",
      "date_published": "2026-08-13T17:40:49Z",
      "date_modified": "2026-08-13T17:59:20Z",
      "tags": [
        "issue",
        "type/bug",
        "area/auth",
        "P2",
        "needs-repro",
        "sweeper:risk-security-boundary",
        "comp/desktop",
        "comp/dashboard"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 18
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:105429",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/8/#signal-cae0262aba6d",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/105429",
      "title": "[ClickHouse] Release pull request for branch 26.5",
      "content_text": "This PullRequest is a part of ClickHouse release cycle. It is used by CI system only. Do not perform any changes with it. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches security-sensitive internal/DDL execution gating by replacing `query_kind` checks with a new server-set flag, which could affect ON CLUSTER/replication/backup behavior if mis-propagated. Also tightens Arrow/Native input validation, which may reject previously-accepted malformed inputs and impact ingestion edge cases. > > **Overview** > Introduces a new `Context` flag `is_ddl_or_on_cluster_internal` (server-set and non-spoofable) and switches multiple code paths from `ClientInfo::QueryKind::SECONDARY_QUERY` to this flag for *security-sensitive* decisions, including internal backup/restore gating, Replicated DB DDL handling, `ON CLUSTER`/UUID-macro allowances, and context creation in DDL/replication/system operations. > > Hardens Arrow ingestion by reading geo metadata from the Arrow schema, validating BinaryArray offsets/lengths against buffer bounds (and handling absent/empty buffers), and avoiding `mutable_data()` usage in geo parsing; adds regression tests for corrupted Arrow offsets and geo met",
      "date_published": "2026-05-20T13:36:34Z",
      "date_modified": "2026-08-13T17:59:14Z",
      "tags": [
        "pull_request",
        "release"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 3
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114475",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/10/#signal-45ed2151f2c3",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114475",
      "title": "[ClickHouse] Backport #113289 to 26.5: Fix quadratic JSON subcolumn skip-index matching over a large dotted constant",
      "content_text": "Original pull-request https://github.com/ClickHouse/ClickHouse/pull/113289 This pull-request is a last step of an automated backporting. Treat it as a standard pull-request: look at the checks and resolve conflicts. Merge it only if you intend to backport changes to the target branch, otherwise just close it. ### The PR source The PR is created in the [CI job](https://github.com/ClickHouse/ClickHouse/actions/runs/31593284251/job/94102850957)",
      "date_published": "2026-08-12T12:06:09Z",
      "date_modified": "2026-08-13T17:59:14Z",
      "tags": [
        "pull_request",
        "pr-bugfix",
        "pr-backport"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "closed",
        "assignees": [
          "alexey-milovidov",
          "Avogar",
          "groeneai"
        ],
        "change": "updated",
        "importanceScore": 2
      }
    },
    {
      "id": "2026-08-13:github:anomalyco/opencode:issue:42293",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/opencode/page/2/#signal-82728ceca9e8",
      "external_url": "https://github.com/anomalyco/opencode/issues/42293",
      "title": "[OpenCode] opencode zen DeepSeek V4 Flash Free requests fail with [invalid_bearer_credential]",
      "content_text": "### Description I was using opencode connected to DeepSeek V4 Flash Free on opencode zen, and most - *but not all*! - requests failed with an error, `Upstream request failed: [invalid_bearer_credential] Missing or invalid bearer credential` This happened with version 1.18.3. I upgraded to 1.18.18, and it kept happening. I then connected to DeepSeek V4 Flash on my opencode **go** subscription, and the request immediately succeeded, and kept working. ### Plugins None ### OpenCode version 1.18.18 ### Steps to reproduce 1. Connect to opencode zen 2. Choose DeepSeek V4 Flash (Free) as the model 3. Ask some number of requests, most of them seem to be failing at the time of reporting. ### Screenshot and/or share link With DeepSeek V4 Flash Free on OpenCode Zen: <img width=\"1896\" height=\"1642\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/bb2b2c90-7204-4f3b-a905-34dd47dcddbc\" /> With DeepSeek V4 Flash on OpenCode Go: <img width=\"1896\" height=\"1642\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/ee91724e-6030-4604-a3e7-c53bfc1f5d7c\" /> ### Operating System Ubuntu 26.04 ### Terminal Ubuntu terminal",
      "date_published": "2026-08-13T09:21:50Z",
      "date_modified": "2026-08-13T17:59:10Z",
      "tags": [
        "issue"
      ],
      "_contribution_compass": {
        "project": "anomalyco/opencode",
        "group": "coding-agent-infrastructure",
        "state": "closed",
        "assignees": [
          "MrMushrooooom"
        ],
        "change": "updated",
        "importanceScore": 12
      }
    },
    {
      "id": "2026-08-13:github:vllm-project/vllm:pull_request:51915",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/vllm/page/4/#signal-2c7767588484",
      "external_url": "https://github.com/vllm-project/vllm/pull/51915",
      "title": "[vLLM] [ROCm][Model][Bugfix] Enable GLM-5.2-MXFP4 on the deepseek_v32 path and fix sparse attention correctness",
      "content_text": "## Purpose Enables GLM-5.2 (`GlmMoeDsaForCausalLM`) end-to-end on `vllm/models/deepseek_v32/amd/` for gfx942/gfx950. Routing is opt-in via `--model-class-overrides`; the registry entry is unchanged, so the default path for GLM-5.2 and DeepSeek-V3.2 is untouched. The following issues were also fixed as a result of this overall enablement since it surfaced dormant bugs from a prior deepseek_v32 porting work: - **`launch_pdl` forwarded to a Triton runtime that doesn't accept it** — the shared `common/kernels.py` passed this CUDA-only kwarg unconditionally; ROCm's Triton rejects it by name even when `False`, so the engine died at startup with `KeyError`. Now passed only when the platform actually supports PDL. - **fp4 bmm invoked with mismatched positional args** — the output tensor landed in the kernel's `dtype` slot (`Expected 'Optional[int]' for 'dtype' but found Tensor`). Routed through the existing `rocm_aiter_ops.batched_gemm_a16wfp4` wrapper rather than calling aiter directly, so the argument contract lives in one place. - **fp4 MLA bmm silently wrong for non-power-of-two K** — `batched_gemm_a16wfp4` only supports power-of-two K, and returns wrong values without erroring otherwi",
      "date_published": "2026-08-12T02:59:15Z",
      "date_modified": "2026-08-13T17:59:08Z",
      "tags": [
        "pull_request",
        "bug",
        "rocm",
        "needs-rebase",
        "deepseek"
      ],
      "_contribution_compass": {
        "project": "vllm-project/vllm",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 8
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54333",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent.html#signal-a4bf0086a29e",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54333",
      "title": "[Datadog Agent] Build with race detector",
      "content_text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Build with race detector. ### Motivation Make a custom build and give it a shot internally, to see if we can detect races. ### Describe how you validated your changes n/a ### Additional Notes [AGENTRUN-1159]: https://datadoghq.atlassian.net/browse/AGENTRUN-1159?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ",
      "date_published": "2026-08-03T05:47:18Z",
      "date_modified": "2026-08-13T17:58:50Z",
      "tags": [
        "pull_request",
        "do-not-merge/hold",
        "changelog/no-changelog",
        "team/agent-apm",
        "component/system-probe",
        "team/agent-security",
        "team/ebpf-platform",
        "qa/done",
        "long review",
        "team/agent-runtimes",
        "team/agent-metric-pipelines",
        "team/agent-devx",
        "team/container-experiences",
        "team/windows-products",
        "team/action-platform",
        "team/profiling-full-host",
        "internal",
        "team/fleet-automation"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 18
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:issue:73030",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/2/#signal-24fe395a3bb9",
      "external_url": "https://github.com/NousResearch/hermes-agent/issues/73030",
      "title": "[Hermes Agent] [Bug] Child Kanban subscriptions drop chat_type and delivery_metadata during inheritance",
      "content_text": "### Summary At commit `373632e33813c86b1b9b024168a5892af1926b83`, `hermes_cli/kanban_db.py::_inherit_notify_subs()` copies a parent task’s notification subscription to a child but omits the `chat_type` and `delivery_metadata` columns. The same omission remained on `main` when rechecked on 2026-07-27. Subscriptions created by gateway `/kanban create` and tool-driven `kanban_create` can carry both fields. The explicit CLI subscription path can carry `chat_type`. `create_task(..., parents=...)`, `link_tasks()`, and `decompose_triage_task()` all call the inheritance helper, so inherited child rows silently lose available routing metadata. ### Impact The recipient identifiers (`chat_id`, `user_id`, and `thread_id`) are preserved, so this is not a cross-recipient delivery issue. However: - creator-wake reconstruction falls back to `chat_type=\"group\"`, causing a DM-originated child completion to wake a fresh group-scoped session instead of the originating DM session; - Telegram DM-topic subscriptions lose their persisted reply-fallback and topic metadata, while `message_thread_id` alone can render outside the intended visible lane. ### Reproduction 1. Add a parent notification subscriptio",
      "date_published": "2026-07-28T01:33:54Z",
      "date_modified": "2026-08-13T17:58:46Z",
      "tags": [
        "issue",
        "type/bug",
        "comp/cron",
        "platform/telegram",
        "P3",
        "sweeper:risk-session-state",
        "sweeper:risk-message-delivery"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "closed",
        "assignees": [],
        "change": "new",
        "importanceScore": 5
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114531",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/7/#signal-382be57f1434",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114531",
      "title": "[ClickHouse] Reject a lossy codec on columns backing keys and indexes",
      "content_text": "Closes: https://github.com/ClickHouse/ClickHouse/issues/114406 ### Changelog category (leave one): - Bug Fix (user-visible misbehavior in an official stable release) ### Changelog entry (a [user-readable short description](https://github.com/ClickHouse/ClickHouse/blob/master/docs/changelog_entry_guidelines.md) of the changes that goes into CHANGELOG.md): A lossy codec such as `SZ3` is now rejected at DDL time on any column that backs the sorting key, primary key, partition key, a secondary index or the unique key. Because such a codec does not return the value that was written, a merged part could be stored out of physical order and index analysis would skip rows matching the query. Column statistics are no longer built for, or used to prune parts by, a lossily compressed column, which returned too few rows on default settings. Existing tables stay loadable. ### Description `ORDER BY` makes a physical promise: rows are stored inside a part in sorting-key order and the primary index samples those stored values. A lossy codec breaks `read(write(v)) == v`, so the merge sorts pre-compression values while the part stores post-compression ones. `SZ3` is not monotonic, so the stored seque",
      "date_published": "2026-08-12T18:16:56Z",
      "date_modified": "2026-08-13T17:58:38Z",
      "tags": [
        "pull_request",
        "pr-bugfix",
        "can be tested"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 5
      }
    },
    {
      "id": "2026-08-13:github:astral-sh/uv:pull_request:21098",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/developer-infrastructure/uv/page/2/#signal-9c3efebee306",
      "external_url": "https://github.com/astral-sh/uv/pull/21098",
      "title": "[uv] Add regression test for uv#21096",
      "content_text": "Add a minimal integration test that reproduces astral-sh/uv#21096.",
      "date_published": "2026-08-13T17:58:34Z",
      "date_modified": "2026-08-13T17:58:36Z",
      "tags": [
        "pull_request",
        "internal",
        "testing"
      ],
      "_contribution_compass": {
        "project": "astral-sh/uv",
        "group": "developer-infrastructure",
        "state": "open",
        "assignees": [
          "zanieb"
        ],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85509",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/9/#signal-9beb6dc56ca1",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85509",
      "title": "[Hermes Agent] fix(agent): write context-length cache atomically",
      "content_text": "## Summary The context-length cache was written with a plain truncating `open(path, \"w\")` — a crash/kill mid-dump leaves empty or partial YAML, and the next load swallows the parse error and returns `{}`, silently wiping every persisted context length. Both writers now use the existing `atomic_yaml_write()` (temp file + fsync + `os.replace`). Salvages #40919 by @sasquatch9818 (cherry-picked, authorship preserved), the cleaner of the two duplicate implementations. #35140 by @annguyenNous proposed the same fix 8 days EARLIER — first-submitter credit to @annguyenNous; #40919 was picked for its regression test and comments. ## Changes - `agent/model_metadata.py`: `save_context_length()` + `_invalidate_cached_context_length()` → `atomic_yaml_write()`. - `tests/agent/test_model_metadata.py`: interrupted-write-leaves-cache-intact regression test. ## Validation | | Result | |---|---| | `test_model_metadata.py` | 75/75 pass | | Stale-base gate | 0 behind, 2-file diff | ## Infographic ![Atomic cache write — no torn YAML](https://files.catbox.moe/uachrd.png)",
      "date_published": "2026-08-13T17:58:36Z",
      "date_modified": "2026-08-13T17:58:36Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:temporalio/temporal:pull_request:11232",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/platform-infrastructure/temporal.html#signal-627253405072",
      "external_url": "https://github.com/temporalio/temporal/pull/11232",
      "title": "[Temporal] VLN-1574: remediate checkout-below-v7",
      "content_text": "> 🏕️ This pull request was created by [camper](https://github.com/temporalio/camper), an automated security campaign tool. ## Finding <table> <tr><td><strong>Rule</strong></td><td><code>checkout-below-v7</code></td></tr> <tr><td><strong>Severity</strong></td><td>HIGH</td></tr> <tr><td><strong>Repository</strong></td><td><code>temporalio/temporal</code></td></tr> <tr><td><strong>Ticket</strong></td><td><a href=\"https://temporalio.atlassian.net/browse/VLN-1574\">VLN-1574</a></td></tr> </table> ## Summary - `.github/workflows/build-and-publish.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. - `.github/workflows/check-release-dependencies.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/ci-success-report.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/docker-build-manual.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. - `.github/workflows/features-integration.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/flaky-tests-report.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflo",
      "date_published": "2026-07-23T15:57:20Z",
      "date_modified": "2026-08-13T17:58:35Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "temporalio/temporal",
        "group": "platform-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 1
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:113681",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/2/#signal-0609f41299a5",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/113681",
      "title": "[ClickHouse] Replace the per-bucket hash map in `timeSeries*ToGrid` with a sorted-append sample array",
      "content_text": "### Changelog category (leave one): - Performance Improvement ### Changelog entry (a [user-readable short description](https://github.com/ClickHouse/ClickHouse/blob/master/docs/changelog_entry_guidelines.md) of the changes that goes into CHANGELOG.md): Replaced the per-bucket hash map inside the `timeSeries*ToGrid` aggregate functions with a flat sorted array of samples: sample ingestion becomes an O(1) append for in-order inputs (the overwhelmingly common case) and the per-bucket copy-and-sort at finalization is gone. ### Description The `timeSeries*ToGrid` functions kept each bucket's samples in an `absl::flat_hash_map<timestamp, value>`: every `add()` paid a hash-map emplace, and the order-dependent functions (`rate`, `increase`, `delta`, `changes`, `resets`) copied and sorted every bucket at finalization. Yet the input is almost perfectly ordered — samples come from MergeTree tables sorted by `(id, timestamp)`; an instrumented probe on a 32-thread read of a 62.5-billion-sample table counted **1 out-of-order add in 1,474,559,998**. The bucket is now a flat, memory-tracked vector of `(timestamp, value)` pairs: O(1) append while timestamps ascend, in-place max on an equal timestam",
      "date_published": "2026-08-06T13:46:38Z",
      "date_modified": "2026-08-13T17:58:34Z",
      "tags": [
        "pull_request",
        "pr-performance",
        "comp-promql"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [
          "vitlibar"
        ],
        "change": "updated",
        "importanceScore": 20
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85507",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/9/#signal-c5def71d2f99",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85507",
      "title": "[Hermes Agent] fix(agent): guard against non-positive context_length poisoning the cache",
      "content_text": "## Summary A cached `context_length` of 0 (corrupted cache, failed probe, manual edit) poisoned the whole resolution chain: `0 is not None` short-circuits step 1, so the compressor and every downstream display got context_length=0 forever. This refuses to persist non-positive values and drops any pre-existing non-positive entry so it re-resolves. Salvages #25812 by @OmarB97 (cherry-picked, authorship preserved). The original shipped without tests; we added sabotage-verified regression coverage on top. ## Changes - `agent/model_metadata.py` (@OmarB97): `save_context_length()` refuses `length <= 0`; step-1 drops `cached <= 0` entries and re-resolves. - `tests/agent/test_model_metadata.py` (ours): never-persisted + dropped-and-re-resolved regression tests. ## Validation | | Result | |---|---| | `test_model_metadata.py` | 76/76 pass | | Sabotage run (guard disabled) | both new tests fail as expected, restore → green | ## Infographic ![Zero poisons the cache — non-positive context lengths rejected](https://files.catbox.moe/8jaai3.png)",
      "date_published": "2026-08-13T17:58:34Z",
      "date_modified": "2026-08-13T17:58:34Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:vllm-project/vllm:pull_request:51793",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/vllm/page/4/#signal-9481185f4b08",
      "external_url": "https://github.com/vllm-project/vllm/pull/51793",
      "title": "[vLLM] [Quantization] Remove dead `QuantizationConfig.is_mxfp4_quant`",
      "content_text": "## Purpose This is dead code following https://github.com/vllm-project/vllm/pull/37128. This was originally added in https://github.com/vllm-project/vllm/pull/29008 that supported padding for gpt-oss / certain MXFP4 backends, see: https://github.com/xuebwang-amd/vllm/blob/c62f664e97977ee54ab1d1c77604ebb45081bc06/vllm/model_executor/layers/fused_moe/layer.py#L259-L277 This is now handled in: https://github.com/vllm-project/vllm/blob/490259c1f63faf025b8050504db63d81c817d781/vllm/model_executor/layers/fused_moe/oracle/mxfp4.py#L640 ## Test Plan N/A ## Test Result N/A",
      "date_published": "2026-08-11T09:46:17Z",
      "date_modified": "2026-08-13T17:58:31Z",
      "tags": [
        "pull_request",
        "ready",
        "quantization"
      ],
      "_contribution_compass": {
        "project": "vllm-project/vllm",
        "group": "ai-infrastructure",
        "state": "closed",
        "assignees": [],
        "change": "updated",
        "importanceScore": 8
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:44772",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent.html#signal-ba39ce0feb44",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/44772",
      "title": "[Hermes Agent] fix(cli): drop agent-browser/@streamdown-math from root npm deps",
      "content_text": "## What does this PR do? `hermes update` was pruning root-level Node dependencies (e.g. `agent-browser`) on every run. This PR originally tried to fix that by juggling install order between the root and ui-tui/web workspace installs; that approach didn't hold up under review. The old two-pass shape (`npm ci --workspaces=false` then `npm ci --workspace ui-tui --workspace web`) reliably prunes a root-only dependency on its second pass, confirmed empirically and via npm/cli source. A single-pass `npm ci --workspace ui-tui --workspace web --include-workspace-root` does keep a root-only dependency (`--include-workspace-root` is consumed via `flatOptions` into Arborist's `includeWorkspaceRoot`, independent of the two-pass shape's problem), so a flag-only fix was possible. This PR takes a different approach anyway, removing the root-only dependencies entirely, because it also eliminates the manifests-digest skip-marker problem a flag-only fix would still have to handle explicitly, and it doesn't depend on one flag's semantics staying stable across future npm versions: 1. **agent-browser is no longer a root `package.json` dependency.** It resolves lazily via `npx agent-browser` (`tools/bro",
      "date_published": "2026-06-12T08:22:34Z",
      "date_modified": "2026-08-13T17:58:27Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/cli",
        "tool/browser",
        "P2",
        "sweeper:risk-compatibility",
        "sweeper:risk-platform-windows",
        "sweeper:blast-moderate",
        "comp/desktop",
        "platform/windows",
        "area/install-update"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "closed",
        "assignees": [],
        "change": "new",
        "importanceScore": 13
      }
    },
    {
      "id": "2026-08-13:github:BerriAI/litellm:pull_request:33757",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/litellm/page/2/#signal-91fb30e3e9f6",
      "external_url": "https://github.com/BerriAI/litellm/pull/33757",
      "title": "[LiteLLM] fix(azure_ai): recognize real Search doc endpoints so teams can read/write via passthrough",
      "content_text": "## Relevant issues Non-admin teams cannot upload documents to, read the details of, or run most of the query endpoints on an Azure AI Search index through the passthrough, even when an admin has granted them access ## Linear ticket ## Pre-Submission checklist - [x] I have added meaningful tests - [x] My PR passes all CI/CD checks (e.g., lint, format, unit tests) - [x] My PR's scope is as isolated as possible; it only solves 1 specific problem - [x] I have received a Greptile **Confidence Score of at least 4/5** before requesting a maintainer review ## Screenshots / Proof of Fix Captured against a local proxy on `:4000` wired to a real Azure AI Search service, no mocks, every call hitting the Search data plane. Setup: the admin master key registered the index and created it physically over the passthrough, then a team was granted `allowed_vector_store_indexes` with `read` and `write` on that index and a non-admin virtual key was minted for that team. Every call below runs as that team key. Service hostnames are redacted. Before, at `4d33964898`, the commit this branch starts from, the team key is refused on nine of the ten non-lifecycle routes despite holding a grant on the index. O",
      "date_published": "2026-07-17T18:54:18Z",
      "date_modified": "2026-08-13T17:58:25Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "BerriAI/litellm",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 7
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114323",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/9/#signal-5cff885b95c1",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114323",
      "title": "[ClickHouse] Docs: require canonical internal links",
      "content_text": "Related: https://github.com/ClickHouse/ClickHouse/pull/114230 This is a one-off cleanup of repository-authored documentation links that use legacy redirect aliases. It updates the current English documentation and source-embedded reference documentation to use routes relative to the docs root, so the automated translation PR can parse and localize them without producing missing locale routes. This PR intentionally adds no permanent CI checks or ongoing enforcement. Its scope is limited to the current link corrections needed to get the automated translation PR parsing successfully. CI report: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=114230&sha=e599855a281a4dd841be20794036908a58acbf63&name_0=PR&name_1=Docs%20check%20%28Mintlify%29 CI report: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=114323&sha=86d2d7e194d7fbf75cc84616a8fa0da1ed84802e&name_0=PR&name_1=Docs%20check%20%28Mintlify%29 ### Changelog category (leave one): - CI Fix or Improvement (changelog entry is not required) ### Changelog entry (a [user-readable short description](https://github.com/ClickHouse/ClickHouse/blob/master/docs/changelog_entry_guidelines.md) of the changes that goes int",
      "date_published": "2026-08-11T13:26:47Z",
      "date_modified": "2026-08-13T17:58:20Z",
      "tags": [
        "pull_request",
        "pr-ci",
        "pr-autogenerated-docs"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 3
      }
    },
    {
      "id": "2026-08-13:github:openai/codex:issue:11023",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/codex.html#signal-338ef8f9eea3",
      "external_url": "https://github.com/openai/codex/issues/11023",
      "title": "[Codex] Codex desktop app for Linux",
      "content_text": "### What variant of Codex are you using? App ### What feature would you like to see? I love the new codex app. However due to [this issue](https://github.com/openai/codex/issues/10432) it is almost unusable on my mac laptop. I would like to use the app on my linux desktop where power consumption is far less of an issue. ### Additional information _No response_",
      "date_published": "2026-02-07T17:34:16Z",
      "date_modified": "2026-08-13T17:58:20Z",
      "tags": [
        "issue",
        "enhancement",
        "app"
      ],
      "_contribution_compass": {
        "project": "openai/codex",
        "group": "coding-agent-infrastructure",
        "state": "closed",
        "assignees": [],
        "change": "new",
        "importanceScore": 64
      }
    },
    {
      "id": "2026-08-13:github:sgl-project/sglang:pull_request:34608",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/sglang/page/4/#signal-35162b069e9b",
      "external_url": "https://github.com/sgl-project/sglang/pull/34608",
      "title": "[SGLang] Publish per-scheduler load on a dedicated socket for load-aware routers",
      "content_text": "## Motivation The cache-aware-zmq router infers a worker's load from a router-side in-flight counter. That counter measures what *this router* dispatched — it misses traffic from other routers and direct clients, and for streaming responses it stays held for the whole response rather than the time the request occupies the scheduler. The engine already builds the right number: `SchedulerLoadInquirer.get_loads()` produces a `LoadSnapshot` every publish cycle (feeding `/v1/loads` and DP-attention dispatch). This exposes that snapshot to out-of-process consumers so a router can price workers on real queue depth / KV occupancy. Ported to `main` from a production branch; the router-side consumer lands separately. ## Modifications **A dedicated per-scheduler load PUB socket.** `SchedulerLoadPublisher` publishes a compact `LoadStat` gauge (`num_running_reqs`, `num_waiting_reqs`, `num_tokens`, `max_total_num_tokens`) on its own ZMQ PUB socket, independent of KV-cache events. The payload is a tagged subset of `LoadSnapshot` so the router-facing wire contract stays fixed as the internal snapshot grows. Framing matches the KV-event socket (`[b\"load\", big-endian i64 seq, msgpack LoadStat]`) so ",
      "date_published": "2026-08-12T17:43:45Z",
      "date_modified": "2026-08-13T17:58:19Z",
      "tags": [
        "pull_request",
        "documentation",
        "run-ci"
      ],
      "_contribution_compass": {
        "project": "sgl-project/sglang",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [
          "Kangyan-Zhou",
          "alexnails"
        ],
        "change": "updated",
        "importanceScore": 3
      }
    },
    {
      "id": "2026-08-13:github:sgl-project/sglang:pull_request:33554",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/sglang/page/4/#signal-df30ebbae513",
      "external_url": "https://github.com/sgl-project/sglang/pull/33554",
      "title": "[SGLang] Add new spec-dec support and quant recipe for Nano v3",
      "content_text": "## Motivation Add support for Nemotron 3.5 including DFlash and DSpark spec-dec ## Modifications <!-- Detail the changes made in this pull request. --> ## Accuracy Tests <!-- If this pull request affects model outputs (e.g., changes to the kernel or model forward code), provide accuracy test results. --> ## Speed Tests and Profiling <!-- If this pull request impacts inference speed, provide benchmarking and profiling results. --> ## Checklist - [ ] Format your code according to the [Format code with pre-commit](https://docs.sglang.io/developer_guide/contribution_guide.html#format-code-with-pre-commit). - [ ] Add unit tests according to the [Run and add unit tests](https://docs.sglang.io/developer_guide/contribution_guide.html#run-and-add-unit-tests). - [ ] Update documentation according to [Write documentations](https://docs.sglang.io/developer_guide/contribution_guide.html#write-documentations). - [ ] Provide accuracy and speed benchmark results according to [Test the accuracy](https://docs.sglang.io/developer_guide/contribution_guide.html#test-the-accuracy) and [Benchmark the speed](https://docs.sglang.io/developer_guide/contribution_guide.html#benchmark-the-speed). - [ ] Follow ",
      "date_published": "2026-08-04T13:09:55Z",
      "date_modified": "2026-08-13T17:58:06Z",
      "tags": [
        "pull_request",
        "quant",
        "speculative-decoding",
        "new-model"
      ],
      "_contribution_compass": {
        "project": "sgl-project/sglang",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [
          "b8zhong"
        ],
        "change": "updated",
        "importanceScore": 3
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:77507",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/4/#signal-409673d995bf",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/77507",
      "title": "[Hermes Agent] fix(desktop): eliminate sidebar scroll jitter during dynamic sizing",
      "content_text": "## What does this PR do? Stops the Desktop sessions sidebar from jumping/flickering while you scroll a long virtualized list. Native scroll anchoring was fighting the virtualizer’s padding updates, and date-divider rows were estimated at the session-row height. Rebased onto current `main` so inbox-style card rows keep the 66px estimate. A naive replay of the original `estimateSize` line would have sized every non-divider row at 28px, including cards. Not in this PR: mouse-wheel dead-zones once the list is long (~25+ sessions), where the wheel stops mid-list but dragging the scrollbar still works. Tracked as #84964. ## Related Issue Fixes #77505 ## Type of Change - [x] 🐛 Bug fix (non-breaking change that fixes an issue) - [ ] ✨ New feature (non-breaking change that adds functionality) - [ ] 🔒 Security fix - [ ] 📝 Documentation update - [ ] ✅ Tests (adding or improving test coverage) - [ ] ♻️ Refactor (no behavior change) - [ ] 🎯 New skill (bundled or hub) ## Changes Made - `apps/desktop/src/app/chat/sidebar/virtual-session-list.tsx`: disable native scroll anchoring on the virtual list container. - Same file: `estimateSize` is divider 26px / compact session 28px / card session 66px. ",
      "date_published": "2026-08-03T08:42:55Z",
      "date_modified": "2026-08-13T17:58:03Z",
      "tags": [
        "pull_request",
        "type/bug",
        "P2",
        "comp/desktop"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 2
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54834",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent.html#signal-eccfab9fc02e",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54834",
      "title": "[Datadog Agent] ci: default GitLab jobs to shallow clones, keep full history where needed",
      "content_text": "## Summary - Default GitLab jobs to `GIT_DEPTH: 1` so most checkouts are a shallow clone of HEAD only. - Set `GIT_DEPTH: 0` on jobs that actually need git history (merge-base, ancestor walks, `git describe`, `git log` ranges, three-dot diffs, or checkout of another branch). - Jobs that inherit a full-history template but never use merge-base stay at depth 1 (`new-e2e-unit-tests`, upgrade/RPM install-package jobs). - `GIT_STRATEGY: clone` is not a full clone; clone with depth 1 is still shallow. Full history requires `GIT_DEPTH: 0`. Supersedes https://github.com/DataDog/datadog-agent/pull/54799 (opened from a fork). ## Test plan - [ ] Confirm a typical build/lint job clones with depth 1 and still has the working tree. - [ ] Confirm jobs that compute merge-base still succeed (`golang_deps_diff`, e2e `--impacted`, `static_quality_gates`, `files_inventory_check`, SMP merge-base check). - [ ] Confirm `setup_agent_version` can still run `git describe --tags`. - [ ] Confirm unit-test jobs with `FAST_TESTS=true` still detect impacted packages. - [ ] Confirm `benchmark` can check out `BASE_BRANCH` and `prebuild-workspace-image-check` can three-dot diff against `COMPARE_TO_BRANCH`. Made with",
      "date_published": "2026-08-13T14:03:09Z",
      "date_modified": "2026-08-13T17:58:00Z",
      "tags": [
        "pull_request",
        "changelog/no-changelog",
        "team/agent-apm",
        "team/agent-security",
        "team/ebpf-platform",
        "qa/no-code-change",
        "team/container-platform",
        "team/agent-delivery",
        "long review",
        "team/agent-integrations",
        "team/container-integrations",
        "team/agent-devx",
        "team/agent-build",
        "team/windows-products",
        "team/profiling-full-host",
        "internal"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 18
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114283",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/7/#signal-c806db8aa858",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114283",
      "title": "[ClickHouse] Add pre-hook to insert CI links into PR body",
      "content_text": "### Changelog category (leave one): - CI Fix or improvement (changelog entry is not required) -- Adds a `ci_links.py` pre-hook to the `PR` workflow that, on upstream `ClickHouse/ClickHouse` pull request runs, appends a `:ci_links:` block to the PR description with: - a link to the workflow report, and - a link to a GitHub search for the corresponding sync PR (`sync-upstream/pr/<number>`). The block is added only when it is not already present, so subsequent runs do not re-edit the PR body. Non-upstream / non-PR runs are skipped, and any failure is caught so it can never break the workflow. <!-- CI automatic block start :ci_links: --> --- Workflow [[PR](https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=114283&sha=latest&name_0=PR)] Sync PR [[sync-upstream/pr/114283](https://github.com/search?q=head%3Async-upstream%2Fpr%2F114283+org%3AClickHouse+type%3Apr&type=pullrequests)] <!-- CI automatic block end :ci_links: -->",
      "date_published": "2026-08-11T07:48:23Z",
      "date_modified": "2026-08-13T17:58:00Z",
      "tags": [
        "pull_request",
        "pr-ci"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 5
      }
    },
    {
      "id": "2026-08-13:github:anthropics/claude-code:issue:86464",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/claude-code/page/19/#signal-9d0c8b7771dc",
      "external_url": "https://github.com/anthropics/claude-code/issues/86464",
      "title": "[Claude Code] [BUG] MCP progress notifications are received but discarded once a call is auto-backgrounded at 120s",
      "content_text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When an MCP tool call exceeds the 120s foreground limit, Claude Code moves it to the background — and from that moment the progress the server is streaming becomes unobservable. Opening the background task manager (`↓` to manage) gives one static row per task: ``` Background MCP tasks (1) ❯ ⏳ slowstream/slow_stream · klxdvixp · working ↑/↓ to select · x to stop · Esc to close ``` A tool name, an opaque task ID, and the frozen word `working`. The server is emitting a `notifications/progress` every two seconds with a human-readable `message` — 600 of them over a twenty-minute call — and none of it appears here. **The notifications are received; they are then deliberately discarded.** The `onprogress` callback on the call stays live for the whole call and is actively used — it disarms the transport watchdog and refreshes the idle-timeout timestamp ",
      "date_published": "2026-08-13T17:52:25Z",
      "date_modified": "2026-08-13T17:57:53Z",
      "tags": [
        "issue",
        "bug",
        "has repro",
        "platform:macos",
        "area:tui",
        "area:mcp"
      ],
      "_contribution_compass": {
        "project": "anthropics/claude-code",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 4
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85263",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/2/#signal-81000f630b55",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85263",
      "title": "[Hermes Agent] fix(webhook): stop route scripts from losing authenticated delivery identity",
      "content_text": "## What does this PR do? Webhook route scripts currently receive only payload JSON, so they cannot bind work to the event type and delivery identity that Hermes authenticated. This change passes bounded request metadata through a sanitized environment, rejects script deliveries without an external identity, and applies idempotency before script execution so a retry cannot run a stateful script twice. ### Symptom A signed GitHub webhook reaches a configured route script without `X-GitHub-Event` or `X-GitHub-Delivery`. A repeated delivery can also execute the script again before Hermes recognizes the duplicate. ### Impact Stateful script consumers cannot reliably associate processing with the authenticated delivery. They must otherwise infer identity from attacker-controlled payload data, and duplicate webhook retries can repeat script side effects. ### Bug Cause **Trigger:** `gateway/platforms/webhook.py:738` in `WebhookAdapter._handle_webhook` **Causal chain:** 1. Hermes validates the request signature and resolves the event type from request headers. 2. The adapter calls `run_route_script` with only parsed payload data, and it checks delivery idempotency only after the script retu",
      "date_published": "2026-08-13T11:38:59Z",
      "date_modified": "2026-08-13T17:57:51Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/gateway",
        "platform/webhook",
        "P2",
        "sweeper:risk-message-delivery"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 6
      }
    },
    {
      "id": "2026-08-13:github:anomalyco/opencode:issue:6719",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/opencode.html#signal-2b3b3806ca55",
      "external_url": "https://github.com/anomalyco/opencode/issues/6719",
      "title": "[OpenCode] [FEATURE]: slash command for reload",
      "content_text": "### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request A `/reload` that reloads config files like `opencode.jsonc` of global and project level and also `.opencode/` this way without having to close and open the tui just able to reload easily could be even better done when a `/compact` is runnning",
      "date_published": "2026-01-03T02:53:24Z",
      "date_modified": "2026-08-13T17:57:46Z",
      "tags": [
        "issue"
      ],
      "_contribution_compass": {
        "project": "anomalyco/opencode",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [
          "rekram1-node"
        ],
        "change": "new",
        "importanceScore": 52
      }
    },
    {
      "id": "2026-08-13:github:vllm-project/vllm:pull_request:52183",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/vllm/page/5/#signal-a11c53319e20",
      "external_url": "https://github.com/vllm-project/vllm/pull/52183",
      "title": "[vLLM] [Core] Update PyTorch to 2.14.0, torchvision to 0.29.0, triton to 3.8.0 (test channel)",
      "content_text": "## Purpose Update the PyTorch ecosystem to the **2.14.0** release candidate, resolving wheels from the PyTorch **test channel** (`download.pytorch.org/whl/test/...`): - `torch`: → **2.14.0** - `torchvision`: → **0.29.0** - `triton`: → **3.8.0** 2.14.0 is published on `download.pytorch.org/whl/test/` but not yet on the release index / PyPI, so the index URLs point at the test channel. This mirrors the 2.13.0 test PR #45731. ### Verified availability (test channel) before pinning - `torch-2.14.0+cu130`: present - `torchvision-0.29.0`: present - `triton==3.8.0`: present, and is exactly what `pytorch` `release/2.14` pins in `.ci/docker/triton_version.txt` - `torchaudio`: newest published is still **2.11.0** on every channel, so that pin is unchanged ### ROCm `requirements/build/rocm.txt` moves from the `rocm7.1` index to `test/rocm7.2`. `rocm7.1` has no torch 2.14.0 wheels — 2.14 is built for `rocm7.2` and `rocm7.14` only. That file was also still on torch 2.11.0 / triton 3.6.0, so this brings it in line with `CMakeLists.txt`'s `TORCH_SUPPORTED_VERSION_ROCM`. ### Ray dependency-compatibility check `.buildkite/scripts/check-ray-compatibility.sh` now offers `uv` both the stable and test ",
      "date_published": "2026-08-13T14:56:49Z",
      "date_modified": "2026-08-13T17:57:44Z",
      "tags": [
        "pull_request",
        "ci/build",
        "cpu",
        "nvidia"
      ],
      "_contribution_compass": {
        "project": "vllm-project/vllm",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 7
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:issue:4438",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/2/#signal-f8fa6569b2e9",
      "external_url": "https://github.com/NousResearch/hermes-agent/issues/4438",
      "title": "[Hermes Agent] [Feature]: Rich Spreadsheet Skill (xlsx / csv)",
      "content_text": "## Current behavior hermes-agent can read and write files with its terminal tool, but Excel/spreadsheet handling relies on raw Python (`openpyxl`, `pandas`) with no structured abstraction. The agent has to figure out the library, the sheet structure, and error handling from scratch every time. This leads to inconsistent results — formatting is lost on round-trips, the wrong library is chosen for the task, and CSV vs. XLSX differences are handled ad hoc. ## Desired behavior A dedicated `spreadsheet` skill in `~/.hermes/skills/` that gives the agent a consistent, high-level vocabulary for spreadsheet operations: ``` read_sheet(path, sheet=None) → structured JSON rows write_sheet(path, rows, sheet=None) → creates/overwrites sheet apply_formula(path, cell, formula) → sets a formula and recalculates pivot(path, rows, cols, values, agg) → builds a pivot table chart(path, type, data_range, title) → embeds a chart into the workbook diff(path_a, path_b) → highlights cell-level changes ``` A CSV fallback path should handle plain CSVs without requiring Excel dependencies. This mirrors the pattern used by the existing `pdf` and `browser` skills. ## Implementation sketch - **Core wrapper** arou",
      "date_published": "2026-04-01T11:09:18Z",
      "date_modified": "2026-08-13T17:57:40Z",
      "tags": [
        "issue",
        "type/feature",
        "tool/skills",
        "P3"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 7
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:99495",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse.html#signal-0647f6bb0863",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/99495",
      "title": "[ClickHouse] Add `GradualResizeProcessor` to limit effective parallelism for GROUP BY on small data volumes",
      "content_text": "When ClickHouse processes GROUP BY, it often overestimates the number of threads needed. With `max_threads = 64` but only a few thousand rows, all 64 `AggregatingTransform` instances get data, produce 64 partial hash tables, and the merge phase has to combine all of them — most nearly empty. This wastes time on merging overhead, which is especially noticeable for heavy aggregate states such as `uniq`, `uniqExact`, `groupArray`, etc. The new `GradualResizeProcessor` starts by pushing data to a single output port (or one port per split group when `min_outstreams_per_resize_after_split` applies), and activates all aggregation streams at once as soon as the configured row or byte threshold is crossed. For small datasets, only one aggregating thread receives data (or one per split group); for large datasets, all threads are used as before. New settings: - `min_rows_per_stream_for_gradual_resize` (default: `1000`) - `min_bytes_per_stream_for_gradual_resize` (default: `0`) When either threshold is non-zero, the pre-aggregation `StrictResize` is replaced with `GradualResize` in the pipeline. The optimization is enabled by default; set both `min_rows_per_stream_for_gradual_resize = 0` and `",
      "date_published": "2026-03-14T07:35:33Z",
      "date_modified": "2026-08-13T17:57:39Z",
      "tags": [
        "pull_request",
        "pr-performance"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [
          "nihalzp"
        ],
        "change": "updated",
        "importanceScore": 29
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54852",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent/page/3/#signal-908a7eae4ae9",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54852",
      "title": "[Datadog Agent] [NTWK-812] Filter dynamic tests across all reverse-DNS names",
      "content_text": "What does this PR do? Fixes Network Path dynamic tests scheduling traceroutes against Datadog's own intake backends (e.g. l4-metrics-agent-*.elb.us-east-1.amazonaws.com) despite the default *.datadoghq.com connection-filter exclude. - Adds ConnFilter.EvaluateDomains(domains, ip), which evaluates every DNS name a destination IP reverse-resolves to (via the existing last-match-wins chain) instead of only the first. A connection is excluded if any of its names is excluded, and the returned hostname is the preferred name for the path test (an include-matched name, else the first included name). - Plumbs the full name list end-to-end: adds Domains []string to NetworkPathConnection, a getDNSNamesForIP helper in both connection builders (pkg/network/sender, pkg/process/checks), and wires npcollector to filter on it and use the selected hostname. - Adds l4-metrics-agent-*.elb.*.amazonaws.com to the default excludes as hardening for the case where only the ELB name is cached. Customer include filters still override the defaults, so Datadog domains can be re-enabled if desired. Motivation [NTWK-812 / ZD 2972181](https://datadoghq.atlassian.net/browse/NTWK-812). A destination IP for a Datadog",
      "date_published": "2026-08-13T17:33:46Z",
      "date_modified": "2026-08-13T17:57:36Z",
      "tags": [
        "pull_request",
        "component/system-probe",
        "medium review",
        "team/cloud-network-monitoring",
        "team/network-path",
        "internal"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 5
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:53085",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent/page/2/#signal-948100adac7b",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/53085",
      "title": "[Datadog Agent] feat(serverless-init): add standalone MicroVM lifecycle HTTP server",
      "content_text": "## Summary This adds the MicroVM lifecycle HTTP server itself: an `http.Server` listening on the configured port, handling the six lifecycle hooks the AWS MicroVM platform sends — `/ready`, `/validate`, `/run`, `/resume`, `/suspend`, and `/terminate` — in **standalone** mode, i.e. the agent answers each hook itself rather than forwarding it to a user application (that pass-through mode is added later in this stack). The motivation is to give the agent visibility into a MicroVM's full lifecycle without requiring any cooperation from the user's own application: `/ready` reports child-process liveness so the platform knows when it's safe to snapshot; `/run`/`/resume`/`/suspend`/`/terminate` each emit an enhanced lifecycle metric (tagged with the MicroVM instance ID once known), and `/suspend`/`/terminate` additionally flush all pending telemetry (metrics, traces, logs) before responding, since those are the two points where telemetry could otherwise be lost — either frozen into a snapshot or torn down with the VM. `/run`'s request body (the `runHookPayload` a caller passes to `RunMicrovm`) is capped at **1 MiB** via `http.MaxBytesReader` before being buffered; a body exceeding the cap",
      "date_published": "2026-07-01T16:12:21Z",
      "date_modified": "2026-08-13T17:57:27Z",
      "tags": [
        "pull_request",
        "long review",
        "aws-microvm"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 6
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:53092",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent/page/3/#signal-49edd34863d7",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/53092",
      "title": "[Datadog Agent] feat(serverless-init): add ProcessHooks for subprocess liveness tracking",
      "content_text": "### What does this PR do? Adds a `*ProcessHooks` parameter (`OnAlive`/`OnDead`) to `mode.RunInit` and its internal `execute()`, so a caller can be notified when the spawned user process starts and exits. `mode.Conf.Runner` is dropped for init-container mode — its field type (`func(*serverlessLog.Config) error`) can no longer match `RunInit`'s new two-argument signature, so `main.go` switches from calling `modeConf.Runner(logConfig)` to `cloudService.Run(modeConf, logConfig)`, which already exists on the `CloudService` interface and produces identical behavior for every existing cloud service (sidecar → `RunSidecar`, init-container → `RunInit` with `nil` hooks). Also adds `cloudservice.MicroVM`, a `CloudService` implementation for AWS Lambda MicroVMs, and a `LifecycleContext` type carried on `TracingContext.LifecycleCtx`: - `GetTags` parses `DD_AWS_MICROVM_IMAGE_ARN` for `region`/`account_id`/`image_name` (falling back to `\"unknown\"` for any field it can't parse). - `GetEnhancedMetricTags` derives base/usage tag sets from those tags. - `Init` reads a `LifecycleContext` (metric/log flushers, trace-tag/log-tag setters, flush timeout, sidecar flag) and constructs + starts the lifecycle",
      "date_published": "2026-07-01T18:53:25Z",
      "date_modified": "2026-08-13T17:57:27Z",
      "tags": [
        "pull_request",
        "aws-microvm"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 4
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54828",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent/page/2/#signal-5e8ba076f22a",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54828",
      "title": "[Datadog Agent] [EBPF] gpu: add NVLink capability tag",
      "content_text": "<!--Please give us some feedback on your experience writing this PR ! https://app.datadoghq.com/forms/43db4c02-6837-400c-8083-692e141b1b88 !--> ### What does this PR do? Adds `gpu_nvlink_capable` and `gpu_nvlink_version` tags to GPU metrics. ### Motivation Knowing whether a GPU is NVlink-capable and the version of the NVlink system or not is useful to ensure the presence of certain metrics and to compare GPU performance. Another PR will also use part of this code to allow segmenting telemetry based on NVLink capability. ### Describe how you validated your changes Unit tests, manually validated in nvlink-enabled instance. ### Additional Notes Both tags might be slightly redundant but having two doesn't cost extra cardinality (gpu_uuid is already there, with one value per GPU) and it allows separating \"nvlink GPUs/non nvlink GPUs\" and between specific versions.",
      "date_published": "2026-08-13T11:52:04Z",
      "date_modified": "2026-08-13T17:57:26Z",
      "tags": [
        "pull_request",
        "team/ebpf-platform",
        "qa/done",
        "team/container-platform",
        "long review",
        "team/container-integrations",
        "internal",
        "team/gpu-monitoring-agent"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 7
      }
    },
    {
      "id": "2026-08-13:github:BerriAI/litellm:pull_request:36731",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/litellm/page/3/#signal-2aa8eb92aa34",
      "external_url": "https://github.com/BerriAI/litellm/pull/36731",
      "title": "[LiteLLM] feat(guardrails): add payload, applicability and dispatch controls to generic_guardrail_api",
      "content_text": "## TLDR Problem this solves: - Guardrail sits on the user's critical path, always - Whole transcript re-sent every turn, O(n^2) per session - Base64 images sent to text-only guardrails - Embeddings and audio calls scanned pointlessly - No way to scope a guardrail to some requests How it solves it: - `fire_and_forget` dispatches the call, request proceeds immediately - `send_images` / `exclude_payload_fields` / `max_messages` / `max_text_chars` trim the payload - `strip_patterns` removes boilerplate before it leaves LiteLLM - `skip_if_system_prompt_matches` skips out-of-scope requests entirely - `run_only_on_call_types` / `skip_call_types` scope by call type - All default to today's behavior ## User Flow Before: a team running an observe-only guardrail pays for it on every request, and their agent sessions crawl 1. A developer sends POST https://litellm-domain/v1/chat/completions with a 40-turn conversation and a screenshot 2. The request holds until the guardrail service answers, adding its full latency to every turn 3. The guardrail service receives the whole transcript again, plus the base64 screenshot it cannot read 4. Their RAG worker sends POST https://litellm-domain/v1/embedd",
      "date_published": "2026-08-13T05:01:27Z",
      "date_modified": "2026-08-13T17:57:25Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "BerriAI/litellm",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 6
      }
    },
    {
      "id": "2026-08-13:github:apple/foundationdb:pull_request:13856",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/distributed-systems/foundationdb.html#signal-040e99153cef",
      "external_url": "https://github.com/apple/foundationdb/pull/13856",
      "title": "[FoundationDB] Preserve DD maintenance start versions across transaction retries",
      "content_text": "## Summary - Preserve the first observed maintenance-window start version when a transaction must be retried. - Adopt an already committed start after ambiguous commits, concurrent writers, or data-distributor recruitment. - Retry stale-start cleanup when maintenance ends while preserving the existing maintenance tracing and durable storage format. - Cover failed starts, ambiguous commits, competing writers, failed clears, changed maintenance zones, and recruitment with six focused regression tests. ## Testing - GCC 13, `-DUSE_WERROR=ON -DWITH_ROCKSDB=OFF`: `fdbserver_datadistributor_test -f /DataDistribution/Maintenance/` - 6 passed, 0 failed. - GCC 13, `-DUSE_WERROR=ON -DWITH_ROCKSDB=OFF`: `fdbserver_datadistributor_test` - 56 passed, 0 failed. - `clang-format` 19 and `git diff --check` passed.",
      "date_published": "2026-08-12T20:04:26Z",
      "date_modified": "2026-08-13T17:57:20Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "apple/foundationdb",
        "group": "distributed-systems",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 22
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114643",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/7/#signal-d4ebfc8b9751",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114643",
      "title": "[ClickHouse] Re-land aggregate function `gini` in the `sum` family",
      "content_text": "<!-- Linked issues and pull requests. Use full GitHub URLs, one relationship per line; delete the lines you don't need. Related: https://github.com/ClickHouse/ClickHouse/issues/113763 Related: https://github.com/ClickHouse/ClickHouse/pull/113868 Related: https://github.com/ClickHouse/ClickHouse/pull/112280 --> ### Changelog category (leave one): - New Feature ### Changelog entry (a [user-readable short description](https://github.com/ClickHouse/ClickHouse/blob/master/docs/changelog_entry_guidelines.md) of the changes that goes into CHANGELOG.md): New aggregate function `gini`, which calculates the [Gini coefficient](https://en.wikipedia.org/wiki/Gini_coefficient) of a column of finite, non-negative numeric values. The result ranges from `0` (all values equal) towards `1` as inequality grows; for a sample of `n` values the maximum is `(n - 1) / n`. `NaN` values are skipped and infinite values are rejected. The function returns `Float64` and consumes `O(n)` memory. ### Description Re-lands the `gini` function that #113868 reverted, following the option-2 spec @ Manerone gave in https://github.com/ClickHouse/ClickHouse/issues/113763#issuecomment-5217284116 and confirmed in https://git",
      "date_published": "2026-08-13T13:34:59Z",
      "date_modified": "2026-08-13T17:57:20Z",
      "tags": [
        "pull_request",
        "pr-feature",
        "can be tested"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [
          "Manerone"
        ],
        "change": "updated",
        "importanceScore": 5
      }
    },
    {
      "id": "2026-08-13:github:sgl-project/sglang:pull_request:29328",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/sglang.html#signal-2780cb5b8483",
      "external_url": "https://github.com/sgl-project/sglang/pull/29328",
      "title": "[SGLang] [AMD][Quantization] Online MXFP4 quantization 4/N - NVFP4 to MXFP4 Online Requantization on AMD GPUs",
      "content_text": "## Summary Adds support in SGLang for loading and inference for ModelOpt (and Quark) NVFP4 checkpoints by dequantizing the supplied NVFP4 weights and requantizing them to MXFP4 at load time to allow efficient inference using supported AMD hardware (e.g. AMD MI355x). Enabled via `--quantization quark_mxfp4`. Weights dequantized then requantized to MXFP4 during loading, so the resulting model occupies MXFP4 memory without ever holding a full-precision copy. Also includes the config-routing and shared-expert-fusion fixes needed to load ModelOpt exports across various architectures using the existing SGLang AMD Quark integration. ## Modifications ### Online Requantization Path - **`layers/quantization/quark/quark.py`**: `_detect_nvfp4_source` detects ModelOpt and AMD Quark NVFP4 layouts; `_parse_nvfp4_excludes` extracts producer exclude lists; `from_config` routing gated on `requantization_method`. `_maybe_disable_shared_experts_fusion` delegates to the existing `can_fuse_shared_expert()` to correctly handle `shared_expert_gate` and `mtp.` exclusions. - **`layers/quantization/quark/schemes/quark_w4a4_mxfp4.py`**: NVFP4 linear scheme: `_create_weights_from_nvfp4` allocates NVFP4 staging",
      "date_published": "2026-06-25T20:10:55Z",
      "date_modified": "2026-08-13T17:57:19Z",
      "tags": [
        "pull_request",
        "documentation",
        "quant",
        "amd",
        "dependencies",
        "lora",
        "Multi-modal",
        "deepseek",
        "speculative-decoding",
        "hicache",
        "blackwell",
        "npu",
        "run-ci",
        "diffusion",
        "mthreads",
        "apple-silicon",
        "jit-kernel",
        "bypass-fastfail"
      ],
      "_contribution_compass": {
        "project": "sgl-project/sglang",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 15
      }
    },
    {
      "id": "2026-08-13:github:DataDog/datadog-agent:pull_request:54597",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/observability/datadog-agent/page/5/#signal-9a7381d63211",
      "external_url": "https://github.com/DataDog/datadog-agent/pull/54597",
      "title": "[Datadog Agent] [NDINT-652] [Agent] Accept CLI commands from payload sent via PAR",
      "content_text": "### What does this PR do? This PR adds a RunCommand action which, if enabled, allows a user to submit commands via PAR to be executed on a remote device. ### Motivation https://datadoghq.atlassian.net/browse/NDINT-652 ### Describe how you validated your changes ### Additional Notes",
      "date_published": "2026-08-07T18:39:04Z",
      "date_modified": "2026-08-13T17:57:15Z",
      "tags": [
        "pull_request",
        "long review",
        "team/ndm-integrations",
        "team/agent-build",
        "team/action-platform",
        "internal"
      ],
      "_contribution_compass": {
        "project": "DataDog/datadog-agent",
        "group": "observability",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 2
      }
    },
    {
      "id": "2026-08-13:github:apple/foundationdb:pull_request:13861",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/distributed-systems/foundationdb.html#signal-a57ae1b0ce75",
      "external_url": "https://github.com/apple/foundationdb/pull/13861",
      "title": "[FoundationDB] documentation: release-notes titles, consolidate pre-1.0",
      "content_text": "Append Major.Minor to titles of release-notes pages so they better distinguish themselves. URLs do not change, they are based on filename. Consolidate pre-1.0 alpha and beta release notes into the 1.0 page (subjective 🤷) Latest release-notes-740 keep version-less title because of links to \"latest Release Notes\" elsewhere in the docs site that would be affected by the title change. -------- The main place these updated titles can be appreciated is in the Previous Releases page (which might only be linked from the entire site index anyway): Before: <img width=\"1166\" height=\"826\" alt=\"Screenshot 2026-08-13 at 1 21 32 PM\" src=\"https://github.com/user-attachments/assets/9a247e5e-a1bf-45c7-8bbb-2c3692a98c26\" /> After: <img width=\"1187\" height=\"749\" alt=\"Screenshot 2026-08-13 at 1 20 47 PM\" src=\"https://github.com/user-attachments/assets/a5a6fb7d-8123-4334-9a16-c328a5701698\" />",
      "date_published": "2026-08-13T17:33:00Z",
      "date_modified": "2026-08-13T17:56:49Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "apple/foundationdb",
        "group": "distributed-systems",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 2
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:80135",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/5/#signal-fdeef9871276",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/80135",
      "title": "[Hermes Agent] fix(update): preserve non-prefixed systemd gateway process",
      "content_text": "## Summary Fixes an updater safety gap for **non-prefixed systemd-managed Hermes gateways**. `hermes update` already excludes active `hermes-gateway*` service PIDs from its manual-process sweep. A valid gateway run owned by a custom system unit (for example `gaiasignal-agent-hermes.service`) was not in that set, then was rediscovered as a manual process and sent `SIGTERM`. This focused patch classifies only existing positive `gateway run` candidates at the update manual-sweep boundary using `/proc/<pid>/cgroup`: - cgroup v2 `0::/...unit.service` and v1 `name=systemd:/...unit.service` => managed service, never raw-SIGTERM; - confirmed non-service membership => preserves the existing manual-cleanup behavior; - unreadable/ambiguous cgroup on Linux => fail safe and do not terminate; - no broad `systemctl` enumeration and no unit-name-prefix trust. ## Why A real custom systemd service was interrupted by the generic updater and systemd recovered it roughly five seconds later. The update code must not treat system-manager ownership as manual merely because the unit name is outside the standard `hermes-gateway*` convention. ## Verification Fork branch commit `2ece25503`: ```text uv sync --",
      "date_published": "2026-08-06T07:16:55Z",
      "date_modified": "2026-08-13T17:56:49Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/cli",
        "P2",
        "sweeper:risk-compatibility",
        "area/install-update"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:79203",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/5/#signal-ab881f252802",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/79203",
      "title": "[Hermes Agent] fix(gateway): bound systemd planned-restart helper",
      "content_text": "## Summary - bound the transient systemd planned-restart helper to `restart_drain_timeout + 5s` - after that grace period, re-read the unit's `MainPID` and only force-kill when it still matches the original gateway PID - reset and restart the unit as before, using the resolved `systemctl` path - add focused coverage for user-unit scope, timeout derivation, PID identity guard, and action ordering ## Why this is valuable A gateway can finish logical shutdown (drain timeout, adapter disconnect, state cleanup, exit code selected) yet retain a live Python PID because a thread or interpreter teardown path is wedged. In that state systemd still reports the service as active, while Slack/other platforms are offline. `_launch_systemd_restart_shortcut()` currently waits forever in `while kill -0 <pid>`. Because the PID never disappears, the helper never reaches `systemctl restart`, and systemd has no failed/exited main process to recover. This turns a recoverable stuck shutdown into an indefinite messaging outage. The change keeps the graceful path intact and uses the existing configured drain budget. Force is a last resort only after that budget, and the fresh `MainPID` equality check preve",
      "date_published": "2026-08-05T08:29:38Z",
      "date_modified": "2026-08-13T17:56:45Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/gateway",
        "P2",
        "sweeper:risk-message-delivery"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:NousResearch/hermes-agent:pull_request:85365",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/hermes-agent/page/7/#signal-2c604df90d09",
      "external_url": "https://github.com/NousResearch/hermes-agent/pull/85365",
      "title": "[Hermes Agent] fix(gateway): propagate HERMES_BUNDLED_* into launchd/systemd units",
      "content_text": "## Problem On Homebrew/Nix installs the launchd-supervised gateway logs `No adapter available for <platform>` for every bundled messaging platform (telegram, discord, slack, …), even when the plugin is enabled, the SDK is installed, and the token is valid. The identical setup works when started from a shell. ## Root cause The `hermes` wrapper exports resource pointers — `HERMES_BUNDLED_PLUGINS`, `HERMES_BUNDLED_SKILLS`, `HERMES_BUNDLED_LOCALES`, `HERMES_OPTIONAL_SKILLS`, `HERMES_TUI_DIR` — so `get_bundled_plugins_dir()` resolves to the real manifest tree, which on packaged installs lives outside site-packages (e.g. `<prefix>/share/hermes-agent/plugins`). But `generate_launchd_plist()` writes only `PATH`, `VIRTUAL_ENV`, and `HERMES_HOME` into the plist's `EnvironmentVariables`. launchd starts the venv python directly, bypassing the wrapper, so inside the supervised gateway `get_bundled_plugins_dir()` falls back to the in-repo `plugins/` path, discovers **zero** bundled platform manifests, and `_create_adapter()` returns `None`. `generate_systemd_unit()` has the identical gap on the Linux side (Nix uses systemd user units with the same wrapper vars). ## Fix Bake the wrapper's `HERMES",
      "date_published": "2026-08-13T14:46:08Z",
      "date_modified": "2026-08-13T17:56:40Z",
      "tags": [
        "pull_request",
        "type/bug",
        "comp/cli",
        "comp/gateway",
        "P2",
        "sweeper:risk-message-delivery",
        "sweeper:risk-compatibility"
      ],
      "_contribution_compass": {
        "project": "NousResearch/hermes-agent",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "new",
        "importanceScore": 0
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114285",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/10/#signal-ef532f4bdf5c",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114285",
      "title": "[ClickHouse] Register Iceberg namespace in the catalog before writing table files (needed for SeaweedFS)",
      "content_text": "Files written first turn the namespace into a plain directory, which a catalog sharing the storage view (SeaweedFS) rejects with HTTP 500; the swallowed error left an orphaned metadata file that broke retries. Ensure the namespace before the first write; propagate failures except 404-then-create and 409 (REST) / AlreadyExists (Glue). Example: https://pastila.nl/?01f91a25/620869a81af815ba6927860efbc72af4#NhE2Nbzh3AHhUHhA5Fdkzw==GCM ### Changelog category (leave one): - Bug Fix (user-visible misbehavior in an official stable release) ### Changelog entry (a [user-readable short description](https://github.com/ClickHouse/ClickHouse/blob/master/docs/changelog_entry_guidelines.md) of the changes that goes into CHANGELOG.md): Register Iceberg namespace in the catalog before writing table files (needed for SeaweedFS)",
      "date_published": "2026-08-11T08:20:50Z",
      "date_modified": "2026-08-13T17:56:38Z",
      "tags": [
        "pull_request",
        "pr-bugfix"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [
          "alesapin"
        ],
        "change": "updated",
        "importanceScore": 2
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:112805",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/6/#signal-6a76d512c395",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/112805",
      "title": "[ClickHouse] Do not drop a named collection that a detached table still uses",
      "content_text": "Related: https://github.com/ClickHouse/ClickHouse/pull/96181 Related: https://github.com/ClickHouse/ClickHouse/issues/77366 Related: https://github.com/ClickHouse/ClickHouse/pull/110529 A table detached with a plain `DETACH TABLE` keeps its metadata file, so the server attaches it again on the next start. It is gone from `DatabaseCatalog` though, so `isTableExist` returns false for it, and the `check_named_collection_dependencies` check (added in #96181) treated its dependency as a stale leftover of a failed `CREATE TABLE`: it removed the dependency and let `DROP NAMED COLLECTION` succeed. The `ATTACH` replayed at startup then threw `NAMED_COLLECTION_DOESNT_EXIST`, which aborts loading the metadata, and the server did not start at all. This is how the `Stress test (arm_tsan)` job fails on master with `Cannot start clickhouse-server`: the AST fuzzer makes `04320_url_engine_dispatch_partition_and_format` leave its `URL(named_collection)` table detached (the test's `ATTACH TABLE` never reaches the server), and the test then drops the named collection. CI report: https://s3.amazonaws.com/clickhouse-test-reports/json.html?REF=master&sha=8aad759007771032aa94d7f4eee3e18103dd63c3&name_0=Ma",
      "date_published": "2026-07-31T19:56:49Z",
      "date_modified": "2026-08-13T17:56:31Z",
      "tags": [
        "pull_request",
        "pr-bugfix"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [
          "alexey-milovidov"
        ],
        "change": "updated",
        "importanceScore": 5
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:109891",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse.html#signal-f0a58197b8ce",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/109891",
      "title": "[ClickHouse] Reintroduce borrowed threadgroup async uaf fix",
      "content_text": "Reintroduce #108988 Related: https://github.com/ClickHouse/ClickHouse/pull/107030 Related: https://github.com/ClickHouse/ClickHouse/pull/108577 CI: https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=105890&sha=3dc0e76362eb18e27f1fffcd3f61ca9f13725fe8&name_0=PR&name_1=Stateless%20tests%20%28amd_tsan%2C%20s3%20storage%2C%20sequential%2C%201%2F2%29 Fixes a use-after-free risk in asynchronous work scheduled while a borrowed `ThreadGroup` is current. Borrowed `ThreadGroup` objects used by materialized view and async insert flush paths point their `performance_counters` and `memory_tracker` to the parent query group, so they are valid only while that parent group is alive. Async callbacks could capture such a borrowed group and later attach it on a pool thread after the parent query group had finished. Instead of keeping the parent `ThreadGroup` alive with a `shared_ptr`, this change keeps borrowed accounting scoped. Borrowed groups are marked explicitly, async callback capture drops borrowed groups, and thread pool callback runners capture the normalized group at task enqueue time rather than when a potentially long-lived runner object is created. This preserves synchronous b",
      "date_published": "2026-07-09T12:34:20Z",
      "date_modified": "2026-08-13T17:56:28Z",
      "tags": [
        "pull_request",
        "pr-bugfix",
        "can be tested",
        "comp-query-execution"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "open",
        "assignees": [
          "azat",
          "alexey-milovidov"
        ],
        "change": "updated",
        "importanceScore": 22
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:111794",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/8/#signal-053a00217bd5",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/111794",
      "title": "[ClickHouse] Add unordered stream modifier",
      "content_text": "### Changelog category (leave one): - Improvement ### Changelog entry (a [user-readable short description](https://github.com/ClickHouse/ClickHouse/blob/master/docs/changelog_entry_guidelines.md) of the changes that goes into CHANGELOG.md): Add STREAM UNORDERED modifier: skip the per-snapshot commit-order sort depends on https://github.com/ClickHouse/ClickHouse/pull/110653 (not for functional reason, only test) cc @alesapin @Michicosun",
      "date_published": "2026-07-24T13:31:48Z",
      "date_modified": "2026-08-13T17:56:27Z",
      "tags": [
        "pull_request",
        "pr-improvement",
        "pr-synced-to-cloud"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "closed",
        "assignees": [
          "Michicosun"
        ],
        "change": "updated",
        "importanceScore": 3
      }
    },
    {
      "id": "2026-08-13:github:ClickHouse/ClickHouse:pull_request:114661",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/data-infrastructure/clickhouse/page/9/#signal-5fd02c689f50",
      "external_url": "https://github.com/ClickHouse/ClickHouse/pull/114661",
      "title": "[ClickHouse] Revert \"Document that PREWHERE filters one join input before the JOIN\"",
      "content_text": "Reverts ClickHouse/ClickHouse#114484 - it is too low-quality, sorry. CC @PedroTadim @dhtclk <!-- ch-version-info:start --> ### Version info - Merged into: `26.8.1.1350` (included in `26.8` and later) <!-- ch-version-info:end -->",
      "date_published": "2026-08-13T15:53:35Z",
      "date_modified": "2026-08-13T17:56:23Z",
      "tags": [
        "pull_request",
        "pr-not-for-changelog",
        "pr-synced-to-cloud"
      ],
      "_contribution_compass": {
        "project": "ClickHouse/ClickHouse",
        "group": "data-infrastructure",
        "state": "closed",
        "assignees": [],
        "change": "updated",
        "importanceScore": 3
      }
    },
    {
      "id": "2026-08-13:github:BerriAI/litellm:pull_request:36792",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/litellm/page/3/#signal-a7a15cd140a1",
      "external_url": "https://github.com/BerriAI/litellm/pull/36792",
      "title": "[LiteLLM] feat(gemini): day-0 pricing for gemini-3.7-flash",
      "content_text": "## TLDR Problem this solves: - Gemini 3.7 Flash launched today with no cost map entry - Requests route fine but spend tracking silently records nothing How it solves it: - Adds `gemini/`, `vertex_ai/`, and bare cost map entries - Launch pricing: $0.75 input / $3.75 output per 1M tokens - Cache, batch, flex, and priority tiers scaled at the same 50% discount - Regression tests lock the launch prices in ## User Flow Before: a team adds Gemini 3.7 Flash to their gateway on launch day and every request comes back unpriced, so spend tracking and budgets silently miss it 1. The proxy admin adds a `gemini/gemini-3.7-flash` deployment to the model list and starts the proxy 2. A developer sends POST https://litellm-domain/v1/chat/completions with `\"model\": \"gemini-3.7-flash\"` and a user message 3. They get a 200 with the model's reply, but the response carries no `x-litellm-response-cost` header at all 4. https://litellm-domain/ui/?page=logs shows the request at $0 spend, and key and team budgets never count it After: the same request is priced at the launch rate and spend shows up everywhere 1. The proxy admin adds a `gemini/gemini-3.7-flash` deployment to the model list and starts the pro",
      "date_published": "2026-08-13T17:03:03Z",
      "date_modified": "2026-08-13T17:56:23Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "BerriAI/litellm",
        "group": "ai-infrastructure",
        "state": "closed",
        "assignees": [],
        "change": "updated",
        "importanceScore": 6
      }
    },
    {
      "id": "2026-08-13:github:sgl-project/sglang:pull_request:34753",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/sglang/page/6/#signal-1961285f686d",
      "external_url": "https://github.com/sgl-project/sglang/pull/34753",
      "title": "[SGLang] feat(cli): add extensible serve backend plugins",
      "content_text": "## Motivation SGLang now uses `sglang serve` as the common entry point for both autoregressive and diffusion runtimes. Ecosystem projects also build on SGLang, but publishing a second console script named `sglang` would make installation and uninstallation order decide which executable survives. This PR makes `sglang serve` an extensible frontend while keeping one clear owner for the executable: the SGLang distribution. Out-of-tree projects register serving backends through Python package metadata instead of replacing the command. The immediate downstream use case is SGLang-Omni: ```bash sglang serve MiniMaxAI/MiniMax-Music3 --model-type omni ``` The core API is intentionally generic and does not contain an Omni-specific import or backend name. ## Design and plan ### Phase 1: land the generic core contract (this PR) - Add the `sglang.serve_backends` entry point group ### Phase 2: integrate SGLang-Omni in its repository (follow-up PR) - Register `omni = \"sglang_omni.cli.sglang_backend:create_backend\"` under `sglang.serve_backends`. - Add a thin adapter that forwards `ServeRequest.argv` to the existing Omni Typer parser and launcher. ### Phase 3: enable safe auto detection per ecosys",
      "date_published": "2026-08-13T16:32:07Z",
      "date_modified": "2026-08-13T17:56:15Z",
      "tags": [
        "pull_request",
        "documentation",
        "run-ci"
      ],
      "_contribution_compass": {
        "project": "sgl-project/sglang",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 2
      }
    },
    {
      "id": "2026-08-13:github:anomalyco/opencode:issue:42382",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/coding-agent-infrastructure/opencode/page/7/#signal-c75b76e01552",
      "external_url": "https://github.com/anomalyco/opencode/issues/42382",
      "title": "[OpenCode] slowless",
      "content_text": "mimo v2.5 free is so slow its making a readme on 10 hours.",
      "date_published": "2026-08-13T17:53:50Z",
      "date_modified": "2026-08-13T17:56:09Z",
      "tags": [
        "issue",
        "needs:compliance"
      ],
      "_contribution_compass": {
        "project": "anomalyco/opencode",
        "group": "coding-agent-infrastructure",
        "state": "open",
        "assignees": [
          "fwang"
        ],
        "change": "new",
        "importanceScore": 4
      }
    },
    {
      "id": "2026-08-13:github:BerriAI/litellm:pull_request:36763",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/ai-infrastructure/litellm/page/3/#signal-19f21a980386",
      "external_url": "https://github.com/BerriAI/litellm/pull/36763",
      "title": "[LiteLLM] refactor: replace Any with precise types across responses, proxy, and llms modules",
      "content_text": "## TLDR Problem this solves: - basedpyright reportAny / reportExplicitAny counts sit far above zero - silent `Any` values skip type checking and hide real bugs How it solves it: - replaces `Any` with precise types across 28 hotspot files - Protocols, TypedDicts, and Pydantic validation replace untyped access - cuts reportAny by 967 and reportExplicitAny by 261 - 1406 basedpyright errors removed in total across 48 rules - ratchets basedpyright, ruff-strict, and LIT budgets down to match ## User Flow Before: every request already succeeds, since this refactor only tightens internal types 1. A developer sends POST https://litellm-domain/v1/responses with `\"model\": \"gpt-4.1\"` and an `\"input\"` string and gets a 200 with an OpenAI-shaped response id like `resp_abc123` 2. The proxy admin sends POST https://litellm-domain/v1/mcp/server with a server alias and URL and gets a 201 with the stored server config echoed back 3. The admin sends POST https://litellm-domain/prompt/new with a prompt id and dotprompt params and gets a 200 with the versioned prompt id `my_prompt.v1` After: the same requests return byte-identical responses, nothing observable changes 1. The developer sends the same POS",
      "date_published": "2026-08-13T11:02:40Z",
      "date_modified": "2026-08-13T17:55:56Z",
      "tags": [
        "pull_request"
      ],
      "_contribution_compass": {
        "project": "BerriAI/litellm",
        "group": "ai-infrastructure",
        "state": "open",
        "assignees": [],
        "change": "updated",
        "importanceScore": 6
      }
    },
    {
      "id": "2026-08-13:github:cilium/cilium:pull_request:47932",
      "url": "https://amk9978.github.io/contribution-compass/updates/2026-08-13/platform-infrastructure/cilium/page/2/#signal-e92f09bcae6d",
      "external_url": "https://github.com/cilium/cilium/pull/47932",
      "title": "[Cilium] clustermesh/endpointslices: explicitly limit maximum decoder memory",
      "content_text": "Explicitly configure a limit for the zstd decoder used to decode the ClusterEndpointSlice entries received over Cluster Mesh, to prevent the risk of unbounded memory usage in case of crafted payloads. I've marked the PR as `release-note/misc` because the logic ingesting ClusterEndpointSlices is incomplete and disabled behind a feature flag in v1.20. Reported-by: Secstant - Sigma Prime \\<secstant@sigmaprime.io>",
      "date_published": "2026-08-13T08:30:58Z",
      "date_modified": "2026-08-13T17:55:53Z",
      "tags": [
        "pull_request",
        "ready-to-merge",
        "area/clustermesh",
        "release-note/misc",
        "needs-backport/1.20"
      ],
      "_contribution_compass": {
        "project": "cilium/cilium",
        "group": "platform-infrastructure",
        "state": "closed",
        "assignees": [],
        "change": "updated",
        "importanceScore": 7
      }
    }
  ]
}
