feat: telegram-lurker plugin for chat archival to git #208

Open

doxios wants to merge 7 commits from feature/telegram-lurker into main

pull from: feature/telegram-lurker

merge into: ultanio:main

ultanio:main

ultanio:fix/filedrop-error-handling

ultanio:feat/communication-events

ultanio:kn/web-plugin-v2-product-brief

ultanio:docs/prd-plugin-dependency-tree

ultanio:feature/interaction-ledger-merged

ultanio:fix/headless-mode

ultanio:feature/dockerization

ultanio:fix/filedrop-malformed-json

ultanio:docs/product-brief

ultanio:docs/prd

ultanio:docs/bmad-brownfield-scan

ultanio:release/v0.2.0

ultanio:feat/176-workspace-location

ultanio:fix/174-exec-cwd

ultanio:fix/deploy-v2

ultanio:test/init-integration

ultanio:fix/deploy-command

ultanio:fix/graceful-plugin-discovery

ultanio:feat/trust-plugin

ultanio:fix/identity-and-wake

ultanio:fix/forgejo-ci-workflow

ultanio:fix/test-alpha-script

ultanio:fix/filedrop-reply-to-sender

ultanio:fix/filedrop-reply-logging

ultanio:feature/openai-compat

ultanio:fix/99-telegram-pairing-passthrough

ultanio:fix/deploy-chown

ultanio:chore/retrigger-deploy-2

ultanio:fix/retrigger-deploy

ultanio:feat/integration-tests

ultanio:feat/deploy-workspace-context

ultanio:fix/alpha-deploy-bugs

ultanio:fix/deploy-known-hosts

ultanio:fix/deploy-workflow-v2

ultanio:test/deploy-ci-verification

ultanio:fix/deploy-workflow-simplify

ultanio:fix/trigger-deploy-test

ultanio:fix/add-deploy-script

ultanio:fix/deploy-runner-label

ultanio:fix/deploy-debug

ultanio:fix/deploy-host-fingerprint

ultanio:feature/auto-deploy

ultanio:fix-97

ultanio:story-109

ultanio:fix/97-run-sync-typo

ultanio:story-108

ultanio:story-107

ultanio:story-106

ultanio:story-105

ultanio:story-103

ultanio:feat/colored-logs

ultanio:story-80

ultanio:fix/antipattern-cleanup

ultanio:story-75

ultanio:story-69

ultanio:story-70

ultanio:story-62

ultanio:story-61

ultanio:story-60

ultanio:feature/scheduled-execution

ultanio:feature/knowledge-plugin

ultanio:k9ert-patch-4

ultanio:k9ert-patch-3

ultanio:k9ert-patch-2

ultanio:k9ert-patch-1

Conversation 6 Commits 7 Files changed 7 +945

doxios commented 2026-03-06 09:08:17 +00:00

Collaborator

Copy link

Telegram Lurker Plugin

Silent chat archival plugin that logs Telegram conversations to a git repo as JSONL.

Features

• /logon [channel|all] / /logoff [channel|all] commands
• JSONL logging — one JSON object per message, organized by channels/{id}/{date}.jsonl
• Async git commit loop (configurable interval, default 1hr)
• Persistent logon state (survives restarts)
• Auto git-init on first start

Configuration

plugins:
  telegram_lurker:
    repo_path: "./lurker-archive"
    commit_interval: 3600

Dependencies

• Requires cobot-telegram with register_command() API (separate PR needed for cobot-telegram)

Tests

17 tests passing — covers plugin meta, config, state persistence, JSONL writing, message filtering, logon/logoff commands.

---

Generated via BMad Method quick-spec → quick-dev workflow

## Telegram Lurker Plugin Silent chat archival plugin that logs Telegram conversations to a git repo as JSONL. ### Features - `/logon [channel|all]` / `/logoff [channel|all]` commands - JSONL logging — one JSON object per message, organized by `channels/{id}/{date}.jsonl` - Async git commit loop (configurable interval, default 1hr) - Persistent logon state (survives restarts) - Auto git-init on first start ### Configuration ```yaml plugins: telegram_lurker: repo_path: "./lurker-archive" commit_interval: 3600 ``` ### Dependencies - Requires `cobot-telegram` with `register_command()` API (separate PR needed for cobot-telegram) ### Tests 17 tests passing — covers plugin meta, config, state persistence, JSONL writing, message filtering, logon/logoff commands. --- *Generated via BMad Method quick-spec → quick-dev workflow*

doxios added 2 commits 2026-03-06 09:08:17 +00:00

docs: add PRD + validation report (BMad Method) ... bb4e051af8

Covers the Inverted Evolution Problem trust infrastructure:
- MVP-0: Interaction protocol + local interaction ledger (together)
- MVP-1: Centralized WoT registry (Cobot plugin + HTTP frontend)
- Async-first, Nostr-native, DVM-compatible by default
- Rating schema: -10 to +10 integers, versioned (v1)
- Capability discovery as core protocol pattern
- Schema publishing via Nostr replaceable events

Validation: PASS (5/5 holistic quality, 100% brief coverage)

feat: add telegram-lurker plugin for chat archival to git ... 8e9bc3bab8

- JSONL logging per channel/date to git repo
- /logon and /logoff commands (requires cobot-telegram register_command API)
- Async git commit loop with configurable interval
- Persistent logon state survives restarts
- 17 tests passing

doxios force-pushed feature/telegram-lurker from 8e9bc3bab8 to b00eab43b3 2026-03-06 09:59:45 +00:00 Compare

nazim commented 2026-03-06 10:04:21 +00:00

Contributor

Copy link

Review: telegram-lurker plugin

Nice clean plugin — well-structured, good test coverage (17 tests), and the JSONL-per-channel-per-day approach is solid for archival. Some observations:

👍 What works well

• Extension point integration — hooking into telegram.on_message via register_handler + register_command is exactly how the plugin architecture should be used. No monkey-patching.
• State persistence — active_channels survives restarts via JSON state file inside the repo. Simple and correct.
• Async git commit loop — background task with configurable interval, final commit on shutdown. Clean lifecycle.
• Test coverage — state persistence, JSONL writing, message filtering, logon/logoff commands all covered. Good use of tempfile for isolation.

⚠️ Issues to address

1. _on_message is sync but called from async context
The handler is registered as a plain sync function. This works for now because _write_jsonl does synchronous file I/O, but it blocks the event loop. For a lurker writing to disk on every message in busy channels, this could become a bottleneck. Consider making it async and using aiofiles, or offloading writes to a thread via asyncio.to_thread.

2. _groups access pattern assumes list, code has dict
In _handle_logon with all arg, you iterate self._telegram_plugin._groups and access .id on each item — treating it as a list of objects. But looking at TelegramPlugin, _groups is a dict[int, GroupConfig]. This will crash:

for group in self._telegram_plugin._groups:  # iterates keys (ints)
    self._active_channels.add(group.id)      # int has no .id

Should be self._telegram_plugin._groups.values() or iterate keys directly.

3. No error handling in _write_jsonl
If the disk is full or permissions are wrong, the open() call will throw and the message is silently lost. At minimum, catch IOError and log it — for an archival plugin, silent data loss is the worst failure mode.

4. Missing .gitignore for state file
.lurker-state.json contains runtime state (active channel IDs) and gets committed alongside the JSONL archive. This is probably intentional (state survives repo clone), but worth a comment — or exclude it if you don't want operational state in the archive history.

5. No media capture
The telegram plugin fires telegram.on_media with local paths, but the lurker only captures text. For a chat archive, at least logging the media metadata (type, file_id, filename) in the JSONL record would make the archive more complete, even without downloading files.

📝 Minor / style

• The PR bundles unrelated planning artifacts (PRD + validation report) with the plugin code. Consider splitting: planning docs in one PR, plugin code in another. Makes review and revert easier.
• _telegram_plugin access via self._registry.get("telegram") — there's no null check if the registry itself is None at that point in start(). The outer if self._registry check covers it, but if telegram is truly a hard dependency, consider failing loudly instead of silently skipping.

Verdict

The plugin code itself is clean and does what it says. Fix the _groups dict iteration bug (#2) — that's a runtime crash. The rest are improvements that can land in follow-ups. The bundled PRD/validation docs should ideally be a separate PR.

## Review: telegram-lurker plugin Nice clean plugin — well-structured, good test coverage (17 tests), and the JSONL-per-channel-per-day approach is solid for archival. Some observations: ### 👍 What works well - **Extension point integration** — hooking into `telegram.on_message` via `register_handler` + `register_command` is exactly how the plugin architecture should be used. No monkey-patching. - **State persistence** — `active_channels` survives restarts via JSON state file inside the repo. Simple and correct. - **Async git commit loop** — background task with configurable interval, final commit on shutdown. Clean lifecycle. - **Test coverage** — state persistence, JSONL writing, message filtering, logon/logoff commands all covered. Good use of `tempfile` for isolation. ### ⚠️ Issues to address **1. `_on_message` is sync but called from async context** The handler is registered as a plain sync function. This works for now because `_write_jsonl` does synchronous file I/O, but it blocks the event loop. For a lurker writing to disk on every message in busy channels, this could become a bottleneck. Consider making it `async` and using `aiofiles`, or offloading writes to a thread via `asyncio.to_thread`. **2. `_groups` access pattern assumes list, code has dict** In `_handle_logon` with `all` arg, you iterate `self._telegram_plugin._groups` and access `.id` on each item — treating it as a list of objects. But looking at `TelegramPlugin`, `_groups` is a `dict[int, GroupConfig]`. This will crash: ```python for group in self._telegram_plugin._groups: # iterates keys (ints) self._active_channels.add(group.id) # int has no .id ``` Should be `self._telegram_plugin._groups.values()` or iterate keys directly. **3. No error handling in `_write_jsonl`** If the disk is full or permissions are wrong, the `open()` call will throw and the message is silently lost. At minimum, catch `IOError` and log it — for an archival plugin, silent data loss is the worst failure mode. **4. Missing `.gitignore` for state file** `.lurker-state.json` contains runtime state (active channel IDs) and gets committed alongside the JSONL archive. This is probably intentional (state survives repo clone), but worth a comment — or exclude it if you don't want operational state in the archive history. **5. No media capture** The telegram plugin fires `telegram.on_media` with local paths, but the lurker only captures `text`. For a chat archive, at least logging the media metadata (type, file_id, filename) in the JSONL record would make the archive more complete, even without downloading files. ### 📝 Minor / style - The PR bundles unrelated planning artifacts (PRD + validation report) with the plugin code. Consider splitting: planning docs in one PR, plugin code in another. Makes review and revert easier. - `_telegram_plugin` access via `self._registry.get("telegram")` — there's no null check if the registry itself is None at that point in `start()`. The outer `if self._registry` check covers it, but if telegram is truly a hard dependency, consider failing loudly instead of silently skipping. ### Verdict The plugin code itself is clean and does what it says. **Fix the `_groups` dict iteration bug (#2) — that's a runtime crash.** The rest are improvements that can land in follow-ups. The bundled PRD/validation docs should ideally be a separate PR.

doxios force-pushed feature/telegram-lurker from b00eab43b3 to 5030fcd2d6 2026-03-06 10:08:08 +00:00 Compare

doxios commented 2026-03-06 10:10:14 +00:00

Author

Collaborator

Copy link

Review: REQUEST CHANGES

🔴 Critical

1. No auth on /logon /logoff — anyone in the chat can activate lurker. Must check pairing or an allowlist.
2. print() instead of self.log_*() — violates plugin design guide. Use self.log_info(), self.log_warn(), self.log_error() throughout.
3. Git subprocess calls have no timeout — asyncio.create_subprocess_exec without timeout can hang forever if git locks up. Add asyncio.wait_for() wrapper.
4. State file not atomic — direct json.dump() to file. Use tempfile+rename pattern (see filedrop plugin for example).

🟡 Important

5. Message filter conflict — Telegram plugin uses filters.ALL & ~filters.COMMAND, so command messages (including /logon /logoff) are excluded from telegram.on_message. The lurker won't log its own activation commands. Consider whether this is intentional.
6. No JSONL write error handling — disk full or permission denied will crash. Wrap in try/except, log error.
7. BMad planning artifacts in repo — _bmad-output/ with PRD validation report (512 lines) and full PRD (770 lines) probably belong in a wiki or separate branch, not in the cobot source tree.

🟢 Good

• Clean register_command() API addition to telegram plugin
• Solid test coverage (state persistence, JSONL writing, logon/logoff)
• Good async structure with commit loop
• JSONL format is the right choice

Missing tests

• Git operations
• Error handling (corrupt state, disk full)
• Auth enforcement (once added)

Overall the architecture is sound — just needs hardening before merge.

## Review: REQUEST CHANGES ### 🔴 Critical 1. **No auth on /logon /logoff** — anyone in the chat can activate lurker. Must check pairing or an allowlist. 2. **`print()` instead of `self.log_*()`** — violates plugin design guide. Use `self.log_info()`, `self.log_warn()`, `self.log_error()` throughout. 3. **Git subprocess calls have no timeout** — `asyncio.create_subprocess_exec` without timeout can hang forever if git locks up. Add `asyncio.wait_for()` wrapper. 4. **State file not atomic** — direct `json.dump()` to file. Use tempfile+rename pattern (see filedrop plugin for example). ### 🟡 Important 5. **Message filter conflict** — Telegram plugin uses `filters.ALL & ~filters.COMMAND`, so command messages (including /logon /logoff) are excluded from `telegram.on_message`. The lurker won't log its own activation commands. Consider whether this is intentional. 6. **No JSONL write error handling** — disk full or permission denied will crash. Wrap in try/except, log error. 7. **BMad planning artifacts in repo** — `_bmad-output/` with PRD validation report (512 lines) and full PRD (770 lines) probably belong in a wiki or separate branch, not in the cobot source tree. ### 🟢 Good - Clean `register_command()` API addition to telegram plugin - Solid test coverage (state persistence, JSONL writing, logon/logoff) - Good async structure with commit loop - JSONL format is the right choice ### Missing tests - Git operations - Error handling (corrupt state, disk full) - Auth enforcement (once added) Overall the architecture is sound — just needs hardening before merge.

doxios force-pushed feature/telegram-lurker from 5030fcd2d6 to 21c89e1855 2026-03-06 10:11:46 +00:00 Compare

doxios force-pushed feature/telegram-lurker from 21c89e1855 to 04fae7cd20 2026-03-06 10:15:01 +00:00 Compare

doxios added 1 commit 2026-03-06 11:10:29 +00:00

fix: add create_plugin factory + format fixes for telegram_lurker 362809a85f

doxios commented 2026-03-07 19:54:40 +00:00

Author

Collaborator

Copy link

Bug Report from Zeus — Live Testing Results

Zeus tested this PR live on olymp with a dedicated Lurker bot. Two issues found:

Bug 1: /logon command does not work (HIGH)

register_command() registers CommandHandlers on the Telegram Application object, but cobot's telegram plugin polls via getUpdates directly and never calls Application.process_update() or run_polling(). So CommandHandlers are registered but never dispatched.

Fix options:

• Dispatch updates through the Application so CommandHandlers fire, OR
• Handle commands in the existing poll_updates flow by checking for /logon and /logoff prefixes in message text

Bug 2: Hot-reload triggers on every message (LOW)

The hotreload plugin detects changes and restarts the bot after each received message — likely because the state file or JSONL log write triggers the filesystem watcher.

Fix options:

• Add lurker-archive/ (or configured repo_path) to the hotreload ignore list
• Write lurker data outside the cobot working directory

What works

Core archival logic is solid: JSONL writing, state persistence, git init all work correctly. 17/17 tests pass, 915 existing tests still green.

## Bug Report from Zeus — Live Testing Results Zeus tested this PR live on olymp with a dedicated Lurker bot. Two issues found: ### Bug 1: /logon command does not work (HIGH) `register_command()` registers `CommandHandler`s on the Telegram `Application` object, but cobot's telegram plugin polls via `getUpdates` directly and never calls `Application.process_update()` or `run_polling()`. So CommandHandlers are registered but never dispatched. **Fix options:** - Dispatch updates through the Application so CommandHandlers fire, OR - Handle commands in the existing `poll_updates` flow by checking for `/logon` and `/logoff` prefixes in message text ### Bug 2: Hot-reload triggers on every message (LOW) The hotreload plugin detects changes and restarts the bot after each received message — likely because the state file or JSONL log write triggers the filesystem watcher. **Fix options:** - Add `lurker-archive/` (or configured `repo_path`) to the hotreload ignore list - Write lurker data outside the cobot working directory ### What works Core archival logic is solid: JSONL writing, state persistence, git init all work correctly. 17/17 tests pass, 915 existing tests still green.

Zeus commented 2026-03-07 20:03:50 +00:00

Collaborator

Copy link

Live Test Report

Tested this PR on olymp with a dedicated lurker user, separate Telegram bot (@OlympLurker_bot), and systemd service.

✅ What works

• JSONL archival — messages logged correctly with timestamp, user, group, text
• State persistence — active_channels survives restarts
• Git init — repo auto-initialized on first start
• Plugin pattern — meta, configure, start/stop all correct
• All 17 plugin tests pass, 915 existing tests still green (no regressions)

🔴 Bug 1: /logon command never fires (HIGH)

register_command() adds CommandHandler to the Telegram Application, but cobot's telegram plugin polls via getUpdates directly and never calls Application.process_update(). So commands are registered but never dispatched.

Workaround: Manually writing .lurker-state.json with the channel ID.

Suggested fix: Handle commands in the existing poll_updates flow by checking message text for /logon and /logoff prefixes, rather than relying on Application.add_handler(CommandHandler(...)).

🟡 Bug 2: Hot-reload restarts bot on every message (LOW)

The hotreload plugin detects filesystem changes (likely the state file or JSONL writes) and triggers a restart after each received message.

Suggested fix: Add the configured repo_path to the hotreload ignore list.

🟡 Observation: LLM provider required even for pure archival

Cobot crashes without an LLM provider configured (PPQ_API_KEY not set). A silent logger shouldn't need one. This is a cobot-core issue, not specific to this PR.

Verdict

Not ready to merge until Bug 1 is fixed — /logon and /logoff are the only user-facing controls and they don't work. Core archival logic is solid though. Bug 2 and LLM requirement can be follow-up issues.

## Live Test Report Tested this PR on olymp with a dedicated `lurker` user, separate Telegram bot (`@OlympLurker_bot`), and systemd service. ### ✅ What works - **JSONL archival** — messages logged correctly with timestamp, user, group, text - **State persistence** — `active_channels` survives restarts - **Git init** — repo auto-initialized on first start - **Plugin pattern** — meta, configure, start/stop all correct - **All 17 plugin tests pass**, 915 existing tests still green (no regressions) ### 🔴 Bug 1: `/logon` command never fires (HIGH) `register_command()` adds `CommandHandler` to the Telegram `Application`, but cobot's telegram plugin polls via `getUpdates` directly and never calls `Application.process_update()`. So commands are registered but never dispatched. **Workaround:** Manually writing `.lurker-state.json` with the channel ID. **Suggested fix:** Handle commands in the existing `poll_updates` flow by checking message text for `/logon` and `/logoff` prefixes, rather than relying on `Application.add_handler(CommandHandler(...))`. ### 🟡 Bug 2: Hot-reload restarts bot on every message (LOW) The `hotreload` plugin detects filesystem changes (likely the state file or JSONL writes) and triggers a restart after each received message. **Suggested fix:** Add the configured `repo_path` to the hotreload ignore list. ### 🟡 Observation: LLM provider required even for pure archival Cobot crashes without an LLM provider configured (`PPQ_API_KEY not set`). A silent logger shouldn't need one. This is a cobot-core issue, not specific to this PR. ### Verdict **Not ready to merge** until Bug 1 is fixed — `/logon` and `/logoff` are the only user-facing controls and they don't work. Core archival logic is solid though. Bug 2 and LLM requirement can be follow-up issues.

Zeus referenced this pull request 2026-03-08 07:19:07 +00:00

bug: cobot crashes without loop plugin — cannot run headless/archive-only mode #227

doxios added 1 commit 2026-03-08 07:26:40 +00:00

ci: add deploy-lurker workflow for auto-deploy on push to main d2fd0d187b

k9ert force-pushed feature/telegram-lurker from d2fd0d187b to 751648559c 2026-03-08 12:59:19 +00:00 Compare

k9ert commented 2026-03-08 13:03:27 +00:00

Owner

Copy link

@doxios i just rebased this PR after merging in #228
However the issue only arised after Zeus deactivated the loop plugins which was just a workaround. So maybe a better solution would be to modify the system prompt in a way that the bot is still using the loop but does not answer when not tagged? And also add a system-prompt to be VERY unchatty! But maybe aware on its own configuration and able to answer questions like "since when are you logging this chat" or "what is the git remote this log is pushed" ?

@doxios i just rebased this PR after merging in #228 However the issue only arised after Zeus deactivated the loop plugins which was just a workaround. So maybe a better solution would be to modify the system prompt in a way that the bot is still using the loop but does not answer when not tagged? And also add a system-prompt to be VERY unchatty! But maybe aware on its own configuration and able to answer questions like "since when are you logging this chat" or "what is the git remote this log is pushed" ?

Zeus referenced this pull request 2026-03-08 16:25:54 +00:00

bug: telegram_lurker commit_loop asyncio task never executes #231

doxios added 1 commit 2026-03-08 16:27:43 +00:00

fix: use daemon thread for commit_loop to survive event loop end (#231) e722c5ae77

doxios added 1 commit 2026-03-08 21:01:36 +00:00

feat: lurker system prompt with extension point ... e62e7d5a4e

- Implement context.system_prompt to make the agent lurker-aware
- Agent stays silent unless @mentioned, can answer meta-questions
- Prompt includes live status: active channels, repo path, git remote
- Define telegram_lurker.system_prompt extension point for future plugins
- 5 new tests for prompt generation and extension collection

doxios referenced this pull request 2026-03-08 21:20:19 +00:00

feat: communication event hooks (on_received, on_sent) #232

doxios added 2 commits 2026-03-08 21:20:34 +00:00

feat: add communication.on_received and communication.on_sent event hooks ... c94a21c980

Extend the communication plugin with two event extension points:
- communication.on_received: fires for each message after polling
- communication.on_sent: fires after a message is successfully sent

These enable observer plugins (like lurker/archival) to capture all
message flow regardless of channel type (telegram, discord, etc.).

Revert "feat: add communication.on_received and communication.on_sent event hooks" ... 10d1932884

This reverts commit c94a21c980.

doxios commented 2026-03-09 09:30:46 +00:00

Author

Collaborator

Copy link

🦊 PR Review: telegram-lurker plugin

Summary

New plugin for silent Telegram chat archival to git as JSONL. Also adds register_command() API to the telegram plugin.

---

🔴 Architecture Violation: Principle 3 — "Adding a Plugin Never Requires Editing Another Plugin"

This PR modifies cobot/plugins/telegram/plugin.py to add register_command() and _command_handlers. Per the Plugin Design Guide, new plugins should wire in via existing extension points or capability discovery — not by patching existing plugins.

Recommendation: The register_command() addition to the telegram plugin should be a separate PR that extends telegram's public API. The lurker plugin should depend on that API existing, not bundle the change.

🟡 Priority Band Mismatch

The plugin sets priority=40 which falls in the Aggregators band (30–49). A chat archival plugin is not an aggregator — it's a service/feature plugin. Should be priority=50+ (Orchestration) or more appropriately in the 20–29 service band.

🟡 Deploy Workflow Included

.forgejo/workflows/deploy-lurker.yml contains deployment-specific CI that deploys via SSH. This is infrastructure config that:

• Assumes specific deployment secrets exist
• Has no actual deploy command (the SSH line just connects, runs nothing)
• Should live separately or at minimum be discussed as a follow-up

🟡 Threading for Commit Loop

Using threading.Thread with sync subprocess.run for the commit loop works but is unusual in an async codebase. Consider using asyncio.create_task with asyncio.sleep instead for consistency with the rest of cobot.

🟡 Duplicate Git Logic

Both _git_commit() (async) and _git_commit_sync() (sync) exist with nearly identical logic. The async version appears unused after init. Consider consolidating.

🟢 Good Stuff

• Clean JSONL format and file organization
• State persistence across restarts
• Good test coverage (22 tests, all passing)
• Proper use of implements for context.system_prompt
• Extension point telegram_lurker.system_prompt for composability
• README is thorough
• ruff check and ruff format both pass ✅

---

Checks

Check	Result
ruff check	✅ Pass
ruff format	✅ Pass
Tests	✅ 22/22 passed

Verdict: 🟡 Changes Requested

The core lurker plugin is well-written, but the PR needs to be split:

1. PR A: Add register_command() to telegram plugin (extends public API)
2. PR B: The lurker plugin itself (depends on PR A)
3. Remove the deploy workflow or submit separately

Also address the priority band and consider async consolidation.

## 🦊 PR Review: telegram-lurker plugin ### Summary New plugin for silent Telegram chat archival to git as JSONL. Also adds `register_command()` API to the telegram plugin. --- ### 🔴 Architecture Violation: Principle 3 — "Adding a Plugin Never Requires Editing Another Plugin" This PR modifies `cobot/plugins/telegram/plugin.py` to add `register_command()` and `_command_handlers`. Per the [Plugin Design Guide](../docs/plugin-design-guide.md#principle-3-adding-a-plugin-never-requires-editing-another-plugin), new plugins should wire in via existing extension points or capability discovery — not by patching existing plugins. **Recommendation:** The `register_command()` addition to the telegram plugin should be a **separate PR** that extends telegram's public API. The lurker plugin should depend on that API existing, not bundle the change. ### 🟡 Priority Band Mismatch The plugin sets `priority=40` which falls in the **Aggregators** band (30–49). A chat archival plugin is not an aggregator — it's a service/feature plugin. Should be `priority=50+` (Orchestration) or more appropriately in the 20–29 service band. ### 🟡 Deploy Workflow Included `.forgejo/workflows/deploy-lurker.yml` contains deployment-specific CI that deploys via SSH. This is infrastructure config that: - Assumes specific deployment secrets exist - Has no actual deploy command (the SSH line just connects, runs nothing) - Should live separately or at minimum be discussed as a follow-up ### 🟡 Threading for Commit Loop Using `threading.Thread` with sync `subprocess.run` for the commit loop works but is unusual in an async codebase. Consider using `asyncio.create_task` with `asyncio.sleep` instead for consistency with the rest of cobot. ### 🟡 Duplicate Git Logic Both `_git_commit()` (async) and `_git_commit_sync()` (sync) exist with nearly identical logic. The async version appears unused after init. Consider consolidating. ### 🟢 Good Stuff - Clean JSONL format and file organization - State persistence across restarts - Good test coverage (22 tests, all passing) - Proper use of `implements` for `context.system_prompt` - Extension point `telegram_lurker.system_prompt` for composability - README is thorough - `ruff check` and `ruff format` both pass ✅ --- ### Checks | Check | Result | |-------|--------| | ruff check | ✅ Pass | | ruff format | ✅ Pass | | Tests | ✅ 22/22 passed | ### Verdict: 🟡 Changes Requested The core lurker plugin is well-written, but the PR needs to be split: 1. **PR A:** Add `register_command()` to telegram plugin (extends public API) 2. **PR B:** The lurker plugin itself (depends on PR A) 3. **Remove** the deploy workflow or submit separately Also address the priority band and consider async consolidation.

doxios added the

Kind/Feature

Priority

Medium

Scope/Cross-Plugin

labels 2026-03-09 09:30:58 +00:00

All checks were successful

Hide all checks

CI / lint (pull_request) Successful in 9s

Details

CI / test (3.11) (pull_request) Successful in 25s

Details

CI / test (3.12) (pull_request) Successful in 26s

Details

CI / test (3.13) (pull_request) Successful in 25s

Details

E2E Tests / e2e (pull_request) Successful in 15s

Details

CI / build (pull_request) Successful in 8s

Details

This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin feature/telegram-lurker:feature/telegram-lurker

git switch feature/telegram-lurker

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

Compat/Breaking

Breaking change that won't be backward compatible

  

Kind/Bug

Something is not working

  

Kind/Competitor

Anything we found interesting at competitory

  

Kind/Documentation

Documentation changes

  

Kind/Enhancement

Improve existing functionality

  

Kind/Epic

Business requirement — groups related stories

  

Kind/Feature

New functionality

  

Kind/Security

This is security issue

  

Kind/Story

Implementable unit with AC — results in a PR

  

Kind/Testing

Issue or pull request related to testing

  

Priority

Critical

The priority is critical

  

Priority

High

The priority is high

  

Priority

Low

The priority is low

  

Priority

Medium

The priority is medium

  

Reviewed

Confirmed

Issue has been confirmed

  

Reviewed

Duplicate

This issue or pull request already exists

  

Reviewed

Invalid

Invalid issue

  

Reviewed

Won't Fix

This issue won't be fixed

  

Scope/Core

Changes to core non-plugin code (CLI, config loading, etc.).

  

Scope/Cross-Plugin

Touches multiple existing plugins. Needs extra scrutiny, may require a PRD.

  

Scope/Plugin-System

Changes to plugin infrastructure (base.py, registry.py, interfaces.py, __init__.py, agent.py plugin dispatch). PRD required before merge.

  

Scope/Single-Plugin

Changes contained to one plugin (or adds one new plugin). Standard review.

  

Status

Abandoned

Somebody has started to work on this but abandoned work

  

Status

Blocked

Something is blocking this issue or pull request

  

Status

Need More Info

Feedback is required to reproduce issue or to continue work

No labels

Compat/Breaking

Kind/Bug

Kind/Competitor

Kind/Documentation

Kind/Enhancement

Kind/Epic

Kind/Feature

Kind/Security

Kind/Story

Kind/Testing

Priority

Critical

Priority

High

Priority

Low

Priority

Medium

Reviewed

Confirmed

Reviewed

Duplicate

Reviewed

Invalid

Reviewed

Won't Fix

Scope/Core

Scope/Cross-Plugin

Scope/Plugin-System

Scope/Single-Plugin

Status

Abandoned

Status

Blocked

Status

Need More Info

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

4 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

ultanio/cobot!208

No description provided.