À propos du projet

Positionnement du projet Il s'agit d'un poste de travail local pour Windows destiné aux scénarios de publication longue sur Fanqie Novel, utilisant une pile technique composée d'Electron, React, TypeScript et SQLite. L'application ne nécessite pas de connexion au compte Fanqie et ne publie pas automatiquement les œuvres ; toutes les actions de publication sont effectuées manuellement par l'auteur via le backend de la plateforme. L'idée centrale est de transformer le flux « étude des classements — analyse d'échantillons — lancement d'original — planification glissante — rédaction chapitre par chapitre — registre d'état — contrôle qualité — planification de publication — analyse des données » en un pipeline local auditable. Capacités principales Côté étude de marché, le système peut collecter des pages de classements publics sans connexion ou importer des fichiers CSV de classements, et supporte la comparaison de snapshots à dates multiples. Lors de l'importation de fichiers TXT, EPUB, DOCX ou du collage de texte, un aperçu du découpage des chapitres est proposé avant la confirmation de l'entrée en base de données. L'analyse d'échantillons peut être purement locale ou, après consentement explicite pour chaque livre, appeler des modèles cloud par lots de dix chapitres pour produire des preuves à quatre niveaux (chapitre, phase de dix chapitres, volume, livre complet), et extraire chapitre par chapitre, selon une base de connaissances intégrée sur le web-roman commercial chinois, l'attente, l'intérêt central, l'action proactive, le retour émotionnel, l'impact réel et l'attente suivante. Le volet rédaction comprend l'approbation du contrat de création, les phases macro et volumes, un synopsis grossier pour les 30 prochains chapitres, un synopsis détaillé pour les 5 prochains chapitres et une fiche de scène pour le chapitre actuel. La table de rédaction permet de sauvegarder le plan du chapitre, de prévisualiser le contexte minimal compilé, puis de générer ou d'écrire le texte. Les chapitres standards sont supportés par lots de cinq ; avant l'exécution, les entrées, sorties et estimations de coûts sont affichées. Les chapitres clés, les limites de volumes, les changements d'état majeurs, les conflits de faits ou les alertes critiques demandent automatiquement un traitement chapitre par chapitre. Le registre d'état sert à maintenir les personnages, relations, capacités, ressources, lieux, chronologies, secrets, promesses, indices (foreshadowing), intrigues secondaires et événements. Modèles et contexte Dans les paramètres système, on peut choisir OpenAI / interfaces compatibles ou le protocole Anthropic Claude, en renseignant l'adresse de base et le nom du modèle, ainsi que les prix unitaires d'entrée et de sortie pour l'estimation des coûts. Le délai total pour les tâches longues peut être choisi entre 5, 10 et 15 minutes ; une réponse en streaming sans données pendant 180 secondes s'arrêtera prématurément. Les clés API sont stockées dans le Windows Credential Manager, et non dans SQLite, les logs, le répertoire du projet ou les packs de sauvegarde. Les appels Anthropic utilisent la clé API officielle et ne lisent pas l'état de connexion de Claude Code / Claude Max. La recherche de faits pertinents utilise un index de similarité de caractères chinois local, sans appel à des modèles de vecteurs cloud. Le contexte est rendu par couches selon sa stabilité : le contrat de création est fixé à la fin du prompt système, et la tâche du chapitre est placée près du point de génération. Les longues listes de la « Bible de l'histoire » peuvent être converties en entrées de configuration, injectées via un filtrage par intervalle de chapitres effectifs, chapitre de révélation au lecteur et moment de mention ; les règles du monde et les ancres temporelles sont résidentes par défaut. La fenêtre de contexte du modèle privilégie les résultats de détection ; à défaut, elle déduit 1M pour le cloud et 32k pour le local, avec possibilité de recouvrement manuel. Passerelles humaines Tant que le contrat de création n'est pas approuvé, la planification ou la génération de texte ne peuvent être validées. Les chapitres avec des problèmes critiques non résolus ne peuvent être finalisés ni entrer dans la file de publication. Si un contrat approuvé, une planification validée, ou un chapitre finalisé/en cours de publication doit être modifié, un bon de modification de plan doit d'abord être approuvé. L'IA ne génère que des candidats, des brouillons et des suggestions ; elle ne finalise pas, ne modifie pas les plans et ne publie pas automatiquement. Le contrôle qualité exécute toujours des règles hors ligne, avec une révision sémantique ajoutée après configuration du modèle, basée sur des preuves du texte ou du registre. Isolation et sécurité Les échantillons originaux sont conservés uniquement dans research\research.sqlite. L'analyse cloud n'envoie que des fragments de chapitres anonymisés localement. Le modèle de création ne reçoit que des packs d'insights anonymisés, pas le texte original de recherche. Les enregistrements de contrôle qualité ne conservent que des références de recherche anonymes et des empreintes. Le processus de rendu Electron active le sandbox, l'isolation du contexte et la politique de sécurité du contenu (CSP), sans intégration Node.js. L'IPC n'accepte que les appels de la fenêtre principale, et les API publiques doivent enregistrer un schéma de paramètres Zod ; les canaux non enregistrés sont refusés par défaut. La collecte de classements et les adresses de modèles n'autorisent que le HTTP/HTTPS et rejettent les adresses locales, privées ou réservées. Données, sauvegarde et fiabilité L'espace de travail par défaut se situe dans « Données du poste de travail de création longue » sous le répertoire Documents de l'utilisateur, comprenant catalog.sqlite, la base de recherche, un project.sqlite indépendant par œuvre, des annexes, et des répertoires d'exportation et de sauvegarde. Aucune recherche plein texte ou vectorielle inter-projets n'est effectuée. Les fichiers de sauvegarde .novelbak utilisent le chiffrement AES-256-GCM, incluant la base de données, le répertoire de l'œuvre, les annexes et la liste des fichiers. Un checkpoint SQLite est exécuté avant la création ; le fichier est écrit temporairement, puis remplacé après une vérification complète du déchiffrement. La restauration écrit dans un nouveau répertoire de copie sans écraser l'espace de travail actif. Les sauvegardes automatiques peuvent être quotidiennes ou hebdomadaires (conservation de 1 à 30 versions), et le mot de passe dédié réside uniquement dans le Windows Credential Manager. La page de santé système permet de vérifier manuellement l'intégrité de chaque base SQLite, de comparer le nombre d'enregistrements de chapitres avec les deux index FTS, et de signaler les répertoires orphelins, les tâches échouées et l'occupation disque. Les index peuvent être reconstruits de manière transactionnelle ; les fichiers corrompus ou manquants sont signalés sans être supprimés ou déplacés automatiquement. Le centre de tâches IA enregistre l'état, le modèle, les tokens réels, le coût et la durée. Les tâches en cours après une sortie anormale sont marquées comme interrompues ; les tâches de texte peuvent être annulées ou retentées en toute sécurité. Les logs de bureau sont au format JSON Lines, avec anonymisation des clés, Bearer, URL et répertoires utilisateurs avant l'écriture, et peuvent être exportés en ZIP de diagnostic sans texte ni base de données. Publication et mise à jour La publication Windows utilise un installateur NSIS, avec une version portable dans release\win-unpacked. La version de développement actuelle ne possède pas de certificat de signature de code commercial, SmartScreen peut donc signaler un éditeur inconnu. Les mises à jour automatiques sont activées uniquement dans l'application packagée : vérification 15 secondes après le démarrage, puis toutes les 6 heures, téléchargement en arrière-plan sans redémarrage automatique. Un snapshot chiffré pre-update est créé avant l'installation ; en cas d'échec de l'installateur, la version actuelle est conservée. La source de mise à jour est fixée aux GitHub Releases du projet, demandant uniquement latest.yml, sans envoyer de texte, de registre ou d'identifiants, et peut être totalement désactivée via des variables d'environnement. Le pipeline de publication nécessite trois GitHub Secrets pour le certificat et le nom de l'éditeur ; les tags v* déclenchent les tests, la construction, la signature et la publication. Ingénierie et critères de qualité Pour le développement local, Node.js 22 LTS et Windows 10/11 sont recommandés. Les commandes incluent npm test, test:quality, test:scale (capacité de 10 livres × 1500 chapitres × 3 millions de mots), test:e2e, build, test:electron et dist:win. Le fichier src/shared/quality-benchmark-corpus.ts contient des cas fixes liés aux versions de prompts, couvrant les limites de connaissances des personnages, la conservation des ressources, les conflits de temps et de lieu, la répétition des mécanismes de retour continu et le contrôle des faux positifs pour les chapitres normaux. Les tests de qualité calculent respectivement le taux de rappel des problèmes, la précision, la précision du niveau de gravité, la précision des preuves et le taux de contrôle des faux positifs, avec le coût des tokens mesuré séparément. L'injection de pannes n'est active que sous NODE_ENV=test, simulant un disque plein, une coupure de courant avant soumission ou des identifiants indisponibles. Le projet dispose également de documents sur l'architecture, les règles de domaine, la base de connaissances et le modèle de sécurité, et est open-source sous licence MIT.