Import an existing project

Read THIS codebase and document it into PugBase as a "Docs" session so my team can read, onboard and hand off the project. This is DOCUMENTATION ONLY: do not change any code, and do not create tasks, plans, backlogs or anything with checkboxes - these notes describe what IS, they are not a to-do list.

Before anything else, TWO checks - and if either fails, STOP and tell me instead of improvising:
- The PugBase MCP tools must actually be available to you (you can see tools like create_note and list_notes). If you cannot see them, the PugBase MCP server is not connected: stop, do NOT pretend to work, and tell me to connect it first (PugBase -> Settings -> Developer).
- The target workspace must be certain. If your PugBase connection is scoped to one workspace, use it. If you can see MORE than one workspace (or more than one PugBase server is connected), list them and ask me which one BEFORE creating any note.

If this is a LARGE repo or a monorepo (many packages/services), do not silently survey everything: tell me what you found at the top level and ask which systems matter most, then go deep on those first.

SEVERAL REPOS IN ONE FOLDER: your working directory may be a PARENT folder holding one folder per repo (e.g. shop/{shop-web, shop-api, shop-admin}), each with its own .git - a very common shape for a product split across repos. Detect it BEFORE surveying: if the top level has no manifest of its own but its subfolders each carry a .git plus their own manifest, treat EACH as a separate repo, not as packages of one project (a monorepo has ONE .git at the top and shared tooling - say which of the two you found). Then: survey each repo in turn, name the repo on every note that describes its code (a "**Repo:** <folder name>" line under the title), and give Overview a "## Repos" table - | Repo | What it is | Stack | Runs on | - so a reader knows which checkout a file path belongs to. Cross-repo calls (web calling api) belong in the Architecture diagram with each system in its own zone. If PugBase reports declared repos for this workspace, use THOSE names verbatim.

Steps:
1. Survey the repo IN THIS ORDER, whatever the language - the artifacts below exist in every stack under some name:
   a. List the folder tree 2-3 levels deep to see the shape of the project (and, in a multi-repo folder, do this per repo).
   b. Read every manifest / build file (package.json, go.mod, Cargo.toml, pyproject, pom, csproj, Gemfile, pubspec, Makefile, ...) for dependencies and scripts.
   c. Find the entry points and how each system STARTS and how its tests run - the exact commands.
   d. Read the schema: migrations, ORM models, or collection definitions.
   e. Read routes/handlers/events, config + .env.example, CI and deploy files, then any README / docs.
2. Create EXACTLY these notes, with EXACTLY these titles, in the "Docs" session. Titles are a contract: teammates and tools look these notes up BY NAME, so do not rename, merge or restructure them - a small project gets the same set with shorter notes, never fewer notes. Skip a note ONLY when the project truly has none of that thing (no API, no database), and then say so in "Start Here" ("no Data Model - the service keeps no state"). File each note in the FOLDER shown and pass the ICON shown (icon + folderIcon args) so the sidebar reads at a glance. A [[link]] only becomes a real link when its target note already exists, so create the content notes first and the index LAST:
   - Overview (no folder, icon "🧭"): what the project is and does, who uses it, and a "## Systems & architecture" section listing each system/service with its real stack and how they connect.
   - Run & Deploy (folder "Setup", folderIcon "🚀", icon "▶"): per system, the EXACT commands - 'Run: `<start command>`', 'Test: `<test command>`', build and deploy steps, and where it runs in production. A new teammate should go from clone to running using only this note. Every URL/port you print must be the one THAT START COMMAND actually serves - resolve it from the launch profile / config the command uses (e.g. `dotnet run` uses the first "Project" profile in launchSettings.json; an IIS Express port belongs to Visual Studio, not to `dotnet run`).
   - Config & Environment (folder "Setup", icon "🔑"): a table of every env var / config key - name, required or optional, what it does, where it is read. Mark secrets as <secret>; never paste real values.
   - Features (folder "Reference", folderIcon "📚", icon "💡"): what the product actually DOES, feature by feature - a table with: feature, what it does in one plain sentence, who uses it (end user / admin / other services), the entry-point file(s), and the main classes/services/entities behind it. This is the note that answers "what am I even looking at" - write it from the routes/screens/handlers that exist, not from the README's ambitions.
   - Code Map (folder "Reference", icon "🗺"): the guided tour of the code for someone who has NEVER worked in this stack - per top-level project/package: one intro sentence, then a TABLE of its sub-folders (folder | what lives there | key types), then its dependency rule as a ```callout-info ("may depend on X, must NOT depend on Y - and why, when the code enforces a direction"). After the projects: ONE real request/operation traced end to end as a NUMBERED list naming the actual files and classes ("browser hits /basket -> src/Web/Controllers/... -> ..."), and a "to add or change X, you will touch these files" section as a table for the 2-3 most common kinds of change.
   - Conventions (folder "Reference", icon "📏"): the decisions the code already follows - architecture pattern + folder layout, auth/session approach, error shape, naming conventions, hard limits. Describe what IS, not what should be.
   - Data Model (folder "Reference", icon "🗄"): for a SQL database you MUST use the create_diagram_note tool with kind "erd" and DBML code of the real tables - it renders as a live tables-and-relations canvas the team can edit; a ```dbml``` code block in a doc note renders flat and dead. For NoSQL use a regular create_note with the real collections + document shapes. Base it on the actual schema/migrations, not a guess.
   - API Reference (folder "Reference", icon "🔌"; ONLY if the project exposes an API/events): for an HTTP API you MUST use the create_api_note tool - never create_note - with a COMPLETE OpenAPI 3 YAML of the real endpoints: request/response schemas, worked example values, error responses, tags per resource, and the auth scheme. It renders as a Swagger-style reference the team can edit endpoint-by-endpoint; a markdown API note cannot. For non-HTTP contracts (events, CLI, library interfaces) use a regular create_note describing each one.
   - Architecture (folder "Diagrams", folderIcon "📊", icon "🏗"): you MUST use the create_diagram_note tool with kind "flowchart" and Mermaid code of the real systems and how they connect (subgraph zones per service, @logos:<tech> icons for concrete technologies (cloud PRODUCTS use their product set instead: gcp:<product> for GCP - e.g. gcp:google-kubernetes-engine, gcp:artifact-registry - and logos:aws-<service> for AWS), labels ONE short line). NEVER put an architecture or flow diagram in a mermaid code block inside a doc note - the diagram canvas lays out zones and renders real icons and stays editable; a code block renders it flat with the icon syntax showing as raw text.
   - Code Architecture (folder "Diagrams", icon "🧩"): you MUST use the create_diagram_note tool with kind "flowchart" - the inside-the-code companion to Architecture (which stays at the system level). One zone (subgraph) per layer or top-level module, nodes at COMPONENT granularity (a group of files with one job: "Razor Pages", "MediatR handlers", "IRepository<T>", "EF DbContexts") - NEVER one node per class, stop before the diagram needs more than ~15 nodes. Every edge is a real call or dependency that exists in the code, labeled with its mechanism ("DI interface", "MediatR", "HTTP + JWT", "props") - and every edge connects two component NODES, not two subgraph ids (zone-level edges exist on the canvas, but "which component in A calls which component in B" is exactly the information THIS diagram carries), so pick the concrete pair (the HTTP client node to the endpoint node, the repository node to the DbContext node). First identify the pattern the code ACTUALLY follows - MVC, MVVM, Clean/Onion, Hexagonal (ports and adapters), layered n-tier, feature-sliced / feature-based (common in React), event-driven, plain scripts - name it in the diagram title node and let the zones mirror that pattern's own vocabulary. Judge the pattern from imports and folder structure, not from what the README claims; if the code follows no named pattern, diagram the real structure and say "no formal pattern" instead of forcing a label.
   - Key Flows (folder "Diagrams", icon "🔁"; only if the project has nontrivial runtime flows): 1-3 ```mermaid``` sequenceDiagram blocks in a REGULAR note (create_note) for the flows that matter most - actors, calls, and what can fail. Sequence diagrams are the ONE kind that stays as a mermaid block: the canvas has no sequence mode, and the mermaid renderer is the accurate one for them.
   - Known Gaps (folder "Reference", icon "⚠"): TODOs, tech debt and sharp edges you can SEE in the code. Each gap is its OWN callout block - ```callout-error for security holes (hardcoded secrets, auth bypasses), ```callout-warning for everything else - first line a bold title, then what/where, then "Why it matters: ...". Never checkboxes - this is a warning label, not a work list.
3. Now that every note exists, create the index note titled "Start Here" (session "Docs", NO folder, icon "👋") - this note is NOT optional, it is the front door: first line "# <the real project name>", a short paragraph on what it is, then a "## Read in this order" NUMBERED LIST (never a table), one line per note as "[[Note Title]] - what it answers", ordered the way a new teammate should read them, plus one line per SKIPPED note saying why it does not exist here.
4. Cross-link: whenever one note mentions an endpoint, entity, or decision defined in another, write [[That Note Title]] at first mention.
5. Keep every note SKIMMABLE - these notes render as RICH BLOCKS, so use the block that carries the meaning instead of prose:
   - Any list where every item has the same fields (endpoints, env vars, folders, features) is a markdown TABLE, never bullets.
   - Any warning, hard rule, or gotcha is a ```callout-warning / ```callout-error fence; any "good to know" aside is ```callout-info or ```callout-tip. The fence body is plain markdown.
   - Commands, schema, config and payloads are fenced code blocks with the right language tag.
   - More than 5 consecutive plain bullets or a paragraph over ~5 lines means you picked the wrong block - restructure.
   Use only keyboard characters: "->" not an arrow glyph, "-" not an em-dash, "..." not an ellipsis character.
6. Write for a reader who has never used this stack: the FIRST time a stack-specific concept appears in a note (DbContext, goroutine, Blazor, middleware, ...), add a plain-words gloss in the same sentence ("AppIdentityDbContext (the class through which EF Core talks to the identity database)"). Once per note is enough - do not re-explain on every mention.

Be accurate to the code as it exists now. When something is genuinely unclear from the code, say so in the note ("unclear from code: ...") rather than guessing.

Update the PugBase "Docs" session for this repo so it matches the code as it is now. Documentation only - do not change any code. The PugBase MCP server's instructions carry the full procedure; follow them, and tell me exactly which notes changed - or that everything was already in sync. If you cannot see the PugBase tools, STOP and tell me to connect the MCP server instead of improvising.