chore: remove agent config files from git tracking
This commit is contained in:
@@ -33,6 +33,11 @@ next-env.d.ts
|
|||||||
.claude/
|
.claude/
|
||||||
.idea/
|
.idea/
|
||||||
.zed/
|
.zed/
|
||||||
|
AGENTS.md
|
||||||
|
CLAUDE.md
|
||||||
|
AIDER_RULES.md
|
||||||
|
.aider.chat.history.md
|
||||||
|
.aider.input.history
|
||||||
|
|
||||||
# agent loop
|
# agent loop
|
||||||
agent_loop/
|
agent_loop/
|
||||||
|
|||||||
@@ -1,5 +0,0 @@
|
|||||||
<!-- BEGIN:nextjs-agent-rules -->
|
|
||||||
# This is NOT the Next.js you know
|
|
||||||
|
|
||||||
This version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in `node_modules/next/dist/docs/` before writing any code. Heed deprecation notices.
|
|
||||||
<!-- END:nextjs-agent-rules -->
|
|
||||||
@@ -1,45 +0,0 @@
|
|||||||
# Aider Coding Rules
|
|
||||||
|
|
||||||
You are editing a real repository. Correctness is more important than speed.
|
|
||||||
|
|
||||||
## Operating Rules
|
|
||||||
|
|
||||||
1. Before editing, identify the exact requested task and restate the concrete files or behaviors that must
|
|
||||||
change.
|
|
||||||
2. Read the relevant existing files before making changes. Do not infer APIs, imports, types, or component
|
|
||||||
contracts from memory.
|
|
||||||
3. Implement every requested step. Do not skip checklist items, tests, wiring, exports, or documentation
|
|
||||||
updates that are part of the task.
|
|
||||||
4. Keep changes minimal and scoped. Do not refactor unrelated code, rename unrelated symbols, or change
|
|
||||||
behavior outside the task.
|
|
||||||
5. Prefer existing project patterns over new abstractions.
|
|
||||||
6. If a requirement is ambiguous, choose the smallest implementation that satisfies the written request and
|
|
||||||
state the assumption.
|
|
||||||
|
|
||||||
## Code Quality Rules
|
|
||||||
|
|
||||||
1. Do not introduce type errors, broken imports, missing exports, unused variables, or dead code.
|
|
||||||
2. Do not use placeholder code, TODOs, stubs, fake implementations, or comments claiming work is done when
|
|
||||||
it is not.
|
|
||||||
3. Preserve existing public APIs unless the task explicitly changes them.
|
|
||||||
4. Handle null, undefined, empty arrays, failed network calls, and invalid user input where relevant.
|
|
||||||
5. Keep async behavior explicit. Await promises that must complete before continuing.
|
|
||||||
6. Do not weaken or delete tests to make checks pass.
|
|
||||||
|
|
||||||
## Step Completion Rules
|
|
||||||
|
|
||||||
Before finishing, verify this checklist mentally and fix any failures:
|
|
||||||
|
|
||||||
- The requested behavior is fully implemented.
|
|
||||||
- Every required file is created or updated.
|
|
||||||
- All changed imports resolve.
|
|
||||||
- All changed types are valid.
|
|
||||||
- Existing behavior not mentioned in the task is preserved.
|
|
||||||
- Tests were added or updated when behavior changed.
|
|
||||||
- No generated files, build artifacts, cache files, or secrets were edited.
|
|
||||||
- The final response lists what changed and any checks that still need to be run.
|
|
||||||
|
|
||||||
## If You Are Unsure
|
|
||||||
|
|
||||||
Do not guess. Inspect the repository first. If still uncertain, make the smallest safe change and
|
|
||||||
explicitly mention the assumption in the final response.
|
|
||||||
Reference in New Issue
Block a user