{"owner":"fathah","repo":"hermes-desktop","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md"],"skills":{"AGENTS.md":"# Before starting work\n\n- Run `lat search` to find sections relevant to your task. Read them to understand the design intent before writing code.\n- Run `lat expand` on user prompts to expand any `[[refs]]` — this resolves section names to file locations and provides context.\n\n# Post-task checklist (REQUIRED — do not skip)\n\nAfter EVERY task, before responding to the user:\n\n- [ ] Update `lat.md/` if you added or changed any functionality, architecture, tests, or behavior\n- [ ] Run `lat check` — all wiki links and code refs must pass\n- [ ] Do not skip these steps. Do not consider your task done until both are complete.\n\n---\n\n# What is lat.md?\n\nThis project uses [lat.md](https://www.npmjs.com/package/lat.md) to maintain a structured knowledge graph of its architecture, design decisions, and test specs in the `lat.md/` directory. It is a set of cross-linked markdown files that describe **what** this project does and **why** — the domain concepts, key design decisions, business logic, and test specifications. Use it to ground your work in the actual architecture rather than guessing.\n\n# Commands\n\n```bash\nlat locate \"Section Name\"      # find a section by name (exact, fuzzy)\nlat refs \"file#Section\"        # find what references a section\nlat search \"natural language\"  # semantic search across all sections\nlat expand \"user prompt text\"  # expand [[refs]] to resolved locations\nlat check                      # validate all links and code refs\n```\n\nRun `lat --help` when in doubt about available commands or options.\n\nIf `lat search` fails because no API key is configured, explain to the user that semantic search requires a key provided via `LAT_LLM_KEY` (direct value), `LAT_LLM_KEY_FILE` (path to key file), or `LAT_LLM_KEY_HELPER` (command that prints the key). Supported key prefixes: `sk-...` (OpenAI) or `vck_...` (Vercel). If the user doesn't want to set it up, use `lat locate` for direct lookups instead.\n\n# Syntax primer\n\n- **Section ids**: `lat.md/path/to/file#Heading#SubHeading` — full form uses project-root-relative path (e.g. `lat.md/tests/search#RAG Replay Tests`). Short form uses bare file name when unique (e.g. `search#RAG Replay Tests`, `cli#search#Indexing`).\n- **Wiki links**: `[[target]]` or `[[target|alias]]` — cross-references between sections. Can also reference source code: `[[src/foo.ts#myFunction]]`.\n- **Source code links**: Wiki links in `lat.md/` files can reference functions, classes, constants, and methods in TypeScript/JavaScript/Python/Rust/Go/C files. Use the full path: `[[src/config.ts#getConfigDir]]`, `[[src/server.ts#App#listen]]` (class method), `[[lib/utils.py#parse_args]]`, `[[src/lib.rs#Greeter#greet]]` (Rust impl method), `[[src/app.go#Greeter#Greet]]` (Go method), `[[src/app.h#Greeter]]` (C struct). `lat check` validates these exist.\n- **Code refs**: `// @lat: [[section-id]]` (JS/TS/Rust/Go/C) or `# @lat: [[section-id]]` (Python) — ties source code to concepts\n\n# Test specs\n\nKey tests can be described as sections in `lat.md/` files (e.g. `tests.md`). Add frontmatter to require that every leaf section is referenced by a `// @lat:` or `# @lat:` comment in test code:\n\n```markdown\n---\nlat:\n  require-code-mention: true\n---\n# Tests\n\nAuthentication and authorization test specifications.\n\n## User login\n\nVerify credential validation and error handling for the login endpoint.\n\n### Rejects expired tokens\nTokens past their expiry timestamp are rejected with 401, even if otherwise valid.\n\n### Handles missing password\nLogin request without a password field returns 400 with a descriptive error.\n```\n\nEvery section MUST have a description — at least one sentence explaining what the test verifies and why. Empty sections with just a heading are not acceptable. (This is a specific case of the general leading paragraph rule below.)\n\nEach test in code should reference its spec with exactly one comment placed next to the relevant test — not at the top of the file:\n\n```python\n# @lat: [[tests#User login#Rejects expired tokens]]\ndef test_rejects_expired_tokens():\n    ...\n\n# @lat: [[tests#User login#Handles missing password]]\ndef test_handles_missing_password():\n    ...\n```\n\nDo not duplicate refs. One `@lat:` comment per spec section, placed at the test that covers it. `lat check` will flag any spec section not covered by a code reference, and any code reference pointing to a nonexistent section.\n\n# Section structure\n\nEvery section in `lat.md/` **must** have a leading paragraph — at least one sentence immediately after the heading, before any child headings or other block content. The first paragraph must be ≤250 characters (excluding `[[wiki link]]` content). This paragraph serves as the section's overview and is used in search results, command output, and RAG context — keeping it concise guarantees the section's essence is always captured.\n\n```markdown\n# Good Section\n\nBrief overview of what this section documents and why it matters.\n\nMore detail can go in subsequent paragraphs, code blocks, or lists.\n\n## Child heading\n\nDetails about this child topic.\n```\n\n```markdown\n# Bad Section\n\n## Child heading\n\nDetails about this child topic.\n```\n\nThe second example is invalid because `Bad Section` has no leading paragraph. `lat check` validates this rule and reports errors for missing or overly long leading paragraphs.\n","CLAUDE.md":"# Before starting work\n\n- Run `lat search` to find sections relevant to your task. Read them to understand the design intent before writing code.\n- Run `lat expand` on user prompts to expand any `[[refs]]` — this resolves section names to file locations and provides context.\n\n# Post-task checklist (REQUIRED — do not skip)\n\nAfter EVERY task, before responding to the user:\n\n- [ ] Update `lat.md/` if you added or changed any functionality, architecture, tests, or behavior\n- [ ] Run `lat check` — all wiki links and code refs must pass\n- [ ] Do not skip these steps. Do not consider your task done until both are complete.\n\n---\n\n# What is lat.md?\n\nThis project uses [lat.md](https://www.npmjs.com/package/lat.md) to maintain a structured knowledge graph of its architecture, design decisions, and test specs in the `lat.md/` directory. It is a set of cross-linked markdown files that describe **what** this project does and **why** — the domain concepts, key design decisions, business logic, and test specifications. Use it to ground your work in the actual architecture rather than guessing.\n\n# Commands\n\n```bash\nlat locate \"Section Name\"      # find a section by name (exact, fuzzy)\nlat refs \"file#Section\"        # find what references a section\nlat search \"natural language\"  # semantic search across all sections\nlat expand \"user prompt text\"  # expand [[refs]] to resolved locations\nlat check                      # validate all links and code refs\n```\n\nRun `lat --help` when in doubt about available commands or options.\n\nIf `lat search` fails because no API key is configured, explain to the user that semantic search requires a key provided via `LAT_LLM_KEY` (direct value), `LAT_LLM_KEY_FILE` (path to key file), or `LAT_LLM_KEY_HELPER` (command that prints the key). Supported key prefixes: `sk-...` (OpenAI) or `vck_...` (Vercel). If the user doesn't want to set it up, use `lat locate` for direct lookups instead.\n\n# Syntax primer\n\n- **Section ids**: `lat.md/path/to/file#Heading#SubHeading` — full form uses project-root-relative path (e.g. `lat.md/tests/search#RAG Replay Tests`). Short form uses bare file name when unique (e.g. `search#RAG Replay Tests`, `cli#search#Indexing`).\n- **Wiki links**: `[[target]]` or `[[target|alias]]` — cross-references between sections. Can also reference source code: `[[src/foo.ts#myFunction]]`.\n- **Source code links**: Wiki links in `lat.md/` files can reference functions, classes, constants, and methods in TypeScript/JavaScript/Python/Rust/Go/C files. Use the full path: `[[src/config.ts#getConfigDir]]`, `[[src/server.ts#App#listen]]` (class method), `[[lib/utils.py#parse_args]]`, `[[src/lib.rs#Greeter#greet]]` (Rust impl method), `[[src/app.go#Greeter#Greet]]` (Go method), `[[src/app.h#Greeter]]` (C struct). `lat check` validates these exist.\n- **Code refs**: `// @lat: [[section-id]]` (JS/TS/Rust/Go/C) or `# @lat: [[section-id]]` (Python) — ties source code to concepts\n\n# Test specs\n\nKey tests can be described as sections in `lat.md/` files (e.g. `tests.md`). Add frontmatter to require that every leaf section is referenced by a `// @lat:` or `# @lat:` comment in test code:\n\n```markdown\n---\nlat:\n  require-code-mention: true\n---\n# Tests\n\nAuthentication and authorization test specifications.\n\n## User login\n\nVerify credential validation and error handling for the login endpoint.\n\n### Rejects expired tokens\nTokens past their expiry timestamp are rejected with 401, even if otherwise valid.\n\n### Handles missing password\nLogin request without a password field returns 400 with a descriptive error.\n```\n\nEvery section MUST have a description — at least one sentence explaining what the test verifies and why. Empty sections with just a heading are not acceptable. (This is a specific case of the general leading paragraph rule below.)\n\nEach test in code should reference its spec with exactly one comment placed next to the relevant test — not at the top of the file:\n\n```python\n# @lat: [[tests#User login#Rejects expired tokens]]\ndef test_rejects_expired_tokens():\n    ...\n\n# @lat: [[tests#User login#Handles missing password]]\ndef test_handles_missing_password():\n    ...\n```\n\nDo not duplicate refs. One `@lat:` comment per spec section, placed at the test that covers it. `lat check` will flag any spec section not covered by a code reference, and any code reference pointing to a nonexistent section.\n\n# Section structure\n\nEvery section in `lat.md/` **must** have a leading paragraph — at least one sentence immediately after the heading, before any child headings or other block content. The first paragraph must be ≤250 characters (excluding `[[wiki link]]` content). This paragraph serves as the section's overview and is used in search results, command output, and RAG context — keeping it concise guarantees the section's essence is always captured.\n\n```markdown\n# Good Section\n\nBrief overview of what this section documents and why it matters.\n\nMore detail can go in subsequent paragraphs, code blocks, or lists.\n\n## Child heading\n\nDetails about this child topic.\n```\n\n```markdown\n# Bad Section\n\n## Child heading\n\nDetails about this child topic.\n```\n\nThe second example is invalid because `Bad Section` has no leading paragraph. `lat check` validates this rule and reports errors for missing or overly long leading paragraphs.\n"},"files":{"AGENTS.md":"# Before starting work\n\n- Run `lat search` to find sections relevant to your task. Read them to understand the design intent before writing code.\n- Run `lat expand` on user prompts to expand any `[[refs]]` — this resolves section names to file locations and provides context.\n\n# Post-task checklist (REQUIRED — do not skip)\n\nAfter EVERY task, before responding to the user:\n\n- [ ] Update `lat.md/` if you added or changed any functionality, architecture, tests, or behavior\n- [ ] Run `lat check` — all wiki links and code refs must pass\n- [ ] Do not skip these steps. Do not consider your task done until both are complete.\n\n---\n\n# What is lat.md?\n\nThis project uses [lat.md](https://www.npmjs.com/package/lat.md) to maintain a structured knowledge graph of its architecture, design decisions, and test specs in the `lat.md/` directory. It is a set of cross-linked markdown files that describe **what** this project does and **why** — the domain concepts, key design decisions, business logic, and test specifications. Use it to ground your work in the actual architecture rather than guessing.\n\n# Commands\n\n```bash\nlat locate \"Section Name\"      # find a section by name (exact, fuzzy)\nlat refs \"file#Section\"        # find what references a section\nlat search \"natural language\"  # semantic search across all sections\nlat expand \"user prompt text\"  # expand [[refs]] to resolved locations\nlat check                      # validate all links and code refs\n```\n\nRun `lat --help` when in doubt about available commands or options.\n\nIf `lat search` fails because no API key is configured, explain to the user that semantic search requires a key provided via `LAT_LLM_KEY` (direct value), `LAT_LLM_KEY_FILE` (path to key file), or `LAT_LLM_KEY_HELPER` (command that prints the key). Supported key prefixes: `sk-...` (OpenAI) or `vck_...` (Vercel). If the user doesn't want to set it up, use `lat locate` for direct lookups instead.\n\n# Syntax primer\n\n- **Section ids**: `lat.md/path/to/file#Heading#SubHeading` — full form uses project-root-relative path (e.g. `lat.md/tests/search#RAG Replay Tests`). Short form uses bare file name when unique (e.g. `search#RAG Replay Tests`, `cli#search#Indexing`).\n- **Wiki links**: `[[target]]` or `[[target|alias]]` — cross-references between sections. Can also reference source code: `[[src/foo.ts#myFunction]]`.\n- **Source code links**: Wiki links in `lat.md/` files can reference functions, classes, constants, and methods in TypeScript/JavaScript/Python/Rust/Go/C files. Use the full path: `[[src/config.ts#getConfigDir]]`, `[[src/server.ts#App#listen]]` (class method), `[[lib/utils.py#parse_args]]`, `[[src/lib.rs#Greeter#greet]]` (Rust impl method), `[[src/app.go#Greeter#Greet]]` (Go method), `[[src/app.h#Greeter]]` (C struct). `lat check` validates these exist.\n- **Code refs**: `// @lat: [[section-id]]` (JS/TS/Rust/Go/C) or `# @lat: [[section-id]]` (Python) — ties source code to concepts\n\n# Test specs\n\nKey tests can be described as sections in `lat.md/` files (e.g. `tests.md`). Add frontmatter to require that every leaf section is referenced by a `// @lat:` or `# @lat:` comment in test code:\n\n```markdown\n---\nlat:\n  require-code-mention: true\n---\n# Tests\n\nAuthentication and authorization test specifications.\n\n## User login\n\nVerify credential validation and error handling for the login endpoint.\n\n### Rejects expired tokens\nTokens past their expiry timestamp are rejected with 401, even if otherwise valid.\n\n### Handles missing password\nLogin request without a password field returns 400 with a descriptive error.\n```\n\nEvery section MUST have a description — at least one sentence explaining what the test verifies and why. Empty sections with just a heading are not acceptable. (This is a specific case of the general leading paragraph rule below.)\n\nEach test in code should reference its spec with exactly one comment placed next to the relevant test — not at the top of the file:\n\n```python\n# @lat: [[tests#User login#Rejects expired tokens]]\ndef test_rejects_expired_tokens():\n    ...\n\n# @lat: [[tests#User login#Handles missing password]]\ndef test_handles_missing_password():\n    ...\n```\n\nDo not duplicate refs. One `@lat:` comment per spec section, placed at the test that covers it. `lat check` will flag any spec section not covered by a code reference, and any code reference pointing to a nonexistent section.\n\n# Section structure\n\nEvery section in `lat.md/` **must** have a leading paragraph — at least one sentence immediately after the heading, before any child headings or other block content. The first paragraph must be ≤250 characters (excluding `[[wiki link]]` content). This paragraph serves as the section's overview and is used in search results, command output, and RAG context — keeping it concise guarantees the section's essence is always captured.\n\n```markdown\n# Good Section\n\nBrief overview of what this section documents and why it matters.\n\nMore detail can go in subsequent paragraphs, code blocks, or lists.\n\n## Child heading\n\nDetails about this child topic.\n```\n\n```markdown\n# Bad Section\n\n## Child heading\n\nDetails about this child topic.\n```\n\nThe second example is invalid because `Bad Section` has no leading paragraph. `lat check` validates this rule and reports errors for missing or overly long leading paragraphs.\n","CLAUDE.md":"# Before starting work\n\n- Run `lat search` to find sections relevant to your task. Read them to understand the design intent before writing code.\n- Run `lat expand` on user prompts to expand any `[[refs]]` — this resolves section names to file locations and provides context.\n\n# Post-task checklist (REQUIRED — do not skip)\n\nAfter EVERY task, before responding to the user:\n\n- [ ] Update `lat.md/` if you added or changed any functionality, architecture, tests, or behavior\n- [ ] Run `lat check` — all wiki links and code refs must pass\n- [ ] Do not skip these steps. Do not consider your task done until both are complete.\n\n---\n\n# What is lat.md?\n\nThis project uses [lat.md](https://www.npmjs.com/package/lat.md) to maintain a structured knowledge graph of its architecture, design decisions, and test specs in the `lat.md/` directory. It is a set of cross-linked markdown files that describe **what** this project does and **why** — the domain concepts, key design decisions, business logic, and test specifications. Use it to ground your work in the actual architecture rather than guessing.\n\n# Commands\n\n```bash\nlat locate \"Section Name\"      # find a section by name (exact, fuzzy)\nlat refs \"file#Section\"        # find what references a section\nlat search \"natural language\"  # semantic search across all sections\nlat expand \"user prompt text\"  # expand [[refs]] to resolved locations\nlat check                      # validate all links and code refs\n```\n\nRun `lat --help` when in doubt about available commands or options.\n\nIf `lat search` fails because no API key is configured, explain to the user that semantic search requires a key provided via `LAT_LLM_KEY` (direct value), `LAT_LLM_KEY_FILE` (path to key file), or `LAT_LLM_KEY_HELPER` (command that prints the key). Supported key prefixes: `sk-...` (OpenAI) or `vck_...` (Vercel). If the user doesn't want to set it up, use `lat locate` for direct lookups instead.\n\n# Syntax primer\n\n- **Section ids**: `lat.md/path/to/file#Heading#SubHeading` — full form uses project-root-relative path (e.g. `lat.md/tests/search#RAG Replay Tests`). Short form uses bare file name when unique (e.g. `search#RAG Replay Tests`, `cli#search#Indexing`).\n- **Wiki links**: `[[target]]` or `[[target|alias]]` — cross-references between sections. Can also reference source code: `[[src/foo.ts#myFunction]]`.\n- **Source code links**: Wiki links in `lat.md/` files can reference functions, classes, constants, and methods in TypeScript/JavaScript/Python/Rust/Go/C files. Use the full path: `[[src/config.ts#getConfigDir]]`, `[[src/server.ts#App#listen]]` (class method), `[[lib/utils.py#parse_args]]`, `[[src/lib.rs#Greeter#greet]]` (Rust impl method), `[[src/app.go#Greeter#Greet]]` (Go method), `[[src/app.h#Greeter]]` (C struct). `lat check` validates these exist.\n- **Code refs**: `// @lat: [[section-id]]` (JS/TS/Rust/Go/C) or `# @lat: [[section-id]]` (Python) — ties source code to concepts\n\n# Test specs\n\nKey tests can be described as sections in `lat.md/` files (e.g. `tests.md`). Add frontmatter to require that every leaf section is referenced by a `// @lat:` or `# @lat:` comment in test code:\n\n```markdown\n---\nlat:\n  require-code-mention: true\n---\n# Tests\n\nAuthentication and authorization test specifications.\n\n## User login\n\nVerify credential validation and error handling for the login endpoint.\n\n### Rejects expired tokens\nTokens past their expiry timestamp are rejected with 401, even if otherwise valid.\n\n### Handles missing password\nLogin request without a password field returns 400 with a descriptive error.\n```\n\nEvery section MUST have a description — at least one sentence explaining what the test verifies and why. Empty sections with just a heading are not acceptable. (This is a specific case of the general leading paragraph rule below.)\n\nEach test in code should reference its spec with exactly one comment placed next to the relevant test — not at the top of the file:\n\n```python\n# @lat: [[tests#User login#Rejects expired tokens]]\ndef test_rejects_expired_tokens():\n    ...\n\n# @lat: [[tests#User login#Handles missing password]]\ndef test_handles_missing_password():\n    ...\n```\n\nDo not duplicate refs. One `@lat:` comment per spec section, placed at the test that covers it. `lat check` will flag any spec section not covered by a code reference, and any code reference pointing to a nonexistent section.\n\n# Section structure\n\nEvery section in `lat.md/` **must** have a leading paragraph — at least one sentence immediately after the heading, before any child headings or other block content. The first paragraph must be ≤250 characters (excluding `[[wiki link]]` content). This paragraph serves as the section's overview and is used in search results, command output, and RAG context — keeping it concise guarantees the section's essence is always captured.\n\n```markdown\n# Good Section\n\nBrief overview of what this section documents and why it matters.\n\nMore detail can go in subsequent paragraphs, code blocks, or lists.\n\n## Child heading\n\nDetails about this child topic.\n```\n\n```markdown\n# Bad Section\n\n## Child heading\n\nDetails about this child topic.\n```\n\nThe second example is invalid because `Bad Section` has no leading paragraph. `lat check` validates this rule and reports errors for missing or overly long leading paragraphs.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Before starting work\n\n- Run `lat search` to find sections relevant to your task. Read them to understand the design intent before writing code.\n- Run `lat expand` on user prompts to expand any `[[refs]]` — this resolves section names to file locations and provides context.\n\n# Post-task checklist (REQUIRED — do not skip)\n\nAfter EVERY task, before responding to the user:\n\n- [ ] Update `lat.md/` if you added or changed any functionality, architecture, tests, or behavior\n- [ ] Run `lat check` — all wiki links and code refs must pass\n- [ ] Do not skip these steps. Do not consider your task done until both are complete.\n\n---\n\n# What is lat.md?\n\nThis project uses [lat.md](https://www.npmjs.com/package/lat.md) to maintain a structured knowledge graph of its architecture, design decisions, and test specs in the `lat.md/` directory. It is a set of cross-linked markdown files that describe **what** this project does and **why** — the domain concepts, key design decisions, business logic, and test specifications. Use it to ground your work in the actual architecture rather than guessing.\n\n# Commands\n\n```bash\nlat locate \"Section Name\"      # find a section by name (exact, fuzzy)\nlat refs \"file#Section\"        # find what references a section\nlat search \"natural language\"  # semantic search across all sections\nlat expand \"user prompt text\"  # expand [[refs]] to resolved locations\nlat check                      # validate all links and code refs\n```\n\nRun `lat --help` when in doubt about available commands or options.\n\nIf `lat search` fails because no API key is configured, explain to the user that semantic search requires a key provided via `LAT_LLM_KEY` (direct value), `LAT_LLM_KEY_FILE` (path to key file), or `LAT_LLM_KEY_HELPER` (command that prints the key). Supported key prefixes: `sk-...` (OpenAI) or `vck_...` (Vercel). If the user doesn't want to set it up, use `lat locate` for direct lookups instead.\n\n# Syntax primer\n\n- **Section ids**: `lat.md/path/to/file#Heading#SubHeading` — full form uses project-root-relative path (e.g. `lat.md/tests/search#RAG Replay Tests`). Short form uses bare file name when unique (e.g. `search#RAG Replay Tests`, `cli#search#Indexing`).\n- **Wiki links**: `[[target]]` or `[[target|alias]]` — cross-references between sections. Can also reference source code: `[[src/foo.ts#myFunction]]`.\n- **Source code links**: Wiki links in `lat.md/` files can reference functions, classes, constants, and methods in TypeScript/JavaScript/Python/Rust/Go/C files. Use the full path: `[[src/config.ts#getConfigDir]]`, `[[src/server.ts#App#listen]]` (class method), `[[lib/utils.py#parse_args]]`, `[[src/lib.rs#Greeter#greet]]` (Rust impl method), `[[src/app.go#Greeter#Greet]]` (Go method), `[[src/app.h#Greeter]]` (C struct). `lat check` validates these exist.\n- **Code refs**: `// @lat: [[section-id]]` (JS/TS/Rust/Go/C) or `# @lat: [[section-id]]` (Python) — ties source code to concepts\n\n# Test specs\n\nKey tests can be described as sections in `lat.md/` files (e.g. `tests.md`). Add frontmatter to require that every leaf section is referenced by a `// @lat:` or `# @lat:` comment in test code:\n\n```markdown\n---\nlat:\n  require-code-mention: true\n---\n# Tests\n\nAuthentication and authorization test specifications.\n\n## User login\n\nVerify credential validation and error handling for the login endpoint.\n\n### Rejects expired tokens\nTokens past their expiry timestamp are rejected with 401, even if otherwise valid.\n\n### Handles missing password\nLogin request without a password field returns 400 with a descriptive error.\n```\n\nEvery section MUST have a description — at least one sentence explaining what the test verifies and why. Empty sections with just a heading are not acceptable. (This is a specific case of the general leading paragraph rule below.)\n\nEach test in code should reference its spec with exactly one comment placed next to the relevant test — not at the top of the file:\n\n```python\n# @lat: [[tests#User login#Rejects expired tokens]]\ndef test_rejects_expired_tokens():\n    ...\n\n# @lat: [[tests#User login#Handles missing password]]\ndef test_handles_missing_password():\n    ...\n```\n\nDo not duplicate refs. One `@lat:` comment per spec section, placed at the test that covers it. `lat check` will flag any spec section not covered by a code reference, and any code reference pointing to a nonexistent section.\n\n# Section structure\n\nEvery section in `lat.md/` **must** have a leading paragraph — at least one sentence immediately after the heading, before any child headings or other block content. The first paragraph must be ≤250 characters (excluding `[[wiki link]]` content). This paragraph serves as the section's overview and is used in search results, command output, and RAG context — keeping it concise guarantees the section's essence is always captured.\n\n```markdown\n# Good Section\n\nBrief overview of what this section documents and why it matters.\n\nMore detail can go in subsequent paragraphs, code blocks, or lists.\n\n## Child heading\n\nDetails about this child topic.\n```\n\n```markdown\n# Bad Section\n\n## Child heading\n\nDetails about this child topic.\n```\n\nThe second example is invalid because `Bad Section` has no leading paragraph. `lat check` validates this rule and reports errors for missing or overly long leading paragraphs.\n","category":"root","tokens":1327},{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# Before starting work\n\n- Run `lat search` to find sections relevant to your task. Read them to understand the design intent before writing code.\n- Run `lat expand` on user prompts to expand any `[[refs]]` — this resolves section names to file locations and provides context.\n\n# Post-task checklist (REQUIRED — do not skip)\n\nAfter EVERY task, before responding to the user:\n\n- [ ] Update `lat.md/` if you added or changed any functionality, architecture, tests, or behavior\n- [ ] Run `lat check` — all wiki links and code refs must pass\n- [ ] Do not skip these steps. Do not consider your task done until both are complete.\n\n---\n\n# What is lat.md?\n\nThis project uses [lat.md](https://www.npmjs.com/package/lat.md) to maintain a structured knowledge graph of its architecture, design decisions, and test specs in the `lat.md/` directory. It is a set of cross-linked markdown files that describe **what** this project does and **why** — the domain concepts, key design decisions, business logic, and test specifications. Use it to ground your work in the actual architecture rather than guessing.\n\n# Commands\n\n```bash\nlat locate \"Section Name\"      # find a section by name (exact, fuzzy)\nlat refs \"file#Section\"        # find what references a section\nlat search \"natural language\"  # semantic search across all sections\nlat expand \"user prompt text\"  # expand [[refs]] to resolved locations\nlat check                      # validate all links and code refs\n```\n\nRun `lat --help` when in doubt about available commands or options.\n\nIf `lat search` fails because no API key is configured, explain to the user that semantic search requires a key provided via `LAT_LLM_KEY` (direct value), `LAT_LLM_KEY_FILE` (path to key file), or `LAT_LLM_KEY_HELPER` (command that prints the key). Supported key prefixes: `sk-...` (OpenAI) or `vck_...` (Vercel). If the user doesn't want to set it up, use `lat locate` for direct lookups instead.\n\n# Syntax primer\n\n- **Section ids**: `lat.md/path/to/file#Heading#SubHeading` — full form uses project-root-relative path (e.g. `lat.md/tests/search#RAG Replay Tests`). Short form uses bare file name when unique (e.g. `search#RAG Replay Tests`, `cli#search#Indexing`).\n- **Wiki links**: `[[target]]` or `[[target|alias]]` — cross-references between sections. Can also reference source code: `[[src/foo.ts#myFunction]]`.\n- **Source code links**: Wiki links in `lat.md/` files can reference functions, classes, constants, and methods in TypeScript/JavaScript/Python/Rust/Go/C files. Use the full path: `[[src/config.ts#getConfigDir]]`, `[[src/server.ts#App#listen]]` (class method), `[[lib/utils.py#parse_args]]`, `[[src/lib.rs#Greeter#greet]]` (Rust impl method), `[[src/app.go#Greeter#Greet]]` (Go method), `[[src/app.h#Greeter]]` (C struct). `lat check` validates these exist.\n- **Code refs**: `// @lat: [[section-id]]` (JS/TS/Rust/Go/C) or `# @lat: [[section-id]]` (Python) — ties source code to concepts\n\n# Test specs\n\nKey tests can be described as sections in `lat.md/` files (e.g. `tests.md`). Add frontmatter to require that every leaf section is referenced by a `// @lat:` or `# @lat:` comment in test code:\n\n```markdown\n---\nlat:\n  require-code-mention: true\n---\n# Tests\n\nAuthentication and authorization test specifications.\n\n## User login\n\nVerify credential validation and error handling for the login endpoint.\n\n### Rejects expired tokens\nTokens past their expiry timestamp are rejected with 401, even if otherwise valid.\n\n### Handles missing password\nLogin request without a password field returns 400 with a descriptive error.\n```\n\nEvery section MUST have a description — at least one sentence explaining what the test verifies and why. Empty sections with just a heading are not acceptable. (This is a specific case of the general leading paragraph rule below.)\n\nEach test in code should reference its spec with exactly one comment placed next to the relevant test — not at the top of the file:\n\n```python\n# @lat: [[tests#User login#Rejects expired tokens]]\ndef test_rejects_expired_tokens():\n    ...\n\n# @lat: [[tests#User login#Handles missing password]]\ndef test_handles_missing_password():\n    ...\n```\n\nDo not duplicate refs. One `@lat:` comment per spec section, placed at the test that covers it. `lat check` will flag any spec section not covered by a code reference, and any code reference pointing to a nonexistent section.\n\n# Section structure\n\nEvery section in `lat.md/` **must** have a leading paragraph — at least one sentence immediately after the heading, before any child headings or other block content. The first paragraph must be ≤250 characters (excluding `[[wiki link]]` content). This paragraph serves as the section's overview and is used in search results, command output, and RAG context — keeping it concise guarantees the section's essence is always captured.\n\n```markdown\n# Good Section\n\nBrief overview of what this section documents and why it matters.\n\nMore detail can go in subsequent paragraphs, code blocks, or lists.\n\n## Child heading\n\nDetails about this child topic.\n```\n\n```markdown\n# Bad Section\n\n## Child heading\n\nDetails about this child topic.\n```\n\nThe second example is invalid because `Bad Section` has no leading paragraph. `lat check` validates this rule and reports errors for missing or overly long leading paragraphs.\n","category":"root","tokens":1327}]}