OpenSwissData MCP server

OpenSwissData

Jeux de données publics suisses normalisés : FINMA, TARES et classifications. API Hono, site Astro et collectes TypeScript dans ce dépôt. Les données des clients et les preuves privées restent hors Git.

Préparer une copie de travail

Node 22.12 ou ultérieur ; la CI et Railway utilisent Node 22. Utiliser une copie isolée et lire AGENTS.md avant de commencer. Depuis la racine de cette copie :

npm ci
npm --prefix web ci
npm run typecheck
npm test
npm run build

Ces contrôles ne demandent aucun secret de production. Ne pas copier un .env ni une base de clients pour tester. Le build prépare des modèles publics figés : le premier passage demande le réseau et plusieurs gigaoctets ; les suivants contrôlent et réutilisent dist/models. La construction du site vérifie ensuite liens, langues et sitemap.

Les tests créent des bases fictives dans des dossiers temporaires et injectent explicitement leurs clés Ed25519 éphémères. Ils ne remplacent jamais la clé publique officielle et ne contactent pas les autorités d’horodatage pour fabriquer les archives de test. La CI vérifie que les fichiers suivis sont inchangés après les tests.

Démarrer localement

Après construction, depuis la copie isolée, sans variables de production :

npm run db:migrate
npm run dev

L’application est accessible sur http://localhost:3000. DATABASE_PATH permet de choisir une base locale fictive ; par défaut, elle est créée dans data/openswissdata.sqlite. Le site servi vient de web/dist et se reconstruit avec npm run web:build. npm run web:dev lance séparément le serveur Astro.

Une base vide permet de démarrer, mais ne satisfait pas /api/health/ready : ce contrôle exige les trois versions distribuées et les ressources du site. Ne pas inventer des versions pour contourner la disponibilité. Les tests créent leurs propres références fictives. Paiement, messagerie et stockage ne fonctionnent qu’avec leurs connexions configurées ; les commandes de vérification ci-dessus n’en ont pas besoin.

db:migrate initialise le schéma et applique les évolutions idempotentes de getDb(). Ce n’est pas un exécuteur de toutes les anciennes migrations SQL : l’élargissement historique Business reste une intervention distincte avant réouverture de cette offre.

Carte du projet

Les archives vendues résident dans R2. La base référence leurs versions ; catalogue, échantillons et caches MCP suivent les publications validées. Les fiches publiques FINMA et les index vectoriels historiques sont distincts : voir docs/fiches-publiques.md et les limites dans AGENTS.md.

La procédure de sauvegarde et de reprise distingue les contrôles réels de la base, les témoins indépendants dans le stockage et l’exercice complet du service restant à réaliser.

Publication et contrôles

main alimente Railway, qui attend les tests GitHub puis /api/health/ready. Un changement uniquement documentaire ou ETL peut être ignoré par les filtres de railway.json : le SHA de l’application demeure alors celui du dernier déploiement. Un push réussi ne prouve pas la publication.

Shortened. The full README is on GitHub.