diff --git a/.custodian-brief.md b/.custodian-brief.md deleted file mode 100644 index 082bcc2..0000000 --- a/.custodian-brief.md +++ /dev/null @@ -1,27 +0,0 @@ - -# 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 deleted file mode 100644 index e4e0199..0000000 --- a/.gitignore +++ /dev/null @@ -1,5 +0,0 @@ -# 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 deleted file mode 100644 index b52bc20..0000000 --- a/AGENTS.md +++ /dev/null @@ -1,205 +0,0 @@ -# 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 deleted file mode 100644 index 509c54f..0000000 --- a/INTENT.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -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/README.md b/README.md index 2250806..88b2e25 100644 --- a/README.md +++ b/README.md @@ -1,65 +1,3 @@ # pr-hall-of-helix -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`. +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 diff --git a/SCOPE.md b/SCOPE.md deleted file mode 100644 index 245c23e..0000000 --- a/SCOPE.md +++ /dev/null @@ -1,32 +0,0 @@ -# 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/ diff --git a/presence/assets/README.md b/presence/assets/README.md deleted file mode 100644 index 85883e3..0000000 --- a/presence/assets/README.md +++ /dev/null @@ -1,17 +0,0 @@ -# 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 deleted file mode 100644 index 1999155..0000000 --- a/presence/telegram.yaml +++ /dev/null @@ -1,67 +0,0 @@ -# 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