112c64a22b
Some checks are pending
Veza CI / Backend (Go) (push) Waiting to run
Veza CI / Frontend (Web) (push) Waiting to run
Veza CI / Rust (Stream Server) (push) Waiting to run
Veza CI / Notify on failure (push) Blocked by required conditions
E2E Playwright / e2e (full) (push) Waiting to run
Security Scan / Secret Scanning (gitleaks) (push) Waiting to run
The soft-launch report doc (SOFT_LAUNCH_BETA_2026.md) had the
narrative — cohort table, email body inline, monitoring list,
acceptance gate. But the operational pieces were notes-to-self :
"add migration if missing", "Typeform to-do", "schema TBD". The
operator was supposed to assemble them on the day, which on a soft-
launch day is the worst possible time.
Added the missing 6 pieces so the day-of work is "tick boxes",
not "build the tooling" :
* migrations/990_beta_invites.sql — schema with code (16-char
base32-ish), email, cohort label, used_at, expires_at + 30d
default, sent_by FK with ON DELETE SET NULL. Three indexes :
unique on code (signup-path lookup), cohort (post-launch
attribution report), partial expires_at WHERE used_at IS NULL
(cleanup cron).
* scripts/soft-launch/validate-cohort.sh — sanity check on the
operator's CSV : header form, malformed emails, duplicates,
cohort distribution (≥50 total / ≥5 creators / ≥3 distinct
labels), optional collision check against existing users.
Exit codes 0 / 1 (block) / 2 (warn-but-proceed). Hard checks
block, soft checks let the operator override with FORCE=1.
* scripts/soft-launch/send-invitations.sh — split-phase :
step 1 (default) inserts beta_invites rows + renders one .eml
per recipient under scripts/soft-launch/out-<date>/
step 2 (SEND=1) dispatches via $SEND_CMD (msmtp by default)
so the operator can review the rendered emls before sending
100 emails. Per-recipient transactional INSERT so a partial
failure doesn't poison the table. Failed inserts logged with
the offending email so the operator can rerun on the subset.
* templates/email/beta_invite.eml.template — proper MIME multipart
(text + HTML) eml ready for sendmail-compatible piping. French
copy aligned with the éthique brand (no FOMO, no urgency
manipulation, no "limited spots" framing).
* scripts/soft-launch/monitor-checks.sh — polls the 6 acceptance-
gate signals defined in SOFT_LAUNCH_BETA_2026.md §"Acceptance
gate" : testers signed up, Sentry P1 events, status page,
synthetic parcours, k6 nightly age, HIGH issues. Each gate
independently emits ✅ / 🔴 / ⚪ (last for "couldn't check").
Verdict on stdout. LOOP=1 keeps polling every CHECK_INTERVAL
seconds. Designed for cron + tmux, not for an interactive UI.
* docs/SOFT_LAUNCH_BETA_2026_CHECKLIST.md — pre-flight gate that
must reach 100% green before the first invitation goes out.
T-72h section (database, cohort, email infra, redemption path,
monitoring, comms), D-day section (last-hour, send, hour-1,
every-4h), 18:00 UTC decision call section. Linked back to the
bigger SOFT_LAUNCH_BETA_2026.md so the operator can navigate
between the "what" (report) and the "how / has-everything-
been-checked" (this checklist) without losing context.
What still requires the operator on the day :
- Build the cohort CSV (curate emails from real sources)
- Create the Typeform feedback form ; paste its URL into the
eml template once known
- Configure msmtp / sendmail ($SEND_CMD)
- Press the send button
- Show up at 18:00 UTC for the decision call
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| adr | ||
| archive | ||
| audit-2026-04 | ||
| audits | ||
| runbooks | ||
| testing | ||
| API_REFERENCE.md | ||
| API_VERSIONING_POLICY.md | ||
| BOOT_MODE_STATUS.md | ||
| BUDGETS.md | ||
| BUG_BASH_V0981.md | ||
| CANARY_RELEASE.md | ||
| CHAT_FEATURE_PARITY.md | ||
| CI_E2E.md | ||
| DB_MIGRATIONS_AUDIT_V1.md | ||
| DB_MIGRATIONS_ORIGIN_DIFF.md | ||
| DB_MIGRATIONS_STRATEGY_FINAL.md | ||
| DB_MIGRATIONS_V1_VALIDATION.md | ||
| DB_TRANSACTION_PLAN.md | ||
| DISCOVERY_ALGORITHM.md | ||
| ENV_CONFIG.md | ||
| ENV_VARIABLES.md | ||
| ENVIRONMENT_REAL_SETUP.md | ||
| FEATURE_STATUS.md | ||
| FRONTEND_AUDIT_VISUAL.md | ||
| FRONTEND_DEEP_DIVE_AUDIT.md | ||
| FRONTEND_ROADMAP_SPOTIFY_DISCORD_QUALITY.md | ||
| FRONTEND_SETUP.md | ||
| FRUGALITY.md | ||
| GLOBAL_PROJECT_STATE_2026.md | ||
| GO_NO_GO_CHECKLIST_v1.0.0.md | ||
| GO_NO_GO_CHECKLIST_v2.0.0_PUBLIC.md | ||
| MIGRATION_CONSOLIDATION.md | ||
| MIGRATIONS.md | ||
| MINIMAL_WEB.md | ||
| MONITORING_SETUP.md | ||
| MONOREPO_ORCHESTRATION.md | ||
| ONBOARDING.md | ||
| PAYMENT_E2E_LIVE_REPORT.md | ||
| PAYMENTS_SETUP.md | ||
| PAYOUT_MANUAL.md | ||
| PENTEST_SCOPE_2026.md | ||
| PENTEST_SEND_PACKAGE.md | ||
| PERFORMANCE_BASELINE.md | ||
| PR_READY_CHECKLIST.md | ||
| PRIVACY_POLICY.md | ||
| PRODUCTION_DEPLOYMENT.md | ||
| PROJECT_STATE.md | ||
| PWA_OFFLINE_VERIFICATION.md | ||
| README.md | ||
| RELEASE_NOTES_V2.0.0_RC1.md | ||
| REMOTE_DEV_R720.md | ||
| REPORT_FRONTEND_PHASE1.md | ||
| RGPD_CCPA_VERIFICATION.md | ||
| ROADMAP_V1.0_LAUNCH.md | ||
| ROADMAP_V09XX_TO_V1.md | ||
| RUNBOOK_ROLLBACK.md | ||
| SCOPE_CONTROL.md | ||
| SECRET_ROTATION.md | ||
| SECRETS_AUDIT.md | ||
| SECRETS_VERIFICATION.md | ||
| SECURITY_PRELAUNCH_AUDIT.md | ||
| SECURITY_SCAN_RC1.md | ||
| SOFT_LAUNCH_BETA_2026.md | ||
| SOFT_LAUNCH_BETA_2026_CHECKLIST.md | ||
| STAGING_DEPLOYMENT.md | ||
| STORYBOOK_CONTRACT.md | ||
| STRATEGIE_COUVERTURE_ET_TMT_2025_02.md | ||
| TEST_PROTOCOL_BOOT.md | ||
| TODO_TRIAGE_VEZA.md | ||
| TRANSACTION_TESTS_PHASE3.md | ||
| TRIAGE_REPORT.md | ||
| UUID_DB_CARTOGRAPHY.md | ||
| UUID_DB_MIGRATION_PLAN.md | ||
| V1_LIMITATIONS.md | ||
| V1_MVP_SCOPE.md | ||
| V1_SIGNOFF.md | ||
| VEZA_PROJECT_DOCUMENTATION.md | ||
| VISUAL_TESTING_STRATEGY.md | ||
Documentation Veza
Index de la documentation principale du monorepo.
Démarrage
- Onboarding — Setup, architecture, conventions, troubleshooting
- Frontend Setup — Configuration du frontend React
- Environment Config — Variables d'environnement et connexion Docker
Architecture & Déploiement
- Production Deployment — Déploiement en production
- Monorepo Orchestration — Organisation du monorepo
- Monitoring Setup — Configuration du monitoring
Développement
- Remote Dev R720 — Développement sur serveur R720 via Cursor Remote-SSH
- Scope v0.201 — Périmètre de la version courante (référence prioritaire)
- État du projet — Où en sommes-nous, prochaines étapes
- Contrôle du scope — Processus anti-scope-creep
- Feature Status — Statut des fonctionnalités
- Storybook Contract — Conventions Storybook
- Visual Testing Strategy — Stratégie des tests visuels
- PR Ready Checklist — Checklist avant merge
Base de données & Migrations
- DB Migrations Strategy — Stratégie des migrations
- UUID Migration Plan — Plan de migration UUID
Sécurité & Opérations
- Secrets Verification — Vérification des secrets
- Secret Rotation — Rotation des secrets
- Payments Setup — Configuration des paiements
Remédiation & Progression
- Remediation Progress — Suivi de la remédiation
- Global Project State — État global du projet
Archives
Les audits et rapports historiques sont dans docs/archive/.
Documentation par composant
- Frontend :
apps/web/docs/(FULL_LAYOUT_PAGE, DESIGN_TOKENS, etc.) - Backend :
veza-backend-api/docs/