[007] Family Social Platform (MVP)

A social platform where users form confirmed family relationships (Spouse, Parent, Child, Sibling) and share posts visible only to direct relationships—never friends-of-friends.

Build this as a Python backend service with no UI; expose the functionality below through an HTTP API.

CORE CONSTRAINTS
- No transitive visibility: only Active direct relationships can see your posts/birth date
- One relationship per user pair (Pending or Active blocks new requests; to change type, end then re-request)
- Mutual acceptance required for relationships; requests never expire

1) ACCOUNTS & PROFILES

Registration & Login
- Sign up with email (unique, case-insensitive) and password (min 8 characters)
- After signup, user must complete profile (Username + Display Name required) before accessing any features
- Login errors must not reveal whether email or password was incorrect
- Logout ends the session
- Delete Account: removes all user data; all relationships (Active and Past) involving this user show "Deleted User" as the other party in other users' Past sections

Profile Fields
- Username: required, 3–30 chars, alphanumeric + underscores only, unique (case-insensitive)
- Display Name: required
- Bio, Profile Photo, Birth Date: optional; Birth Date cannot be in the future

Profile Visibility
- Public (anyone can see): Display Name, Username, Profile Photo, Bio, Active relationships list
- Relationship-only (requires Active relationship): Birth Date, posts list

2) FAMILY RELATIONSHIPS

Relationship Types
When sending a request, select how you view this person:
- "Parent" = this person is my parent
- "Child" = this person is my child
- "Spouse" = this person is my spouse
- "Sibling" = this person is my sibling

Reciprocal Types (after acceptance)
- Spouse ↔ Spouse, Sibling ↔ Sibling
- Parent ↔ Child (sender sees "Parent", recipient sees "Child")
- Child ↔ Parent (sender sees "Child", recipient sees "Parent")

Request Flow
- Send: appears in your Outgoing Requests and their Incoming Requests (recipient sees what type sender selected, not the reciprocal type yet)
- Accept: relationship becomes Active
- Decline: moves to Past for both parties
- Cancel (sender only): moves to Past for both parties
- Cannot request relationship with yourself

Ending Relationships
- Either party can end an Active relationship
- Both immediately lose access to each other's posts and birth date
- Relationship moves to Past for both

Relationships Data
- Incoming Requests, Outgoing Requests, Active, Past
- Active relationships exposed publicly on profiles, grouped by type, alphabetical by username
- Past relationships visible only to the owner; shows: other user's name, type, status (Declined/Canceled/Ended), date moved to Past
- After any status (Declined/Canceled/Ended), either party may send a new request

3) POSTS

Creation & Content
- Post requires at least one of: non-empty caption, image(s)
- Up to 4 images per post

Editing & Deletion
- After publish: only caption can be edited; images are immutable
- Author can delete their own posts (removed everywhere)

Visibility
- Visible to author (always) and users with Active relationship at viewing time
- Relationship ends → immediate loss of access to each other's posts

4) FEED & SEARCH

Home Feed
- Returns posts from yourself + Active relationships, newest first
- Each post includes author, timestamp, caption, images

User Search
- Query matches username OR display name (case-insensitive substring match)
- No self-exclusion
- Results sorted alphabetically by username

The issue names no files, tests, or entry points. Start by mapping the repository's Python service structure and HTTP API entry point, then break the MVP requirements into independently testable account, relationship, post, feed, and search behavior. Done requires implementing and testing the complete specified API and visibility rules.

Escrito por el modelo de indexación a partir del texto del issue.