coulomb/fluid-telegram
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add the operator seeding runbook and enforce the presence schema

Browse source 
Loosen the all-or-nothing stance on provisioning: where a platform has no
API to seed access, a guided runbook is the right answer. docs/seeding-runbook.md
covers the three Telegram steps that cannot be automated, and each carries a
"why not automated" line so the judgement can be revisited rather than
inherited. Telegram's steps resist automation incidentally -- nobody built
the endpoints -- unlike a control such as KYC, which resists by design and
where a weak component would be a defect rather than an opening.

Fix the schema's $id, which was a relative path and broke $ref resolution in
ordinary validators, and add the visibility/username constraint the field
descriptions already claimed. Both specs now validate, and the rejections are
tested.

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
This commit is contained in:
tegwick 2026-09-04 19:30:54 +02:00
parent d26c4619b8
commit f06be1f949
4 changed files with 211 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

16
docs/provisioning.md
View file

@ -28,8 +28,20 @@ creation, visibility, administrator rights, the redaction salt — is declared a
reconciled.
That is the honest boundary. This is not "no human steps"; it is **one bounded
bootstrap, then a declared surface that converges.** The steps that remain are
the ones Telegram places outside any API on purpose.
bootstrap, then a declared surface that converges.**
Those steps are not left to improvisation. `docs/seeding-runbook.md` guides them:
what to have ready, what to do, what to record and where, and — for each one — why
it could not be automated. A manual step is acceptable when it is guided,
repeatable and bounded, and unacceptable when it is merely undocumented.
Worth distinguishing two reasons a step resists automation, because they age
differently. A KYC check resists *by design*; automating it would defeat its
purpose, and a component weak enough to permit it is a defect rather than an
opportunity. A web form that mints an API key resists only *incidentally*,
because nobody built the endpoint. All three Telegram steps are the second kind —
none is a fraud control — so each is a candidate for removal the moment the
platform changes.
## Where the specification lives