storkit: done 387_story_configurable_base_branch_name_in_project_toml
This commit is contained in:
@@ -1,30 +0,0 @@
|
||||
---
|
||||
name: "WhatsApp missing async command handlers for start, rebuild, reset, rmtree, assign"
|
||||
---
|
||||
|
||||
# Bug 390: WhatsApp missing async command handlers for start, rebuild, reset, rmtree, assign
|
||||
|
||||
## Description
|
||||
|
||||
Five bot commands listed in help don't work in WhatsApp. Matrix's on_room_message pre-dispatches these via extract_*_command() functions before calling try_handle_command(), but WhatsApp's handle_incoming_message only pre-dispatches htop and delete. The missing commands have fallback handlers that return None, so they silently fall through to the LLM instead of executing.
|
||||
|
||||
## How to Reproduce
|
||||
|
||||
1. Send "rebuild" (or "start 386", "reset", "rmtree 386", "assign 386 opus") to the WhatsApp bot\n2. Observe the message is forwarded to the LLM instead of executing the command
|
||||
|
||||
## Actual Result
|
||||
|
||||
The 5 commands (start, rebuild, reset, rmtree, assign) fall through to the LLM and generate a conversational response instead of executing the bot command.
|
||||
|
||||
## Expected Result
|
||||
|
||||
All commands listed in help should work in WhatsApp, matching Matrix behavior. start should spawn an agent, rebuild should rebuild the server, reset should clear the session, rmtree should remove a worktree, assign should pre-assign a model.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] start command works in WhatsApp (extract_start_command dispatch)
|
||||
- [ ] rebuild command works in WhatsApp (extract_rebuild_command dispatch)
|
||||
- [ ] reset command works in WhatsApp (extract_reset_command dispatch)
|
||||
- [ ] rmtree command works in WhatsApp (extract_rmtree_command dispatch)
|
||||
- [ ] assign command works in WhatsApp (extract_assign_command dispatch)
|
||||
- [ ] Same 5 commands also work in Slack transport if similarly missing
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
name: "Configurable base branch name in project.toml"
|
||||
---
|
||||
|
||||
# Story 387: Configurable base branch name in project.toml
|
||||
|
||||
## User Story
|
||||
|
||||
As a project owner, I want to configure the main branch name in project.toml (e.g. "main", "master", "develop"), so that the system doesn't hardcode "master" and works with any branching convention.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] New optional `base_branch` setting in project.toml (e.g. base_branch = "main")
|
||||
- [ ] When set, all worktree creation, merge operations, and agent prompts use the configured branch name
|
||||
- [ ] When not set, falls back to the existing auto-detection logic (detect_base_branch) which reads the current git branch
|
||||
- [ ] The hardcoded "master" fallback in detect_base_branch is replaced by the project.toml setting when available
|
||||
- [ ] Agent prompt template {{base_branch}} resolves to the configured value
|
||||
- [ ] Existing projects without the setting continue to work unchanged (backwards compatible)
|
||||
- [ ] project.toml.example uses base_branch = \"main\" as the example value; the actual project.toml uses base_branch = \"master\"
|
||||
|
||||
## Out of Scope
|
||||
|
||||
- TBD
|
||||
Reference in New Issue
Block a user