repo-onboarding-context-maplisted

# Repo Onboarding & Context Map ## Purpose Inspect an unfamiliar repo and produce a durable context map so future sessions know the project's structure, commands, protected paths, and risky system boundaries without re-investigating each session. ## When to invoke - First-time installation of Fusebase Flow into an existing repo - Operator says "I'm picking up this repo" / "what's in this codebase?" / "set up flow here" - After a major structural change (large rename, monorepo split, framework swap) - When `docs/specs/repo-context.md` is missing or older than 90 days ## Do not invoke when - A current `repo-context.md` exists and the repo hasn't changed structurally - Operator is asking a code-specific question — use code-review or normal investigation - A spec is in flight — don't pivot to onboarding mid-ticket ## Required inputs | Input | Where it lives | If missing | |---|---|---| | Repo root | git root | Stop; ask operator to confirm working directory | | Package/project files | `package.json`, `pyproject.toml`, `Cargo.toml`, etc. | Note "no manifest detected"; describe based on file extensions only | | Existing READMEs | `README.md`, `docs/`, etc. | Note absence; flag as Phase-4 onboarding gap | | CLI edition map, for this edition | `docs/fusebase-cli-edition.md` | Continue with generic repo map, but mark CLI provider asset mapping unknown | ## Procedure 1. List repo root files (top level only). Identify project type (Node/Python/Go/Rust/etc.) and frontend/backen