fluid-telegram/revisions/R-1.yaml
tegwick 5a785b9d9f Ground the repo docs and move presence provisioning to a declared spec
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
2026-09-04 19:21:08 +02:00

52 lines
1.5 KiB
YAML

# Revision descriptor for R-1.
#
# Fill in the digest and upstream, then publish through the pipeline:
#
# fluid revision publish --file revisions/R-1.yaml \
# --key-file "$FLUID_SIGNING_KEY" \
# --adaptation-classes presentation \
# --approved-by "$USER" --traffic-share 1.0
#
# The digest is the sha256 of contracts/r1.openapi.yaml:
# printf 'sha256:%s' "$(sha256sum contracts/r1.openapi.yaml | cut -d' ' -f1)"
revision:
schema_version: "0.1"
id: "R-1"
interface: "helix-forge-telegram-publishing"
state: "stable"
contract:
type: "openapi"
digest: "sha256:<digest of contracts/r1.openapi.yaml>"
source: "contracts/r1.openapi.yaml"
runtime:
upstream: "http://fluid-telegram-adapter:8080"
# Telegram rate-limits channel posts to roughly 20 per minute. A generous
# timeout is correct here: publication is not latency-sensitive, and
# failing fast would turn a rate limit into a lost entry.
timeout_ms: 30000
retry:
# Only GET is retried by the connector. POST /v1/channel-posts is
# idempotent on post_id, but the retry decision stays with the adapter,
# which knows whether Telegram accepted the message.
max_attempts: 1
circuit_breaker:
failure_threshold: 5
reset_after_ms: 60000
intent:
version: "IEI-1"
routing:
eligible_cohorts:
- "hall-publishing-jobs"
- "helix-forge-agents"
- "operators"
max_traffic_share: 1.0
policy:
compatibility: "additive"
security_check: "passed"
policy_check: "passed"
rollback_to: null