UC-6 Student receives a post-check-in tip

Primary actor	Student
Priority	Must
Satisfies	FR-E1, FR-E6
Trigger	A successful event check-in (UC-3).

Main success scenario

1. After the check-in is recorded, the system builds a tip request from the task's title, activity type and the number of required tasks still remaining. It carries no student identifier and no free text.
2. The tip generator matches the task to a topic in the SHS-cleared corpus and returns one line of SHS-authored copy, a resource link, and a next step.
3. The scan response carries the tip; the app shows it with the completed week.

Extensions

• 2a. The generator raises. A generic fallback tip is shown. The check-in already succeeded and is never rolled back.
• Model-backed generation. The TipGenerator seam accepts a Bedrock-shaped request built only from the tip request's fields. No model is called in the shipped configuration.

Acceptance criteria (Gherkin)

Feature file	Test module
post_checkin_tip.feature	test_post_checkin_tip_bdd.py

Plain pytest: test_tips.py.

Views

• Process: UC-6 Post-check-in tip
• Logical: services/tips and the corpus in system components; ContentView (a tip view is recorded for the engagement report) in the domain model

Code: backend/app/services/tips.py, backend/app/services/guide_corpus.py.