[zwanski-start]

Closes #135

What changed

The project assistant can now take bug reports against features that already exist. Before, the only option was creating a new "fix X" feature.

• New MCP tool feature_report_bug(feature_id, bug_description, steps?) in mcp_server/feature_mcp.py. It appends **Bug report:** … to the feature's description, appends any repro/verification steps to its steps, and sets passes = false, so a coding agent picks it up again. Priority stays the same and no new feature is created. Features that are currently in_progress are rejected, so a running agent isn't affected.
• Assistant toolset (server/services/assistant_chat_session.py): adds feature_report_bug and feature_get_graph. The graph tool lets the assistant list every feature, including done ones, to find the one a bug belongs to. feature_mark_passing and feature_mark_failing stay disallowed.
• System prompt and greeting describe the three kinds of request: help, new feature, bug report. A new "Reporting Bugs" section says to prefer reopening the existing feature, to use ask_user when it's unclear which feature is affected, and to create a new feature only if no existing one fits.
• UI (AssistantChat.tsx): until the first user message, three quick-action chips appear under the greeting: Ask for help, New feature, Report a bug. Clicking one prefills the input (e.g. Bug report: ), changes the placeholder and focuses the textarea.
• Added feature_report_bug to the MCP tool list in CLAUDE.md.

Verification

• New test_feature_report_bug.py (5 tests) covers: reopening a passing feature, a pending feature with no steps, rejecting an in-progress feature, a missing feature or blank description, and the assistant allow/deny lists. All pass, and so does test_client.py.
• ruff check . is clean and python test_security.py passes. mypy reports no new errors in the touched files; the existing unused-ignore warnings are unchanged.
• npm run lint shows 0 errors and npm run build succeeds.
• Browser check on port 5820 with the assistant WebSocket mocked: the chips render under the greeting, and clicking Report a bug prefills Bug report: with the new placeholder and focus.

Assumptions

• A reopened feature keeps its original priority rather than jumping the queue. Features that were already done usually have low priority numbers, so they get picked up soon anyway.
• The chips prefill the input instead of sending a message right away, so the user can describe the bug in the same message.
• I didn't add feature_report_bug to the coding, testing or initializer agent tool lists. They already have feature_mark_failing.

🤖 Generated with Claude Code

[zwanski-start]

🔍 QA report: ✅ Passed

Tester: Barbara (cubefarm agent, in a fresh session) · Round: 1 · Author: Guido

The PR adds a feature_report_bug MCP tool and gives the assistant access to it and to feature_get_graph. A bug report reopens the existing feature as pending instead of creating a new one, as issue #135 asks. Running the real MCP server over stdio showed correct reopen/append behaviour and correct rejection of bad input. The new tests, ruff, the security tests, the UI lint and the UI build all pass, and the 21 pytest failures are the same as on master. In the browser, with the assistant WebSocket mocked, the help / new feature / bug report quick-action buttons render, fill in the input and hide after the first message, with no console errors.

	Check	Details
✅	Issue AC: report a bug against an existing (passing) feature and move it back to pending	Over MCP stdio: created 2 features, marked #1 passing, then called feature_report_bug(1, 'Empty pw accepted', steps). Result: passes=false, 'Bug report: …' appended to the description, steps appended, priority unchanged, total still 2. A second report on the now-pending feature returned 'updated (still pending)'. The Kanban board then showed #1 in Pending with the bug text.
✅	Validation and error cases	feature_id=0 and an empty description are rejected by pydantic. A missing feature id returns an error. An in_progress feature is rejected and left unchanged. A Unicode description is stored intact.
✅	Assistant toolset and permissions	feature_report_bug and feature_get_graph were added to the allowed tools. feature_mark_passing, feature_mark_failing, feature_mark_in_progress, feature_claim_and_get, Write, Edit and Bash are still disallowed. security.py and the localhost middleware are not touched. The system prompt and greeting describe the help / new feature / bug report flows.
✅	No regressions in the Python test suite (compared with master)	PR: 149 passed, 21 failed. The 21 failures (test_devserver_security shell-runner/empty-command cases) are identical on a master worktree, so they are environmental and not caused by this PR. The new test_feature_report_bug.py has 5 tests and all pass.
✅	UI quick-action buttons	With /api/assistant/ws mocked: the Ask for help, New feature and Report a bug buttons render under the greeting. Clicking Report a bug fills in 'Bug report: ', changes the placeholder, focuses the textarea and puts the caret at the end. After a message is sent the buttons are hidden.
✅	Responsive layout at phone width	At 390x844 the buttons wrap onto two rows and there is no horizontal overflow (scrollWidth - innerWidth = 0).
✅	Kanban and console errors	The Kanban board renders the reopened feature with no console errors. The only error seen in the session was a 404 for /api/assistant/conversations/qa-demo/1, caused by the fake conversation id that my mock emitted. An earlier .map TypeError came from a bad response my mock returned for the conversation detail, and it went away once that mock was removed.
✅	Minor UX nits (non-blocking)	The chat shows the raw tool name 'mcp__features__feature_report_bug' because useAssistantChat has no friendly label for it. The bug-report placeholder persists after sending and after starting a new chat. The 'Bug report:' markdown appears as literal asterisks on Kanban cards.
⏭️	Playwright e2e suite (test:e2e)	Not run. The UI change was checked manually in the browser instead.

🧪 Commands run

Command	Result
ruff check .	All checks passed
python -m pytest -q	149 passed, 21 failed (the same 21 fail on origin/master)
python -m pytest -q test_feature_report_bug.py	5 passed
python test_security.py	ALL TESTS PASSED
mypy . (PR vs master diff)	No new errors from the PR. The only differences are a shifted line number on an existing unused-ignore and a venv/ file that exists only in the PR worktree.
npm --prefix ui run lint	0 errors, 6 warnings
npm --prefix ui run build	tsc -b && vite build succeeded
python mcp_probe.py (MCP stdio client calling feature_report_bug)	Tool registered, schema correct, all success and error cases behaved as expected
uvicorn server.main:app --host 127.0.0.1 --port 5443 (isolated HOME)	Booted. /api/projects and /api/projects/qa-demo/features returned 200 with the reopened feature. Server stopped afterwards.

No browser screenshots were taken in this round.

_{Posted by cubefarm · merges automatically once GitHub's checks pass}