map-product-systemlisted

# Map Product System Build a shared model of how the product works from user intent to system outcome. Accept raw, conversational, or mixed-language explanations directly; do not require an optimized prompt first. ## Operating principles - Preserve the product intent before adding structure. - Distinguish **Known**, **Inferred**, **Proposed**, and **Unknown**. Never present an invention as an existing fact. - Seek traceability, not a long feature wishlist. A system is well mapped when journeys, capabilities, decisions, data, actors, states, and failure handling connect end to end. - Separate product-wide foundations from tenant-specific behavior. - Make consequential design recommendations. Explain the tradeoff briefly instead of hiding behind an unranked option list. - Match depth to the request. Do not force a full architecture report onto a narrow question. - Run broad coverage checks internally; expose only the structure, gaps, and evidence that affect the user's decision unless an exhaustive artifact is requested. ## Choose the job 1. **Discover** — turn an early or incomplete idea into the first coherent system model. 2. **Audit** — inspect existing code, documents, diagrams, or behavior and identify gaps, contradictions, and accidental architecture. 3. **Evolve** — place a new feature or mandate into the existing model and trace its downstream effects. When sources exist, inspect them before proposing structure. Treat repository behavior and current documents as