Advanced Directives screen

Description

That a directive exists, who has access to it, and where it is kept — not the
directive's contents and not credentials to reach it. Static profile.

The existing one-line body already states that boundary; it is the whole point
of the ticket rather than a detail.

Fields — shape needs confirming; the boundary does not

• Directive exists (yes/no)
• Type or name
• Who has access — name, relationship, phone
• Where it is kept
• Notes

Excluded: the directive text, scans or photos of it, and any login to a
service holding it. The last of those is the same reasoning
0006 applies to portal
credentials.

Acceptance Criteria

• Scope boundary against #44 agreed before any code
• Single-record profile, edited in place
• Persists to the encrypted local database and survives a relaunch
• No field for directive contents, no file or image attachment, no credentials
• WCAG-aligned; copy neutral per 0004
• Covered by unit tests

Additional Info and Resources

• 0006 for the credential reasoning
• Attachments would be a new capability with its own encryption and export questions. Out of scope; raise an issue if someone wants it

QA

• Fill in, relaunch, confirm persistence
• Search the diff for attachment or file-picker APIs — expect nothing
• VoiceOver/TalkBack through the screen

Read docs/decisions/0006-excluded-field-safety-boundary.md and review issue #44 before confirming the scope boundary. Then locate the existing profile screen and its encrypted local database persistence, add unit tests for the single-record edit and relaunch behavior, and verify the listed exclusions and accessibility QA are satisfied.