|
| 1 | +# Before starting work |
| 2 | + |
| 3 | +- Run `lat search` to find sections relevant to your task. Read them to understand the design intent before writing code. |
| 4 | +- Run `lat expand` on user prompts to expand any `[[refs]]` — this resolves section names to file locations and provides context. |
| 5 | + |
| 6 | +# Post-task checklist (REQUIRED — do not skip) |
| 7 | + |
| 8 | +After EVERY task, before responding to the user: |
| 9 | + |
| 10 | +- [ ] Update `lat.md/` if you added or changed any functionality, architecture, tests, or behavior |
| 11 | +- [ ] Run `lat check` — all wiki links and code refs must pass |
| 12 | +- [ ] Do not skip these steps. Do not consider your task done until both are complete. |
| 13 | + |
| 14 | +--- |
| 15 | + |
| 16 | +# What is lat.md? |
| 17 | + |
| 18 | +This 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. |
| 19 | + |
| 20 | +# Commands |
| 21 | + |
| 22 | +```bash |
| 23 | +lat locate "Section Name" # find a section by name (exact, fuzzy) |
| 24 | +lat refs "file#Section" # find what references a section |
| 25 | +lat search "natural language" # semantic search across all sections |
| 26 | +lat expand "user prompt text" # expand [[refs]] to resolved locations |
| 27 | +lat check # validate all links and code refs |
| 28 | +``` |
| 29 | + |
| 30 | +Run `lat --help` when in doubt about available commands or options. |
| 31 | + |
| 32 | +If `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. |
| 33 | + |
| 34 | +# Syntax primer |
| 35 | + |
| 36 | +- **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`). |
| 37 | +- **Wiki links**: `[[target]]` or `[[target|alias]]` — cross-references between sections. Can also reference source code: `[[src/foo.ts#myFunction]]`. |
| 38 | +- **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. |
| 39 | +- **Code refs**: `// @lat: [[section-id]]` (JS/TS/Rust/Go/C) or `# @lat: [[section-id]]` (Python) — ties source code to concepts |
| 40 | + |
| 41 | +# Test specs |
| 42 | + |
| 43 | +Key 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: |
| 44 | + |
| 45 | +```markdown |
| 46 | +--- |
| 47 | +lat: |
| 48 | + require-code-mention: true |
| 49 | +--- |
| 50 | +# Tests |
| 51 | + |
| 52 | +Authentication and authorization test specifications. |
| 53 | + |
| 54 | +## User login |
| 55 | + |
| 56 | +Verify credential validation and error handling for the login endpoint. |
| 57 | + |
| 58 | +### Rejects expired tokens |
| 59 | +Tokens past their expiry timestamp are rejected with 401, even if otherwise valid. |
| 60 | + |
| 61 | +### Handles missing password |
| 62 | +Login request without a password field returns 400 with a descriptive error. |
| 63 | +``` |
| 64 | + |
| 65 | +Every 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.) |
| 66 | + |
| 67 | +Each test in code should reference its spec with exactly one comment placed next to the relevant test — not at the top of the file: |
| 68 | + |
| 69 | +```python |
| 70 | +# @lat: [[tests#User login#Rejects expired tokens]] |
| 71 | +def test_rejects_expired_tokens(): |
| 72 | + ... |
| 73 | + |
| 74 | +# @lat: [[tests#User login#Handles missing password]] |
| 75 | +def test_handles_missing_password(): |
| 76 | + ... |
| 77 | +``` |
| 78 | + |
| 79 | +Do 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. |
| 80 | + |
| 81 | +# Section structure |
| 82 | + |
| 83 | +Every 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. |
| 84 | + |
| 85 | +```markdown |
| 86 | +# Good Section |
| 87 | + |
| 88 | +Brief overview of what this section documents and why it matters. |
| 89 | + |
| 90 | +More detail can go in subsequent paragraphs, code blocks, or lists. |
| 91 | + |
| 92 | +## Child heading |
| 93 | + |
| 94 | +Details about this child topic. |
| 95 | +``` |
| 96 | + |
| 97 | +```markdown |
| 98 | +# Bad Section |
| 99 | + |
| 100 | +## Child heading |
| 101 | + |
| 102 | +Details about this child topic. |
| 103 | +``` |
| 104 | + |
| 105 | +The 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. |
0 commit comments