About this project

Project Positioning This is a Windows local desktop workbench designed for long-form serialization scenarios on Tomato Novel, utilizing a technical stack of Electron, React, TypeScript, and SQLite. The application does not log into Tomato accounts nor automatically publish works; all publishing actions are performed manually by the author via the platform backend. The core concept is to string together "chart research — sample disassembly — original project initiation — rolling planning — chapter-by-chapter writing — state ledger — quality inspection — scheduling and publishing — data review" into an auditable local pipeline. Main Capabilities Regarding market research, it can collect public chart pages that do not require login or import chart CSVs, supporting multi-date snapshot comparisons. When importing TXT, EPUB, DOCX, or pasting text, it provides a chapter-splitting preview before confirming database entry. Book disassembly supports local-only analysis or, upon explicit consent per book, calls cloud models in ten-chapter batches to produce four levels of evidence: chapters, ten-chapter stages, volumes, and the full book. It extracts entry expectations, core interests, active actions, emotional rewards, actual impacts, and next expectations for each chapter based on a built-in Chinese commercial web-novel knowledge base. On the writing side, it includes creative contract approval, macro stages and volumes, rough outlines for the next 30 chapters, detailed outlines for the next 5 chapters, and scene cards for the current chapter. The writing desk can save chapter outlines, preview compiled minimum contexts, and then generate or manually write the main text. Regular chapters support five-chapter batches, displaying input, output, and cost estimates before execution. Key chapters, volume boundaries, major state changes, factual conflicts, or hard warnings will automatically require chapter-by-chapter processing. The state ledger is used to maintain characters, relationships, abilities, resources, locations, timelines, secrets, promises, foreshadowing, side plots, and events. Models and Context In system settings, users can select OpenAI / compatible interfaces or the Anthropic Claude protocol and fill in the base address and model name, as well as input/output unit prices for cost estimation. Total time limits for long tasks can be selected from 5, 10, or 15 minutes, and streaming responses will stop early if no data is received for 180 seconds. API keys are stored in the Windows Credential Manager and are not written to SQLite, logs, project directories, or backup packages. Anthropic calls use official API keys and do not read Claude Code / Claude Max login states. Relevant fact retrieval uses a local Chinese character similarity index and does not call cloud vector models. Context is rendered in layers based on stability: the creative contract is fixed at the end of the system prompt, and the current chapter task is placed close to the generation point. Long lists in the story bible can be converted into setting entries, injected via filters based on effective chapter ranges, reader revelation chapters, and mention timing; world rules and time anchors remain resident by default. The model context window prioritizes probe results; if unfilled, it derives 1M for cloud and 32k for local, or can be manually overridden. Human Gates Planning or text generation cannot be approved if the creative contract is not approved. Chapters with unresolved hard issues cannot be finalized or enter the publishing queue. If an approved contract, approved plan, finalized chapter, or chapter in publishing needs modification, a plan change request must first be approved. AI only generates candidates, drafts, and suggestions; it will not automatically finalize, change plans, or publish. Quality inspection always executes offline rules, with semantic review based on main text or ledger evidence added after model configuration. Isolation and Security Original samples are stored only in research\research.sqlite. Cloud disassembly only sends locally desensitized chapter fragments. The creative model only receives desensitized insight packages, not original research text. Work quality inspection records only save anonymous research references and fingerprints. The Electron rendering process enables sandbox, context isolation, and Content Security Policy (CSP), without exposing Node.js integration. IPC only accepts calls from the main window; public APIs must register Zod parameter schemas, and unregistered channels are rejected by default. Chart collection and model addresses only allow HTTP/HTTPS and reject localhost, private network, and reserved addresses. Data, Backup, and Reliability The default workspace is located in "Long-form Creation Workbench Data" under the user's documents directory, containing catalog.sqlite, the research library, independent project.sqlite for each work, attachments, and export/backup directories. No cross-project full-text or vector retrieval is performed between different works. Backup files (.novelbak) use AES-256-GCM encryption, containing databases, work directories, attachments, and file lists. A SQLite checkpoint is executed before creation, writing to a temporary file and performing full decryption verification before replacing the target. Recovery writes to a new copy directory without overwriting the active workspace. Automatic backups can be daily or weekly, retaining the last 1–30 copies, with dedicated passwords stored only in the Windows Credential Manager. The system health page allows manual checks of SQLite integrity for each library, verification of chapter records against two sets of FTS index counts, reporting of orphaned directories, failed tasks, and disk usage. Indexes can be rebuilt transactionally; damaged or missing files are reported but not automatically deleted or moved. The AI task center records status, model, actual tokens, cost, and duration. Tasks running during an abnormal exit are marked as interrupted; text tasks can be canceled or safely retried. Desktop logs are in JSON Lines format, desensitizing keys, Bearers, URL credentials, and user directories before writing to disk, and can export a diagnostic ZIP without main text or databases. Publishing and Updates Windows publishing uses NSIS installers, with portable builds located in release\win-unpacked. The current development version lacks a commercial code signing certificate, so SmartScreen may prompt an unknown publisher. Auto-updates are enabled only in packaged apps, checking 15 seconds after startup and every 6 hours thereafter, downloading in the background without automatic restarts. An encrypted pre-update snapshot is created before installation; if the installer fails, the current version is retained. The update source is fixed to project GitHub Releases, requesting only latest.yml, without uploading main text, ledgers, or credentials, and can be completely disabled via environment variables. The publishing pipeline requires three GitHub Secrets for certificates and publisher name; tags v* trigger testing, building, signing, and publishing. Engineering and Quality Benchmarks Local development recommends Node.js 22 LTS and Windows 10/11. Commands include npm test, test:quality, test:scale (10 books × 1500 chapters × 3 million words capacity), test:e2e, build, test:electron, and dist:win. src/shared/quality-benchmark-corpus.ts stores fixed cases tied to prompt versions, covering character knowledge boundaries, resource conservation, time/location conflicts, continuous reward mechanism repetition, and normal chapter false positive control. Quality tests separately calculate problem recall, accuracy, severity accuracy, evidence accuracy, and false positive control rate, with Token costs measured separately. Fault injection is only active in NODE_ENV=test, simulating full disks, power failure before submission, and unavailable credentials. The project also includes documentation for architecture, domain rules, knowledge base, and security models, and is open-sourced under the MIT License.