f01e2064fb
Security & Permissions: - All 30 agents: task[*]=deny, task[subagent]=deny (cascade prevention) - orchestrator & release-manager: bash=ask (hardening) - New .kilo/rules/subagent-security.md with audit rules - Updated .kilo/rules/global.md with Security & Permissions section - Updated .kilo/agents/orchestrator.md with Security Enforcement block Session Management: - New .kilo/rules/session-persistence.md (checkpoint format, worktree isolation) - Updated .kilo/rules/branch-strategy.md (worktree per agent) - pipeline-runner.ts: Checkpoint interface + save/load/resume methods Plan Persistence: - Updated .kilo/rules/lead-developer.md (plan handover section) Per-Agent Reasoning: - capability-index.yaml: reasoning_effort for all 30 agents (xhigh/high/medium/low) MCP Cleanup: - New .kilo/skills/docker-security/SKILL.md (--rm, orphaned process cleanup) Config Validation: - Updated .kilo/rules/docker.md (startup checks, commit scoping, location awareness) Docs: - README.md: v2026-05-07 evolution badges - .kilo/EVOLUTION_LOG.md: Entry #6 with full metrics - .gitignore: ignore dist/ + bun.lock Gitea: Milestone #66, Issues #91-#98 Architect: 9/9 sections fresh (express project type)
64 lines
1.8 KiB
Markdown
64 lines
1.8 KiB
Markdown
# Lead Developer Rules
|
|
|
|
- Write clean, maintainable code following project conventions
|
|
- NEVER add comments unless explicitly asked
|
|
- Check existing dependencies before adding new ones
|
|
- Follow existing code patterns and style in the codebase
|
|
|
|
## Code Quality
|
|
|
|
- Use early returns to reduce nesting
|
|
- Prefer immutable data structures
|
|
- Write self-documenting code with clear names
|
|
- Handle edge cases and errors appropriately
|
|
- Follow SOLID principles where applicable
|
|
|
|
## Before Writing Code
|
|
|
|
1. Use search tools to understand existing patterns
|
|
2. Check package.json/cargo.toml for available libraries
|
|
3. Read neighboring files for style conventions
|
|
4. Identify existing utilities that can be reused
|
|
|
|
## Implementation Priority
|
|
|
|
1. Make it work
|
|
2. Make it clean
|
|
3. Make it fast (only if needed)
|
|
|
|
## Security
|
|
|
|
- Never expose secrets, keys, or credentials
|
|
- Validate all inputs
|
|
- Use parameterized queries for databases
|
|
- Follow OWASP guidelines for web applications
|
|
|
|
## Examples
|
|
|
|
Good variable naming:
|
|
```javascript
|
|
const userCount = users.length;
|
|
const isValidEmail = email.includes('@');
|
|
```
|
|
|
|
Early returns:
|
|
```javascript
|
|
function processUser(user) {
|
|
if (!user) return null;
|
|
if (!user.active) return inactiveResponse();
|
|
return processActive(user);
|
|
}
|
|
```
|
|
|
|
## Plan Persistence & Handover
|
|
|
|
### After Plan Completion
|
|
1. When plan mode completes, save the plan to `.kilo/plans/{issue}.md`.
|
|
2. Include a compact summary of explored files and key decisions.
|
|
3. Append predefined suggestions for next-session context management.
|
|
|
|
### Before Destructive Edits
|
|
1. Create a checkpoint stash named `checkpoint/{issue}-{agent}-{timestamp}`.
|
|
2. Persist the current session state to `.kilo/logs/checkpoints/{issue}-planning.json`.
|
|
3. If resuming from checkpoint, read the plan file first and inject its summary into system context.
|