NovaForge v0.1.0-alpha
Reproducible FFmpeg media pipeline
Transformer un pipeline média local en workflow reproductible avec génération MP4 réelle, validation ffprobe et provenance SHA-256.
Problem
Un traitement média n'est commercialement crédible que si la sortie peut être reproduite, inspectée et reliée à une preuve de test.
Constraints
- • source canonique privée
- • preuve publique limitée aux artefacts publiables
- • pas de GPU inference ni de génération vidéo IA revendiquée
- • reproductibilité fonctionnelle, pas déterminisme bit-for-bit
Build / Approach
- 01orchestrer un job média borné
- 02exécuter FFmpeg pour produire un MP4 réel
- 03valider la sortie avec ffprobe
- 04capturer une provenance SHA-256
- 05publier un paquet de preuve public sans exposer le dépôt privé
Verified results
- • 100 tests de régression enregistrés sur le run de référence
- • 1 test E2E FFmpeg réel enregistré sur le run de référence
- • MP4 public de démonstration publié
- • checksum public publié
- • clean-clone functional reproduction documentée
Tools
FFmpegffprobeSHA-256GitHub ActionsGitHub Pages
Related freelance services
FFmpeg AutomationCI/CD GitHub ActionsTechnical Documentation
Claim boundary
- • Ce cas n'est pas un projet client.
- • Le code source NovaForge reste privé.
- • Aucune production cloud, GPU inference ou SLA n'est démontrée.
VERIFIED 2026-09-25
KIANGANA 2.0 — KIF V0.2 CP-01
Dual-provider API routing with fallback
Construire et figer un checkpoint d'intégration de deux fournisseurs avec fallback contrôlé, tests unitaires, intégrations réelles et hygiène des secrets.
Problem
Une intégration API multi-fournisseur doit continuer à se comporter de manière prévisible lorsqu'un fournisseur n'est pas disponible, sans exposer les secrets.
Constraints
- • checkpoint historique distinct du current main
- • les preuves de reproductibilité s'appliquent à KIF V0.2 CP-01, pas à tout KIANGANA 2.0
- • aucune garantie SLA fournisseur
Build / Approach
- 01définir deux routes fournisseur interchangeables
- 02implémenter un fallback explicite
- 03tester les providers et le fallback
- 04scanner l'hygiène des secrets
- 05comparer proof commit et freeze commit
Verified results
- • 41 tests unitaires PASS sur le checkpoint
- • 3 tests d'intégration PASS incluant DeepSeek réel, Groq réel et fallback
- • freeze run PASS avec secret hygiene CLEAN
- • proof → freeze documenté comme checkpoint reproductible
Tools
API providersNode/Python test toolingGitHub ActionsGitsecret scanning
Related freelance services
API AutomationCI/CD GitHub ActionsTechnical AuditTechnical Documentation
Claim boundary
- • Ce cas n'est pas un projet client.
- • KIF V0.2 est un checkpoint historique.
- • Les tests réels de fournisseurs ne constituent pas une garantie de disponibilité future.
VERIFIED 2026-09-25
eCDF 0.1.0-alpha.0
Deterministic lifecycle with CI-backed evidence
Transformer une idée de transfert numérique en prototype TypeScript borné avec machine d'état, invariants, erreurs explicites et démonstration locale testée.
Problem
Un prototype de transfert de valeur peut facilement sur-promettre. Il fallait séparer strictement le comportement local démontré de tout règlement réseau ou financier non implémenté.
Constraints
- • aucun fonds réel
- • aucun règlement Stellar live dans le scope vérifié
- • aucune custody, banque, CBDC ou validation réglementaire revendiquée
- • démo locale CLI uniquement
Build / Approach
- 01modéliser explicitement les états et transitions
- 02rejeter transitions invalides et événements dupliqués
- 03utiliser bigint pour les montants
- 04produire une démo déterministe locale
- 05lier README, statut, tests, commit et CI
Verified results
- • 29 / 29 tests PASS sur le run de démo référencé
- • cycle local DRAFT → AUTHORIZED → SUBMITTED → SETTLED démontré
- • networkSettlement=false explicitement documenté
- • repository public avec Apache-2.0
Tools
TypeScriptNode.jsGitHub ActionsGitHubdeterministic tests
Related freelance services
GitHub SetupCI/CD GitHub ActionsTechnical AuditTechnical Documentation
Claim boundary
- • Ce cas n'est pas un projet client.
- • Il ne démontre pas un backend HTTP de production.
- • Il ne démontre pas de règlement Stellar Testnet/Mainnet ou de conformité financière.
VERIFIED 2026-09-25
P01-CP-FREELANCE-02
Three freelance capabilities converted into public proof packs
Fermer trois gaps de crédibilité commerciale en construisant des preuves publiques dédiées pour API Automation, Backend Prototype et Dockerisation.
Problem
Une liste de compétences n'est pas une preuve. Trois services de P01 étaient commercialement décrits mais ne disposaient pas encore de démonstrations publiques dédiées.
Constraints
- • coût externe = 0 USD pour les preuves
- • aucune clé API réelle nécessaire
- • aucun secret
- • tests exécutables sur GitHub-hosted runners
- • preuves bornées sans prétention production
Build / Approach
- 01créer deux API HTTP locales factices pour la preuve d'automatisation
- 02construire un backend JSON minimal avec health, OpenAPI et validation
- 03construire une image Docker non-root avec healthcheck
- 04exécuter trois jobs CI indépendants
- 05lier les résultats aux services publics P01
Verified results
- • API Automation proof PASS
- • Backend Prototype proof PASS
- • Docker build/start/health/smoke/teardown PASS
- • 3 services promus de PARTIAL PROOF à PUBLIC PROOF
- • workflow dédié reproductible sur main
Tools
Node.jsHTTPDockerDocker ComposeGitHub Actionscurl
Related freelance services
API AutomationDockerisationBackend PrototypeCI/CD GitHub Actions
Claim boundary
- • Ce cas est un proof pack interne, pas une livraison client.
- • Les API de test sont locales et fictives.
- • Aucune charge production, authentification complexe ou infrastructure cloud n'est démontrée.
VERIFIED 2026-09-25