feat(agent): add auto-backgrounding and process management (#17 )

* feat(agent): add auto-backgrounding to exec tool

- Add yieldMs parameter to exec tool (default 5s) - commands that don't
  complete within this time automatically run in background
- Create shared process-registry.ts for unified process management
- Refactor process.ts to use shared registry
- Add --debug CLI flag for session message logging
- Signal isolation: backgrounded processes ignore abort signals

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix(session): preserve tool_use/tool_result pairs during compaction

Previously, session compaction simply kept the last N messages, which
could break tool_use/tool_result pairs if the cut point fell between
them. This caused "tool_call_id is not found" errors from the API.

Now compaction finds a safe cut point that starts from either:
- A user message without tool_result
- An assistant message whose tool_use is needed by the next tool_result

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* feat(session): use Kimi as default model for summary compaction

- Auto-detect MOONSHOT_API_KEY from environment
- Use moonshot-v1-128k (cheaper than k2-thinking)
- Fall back to tokens mode if API key not available

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs: add rule to never use git commit --amend

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs: clarify git amend rule for immediate fixes

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>

2026-01-30 04:22:42 +08:00

2.1 KiB

Raw Blame History

Project Instructions for AI Agents

Atomic Commits

After completing any task that modifies code, you MUST create atomic commits before ending the conversation. Do not ask for permission - just do it.

Workflow

Check for changes: Run git status and git diff to see all modifications
Skip if clean: If there are no changes, skip the commit process
Analyze changes: Group changes by their logical purpose:
- Feature additions
- Bug fixes
- Refactoring
- Documentation
- Tests
- Configuration/dependencies
Create atomic commits: For each logical group, stage only the relevant files and create a separate commit

Commit Process

For each logical group of changes:

# Stage specific files for this logical change
git add <file1> <file2>

# Commit with conventional commit message
git commit -m "<type>(<scope>): <description>"

Commit Message Format

Use conventional commits:

feat: New feature
fix: Bug fix
refactor: Code refactoring (no functional change)
docs: Documentation changes
test: Adding or updating tests
chore: Build, config, dependencies

Examples

If you modified:

src/api/user.ts (added new endpoint)
src/api/user.test.ts (tests for new endpoint)
src/utils/format.ts (refactored helper)
README.md (updated docs)

Create three commits:

git add src/api/user.ts src/api/user.test.ts && git commit -m "feat(api): add user profile endpoint"
git add src/utils/format.ts && git commit -m "refactor(utils): simplify date formatting logic"
git add README.md && git commit -m "docs: update API documentation"

Rules

Each commit should be independently meaningful and buildable
Related test files should be committed with their implementation
Never create empty commits
Never combine unrelated changes in one commit
Keep commit messages concise but descriptive
If all changes are related to one logical unit, a single commit is fine
git commit --amend can be used for immediate small fixes to the last commit, but not for unrelated changes

2.1 KiB Raw Blame History