tegwick
5a785b9d9f
Align AGENTS.md with the FT-WP- prefix the hub already registered, and rewrite INTENT.md and SCOPE.md, which were still the generated stubs and carried none of the composed-post framing the interface is built around. Fix two artifact inconsistencies: R-1's retry comment still described POST /v1/hall-entries idempotent on entry_id, from before the reframe to composed posts; and the seed pressure record listed only one of the two hypotheses that cite it. Rename it to match its id. Replace the manual T01-T03 route with FT-WP-0002. The Bot API cannot create a bot or a channel, so provisioning is an MTProto client acting as a designated operator account (Canon INT-03), driven from a declared presence spec owned by the campaign. One bounded human bootstrap remains and docs/provisioning.md says why it cannot be removed. 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
114 lines
4.1 KiB
YAML
114 lines
4.1 KiB
YAML
# Declared presence — schema for a campaign's Telegram surface.
|
|
#
|
|
# The instance lives in the campaign repo (pr-hall-of-helix/presence/telegram.yaml).
|
|
# This file is the contract it is validated against, and lives here because the
|
|
# provisioner is here. See docs/provisioning.md.
|
|
$schema: "https://json-schema.org/draft/2020-12/schema"
|
|
$id: "fluid-telegram/presence/telegram.schema.yaml"
|
|
title: "Telegram declared presence"
|
|
type: object
|
|
required: [presence]
|
|
additionalProperties: false
|
|
|
|
properties:
|
|
presence:
|
|
type: object
|
|
required: [schema_version, campaign, interface, bot, channels]
|
|
additionalProperties: false
|
|
properties:
|
|
|
|
schema_version: { const: "0.1" }
|
|
|
|
campaign:
|
|
type: string
|
|
description: >
|
|
Campaign slug. Names the resolved-state file and the OpenBao subtree,
|
|
so it must be stable for the life of the presence.
|
|
pattern: "^[a-z0-9][a-z0-9-]*$"
|
|
|
|
interface:
|
|
type: string
|
|
description: The FLUID interface that will publish through this presence.
|
|
const: "helix-forge-telegram-publishing"
|
|
|
|
bot:
|
|
type: object
|
|
required: [name, about, description]
|
|
additionalProperties: false
|
|
properties:
|
|
name:
|
|
type: string
|
|
maxLength: 64
|
|
description: Display name. What a reader encountering it cold sees first.
|
|
username_preference:
|
|
type: array
|
|
description: >
|
|
Candidate usernames in order. BotFather requires a globally unique
|
|
name ending in "bot" or "_bot", and the first choice is often taken.
|
|
Declaring fallbacks keeps apply from stopping on a collision; the
|
|
one actually issued is recorded in the resolved state.
|
|
items: { type: string, pattern: "^[A-Za-z][A-Za-z0-9_]{3,30}([Bb]ot|_bot)$" }
|
|
minItems: 1
|
|
about:
|
|
type: string
|
|
maxLength: 120
|
|
description: BotFather /setabouttext — shown on the profile before a chat starts.
|
|
description:
|
|
type: string
|
|
maxLength: 512
|
|
description: BotFather /setdescription — shown in the empty chat.
|
|
avatar:
|
|
type: string
|
|
description: >
|
|
Repo-relative path to a square image in the campaign repo.
|
|
Provisioning is content-addressed on its digest, so replacing the
|
|
file is what triggers an update.
|
|
|
|
channels:
|
|
type: object
|
|
required: [test, public]
|
|
additionalProperties: false
|
|
description: >
|
|
Exactly two. The test channel is created first and is where every
|
|
verification runs; nothing reaches the public channel until a person
|
|
has looked at a rendering in the test channel (Canon PUB-01).
|
|
properties:
|
|
test: { $ref: "#/$defs/channel" }
|
|
public: { $ref: "#/$defs/channel" }
|
|
|
|
linked_discussion_group:
|
|
type: boolean
|
|
default: false
|
|
description: >
|
|
Whether the public channel has a linked group for comments. Off by
|
|
default: comments are an inbound surface, and this interface is
|
|
outbound only. Turning it on is a scope change, not a setting.
|
|
|
|
$defs:
|
|
channel:
|
|
type: object
|
|
required: [title, visibility]
|
|
additionalProperties: false
|
|
properties:
|
|
title:
|
|
type: string
|
|
maxLength: 128
|
|
description:
|
|
type: string
|
|
maxLength: 255
|
|
visibility:
|
|
enum: [private, public]
|
|
username_preference:
|
|
type: array
|
|
description: Public channels only. Ordered candidates; a private channel must not declare one.
|
|
items: { type: string, pattern: "^[A-Za-z][A-Za-z0-9_]{4,31}$" }
|
|
admin_rights:
|
|
type: array
|
|
description: >
|
|
Rights granted to the bot. The provisioner clamps this: post_messages
|
|
is the only permitted value, and any other entry fails validation
|
|
rather than being silently dropped. Declared explicitly so that a
|
|
reader of the spec can see the boundary rather than infer it.
|
|
items: { const: post_messages }
|
|
default: [post_messages]
|
|
maxItems: 1
|