SaaS

Legal History Hub

warningProblem

"Spanish legislation as a Git repo"

psychologyPotansiyel Çözüm

İspanya'nın yasal mevzuatını, her yasanın bir Markdown dosyası, her reformun ise bir Git commiti olarak saklayan ve yöneten yenilikçi bir SaaS platformu. Kullanıcılar, Git'in versiyonlama ve geçmiş takibi yeteneklerini kullanarak yasalardaki değişiklikleri kolayca izleyebilecek, belirli bir tarihteki yasaların durumunu görebilecek ve reformların tam geçmişini inceleyebilecek.

groupHedef Kitle

Hukuk profesyonelleri (avukatlar, hakimler, akademisyenler), devlet kurumları, politika analistleri, tarihçiler ve yasal düzenlemelerin evrimini anlamak isteyen herkes.

paymentsGelir Modeli

Katmanlı abonelik modeli: Ücretsiz katman (sınırlı yasa erişimi, temel geçmiş), Standart katman (tüm yasalara erişim, gelişmiş arama, commit geçmişi), Profesyonel katman (API erişimi, karşılaştırma araçları, team özellikleri). Kurumsal lisanslamalar.

Aksiyon Planı

Yasaların Markdown formatında görüntülenmesi ve Git reposu olarak sunulması.

Her yasa reformunun ayrı bir Git commiti olarak kaydedilmesi ve commit geçmişi ile takip edilebilmesi.

Belirli bir yasama dönemi veya tarih aralığı için filtreleme ve arama fonksiyonu.

Yasalardaki değişiklikleri görselleştiren basit bir karşılaştırma arayüzü.

Pazar Analizi

8.7Puan

Kaynak: Hacker Newsopen_in_new

AI Prompt

# AI Master Prompt for Legal History Hub MVP

## 1. PROJECT OVERVIEW

**Project Name:** Legal History Hub

**Value Proposition:** Legal History Hub transforms Spanish legislation into a dynamic, version-controlled repository, akin to a Git repository. It allows legal professionals, researchers, and policymakers to effortlessly track the evolution of laws, understand the impact of reforms, and access historical versions of any Spanish law with unprecedented ease and transparency. By leveraging Git's powerful version control system, we solve the problem of fragmented, difficult-to-track legal histories, offering a single source of truth for legislative changes.

**Problem Solved:** Traditional legal archives are often static, making it challenging to trace the historical development of specific laws or understand the precise impact of legislative reforms over time. Legal History Hub addresses this by treating each law as a file and each reform as a commit, providing a clear, auditable, and accessible historical log.

**Core Value:** Transparency, traceability, and accessibility of legislative history.

## 2. TECH STACK

*   **Frontend:** React (Next.js App Router)
*   **Styling:** Tailwind CSS
*   **ORM:** Drizzle ORM (PostgreSQL compatibility)
*   **Database:** PostgreSQL
*   **Authentication:** NextAuth.js (Credentials Provider and potentially OAuth for Google/GitHub)
*   **UI Library:** shadcn/ui
*   **State Management:** React Context API / Zustand (for global state if needed)
*   **Data Fetching:** Server Actions, Fetch API (for API routes)
*   **Deployment:** Vercel (recommended)
*   **Other:** `zod` for validation, `react-hook-form` for forms, `date-fns` for date manipulation.

## 3. DATABASE SCHEMA

We will use PostgreSQL with Drizzle ORM.

**Tables:**

1.  **`users`**
    *   `id` (uuid, primary key)
    *   `name` (text)
    *   `email` (text, unique)
    *   `emailVerified` (timestamp)
    *   `image` (text, optional)
    *   `createdAt` (timestamp, default now())
    *   `updatedAt` (timestamp, default now())

2.  **`accounts`** (for NextAuth.js)
    *   `id` (bigint, primary key, auto_increment)
    *   `userId` (uuid, foreign key to `users.id`)
    *   `type` (text)
    *   `provider` (text)
    *   `providerAccountId` (text)
    *   `refresh_token` (text, optional)
    *   `access_token` (text, optional)
    *   `expires_at` (bigint, optional)
    *   `token_type` (text, optional)
    *   `scope` (text, optional)
    *   `id_token` (text, optional)
    *   `session_state` (text, optional)

3.  **`sessions`** (for NextAuth.js)
    *   `id` (bigint, primary key, auto_increment)
    *   `sessionToken` (text, unique)
    *   `userId` (uuid, foreign key to `users.id`)
    *   `expires` (timestamp)

4.  **`verificationTokens`** (for NextAuth.js)
    *   `identifier` (text)
    *   `token` (text)
    *   `expires` (timestamp)

5.  **`laws`**
    *   `id` (uuid, primary key, default gen_random_uuid())
    *   `title` (text, not null)
    *   `identifier` (text, unique, not null) - e.g., "BOE-A-1978-31229"
    *   `country` (varchar(2), not null, default 'es')
    *   `category` (text, not null) - e.g., "constitution", "penal_code", "labor_law"
    *   `publicationDate` (date, not null)
    *   `latestUpdate` (date, not null)
    *   `status` (text, not null, default 'vigente') - e.g., "vigente", "derogado"
    *   `sourceUrl` (text, optional)
    *   `latestVersionContent` (text, not null) - Stores the latest version of the law content in Markdown.
    *   `createdAt` (timestamp, default now())
    *   `updatedAt` (timestamp, default now())

6.  **`lawVersions`** (Represents historical states of a law, akin to commits)
    *   `id` (uuid, primary key, default gen_random_uuid())
    *   `lawId` (uuid, foreign key to `laws.id`, not null)
    *   `commitHash` (text, unique, not null) - Unique identifier for this version, mimicking a Git commit hash.
    *   `commitMessage` (text, not null) - Description of the reform.
    *   `authorEmail` (text, not null) - Email of the user/system performing the update.
    *   `commitDate` (timestamp, not null) - Official publication date of the reform.
    *   `content` (text, not null) - The full Markdown content of the law at this version.
    *   `previousVersionCommitHash` (text, optional, foreign key to `lawVersions.commitHash`)
    *   `createdAt` (timestamp, default now())

**Relations:**
*   One `User` can have many `Accounts` and `Sessions`.
*   One `Law` can have many `LawVersions`.

## 4. CORE FEATURES & USER FLOW

**A. User Authentication**

*   **Flow:**
    1.  User lands on the homepage.
    2.  Clicks "Sign In" or "Sign Up".
    3.  Presented with email/password form and optionally Google/GitHub OAuth buttons.
    4.  **Sign Up:** User provides email and password. Password is hashed. A verification token is generated and emailed to the user. User clicks the link to verify their email and is logged in.
    5.  **Sign In:** User provides credentials. System verifies the hashed password. If valid and email verified, a session is created.
    6.  **OAuth:** User clicks provider button, is redirected to provider, authorizes, and redirected back. Session is created or linked to existing user.
    7.  Protected routes redirect to sign-in page if not authenticated.

*   **Edge Cases:** Invalid credentials, email already in use, password reset flow (future), session expiration.

**B. Law Browsing and Viewing**

*   **Flow:**
    1.  Authenticated user navigates to the "Laws" page.
    2.  A list/table of laws is displayed, sortable and filterable by category, country, publication date.
    3.  User clicks on a specific law.
    4.  A detailed view page for the law is shown. This page displays:
        *   Law Title, Identifier, Country, Category, Publication Date, Latest Update, Status.
        *   The full Markdown content of the *latest* version of the law.
        *   A link to the original source (BOE).
        *   A "View History" button.

*   **Edge Cases:** No laws found, empty content, broken source URLs.

**C. Law History (Commit Log)**

*   **Flow:**
    1.  From the Law Detail page, the user clicks "View History".
    2.  User is taken to a dedicated "Law History" page for that specific law.
    3.  This page displays a list of `lawVersions` (commits) sorted by `commitDate` (descending).
    4.  Each list item shows:
        *   Commit Hash (truncated)
        *   Commit Message
        *   Author Email
        *   Commit Date
    5.  User clicks on a specific commit.
    6.  The system displays the *full Markdown content* of the law as it was at that specific `commitHash`.
    7.  A "Compare with" button is available to select another version for comparison.

*   **Edge Cases:** No history available (first version), very long commit messages, large law content.

**D. Law Version Comparison**

*   **Flow:**
    1.  On the "Law History" page, user selects two versions (e.g., using checkboxes or a "Compare with" action).
    2.  User clicks a "Compare Selected" button.
    3.  A "Comparison View" page is displayed, showing the two selected versions side-by-side (or using a diff tool).
    4.  Differences in the Markdown content are highlighted (added lines green, removed lines red).

*   **Edge Cases:** Comparing the same version, comparing with a non-existent version, very large diffs.

## 5. API & DATA FETCHING

*   **Next.js App Router:** Utilize Server Actions for mutations (e.g., adding laws, creating versions during initial seeding) and Server Components for fetching and rendering data wherever possible.
*   **API Routes (for potential external use or complex client-side fetching):**
    *   `GET /api/laws`: Fetch a paginated, filterable list of laws.
    *   `GET /api/laws/[identifier]`: Fetch details and latest content for a specific law.
    *   `GET /api/laws/[identifier]/history`: Fetch the version history for a specific law.
    *   `GET /api/laws/[identifier]/version/[commitHash]`: Fetch the content of a specific historical version.
*   **Data Flow:** Server Components fetch data directly from the database using Drizzle ORM. Client Components can use Server Actions or trigger Server Component re-renders. For dynamic client-side interactions (e.g., filtering without full page reload), use `fetch` in API routes or dedicated client-side fetching libraries if absolutely necessary.
*   **Expected Bodies:** Standard JSON for API routes. Server Actions use direct function calls.

## 6. COMPONENT BREAKDOWN

*   **`app/layout.tsx`**: Root layout (<html>, <body>, global providers, Tailwind CSS setup).
*   **`app/page.tsx`**: Landing Page (Marketing content, value proposition, call to action).
*   **`app/(auth)/signin/page.tsx`**: Sign-in form page.
*   **`app/(auth)/signup/page.tsx`**: Sign-up form page.
*   **`app/(auth)/forgot-password/page.tsx`**: Forgot Password form (future).
*   **`app/(auth)/verify-email/[token]/page.tsx`**: Email verification page.
*   **`app/(app)/dashboard/page.tsx`**: Authenticated User Dashboard (Overview, recent activity - future MVP).
*   **`app/(app)/laws/page.tsx`**: Law Listing Page.
    *   **Components:** `LawTable` (displays laws, includes sorting/filtering controls), `SearchBar`, `FilterDropdowns`.
*   **`app/(app)/laws/[identifier]/page.tsx`**: Law Detail Page.
    *   **Components:** `LawHeader` (title, metadata), `MarkdownDisplay` (renders law content), `HistoryButton`, `SourceLink`.
*   **`app/(app)/laws/[identifier]/history/page.tsx`**: Law History (Commit Log) Page.
    *   **Components:** `CommitList` (displays list of versions), `CommitListItem`, `ViewButton`, `CompareButton`.
*   **`app/(app)/laws/compare/[lawId]/[commitHash1]/[commitHash2]/page.tsx`**: Version Comparison Page.
    *   **Components:** `DiffViewer` (displays side-by-side or inline diff).
*   **`components/ui/`**: Re-usable UI components from shadcn/ui (Button, Input, Card, Table, Dialog, etc.).
*   **`components/layout/`**: `Navbar`, `Footer`, `Sidebar` (if applicable).
*   **`components/auth/`**: `SignInForm`, `SignUpForm`.
*   **`lib/`**: Utility functions, database client setup (Drizzle).
*   **`server/actions/`**: Server Actions for auth, data mutations.
*   **`styles/`**: Global CSS, Tailwind configuration.

**State Management:**
*   Global auth state via NextAuth.js session context.
*   Local component state for forms, UI interactions.
*   Server Components fetch and manage their own data.

## 7. UI/UX DESIGN & VISUAL IDENTITY

*   **Design Style:** Minimalist Clean with a touch of Professionalism.
*   **Color Palette:**
    *   Primary: `#0077cc` (A professional, trustworthy blue)
    *   Secondary: `#66ccff` (Lighter blue for accents)
    *   Background: `#f8f9fa` (Very light gray)
    *   Surface/Card Background: `#ffffff` (Pure white)
    *   Text (Primary): `#212529` (Dark gray)
    *   Text (Secondary): `#6c757d` (Medium gray)
    *   Success: `#28a745` (Green)
    *   Warning: `#ffc107` (Yellow)
    *   Error: `#dc3545` (Red)
*   **Typography:**
    *   Headings: Inter (or a similar modern sans-serif, e.g., Poppins)
    *   Body Text: Inter (or Open Sans)
*   **Layout:** Use a consistent grid system (e.g., 12-column responsive grid). Max-width container for content on larger screens. Clear separation of sections.
*   **UI Elements:** Utilize shadcn/ui components for consistency. Focus on clear calls to action, intuitive navigation, and easily scannable information.
*   **Responsive Rules:** Mobile-first approach. Ensure excellent usability on small screens, scaling gracefully to tablets and desktops. Navigation should adapt (e.g., hamburger menu on mobile).

## 8. SAMPLE/MOCK DATA

**Mock Law Data:**

1.  **Law:**
    *   `title`: "Constitución Española"
    *   `identifier`: "BOE-A-1978-31229"
    *   `category`: "constitucion"
    *   `publicationDate`: "1978-12-29"
    *   `latestUpdate`: "2024-02-17"
    *   `status`: "vigente"
    *   `latestVersionContent`: "---\ntitulo: \"Constitución Española\"
identificador: \"BOE-A-1978-31229\"
...
---\n\n**Artículo 1.** Los españoles son iguales ante la ley, sin que pueda prevalecer discriminación alguna por razón de nacimiento, raza, sexo, religión, opinión o cualquier otra condición o circunstancia personal o social."

2.  **Law:**
    *   `title`: "Código Penal"
    *   `identifier`: "BOE-A-1995-25444"
    *   `category`: "penal_code"
    *   `publicationDate`: "1995-11-23"
    *   `latestUpdate`: "2023-01-01"
    *   `status`: "vigente"
    *   `latestVersionContent`: "---\ntitulo: \"Código Penal\"
...
---\n\n**Artículo 1.**"