Register with the Custodian State Hub

Domain infotech, workplan prefix PRHOH-WP-. Adds the generated integration
files; the bootstrap workplan is dropped for the same reason as elsewhere.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1361245@bnt-lap001
Assistant-Session: b3b428ef-f3e6-4688-b091-01f71461d66a

.custodian-brief.md

@@ -0,0 +1,27 @@
+<!-- custodian-brief: generated by statehub register; fix-consistency may replace this file -->
+# Custodian Brief - pr-hall-of-helix
+
+**Project:** pr-hall-of-helix
+**Domain:** infotech
+**State Hub:** http://127.0.0.1:8000
+**Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a`
+
+## Open Workplans
+
+### Bootstrap State Hub integration
+
+Workplan file: `workplans/PRHOH-WP-0001-statehub-bootstrap.md`
+
+Open tasks:
+- T01 - Review generated integration files
+- T02 - Verify local developer workflow
+- T03 - Seed first real workplan
+
+## Session Start
+
+1. Read `INTENT.md`, `SCOPE.md`, and `AGENTS.md`.
+2. Check inbox: `GET /messages/?to_agent=pr-hall-of-helix&unread_only=true`.
+3. Scan `workplans/`.
+4. Update task statuses in workplan files as work progresses.
+
+Last generated: 2026-09-04

.gitignore

@@ -0,0 +1,5 @@
+# state-hub: track .claude/rules
+# Claude Code local state (track shared rules; ignore machine-specific files)
+.claude/*
+!.claude/rules/
+!.claude/rules/*.md

AGENTS.md

@@ -0,0 +1,205 @@
+# pr-hall-of-helix — Agent Instructions
+
+## Repo Identity
+
+**Purpose:** Public-relations campaign that composes and publishes posts about hall-of-helix work through the fluid-telegram interface.
+
+**Domain:** infotech
+**Repo slug:** pr-hall-of-helix
+**Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a`
+**Workplan prefix:** `PRHOH-WP-`
+
+---
+
+## State Hub Integration
+
+The Custodian State Hub tracks work across all domains. Codex uses HTTP REST and
+the `statehub` CLI by default. MCP is opt-in because the current Codex MCP bridge
+adds severe call latency; the full administrative MCP surface remains available
+to clients that need it.
+
+| Context | URL |
+|---------|-----|
+| Local workstation | `http://127.0.0.1:8000` |
+| Remote via tunnel | `http://127.0.0.1:18000` |
+| Optional local edge relay | http://127.0.0.1:18080 |
+
+When an operator has enabled the edge relay, set API_BASE to the relay URL.
+Queueable writes return an explicit queued receipt if the central hub is
+unreachable. Treat that as pending local evidence, then ask the operator to run
+statehub outbox status/replay after connectivity returns.
+
+Codex workspace-write sandboxes need network access enabled to reach the host's
+loopback listener. Bootstrap this once with `make -C ~/state-hub configure-codex`
+and restart Codex. The canonical REST health endpoint is `/state/health`, not
+`/health`. If a sandboxed loopback probe fails, retry it with escalated execution
+before declaring State Hub unavailable; a managed Codex permission profile may
+still enforce isolated networking. Experimental MCP can be enabled explicitly
+with `make -C ~/state-hub configure-codex WITH_MCP=1`.
+
+### Orient at session start
+
+```bash
+# Offline brief — works without hub connection
+cat .custodian-brief.md
+
+# Active workplans for this domain
+curl -s "http://127.0.0.1:8000/workplans/?topic_id=cee7bedf-2b48-46ef-8601-006474f2ad7a&status=active" \
+  | python3 -m json.tool
+
+# Check inbox
+curl -s "http://127.0.0.1:8000/messages/?to_agent=pr-hall-of-helix&unread_only=true" \
+  | python3 -m json.tool
+```
+
+Mark a message read:
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
+  -H "Content-Type: application/json" -d '{}'
+```
+
+### Log progress (required at session close)
+
+```bash
+curl -s -X POST http://127.0.0.1:8000/progress/ \
+  -H "Content-Type: application/json" \
+  -d '{
+    "summary": "what was done",
+    "event_type": "note",
+    "author": "codex",
+    "workplan_id": "<uuid>",
+    "task_id": "<uuid>"
+  }'
+```
+
+Omit `workplan_id` / `task_id` when not applicable.
+
+### Update task status
+
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
+  -H "Content-Type: application/json" \
+  -d '{"status": "progress"}'
+# values: wait | todo | progress | done | cancel
+```
+
+### Flag a task for human review
+
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
+  -H "Content-Type: application/json" \
+  -d '{"needs_human": true, "intervention_note": "reason"}'
+```
+
+---
+
+## Session Protocol
+
+**Start:**
+1. `cat .custodian-brief.md` — domain goal and open workplans (offline-safe)
+2. Check inbox: `GET /messages/?to_agent=pr-hall-of-helix&unread_only=true`; mark read
+3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks
+4. Check human-needed tasks: `GET /tasks/?needs_human=true`
+
+**During work:**
+- Update task statuses in workplan files as tasks progress
+- Record significant decisions via `POST /decisions/`
+
+**Close:**
+1. Update workplan file task statuses to reflect progress
+2. If finishing a workplan: hand off **residuals** as live work records first
+   (intake with `origin: residual` + `origin_ref: <WP-id>`, or a next workplan /
+   decision / engagement). Do not park leftovers only in prose or `SCOPE.md`.
+   Canon: `the-custodian/canon/standards/work-record-types_v0.1.md` § Residuals.
+3. Log: `POST /progress/` with a summary of what changed (name handoff ids)
+4. After workplan file changes, run:
+   ```bash
+   uv run --project ~/repo-manager rmgr sync --path . --push
+   ```
+   This assigns only missing deterministic identifiers, verifies the pushed
+   Forgejo commit and `primary/railliance01`, then requests one central
+   reconciliation. A queued receipt is pending evidence; rerun after
+   connectivity returns. Use `statehub fix-consistency` for a separate deep audit.
+
+---
+
+{CREDENTIAL_ROUTING}
+
+<!-- REPO-AGENTS-EXTENSIONS -->
+<!-- Append repo-specific agent instructions below this marker.
+     The state-hub template sync preserves content after this line. -->
+
+---
+
+## Workplan Convention (ADR-001)
+
+Work items originate as files in this repo — not in the hub. The hub is a
+read/cache/index layer that rebuilds from files.
+
+**File location:** `workplans/PRHOH-WP-NNNN-<slug>.md`
+
+**Archived location:** finished workplans may move to
+`workplans/archived/YYMMDD-PRHOH-WP-NNNN-<slug>.md`. The `YYMMDD` prefix is
+the completion/archive date; the frontmatter `id` does not change.
+
+**Ad Hoc Tasks:** small opportunistic fixes discovered during a session use
+`workplans/ADHOC-YYYY-MM-DD.md`, workplan id
+`PRHOH-WP-ADHOC-YYYY-MM-DD`, and task ids
+`PRHOH-WP-ADHOC-YYYY-MM-DD-T01`, etc. `PRHOH-WP` includes its final `-WP`
+token. Unqualified historic `ADHOC-*` ids are grandfathered and must not be
+copied into new records. Use this only for low-risk work completed directly;
+create a normal workplan for anything needing analysis, design, approval,
+dependencies, or multiple phases.
+
+**Frontmatter:**
+
+```yaml
+---
+id: PRHOH-WP-NNNN
+type: workplan
+title: "..."
+domain: infotech
+repo: pr-hall-of-helix
+status: proposed | ready | active | blocked | backlog | finished | archived
+owner: codex
+topic_slug: ...
+created: "YYYY-MM-DD"
+updated: "YYYY-MM-DD"
+state_hub_workstream_id: "<uuid>"   # deterministic UUIDv5; managed by Repo Manager
+---
+```
+
+Use `proposed` for a new draft, `ready` after review against current repo
+state, and `finished` after implementation. `stalled` and `needs_review` are
+derived health labels, not frontmatter statuses.
+
+**Terminology:** workplan is the fleet term; `workstream` appears only in legacy
+API/MCP/frontmatter bridges until `STATE-WP-0069` retires them — see
+`the-custodian/canon/standards/workplan-terminology-fleet_v0.1.md`.
+
+**Task block format** (one per `##` section):
+
+```
+## Task Title
+
+` ` `task
+id: PRHOH-WP-NNNN-T01
+status: wait | todo | progress | done | cancel
+priority: high | medium | low
+state_hub_task_id: "<uuid>"         # deterministic UUIDv5; managed by Repo Manager
+` ` `
+
+Task description text.
+```
+
+Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work.
+
+**Residuals when finishing:** actionable leftovers become live work records
+before `status: finished` — usually an intake (`origin: residual`,
+`origin_ref: PRHOH-WP-NNNN`) or a spawned workplan. Residual is a *role*,
+not a kind. Fleet list lives on State Hub, not in `SCOPE.md`.
+
+To create a new workplan:
+1. Write the file following the format above
+2. Run `uv run --project ~/repo-manager rmgr sync --path . --push`.
+3. Run `statehub fix-consistency` only when a separate deep audit is needed.

INTENT.md

@@ -0,0 +1,24 @@
+---
+repo: pr-hall-of-helix
+updated: "2026-09-04"
+---
+
+# INTENT
+
+## Why it exists
+
+Public-relations campaign that composes and publishes posts about hall-of-helix work through the fluid-telegram interface.
+
+The public-relations campaign that turns `hall-of-helix` work into published posts. The `pr-` prefix marks it as a campaign repository rather than a service.
+
+## Governing principle
+
+This repository should stay focused on the purpose above. Work that changes its
+authority, ownership boundaries, or operational promises should be captured in a
+workplan before implementation.
+
+## What it enables
+
+- A coding agent can understand why the repository exists before changing it.
+- State Hub can register and coordinate work for this repository.
+- Future workplans can stay connected to the repository's intended role.

README.md

@@ -1,3 +1,65 @@
 # pr-hall-of-helix
 
-Marketing campaign and outlet to promote achievements on helix-forge from the hall-of-helix information about work sessions by agents or humans.
+The public-relations campaign that turns `hall-of-helix` work into published
+posts. The `pr-` prefix marks it as a campaign repository rather than a service.
+
+## What this repo owns
+
+- **Composition** — turning a hall entry into a post, and the editorial voice
+  that does it.
+- **Selection** — which work is worth a post, and when.
+- **Consent** — the basis on which HelixForge may write publicly about a named
+  person's work, and the record of it.
+- **Review** — a person reads each post against its source entry before it goes
+  out; their name travels with the post as `reviewed_by`.
+- **Variant strategies** and their competition.
+- **The declared presence** — `presence/telegram.yaml`, because a bot's name and
+  a channel's title are brand, not mechanism.
+
+## What it does not own
+
+Delivery. Posts are published through the FLUID interface
+`helix-forge-telegram-publishing` in [`fluid-telegram`](../fluid-telegram), by a
+single call:
+
+```
+POST /v1/channel-posts
+```
+
+That interface renders and delivers. It never writes, selects, shortens or
+embellishes — a post that will not fit is refused, not truncated. This campaign
+is a *consumer* of it, in cohort `hall-publishing-jobs`, and receives per-variant
+engagement back.
+
+The channel **does not republish entries.** A hall entry is a considered
+first-person account written for a colleague reading a repository; a post is
+short, personal, and written to travel. The post is composed *from* the entry
+and is a different piece of writing. The entry is the source and the check,
+never the payload.
+
+## Status
+
+Stub. The declared presence exists; composition, consent and the review queue do
+not yet. They currently live in `fluid-telegram` under `FT-WP-0001` T06/T07 as a
+temporary arrangement, and move here under `FT-WP-0001` T13 once the loop has
+closed at least once.
+
+## Layout
+
+```
+presence/telegram.yaml    the declared Telegram presence (validated by
+                          fluid-telegram/presence/telegram.schema.yaml)
+presence/assets/          avatar and other brand assets
+```
+
+## Provisioning the presence
+
+From `fluid-telegram`, after the seeding runbook (`docs/seeding-runbook.md`):
+
+```bash
+provision plan  --spec ../pr-hall-of-helix/presence/telegram.yaml
+provision apply --spec ../pr-hall-of-helix/presence/telegram.yaml
+```
+
+Nothing secret belongs in this repo. Tokens, sessions and the redaction salt
+live in OpenBao. See `fluid-telegram/docs/provisioning.md`.

SCOPE.md

@@ -0,0 +1,32 @@
+# SCOPE
+
+> This file was generated by `statehub register`. Refine it as the repository
+> boundaries become clearer.
+
+## One-liner
+
+Public-relations campaign that composes and publishes posts about hall-of-helix work through the fluid-telegram interface.
+
+## Core Idea
+
+pr-hall-of-helix exists to provide the capability described in INTENT.md.
+
+## In Scope
+
+- Maintain the repository's primary implementation.
+- Keep docs, tests, and operational metadata current.
+
+## Out of Scope
+
+- Own unrelated adjacent systems.
+- Make irreversible operational decisions without human approval.
+
+## Current State
+
+- Status: active; implementation and stability should be verified by the repo agent.
+
+## Getting Oriented
+
+- Start with: INTENT.md
+- Agent instructions: AGENTS.md
+- Workplans: workplans/

presence/assets/README.md

@@ -0,0 +1,17 @@
+# Brand assets
+
+## helixforge-avatar.png — MISSING
+
+`presence/telegram.yaml` references `presence/assets/helixforge-avatar.png`.
+It does not exist yet, and `provision apply` will fail on `/setuserpic` until
+it does.
+
+Requirements: square, at least 512×512, PNG. Telegram crops to a circle, so
+keep the mark clear of the corners.
+
+Deliberately not generated. This is the first thing a stranger sees of
+HelixForge on Telegram, and it should be a considered choice rather than a
+placeholder that quietly becomes permanent.
+
+Provisioning is content-addressed on the file's digest, so replacing this file
+is what triggers an avatar update on a later `apply`.

presence/telegram.yaml

@@ -0,0 +1,67 @@
+# The declared Telegram presence for the Hall of Helix campaign.
+#
+# This file is the campaign's, because it is editorial: the bot's name, its
+# description, and the channel titles a stranger reads are brand, not mechanism.
+#
+# It is consumed by the provisioner in fluid-telegram, which validates it against
+# presence/telegram.schema.yaml there and reconciles Telegram to match:
+#
+#   provision plan  --spec ../pr-hall-of-helix/presence/telegram.yaml
+#   provision apply --spec ../pr-hall-of-helix/presence/telegram.yaml
+#
+# Nothing secret belongs here. See fluid-telegram/docs/provisioning.md.
+presence:
+  schema_version: "0.1"
+  campaign: "hall-of-helix"
+  interface: "helix-forge-telegram-publishing"
+
+  bot:
+    name: "HelixForge"
+
+    # BotFather requires a globally unique username ending in "bot" or "_bot",
+    # and a good first choice is usually taken. Fallbacks keep apply from
+    # stopping on a collision; the one actually issued is recorded in
+    # fluid-telegram/presence/resolved/hall-of-helix.yaml.
+    username_preference:
+      - "HelixForgeBot"
+      - "HelixForgeHallBot"
+      - "HelixForgePublishBot"
+
+    about: >-
+      Short notes on the work going into HelixForge, and the people doing it.
+
+    description: >-
+      HelixForge turns intent into structure, structure into capability, and
+      capability into lasting progress. The Hall of Helix is where the people
+      and sessions doing that work are acknowledged. This channel carries short
+      accounts of it, each linking back to the entry it was written from.
+
+    avatar: "presence/assets/helixforge-avatar.png"
+
+  channels:
+    # Created first. Every rendering is checked here, and nothing reaches the
+    # public channel until a person has looked at one.
+    test:
+      title: "HelixForge — rendering checks"
+      description: >-
+        Private. Publications land here first so a person can see them rendered
+        before any subscriber does. Nothing here is published.
+      visibility: private
+      admin_rights: [post_messages]
+
+    public:
+      title: "Hall of Helix"
+      description: >-
+        Short notes on the work going into HelixForge, and the people doing it.
+        Each post links to the entry it was written from.
+      visibility: public
+      username_preference:
+        - "hallofhelix"
+        - "halloftheHelix"
+        - "helixforgehall"
+      admin_rights: [post_messages]
+
+  # Comments are an inbound surface; this interface is outbound only. Turning
+  # this on is a scope change rather than a setting — it creates a moderation
+  # obligation that nothing in the current design carries.
+  linked_discussion_group: false