muninn/docs/superpowers/specs/2026-07-18-sites-and-accounts-design.md

Sites & Social Accounts Manager — Design

Purpose

A local-network-only Laravel app for managing two independent lists of data that an AI agent will later consume via API to act on the user's behalf:

1. Sites — a list of the user's websites (name, url, description).
2. Social Accounts — a list of social network accounts (network, username, email, password, type) that the AI can use to post, comment, or like on the user's behalf.

Both lists are managed through a Livewire UI (full CRUD) and exposed read-only via a JSON API for AI consumption.

Scope

• CRUD UI for Sites
• CRUD UI for Social Accounts
• Read-only JSON API for both resources, with basic filtering
• No authentication anywhere (UI or API) — this runs on the local network only
• No relationship between Sites and Social Accounts — fully independent resources

Out of scope:

• Authentication/authorization (UI or API)
• Password encryption/hashing (stored and returned as plain text by design, since the AI needs to use credentials directly)
• Linking sites to accounts
• Multi-type accounts (an account has at most one type)
• Write endpoints on the API (create/update/delete are UI-only)

Data Model

sites table

Column	Type	Constraints
id	bigint	PK
name	string	required
url	string	required
description	text	nullable
created_at / updated_at	timestamps

social_accounts table

Column	Type	Constraints
id	bigint	PK
network	string (enum)	required — one of: twitter, instagram, facebook, reddit, tiktok, linkedin, youtube, other
username	string	required
email	string	required
password	string	required, stored in plain text (no hashing/encryption)
type	string (enum)	nullable — one of: post, comment, like, or null
created_at / updated_at	timestamps

No foreign keys between the two tables.

UI (Livewire, no auth)

Simple nav with two sections: Sites and Social Accounts.

Sites

• Table view: name, url, description, actions (edit/delete)
• Create/Edit via modal form (name and url required, description optional)
• Delete with confirmation

Social Accounts

• Table view: network, username, email, type, actions (edit/delete)
• Password is stored/edited as plain text in the form, but masked in the table view with a reveal toggle (UI convenience only — not a security control, since the API and DB already hold it in plain text)
• Create/Edit via modal form — network (dropdown), username, email, password all required; type dropdown optional (post/comment/like/none)
• Delete with confirmation

Exact Livewire component structure (single component with modal vs. separate index/form components) is an implementation detail decided during planning.

API (read-only, no auth, JSON)

Standard Laravel API resource controllers, index/show actions only (no store/update/destroy routes). Responses via Eloquent API Resources.

• GET /api/sites — list all sites
  • ?name= — optional partial match filter on name
• GET /api/sites/{id} — single site
• GET /api/accounts — list all social accounts, including the plain-text password field
  • ?network= — optional exact match filter
  • ?type= — optional exact match filter
• GET /api/accounts/{id} — single social account, including password

No pagination requirements specified — dataset is expected to be small (personal use). Standard Eloquent collection response is sufficient; can add pagination later if needed.

Testing

• Feature tests for CRUD flows (Livewire component tests) for both resources
• Feature tests for API endpoints: list, show, and filter behavior for both resources