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:
@@ -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
|
||||
Reference in New Issue
Block a user