Phase 1 — Étapes et soumission¶

Référence pour le parcours Présentation → Documents → Emprunteur (project owner company) avant passage en analyse.

Deux phases, deux sources de statut¶

Phase	Étapes (UI PDP)	Source du statut affiché
Phase 1	`presentation`, `documents`, `borrower`	API `GET /projects` → `steps` (persisté par entité)
Phase 2	`analysis`, `offer`, `collect`, `signature`	API `GET /projects` → `steps` via `compute-project-financing-request-steps.ts`. L'app PDP lit ces statuts tels quels (`getFunnel`)

Macro-statuts (ownerProjectStatusSchema) : draft, in-analysis, blocked, offer, finalization, completed, rejected, canceled.

Phase 2 côté API — compute-project-financing-request-steps.ts :

steps.analysis : dérivé du macro-statut (unavailable en draft / canceled ; draft en in-analysis / blocked / rejected ; completed dès offer+).
canceled verrouille toute la phase 2 (analysis, offer, finalization, signature → unavailable). La phase 1 garde ses statuts acquis : ils disent ce que le porteur avait rempli, et l'API refuse déjà toute écriture hors draft.
steps.offer : dérivé du macro-statut (draft en offer ; completed dès finalization).
steps.finalization et steps.signature : finalization laisse la finalisation draft et la signature unavailable. POST …/finalization/complete passe le dossier en signature : finalisation completed, signature draft. Projet completed → les deux completed. Une société déjà finalized ne ferme pas la finalisation d'un autre dossier : il reste en finalization tant qu'il n'a pas conclu l'étape.
POST …/finalization/complete renvoie { status, steps } (comme submit et accept-offer) pour que le front ouvre la signature sans refetch.
L'app PDP mappe la clé API finalization → libellé UI collect.

Phase 1 — statuts indépendants¶

Chaque étape possède son propre status (unavailable | draft | completed). Aucune cascade : compléter ou rééditer une étape ne re-verrouille pas les autres.

Logique : compute-project-financing-request-steps.ts.

Présentation¶

Toujours draft tant que non complétée (création auto au premier GET).
PUT …/presentation/:id/complete → completed et ouvre Documents (documentsStep.status : unavailable → draft, idempotent).

Documents¶

Démarre unavailable ; s'ouvre en draft quand la présentation est complétée une première fois.
Checklist expectedDocuments (9 clés) : guide UX, pas bloquante pour PUT …/documents/complete.
Complétion : au moins un fichier uploadé → documentsStep.status = 'completed'.
Toute modification (upload, commentaire, toggle checklist) après complétion repasse l'étape en draft.

Emprunteur (project owner company)¶

Statut = completed dès que la société est completed ou finalized ; sinon draft si la step est ouverte, unavailable sinon. Une société déjà validée ferme donc l'étape des dossiers qui la partagent.
GET …/project-owner-company crée une société vide en draft si absente.
PUT …/project-owner-company/:id/complete valide les champs requis et verrouille la société.
Facultatif pour la soumission : seules présentation + documents sont requises. La step s'ouvre deux fois : en phase 1 dès les documents completed, et — si le porteur l'a sautée — à l'acceptation de l'offre. Ailleurs elle est fermée, et l'écriture suit exactement cette ouverture (isBorrowerEditable) — voir compute-project-financing-request-steps.ts et project owner company.
isBorrowerStepDeferred : posé à true à la soumission si la société est absente ou encore draft (POST /submit). Immutable ensuite — compléter la société plus tard ne le remet pas à false. Exposé côté API sur steps.borrower.isDeferred ; l'app PDP déplace l'étape emprunteur en phase 2 (après offer) quand le flag est actif.

Soumission en analyse¶

Endpoint dédié : POST /project-financing-request/:projectId/submit (project-submission.service.ts).

POST /submit (projet draft)
  → lock projet + relecture présentation
  → canSubmitToAnalysis(presentation completed, documents completed) ?
       oui → status = in-analysis + notify Projet Analyse + steps recalculés
       non → 409 project-phase-one-incomplete

Prérequis : presentation.status === 'completed' et documentsStep.status === 'completed'. La société n'est pas requise.

Erreur	HTTP	Cause
`project-not-found`	404	Projet inconnu
`project-not-draft`	409	Déjà soumis
`project-phase-one-incomplete`	409	Présentation ou documents pas `completed`

Effets :

Le projet quitte draft : documentsStep n'existe plus sur le JSON (discriminated union).
Présentation n'est plus éditable (ProjectEditabilityService → project-not-editable).
La société sautée n'est plus éditable pendant l'analyse : c'est l'acceptation de l'offre qui la rouvre, et la compléter fait alors passer le dossier en finalization.
Les documents restent uploadables (hors guard d'éditabilité phase 1).

Côté app PDP : l'écran emprunteur expose un flux skip (skipAction → POST /submit sans compléter la société) ou un flux submit (save + PUT …/project-owner-company/complete puis POST /submit).

Phase 2 — stepper app PDP¶

getFunnel lit project.steps depuis l'API (y compris signature). Guards, progression et FinancingRequestLayoutUI consomment ce helper unique — plus de dérivation locale depuis project.status. isProjectFinished = signature completed.

La barre d'étapes affiche phase 1 ou phase 2 selon l'URL courante (PHASE_1_STEPS / PHASE_2_STEPS, cette dernière inclut signature). Les étapes unavailable ne sont pas cliquables ; en phase 2, les étapes déjà completed sont aussi désactivées (lecture seule).

Nommage : le contrat API utilise finalization comme clé d'étape et macro-statut ; l'app PDP l'affiche comme collect (collecte de fonds). Détail endpoints et upload KYB : project-finalization.md. Voir aussi data-reference.md pour la cible complète (offre signée, documents, etc.).

Éditabilité après soumission¶

Ressource	Éditable après soumission ?
Présentation	Non (`draft` uniquement)
Société emprunteuse	Éditable quand la step est ouverte : documents `completed` en phase 1, ou offre acceptée (voir project owner company)
Fichiers documents	Oui (upload, commentaires)
Checklist onboarding	Non (`draft` uniquement)
Compléments analyse	Oui en `blocked` (toggle + validate)