Skip to main content

Velox Help Repository TODO

Static review performed on 2026-07-05.

Scope:

  • Reviewed Code Library documentation, generated index metadata, Docusaurus project files, and copy/update scripts.
  • Did not modify documentation content outside this TODO file.
  • Did not run a Docusaurus build.
  • Stability focus was on documentation freshness, generated-index reliability, and scripts that copy content into install/runtime locations.

High Risk​

No high-risk runtime code issue was identified in this repository.

The main product stability risk is indirect: incorrect or stale documentation can lead operators to configure Velox incorrectly, especially around services, database upgrades, transports, and 32/64-bit dependencies.

Medium Risk​

Code Library content can drift from generated index metadata​

Files/folders:

  • CodeLibrary
  • CodeLibrary\_Index.json

Evidence:

  • The repository contains thousands of Markdown files under CodeLibrary.
  • _Index.json is a large generated/navigation artifact.
  • The install repository also contains a copied Code Library index.

Risk:

  • A stale index can make current documentation hard to find or can point to missing/moved files.
  • Customer-facing Designer help can diverge from the source documentation.
  • Broken navigation may be interpreted as a product defect.

Suggested direction:

  • Document the index generation process.
  • Add a validation step that checks every indexed file exists and every intended Markdown file is indexed.
  • Compare source and install copies during release.

Hard-coded copy script can overwrite install and local ProgramData help​

File:

  • _UPDATE INSTALL FOLDER.bat

Evidence:

  • The script uses hard-coded source and target paths.
  • It copies Code Library content into the install repository and C:\ProgramData\Velox\Help\CodeLibrary.

Risk:

  • Running the script from the wrong machine or branch can push draft documentation into release/install folders.
  • There is no obvious dry-run, validation, or backup step.

Suggested direction:

  • Add a documented release process for help publishing.
  • Validate source branch and target path before copying.
  • Consider generating release help artifacts instead of manually copying folders.

Docusaurus site still contains starter content and placeholder branding​

Files:

  • Velox\docusaurus.config.js
  • Velox\src\pages\index.js
  • Velox\src\components\HomepageFeatures\index.js
  • Velox\docs\intro.md

Evidence:

  • The Docusaurus config contains starter values such as template title/tagline, placeholder URL, template GitHub links, and placeholder labels.
  • The homepage and intro docs still contain Docusaurus tutorial/starter content.

Risk:

  • If published accidentally, the site would present incorrect branding and misleading content.
  • If the site is not active, the scaffold creates maintenance and search noise.

Suggested direction:

  • Decide whether the Docusaurus site is an active product documentation target.
  • If active, replace starter content before publication.
  • If inactive, document its status clearly.

User-facing documentation freshness depends on cross-repository behavior​

Repositories involved:

  • velox
  • velox-data
  • velox-web
  • velox-web2
  • Install

Evidence:

  • User documentation describes behavior implemented across multiple repositories.
  • Runtime behavior can be unclear from documentation alone when code changes are made elsewhere.

Risk:

  • Documentation can claim behavior that no longer matches the Velox services, web apps, database scripts, or install artifacts.
  • Operational docs for upgrade, service restart, and 32/64-bit dependencies are especially important for stability.

Suggested direction:

  • Link user-facing documentation changes to source code or release changes.
  • Mark unclear behavior as unclear until confirmed from code or product owner knowledge.
  • Add release review checks for service startup, database upgrade, install, and transport documentation.

Low Risk​

Package dependencies should be periodically refreshed​

Files:

  • Velox\package.json
  • Velox\package-lock.json

Evidence:

  • The Docusaurus site uses Node/Docusaurus dependencies.
  • The package lock is large and should be treated as generated dependency state.

Risk:

  • Dependency age can create build, security, or compatibility issues.
  • This matters only if the Docusaurus site is actively built/published.

Suggested direction:

  • Keep Node version and Docusaurus version documented.
  • Refresh dependencies through a normal tested upgrade process, not opportunistically.

Static documentation repository has limited direct thread-safety or bitness exposure​

Evidence:

  • This repository is mostly Markdown, JSON, JavaScript config, and copy scripts.

Risk:

  • There is no direct runtime threading issue in the help content.
  • The documentation must still accurately describe thread-sensitive and bitness-sensitive product behavior.

Suggested direction:

  • Use the runtime repository docs as the source for stability-sensitive user guidance.

Duplicate Code Areas​

  • Code Library content exists in source form here and copied form under Install.
  • Docusaurus starter pages duplicate template content rather than Velox-specific documentation.

Dead Code / Stub Areas​

  • The Docusaurus starter homepage and tutorial pages appear to be placeholder content unless the site is actively being customized.
  • Any generated index or copied help file not used by Designer or the published docs should be identified and documented.

Thread Safety / Stability Concerns​

  • No in-process thread-safety concern was identified.
  • Stability risk is documentation-driven: incorrect stop/start, upgrade, transport, or driver-bit comments can lead operators into unsafe actions.

32-bit / 64-bit Concerns​

  • No code-level pointer or architecture issue was identified in this repository.
  • Help content should explicitly document when users need 32-bit versus 64-bit Velox binaries and matching native drivers.
  • Help should also document known 64-bit limitations or validation requirements from the Delphi runtime review.

Performance Concerns​

  • Docusaurus build performance may become an issue if all Code Library content is eventually included in the site.
  • Large generated JSON indexes should be validated for load time in Designer/help UI, but runtime measurement is outside this repository.

Areas Difficult to Maintain​

  • Thousands of small Code Library Markdown files.
  • Generated navigation/index metadata.
  • Cross-repository user documentation that must match Delphi services, database schema, install packages, and web front ends.

Open Questions​

  • What command or tool generates CodeLibrary\_Index.json?
  • Is the Docusaurus site planned for customer publication?
  • Which help content is the authoritative source for Designer Code Library help?
  • Should help publishing to Install be automated as part of the release pipeline?
  • Which 32/64-bit guidance must be user-facing versus developer-facing?