# Repository Guidelines

## Project Structure & Module Organization
This repository is a Markdown-based knowledge base rather than an application codebase. Top-level folders group notes by domain, such as `AI/`, `Linux/`, `Docker/`, `数据库/`, `编程语言/`, and `项目策划/`. Root files like `README.md`, `📒萌芽笔记.md`, and `🗒记事本.md` act as entry points or quick notes. Obsidian workspace settings live in `.obsidian/`; only commit those changes when they are intentional and useful to other contributors.

## Build, Test, and Development Commands
There is no required build step or automated test suite in this repository. Useful maintenance commands:

- `rg --files` lists all tracked notes quickly.
- `git status --short` checks pending edits before committing.
- `git diff -- path/to/file.md` reviews a note before submission.
- `find . -name '*.md'` helps inspect coverage by folder when reorganizing content.

Preview and link-check notes in your local Markdown editor or Obsidian vault before committing.

## Coding Style & Naming Conventions
Use Markdown with clear heading hierarchy (`#`, `##`, `###`) and short paragraphs. Prefer one topic per file. Keep filenames descriptive and readable, matching the existing repository style: Chinese titles are common, sometimes with product or technology prefixes such as `Linux/SSH/安全SSH连接.md` or `编程语言/Golang/Golang标准代码架构.md`. Use fenced code blocks with language tags, for example ```bash or ```json. Prefer relative links for cross-note references.

## Testing Guidelines
Testing is manual. Verify that:

- headings render correctly,
- code blocks are fenced and labeled,
- internal links and paths are valid,
- moved notes remain in the correct category folder.

For large reorganizations, open the vault in Obsidian and spot-check edited directories.

## Commit & Pull Request Guidelines
Recent history uses short messages such as `chore: sync local changes`, `feat: 更新笔记内容`, and `update: 2026-03-28 21:00`. Follow that pattern, but make the summary specific: `docs: add WireGuard troubleshooting note` is better than `update`. Keep commits focused by topic or folder.

Pull requests should include a brief summary, affected directories, and any rename or move notes. Add screenshots only when a PR intentionally changes `.obsidian` appearance or workspace behavior.

## Security & Content Boundaries
Do not commit secrets, private tokens, or machine-specific scratch data. Treat `.obsidian/workspace.json`, temporary notes, and personal account records as high-risk changes and review them carefully before pushing.
