crashlabs/huskies
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 26 Wiki Activity

storkit: delete 398_bug_whatsapp_and_slack_missing_async_command_handlers_for_start_rebuild_reset_rmtree_assign

Browse Source
This commit is contained in:
dave
2026-03-26 20:09:30 +00:00
parent f6b5b1b01a
commit b5bf75aa5a
2 changed files with 0 additions and 64 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.storkit/work/1_backlog/398_bug_whatsapp_and_slack_missing_async_command_handlers_for_start_rebuild_reset_rmtree_assign.md
-33
View File
@@ -1,33 +0,0 @@
---
name: "WhatsApp and Slack missing async command handlers for start, rebuild, reset, rmtree, assign"
---
# Bug 398: WhatsApp and Slack missing async command handlers for start, rebuild, reset, rmtree, assign
## Description
The WhatsApp and Slack transports are missing async handlers for several bot commands: start, rebuild, reset, rmtree, and assign. These commands have fallback handlers in chat/commands/mod.rs that return None, with comments stating they are "detected and handled before try_handle_command is invoked". This is only true for the Matrix transport. On WhatsApp and Slack, the fallback returns None, causing the message to fall through to the LLM path instead of executing the intended command.
The reset command is the most impactful — it's supposed to clear the Claude Code session_id so the bot starts a fresh conversation, but on WhatsApp it silently forwards "reset" to the LLM instead. This caused a real outage when switching from Docker to bare-metal: stale session IDs persisted in .storkit/whatsapp_history.json could not be cleared via the bot.
## How to Reproduce
1. Configure the bot with transport = "whatsapp" (Twilio) or "slack".
2. Send "reset" to the bot via WhatsApp.
3. Observe the server logs.
## Actual Result
Log shows "No command matched, forwarding to LLM" — the reset command is sent to the LLM as a conversational message instead of clearing the session.
## Expected Result
The bot should clear the sender's session_id from conversation history and reply with a confirmation like "Session cleared."
## Acceptance Criteria
- [ ] WhatsApp transport handles reset command: clears sender session_id and replies with confirmation
- [ ] Slack transport handles reset command: clears channel session_id and replies with confirmation
- [ ] WhatsApp transport handles start, rebuild, rmtree, and assign commands (or returns a meaningful response)
- [ ] Slack transport handles start, rebuild, rmtree, and assign commands (or returns a meaningful response)
- [ ] Fallback handlers in chat/commands/mod.rs no longer silently swallow these commands
.storkit/work/1_backlog/399_story_cli_port_flag_with_project_toml_persistence.md
-31
View File
@@ -1,31 +0,0 @@
---
name: "CLI --port flag with project.toml persistence"
---
# Story 399: CLI --port flag with project.toml persistence
## User Story
As a developer, I want to set the server port via a --port CLI flag that persists to project.toml, so that I don't have to remember an environment variable on every run.
## Acceptance Criteria
- [ ] `storkit --help` shows a `--port` option
- [ ] `storkit --port 4000` starts the server on port 4000
- [ ] After first run with `--port`, the port is saved to `project.toml`
- [ ] On subsequent runs without `--port`, the port from `project.toml` is used
- [ ] CLI `--port` overrides the value in `project.toml`
- [ ] Default port is 3001 when neither `--port` nor `project.toml` port is set
- [ ] `STORKIT_PORT` env var is removed — no longer read or respected
- [ ] `.storkit_port` lock file mechanism is removed (`write_port_file` / `remove_port_file`)
## Out of Scope
- Docker compose changes (can update `STORKIT_PORT` references separately)
- Adding other CLI flags beyond `--port`
## Technical Notes
Port resolution priority: `--port` flag > `project.toml` `port` field > default 3001
The port should be written to `project.toml` on startup so subsequent runs remember it. Use the existing `config.rs` / `ProjectConfig` struct — add a `port` field.