# Repository Guidelines

## Project Structure & Module Organization
This repository is an Obsidian vault organized with the PARA method:
- `000-inbox/`: unprocessed notes and clippings
- `100-project/`: active projects (personal and work)
- `200-area/`: ongoing areas of responsibility
- `300-resources/`: reference material by topic
- `400-archive/`: completed/inactive items
- `Clippings/` and `ReadItLater Inbox/`: saved articles

Top-level date notes (for example `2025-12-29.md`) live at the root. Treat the vault as content, not an app project.

## Build, Test, and Development Commands
There is no build or test system. Use standard shell tools to inspect and edit Markdown files.
- Example: `rg "keyword" 200-area/` for fast search

## Writing Style & Naming Conventions
- Use Markdown for all notes. Keep headings short and sentence-case.
- Prefer ASCII characters unless the note already uses non-ASCII.
- Frontmatter keys should be consistent: `title`, `aliases`, `tags`, `created`, `updated`, `source`.
- Do not modify `.obsidian/` or `.smart-env/` unless explicitly requested.

## Content Safety & Refactor Rules
- Never delete information. If merging or replacing notes, move originals to `400-archive/` and leave a short stub linking to the new note.
- Keep changes incremental: one clear objective per batch.
- When moving/renaming, update affected wikilinks `[[...]]` across the vault.

## Testing Guidelines
No automated tests are configured. If you make large changes, run a link check if you have one locally, or do a targeted `rg` search to spot broken wikilinks.

## Commit & Pull Request Guidelines
Recent commits use short, descriptive summaries (for example: “Refactor Personal folder structure for improved organization”). If you add backup commits, follow the existing pattern `vault backup: YYYY-MM-DD HH:MM:SS`.

PRs should include:
- A brief description of what moved/changed and why
- A list of affected directories (for example `100-project/Personal/`)
- Any manual checks performed (link search, spot review)