# 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/hall-entries is
      # idempotent on entry_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