onboarding-existing-codebaselisted

# Onboarding an existing codebase Learn the repo from its evidence (manifests, CI, scripts, tests), not from guesses. Then write down what you learned, so every later session starts oriented. **Read-only until the map is done.** ## 1. Map - **Stack and runtime:** `package.json`, lockfiles, `pyproject.toml`, `go.mod`, `Cargo.toml`, `*.csproj`/`global.json`, `build.gradle(.kts)`/`libs.versions.toml`, `Podfile`/`Package.swift`, `.nvmrc`, `.tool-versions`, Dockerfiles. - **Real commands:** the CI config (`.github/workflows`, `.gitlab-ci.yml`, Jenkinsfile), `Makefile`/`justfile`, package scripts, the Gradle wrapper, Xcode schemes. **CI is the truth**; the README may be stale. - **Structure:** entry points, modules and layers, and where business logic lives. Note generated code, vendored code, migrations and anything else that must not be hand-edited. - **Conventions:** formatter and linter configs, commit style (`git log --oneline -30`), branch naming, test layout and naming, error-handling and logging patterns. - **Existing agent files:** AGENTS.md, CLAUDE.md, `.cursor/rules`, `.github/copilot-instructions.md`. Reuse them; don't duplicate them. - **Risky areas:** payments, auth, data migrations, fiscal or device integrations, anything without tests. On a large repo, dispatch `Explore` agents per area in parallel (dispatching-parallel-agents), then merge their findings. ## 2. Prove the commands Run install, build, test and typecheck/lint exactly as CI does. Record which ones