SelfDoc Website Publication

Core rule

implementation checkout is the implementation truth.

website source tree is the public publication surface.

The site should present reviewed, provenance-aware derivatives of the runtime, contracts, HELP, metadata, manuals, and diagrams. It should not invent technical truth on its own.

Full-stack documentation push (pass 4)

The concepts on this page are unchanged. What has evolved is the cadence: a documentation change now travels the whole stack end to end, and we are on the fourth full-stack documentation push (pass 4). The data-flow below is the start-to-finish path a change follows, from implementation evidence to the public consumers.

The pass in detail (steps collapsed to reduce clutter)

Produce -- in the implementation checkout: command/function registration, HELP text, metadata, inline contracts, comments, and canaries.
Validate -- SelfDoc / CMDHELPCHK confirm HELP, metadata, and contracts agree with the runtime.
Harvest -- metacollect and the harvest exporter pull reviewed evidence out of the tree.
Generate -- manualgen / MDO assemble manual sections and attach reviewed diagrams.
Gate -- doc candidates must clear the public-content guard and the diagram-integrity check (check:diagrams) before promotion.
Sign off -- Phase 9 owner review: stale-copy audit and generated-page integrity across the site.
Publish -- consumers receive the reviewed derivative: the manual, the website (x64base.com), and the GPTbase bundle.

Public source

Public GitHub repo: deraldg/x64base
Local implementation tree: implementation checkout
Local DotTalk++ runtime tree: DotTalk++ runtime tree
Local Laboratory Campus tree: Laboratory Campus tree
Local site tree: website source tree
Local runtime mirror: local staging mirror
Public reviewed derivative: x64base.com

Observed maintainer flow

Use this as the normal direction of travel:

source/runtime:
implementation checkout -> local staging mirror -> GitHub repository

website:
website source tree -> build/public artifact -> GitHub Pages -> x64base.com

Shared document model

Use this split:

Runtime/source/contracts/manual truth lives in implementation checkout
Public website framing and navigation live in website source tree
local staging mirror is the clean staging mirror for source/runtime promotion
Built website output moves through reviewed build/public artifacts before GitHub Pages publication
Shared diagrams and publication artifacts should be promoted from reviewed SelfDoc/manual outputs, not rewritten from memory

Repeatable feed

For the report-only source-to-website feed, see SelfDoc Feed Pipeline.

When commands or functions are added to DotTalk++, they should flow through registration, HELP, metadata, comments, usage contracts, SelfDoc/CMDHELPCHK validation, manualgen, and then the public command/function/API pages.

dottalkpp.com -- the lean entry site

The Public Site Architecture provides separate diagrams for x64base.com and dottalkpp.com plus a governed connection map showing their reciprocal links, independent release histories, and blocked reverse-authority path. (Role updated 2026-08-11, AIF-107: dottalkpp.com is the lean public entry surface, not a library; the diagrams predate the change.)

Related in-site starting points:

Releases and reviewed downloads: x64base Downloads
DotScript: DotScript language guide
Reference: Command catalog
Governance: Current Project Truth

Its role is the lean public entry: current status with evidence tiers, plain-vocabulary documentation, downloads, schemas, and contact. x64base.com remains the development and conception site.

Authority rule: the lean site is downstream from implementation evidence, HELP, metadata, SelfDoc, MDO, and manualgen. It may feed selected summary links back to x64base.com, but it must not become a substitute source for command syntax, file formats, mutator behavior, indexing behavior, or runtime truth.

Simplex and duplex gates

The website, manuals, and implementation tree are connected, but they do not have equal authority.

Rule 1: most technical data on x64base.com must be derived, harvested, calculated, or reviewed from the implementation checkout. The website may frame and organize that information, but it should not become the source of runtime, command, field-format, index, memo, HELP, or manual truth.

Rule 2: the manual may contribute reviewed sections, diagrams, and summaries to the website. The manual must not consume website copy as technical truth unless the website artifact is explicitly non-derivable from the implementation tree and is maintained separately as a public artifact.

Rule 3: README.* files are sacred orientation artifacts. They may be improved, annotated, or superseded, but a replacement must be versioned so the older README remains recoverable and comparable. Do not casually overwrite a README during website, manual, or staging work.

Use these gates:

Path	Gate Type	Rule
implementation checkout -> manual	Simplex default	Source, HELP, metadata, comments, contracts, canaries, and SelfDoc/manualgen reports feed the manual.
implementation checkout -> website	Simplex default	Website pages should be derivatives of source/runtime/manual evidence, not hand-written replacements for it.
implementation checkout -> dottalkpp.com lean site	Simplex default	Manuals, references, generated docs, downloads, proof packets, and governance should derive from source/runtime/HELP/metadata/SelfDoc/MDO/manualgen evidence.
manual -> website	Duplex, reviewed	Reviewed manual sections may promote into website summaries when proof labels and source anchors remain intact.
dottalkpp.com lean site -> website	Duplex, reviewed	The lean site may contribute selected summary links, route maps, and downloadable artifact notices to x64base.com after review.
website -> manual	Blocked by default	Do not let website prose become manual truth. Only ingest website-owned artifacts that are non-derivable elsewhere.
website -> dottalkpp.com lean site	Blocked by default	Do not let ecosystem prose become technical manual truth unless the artifact is website-owned and non-derivable elsewhere.
website-owned artifact -> manual	Exception gate	Allowed for public-only artifacts such as curated screenshots, branding/UX copy, published contact details, or hosted downloads, when the artifact has an owner and provenance.
manual -> implementation checkout	Review gate	Manual discoveries should become source contracts, TODOs, tests, HELP changes, or SelfDoc tasks before they become runtime claims.
README replacement	Versioned artifact gate	Preserve the prior README version before replacing it; README history is part of project provenance.

If a manual chat wants to "steal" from the website, it should first ask whether the website text is derivative of the implementation tree. If yes, the manual should return to the original source/manualgen/SelfDoc evidence. If no, the manual may cite or ingest the website artifact only after recording why that artifact is independently maintained.

Front-end naming rule

DotTalk++ Workbench is the family name for front-end/workbench surfaces
Parallel GUI/TUI is the public product lane for aligned graphical and terminal interfaces
Arctic is the code name for the TUI surface
TableTalk is the table-buffering lane, not generic table browsing
Foxtalk and fox-derived names remain valid lineage/subsystem names
Classic FoxPro-style syntax may remain for historical and educational reasons
DotTalk++ should not be described as a clone

Route-bucket naming rule

short route buckets such as /docs/dottalk/* may remain stable for continuity
those route buckets are not the preferred public brand
visible page titles, navigation labels, and prose should use DotTalk++
historical names should be explained, not silently promoted into top-level branding

Educational goal

The stack is meant to teach full-stack thinking from beginning to end:

engine and file/runtime behavior
command shell and automation
HELP, metadata, and contracts
manuals and diagrams
GUI/TUI/front-end work
public website publication

The Laboratory Campus is the natural education-facing and collaboration frame for this goal. LabTalk remains the mark/license name for that area.