68 lines
3.4 KiB
Markdown
68 lines
3.4 KiB
Markdown
# TODO
|
|
|
|
Ordered backlog. `CURRENT.md` tracks the live session state.
|
|
|
|
## Where the project finished (2026-09-11)
|
|
|
|
- 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, 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.
|
|
|
|
## Deferred
|
|
|
|
- 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.
|
|
|
|
## Text features
|
|
|
|
Done:
|
|
|
|
- Trusted-only triggers: direct messages and direct mentions.
|
|
- 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.
|
|
- Reaction poll command: `poll "Question" opt 1 // opt 2 [// opt 3 [// opt 4]]` or the pipe form.
|
|
Number emojis, multiple reactions per user, bare command shows help, auto results after
|
|
`pollSeconds`.
|
|
- Bare `whitelist` and bare `poll` show help with usage and formatting.
|
|
|
|
Next:
|
|
|
|
- Notification parsing: edits, deletes, reactions, and message references.
|
|
- Reply-to-puppet counts as a trigger.
|
|
- Per-user rate limit and command cooldowns.
|
|
- 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 decisions
|
|
|
|
- **MCP event delivery.** The current Streamable HTTP mode is stateless. The server cannot push
|
|
events. Options:
|
|
1. Poll `get_message_log` and `get_action_log` with a `since` 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.
|
|
- **Untrusted logging.** Untrusted interactions are ignored at this time. The separate 30-entry
|
|
buffer exists but receives nothing. Decide whether to log untrusted DMs and mentions again.
|
|
- **Privacy pass.** Only token-shaped and `mfa.` strings are redacted, and only in the persistent
|
|
action log. Decide the fuller policy (retention, cache clearing, message redaction) later.
|
|
- **Live reaction check.** `reaction.add` and the message-ID return are mock-verified only. Confirm
|
|
Discord's internal `addReaction` lookup on the first real-client run.
|