story-kit: commit work pipeline files and package-lock
Commit untracked work pipeline files (stories, bugs in various stages) and package-lock.json that were present on the filesystem but not yet tracked by git. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -1,5 +1,7 @@
|
|||||||
{
|
{
|
||||||
"enabledMcpjsonServers": ["story-kit"],
|
"enabledMcpjsonServers": [
|
||||||
|
"story-kit"
|
||||||
|
],
|
||||||
"permissions": {
|
"permissions": {
|
||||||
"allow": [
|
"allow": [
|
||||||
"Bash(./server/target/debug/story-kit:*)",
|
"Bash(./server/target/debug/story-kit:*)",
|
||||||
@@ -56,7 +58,8 @@
|
|||||||
"WebSearch",
|
"WebSearch",
|
||||||
"mcp__story-kit__*",
|
"mcp__story-kit__*",
|
||||||
"Edit",
|
"Edit",
|
||||||
"Write"
|
"Write",
|
||||||
|
"Bash(find *)"
|
||||||
]
|
]
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
@@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
name: "Merge pipeline cherry-pick fails with bad revision on merge-queue branch"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bug 250: Merge pipeline cherry-pick fails with bad revision on merge-queue branch
|
||||||
|
|
||||||
|
## Description
|
||||||
|
|
||||||
|
The mergemaster merge pipeline consistently fails at the cherry-pick step with: fatal: bad revision merge-queue/{story_id}. The merge-queue branch is created and the squash commit succeeds, but the branch reference is not accessible during the subsequent cherry-pick onto master. This affects every story that reaches the merge stage — no stories can be automatically merged. The issue is in the git reference handling within the merge pipeline, not a code conflict.
|
||||||
|
|
||||||
|
## How to Reproduce
|
||||||
|
|
||||||
|
1. Have a completed story in 4_merge/ with a feature branch containing commits ahead of master
|
||||||
|
2. Trigger merge_agent_work via MCP or let the mergemaster agent run
|
||||||
|
3. Observe the cherry-pick failure
|
||||||
|
|
||||||
|
## Actual Result
|
||||||
|
|
||||||
|
Cherry-pick fails with fatal: bad revision merge-queue/{story_id}. The merge-queue branch was created and squash commit succeeded, but the branch reference is not found during cherry-pick. Master is untouched.
|
||||||
|
|
||||||
|
## Expected Result
|
||||||
|
|
||||||
|
The merge pipeline should successfully squash-merge the feature branch into master, run quality gates, move the story to done, and clean up the worktree and branch.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] Use git bisect or git log to find when the merge pipeline broke
|
||||||
|
- [ ] Fix the root cause — do not layer on a workaround
|
||||||
|
- [ ] Merge pipeline successfully merges a story from 4_merge to master end-to-end
|
||||||
|
- [ ] Quality gates run and pass before the merge commits to master
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
---
|
||||||
|
name: "Chat history persistence lost on page refresh (story 145 regression)"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bug 245: Chat history persistence lost on page refresh (story 145 regression)
|
||||||
|
|
||||||
|
## Description
|
||||||
|
|
||||||
|
Story 145 implemented localStorage persistence for chat history across page reloads. This is no longer working — refreshing the page loses all conversation context. This is a regression of the feature delivered in story 145.
|
||||||
|
|
||||||
|
## How to Reproduce
|
||||||
|
|
||||||
|
1. Open the web UI and have a conversation with the agent
|
||||||
|
2. Refresh the page (F5 or Cmd+R)
|
||||||
|
|
||||||
|
## Actual Result
|
||||||
|
|
||||||
|
Chat history is gone after refresh — the UI shows a blank conversation.
|
||||||
|
|
||||||
|
## Expected Result
|
||||||
|
|
||||||
|
Chat history is restored from localStorage on page load, as implemented in story 145.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] Chat messages survive a full page refresh
|
||||||
|
- [ ] Chat messages are restored from localStorage on component mount
|
||||||
|
- [ ] Behaviour matches the original acceptance criteria from story 145
|
||||||
|
|
||||||
|
## Investigation Notes
|
||||||
|
|
||||||
|
**Use `git bisect` to find the commit that broke this.** Story 145 delivered working localStorage persistence — something after that regressed it. Find the breaking commit, understand the root cause, and fix it there. Do NOT layer on a new implementation. Revert or surgically fix the regression.
|
||||||
@@ -0,0 +1,21 @@
|
|||||||
|
---
|
||||||
|
name: "Agent assignment via story front matter"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Story 249: Agent assignment via story front matter
|
||||||
|
|
||||||
|
## User Story
|
||||||
|
|
||||||
|
As a project owner, I want to specify which agent should work on a story via a front matter field (e.g. agent: coder-opus) so that complex stories get assigned to the right coder automatically.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] Story files support an optional agent front matter field (e.g. agent: coder-opus)
|
||||||
|
- [ ] When the pipeline auto-assigns a coder to a story, it uses the agent specified in front matter if present
|
||||||
|
- [ ] If the specified agent is busy, the story waits rather than falling back to a different coder
|
||||||
|
- [ ] If no agent is specified in front matter, the existing default assignment behaviour is used
|
||||||
|
- [ ] The supervisor agent respects the front matter assignment when starting coders
|
||||||
|
|
||||||
|
## Out of Scope
|
||||||
|
|
||||||
|
- TBD
|
||||||
@@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
name: /btw Side Question Slash Command
|
||||||
|
merge_failure: "Squash-merge resulted in an empty diff after auto-resolving a conflict in frontend/src/components/Chat.tsx. The feature branch has no code changes beyond master — the changes may have already been incorporated into master via another merge, or the conflict resolution cancelled out the feature's additions. Human investigation needed to determine whether the feature code is already on master or needs to be re-implemented."
|
||||||
|
---
|
||||||
|
|
||||||
|
## User Story
|
||||||
|
|
||||||
|
As a user, I want to ask the agent a quick side question using `/btw` so that I can get a fast answer from the current conversation context without disrupting the main chat thread.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] User can type `/btw <question>` in the chat input
|
||||||
|
- [ ] The agent answers using the full conversation history as context
|
||||||
|
- [ ] The question and response are displayed in a dismissible overlay, not in the main chat thread
|
||||||
|
- [ ] The question and response are not added to the conversation history
|
||||||
|
- [ ] No tool calls are made when answering a `/btw` question — the agent responds only from what is already in context
|
||||||
|
- [ ] The overlay can be dismissed with Escape, Enter, or Space
|
||||||
|
- [ ] `/btw` can be invoked while the agent is actively processing a response without interrupting it
|
||||||
|
- [ ] The slash command detection and dispatch mechanism must be reusable — build a shared parser/router so future slash commands (e.g. /help, /status) can plug in without duplicating detection logic
|
||||||
|
|
||||||
|
## Out of Scope
|
||||||
|
|
||||||
|
- Follow-up turns within the side question
|
||||||
|
- Tool usage in side question responses
|
||||||
|
- Persisting side question history
|
||||||
|
|
||||||
|
## Rejection Notes
|
||||||
|
|
||||||
|
**2026-03-14:** Previous implementation was rejected. The frontend did nothing when the user typed `/btw` — the slash command was not wired up in the UI at all. The backend may have had changes but the feature was non-functional from the user's perspective. Ensure the full end-to-end flow works: typing `/btw <question>` in the chat input must visibly trigger the overlay with a response.
|
||||||
24
.story_kit/work/5_done/241_story_help_slash_command.md
Normal file
24
.story_kit/work/5_done/241_story_help_slash_command.md
Normal file
@@ -0,0 +1,24 @@
|
|||||||
|
---
|
||||||
|
name: "/help Slash Command"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Story 241: /help Slash Command
|
||||||
|
|
||||||
|
## User Story
|
||||||
|
|
||||||
|
As a user, I want to type /help in the chat input so that I can see a list of available slash commands and what they do.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] User can type /help in the chat input
|
||||||
|
- [ ] A help overlay or panel displays all available slash commands with brief descriptions
|
||||||
|
- [ ] The overlay can be dismissed with Escape, Enter, or Space
|
||||||
|
- [ ] The slash command detection and dispatch mechanism is shared across all slash commands (reuse the same parser/router used by /btw and other slash commands — do not duplicate detection logic)
|
||||||
|
|
||||||
|
## Out of Scope
|
||||||
|
|
||||||
|
- TBD
|
||||||
|
|
||||||
|
## Rejection Notes
|
||||||
|
|
||||||
|
**2026-03-14:** Previous implementation was rejected. The frontend did nothing when the user typed `/help` — the slash command was not wired up in the UI at all. Ensure the full end-to-end flow works: typing `/help` in the chat input must visibly display the help overlay with slash command descriptions.
|
||||||
21
.story_kit/work/5_done/242_story_status_slash_command.md
Normal file
21
.story_kit/work/5_done/242_story_status_slash_command.md
Normal file
@@ -0,0 +1,21 @@
|
|||||||
|
---
|
||||||
|
name: "/status Slash Command"
|
||||||
|
merge_failure: "Squash-merge resulted in an empty diff — the feature branch (feature/story-242_story_status_slash_command) has no code changes beyond master. The coder agent's work may not have been committed to the feature branch, or the changes were already merged via another path."
|
||||||
|
---
|
||||||
|
|
||||||
|
# Story 242: /status Slash Command
|
||||||
|
|
||||||
|
## User Story
|
||||||
|
|
||||||
|
As a user, I want to type /status in the chat input so that I can see the current state of the agent, active story, pipeline stage, and any running processes at a glance.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] User can type /status in the chat input
|
||||||
|
- [ ] A status overlay or panel shows: current story (if any), pipeline stage, agent status, and running processes
|
||||||
|
- [ ] The overlay can be dismissed with Escape, Enter, or Space
|
||||||
|
- [ ] The slash command detection and dispatch mechanism is shared across all slash commands (reuse the same parser/router used by /btw and other slash commands — do not duplicate detection logic)
|
||||||
|
|
||||||
|
## Out of Scope
|
||||||
|
|
||||||
|
- TBD
|
||||||
28
.story_kit/work/5_done/243_bug_replace_pnpm_with_npm.md
Normal file
28
.story_kit/work/5_done/243_bug_replace_pnpm_with_npm.md
Normal file
@@ -0,0 +1,28 @@
|
|||||||
|
---
|
||||||
|
name: "Replace pnpm with npm"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bug 243: Replace pnpm with npm
|
||||||
|
|
||||||
|
## Description
|
||||||
|
|
||||||
|
pnpm's reflink-based package import frequently fails with ERR_PNPM_ENOENT when running in git worktrees (.story_kit/merge_workspace), causing merge quality gates to fail repeatedly. No pnpm-specific features are in use.
|
||||||
|
|
||||||
|
## How to Reproduce
|
||||||
|
|
||||||
|
Move any story to merge. The mergemaster runs pnpm install in the merge worktree and it fails with ERR_PNPM_ENOENT reflink errors.
|
||||||
|
|
||||||
|
## Actual Result
|
||||||
|
|
||||||
|
pnpm install fails in merge worktrees, blocking all merges.
|
||||||
|
|
||||||
|
## Expected Result
|
||||||
|
|
||||||
|
Package installation works reliably in all worktree contexts.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] pnpm-lock.yaml is removed and package-lock.json is generated
|
||||||
|
- [ ] All pnpm references in project.toml are replaced with npm equivalents
|
||||||
|
- [ ] npm install and npm run build succeed in a clean worktree
|
||||||
|
- [ ] No other pnpm references remain in project configuration
|
||||||
@@ -0,0 +1,22 @@
|
|||||||
|
---
|
||||||
|
name: "Enforce cryptographic identity verification for Matrix commands"
|
||||||
|
merge_failure: "Cherry-pick of squash commit onto master failed with \"fatal: bad revision 'merge-queue/246_story_enforce_cryptographic_identity_verification_for_matrix_commands'\". The merge-queue branch was created and the squash commit succeeded, but the branch reference was not accessible during the cherry-pick step. This appears to be an infrastructure/git reference issue in the merge pipeline, not a code conflict. Master is untouched."
|
||||||
|
---
|
||||||
|
|
||||||
|
# Story 246: Enforce cryptographic identity verification for Matrix commands
|
||||||
|
|
||||||
|
## User Story
|
||||||
|
|
||||||
|
As the operator of a Story Kit instance, I want the Matrix bot to always require cryptographic device verification before executing commands, so that a compromised homeserver cannot be used to execute unauthorized commands.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] Bot refuses to process commands from unencrypted rooms
|
||||||
|
- [ ] Bot always verifies the sending device is cross-signing-verified by a trusted identity before executing any command
|
||||||
|
- [ ] The require_verified_devices config option is removed — verification is always on with no way to disable it
|
||||||
|
- [ ] Messages from unverified devices are rejected with a clear log message
|
||||||
|
- [ ] Existing allowed_users check remains as a first-pass filter before the cryptographic check
|
||||||
|
|
||||||
|
## Out of Scope
|
||||||
|
|
||||||
|
- TBD
|
||||||
@@ -0,0 +1,25 @@
|
|||||||
|
---
|
||||||
|
name: "Human QA gate with rejection flow"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Story 247: Human QA gate with rejection flow
|
||||||
|
|
||||||
|
## User Story
|
||||||
|
|
||||||
|
As the project owner, I want stories to require my manual approval after machine QA before they can be merged, so that features that compile and pass tests but do not actually work correctly are caught before reaching master.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] Story files support a manual_qa front matter field (defaults to true)
|
||||||
|
- [ ] After machine QA passes in 3_qa, stories with manual_qa: true wait for human approval before moving to 4_merge
|
||||||
|
- [ ] The UI shows a clear way to launch the app from the worktree for manual testing (single button click), with automatic port conflict handling via .story_kit_port
|
||||||
|
- [ ] Frontend and backend are pre-compiled during machine QA so the app is ready to run instantly for manual testing
|
||||||
|
- [ ] Only one QA app instance runs at a time — do not automatically spin up multiple instances
|
||||||
|
- [ ] Human can approve a story from 3_qa to move it to 4_merge
|
||||||
|
- [ ] Human can reject a story from 3_qa back to 2_current with notes about what is broken
|
||||||
|
- [ ] Rejection notes are written into the story file so the coder can see what needs fixing
|
||||||
|
- [ ] Stories with manual_qa: false skip the human gate and proceed directly from machine QA to 4_merge
|
||||||
|
|
||||||
|
## Out of Scope
|
||||||
|
|
||||||
|
- TBD
|
||||||
@@ -0,0 +1,27 @@
|
|||||||
|
---
|
||||||
|
name: "Chat does not auto-scroll to new messages"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bug 248: Chat does not auto-scroll to new messages
|
||||||
|
|
||||||
|
## Description
|
||||||
|
|
||||||
|
The chat UI does not automatically scroll to the bottom when new assistant messages stream in. The user has to manually scroll down to see the response, making it appear as if the bot stopped responding.
|
||||||
|
|
||||||
|
## How to Reproduce
|
||||||
|
|
||||||
|
1. Send a message in the chat UI
|
||||||
|
2. Wait for the assistant to respond with a long message or multi-turn tool use
|
||||||
|
3. Observe that the viewport does not scroll to follow the new content
|
||||||
|
|
||||||
|
## Actual Result
|
||||||
|
|
||||||
|
The viewport stays at the current scroll position. New messages appear below the fold, invisible to the user.
|
||||||
|
|
||||||
|
## Expected Result
|
||||||
|
|
||||||
|
The chat viewport should auto-scroll to the bottom as new content streams in, keeping the latest message visible.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
- [ ] Bug is fixed and verified
|
||||||
6
package-lock.json
generated
Normal file
6
package-lock.json
generated
Normal file
@@ -0,0 +1,6 @@
|
|||||||
|
{
|
||||||
|
"name": "story-kit",
|
||||||
|
"lockfileVersion": 3,
|
||||||
|
"requires": true,
|
||||||
|
"packages": {}
|
||||||
|
}
|
||||||
Reference in New Issue
Block a user