Insert a short 'Documentation' section between the GitHub Actions
status badges and 'Construction et deploiement'. The new section
names the doc/ directory, links to doc/README.md (the new index),
and to Architecture.md (the architecture root).
The two limitations (centralised PayPal collection, no payroll)
were grammatically fine but mixed model statement and technical
implementation in a way that obscured each.
Split into two bullets, each with a bold topic label:
- 'Collecte centralisée' names the fact (single PayPal account,
third-party status) and the technical reason (only credentials
configured).
- 'Pas de gestion de paie' restates the unit-payment-only limit
in present tense.
Original phrasing ('Elle ne prendra pas en charge, du moins pas
encore, ni … ni …') was wordy and used a future tense ('ne
prendra pas') for a limitation that is already observable in
the current codebase.
Keep the semantic content unchanged (no claim about roadmap
status) — this commit only restates the existing limitation in
present tense and removes the 'du moins pas encore' hedge.
Code review: grep for Stripe|Adyen|Braintree|PSP across src/
returns zero hits. PayPal is the only payment service provider,
and the integration is built on SetExpressCheckout (NVP/SOAP),
not the PayPal REST API PayPal has been recommending since 2017.
Rewrite the bullet as:
- explicit naming of the only PSP and the absence of any other;
- clarification that the deprecation is PayPal's, not ours;
- honest statement that no migration is planned.
Code review confirms there is no application-level handling for
post-prestation claims: grep for Reclamation|Litige|Complaint|
Dispute across src/ returns zero hits. No route, no controller,
no model. The only mention of conciliation is in the design
exploration doc, scheduled for Jalon 5.
Replace 'toute reclamation necessitera l'intervention d'un
systeme auxiliaire (un processus humain?)' with an explicit
statement of the absence, the Jalon 5 target, and a link to
doc/ddd-exploration-2026-06-14.md where the design lives.
Code review of HairCutCommandController confirms the previous
bullet ('Dans le cas de l'avance ... aucune annulation de la
prestation n'est supportée') understated the gap:
- Only the client side has any surface area
(ClientCancel GET + ClientCancelConfirm POST).
- ClientCancelConfirm does _context.HairCutQueries.Remove(query)
followed by SaveChangesAsync — no PayPal refund, no logic
distinguishing arrhes vs avance.
- There is no PerformerCancel / ProviderCancel action anywhere
in the codebase (grep -rn PerformerCancel|ProviderCancel
returns nothing).
- No Refund* call exists anywhere in src/ (grep -rn Refund
returns nothing).
The README's earlier promises (arrhes +20% on provider cancel,
arrhes lost on client cancel, advance non-cancellable) were
never implemented. PayPal flow has never been end-to-end tested.
Replace with a two-clause statement: current state (partial,
no refund, untested), target (RefundTransaction wired + full
workflow), link to ROADMAP.md.
The original bullet ('à une commande, une prestation') was
syntactically broken (ellipsis without a verb, doubled 'à') and
said nothing about the multi-party target.
Replace with a two-clause statement that names both the current
limitation and the planned target, with a link to ROADMAP.md
where the multi-party direction is documented.
Bullet now reads:
Aujourd'hui : une prestation par commande, sur un axe
client → prestataire unique, sans sous-traitance.
Cible roadmap : montages multi-parties (plusieurs clients
et/ou plusieurs fournisseurs collaborant autour d'un même
projet, avec sous-traitance validée par le client) —
voir la ROADMAP.
The original phrasing 'Ni le client ni le prestataire ne sont
anonymes pour l'application, ils sont même formellement
authentifiés, au moment de leur accord pour une première
facturation en ligne, à l'occasion' was contradictory: the
paragraph asserted the users are not anonymous, then anchored
the formal authentication to the moment of the first billed
act, which a careful reader could parse as 'they ARE anonymous
until then'.
Rewrite as two distinct statements:
- both parties are nominatively identified and authenticated
from the moment they register;
- a stronger verification step is triggered at the first
billable act (light KYC on the client side, professional
profile validation on the provider side).
While here, fix a small grammar slip in the second bullet
('de la validation' -> 'lors de la validation').
The 'professionals are third parties' bullet was carrying an
inline 'TODO Aucune edition de fiche de paye …' mid-sentence,
which is hard to scan and mixes two distinct concerns
(commissioning / payout). Split into two bullets and tidy the
francais:
- 'edition' -> 'édition'
- 'payments unitaires' -> 'paiements unitaires'
- 'Seul … le sont' -> 'Seuls … le sont' (subject agreement)
The previous commit's table incorrectly stated that
appsettings-org.Development.json is committed; it is in fact
matched by .gitignore (appsettings-*.*.json), so each developer
generates their own from the template documented here. Fix the
table and clarify the role.
The localhoist typo that lived in the previously-shown blob is
not versioned, so it does not propagate via git.
The Yavsc.Org service reads appsettings-org.json at runtime, but the
contrib/Makefile renames that file to appsettings-org-dist.json right
before deploying to $(BASEAPPDIR), so first-time operators have to
copy the dist variant back to appsettings-org.json on the server and
fill in their actual values. None of that was documented; this commit
adds a Fichiers de configuration d'Yavsc.Org section under Paramétrage.
The section also notes that Site.ExternalUrl is now consumed by the
IdentityServer EF seed (added in the previous PostIt PKCE commit) to
authorize a RedirectUri for the 'postit' OIDC client, so PostIt can
be embedded in a Yavsc.Org web page without redirect_uri mismatch.
Side note: the appsettings-org.Development.json template points at
'https://localhoist:5001' which looks like a typo for 'localhost'.
Flagged in the README so it doesn't get copy-pasted into a new
environment as-is.
* input.css: refabrication des feuilles de style : la feuille des
champs de formulaire.
* CircleMember.cs: un membre de cercle est un nom d'utilisateur
associé au cercle d'un autre utilisateur.
* ICircle.cs: Définit l'interface d'un cercle:
un cercle est identifié par un entier long,
il a un possesseur.
* Makefile: utilise le fichier de conf généré pour débugger.
* NpgsqlContentProvider.cs: bug fix
* README.md: maj priorités
* AccountController.cs: implémente une méthode de l'API pour ajouter
un utilisateur au cercle
* links.css: Corrige la couleur du boutton de validation des
formulaire de classe `ActionLink`
* style.css: refabrication: importe la nouvelle feuille de style des
champs de formulaires
* style.css: nettoyage du thème sombre
* style.css: nettoyage + section principale (`main`) centré
* FrontOfficeController.cs: Repositionne la route vers le devis à
do/Estimate
* YavscHelpers.cs: corrige ma ré-écriture des helpers html ActionLink
* App.master: formattage du code source
* AppAdmin.master: synchronisation avec la page maître,
beaucoup de changements dans cette page maître pour les
administrateurs:
* prend en charge les côtes d'article
* utilise les fontes de caractère de la page pour les lien action
* prend en charge les zones de formulaire masquable.
* NoLogin.master: synchronisation avec la page maître
* Performer.ascx: WIP permet d'ajouter un préstataire à un de ses
cercles.
* YourEstimates.aspx: corrige un lien cassé
* Yavsc.csproj: mise à niveau Npgsql,
renommage Estimate
* packages.config: mise à niveau de la bibliothèque Npgsql (pilote
d'accès à la base de donnée)
* CircleBase.cs: un objet cercle basique implémente l'interface d'un
cercle.
* PerformerProfile.cs: s'assure que le nom d'utilisateur utilisé n'est
pas vide.
* IIdentified.cs: doc xml
* UserNameBase.cs: l'objet base de type "nom d'utilisateur" implémente
l'interface générique
d'un identifié, par une chaine de caractère.
* YavscModel.csproj: reference les nouvelles definitions :
* un membre de cercle
* l'interface d'un cercle
* MainClass.cs: format du code
* YavscClient.csproj:
* Estimate.aspx: refabrication