chore: OpenSpec scaffold

.gitignore

@@ -0,0 +1,16 @@
+# General
+.DS_Store
+*.log
+node_modules/
+dist/
+build/
+.cache/
+.env*
+
+# Mobile/Flutter/Expo (if chosen later)
+.gradle/
+android/app/build/
+ios/Pods/
+.flutter-plugins*
+.expo/
+

README.md

@@ -0,0 +1,22 @@
+# More Than A Diagnosis — Community Hub (OpenSpec)
+
+This repository hosts the multi‑platform community hub for morethanadiagnosis.com, designed for people living with cancer or terminal diagnoses. The project strictly follows the OpenSpec methodology and is compatible with https://github.com/Fission-AI/OpenSpec.
+
+Key goals
+- Full feature parity across Android, iOS, and Web
+- Accessibility tailored to chronic/terminal illness communities (WCAG 2.2 AA+)
+- Strong privacy and compliance practices (HIPAA/GDPR/platform policies)
+- Open APIs and modular architecture to support open‑source and third‑party extensions
+- Seamless migration from the existing Wix site
+
+Start here
+- See `openspec/project.md` for conventions, workflow, and architectural guardrails.
+- Propose changes with the template in `openspec/templates/proposal-template.md`.
+- Active and archived proposals live under `openspec/changes/`.
+- Approved/implemented specs live under `openspec/specs/`.
+
+Repository layout
+- `openspec/` — OpenSpec workflow, specs, and changes
+- `apps/` — App code (placeholders for web and mobile; to be proposed via OpenSpec)
+- `packages/` — Shared libraries/modules (to be proposed via OpenSpec)
+

ROADMAP.md

@@ -0,0 +1,32 @@
+# Roadmap (Mapped to OpenSpec Cycles)
+
+Phase 0 — Foundations (Weeks 0–2)
+- /propose Project guardrails → finalize `openspec/project.md`
+- /propose Architecture baseline → `openspec/specs/architecture.md`
+- /propose Privacy & Accessibility baselines → `openspec/specs/privacy-compliance.md`, `openspec/specs/accessibility.md`
+
+Phase 1 — Migration Prep (Weeks 2–4)
+- /propose Wix inventory & export plan → `openspec/specs/migration-wix.md`
+- /propose Data model v1 → `openspec/specs/data-model.md`
+- /review compliance,a11y on migration plan
+
+Phase 2 — Core Features MVP (Weeks 4–10)
+- Forum MVP → `feature-forum.md`
+- Profiles → `feature-profiles.md`
+- Resources → `feature-resources.md`
+- Blog (internal + Substack) → `feature-blog.md`
+
+Phase 3 — Media & Tribute (Weeks 8–12)
+- Podcast hosting → `feature-podcast.md`
+- Tribute page → `feature-tribute.md`
+
+Phase 4 — Commerce (Weeks 10–14)
+- Merch store → `feature-merch.md`
+
+Phase 5 — Full Migration & Launch (Weeks 12–16)
+- Dry‑run imports, redirects, content QA
+- A11y + compliance sign‑off, incident runbook
+
+For each item
+- Propose → Review (a11y/compliance/security/platform) → Apply (merge spec) → Implement → Validate → Archive
+

apps/README.md

@@ -0,0 +1,11 @@
+# Apps (placeholders)
+
+Code for Android/iOS/Web apps will live here once proposed and approved via OpenSpec.
+
+Candidates to be proposed
+- React Native + Expo (Android/iOS) with a shared design system
+- Next.js (Web) with server‑side rendering and shared UI package
+- Or Flutter (Android/iOS/Web) for single codebase parity
+
+Decide via proposal referencing `openspec/specs/architecture.md`.
+

openspec/README.md

@@ -0,0 +1,23 @@
+# OpenSpec Workflow (Project-Compatible)
+
+This repository uses OpenSpec for all proposals, reviews, changes, and specifications. The structure and slash commands are compatible with https://github.com/Fission-AI/OpenSpec.
+
+Directory layout
+- `openspec/project.md` — Project conventions, workflow details, and architectural guidelines
+- `openspec/specs/` — Accepted/implemented specifications
+- `openspec/changes/` — Proposals and change cycles (propose → review → apply → archive)
+- `openspec/templates/` — Proposal templates and authoring helpers
+
+Lifecycle (every change)
+1) Propose: author a proposal in `openspec/changes/` using the template
+2) Review: async discussion; resolve risks, compliance, and accessibility
+3) Apply: merge and move normative content into `openspec/specs/`
+4) Archive: close the proposal with a link to the applied spec/PR
+
+Slash commands (AI-friendly)
+- `/propose` — start a proposal using the template
+- `/review` — request targeted review (compliance, accessibility, security, data, mobile, web)
+- `/apply` — prepare the agreed diff and migration steps
+- `/archive` — mark the proposal as archived with links
+- Additional commands and examples: `openspec/ai-commands.md`
+

openspec/ai-commands.md

@@ -0,0 +1,30 @@
+# AI Slash Commands Workflow
+
+These commands align with OpenSpec and can be used with Claude Code, Codex, Copilot, or similar assistants. Include them in PR descriptions, issues, or comments.
+
+Core commands
+- `/propose <title> [scope=spec|infra|policy] [labels=a11y,compliance] [assignees=@owner] [model=claude|gpt|copilot]`
+  - Scaffolds `openspec/changes/YYYY-MM-DD-title/proposal.md` from the template
+- `/review areas=accessibility,compliance,security,mobile,web,backend`
+  - Summons focused review checklists and routes to domain owners
+- `/apply spec=openspec/specs/<target>.md [pr=<link>]`
+  - Moves accepted sections into the target spec; opens/updates PR
+- `/archive reason="accepted into <spec>" link=<PR>`
+  - Finalizes the change and records traceability
+
+Helpful commands
+- `/assign @user1 @user2` — set reviewers/owners
+- `/estimate 5d` — initial t‑shirt or time estimate
+- `/plan` — generate a milestone/task breakdown tied to the spec
+- `/generate tests scope=<module>` — create or update test skeletons per acceptance criteria
+
+Usage examples
+- Start a feature: `/propose Community Forum MVP scope=spec labels=a11y,compliance,security model=claude`
+- Ask for targeted review: `/review areas=accessibility,compliance`
+- Apply after approval: `/apply spec=openspec/specs/feature-forum.md pr=<link>`
+- Archive the change: `/archive reason="merged" link=<PR>`
+
+Agent notes
+- Keep assistants grounded in `openspec/project.md` guardrails.
+- When generating code, require an approved spec link in the PR description.
+

openspec/changes/README.md

@@ -0,0 +1,16 @@
+# Changes
+
+OpenSpec change proposals live here during their lifecycle:
+
+1) Propose — create `yyyy-mm-dd-<short-title>/proposal.md` using the template
+2) Review — iterate via comments; track decisions and updates in the same folder
+3) Apply — move normative content into `openspec/specs/` via PR; link back
+4) Archive — add `ARCHIVED.md` with reason and pointers
+
+Naming
+- Folder: `YYYY-MM-DD-short-title`
+- Primary file: `proposal.md`
+
+Helpers
+- Use `/propose`, `/review`, `/apply`, `/archive` slash commands for consistency
+

openspec/project.md

@@ -0,0 +1,69 @@
+# OpenSpec Project Conventions and Architectural Guidelines
+
+Status: draft
+Owners: Program Lead, Architecture, Compliance
+Last updated: 2025-11-17
+
+Purpose
+- Define repository‑wide conventions for OpenSpec usage, spec authoring, compliance and accessibility gates, and architectural boundaries.
+
+OpenSpec conventions
+- Filenames: use kebab‑case; prefix with domain (e.g., `feature-forum.md`).
+- Status labels: `draft`, `in-review`, `approved`, `implemented`, `archived`.
+- Each proposal follows the template in `openspec/templates/proposal-template.md` and lives under `openspec/changes/`.
+- Accepted specs move to `openspec/specs/` with clear versioning.
+- One change = one lifecycle: propose → review → apply → archive.
+
+Slash command conventions
+- `/propose <title> [scope=spec|infra|policy] [labels=...] [assignees=...] [model=claude|gpt|copilot]`
+- `/review <areas=accessibility,compliance,security,mobile,web,backend>`
+- `/apply <spec=<file>> [pr=link]` moves normative text to `openspec/specs/`
+- `/archive <reason> [link=PR]` marks closure with traceability
+- `/assign @user1 @user2` sets proposal owners
+
+Decision records
+- Record important decisions inline in proposals under “Alternatives considered” and “Decision & rationale”.
+- For cross‑cutting decisions, add a short entry in `openspec/specs/architecture.md#decisions`.
+
+Architecture (guardrails)
+- Modular domain map:
+  - Identity & Profiles
+  - Community Forum
+  - Content (Blog & Resources)
+  - Media (Podcast)
+  - Tribute/Memorials
+  - Commerce (Merch)
+  - Compliance, Auditing & Privacy
+  - Platform (Mobile/Web Apps) and Design System
+  - Integration & APIs
+
+API standards
+- OpenAPI-first for HTTP; JSON over HTTPS; WebSocket for realtime.
+- OAuth2/OIDC for auth; short‑lived access tokens; rotate refresh tokens.
+- Resource versioning via URI (`/v1`) and schema versioning in payloads as needed.
+- Pagination, idempotency keys for writes, and explicit rate limits.
+
+Data protection & compliance
+- Data classes: `Public`, `PII`, `PHI`. Keep PHI minimized and isolated.
+- Encryption: TLS 1.3 in transit, AES‑256 at rest; per‑table/field encryption for PHI/PII where applicable.
+- Access controls: role‑based (RBAC) and attribute‑based (ABAC) where necessary; audited access to sensitive data.
+- Data retention & deletion: GDPR erase requests and well‑defined retention policies per data class.
+- Logging: no PHI/PII in logs; use structured logs with redaction.
+
+Accessibility baseline
+- Target WCAG 2.2 AA+; support reduced motion, dynamic type/large fonts, high contrast, screen readers, and keyboard/assistive navigation.
+- Mobile: iOS VoiceOver / Android TalkBack parity for all screens.
+- Web: semantic landmarks, focus order, ARIA where necessary; test via automated and manual checks per spec.
+
+Observability & quality
+- Tracing for backend APIs; structured logs; SLOs for critical user journeys.
+- Test pyramid per component: unit, integration, e2e. Accessibility checks included in CI for UI changes.
+
+Release management
+- Feature flags for staged rollouts. Rollback plan defined in each proposal.
+- Data migrations versioned and reversible; dry‑runs for large imports.
+
+Contribution
+- All code contributions must link to an approved OpenSpec change.
+- Security review is mandatory for anything touching PHI/PII.
+

openspec/specs/accessibility.md

@@ -0,0 +1,21 @@
+# Accessibility Spec
+
+Status: draft
+Owners: Accessibility Lead
+
+Standards
+- WCAG 2.2 AA minimum; include reduced motion, dynamic type/large text, high contrast, screen reader parity.
+
+Mobile
+- iOS VoiceOver and Android TalkBack support across all screens; large tap targets; flexible layouts.
+
+Web
+- Semantic HTML landmarks, focus management, ARIA when necessary, keyboard navigation.
+
+Validation
+- Automated: axe checks in CI for web; lint rules for RN/Flutter accessibility.
+- Manual: assistive tech smoke tests per release; usability sessions with community advisors.
+
+Non‑functional
+- Performance budgets mindful of low‑end devices and intermittent connectivity.
+

openspec/specs/architecture.md

@@ -0,0 +1,27 @@
+# Architecture & APIs
+
+Status: draft
+Owners: Architecture
+
+Overview
+- Modular, domain‑driven architecture with clear boundaries and open APIs.
+
+Modules
+- Identity & Profiles, Forum, Content (Blog/Resources), Media (Podcast), Tribute, Commerce, Compliance, Platform (Design System + Apps), Integration.
+
+Client platforms
+- Mobile: Android/iOS (proposed: React Native/Expo or Flutter — to be decided via proposal)
+- Web: Next.js/SSR or Flutter Web — parity is mandatory and defined per feature spec
+
+Backend
+- Proposed: API service with OpenAPI, Postgres primary store, object storage for media, search index for forum/content, queue for async tasks.
+
+API standards
+- REST+JSON with OpenAPI; WebSocket for realtime forum/presence; OAuth2/OIDC; rate limits; pagination; idempotency keys.
+
+Data boundaries
+- Strict separation of PHI/PII domains; audit and consent services.
+
+Decisions
+- <record cross‑cutting decisions here>
+

openspec/specs/data-model.md

@@ -0,0 +1,15 @@
+# Data Model
+
+Status: draft
+Owners: Architecture, Data
+
+Entities (initial)
+- User, Profile, Consent, ForumCategory, ForumThread, ForumPost, BlogPost, Resource, PodcastEpisode, Tribute, Product, Order, MediaAsset.
+
+Notes
+- Mark each field with data class (Public/PII/PHI) and retention policy.
+- Define soft‑delete vs hard‑delete behavior for user‑generated content.
+
+Migrations
+- Version every schema change; ensure reversible steps; seed data for initial categories/resources.
+

openspec/specs/feature-blog.md

@@ -0,0 +1,18 @@
+# Feature: Blog (Internal + Substack Cross‑Posting)
+
+Status: draft
+Owners: Content
+
+Summary
+- Native blog with editor, scheduling, tags, and optional Substack cross‑posting.
+
+Requirements
+- Members‑only posts; SEO for public posts; RSS/Atom
+- Cross‑post integration: publish and sync canonical links and excerpts
+
+API
+- Posts CRUD; media; tags; cross‑post webhooks
+
+Acceptance Criteria
+- Content parity; accessibility in editor and output; analytics without PII/PHI
+

openspec/specs/feature-forum.md

@@ -0,0 +1,22 @@
+# Feature: Community Forum
+
+Status: draft
+Owners: Community
+
+Summary
+- Members forum with categories, threads, posts, reactions, moderation, notifications, and realtime updates.
+
+Requirements
+- Accessibility parity (screen readers, keyboard navigation, large text)
+- Privacy by default: pseudonyms, private groups, report/flag, mod tooling
+- Realtime: typing/presence optional; live updates for new posts
+
+API
+- Threads: list/create/update; Posts: list/create/edit/delete; Moderation endpoints
+
+Migration
+- Import forum‑like content from Wix (if any); mapping in `migration-wix.md`.
+
+Acceptance Criteria
+- Cross‑platform UI parity and assistive tech checks; moderation workflows verified
+

openspec/specs/feature-merch.md

@@ -0,0 +1,17 @@
+# Feature: Merch Store
+
+Status: draft
+Owners: Commerce
+
+Summary
+- Storefront for merchandise with secure checkout through a PCI‑compliant provider.
+
+Requirements
+- External payment processor; no card data stored; tax/shipping rules
+
+API
+- Product catalog; orders; webhooks for fulfillment
+
+Acceptance Criteria
+- Accessibility parity; privacy and PCI boundaries; fraud checks
+

openspec/specs/feature-podcast.md

@@ -0,0 +1,17 @@
+# Feature: Podcast Hosting
+
+Status: draft
+Owners: Media
+
+Summary
+- Host and distribute podcast episodes with transcripts and player embeds.
+
+Requirements
+- Upload flow with loudness normalization; transcripts for accessibility; RSS feed
+
+API
+- Episodes CRUD; media processing callbacks; feed generation
+
+Acceptance Criteria
+- Transcripts available; accessible player controls; analytics without PII/PHI
+

openspec/specs/feature-profiles.md

@@ -0,0 +1,18 @@
+# Feature: Profiles
+
+Status: draft
+Owners: Identity
+
+Summary
+- Full profile management with privacy controls and optional pseudonyms.
+
+Requirements
+- Profile fields with data class tags; consent-driven visibility controls
+- Avatar and pronouns; health journey fields optional and private by default
+
+API
+- CRUD for profiles; consent endpoints; media upload policy
+
+Acceptance Criteria
+- GDPR export/delete; HIPAA constraints respected; accessibility parity
+

openspec/specs/feature-resources.md

@@ -0,0 +1,18 @@
+# Feature: Resources (Public + Members‑Only)
+
+Status: draft
+Owners: Content
+
+Summary
+- Curated resources with access tiers, tagging, and search.
+
+Requirements
+- Public section for discovery; members‑only section for community resources
+- Accessibility readable layouts; offline‑friendly patterns where feasible
+
+API
+- Resources CRUD; taxonomy; search index
+
+Acceptance Criteria
+- Clear labeling of access tier; WCAG checks; analytics without PII/PHI
+

openspec/specs/feature-tribute.md

@@ -0,0 +1,17 @@
+# Feature: Tribute / Memorial Page
+
+Status: draft
+Owners: Community
+
+Summary
+- Tribute pages honoring members; controls for family moderators; optional donations link.
+
+Requirements
+- Sensitive defaults; moderation workflows; memory posts with media
+
+API
+- Tribute CRUD; permissions; media; moderation
+
+Acceptance Criteria
+- Accessibility parity; content controls; privacy defaults
+

openspec/specs/index.md

@@ -0,0 +1,17 @@
+# Specs Index
+
+This index lists accepted/implemented specs and their current status. Drafts live under `openspec/changes/` until approved.
+
+- Architecture & APIs — `openspec/specs/architecture.md`
+- Accessibility — `openspec/specs/accessibility.md`
+- Privacy & Compliance — `openspec/specs/privacy-compliance.md`
+- Data Model — `openspec/specs/data-model.md`
+- Community Forum — `openspec/specs/feature-forum.md`
+- Profiles — `openspec/specs/feature-profiles.md`
+- Blog (internal + Substack) — `openspec/specs/feature-blog.md`
+- Resources (public + members) — `openspec/specs/feature-resources.md`
+- Podcast — `openspec/specs/feature-podcast.md`
+- Tribute/Memorial — `openspec/specs/feature-tribute.md`
+- Merch Store — `openspec/specs/feature-merch.md`
+- Wix Migration — `openspec/specs/migration-wix.md`
+

openspec/specs/migration-wix.md

@@ -0,0 +1,28 @@
+# Migration: Wix → Community Hub
+
+Status: draft
+Owners: Data, Content
+
+Scope
+- Inventory existing Wix content and data; define export, mapping, transform, validate, and import steps.
+
+Data sources
+- Pages, blog posts, media, members, products (if applicable), forms/submissions.
+
+Mapping template
+- Source → Target entity
+- Field mapping with transforms
+- Data class (Public/PII/PHI)
+- Retention policy
+- Notes
+
+Process
+1) Export: obtain Wix exports (CSV/JSON/API) and media dumps
+2) Transform: normalize slugs, HTML → markdown where needed, sanitize
+3) Validate: dry‑run import, link integrity checks, accessibility checks on content
+4) Import: staged, idempotent jobs; audit logs
+5) Verify: sampling and spot checks; stakeholder sign‑off
+
+Rollback
+- Keep original exports; implement reversible migrations; track IDs and redirects
+

openspec/specs/privacy-compliance.md

@@ -0,0 +1,26 @@
+# Privacy & Compliance Spec
+
+Status: draft
+Owners: Compliance, Security
+
+Scope
+- GDPR: data subject rights, consent, DSR workflows, data minimization.
+- HIPAA: PHI handling, access controls, audit logging, BAAs, breach response.
+
+Data classes
+- Public, PII, PHI — document per‑field classification in `data-model.md`.
+
+Controls
+- Encryption in transit (TLS 1.3) and at rest (AES‑256). Key mgmt with rotation.
+- RBAC/ABAC for sensitive actions; least privilege; admin action audit.
+- Logging with redaction; no PHI/PII in logs/traces.
+
+DSR & retention
+- Defined SLAs and automated workflows for export/delete; retention policies per entity.
+
+3rd‑party
+- Subprocessors inventory; data flow diagrams; DPAs/BAAs tracked.
+
+Validation
+- Privacy & security review is a gate on every proposal that touches user data.
+

openspec/templates/proposal-template.md

@@ -0,0 +1,67 @@
+# Proposal: <Concise Title>
+
+Status: draft
+Authors: <names/handles>
+Owners: <approvers/maintainers>
+Created: <yyyy-mm-dd>
+Scope: spec|infra|policy|process
+Related: <links to issues/PRs/specs>
+
+Summary
+- One paragraph that states the problem, the audience, and the outcome.
+
+Motivation
+- Why this matters to our community (especially those with chronic/terminal illness). Link data or feedback.
+
+Goals / Non‑Goals
+- Goals: …
+- Non‑Goals: …
+
+User Stories
+- As a <role>, I want … so that …
+
+Requirements
+- Functional: …
+- Accessibility: WCAG 2.2 AA+ requirements …
+- Privacy & Compliance: PHI/PII boundaries, HIPAA/GDPR notes …
+- Performance/SLOs: …
+
+Architecture & Design
+- System overview and component boundaries
+- Data model updates (ERD snippet or tables)
+- API design (OpenAPI excerpt or endpoints)
+- Feature flags / configuration
+
+Security & Threat Model
+- Trust boundaries, principal actions, abuse cases, mitigations
+
+Observability & Telemetry
+- Logs/metrics/traces; PII/PHI handling policy
+
+Migration / Rollout Plan
+- Data migration steps, backfills, dry‑run plan
+- Rollout stages, monitoring, rollback
+
+Test Plan
+- Unit, integration, E2E, accessibility checks
+
+Risks & Mitigations
+- …
+
+Alternatives Considered
+- … and why not chosen
+
+Work Breakdown
+- Milestones and tasks with owners
+
+Acceptance Criteria
+- Checkable criteria that define done
+
+Open Questions
+- …
+
+Slash Commands
+- `/review areas=accessibility,compliance,security,mobile,web,backend`
+- `/apply spec=openspec/specs/<target-file>.md` once approved
+- `/archive link=<PR>` after merge
+

packages/README.md

@@ -0,0 +1,4 @@
+# Packages (placeholders)
+
+Shared libraries (design system, API SDK, validation, analytics wrappers, etc.) will live here, proposed and added via OpenSpec changes.
+