Independent extension: a response style for each conversation
Add three application-defined styles: Concise, Detailed, and Socratic. The learner chooses a style for a conversation; that choice persists and influences subsequent requests in that conversation. This is a capstone proposal, not an existing PocketChat feature. Start from your tested context-policy branch.
Design before editing
Decide where the enum and selection live, how existing serialized conversations receive a default, and how the selected value reaches the service. Do not append raw user-written “system instructions” to the trusted Android Engineers identity. Build a short instruction from an allowlisted style value. Keep the directory, identity, and limitations intact.
The current service signature receives key, model, and context parts. A useful design introduces a typed request object or a narrowly scoped style parameter. Update both debug and release implementations and every fake. A change that only alters a UI label is not a completed feature.
Acceptance criteria
- Create two conversations with different styles; switching does not leak one style into the other.
- Save/reopen through Room and preserve the selected style. Older serialized data without the field loads with a documented default.
- Request tests prove the chosen style reaches the correct request while the curated guide remains present.
- Retry uses the conversation's selected policy consistently; document behavior if it changes during an active request.
- Missing credentials, Stop, and interrupted-state recovery still work.
- The UI is accessible with large text and announces the selected style.
Suggested test shape
Use controlled requests to assert the exact style instruction, not a nondeterministic natural-language answer. Then evaluate three live prompts across the styles for usefulness. “Socratic” should invite reasoning without becoming evasive; “Concise” should not omit essential correctness.
Portfolio evidence
Provide an architecture note, source diff, migration/default test, request tests, device observation, and a short demo using nonpersonal content. Explain why a serializable field default can preserve compatibility for this aggregate representation but does not replace proper migration planning when the Room schema changes.
Do not ship the debug key workflow as production authentication. Do not claim the capstone guarantees a model's tone; instructions are evaluated behavior. The final review should defend the implementation and its limits without copying this assignment back as evidence.