Independent task
Extend each story with editable character facts: a name, a short description and an optional rule such as “the brass robot cannot fly.” These are user-authored story facts, not discoveries that the model has verified. The feature must work locally, persist across restart and affect only that story's next prompt. This is new learner work; it is not implemented in the published baseline.
Design before code
Choose a serializable domain representation with default values so old story JSON remains readable. Keep facts in the Story payload rather than a global singleton. Define input bounds (for example at most five facts, each at most 200 characters), editing rules while generation runs, and how facts consume the context budget. Character counts still are not tokens. An explicit policy should decide whether to reject excess facts or shorten history; silently truncating an essential fact can change the story.
Add a Compose editor that saves through the same ViewModel/persistence boundary as stories. Render labels that distinguish user facts from generated prose. Do not ask the model to edit Room rows, grant permissions or execute instructions extracted from a photo.
Acceptance tests
- An older serialized story without facts loads with an empty collection.
- Saving a fact and reopening preserves it for that story.
- Another story never receives that fact in its prompt.
- Blank or oversized facts follow the documented validation rule.
- Accepted scenes and facts appear in the prompt; discarded drafts do not.
- A cancelled generation does not overwrite an edit made after the operation ended.
Use a fixture of the old JSON rather than relying on a newly constructed object to prove backward compatibility. If you change a Room table, add and test a migration; if only JSON changes, still test serialization defaults and application-level validation.
Deliverables and review
Submit a small diff, failing-then-passing tests, screenshots of editor states, and a before/after prompt example containing non-sensitive fictional data. Write a short tradeoff note on JSON versus normalized facts, context allocation and edits during generation. For a compatible device, evaluate whether the output follows facts; passing a string-inclusion test is not evidence of model adherence.
Optional second task: replace raw native errors with categorized recovery guidance without discarding the technical cause. Do not add PDF export, RAG, automatic camera streaming or cloud fallback to finish this capstone. Those need their own requirements and evaluation.
A strong submission explains what was verified, handles old data and isolates stories. UI polish alone or a sample output copied into the app does not meet the engineering requirements.