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

storkit: done 399_story_cli_port_flag_with_project_toml_persistence

Browse Source
This commit is contained in:
dave
2026-03-26 20:46:59 +00:00
parent f22a2666b8
commit 85e37e03a8
2 changed files with 31 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.storkit/work/1_backlog/401_bug_whatsapp_and_slack_missing_start_command_handler.md
-35
View File
@@ -1,35 +0,0 @@
---
name: "WhatsApp and Slack missing start command handler"
---
# Bug 401: WhatsApp and Slack missing start command handler
## Description
The start command has a fallback handler in chat/commands/mod.rs that returns None. Only Matrix has pre-dispatch handling for this command. On WhatsApp and Slack, the command falls through to the LLM path.
## Implementation Note
Follow the **rebuild pattern** established in story 402.
- `extract_start_command` and `handle_start` already exist in `server/src/chat/transport/matrix/start.rs`
- Add an async intercept in `server/src/chat/transport/whatsapp.rs` (see rebuild intercept ~line 1107) and `server/src/chat/transport/slack.rs` (see rebuild intercept ~line 845)
- Call `crate::chat::transport::matrix::start::extract_start_command` to detect the command, then `crate::chat::transport::matrix::start::handle_start` to execute it
- The fallback handler in `chat/commands/mod.rs` (`handle_start_fallback`) stays as-is — it exists only so `help` lists the command
## How to Reproduce
1. Configure bot with transport = "whatsapp" or "slack"\n2. Send "start <story_id>" to the bot\n3. Check server logs
## Actual Result
Command falls through to LLM instead of starting an agent.
## Expected Result
The bot starts an agent for the specified story and replies with confirmation.
## Acceptance Criteria
- [ ] WhatsApp transport handles start command: starts agent and replies with confirmation
- [ ] Slack transport handles start command: starts agent and replies with confirmation
.storkit/work/5_done/399_story_cli_port_flag_with_project_toml_persistence.md
+31
View File
@@ -0,0 +1,31 @@
---
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.