@particle-academy/telegram-js 0.2.0 → 0.3.0

package/CHANGELOG.md

@@ -8,6 +8,40 @@ The four packages share one version, because they are generated from one
 `provider/` definition and a version that meant something different in each
 would be a version nobody could reason about.
 
+## [0.3.0] — 2026-08-24
+
+### Added
+
+- **The README now says how to SET THIS CONNECTOR UP**, in the package itself.
+
+Until now it explained what the four packages are, what they cost and why the
+repo is generated — and said nothing about credentials, scopes, sandboxes or
+operations. Somebody who installed it could not learn from it which credentials
+a connection needs, where a human GETS them, which scopes to request, or what
+the connector can actually do. All of that was already in the definition; the
+one document a consumer reads was the one that omitted everything actionable.
+
+The new **Setting it up** section carries:
+
+- every credential, with the text saying where the value comes from, whether it
+  is **per installation** or **per connected account**, and whether it is secret;
+- the OAuth authorize and token URLs and the exact scopes, verbatim;
+- the access-token lifetime, and where refresh tokens ROTATE, the two things a
+  host must not do — retry a failed refresh, or refresh concurrently — because a
+  replay revokes the entire grant and nothing in the failure says why;
+- the estate in this provider's own terms, including the cases where a
+  successful-looking run reaches nobody, or reaches the real one;
+- every action and trigger with its method, path, inputs, and whether it is safe
+  to replay;
+- a trigger's provider-side setup, which nobody can derive from anything else.
+
+It is **generated from `provider/manifest.json`**, so it cannot drift from what
+the packages do — which is the point at a few hundred providers, where a
+hand-written setup section is a few hundred documents going quietly stale.
+
+No code changed. This release exists because a registry and an installing agent
+read the PUBLISHED artifact, and the artifact carried the old README.
+
 ## [0.2.0] — 2026-08-24
 
 ### Changed
@@ -86,3 +120,4 @@ rules say not to take on a consumer's behalf.
 
 [0.1.0]: https://github.com/Fancy-Friends/telegram/releases/tag/v0.1.0
 [0.2.0]: https://github.com/Fancy-Friends/telegram/releases/tag/v0.2.0
+[0.3.0]: https://github.com/Fancy-Friends/telegram/releases/tag/v0.3.0

package/README.md

@@ -27,6 +27,40 @@ dependencies.
 subject to the kit's full approval bar, and one per provider is hundreds of
 dependencies nobody is tracking.
 
+## Setting it up
+
+Everything below is generated from `provider/manifest.json`, so it cannot disagree with what the packages do.
+
+### Credentials
+
+A Telegram connection holds 1 value.
+
+Every value here is `account` scope: one per connected account, not one per installation.
+
+| Field | Scope | Secret | Where it comes from |
+|---|---|---|---|
+| **Bot token** | per connected account | **secret** | From @BotFather — 123456:ABC-DEF… . A bot registered in the test environment is a DIFFERENT bot with a different token; the same token does not reach both. |
+
+### The estate
+
+Telegram has a test estate on the same host, reached with credentials from a SEPARATE test account you register. Selecting sandbox mode uses those credentials.
+
+> Telegram's test environment is a genuinely SEPARATE ACCOUNT: you create a new account inside it and register a new bot there, so the sandbox credential is a different token rather than the same one pointed elsewhere. The `/test` path segment is how you reach it; the account is what makes it separate. Flood limits are NOT relaxed there, so it is a place to test, not a place to hammer.
+
+## What it can do
+
+### Triggers
+
+#### `get_updates` — Telegram message
+
+Start a run when a Telegram bot receives an update (long polling, not a webhook).
+
+Polls Telegram, no more often than every 1 seconds.
+
+**You have to set this up with the provider first:**
+
+The host polls getUpdates on a schedule and persists the `offset` cursor between calls, passing the last `cursor` back in — Telegram queues nothing once an offset has acknowledged it, so a lost cursor is lost updates. getUpdates and setWebhook are MUTUALLY EXCLUSIVE for one bot: a host running both gets neither.
+
 ## Run it before you have credentials
 
 Every operation ships a **faker**, whether or not Telegram has a sandbox. Set a

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@particle-academy/telegram-js",
-  "version": "0.2.0",
+  "version": "0.3.0",
   "description": "Telegram for Node — the service descriptor, its faker, its webhook verification, and one function per operation. Plain HTTP on @particle-academy/fancy-connector-core; no vendor SDK.",
   "repository": {
     "type": "git",
@@ -52,7 +52,7 @@
   },
   "peerDependencies": {
     "@particle-academy/fancy-flow": ">=0.47.1 <2.0",
-    "@particle-academy/telegram-ui": "0.2.0"
+    "@particle-academy/telegram-ui": "0.3.0"
   },
   "peerDependenciesMeta": {
     "@particle-academy/fancy-flow": {