docs: add development and security links to README
This commit is contained in:
@@ -0,0 +1,30 @@
|
||||
# Contribuer à ZEN
|
||||
|
||||
Le développement se fait sur un serveur Git privé. GitHub est le point d'entrée pour les contributions externes. Le code source y est mis à jour automatiquement.
|
||||
|
||||
---
|
||||
|
||||
## Signaler un bug
|
||||
|
||||
Ouvrir une Issue GitHub avec :
|
||||
- Le comportement observé
|
||||
- Le comportement attendu
|
||||
- Les étapes pour reproduire
|
||||
- La version de `@zen/core` utilisée
|
||||
|
||||
## Proposer une idée
|
||||
|
||||
Utiliser l'onglet Discussions GitHub. C'est l'endroit pour les idées ouvertes, les questions d'architecture ou les suggestions de fonctionnalités.
|
||||
|
||||
## Soumettre une correction de code
|
||||
|
||||
1. Forker le dépôt GitHub
|
||||
2. Créer une branche depuis `main` : `git checkout -b fix/description-courte`
|
||||
3. Lire [GUIDE.md](./docs/dev/GUIDE.md) et [REDACTION.md](./docs/dev/REDACTION.md) avant de commencer
|
||||
4. Ouvrir une Pull Request avec une description claire du problème résolu
|
||||
|
||||
Les PRs approuvées sont intégrées dans le dépôt principal. GitHub est ensuite mis à jour automatiquement.
|
||||
|
||||
## Signaler une faille de sécurité
|
||||
|
||||
Ne pas ouvrir d'issue publique. Voir [SECURITY.md](./SECURITY.md).
|
||||
@@ -19,3 +19,9 @@ Un CMS Next.js construit sur l'essentiel, rien de plus, rien de moins.
|
||||
## Démarrage
|
||||
|
||||
Pour les instructions d'installation et de configuration, voir [INSTALL.md](./docs/INSTALL.md).
|
||||
|
||||
## Développement
|
||||
|
||||
Pour contribuer au projet, voir [CONTRIBUTING.md](./CONTRIBUTING.md) et [DEV.md](./docs/DEV.md).
|
||||
|
||||
Pour signaler une faille de sécurité, voir [SECURITY.md](./SECURITY.md).
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
# Politique de sécurité
|
||||
|
||||
## Signaler une vulnérabilité
|
||||
|
||||
Ne pas ouvrir d'issue publique pour une faille de sécurité.
|
||||
|
||||
Envoyer un rapport à : **security@hyko.cx**
|
||||
|
||||
Inclure dans le rapport :
|
||||
- Une description de la vulnérabilité
|
||||
- Les étapes pour la reproduire
|
||||
- L'impact potentiel
|
||||
- Une suggestion de correctif, si possible
|
||||
|
||||
On répond sous 48 heures. On développe le correctif de façon confidentielle avant toute divulgation publique.
|
||||
|
||||
## Divulgation publique
|
||||
|
||||
Une fois le correctif publié, on peut divulguer la vulnérabilité. Le délai entre le signalement et la divulgation dépend de la complexité du correctif. Il ne dépasse pas 90 jours, sauf entente contraire.
|
||||
+115
@@ -0,0 +1,115 @@
|
||||
# DEV
|
||||
|
||||
## Standards
|
||||
|
||||
On suit ces deux guides :
|
||||
|
||||
- [GUIDE.md](./dev/GUIDE.md) : conventions générales de rédaction et de structure
|
||||
- [REDACTION.md](./dev/REDACTION.md) : règles de style, ton et formatage
|
||||
|
||||
---
|
||||
|
||||
## Structure du projet
|
||||
|
||||
```
|
||||
src/
|
||||
├── cli/ # Scripts CLI : zen-db, zen-setup
|
||||
├── core/ # Briques techniques : database, api, email, storage, cron, pdf, toast, payments
|
||||
├── features/ # Features utilisateur : auth, admin, provider
|
||||
├── modules/ # Modules métier : posts, invoice, nuage…
|
||||
└── shared/ # Composants, lib et styles partagés
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Publier le package
|
||||
|
||||
Le package `@zen/core` est publié sur le registre npm à `https://git.hyko.cx`.
|
||||
|
||||
### 1. Configurer l'authentification
|
||||
|
||||
Créer un token d'accès dans Gitea (Settings → Applications → Generate Token), puis l'enregistrer localement :
|
||||
|
||||
```bash
|
||||
npm config set //git.hyko.cx/api/packages/zen/npm/:_authToken TOKEN
|
||||
```
|
||||
|
||||
Remplacer `TOKEN` par le token généré.
|
||||
|
||||
### 2. Build et publish
|
||||
|
||||
```bash
|
||||
npm publish
|
||||
```
|
||||
|
||||
Le script `prepublishOnly` lance automatiquement le build avant la publication.
|
||||
|
||||
---
|
||||
|
||||
## Intégrer une Pull Request GitHub
|
||||
|
||||
Le dépôt GitHub est un miroir en lecture seule. On intègre manuellement les PRs de la communauté depuis Gitea.
|
||||
|
||||
### 1. Récupérer la branche du contributeur
|
||||
|
||||
```bash
|
||||
git fetch https://github.com/<contributeur>/core <branche>
|
||||
```
|
||||
|
||||
Par exemple :
|
||||
|
||||
```bash
|
||||
git fetch https://github.com/jdupont/core fix/auth-token-expiry
|
||||
```
|
||||
|
||||
### 2. Inspecter les changements
|
||||
|
||||
```bash
|
||||
git log FETCH_HEAD --oneline
|
||||
git diff main...FETCH_HEAD
|
||||
```
|
||||
|
||||
### 3a. Appliquer avec cherry-pick (recommandé pour un ou quelques commits)
|
||||
|
||||
```bash
|
||||
git cherry-pick <hash-du-commit>
|
||||
```
|
||||
|
||||
Pour plusieurs commits consécutifs :
|
||||
|
||||
```bash
|
||||
git cherry-pick <hash-début>^..<hash-fin>
|
||||
```
|
||||
|
||||
### 3b. Appliquer avec merge (pour une branche entière)
|
||||
|
||||
```bash
|
||||
git checkout -b integration/<description>
|
||||
git merge FETCH_HEAD
|
||||
# résoudre les conflits si nécessaire
|
||||
git checkout main
|
||||
git merge integration/<description>
|
||||
git branch -d integration/<description>
|
||||
```
|
||||
|
||||
### 4. Pousser vers Gitea
|
||||
|
||||
```bash
|
||||
git push origin main
|
||||
```
|
||||
|
||||
Le miroir GitHub se met à jour automatiquement. Fermer ensuite la PR sur GitHub en indiquant le hash du commit en commentaire.
|
||||
|
||||
---
|
||||
|
||||
## Bump de version
|
||||
|
||||
Modifier `"version"` dans `package.json` en suivant [semver](https://semver.org/) :
|
||||
|
||||
| Type | Version |
|
||||
|------|---------|
|
||||
| `fix` | PATCH `1.x.X` |
|
||||
| `feat` | MINOR `1.X.0` |
|
||||
| Breaking change | MAJOR `X.0.0` |
|
||||
|
||||
---
|
||||
@@ -1,59 +0,0 @@
|
||||
# DEV
|
||||
|
||||
## Standards
|
||||
|
||||
Toute contribution doit respecter les guides suivants :
|
||||
|
||||
- [GUIDE.md](GUIDE.md) — conventions générales de rédaction et de structure
|
||||
- [REDACTION.md](REDACTION.md) — règles de style, ton et formatage
|
||||
|
||||
---
|
||||
|
||||
## Structure du projet
|
||||
|
||||
```
|
||||
src/
|
||||
├── cli/ # Scripts CLI : zen-db, zen-setup
|
||||
├── core/ # Briques techniques : database, api, email, storage, cron, pdf, toast, payments
|
||||
├── features/ # Features utilisateur : auth, admin, provider
|
||||
├── modules/ # Modules métier : posts, invoice, nuage…
|
||||
└── shared/ # Composants, lib et styles partagés
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Publier le package
|
||||
|
||||
Le package `@zen/core` est publié sur le registre npm à `https://git.hyko.cx`.
|
||||
|
||||
### 1. Configurer l'authentification
|
||||
|
||||
Créer un token d'accès dans Gitea (Settings → Applications → Generate Token), puis l'enregistrer localement :
|
||||
|
||||
```bash
|
||||
npm config set //git.hyko.cx/api/packages/zen/npm/:_authToken TOKEN
|
||||
```
|
||||
|
||||
Remplacer `TOKEN` par le token généré.
|
||||
|
||||
### 2. Build et publish
|
||||
|
||||
```bash
|
||||
npm publish
|
||||
```
|
||||
|
||||
Le script `prepublishOnly` lance automatiquement le build avant la publication.
|
||||
|
||||
---
|
||||
|
||||
## Bump de version
|
||||
|
||||
Modifier `"version"` dans `package.json` en suivant [semver](https://semver.org/) :
|
||||
|
||||
| Changement | Version |
|
||||
|------------|---------|
|
||||
| `fix` — correctif | PATCH `1.x.X` |
|
||||
| `feat` — nouvelle fonctionnalité | MINOR `1.X.0` |
|
||||
| Breaking change | MAJOR `X.0.0` |
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user