tegwick
1e9481e108
plan --check treated BotFather profile reassertion as drift, so a scheduled check could never go quiet. Reassertion is now its own kind; a changed spec digest is the drift signal. apply reasserts the profile, updates channel copy when the spec changes, and is tested against a fake Telegram surface. The adapter reads its chat id from resolved state and its token from OpenBao, never the operator session. IEI-2 records that an approved provisioning plan is not autonomous Daimon action. Assistant: grok Assistant-Session: 01a09d5a-92c1-7802-915b-92bee57fc9f0
18 lines
1 KiB
Markdown
18 lines
1 KiB
Markdown
# fluid-telegram
|
|
|
|
Fluid interface for telegram messaging and interaction platform.
|
|
|
|
## Status
|
|
|
|
The FLUID interface `helix-forge-telegram-publishing` is prepared but not yet
|
|
live. Governance, contract, seed hypotheses, the adapter's connector contract
|
|
and the presence provisioner are in place; the bot, the channel and the adapter
|
|
itself are not. The first live apply waits on the operator seeding runbook.
|
|
|
|
- Governance: [`InterfaceEvolutionIntent.md`](InterfaceEvolutionIntent.md)
|
|
- The channel publishes composed posts written *from* hall entries, not the
|
|
entries themselves. Composition happens upstream and moves to
|
|
`pr-hall-of-helix` once the loop has closed once (FT-WP-0001 T13).
|
|
- Work: [`workplans/FT-WP-0001-telegram-identity-and-hall-channel.md`](workplans/FT-WP-0001-telegram-identity-and-hall-channel.md)
|
|
- Provisioning: [`workplans/FT-WP-0002-declared-presence-provisioning.md`](workplans/FT-WP-0002-declared-presence-provisioning.md)
|
|
- Handover from fluid-core: `fluid-core/docs/handover/fluid-telegram.md`
|