chore: sync upstream/main 19 commits (2026-09-05)

.agents/skills/speckit-bug-assess/SKILL.md

@@ -0,0 +1 @@
+../../../.specify/extensions/bug/.specify-dev/agent-commands/zed/speckit-bug-assess/SKILL.md

.agents/skills/speckit-bug-fetch/SKILL.md

@@ -0,0 +1 @@
+../../../.specify/extensions/bug/.specify-dev/agent-commands/zed/speckit-bug-fetch/SKILL.md

.agents/skills/speckit-bug-fix/SKILL.md

@@ -0,0 +1 @@
+../../../.specify/extensions/bug/.specify-dev/agent-commands/zed/speckit-bug-fix/SKILL.md

.agents/skills/speckit-bug-issue/SKILL.md

@@ -0,0 +1 @@
+../../../.specify/extensions/bug/.specify-dev/agent-commands/zed/speckit-bug-issue/SKILL.md

.agents/skills/speckit-bug-pr/SKILL.md

@@ -0,0 +1 @@
+../../../.specify/extensions/bug/.specify-dev/agent-commands/zed/speckit-bug-pr/SKILL.md

.agents/skills/speckit-bug-test/SKILL.md

@@ -0,0 +1 @@
+../../../.specify/extensions/bug/.specify-dev/agent-commands/zed/speckit-bug-test/SKILL.md

.specify/bugs/auto-compaction-freeze-all/assessment.md

@@ -0,0 +1,93 @@
+# Bug Assessment: Auto-compaction should freeze everything (goals, todolist, auto, yolo, etc.) — past fixes cancelled compaction instead
+
+- **Slug**: auto-compaction-freeze-all
+- **Created**: 2025-08-26T08:00:02.053Z
+- **Source**: pasted text (referencing past failed attempts)
+- **Verdict**: valid
+- **Severity**: critical
+
+## Report (verbatim or summarized)
+
+> create a new issue referencing past failed attempts of auto compact. when auto compact kicks in, everything should freeze, pause, goal,todolist,auoto,yolo whatever, currently when auto-compact kickis in it is just getting cancelled by agent ALL THE TIME. we did some several attempts to fix and failed, all previous code was removed so new task will get a clean slate. this should be fixed with a minimal change, preferablly a single setting, trying to toucch multiple surfaces will make it only fragile so DO NOT over engineer it, I am sure in the all configs arsenal, this can be fixed without wrintrg a single line of code only changing a setting or simply adding a 1 or 2 if statenments.
+
+**Past failed attempts (assessments exist):**
+1. `.specify/bugs/goal-pause-compaction/` — Goal runtime was supposed to pause on auto-compaction begin and resume on complete. **Failed** — compaction still cancelled.
+2. `.specify/bugs/todolist-cancels-compaction/` — Context injector was supposed to skip injections during compaction. **Failed** — compaction still cancelled.
+
+Both assessments were written, but the fixes either weren't applied or didn't work. All previous code changes were reverted/removed.
+
+## Symptom
+
+When auto-compaction triggers (context crosses threshold), the compaction begins but is **repeatedly cancelled** by the agent's ongoing activity (goals, todolist reminders, auto-continuation turns, etc.). The TUI shows "Compacting context…" then immediately "Compaction cancelled". The context never gets compacted, leading to context overflow and degraded performance.
+
+The user wants **everything to freeze** when auto-compaction runs: goals pause, todolist pauses, auto/yolo modes pause — and only resume after compaction **completes successfully**.
+
+## Reproduction
+
+1. Run a session with auto-compaction enabled (default)
+2. Grow context to cross the auto-compaction threshold (or set a low threshold for testing)
+3. Have an active goal (`/goal ...`) AND/OR an active TodoList
+4. Let auto-compaction trigger
+5. Observe: `compaction.started` → `compaction.cancelled` (repeatedly); context never compacted
+
+## Suspected Code Paths
+
+**Compaction core (v2):**
+- `packages/agent-core-v2/src/agent/fullCompaction/fullCompactionService.ts` — `beforeStep()` → `checkAutoCompaction()` → `begin({ source: 'auto' })` → `block(signal, turnId)` (line ~614). The `block()` method registers `propagateBlockingAbort()` which aborts compaction when the step signal aborts. This is the **cancellation mechanism**.
+
+**Goal subsystem (v2):**
+- `packages/agent-core-v2/src/features/goal/goalAgentRuntime.ts` — Drives goal via `launchContinuationTurn()` / `handleTurnEnded()`. Previous fix attempted to subscribe to `FullCompactionBegin`/`FullCompactionComplete` and pause/resume, but didn't prevent the step signal abort that cancels compaction.
+
+**TodoList subsystem (v2):**
+- `packages/agent-core-v2/src/agent/contextInjector/contextInjectorService.ts` — `reconcileAroundStep` on `onWillBeginStep` hook injects TodoList reminders during compaction.
+- `packages/agent-core-v2/src/agent/fullCompaction/fullCompactionService.ts:933` — `historySafeToCompact()` rejects context mutated by injections → `cancelActive()` → `compaction.cancelled`.
+
+**Prompt service (v2):**
+- `packages/agent-core-v2/src/agent/prompt/promptService.ts:231,404` — Already has `fullCompaction.compacting !== null` guard to defer new turns, but this doesn't stop context injector or step signal abort.
+
+## Root Cause Hypothesis
+
+**Confidence: high**
+
+The root cause is architectural: **the compaction `block()` method uses the step's abort signal to cancel compaction**. Any agent turn that starts during compaction and then gets aborted (new continuation, budget deadline, user interrupt, etc.) fires the step signal abort → compaction cancelled.
+
+The previous fixes tried to **pause higher-level systems** (goal, todolist) but didn't address the **core mechanism**: the step signal abort propagates to compaction. As long as the agent loop can start a turn during compaction and that turn can be aborted, compaction will be cancelled.
+
+The user's insight: **"in the all configs arsenal, this can be fixed without writing a single line of code only changing a setting or simply adding a 1 or 2 if statements"** — suggests there's a configuration flag or simple guard that prevents turn starts during compaction, rather than trying to coordinate pause/resume across multiple subsystems.
+
+## Proposed Remediation
+
+**Preferred**: **Single config flag / minimal guard** to prevent *any* turn from starting while compaction is in flight, rather than coordinating pause/resume across goals/todolist/auto/yolo.
+
+Looking at the code:
+- `promptService.ts` already checks `fullCompaction.compacting !== null` to defer turns
+- But the **loop itself** still runs steps during compaction (the compaction runs *inside* a blocked step)
+- The issue is that **other code paths** (context injector hooks, goal continuation logic) can trigger during the blocked step
+
+**Minimal fix candidates (config-only or 1-2 if statements):**
+1. **Add a `compaction.exclusive` config flag** (default `true`) that makes the loop skip `beforeStep`/`onWillBeginStep` hooks entirely while compaction is running
+2. **Extend the existing `promptService` guard** to also gate the context injector and any other hook that can mutate context/start turns
+3. **Set a global "compaction in progress" flag on the session/agent** that all subsystems check before doing anything
+
+The user believes this is solvable via **configuration**. Check if there's already a flag like `compaction.blocksAllActivity` or similar in the config schema.
+
+**Files likely to change (minimal):**
+- `packages/agent-core-v2/src/agent/fullCompaction/configSection.ts` — add config flag if missing
+- `packages/agent-core-v2/src/agent/loop/loop.ts` — single `if (compacting) return` in step entry
+- OR `packages/agent-core-v2/src/agent/prompt/promptService.ts` — extend existing guard (already has the pattern)
+
+**Tests to add or update:**
+- Test that with the config enabled, auto-compaction runs to completion without any `compaction.cancelled` when goals/todolist/auto are active
+- Test that the compaction completes in one go (no repeated start/cancel cycles)
+
+## Risks & Considerations
+
+- **Minimalism**: User explicitly said "DO NOT over engineer it", "single setting", "1 or 2 if statements". Any fix touching multiple files/subsystems is wrong.
+- **Clean slate**: All previous code was removed. This is a fresh attempt.
+- **Config-driven**: The fix should ideally be a config change, not code. If code is needed, it must be a single guard in the main loop.
+
+## Open Questions
+
+- [NEEDS CLARIFICATION: Is there already a config flag for this in `fullCompaction` config section?]
+- [NEEDS CLARIFICATION: Which engine — v1 (`agent-core`) or v2 (`agent-core-v2`) — is the CLI using? The fix should target the default engine.]
+- [NEEDS CLARIFICATION: Should manual compaction (`/squeeze`) also get exclusive mode, or only auto?]

.specify/bugs/auto-compaction-freeze-all/issue.md

@@ -0,0 +1,9 @@
+# Bug Issue: Auto-compaction should freeze everything — past fixes cancelled compaction instead
+
+- **Slug**: auto-compaction-freeze-all
+- **Reported**: 2025-08-26T08:00:02.053Z
+- **Issue**: 17
+- **URL**: https://github.com/arrrrny/kimi-code-sync/issues/17
+- **Severity**: critical
+
+Filed GitHub issue for the auto-compaction freeze problem, referencing past failed attempts (goal-pause-compaction #14, todolist-cancels-compaction #15). The fix should be minimal — ideally a single config setting or 1-2 if statements — not a multi-subsystem coordination.

.specify/bugs/fallback-model-retry-mechanism/assessment.md

@@ -0,0 +1,90 @@
+# Bug Assessment: No fallback model mechanism on request failures
+
+- **Slug**: fallback-model-retry-mechanism
+- **Created**: 2025-08-26T08:00:02.053Z
+- **Source**: pasted text
+- **Verdict**: valid
+- **Severity**: high
+
+## Report (verbatim or summarized)
+
+> when a request fails there is no fallback mechanism. create a fallback model with option retryAfterErrorCount default to 3 max 10 min 1 so if set after 3 tries it tries with the fallback model and if successed it switches to that fallback model. this should apply to all models in all scenarios so no need to go extra detail of indivual fallback model setting, so lets say a swarm agent failed it retries with fallback and sucessed and change its model. so every session, agent only changes to fallback on only in its own scope.
+
+## Symptom
+
+When an LLM request fails (rate limit, timeout, provider error), there's no automatic fallback to an alternative model. Users must manually change models via `/model` command. The request is retried with the same model (up to 10 attempts by default in `chatWithRetry`), but if the model is fundamentally unavailable (quota exhausted, model deprecated, provider down), retries will never succeed.
+
+## Reproduction
+
+1. Configure a session with a primary model
+2. Exhaust the quota for that model (or simulate a provider outage)
+3. Send a prompt — requests fail with rate limit / quota errors
+4. Observe that retries continue with the same failing model (up to 10 attempts)
+5. No automatic switch to a fallback model occurs
+
+## Suspected Code Paths
+
+- `packages/agent-core/src/loop/retry.ts` — `chatWithRetry()` (lines 38-89): Implements retry logic with exponential backoff but **no model fallback**. Only retries the same LLM instance.
+- `packages/agent-core/src/loop/llm.ts` — `LLM` interface and implementations: Each LLM is bound to a specific model; no fallback chain.
+- `packages/agent-core/src/session/provider-manager.ts` — `ProviderManager`: Resolves provider config for a model alias; could be extended to resolve fallback chain.
+- `packages/agent-core-v2/src/agent/loop/loop.ts` — Agent loop that calls `chatWithRetry`
+- `packages/kosong/src/provider.ts` — Provider abstraction; errors include `APIProviderRateLimitError`
+
+## Root Cause Hypothesis
+
+**Confidence: high**
+
+The retry mechanism in `chatWithRetry` (agent-core v1) only retries the **same LLM instance** with the same model. There's no concept of a "fallback model" in the LLM abstraction or the retry logic. The `maxAttempts` (default 10) only controls how many times to retry the same model, not when to switch models.
+
+In agent-core-v2, the loop likely uses a similar pattern. The `ProviderManager` can resolve different model aliases, but there's no configuration for fallback chains or automatic switching on failure.
+
+## Proposed Remediation
+
+**Preferred**: Add a global fallback model configuration with retry threshold
+
+1. **Add config section** (e.g., `[fallback_model]` in `config.toml`):
+   - `model`: fallback model alias
+   - `retryAfterErrorCount`: number of failed attempts before fallback (default: 3, min: 1, max: 10)
+   - `enabled`: boolean (default: false)
+2. **Modify `chatWithRetry`** (and v2 equivalent) to:
+   - Track consecutive failures per agent/session scope
+   - After `retryAfterErrorCount` failures, attempt request with fallback model
+   - If fallback succeeds, **switch the agent's model to the fallback** for subsequent requests (persist in agent config)
+   - Scope the switch to the individual agent (session, subagent, swarm agent each track their own fallback state)
+3. **Add fallback model resolution** in `ProviderManager` / kosong provider layer
+
+**Alternatives**:
+- Per-model fallback configuration (more granular but complex)
+- Fallback only on specific error codes (rate limit, quota, unavailable) — not all errors
+- Event-based: emit `model.fallback` event for UI notification
+
+**Files likely to change**:
+- `packages/agent-core/src/loop/retry.ts` — core retry logic modification
+- `packages/agent-core/src/config/schema.ts` — add `FallbackModelConfigSchema`
+- `packages/agent-core/src/config/` — new `fallback-model.ts` for overlay/logic
+- `packages/agent-core/src/session/provider-manager.ts` — fallback model resolution
+- `packages/agent-core-v2/src/agent/loop/loop.ts` — v2 loop integration
+- `packages/agent-core-v2/src/app/kosongConfig/` — v2 config section
+
+**Tests to add or update**:
+- Test that after N failures, fallback model is attempted
+- Test that successful fallback switches the agent's model persistently
+- Test that fallback is scoped per-agent (swarm agent fallback doesn't affect parent)
+- Test that `retryAfterErrorCount` bounds (1-10) are enforced
+- Test that fallback only triggers on retryable errors (rate limit, not validation errors)
+
+## Risks & Considerations
+
+- **Scope isolation**: Each agent (session, subagent, swarm agent) must have independent fallback state. A swarm agent falling back should not change the parent's model.
+- **Error classification**: Only retryable errors (rate limit, timeout, 5xx) should trigger fallback. Invalid requests (400) should not.
+- **Infinite fallback loop**: If fallback also fails, should not keep switching models. Max one fallback switch per agent per session.
+- **Config persistence**: When an agent switches to fallback, should the config be persisted? User said "switches to that fallback model" — implies persistent change for that agent.
+- **Provider compatibility**: Fallback model must be from a compatible provider (or at least callable via kosong).
+
+## Open Questions
+
+- [NEEDS CLARIFICATION: Should fallback apply to all error types or only rate limit / quota errors?]
+- [NEEDS CLARIFICATION: Should the fallback model switch be persisted to config.toml or only in-memory for the session?]
+- [NEEDS CLARIFICATION: Should there be a fallback chain (fallback of fallback) or just one level?]
+- [NEEDS CLARIFICATION: Does this need to work in both agent-core (v1) and agent-core-v2, or only v2?]
+- [NEEDS CLARIFICATION: How should the fallback model be specified — a single global fallback, or per-model fallback mapping?]

.specify/bugs/fallback-model-retry-mechanism/issue.md

@@ -0,0 +1,9 @@
+# Bug Issue: No fallback model mechanism on request failures
+
+- **Slug**: fallback-model-retry-mechanism
+- **Reported**: 2025-08-26T08:00:02.053Z
+- **Issue**: 16
+- **URL**: https://github.com/arrrrny/kimi-code-sync/issues/16
+- **Severity**: high
+
+Filed GitHub issue for the missing fallback model mechanism — when requests fail (rate limit, quota), there's no automatic switch to a fallback model after N retries.