Cycle de vie d'une propriété

Extrait du domain map API, qui était chargé dans chaque session agent. La rule garde l'index module → contexte ; le détail vit ici, à côté du code.

draft -> published -> funding -> cloture -> echeancier -> remboursements -> fin

Subtilites par transition :

Publication (draft -> published) : - Cree physiquement les briques en base (pas juste un changement de statut) - Schedule les jobs d'investissement automatique (atomique avec la publication) - Prerequis : SPV Lemonway valide, funding dans 2h minimum, au moins 2 images

Edit projet (draft / published) : - projectOwnerPresentationId : posé à la création, patchable ensuite via PATCH .../edit/draft et .../edit/published (présentation existante ; 404 si inconnue). idtlt droppe les clés hors schéma, donc omettre le champ du validator = 200 sans écriture

Cloture funding -> flux financiers post-funding : Les transferts de fees sont des operations manuelles separees, pas automatiques : - Funding fees : SPV -> compte origination Bricks (P2P) - Fiducie fees : SPV -> compte principal Bricks (P2P) - Fonds au porteur : SPV -> compte bancaire porteur (withdraw, pas P2P)

Max transferable au porteur = montant finance - funding fees TTC - fiducie fees TTC - sequestre - budget construction. Plusieurs transferts partiels autorises, cumul tracke.

Statut projet (derive, pas stocke) : - funding-ongoing : funding pas encore cloture - funding-failed : funding cloture en echec - reception-by-project-owner-pending : funding success + fonds pas encore recus par le PDP (receivedByProjectOwnerAt null) - repayment-ongoing : funding success + fonds recus par PDP + pas de remboursement final - repayment-finished : remboursement final execute (finalRepaymentAt set)

La date de reception des fonds par le PDP (receivedByProjectOwnerAt) est set par l'Espace Financement via l'API quand le projet passe en statut running : jamais dans le futur, et une seule fois. Le notaire, auteur de l'acte, est le seul chemin autorise a la corriger ou l'annuler (PUT /notary/projects/:projectId/funding-received-by-project-owner-date, null droppe la cle JSONB et rewind repayment-ongoing → reception-by-project-owner-pending) ; meme verrou payouts SPV que la correction. Le refus des dates futures reste partage. Elle est prerequise pour approuver les tirages travaux (construction budget).

Revente royalty / marketplace : create et purchase refuses si isMarketplaceAllowed est false (colonne properties). L'acceptation d'une offre saleType = 'total' le bascule ; le BO Projets peut aussi le basculer (annule les pending). Un dernier partiel qui met le prix a 0 pose completedAt et isMarketplaceAllowed = false dans le meme event. Les reserved en cours continuent. Le listing public masque les pending ; le vendeur les voit encore pour les annuler. Script 01 refuse un brick price royalty a 0 sans donnees de revente, refuse toute hausse vs le dernier brick_prices, et n'autorise une revente finale (totale ou derniere partielle) que si isMarketplaceAllowed est deja false et qu'il n'existe plus aucun deal pending ni reserved — fermer le marche dans le BO d'abord, attendre les P2P reserved, puis lancer le 01. Script 02b calcule computeHamiltonPayout (plus grand reste, ex aequo par investorId, somme exacte) avant d'ecrire property_resale_payout. Le plancher 1 ct/brique et le check de somme (allocation vs Excel, pas les WT du run) tournent avant l'insert. Abort si doublon Excel parmi les lignes revente royalty remplies — clé propertyId après enrich (deux businessId peuvent résoudre le même projet). brickCountByProject est la somme de la même Map investisseur→bricks que Hamilton.