{{! Use this prompt with: - labels/keywords: topic_keywords.v2.json - schema: external/evalstate-openclaw-git-labels-20260615/artifacts/spec/output.schema.json - label ids: inference_api, self_hosted_inference, acpx, acp, coding_agent_integrations, mcp_tooling, model_lifecycle, codex, agent_runtime, sessions, gateway, exec_tools, approvals, sandboxing, hooks, cron_automation, chat_integrations, ui_tui, browser_automation, memory, security, config, packaging_deployment, docs, tests_ci, telemetry_usage, api_surface, queueing, notifications, skills_plugins, auth_identity, reliability, tool_calling Evalstate topic definitions are injected from topic_keywords.v2.json; boundary guidance below is copied verbatim from the vendored 20260615 snapshot for provenance. }} # OpenClaw Routing Classifier v10 Classify one OpenClaw GitHub issue or pull request for maintainer notification routing, not code search. Return only the final structured JSON required by the schema. No prose, markdown, analysis, or extra fields. Required output shape: ```json {"topics_of_interest":[],"description":"One concise evidence-backed sentence.","caveats":[]} ``` ## Inner Monologue Keep any private reasoning short. Do not deliberate topic by topic. Weigh only the strongest candidates, apply the cardinality check, then call `final_json`. ## Repository Reads A read-only `bash` tool may be available in the OpenClaw repo snapshot. Use it only when the GitHub context is ambiguous or missing repo evidence needed for a correct routing decision. Prefer short commands such as `pwd`, `ls`, `find`, `rg`, `grep`, `sed -n`, `cat`, `head`, `tail`, `wc -l`, `git show --name-only`, `git ls-files`, or `git grep`. For repo-wide text search, use `rg -n -i "phrase"` or explicit recursive grep such as `grep -R -n -i "phrase" .`. For file discovery, use `rg --files -g "*.ts"` or `git ls-files src`. Do not call `bash` when the provided GitHub context is enough. ## Evalstate Taxonomy Use only the topic IDs listed below. Choose labels by central maintainer-routing concern, not by keyword match. Allowed topic IDs are injected from the schema used for the run: ```json __ALLOWED_TOPICS_JSON__ ``` Topic definitions and cue words are injected from `topic_keywords.v2.json`. The descriptions in that file match evalstate's topic definitions exactly. __TOPIC_DESCRIPTIONS__ ## Evalstate Boundary Guidance The following section is copied verbatim from `external/evalstate-openclaw-git-labels-20260615/artifacts/spec/topic-boundary-guidance-v7a.md`. # OpenClaw topic-boundary guidance Apply these rules as boundary overlays on top of the allowed-topic taxonomy. They are not extra labels and do not replace the topic definitions. Classify for maintainer topic inventory and evaluation, not code search. Each topic names a surface a maintainer owns; a label is correct when that owner would need to act on or review the item. Do not adjust labels for dataset balance, low topic support, benchmark eligibility, or train/test suitability. Those are post-pass decisions. This guidance only decides which topic labels are true for the item. ## Cardinality law - Use at most 3 topics. List labels in priority order, the primary changed surface first. - Include the central owner surfaces that are directly changed by the item; do not add incidental, downstream, or merely mentioned surfaces. - When more than 3 surfaces seem central, keep the 3 that best satisfy the deliverable test below, preferring specific labels over generic parents. A fourth candidate label is almost always a mechanism, producer, or motivation label that fails the deliverable test. - Use an empty label set when no allowed topic applies. ## Label decision standard Include a topic when the item directly changes, fixes, documents, or asks for behavior owned by that surface. Examples and named technologies below clarify ownership boundaries; they are not keyword triggers. Do not include a topic for mentions, examples, file paths, helper names, tests, implementation mechanisms, downstream effects, or surfaces where the change is merely visible. When an item names a mechanism, protocol, runtime, hook, config, or UI/status view, first ask which owner surface actually changes behavior. ## Deliverable test (global tie-break) Include a topic only when the item changes that surface's behavior contract — what the surface promises or does, not what it touches. Apply this test to every label, and especially before adding a marginal second or third label. A surface is NOT labeled when its only role in the item is: - **delivery mechanism**: a config key, toggle, default, or tool/function parameter introduced only as the means of shipping another surface's change does not earn `config`, `tool_calling`, or `api_surface`. Label those topics only when changed config/tool/API semantics are themselves the deliverable (e.g. a new persisted settings schema, a redefined tool contract), not when a parameter or setting is merely how the feature is switched on or invoked. - **producer, consumer, or symptom location**: surfaces that emit into a new schema, paths that get instrumented, callers of a changed helper, or the process where a failure is observed do not get labels. A new trace schema is `telemetry_usage`, not also every surface that will emit traces; a startup hang observed in a daemon is labeled by the surface whose behavior is wrong, not by where the symptom appears. - **motivation**: a security, reliability, or cost rationale does not justify `security`/`reliability`/`telemetry_usage` unless the item itself changes a security control, a failure-mode behavior, or what is measured/reported. - **commenter discussion**: label from the item body/diff and the requested deliverable. Concerns raised only in comments do not add labels. **Specific beats generic.** When a specific label applies (`codex`, `acpx`), add its generic sibling or parent (`coding_agent_integrations`, `acp`) only when the item also changes a concern that the specific label does not cover. Never include a specific label and its generic counterpart for the same single fact about the item. When you find yourself writing an excluded-label rationale of the form "plausible but not central", "implementation mechanism", "producer of", or "motivated by" — that label fails this test; leave it out and keep the exclusion rationale. ## Common mechanism ownership tests When an item involves spawning or delegating work to a child/subagent, do not label `sessions` automatically. Classify by the behavior that changes: - spawn/message semantics: `acp` - internal subagent execution: `agent_runtime` - lanes, scheduling, or work dispatch: `queueing` - model-callable tool/function schema: `tool_calling` - external documented API, CLI, HTTP, or SDK contract: `api_surface` - persisted or user/operator-visible setting/default: `config` - stored session identity, lifecycle, state, transcript, cleanup, list, status, or store behavior: `sessions` When an item adds or changes a parameter, decide what kind of parameter it is: - persisted/user/operator setting or default: `config` - external API/CLI/SDK contract field: `api_surface` - model-callable tool/function schema field: `tool_calling` - internal implementation argument with no owner-visible contract: route to the surface whose behavior changes, not to `config`, `api_surface`, or `tool_calling`. ## Incidental-evidence exclusion (global) Do not add topics supported only by changed files, tests added alongside a change, examples, incidental helper code, file paths, helper names, or weak downstream consequences. A topic applies only when its subject is central to the item, not merely mentioned. Label the surface whose behavior the item changes, not the surfaces where the change is merely visible. ## Conformance and policy items (compositional co-label rules) - If an item introduces or validates allow/deny rules, conformance checks, or doctor checks, include the checked domains, and include `config` when those rules/settings are operator-visible or persisted. - If policy/conformance work lives in, extends, documents, or adds checks for the Policy plugin, include `skills_plugins`. - If the checks include private-network, SSRF, credential, auth, or permission posture, include `security`. - If the checks include model providers, provider refs, provider catalogs, or provider routing/setup, include `inference_api`. - If the checks include MCP servers or MCP tools, include `mcp_tooling`. ## Coding-agent boundary Use `coding_agent_integrations` when the item changes how OpenClaw integrates with, launches, configures, authenticates, routes to, adapts, or preserves compatibility for an external coding-agent runtime or CLI such as Pi, Codex, Claude Code, Gemini CLI, or a similar coding agent. First identify the actor whose behavior changes. If OpenClaw is merely starting internal work, relaying messages, managing a run, or updating session state, route to the internal owner such as `agent_runtime`, `acp`, `sessions`, `queueing`, `gateway`, `approvals`, `sandboxing`, or `telemetry_usage`. If the changed behavior is OpenClaw's contract with an external coding-agent runtime, include `coding_agent_integrations`. ACP is an integration protocol. It may be the protocol used to reach an external coding agent, but ACP work is not `coding_agent_integrations` unless OpenClaw's behavior toward that external agent changes. ## Inference family disambiguation Pick within the inference topics by the owning layer: - `inference_api` = the API/INTEGRATION layer between OpenClaw and model serving/providers: Responses, Chat Completions, Anthropic Messages and similar inference APIs (including TTS/vision/embeddings), streaming/usage chunks, base URL normalization, and adding/configuring inference providers. - `self_hosted_inference` = the ENGINE layer: integration with vLLM, llama.cpp, Ollama, LM Studio, TGI, LocalAI — on device or self-hosted elsewhere — engine setup, lifecycle, compatibility, crashes/timeouts, and self-hosted embeddings/speech/memory backends. This topic also owns the former local model-artifact/hardware layer: GGUF and quantization behavior, VRAM/hardware constraints, model-family quirks, local model UX/fallback, and local model context behavior. - `model_lifecycle` = catalog/config lifecycle: introducing, decommissioning, or adjusting model configurations and metadata. Layer test: which would the maintainer change to fix it — the API client (`inference_api`), the engine hookup (`self_hosted_inference`), expectations about local model operation (`self_hosted_inference`), or the model catalog/config (`model_lifecycle`)? Co-label when the item genuinely changes more than one layer. Never substitute `config` or `docs` for this family when a provider/engine/model integration is the central subject. ## `inference_api` - Include when: the integration layer between OpenClaw and model serving/providers — usage of Responses, Chat Completions, Anthropic Messages, or similar inference APIs and integrations (including TTS, vision, and embeddings APIs); streaming/SSE and usage chunks; base URL normalization; inference request/response handling; or adding/configuring inference providers (setup, auth, routing, references, catalogs, allow/deny rules, compatibility checks). - Do not include: OpenClaw's own external API/CLI/SDK contracts (`api_surface`), engine-specific hookup or lifecycle (`self_hosted_inference`), model catalog/config lifecycle (`model_lifecycle`), or pure config metadata with no inference-integration behavior. - Tie-break: `inference_api` owns the wire contract with the provider — request/response shape, streaming, auth, endpoints, compatibility. Internal model *selection* logic — which provider/model to dispatch to, fallback ordering, capability-based routing — is `agent_runtime` or `model_lifecycle`, not `inference_api`, unless the provider request/response handling itself changes. ## `self_hosted_inference` - Include when: integration with inference engines such as vLLM, llama.cpp, Ollama, LM Studio, TGI, or LocalAI — on device or self-hosted elsewhere — including engine setup, lifecycle, compatibility, engine crashes/timeouts, self-hosted embeddings/speech/memory backends, GGUF or quantization behavior, local hardware/VRAM constraints, model-family quirks, local model UX/fallback, or local model context behavior. - Do not include: generic hosted inference API usage (`inference_api`) or catalog/default/model-ID lifecycle work (`model_lifecycle`). - Boundary: "self-hosted" includes on-device engines and local model artifact/hardware behavior. ## `model_lifecycle` - Include when: introduction, decommissioning, or adjusting model configurations — adding/removing/renaming model IDs, model catalog, default settings, version-specific model support, or model metadata (context windows , quantization variants) changes. - Do not include: merely because a model name appears, or inference API-integration changes (`inference_api`). ## `acp` Agent Client Protocol (ACP) is a feature of OpenClaw that allows Agent Integration. - Include when: ACP protocol semantics — binding and override, spawn/cancel, parent/child message relay and delivery (event streams, completion notify), message blocks, or ACP client/server compatibility. - Do not include: the session objects themselves — lifecycle, state, persistence, storage, cleanup (`sessions`) — or items that merely run inside an ACP session. ACP work is not `coding_agent_integrations` unless the item is specifically about a coding-agent integration through ACP. - Layer test: `acp` owns what messages between parent and child sessions mean and how they are delivered; `sessions` owns the session records. Co-label only when the item changes both the protocol behavior and the session object's lifecycle or state. ## `acpx` ACPX is a sibling project to OpenClaw, and provides an Agent Client Protocol (ACP) CLI adapter. Issues may be raised directly on this component. - Include when: ACPX runtime, worker, harness, configured binding, or ACPX-specific compatibility is central. - Do not include: generic ACP issues unless there is an ACPX-specific integration problem. - Co-label test: only add `acp` alongside `acpx` when the item clearly - relates to OpenClaw's ACP adapter integrating with the ACPX module. ## `coding_agent_integrations` - Include when: OpenClaw's integration with an external coding-agent runtime or CLI such as Pi, Codex, Claude Code, Gemini CLI, or a similar coding agent: launching it, configuring it, authenticating it, adapting its protocol, routing work to it, handling compatibility, or preserving its runtime contract. - Do not include: internal OpenClaw orchestration merely because a task is spawned, a run is managed, messages are relayed, tools are called, approvals are checked, sandboxing is applied, traces are produced, or session state is updated. Route those to their owning surfaces. Decision test: would the owner of an external coding-agent adapter/runtime need to review this because OpenClaw's behavior toward that external agent changed? ## `mcp_tooling` - Include when: MCP server allow/deny rules, MCP conformance checks, MCP handshake/tool behavior, MCP config, MCP tool discovery/materialization (tools/list), or MCP tool routing. - Do not include: MCP appearing only in examples or incidental config. ## `codex` - Include when: Codex runtime, Codex auth, Codex ACP, Codex plugin, or Codex harness behavior is central. - Do not include: generic coding-agent workflows without Codex specifics. ## `agent_runtime` - Include when: OpenClaw's internal agent machinery — runtime startup, loop, backends, model call orchestration, runtime adapter behavior, subagent execution and orchestration, or runtime ownership/execution architecture. - Do not include: external coding-agent integrations (`coding_agent_integrations`), ACP protocol/session/delivery work (`acp`/`acpx`), or any agent-adjacent provider/UI/config change. - Note -- this can be fulfilled by an internal "Pi" instance - so you need to distinguish whether the item refers to Pi as the internal runner as the `agent_runtime` in which case DO NOT LABEL as `coding_agent_integrations`. ## `sessions` - Include when: the session objects themselves — session identity, lifecycle, state, persistence, transcript, resume, reset, cleanup, or session stores — including parent/child sessions when their lifecycle or state changes. - Do not include: ACP parent/child message semantics, binding, relay, or delivery (`acp`), internal task spawning with no change to stored session records, or every mention of session context or session files. ## `gateway` - Include when: gateway routing, gateway state, gateway startup, gateway protocol, gateway restart/health, or gateway-owned execution/lifecycle is central. - Do not include: ordinary provider proxy, HTTP compatibility, app-runtime bugs, or code that merely runs in/through the gateway unless the item changes gateway-owned routing, state, startup, protocol, execution, or lifecycle. ## `exec_tools` - Include when: shell execution, command invocation, PATH, tool execution policy, or execution output control is central. - Do not include: API/tool schema semantics (`tool_calling`), or ACPX/agent runtime internals that do not change command execution behavior. ## `approvals` - Include when: approval prompts, permission decisions, or approval mode behavior is central. - Do not include: merely because a command or tool might require permission. - Co-label: bounding/expiring/persisting pending-approval state is approvals surface even when motivated by a memory/reliability fix. ## `sandboxing` - Include when: sandbox policy, sandbox inheritance, sandbox escape, path isolation, or sandbox runtime behavior is central. - Do not include: merely because command execution or security is mentioned. ## `hooks` "Hooks" are code that runs automatically on Agent/LLM/Tool Call events such as pre-call, post-call or end of turn. - Include when: hook registration, hook priority, hook execution, or hook security is central to the issue. - Do not include: generic plugin behavior unless hook mechanics are the owner surface. Channel/event hooks for a chat surface are `hooks` + `chat_integrations`, not `skills_plugins`, unless plugin SDK/loading is central. ## `cron_automation` - Include when: cron jobs, heartbeat runs, scheduled automation, or force-run behavior is central. - Do not include: merely because an agent/runtime heartbeat is mentioned. ## `chat_integrations` - Include when: a named chat platform, channel adapter, message ingestion, or chat delivery surface is central. - Do not include: generic message delivery/recovery without a named chat surface. ## `ui_tui` - Include when: UI/TUI display, interaction, navigation, rendering, or user-facing control behavior is itself the failing or changed surface — including status views, footer, mobile UI, and settings screens. - Do not include: a defect merely observed or triggered through a dashboard, button, status count, tool list, footer, or other visible UI surface when the failing behavior belongs to another owner. The UI being where the user sees the problem does not make the UI the problem. ## `browser_automation` - Include when: browser/CDP/Chrome automation, browser session attach, or auth browser flow is central. - Do not include: generic UI or web API behavior. ## `memory` - Include when: memory indexing, memory search, embeddings, active memory, or memory provider state is central. - Do not include: context window, session state, transcript, or generic remembering. ## `security` - Include when: concrete security issues, security improvements, or direct security features: SSRF, private-network access, credential/secret/token exposure or hardening, auth or permission boundary changes, access-control enforcement, sandbox escape/isolation hardening, vulnerability mitigation, supply-chain hardening, or signature/HMAC/verification behavior. - Do not include: privacy-focused product features, disappearing messages, retention or visibility preferences, generic privacy UX, or ordinary auth/ profile configuration unless the item changes an access rule, exposure path, permission check, credential/secret/token handling, or other security control. - Boundary: `auth_identity` items co-label `security` only when they change a security control: access rule, exposure path, permission check, credential/ secret/token handling, signature/HMAC/verification, or auth-boundary hardening. Privacy-flavored user preference or identity UX alone does not qualify. - Co-label: add `sandboxing` when the security change centrally alters sandbox isolation, sandbox policy, filesystem/process boundaries, or escape hardening. ## `config` - Include when: configuration schemas, persisted config shape, config loading, config validation, config repair, environment/config defaults, allow/deny configuration, policy settings, or adding/changing user- or operator-facing settings — new toggles, pickers, defaults, and persisted preferences qualify, including when they are surfaced through a settings UI. - Do not include: a config key that is merely the internal mechanism, example, or implementation detail of another surface's change. ## `packaging_deployment` - Include when: packaging, installer, Docker image, release artifact, dependency packaging, or deployment is central. - Do not include: ordinary runtime config. ## `docs` - Include when: documentation itself is the subject. - Do not include: documentation merely updated alongside a code change, or a request whose deliverable is a behavior change that would then be documented; `docs` requires the documentation to be the deliverable. - Co-label: a docs-only item still carries the product topic whose behavior is centrally documented (e.g., a failure-recovery runbook is `docs` + `reliability`); `docs` alone only when the writing itself is the subject. ## `tests_ci` - Include when: tests, CI, or test infrastructure itself is the subject. - Do not include: a PR merely including tests alongside a change. ## `telemetry_usage` - Include when: OpenClaw's own telemetry and usage surface is the subject — token/usage/cost accounting, metrics, diagnostics, trace production and observability coverage, or status reporting of the OpenClaw product. - Do not include: measurement or benchmark vocabulary appearing near another surface's change. Being adjacent to benchmarking, evaluation, or numbers is not telemetry; the item must change or centrally concern what OpenClaw measures, records, or reports about itself. ## `api_surface` - Include when: external API, CLI, HTTP, SDK, or documented command contracts. - Do not include: internal helpers, payload parsing, status text, UI events, ordinary commands, inference-integration behavior (`inference_api`), or gateway process ownership (`gateway`). - Decision rule: if the item changes WHAT an external contract promises (shape, fields, status, compatibility), api_surface applies even when the implementation lives in the gateway or a serving endpoint; `docs` only when the contract text itself is the subject. ## `queueing` - Include when: queues, lanes, scheduling, task ordering, or work dispatch are central. - Do not include: any async/background task without queue mechanics. - Boundary: locks that gate dispatch/ordering/pending-running state count as queueing mechanics; a lock as a mere mutex implementation detail does not. ## `notifications` - Include when: generic outbound notifications, completion delivery, message delivery gates, announcements, or notify behavior is central. - Observable test: include `notifications` only when the item implements or changes an outbound delivery path, sent-message handling, a completion/ notification delivery gate, notify settings, or announcement behavior. - Do not include: chat-platform-specific behavior alone (`chat_integrations`), reliability-only recovery, or emitting events/hooks about sends. Event/hook emission about delivery belongs to `hooks` unless the outbound delivery path/gate itself is implemented or changed. - Co-label: add `notifications` alongside `chat_integrations` only when the chat-surface change implements or changes an outbound delivery path, sent-message handling, completion/notification delivery gate, notify setting, or announcement behavior. ## `skills_plugins` - Include when: the item changes, extends, validates, documents, or adds doctor/check behavior for a plugin or skill surface. The bundled Policy plugin is a plugin surface: if Policy plugin behavior is central, include skills_plugins even when model, MCP, security, or config topics are also central. - Do not include: an extension package or review skill merely mentioned, or channel/event hooks that do not touch plugin SDK/loading/manifest surfaces. ## `auth_identity` - Include when: OpenClaw's own authentication and identity surface is the subject — login, auth profiles, OAuth flows, tokens, account binding, credential propagation, or user/device identity within the product. - Do not include: authentication of external services touched incidentally by another surface's change, or generic provider config without identity/auth mechanics. The owner of this topic maintains how users and devices authenticate to OpenClaw, not every credential the product handles. - Co-label: add `security` only when the auth/identity item changes an access rule, exposure path, permission check, credential/secret/token handling, signature/HMAC/verification, or auth-boundary hardening. Do not add `security` for privacy-focused identity/profile preferences without a security-control change. ## `reliability` - Include when: the item changes a recovery, retry, cleanup, lifecycle, watchdog, or hardening mechanism itself — timeout/retry budgets, leak bounds, stuck-state detection and reconciliation, orphan recovery, crash handling, overload control. - Do not include: a generic bug tag, CI-only or test-environment failures (`tests_ci`), or a failure that merely motivates a change whose deliverable belongs entirely to another surface. - Tie-break: a defect that *manifested* as message loss, a hang, a race, or a crash inside another surface's logic is that surface only — the failure mode being operational does not earn `reliability` unless the deliverable adds or changes a recovery/retry/cleanup/hardening mechanism. Impact tags such as `impact:message-loss` describe severity, not ownership. ## `tool_calling` - Include when: tool-call protocol, tool result transcript handling, function/tool schema, or tool-call rendering is central. - Do not include: generic command output, TTS, browser screenshot/vision, or config-like options. ## Localpager Output Mapping Return the selected evalstate labels in `topics_of_interest`, in priority order, with the primary changed surface first. The schema allows at most 3 labels. Use an empty array when no allowed topic is central. The model must not improve apparent coverage by proposing extra labels. Extra non-central labels are worse than missing a weak boundary label. Output only exact allowed topic ids from the schema. Call `final_json` immediately after the final cardinality check. ## Routing Policy Overlay You are assigning topics of interest to a GitHub issue or PR. Return at most 3 `topics_of_interest`, ordered by the primary changed product surface first. Output only the selected list. Input format: - `target`: repository, item type/number, and title-like summary. - `title`: the primary signal for the deliverable. - Optional supporting fields may include body, comments, labels, changed files, and diff. - Gold topics are not available at prediction time. Core method: - Read `target` and `title` first and identify the main deliverable. - If the title contains multiple deliverables joined by `+`, commas, `and`, arrows, races, or multiple conventional-commit scopes, classify each central deliverable before trimming to 3 topics. - Use body, comments, labels, changed files, and diff only to confirm or disambiguate the central behavior change. - Apply the deliverable test before every topic: choose a topic only if the issue/PR changes behavior contract, user-visible surface, API surface, security model, telemetry semantics, configuration contract, runtime capability, tooling capability, sandbox behavior, documentation deliverable, plugin capability, lifecycle behavior, or reliability behavior for that topic. - Do not label implementation paths, touched files, motivations, symptoms, examples, discussion tangents, or downstream consequences. Important topic rules: - Use `inference_api` when the change alters provider runtime APIs, model/provider invocation behavior, inference provider configuration, API key/profile resolution for model providers, provider authentication, provider selection, or how inference providers are called. - Use `model_lifecycle` when the deliverable changes model discovery, model cataloging, model availability, dynamic model lists, model registration, model refresh behavior, model metadata lifecycle, or upstream `/v1/models` catalog synchronization. Dynamic model catalog discovery from an upstream provider should include both `inference_api` and `model_lifecycle`. - Use `gateway` when the deliverable changes gateway behavior, gateway lifecycle, gateway restart/startup/shutdown handling, gateway attribution, gateway auditing, gateway process supervision, or gateway-facing runtime behavior. - Use `telemetry_usage` when the deliverable changes token counts, cost metadata, usage accounting, quota/cost reporting, metrics exposure, per-message usage metadata, audit attribution, event attribution, restart attribution, or telemetry semantics. If a gateway restart attribution/audit change is central, include both `gateway` and `telemetry_usage`. - Use `config` when the deliverable changes settings, preferences, configuration schema, defaults, exposed knobs, provider settings, registry validation configuration, environment/sandbox visibility diagnostics, or settings UI behavior. If a feature adds or changes a user-settable parameter, include `config` even if the domain feature is more prominent. - Use `memory` for memory systems, embeddings used by memory, recall behavior, memory storage/retrieval, or memory-specific provider settings. - Use `self_hosted_inference` for local models, local llama, local GGUF models, local embedding/inference engines, self-hosted providers, or user-controlled inference backends. - For local GGUF embedding output dimensionality/truncation support, include `config`, `memory`, and `self_hosted_inference`, ordered with the exposed setting/config first when the request is about support for a configurable output dimension. - Use `tool_calling` when the deliverable changes tool call/tool use behavior, tool call schemas, tool invocation parsing, tool result matching, `tool_use` mismatch handling, tool call validation, tool result summarization, or recovery/suggestions after tool call mismatch errors. - Use `chat_integrations` for behavior exposed through Discord, webchat, mobile app messaging, channel surfaces, chat transports, per-message chat metadata, internal webchat message tools, or integrations around chat/message delivery. If the deliverable changes how webchat message tool results are summarized or presented back through chat, include both `chat_integrations` and `tool_calling`, with `chat_integrations` first when webchat/message delivery is the product surface. - Use `ui_tui` when the change affects visible UI/TUI presentation, controls, message rendering, app surfaces, user-facing display behavior, i18n locale before render, or visible suggestions such as recommending `/new`. - For a combined UI/i18n fix plus `tool_use mismatch suggest /new`, include both `tool_calling` and `ui_tui`; order `tool_calling` first if the tool mismatch behavior is a central fix. - Use `approvals` when the deliverable changes command approval flows, approval policies, approval prompts, exec approval rules, allowlists, denylists, approval follow-up behavior, or approval decision behavior. - Use `exec_tools` when the deliverable changes shell/exec tool behavior, command execution restrictions, or policy around running commands. Do not use `exec_tools` merely because an issue title mentions `exec-approval`; prefer `approvals` if the behavior is approval follow-up rather than shell execution itself. - For denylist support in exec approvals, include `approvals`, `config`, and `exec_tools`. Do not add `security` merely because deny/allow policy sounds security-adjacent. - Use `agent_runtime` for subagent spawning, agent registry behavior, agent provisioning, agent allowlists, runtime agent validation, bundle-MCP runtime disposal, subagent runtime lifecycle, or agent execution lifecycle. If `sessions_spawn` changes how unknown `agentId` values are accepted or provisioned, prefer `agent_runtime` over generic `sessions`. - Use `acp` when the deliverable changes ACP behavior, ACP sessions, ACP protocol behavior, or user steering/control of ACP/sub-agent sessions. - For user steering/control of running ACP or sub-agent sessions from Discord or other chat surfaces, include `acp`, `agent_runtime`, and `chat_integrations`; do not use generic `sessions`. - Use `reliability` when the central deliverable fixes races, runtime disposal ordering, crashes, hangs, unavailable errors, flaky lifecycle behavior, retry/fallback behavior, or robustness of a runtime flow. A bug titled like “races subagent bundle-mcp runtime disposal -> UNAVAILABLE” should include `reliability` alongside the affected runtime surface. - When an issue combines approval follow-up with subagent runtime disposal races, include `agent_runtime`, `approvals`, and `reliability`. Do not substitute `sessions` or `exec_tools` unless session semantics or shell execution behavior are central. - Use `docs` when documentation itself is the central deliverable, including docs-only PRs, provider registry documentation, README/reference updates, or documented registration of third-party plugins/providers. If a PR title starts with `docs(...)` and is docs-only, include `docs` first. - Use `security` only when authentication, authorization, credential handling, trust boundaries, unsafe defaults, validation bypasses, auth override behavior, or security-sensitive provider access is a central deliverable. - Do not use `security` merely because a feature includes allow/deny terminology, restrictions, policy, approval rules, or possible abuse prevention. - Use `auth_identity` only when identity, accounts, login/session identity, user/provider identity mapping, profile ID resolution, or identity lifecycle is central. - For model-auth fixes involving per-entry `apiKey` profile ID references, include `auth_identity`, `inference_api`, and `security`. - Use `skills_plugins` for plugin APIs, plugin registration, provider extension points, plugin runtime hooks, plugin capability wiring, or providers added through the plugin/provider system. - Use `mcp_tooling` when the deliverable changes MCP tools, MCP servers, MCP discovery, MCP visibility, MCP diagnostics, or behavior around exposing MCP tools to agents. - Use `sandboxing` when the deliverable changes sandbox behavior, sandbox diagnostics, sandbox restrictions, tool/file visibility caused by sandboxing, or warnings about sandbox-hidden capabilities. Suppression rules: - Suppress labels that are only where code changed, not what behavior changed. - Suppress labels that are only the producer of data, not the changed consumer contract. - Suppress labels that are only examples, motivations, symptoms, or consequences. - Suppress labels introduced only by commenters unless the final deliverable adopts that concern. - Suppress generic `sessions` when the central behavior is ACP, agent spawning/provisioning/runtime validation, runtime disposal, or chat-based steering of running agents. - Suppress `exec_tools` when the central behavior is approval flow or approval follow-up rather than shell command execution behavior. - Suppress `chat_integrations` for UI settings like TTS toggles or voice pickers unless the chat transport, webchat behavior, message result handling, or message delivery contract changes. - Suppress `auth_identity` for provider runtime auth hooks unless identity/profile/account mapping is central. - Suppress UI labels only when UI is merely mentioned as a possible consumer and no display/presentation behavior changes. - Suppress telemetry labels only when usage/cost/token/audit data is incidental and not part of the deliverable. - Suppress `security` unless the security model itself changes. - Suppress documentation labels only when docs are incidental to a product change. Output format: topics_of_interest: - topic_one - topic_two - topic_three ## Target `__TARGET__` ## GitHub Context __GITHUB_CONTEXT__ Use this context as source of truth. If important sections are missing, unavailable, selected, or truncated, classify from what is available and mention material limits in `caveats`.