opensource/kilocode
3
0
Fork 0
mirror of https://github.com/Kilo-Org/kilocode.git synced 2026-09-24 16:02:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

chore: remove plan files

Browse Source
This commit is contained in:
kirillk
2026-05-13 16:31:21 -04:00
parent 62e98e8b3d
commit 064bb1b6a7
3 changed files with 0 additions and 552 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.kilo/plans/1778523694544-stellar-panda.md
-133
View File
@@ -1,133 +0,0 @@
# Plan: Fix Plan Updated Label Without Performance Regression
## Goal
Fix the VS Code `plan_exit` label so updated plans reliably show `Existing plan was updated:` while avoiding broad scans or reactive work that could slow down chat rendering.
## Current Behavior
The plan-ready card sometimes shows `Plan is ready:` even when the preceding tool clearly updated the plan, e.g.:
- `Write ... .kilo/plans/ +218 -44`
- `Patch ... .kilo/plans/ +17 -3`
Those should show `Existing plan was updated:`.
## Why The Current Fix Fails
The current implementation in `packages/kilo-vscode/webview-ui/src/components/chat/AssistantMessage.tsx` tries to infer status inside `PlanExitCard`:
```ts
const all = createMemo(() => Object.values(data.store.part ?? {}).flat() as SDKPart[])
planExitInfo(props.part as unknown as SDKPart, [...props.parts, ...all()])
```
This has two problems:
1. Ordering bug
- `props.parts` is the current assistant message’s parts.
- When the current assistant message contains only `plan_exit`, the combined array starts with `plan_exit`.
- `inferPlanStatus()` finds the first `plan_exit` index and only checks parts before it:
```ts
const idx = parts.findIndex(...exit.id...)
const prior = idx === -1 ? parts : parts.slice(0, idx)
```
- Because `plan_exit` is first, `prior` is empty, so it never sees the earlier `write`/`apply_patch` tool.
2. Performance risk
- `Object.values(data.store.part ?? {}).flat()` runs inside every `PlanExitCard` render and can scan all loaded part arrays in the session store.
- This is unnecessary work for almost every assistant message and can grow with long sessions.
## Correct Approach
Use turn-local context instead of scanning all loaded session parts.
`VscodeSessionTurn.tsx` already has the full current turn:
- `props.turn.user`
- `props.turn.assistant`
It also already hydrates parts for that exact turn:
```ts
const ids = turn.partial ? turn.assistant.map((m) => m.id) : [turn.user.id, ...turn.assistant.map((m) => m.id)]
session.hydrateParts(ids)
```
The status inference only needs tools in this planning turn, not the whole session. The update/write/patch that produced the plan and the `plan_exit` part are part of the same visible turn. So we should compute ordered turn parts once in `VscodeSessionTurn` and pass them into every `AssistantMessage` for that turn.
## Implementation Plan
1. Add a turn-local ordered assistant parts memo in `VscodeSessionTurn.tsx`.
- Compute it from `assistantMessages()` in order.
- For each assistant message id, read `data.store.part?.[msg.id] ?? emptyParts`.
- Flatten only those arrays.
- Example shape:
```ts
const assistantParts = createMemo(() =>
assistantMessages().flatMap((msg) => (data.store.part?.[msg.id] ?? emptyParts) as SDKPart[]),
)
```
- This is bounded by the current turn, not all loaded session history.
2. Pass the turn-local parts into `AssistantMessage`.
- Extend `AssistantMessageProps` with `parts?: SDKPart[]` or `turnParts?: SDKPart[]`.
- In `VscodeSessionTurn.tsx`, pass `turnParts={assistantParts()}`.
- Keep naming clear; `turnParts` is probably best.
3. Remove the broad store scan from `PlanExitCard`.
- Remove:
```ts
const all = createMemo(() => Object.values(data.store.part ?? {}).flat() as SDKPart[])
```
- Call:
```ts
planExitInfo(props.part as unknown as SDKPart, props.turnParts)
```
- Do not concatenate `props.parts` in front of the ordered list.
4. Make `inferPlanStatus()` robust to list ordering.
- Keep current behavior of considering only parts before the current `plan_exit` if the exit id is found.
- If the exit id is not found in `turnParts` for any reason, use all `turnParts` except any `plan_exit` parts.
- This avoids false positives from tools after `plan_exit` while still avoiding the empty-prior bug.
- Example:
```ts
const idx = parts.findIndex(...)
const prior = idx >= 0 ? parts.slice(0, idx) : parts.filter((p) => !isPlanExit(p))
```
5. Keep the existing status heuristics but apply them to turn-local ordered parts.
- `edit` touching plan -> updated
- `apply_patch` touching plan with `type: "update" | "delete" | "move"` or deletions > 0 -> updated
- `write` touching plan with `filediff.deletions > 0` -> updated
- `read` + `write` touching plan -> updated
- `write` touching plan only -> new
- no match -> ready
6. Add/adjust tests to lock the performance-sensitive shape.
- Update `packages/kilo-vscode/tests/unit/plan-exit.test.ts` static assertions:
- Assert it no longer contains `Object.values(data.store.part ?? {}).flat()`.
- Assert `VscodeSessionTurn.tsx` contains a turn-local assistant parts memo using `assistantMessages().flatMap`.
- Assert `AssistantMessage` receives/passes `turnParts`.
- Keep assertions for:
- `data.openFile` and no `openDiff` usage.
- `write`, `edit`, `apply_patch`, `read + write`, and deletion heuristics.
7. Run targeted checks.
- `bun test tests/unit/plan-exit.test.ts` from `packages/kilo-vscode/`.
- If making TypeScript prop changes, run a targeted typecheck if feasible:
- `bun run typecheck` from `packages/kilo-vscode/` or at least `bun turbo typecheck --filter=kilo-code` if that is the established path after the merge.
- No opencode annotation check should be necessary because this fix should stay entirely in `packages/kilo-vscode/`.
## Performance Notes
- Current approach is O(total loaded parts) per `PlanExitCard` recomputation.
- Proposed approach is O(parts in current turn), computed once per visible turn and reused by its assistant messages.
- Typical turns have a small bounded number of parts compared to the full loaded session history.
- This also avoids allocating a flattened array for every plan-ready card from the full store.
- No backend or opencode changes are needed.
## Expected Outcome
After the fix:
- The screenshot case `Write ... +218 -44` should render `Existing plan was updated: .kilo/plans/...`.
- The `Patch ... +17 -3` case should render `Existing plan was updated: .kilo/plans/...`.
- A true first-time `write` with no deletions and no prior read should render `New plan is ready: .kilo/plans/...`.
- The renderer should remain fast because it uses only current-turn parts, not all loaded parts.
.kilo/plans/1778697937544-misty-wolf.md
-242
View File
@@ -1,242 +0,0 @@
# Plan: Colored Git Prompt Showing Branch
Goal: create a custom shell prompt that displays the current Git branch in color when the shell is inside a Git repository, hides the Git segment elsewhere, and remains easy to remove or extend later.
## Scope
- Target shell: `zsh`, because the environment default shell is `/bin/zsh`.
- Target config file: usually `~/.zshrc`, unless the existing prompt is sourced from another file.
- Prompt behavior:
- Show the current directory.
- Show the current Git branch in a colored segment when inside a Git repo.
- Show a short commit hash when in detached HEAD state.
- Show no Git text and no Git errors outside a repo.
- Implementation style:
- Prefer native `zsh` prompt escapes and shell functions.
- Avoid prompt frameworks unless one is already installed and clearly managing the prompt.
- Keep the change small, readable, and reversible.
## Design Choices
1. Use a helper function instead of embedding Git commands directly in `PROMPT`.
- This keeps the prompt definition readable.
- It makes later features like dirty-state or ahead/behind indicators easier to add.
- It isolates error suppression for non-Git directories.
2. Use `git symbolic-ref --short HEAD` for normal branches.
- This is simple and directly returns branch names such as `main` or `feature/login`.
- It fails in detached HEAD state, which can be handled by a fallback.
3. Use `git rev-parse --short HEAD` as the detached HEAD fallback.
- This keeps the prompt useful when checking out a commit, tag, rebase state, or bisect state.
- The prompt can display a short hash such as `(a1b2c3d)`.
4. Use `setopt PROMPT_SUBST`.
- This allows `$(git_branch)` to be evaluated every time the prompt is redrawn.
- Without this option, the Git branch would either not appear or would be evaluated only once.
5. Use zsh prompt color escapes instead of raw ANSI codes.
- `%F{green}` starts green foreground text.
- `%F{blue}` starts blue foreground text.
- `%f` resets the foreground color.
- These escapes are prompt-aware and avoid cursor-position issues caused by unwrapped ANSI sequences.
## Pre-Implementation Inspection
Before editing any shell config, inspect the current prompt setup:
1. Check `~/.zshrc`.
- Look for existing `PROMPT=`, `PS1=`, `RPROMPT=`, or `RPS1=` assignments.
- Look for `source` lines that load prompt-related files.
- Look for `setopt PROMPT_SUBST` or `unsetopt PROMPT_SUBST`.
2. Check whether a prompt framework is already active.
- Oh My Zsh indicators:
- `export ZSH=...`
- `ZSH_THEME=...`
- `source $ZSH/oh-my-zsh.sh`
- Powerlevel10k indicators:
- `powerlevel10k/powerlevel10k`
- `source ~/.p10k.zsh`
- Starship indicators:
- `eval "$(starship init zsh)"`
- Spaceship or other theme indicators:
- `SPACESHIP_...`
- theme plugin source lines.
3. Decide how to apply the prompt change based on what exists.
- If no framework manages the prompt, add the custom helper and `PROMPT` directly.
- If a framework manages the prompt, do not blindly override it.
- If the user already has a custom `PROMPT`, modify it carefully or add the Git segment in the least disruptive place.
- If Starship or Powerlevel10k is active, prefer configuring that framework instead of replacing it.
## Backup Strategy
Before changing shell config:
1. Create a timestamped backup of the file to be edited.
- Example: `~/.zshrc.backup.20260513-144700`
2. Keep the change grouped and labeled.
- Add a short marker comment before the custom prompt block.
- This makes rollback simple without restoring the whole backup.
3. Do not modify unrelated shell settings.
- Avoid reorganizing aliases, exports, plugins, or path setup.
- Keep the prompt block near existing prompt configuration if possible.
## Implementation Plan
1. Add prompt substitution if needed.
- Add `setopt PROMPT_SUBST` near the prompt block.
- If it already exists, do not duplicate it.
2. Add the Git branch function.
- Use a compact helper named `git_branch`.
- Suppress Git errors with `2>/dev/null`.
- Return no output outside Git repositories.
- Print a leading space only when a Git value exists, so the prompt spacing stays clean.
3. Define the colored prompt.
- Keep the current directory visible with `%~`.
- Color the directory blue.
- Color the branch segment green.
- Reset colors after each colored segment.
- End with `%#`, which shows `%` for normal users and `#` for root.
4. Keep the prompt single-line by default.
- A simple default is easier to validate and less disruptive.
- Multi-line prompt variants can be added later if desired.
5. Avoid adding expensive Git status checks in the first version.
- Branch lookup is fast enough for normal use.
- Dirty-state checks can be added later, but they may slow prompts in large repos.
## Proposed zsh Snippet
```zsh
# Custom colored Git prompt
setopt PROMPT_SUBST
git_branch() {
local branch
branch=$(git symbolic-ref --short HEAD 2>/dev/null) || branch=$(git rev-parse --short HEAD 2>/dev/null) || return
print -r -- " %F{green}(${branch})%f"
}
PROMPT='%F{blue}%~%f$(git_branch) %# '
```
Expected examples:
```text
~/projects/app (main) %
~/projects/app (feature/git-prompt) %
~/projects/app (a1b2c3d) %
~/Downloads %
```
## Optional Enhanced Variant
If the user wants a slightly richer prompt, add a dirty working tree marker later:
```zsh
git_branch() {
local branch dirty
branch=$(git symbolic-ref --short HEAD 2>/dev/null) || branch=$(git rev-parse --short HEAD 2>/dev/null) || return
git diff --quiet --ignore-submodules HEAD 2>/dev/null || dirty='*'
print -r -- " %F{green}(${branch}${dirty})%f"
}
```
Behavior:
- `(main)` means clean working tree.
- `(main*)` means the repo has uncommitted changes.
Caveat:
- Dirty-state checks can be slower in very large repositories, so this should be optional rather than the default first implementation.
## Validation Plan
Validate in a new shell process so a broken prompt does not disrupt the current session.
1. Syntax-load the config.
- Run a new `zsh` process that sources the modified config.
- Confirm there are no syntax errors.
2. Test outside a Git repo.
- Move to a non-repository directory.
- Confirm the prompt shows only the path and prompt symbol.
- Confirm no Git error messages appear.
3. Test inside a Git repo on a branch.
- Move to any repository with a checked-out branch.
- Confirm the branch appears in green.
- Confirm the directory appears in blue.
4. Test after changing branches.
- Switch to another branch in a disposable repo if available.
- Confirm the prompt updates without restarting the shell.
5. Test detached HEAD if practical.
- In a safe test repo, check out a commit hash temporarily.
- Confirm the prompt shows a short hash.
- Return to the original branch afterward.
6. Test command readability.
- Type a long command and use backspace/navigation.
- Confirm cursor movement is correct, which validates that color escapes are prompt-safe.
## Rollback Plan
If the prompt behaves incorrectly:
1. Remove the custom prompt block.
- Delete the `git_branch` function and the related `PROMPT` assignment.
- Remove `setopt PROMPT_SUBST` only if it was added solely for this prompt.
2. Restore the backup if needed.
- Copy the timestamped backup over the edited config.
3. Start a new shell.
- Confirm the old prompt is restored.
## Risks and Mitigations
- Risk: overriding an existing framework prompt.
- Mitigation: inspect for Oh My Zsh, Powerlevel10k, Starship, or theme setup before editing.
- Risk: raw ANSI colors break cursor movement.
- Mitigation: use zsh prompt escapes like `%F{green}` and `%f`.
- Risk: Git command errors appear outside repositories.
- Mitigation: redirect Git stderr to `/dev/null` and return no output when Git commands fail.
- Risk: prompt becomes slow in large repos.
- Mitigation: only resolve branch by default; make dirty-state checks optional.
- Risk: function name conflicts with an existing shell function.
- Mitigation: check for an existing `git_branch` function first, or rename to something more specific such as `prompt_git_branch`.
## Completion Criteria
The task is complete when:
- The prompt config is backed up before modification.
- The prompt shows a colored Git branch inside repositories.
- The prompt hides the Git segment outside repositories.
- Detached HEAD state displays a short commit hash.
- Existing framework-managed prompts are not accidentally overwritten.
- A new shell can load the config without syntax errors.
- Rollback instructions are clear and tested enough to be reliable.
## Future Enhancements
- Add dirty-state marker such as `*` for uncommitted changes.
- Add staged/unstaged indicators with different symbols.
- Add upstream ahead/behind counts.
- Add right-side prompt support with `RPROMPT`.
- Add a multi-line prompt layout.
- Switch to Starship if the user wants a cross-shell prompt with TOML configuration.
.kilo/plans/1778699914978-brave-moon.md
-177
View File
@@ -1,177 +0,0 @@
# Plan: Deliberate Custom Colored Git Prompt
## Objective
Create a polished, intentional shell prompt that clearly displays the current Git branch in color when inside a repository, stays clean outside Git repositories, and avoids slow Git operations on every prompt render.
## Design Principles
- Keep the prompt readable at a glance: path first, Git context second, prompt symbol last.
- Use color to communicate meaning, not decoration only.
- Avoid noisy output in non-Git directories.
- Support normal branches and detached HEAD states.
- Start with branch display only; add dirty-state indicators only if the user wants that extra signal.
- Keep the implementation self-contained in the shell config and easy to remove.
## Target Shell
Use `zsh` by default because the current environment uses zsh.
Primary config file:
```sh
~/.zshrc
```
If the target shell is different, adapt the same structure:
- `bash`: use `~/.bashrc` or `~/.bash_profile`
- `fish`: use `~/.config/fish/config.fish` with fish-specific syntax
## Prompt Layout
Use this deliberate layout:
```sh
<path> <git-branch> <symbol>
```
Examples:
```sh
~/projects %
~/projects/app (main) %
~/projects/app (a1b2c3d) %
```
Color choices:
- Path: cyan, because it is stable location context.
- Git branch: green, because it is contextual state and should stand out.
- Detached HEAD: yellow, because it is notable but not necessarily an error.
- Prompt symbol: default color, to avoid visual clutter.
## Git Branch Behavior
The branch helper should return:
- nothing outside a Git worktree
- the branch name on a normal branch
- a short commit hash in detached HEAD state
Use this order:
1. `git symbolic-ref --quiet --short HEAD` for normal branches.
2. `git rev-parse --short HEAD` for detached HEAD.
3. return nothing if both fail.
Redirect errors to `/dev/null` so the prompt never prints Git errors.
## Implementation Plan
1. Back up the existing prompt configuration mentally before editing.
- Inspect `~/.zshrc` for an existing `PROMPT`, `PS1`, `precmd`, or prompt framework setup.
- If a framework is active, such as Oh My Zsh, Starship, Powerlevel10k, or Prezto, do not blindly override it; either disable that framework's prompt or integrate the Git segment into the existing prompt style.
2. Add prompt substitution for zsh.
```sh
setopt PROMPT_SUBST
```
This allows `$(git_prompt)` to be evaluated every time the prompt is drawn.
3. Add a small helper for the current Git ref.
- Keep the function focused on data retrieval only.
- Do not format colors in this helper.
4. Add a formatter for the Git prompt segment.
- Return an empty string outside Git repos.
- Wrap normal branches in green.
- Wrap detached HEAD hashes in yellow.
- Keep parentheses around the value for visual separation.
5. Set the prompt.
- Use `%~` for compact path display.
- Use `%#` for the prompt symbol.
- Keep one space between path, Git segment, and symbol.
6. Reload the shell config.
```sh
source ~/.zshrc
```
7. Verify behavior in three directories.
- Home or another non-Git directory: no Git segment appears.
- A Git repo on a branch: branch appears in green.
- Detached HEAD state: short commit hash appears in yellow.
## Recommended zsh Snippet
```sh
setopt PROMPT_SUBST
_git_ref() {
git symbolic-ref --quiet --short HEAD 2>/dev/null || git rev-parse --short HEAD 2>/dev/null
}
_git_prompt() {
local ref="$(_git_ref)"
if [[ -z "$ref" ]]; then
return
fi
if git symbolic-ref --quiet HEAD >/dev/null 2>&1; then
printf '%%F{green}(%s)%%f' "$ref"
return
fi
printf '%%F{yellow}(%s)%%f' "$ref"
}
PROMPT='%F{cyan}%~%f $(_git_prompt) %# '
```
## More Polished Variant
If the user wants a more styled prompt, use separators while keeping it simple:
```sh
PROMPT='%F{cyan}%~%f %F{242}|%f $(_git_prompt) %# '
```
Example:
```sh
~/projects/app | (main) %
```
This is visually cleaner in long paths, but the plain version is better if minimalism is preferred.
## Optional Dirty-State Indicator
Add this only after the basic prompt works.
Desired behavior:
- Clean repo: `(main)` in green
- Dirty repo: `(main*)` in yellow
- Detached HEAD: `(a1b2c3d)` in yellow
Implementation idea:
```sh
_git_dirty() {
git diff --quiet --ignore-submodules -- 2>/dev/null && git diff --cached --quiet --ignore-submodules -- 2>/dev/null
}
```
Tradeoff:
- Useful signal, but adds Git work on every prompt render.
- Usually fine in small repos, but can feel slow in very large repos.
- Do not include remote ahead/behind checks by default because they are more expensive.
## Framework Compatibility Notes
If a prompt framework is already installed:
- Starship: configure Git branch in `~/.config/starship.toml` instead of writing custom zsh functions.
- Oh My Zsh: either select a theme with Git support or add this custom segment after theme initialization.
- Powerlevel10k: use `p10k configure` or edit `~/.p10k.zsh`; do not overwrite `PROMPT` directly.
Default recommendation: only use the custom snippet when the shell config does not already delegate prompt rendering to a framework.
## Verification Checklist
- `source ~/.zshrc` exits with no errors.
- Prompt has no empty `()` segment outside Git repos.
- Branch appears in green inside a normal Git branch.
- Detached HEAD appears as a short hash in yellow.
- Prompt remains responsive after several `cd` operations.
- Existing shell aliases, completions, and prompt framework behavior are not accidentally broken.
## Rollback Plan
If the prompt behaves incorrectly:
1. Reopen `~/.zshrc`.
2. Remove or comment out the custom functions and `PROMPT=...` line.
3. Restore the previous `PROMPT`, `PS1`, or framework initialization.
4. Run `source ~/.zshrc` again.
## Final Recommendation
Implement the basic zsh snippet first. It gives a clean, colored branch display with detached HEAD support and minimal performance cost. Add dirty-state indicators only after confirming the base prompt feels good in daily use.