AI Coach opens and analyzes the wrong issue when invoked from Issue Board

[mottych]

Description

Type Bug
Category AI Coach / Issue Board
Environment

• Purpose Path (production or dev — specify if needed)
• Issue Board view
• AI Coach “Resolve with AI” modal

Summary

When selecting the first issue (“testing focus”) and launching the AI Coach, the AI Coach incorrectly loads and analyzes a different issue (“get motivated”). The AI is not respecting the user’s selected issue context.

Steps to Reproduce

1. Navigate to the Issue Board.
2. Click on the first issue titled “testing focus.”
3. Select Resolve with AI to open the AI Coach modal.
4. Observe which issue the AI Coach begins analyzing.

Actual Behavior

The AI Coach ignores the selected issue (“testing focus”) and instead loads the content of a different issue (“get motivated”), including its title, description, and related goals.

Expected Behavior

The AI Coach should always load and analyze the exact issue the user selected, passing the correct issue ID and metadata into the AI prompt.

Impact

• Breaks user trust in AI accuracy
• Creates confusion and incorrect coaching context
• Blocks QA from validating AI behavior
• Could cause users to receive irrelevant or inappropriate guidance

Suspected Cause (for engineering)

Likely a mismatch in:

• Issue ID passed from the Issue Board → AI Coach modal
• State management not updating the selected issue before the AI call
• A stale or cached issue object being reused
• Incorrect index mapping in the Issue Board list

Attachments

• Screenshot showing AI Coach analyzing “get motivated” despite selecting “testing focus”

Priority

Attachments

• Attachment

[mottych]

Approved design for implementation:\n\n- Preserve the existing coaching workflow (start/check/resume/pause/timeout/auto-resume behavior) and only change how active sessions are matched.\n- Session identity will be derived from the topic's required request payload parameters (REQUEST-source parameters required to start the topic), not from template placeholders or enriched values.\n- For topics without required request parameters, behavior remains unchanged: one active session per user/topic.\n- For scoped topics like issue coaching, active-session matching must compare tenant + user + topic + derived request scope values (for example issue_id), so different objects under the same topic can have separate active sessions.\n- Store the derived request scope values on the session header/metadata when creating the session.\n- Update session check so the frontend can send the same identifying parameters it uses on start, and return the matching session_id when one exists.\n- Keep resume as session_id-based only.\n- Apply the same scoped matching to tenant conflict detection so different scoped objects do not block each other.\n\nPlanned implementation areas:\n- coaching/src/api/routes/coaching_sessions.py\n- coaching/src/services/coaching_session_service.py\n- coaching/src/domain/entities/coaching_session.py\n- coaching/src/domain/ports/coaching_session_repository_port.py\n- coaching/src/infrastructure/repositories/dynamodb_coaching_session_repository.py\n- relevant coaching tests\n\nValidation plan:\n- Add focused tests for unscoped topics vs scoped topics, session/check behavior, start behavior, and tenant conflict matching.\n- Run targeted pytest during development.\n- Run ruff, format, mypy, and full pytest or pre-commit checks before completion.

[mottych]

Implemented and deployed the scoped-session fix for AI coaching issue context.\n\nWhat changed:\n- Active coaching sessions are now matched by tenant + user + topic + normalized required request parameters (for example issue_id), instead of topic alone.\n- The derived request scope is stored on the coaching session record when a session is created.\n- GET /ai/coaching/session/check now accepts scoped identifying query parameters alongside opic_id, so the frontend can check the correct object-specific session before starting or resuming.\n- POST /ai/coaching/resume remains session_id-based and the existing pause/timeout/auto-resume workflow was left unchanged.\n\nValidation completed:\n- Focused service and API tests for scoped vs unscoped session matching passed.\n- Repository pre-commit verification passed (ruff, format, type checks, unit tests).\n- Dev deployment passed after merge to dev.\n\nNote:\n- A separate Sync Shared Documentation workflow failed on the merge commit summary step because the workflow currently does not safely escape commit messages containing single quotes. The application deployment itself succeeded and the issue-specific fix is live on dev.