From 305e6cd31340f7902fac544d6ce29ad19b48d6b7 Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 4 Sep 2026 19:30:39 +0200 Subject: [PATCH 1/2] Declare the Telegram presence and state the campaign's boundary The presence spec is editorial -- a bot's name, its description and the channel titles a stranger reads are brand, not mechanism -- so it belongs to the campaign rather than to the delivery interface. fluid-telegram's provisioner consumes it by path, which keeps that interface reusable by campaigns other than this one. The avatar is referenced but deliberately absent: it is the first thing a stranger sees of HelixForge on Telegram, and a generated placeholder would quietly become permanent. Co-Authored-By: Claude Opus 5 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 --- README.md | 64 ++++++++++++++++++++++++++++++++++++- presence/assets/README.md | 17 ++++++++++ presence/telegram.yaml | 67 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 147 insertions(+), 1 deletion(-) create mode 100644 presence/assets/README.md create mode 100644 presence/telegram.yaml diff --git a/README.md b/README.md index 88b2e25..2250806 100644 --- a/README.md +++ b/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. \ No newline at end of file +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`. diff --git a/presence/assets/README.md b/presence/assets/README.md new file mode 100644 index 0000000..85883e3 --- /dev/null +++ b/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`. diff --git a/presence/telegram.yaml b/presence/telegram.yaml new file mode 100644 index 0000000..1999155 --- /dev/null +++ b/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 From 3431a6eb91bebc6501f8859c06ab919903e4a0f1 Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 4 Sep 2026 19:57:31 +0200 Subject: [PATCH 2/2] 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 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 | 27 ++++++ .gitignore | 5 ++ AGENTS.md | 205 ++++++++++++++++++++++++++++++++++++++++++++ INTENT.md | 24 ++++++ SCOPE.md | 32 +++++++ 5 files changed, 293 insertions(+) create mode 100644 .custodian-brief.md create mode 100644 .gitignore create mode 100644 AGENTS.md create mode 100644 INTENT.md create mode 100644 SCOPE.md diff --git a/.custodian-brief.md b/.custodian-brief.md new file mode 100644 index 0000000..082bcc2 --- /dev/null +++ b/.custodian-brief.md @@ -0,0 +1,27 @@ + +# 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 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e4e0199 --- /dev/null +++ b/.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 diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..b52bc20 --- /dev/null +++ b/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//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": "", + "task_id": "" + }' +``` + +Omit `workplan_id` / `task_id` when not applicable. + +### Update task status + +```bash +curl -s -X PATCH "http://127.0.0.1:8000/tasks/" \ + -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/" \ + -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: `, 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} + + + + +--- + +## 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-.md` + +**Archived location:** finished workplans may move to +`workplans/archived/YYMMDD-PRHOH-WP-NNNN-.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: "" # 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: "" # 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. diff --git a/INTENT.md b/INTENT.md new file mode 100644 index 0000000..509c54f --- /dev/null +++ b/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. diff --git a/SCOPE.md b/SCOPE.md new file mode 100644 index 0000000..245c23e --- /dev/null +++ b/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/