Static publishing, package discovery, and agent workflow — a six-week snapshot

Date: 2026-10-04
Status: Complete

A personal site with operational jobs

At first glance, ubunatic.com is a personal website. Its repository does more than hold pages: it publishes project sites, hosts Go vanity import paths, keeps static data visualizations current, and ships the checked-out revision to a self-hosted webroot. The constraint is deliberate: pages are served as-is, with no site build step, framework, or external CDN dependency. That simplicity moves complexity into small maintenance tools and clear publishing checks.

The site’s Go package paths are an example. A page such as /goto has to tell the Go tool where the source repository lives while directing a human visitor to the project. The repository provides a template and a Go checker/ingester. On October 2, issue 032 was closed after the new goto vanity page was verified live; commit 668b830 added the redirect, and 152aa4e injected the shared navigation. The issue captures both implementation and the live verification condition instead of treating a page that merely renders as finished.

Another operational problem was deployment. Before the direct SSH path, publishing depended on a Git pull on the host and its Git LFS integration. Commit bf69b1d added make sync, which runs checks and streams a Git archive to the host through SSH. A separate check, added in 409fe97, makes a stale LFS manifest fail validation. The repository instructions now state an important distinction plainly: pushing source to the remote does not itself deploy the site.

A dashboard that had to earn its data

The /telemetry dashboard gives visitors an interactive view of agent token and tool activity. Its implementation uses static HTML, CSS, JavaScript, SVG and a JSON bundle. Commit f1545d2 added the dashboard; 9809338 later added taxonomic activity categories. There is also a Go data transformer and a Go prose-audit utility in scripts/.

The most instructive design decision was about what not to publish. The project’s September 3 retrospective records that raw agent notes could contain sensitive operational details. The response was to make the public export zero-prose and retain useful aggregate categories instead of publishing free-form notes. That is a stronger boundary than attempting to guess every sensitive phrase with a growing collection of text filters. The public page can show activity patterns without presenting the underlying notes.

This work also exposed a routine agent failure mode. The same retrospective describes an initial Python helper where the project expected Go. The correction became a Go utility, and the experience was captured in issue 031, which proposes an explicit Go-first rule for scripts. A human caught the mismatch early; the project preserved the lesson in its own tracker rather than leaving it only in chat.

What the repository can show

The six-week Git history contains 52 commits, from late August through October 2. They include site features, synced project websites, documentation updates, issue tracking, and maintenance. This is evidence of sustained work, but not proof that every individual change required agents or could not have been made by one developer. More concrete evidence is the repeated use of tickets, verification gates, and retrospectives to coordinate work across the static site and neighboring projects.

The repository has 32 numbered issue files and five existing engineering stories before this one. Its current make check verifies 19 package subpages, 27 subpage asset trees, generated project cards, REUSE licensing for 708 files, and an LFS manifest. Those checks make a broad collection of static pages maintainable without introducing a build system. The task flow documented in docs/AgenticLoop.md describes advisor discovery, sequential implementation, review, process hygiene, and retrospective capture. In this review, the worker role was explicitly single-agent; no delegation was used.

There are limits to the evidence. The scripts/ tree has no Go _test.go files, and the whole-site checks do not substitute for browser usability review. The checks passing is useful, but the repository should not present that as comprehensive application test coverage. The website is a credible home for project links and live demos; its own issue backlog still calls for stronger project narratives and discoverability. The next useful website step is to turn implementation evidence like this case into concise, linked project stories.

Facts