Give Claude a whiteboard. Pastefield MCP.

Map this codebase on a Pastefield board, so people and agents can see how it works.

1. Read the repository before drawing anything: the README and docs, package manifests, the folder layout, database migrations or schema files, route and API definitions, the environment variables that name outside services, and the main entry points. Note the https URL of the git remote and the current commit (git rev-parse --short HEAD).
2. Choose the frames, the systems a newcomer would name: the people and agents who use it, the client app, the server, shared packages, the database, outside services. Usually 4 to 8; a large system can use more, up to the limit below.
3. Choose the cards: the routes, functions, modules, tables, services and jobs that matter, usually 40 to 120. Give each a key, a frame, a kind (route, function, module, table, service, package, hook, job, actor), a name, a one-sentence summary in plain words, and a file path from the repository root. A table lists its columns in cols, most important first. Add notes only where they help a reader: auth (who is allowed), limit (quotas), retry (what makes a repeat safe), fail (what happens when it breaks).
4. Make keys stable and readable, built from the code itself, such as `table:items`, `route:post:/api/ops` or `mod:src/server/ops.ts`. Keys use only letters, digits and the characters `_ . : / @ # -`. The next sync finds each card by its key, so never rename a key without a reason.
5. Add links for real calls, reads, writes and events between cards, with a label of a word or two where it helps; dash the ones that happen later or through a queue. Fewer true links read better than many guessed ones.
6. Add journeys, usually 4 to 8 (a large system can use more, up to the limit below): the flows a user or an operator cares about, such as signing up, the product's core action, paying, an agent making a change, a background job. Each step names a card by key, with a short title, one sentence and a tag of a word or two for the link into that step. Let steps follow links that exist.
7. Create a board named after the project (create_board). If the board already has a map, call get_map first and keep its keys, so what people changed stays. Then call sync_map once with title, summary, repo, commit, frames, nodes, links and journeys. Limits: 24 frames, 400 cards, 800 links, 12 journeys of up to 30 steps.
8. Check it: call screenshot_board, fix anything that reads wrong or anything sync_map reported under dropped or unlinked, then reply with the board's URL and two sentences on what the map covers.

Write summaries for someone new to the code: what each part does and why it matters, not how it is written. Never add a file, table, route or service you did not read.

Write every summary, note, frame summary and journey step in ASD-STE100 Simplified Technical English. One idea in each sentence, and at most 20 words in a sentence. Use the active voice and simple tenses: "The server writes the op", not "The op is written" or "is writing". Use one word for one thing everywhere on the map: if a card says board, no card says canvas. Use common words with one meaning (use, start, make sure, before). Keep technical names as the code spells them: routes, tables, functions, product terms. No idioms and no filler such as "the heart of" or "seamlessly".