WEBSITE ALPHA · AI-assisted, source-reviewed documentation · Full-stack docs reconciled 2026-08-26
64x64base

Developer Handbook

How to work from the local DotTalk++ / x64base truth.

Source of truth

Use the implementation checkout as the authoritative source tree for DotTalk++ / x64base work.

Use the website source tree as the website publication tree.

Use the local staging mirror as the clean source/runtime promotion mirror.

Observed local subtrees:

  • DotTalk++ runtime tree
  • Laboratory Campus / LabTalk tree
  • staged DotTalk++ runtime tree

The site content was updated from a scan of:

  • CMake build configuration.
  • command reference docs.
  • GUI docs under docs/gui.
  • database safety docs under docs/database.
  • source directories under src/xbase, src/xindex, src/memo, src/cli, src/datadict, and bindings/pydottalk.

See Current Project Truth. See SelfDoc Website Publication.

Accepted documentation entrypoints

These are reviewed website entrypoints, not a replacement for public source authority. Technical corrections start in the implementation/source evidence lane and are republished through the documented gates.

Working principles

  • Preserve the difference between runtime-proven, active, partial, experimental, and canary features.
  • Treat DotTalk++ as the canonical runtime and command surface.
  • Treat x64base as the engine/runtime/data layer, not as a separate polished product unless the source tree proves that packaging.
  • Keep GUI descriptions top-down over the existing runtime. Do not imply wxWidgets, Tk, or TUI lanes own database semantics.
  • Treat the website as downstream of SelfDoc, contracts, manuals, and reviewed runtime docs.
  • Keep public GitHub links current where the site describes public work.
  • Avoid placeholder CLI commands when the local command reference has real commands.

Shared document workflow

  • Runtime/engineering truth belongs first in implementation checkout.
  • Publication-ready manuals, contracts, and diagrams should be reviewed there before site promotion.
  • The website should mirror or curate those reviewed materials, not replace them.
  • Website publication should flow through the website source tree to built/public artifacts, then to GitHub Pages and x64base.com.
  • Source/runtime publication should flow through the implementation checkout to the local staging mirror, then to GitHub.
  • If a technical claim diverges between the two trees, fix the implementation checkout first and then republish the site.

Education goal

One explicit project goal is to learn front-end work through the x64base / DotTalk++ / LabTalk stack.

That means learning:

  • how runtime truth feeds UI truth,
  • how CLI, TUI, GUI, and website layers align,
  • how SelfDoc and manuals feed public-facing documentation,
  • how to build a full-stack educational database system from source to site.

Build boundaries

Do not mutate DBFs, HELP data, metadata catalogs, or generated publication artifacts unless the task explicitly asks for that and the mutation path is understood.

The local CMake metacollect block calls out a safety boundary: no HELP DATA rebuild, no CMDHELPCHK mutation, and no DBF writes.

Contributing

See: Contribution Guide

← Developer Profile
SelfDoc Website Publication →