# Cadrage: Pre-Analysis Reference

> Reference for step-01-cadrage.md — silent pre-analysis to PREPARE the interactive conversation.
> **This file does NOT replace the conversation — it prepares it.**

## Purpose

Before engaging the client, the AI silently analyzes the `{feature_description}` to:
1. Understand what was said (extract explicit requirements)
2. Detect what was NOT said (identify shadow zones to challenge)
3. Prepare targeted questions (not generic ones)
4. Pre-identify modules, sections, and resources

**The output of this pre-analysis is INTERNAL ONLY.** It is never shown directly to the client — it feeds the reformulation (Phase 2) and challenge questions (Phase 3).

## Pre-Analysis Rules

### 1. Problem Type Inference

Derive the problem type from `{feature_description}` keywords:

```yaml
problem_type:
  → Keywords "remplacer", "migrer", "existant" → "replace" (existing tool to replace)
  → Keywords "automatiser", "manuel", "processus" → "automate" (manual process to automate)
  → Keywords "centraliser", "dispersees", "eparpillees" → "centralize" (data scattered across systems)
  → Default (new tool) → "new_tool" (no system in place)
```

### 2. Explicit Module/Feature Extraction

Extract functional areas explicitly mentioned in the description:

```yaml
detected_modules:
  → For each distinct functional area mentioned:
    - name: "{PascalCase module name}"
    - description: "{what the user said about it}"
    - detected_sections: ["{inferred sections based on description}"]
    - detected_resources: ["{inferred resources}"]
```

### 3. Shadow Zone Detection (CRITICAL)

> **Shadow zones are the most valuable output of pre-analysis.**
> They become the challenge questions in Phase 3.

For EACH detected module, check for missing information:

| What to check | Shadow zone if missing | Challenge question pattern |
|--------------|----------------------|--------------------------|
| Stakeholders | Who uses this module? | "Who interacts with {module} daily? Only {mentioned role} or also managers, admins, external users?" |
| Cardinality | Relationships stated as fact | "You said {A} is 1:1 with {B}. Can {A} exist without {B}? Can {B} have multiple {A}?" |
| Granularity | Level of detail unclear | "What granularity for {feature}? Day, half-day, hour? Single entry or batch?" |
| Reports | Mentioned but not detailed | "Which reports exactly? For whom? What format? How often?" |
| Validation workflow | Actions without approval | "Does {action} require approval? Who validates? What happens if rejected?" |
| Edge cases | Only happy path described | "What happens when {something goes wrong}? When data is incomplete? When two users do it simultaneously?" |
| Non-functional | Security, performance, compliance | "Is there sensitive data (GDPR)? Expected concurrent users? Compliance requirements?" |
| Integration | Standalone or connected | "Does {module} need to exchange data with external systems? Import? Export? API?" |

### 4. Domain-Specific Anticipation Patterns

When the problem domain is identified, pre-load domain-specific needs:

| Domain keywords | Anticipated needs (suggest in Phase 4) |
|----------------|---------------------------------------|
| RH, employes, personnel | Contrats, competences, organigramme, RGPD, conges, jours feries, calendriers |
| Temps, activites, absences | Granularite saisie, validation manageriale, soldes conges, compteurs, export paie |
| Ventes, commandes, clients | Devis, factures, pipeline, relances, taux conversion, segments client |
| Stock, inventaire, produits | Categories, fournisseurs, seuils reapprovisionnement, mouvements, valorisation |
| Projets, taches, planning | Jalons, ressources, Gantt, charge, budget, risques projet |
| Tickets, support, incidents | SLA, escalade, base connaissances, satisfaction, priorites |
| Documents, GED | Versionning, workflows validation, templates, OCR, archivage legal |

### 5. Section & Resource Pre-Identification

For each detected module, anticipate sections (Level 4) and resources (Level 5) based on feature type:

| Feature type | Sections (functional zones) | Resources (in list section) | Detail page tabs |
|-------------|---------------------------|---------------------------|------------------|
| data-centric | list | {entity}-grid, {entity}-filters, {entity}-form | Infos, {relations} |
| workflow | list, approve | {entity}-grid, {entity}-filters, {entity}-form, approval-queue | Infos, {relations}, Historique |
| reporting | dashboard | summary-chart, kpi-cards, export-panel | — |
| integration | list | sync-status-grid, config-form, log-viewer | Infos, Config, Logs |

> **RULE:** Sections = functional zones only (`list`, `dashboard`, `approve`, `import`, `rapport`, `planning`).
> `create`/`edit` = separate pages with own URL routes (`/create` and `/:id/edit`). `detail` = tabbed page reached by clicking a row in `list`.

**Always check:** Does the user's description imply additional functional sections? (e.g., "reports" → `dashboard`, "calendar view" → `planning`, "approval workflow" → `approve`)

## Output Format (Internal Only)

```yaml
pre_analysis:
  problem_type: "new_tool|replace|automate|centralize"
  detected_modules:
    - name: "ModuleName"
      description: "What the user said"
      detected_sections: ["list", "detail", "create"]
      detected_resources: ["entity-grid", "entity-form"]
  shadow_zones:
    - topic: "Cardinality Employee-User"
      why_it_matters: "1:1 assumption may not hold for temp workers"
      challenge_question: "Can a user be linked to multiple employee records?"
    - topic: "Report granularity"
      why_it_matters: "Reports mentioned but not specified"
      challenge_question: "Which reports exactly? For whom? What format?"
  anticipated_suggestions:
    - suggestion: "Leave balance management"
      justification: "Time tracking without leave balances is incomplete"
      module: "TimeTracking"
    - suggestion: "GDPR compliance module"
      justification: "HR data is personal data under GDPR"
      module: "Employees"
```
