Documentation maintenance and Lorekeeper handover

Overview · Build and release · Architecture · Operations

Import into Lorekeeper

The handover unit is the entire docs/olympus-deployment folder. It contains ordinary UTF-8 Markdown and local image assets. It has no dependency on Codex chat history, a build machine's user profile, private file URLs, or the ignored artifacts directory.

1. Copy/import the folder into the chosen company documentation area.
2. Use README.md as the overview/landing page.
3. Add the remaining pages to Lorekeeper navigation in this order: build/release, architecture, Olympus integration, service contract, operations, maintenance.
4. Preserve filenames and the images subfolder so relative page/image links resolve. If the import system assigns page/asset IDs instead, rewrite the links during that import and check every image/navigation link afterward.
5. Check the architecture Mermaid diagram. If the target Lorekeeper renderer does not support Mermaid, render that block to a static diagram as part of the import rather than removing the accompanying component explanation.
6. Apply the company's internal engineering access policy. The pages include an internal deployment endpoint and operational details; no external publication was performed when creating this package.

There is no assumed Lorekeeper-specific import API, navigation schema, or automatic publishing configuration in this repository. The relative file structure is the portable source. A ZIP copy under artifacts/documentation is a convenience export; update the source pages first, then regenerate that export.

Image assets and provenance

The captions deliberately distinguish a live screenshot from a controlled form render. Neither is an application functional-health test. Example progress numbers and error text are not a record of a production incident. Keep the same distinction when replacing images.

The setup's actual native title bar is visible in its screenshot. Do not substitute the earlier borderless layout concept and describe it as a native capture. The launcher itself is borderless; its bitmap renders do not capture compositor shadows/corner effects as a desktop screenshot would.

Refresh screenshots

1. Build the intended bootstrap release and identify its version, CPU, agent mode, and source revision.
2. Preview the setup welcome/progress/maintenance screens in a suitable test account. A screenshot task must not click Install/Uninstall merely to obtain an attractive frame on a developer's production account. If an operator is already running setup, capture without changing their operation.
3. Capture only the target window. Keep desktop documents, personal information, private URLs, and unrelated windows out of the image. Do not alter the displayed messages to imply a test that did not run.
4. Use controlled launcher states or an isolated local feed; do not contact the production service merely to create a download animation. Label simulated states.
5. Preserve the actual CODE Group logo at the top-right of setup, the version at the bottom-left, native label colors, and readable image scale. Inspect 100% and scaled views of the built UI.
6. Replace the corresponding images asset and update its caption/provenance/date when meaningful. Keep the filename stable if the same illustration role remains appropriate.

The original CODE Group logo and setup artwork generator live under installer/Olympus.Setup/Assets and scripts/New-InstallerArtwork.ps1. Launcher art and the approved icon live in Olympus.Launcher/Assets. Those are product source assets, not substitutes for verification screenshots.

Verification and remaining work

On October 21, 2026, documentation preparation re-ran the Release solution build successfully with zero warnings/errors and the dependency-free application suite passed 127 checks. The current MSI contract checker has 18 assertions per CPU. The installer work also built both CPU packages, validated their tables, and verified embedded MSI/theme/artwork content. These results apply to their tested source/build context, not automatically to future releases.

The available development packages use the explicitly selected managed agent and are unsigned. Native AOT remains the release default in the build script; compiler/linker availability and native publication must be verified on release build agents. Do not describe the development packages as signed production releases.

The screenshot shows a running setup operation, not its final outcome. Complete installation/upgrade/uninstall behavior, the earlier per-user MSI cache-path error, real logon execution, production signing, and the full native-machine matrix remain release-validation work. A prior real-process dummy smoke check is useful fixture evidence, not proof of production Olympus integration.

Track these items with named owners/release evidence in the company project system:

Keep the docs aligned with source

Update the relevant pages whenever changes affect project versions, supported CPUs, SDK/WiX versions, publish flags, endpoint/query parameters, service parsing, policy/timeout behavior, file/registry ownership, IPC/environment variables, minimum versions, or taskbar identity. Check code rather than copying older README claims.

Stable identifiers such as the AppUserModelID, pipe protocol/name, registry paths, UpgradeCodes, and data epoch require an explicit compatibility decision before changing them. Display-brand changes alone do not justify changing those identifiers.

For each documentation release, verify relative links, image files/captions, fenced code blocks, copyable build commands, external reference URLs, and the distinction between implemented behavior, example data, and remaining integration work. Keep the overview concise; put operational detail on its owning page.