Documentation menu
Getting started
New in v2.0
Feature deep dives
Reference
Status
Forwarding Feature Status & Roadmap
An honest implemented / partial / planned board for AutoTelegramForward, generated from the feature catalog on every build with the reason each is unfinished.
Verified against the checkout built for v2.2.4 · updated 20 Oct 2026
This page does not have an opinion about what is finished. It renders the catalog the repository maintains for itself: docs/feature_catalog.json, read at build time and shown verbatim. 18 features are listed — each one either implemented, partially implemented, or planned.
The three counts sum to 18. A row is implemented only when the catalog records IMPLEMENTED for it; anything the catalog marks PARTIALLY_IMPLEMENTED or NOT_IMPLEMENTED is shown as partial or planned here, with the reason.
Implemented 14
Shipped and reachable through the clients and entry points the catalog names. Where a completion condition is recorded, it is what the feature had to prove to leave this list.
- Create forwarding ruleImplementedwebbotmobileminiapp
Completion condition: rule row committed with generated id and owner_user_id
- Update forwarding rule (optimistic concurrency)Implemented
Completion condition: version-bumped UPDATE committed; version conflict returns explicit error
- Pause/resume rule with durable queue semanticsImplemented
Completion condition: paused rules never forward new messages; queued jobs deferred with backoff; resume unblocks RETRY_WAIT jobs
- Durable message forwarding pipelineImplemented
Completion condition: Telegram API confirms delivery (target_msg_id > 0); UNKNOWN on timeout; DLQ after max retries
- Branding hop (A -> C -> B) composed with every message transformImplemented
Completion condition: the processed message is posted into C once per deliverable and the target receives a forward of C; transforms run exactly once (never skipped or doubled by the worker); any hop failure falls back to a direct A -> B delivery
- SHA-256 content fingerprint deduplicationImplemented
No completion condition recorded in the catalog.
- Keyword-triggered reply add-onImplemented
No completion condition recorded in the catalog.
- Central Logger gRPC microserviceImplemented
Completion condition: durable insert before ack; bounded queue with drop-oldest shedding counter
- End-to-end correlation ID propagationImplemented
Completion condition: ID extracted/generated at gateway, echoed in response, propagated via gRPC metadata, persisted in queue job payload
- Web DevOps log explorer with live stream, filters, stats, purgeImplemented
No completion condition recorded in the catalog.
- Field-aware secret redaction in logs/errorsImplemented
No completion condition recorded in the catalog.
- Dead-letter queue inspect/replay/purge with tenant scopingImplemented
No completion condition recorded in the catalog.
- Telegram timeout classified as OUTCOME_UNCONFIRMED (never silent success/failure)Implemented
No completion condition recorded in the catalog.
- Service topology live health probingImplemented
No completion condition recorded in the catalog.
Partially implemented 2
The catalog marks these PARTIALLY_IMPLEMENTED, so the site does not present them as finished. Each row states exactly what is missing.
- Database query error/latency eventsPartially implemented
- core/infrastructure/persistence/postgres_repositories.py#_execute_db/_fetch_all_db
- core/infrastructure/persistence/database.py#SqliteDatabase.execute
- Transactional audit / outbox for business mutationsPartially implemented
- [new] core/infrastructure/persistence/audit_outbox.py
- scripts/postgres/schema.sql#audit_events/audit_outbox
An entry point marked
[new]is one the catalog records as newly planned rather than as a runtime path the pipeline reaches today.
Planned 2
The catalog records these NOT_IMPLEMENTED. Each of their entry points is marked (new) — recorded as planned rather than as a path the pipeline reaches today — so nothing here is described as working.
- Slow-query threshold monitoring with configurable limitsNot implemented
- [new] core/infrastructure/persistence/db_observability.py
- Bounded-label metrics aggregation (per-feature latency, error rates)Not implemented
- [new] core/infrastructure/persistence/db_observability.py#metrics
How this list is produced
The single source of truth is docs/feature_catalog.json at the root of the repository. On every build, scripts/sync-repo-content.mjs reads that file and writes it intosrc/data/repo-info.json as featureCatalogDetail and featureCatalogStatus, which this page reads directly. No feature name, status or count on this page is typed by hand, so the site cannot claim more than the repository does.
Source of truth
docs/feature_catalog.json
Built by
scripts/sync-repo-content.mjs
Rendered from
repoInfo.featureCatalogDetail
Catalog state for AutoTelegramForward v2.2.4 (commit 23bafe6): 14 implemented, 2 partial, 2 planned.