From 7c553315007494a61a0f5914c6b573eab794c785 Mon Sep 17 00:00:00 2001
From: Ibraheem Amin <68827140+DIodide@users.noreply.github.com>
Date: Mon, 28 Sep 2026 14:37:26 -0400
Subject: [PATCH] Remove OpenSpec (#60)

Removes `openspec/` and the OpenSpec (`opsx`) commands and skills for
Claude, Codex, Cursor and agents (72 files). The specs were stale
planning docs (phase-7 was marked 41/41 done though its extraction and
org matching never shipped; the listserv engine now lives in
InboxEngine). `.cursor/rules` stay. Nothing else referenced OpenSpec.


**Report:** https://claude.ai/artifact/6eft6aycrrsdskBekKCGXZ
---
 .agents/skills/openspec-apply-change/SKILL.md | 156 ----------
 .../skills/openspec-archive-change/SKILL.md   | 114 -------
 .agents/skills/openspec-explore/SKILL.md      | 288 -----------------
 .agents/skills/openspec-propose/SKILL.md      | 110 -------
 .claude/commands/opsx/apply.md                | 152 ---------
 .claude/commands/opsx/archive.md              | 157 ----------
 .claude/commands/opsx/explore.md              | 173 -----------
 .claude/commands/opsx/propose.md              | 106 -------
 .claude/skills/openspec-apply-change/SKILL.md | 156 ----------
 .../skills/openspec-archive-change/SKILL.md   | 114 -------
 .claude/skills/openspec-explore/SKILL.md      | 288 -----------------
 .claude/skills/openspec-propose/SKILL.md      | 110 -------
 .codex/skills/openspec-apply-change/SKILL.md  | 156 ----------
 .../skills/openspec-archive-change/SKILL.md   | 114 -------
 .codex/skills/openspec-explore/SKILL.md       | 288 -----------------
 .codex/skills/openspec-propose/SKILL.md       | 110 -------
 .cursor/commands/opsx-apply.md                | 152 ---------
 .cursor/commands/opsx-archive.md              | 157 ----------
 .cursor/commands/opsx-explore.md              | 173 -----------
 .cursor/commands/opsx-propose.md              | 106 -------
 .cursor/skills/openspec-apply-change/SKILL.md | 156 ----------
 .../skills/openspec-archive-change/SKILL.md   | 114 -------
 .cursor/skills/openspec-explore/SKILL.md      | 288 -----------------
 .cursor/skills/openspec-propose/SKILL.md      | 110 -------
 .../listserv-data-engine/.openspec.yaml       |   2 -
 .../changes/listserv-data-engine/design.md    | 127 --------
 .../changes/listserv-data-engine/proposal.md  |  35 ---
 .../specs/backfill-engine/spec.md             |  26 --
 .../specs/body-fetcher/spec.md                |  37 ---
 .../specs/classification-pipeline/spec.md     |  27 --
 .../specs/cross-listserv-dedup/spec.md        |  26 --
 .../specs/job-manager/spec.md                 |  23 --
 .../specs/rss-poller/spec.md                  |  38 ---
 .../changes/listserv-data-engine/tasks.md     |  74 -----
 openspec/changes/mvp-foundation/design.md     | 292 ------------------
 openspec/changes/mvp-foundation/proposal.md   | 111 -------
 openspec/changes/mvp-foundation/specs/auth.md |  63 ----
 .../changes/mvp-foundation/specs/events.md    |  90 ------
 .../mvp-foundation/specs/feed-ranking.md      |  92 ------
 .../changes/mvp-foundation/specs/social.md    |  68 ----
 openspec/changes/mvp-foundation/tasks.md      | 163 ----------
 .../phase-5-completeness/.openspec.yaml       |   2 -
 .../changes/phase-5-completeness/design.md    |  67 ----
 .../changes/phase-5-completeness/proposal.md  |  35 ---
 .../specs/friends-events/spec.md              |  16 -
 .../specs/gcal-export/spec.md                 |  12 -
 .../specs/notification-triggers/spec.md       |  23 --
 .../specs/org-member-management/spec.md       |  30 --
 .../specs/org-recommendations/spec.md         |  16 -
 .../specs/share-link/spec.md                  |  12 -
 .../changes/phase-5-completeness/tasks.md     |  35 ---
 .../changes/phase-6-polish/.openspec.yaml     |   2 -
 openspec/changes/phase-6-polish/design.md     |  27 --
 openspec/changes/phase-6-polish/proposal.md   |  32 --
 .../specs/advanced-filters/spec.md            |  36 ---
 .../specs/event-reporting/spec.md             |  12 -
 .../specs/org-event-creation/spec.md          |  19 --
 openspec/changes/phase-6-polish/tasks.md      |  32 --
 .../phase-7-data-pipelines/.openspec.yaml     |   2 -
 .../changes/phase-7-data-pipelines/design.md  | 134 --------
 .../phase-7-data-pipelines/proposal.md        |  32 --
 .../specs/listserv-ingestion/spec.md          |  67 ----
 .../changes/phase-7-data-pipelines/tasks.md   |  70 -----
 .../phase-8-recommendations/.openspec.yaml    |   2 -
 .../changes/phase-8-recommendations/design.md | 256 ---------------
 .../phase-8-recommendations/proposal.md       | 112 -------
 .../specs/collaborative-filtering/spec.md     | 131 --------
 .../specs/enhanced-scoring/spec.md            |  54 ----
 .../specs/evaluation-and-privacy/spec.md      | 103 ------
 .../specs/interaction-logging/spec.md         |  59 ----
 .../changes/phase-8-recommendations/tasks.md  |  46 ---
 openspec/config.yaml                          |  20 --
 72 files changed, 6638 deletions(-)
 delete mode 100644 .agents/skills/openspec-apply-change/SKILL.md
 delete mode 100644 .agents/skills/openspec-archive-change/SKILL.md
 delete mode 100644 .agents/skills/openspec-explore/SKILL.md
 delete mode 100644 .agents/skills/openspec-propose/SKILL.md
 delete mode 100644 .claude/commands/opsx/apply.md
 delete mode 100644 .claude/commands/opsx/archive.md
 delete mode 100644 .claude/commands/opsx/explore.md
 delete mode 100644 .claude/commands/opsx/propose.md
 delete mode 100644 .claude/skills/openspec-apply-change/SKILL.md
 delete mode 100644 .claude/skills/openspec-archive-change/SKILL.md
 delete mode 100644 .claude/skills/openspec-explore/SKILL.md
 delete mode 100644 .claude/skills/openspec-propose/SKILL.md
 delete mode 100644 .codex/skills/openspec-apply-change/SKILL.md
 delete mode 100644 .codex/skills/openspec-archive-change/SKILL.md
 delete mode 100644 .codex/skills/openspec-explore/SKILL.md
 delete mode 100644 .codex/skills/openspec-propose/SKILL.md
 delete mode 100644 .cursor/commands/opsx-apply.md
 delete mode 100644 .cursor/commands/opsx-archive.md
 delete mode 100644 .cursor/commands/opsx-explore.md
 delete mode 100644 .cursor/commands/opsx-propose.md
 delete mode 100644 .cursor/skills/openspec-apply-change/SKILL.md
 delete mode 100644 .cursor/skills/openspec-archive-change/SKILL.md
 delete mode 100644 .cursor/skills/openspec-explore/SKILL.md
 delete mode 100644 .cursor/skills/openspec-propose/SKILL.md
 delete mode 100644 openspec/changes/listserv-data-engine/.openspec.yaml
 delete mode 100644 openspec/changes/listserv-data-engine/design.md
 delete mode 100644 openspec/changes/listserv-data-engine/proposal.md
 delete mode 100644 openspec/changes/listserv-data-engine/specs/backfill-engine/spec.md
 delete mode 100644 openspec/changes/listserv-data-engine/specs/body-fetcher/spec.md
 delete mode 100644 openspec/changes/listserv-data-engine/specs/classification-pipeline/spec.md
 delete mode 100644 openspec/changes/listserv-data-engine/specs/cross-listserv-dedup/spec.md
 delete mode 100644 openspec/changes/listserv-data-engine/specs/job-manager/spec.md
 delete mode 100644 openspec/changes/listserv-data-engine/specs/rss-poller/spec.md
 delete mode 100644 openspec/changes/listserv-data-engine/tasks.md
 delete mode 100644 openspec/changes/mvp-foundation/design.md
 delete mode 100644 openspec/changes/mvp-foundation/proposal.md
 delete mode 100644 openspec/changes/mvp-foundation/specs/auth.md
 delete mode 100644 openspec/changes/mvp-foundation/specs/events.md
 delete mode 100644 openspec/changes/mvp-foundation/specs/feed-ranking.md
 delete mode 100644 openspec/changes/mvp-foundation/specs/social.md
 delete mode 100644 openspec/changes/mvp-foundation/tasks.md
 delete mode 100644 openspec/changes/phase-5-completeness/.openspec.yaml
 delete mode 100644 openspec/changes/phase-5-completeness/design.md
 delete mode 100644 openspec/changes/phase-5-completeness/proposal.md
 delete mode 100644 openspec/changes/phase-5-completeness/specs/friends-events/spec.md
 delete mode 100644 openspec/changes/phase-5-completeness/specs/gcal-export/spec.md
 delete mode 100644 openspec/changes/phase-5-completeness/specs/notification-triggers/spec.md
 delete mode 100644 openspec/changes/phase-5-completeness/specs/org-member-management/spec.md
 delete mode 100644 openspec/changes/phase-5-completeness/specs/org-recommendations/spec.md
 delete mode 100644 openspec/changes/phase-5-completeness/specs/share-link/spec.md
 delete mode 100644 openspec/changes/phase-5-completeness/tasks.md
 delete mode 100644 openspec/changes/phase-6-polish/.openspec.yaml
 delete mode 100644 openspec/changes/phase-6-polish/design.md
 delete mode 100644 openspec/changes/phase-6-polish/proposal.md
 delete mode 100644 openspec/changes/phase-6-polish/specs/advanced-filters/spec.md
 delete mode 100644 openspec/changes/phase-6-polish/specs/event-reporting/spec.md
 delete mode 100644 openspec/changes/phase-6-polish/specs/org-event-creation/spec.md
 delete mode 100644 openspec/changes/phase-6-polish/tasks.md
 delete mode 100644 openspec/changes/phase-7-data-pipelines/.openspec.yaml
 delete mode 100644 openspec/changes/phase-7-data-pipelines/design.md
 delete mode 100644 openspec/changes/phase-7-data-pipelines/proposal.md
 delete mode 100644 openspec/changes/phase-7-data-pipelines/specs/listserv-ingestion/spec.md
 delete mode 100644 openspec/changes/phase-7-data-pipelines/tasks.md
 delete mode 100644 openspec/changes/phase-8-recommendations/.openspec.yaml
 delete mode 100644 openspec/changes/phase-8-recommendations/design.md
 delete mode 100644 openspec/changes/phase-8-recommendations/proposal.md
 delete mode 100644 openspec/changes/phase-8-recommendations/specs/collaborative-filtering/spec.md
 delete mode 100644 openspec/changes/phase-8-recommendations/specs/enhanced-scoring/spec.md
 delete mode 100644 openspec/changes/phase-8-recommendations/specs/evaluation-and-privacy/spec.md
 delete mode 100644 openspec/changes/phase-8-recommendations/specs/interaction-logging/spec.md
 delete mode 100644 openspec/changes/phase-8-recommendations/tasks.md
 delete mode 100644 openspec/config.yaml

diff --git a/.agents/skills/openspec-apply-change/SKILL.md b/.agents/skills/openspec-apply-change/SKILL.md
deleted file mode 100644
index d474dc1..0000000
--- a/.agents/skills/openspec-apply-change/SKILL.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read the files listed in `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.agents/skills/openspec-archive-change/SKILL.md b/.agents/skills/openspec-archive-change/SKILL.md
deleted file mode 100644
index 9b1f851..0000000
--- a/.agents/skills/openspec-archive-change/SKILL.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.agents/skills/openspec-explore/SKILL.md b/.agents/skills/openspec-explore/SKILL.md
deleted file mode 100644
index ffa10ca..0000000
--- a/.agents/skills/openspec-explore/SKILL.md
+++ /dev/null
@@ -1,288 +0,0 @@
----
-name: openspec-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│   ┌────────┐         ┌────────┐        │
-│   │ State  │────────▶│ State  │        │
-│   │   A    │         │   B    │        │
-│   └────────┘         └────────┘        │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-   | Insight Type | Where to Capture |
-   |--------------|------------------|
-   | New requirement discovered | `specs/<capability>/spec.md` |
-   | Requirement changed | `specs/<capability>/spec.md` |
-   | Design decision made | `design.md` |
-   | Scope changed | `proposal.md` |
-   | New work identified | `tasks.md` |
-   | Assumption invalidated | Relevant artifact |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Handling Different Entry Points
-
-**User brings a vague idea:**
-```
-User: I'm thinking about adding real-time collaboration
-
-You: Real-time collab is a big space. Let me think about this...
-
-      COLLABORATION SPECTRUM
-      ════════════════════════════════════════════
-
-      Awareness          Coordination         Sync
-          │                   │                 │
-          ▼                   ▼                 ▼
-      ┌────────┐         ┌────────┐        ┌────────┐
-      │Presence│         │Cursors │        │  CRDT  │
-      │  "3    │         │ Multi  │        │Conflict│
-      │online" │         │ select │        │  free  │
-      └────────┘         └────────┘        └────────┘
-          │                   │                 │
-       trivial            moderate           complex
-
-      Where's your head at?
-```
-
-**User brings a specific problem:**
-```
-User: The auth system is a mess
-
-You: [reads codebase]
-
-     ┌─────────────────────────────────────────────┐
-     │              CURRENT AUTH FLOW              │
-     └─────────────────────────────────────────────┘
-                        │
-          ┌─────────────┼─────────────┐
-          ▼             ▼             ▼
-     ┌─────────┐  ┌─────────┐  ┌─────────┐
-     │ Google  │  │  GitHub │  │  Email  │
-     │  OAuth  │  │  OAuth  │  │  Magic  │
-     └────┬────┘  └────┬────┘  └────┬────┘
-          │             │             │
-          └─────────────┼─────────────┘
-                        ▼
-                  ┌───────────┐
-                  │  Session  │
-                  └─────┬─────┘
-                        │
-                        ▼
-                  ┌───────────┐
-                  │   Perms   │
-                  └───────────┘
-
-     I see three tangles. Which one's burning?
-```
-
-**User is stuck mid-implementation:**
-```
-User: /opsx:explore add-auth-system
-      The OAuth integration is more complex than expected
-
-You: [reads change artifacts]
-
-     You're on task 4: "Implement OAuth flow"
-
-     Let me trace what's involved...
-
-     [draws diagram, explores options, suggests paths]
-
-     Want to update the design to reflect this?
-     Or add a spike task to investigate?
-```
-
-**User wants to compare options:**
-```
-User: Should we use Postgres or SQLite?
-
-You: Generic answer is boring. What's the context?
-
-User: A CLI tool that tracks local dev environments
-
-You: That changes everything.
-
-     ┌─────────────────────────────────────────────────┐
-     │         CLI TOOL DATA STORAGE                  │
-     └─────────────────────────────────────────────────┘
-
-     Key constraints:
-     • No daemon running
-     • Must work offline
-     • Single user
-
-                  SQLite          Postgres
-     Deployment   embedded ✓      needs server ✗
-     Offline      yes ✓           no ✗
-     Single file  yes ✓           no ✗
-
-     SQLite. Not even close.
-
-     Unless... is there a sync component?
-```
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When it feels like things are crystallizing, you might summarize:
-
-```
-## What We Figured Out
-
-**The problem**: [crystallized understanding]
-
-**The approach**: [if one emerged]
-
-**Open questions**: [if any remain]
-
-**Next steps** (if ready):
-- Create a change proposal
-- Keep exploring: just keep talking
-```
-
-But this summary is optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.agents/skills/openspec-propose/SKILL.md b/.agents/skills/openspec-propose/SKILL.md
deleted file mode 100644
index d27bc53..0000000
--- a/.agents/skills/openspec-propose/SKILL.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-name: openspec-propose
-description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
-
-**Steps**
-
-1. **If no clear input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.claude/commands/opsx/apply.md b/.claude/commands/opsx/apply.md
deleted file mode 100644
index bf23721..0000000
--- a/.claude/commands/opsx/apply.md
+++ /dev/null
@@ -1,152 +0,0 @@
----
-name: "OPSX: Apply"
-description: Implement tasks from an OpenSpec change (Experimental)
-category: Workflow
-tags: [workflow, artifacts, experimental]
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - Context file paths (varies by schema)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read the files listed in `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! You can archive this change with `/opsx:archive`.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.claude/commands/opsx/archive.md b/.claude/commands/opsx/archive.md
deleted file mode 100644
index 5e91608..0000000
--- a/.claude/commands/opsx/archive.md
+++ /dev/null
@@ -1,157 +0,0 @@
----
-name: "OPSX: Archive"
-description: Archive a completed change in the experimental workflow
-category: Workflow
-tags: [workflow, archive, experimental]
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Spec sync status (synced / sync skipped / no delta specs)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success (No Delta Specs)**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** No delta specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success With Warnings**
-
-```
-## Archive Complete (with warnings)
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** Sync skipped (user chose to skip)
-
-**Warnings:**
-- Archived with 2 incomplete artifacts
-- Archived with 3 incomplete tasks
-- Delta spec sync was skipped (user chose to skip)
-
-Review the archive if this was not intentional.
-```
-
-**Output On Error (Archive Exists)**
-
-```
-## Archive Failed
-
-**Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
-
-Target archive directory already exists.
-
-**Options:**
-1. Rename the existing archive
-2. Delete the existing archive if it's a duplicate
-3. Wait until a different date to archive
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/commands/opsx/explore.md b/.claude/commands/opsx/explore.md
deleted file mode 100644
index 30d9c57..0000000
--- a/.claude/commands/opsx/explore.md
+++ /dev/null
@@ -1,173 +0,0 @@
----
-name: "OPSX: Explore"
-description: "Enter explore mode - think through ideas, investigate problems, clarify requirements"
-category: Workflow
-tags: [workflow, explore, experimental, thinking]
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
-**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
-- A vague idea: "real-time collaboration"
-- A specific problem: "the auth system is getting unwieldy"
-- A change name: "add-dark-mode" (to explore in context of that change)
-- A comparison: "postgres vs sqlite for this"
-- Nothing (just enter explore mode)
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│   ┌────────┐         ┌────────┐        │
-│   │ State  │────────▶│ State  │        │
-│   │   A    │         │   B    │        │
-│   └────────┘         └────────┘        │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-If the user mentioned a specific change name, read its artifacts for context.
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-   | Insight Type | Where to Capture |
-   |--------------|------------------|
-   | New requirement discovered | `specs/<capability>/spec.md` |
-   | Requirement changed | `specs/<capability>/spec.md` |
-   | Design decision made | `design.md` |
-   | Scope changed | `proposal.md` |
-   | New work identified | `tasks.md` |
-   | Assumption invalidated | Relevant artifact |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.claude/commands/opsx/propose.md b/.claude/commands/opsx/propose.md
deleted file mode 100644
index 05276f4..0000000
--- a/.claude/commands/opsx/propose.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-name: "OPSX: Propose"
-description: Propose a new change - create it and generate all artifacts in one step
-category: Workflow
-tags: [workflow, artifacts, experimental]
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
-
-**Steps**
-
-1. **If no input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` to start implementing."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.claude/skills/openspec-apply-change/SKILL.md b/.claude/skills/openspec-apply-change/SKILL.md
deleted file mode 100644
index d474dc1..0000000
--- a/.claude/skills/openspec-apply-change/SKILL.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read the files listed in `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.claude/skills/openspec-archive-change/SKILL.md b/.claude/skills/openspec-archive-change/SKILL.md
deleted file mode 100644
index 9b1f851..0000000
--- a/.claude/skills/openspec-archive-change/SKILL.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/skills/openspec-explore/SKILL.md b/.claude/skills/openspec-explore/SKILL.md
deleted file mode 100644
index ffa10ca..0000000
--- a/.claude/skills/openspec-explore/SKILL.md
+++ /dev/null
@@ -1,288 +0,0 @@
----
-name: openspec-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│   ┌────────┐         ┌────────┐        │
-│   │ State  │────────▶│ State  │        │
-│   │   A    │         │   B    │        │
-│   └────────┘         └────────┘        │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-   | Insight Type | Where to Capture |
-   |--------------|------------------|
-   | New requirement discovered | `specs/<capability>/spec.md` |
-   | Requirement changed | `specs/<capability>/spec.md` |
-   | Design decision made | `design.md` |
-   | Scope changed | `proposal.md` |
-   | New work identified | `tasks.md` |
-   | Assumption invalidated | Relevant artifact |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Handling Different Entry Points
-
-**User brings a vague idea:**
-```
-User: I'm thinking about adding real-time collaboration
-
-You: Real-time collab is a big space. Let me think about this...
-
-      COLLABORATION SPECTRUM
-      ════════════════════════════════════════════
-
-      Awareness          Coordination         Sync
-          │                   │                 │
-          ▼                   ▼                 ▼
-      ┌────────┐         ┌────────┐        ┌────────┐
-      │Presence│         │Cursors │        │  CRDT  │
-      │  "3    │         │ Multi  │        │Conflict│
-      │online" │         │ select │        │  free  │
-      └────────┘         └────────┘        └────────┘
-          │                   │                 │
-       trivial            moderate           complex
-
-      Where's your head at?
-```
-
-**User brings a specific problem:**
-```
-User: The auth system is a mess
-
-You: [reads codebase]
-
-     ┌─────────────────────────────────────────────┐
-     │              CURRENT AUTH FLOW              │
-     └─────────────────────────────────────────────┘
-                        │
-          ┌─────────────┼─────────────┐
-          ▼             ▼             ▼
-     ┌─────────┐  ┌─────────┐  ┌─────────┐
-     │ Google  │  │  GitHub │  │  Email  │
-     │  OAuth  │  │  OAuth  │  │  Magic  │
-     └────┬────┘  └────┬────┘  └────┬────┘
-          │             │             │
-          └─────────────┼─────────────┘
-                        ▼
-                  ┌───────────┐
-                  │  Session  │
-                  └─────┬─────┘
-                        │
-                        ▼
-                  ┌───────────┐
-                  │   Perms   │
-                  └───────────┘
-
-     I see three tangles. Which one's burning?
-```
-
-**User is stuck mid-implementation:**
-```
-User: /opsx:explore add-auth-system
-      The OAuth integration is more complex than expected
-
-You: [reads change artifacts]
-
-     You're on task 4: "Implement OAuth flow"
-
-     Let me trace what's involved...
-
-     [draws diagram, explores options, suggests paths]
-
-     Want to update the design to reflect this?
-     Or add a spike task to investigate?
-```
-
-**User wants to compare options:**
-```
-User: Should we use Postgres or SQLite?
-
-You: Generic answer is boring. What's the context?
-
-User: A CLI tool that tracks local dev environments
-
-You: That changes everything.
-
-     ┌─────────────────────────────────────────────────┐
-     │         CLI TOOL DATA STORAGE                  │
-     └─────────────────────────────────────────────────┘
-
-     Key constraints:
-     • No daemon running
-     • Must work offline
-     • Single user
-
-                  SQLite          Postgres
-     Deployment   embedded ✓      needs server ✗
-     Offline      yes ✓           no ✗
-     Single file  yes ✓           no ✗
-
-     SQLite. Not even close.
-
-     Unless... is there a sync component?
-```
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When it feels like things are crystallizing, you might summarize:
-
-```
-## What We Figured Out
-
-**The problem**: [crystallized understanding]
-
-**The approach**: [if one emerged]
-
-**Open questions**: [if any remain]
-
-**Next steps** (if ready):
-- Create a change proposal
-- Keep exploring: just keep talking
-```
-
-But this summary is optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.claude/skills/openspec-propose/SKILL.md b/.claude/skills/openspec-propose/SKILL.md
deleted file mode 100644
index d27bc53..0000000
--- a/.claude/skills/openspec-propose/SKILL.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-name: openspec-propose
-description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
-
-**Steps**
-
-1. **If no clear input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.codex/skills/openspec-apply-change/SKILL.md b/.codex/skills/openspec-apply-change/SKILL.md
deleted file mode 100644
index d474dc1..0000000
--- a/.codex/skills/openspec-apply-change/SKILL.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read the files listed in `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.codex/skills/openspec-archive-change/SKILL.md b/.codex/skills/openspec-archive-change/SKILL.md
deleted file mode 100644
index 9b1f851..0000000
--- a/.codex/skills/openspec-archive-change/SKILL.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.codex/skills/openspec-explore/SKILL.md b/.codex/skills/openspec-explore/SKILL.md
deleted file mode 100644
index ffa10ca..0000000
--- a/.codex/skills/openspec-explore/SKILL.md
+++ /dev/null
@@ -1,288 +0,0 @@
----
-name: openspec-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│   ┌────────┐         ┌────────┐        │
-│   │ State  │────────▶│ State  │        │
-│   │   A    │         │   B    │        │
-│   └────────┘         └────────┘        │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-   | Insight Type | Where to Capture |
-   |--------------|------------------|
-   | New requirement discovered | `specs/<capability>/spec.md` |
-   | Requirement changed | `specs/<capability>/spec.md` |
-   | Design decision made | `design.md` |
-   | Scope changed | `proposal.md` |
-   | New work identified | `tasks.md` |
-   | Assumption invalidated | Relevant artifact |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Handling Different Entry Points
-
-**User brings a vague idea:**
-```
-User: I'm thinking about adding real-time collaboration
-
-You: Real-time collab is a big space. Let me think about this...
-
-      COLLABORATION SPECTRUM
-      ════════════════════════════════════════════
-
-      Awareness          Coordination         Sync
-          │                   │                 │
-          ▼                   ▼                 ▼
-      ┌────────┐         ┌────────┐        ┌────────┐
-      │Presence│         │Cursors │        │  CRDT  │
-      │  "3    │         │ Multi  │        │Conflict│
-      │online" │         │ select │        │  free  │
-      └────────┘         └────────┘        └────────┘
-          │                   │                 │
-       trivial            moderate           complex
-
-      Where's your head at?
-```
-
-**User brings a specific problem:**
-```
-User: The auth system is a mess
-
-You: [reads codebase]
-
-     ┌─────────────────────────────────────────────┐
-     │              CURRENT AUTH FLOW              │
-     └─────────────────────────────────────────────┘
-                        │
-          ┌─────────────┼─────────────┐
-          ▼             ▼             ▼
-     ┌─────────┐  ┌─────────┐  ┌─────────┐
-     │ Google  │  │  GitHub │  │  Email  │
-     │  OAuth  │  │  OAuth  │  │  Magic  │
-     └────┬────┘  └────┬────┘  └────┬────┘
-          │             │             │
-          └─────────────┼─────────────┘
-                        ▼
-                  ┌───────────┐
-                  │  Session  │
-                  └─────┬─────┘
-                        │
-                        ▼
-                  ┌───────────┐
-                  │   Perms   │
-                  └───────────┘
-
-     I see three tangles. Which one's burning?
-```
-
-**User is stuck mid-implementation:**
-```
-User: /opsx:explore add-auth-system
-      The OAuth integration is more complex than expected
-
-You: [reads change artifacts]
-
-     You're on task 4: "Implement OAuth flow"
-
-     Let me trace what's involved...
-
-     [draws diagram, explores options, suggests paths]
-
-     Want to update the design to reflect this?
-     Or add a spike task to investigate?
-```
-
-**User wants to compare options:**
-```
-User: Should we use Postgres or SQLite?
-
-You: Generic answer is boring. What's the context?
-
-User: A CLI tool that tracks local dev environments
-
-You: That changes everything.
-
-     ┌─────────────────────────────────────────────────┐
-     │         CLI TOOL DATA STORAGE                  │
-     └─────────────────────────────────────────────────┘
-
-     Key constraints:
-     • No daemon running
-     • Must work offline
-     • Single user
-
-                  SQLite          Postgres
-     Deployment   embedded ✓      needs server ✗
-     Offline      yes ✓           no ✗
-     Single file  yes ✓           no ✗
-
-     SQLite. Not even close.
-
-     Unless... is there a sync component?
-```
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When it feels like things are crystallizing, you might summarize:
-
-```
-## What We Figured Out
-
-**The problem**: [crystallized understanding]
-
-**The approach**: [if one emerged]
-
-**Open questions**: [if any remain]
-
-**Next steps** (if ready):
-- Create a change proposal
-- Keep exploring: just keep talking
-```
-
-But this summary is optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.codex/skills/openspec-propose/SKILL.md b/.codex/skills/openspec-propose/SKILL.md
deleted file mode 100644
index d27bc53..0000000
--- a/.codex/skills/openspec-propose/SKILL.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-name: openspec-propose
-description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
-
-**Steps**
-
-1. **If no clear input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.cursor/commands/opsx-apply.md b/.cursor/commands/opsx-apply.md
deleted file mode 100644
index a6b077b..0000000
--- a/.cursor/commands/opsx-apply.md
+++ /dev/null
@@ -1,152 +0,0 @@
----
-name: /opsx-apply
-id: opsx-apply
-category: Workflow
-description: Implement tasks from an OpenSpec change (Experimental)
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - Context file paths (varies by schema)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read the files listed in `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! You can archive this change with `/opsx:archive`.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.cursor/commands/opsx-archive.md b/.cursor/commands/opsx-archive.md
deleted file mode 100644
index e5cdd0e..0000000
--- a/.cursor/commands/opsx-archive.md
+++ /dev/null
@@ -1,157 +0,0 @@
----
-name: /opsx-archive
-id: opsx-archive
-category: Workflow
-description: Archive a completed change in the experimental workflow
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Spec sync status (synced / sync skipped / no delta specs)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success (No Delta Specs)**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** No delta specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success With Warnings**
-
-```
-## Archive Complete (with warnings)
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** Sync skipped (user chose to skip)
-
-**Warnings:**
-- Archived with 2 incomplete artifacts
-- Archived with 3 incomplete tasks
-- Delta spec sync was skipped (user chose to skip)
-
-Review the archive if this was not intentional.
-```
-
-**Output On Error (Archive Exists)**
-
-```
-## Archive Failed
-
-**Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
-
-Target archive directory already exists.
-
-**Options:**
-1. Rename the existing archive
-2. Delete the existing archive if it's a duplicate
-3. Wait until a different date to archive
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.cursor/commands/opsx-explore.md b/.cursor/commands/opsx-explore.md
deleted file mode 100644
index a1fbd17..0000000
--- a/.cursor/commands/opsx-explore.md
+++ /dev/null
@@ -1,173 +0,0 @@
----
-name: /opsx-explore
-id: opsx-explore
-category: Workflow
-description: "Enter explore mode - think through ideas, investigate problems, clarify requirements"
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
-**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
-- A vague idea: "real-time collaboration"
-- A specific problem: "the auth system is getting unwieldy"
-- A change name: "add-dark-mode" (to explore in context of that change)
-- A comparison: "postgres vs sqlite for this"
-- Nothing (just enter explore mode)
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│   ┌────────┐         ┌────────┐        │
-│   │ State  │────────▶│ State  │        │
-│   │   A    │         │   B    │        │
-│   └────────┘         └────────┘        │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-If the user mentioned a specific change name, read its artifacts for context.
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-   | Insight Type | Where to Capture |
-   |--------------|------------------|
-   | New requirement discovered | `specs/<capability>/spec.md` |
-   | Requirement changed | `specs/<capability>/spec.md` |
-   | Design decision made | `design.md` |
-   | Scope changed | `proposal.md` |
-   | New work identified | `tasks.md` |
-   | Assumption invalidated | Relevant artifact |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.cursor/commands/opsx-propose.md b/.cursor/commands/opsx-propose.md
deleted file mode 100644
index 4d75466..0000000
--- a/.cursor/commands/opsx-propose.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-name: /opsx-propose
-id: opsx-propose
-category: Workflow
-description: Propose a new change - create it and generate all artifacts in one step
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
-
-**Steps**
-
-1. **If no input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` to start implementing."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.cursor/skills/openspec-apply-change/SKILL.md b/.cursor/skills/openspec-apply-change/SKILL.md
deleted file mode 100644
index d474dc1..0000000
--- a/.cursor/skills/openspec-apply-change/SKILL.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read the files listed in `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.cursor/skills/openspec-archive-change/SKILL.md b/.cursor/skills/openspec-archive-change/SKILL.md
deleted file mode 100644
index 9b1f851..0000000
--- a/.cursor/skills/openspec-archive-change/SKILL.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.cursor/skills/openspec-explore/SKILL.md b/.cursor/skills/openspec-explore/SKILL.md
deleted file mode 100644
index ffa10ca..0000000
--- a/.cursor/skills/openspec-explore/SKILL.md
+++ /dev/null
@@ -1,288 +0,0 @@
----
-name: openspec-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│   ┌────────┐         ┌────────┐        │
-│   │ State  │────────▶│ State  │        │
-│   │   A    │         │   B    │        │
-│   └────────┘         └────────┘        │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-   | Insight Type | Where to Capture |
-   |--------------|------------------|
-   | New requirement discovered | `specs/<capability>/spec.md` |
-   | Requirement changed | `specs/<capability>/spec.md` |
-   | Design decision made | `design.md` |
-   | Scope changed | `proposal.md` |
-   | New work identified | `tasks.md` |
-   | Assumption invalidated | Relevant artifact |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Handling Different Entry Points
-
-**User brings a vague idea:**
-```
-User: I'm thinking about adding real-time collaboration
-
-You: Real-time collab is a big space. Let me think about this...
-
-      COLLABORATION SPECTRUM
-      ════════════════════════════════════════════
-
-      Awareness          Coordination         Sync
-          │                   │                 │
-          ▼                   ▼                 ▼
-      ┌────────┐         ┌────────┐        ┌────────┐
-      │Presence│         │Cursors │        │  CRDT  │
-      │  "3    │         │ Multi  │        │Conflict│
-      │online" │         │ select │        │  free  │
-      └────────┘         └────────┘        └────────┘
-          │                   │                 │
-       trivial            moderate           complex
-
-      Where's your head at?
-```
-
-**User brings a specific problem:**
-```
-User: The auth system is a mess
-
-You: [reads codebase]
-
-     ┌─────────────────────────────────────────────┐
-     │              CURRENT AUTH FLOW              │
-     └─────────────────────────────────────────────┘
-                        │
-          ┌─────────────┼─────────────┐
-          ▼             ▼             ▼
-     ┌─────────┐  ┌─────────┐  ┌─────────┐
-     │ Google  │  │  GitHub │  │  Email  │
-     │  OAuth  │  │  OAuth  │  │  Magic  │
-     └────┬────┘  └────┬────┘  └────┬────┘
-          │             │             │
-          └─────────────┼─────────────┘
-                        ▼
-                  ┌───────────┐
-                  │  Session  │
-                  └─────┬─────┘
-                        │
-                        ▼
-                  ┌───────────┐
-                  │   Perms   │
-                  └───────────┘
-
-     I see three tangles. Which one's burning?
-```
-
-**User is stuck mid-implementation:**
-```
-User: /opsx:explore add-auth-system
-      The OAuth integration is more complex than expected
-
-You: [reads change artifacts]
-
-     You're on task 4: "Implement OAuth flow"
-
-     Let me trace what's involved...
-
-     [draws diagram, explores options, suggests paths]
-
-     Want to update the design to reflect this?
-     Or add a spike task to investigate?
-```
-
-**User wants to compare options:**
-```
-User: Should we use Postgres or SQLite?
-
-You: Generic answer is boring. What's the context?
-
-User: A CLI tool that tracks local dev environments
-
-You: That changes everything.
-
-     ┌─────────────────────────────────────────────────┐
-     │         CLI TOOL DATA STORAGE                  │
-     └─────────────────────────────────────────────────┘
-
-     Key constraints:
-     • No daemon running
-     • Must work offline
-     • Single user
-
-                  SQLite          Postgres
-     Deployment   embedded ✓      needs server ✗
-     Offline      yes ✓           no ✗
-     Single file  yes ✓           no ✗
-
-     SQLite. Not even close.
-
-     Unless... is there a sync component?
-```
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When it feels like things are crystallizing, you might summarize:
-
-```
-## What We Figured Out
-
-**The problem**: [crystallized understanding]
-
-**The approach**: [if one emerged]
-
-**Open questions**: [if any remain]
-
-**Next steps** (if ready):
-- Create a change proposal
-- Keep exploring: just keep talking
-```
-
-But this summary is optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.cursor/skills/openspec-propose/SKILL.md b/.cursor/skills/openspec-propose/SKILL.md
deleted file mode 100644
index d27bc53..0000000
--- a/.cursor/skills/openspec-propose/SKILL.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-name: openspec-propose
-description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.2.0"
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
-
-**Steps**
-
-1. **If no clear input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/openspec/changes/listserv-data-engine/.openspec.yaml b/openspec/changes/listserv-data-engine/.openspec.yaml
deleted file mode 100644
index 8fb8631..0000000
--- a/openspec/changes/listserv-data-engine/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-03-31
diff --git a/openspec/changes/listserv-data-engine/design.md b/openspec/changes/listserv-data-engine/design.md
deleted file mode 100644
index 5990c01..0000000
--- a/openspec/changes/listserv-data-engine/design.md
+++ /dev/null
@@ -1,127 +0,0 @@
-## Context
-
-The Forum currently has two separate systems for email ingestion:
-
-1. **Phase 7 Gmail pipeline** (`backends/fastapi/app/pipeline/`) — polls a Gmail inbox via Google API, runs LLM extraction, writes events to Postgres. Works but requires Gmail OAuth, a dedicated Gmail account, and subscribing that account to listservs.
-
-2. **Batch scraper** (`apps/listserv-scraper/`) — authenticates directly to Princeton LISTSERV, fetches RSS feeds, extracts full HTML bodies. Runs manually, outputs JSON files.
-
-We need to combine these into a single persistent service that polls LISTSERV RSS feeds directly, processes emails through classifiers, and writes to the database — eliminating the Gmail middleman.
-
-**Constraints:**
-- LISTSERV sessions expire — the service must detect expiry and re-authenticate automatically.
-- RSS feed descriptions are truncated — full body requires 2 additional HTTP requests per message (A2 page → A3 HTML attachment).
-- Princeton LISTSERV has no documented rate limits, but we should be respectful (0.1-0.2s between requests).
-- The classifiers (Tasks 1 & 2) are being built by other team members — the integration point must be pluggable.
-- Must run on a t4g.small EC2 instance (2GB RAM) alongside the web app.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Near-realtime email ingestion (2-5 minute polling intervals)
-- Dynamic listserv management without service restart
-- Pluggable classifier interface so Task 1/2 can be swapped in without engine changes
-- Reliable dedup across listservs (most emails are HoagieMail cross-posts)
-- Backfill capability for historical data when a new listserv is added
-- Observability — track messages processed, events created, errors, latency
-
-**Non-Goals:**
-- Building the classifiers themselves (Task 1 & 2 — other team members)
-- Real-time WebSocket push to the frontend (polling is sufficient)
-- Scraping non-LISTSERV email sources (e.g., direct email, Mailman lists)
-- Full-text search indexing (can be added later)
-- Multi-region deployment or horizontal scaling
-
-## Decisions
-
-### 1. Extend existing FastAPI backend vs. new service
-
-**Decision:** Extend `backends/fastapi/` with new modules.
-
-**Rationale:** The FastAPI backend already has the pipeline router, admin auth, DB access layer, and dedup logic. Creating a separate service adds deployment complexity (second process, second Docker container, inter-service communication) for no benefit at our scale. The data engine is just a new set of endpoints + a background scheduler.
-
-**Alternative considered:** Standalone Go/Elixir service. Better concurrency model, but adds a second language to the stack and duplicates DB access, auth, and dedup logic.
-
-### 2. Polling scheduler: APScheduler vs. background tasks vs. Celery
-
-**Decision:** APScheduler with AsyncIOScheduler.
-
-**Rationale:** APScheduler runs in-process with FastAPI, supports per-job intervals, dynamic job add/remove at runtime, and persistent job state. It's lightweight — no Redis/RabbitMQ dependency. Celery is overkill for polling 7 listservs every few minutes.
-
-**Alternative considered:** Simple `asyncio.create_task` loops. Works but no built-in job management, persistence, or dynamic reconfiguration. Celery Beat — requires Redis, too heavy for this use case.
-
-### 3. Classifier interface: Direct function call vs. HTTP API vs. message queue
-
-**Decision:** Python protocol (abstract interface) with direct function call, HTTP fallback.
-
-**Rationale:** The classifiers will likely be Python (scikit-learn, transformers, or LLM API calls). A Python protocol/interface is simplest:
-
-```python
-class EventClassifier(Protocol):
-    def classify(self, email: ListservEmail) -> ClassificationResult: ...
-
-class TagClassifier(Protocol):
-    def classify(self, email: ListservEmail) -> list[TagResult]: ...
-```
-
-Default implementations can call the existing Gemini/OpenRouter LLM. When Task 1/2 teams ship their classifiers, they implement the same interface. If a classifier needs to run on a different host (e.g., GPU inference), the interface can be implemented as an HTTP client.
-
-### 4. Dedup strategy
-
-**Decision:** Three-layer dedup in the database.
-
-- **Layer 1 — Exact:** `message_id` unique constraint on `listserv_emails`. Catches identical cross-posts.
-- **Layer 2 — Sender + title fuzzy:** Same `hoagiemail_sender_email` + `pg_trgm` similarity > 0.6 on subject + within 72-hour window. Catches reminders and corrections.
-- **Layer 3 — Post-classification event dedup:** After metadata extraction, compare event title + datetime + location against existing events. Existing `thefuzz` logic in `pipeline/dedup.py`.
-
-Layer 1 happens at ingestion. Layers 2-3 happen during classification pipeline.
-
-### 5. Session management
-
-**Decision:** Shared session state with proactive re-login.
-
-The LISTSERV login returns a `WALOGIN` cookie and session token `X=...`. These are stored as module-level state in the poller. On any "Login Required" response, the poller re-authenticates and retries. Session is shared across all listserv polls (single login works for all lists).
-
-### 6. Backfill architecture
-
-**Decision:** Reuse the existing batch scraper logic, triggered via API endpoint.
-
-Backfill is a one-time operation per listserv. Rather than building MapReduce, we expose a `POST /engine/backfill` endpoint that runs the existing `scrape_listserv.py` logic (chunked RSS fetch + body enrichment) as a background task. Progress is tracked in the DB and queryable via `GET /engine/backfill/{job_id}/status`.
-
-For the 7 known listservs, backfill of ~40k messages per list is a ~4 hour job per list. These can run sequentially overnight.
-
-## Risks / Trade-offs
-
-**[LISTSERV rate limiting]** → We have no documentation on Princeton LISTSERV rate limits. Mitigation: conservative 0.15s delay between requests, exponential backoff on errors, and monitoring for 429/503 responses. Can be tuned up if no issues observed.
-
-**[Session expiry mid-batch]** → Already mitigated: the scraper detects "Login Required" and re-authenticates. The new service inherits this logic.
-
-**[Classifier latency]** → If classifiers use LLM APIs, each email takes 1-2 seconds to classify. For 50 new emails per poll cycle, that's ~1-2 minutes of classification time. Mitigation: classification runs async after ingestion — emails are stored immediately, classified in a background queue. The forum shows events after classification completes.
-
-**[Memory on t4g.small]** → 2GB RAM is tight. The RSS XML for 100 recent messages is ~200KB — fine. Backfill of 40k messages loads ~65MB XML. Mitigation: backfill streams the XML parser rather than loading into memory, or uses smaller batch sizes.
-
-**[Duplicate events from different wording]** → Two clubs may independently promote the same event with different email text. Fuzzy dedup catches most cases but not all. Mitigation: accept some duplicates initially; can add embedding-based dedup (pgvector) later.
-
-## Module Layout
-
-```
-backends/fastapi/app/
-├── engine/                    # New — data engine modules
-│   ├── __init__.py
-│   ├── router.py              # FastAPI endpoints for job management + status
-│   ├── scheduler.py           # APScheduler setup, job lifecycle
-│   ├── poller.py              # RSS fetch + body enrichment per listserv
-│   ├── session.py             # LISTSERV auth, cookie/token management
-│   ├── classifier.py          # Classifier protocol + default LLM impl
-│   ├── dedup.py               # Cross-listserv dedup logic
-│   ├── processor.py           # Orchestrator: ingest → dedup → classify → write
-│   └── backfill.py            # Bulk historical ingestion
-├── pipeline/                  # Existing — keep for now, deprecate later
-│   └── ...
-```
-
-## Open Questions
-
-- Should we deprecate the Gmail pipeline immediately or keep it as a fallback?
-- What's the desired SLA for email-to-event latency? (Currently assuming 2-5 minutes is acceptable.)
-- Should the admin panel (`apps/admin-web/`) be extended with data engine controls, or is API-only management sufficient for now?
diff --git a/openspec/changes/listserv-data-engine/proposal.md b/openspec/changes/listserv-data-engine/proposal.md
deleted file mode 100644
index a799e32..0000000
--- a/openspec/changes/listserv-data-engine/proposal.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## Why
-
-The Forum needs a continuous, automated pipeline to ingest event emails from Princeton listservs. Currently, event data comes from a Gmail-based pipeline (Phase 7) that requires a Gmail account and Google OAuth — which adds operational complexity and doesn't scale to multiple listservs. We have a working LISTSERV scraper that authenticates directly and fetches via RSS, but it's a manual batch script. We need to turn this into a persistent service that polls in near-realtime, runs classifier inference, and writes structured events to the database.
-
-## What Changes
-
-- **New backend service**: A persistent data engine that continuously polls Princeton LISTSERV RSS feeds, fetches full message bodies, and stores raw emails in `listserv_emails`.
-- **Job management API**: CRUD endpoints for managing which listservs to poll, with per-list poll intervals and enable/disable controls.
-- **Classification pipeline integration**: A pluggable interface where the binary event classifier (Task 1) and multi-label tag classifier (Task 2) slot in to process each new email.
-- **Cross-listserv deduplication**: Message-ID exact dedup plus fuzzy title + sender matching within time windows to handle HoagieMail cross-posts and reminder emails.
-- **Backfill support**: Ability to bulk-ingest historical emails when a new listserv is added, using chunked RSS fetches with checkpointing.
-- **Session management**: Auto-login to LISTSERV with automatic re-authentication on session expiry.
-- **Replaces Gmail pipeline**: The LISTSERV RSS poller replaces the Gmail API poller as the primary email ingestion method. **BREAKING** for the existing `backends/fastapi/app/pipeline/gmail.py` module (no longer the primary ingestion path).
-
-## Capabilities
-
-### New Capabilities
-- `rss-poller`: Periodic RSS feed polling with configurable intervals per listserv, message dedup against last-seen ID, and session management with auto re-login.
-- `body-fetcher`: Full message body extraction via A2 page → A3 HTML attachment fetching, with rate limiting, retry logic, and session expiry handling.
-- `job-manager`: CRUD API for listserv scrape jobs — add/remove/enable/disable listservs, configure poll intervals, view job status and last-polled timestamps.
-- `classification-pipeline`: Pluggable pipeline that runs incoming emails through the event binary classifier and tag classifier, extracts structured event metadata, and writes results to the database.
-- `cross-listserv-dedup`: Multi-layer deduplication — exact message_id matching, fuzzy title + sender matching within time windows, and embedding-based similarity for edge cases.
-- `backfill-engine`: Bulk historical email ingestion with chunked RSS fetches, incremental body fetching, checkpointing, and resume support.
-
-### Modified Capabilities
-(none — no existing specs)
-
-## Impact
-
-- **Database**: `listserv_emails` table already created. May need indexes on `(listserv, date)`, `(message_id)`, `(hoagiemail_sender_email, date)` for dedup queries.
-- **`listserv_configs` table**: Needs new columns: `poll_interval_seconds`, `last_polled_at`, `last_message_id` for the poller state.
-- **`backends/fastapi/`**: New router/endpoints for job management. Existing pipeline orchestrator will be refactored to use LISTSERV RSS instead of Gmail API.
-- **`apps/listserv-scraper/`**: Core scraping logic (login, RSS fetch, body fetch) will be extracted into a shared library used by both the batch scraper and the data engine.
-- **Environment variables**: `LISTSERV_EMAIL`, `LISTSERV_PASSWORD` (already added to `.env.example`).
-- **Dependencies**: `apscheduler` or similar for periodic task scheduling, `thefuzz` for fuzzy dedup (already in fastapi deps), `psycopg2` for direct DB access.
diff --git a/openspec/changes/listserv-data-engine/specs/backfill-engine/spec.md b/openspec/changes/listserv-data-engine/specs/backfill-engine/spec.md
deleted file mode 100644
index c916390..0000000
--- a/openspec/changes/listserv-data-engine/specs/backfill-engine/spec.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Backfill via API
-The system SHALL expose `POST /engine/backfill` to trigger a bulk historical import for a listserv, accepting `list_name` and `limit` parameters.
-
-#### Scenario: Backfill a new listserv
-- **WHEN** `POST /engine/backfill` with `{ "list_name": "BUTLERBUZZ", "limit": 20000 }`
-- **THEN** the system SHALL start a background task that fetches the RSS feed with the given limit, fetches full bodies, and inserts into listserv_emails
-
-#### Scenario: Backfill already running
-- **WHEN** a backfill is requested for a listserv that already has a backfill in progress
-- **THEN** the system SHALL reject the request with a 409 Conflict
-
-### Requirement: Checkpointed progress
-The system SHALL save progress every 500 messages during backfill so the job can be resumed if interrupted.
-
-#### Scenario: Backfill interrupted
-- **WHEN** the service restarts during a backfill at message 2500/10000
-- **THEN** the system SHALL resume from message 2500 on restart, skipping already-fetched bodies
-
-### Requirement: Backfill status tracking
-The system SHALL expose `GET /engine/backfill/{job_id}/status` returning total messages, completed count, errors, and estimated time remaining.
-
-#### Scenario: Check backfill progress
-- **WHEN** `GET /engine/backfill/{job_id}/status`
-- **THEN** the system SHALL return `{ "total": 20000, "completed": 8500, "errors": 3, "eta_minutes": 77 }`
diff --git a/openspec/changes/listserv-data-engine/specs/body-fetcher/spec.md b/openspec/changes/listserv-data-engine/specs/body-fetcher/spec.md
deleted file mode 100644
index ad0e64f..0000000
--- a/openspec/changes/listserv-data-engine/specs/body-fetcher/spec.md
+++ /dev/null
@@ -1,37 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Full HTML body extraction
-The system SHALL fetch the complete HTML body for each new email by requesting the A2 message page, finding the text/html A3 attachment link, and fetching the raw HTML content.
-
-#### Scenario: Successful body fetch
-- **WHEN** the A2 page contains a text/html A3 attachment link
-- **THEN** the system SHALL fetch the HTML attachment (without `&header=1`), store the full HTML as `body_html`, and derive `body_text` by stripping HTML tags
-
-#### Scenario: No HTML attachment available
-- **WHEN** the A2 page has no text/html A3 link (plain-text-only email)
-- **THEN** the system SHALL use the RSS description as `body_html` and mark `body_complete` as false
-
-### Requirement: HoagieMail sender extraction
-The system SHALL parse the full HTML body for the HoagieMail footer pattern `Email composed by {name} ({email})` and extract the sender's real name and email.
-
-#### Scenario: HoagieMail footer present
-- **WHEN** the HTML body contains the HoagieMail footer
-- **THEN** the system SHALL extract and store `hoagiemail_sender_name` and `hoagiemail_sender_email`
-
-#### Scenario: HoagieMail footer absent but author is hoagie@princeton.edu
-- **WHEN** the author email is `hoagie@PRINCETON.EDU` but no footer is found
-- **THEN** the system SHALL set `is_hoagiemail` to true but leave sender name/email as null
-
-### Requirement: Rate limiting
-The system SHALL enforce a minimum delay of 150ms between HTTP requests to the LISTSERV server to avoid overloading it.
-
-#### Scenario: Burst of new messages
-- **WHEN** 50 new messages are detected in a single poll cycle
-- **THEN** the system SHALL process body fetches sequentially with at least 150ms between each request, completing in approximately 15 seconds
-
-### Requirement: Session-aware fetching
-The system SHALL detect LISTSERV session expiry during body fetching and re-authenticate automatically.
-
-#### Scenario: Session expires mid-batch
-- **WHEN** an A2 or A3 page fetch returns "Login Required"
-- **THEN** the system SHALL re-login, obtain fresh session credentials, and retry the failed request
diff --git a/openspec/changes/listserv-data-engine/specs/classification-pipeline/spec.md b/openspec/changes/listserv-data-engine/specs/classification-pipeline/spec.md
deleted file mode 100644
index f5cde6b..0000000
--- a/openspec/changes/listserv-data-engine/specs/classification-pipeline/spec.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Pluggable classifier interface
-The system SHALL define a Python protocol for event classification and tag classification. Default implementations SHALL use the existing Gemini/OpenRouter LLM. Team-built classifiers SHALL be swappable without engine code changes.
-
-#### Scenario: LLM classifier (default)
-- **WHEN** no custom classifier is configured
-- **THEN** the system SHALL use Gemini Flash Lite via OpenRouter to classify emails as event/not-event and assign tags
-
-#### Scenario: Custom classifier plugged in
-- **WHEN** a Python class implementing the EventClassifier protocol is registered
-- **THEN** the system SHALL use that class for classification instead of the LLM default
-
-### Requirement: Pipeline orchestration
-The system SHALL process each new email through: (1) event binary classification, (2) if event: tag classification + metadata extraction, (3) write to events table. Processing SHALL be async and not block the poller.
-
-#### Scenario: Email classified as event
-- **WHEN** the classifier returns `is_event: true`
-- **THEN** the system SHALL run tag classification, extract metadata (title, datetime, location, description), and insert into the events table with `source='listserv'`
-
-#### Scenario: Email classified as not-event
-- **WHEN** the classifier returns `is_event: false`
-- **THEN** the system SHALL log the result in pipeline_logs with status `skipped_not_event` and take no further action
-
-#### Scenario: Classifier error
-- **WHEN** the classifier raises an exception or times out
-- **THEN** the system SHALL log the error in pipeline_logs with status `error` and continue processing the next email
diff --git a/openspec/changes/listserv-data-engine/specs/cross-listserv-dedup/spec.md b/openspec/changes/listserv-data-engine/specs/cross-listserv-dedup/spec.md
deleted file mode 100644
index b2b8da1..0000000
--- a/openspec/changes/listserv-data-engine/specs/cross-listserv-dedup/spec.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Exact message_id dedup at ingestion
-The system SHALL reject emails with a message_id already present in the listserv_emails table via the unique constraint.
-
-#### Scenario: Same HoagieMail on two listservs
-- **WHEN** the same email (same message_id) appears on WHITMANWIRE and ROCKYWIRE
-- **THEN** the system SHALL store the first occurrence and skip the duplicate with a log entry
-
-### Requirement: Fuzzy sender + title dedup
-The system SHALL detect near-duplicate emails from the same sender with similar subjects within a 72-hour window using pg_trgm trigram similarity (threshold 0.6).
-
-#### Scenario: Reminder email
-- **WHEN** the same hoagiemail_sender_email sends "Free Food Friday!" then "[REMINDER] Free Food Friday!" within 72 hours
-- **THEN** the system SHALL flag the second as a duplicate of the first and link them in pipeline_logs
-
-#### Scenario: Different events from same sender
-- **WHEN** the same sender sends "Concert Tonight" and "Auditions Tomorrow" within 72 hours
-- **THEN** the system SHALL treat them as separate emails (trigram similarity below threshold)
-
-### Requirement: Post-classification event dedup
-After metadata extraction, the system SHALL compare the extracted event title + datetime against existing events using fuzzy matching (token_set_ratio > 0.75 within ±24 hours).
-
-#### Scenario: Same event extracted from different email wording
-- **WHEN** two emails produce events with title "Spring Concert" at the same datetime
-- **THEN** the system SHALL create only one event and log the second as `duplicate`
diff --git a/openspec/changes/listserv-data-engine/specs/job-manager/spec.md b/openspec/changes/listserv-data-engine/specs/job-manager/spec.md
deleted file mode 100644
index 75ed82b..0000000
--- a/openspec/changes/listserv-data-engine/specs/job-manager/spec.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## ADDED Requirements
-
-### Requirement: CRUD for listserv scrape jobs
-The system SHALL expose API endpoints to create, read, update, and delete listserv scrape jobs. Each job stores: list_name, poll_interval_seconds, enabled, last_polled_at, last_message_id.
-
-#### Scenario: Add a new listserv
-- **WHEN** `POST /engine/jobs` with `{ "list_name": "ROCKYWIRE", "poll_interval_seconds": 300 }`
-- **THEN** the system SHALL create the job, start polling at the specified interval, and return the job config
-
-#### Scenario: Disable a listserv
-- **WHEN** `PATCH /engine/jobs/{id}` with `{ "enabled": false }`
-- **THEN** the system SHALL stop polling that listserv without deleting its data
-
-#### Scenario: Delete a listserv job
-- **WHEN** `DELETE /engine/jobs/{id}`
-- **THEN** the system SHALL stop polling and remove the job config (ingested emails remain in the database)
-
-### Requirement: Engine status endpoint
-The system SHALL expose `GET /engine/status` returning aggregate stats: total jobs, active jobs, messages processed, events created, errors, and last poll time per job.
-
-#### Scenario: Status check
-- **WHEN** `GET /engine/status`
-- **THEN** the system SHALL return a JSON object with per-job and aggregate statistics
diff --git a/openspec/changes/listserv-data-engine/specs/rss-poller/spec.md b/openspec/changes/listserv-data-engine/specs/rss-poller/spec.md
deleted file mode 100644
index 66a3206..0000000
--- a/openspec/changes/listserv-data-engine/specs/rss-poller/spec.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Periodic RSS feed polling
-The system SHALL poll each enabled listserv's RSS feed at its configured interval (default 5 minutes). The poll SHALL fetch recent messages using `?RSS&L={listname}&v=2.0&LIMIT=100` and compare against `last_message_id` to identify new emails.
-
-#### Scenario: New messages detected
-- **WHEN** the RSS feed contains messages with IDs not matching `last_message_id`
-- **THEN** the system SHALL extract message metadata (title, link, description, author, pubDate) and pass new messages to the body fetcher, and update `last_message_id` to the most recent message ID
-
-#### Scenario: No new messages
-- **WHEN** the RSS feed contains no messages newer than `last_message_id`
-- **THEN** the system SHALL update `last_polled_at` and take no further action
-
-#### Scenario: RSS feed unavailable
-- **WHEN** the RSS feed request fails (timeout, 5xx, network error)
-- **THEN** the system SHALL log the error, increment an error counter, and retry at the next poll interval without crashing
-
-### Requirement: Authenticated RSS access
-The system SHALL authenticate to LISTSERV before polling RSS feeds. The authentication SHALL use the LISTSERV email/password login flow to obtain a WALOGIN cookie and session token.
-
-#### Scenario: Session expiry during poll
-- **WHEN** the RSS feed returns a "Login Required" HTML page instead of XML
-- **THEN** the system SHALL re-authenticate automatically and retry the RSS fetch
-
-#### Scenario: Login credentials invalid
-- **WHEN** the LISTSERV login fails (bad email/password)
-- **THEN** the system SHALL log a critical error, disable all polling jobs, and surface the error via the status API
-
-### Requirement: Per-listserv poll intervals
-The system SHALL support configurable poll intervals per listserv. The interval MUST be at minimum 60 seconds and default to 300 seconds (5 minutes).
-
-#### Scenario: High-traffic listserv
-- **WHEN** a listserv is configured with `poll_interval_seconds: 120`
-- **THEN** the system SHALL poll that listserv's RSS feed every 120 seconds
-
-#### Scenario: Interval update at runtime
-- **WHEN** an admin updates a listserv's poll interval via the API
-- **THEN** the scheduler SHALL apply the new interval without restarting the service
diff --git a/openspec/changes/listserv-data-engine/tasks.md b/openspec/changes/listserv-data-engine/tasks.md
deleted file mode 100644
index d1dbf9c..0000000
--- a/openspec/changes/listserv-data-engine/tasks.md
+++ /dev/null
@@ -1,74 +0,0 @@
-## 1. Project Setup & Database
-
-- [ ] 1.1 Create `backends/fastapi/app/engine/` module directory with `__init__.py`
-- [ ] 1.2 Add `apscheduler` dependency to FastAPI backend (`pyproject.toml` / `requirements.txt`)
-- [ ] 1.3 Add `poll_interval_seconds` (int, default 300), `last_polled_at` (timestamptz), and `last_message_id` (varchar) columns to `listserv_configs` table
-- [ ] 1.4 Add indexes on `listserv_emails`: `(listserv, date)`, `(hoagiemail_sender_email, date)` for dedup queries
-- [ ] 1.5 Enable `pg_trgm` extension in Postgres for fuzzy string matching
-
-## 2. Session Management
-
-- [ ] 2.1 Create `engine/session.py` — LISTSERV login using email/password, returns cookie + session token
-- [ ] 2.2 Store session state (cookie, auth_params) as module-level singleton, thread-safe
-- [ ] 2.3 Implement `ensure_session()` that checks if session is valid, re-logins if expired
-- [ ] 2.4 Add `LISTSERV_EMAIL` and `LISTSERV_PASSWORD` to FastAPI config/settings
-
-## 3. RSS Poller
-
-- [ ] 3.1 Create `engine/poller.py` — `poll_listserv(list_name)` function that fetches RSS, parses XML, returns list of new message stubs (id, title, link, author, date)
-- [ ] 3.2 Implement new-message detection by comparing RSS items against `last_message_id` in DB
-- [ ] 3.3 Handle "Login Required" response — call `ensure_session()` and retry
-- [ ] 3.4 Update `last_polled_at` and `last_message_id` in `listserv_configs` after each poll
-
-## 4. Body Fetcher
-
-- [ ] 4.1 Create `engine/fetcher.py` — `fetch_full_body(msg_url)` that fetches A2 page, finds A3 text/html link, fetches raw HTML
-- [ ] 4.2 Extract HoagieMail sender name/email from full HTML body
-- [ ] 4.3 Extract links, images, and attachment URLs from full HTML body
-- [ ] 4.4 Implement rate limiting (150ms between requests) and retry with exponential backoff
-- [ ] 4.5 Handle session expiry mid-fetch — detect "Login Required", re-login, retry
-
-## 5. Deduplication
-
-- [ ] 5.1 Create `engine/dedup.py` — exact dedup via `message_id` unique constraint (ON CONFLICT DO NOTHING)
-- [ ] 5.2 Implement fuzzy sender + title dedup using `pg_trgm` similarity query within 72-hour window
-- [ ] 5.3 Implement post-classification event dedup using `thefuzz` token_set_ratio on extracted event title + datetime (±24 hours)
-
-## 6. Classifier Interface
-
-- [ ] 6.1 Create `engine/classifier.py` — define `EventClassifier` and `TagClassifier` Python protocols with `classify()` method
-- [ ] 6.2 Implement `LLMEventClassifier` default using existing Gemini/OpenRouter extractor logic
-- [ ] 6.3 Implement `LLMTagClassifier` default using existing tag extraction logic
-- [ ] 6.4 Add classifier registry/config so implementations can be swapped via settings
-
-## 7. Processing Pipeline
-
-- [ ] 7.1 Create `engine/processor.py` — orchestrator that takes a raw email, runs dedup → classify → extract metadata → write to DB
-- [ ] 7.2 Insert raw emails into `listserv_emails` table immediately on ingestion
-- [ ] 7.3 Run event classifier; if event, run tag classifier and metadata extraction
-- [ ] 7.4 Insert classified events into `events` table with `source='listserv'` and tags into `event_tags`
-- [ ] 7.5 Log all processing results to `pipeline_logs` (success, skipped_not_event, duplicate, error)
-
-## 8. Job Manager & Scheduler
-
-- [ ] 8.1 Create `engine/scheduler.py` — APScheduler AsyncIOScheduler setup, integrated with FastAPI lifespan
-- [ ] 8.2 On startup, load all enabled listserv_configs and schedule polling jobs at their intervals
-- [ ] 8.3 Support dynamic add/remove/update of jobs at runtime without restart
-- [ ] 8.4 Create `engine/router.py` — FastAPI endpoints: `POST/GET/PATCH/DELETE /engine/jobs`, `GET /engine/status`
-- [ ] 8.5 Wire router into FastAPI app (`app/main.py`)
-
-## 9. Backfill
-
-- [ ] 9.1 Create `engine/backfill.py` — bulk RSS fetch + body enrichment as a background task, reusing poller + fetcher logic
-- [ ] 9.2 Implement checkpointing every 500 messages (save progress to DB or file)
-- [ ] 9.3 Add `POST /engine/backfill` endpoint with `list_name` and `limit` params
-- [ ] 9.4 Add `GET /engine/backfill/{job_id}/status` endpoint for progress tracking
-- [ ] 9.5 Prevent duplicate backfill jobs for the same listserv (409 Conflict)
-
-## 10. Integration & Testing
-
-- [ ] 10.1 Extract shared scraping logic from `apps/listserv-scraper/src/scrape_listserv.py` into importable functions used by both batch scraper and engine
-- [ ] 10.2 Write integration test: add a listserv job → poll → verify emails in DB
-- [ ] 10.3 Write unit tests for dedup logic (exact, fuzzy, post-classification)
-- [ ] 10.4 Test session expiry and re-login flow end-to-end
-- [ ] 10.5 Load test: simulate 50 new messages per poll cycle, verify throughput and memory usage on t4g.small
diff --git a/openspec/changes/mvp-foundation/design.md b/openspec/changes/mvp-foundation/design.md
deleted file mode 100644
index b5327cc..0000000
--- a/openspec/changes/mvp-foundation/design.md
+++ /dev/null
@@ -1,292 +0,0 @@
-# MVP Foundation — Design
-
-## System Architecture
-
-```
-Browser
-  │
-  ├─ Auth.js session cookie
-  │
-  ▼
-┌─────────────────────────────────────────────────────────┐
-│                    Next.js 15 (App Router)               │
-│                                                          │
-│  ┌──────────────────────────────────────────────────┐    │
-│  │  Middleware (src/middleware.ts)                   │    │
-│  │  ├─ Check Auth.js session                        │    │
-│  │  ├─ Redirect unauthenticated → /                 │    │
-│  │  ├─ Redirect un-onboarded → /onboarding          │    │
-│  │  └─ Pass through for public routes               │    │
-│  └──────────────────────────────────────────────────┘    │
-│                                                          │
-│  Pages (src/app/)                                        │
-│  ├─ /                    Landing (public)                │
-│  ├─ /onboarding          Multi-step setup                │
-│  ├─ /explore             Main feed (protected)           │
-│  ├─ /events/[id]         Event detail (protected)        │
-│  ├─ /events/create       Create event (protected)        │
-│  ├─ /events/[id]/edit    Edit event (protected, owner)   │
-│  ├─ /orgs                Organization directory           │
-│  ├─ /orgs/[id]           Org profile                     │
-│  ├─ /orgs/create         Create org (org leaders)        │
-│  ├─ /friends             Friend management               │
-│  ├─ /map                 Campus map view                 │
-│  ├─ /settings            Account settings                │
-│  └─ /api/auth/[...nextauth]  Auth.js route handler       │
-│                                                          │
-│  Server Actions (src/actions/)                           │
-│  ├─ events.ts            CRUD + RSVP + Save              │
-│  ├─ users.ts             Profile + onboarding            │
-│  ├─ friends.ts           Requests + list                 │
-│  ├─ orgs.ts              CRUD + follow                   │
-│  ├─ notifications.ts     Fetch + mark read               │
-│  └─ upload.ts            S3 presigned URL generation     │
-│                                                          │
-│  Drizzle ORM (via @the-forum/database)                   │
-└──────────────┬───────────────────────────────────────────┘
-               │
-          ┌────▼─────┐
-          │ Postgres  │
-          │ (Docker)  │
-          └──────────┘
-```
-
-## Authentication Flow
-
-```
-┌────────┐     ┌──────────┐     ┌───────────────┐     ┌──────────────┐
-│ User   │────▶│ Next.js  │────▶│ Microsoft     │────▶│ Microsoft    │
-│ clicks │     │ /api/    │     │ login.micro-  │     │ Graph API    │
-│ login  │     │ auth     │     │ softonline    │     │ /v1.0/me     │
-└────────┘     └──────────┘     │ .com          │     └──────┬───────┘
-                                └───────────────┘            │
-                                                             ▼
-                                                    ┌────────────────┐
-                                                    │ Profile data:  │
-                                                    │ - displayName  │
-                                                    │ - mail         │
-                                                    │ - UPN (NetID)  │
-                                                    └────────┬───────┘
-                                                             │
-                                                             ▼
-                                                    ┌────────────────┐
-                                                    │ Auth.js        │
-                                                    │ signIn callback│
-                                                    │ → upsert user  │
-                                                    │ → set session  │
-                                                    └────────────────┘
-```
-
-**Auth.js config** (`src/auth.ts`):
-- Provider: `AzureADProvider` (from `next-auth/providers/azure-ad`)
-- Tenant: `2ff60116-7431-425d-b5af-077d7791bda4` (Princeton)
-- Scope: `User.Read` (Microsoft Graph profile)
-- Callbacks:
-  - `signIn`: Upsert user in DB, extract NetID from `userPrincipalName`
-  - `session`: Attach `userId`, `netId`, `onboarded` flag to session
-  - `jwt`: Persist user ID in JWT token
-
-**Middleware** (`src/middleware.ts`):
-- Public routes: `/`, `/api/auth/*`
-- Protected routes: everything else
-- Onboarding guard: if `session.user.onboarded === false`, redirect to `/onboarding`
-
-## Database Schema
-
-```
-┌─────────────┐       ┌──────────────────┐       ┌───────────────┐
-│   users      │       │   events          │       │ organizations │
-├─────────────┤       ├──────────────────┤       ├───────────────┤
-│ id (uuid)    │──┐    │ id (uuid)         │   ┌──│ id (uuid)      │
-│ netId        │  │    │ title             │   │  │ name           │
-│ email        │  │    │ description       │   │  │ description    │
-│ displayName  │  │    │ datetime          │   │  │ logo (url)     │
-│ classYear    │  │    │ endDatetime       │   │  │ category       │
-│ major        │  │    │ locationId (FK)   │───┤  │ creatorId (FK) │
-│ avatarUrl    │  │    │ orgId (FK)        │───┘  │ createdAt      │
-│ isOrgLeader  │  │    │ creatorId (FK)    │──┐   └───────────────┘
-│ onboarded    │  │    │ flyerUrl          │  │
-│ createdAt    │  │    │ externalLink      │  │
-│ updatedAt    │  │    │ isPublic          │  │
-└──────┬──────┘  │    │ createdAt         │  │
-       │         │    │ updatedAt         │  │
-       │         │    └──────────────────┘  │
-       │         │                          │
-       │    ┌────▼──────────┐    ┌─────────▼────────┐
-       │    │ user_interests │    │   event_tags      │
-       │    ├───────────────┤    ├──────────────────┤
-       │    │ userId (FK)    │    │ eventId (FK)      │
-       │    │ tag (enum)     │    │ tag (enum)         │
-       │    └───────────────┘    └──────────────────┘
-       │
-       │    ┌───────────────┐    ┌──────────────────┐
-       │    │ user_regions   │    │   rsvps            │
-       │    ├───────────────┤    ├──────────────────┤
-       ├───▶│ userId (FK)    │    │ userId (FK)        │
-       │    │ region (enum)  │    │ eventId (FK)       │
-       │    └───────────────┘    │ createdAt          │
-       │                         └──────────────────┘
-       │
-       │    ┌───────────────┐    ┌──────────────────┐
-       │    │ saved_events   │    │   friendships      │
-       │    ├───────────────┤    ├──────────────────┤
-       ├───▶│ userId (FK)    │    │ userId (FK)        │
-       │    │ eventId (FK)   │    │ friendId (FK)      │
-       │    │ createdAt      │    │ status (enum)      │
-       │    └───────────────┘    │ createdAt          │
-       │                         └──────────────────┘
-       │
-       │    ┌────────────────┐   ┌──────────────────┐
-       │    │ org_followers   │   │  notifications     │
-       │    ├────────────────┤   ├──────────────────┤
-       ├───▶│ userId (FK)     │   │ id (uuid)          │
-       │    │ orgId (FK)      │   │ userId (FK)        │
-       │    │ createdAt       │   │ type (enum)        │
-       │    └────────────────┘   │ payload (json)     │
-       │                         │ read (bool)        │
-       │    ┌────────────────┐   │ createdAt          │
-       │    │ org_members     │   └──────────────────┘
-       │    ├────────────────┤
-       └───▶│ orgId (FK)      │
-            │ userId (FK)     │
-            │ role (enum)     │
-            └────────────────┘
-
-┌──────────────────┐
-│ campus_locations  │
-├──────────────────┤
-│ id (varchar)      │  ← slug: "frist-campus-center"
-│ name              │  ← "Frist Campus Center"
-│ latitude          │
-│ longitude         │
-│ category          │  ← "academic", "residential", "athletic", etc.
-└──────────────────┘
-```
-
-### Enums / Fixed Taxonomies
-
-**Interest/Event Tags:**
-```
-free-food, workshop, performance, speaker, social, career,
-sports, music, art, academic, cultural, community-service,
-religious, political, tech, gaming, outdoor, wellness
-```
-
-**Campus Regions:**
-```
-central (Frist, Nassau), east (E-Quad, Bloomberg),
-west (Wu, Forbes), south (athletic fields, Jadwin),
-north (grad college, Lawrence), off-campus
-```
-
-**Campus Locations (seed data):**
-```
-Frist Campus Center, McCosh Hall, Richardson Auditorium,
-Alexander Hall, Friend Center, Computer Science Building,
-Prospect House, Terrace Club, Jadwin Gymnasium,
-Princeton Stadium, Lewis Library, Mudd Library,
-Robertson Hall, Whig Hall, Clio Hall, Nassau Hall,
-Einstein Walkway, Chancellor Green, etc.
-```
-
-**Friendship Status:** `pending`, `accepted`, `declined`
-
-**Notification Types:** `friend_request`, `event_reminder`, `org_new_event`
-
-**Org Categories:** `career`, `affinity`, `performance`, `academic`, `athletic`, `social`, `cultural`, `religious`, `political`, `service`
-
-**Org Member Roles:** `owner`, `officer`, `member`
-
-## Image Upload Flow
-
-```
-┌────────┐    1. Request presigned URL    ┌──────────┐
-│ Browser │──────────────────────────────▶│ Server   │
-│         │◀──────────────────────────────│ Action   │
-│         │    2. Return { url, key }     │          │
-│         │                               └──────────┘
-│         │    3. PUT image directly
-│         │──────────────────────────────▶┌──────────┐
-│         │◀──────────────────────────────│   S3     │
-│         │    4. 200 OK                  │          │
-│         │                               └──────────┘
-│         │    5. Save event with imageUrl
-│         │──────────────────────────────▶┌──────────┐
-│         │                               │ Server   │
-└────────┘                               │ Action   │
-                                          └──────────┘
-```
-
-S3 bucket: `the-forum-uploads` (or similar)
-Key pattern: `events/{eventId}/{uuid}.{ext}`
-Max file size: 5MB
-Allowed types: `image/jpeg`, `image/png`, `image/webp`
-
-## Feed Ranking Algorithm (MVP)
-
-SQL-based weighted scoring, computed at query time:
-
-```
-score = w1 * interest_overlap    -- how many of user's interests match event tags
-      + w2 * time_proximity      -- inverse of days until event (closer = higher)
-      + w3 * friend_rsvp_count   -- number of user's friends who RSVP'd
-      + w4 * recency_boost       -- newer events get a small boost
-      + w5 * random_factor       -- small random factor for exploration
-```
-
-Initial weights: `w1=3, w2=2, w3=4, w4=1, w5=0.5`
-
-Friend RSVPs weighted highest — the PRD emphasizes social discovery. Interest match next, then time proximity.
-
-Implemented as a Drizzle query with subqueries for each signal, ordered by computed score. Paginated (20 events per page, cursor-based).
-
-## Component Architecture
-
-```
-src/components/
-├── ui/                      # shadcn primitives (button, card, input, etc.)
-├── layout/
-│   ├── AppShell.tsx          # Authenticated layout wrapper
-│   ├── Sidebar.tsx           # Left nav (Home, My Events, Map, Friends)
-│   ├── TopBar.tsx            # Search bar, filters, create event, notifications, profile
-│   └── RightPanel.tsx        # Recently saved + friends (explore page)
-├── events/
-│   ├── EventCard.tsx         # Feed card (from /6 design)
-│   ├── EventFlyer.tsx        # Large flyer display (from /8 design)
-│   ├── EventForm.tsx         # Create/edit event form
-│   ├── EventFilters.tsx      # Category filter pills
-│   └── SimilarEvents.tsx     # Grid of related events
-├── social/
-│   ├── AvatarStack.tsx       # Overlapping friend avatars
-│   ├── FriendCard.tsx        # Friend list item
-│   ├── FriendSearch.tsx      # Search + add friends
-│   └── NotificationDropdown.tsx
-├── orgs/
-│   ├── OrgCard.tsx           # Organization list/grid item
-│   ├── OrgProfile.tsx        # Full org page content
-│   └── OrgForm.tsx           # Create/edit org
-├── onboarding/
-│   ├── InterestPicker.tsx    # Tag multi-select
-│   ├── DemographicsForm.tsx  # Year, major, regions
-│   └── OnboardingProgress.tsx
-└── map/
-    ├── CampusMap.tsx         # Map container
-    └── EventPin.tsx          # Map marker
-```
-
-## Route Protection Strategy
-
-```typescript
-// Middleware matcher:
-// - Public: /, /api/auth/*, /_next/*, /favicon.ico
-// - Everything else: requires auth
-
-// Onboarding guard (in middleware):
-// If authenticated but !session.user.onboarded → redirect /onboarding
-// If on /onboarding and already onboarded → redirect /explore
-
-// Page-level guards:
-// - /events/[id]/edit: verify event.creatorId === session.user.id
-// - /orgs/create: verify session.user.isOrgLeader
-// - /orgs/[id]/edit: verify org membership with owner role
-```
diff --git a/openspec/changes/mvp-foundation/proposal.md b/openspec/changes/mvp-foundation/proposal.md
deleted file mode 100644
index 5b1fbda..0000000
--- a/openspec/changes/mvp-foundation/proposal.md
+++ /dev/null
@@ -1,111 +0,0 @@
-# MVP Foundation — The Forum
-
-## Summary
-
-Build the complete MVP of The Forum: a campus event discovery platform for Princeton students. This change takes the codebase from boilerplate scaffolding to a working product with authentication, a real database schema, event CRUD, a personalized explore feed, social features, and organization management.
-
-## Motivation
-
-Students discover campus events through fragmented channels — listservs, group chats, Instagram. The Forum centralizes event discovery with personalization, social signals (friend RSVPs), and a polished UI. The PRD defines P0 requirements across onboarding, explore feed, event creation, social features, organizations, and notifications. None of these exist yet.
-
-## Approach
-
-**Next.js-first architecture.** All application logic lives in Next.js (App Router, Server Actions, Drizzle ORM). FastAPI is reserved for the recommendation algorithm later. This keeps the stack simple and avoids unnecessary API boundaries during MVP.
-
-```
-┌─────────────────────────────────────────────────┐
-│                   Next.js 15                    │
-│  ┌───────────┐  ┌───────────┐  ┌────────────┐  │
-│  │   Pages   │  │  Server   │  │   Auth.js   │  │
-│  │ (App      │  │  Actions  │  │  (EntraID)  │  │
-│  │  Router)  │  │  + API    │  │             │  │
-│  └─────┬─────┘  └─────┬─────┘  └──────┬─────┘  │
-│        │              │               │         │
-│        └──────────┬───┘───────────────┘         │
-│              ┌────▼─────┐                       │
-│              │ Drizzle  │                       │
-│              │   ORM    │                       │
-│              └────┬─────┘                       │
-└───────────────────┼─────────────────────────────┘
-               ┌────▼─────┐     ┌──────────┐
-               │ Postgres │     │    S3     │
-               │   (DB)   │     │ (images)  │
-               └──────────┘     └──────────┘
-```
-
-**Auth: Microsoft EntraID** via Auth.js (NextAuth v5) with the Azure AD provider. Princeton tenant: `2ff60116-7431-425d-b5af-077d7791bda4`. Users authenticate with their Princeton credentials; we extract NetID from the `userPrincipalName`.
-
-**Image uploads: AWS S3** using presigned URLs. Flyer images upload directly from the browser to S3, and we store the URL in the database.
-
-**Feed ranking (MVP):** SQL-based scoring. Weighted sum of interest-tag overlap, time proximity, friend RSVP count, and recency. No ML needed yet — this can be extracted to FastAPI later.
-
-**UI:** Extract reusable components from the /6 (explore) and /8 (event detail) design mockups. Install shadcn/ui primitives. Use the frontend-design skill for high-fidelity polish.
-
-## Phases
-
-### Phase 0 — Foundation
-- Database schema (all tables)
-- Auth.js + Microsoft EntraID integration
-- Install shadcn components
-- Extract reusable UI components (EventCard, Sidebar, TopBar, etc.)
-- Layout shell (authenticated app layout)
-
-### Phase 1 — Onboarding + Explore Feed
-- Multi-step onboarding flow (interests, demographics, org leader status)
-- Explore page with personalized feed (the /6 design)
-- Search + category filters
-- RSVP + Save actions on event cards
-
-### Phase 2 — Event Creation + Detail Page
-- Create Event form (title, description, datetime, location, tags, flyer upload)
-- S3 presigned URL upload flow
-- Event detail page (the /8 design)
-- Edit/delete own events
-- "Similar events" section
-
-### Phase 3 — Social Features
-- Friend search (name/NetID)
-- Send/accept friend requests
-- Friend list in sidebar
-- "Friends attending" on event cards + detail page
-- Notification dropdown (friend requests, event reminders)
-- Polling-based notification updates
-
-### Phase 4 — Organizations + Map + Polish
-- Organization profiles (logo, description, officers, events)
-- Create organization (org leaders only)
-- Follow organizations
-- Org search + category filters
-- Campus map with event pins (fixed location set)
-- Time navigation on map
-- Account settings page
-- Landing page (unauthenticated)
-
-## Non-goals
-
-- Mobile app
-- Private event coordination
-- Analytics dashboard
-- Real-time WebSocket notifications (polling is fine for MVP)
-- ML-based recommendations (SQL scoring is sufficient)
-- Email scraping / listserv integration (manual event creation only)
-
-## Key decisions
-
-| Decision | Choice | Rationale |
-|----------|--------|-----------|
-| API architecture | Next.js Server Actions | Simpler than REST API for MVP; type-safe end-to-end |
-| Auth | Auth.js v5 + Azure AD provider | Handles OAuth2 flow natively; Princeton EntraID compatible |
-| Image storage | S3 presigned URLs | AWS creds already configured; direct browser upload |
-| Feed ranking | SQL-weighted scoring | Good enough for MVP; no ML infrastructure needed |
-| Locations | Fixed enum/lookup table | Enables map feature + consistent filtering |
-| Tags | Fixed taxonomy (extensible later) | Better matching quality; simpler UI |
-| Notifications | Polling | Avoids WebSocket complexity for MVP |
-| Map library | TBD (Mapbox or Leaflet) | Need campus map tiles — investigate options |
-
-## Risks
-
-- **EntraID registration** — Need Azure AD app registration with Princeton tenant. Requires admin consent for `User.Read` scope.
-- **Campus map tiles** — Need a good map source for Princeton campus. Mapbox has campus-level detail; could also use a static SVG map.
-- **S3 bucket setup** — Need bucket creation, CORS config, IAM policy for presigned URLs.
-- **Schema migrations** — First real schema push. Need to get Drizzle migrations working cleanly.
diff --git a/openspec/changes/mvp-foundation/specs/auth.md b/openspec/changes/mvp-foundation/specs/auth.md
deleted file mode 100644
index c749d7b..0000000
--- a/openspec/changes/mvp-foundation/specs/auth.md
+++ /dev/null
@@ -1,63 +0,0 @@
-# Spec: Authentication (Microsoft EntraID)
-
-## Overview
-Princeton students authenticate via Microsoft EntraID (Azure AD) using their university credentials. Auth.js v5 handles the OAuth2 Authorization Code flow. The NetID is extracted from the Microsoft Graph `userPrincipalName` field.
-
-## Requirements
-
-### P0
-- Users sign in with Princeton Microsoft credentials
-- NetID extracted from `userPrincipalName` (e.g., `iamin@princeton.edu` → `iamin`)
-- User record created/updated in DB on first/subsequent sign-ins
-- Session includes: `userId`, `netId`, `displayName`, `email`, `onboarded` flag
-- Unauthenticated users can only access the landing page
-- Un-onboarded users are redirected to `/onboarding`
-- Sign out clears session and redirects to landing page
-
-### P1
-- Full Microsoft logout (redirect to Microsoft's logout endpoint, then back to app)
-- Session refresh without re-authentication (Auth.js handles via JWT rotation)
-
-## Auth.js Configuration
-
-**Provider:** `AzureADProvider` from `next-auth/providers/azure-ad`
-
-**Env vars:**
-```
-AUTH_SECRET=<random-secret>
-AUTH_AZURE_AD_CLIENT_ID=<from-entra-registration>
-AUTH_AZURE_AD_CLIENT_SECRET=<from-entra-registration>
-AUTH_AZURE_AD_TENANT_ID=2ff60116-7431-425d-b5af-077d7791bda4
-```
-
-**Callbacks:**
-- `signIn`: Upsert user in `users` table. Return `true` to allow sign-in.
-- `jwt`: Add `userId`, `netId`, `onboarded` to JWT token.
-- `session`: Expose `userId`, `netId`, `onboarded` on `session.user`.
-
-**Adapter:** `DrizzleAdapter` from `@auth/drizzle-adapter` — but note that Auth.js adapters expect specific table names (`accounts`, `sessions`, `verification_tokens`). We may use JWT strategy instead to avoid extra tables.
-
-**Strategy:** JWT (stateless sessions, no DB session table needed).
-
-## Middleware
-
-```
-Matcher: everything except /, /api/auth/*, /_next/*, /favicon.ico, static assets
-
-Logic:
-  1. Get session via auth()
-  2. No session → redirect to /
-  3. Session but !onboarded → redirect to /onboarding (unless already there)
-  4. On /onboarding but already onboarded → redirect to /explore
-  5. Otherwise → pass through
-```
-
-## Azure AD App Registration
-
-Steps (from reference implementation README):
-1. Go to https://entra.microsoft.com
-2. Register new application
-3. Set redirect URI: `http://localhost:3000/api/auth/callback/azure-ad` (dev)
-4. Generate client secret
-5. Note: Application (client) ID, Client secret value, Tenant ID
-6. API permissions: `User.Read` (Microsoft Graph) — should be granted by default
diff --git a/openspec/changes/mvp-foundation/specs/events.md b/openspec/changes/mvp-foundation/specs/events.md
deleted file mode 100644
index 61c3f19..0000000
--- a/openspec/changes/mvp-foundation/specs/events.md
+++ /dev/null
@@ -1,90 +0,0 @@
-# Spec: Events (CRUD, RSVP, Save)
-
-## Overview
-Events are the core entity. Org leaders and students can create events, which appear in the explore feed. Users interact via RSVP (public) and Save (private).
-
-## Requirements
-
-### P0 — Event Creation
-- Title (required, max 200 chars)
-- Description (required, max 2000 chars)
-- Start date/time (required, must be in future)
-- End date/time (optional)
-- Campus location (required, select from fixed list)
-- Tags (required, at least 1, max 5, from fixed taxonomy)
-- Flyer image (optional, upload to S3, max 5MB, jpeg/png/webp)
-- Organization (optional — select from orgs user belongs to)
-- Creator is automatically set to current user
-
-### P1
-- External registration link (optional URL)
-- Draft/publish status
-
-### P0 — Event Detail
-- Display all event fields
-- Show RSVP count
-- Show friends who RSVP'd (avatar stack)
-- RSVP button (toggle on/off)
-- Save button (toggle on/off, private)
-- Edit/delete visible only to creator
-- Similar events: same tags or same org, max 4
-
-### P0 — Event Editing
-- Creator can edit all fields
-- Creator can delete event (hard delete for MVP)
-
-### P0 — RSVP
-- Authenticated user can RSVP to any event
-- RSVP is visible to user's friends
-- User can un-RSVP (toggle)
-- RSVP count shown on event card and detail page
-
-### P0 — Save
-- Authenticated user can save any event
-- Saves are private (not visible to others)
-- User can unsave (toggle)
-- Saved events appear in "My Events" sidebar section
-
-## Server Actions
-
-```typescript
-// src/actions/events.ts
-
-createEvent(data: CreateEventInput): Promise<{ id: string }>
-updateEvent(eventId: string, data: UpdateEventInput): Promise<void>
-deleteEvent(eventId: string): Promise<void>
-getEvent(eventId: string): Promise<EventDetail>
-getFeedEvents(params: FeedParams): Promise<{ events: EventCard[], cursor: string | null }>
-toggleRsvp(eventId: string): Promise<{ rsvped: boolean, count: number }>
-toggleSave(eventId: string): Promise<{ saved: boolean }>
-getMyEvents(): Promise<{ created: EventCard[], rsvped: EventCard[], saved: EventCard[] }>
-getSimilarEvents(eventId: string): Promise<EventCard[]>
-```
-
-## Data Types
-
-```typescript
-interface EventCard {
-  id: string
-  title: string
-  orgName: string | null
-  datetime: Date
-  location: { id: string, name: string }
-  tags: string[]
-  flyerUrl: string | null
-  rsvpCount: number
-  friendsAttending: { id: string, displayName: string, avatarUrl: string | null }[]
-  isRsvped: boolean
-  isSaved: boolean
-}
-
-interface EventDetail extends EventCard {
-  description: string
-  endDatetime: Date | null
-  externalLink: string | null
-  creatorId: string
-  orgId: string | null
-  createdAt: Date
-  attendees: { id: string, displayName: string, avatarUrl: string | null }[]
-}
-```
diff --git a/openspec/changes/mvp-foundation/specs/feed-ranking.md b/openspec/changes/mvp-foundation/specs/feed-ranking.md
deleted file mode 100644
index 75c56f2..0000000
--- a/openspec/changes/mvp-foundation/specs/feed-ranking.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# Spec: Feed Ranking Algorithm
-
-## Overview
-The explore feed shows a personalized, ranked list of upcoming events. The MVP uses SQL-based weighted scoring — no ML infrastructure needed.
-
-## Requirements
-
-### P0
-- Events ranked by composite score based on user signals
-- Only show future events (datetime > now)
-- Paginated results (20 per page, cursor-based)
-- Filters: search query (title + description), tags, location, date range
-- Score considers: interest overlap, time proximity, friend RSVPs, recency
-
-### P1
-- Diversity constraint: max 3 events per org in top 20
-- "New events" boost for events < 24 hours old
-- Track click-through for future signal refinement
-
-## Scoring Formula
-
-```
-score = (3.0 × interest_overlap)
-      + (2.0 × time_proximity)
-      + (4.0 × friend_rsvp_score)
-      + (1.0 × recency_boost)
-      + (0.5 × random_factor)
-```
-
-### Signal Definitions
-
-**interest_overlap** (0-1):
-```
-count(user_interests ∩ event_tags) / count(user_interests)
-```
-If user has no interests, defaults to 0.5.
-
-**time_proximity** (0-1):
-```
-CASE
-  WHEN days_until <= 0 THEN 0        -- past events filtered out
-  WHEN days_until <= 1 THEN 1.0      -- today/tomorrow: max score
-  WHEN days_until <= 3 THEN 0.8
-  WHEN days_until <= 7 THEN 0.6
-  WHEN days_until <= 14 THEN 0.3
-  ELSE 0.1
-END
-```
-
-**friend_rsvp_score** (0-1):
-```
-MIN(1.0, friend_rsvp_count / 3.0)
-```
-Caps at 3 friends. Having 3+ friends going = max score.
-
-**recency_boost** (0-1):
-```
-CASE
-  WHEN hours_since_created <= 24 THEN 1.0
-  WHEN hours_since_created <= 72 THEN 0.5
-  ELSE 0.0
-END
-```
-
-**random_factor** (0-1):
-```
-random()  -- Postgres random() returns 0-1
-```
-Ensures feed isn't deterministic. Small weight (0.5) so it nudges, not dominates.
-
-## Query Strategy
-
-Use a Drizzle raw SQL query or `sql` template tag for the scoring subqueries. Wrap in a single query that:
-
-1. Filters: `datetime > now()`, optional tag/location/date/search filters
-2. Computes each signal as a subquery/lateral join
-3. Sums weighted score
-4. Orders by score DESC
-5. Limits to 20, with cursor for pagination
-
-Cursor: `(score, eventId)` — sort by score DESC, then eventId as tiebreaker.
-
-## Filters (applied before scoring)
-
-| Filter | Implementation |
-|--------|---------------|
-| Search | `WHERE title ILIKE '%q%' OR description ILIKE '%q%'` |
-| Tags | `WHERE id IN (SELECT eventId FROM event_tags WHERE tag = ANY($tags))` |
-| Location | `WHERE locationId = $locationId` |
-| Date range | `WHERE datetime BETWEEN $start AND $end` |
-
-Filters narrow the candidate set. Scoring ranks within the filtered set.
diff --git a/openspec/changes/mvp-foundation/specs/social.md b/openspec/changes/mvp-foundation/specs/social.md
deleted file mode 100644
index 38754dc..0000000
--- a/openspec/changes/mvp-foundation/specs/social.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# Spec: Social Features (Friends + Notifications)
-
-## Overview
-Users can add friends and see which events their friends are attending. Notifications alert users to friend requests and upcoming events.
-
-## Requirements
-
-### P0 — Friends
-- Search users by display name or NetID
-- Send friend request (creates `pending` friendship)
-- Accept/decline friend requests
-- View friend list
-- "Friends attending" shown on event cards (avatar stack + count)
-- Bidirectional: if A friends B, both see each other's RSVPs
-
-### P1
-- "Friends attending" scrollable list on event detail page
-- Suggested friends (friends of friends)
-
-### P0 — Notifications
-- Friend request received → notification
-- Upcoming RSVP'd event (1 day before) → notification
-- Notification dropdown from bell icon in TopBar
-- Unread count badge on bell icon
-- Mark individual notification as read
-- Mark all as read
-
-### P1
-- Org new event notification (for followed orgs)
-
-## Server Actions
-
-```typescript
-// src/actions/friends.ts
-searchUsers(query: string): Promise<UserSearchResult[]>
-sendFriendRequest(userId: string): Promise<void>
-acceptFriendRequest(friendshipId: string): Promise<void>
-declineFriendRequest(friendshipId: string): Promise<void>
-getFriends(): Promise<Friend[]>
-getPendingRequests(): Promise<FriendRequest[]>
-
-// src/actions/notifications.ts
-getNotifications(limit?: number): Promise<Notification[]>
-getUnreadCount(): Promise<number>
-markRead(notificationId: string): Promise<void>
-markAllRead(): Promise<void>
-```
-
-## Notification Generation
-
-Notifications are created by server actions as side effects:
-
-- `acceptFriendRequest()` → create notification for the requester
-- `sendFriendRequest()` → create notification for the recipient
-- Cron/scheduled job: scan RSVP'd events happening tomorrow, create reminders (or do this lazily at query time)
-
-For MVP, event reminders can be computed at read time: "show events you RSVP'd to that start within 24 hours" — no need for a background job.
-
-## Polling
-
-Client-side polling on the explore page:
-```typescript
-// Poll every 60 seconds
-useEffect(() => {
-  const interval = setInterval(() => fetchUnreadCount(), 60_000)
-  return () => clearInterval(interval)
-}, [])
-```
diff --git a/openspec/changes/mvp-foundation/tasks.md b/openspec/changes/mvp-foundation/tasks.md
deleted file mode 100644
index c5bc386..0000000
--- a/openspec/changes/mvp-foundation/tasks.md
+++ /dev/null
@@ -1,163 +0,0 @@
-# MVP Foundation — Tasks
-
-## Phase 0: Foundation
-
-### 0.1 Database Schema
-- [ ] Replace placeholder `users` + `posts` schema with full schema (see design.md)
-- [ ] Define all enums: tags, regions, friendship status, notification types, org categories, org roles
-- [ ] Create `campus_locations` table with seed data (Princeton locations + lat/lng)
-- [ ] Run `bun run db:push` to apply schema
-- [ ] Verify with `bun run db:studio`
-
-### 0.2 Auth — Microsoft EntraID
-- [ ] Install `next-auth@beta` (Auth.js v5) and `@auth/drizzle-adapter`
-- [ ] Create `src/auth.ts` with Azure AD provider config
-  - Tenant: `2ff60116-7431-425d-b5af-077d7791bda4`
-  - Scope: `User.Read`
-- [ ] Create `src/app/api/auth/[...nextauth]/route.ts`
-- [ ] Implement `signIn` callback: upsert user in DB, extract NetID from UPN
-- [ ] Implement `session` callback: attach userId, netId, onboarded flag
-- [ ] Create `src/middleware.ts` with route protection + onboarding guard
-- [ ] Add env vars: `AUTH_SECRET`, `AUTH_AZURE_AD_CLIENT_ID`, `AUTH_AZURE_AD_CLIENT_SECRET`, `AUTH_AZURE_AD_TENANT_ID`
-- [ ] Update `src/env.ts` with new auth env vars
-- [ ] Test login/logout flow end-to-end
-
-### 0.3 S3 Upload Infrastructure
-- [ ] Install `@aws-sdk/client-s3` and `@aws-sdk/s3-request-presigner`
-- [ ] Create server action `src/actions/upload.ts` for presigned URL generation
-- [ ] Add env vars: `AWS_S3_BUCKET`, `AWS_REGION` (creds from ~/.aws/credentials)
-- [ ] Create reusable `ImageUpload` client component with drag-and-drop
-
-### 0.4 shadcn Components
-- [ ] Install core components: `button`, `card`, `input`, `dialog`, `badge`, `avatar`, `select`, `dropdown-menu`, `sheet`, `tabs`, `tooltip`, `separator`, `label`, `textarea`, `calendar`, `popover`, `command`, `scroll-area`, `skeleton`
-- [ ] Verify Tailwind v4 compatibility
-
-### 0.5 Layout Shell + Reusable Components
-- [ ] Create `AppShell` layout (authenticated wrapper with sidebar + topbar)
-- [ ] Extract `Sidebar` from /6 design (Home, My Events, Map, Friends nav)
-- [ ] Extract `TopBar` from /6 design (search, filters, create event button, notifications, profile)
-- [ ] Extract `EventCard` from /6 design
-- [ ] Extract `AvatarStack` from /8 design
-- [ ] Create authenticated layout at `src/app/(app)/layout.tsx`
-- [ ] Move protected pages under `(app)` route group
-
----
-
-## Phase 1: Onboarding + Explore Feed
-
-### 1.1 Onboarding Flow
-- [ ] Create `src/app/(app)/onboarding/page.tsx` — multi-step form
-- [ ] Step 1: Interest tags (multi-select grid using tag enum)
-- [ ] Step 2: Demographics (class year dropdown, major text input, campus regions multi-select)
-- [ ] Step 3: Organization leader toggle
-- [ ] Server action `src/actions/users.ts` — `completeOnboarding()`: save interests, demographics, set `onboarded=true`
-- [ ] Redirect to `/explore` on completion
-- [ ] Polish with frontend-design skill
-
-### 1.2 Explore Page
-- [ ] Create `src/app/(app)/explore/page.tsx` — main feed
-- [ ] Implement feed query with scoring algorithm (see design.md)
-- [ ] Category filter pills (from /6 design)
-- [ ] Search bar with keyword search (title + description)
-- [ ] EventCard grid (responsive 2-3 columns)
-- [ ] Right panel: recently saved events + friends
-- [ ] RSVP server action (`src/actions/events.ts`)
-- [ ] Save server action (`src/actions/events.ts`)
-- [ ] Pagination (cursor-based, load more button)
-- [ ] Polish with frontend-design skill
-
----
-
-## Phase 2: Event Creation + Detail
-
-### 2.1 Create Event
-- [ ] Create `src/app/(app)/events/create/page.tsx`
-- [ ] Form fields: title, description, date/time (calendar picker), end time, location (select from campus_locations), tags (multi-select), flyer image upload
-- [ ] Optional: external registration link
-- [ ] Server action `createEvent()` — validate, save to DB
-- [ ] Redirect to event detail page on success
-- [ ] Polish with frontend-design skill
-
-### 2.2 Event Detail Page
-- [ ] Create `src/app/(app)/events/[id]/page.tsx` — from /8 design
-- [ ] Event flyer display (large, gradient background)
-- [ ] Event info: title, org name, date/time, location, description, tags
-- [ ] RSVP button (toggle, shows count)
-- [ ] Save button (toggle, private)
-- [ ] Attendee list with friend avatars highlighted
-- [ ] Share button (copy link)
-- [ ] "Similar events" section (same tags, same org)
-- [ ] Edit/delete buttons (visible only to event creator)
-- [ ] Polish with frontend-design skill
-
-### 2.3 Edit/Delete Event
-- [ ] Create `src/app/(app)/events/[id]/edit/page.tsx` — reuse EventForm
-- [ ] Server action `updateEvent()` — verify ownership
-- [ ] Server action `deleteEvent()` — verify ownership, soft delete or hard delete
-- [ ] "My Events" view (sidebar): list of user's created events + RSVP'd/saved events
-
----
-
-## Phase 3: Social Features
-
-### 3.1 Friend System
-- [ ] Create friend search component (`FriendSearch`) — search by name or NetID
-- [ ] Server action `sendFriendRequest()`
-- [ ] Server action `acceptFriendRequest()` / `declineFriendRequest()`
-- [ ] Friends sidebar panel with friend list
-- [ ] "Friends attending" display on EventCard (avatar stack + count)
-- [ ] "Friends attending" on event detail page
-
-### 3.2 Notifications
-- [ ] Create `NotificationDropdown` component (bell icon in TopBar)
-- [ ] Server action `getNotifications()` — fetch unread + recent
-- [ ] Server action `markNotificationRead()`
-- [ ] Generate notifications on: friend request received, upcoming RSVP'd event (1 day before)
-- [ ] Polling: fetch notifications every 60 seconds on explore page
-- [ ] Unread badge count on bell icon
-
----
-
-## Phase 4: Organizations + Map + Polish
-
-### 4.1 Organizations
-- [ ] Create `src/app/(app)/orgs/page.tsx` — org directory with search + category filters
-- [ ] Create `src/app/(app)/orgs/[id]/page.tsx` — org profile (logo, desc, officers, events list)
-- [ ] Create `src/app/(app)/orgs/create/page.tsx` — create org form (org leaders only)
-- [ ] Follow/unfollow server action
-- [ ] Org recommendation feed (based on user interests)
-- [ ] Org event list on profile page
-
-### 4.2 Campus Map
-- [ ] Choose map library (Mapbox GL JS or Leaflet + OpenStreetMap)
-- [ ] Create `CampusMap` component centered on Princeton campus
-- [ ] Event pins at campus locations (from `campus_locations` table)
-- [ ] Clickable pins → event preview popup
-- [ ] Time navigation: date selector to show events on different days
-- [ ] Create `src/app/(app)/map/page.tsx`
-
-### 4.3 Account Settings
-- [ ] Create `src/app/(app)/settings/page.tsx`
-- [ ] Edit demographics (class year, major)
-- [ ] Edit campus regions
-- [ ] Edit interest tags
-- [ ] Toggle org leader status
-
-### 4.4 Landing Page
-- [ ] Create `src/app/page.tsx` — public landing page
-- [ ] Sign up / Log in CTA → Auth.js sign in
-- [ ] Value proposition messaging
-- [ ] Polish with frontend-design skill
-
----
-
-## Cross-cutting
-
-### Testing
-- [ ] Set up Playwright for E2E tests (auth flow, create event, RSVP)
-- [ ] Add basic server action unit tests with Vitest
-
-### DevOps
-- [ ] Verify Docker Compose works for local development
-- [ ] Ensure `bun run dev` starts everything cleanly
-- [ ] Document env var setup in README
diff --git a/openspec/changes/phase-5-completeness/.openspec.yaml b/openspec/changes/phase-5-completeness/.openspec.yaml
deleted file mode 100644
index 5cb9e8f..0000000
--- a/openspec/changes/phase-5-completeness/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-03-09
diff --git a/openspec/changes/phase-5-completeness/design.md b/openspec/changes/phase-5-completeness/design.md
deleted file mode 100644
index fed2d40..0000000
--- a/openspec/changes/phase-5-completeness/design.md
+++ /dev/null
@@ -1,67 +0,0 @@
-## Context
-
-The Forum MVP (Phases 0–4) is built with Next.js 16 (App Router, Server Actions, Drizzle ORM) + PostgreSQL. All business logic runs as `"use server"` actions — no REST API. The notification table, org membership tables, and event `externalLink` column already exist in the schema but lack business logic or UI in several places. Phase 5 closes these gaps without schema changes.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Complete all notification trigger logic (event reminders, org new events)
-- Add GCal export and share link to event detail page
-- Provide org owners with member management UI
-- Surface org recommendations and friends' RSVP'd events
-- Display external registration links on event detail
-
-**Non-Goals:**
-- Real-time/WebSocket notifications (polling is sufficient)
-- Email/SMS notification delivery (DB + in-app only for now)
-- Scheduled cron jobs for reminders (use on-demand check approach instead)
-- ML-based recommendations (simple tag overlap scoring is sufficient)
-- Changes to the database schema
-
-## Decisions
-
-### 1. Event reminders: on-demand vs. cron
-
-**Decision:** On-demand generation when notifications are fetched.
-
-When `getNotifications()` is called, check for RSVP'd events happening within the next 24 hours that don't already have a reminder notification. Generate them inline. This avoids needing a cron job or external scheduler.
-
-**Alternative considered:** Scheduled cron job (e.g., Vercel Cron or `node-cron`). Rejected because it adds infrastructure complexity and the on-demand approach is sufficient for the user base.
-
-### 2. Org new-event notifications: trigger point
-
-**Decision:** Generate in `createEvent()` when `orgId` is provided.
-
-When an event is created with an `orgId`, query `orgFollowers` for that org and batch-insert `org_new_event` notifications. This is synchronous but acceptable — follower counts are small (tens to hundreds, not thousands).
-
-**Alternative considered:** Background job queue. Overkill for current scale.
-
-### 3. GCal export: URL scheme vs. API
-
-**Decision:** Use the public Google Calendar URL scheme (`https://calendar.google.com/calendar/render?action=TEMPLATE&...`).
-
-No API key, no OAuth, no dependency. Just construct the URL with event details and open in a new tab.
-
-### 4. Share link: implementation
-
-**Decision:** Use `navigator.clipboard.writeText()` with a shadcn toast (sonner) for feedback.
-
-Need to install `sonner` toast component via shadcn. Simple, no external deps.
-
-### 5. Org recommendations: scoring approach
-
-**Decision:** SQL-based scoring. For each org, count how many of its events' tags overlap with the user's interest tags. Rank by overlap count. Return top suggestions.
-
-Query: join `organizations` → `events` → `eventTags` against `userInterests`, group by org, order by match count descending.
-
-### 6. Friends' events: surface location
-
-**Decision:** Add a "Friends Going" filter/section on the explore page.
-
-Query: get event IDs where friends have RSVP'd, then fetch those events. Show as a toggleable section or filter pill on the explore feed.
-
-## Risks / Trade-offs
-
-- **On-demand reminder generation** — Could be slow if user has many RSVPs. Mitigation: limit check to next 24h window, use efficient indexed query.
-- **Synchronous org follower notifications** — Could slow down event creation if org has many followers. Mitigation: acceptable at current scale (<1000 followers per org). Can move to background job later if needed.
-- **No deduplication of reminders across sessions** — If `getNotifications()` is called multiple times, we need to check for existing reminders before creating duplicates. Mitigation: query for existing `event_reminder` with matching `eventId` in payload before inserting.
diff --git a/openspec/changes/phase-5-completeness/proposal.md b/openspec/changes/phase-5-completeness/proposal.md
deleted file mode 100644
index 461d565..0000000
--- a/openspec/changes/phase-5-completeness/proposal.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## Why
-
-The Forum MVP (Phases 0–4) is feature-complete but several capabilities are half-built: notification types exist in the DB enum but nothing generates them, the `externalLink` field on events is stored but never displayed, and key PRD P1 items (GCal export, share link, friends' events browsing) are missing. These gaps would make the product feel incomplete at launch. Phase 5 closes them.
-
-## What Changes
-
-- **Notification triggers**: Generate `event_reminder` (1 day before RSVP'd event) and `org_new_event` (when followed org posts) notifications. The enum values and notification table already exist — this adds the business logic.
-- **GCal export**: "Add to Google Calendar" button on event detail page using the public `calendar.google.com` URL scheme (no API key needed).
-- **Share link**: Copy-to-clipboard button on event detail page with toast confirmation.
-- **Org member management**: UI for org owners to search/add officers, remove officers, and view membership from the org profile page.
-- **Org recommendation feed**: Score and suggest organizations on the orgs page based on overlap between org event tags and user interest tags.
-- **Friends' events browsing**: Show events friends have RSVP'd to — surface on the explore page as a "Friends Going" filter or section.
-- **External registration link**: Display the `externalLink` field on event detail page when present (data already stored, just needs UI).
-
-## Capabilities
-
-### New Capabilities
-
-- `notification-triggers`: Business logic to generate event_reminder and org_new_event notifications at the right moments
-- `gcal-export`: Google Calendar URL generation and button on event detail
-- `share-link`: Clipboard copy for event URLs with feedback toast
-- `org-member-management`: UI + server actions for org owners to manage officers
-- `org-recommendations`: Interest-based org scoring and suggestion feed
-- `friends-events`: Surface events that friends have RSVP'd to in the explore flow
-
-### Modified Capabilities
-
-_(No existing specs to modify — this is the first use of OpenSpec specs)_
-
-## Impact
-
-- **Server actions**: New actions in `notifications.ts` (trigger generation), `orgs.ts` (member management), `friends.ts` or `events.ts` (friends' events query). Modifications to `orgs.ts` (recommendations).
-- **UI components**: Changes to event detail page (`events/[id]`), org profile page (`orgs/[id]`), orgs list page (`orgs`), explore page (`explore`).
-- **Database**: No schema changes — all tables/columns/enums already exist.
-- **Dependencies**: May need a toast component from shadcn (`sonner` or `toast`) for share link feedback.
diff --git a/openspec/changes/phase-5-completeness/specs/friends-events/spec.md b/openspec/changes/phase-5-completeness/specs/friends-events/spec.md
deleted file mode 100644
index ea24770..0000000
--- a/openspec/changes/phase-5-completeness/specs/friends-events/spec.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Friends' events browsing
-The explore page SHALL offer a way to view events that the user's friends have RSVP'd to.
-
-#### Scenario: User filters by friends' events
-- **WHEN** the user activates the "Friends Going" filter on the explore page
-- **THEN** the feed shows only events where at least one accepted friend has RSVP'd, with friend count visible
-
-#### Scenario: User has no friends
-- **WHEN** the user has no accepted friends
-- **THEN** the "Friends Going" filter is hidden or disabled
-
-#### Scenario: No friends attending any events
-- **WHEN** the user has friends but none have RSVP'd to any upcoming events
-- **THEN** the feed shows an empty state message
diff --git a/openspec/changes/phase-5-completeness/specs/gcal-export/spec.md b/openspec/changes/phase-5-completeness/specs/gcal-export/spec.md
deleted file mode 100644
index 7988c65..0000000
--- a/openspec/changes/phase-5-completeness/specs/gcal-export/spec.md
+++ /dev/null
@@ -1,12 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Google Calendar export button
-The event detail page SHALL display an "Add to Calendar" button that opens a Google Calendar event creation URL in a new tab.
-
-#### Scenario: User exports event to Google Calendar
-- **WHEN** the user clicks "Add to Calendar" on an event detail page
-- **THEN** a new tab opens with a Google Calendar URL pre-filled with the event title, description, start datetime, end datetime (if available), and location name
-
-#### Scenario: Event without end time
-- **WHEN** the event has no `endDatetime`
-- **THEN** the Google Calendar URL SHALL default to a 1-hour duration from the start time
diff --git a/openspec/changes/phase-5-completeness/specs/notification-triggers/spec.md b/openspec/changes/phase-5-completeness/specs/notification-triggers/spec.md
deleted file mode 100644
index c93ebd0..0000000
--- a/openspec/changes/phase-5-completeness/specs/notification-triggers/spec.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Event reminder notifications
-The system SHALL generate an `event_reminder` notification for each user who has RSVP'd to an event occurring within the next 24 hours. Reminders SHALL NOT be duplicated if already generated for the same event+user pair.
-
-#### Scenario: Reminder generated on notification fetch
-- **WHEN** a user fetches their notifications and has RSVP'd to an event starting within 24 hours
-- **THEN** the system creates an `event_reminder` notification with the event ID and title in the payload, if one does not already exist
-
-#### Scenario: No duplicate reminders
-- **WHEN** a reminder notification already exists for a given user+event pair
-- **THEN** the system SHALL NOT create another reminder for that pair
-
-### Requirement: Org new-event notifications
-The system SHALL generate `org_new_event` notifications for all followers of an organization when a new event is created under that organization.
-
-#### Scenario: Notifications created on event creation
-- **WHEN** a user creates an event with an `orgId`
-- **THEN** the system creates an `org_new_event` notification for every user who follows that organization, with the event ID, event title, and org name in the payload
-
-#### Scenario: Creator excluded from notification
-- **WHEN** the event creator is also a follower of the organization
-- **THEN** the creator SHALL NOT receive an `org_new_event` notification for their own event
diff --git a/openspec/changes/phase-5-completeness/specs/org-member-management/spec.md b/openspec/changes/phase-5-completeness/specs/org-member-management/spec.md
deleted file mode 100644
index 8874c6f..0000000
--- a/openspec/changes/phase-5-completeness/specs/org-member-management/spec.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Org owner can add officers
-The org profile page SHALL allow org owners to search for users and add them as officers.
-
-#### Scenario: Owner adds an officer
-- **WHEN** the org owner searches for a user by name or NetID and clicks "Add Officer"
-- **THEN** the user is added to `orgMembers` with role `officer` and the member list updates
-
-#### Scenario: Non-owner cannot manage members
-- **WHEN** a user who is not the org owner views the org profile
-- **THEN** the member management UI (add/remove officers) SHALL NOT be visible
-
-### Requirement: Org owner can remove officers
-The org profile page SHALL allow org owners to remove officers from the organization.
-
-#### Scenario: Owner removes an officer
-- **WHEN** the org owner clicks "Remove" on an officer in the member list
-- **THEN** the officer's `orgMembers` row is deleted and the member list updates
-
-### Requirement: External registration link display
-The event detail page SHALL display the `externalLink` field as a clickable button when present.
-
-#### Scenario: Event has external link
-- **WHEN** an event has a non-null `externalLink`
-- **THEN** the event detail page displays a "Register" button that opens the link in a new tab
-
-#### Scenario: Event has no external link
-- **WHEN** an event has a null `externalLink`
-- **THEN** no registration button is displayed
diff --git a/openspec/changes/phase-5-completeness/specs/org-recommendations/spec.md b/openspec/changes/phase-5-completeness/specs/org-recommendations/spec.md
deleted file mode 100644
index 606bf98..0000000
--- a/openspec/changes/phase-5-completeness/specs/org-recommendations/spec.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Org recommendation feed
-The orgs page SHALL display a "Recommended for You" section showing organizations whose events match the user's interest tags, ranked by overlap count.
-
-#### Scenario: User has matching interests
-- **WHEN** the user views the orgs page and has interest tags that overlap with event tags of organizations they don't already follow
-- **THEN** the system displays up to 6 recommended organizations ranked by tag overlap count
-
-#### Scenario: User already follows all matching orgs
-- **WHEN** all recommended organizations are already followed by the user
-- **THEN** the "Recommended for You" section is hidden
-
-#### Scenario: User has no interests set
-- **WHEN** the user has no interest tags in their profile
-- **THEN** the "Recommended for You" section is hidden
diff --git a/openspec/changes/phase-5-completeness/specs/share-link/spec.md b/openspec/changes/phase-5-completeness/specs/share-link/spec.md
deleted file mode 100644
index 32ce912..0000000
--- a/openspec/changes/phase-5-completeness/specs/share-link/spec.md
+++ /dev/null
@@ -1,12 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Copy event link
-The event detail page SHALL display a "Share" button that copies the event URL to the user's clipboard.
-
-#### Scenario: Successful copy
-- **WHEN** the user clicks the "Share" button on an event detail page
-- **THEN** the event URL (`/events/{id}`) is copied to the clipboard and a toast notification confirms "Link copied"
-
-#### Scenario: Clipboard API unavailable
-- **WHEN** the browser does not support `navigator.clipboard`
-- **THEN** the system SHALL fall back to selecting text in a hidden input and executing `document.execCommand('copy')`
diff --git a/openspec/changes/phase-5-completeness/tasks.md b/openspec/changes/phase-5-completeness/tasks.md
deleted file mode 100644
index aea71c5..0000000
--- a/openspec/changes/phase-5-completeness/tasks.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## 1. Notification Triggers
-
-- [x] 1.1 Add on-demand event reminder generation to `getNotifications()` in `actions/notifications.ts` — check for RSVP'd events in next 24h, create `event_reminder` if not already exists
-- [x] 1.2 Add `org_new_event` notification generation to `createEvent()` in `actions/events.ts` — query org followers, batch-insert notifications (exclude creator)
-- [x] 1.3 Update `NotificationDropdown` component to render event_reminder and org_new_event notification types with appropriate icons and links
-
-## 2. GCal Export
-
-- [x] 2.1 Create `buildGCalUrl()` helper that generates Google Calendar URL from event title, description, datetime, endDatetime, and location name (default 1h duration if no end time)
-- [x] 2.2 Add "Add to Calendar" button to event detail page (`events/[id]`) that opens the GCal URL in a new tab
-
-## 3. Share Link
-
-- [x] 3.1 Install sonner toast component via shadcn (`bunx shadcn@latest add sonner`) and add `<Toaster>` to app layout
-- [x] 3.2 Add "Share" button to event detail page that copies event URL to clipboard with toast confirmation
-
-## 4. Org Member Management
-
-- [x] 4.1 Add server actions in `actions/orgs.ts`: `addOfficer(orgId, userId)` and `removeOfficer(orgId, userId)` with ownership verification
-- [x] 4.2 Add user search for adding officers — reuse `searchUsers()` from `actions/friends.ts` or create a shared variant
-- [x] 4.3 Add member management UI to org profile page (`orgs/[id]`) — visible only to org owner: search to add officers, remove button on existing officers
-
-## 5. Org Recommendations
-
-- [x] 5.1 Add `getRecommendedOrgs()` server action in `actions/orgs.ts` — join orgs → events → eventTags against userInterests, rank by overlap count, exclude already-followed orgs, limit 6
-- [x] 5.2 Add "Recommended for You" section to orgs page (`orgs/page.tsx`) — show recommended org cards, hide if empty
-
-## 6. Friends' Events
-
-- [x] 6.1 Add `getFriendsEvents()` server action in `actions/events.ts` — fetch events where accepted friends have RSVP'd, include friend count per event
-- [x] 6.2 Add "Friends Going" filter pill to explore page — when active, feed shows only events with friend RSVPs
-
-## 7. External Registration Link
-
-- [x] 7.1 Add "Register" button to event detail page (`events/[id]`) that opens `externalLink` in a new tab when present
diff --git a/openspec/changes/phase-6-polish/.openspec.yaml b/openspec/changes/phase-6-polish/.openspec.yaml
deleted file mode 100644
index 5cb9e8f..0000000
--- a/openspec/changes/phase-6-polish/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-03-09
diff --git a/openspec/changes/phase-6-polish/design.md b/openspec/changes/phase-6-polish/design.md
deleted file mode 100644
index f76f6e6..0000000
--- a/openspec/changes/phase-6-polish/design.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## Design Decisions
-
-### Global Search
-The top bar search input already exists but has no onChange handler. Wire it to navigate to `/explore?search=<query>` using `useRouter`. The explore page reads the search param on mount and triggers `getFeedEvents` with it.
-
-### Advanced Filters
-Add org category, location, and date range as optional params to `getFeedEvents()`. Render filter dropdowns in a collapsible "More Filters" row below the tag filters on the explore page. Use shadcn Select/Popover components.
-
-### Org Event Creation
-The `createEvent` action already accepts `orgId`. Add a Select dropdown to the create event form that lists orgs where the current user is an owner or officer (query `orgMembers`). Add a `getUserOrgs()` action that returns orgs the user can post events for.
-
-### Event Reporting
-Simple approach: add a `reports` table or use a lightweight mechanism (just email/log for MVP). For now, create a `reportEvent` server action that inserts into a new `event_reports` table (eventId, reporterId, reason, createdAt). Show a report dialog on event detail with a textarea.
-
-### Landing Page Organizer CTA
-Add a secondary "Post an Event" link/button below the main sign-in CTA on the landing page. Routes to `/events/create` (which will redirect to auth if not logged in).
-
-### Clickable Org Name
-Wrap the org name text in event cards with a `<Link>` to `/orgs/<orgId>`. Requires passing `orgId` to event cards (currently not in FeedEvent type — need to add it).
-
-## Schema Changes
-- New table: `event_reports` (id, eventId, reporterId, reason text, createdAt)
-- No changes to existing tables
-
-## Dependencies
-- shadcn Select component (may need to install)
-- No new packages required
diff --git a/openspec/changes/phase-6-polish/proposal.md b/openspec/changes/phase-6-polish/proposal.md
deleted file mode 100644
index a1d10b5..0000000
--- a/openspec/changes/phase-6-polish/proposal.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## Why
-
-Several P0 and P1 PRD requirements remain unimplemented or broken. The global search bar is non-functional, explore filters are limited to tags only (missing org, location, date range), org leaders can't tie events to their organizations via the UI, and there's no report mechanism. These gaps block a polished launch experience.
-
-## What Changes
-
-- Wire the top-bar search input to actually trigger explore page search
-- Add advanced explore filters: organization type, location, date range
-- Add org selector to event creation form (backend already accepts `orgId`)
-- Add event report/flag mechanism with textbox submission
-- Add "Post an Event" organizer CTA to landing page
-- Add clickable org name on event cards linking to org profile
-
-## Capabilities
-
-### New Capabilities
-- `advanced-filters`: Organization type, location, and date range filters on explore page
-- `event-reporting`: Report/flag button on event detail with textbox submission
-- `org-event-creation`: Org selector in create event form for org leaders
-
-### Modified Capabilities
-- None
-
-## Impact
-
-- `apps/web/src/components/layout/top-bar.tsx` — wire search input
-- `apps/web/src/components/events/event-filters.tsx` — add filter UI
-- `apps/web/src/actions/events.ts` — extend `getFeedEvents` params
-- `apps/web/src/app/(app)/events/create/create-event-form.tsx` — add org selector
-- `apps/web/src/app/(app)/events/[id]/event-detail-client.tsx` — add report button
-- `apps/web/src/app/(auth)/page.tsx` — add organizer CTA
-- `apps/web/src/components/events/event-card.tsx` — clickable org name
diff --git a/openspec/changes/phase-6-polish/specs/advanced-filters/spec.md b/openspec/changes/phase-6-polish/specs/advanced-filters/spec.md
deleted file mode 100644
index 50a08dc..0000000
--- a/openspec/changes/phase-6-polish/specs/advanced-filters/spec.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Global search bar functionality
-The top bar search input SHALL trigger event search when the user types.
-
-#### Scenario: User searches from top bar
-- **WHEN** the user types a query in the top bar search input
-- **THEN** the app navigates to the explore page with the search query applied
-
-### Requirement: Organization type filter
-The explore page SHALL allow filtering events by organization category.
-
-#### Scenario: User filters by org category
-- **WHEN** the user selects an organization category (e.g., "Career", "Social")
-- **THEN** the feed shows only events from organizations of that category
-
-### Requirement: Location filter
-The explore page SHALL allow filtering events by campus location.
-
-#### Scenario: User filters by location
-- **WHEN** the user selects a campus location
-- **THEN** the feed shows only events at that location
-
-### Requirement: Date range filter
-The explore page SHALL allow filtering events by date range.
-
-#### Scenario: User filters by date
-- **WHEN** the user selects "Today", "This Week", or "This Month"
-- **THEN** the feed shows only events within that time range
-
-### Requirement: Clickable org name on event cards
-Event cards SHALL link the organization name to the org profile page.
-
-#### Scenario: User clicks org name
-- **WHEN** the user clicks the organization name on an event card
-- **THEN** the user navigates to that organization's profile page
diff --git a/openspec/changes/phase-6-polish/specs/event-reporting/spec.md b/openspec/changes/phase-6-polish/specs/event-reporting/spec.md
deleted file mode 100644
index 285b92a..0000000
--- a/openspec/changes/phase-6-polish/specs/event-reporting/spec.md
+++ /dev/null
@@ -1,12 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Report event
-The event detail page SHALL allow users to report inappropriate or inaccurate events.
-
-#### Scenario: User reports an event
-- **WHEN** the user clicks the "Report" button on the event detail page and submits a reason
-- **THEN** the report is stored for admin review and a confirmation toast is shown
-
-#### Scenario: Duplicate report prevention
-- **WHEN** the user has already reported an event
-- **THEN** the report button indicates the event has been reported
diff --git a/openspec/changes/phase-6-polish/specs/org-event-creation/spec.md b/openspec/changes/phase-6-polish/specs/org-event-creation/spec.md
deleted file mode 100644
index 72e7a45..0000000
--- a/openspec/changes/phase-6-polish/specs/org-event-creation/spec.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Org selector in event creation
-The event creation form SHALL allow org members to associate an event with their organization.
-
-#### Scenario: Org member creates event for org
-- **WHEN** the user is an owner or officer of an organization
-- **THEN** the create event form shows a dropdown to select which org the event belongs to
-
-#### Scenario: User with no org memberships
-- **WHEN** the user is not a member of any organization
-- **THEN** no org selector is shown
-
-### Requirement: Landing page organizer CTA
-The landing page SHALL include a secondary CTA encouraging organizers to post events.
-
-#### Scenario: Visitor sees organizer CTA
-- **WHEN** an unauthenticated user views the landing page
-- **THEN** a "Post an Event" call-to-action is visible alongside the main sign-in button
diff --git a/openspec/changes/phase-6-polish/tasks.md b/openspec/changes/phase-6-polish/tasks.md
deleted file mode 100644
index 0180d58..0000000
--- a/openspec/changes/phase-6-polish/tasks.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## 1. Global Search Bar
-
-- [ ] 1.1 Wire top-bar search input to navigate to `/explore?search=<query>` on Enter/submit
-- [ ] 1.2 Read `search` query param in explore page and pass to `ExploreClient` as `initialSearch`
-- [ ] 1.3 Pre-populate search input in explore client from `initialSearch` and trigger feed refresh
-
-## 2. Advanced Explore Filters
-
-- [ ] 2.1 Extend `getFeedEvents()` params to accept `orgCategory`, `locationId`, and `dateRange` ("today"|"week"|"month")
-- [ ] 2.2 Add filter UI row below tag filters — org category dropdown, location dropdown, date range pills
-- [ ] 2.3 Wire filter state changes to `refreshEvents()` in explore client
-
-## 3. Event Card Org Link
-
-- [ ] 3.1 Add `orgId` to `FeedEvent` interface and populate it in `getFeedEvents()`, `getMyEvents()`, `getSavedEvents()`, `getFriendsEvents()`
-- [ ] 3.2 Make org name on event cards a clickable `<Link>` to `/orgs/<orgId>`
-
-## 4. Org Event Creation
-
-- [x] 4.1 Add `getUserOrgs()` server action — return orgs where user is owner or officer
-- [x] 4.2 Add org selector dropdown to create event form, populated by `getUserOrgs()`
-- [x] 4.3 Pass selected `orgId` to `createEvent()` call
-
-## 5. Event Reporting
-
-- [ ] 5.1 Add `eventReports` table to database schema (id, eventId, reporterId, reason, createdAt)
-- [ ] 5.2 Add `reportEvent(eventId, reason)` server action with duplicate check
-- [ ] 5.3 Add report button + dialog with textarea to event detail page, with toast confirmation
-
-## 6. Landing Page Organizer CTA
-
-- [ ] 6.1 Add "Post an Event" secondary CTA button/link to landing page below sign-in button
diff --git a/openspec/changes/phase-7-data-pipelines/.openspec.yaml b/openspec/changes/phase-7-data-pipelines/.openspec.yaml
deleted file mode 100644
index 5cb9e8f..0000000
--- a/openspec/changes/phase-7-data-pipelines/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-03-09
diff --git a/openspec/changes/phase-7-data-pipelines/design.md b/openspec/changes/phase-7-data-pipelines/design.md
deleted file mode 100644
index d51084f..0000000
--- a/openspec/changes/phase-7-data-pipelines/design.md
+++ /dev/null
@@ -1,134 +0,0 @@
-## Design Decisions
-
-### Email Ingestion — Pull Model via Gmail API
-
-Use the Gmail API (not IMAP) to poll a Gmail inbox subscribed to Princeton listservs. A FastAPI background task or cron-triggered endpoint runs every 10–15 minutes, fetches unread messages, processes them, and marks them as read.
-
-**Account strategy:** Use a personal Google Workspace account for initial development and testing. Migrate to a dedicated service account before production deployment.
-
-**Why Gmail API over IMAP?**
-- OAuth2 is more secure than stored passwords
-- Gmail API supports label/query filtering natively
-- Better rate limits and reliability than raw IMAP
-- Google Workspace is standard at Princeton (g.princeton.edu)
-
-**Why not SMTP push (like listflow)?**
-- Requires DNS/MX record setup and a publicly-reachable SMTP server
-- More infrastructure burden for the same result
-- Pull model is simpler to deploy alongside the existing FastAPI backend
-
-### LLM Extraction Pipeline
-
-Each email goes through a structured extraction pipeline using **Gemini 3.1 Flash Lite via OpenRouter** (OpenAI-compatible API) with JSON mode:
-
-1. **Preprocess**: Convert HTML to plain text (via `beautifulsoup4`), extract links and attachment metadata
-2. **HoagieMail detection**: Check for HoagieMail footer pattern; if present, extract sender name and email from the structured footer (`Email composed by First.Last (first.last@princeton.edu)`)
-3. **Event extraction**: Single LLM call with JSON schema enforcement to extract:
-   - `title` (string) — event name
-   - `description` (string) — event details
-   - `datetime` (ISO 8601) — start time
-   - `end_datetime` (ISO 8601 | null) — end time if mentioned
-   - `location_name` (string) — raw location text
-   - `tags` (string[]) — from our `event_tag` enum
-   - `is_event` (boolean) — whether the email describes an actual event (vs. announcements, lost & found, etc.)
-4. **Location resolution**: Fuzzy-match `location_name` against our `campus_locations` table using string similarity. Fall back to a "TBD" / generic location if no match above threshold.
-5. **Deduplication check** (see below)
-6. **Insert** into `events` table with `source = "listserv"` and `sourceMessageId` set to the Gmail message ID
-
-### HoagieMail Footer Parsing
-
-HoagieMail emails include a structured footer:
-```
-This email was instantly sent to all college listservs with Hoagie Mail.
-Email composed by First.Last (first.last@princeton.edu) — if you believe ...
-```
-
-Parse this with a regex to extract `sender_name` and `sender_email`. Cross-reference against:
-1. `organizations` table (by name fuzzy match or a `listserv_configs` mapping)
-2. `users` table (by email/netId) to set `creatorId`
-
-If no org match, the event is created as an individual post attributed to a system "The Forum Bot" pipeline user (a dedicated row in the `users` table with a reserved netId like `_pipeline`).
-
-### Deduplication Strategy
-
-Aggressive dedup using a two-layer approach:
-
-1. **Exact dedup**: `sourceMessageId` uniqueness constraint prevents reprocessing the same email
-2. **Fuzzy dedup**: Before inserting, query events within ±24 hours of the extracted datetime. Compare titles using normalized Levenshtein similarity (via `thefuzz` library). If similarity > 0.75, skip insertion and log the duplicate.
-
-This catches cases where an event is both emailed to a listserv and manually created on The Forum.
-
-### Listserv Configuration
-
-New `listserv_configs` table to make the system extensible:
-
-| Column | Type | Description |
-|--------|------|-------------|
-| id | uuid | PK |
-| address | varchar | Listserv email address (e.g. `WHITMANWIRE@Princeton.EDU`) |
-| label | varchar | Display name (e.g. "Whitman Wire") |
-| org_id | uuid? | FK to organizations — auto-associate events from this list |
-| gmail_label | varchar | Gmail label/filter to identify these emails |
-| enabled | boolean | Toggle ingestion on/off |
-| created_at | timestamp | |
-
-### Events Schema Changes
-
-Add two columns to the `events` table:
-- `source` — `varchar`, default `"manual"`. Values: `"manual"`, `"listserv"`
-- `sourceMessageId` — `varchar`, nullable, unique. Gmail message ID for dedup
-
-No existing data is affected (all current events get `source = "manual"` by default).
-
-### Admin Panel (`apps/admin-web`)
-
-Minimal Vite + React app (no SSR needed) that talks directly to FastAPI endpoints:
-
-**Pages:**
-1. **Pipeline Dashboard** — Recent ingested emails, success/failure counts, last poll timestamp
-2. **Event Review** — List of pipeline-created events with inline edit/delete. Filter by status, date, listserv source
-3. **Listserv Config** — CRUD table for managing listserv subscriptions and org mappings
-4. **Dedup Log** — Shows skipped duplicates for debugging
-
-**Auth:** Protect with a simple API key or admin token in FastAPI (no CAS needed for internal tool).
-
-**Stack:** Vite 6, React 19, Tailwind CSS, shadcn/ui (standalone install), TanStack Query for data fetching.
-
-### FastAPI Endpoints (new)
-
-```
-POST   /pipeline/poll              — Trigger email poll (cron or manual)
-GET    /pipeline/status            — Last poll time, counts, errors
-GET    /pipeline/events            — List pipeline-created events (paginated)
-PATCH  /pipeline/events/{id}       — Edit a pipeline event
-DELETE /pipeline/events/{id}       — Delete a pipeline event
-GET    /pipeline/duplicates        — List skipped duplicates
-GET    /pipeline/configs           — List listserv configs
-POST   /pipeline/configs           — Create listserv config
-PATCH  /pipeline/configs/{id}      — Update listserv config
-DELETE /pipeline/configs/{id}      — Delete listserv config
-```
-
-### Cron / Scheduling
-
-Use a simple approach: a GitHub Actions cron (like Today does) or an external cron service that hits `POST /pipeline/poll` every 10–15 minutes. No in-process scheduler needed — keeps the FastAPI app stateless.
-
-## Schema Changes
-
-- `events` table: Add `source varchar default 'manual'`, `source_message_id varchar unique`
-- New table: `listserv_configs` (id, address, label, org_id FK, gmail_label, enabled, created_at)
-- New table: `pipeline_logs` (id, message_id, listserv_config_id FK, status enum, error_text, extracted_event_id FK nullable, created_at)
-
-## Dependencies
-
-### FastAPI (backends/fastapi)
-- `google-api-python-client` + `google-auth-oauthlib` — Gmail API access
-- `openai` — OpenRouter client (OpenAI-compatible SDK, pointed at `https://openrouter.ai/api/v1`)
-- `beautifulsoup4` — HTML parsing
-- `thefuzz[speedup]` — Fuzzy string matching for dedup and location resolution
-
-### Admin panel (apps/admin-web)
-- `vite`, `react`, `react-dom`, `react-router-dom`
-- `tailwindcss`, `@tailwindcss/vite`
-- `@tanstack/react-query`
-- `shadcn/ui` components (standalone)
diff --git a/openspec/changes/phase-7-data-pipelines/proposal.md b/openspec/changes/phase-7-data-pipelines/proposal.md
deleted file mode 100644
index 9ae1aa4..0000000
--- a/openspec/changes/phase-7-data-pipelines/proposal.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## Why
-
-The Forum currently depends entirely on manual event creation. Most Princeton events are announced via residential college listservs and services like Hoagie Mail — hundreds of emails per week that never make it into our platform. Without automated ingestion, the feed will always be incomplete and students will miss events.
-
-## What Changes
-
-- Add a listserv email ingestion pipeline in the FastAPI backend that polls a Gmail/Google Workspace inbox subscribed to Princeton listservs
-- Use LLM extraction (Gemini 3.1 Flash Lite via OpenRouter) to parse unstructured emails into structured event data matching our schema (title, description, datetime, location, tags)
-- Parse HoagieMail structured footers to extract sender org identity
-- Auto-publish extracted events to the main feed with `source = "listserv"` provenance tracking
-- Aggressive deduplication using title similarity + datetime proximity to prevent duplicates with manually-created events
-- Build a lightweight admin panel (`apps/admin-web`) for reviewing, editing, and managing pipeline-ingested events
-- Design the system to support any listserv — initial targets are one residential college listserv (e.g. WHITMANWIRE) and freefood@princeton.edu
-
-## Capabilities
-
-### New Capabilities
-- `listserv-ingestion`: Poll email inbox, extract structured events via LLM, auto-publish to feed
-- `deduplication`: Title + datetime similarity matching to prevent duplicate events
-- `hoagiemail-parsing`: Extract sender org from HoagieMail structured footers
-- `admin-panel`: Vite + React admin dashboard for managing pipeline-ingested events
-- `listserv-config`: CRUD for managing which listservs are ingested and their org mappings
-
-### Modified Capabilities
-- `events` schema: Add `source` and `sourceMessageId` fields for provenance tracking
-
-## Impact
-
-- `backends/fastapi/app/` — New pipeline modules: email polling, LLM extraction, dedup, auto-publish
-- `apps/database/src/schema/index.ts` — Add `source`, `sourceMessageId` to events table; add `listserv_configs` table
-- `apps/admin-web/` — New Vite + React app for pipeline management
-- `backends/fastapi/pyproject.toml` — Add dependencies: `google-api-python-client`, `openai` (for OpenRouter), `thefuzz`
diff --git a/openspec/changes/phase-7-data-pipelines/specs/listserv-ingestion/spec.md b/openspec/changes/phase-7-data-pipelines/specs/listserv-ingestion/spec.md
deleted file mode 100644
index 81f7a83..0000000
--- a/openspec/changes/phase-7-data-pipelines/specs/listserv-ingestion/spec.md
+++ /dev/null
@@ -1,67 +0,0 @@
-## Capability: Listserv Ingestion
-
-### Overview
-Automated pipeline that polls a Gmail inbox subscribed to Princeton listservs, extracts structured event data via LLM, deduplicates against existing events, and auto-publishes to The Forum's feed.
-
-### Email Ingestion
-- **Source**: Gmail API polling a dedicated inbox (e.g. `theforum-pipeline@g.princeton.edu`)
-- **Frequency**: Every 10–15 minutes via external cron
-- **Scope**: Configurable per-listserv via `listserv_configs` table
-- **Target listservs (initial)**: WHITMANWIRE@Princeton.EDU, freefood@Princeton.EDU
-- **Process**: Fetch unread → mark as read → enqueue for processing
-
-### HoagieMail Parsing
-- Detect HoagieMail footer via regex: `Email composed by (.+?) \((.+?@princeton\.edu)\)`
-- Extract sender display name and princeton.edu email
-- Use sender email to match against `users` (by netId/email) and `organizations` (via `listserv_configs.org_id` or name fuzzy match)
-
-### LLM Extraction
-- **Model**: Gemini 3.1 Flash Lite via OpenRouter (`google/gemini-flash-lite-3.1`) with `response_format: { type: "json_object" }`
-- **Input**: Preprocessed email (subject + plain text body + link list + attachment descriptions)
-- **Output schema**:
-  ```json
-  {
-    "is_event": true,
-    "title": "Spring Fling Concert",
-    "description": "Join us for live music...",
-    "datetime": "2026-04-15T19:00:00-04:00",
-    "end_datetime": "2026-04-15T22:00:00-04:00",
-    "location_name": "Frist Campus Center",
-    "tags": ["music", "social"]
-  }
-  ```
-- **Non-events**: Emails where `is_event = false` (lost & found, general announcements, etc.) are logged but not inserted
-- **Tag mapping**: LLM selects from the fixed `event_tag` enum values
-
-### Location Resolution
-- Fuzzy-match `location_name` against `campus_locations.name` using token-set ratio
-- Threshold: 70% similarity → match, else fall back to a generic "Other" location
-- Common aliases handled (e.g. "Frist" → "Frist Campus Center", "McCosh 50" → "McCosh Hall")
-
-### Deduplication
-- **Layer 1 — Exact**: `source_message_id` unique constraint prevents reprocessing
-- **Layer 2 — Fuzzy**: Before insert, query events where `datetime` is within ±24 hours. Compute normalized title similarity (token-set ratio via `thefuzz`). Skip if similarity > 0.75
-- **Logging**: All skipped duplicates recorded in `pipeline_logs` with `status = "duplicate"`
-
-### Auto-Publishing
-- Events with `is_event = true` that pass dedup are inserted directly into the `events` table
-- `source` set to `"listserv"`, `sourceMessageId` set to Gmail message ID
-- `orgId` set from `listserv_configs.org_id` or HoagieMail sender match
-- `creatorId` set from sender email match against `users`, or the system "The Forum Bot" pipeline user (netId: `_pipeline`)
-- `isPublic` set to `true`
-
-### Pipeline Logging
-- Every processed email produces a `pipeline_logs` entry with status: `"success"`, `"skipped_not_event"`, `"duplicate"`, `"error"`
-- Error entries include `error_text` for debugging
-- Success entries link to the created event via `extracted_event_id`
-
-### Admin Panel
-- **Dashboard**: Poll status, email throughput, error rate
-- **Event Review**: Browse/search/edit/delete pipeline-created events
-- **Listserv Config**: Add/remove/toggle listserv subscriptions, set org mappings
-- **Dedup Log**: Inspect skipped duplicates, manually override if needed
-
-### Extensibility
-- Adding a new listserv requires only a row in `listserv_configs` + subscribing the Gmail inbox to that list
-- The extraction prompt and tag enum can be updated without code changes (prompt stored as constant, enum comes from DB schema)
-- Future: image/flyer extraction from email attachments (OCR), webhook-based push ingestion
diff --git a/openspec/changes/phase-7-data-pipelines/tasks.md b/openspec/changes/phase-7-data-pipelines/tasks.md
deleted file mode 100644
index de5b0d5..0000000
--- a/openspec/changes/phase-7-data-pipelines/tasks.md
+++ /dev/null
@@ -1,70 +0,0 @@
-## 1. Database Schema Extensions
-
-- [x] 1.1 Add `source` (varchar, default `"manual"`) and `sourceMessageId` (varchar, nullable, unique) columns to `events` table
-- [x] 1.2 Create `listserv_configs` table (id, address, label, org_id FK, gmail_label, enabled, created_at)
-- [x] 1.3 Create `pipeline_logs` table (id, message_id, listserv_config_id FK, status enum, error_text, extracted_event_id FK nullable, created_at)
-- [x] 1.4 Generate and apply migration, seed initial listserv configs for WHITMANWIRE and freefood
-- [x] 1.5 Seed a system pipeline user ("The Forum Bot", netId: `_pipeline`) in the users table for unmatched event attribution
-
-## 2. Gmail API Integration
-
-- [x] 2.1 Add `google-api-python-client`, `google-auth-oauthlib` to FastAPI dependencies
-- [x] 2.2 Implement Gmail OAuth2 credential setup (service account or OAuth flow) with token persistence
-- [x] 2.3 Implement `fetch_unread_emails(label)` — fetch unread messages matching a Gmail label/query, return list of raw email data, mark as read
-- [x] 2.4 Add env vars (`GMAIL_CREDENTIALS_JSON`, `GMAIL_TOKEN_PATH`, `OPENROUTER_API_KEY`) to FastAPI config
-
-## 3. Email Parsing & Preprocessing
-
-- [x] 3.1 Add `beautifulsoup4` dependency, implement `html_to_text(html)` and `extract_links(html)` utilities
-- [x] 3.2 Implement HoagieMail footer detection and parsing — extract sender name and email via regex
-- [x] 3.3 Implement `preprocess_email(raw)` — returns structured dict with subject, body_text, sender, links, hoagiemail_sender, timestamp, message_id
-
-## 4. LLM Event Extraction
-
-- [x] 4.1 Add `openai` dependency, implement OpenRouter client wrapper (base_url `https://openrouter.ai/api/v1`, model `google/gemini-flash-lite-3.1`) with JSON mode
-- [x] 4.2 Design and implement extraction prompt — input: preprocessed email text; output: JSON with title, description, datetime, end_datetime, location_name, tags[], is_event
-- [x] 4.3 Implement `extract_event(preprocessed_email)` — calls LLM, validates output against schema, returns structured event or None (if `is_event = false`)
-- [x] 4.4 Implement `resolve_location(location_name)` — fuzzy-match against `campus_locations` table, return location_id or fallback
-
-## 5. Deduplication
-
-- [x] 5.1 Add `thefuzz[speedup]` dependency
-- [x] 5.2 Implement `check_duplicate(title, datetime)` — query events within ±24h window, compute title similarity, return True if match > 0.75 threshold
-- [x] 5.3 Implement `sourceMessageId` uniqueness check to prevent reprocessing same email
-
-## 6. Pipeline Orchestration
-
-- [x] 6.1 Implement `run_pipeline()` — orchestrates: fetch emails → preprocess → extract → dedup → insert event → log result
-- [x] 6.2 Handle org matching: cross-reference HoagieMail sender and listserv_config.org_id to set event's orgId
-- [x] 6.3 Handle creator attribution: match sender email to users table for creatorId, fall back to a system pipeline user
-- [x] 6.4 Wire up `POST /pipeline/poll` endpoint that triggers `run_pipeline()`
-- [x] 6.5 Add `GET /pipeline/status` endpoint — last poll time, success/fail counts
-
-## 7. Pipeline CRUD Endpoints
-
-- [x] 7.1 Implement `GET /pipeline/events` — list pipeline-created events (paginated, filterable by listserv source and date)
-- [x] 7.2 Implement `PATCH /pipeline/events/{id}` — edit pipeline event fields
-- [x] 7.3 Implement `DELETE /pipeline/events/{id}` — delete pipeline event
-- [x] 7.4 Implement `GET /pipeline/duplicates` — list skipped duplicates from pipeline_logs
-- [x] 7.5 Implement CRUD for `/pipeline/configs` — list, create, update, delete listserv configs
-
-## 8. Admin Panel — Project Setup
-
-- [x] 8.1 Scaffold `apps/admin-web` with Vite 6 + React 19 + TypeScript
-- [x] 8.2 Install and configure Tailwind CSS v4 and shadcn/ui (standalone)
-- [x] 8.3 Add react-router-dom with shell layout (sidebar nav, header)
-- [x] 8.4 Add TanStack Query provider and API client pointing to FastAPI backend
-- [x] 8.5 Add admin-web to Turborepo config and root dev script
-
-## 9. Admin Panel — Pages
-
-- [x] 9.1 Pipeline Dashboard page — last poll time, email count, success/failure stats, manual "Poll Now" button
-- [x] 9.2 Event Review page — table of pipeline events with inline edit (title, datetime, location, tags), delete, and link to live event
-- [x] 9.3 Listserv Config page — CRUD table for managing listserv subscriptions and org mappings
-- [x] 9.4 Dedup Log page — table of skipped duplicates showing original vs matched event
-
-## 10. Scheduling & Deployment
-
-- [x] 10.1 Add cron trigger (GitHub Actions workflow or external) to hit `POST /pipeline/poll` every 15 minutes
-- [x] 10.2 Add admin panel auth middleware — simple API key or bearer token check
-- [x] 10.3 Document env vars and setup steps for Gmail API credentials, OpenAI key, and admin auth
diff --git a/openspec/changes/phase-8-recommendations/.openspec.yaml b/openspec/changes/phase-8-recommendations/.openspec.yaml
deleted file mode 100644
index 3c861dd..0000000
--- a/openspec/changes/phase-8-recommendations/.openspec.yaml
+++ /dev/null
@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-03-18
diff --git a/openspec/changes/phase-8-recommendations/design.md b/openspec/changes/phase-8-recommendations/design.md
deleted file mode 100644
index a8d7e5e..0000000
--- a/openspec/changes/phase-8-recommendations/design.md
+++ /dev/null
@@ -1,256 +0,0 @@
-## Design Decisions
-
-### Interaction Logging — Server Actions + Postgres
-
-Log all implicit feedback directly from Next.js server actions into a Postgres `interactions` table. No separate analytics service needed at campus scale (~6K users).
-
-**Interaction types and weights** (per Emilio's research):
-
-| Type | Weight | Trigger |
-|------|--------|---------|
-| view | 1.0 | Event card enters viewport (IntersectionObserver, 1s threshold) |
-| click | 2.0 | Click on event card or expand icon |
-| save | 3.0 | Toggle save/bookmark |
-| rsvp | 5.0 | Toggle RSVP |
-| share | 2.0 | Share action |
-| hide | -1.0 | Dismiss/not-interested action |
-
-**Metadata captured per interaction:**
-```json
-{
-  "source": "feed" | "search" | "map" | "notification" | "similar" | "direct",
-  "position": 3,           // rank position in feed (for position bias correction)
-  "dwell_ms": 1200,        // time spent on event detail page (for views)
-  "query": "free boba"     // search query context (for search clicks)
-}
-```
-
-**Why not a dedicated analytics service?**
-- Campus scale (~6K users, ~100 events/week) means ~10K interactions/day max
-- Postgres handles this easily; no need for Kafka/ClickHouse
-- Keeps the stack simple — same DB, same ORM, same deployment
-
-### Tag Weight Aggregation — Nightly Batch Job
-
-A FastAPI cron job (or GitHub Actions trigger) computes per-user tag preference weights:
-
-```python
-# Pseudocode for tag weight computation
-for each user:
-    interactions = get_interactions(user_id, last_90_days)
-    tag_scores = defaultdict(float)
-    for interaction in interactions:
-        age_days = (now - interaction.created_at).days
-        decay = 0.95 ** age_days  # exponential time decay
-        weight = interaction.interaction_value * decay
-        for tag in get_event_tags(interaction.item_id):
-            tag_scores[tag] += weight
-    # Normalize to 0-1
-    max_score = max(tag_scores.values(), default=1)
-    normalized = {tag: score / max_score for tag, score in tag_scores.items()}
-    upsert_user_preference_vector(user_id, tag_weights=normalized)
-```
-
-**Time decay:** `0.95^days` — interactions from 2 weeks ago retain ~48% weight; 1 month ago ~22%; 3 months ago ~0.8%. This naturally adapts to changing interests.
-
-**Blend with onboarding:** For users with < 10 interactions, blend:
-```
-effective_weights = 0.7 × onboarding_interests + 0.3 × interaction_weights
-```
-Gradually shifts to 100% interaction-based as data grows.
-
-### Enhanced SQL Scoring — Incremental Upgrade
-
-Modify `getFeedEvents()` to use computed tag weights instead of static onboarding interests:
-
-```
-score = (3.0 × behavioral_interest_overlap)  // from user_preference_vectors
-      + (2.0 × time_proximity)
-      + (4.0 × friend_rsvp_score)
-      + (1.0 × recency_boost)
-      + (0.5 × popularity_score)             // NEW: log(view_count + 1) * 0.5
-      + (0.5 × org_affinity)                 // NEW: user follows/interacted with org
-      + (0.3 × random_factor)                // reduced from 0.5
-```
-
-**Diversity constraint:** After scoring, deduplicate: max 3 events per org in the top 20 results.
-
-**Item-item similarity for "Similar Events":**
-```sql
--- Co-RSVP similarity: events that share RSVPs
-SELECT b.event_id, COUNT(*) as co_rsvps
-FROM rsvps a
-JOIN rsvps b ON a.user_id = b.user_id AND a.event_id != b.event_id
-WHERE a.event_id = $target_event_id
-GROUP BY b.event_id
-ORDER BY co_rsvps DESC
-LIMIT 8
-```
-
-### Collaborative Filtering — Implicit ALS via FastAPI
-
-**Algorithm choice: ALS (Alternating Least Squares) for implicit feedback**
-
-Per Yubi's research, ALS is the best fit because:
-- Designed for implicit feedback (no explicit ratings)
-- Scalable to our data size (~6K users × ~1K items)
-- Well-supported by the `implicit` Python library
-- Produces latent vectors usable for both user-to-item and item-to-item similarity
-
-**Training pipeline:**
-
-```python
-# backends/fastapi/app/train.py
-from implicit.als import AlternatingLeastSquares
-import scipy.sparse as sparse
-
-def train_model():
-    # 1. Build interaction matrix from Postgres
-    interactions = fetch_interactions(last_180_days)
-    user_ids, item_ids, values = zip(*[
-        (i.user_id, i.item_id, i.interaction_value)
-        for i in interactions
-    ])
-    matrix = sparse.csr_matrix((values, (user_ids, item_ids)))
-
-    # 2. Train ALS model
-    model = AlternatingLeastSquares(
-        factors=64,          # latent dimension
-        regularization=0.1,
-        iterations=15,
-        use_gpu=False,       # CPU is fine for campus scale
-    )
-    model.fit(matrix)
-
-    # 3. Export vectors to Postgres
-    for user_idx, user_id in enumerate(user_id_map):
-        upsert_user_vector(user_id, model.user_factors[user_idx].tolist())
-    for item_idx, item_id in enumerate(item_id_map):
-        upsert_item_vector(item_id, model.item_factors[item_idx].tolist())
-```
-
-**Inference (online):**
-
-```python
-# backends/fastapi/app/routers/recommendations.py
-@router.post("/recommendations/feed")
-async def get_recommendations(user_id: str, limit: int = 20):
-    user_vector = get_user_vector(user_id)
-    if user_vector is None:
-        return cold_start_recommendations(user_id, limit)
-
-    # Score all candidate items
-    candidate_items = get_upcoming_events()
-    scores = []
-    for item in candidate_items:
-        cf_score = np.dot(user_vector, item.vector) if item.vector else 0
-        content_score = tag_similarity(user_id, item.id)
-        popularity = math.log(item.view_count + 1) * 0.15
-        time_score = time_proximity(item.datetime)
-        context = context_adjustment(user_id, item)
-
-        final = (0.4 * cf_score
-               + 0.25 * content_score
-               + 0.15 * popularity
-               + 0.1 * time_score
-               + 0.1 * context)
-        scores.append((item.id, final))
-
-    # Apply diversity: max 3 per org
-    return apply_diversity(sorted(scores, reverse=True), limit)
-```
-
-**Schedule:** Nightly at 3 AM via cron (`0 3 * * *`). Training takes ~seconds at campus scale.
-
-### Cold Start Strategy (per Yubi's research)
-
-**New students (< 10 interactions):**
-1. Use onboarding interests as seed (treat as pseudo-interactions with weight 3.0)
-2. Attribute-based filtering: boost events matching class year (freshmen → orientation events), major (COS → tech talks), residential college (Butler → Butler events)
-3. Popularity fallback: fill remaining slots with most-RSVP'd upcoming events
-
-**New events (< 5 interactions):**
-1. Content-based: match event tags to user tag_weights
-2. Org-based: boost for users who follow the organizing group
-3. Creator-based: boost if friends with the event creator
-
-### A/B Testing — Cookie-Based Split
-
-```typescript
-// middleware.ts
-const AB_COOKIE = "forum_rec_variant";
-if (!request.cookies.get(AB_COOKIE)) {
-  const variant = Math.random() < 0.5 ? "sql" : "cf";
-  response.cookies.set(AB_COOKIE, variant, { maxAge: 7 * 86400 });
-}
-```
-
-In `getFeedEvents()`, read the cookie to decide scoring method:
-- `"sql"` → enhanced SQL scoring (Phase 2)
-- `"cf"` → FastAPI CF scoring (Phase 3)
-
-Log the variant in interactions for offline metric computation.
-
-### Privacy & User Controls
-
-**Data separation** (per Yubi's spec):
-- All interaction data uses internal `user_id` (UUID), never NetID
-- NextAuth JWT already maps CAS → internal ID
-- Recommendation service never receives PII
-
-**User controls (in Settings page):**
-- "Not interested" button on event cards → logs `hide` interaction
-- "Reset my recommendations" → deletes interaction history, resets to onboarding interests
-- "Turn off personalization" → flag in `users` table; feed falls back to popularity + time only
-- "How recommendations work" → static explanation page
-
-**Data retention:**
-- Raw interactions: retained for 6 months
-- Older than 6 months: aggregated into `user_preference_vectors`, raw logs deleted
-- Nightly cleanup job alongside training
-
-## Schema Changes
-
-### New Tables
-
-```sql
--- Implicit feedback log
-CREATE TABLE interactions (
-  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-  user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
-  item_id UUID NOT NULL,
-  item_type VARCHAR(20) NOT NULL DEFAULT 'event',  -- 'event' | 'organization'
-  interaction_type VARCHAR(20) NOT NULL,  -- 'view' | 'click' | 'rsvp' | 'save' | 'share' | 'hide'
-  interaction_value FLOAT NOT NULL,
-  metadata JSONB,
-  created_at TIMESTAMP NOT NULL DEFAULT now()
-);
-
-CREATE INDEX idx_interactions_user ON interactions(user_id);
-CREATE INDEX idx_interactions_item ON interactions(item_id);
-CREATE INDEX idx_interactions_created ON interactions(created_at);
-
--- Materialized user preference vectors
-CREATE TABLE user_preference_vectors (
-  user_id UUID PRIMARY KEY REFERENCES users(id) ON DELETE CASCADE,
-  tag_weights JSONB NOT NULL DEFAULT '{}',
-  latent_vector FLOAT[] DEFAULT NULL,
-  interaction_count INT NOT NULL DEFAULT 0,
-  updated_at TIMESTAMP NOT NULL DEFAULT now()
-);
-```
-
-### Modified Tables
-
-- `users`: Add `personalization_enabled BOOLEAN DEFAULT true`
-
-## Dependencies
-
-### FastAPI (backends/fastapi)
-- `implicit` — ALS and BPR collaborative filtering
-- `scipy` — Sparse matrix operations
-- `numpy` — Numerical computing
-- `psycopg2-binary` — Direct Postgres access for training pipeline
-
-### Next.js (apps/web)
-- No new dependencies — uses existing Drizzle ORM and server actions
diff --git a/openspec/changes/phase-8-recommendations/proposal.md b/openspec/changes/phase-8-recommendations/proposal.md
deleted file mode 100644
index 22bbc97..0000000
--- a/openspec/changes/phase-8-recommendations/proposal.md
+++ /dev/null
@@ -1,112 +0,0 @@
-# Phase 8 — ML Recommendation System
-
-## Summary
-
-Build a progressive recommendation engine for The Forum that evolves from enhanced SQL scoring to full collaborative filtering. Leverages research from TIG-212 (Yubi — CF algorithms, data schema, cold-start, privacy) and TIG-215 (Emilio — user modeling, evaluation metrics, implementation libraries).
-
-## Motivation
-
-The MVP feed ranking uses a static weighted formula (`3×interest + 2×time + 4×friends + 1×recency + 0.5×random`) computed in Next.js server actions. This works for launch but has key limitations:
-
-- **No behavioral learning** — the formula never adapts to what a student actually clicks, RSVPs to, or ignores
-- **No collaborative signal** — "students like you attended X" doesn't exist yet
-- **No item similarity** — "similar events" uses only tag overlap, missing co-attendance patterns
-- **Cold start relies entirely on onboarding** — if a student picks wrong interests, the feed stays bad
-
-Princeton has ~6,000 undergraduates and hundreds of events per week. Even modest personalization dramatically improves discovery — the difference between a student seeing the 3 events that matter vs. scrolling past 20 irrelevant ones.
-
-## Approach
-
-Four progressive phases, each deployable independently:
-
-```
-Phase 1: Interaction Logging        (foundation — start collecting signals)
-    ↓
-Phase 2: Enhanced SQL Scoring       (immediate feed improvement, no new infra)
-    ↓
-Phase 3: Collaborative Filtering    (FastAPI ML service, ALS matrix factorization)
-    ↓
-Phase 4: Evaluation & Privacy       (A/B testing, metrics, user controls)
-```
-
-### Architecture
-
-```
-┌─────────────────────────────────────────────────────┐
-│                   Next.js 15                         │
-│  ┌────────────┐  ┌────────────┐  ┌───────────────┐  │
-│  │  Explore   │  │  Server    │  │  Interaction   │  │
-│  │  Feed UI   │  │  Actions   │  │  Logger        │  │
-│  └─────┬──────┘  └─────┬──────┘  └───────┬───────┘  │
-│        │               │                 │           │
-│        └───────┬───────┘─────────────────┘           │
-│           ┌────▼─────┐                               │
-│           │ Drizzle  │                               │
-│           │   ORM    │                               │
-│           └────┬─────┘                               │
-└────────────────┼─────────────────────────────────────┘
-            ┌────▼─────┐         ┌──────────────────┐
-            │ Postgres │◄────────│   FastAPI ML      │
-            │ (+ interactions    │  ┌────────────┐  │
-            │   table)  │        │  │ ALS Train  │  │
-            └──────────┘         │  │ (nightly)  │  │
-                                 │  └────────────┘  │
-                                 │  ┌────────────┐  │
-                                 │  │ /recommend │  │
-                                 │  │  endpoints │  │
-                                 │  └────────────┘  │
-                                 └──────────────────┘
-```
-
-**Key design decisions:**
-- **Interaction logging in Next.js** — no new service needed; server actions write directly to Postgres
-- **ML training in FastAPI** — Python has the best ML ecosystem (`implicit`, `scipy`, `numpy`); FastAPI is already in the monorepo
-- **Graceful fallback** — if FastAPI is down, Next.js falls back to enhanced SQL scoring
-- **Privacy-first** — all recommendation data uses internal `user_id`, never NetID (per Yubi's auth separation pattern)
-
-## Capabilities
-
-### New Capabilities
-- `interaction-logging`: Track implicit user signals (views, clicks, RSVPs, saves, hides) with weighted scoring and metadata
-- `tag-weight-aggregation`: Nightly job to compute per-user tag preference weights from interaction history with time decay
-- `collaborative-filtering`: ALS-based matrix factorization trained on interaction data, served via FastAPI endpoints
-- `hybrid-scoring`: Blended ranking combining CF scores, content similarity, popularity, time proximity, and context
-- `cold-start-fallback`: Attribute-based recommendations for new users (< 10 interactions) and content-based for new events (< 5 interactions)
-- `recommendation-api`: FastAPI endpoints for personalized feed, similar events, and similar users
-- `ab-testing`: Cookie-based A/B split between SQL scoring and CF model
-- `user-controls`: Hide/dismiss events, opt-out of personalization, reset recommendation history
-
-### Modified Capabilities
-- `feed-ranking`: Enhanced with interaction-derived tag weights, popularity scores, org affinity, and diversity constraints
-- `similar-events`: Upgraded from tag-only to co-RSVP item-item cosine similarity
-- `events` schema: Add `interactions`, `user_preference_vectors` tables
-
-## Impact
-
-- `apps/database/src/schema/index.ts` — New tables: `interactions`, `user_preference_vectors`
-- `apps/web/src/actions/interactions.ts` — New: interaction logging server action
-- `apps/web/src/actions/events.ts` — Modified: enhanced `getFeedEvents` and `getSimilarEvents`
-- `apps/web/src/components/events/event-card.tsx` — Modified: add IntersectionObserver view tracking, hide action
-- `apps/web/src/app/(app)/explore/explore-client.tsx` — Modified: click tracking, source context
-- `apps/web/src/app/(app)/settings/settings-client.tsx` — Modified: recommendation controls
-- `backends/fastapi/app/routers/recommendations.py` — New: recommendation endpoints
-- `backends/fastapi/app/train.py` — New: ALS training pipeline
-- `backends/fastapi/app/jobs/aggregate.py` — New: tag weight aggregation job
-
-## Non-goals
-
-- Real-time model updates (nightly batch is sufficient for campus-scale)
-- Deep learning recommenders (ALS is simpler and sufficient for ~6K users)
-- Cross-platform recommendations (The Forum only)
-- Content generation or summarization
-- Social graph analysis beyond friend RSVPs
-
-## Risks
-
-| Risk | Mitigation |
-|------|-----------|
-| Insufficient interaction data at launch | Phase 2 enhanced SQL scoring works without CF; Phase 1 logging starts immediately |
-| Cold start for new students | Onboarding interests + attribute-based filtering (class year, major, res college) |
-| FastAPI service unavailability | Graceful fallback to SQL scoring in Next.js |
-| Privacy concerns with behavioral tracking | Internal user_id only, opt-out controls, data retention limits, transparency page |
-| Model quality degradation | Automated evaluation metrics (Precision@K, NDCG@K), A/B testing against baseline |
diff --git a/openspec/changes/phase-8-recommendations/specs/collaborative-filtering/spec.md b/openspec/changes/phase-8-recommendations/specs/collaborative-filtering/spec.md
deleted file mode 100644
index fd286db..0000000
--- a/openspec/changes/phase-8-recommendations/specs/collaborative-filtering/spec.md
+++ /dev/null
@@ -1,131 +0,0 @@
-# Spec: Collaborative Filtering Engine
-
-## Overview
-Train an implicit feedback ALS (Alternating Least Squares) model on user-item interaction data and serve personalized recommendations via FastAPI endpoints. Based on research from TIG-212 (Yubi) and TIG-215 (Emilio).
-
-## Requirements
-
-### P0
-- ALS training pipeline in FastAPI using `implicit` library
-- Nightly training job producing user and item latent vectors (dimension 64)
-- FastAPI endpoint: `POST /recommendations/feed` returning ranked event IDs with scores
-- FastAPI endpoint: `POST /recommendations/similar` returning similar events for a given event
-- Hybrid scoring: `0.4×CF + 0.25×content + 0.15×popularity + 0.1×time + 0.1×context`
-- Next.js integration: call FastAPI from `getFeedEvents()` with graceful fallback to SQL scoring
-
-### P1
-- Cold-start handling for new users (< 10 interactions): attribute-based + popularity fallback
-- Cold-start handling for new events (< 5 interactions): content-based + org-based fallback
-- `POST /recommendations/users` endpoint for friend suggestions based on similar taste vectors
-- Model versioning: store model timestamp and version in DB
-
-### P2
-- Incremental model updates (hourly mini-batch instead of full nightly retrain)
-- Contextual reranking: boost by time-of-day patterns, campus region proximity
-- Exploration/exploitation balance: inject 10% random candidates to avoid filter bubbles
-
-## Training Pipeline
-
-```
-backends/fastapi/app/train.py
-```
-
-1. **Extract**: Query `interactions` table for last 180 days, join with `events` for active items
-2. **Transform**: Build sparse `user × item` CSR matrix; apply time decay (`0.95^age_days`); filter users with < 3 interactions
-3. **Train**: `implicit.als.AlternatingLeastSquares(factors=64, regularization=0.1, iterations=15)`
-4. **Export**: Write user vectors to `user_preference_vectors.latent_vector`, item vectors to new `item_features` rows
-5. **Validate**: Compute Precision@10 on held-out 10% test set; log to `pipeline_logs`
-
-**Schedule**: `0 3 * * *` (nightly at 3 AM via cron hitting `POST /train/run`)
-
-**Estimated training time**: < 30 seconds for 6K users × 1K items matrix.
-
-## API Endpoints
-
-### `POST /recommendations/feed`
-```json
-Request:  { "user_id": "uuid", "limit": 20, "exclude_ids": ["uuid", ...] }
-Response: { "items": [{ "event_id": "uuid", "score": 0.87, "reason": "cf" }, ...],
-            "model_version": "2026-03-18T03:00:00Z" }
-```
-
-### `POST /recommendations/similar`
-```json
-Request:  { "event_id": "uuid", "limit": 8 }
-Response: { "items": [{ "event_id": "uuid", "similarity": 0.92 }, ...] }
-```
-
-### `POST /recommendations/users`
-```json
-Request:  { "user_id": "uuid", "limit": 10 }
-Response: { "users": [{ "user_id": "uuid", "similarity": 0.85 }, ...] }
-```
-
-## Cold Start Logic
-
-**New users** (interaction_count < 10):
-```python
-def cold_start_recommendations(user_id, limit):
-    profile = get_user_profile(user_id)  # class_year, major, interests
-    candidates = get_upcoming_events()
-
-    scores = []
-    for event in candidates:
-        tag_match = len(set(profile.interests) & set(event.tags)) / max(len(profile.interests), 1)
-        popularity = math.log(event.rsvp_count + 1)
-        time_score = time_proximity(event.datetime)
-        attr_boost = 0.3 if matches_class_year(profile, event) else 0
-
-        score = 0.4 * tag_match + 0.3 * popularity + 0.2 * time_score + 0.1 * attr_boost
-        scores.append((event.id, score))
-
-    return sorted(scores, reverse=True)[:limit]
-```
-
-**New events** (< 5 interactions):
-- Use content-based scoring (tag similarity to user preferences)
-- Boost if user follows the organizing org
-- Inherit popularity estimate from similar past events by same org
-
-## Next.js Integration
-
-```typescript
-// apps/web/src/actions/events.ts
-async function getFeedEvents(params) {
-  const variant = cookies().get("forum_rec_variant")?.value ?? "sql";
-
-  if (variant === "cf") {
-    try {
-      const res = await fetch(`${env.RECOMMENDATION_API_URL}/recommendations/feed`, {
-        method: "POST",
-        body: JSON.stringify({ user_id: userId, limit: 20 }),
-      });
-      if (res.ok) {
-        const { items } = await res.json();
-        // Fetch full event data for the returned IDs
-        return enrichEventIds(items.map(i => i.event_id));
-      }
-    } catch {
-      // Fallback to SQL scoring
-    }
-  }
-
-  // SQL scoring (existing + enhanced)
-  return sqlScoredFeed(params);
-}
-```
-
-## Dependencies
-
-- `implicit>=0.7.0` — ALS and BPR
-- `scipy>=1.11` — Sparse matrices
-- `numpy>=1.25` — Numerical ops
-- `psycopg2-binary` — Direct DB access for training
-
-## Files
-
-- `backends/fastapi/app/train.py` — Training pipeline
-- `backends/fastapi/app/routers/recommendations.py` — API endpoints
-- `backends/fastapi/app/models/recommender.py` — Model loading and inference
-- `apps/web/src/actions/events.ts` — Integration with fallback
-- `apps/web/src/env.ts` — Add `RECOMMENDATION_API_URL` env var
diff --git a/openspec/changes/phase-8-recommendations/specs/enhanced-scoring/spec.md b/openspec/changes/phase-8-recommendations/specs/enhanced-scoring/spec.md
deleted file mode 100644
index 6989416..0000000
--- a/openspec/changes/phase-8-recommendations/specs/enhanced-scoring/spec.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Spec: Enhanced Content-Based Scoring
-
-## Overview
-Improve the existing SQL-based feed ranking by incorporating behavioral signals from the interactions table, popularity metrics, org affinity, and diversity constraints. No new infrastructure needed — all changes are within `getFeedEvents()`.
-
-## Requirements
-
-### P0
-- Replace static `interest_overlap` with `tag_weights` from `user_preference_vectors` table
-- Blend onboarding interests with behavioral weights: `0.7 × onboarding + 0.3 × behavioral` for users with < 10 interactions, shifting to 100% behavioral as interaction count grows
-- Add popularity score: `log(view_count + 1) * 0.5` where `view_count` is aggregated from `interactions`
-- Updated scoring formula:
-  ```
-  score = (3.0 × behavioral_interest_overlap)
-        + (2.0 × time_proximity)
-        + (4.0 × friend_rsvp_score)
-        + (1.0 × recency_boost)
-        + (0.5 × popularity_score)
-        + (0.5 × org_affinity)
-        + (0.3 × random_factor)
-  ```
-
-### P1
-- Org affinity score (0-1): 1.0 if user follows the org, 0.5 if user has interacted with org's past events, 0 otherwise
-- Diversity constraint: max 3 events per org in top 20 results (post-scoring deduplication)
-- "New events" boost: events < 24h old get +1.0 to recency_boost
-
-### P2
-- Co-RSVP item-item similarity for "Similar Events" endpoint
-  ```sql
-  SELECT b.event_id, COUNT(*) as co_rsvps
-  FROM rsvps a JOIN rsvps b ON a.user_id = b.user_id AND a.event_id != b.event_id
-  WHERE a.event_id = $target
-  GROUP BY b.event_id ORDER BY co_rsvps DESC LIMIT 8
-  ```
-- Position bias correction: downweight items the user has seen before (interaction log lookup)
-
-## Nightly Tag Weight Aggregation
-
-A batch job (FastAPI cron or GitHub Actions) computes `user_preference_vectors.tag_weights`:
-
-1. Fetch all interactions for user in last 90 days
-2. Apply exponential time decay: `weight = interaction_value × 0.95^age_days`
-3. Sum weights per tag (from event tags of interacted items)
-4. Normalize to 0-1 range
-5. Upsert into `user_preference_vectors`
-
-Schedule: nightly at 2 AM, before the CF training job at 3 AM.
-
-## Files Changed
-
-- `apps/web/src/actions/events.ts` — `getFeedEvents()` and `getSimilarEvents()`
-- `backends/fastapi/app/jobs/aggregate.py` — New tag weight aggregation job
-- `apps/database/src/schema/index.ts` — `user_preference_vectors` table
diff --git a/openspec/changes/phase-8-recommendations/specs/evaluation-and-privacy/spec.md b/openspec/changes/phase-8-recommendations/specs/evaluation-and-privacy/spec.md
deleted file mode 100644
index 9a3a5e1..0000000
--- a/openspec/changes/phase-8-recommendations/specs/evaluation-and-privacy/spec.md
+++ /dev/null
@@ -1,103 +0,0 @@
-# Spec: Evaluation, Privacy & User Controls
-
-## Overview
-Measure recommendation quality with offline and online metrics, implement A/B testing infrastructure, add user-facing controls for transparency and opt-out, and enforce data retention policies.
-
-## Requirements
-
-### P0 — Evaluation Metrics
-- Offline evaluation during training: compute Precision@10, Recall@10, NDCG@10, Hit Rate@10 on held-out test set
-- Log metrics to `pipeline_logs` table after each training run
-- Alert (Slack webhook or email) if Precision@10 drops below threshold (0.15)
-
-### P0 — User Controls
-- "Not interested" dismiss button on event cards → logs `hide` interaction with weight -1.0
-- Settings toggle: "Personalized recommendations" (on/off) → stored as `personalization_enabled` on users table
-- When disabled: feed falls back to popularity + time scoring only (no CF, no interest overlap)
-
-### P1 — A/B Testing
-- Cookie-based split: `forum_rec_variant` cookie, 50/50 between `sql` and `cf`
-- Set on first visit, persists 7 days
-- Variant logged in every interaction's metadata for offline analysis
-- Dashboard query: compare Precision@10, click-through rate, RSVP rate between variants
-
-### P1 — Privacy
-- All interaction data keyed on internal `user_id` (UUID), never NetID
-- Recommendation API never receives or returns PII
-- "Reset my recommendations" button in Settings: deletes all rows from `interactions` and `user_preference_vectors` for that user
-- "How recommendations work" info section in Settings explaining signals used
-
-### P2 — Data Retention
-- Interactions older than 6 months: aggregate into `user_preference_vectors.tag_weights`, then delete raw rows
-- Nightly cleanup job runs after training: `DELETE FROM interactions WHERE created_at < now() - INTERVAL '180 days'`
-- Latent vectors regenerated nightly; no stale vector accumulation
-
-## Evaluation Metrics Detail
-
-**Precision@K**: Of the top K recommended events, how many did the user actually interact with (click, RSVP, save) within the next 7 days?
-
-**Recall@K**: Of all events the user interacted with in the next 7 days, how many were in the top K recommendations?
-
-**NDCG@K**: Normalized discounted cumulative gain — higher-ranked relevant items score more. Captures ranking quality, not just set overlap.
-
-**Hit Rate@K**: Binary — did the user interact with at least one of the top K recommendations?
-
-**Online proxy metrics** (measured via interaction logs):
-- Feed click-through rate: clicks / views per feed session
-- RSVP conversion rate: RSVPs / clicks
-- Session depth: average number of event cards viewed per session
-- Return rate: % of users who visit the feed on consecutive days
-
-## A/B Testing Implementation
-
-```typescript
-// apps/web/src/middleware.ts
-import { NextResponse } from "next/server";
-
-export function middleware(request) {
-  const response = NextResponse.next();
-  const variant = request.cookies.get("forum_rec_variant")?.value;
-
-  if (!variant) {
-    const assigned = Math.random() < 0.5 ? "sql" : "cf";
-    response.cookies.set("forum_rec_variant", assigned, {
-      maxAge: 7 * 24 * 60 * 60,
-      path: "/",
-      sameSite: "lax",
-    });
-  }
-
-  return response;
-}
-
-export const config = { matcher: ["/explore", "/events/:path*", "/map"] };
-```
-
-## User Controls UI (Settings Page)
-
-```
-┌─────────────────────────────────────────┐
-│ ● Recommendations                        │
-│                                          │
-│ Personalized feed          [████ ON ]    │
-│ Your feed is ranked based on your        │
-│ interests, activity, and friends.        │
-│                                          │
-│ [Reset my recommendations]               │
-│ Clears your activity history and         │
-│ restarts from your onboarding interests. │
-│                                          │
-│ How it works ›                           │
-│ Learn how Forum personalizes your feed.  │
-└─────────────────────────────────────────┘
-```
-
-## Files Changed
-
-- `apps/web/src/middleware.ts` — A/B cookie assignment
-- `apps/web/src/app/(app)/settings/settings-client.tsx` — Recommendation controls UI
-- `apps/web/src/actions/users.ts` — `resetRecommendations()`, `togglePersonalization()` actions
-- `apps/web/src/components/events/event-card.tsx` — Hide/dismiss button
-- `apps/database/src/schema/index.ts` — Add `personalization_enabled` to users table
-- `backends/fastapi/app/jobs/cleanup.py` — Data retention cleanup job
-- `backends/fastapi/app/train.py` — Evaluation metric computation and logging
diff --git a/openspec/changes/phase-8-recommendations/specs/interaction-logging/spec.md b/openspec/changes/phase-8-recommendations/specs/interaction-logging/spec.md
deleted file mode 100644
index 64d3968..0000000
--- a/openspec/changes/phase-8-recommendations/specs/interaction-logging/spec.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Spec: Interaction Logging
-
-## Overview
-Capture implicit user feedback (views, clicks, RSVPs, saves, shares, hides) into a structured `interactions` table. This is the foundation for all ML-based recommendations.
-
-## Requirements
-
-### P0
-- New `interactions` table in Postgres with user_id, item_id, item_type, interaction_type, interaction_value, metadata, created_at
-- Server action `logInteraction()` that writes to the table
-- Log `rsvp` and `save` interactions from existing toggle handlers in event cards
-- Log `click` when user navigates to event detail page
-- Log `share` from existing share handler
-- Interaction weights: view=1, click=2, save=3, rsvp=5, share=2, hide=-1
-
-### P1
-- Log `view` when event card enters viewport using IntersectionObserver (1s dwell threshold to avoid scroll-by noise)
-- Track `source` metadata: feed, search, map, notification, similar, direct
-- Track `position` in feed for position bias correction
-- Add `hide`/dismiss button to event cards (negative signal)
-
-### P2
-- Track `dwell_ms` on event detail pages (time between mount and unmount)
-- Track search `query` context for search-click interactions
-- Batch logging: debounce rapid interactions client-side, send in batches
-
-## Server Action
-
-```typescript
-// apps/web/src/actions/interactions.ts
-export async function logInteraction(data: {
-  itemId: string;
-  itemType: "event" | "organization";
-  interactionType: "view" | "click" | "rsvp" | "save" | "share" | "hide";
-  metadata?: Record<string, unknown>;
-}): Promise<void>
-```
-
-Non-blocking — fire-and-forget. Failures are silently dropped (logging should never break the UX).
-
-## Frontend Integration Points
-
-| Component | Interaction | Trigger |
-|-----------|------------|---------|
-| `EventCard` | view | IntersectionObserver, 1s threshold |
-| `EventCard` | click | Link click to `/events/[id]` |
-| `EventCard` | save | `onSaveToggle` handler |
-| `EventCard` | rsvp | `onRsvpToggle` handler |
-| `EventCard` | share | `onShare` handler |
-| `EventCard` | hide | New dismiss button (P1) |
-| `ExploreClient` | click | Source context = "feed" |
-| `MapClient` | click | Source context = "map" |
-| Event detail page | dwell | Mount/unmount timer (P2) |
-
-## Schema
-
-See design.md for full `interactions` table DDL.
-
-Indexes: `user_id`, `item_id`, `created_at` for efficient aggregation queries.
diff --git a/openspec/changes/phase-8-recommendations/tasks.md b/openspec/changes/phase-8-recommendations/tasks.md
deleted file mode 100644
index 4b01796..0000000
--- a/openspec/changes/phase-8-recommendations/tasks.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Tasks — Phase 8: ML Recommendation System
-
-## Phase 1: Interaction Logging (Week 1)
-- [ ] Add `interactions` and `user_preference_vectors` tables to schema
-- [ ] Run migration (`db:push`)
-- [ ] Create `logInteraction` server action in `actions/interactions.ts`
-- [ ] Wire `rsvp`, `save`, `share` interactions in EventCard toggle handlers
-- [ ] Wire `click` interaction on event card link / expand icon
-- [ ] Add IntersectionObserver to EventCard for `view` tracking (1s threshold)
-- [ ] Add `hide`/dismiss button to EventCard
-- [ ] Track `source` metadata (feed, search, map, notification)
-- [ ] Test: verify interactions are logged for all event types
-
-## Phase 2: Enhanced SQL Scoring (Week 2)
-- [ ] Create `aggregate.py` job in FastAPI to compute tag weights
-- [ ] Add cron trigger for nightly aggregation (2 AM)
-- [ ] Modify `getFeedEvents()` to use `tag_weights` from `user_preference_vectors`
-- [ ] Add popularity score from aggregated view counts
-- [ ] Add org affinity score (follows + past interactions)
-- [ ] Implement diversity constraint (max 3 per org in top 20)
-- [ ] Upgrade `getSimilarEvents()` with co-RSVP similarity
-- [ ] Test: compare feed quality before/after with seeded data
-
-## Phase 3: Collaborative Filtering Engine (Weeks 3-4)
-- [ ] Install `implicit`, `scipy`, `numpy` in FastAPI
-- [ ] Build `train.py`: interaction matrix construction, ALS training, vector export
-- [ ] Build `routers/recommendations.py`: `/feed`, `/similar`, `/users` endpoints
-- [ ] Implement cold-start logic for new users (< 10 interactions)
-- [ ] Implement cold-start logic for new events (< 5 interactions)
-- [ ] Add hybrid scoring function (0.4 CF + 0.25 content + 0.15 pop + 0.1 time + 0.1 ctx)
-- [ ] Integrate Next.js `getFeedEvents()` with FastAPI call + SQL fallback
-- [ ] Add `RECOMMENDATION_API_URL` env var
-- [ ] Set up nightly cron for training (3 AM)
-- [ ] Test: end-to-end recommendation flow with seeded interactions
-
-## Phase 4: Evaluation & Privacy (Week 4, parallel with Phase 3)
-- [ ] Add `personalization_enabled` column to users table
-- [ ] Implement A/B testing middleware (cookie-based split)
-- [ ] Log A/B variant in interaction metadata
-- [ ] Add evaluation metrics to training pipeline (Precision@10, NDCG@10)
-- [ ] Build recommendation controls in Settings (toggle, reset, info)
-- [ ] Implement `resetRecommendations()` server action
-- [ ] Implement `togglePersonalization()` server action
-- [ ] Add data retention cleanup job (delete interactions > 6 months)
-- [ ] Add "How recommendations work" info section
-- [ ] Test: A/B variant assignment, metric computation, user controls
diff --git a/openspec/config.yaml b/openspec/config.yaml
deleted file mode 100644
index 392946c..0000000
--- a/openspec/config.yaml
+++ /dev/null
@@ -1,20 +0,0 @@
-schema: spec-driven
-
-# Project context (optional)
-# This is shown to AI when creating artifacts.
-# Add your tech stack, conventions, style guides, domain knowledge, etc.
-# Example:
-#   context: |
-#     Tech stack: TypeScript, React, Node.js
-#     We use conventional commits
-#     Domain: e-commerce platform
-
-# Per-artifact rules (optional)
-# Add custom rules for specific artifacts.
-# Example:
-#   rules:
-#     proposal:
-#       - Keep proposals under 500 words
-#       - Always include a "Non-goals" section
-#     tasks:
-#       - Break tasks into chunks of max 2 hours