zib/Veskslop-t
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add tiers, continuation, fetch cooldown, persistent action log, voice read, batch MCP

Browse Source
This commit is contained in:
Fisto
2026-09-11 15:53:06 +02:00
parent 82f78bb2b4
commit 8e8c15e8bc
17 changed files with 669 additions and 139 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TODO.md
+31 -23
View File
@@ -6,17 +6,17 @@ Ordered backlog. `CURRENT.md` tracks the live session state.
- The validated core bridge is live: a fixed action list, input validation, structured errors, and a
hard outbound rate limit. See `docs/core-bridge.md`.
- The daemon uses the core bridge. QR login, pacing, the trigger log, the trust list, the context
cache, and the response policy work.
- Mock tests and a live test passed: state, DM send, and a synthetic trigger through the real event
path.
- The daemon uses the core bridge. QR login, pacing, the trigger log, trust tiers, context, the
response policy, the continuation window, the persistent action log, and the read-only voice
state all work.
- Mock end-to-end tests pass: tiers, continuation, sensitive replies, batch MCP, and voice state.
- Repo note: use `zib/Veskslop-t` (remote `veskslop-t`) until the original repo's server hook is
fixed. Pushes to the original land, but its UI and fetch path are broken.
fixed.
## Deferred
- Voice join and leave, invite-link joins, audio in and out, and video streaming. Text features come
first.
- Voice join and leave, invite-link joins, audio in and out, and video streaming. Voice state
reads exist. Voice actions do not.
- Client lightening. Low priority. The client must stay stable.
- Web debug UI and remote client authentication.
@@ -25,25 +25,33 @@ Ordered backlog. `CURRENT.md` tracks the live session state.
Done:
- Trusted-only triggers: direct messages and direct mentions.
- Context: the last 15 messages or 4000 characters, whichever is lower. File names only for videos
and images. Incremental fetch with an old-message cache.
- Context cache in a tmp folder with a size limit.
- Response policy: reply in the origin channel or by DM. Sensitive commands default to DM.
- MCP tools for context and config.
- Trust tiers: `user`, `trusted`, `admin`. The owner is an admin.
- Context: the last 15 messages or 4000 characters, whichever is lower. File names only.
Time stamps. Incremental fetch with an old-message cache.
- Fetch cooldown: `fetchCooldownSeconds`, default 5.
- Continuation window: `continuationSeconds`, default 10. A rushed follow-up joins the request
context.
- Response policy: origin channel or DM. Sensitive commands default to DM.
- Persistent action log with rotation and secret redaction.
- MCP batch tool for read-only commands, plus a voice state tool.
Next:
- Notification parsing: edits, deletes, reactions, replies, and message references.
- Persistent trigger log with rotation.
- Notification parsing: edits, deletes, reactions, and message references.
- Reply-to-puppet counts as a trigger.
- Per-user rate limit and command cooldowns.
- More commands: `ask`, `summarize`, `context`, and `config`.
- MCP event delivery for agents. Push or a stateful stream.
- Multi-identity: a read-only collector account beside the puppet.
- Setup command with reaction-based multiple choice. The puppet reacts 1, 2, 3, 4 to its own
message and waits for the user reaction. This also serves as a small poll for group chats.
- More chat commands: `ask`, `summarize`, `context`, `config`.
- Collector account: stripped-down read-only modules. Use it when the puppet cannot find a user's
voice channel or the channel members.
## Open design questions
## MCP event delivery (open)
- MCP event delivery: the current Streamable HTTP mode is stateless, so the server cannot push
events. Options are polling, SSE, or a stateful session.
- Untrusted interactions: ignored for now. The daemon keeps the 30-entry untrusted buffer for later.
- Context freshness: the daemon fetches on each mention. Add a TTL or a minimum gap if the query
cost is too high.
The current Streamable HTTP mode is stateless. The server cannot push events. Options:
1. Poll `get_message_log` and `get_action_log` with a cursor. No new transport work.
2. A stateful Streamable HTTP session. The server can send notifications.
3. A separate local event stream over SSE or a WebSocket.
Option 1 works today. Options 2 and 3 need a decision before an LLM attaches.