docs: rewrite documentation system

This commit is contained in:
2026-06-12 12:04:28 +02:00
parent 842dcc6235
commit fb302a033e
6 changed files with 872 additions and 799 deletions
+198
View File
@@ -0,0 +1,198 @@
# pi-project-map Usage Guide
For Pi agents and advanced users who want predictable, low-friction navigation and maintenance of project-map artifacts.
## When to use each command
| Situation | Command |
|-----------|---------|
| New project, no `.pi-map.md` files yet, or artifacts are severely outdated | `project_map_init` / `project-map init` |
| You just edited one or more source files | `project_map_patch <file>` / `project-map patch <file>` |
| You suspect stale data, or you are about to make an architectural decision | `project_map_validate` / `project-map validate` |
| Validation shows widespread staleness, or you pulled major changes from version control | `project_map_reinit` / `project-map reinit` |
| You have a specific question like "where is auth handled?" | `project_map_context <query>` / `project-map context <query>` |
## Command behavior
### init
Run once when you start work on a repo, or after large restructuring. It discovers every non-ignored directory, analyzes files with LLM + AST, and writes both `.pi-map.md` and `.pi-map.index.md` for every directory.
### patch
Run **immediately after editing a source file**. The command regenerates the pair for that files directory and refreshes ancestor artifacts.
Patch mode is chosen automatically:
- **small** — refresh ancestor indexes only
- **structural** — refresh ancestor map/index pairs
You can force a mode with `project-map patch <file> --patch-mode=small|structural`.
`auto` remains the default.
### validate
Run before architectural decisions, broad refactors, or final handoff. It checks for:
- missing/orphaned files
- stale signatures
- dirty markers
- broken parent/children/sibling links
- map/index disagreements
Use `project-map validate --fix` to repair affected chains. `--fix` requires an LLM client.
### reinit
Use sparingly. It regenerates every pair from scratch and is the blunt instrument for widespread staleness.
### context
Use when you know what you are looking for:
```bash
project-map context "authentication logic"
project-map context "routing metadata generation"
project-map context "LLM client error handling"
```
The returned bundle is deterministic and ranked. Read indexes first, then strongest-match maps, then the actual source files.
## Practical workflows
### Starting a new task in a mapped project
1. read the root `.pi-map.index.md` and the `Project Map Protocol`
2. use the root index to find the relevant child directory
3. read that directorys `.pi-map.index.md`, then its `.pi-map.md`
4. read the relevant source files
5. edit source
6. run `project_map_patch <changed-file>`
7. run tests/build
8. run `project_map_validate` before architectural summary or handoff
### Exploring an unfamiliar area
```bash
project-map context "how is validation implemented"
```
Treat the returned bundle as a ranked entry point, not as truth.
### After pulling changes from version control
```bash
project-map validate
# if many discrepancies:
project-map reinit
```
### Before a big refactor
```bash
project-map validate
# if needed:
project-map reinit
```
## Prompt injection behavior before and after init
### Before init
If no paired artifacts exist:
- `off`: nothing happens
- `advisory`, `strong`, `strict`: a visible hint appears telling you to run `project_map_init`
No map content is fabricated.
### After init
Once the root pair exists:
- `off`: no automatic injection
- `advisory`: a visible reminder that maps are available, but the root pair is **not** auto-loaded
- `strong`: root pair is auto-loaded; additional pairs are added within the budget; reinjection happens on relevant turns
- `strict`: same as `strong`, plus enforcement of the protocol path for sensitive actions
Relevant turns that trigger reinjection in `strong`/`strict`:
- agent start
- edit intent
- architecture-sensitive reasoning
- compaction
- root-pair artifact changes
## Advisory vs strong vs strict in practice
| Concern | Use |
|---------|-----|
| You want maps available but do not want automatic context expansion | `advisory` |
| Normal daily work; you want routing/orientation preloaded without friction | `strong` (default) |
| High-stakes codebase or you want explicit justification before bypassing context discipline | `strict` |
| You prefer fully manual control | `off` |
In `strict`, if you attempt a sensitive edit or architectural claim without the protocol path in context, a guard appears. To proceed, either restore the project-map context or include:
```text
[PI_MAP_BYPASS: editing a one-line comment, map context not needed]
```
Use bypass markers sparingly.
## Example task flows
### Fix a bug in `src/utils/validation.ts`
```text
1. project-map context "validation utilities"
2. Read src/utils/.pi-map.index.md and .pi-map.md
3. Read src/utils/validation.ts
4. Edit the file
5. project_map_patch src/utils/validation.ts
6. Run tests
7. project_map_validate
```
### Add a new file to `src/llm/`
```text
1. Create src/llm/new-client.ts
2. Implement the file
3. project_map_patch src/llm/new-client.ts
4. project_map_validate
```
### Review architecture before approving a PR
```text
1. project-map validate
2. If clean, read root .pi-map.md and key directory maps
3. Cross-check claims against source
4. If stale, run project-map reinit first
```
## Retrieval vs automatic injection
| | Automatic injection | `project_map_context` / `project-map context` |
|---|---|---|
| Trigger | Configured mode + relevant turn | Explicit request |
| Content | Root pair + budgeted expansion | Top-ranked directories for a query |
| Cost | No LLM call; reads artifacts | No LLM call; deterministic scoring |
| Best use | Maintain baseline orientation | Targeted navigation for a specific task |
Use both together: injection for baseline orientation, retrieval for focused entry points.
## Keeping artifacts fresh
- patch after every edit
- validate before architectural claims
- reinit when many artifacts are stale or after large merges
- watch for the Pi extension warning about dirty packages on session start
## Configuration quick reference
```json
{
"promptInjectionMode": "strong",
"contextBudgetPercent": 15,
"contextBudgetMaxTokens": 100000,
"tagCap": 8,
"workflowHintCap": 5,
"ignorePatterns": ["node_modules", ".git", "dist", "build"]
}
```
Providing `ignorePatterns` replaces the built-in default list, so include any defaults you want to keep.
- lower `contextBudgetPercent` / `contextBudgetMaxTokens` to reduce token use
- raise them if you want deeper auto-loaded context in large projects
- `strict` is the safest enforcement mode; `strong` is the best default for everyday work