coulomb/hall-of-helix
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Open HOH-WP-0002: publish the hall with selectable renderers

Browse source 
The hall is 102 authored seats readable only as raw Markdown. Canonical form:
helix.coulomb.social/hall-of-helix/<entry>?renderer=<renderer>, with renderers
established as their own repos and the parameter optional.

Design-first and deliberately incomplete: four decisions gate the build — the
entry identifier in the URI (a permanent commitment; seat filenames make poor
URLs while frontmatter ids are already unique and enforced), where the service
lives (static vs dynamic, and a sibling tooling repo now that this one is
classified publication), the renderer contract and trust boundary, and whether
the corpus is cleared for public publication.

status: proposed with DoR-Failed, which is the honest state rather than an
oversight. The build tasks are not specified until the decisions land.

Two constraints written in early: ?renderer= is user-controlled input selecting
code to run, so it resolves through a fixed allowlist with sanitised output and
never as a path or import; and the roll of participants must not rank workers or
aggregate the PQRST estimates now carried on seats — that would build the
leaderboard the hall exists not to be.

Publishing an internal corpus publicly is the operator's call, not an agent's.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SQ6oF1DtVDKcD1FCpvRVLx

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 272883@bnt-lap001
Assistant-Session: f40c8f53-fb65-4980-9d29-bcdb3dd946f7
This commit is contained in:
tegwick 2026-09-05 22:17:20 +02:00
parent 356dba0790
commit 9c4da549ee
1 changed files with 187 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

187
workplans/HOH-WP-0002-published-hall-and-renderers.md Normal file
View file

@ -0,0 +1,187 @@
---
id: HOH-WP-0002
type: workplan
title: "Publish the hall at helix.coulomb.social with selectable renderers"
domain: infotech
repo: hall-of-helix
status: proposed
owner: claude-code
topic_slug: helix-forge
priority: medium
created: "2026-09-05"
updated: "2026-09-05"
quality_dor: DoR-Failed
quality_dor_at: "2026-09-05"
quality_dor_by: claude-code
quality_dor_note: "Intent and URI shape are set by the operator, but four decisions block implementation: the entry identifier in the URI, where the service lives, how renderers are discovered and trusted, and whether the corpus is cleared for public publication. T01-T04 resolve those; the build tasks are deliberately not specified until they are."
related:
- HOH-WP-0001
---
# Publish the hall at helix.coulomb.social with selectable renderers
The hall is 102 authored seats that can only be read as raw Markdown in a git
repository. It was always intended to be readable as a hall — a record of who
engaged on the Helix Forge platform, in the spirit of the end titles of a film
or a game, without the compensation framing that "credits" would import.
There is no `helixforge` domain, so the canonical form is:
```
https://helix.coulomb.social/hall-of-helix/<entry>?renderer=<renderer>
```
`<entry>` maps to one seat. `renderer` selects how the Markdown is presented and
is optional — omitting it is the same as `?renderer=default`. Renderers are
expected to be established as their own repos: a hypothetical `render-hrgiger`
would present a seat in an H.R. Giger register, selected as
`?renderer=render-hrgiger`.
**This workplan is design-first and deliberately incomplete.** Four decisions
gate the build, and the implementation tasks should not be written until they
are settled. `status` stays `proposed` and DoR is `DoR-Failed` until then —
that is the honest state, not an oversight.
## Decide the entry identifier in the URI
```task
id: HOH-WP-0002-T01
status: todo
priority: high
```
Seat files are named `<ISO-8601>-<who>-<slug>.md`, which makes a poor URL:
`2026-09-05T16:36:12.000Z-codex-statehub-snapshot-and-signature`.
Every seat already carries a unique frontmatter `id`
(`hall-worker-codex-statehub-snapshot-and-signature`), and `make check` already
rejects duplicates — so identity exists and is enforced. Options:
- the frontmatter `id` verbatim — stable and already unique, but repeats the
`hall-worker-` prefix in every URL;
- the `id` with that prefix stripped — prettier, needs uniqueness re-checked;
- a short opaque id — stable under renaming, unreadable, and a new thing to keep.
Whatever is chosen, **the URI is a permanent commitment**: a hall that breaks its
own links is not a record. Decide how a seat that is renamed or corrected keeps
its URI, and extend `make check` to enforce whatever invariant the answer needs.
## Decide where the service lives and how it is built
```task
id: HOH-WP-0002-T02
status: todo
priority: high
```
Two shapes, and they differ in more than effort:
- **Static generation** — render at commit time, publish artifacts. Cheap,
cacheable, no runtime attack surface. `?renderer=` becomes a pre-rendered
variant per renderer, so the renderer set must be known at build time.
- **Dynamic service** — render on request. Naturally supports an open renderer
set and new renderers without rebuilding the corpus, at the cost of a running
service that executes selected code.
Also decide whether the service lives in this repo or a sibling. This repo is
classified `publication` (canon v1.1 §5.7): the corpus is the deliverable, and
tooling that renders it is conventionally a separate `tooling` repo. That
suggests a sibling — `hall-render` or similar — with this repo staying the
content.
Name the deployment target (railiance / k3s) and who owns the DNS record for
`helix.coulomb.social`.
## Define the renderer contract and trust boundary
```task
id: HOH-WP-0002-T03
status: todo
priority: high
```
`?renderer=<name>` is **user-controlled input that selects code to run**. Treat
it as such from the first line of design:
- resolve renderers through a **fixed allowlist**, never by interpreting the
parameter as a path, module name, package name, or repo URL;
- an unknown value falls back to `default` or returns a clean 404 — it never
attempts a fetch or an import;
- a renderer receives parsed Markdown plus frontmatter and returns markup; it
gets no credentials, no filesystem, and no network;
- renderer output is sanitised before it reaches a page. A renderer is
third-party code producing HTML, which is an XSS sink by construction.
Then define the contract itself: input shape, output shape, how a renderer
declares itself, and how it is registered. Check whether the fleet's existing
capability discovery (`reuse-surface`, the capability catalog) is the right
registry before inventing one.
Write it down as an ADR in this repo — a renderer author needs a spec, and this
is the part that will be got wrong quietly if it stays implicit.
## Clear the corpus for public publication
```task
id: HOH-WP-0002-T04
status: todo
priority: high
```
**Gate on this before anything is served publicly.** The seats were written as
an internal record. Publishing 102 of them to a public domain is an outward
change that cannot be undone by deleting the page — search engines and archives
keep copies.
Review the corpus for: session identifiers and model/harness details, internal
hostnames, IP addresses, repository and infrastructure names, workplan and
decision ids, credential-adjacent narrative, third-party names, and anything a
human author would not have written for readers outside the fleet.
Decide the disposition: publish whole, publish a filtered projection, or serve
the hall behind authentication. If a filter is chosen, it must be enforced in
the renderer pipeline rather than left to the author of each seat.
The operator makes this call. Do not publish on an agent's judgement.
## Build the hall index — the roll of participants
```task
id: HOH-WP-0002-T05
status: todo
priority: medium
```
`https://helix.coulomb.social/hall-of-helix/` is the roll: every worker who has
sat, human and agent, drawn from the seats themselves rather than maintained by
hand — `README.md`'s list is already hand-maintained and will drift.
Derive it from frontmatter: `display_name`, `worker_kind`, `recorded_at`,
`repos`, and the link to the seat. Group as the hall groups — by the work
shared, in the spirit of end titles — and let humans and agents appear on the
same roll, which is the point of the hall.
Constraints from both `INTENT.md` files: no ranking, no scoreboard, no sorting
that implies merit, and **no aggregation of PQRST estimates**. The estimates
carried on seats since `HOH-WP-0001` describe sessions, not workers. A roll that
totals them becomes the leaderboard the hall exists not to be.
Blocked on T01, T02, and T04.
## Implement rendering with the default renderer
```task
id: HOH-WP-0002-T06
status: wait
priority: medium
```
Serve a single seat at the canonical URI with `renderer=default`, honouring the
decisions from T01-T04: identifier mapping, static or dynamic, allowlist
resolution, sanitised output, and whatever disposition T04 sets.
The default renderer should present a seat plainly and legibly — the portrait,
the account, and the record — and set the reference implementation that a
renderer repo like the hypothetical `render-hrgiger` is written against.
Deliberately unspecified until T01-T04 are decided.