22 lines
1.6 KiB
Markdown
22 lines
1.6 KiB
Markdown
# Repo Working Notes
|
|
|
|
- Verify the actual file, class name, and call site before changing a library/controller reference.
|
|
- If a class load error appears, check the existing library file and the current repo usage pattern first.
|
|
- Do not swap to a different library name on assumption alone.
|
|
- Keep fixes minimal and local unless the user asks for a broader refactor.
|
|
- If a task changes live DB objects such as table schema, trigger, stored procedure, or function, always add a SQL record file under `sql/manual_changes/`.
|
|
- Name the SQL record file with the pattern `YYYY-MM-DD-<commit-message-stem>.sql`.
|
|
- The SQL record file must include the actual SQL change that was applied, not just a note.
|
|
- Before every `commit` and `push`, always check first whether local branch needs to pull/rebase from remote.
|
|
- To upload to IBL, run `bash scripts/upload_ibl_committed_files.sh`. Only run this when the user explicitly asks to upload to IBL. Do not run automatically after commit/push.
|
|
|
|
## graphify
|
|
|
|
This project has a graphify knowledge graph at graphify-out/.
|
|
|
|
Rules:
|
|
- Before answering architecture or codebase questions, read graphify-out/GRAPH_REPORT.md for god nodes and community structure
|
|
- If graphify-out/wiki/index.md exists, navigate it instead of reading raw files
|
|
- For cross-module "how does X relate to Y" questions, prefer `graphify query "<question>"`, `graphify path "<A>" "<B>"`, or `graphify explain "<concept>"` over grep — these traverse the graph's EXTRACTED + INFERRED edges instead of scanning files
|
|
- After modifying code files in this session, run `graphify update .` to keep the graph current (AST-only, no API cost)
|