All projects
Active DevelopmentFull StackSep 2025 — present

the-pensive-index

Discovery-first fanfiction search with prompt generation.

A fanfiction discovery platform designed to search existing tagged stories against complex, nuanced criteria before offering to generate a prompt. Tags are hierarchical with conditional branching rather than flat, so a search can express a specific premise instead of a keyword. In progress: the data and admin layers are built, the discovery search is not yet wired up.

Built with

TypeScriptNext.jsSQLite

Highlights

  • ▸In progress. The data model, validation engine and two-tier admin system are built; the discovery search and prompt generation exist as services but are not yet wired to the app.
  • ▸Hierarchical tags with conditional branching express a premise, rather than the flat keyword lists other platforms use.
  • ▸Designed to search what already exists before generating anything, so a reader is not handed a prompt for a story that has already been written.
  • ▸Built for Cloudflare Pages and Workers with a D1 database, KV caching and Durable Object rate limiting; a worker answers at pensive.vkrishna04.me but does not yet serve the app itself.
  • ▸Content is intended to grow through admin-curated submission; a browser extension for submitting stories is drafted but not yet built or published.

From the README

🌟 The Pensieve Index

Discovery-focused fanfiction search platform with intelligent prompt generation

Spec-Kit TypeScript Next.js

🎯 Vision

The Pensieve Index solves a fundamental problem in fanfiction: readers can't find stories that match their specific, nuanced tastes, and writers struggle with detailed prompt generation.

Unlike existing platforms that use basic tags, we provide:

  • 🔍 Discovery-Focused Search: search existing tagged stories with complex criteria before generating new prompts
  • 🌳 Hierarchical Tagging: tropes with conditional branching (e.g., Goblin Inheritance → Black Lordship → After Sirius Death)
  • 🎯 Dual Output: show matching stories AND enhanced prompts with novelty highlights
  • 👥 Community Curation: admin-driven content growth with browser extension for story submission

This is the design, not a description of a finished product. The admin side and the data model are built; the discovery search and prompt generation are not yet wired end to end. See Project Status for what actually runs today.

🚀 Quick Start

Prerequisites

  • Node.js 18+
  • uv for Python package management (spec-kit requirement)
  • Git and your preferred AI coding agent (Claude, Copilot, Cursor, or Gemini)

Development Setup

# Clone the repository
git clone https://github.com/Life-Experimentalist/the-pensive-index.git
cd the-pensive-index

# Install dependencies
npm install

# Set up development database
npm run db:setup

# Start development server
npm run dev

Visit http://localhost:3000 to see the platform in action.

🏗️ Development Workflow

This project follows Spec-Driven Development using the three-command cycle:

# 1. Define feature requirements
/speckit.specify "Add mobile drag-and-drop pathway builder with validation"

# 2. Create technical implementation plan
/speckit.plan "React Native gestures, responsive Tailwind, TypeScript validation"

# 3. Generate ordered implementation tasks
/speckit.tasks

# 4. Execute with TDD: Tests → User Approval → Implementation

-### Core Principles

  • Discovery-Focused: Prioritize existing story discovery over prompt generation
  • Test-First: TDD mandatory (non-negotiable for validation engine)
  • Responsive Design: Desktop drag-and-drop + mobile tap-to-select
  • Community Growth: Admin-curated content with public submission workflow

🏛️ Architecture

Data Hierarchy

Fandom (Harry Potter, Percy Jackson)
├── Tags (angst, fluff, harry/hermione)
│   └── Tag Classes (harry-shipping, hermione-shipping)
└── tropes (Structured Tropes)
    ├── Goblin Inheritance
    │   ├── Black Lordship
    │   │   ├── After Sirius Death
    │   │   │   ├── Black Head of Family
    │   │   │   ├── Slytherin Lordship
    │   │   │   └── Potter Heritage
    │   │   └── Emancipation Route
    │   └── Multiple House Control → Hogwarts Control
    └── Wrong-Boy-Who-Lived

User Journey (intended flow)

  1. Pathway Creation: User builds story criteria using drag-and-drop or tap-to-select
  2. Library Search: System searches existing tagged stories with relevance scoring
  3. Dual Output: Shows matching stories + "Create New Story" prompt with novelty highlights
  4. Story Submission: Community tags stories via browser extension → GitHub issues → Admin review

🛠️ Tech Stack

  • Frontend: Next.js 15 (App Router), React 18, TypeScript 5.x
  • Styling: Tailwind CSS for responsive design
  • Interactions: dnd-kit for drag-and-drop functionality
  • Authentication: Clerk (@clerk/nextjs) with role-based permissions
  • Database: Cloudflare D1 (SQLite) with Drizzle ORM
  • Cache: Cloudflare KV for performance optimization
  • Deployment: Cloudflare Pages + Workers (Edge Functions)
  • Testing: Vitest, React Testing Library, Playwright E2E

📱 User Interface

Desktop (Three-Panel Layout)

  • Selection Panel: Fandom selector, tag browsers, trope trees
  • Pathway Builder: Drag-and-drop canvas with visual connections
  • Output Panel: Story results + prompt generation with novelty highlights

Mobile (Responsive Design)

  • Collapsible Panels: Stack vertically with touch-friendly interactions

  • Tap-to-Select: Replace drag-and-drop with intuitive tap selection

  • Simplified Validation: Same engine, streamlined conflict resolution

  • Desktop: Full three-panel drag-and-drop interface

  • Mobile: Tap-to-select with collapsible panels

  • Performance: the <200ms validation / <500ms search / 60fps interaction figures are design targets set in the project constitution, not measured results.

👥 User Roles

Admin Hierarchy

  • ProjectAdmin: Global access - manage all fandoms, assign admin roles, system-wide settings
  • FandomAdmin: Scoped access - manage content within specific assigned fandoms only

Built:

  • 🔐 Role-Based Access Control (RBAC) with permission validation
  • 📧 Admin Invitation System (src/lib/admin/services/InvitationService.ts)
  • 📊 Audit Logging (src/lib/admin/services/AuditLogService.ts) with an admin viewer
  • 👥 User & fandom management interfaces under app/admin/

Not yet backed by real data: the analytics, rule-templates and validation-rules pages under app/admin/ still render hardcoded mock arrays, and app/api/admin/dashboard/stats/route.ts returns hardcoded zeros.

Community Features

  • Story Submission: Public form for submitting story URLs with manual tagging
  • Browser Extension: Auto-fills GitHub issues with story details and suggested pathways
  • Admin Review: Manual verification and database addition through admin console

🔧 Development Workflow

This project uses Spec-Kit for structured development:

# Create a new feature
/speckit.specify "Add validation engine for trope conflicts"

# Plan implementation
/speckit.plan "TypeScript, React, dnd-kit integration"

# Generate tasks
/speckit.tasks

# Execute development tasks
# Follow TDD: Tests → Implementation → Validation

🏁 Getting Started

Prerequisites

  • Node.js 18+
  • PowerShell (Windows) or compatible shell
  • Git

Initial Setup

  1. Clone the repository

    git clone https://github.com/Life-Experimentalist/the-pensive-index.git
    cd the-pensive-index
    
  2. Install dependencies

    npm install
    
  3. Set up environment

    cp .env.example .env.local
    # Edit .env.local with your configuration
    
  4. Initialize database

    npm run db:setup
    
  5. Run development server

    npm run dev
    

Development Commands

# Development
npm run dev              # Start development server
npm run build            # Build for production + docs
npm run build:nextjs     # Build Next.js only
npm run lint             # Run ESLint
npm run type-check       # Run TypeScript checks

# Testing
npm run test             # Run all tests
npm run test:watch       # Run tests in watch mode
npm run test:e2e         # Run Playwright E2E tests
npm run test:coverage    # Generate coverage reports

# Database (Local Development)
npm run db:setup         # Initialize local SQLite database
npm run db:migrate       # Run database migrations
npm run db:seed          # Seed with sample data

# Cloudflare Deployment
npm run deploy:preview   # Deploy a Cloudflare preview build
npm run dev:worker       # Test worker locally
npm run preview:worker   # Preview worker deployment
wrangler deploy          # Full deployment (Pages + Worker)

# D1 Database (Production)
wrangler d1 migrations apply pensive-index --remote
wrangler d1 execute pensive-index --command="SELECT * FROM fandoms"

# KV Cache Management
wrangler kv:key list --binding=CACHE
wrangler kv:key put --binding=CACHE <key> <value>

Deployment

Deployment is configured in wrangler.toml: Cloudflare Pages + Workers, the pensive-index D1 database, and the CACHE KV namespace.

📋 Project Status

In progress. The lists below describe what is wired end to end today, not what is planned.

Working

  • Spec-driven development framework (.specify/) and repository scaffolding
  • Core data models and migrations — fandoms, tags, tag classes, plot blocks, validation rules (src/lib/database/models/, migrations/)
  • Validation engine — conflict, dependency and circular-reference checks (src/lib/validation/)
  • Two-tier admin roles (ProjectAdmin / FandomAdmin) with role-based access control
  • Admin invitation system and audit logging, with admin UIs for both
  • User & fandom management interfaces
  • Caching (Cloudflare KV + in-memory LRU), rate limiting (Durable Objects), error logging and resource-usage monitoring (src/lib/cache/, src/lib/monitoring/)

Partially built — not finished

  • Story search and discovery. StorySearchService and RelevanceScoreService (src/lib/services/) implement the relevance algorithm, but no API route or page calls them. The routes the UI does call are stubs: app/api/search/stories/route.ts is marked a placeholder implementation, app/api/stories/search/route.ts carries open TODOs for full-text search, tag/trope filtering and relevance scoring, and StoryModel.search() returns an empty array with its body commented out pending a Drizzle ORM fix.
  • Prompt generation. src/lib/services/prompt-generation.ts exists but is not called from a route; its novelty analysis is marked a placeholder, and PathwayModel derives its novelty score with Math.random() rather than by comparing against indexed stories.
  • Drag-and-drop pathway builder. dnd-kit components exist under src/components/drag-drop/ and src/components/pathway/, but no page under app/ mounts them; app/pathway/page.tsx uses its own click-based selection.
  • Admin analytics dashboard. The analytics, rule-templates and validation-rules pages render hardcoded mock arrays, and the dashboard stats endpoint returns hardcoded zeros — the underlying src/lib/analytics/ and src/lib/monitoring/ services are real, but the pages are not reading from them.
  • Browser extension. Source lives in src/extension/, but extension/manifest.json points at built files (service-worker.js, content-script.js, popup.html, icon PNGs) that are not in the repository, and no npm script produces them.

Not started

  • Story corpus. migrations/0002_seed-data.sql seeds fandoms, tag classes, tags and plot blocks. It seeds no stories, so there is nothing indexed to search yet.

🤝 Contributing

  1. Feature Development: Use the /speckit.specify workflow for new features
  2. Follow TDD: All features must have tests before implementation
  3. Responsive Design: Test on both desktop and mobile
  4. Constitution Compliance: All changes must align with project constitution

📚 Documentation

📄 License

This project is licensed under the MIT License.

🔗 Links


Built with ❤️ by the Life Experimentalists team


specs

You're absolutely right! Let's get the core functionality working first before adding crossover complexity. Here's the proper sequence:

Corrected Development Sequence

Phase 1: Core Admin System (Spec 004 - Simplified)

/speckit.specify "Build a hierarchical admin system with Project Admins who can create fandoms and assign Fandom Admins, plus Fandom Admins who manage their specific fandom content. Project Admins have global permissions to create/edit fandoms, assign admin roles, and access all validation rules. Fandom Admins can only manage tags, tropes, validation rules, and story submissions for their assigned fandoms. Include role-based access control, admin invitation system, and audit logging for all admin actions. Focus on single-fandom management first."

Phase 2: Fandom Content Management (Spec 005 - Simplified)

/speckit.specify "Create a modular fandom creation system where Project Admins can add new fandoms with custom taxonomies, and Fandom Admins can populate them with tags, tropes, characters, and validation rules. Support fandom templates for common genres, bulk import/export of fandom content, and hierarchical content organization. Include content approval workflows, version control for fandom data, and automated content validation to ensure data integrity. Single-fandom focus only."
/speckit.plan "Build on existing Next.js 13+ app with TypeScript 5.x. Extend current Drizzle ORM schema with fandom template tables, content item versioning, and approval workflow tables. Create React admin components using existing Tailwind CSS patterns. Implement fandom creation services extending current AdminRoleService architecture. Add API routes following app/api/admin/ structure. Use existing Clerk authentication with ProjectAdmin/FandomAdmin role validation. Implement content validation engine with TypeScript rule definitions. Add bulk import/export with CSV/JSON parsing. Integrate with existing audit logging system for version control. Mobile-responsive admin interfaces using current responsive patterns."
/speckit.tasks
/speckit.implement

Phase 3: Public User Interface (Spec 001)

/speckit.specify "Build the main public-facing story discovery interface that allows anonymous users to browse fandoms, build story pathways using drag-and-drop (desktop) or tap-to-select (mobile), and discover existing stories or generate new story prompts. Implement the discovery-focused approach with relevance scoring, advanced filtering, responsive design, real-time pathway validation, and dual output showing matching stories plus create-new-story prompts with novelty highlights. Single-fandom stories only."
/speckit.clarify
/speckit.plan "Create public-facing Next.js pages with server-side rendering for SEO. Implement drag-and-drop using @dnd-kit/core with TypeScript for desktop pathway building. Add responsive mobile interface using Tailwind CSS breakpoints and touch gestures. Build pathway validation engine with real-time conflict detection using existing validation patterns. Implement story search with SQLite full-text search and relevance scoring algorithms. Create dual-output system showing existing stories plus AI-generated prompts. Use React Server Components for performance with client components for interactivity. Add advanced filtering with URL state management. Implement discovery-focused search prioritizing existing content over prompt generation."
/speckit.checklist
/speckit.tasks
/speckit.analyze
/speckit.implement

Phase 4: Community Features (Spec 002)

/speckit.specify "Implement the community-driven story submission system with browser extension integration, GitHub Issues workflow, and moderation queue. Users can submit stories via browser extension from AO3/FFN/Youtube(Audio books which are youtube long videos)/Wattpat and make it modular such that new websites support can be easily added with as simple as adding a single file, admins review submissions through GitHub Issues, and approved stories automatically integrate into the database. Include submission validation, duplicate detection, tag suggestion AI, automated quality scoring, and community feedback mechanisms."
/speckit.clarify
/speckit.plan "Develop browser extension using Manifest V3 with TypeScript targeting Chrome/Edge/Brave/Firefox. Make the websites support modular so that new websites support is easily added as simple as adding a single new file. Create GitHub API integration using Octokit for automated issue creation. Build story submission API routes with validation using existing admin patterns. Implement moderation queue as admin interface extension. Add duplicate detection using fuzzy string matching and URL normalization. Create tag suggestion system using existing fandom taxonomies. Build automated quality scoring with configurable metrics. Use existing audit logging for submission tracking. Integrate email notifications using existing admin invitation email system. Add community feedback interfaces with simple voting mechanisms."
/speckit.checklist
/speckit.tasks
/speckit.analyze
/speckit.implement

Phase 5: Performance & Polish (Spec 003)

/speckit.specify "Optimize the platform for production scale with caching strategies, database indexing, API rate limiting, and CDN integration. Implement search result caching, validation rule caching, story metadata caching, and real-time invalidation. Add performance monitoring, analytics tracking, error reporting, and automated scaling for high-traffic scenarios."
/speckit.clarify
/speckit.plan "Implement Redis caching layer for Cloudflare deployment with edge caching strategies. Add database indexing optimization for SQLite with query performance monitoring. Create API rate limiting using Cloudflare Workers with Redis state. Build CDN integration for static assets with cache invalidation. Implement search result caching with TTL-based invalidation. Add validation rule caching with dependency-based cache busting. Create real-time performance monitoring using Cloudflare Analytics. Build error reporting system with structured logging. Add automated scaling configuration for Cloudflare Pages. Implement comprehensive monitoring dashboard using existing admin interface patterns. Most important make it such that it remains free even if it is a bit slower"
/speckit.checklist
/speckit.tasks
/speckit.analyze
/speckit.implement

Phase 6: Crossover Support (Spec 004)

/speckit.specify "Integrate the pathway with the data in the admin dashboard and redo the ui of the pathways page and integrate and make it look like the admin dashboard and finally i want you to have a drag adn drop of tags and tropes(tropes) to create a story and the tags adn tropes will have to pass a successful validation before being added to the pathway, and next i want you to have a library to search for stories in the library, and also add a search for existing pathways and make sure that the extensions and such are working and integrated with the main platform. I want this to be done and polished perfectly and make it ready for the production deployment. In the admin dashboard now use the real data from the cloudflare d1 database and make sure that the admin dashboard is mobile responsive and it using real data not mock."
/speckit.clarify
/speckit.plan "Build on existing Next.js 14+ app with TypeScript 5.x. Implement pathway builder using @dnd-kit with real-time validation engine. Create story and pathway search with Cloudflare D1 full-text search. Replace all admin dashboard mock data with Cloudflare D1 queries. Ensure mobile responsiveness with Tailwind CSS. Integrate browser extension with GitHub Issues workflow. Use consistent design system across all pages. Redo the ui of the pathways, add interactive drag and drop of tags and tropes(tropes) to create a story, integrate the pathway with the data in the admin dashboard, implement validation engine for pathway items, build story library search with relevance scoring, add existing pathway search with filtering, ensure browser extension integration with main platform, make all interfaces mobile responsive using Tailwind CSS, optimize performance for smooth interactions, conduct end-to-end testing with Playwright, deploy to Cloudflare Pages with environment configuration. Make sure to keep it as free as possible. And in the admin dashboard use the real data from the cloudflare d1 and remove all the mock data in all the admin pages and use real data"
/speckit.checklist
/speckit.tasks
/speckit.analyze
/speckit.implement

Phase 6: Crossover Support (Spec 005)

/speckit.specify "Extend the platform with crossover fanfiction support, allowing stories that combine multiple fandoms. Add crossover relationship management, cross-fandom validation rules, shared concept mappings, and crossover-specific pathway building. Include crossover templates, conflict resolution systems, and enhanced search for crossover content."
/speckit.clarify
/speckit.plan "Extend existing database schema with crossover relationship tables maintaining referential integrity. Build crossover pathway builder extending current dnd-kit implementation with multi-fandom selection. Create cross-fandom validation engine with conflict resolution algorithms. Implement shared concept mapping system with TypeScript type definitions. Add crossover template system extending existing fandom templates. Build crossover-specific search with multi-fandom relevance scoring. Create conflict resolution UI using existing validation conflict patterns. Extend API routes to handle multi-fandom operations. Add crossover-specific admin interfaces building on existing admin patterns. Implement enhanced search with crossover relationship weighting."
/speckit.checklist
/speckit.tasks
/speckit.analyze
/speckit.implement

Phase 7: Production Ready (Spec 006 - Final)

/speckit.specify "Finalize the platform for production deployment with end-to-end testing, security hardening, SEO optimization, and user documentation. Implement CI/CD pipelines, backup strategies, and disaster recovery plans.
complete all the parts like the landing page make it more suitable for this and complete the drag and drop feature for creating the pathways and search for existing pathways and make sure that the extensions and such are working and integrated with the main platform. I want this to be done and polished perfectly and make it ready for the production deployment.
"
/speckit.clarify
/speckit.plan "Set up GitHub Actions CI/CD pipelines for automated testing and deployment. Implement end-to-end testing with Playwright covering all user flows. Add security hardening with OWASP best practices and regular vulnerability scanning. Optimize SEO with metadata management and server-side rendering strategies. Create comprehensive user documentation using Docusaurus. Develop backup strategies with automated database dumps and offsite storage. Build disaster recovery plans with failover procedures. Implement monitoring alerts for critical system metrics. Make sure that all the pages are workign properly and the landing page is attractive and such. Make sure that the drag and drop feature is working perfectly and the search for existing pathways is working perfectly. Make sure that the extensions are working properly and integrated with the main platform. Make sure that everything is polished and production ready."
/speckit.checklist
/speckit.tasks
/speckit.analyze
/speckit.implement

╭─────────────────────────────────────────────────────────────────────────────────────── Enhancement Commands ───────────────────────────────────────────────────────────────────────────────────────╮ │ │ │ Optional commands that you can use for your specs (improve quality & confidence) │ │ │ │ ○ /speckit.clarify (optional) - Ask structured questions to de-risk ambiguous areas before planning (run before /speckit.plan if used) │ │ ○ /speckit.analyze (optional) - Cross-artifact consistency & alignment report (after /speckit.tasks, before /speckit.implement) │ │ ○ /speckit.checklist (optional) - Generate quality checklists to validate requirements completeness, clarity, and consistency (after /speckit.plan) │ │ │ ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

PS V:\Code\ProjectCode\the-pensive-index>

Why This Sequence Makes Sense:

Phase 1-2: Admin Foundation

  • Get basic admin roles working
  • Create/manage fandoms
  • Add tags, tropes, validation rules
  • Test with 1-2 fandoms (Harry Potter, Percy Jackson)

Phase 3: User Interface

  • Build the public story discovery interface
  • Pathway builder (drag-and-drop)
  • Search and filtering
  • Test with real users on single fandoms

Phase 4: Community

  • Story submission workflow
  • Moderation tools
  • Grow content organically

Phase 5: Production Ready

  • Performance optimization
  • Monitoring and analytics
  • Handle real traffic

Phase 6: Advanced Features

  • Add crossover support once core is solid
  • Complex feature on stable foundation

Immediate Benefits:

  1. Working System Faster: You'll have a usable platform after Phase 3
  2. User Feedback: Real users can test single-fandom functionality
  3. Proven Architecture: Crossovers build on tested foundation
  4. Reduced Complexity: Easier to debug without crossover interactions
  5. Progressive Enhancement: Each phase adds value

Current Focus:

Start with Spec 004 (basic admin system) and get:

  • Project Admin dashboard working
  • Fandom creation
  • Basic role management
  • Simple tag/trope management

Then move to Spec 006 (user interface) to get:

  • Public story discovery
  • Pathway building
  • Search functionality

This gives you a Minimum Viable Product that users can actually use and provide feedback on, before adding the complexity of crossover management.

Should we proceed with the simplified Spec 004 first?


specs

You're absolutely right! Let's get the core functionality working first before adding crossover complexity. Here's the proper sequence:

Corrected Development Sequence

Phase 1: Core Admin System (Spec 004 - Simplified)

/speckit.specify "Build a hierarchical admin system with Project Admins who can create fandoms and assign Fandom Admins, plus Fandom Admins who manage their specific fandom content. Project Admins have global permissions to create/edit fandoms, assign admin roles, and access all validation rules. Fandom Admins can only manage tags, tropes, validation rules, and story submissions for their assigned fandoms. Include role-based access control, admin invitation system, and audit logging for all admin actions. Focus on single-fandom management first."

Phase 2: Fandom Content Management (Spec 005 - Simplified)

/speckit.specify "Create a modular fandom creation system where Project Admins can add new fandoms with custom taxonomies, and Fandom Admins can populate them with tags, tropes, characters, and validation rules. Support fandom templates for common genres, bulk import/export of fandom content, and hierarchical content organization. Include content approval workflows, version control for fandom data, and automated content validation to ensure data integrity. Single-fandom focus only."

Phase 3: Public User Interface (Spec 006)

/speckit.specify "Build the main public-facing story discovery interface that allows anonymous users to browse fandoms, build story pathways using drag-and-drop (desktop) or tap-to-select (mobile), and discover existing stories or generate new story prompts. Implement a discovery-focused approach with relevance scoring, advanced filtering, responsive design, real-time pathway validation, and dual output showing matching stories plus create-new-story prompts with novelty highlights. Single-fandom stories only."

Phase 4: Community Features (Spec 007)

/speckit.specify "Implement the community-driven story submission system with browser extension integration, GitHub Issues workflow, and moderation queue. Users can submit stories via browser extension from AO3/FFN, admins review submissions through GitHub Issues, and approved stories automatically integrate into the database. Include submission validation, duplicate detection, tag suggestion AI, automated quality scoring, and community feedback mechanisms."

Phase 5: Performance & Polish (Spec 008)

/speckit.specify "Optimize the platform for production scale with caching strategies, database indexing, API rate limiting, and CDN integration. Implement search result caching, validation rule caching, story metadata caching, and real-time invalidation. Add performance monitoring, analytics tracking, error reporting, and automated scaling for high-traffic scenarios."

Phase 6: Crossover Support (Spec 009 - Future)

/speckit.specify "Extend the platform with crossover fanfiction support, allowing stories that combine multiple fandoms. Add crossover relationship management, cross-fandom validation rules, shared concept mappings, and crossover-specific pathway building. Include crossover templates, conflict resolution systems, and enhanced search for crossover content."

Why This Sequence Makes Sense:

Phase 1-2: Admin Foundation

  • Get basic admin roles working
  • Create/manage fandoms
  • Add tags, tropes, validation rules
  • Test with 1-2 fandoms (Harry Potter, Percy Jackson)

Phase 3: User Interface

  • Build the public story discovery interface
  • Pathway builder (drag-and-drop)
  • Search and filtering
  • Test with real users on single fandoms

Phase 4: Community

  • Story submission workflow
  • Moderation tools
  • Grow content organically

Phase 5: Production Ready

  • Performance optimization
  • Monitoring and analytics
  • Handle real traffic

Phase 6: Advanced Features

  • Add crossover support once core is solid
  • Complex feature on stable foundation

Immediate Benefits:

  1. Working System Faster: You'll have a usable platform after Phase 3
  2. User Feedback: Real users can test single-fandom functionality
  3. Proven Architecture: Crossovers build on tested foundation
  4. Reduced Complexity: Easier to debug without crossover interactions
  5. Progressive Enhancement: Each phase adds value

Current Focus:

Start with Spec 004 (basic admin system) and get:

  • Project Admin dashboard working
  • Fandom creation
  • Basic role management
  • Simple tag/trope management

Then move to Spec 006 (user interface) to get:

  • Public story discovery
  • Pathway building
  • Search functionality

This gives you a Minimum Viable Product that users can actually use and provide feedback on, before adding the complexity of crossover management.

Should we proceed with the simplified Spec 004 first?

Local Storage Notice

This site uses local storage to cache GitHub data for better performance, and an anonymous visit counter. No personal data is stored or shared.