Record: the project pages, and publishing through the homelab
Outcome
The project now has real project pages, and they are live at https://labs.bannister.us/projects/gnome-appimage-integration/, published the only way this homelab publishes: the homelab fetched this project’s generated tree, ran its own leak gate and nav injection, and rsynced the whole site to the web server. The project is registered in the homelab’s sources/projects.yaml.
What the Pages Were
site.in/index.txt and site.in/dashboard.txt were still the skeleton’s placeholders — index said “Aim of this project is to provide a common project skeleton”, and the dashboard said “Live state: not configured”. Neither had ever been written for this project, so the published pages described a project that does not exist.
They now say what this project is (an overt replacement for AppImageLauncher), what its current phase is, how the work is installed, what the four programs do, and where the truth lives in the documents and records. The dashboard carries live state, and a new extra page lists what this host actually has integrated.
Live State
The conventions want a state file and __KEY__ placeholders; this project had neither, so site-build.sh only knew __TITLE__. Added:
| Piece | What it does |
|---|---|
scripts/site-state-fetch.sh (make state) |
writes dataflow.out/site-state.txt: FETCHED, HOST, VERSION, RELEASE, INTEGRATED_COUNT, MANAGED_DIR, HANDLER, AUDIT_ERRORS, AUDIT_WARNINGS |
site-build.sh |
substitutes __KEY__ from that file; a key with no value becomes unavailable |
make site |
refreshes the state first, because this host is the owning host |
Every value is run through a tidy filter that turns $HOME into ~ and escapes HTML: the publishing gate refuses home paths, and these values land in HTML. The state file therefore carries no user name, no home path, and no address of any kind.
A placeholder with no state behind it renders as unavailable, so the pages still build on a machine where the tool is not installed.
The Extra Page, and the Phase
appimages.htmlis an extra page, declared insite.in/pages.nav, generated bysite-condense.shfromappimage-integrate listandexplain --json. It lists what this host has integrated with the name, version, path, launcher and state, with paths sanitized to~. Reading it from the tool at build time is the point: the page cannot drift from the desktop it describes.- The phase mechanism was broken here:
PHASES.mdreadCurrent: phase 2 — desktop integration — complete, and the parser insite-condense.shexpected exactly one field after the dash, sosite.out/phase.txtwas never written and the projects list would have shown no phase. The parser now takes the last dash-separated field as the state and validates it against the three allowed values, so the line can carry a description as well as the state.PHASES.mdmoves to phase 4: phase 3 (migrate the AppImageLauncher launchers, add an update path) is complete, and phase 4 (make the project installable: pages, release, install script) is complete.
Sanitizing the Sources
The gate refuses a bare user name, absolute home paths, MAC addresses, private LAN addresses, and key material, and the full text of every prompts, documents and records file is published. Seven files carried eleven absolute home paths — in two documents, four records and a search-path example. All were rewritten to ~, which keeps the meaning and passes the gate. Nothing else tripped it: no MAC addresses, no private addresses, no bare user name. The gate now passes over all 84 generated pages — including this record, whose first version the gate refused for naming the very patterns it describes.
Registration and Publishing
The homelab entry:
- id: gnome-appimage-integration
title: GNOME AppImage integration
summary: >
Reads AppImage files and their desktop entries, and gives an AppImage a
proper place on a GNOME desktop: a launcher, icons, MIME associations, a
context menu, and a window that can inspect, integrate, refresh, migrate,
and update it. Written to be overt where AppImageLauncher was not, and
published with one install script. Detailed pages are published by the
project itself.
created: 2026-09-21
status: active
visibility: public
self_published: true
pages_source: ~/work/gnome-appimage-integration/site.out/repository and readme_source were dropped after tests/07-projects-registry.sh pointed out that they belong to site-generated projects and would be ignored for a self-published one.
Verification
Verified 2026-09-24:
tests/07-projects-registry.sh:28 project(s) valid (24 public, 11 self-published).tests/06-project-pages.sh:gnome-appimage-integration OK (7 nav links, 0 depth sample)andOK (single homelab nav, standard page set, sanitized).- The leak gate over
site.out/: zero matches in 84 pages; every page has a real<title>and the<!-- HOMELAB-NAV -->marker, and none has a<nav>of its own. make deployin the homelab staged eleven project trees and deployed them.- Live:
curlreturns 200 for/projects/gnome-appimage-integration/and each standard page plusappimages.htmland a full-text record page; the pages carry the homelab nav with seven links andaria-current="page"on the current one, the breadcrumb, theGenerated 2026-09-24T01:01:35Z · labs.bannister.usstamp, live dashboard values, and the sanitized AppImage inventory.
Commits
aab2901Publish the project pages: real status, live state, and an inventory: real status and dashboard, live state, and an AppImage inventory