diff --git a/docs/_archive/v1.0/architecture.md b/docs/_archive/v1.0/architecture.md
new file mode 100644
index 0000000..4ae5036
--- /dev/null
+++ b/docs/_archive/v1.0/architecture.md
@@ -0,0 +1,569 @@
+# **SYSTEM Fullstack Architecture Document**
+
+## 1. Template and Framework Selection
+
+*   **Framework:** The project is built on **Nuxt 4**, as specified in the provided `repomix-output.xml`.
+*   **UI Library:** The core component library is **PrimeVue**, with the **Aura** theme preset. This choice is confirmed in `nuxt.config.ts`.
+*   **Styling:** A hybrid approach using **Tailwind CSS** for utility-first styling and **SCSS** for global styles, variables, and complex component styling is adopted.
+*   **Starter Template:** The project is based on the custom template provided by the user. No external starter templates are used. This gives us full control but requires us to define the structure meticulously.
+
+### Change Log
+
+| Date | Version | Description | Author |
+| :--- | :--- | :--- | :--- |
+| 2025-08-31 | 1.0 | Initial Frontend Architecture draft | Architect (Winston) |
+
+## 2. Frontend Tech Stack
+
+This table reflects the choices made in the PRD and the user's template, solidifying the frontend technology stack.
+
+| Category | Technology | Version | Purpose & Rationale |
+| :--- | :--- | :--- | :--- |
+| Framework | **Nuxt** | `^4.0.3` | The core application framework, providing SSR, file-based routing, and a robust module ecosystem. |
+| UI Library | **PrimeVue** | `^4.3.7` | The primary component library. Chosen for its rich set of components and powerful theming capabilities. |
+| Theme | **PrimeUI Aura** | `^1.2.3` | The default theme preset for PrimeVue, providing a modern and clean aesthetic out of the box. |
+| Styling | **Tailwind CSS** | `^0.6.1` (primeui) | For utility-first styling, rapid prototyping, and responsive design. |
+| Styling | **SCSS (Sass)** | (via `sass` dev dep) | For structured styling, variables, mixins, and managing global styles and theme overrides. |
+| i18n | **@nuxtjs/i18n**| `10.0.6` | For future-proof internationalization, as required by the PRD. |
+
+---
+
+## 3. Project Structure
+
+Based on the Nuxt 4 documentation and the need to manage SCSS files effectively, the following directory structure will be adopted within the `app/` directory.
+
+```plaintext
+app/
+├── assets/
+│   └── scss/
+│       ├── base/
+│       │   ├── _reset.scss       # Optional: for CSS resets
+│       │   └── _typography.scss  # Base typography styles
+│       ├── components/
+│       │   └── _buttons.scss     # Example: Custom button styles
+│       ├── layout/
+│       │   └── _main.scss        # Main layout styles
+│       ├── themes/
+│       │   └── _aura-overrides.scss # Specific overrides for the Aura theme
+│       ├── utils/
+│       │   ├── _variables.scss   # Global SCSS variables (colors, spacing)
+│       │   └── _mixins.scss      # Global SCSS mixins
+│       └── main.scss             # Main entry file that imports all other SCSS partials
+│
+├── components/
+│   ├── common/
+│   │   └── AppHeader.vue         # Example of a globally used component
+│   └── specific/
+│       └── CellDetailView.vue    # Example of a view-specific component
+│
+├── composables/
+│   ├── useCitizen.ts             # Composable for managing Citizen identity
+│   └── useLedger.ts              # Composable for interacting with The Main Ledger
+│
+├── layouts/
+│   └── default.vue               # The default layout for the application
+│
+├── pages/
+│   ├── index.vue                 # Dashboard / Main View
+│   └── cell/
+│       └── [id].vue              # Cell Detail View (Dynamic Route)
+│
+├── plugins/
+│   └── primevue.ts               # Plugin to register PrimeVue components/services if needed
+│
+└── app.vue                       # Main application entry point
+```
+
+To make this SCSS structure work seamlessly, we will update `nuxt.config.ts` to automatically import our main SCSS file globally.
+
+**`nuxt.config.ts` modification:**
+```typescript
+export default defineNuxtConfig({
+  // ... other configs
+  css: ['~/assets/scss/main.scss'],
+  // ... other configs
+})
+```
+
+**`app/assets/scss/main.scss` content:**
+```scss
+// 1. Utilities (Variables, Mixins)
+@use 'utils/variables';
+@use 'utils/mixins';
+
+// 2. Base Styles
+@use 'base/reset';
+@use 'base/typography';
+
+// 3. Layout Styles
+@use 'layout/main';
+
+// 4. Component Styles
+@use 'components/buttons';
+
+// 5. Theme Overrides
+@use 'themes/aura-overrides';
+```
+
+---
+
+## 4. Component Standards
+
+To ensure consistency and maintainability, all Vue components created in this project must adhere to the following standards.
+
+### Component Template (`.vue` files)
+
+All components should follow the standard Vue 3 `<script setup>` syntax. This is the recommended modern approach by both Vue and Nuxt documentation.
+
+Here is a minimal template for a new component:
+```vue
+<script setup lang="ts">
+// 1. IMPORTS
+// e.g., import { ref } from 'vue';
+// e.g., import Button from 'primevue/button';
+
+// 2. PROPS & EMITS
+// e.g., const props = defineProps<{
+//   citizenId: string;
+// }>();
+// e.g., const emit = defineEmits(['updated']);
+
+// 3. STATE & COMPOSABLES
+// e.g., const count = ref(0);
+// e.g., const { citizen } = useCitizen();
+
+// 4. COMPUTED PROPERTIES & WATCHERS
+// ...
+
+// 5. LIFECYCLE HOOKS
+// ...
+
+// 6. METHODS
+// e.g., function signTransaction() { ... }
+</script>
+
+<template>
+  <!-- 
+    Component template. Use PrimeVue components and Tailwind CSS classes here.
+    e.g., <div class="p-4 border-round-md"> ... </div>
+  -->
+</template>
+
+<style scoped lang="scss">
+/* 
+  Component-specific SCSS goes here.
+  Global variables/mixins are available thanks to nuxt.config.ts.
+  e.g., .my-component { color: var(--primary-color); }
+*/
+</style>
+```
+
+### Naming Conventions
+
+*   **Components:** `PascalCase`. Files should match the component name (e.g., `CellDetailView.vue`).
+*   **Composables:** `camelCase` with a `use` prefix (e.g., `useLedger.ts`).
+*   **SCSS Variables:** `$kebab-case` (e.g., `$primary-accent-color`).
+
+## 5. State Management
+
+*   **Approach:** For the MVP, we will rely primarily on **Nuxt's built-in `useState` composable** for simple, shared, server-side-renderable state. This is the most lightweight and idiomatic approach for Nuxt 4. We will avoid installing a heavy external library like Pinia or Vuex until the application's complexity demonstrably requires it.
+*   **Structure:** Shared state composables will be located in the `app/composables/` directory.
+
+### State Management Template (`app/composables/useSomeState.ts`)
+
+```typescript
+import { useState } from '#app';
+
+// Example: Managing the current Citizen's session info
+interface CitizenSession {
+  name: string;
+  publicKey: string;
+  // NOTE: The private key should NOT be stored in a composable.
+  // It should be managed in a more secure, non-persistent way.
+}
+
+export const useCitizenStore = () => {
+  const citizen = useState<CitizenSession | null>('citizen', () => null);
+
+  const setCitizen = (newCitizen: CitizenSession) => {
+    citizen.value = newCitizen;
+  };
+
+  const clearCitizen = () => {
+    citizen.value = null;
+  };
+
+
+
+  return {
+    citizen,
+    setCitizen,
+    clearCitizen,
+  };
+};
+```
+
+---
+
+## 6. API Integration
+
+Since the project is a monolith where the frontend and backend are served by the same Nuxt instance, we will use the built-in `$fetch` utility for all API calls. This is the recommended, isomorphic way to handle data fetching in Nuxt 4.
+
+### Service Layer Pattern
+
+To keep components clean and organize API logic, we will use a "service layer" pattern. All API calls will be abstracted into functions within files in the `app/services` directory.
+
+**`app/services/cellService.ts` (Example Template)**
+```typescript
+// Using Nuxt's built-in $fetch
+import { $fetch } from 'ofetch';
+
+// Define types for API payloads and responses, ideally imported from a shared location
+interface Cell {
+  id: string;
+  // ... other properties
+}
+
+interface CreateCellPayload {
+  commonGood: string;
+  // ... other properties
+}
+
+const BASE_URL = '/api/cells'; // Internal API endpoint
+
+export const cellService = {
+  /**
+   * Fetches the details for a single Cell.
+   * @param id The ID of the Cell.
+   */
+  async getCellById(id: string): Promise<Cell> {
+    return await $fetch<Cell>(`${BASE_URL}/${id}`);
+  },
+
+  /**
+   * Creates a new Cell.
+   * @param payload The data for the new Cell.
+   */
+  async createCell(payload: CreateCellPayload): Promise<Cell> {
+    return await $fetch<Cell>(BASE_URL, {
+      method: 'POST',
+      body: payload,
+    });
+  },
+
+  // ... other methods like joinAsConsumer, confirmPayment, etc.
+};
+```
+
+## 7. Routing
+
+Routing will be handled by Nuxt's file-based router. All pages will be created as `.vue` files in the `app/pages` directory.
+
+**Route Configuration Example (`app/pages/cell/[id].vue`)**
+```vue
+<script setup lang="ts">
+import { useRoute } from 'vue-router';
+
+const route = useRoute();
+const cellId = route.params.id as string;
+
+// Fetch cell data using the service
+const { data: cell, pending, error } = await useAsyncData(
+  `cell-${cellId}`,
+  () => cellService.getCellById(cellId)
+);
+</script>
+
+<template>
+  <div v-if="pending">Loading...</div>
+  <div v-else-if="error">Error loading Cell: {{ error.message }}</div>
+  <div v-else-if="cell">
+    <h1>{{ cell.commonGood }}</h1>
+    <!-- Display cell details here -->
+  </div>
+</template>
+```
+
+## 8. Testing Requirements
+
+Testing is critical for ensuring the integrity of the system.
+*   **Unit Tests:** We will use **Vitest** for unit testing. Every composable and service function must have unit tests covering its logic.
+*   **Component Tests:** We will use **`@vue/test-utils`** to test individual Vue components. Tests should verify that components render correctly based on props and that they emit events when interacted with.
+*   **Test Location:** All test files will be located alongside the file they are testing, with a `.spec.ts` extension (e.g., `useLedger.spec.ts`).
+
+
+## 1. Introduction
+
+This document outlines the complete fullstack architecture for Project SYSTEM, including the backend systems, frontend implementation, and their integration. It serves as the single source of truth for AI-driven development, ensuring consistency across the entire technology stack. This unified approach combines backend and frontend concerns to streamline development.
+
+### Starter Template or Existing Project
+
+*   **Decision:** The project is based on the custom Nuxt 4 starter template provided by the user. No external templates are used. The architecture will be built upon this existing foundation.
+
+### Change Log
+
+| Date | Version | Description | Author |
+| :--- | :--- | :--- | :--- |
+| 2025-08-31 | 1.0 | Initial Fullstack Architecture draft | Architect (Winston) |
+
+## 2. High Level Architecture
+
+### Technical Summary
+
+Project SYSTEM is a monolithic, self-hosted web application built on the Nuxt 4 framework. The architecture is designed for efficiency and transparency, running on a Raspberry Pi. It features a Vue-based frontend interacting with a PostgreSQL database via Nuxt's server-side API routes. The core of the system is an immutable, event-sourced "Main Ledger" where every action is a cryptographically signed transaction, ensuring data integrity and auditability. Identity management is decentralized, based on public/private key pairs.
+
+### Platform and Infrastructure Choice
+
+*   **Platform:** Self-hosted on a user-provided **Raspberry Pi** (Model 4+).
+*   **Key Services:**
+    *   **Application Server:** **Nuxt 4** running in Node.js mode.
+    *   **Database:** **PostgreSQL**.
+    *   **Containerization:** The entire stack will be managed and deployed via **Docker Compose**. This ensures a consistent and reproducible environment.
+*   **Deployment Host and Regions:** Single host, located within the "Община's" private network.
+
+### Repository Structure
+
+*   **Structure:** **Monorepo**.
+*   **Monorepo Tool:** Not required for this level of simplicity. A single `package.json` at the root will manage all dependencies.
+*   **Package Organization:** A standard Nuxt 4 project structure will be used, as detailed in the Frontend Architecture. Server-side logic will reside within the `server/` directory.
+
+### High Level Architecture Diagram
+
+```mermaid
+graph TD
+    subgraph "Browser"
+        A[Citizen's Browser]
+    end
+
+    subgraph "Raspberry Pi (Docker Compose)"
+        B[Nuxt 4 Server]
+        C[PostgreSQL Database]
+
+        B -- "Serves Frontend" --> A
+        A -- "API Calls ($fetch)" --> B
+        B -- "Reads/Writes" --> C
+    end
+
+    style B fill:#2D3748,stroke:#fff,stroke-width:2px,color:#fff
+    style C fill:#4A5568,stroke:#fff,stroke-width:2px,color:#fff
+```
+
+---
+
+## 3. Tech Stack (Revised)
+
+| Category | Technology | Version | Purpose & Rationale |
+| :--- | :--- | :--- | :--- |
+| **Fullstack Framework**| **Nuxt** | `^4.0.3` | Core framework for both frontend and backend (server routes). |
+| **Database ORM** | **Prisma** | `latest` | Next-generation ORM for type-safe database access and automated migrations. |
+| **Database** | **PostgreSQL** | `latest` | Robust, reliable SQL database managed by Prisma. |
+| **Deployment** | **Docker Compose**| `latest` | For containerizing and managing the application stack. |
+| ... | *(rest of the stack remains the same)* | ... | ... |
+
+## 4. Database Architecture (Revised with Prisma)
+
+The database schema will be defined declaratively using the Prisma schema language in a single source of truth file: `prisma/schema.prisma`. Prisma will be responsible for generating SQL migrations and providing a type-safe client for all database interactions.
+
+### Prisma Schema (`prisma/schema.prisma`)
+
+```prisma
+// This is your Prisma schema file,
+// learn more about it in the docs: https://pris.ly/d/prisma-schema
+
+generator client {
+  provider = "prisma-client-js"
+}
+
+datasource db {
+  provider = "postgresql"
+  url      = env("DATABASE_URL")
+}
+
+// User-friendly metadata associated with a public key.
+model Registry {
+  publicKey   String    @id
+  citizenName String
+  avatarUrl   String?
+  isActive    Boolean   @default(true)
+  createdAt   DateTime  @default(now())
+}
+
+// The core, immutable data model.
+// Once a row is written, it is never updated or deleted.
+model LedgerEntry {
+  id                 BigInt    @id @default(autoincrement())
+  previousHash       String?
+  entryHash          String    @unique
+  citizenPublicKey   String
+  signature          String
+  actionType         String
+  payload            Json? // The actual data for the action, e.g., cell details
+  createdAt          DateTime  @default(now())
+
+  @@index([citizenPublicKey])
+  @@index([payload], name: "idx_ledger_payload_entity") // Example for indexing specific payload keys
+}
+```
+
+### Migrations Workflow
+
+Database migrations will be managed exclusively by Prisma Migrate.
+1.  **Development:** After any change to `schema.prisma`, a new migration will be created and applied using the command:
+    ```bash
+    npx prisma migrate dev --name <descriptive_migration_name>
+    ```
+2.  **Production:** Migrations will be applied during the deployment process using:
+    ```bash
+    npx prisma migrate deploy
+    ```
+This ensures that the database schema is always in sync with the Prisma schema definition.
+
+---
+
+## 5. API Specification & Server Architecture
+
+The application will not expose a public REST или GraphQL API. All communication between the frontend and backend will occur internally via **Nuxt 4 Server Routes**. This approach is secure, performant, and perfectly suited for a monolithic fullstack application.
+
+### Server Directory Structure (`server/`)
+
+The server-side logic will be organized as follows:
+
+```plaintext
+server/
+├── api/
+│   ├── cells/
+│   │   ├── index.post.ts       # Create a new Cell
+│   │   └── [id]/
+│   │       ├── index.get.ts    # Get Cell details
+│   │       └── join.post.ts    # Join a Cell (as consumer/executor)
+│   ├── citizens/
+│   │   ├── index.post.ts       # Create a new Citizen (onboarding)
+│   │   └── invite.get.ts       # Generate an invitation link
+│   └── vault/
+│       ├── index.post.ts       # Create a Vault account
+│       ├── login.post.ts       # Login via Vault
+│       └── recover.post.ts     # Initiate/approve social recovery
+├── middleware/
+│   └── auth.ts                 # Middleware to check Citizen authentication
+└── utils/
+    ├── prisma.ts               # Exports a singleton Prisma Client instance
+    └── crypto.ts               # Cryptographic helper functions
+```
+
+### Core API Endpoints (MVP)
+
+| Endpoint | Method | Description | Request Body | Response |
+| :--- | :--- | :--- | :--- | :--- |
+| `/api/citizens` | `POST` | Creates the first Citizen or a new one via invite. | `{ name, publicKey }` | `Citizen` |
+| `/api/citizens/invite` | `GET` | Generates a single-use invitation link. | (none) | `{ inviteUrl }` |
+| `/api/cells` | `POST` | Creates a new "Cell". | `{ commonGood, executors }` | `LedgerEntry` |
+| `/api/cells/[id]` | `GET` | Retrieves the full state of a "Cell". | (none) | `CellState` |
+| `/api/cells/[id]/join` | `POST` | Joins a "Cell" as Executor or Consumer. | `{ role, item? }` | `LedgerEntry` |
+| `/api/cells/[id]/confirm`| `POST` | Confirms payment from a Consumer. | `{ consumerKey }` | `LedgerEntry` |
+
+### Core Workflow: The Cryptographic Signing Process
+
+This sequence diagram illustrates the fundamental process for every action in the system.
+
+```mermaid
+sequenceDiagram
+    participant Browser as Citizen's Browser
+    participant NuxtServer as Nuxt Server / API
+    participant Prisma
+    participant Ledger as The Main Ledger (DB)
+
+    Browser->>Browser: 1. User performs action (e.g., clicks "Create Cell")
+    Browser->>Browser: 2. Prepare `payload` (e.g., { commonGood: "Суп" })
+    Browser->>Browser: 3. Get `previousHash` from last Ledger entry
+    Browser->>Browser: 4. Create `entryHash` from payload + previousHash
+    Browser->>Browser: 5. Sign `entryHash` with private key to get `signature`
+    Browser->>NuxtServer: 6. POST /api/cells (sends payload, publicKey, signature)
+
+    NuxtServer->>NuxtServer: 7. Receive request
+    NuxtServer->>NuxtServer: 8. Validate signature using sender's `publicKey`
+    alt Signature is Invalid
+        NuxtServer-->>Browser: 9a. Return 401 Unauthorized
+    else Signature is Valid
+        NuxtServer->>Prisma: 9b. Get latest `previousHash` from DB
+        NuxtServer->>NuxtServer: 10. Verify client's `previousHash` matches server's
+        NuxtServer->>Prisma: 11. `prisma.ledgerEntry.create(...)`
+        Prisma->>Ledger: 12. INSERT INTO "LedgerEntry"
+        Ledger-->>Prisma: 13. Return new entry
+        Prisma-->>NuxtServer: 14. Return new entry
+        NuxtServer-->>Browser: 15. Return new LedgerEntry (success)
+    end
+```
+
+---
+
+## 6. Unified Project Structure
+
+This is the final monorepo structure that integrates the frontend (`app/`), backend (`server/`), and database (`prisma/`) components.
+
+```plaintext
+system/
+├── app/                      # Nuxt frontend application
+│   ├── assets/
+│   │   └── scss/
+│   ├── components/
+│   ├── composables/
+│   ├── layouts/
+│   ├── pages/
+│   └── ...
+├── prisma/                   # Prisma ORM configuration
+│   ├── migrations/
+│   │   └── .../migration.sql
+│   └── schema.prisma         # The single source of truth for the database
+├── server/                   # Nuxt server-side logic (API)
+│   ├── api/
+│   │   └── ...
+│   ├── middleware/
+│   └── utils/
+├── types/                    # Shared TypeScript types
+│   ├── citizen.ts
+│   ├── ledger.ts
+│   └── index.ts
+├── docker-compose.yml        # Defines and runs the multi-container stack
+├── Dockerfile                # For building the Nuxt application image
+├── nuxt.config.ts            # Nuxt configuration
+├── package.json
+└── tsconfig.json
+```
+
+## 7. Development Workflow
+
+1.  **Initial Setup:**
+    *   Clone the repository.
+    *   Create a `.env` file with the `DATABASE_URL`.
+    *   Run `docker-compose up -d --build` to start the PostgreSQL container and the Nuxt development server.
+2.  **Schema Changes:**
+    *   Modify `prisma/schema.prisma`.
+    *   Run `npx prisma migrate dev --name <migration-name>` to apply changes to the running database. Prisma Client will be auto-generated.
+3.  **Development:**
+    *   Develop Vue components in the `app/` directory.
+    *   Develop API endpoints in the `server/api/` directory.
+    *   The Nuxt dev server will provide hot-reloading for both frontend and backend changes.
+
+## 8. Deployment Architecture
+
+*   **Strategy:** The application will be deployed as a set of Docker containers orchestrated by `docker-compose`. This simplifies deployment on the target Raspberry Pi.
+*   **Process:**
+    1.  A `Dockerfile` will build the Nuxt application into a production-ready Node.js server.
+    2.  `docker-compose.yml` will define two services:
+        *   `app`: The Nuxt application built from the `Dockerfile`.
+        *   `db`: The official PostgreSQL image, with a persistent volume mounted to store the database data.
+    3.  Deployment consists of pulling the latest code, running `docker-compose up -d --build` on the Raspberry Pi.
+*   **Migrations:** Production migrations will be applied by running `npx prisma migrate deploy` inside the running `app` container or as part of the container's startup command.
+
+## 9. Security & Performance
+
+*   **Security:**
+    *   **Authentication:** Managed via cryptographic signatures. The server is stateless regarding authentication.
+    *   **Authorization:** All API endpoints inside `server/middleware/auth.ts` will verify the incoming signature against the `publicKey` to ensure the action is performed by the legitimate owner of the key.
+    *   **Secrets:** The `DATABASE_URL` will be managed via the `.env` file, which is excluded from version control.
+*   **Performance:**
+    *   The primary performance consideration is the Raspberry Pi environment. The monolithic Nuxt/PostgreSQL stack is chosen for its low resource overhead compared to more complex microservice architectures.
+    *   Database queries will be optimized using indices as defined in the Prisma schema.
+    *   Frontend assets will be optimized by Nuxt's build process.
+
+---
diff --git a/docs/_archive/v1.0/prd.md b/docs/_archive/v1.0/prd.md
new file mode 100644
index 0000000..2d78655
--- /dev/null
+++ b/docs/_archive/v1.0/prd.md
@@ -0,0 +1,255 @@
+## 1. Goals and Background Context
+
+### Goals
+
+Based on our brief, the primary goals for the MVP are:
+*   To establish a fully functional, self-hosted system that replaces informal financial tracking with a trusted, cryptographically secure ledger.
+*   To achieve complete adoption by all members of the initial "Община" (community).
+*   To ensure every transaction is immutable, auditable, and requires the consensus of the participants involved.
+*   To create a system that is not only functional but also engaging and fast for simple, everyday tasks.
+
+### Background Context
+
+The core problem is that the current methods of managing shared domestic finances (like chat groups or spreadsheets) are inefficient, prone to error, and lack transparency. This creates friction and mental overhead for a group of friends living together. Project SYSTEM aims to solve this by providing a single, reliable source of truth that automates calculations, enforces fairness through cryptographic signatures, and introduces a unique, engaging user experience tailored to the community's culture.
+
+### Change Log
+
+| Date | Version | Description | Author |
+| :--- | :--- | :--- | :--- |
+| 2025-08-31 | 1.0 | Initial PRD draft | PM (John) |
+
+---
+
+## 2. Requirements
+
+### Functional
+
+1.  **FR1: System Initialization:** The system must provide an interface for the first user ("Initiator") to create the "Община" and generate their initial cryptographic key pair.
+2.  **FR2: Citizen Onboarding:** The Initiator must be able to generate a unique, single-use invitation link to onboard new "Citizens". The onboarding process must include key pair generation and profile creation in the "Registry".
+3.  **FR3: Optional Key Vault:** During onboarding, a new "Citizen" must have the option to create a login/password account to store their private key in the server-side "Vault".
+4.  **FR4: Immutable Ledger:** Every state-changing action within the system (e.g., creating a Cell, joining, confirming payment) must be recorded as a new, cryptographically signed transaction in "The Main Ledger". The system must not allow direct modification or deletion of past transactions.
+5.  **FR5: Cell Creation:** Any "Citizen" must be able to create a financial "Cell" for a "Common Good", specifying the goal and the required items/costs ("Executor" roles).
+6.  **FR6: Cell Participation:** "Citizens" must be able to join a "Cell" as either an "Executor" (committing to purchase an item) or a "Consumer" (sharing the cost of the "Common Good").
+7.  **FR7: Real-Time Calculation:** The system must automatically and transparently calculate and display the financial obligations between all "Consumers" and "Executors" of a "Cell" as participants join or leave.
+8.  **FR8: Payment Confirmation:** An "Executor" must have the ability to sign a transaction confirming the receipt of payment from a specific "Consumer" for a specific "Cell".
+9.  **FR9: Social Key Recovery:** A "Citizen" who uses the "Vault" and has forgotten their password must be able to initiate a recovery process that requires cryptographic confirmation from a quorum of other "Citizens" (1 confirmation if <=4 members; 2 confirmations if >=5 members).
+
+### Non-Functional
+
+1.  **NFR1: Performance on Embedded Hardware:** The entire system (backend and database) must be optimized to run efficiently on a Raspberry Pi (Model 4 or newer recommended).
+2.  **NFR2: High-Trust Environment Security:** While designed for a trusted, private network, the application must include baseline web security practices (e.g., CSRF protection, secure headers). Direct database access should not be exposed.
+3.  **NFR3: Cryptographic Integrity:** All transactions must be signed using the Ed25519 algorithm or a similarly secure and lightweight standard. The integrity of the ledger's chain (verified by linking transaction hashes) must be maintained.
+4.  **NFR4: Multi-Currency Support:** The system must be able to handle calculations and record transactions in multiple fiat currencies (e.g., UAH, PLN, USD), with the currency specified at the "Cell" or "Plan" level.
+5.  **NFR5: Internationalization (i18n) Readiness:** The frontend architecture must be built to support multiple languages, even if the MVP only includes one language pack.
+6.  **NFR6: Usability:** The user interface for common, simple actions (like creating a quick "Cell") must be low-friction and require a minimal number of steps to encourage daily use.
+
+---
+
+## 3. User Interface Design Goals
+
+### Overall UX Vision
+
+The user experience of SYSTEM should feel like interacting with a reliable, slightly mysterious, but ultimately transparent terminal or government console. The design must build trust by visualizing the cryptographic processes (e.g., showing transaction hashes, signed confirmations) without overwhelming the user. The primary goal is clarity and efficiency: a Citizen should always understand what's happening, what is required of them, and trust the integrity of the data presented. The overall aesthetic should lean into the thematic, "dystopian/communistic" vibe in a subtle, engaging way.
+
+### Key Interaction Paradigms
+
+*   **Low-Friction for Common Tasks:** Creating a simple "Cell" should be achievable in a few clicks. The interface should be fast and responsive.
+*   **Seamless Signing:** The process of signing transactions with the private key should be as unobtrusive as possible, perhaps by "unlocking" a session with the key rather than confirming every single action.
+*   **Visual Trust:** The UI should use visual cues to signify the status of data – e.g., a "finalized" transaction looks solid and permanent, while a "pending" transaction (in "Mushroom Mode") might appear hazy or watermarked.
+
+### Core Screens and Views
+
+For the MVP, the following core screens are necessary:
+*   **Onboarding/Setup Screen:** For the first user to create the "Община" and for new Citizens to join via an invite link.
+*   **Dashboard/Main View:** A central hub showing all active "Cells" and "Plans" requiring the user's attention or participation. It should clearly display the user's current financial state (what they owe, what is owed to them).
+*   **"Cell" Detail View:** A screen showing all information for a single "Cell": the "Common Good", all "Executors" and "Consumers", payment status for each participant, and the transaction history from "The Main Ledger".
+*   **"Cell" Creation Form:** A simple, guided form to create a new "Cell".
+*   **Profile/Keys Management View:** A section where a "Citizen" can view their public key and manage their optional "Vault" account.
+
+### Accessibility: WCAG AA
+
+The application should strive to meet WCAG 2.1 Level AA compliance to ensure it is usable by people with a wide range of disabilities.
+
+### Branding
+
+The branding will be built around the chosen thematic elements of retro-futuristic communism and dystopia. This should be reflected in:
+*   **Terminology:** Using "Citizen," "Cell," "Common Good," "Five-Year Plan" consistently throughout the UI.
+*   **Color Palette:** A limited, functional color palette, perhaps with one striking accent color (e.g., red).
+*   **Typography:** Potentially a monospaced or "terminal-like" font for key data elements to enhance the console feel.
+
+### Target Device and Platforms: Web Responsive
+
+The primary platform is a responsive web application that works seamlessly on both desktop and mobile browsers. A mobile-first design approach is recommended.
+
+---
+
+## 4. Technical Assumptions
+
+### Repository Structure: Monorepo
+
+The project will be developed within a single monorepo. This approach is chosen to simplify dependency management and ensure consistency between the frontend and backend components, especially since they will be tightly coupled and share types and logic.
+
+### Service Architecture
+
+For the MVP, the backend will be a **Monolith**. This simplifies development, deployment, and hosting on a single Raspberry Pi. The architecture should be internally modular to allow for potential future extraction of services if needed, but the initial deployment will be a single service.
+
+### Testing Requirements
+
+The project requires a robust testing strategy focused on data integrity. The minimum requirement is **Unit + Integration Testing**.
+*   **Unit Tests:** Every individual function, especially cryptographic helpers and business logic calculators, must be covered by unit tests.
+*   **Integration Tests:** These are critical to validate the end-to-end flow of transactions within "The Main Ledger". Tests must cover scenarios like: creating a "Cell", adding participants, confirming payments, and verifying that the final calculated state is correct.
+
+### Additional Technical Assumptions and Requests
+
+*   **Hosting:** The entire application must be deployable and performant on a **Raspberry Pi** (Model 4 or newer). Deployment will be managed via **Docker Compose**.
+*   **Core Tech Stack:** The primary technology stack is **Nuxt 4 (Vue 3)** for the frontend and **PostgreSQL** for the database. The backend can be implemented using Nuxt 4's server capabilities.
+*   **Styling:** Styling will be implemented using **SCSS** and **Tailwind CSS**. A component framework (e.g., Nuxt UI, PrimeVue) is anticipated and will be chosen during the architecture phase.
+*   **Cryptography:** Transaction signing will use the **Ed25519** algorithm or a similar lightweight, secure standard. The client is responsible for signing transactions unless the user opts into the server-side "Vault".
+*   **Internationalization (i18n):** The frontend application must be architected with i18n support from the ground up, even though the MVP will only ship with a single language pack.
+*   **API Design:** The API should be designed internally. No requirement for a public-facing REST/GraphQL API in the MVP, as the frontend and backend are tightly coupled.
+
+---
+
+## 5. Epic List
+
+Here is the proposed high-level list of epics required to deliver the MVP. They are sequenced to build upon each other, ensuring a solid foundation is established first.
+
+1.  **Epic 1: The Foundation - "Община" Genesis & Citizen Zero:** Establish the absolute core of the system. This includes project setup, the database schema for the Ledger, and the complete, secure onboarding flow for the very first "Citizen" (the Initiator). The goal is a running application that can support a single user.
+2.  **Epic 2: Community Expansion & The First "Cell":** Focus on growing the "Община". This epic introduces the invitation system for new "Citizens" and implements the entire lifecycle of a financial "Cell" — from creation, participation by Consumers and Executors, to final payment confirmations. The goal is to have a fully functional system for managing one-time shared expenses.
+3.  **Epic 3: The "Vault" & Social Recovery:** Introduce the optional "Vault" feature. This includes creating the login/password mechanism for server-side key storage and implementing the crucial social recovery flow, where Citizens can approve a recovery request for another user. The goal is to add a layer of user-friendliness and safety for key management.
+
+---
+
+## 6. Epic 1: The Foundation - "Община" Genesis & Citizen Zero
+
+**Epic Goal:** To establish the absolute core of the system. This includes the initial project setup, the database schema for "The Main Ledger", and the complete, secure onboarding flow for the very first "Citizen" (the Initiator). The ultimate goal of this epic is a running, deployable application that can securely support a single, authenticated user, creating the foundation for all future functionality.
+
+### Story 1.1: Project Initialization & The Main Ledger
+
+**As a** System Operator, **I want** to set up the initial project structure, including the application framework, database, and deployment configuration, **so that** there is a stable and ready foundation for all future development.
+
+**Acceptance Criteria:**
+1.  A Nuxt 4 project is successfully created and configured in a new monorepo.
+2.  A `docker-compose.yml` file is created to run the Nuxt application and a PostgreSQL database service.
+3.  The Nuxt application can successfully connect to the PostgreSQL database on startup.
+4.  The initial database schema, including tables for "The Main Ledger" and "The Registry", is created via a migration script.
+5.  SCSS and Tailwind CSS are installed and correctly configured within the Nuxt project.
+
+### Story 1.2: Genesis - First Citizen Creation
+
+**As a** first-time user (Initiator), **I want** to be guided through creating a new "Община" and my "Citizen" identity, **so that** I can become the first registered member and start using the system.
+
+**Acceptance Criteria:**
+1.  When the application is launched in an empty state (no Citizens in the Registry), it must display a "Create Община" welcome screen.
+2.  The user is guided through a process that generates a new Ed25519 public/private key pair on the client-side.
+3.  The application must present the newly generated private key to the user for them to copy and save, displaying a prominent warning about the importance of keeping it secure and the consequences of its loss.
+4.  The user must be able to provide a name, which will be associated with their new public key in the "Registry".
+5.  Upon submission, a `CITIZEN_CREATED` transaction, signed with the new private key, must be successfully recorded as the first entry in "The Main Ledger".
+
+### Story 1.3: Authenticated Session & Dashboard Placeholder
+
+**As a** newly created Initiator, **I want** my session to be securely authenticated using my private key, **so that** I can access the main application interface and perform actions on behalf of my "Citizen" identity.
+
+**Acceptance Criteria:**
+1.  After successfully creating a "Citizen" identity, the user is automatically redirected to a main dashboard view.
+2.  The private key must be securely stored for the duration of the browser session in a script-accessible, non-persistent manner (e.g., in-memory variable).
+3.  The main dashboard must be a protected route, inaccessible to unauthenticated users.
+4.  The dashboard must display a simple welcome message that includes the "Citizen's" name from the "Registry" to confirm successful authentication.
+5.  Any future actions initiated from the UI must be able to access the session's private key to sign transactions.
+
+---
+
+## 7. Epic 2: Community Expansion & The First "Cell"
+
+**Epic Goal:** To transform the single-user system into a multi-user "Община" and to implement the core functionality of managing shared finances through "Cells". After this epic, the system will be fully capable of handling the entire lifecycle of a one-time shared expense, from initiation to completion, for a community of two or more "Citizens".
+
+### Story 2.1: Citizen Invitation System
+
+**As an** Initiator, **I want** to generate a secure, single-use invitation link, **so that** I can invite new "Citizens" to join my "Община".
+
+**Acceptance Criteria:**
+1.  A logged-in "Citizen" (initially, only the Initiator) must have a "Generate Invitation" button on the dashboard.
+2.  Clicking the button generates a unique, single-use URL.
+3.  The system must store a record of the generated invitation token to validate it later.
+4.  The user interface must provide an easy way to copy the generated link.
+5.  Once an invitation link has been successfully used, it must be invalidated and cannot be used again.
+
+### Story 2.2: Onboarding via Invitation
+
+**As a** new user, **I want** to be able to join an "Община" using an invitation link, **so that** I can become a "Citizen" and participate in shared activities.
+
+**Acceptance Criteria:**
+1.  Accessing a valid invitation URL must present the new user with the "Citizen" creation screen.
+2.  The onboarding process must be identical to the "Genesis" flow (Story 1.2), including key generation and profile creation in the "Registry".
+3.  Upon successful creation, the new "Citizen" is added to the "Община" and can log in.
+4.  Attempting to access an invalid or already-used invitation URL must show a clear error message.
+
+### Story 2.3: "Cell" Creation
+
+**As a** "Citizen", **I want** to create a new financial "Cell" for a "Common Good", **so that** I can initiate a collection of funds for a shared expense.
+
+**Acceptance Criteria:**
+1.  The main dashboard must have a "Create Cell" button.
+2.  The creation form must allow the user to specify the "Common Good" (the purpose, e.g., "Суп").
+3.  The form must allow the user to define one or more "Executor" roles, including the item to be purchased and its estimated cost (e.g., "Мясо", 100 UAH).
+4.  Submitting the form must create a new `CELL_CREATED` transaction in "The Main Ledger".
+5.  The newly created "Cell" must appear on the main dashboard in an "Open" state.
+
+### Story 2.4: Participating in a "Cell"
+
+**As a** "Citizen", **I want** to be able to join an existing "Cell" as either an "Executor" or a "Consumer", **so that** I can take part in the shared expense.
+
+**Acceptance Criteria:**
+1.  In the "Cell" detail view, a "Citizen" can choose to become an "Executor" for an unassigned item.
+2.  Any "Citizen" (including "Executors") can join the "Cell" as a "Consumer".
+3.  When a "Citizen" joins, the system must re-calculate and display the updated debts for all "Consumers" to all "Executors".
+4.  Each act of joining (as Executor or Consumer) must be recorded as a distinct, signed transaction in "The Main Ledger".
+
+### Story 2.5: Payment Confirmation
+
+**As an** "Executor", **I want** to be able to confirm that I have received a payment from a "Consumer", **so that** their debt is officially cleared in the system.
+
+**Acceptance Criteria:**
+1.  In the "Cell" detail view, an "Executor" must see a list of "Consumers" who owe them money.
+2.  Next to each "Consumer's" name, there must be a "Confirm Payment" button.
+3.  Clicking the button must create a `PAYMENT_CONFIRMED` transaction, signed by the "Executor's" private key, which includes the IDs of both the "Consumer" and "Executor".
+4.  After confirmation, the UI must immediately update to show that the specific debt is cleared.
+
+---
+
+## 8. Epic 3: The "Vault" & Social Recovery
+
+**Epic Goal:** To mitigate the primary risk of a decentralized identity system by introducing the optional "Vault" — a user-friendly, server-side storage for a Citizen's private key, secured by a traditional login/password. This epic will also implement the social recovery mechanism, allowing Citizens to regain access to their Vault-stored key with the help of their peers, thus adding a critical layer of safety and usability.
+
+### Story 3.1: The "Vault" Opt-In
+
+**As a** new or existing "Citizen", **I want** the option to create a "Vault" account (login/password) and store an encrypted copy of my private key on the server, **so that** I have a backup and a way to use the SYSTEM if I don't have my primary key file with me.
+
+**Acceptance Criteria:**
+1.  During the onboarding process (Story 2.2), after the private key is presented to the user, a new step must offer to create a "Vault" account.
+2.  The user must provide a password, which will be used to encrypt their private key on the client-side before it's sent to the server for storage. The server must only store the encrypted key and a salted hash of the password.
+3.  The UI must clearly explain that this is an **optional** convenience feature and that the most secure method is managing the key oneself.
+4.  A logged-in "Citizen" who did not opt-in during onboarding must have an option in their profile to create a "Vault" account later.
+
+### Story 3.2: Session Authentication via The "Vault"
+
+**As a** "Citizen" with a "Vault" account, **I want** to be able to log into a new session using my login and password, **so that** the server can sign transactions on my behalf without me needing to provide my private key file.
+
+**Acceptance Criteria:**
+1.  The main login screen must have a toggle or separate form for "Login with Vault" (username/password).
+2.  Upon successful login, the server must decrypt the user's private key using their password and hold it securely for the duration of the server-side session.
+3.  When the user performs a signable action, the request is sent to the server, which then signs the transaction with the session-stored private key before committing it to "The Main Ledger".
+4.  This flow must be distinct from the default client-side signing, where the server only receives an already-signed transaction.
+
+### Story 3.3: Social Recovery for The "Vault"
+
+**As a** "Citizen" with a "Vault" account who has forgotten their password, **I want** to initiate a recovery process that other "Citizens" can approve, **so that** I can regain access to my encrypted private key.
+
+**Acceptance Criteria:**
+1.  From the "Login with Vault" screen, there must be a "Forgot Password" link.
+2.  The user must identify themselves (e.g., by their name/public key) to initiate a recovery request. A `RECOVERY_REQUESTED` transaction is logged.
+3.  Other "Citizens" must see a notification about the pending recovery request on their dashboard.
+4.  The request UI must show who is requesting recovery and require a quorum of other "Citizens" to approve it by signing a `RECOVERY_APPROVED` transaction. (Quorum rule: 1 approval if <=4 members; 2 approvals if >=5 members).
+5.  Once the quorum is met, the server grants a temporary token, allowing the original user to reset their "Vault" password and re-encrypt their stored private key.
+
+---
diff --git a/docs/architecture/api-integration.md b/docs/architecture/api-integration.md
new file mode 100644
index 0000000..d0ed621
--- /dev/null
+++ b/docs/architecture/api-integration.md
@@ -0,0 +1,49 @@
+# 6. API Integration
+
+Since the project is a monolith where the frontend and backend are served by the same Nuxt instance, we will use the built-in `$fetch` utility for all API calls. This is the recommended, isomorphic way to handle data fetching in Nuxt 4.
+
+## Service Layer Pattern
+
+To keep components clean and organize API logic, we will use a "service layer" pattern. All API calls will be abstracted into functions within files in the `app/services` directory.
+
+**`app/services/cellService.ts` (Example Template)**
+```typescript
+// Using Nuxt's built-in $fetch
+import { $fetch } from 'ofetch';
+
+// Define types for API payloads and responses, ideally imported from a shared location
+interface Cell {
+  id: string;
+  // ... other properties
+}
+
+interface CreateCellPayload {
+  commonGood: string;
+  // ... other properties
+}
+
+const BASE_URL = '/api/cells'; // Internal API endpoint
+
+export const cellService = {
+  /**
+   * Fetches the details for a single Cell.
+   * @param id The ID of the Cell.
+   */
+  async getCellById(id: string): Promise<Cell> {
+    return await $fetch<Cell>(`${BASE_URL}/${id}`);
+  },
+
+  /**
+   * Creates a new Cell.
+   * @param payload The data for the new Cell.
+   */
+  async createCell(payload: CreateCellPayload): Promise<Cell> {
+    return await $fetch<Cell>(BASE_URL, {
+      method: 'POST',
+      body: payload,
+    });
+  },
+
+  // ... other methods like joinAsConsumer, confirmPayment, etc.
+};
+```
diff --git a/docs/architecture/api-specification-server-architecture.md b/docs/architecture/api-specification-server-architecture.md
new file mode 100644
index 0000000..7c1960d
--- /dev/null
+++ b/docs/architecture/api-specification-server-architecture.md
@@ -0,0 +1,75 @@
+# 5. API Specification & Server Architecture
+
+The application will not expose a public REST или GraphQL API. All communication between the frontend and backend will occur internally via **Nuxt 4 Server Routes**. This approach is secure, performant, and perfectly suited for a monolithic fullstack application.
+
+## Server Directory Structure (`server/`)
+
+The server-side logic will be organized as follows:
+
+```plaintext
+server/
+├── api/
+│   ├── cells/
+│   │   ├── index.post.ts       # Create a new Cell
+│   │   └── [id]/
+│   │       ├── index.get.ts    # Get Cell details
+│   │       └── join.post.ts    # Join a Cell (as consumer/executor)
+│   ├── citizens/
+│   │   ├── index.post.ts       # Create a new Citizen (onboarding)
+│   │   └── invite.get.ts       # Generate an invitation link
+│   └── vault/
+│       ├── index.post.ts       # Create a Vault account
+│       ├── login.post.ts       # Login via Vault
+│       └── recover.post.ts     # Initiate/approve social recovery
+├── middleware/
+│   └── auth.ts                 # Middleware to check Citizen authentication
+└── utils/
+    ├── prisma.ts               # Exports a singleton Prisma Client instance
+    └── crypto.ts               # Cryptographic helper functions
+```
+
+## Core API Endpoints (MVP)
+
+| Endpoint | Method | Description | Request Body | Response |
+| :--- | :--- | :--- | :--- | :--- |
+| `/api/citizens` | `POST` | Creates the first Citizen or a new one via invite. | `{ name, publicKey }` | `Citizen` |
+| `/api/citizens/invite` | `GET` | Generates a single-use invitation link. | (none) | `{ inviteUrl }` |
+| `/api/cells` | `POST` | Creates a new "Cell". | `{ commonGood, executors }` | `LedgerEntry` |
+| `/api/cells/[id]` | `GET` | Retrieves the full state of a "Cell". | (none) | `CellState` |
+| `/api/cells/[id]/join` | `POST` | Joins a "Cell" as Executor or Consumer. | `{ role, item? }` | `LedgerEntry` |
+| `/api/cells/[id]/confirm`| `POST` | Confirms payment from a Consumer. | `{ consumerKey }` | `LedgerEntry` |
+
+## Core Workflow: The Cryptographic Signing Process
+
+This sequence diagram illustrates the fundamental process for every action in the system.
+
+```mermaid
+sequenceDiagram
+    participant Browser as Citizen's Browser
+    participant NuxtServer as Nuxt Server / API
+    participant Prisma
+    participant Ledger as The Main Ledger (DB)
+
+    Browser->>Browser: 1. User performs action (e.g., clicks "Create Cell")
+    Browser->>Browser: 2. Prepare `payload` (e.g., { commonGood: "Суп" })
+    Browser->>Browser: 3. Get `previousHash` from last Ledger entry
+    Browser->>Browser: 4. Create `entryHash` from payload + previousHash
+    Browser->>Browser: 5. Sign `entryHash` with private key to get `signature`
+    Browser->>NuxtServer: 6. POST /api/cells (sends payload, publicKey, signature)
+
+    NuxtServer->>NuxtServer: 7. Receive request
+    NuxtServer->>NuxtServer: 8. Validate signature using sender's `publicKey`
+    alt Signature is Invalid
+        NuxtServer-->>Browser: 9a. Return 401 Unauthorized
+    else Signature is Valid
+        NuxtServer->>Prisma: 9b. Get latest `previousHash` from DB
+        NuxtServer->>NuxtServer: 10. Verify client's `previousHash` matches server's
+        NuxtServer->>Prisma: 11. `prisma.ledgerEntry.create(...)`
+        Prisma->>Ledger: 12. INSERT INTO "LedgerEntry"
+        Ledger-->>Prisma: 13. Return new entry
+        Prisma-->>NuxtServer: 14. Return new entry
+        NuxtServer-->>Browser: 15. Return new LedgerEntry (success)
+    end
+```
+
+---
diff --git a/docs/architecture/component-standards.md b/docs/architecture/component-standards.md
new file mode 100644
index 0000000..baf6cb5
--- /dev/null
+++ b/docs/architecture/component-standards.md
@@ -0,0 +1,56 @@
+# 4. Component Standards
+
+To ensure consistency and maintainability, all Vue components created in this project must adhere to the following standards.
+
+## Component Template (`.vue` files)
+
+All components should follow the standard Vue 3 `<script setup>` syntax. This is the recommended modern approach by both Vue and Nuxt documentation.
+
+Here is a minimal template for a new component:
+```vue
+<script setup lang="ts">
+// 1. IMPORTS
+// e.g., import { ref } from 'vue';
+// e.g., import Button from 'primevue/button';
+
+// 2. PROPS & EMITS
+// e.g., const props = defineProps<{
+//   citizenId: string;
+// }>();
+// e.g., const emit = defineEmits(['updated']);
+
+// 3. STATE & COMPOSABLES
+// e.g., const count = ref(0);
+// e.g., const { citizen } = useCitizen();
+
+// 4. COMPUTED PROPERTIES & WATCHERS
+// ...
+
+// 5. LIFECYCLE HOOKS
+// ...
+
+// 6. METHODS
+// e.g., function signTransaction() { ... }
+</script>
+
+<template>
+  <!-- 
+    Component template. Use PrimeVue components and Tailwind CSS classes here.
+    e.g., <div class="p-4 border-round-md"> ... </div>
+  -->
+</template>
+
+<style scoped lang="scss">
+/* 
+  Component-specific SCSS goes here.
+  Global variables/mixins are available thanks to nuxt.config.ts.
+  e.g., .my-component { color: var(--primary-color); }
+*/
+</style>
+```
+
+## Naming Conventions
+
+*   **Components:** `PascalCase`. Files should match the component name (e.g., `CellDetailView.vue`).
+*   **Composables:** `camelCase` with a `use` prefix (e.g., `useLedger.ts`).
+*   **SCSS Variables:** `$kebab-case` (e.g., `$primary-accent-color`).
diff --git a/docs/architecture/database-architecture.md b/docs/architecture/database-architecture.md
new file mode 100644
index 0000000..cecd41e
--- /dev/null
+++ b/docs/architecture/database-architecture.md
@@ -0,0 +1,59 @@
+# 4. Database Architecture (Revised with Prisma)
+
+The database schema will be defined declaratively using the Prisma schema language in a single source of truth file: `prisma/schema.prisma`. Prisma will be responsible for generating SQL migrations and providing a type-safe client for all database interactions.
+
+## Prisma Schema (`prisma/schema.prisma`)
+
+```prisma
+// This is your Prisma schema file,
+// learn more about it in the docs: https://pris.ly/d/prisma-schema
+
+generator client {
+  provider = "prisma-client-js"
+}
+
+datasource db {
+  provider = "postgresql"
+  url      = env("DATABASE_URL")
+}
+
+// User-friendly metadata associated with a public key.
+model Registry {
+  publicKey   String    @id
+  citizenName String
+  avatarUrl   String?
+  isActive    Boolean   @default(true)
+  createdAt   DateTime  @default(now())
+}
+
+// The core, immutable data model.
+// Once a row is written, it is never updated or deleted.
+model LedgerEntry {
+  id                 BigInt    @id @default(autoincrement())
+  previousHash       String?
+  entryHash          String    @unique
+  citizenPublicKey   String
+  signature          String
+  actionType         String
+  payload            Json? // The actual data for the action, e.g., cell details
+  createdAt          DateTime  @default(now())
+
+  @@index([citizenPublicKey])
+  @@index([payload], name: "idx_ledger_payload_entity") // Example for indexing specific payload keys
+}
+```
+
+## Migrations Workflow
+
+Database migrations will be managed exclusively by Prisma Migrate.
+1.  **Development:** After any change to `schema.prisma`, a new migration will be created and applied using the command:
+    ```bash
+    npx prisma migrate dev --name <descriptive_migration_name>
+    ```
+2.  **Production:** Migrations will be applied during the deployment process using:
+    ```bash
+    npx prisma migrate deploy
+    ```
+This ensures that the database schema is always in sync with the Prisma schema definition.
+
+---
diff --git a/docs/architecture/deployment-architecture.md b/docs/architecture/deployment-architecture.md
new file mode 100644
index 0000000..7e69c06
--- /dev/null
+++ b/docs/architecture/deployment-architecture.md
@@ -0,0 +1,10 @@
+# 8. Deployment Architecture
+
+*   **Strategy:** The application will be deployed as a set of Docker containers orchestrated by `docker-compose`. This simplifies deployment on the target Raspberry Pi.
+*   **Process:**
+    1.  A `Dockerfile` will build the Nuxt application into a production-ready Node.js server.
+    2.  `docker-compose.yml` will define two services:
+        *   `app`: The Nuxt application built from the `Dockerfile`.
+        *   `db`: The official PostgreSQL image, with a persistent volume mounted to store the database data.
+    3.  Deployment consists of pulling the latest code, running `docker-compose up -d --build` on the Raspberry Pi.
+*   **Migrations:** Production migrations will be applied by running `npx prisma migrate deploy` inside the running `app` container or as part of the container's startup command.
diff --git a/docs/architecture/development-workflow.md b/docs/architecture/development-workflow.md
new file mode 100644
index 0000000..103d449
--- /dev/null
+++ b/docs/architecture/development-workflow.md
@@ -0,0 +1,13 @@
+# 7. Development Workflow
+
+1.  **Initial Setup:**
+    *   Clone the repository.
+    *   Create a `.env` file with the `DATABASE_URL`.
+    *   Run `docker-compose up -d --build` to start the PostgreSQL container and the Nuxt development server.
+2.  **Schema Changes:**
+    *   Modify `prisma/schema.prisma`.
+    *   Run `npx prisma migrate dev --name <migration-name>` to apply changes to the running database. Prisma Client will be auto-generated.
+3.  **Development:**
+    *   Develop Vue components in the `app/` directory.
+    *   Develop API endpoints in the `server/api/` directory.
+    *   The Nuxt dev server will provide hot-reloading for both frontend and backend changes.
diff --git a/docs/architecture/frontend-tech-stack.md b/docs/architecture/frontend-tech-stack.md
new file mode 100644
index 0000000..145c75a
--- /dev/null
+++ b/docs/architecture/frontend-tech-stack.md
@@ -0,0 +1,14 @@
+# 2. Frontend Tech Stack
+
+This table reflects the choices made in the PRD and the user's template, solidifying the frontend technology stack.
+
+| Category | Technology | Version | Purpose & Rationale |
+| :--- | :--- | :--- | :--- |
+| Framework | **Nuxt** | `^4.0.3` | The core application framework, providing SSR, file-based routing, and a robust module ecosystem. |
+| UI Library | **PrimeVue** | `^4.3.7` | The primary component library. Chosen for its rich set of components and powerful theming capabilities. |
+| Theme | **PrimeUI Aura** | `^1.2.3` | The default theme preset for PrimeVue, providing a modern and clean aesthetic out of the box. |
+| Styling | **Tailwind CSS** | `^0.6.1` (primeui) | For utility-first styling, rapid prototyping, and responsive design. |
+| Styling | **SCSS (Sass)** | (via `sass` dev dep) | For structured styling, variables, mixins, and managing global styles and theme overrides. |
+| i18n | **@nuxtjs/i18n**| `10.0.6` | For future-proof internationalization, as required by the PRD. |
+
+---
diff --git a/docs/architecture/high-level-architecture.md b/docs/architecture/high-level-architecture.md
new file mode 100644
index 0000000..ebf22c0
--- /dev/null
+++ b/docs/architecture/high-level-architecture.md
@@ -0,0 +1,43 @@
+# 2. High Level Architecture
+
+## Technical Summary
+
+Project SYSTEM is a monolithic, self-hosted web application built on the Nuxt 4 framework. The architecture is designed for efficiency and transparency, running on a Raspberry Pi. It features a Vue-based frontend interacting with a PostgreSQL database via Nuxt's server-side API routes. The core of the system is an immutable, event-sourced "Main Ledger" where every action is a cryptographically signed transaction, ensuring data integrity and auditability. Identity management is decentralized, based on public/private key pairs.
+
+## Platform and Infrastructure Choice
+
+*   **Platform:** Self-hosted on a user-provided **Raspberry Pi** (Model 4+).
+*   **Key Services:**
+    *   **Application Server:** **Nuxt 4** running in Node.js mode.
+    *   **Database:** **PostgreSQL**.
+    *   **Containerization:** The entire stack will be managed and deployed via **Docker Compose**. This ensures a consistent and reproducible environment.
+*   **Deployment Host and Regions:** Single host, located within the "Община's" private network.
+
+## Repository Structure
+
+*   **Structure:** **Monorepo**.
+*   **Monorepo Tool:** Not required for this level of simplicity. A single `package.json` at the root will manage all dependencies.
+*   **Package Organization:** A standard Nuxt 4 project structure will be used, as detailed in the Frontend Architecture. Server-side logic will reside within the `server/` directory.
+
+## High Level Architecture Diagram
+
+```mermaid
+graph TD
+    subgraph "Browser"
+        A[Citizen's Browser]
+    end
+
+    subgraph "Raspberry Pi (Docker Compose)"
+        B[Nuxt 4 Server]
+        C[PostgreSQL Database]
+
+        B -- "Serves Frontend" --> A
+        A -- "API Calls ($fetch)" --> B
+        B -- "Reads/Writes" --> C
+    end
+
+    style B fill:#2D3748,stroke:#fff,stroke-width:2px,color:#fff
+    style C fill:#4A5568,stroke:#fff,stroke-width:2px,color:#fff
+```
+
+---
diff --git a/docs/architecture/index.md b/docs/architecture/index.md
new file mode 100644
index 0000000..8101276
--- /dev/null
+++ b/docs/architecture/index.md
@@ -0,0 +1,38 @@
+# SYSTEM Fullstack Architecture Document
+
+## Table of Contents
+
+- [SYSTEM Fullstack Architecture Document](#table-of-contents)
+  - [1. Template and Framework Selection](template-and-framework-selection.md)
+    - [Change Log](template-and-framework-selection.md#change-log)
+  - [2. Frontend Tech Stack](frontend-tech-stack.md)
+  - [3. Project Structure](project-structure.md)
+  - [4. Component Standards](component-standards.md)
+    - [Component Template ( files)](component-standards.md#component-template-files)
+    - [Naming Conventions](component-standards.md#naming-conventions)
+  - [5. State Management](state-management.md)
+    - [State Management Template ()](state-management.md#state-management-template)
+  - [6. API Integration](api-integration.md)
+    - [Service Layer Pattern](api-integration.md#service-layer-pattern)
+  - [7. Routing](routing.md)
+  - [8. Testing Requirements](testing-requirements.md)
+  - [1. Introduction](introduction.md)
+    - [Starter Template or Existing Project](introduction.md#starter-template-or-existing-project)
+    - [Change Log](introduction.md#change-log)
+  - [2. High Level Architecture](high-level-architecture.md)
+    - [Technical Summary](high-level-architecture.md#technical-summary)
+    - [Platform and Infrastructure Choice](high-level-architecture.md#platform-and-infrastructure-choice)
+    - [Repository Structure](high-level-architecture.md#repository-structure)
+    - [High Level Architecture Diagram](high-level-architecture.md#high-level-architecture-diagram)
+  - [3. Tech Stack (Revised)](tech-stack.md)
+  - [4. Database Architecture (Revised with Prisma)](database-architecture.md)
+    - [Prisma Schema ()](database-architecture.md#prisma-schema)
+    - [Migrations Workflow](database-architecture.md#migrations-workflow)
+  - [5. API Specification & Server Architecture](api-specification-server-architecture.md)
+    - [Server Directory Structure ()](api-specification-server-architecture.md#server-directory-structure)
+    - [Core API Endpoints (MVP)](api-specification-server-architecture.md#core-api-endpoints-mvp)
+    - [Core Workflow: The Cryptographic Signing Process](api-specification-server-architecture.md#core-workflow-the-cryptographic-signing-process)
+  - [6. Unified Project Structure](unified-project-structure.md)
+  - [7. Development Workflow](development-workflow.md)
+  - [8. Deployment Architecture](deployment-architecture.md)
+  - [9. Security & Performance](security-performance.md)
diff --git a/docs/architecture/introduction.md b/docs/architecture/introduction.md
new file mode 100644
index 0000000..9c1dbee
--- /dev/null
+++ b/docs/architecture/introduction.md
@@ -0,0 +1,13 @@
+# 1. Introduction
+
+This document outlines the complete fullstack architecture for Project SYSTEM, including the backend systems, frontend implementation, and their integration. It serves as the single source of truth for AI-driven development, ensuring consistency across the entire technology stack. This unified approach combines backend and frontend concerns to streamline development.
+
+## Starter Template or Existing Project
+
+*   **Decision:** The project is based on the custom Nuxt 4 starter template provided by the user. No external templates are used. The architecture will be built upon this existing foundation.
+
+## Change Log
+
+| Date | Version | Description | Author |
+| :--- | :--- | :--- | :--- |
+| 2025-08-31 | 1.0 | Initial Fullstack Architecture draft | Architect (Winston) |
diff --git a/docs/architecture/project-structure.md b/docs/architecture/project-structure.md
new file mode 100644
index 0000000..c26f870
--- /dev/null
+++ b/docs/architecture/project-structure.md
@@ -0,0 +1,78 @@
+# 3. Project Structure
+
+Based on the Nuxt 4 documentation and the need to manage SCSS files effectively, the following directory structure will be adopted within the `app/` directory.
+
+```plaintext
+app/
+├── assets/
+│   └── scss/
+│       ├── base/
+│       │   ├── _reset.scss       # Optional: for CSS resets
+│       │   └── _typography.scss  # Base typography styles
+│       ├── components/
+│       │   └── _buttons.scss     # Example: Custom button styles
+│       ├── layout/
+│       │   └── _main.scss        # Main layout styles
+│       ├── themes/
+│       │   └── _aura-overrides.scss # Specific overrides for the Aura theme
+│       ├── utils/
+│       │   ├── _variables.scss   # Global SCSS variables (colors, spacing)
+│       │   └── _mixins.scss      # Global SCSS mixins
+│       └── main.scss             # Main entry file that imports all other SCSS partials
+│
+├── components/
+│   ├── common/
+│   │   └── AppHeader.vue         # Example of a globally used component
+│   └── specific/
+│       └── CellDetailView.vue    # Example of a view-specific component
+│
+├── composables/
+│   ├── useCitizen.ts             # Composable for managing Citizen identity
+│   └── useLedger.ts              # Composable for interacting with The Main Ledger
+│
+├── layouts/
+│   └── default.vue               # The default layout for the application
+│
+├── pages/
+│   ├── index.vue                 # Dashboard / Main View
+│   └── cell/
+│       └── [id].vue              # Cell Detail View (Dynamic Route)
+│
+├── plugins/
+│   └── primevue.ts               # Plugin to register PrimeVue components/services if needed
+│
+└── app.vue                       # Main application entry point
+```
+
+To make this SCSS structure work seamlessly, we will update `nuxt.config.ts` to automatically import our main SCSS file globally.
+
+**`nuxt.config.ts` modification:**
+```typescript
+export default defineNuxtConfig({
+  // ... other configs
+  css: ['~/assets/scss/main.scss'],
+  // ... other configs
+})
+```
+
+**`app/assets/scss/main.scss` content:**
+```scss
+// 1. Utilities (Variables, Mixins)
+@use 'utils/variables';
+@use 'utils/mixins';
+
+// 2. Base Styles
+@use 'base/reset';
+@use 'base/typography';
+
+// 3. Layout Styles
+@use 'layout/main';
+
+// 4. Component Styles
+@use 'components/buttons';
+
+// 5. Theme Overrides
+@use 'themes/aura-overrides';
+```
+
+---
diff --git a/docs/architecture/routing.md b/docs/architecture/routing.md
new file mode 100644
index 0000000..aef7cfc
--- /dev/null
+++ b/docs/architecture/routing.md
@@ -0,0 +1,28 @@
+# 7. Routing
+
+Routing will be handled by Nuxt's file-based router. All pages will be created as `.vue` files in the `app/pages` directory.
+
+**Route Configuration Example (`app/pages/cell/[id].vue`)**
+```vue
+<script setup lang="ts">
+import { useRoute } from 'vue-router';
+
+const route = useRoute();
+const cellId = route.params.id as string;
+
+// Fetch cell data using the service
+const { data: cell, pending, error } = await useAsyncData(
+  `cell-${cellId}`,
+  () => cellService.getCellById(cellId)
+);
+</script>
+
+<template>
+  <div v-if="pending">Loading...</div>
+  <div v-else-if="error">Error loading Cell: {{ error.message }}</div>
+  <div v-else-if="cell">
+    <h1>{{ cell.commonGood }}</h1>
+    <!-- Display cell details here -->
+  </div>
+</template>
+```
diff --git a/docs/architecture/security-performance.md b/docs/architecture/security-performance.md
new file mode 100644
index 0000000..12732e8
--- /dev/null
+++ b/docs/architecture/security-performance.md
@@ -0,0 +1,12 @@
+# 9. Security & Performance
+
+*   **Security:**
+    *   **Authentication:** Managed via cryptographic signatures. The server is stateless regarding authentication.
+    *   **Authorization:** All API endpoints inside `server/middleware/auth.ts` will verify the incoming signature against the `publicKey` to ensure the action is performed by the legitimate owner of the key.
+    *   **Secrets:** The `DATABASE_URL` will be managed via the `.env` file, which is excluded from version control.
+*   **Performance:**
+    *   The primary performance consideration is the Raspberry Pi environment. The monolithic Nuxt/PostgreSQL stack is chosen for its low resource overhead compared to more complex microservice architectures.
+    *   Database queries will be optimized using indices as defined in the Prisma schema.
+    *   Frontend assets will be optimized by Nuxt's build process.
+
+---
diff --git a/docs/architecture/state-management.md b/docs/architecture/state-management.md
new file mode 100644
index 0000000..df586c5
--- /dev/null
+++ b/docs/architecture/state-management.md
@@ -0,0 +1,40 @@
+# 5. State Management
+
+*   **Approach:** For the MVP, we will rely primarily on **Nuxt's built-in `useState` composable** for simple, shared, server-side-renderable state. This is the most lightweight and idiomatic approach for Nuxt 4. We will avoid installing a heavy external library like Pinia or Vuex until the application's complexity demonstrably requires it.
+*   **Structure:** Shared state composables will be located in the `app/composables/` directory.
+
+## State Management Template (`app/composables/useSomeState.ts`)
+
+```typescript
+import { useState } from '#app';
+
+// Example: Managing the current Citizen's session info
+interface CitizenSession {
+  name: string;
+  publicKey: string;
+  // NOTE: The private key should NOT be stored in a composable.
+  // It should be managed in a more secure, non-persistent way.
+}
+
+export const useCitizenStore = () => {
+  const citizen = useState<CitizenSession | null>('citizen', () => null);
+
+  const setCitizen = (newCitizen: CitizenSession) => {
+    citizen.value = newCitizen;
+  };
+
+  const clearCitizen = () => {
+    citizen.value = null;
+  };
+
+
+
+  return {
+    citizen,
+    setCitizen,
+    clearCitizen,
+  };
+};
+```
+
+---
diff --git a/docs/architecture/tech-stack.md b/docs/architecture/tech-stack.md
new file mode 100644
index 0000000..846cfd4
--- /dev/null
+++ b/docs/architecture/tech-stack.md
@@ -0,0 +1,9 @@
+# 3. Tech Stack (Revised)
+
+| Category | Technology | Version | Purpose & Rationale |
+| :--- | :--- | :--- | :--- |
+| **Fullstack Framework**| **Nuxt** | `^4.0.3` | Core framework for both frontend and backend (server routes). |
+| **Database ORM** | **Prisma** | `latest` | Next-generation ORM for type-safe database access and automated migrations. |
+| **Database** | **PostgreSQL** | `latest` | Robust, reliable SQL database managed by Prisma. |
+| **Deployment** | **Docker Compose**| `latest` | For containerizing and managing the application stack. |
+| ... | *(rest of the stack remains the same)* | ... | ... |
diff --git a/docs/architecture/template-and-framework-selection.md b/docs/architecture/template-and-framework-selection.md
new file mode 100644
index 0000000..d582d68
--- /dev/null
+++ b/docs/architecture/template-and-framework-selection.md
@@ -0,0 +1,12 @@
+# 1. Template and Framework Selection
+
+*   **Framework:** The project is built on **Nuxt 4**, as specified in the provided `repomix-output.xml`.
+*   **UI Library:** The core component library is **PrimeVue**, with the **Aura** theme preset. This choice is confirmed in `nuxt.config.ts`.
+*   **Styling:** A hybrid approach using **Tailwind CSS** for utility-first styling and **SCSS** for global styles, variables, and complex component styling is adopted.
+*   **Starter Template:** The project is based on the custom template provided by the user. No external starter templates are used. This gives us full control but requires us to define the structure meticulously.
+
+## Change Log
+
+| Date | Version | Description | Author |
+| :--- | :--- | :--- | :--- |
+| 2025-08-31 | 1.0 | Initial Frontend Architecture draft | Architect (Winston) |
diff --git a/docs/architecture/testing-requirements.md b/docs/architecture/testing-requirements.md
new file mode 100644
index 0000000..aa564ea
--- /dev/null
+++ b/docs/architecture/testing-requirements.md
@@ -0,0 +1,7 @@
+# 8. Testing Requirements
+
+Testing is critical for ensuring the integrity of the system.
+*   **Unit Tests:** We will use **Vitest** for unit testing. Every composable and service function must have unit tests covering its logic.
+*   **Component Tests:** We will use **`@vue/test-utils`** to test individual Vue components. Tests should verify that components render correctly based on props and that they emit events when interacted with.
+*   **Test Location:** All test files will be located alongside the file they are testing, with a `.spec.ts` extension (e.g., `useLedger.spec.ts`).
+
diff --git a/docs/architecture/unified-project-structure.md b/docs/architecture/unified-project-structure.md
new file mode 100644
index 0000000..f5daf9b
--- /dev/null
+++ b/docs/architecture/unified-project-structure.md
@@ -0,0 +1,33 @@
+# 6. Unified Project Structure
+
+This is the final monorepo structure that integrates the frontend (`app/`), backend (`server/`), and database (`prisma/`) components.
+
+```plaintext
+system/
+├── app/                      # Nuxt frontend application
+│   ├── assets/
+│   │   └── scss/
+│   ├── components/
+│   ├── composables/
+│   ├── layouts/
+│   ├── pages/
+│   └── ...
+├── prisma/                   # Prisma ORM configuration
+│   ├── migrations/
+│   │   └── .../migration.sql
+│   └── schema.prisma         # The single source of truth for the database
+├── server/                   # Nuxt server-side logic (API)
+│   ├── api/
+│   │   └── ...
+│   ├── middleware/
+│   └── utils/
+├── types/                    # Shared TypeScript types
+│   ├── citizen.ts
+│   ├── ledger.ts
+│   └── index.ts
+├── docker-compose.yml        # Defines and runs the multi-container stack
+├── Dockerfile                # For building the Nuxt application image
+├── nuxt.config.ts            # Nuxt configuration
+├── package.json
+└── tsconfig.json
+```
diff --git a/docs/front-end-spec.md b/docs/front-end-spec.md
new file mode 100644
index 0000000..8987c51
--- /dev/null
+++ b/docs/front-end-spec.md
@@ -0,0 +1,212 @@
+# **SYSTEM UI/UX Specification**
+
+## 1. Introduction
+
+This document defines the user experience goals, information architecture, user flows, and visual design specifications for the **SYSTEM** user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience that aligns with the project's unique thematic and technical requirements.
+
+### Overall UX Goals & Principles
+
+*   **Target User Personas:**
+    *   **The "Initiator":** The first user, responsible for setting up the "Община". Values clarity and a straightforward setup process.
+    *   **The "Citizen":** A tech-savvy member of a high-trust community. Values efficiency for daily tasks, absolute transparency in financial matters, and an engaging, unique user experience.
+*   **Usability Goals:**
+    *   **Efficiency:** Common tasks like creating a "Cell" must be low-friction and achievable in minimal steps.
+    *   **Trust & Transparency:** The UI must visually reinforce the integrity of the underlying cryptographic ledger. Users should "feel" the security and immutability.
+    *   **Learnability:** The system's unique concepts ("Cells", "The Vault") must be explained through clear, intuitive interfaces and onboarding cues.
+*   **Design Principles:**
+    1.  **Clarity over Concealment:** Be explicit about processes. Show when a transaction is signed, when it's pending, and when it's finalized.
+    2.  **Thematic Integrity:** The UI should consistently reflect the chosen retro-futuristic, dystopian/communistic aesthetic through terminology, typography, and color.
+    3.  **Seamless Security:** Make the act of cryptographic signing feel powerful, not tedious.
+    4.  **Mobile-First & Responsive:** The experience must be flawless on both mobile and desktop browsers.
+
+### Change Log
+
+| Date | Version | Description | Author |
+| :--- | :--- | :--- | :--- |
+| 2025-08-31 | 1.0 | Initial UI/UX Spec draft | UX Expert (Sally) |
+
+---
+
+## 2. Information Architecture (IA)
+
+### Site Map / Screen Inventory
+
+The SYSTEM application is a single-page application (SPA) with distinct views managed by a router. The information architecture is designed to be flat and task-oriented, ensuring Citizens can access key functions quickly.
+
+```mermaid
+graph TD
+    A[Entry Point] --> B{Is Община Created?};
+    B -->|No| C[Onboarding (Create Община)];
+    B -->|Yes| D{Is Citizen Authenticated?};
+    C --> F[Dashboard];
+
+    D -->|No| E{Has Invite Token?};
+    D -->|Yes| F;
+
+    E -->|Yes| G[Onboarding (Join Община)];
+    E -->|No| H[Authentication View];
+    G --> F;
+    H --> F;
+
+    F --> F1[Active "Cells" List];
+    F --> F2[Create "Cell" Button];
+    F1 --> I[Cell Detail View];
+    F2 --> J[Create "Cell" Form];
+
+    F --> K[Profile & Settings];
+    K --> L[Vault Management];
+    K --> M[Social Recovery View];
+```
+
+### Navigation Structure
+
+*   **Primary Navigation:** Since this is a focused application, there will be no complex primary navigation bar. The main "Dashboard" will serve as the root view. A single icon or user avatar in the corner will lead to the "Profile & Settings" area.
+*   **Breadcrumb Strategy:** Not required for the MVP due to the flat architecture. Context will be maintained within the views themselves (e.g., "Cell Detail View" will clearly display the "Common Good" it belongs to).
+
+---
+
+## 3. User Flows
+
+### Flow 1: Onboarding the First Citizen (Initiator)
+
+*   **User Goal:** To set up the "Община" and create their own identity.
+*   **Entry Points:** Accessing the root URL of the self-hosted application for the first time.
+*   **Success Criteria:** The user has successfully created an identity, saved their private key, and is logged into the main dashboard.
+
+```mermaid
+graph TD
+    A[User opens the app] --> B{Is `Registry` table empty?};
+    B -->|Yes| C[Show "Create Община" screen];
+    C --> D[User clicks "Create"];
+    D --> E[Client-side: Generate key pair];
+    E --> F[Show Private Key with strong warnings];
+    F --> G[User confirms they saved the key];
+    G --> H[Ask for Citizen's name];
+    H --> I[User enters name and submits];
+    I --> J[Sign `CITIZEN_CREATED` transaction];
+    J --> K[Send to server];
+    K --> L[Server validates & saves to Ledger];
+    L --> M[Redirect to Dashboard];
+
+    B -->|No| N[Show Authentication View];
+```
+
+### Flow 2: Creating and Participating in a "Cell"
+
+*   **User Goal:** To initiate a shared expense and have others join and pay their share.
+*   **Entry Points:** Clicking the "Create Cell" button on the Dashboard.
+*   **Success Criteria:** The "Cell" is created, participants have joined, and all payments are confirmed by the "Executors".
+
+```mermaid
+graph TD
+    subgraph Citizen A (Initiator)
+        A[Clicks "Create Cell"] --> B[Fills out "Cell" details: purpose, items, costs];
+        B --> C[Submits form];
+        C --> D[Signs `CREATE_CELL` transaction];
+        D --> E[Cell appears on Dashboard];
+    end
+
+    subgraph Citizen B (Executor)
+        F[Sees new "Cell" on Dashboard] --> G[Opens "Cell" details];
+        G --> H[Clicks "Become Executor" for an item];
+        H --> I[Signs `JOIN_AS_EXECUTOR` transaction];
+    end
+
+    subgraph Citizen C (Consumer)
+        J[Opens "Cell" details] --> K[Sees calculated share];
+        K --> L[Clicks "Join as Consumer"];
+        L --> M[Signs `JOIN_AS_CONSUMER` transaction];
+        M --> N[Physically sends money to Citizen B];
+    end
+
+    subgraph Citizen B (Executor)
+        O[Receives money] --> P[Clicks "Confirm Payment" for Citizen C];
+        P --> Q[Signs `CONFIRM_PAYMENT` transaction];
+        Q --> R[UI updates to show debt is cleared];
+    end
+```
+
+---
+
+## 4. Wireframes & Mockups
+
+*   **Primary Design Files:** Since this is a developer-led project, we will not use external design tools like Figma. The **UI/UX Specification** and the **PrimeVue component documentation** will serve as the primary source of truth for design. The final look and feel will be a direct result of applying the defined theme (`Aura`), typography, and color palette to the PrimeVue components.
+
+### Key Screen Layouts
+
+*   **Dashboard View:**
+    *   **Purpose:** To provide a central overview of all active financial matters.
+    *   **Key Elements:**
+        1.  A prominent "Create Cell" button.
+        2.  A list/grid of active "Cells", each showing its title, total amount, and progress (e.g., "3/5 participants confirmed").
+        3.  A summary panel showing what "I Owe" and what "Is Owed to Me".
+        4.  A corner link/icon to access the "Profile & Settings" page.
+    *   **Interaction Notes:** Clicking a "Cell" card navigates to its `Cell Detail View`.
+*   **Cell Detail View:**
+    *   **Purpose:** To show a complete, transparent breakdown of a single shared expense.
+    *   **Key Elements:**
+        1.  Header with the "Common Good" title and total value.
+        2.  A section for "Executors", listing who is buying what, and for how much.
+        3.  A section for "Consumers", showing each person's share and their payment status relative to each Executor (e.g., "Owes 50 to Citizen B"). A "Confirm Payment" button is visible here for Executors.
+        4.  A simple, immutable log of all transactions related to this "Cell", pulled directly from "The Main Ledger".
+    *   **Interaction Notes:** The view is dynamic, updating in real-time as new transactions are confirmed.
+*   **Profile & Settings View:**
+    *   **Purpose:** To manage Citizen identity and application settings.
+    *   **Key Elements:**
+        1.  Display of the Citizen's name and their full public key.
+        2.  A button to copy the public key.
+        3.  A section to manage the "Vault" (create a vault account, initiate recovery).
+        4.  (Post-MVP) A section for notification preferences.
+
+## 5. Component Library / Design System
+
+*   **Design System Approach:** We will adopt a **Component-Driven** approach using **PrimeVue** as our core component library. We will not build basic components (buttons, inputs) from scratch. Instead, we will use PrimeVue components and customize them globally using the `Aura` theme, Tailwind CSS utilities, and custom SCSS.
+*   **Core Components (PrimeVue):**
+    *   **Button:** For all clickable actions (`p-button`).
+    *   **InputText, InputNumber, Textarea:** For all forms (`p-inputtext`, etc.).
+    *   **Card, Panel:** To encapsulate sections like "Cell" overviews on the dashboard (`p-card`, `p-panel`).
+    *   **DataTable, DataView:** To display lists of participants and transactions (`p-datatable`).
+    *   **Toast:** For non-blocking notifications (e.g., "Transaction Signed") (`p-toast`).
+    *   **Dialog:** For modal confirmations (`p-dialog`).
+
+---
+
+## 6. Branding & Style Guide
+
+*   **Visual Identity:** The brand identity is "SYSTEM" — a blend of retro-futuristic console, dystopian minimalism, and communistic propaganda aesthetics. It should feel functional, slightly stark, but highly trustworthy.
+*   **Color Palette:**
+    *   We will use the **Aura theme from PrimeVue** as the base. The theme's default colors provide a modern, clean look that can be subtly customized.
+*   We will define a primary accent color for all interactive elements to align with the "SYSTEM" theme. Let's start with a strong but not overpowering red.
+
+| Color Type | Hex Code (Example) | Usage | 
+| :--- | :--- | :--- |
+| Primary | `#BF3636` (A deep red) | Buttons, links, active states, key highlights |
+| Surface | Aura Theme Defaults | Backgrounds, cards, panels (e.g., `surface-0` to `surface-900`) |
+| Text | Aura Theme Defaults | Primary and secondary text colors |
+| Success | `#22C55E` (Green) | Confirmation messages, success states |
+| Warning | `#F59E0B` (Amber) | Non-critical alerts, warnings |
+| Error | `#EF4444` (Red) | Error messages, destructive action confirmations |
+*   **Typography:**
+    *   **Primary Font:** `Inter` (already configured in `nuxt.config.ts`). This is a clean, modern, and highly readable sans-serif font that works well for UI.
+    *   **Monospace Font:** We will add a standard monospace font (e.g., `Fira Code`, `JetBrains Mono`) for displaying cryptographic data like keys and hashes to reinforce the "console" aesthetic.
+*   **Iconography:**
+    *   **Icon Library:** `primeicons` (comes with PrimeVue).
+    *   **Usage Guidelines:** Icons should be used sparingly and functionally to guide the user, not for decoration.
+
+## 7. Accessibility Requirements
+
+*   **Compliance Target:** The application will adhere to **WCAG 2.1 Level AA** standards.
+*   **Key Requirements:**
+    *   **Visual:** All text must meet a 4.5:1 contrast ratio against its background. All interactive elements must have clear focus indicators.
+    *   **Interaction:** The entire application must be navigable and operable using only a keyboard. All components must be screen-reader friendly.
+    *   **Content:** All form inputs must have associated labels. Dynamic content updates must be announced to screen readers.
+
+## 8. Responsiveness Strategy
+
+*   **Breakpoints:** We will use the default Tailwind CSS breakpoints (`sm`, `md`, `lg`, `xl`, `2xl`), which provide a robust mobile-first foundation.
+*   **Adaptation Patterns:**
+    *   **Layout:** On mobile, use a single-column layout. On larger screens, transition to multi-column layouts (e.g., dashboard with a side panel for settings).
+    *   **Navigation:** Mobile navigation will be handled by a slide-out panel or a tab bar if needed. Desktop will have a simple, persistent sidebar.
+    *   **Data Display:** Tables (`p-datatable`) will switch to a stacked "card" layout on mobile for better readability.
+
+---
diff --git a/docs/prd/epic-1-the-foundation-genesis-citizen-zero.md b/docs/prd/epic-1-the-foundation-genesis-citizen-zero.md
new file mode 100644
index 0000000..eb2a819
--- /dev/null
+++ b/docs/prd/epic-1-the-foundation-genesis-citizen-zero.md
@@ -0,0 +1,38 @@
+# 6. Epic 1: The Foundation - "Община" Genesis & Citizen Zero
+
+**Epic Goal:** To establish the absolute core of the system. This includes the initial project setup, the database schema for "The Main Ledger", and the complete, secure onboarding flow for the very first "Citizen" (the Initiator). The ultimate goal of this epic is a running, deployable application that can securely support a single, authenticated user, creating the foundation for all future functionality.
+
+## Story 1.1: Project Initialization & The Main Ledger
+
+**As a** System Operator, **I want** to set up the initial project structure, including the application framework, database, and deployment configuration, **so that** there is a stable and ready foundation for all future development.
+
+**Acceptance Criteria:**
+1.  A Nuxt 4 project is successfully created and configured in a new monorepo.
+2.  A `docker-compose.yml` file is created to run the Nuxt application and a PostgreSQL database service.
+3.  The Nuxt application can successfully connect to the PostgreSQL database on startup.
+4.  The initial database schema, including tables for "The Main Ledger" and "The Registry", is created via a migration script.
+5.  SCSS and Tailwind CSS are installed and correctly configured within the Nuxt project.
+
+## Story 1.2: Genesis - First Citizen Creation
+
+**As a** first-time user (Initiator), **I want** to be guided through creating a new "Община" and my "Citizen" identity, **so that** I can become the first registered member and start using the system.
+
+**Acceptance Criteria:**
+1.  When the application is launched in an empty state (no Citizens in the Registry), it must display a "Create Община" welcome screen.
+2.  The user is guided through a process that generates a new Ed25519 public/private key pair on the client-side.
+3.  The application must present the newly generated private key to the user for them to copy and save, displaying a prominent warning about the importance of keeping it secure and the consequences of its loss.
+4.  The user must be able to provide a name, which will be associated with their new public key in the "Registry".
+5.  Upon submission, a `CITIZEN_CREATED` transaction, signed with the new private key, must be successfully recorded as the first entry in "The Main Ledger".
+
+## Story 1.3: Authenticated Session & Dashboard Placeholder
+
+**As a** newly created Initiator, **I want** my session to be securely authenticated using my private key, **so that** I can access the main application interface and perform actions on behalf of my "Citizen" identity.
+
+**Acceptance Criteria:**
+1.  After successfully creating a "Citizen" identity, the user is automatically redirected to a main dashboard view.
+2.  The private key must be securely stored for the duration of the browser session in a script-accessible, non-persistent manner (e.g., in-memory variable).
+3.  The main dashboard must be a protected route, inaccessible to unauthenticated users.
+4.  The dashboard must display a simple welcome message that includes the "Citizen's" name from the "Registry" to confirm successful authentication.
+5.  Any future actions initiated from the UI must be able to access the session's private key to sign transactions.
+
+---
diff --git a/docs/prd/epic-2-community-expansion-the-first-cell.md b/docs/prd/epic-2-community-expansion-the-first-cell.md
new file mode 100644
index 0000000..f0ff215
--- /dev/null
+++ b/docs/prd/epic-2-community-expansion-the-first-cell.md
@@ -0,0 +1,57 @@
+# 7. Epic 2: Community Expansion & The First "Cell"
+
+**Epic Goal:** To transform the single-user system into a multi-user "Община" and to implement the core functionality of managing shared finances through "Cells". After this epic, the system will be fully capable of handling the entire lifecycle of a one-time shared expense, from initiation to completion, for a community of two or more "Citizens".
+
+## Story 2.1: Citizen Invitation System
+
+**As an** Initiator, **I want** to generate a secure, single-use invitation link, **so that** I can invite new "Citizens" to join my "Община".
+
+**Acceptance Criteria:**
+1.  A logged-in "Citizen" (initially, only the Initiator) must have a "Generate Invitation" button on the dashboard.
+2.  Clicking the button generates a unique, single-use URL.
+3.  The system must store a record of the generated invitation token to validate it later.
+4.  The user interface must provide an easy way to copy the generated link.
+5.  Once an invitation link has been successfully used, it must be invalidated and cannot be used again.
+
+## Story 2.2: Onboarding via Invitation
+
+**As a** new user, **I want** to be able to join an "Община" using an invitation link, **so that** I can become a "Citizen" and participate in shared activities.
+
+**Acceptance Criteria:**
+1.  Accessing a valid invitation URL must present the new user with the "Citizen" creation screen.
+2.  The onboarding process must be identical to the "Genesis" flow (Story 1.2), including key generation and profile creation in the "Registry".
+3.  Upon successful creation, the new "Citizen" is added to the "Община" and can log in.
+4.  Attempting to access an invalid or already-used invitation URL must show a clear error message.
+
+## Story 2.3: "Cell" Creation
+
+**As a** "Citizen", **I want** to create a new financial "Cell" for a "Common Good", **so that** I can initiate a collection of funds for a shared expense.
+
+**Acceptance Criteria:**
+1.  The main dashboard must have a "Create Cell" button.
+2.  The creation form must allow the user to specify the "Common Good" (the purpose, e.g., "Суп").
+3.  The form must allow the user to define one or more "Executor" roles, including the item to be purchased and its estimated cost (e.g., "Мясо", 100 UAH).
+4.  Submitting the form must create a new `CELL_CREATED` transaction in "The Main Ledger".
+5.  The newly created "Cell" must appear on the main dashboard in an "Open" state.
+
+## Story 2.4: Participating in a "Cell"
+
+**As a** "Citizen", **I want** to be able to join an existing "Cell" as either an "Executor" or a "Consumer", **so that** I can take part in the shared expense.
+
+**Acceptance Criteria:**
+1.  In the "Cell" detail view, a "Citizen" can choose to become an "Executor" for an unassigned item.
+2.  Any "Citizen" (including "Executors") can join the "Cell" as a "Consumer".
+3.  When a "Citizen" joins, the system must re-calculate and display the updated debts for all "Consumers" to all "Executors".
+4.  Each act of joining (as Executor or Consumer) must be recorded as a distinct, signed transaction in "The Main Ledger".
+
+## Story 2.5: Payment Confirmation
+
+**As an** "Executor", **I want** to be able to confirm that I have received a payment from a "Consumer", **so that** their debt is officially cleared in the system.
+
+**Acceptance Criteria:**
+1.  In the "Cell" detail view, an "Executor" must see a list of "Consumers" who owe them money.
+2.  Next to each "Consumer's" name, there must be a "Confirm Payment" button.
+3.  Clicking the button must create a `PAYMENT_CONFIRMED` transaction, signed by the "Executor's" private key, which includes the IDs of both the "Consumer" and "Executor".
+4.  After confirmation, the UI must immediately update to show that the specific debt is cleared.
+
+---
diff --git a/docs/prd/epic-3-the-vault-social-recovery.md b/docs/prd/epic-3-the-vault-social-recovery.md
new file mode 100644
index 0000000..a9c5519
--- /dev/null
+++ b/docs/prd/epic-3-the-vault-social-recovery.md
@@ -0,0 +1,36 @@
+# 8. Epic 3: The "Vault" & Social Recovery
+
+**Epic Goal:** To mitigate the primary risk of a decentralized identity system by introducing the optional "Vault" — a user-friendly, server-side storage for a Citizen's private key, secured by a traditional login/password. This epic will also implement the social recovery mechanism, allowing Citizens to regain access to their Vault-stored key with the help of their peers, thus adding a critical layer of safety and usability.
+
+## Story 3.1: The "Vault" Opt-In
+
+**As a** new or existing "Citizen", **I want** the option to create a "Vault" account (login/password) and store an encrypted copy of my private key on the server, **so that** I have a backup and a way to use the SYSTEM if I don't have my primary key file with me.
+
+**Acceptance Criteria:**
+1.  During the onboarding process (Story 2.2), after the private key is presented to the user, a new step must offer to create a "Vault" account.
+2.  The user must provide a password, which will be used to encrypt their private key on the client-side before it's sent to the server for storage. The server must only store the encrypted key and a salted hash of the password.
+3.  The UI must clearly explain that this is an **optional** convenience feature and that the most secure method is managing the key oneself.
+4.  A logged-in "Citizen" who did not opt-in during onboarding must have an option in their profile to create a "Vault" account later.
+
+## Story 3.2: Session Authentication via The "Vault"
+
+**As a** "Citizen" with a "Vault" account, **I want** to be able to log into a new session using my login and password, **so that** the server can sign transactions on my behalf without me needing to provide my private key file.
+
+**Acceptance Criteria:**
+1.  The main login screen must have a toggle or separate form for "Login with Vault" (username/password).
+2.  Upon successful login, the server must decrypt the user's private key using their password and hold it securely for the duration of the server-side session.
+3.  When the user performs a signable action, the request is sent to the server, which then signs the transaction with the session-stored private key before committing it to "The Main Ledger".
+4.  This flow must be distinct from the default client-side signing, where the server only receives an already-signed transaction.
+
+## Story 3.3: Social Recovery for The "Vault"
+
+**As a** "Citizen" with a "Vault" account who has forgotten their password, **I want** to initiate a recovery process that other "Citizens" can approve, **so that** I can regain access to my encrypted private key.
+
+**Acceptance Criteria:**
+1.  From the "Login with Vault" screen, there must be a "Forgot Password" link.
+2.  The user must identify themselves (e.g., by their name/public key) to initiate a recovery request. A `RECOVERY_REQUESTED` transaction is logged.
+3.  Other "Citizens" must see a notification about the pending recovery request on their dashboard.
+4.  The request UI must show who is requesting recovery and require a quorum of other "Citizens" to approve it by signing a `RECOVERY_APPROVED` transaction. (Quorum rule: 1 approval if <=4 members; 2 approvals if >=5 members).
+5.  Once the quorum is met, the server grants a temporary token, allowing the original user to reset their "Vault" password and re-encrypt their stored private key.
+
+---
diff --git a/docs/prd/epic-list.md b/docs/prd/epic-list.md
new file mode 100644
index 0000000..7fed6a3
--- /dev/null
+++ b/docs/prd/epic-list.md
@@ -0,0 +1,9 @@
+# 5. Epic List
+
+Here is the proposed high-level list of epics required to deliver the MVP. They are sequenced to build upon each other, ensuring a solid foundation is established first.
+
+1.  **Epic 1: The Foundation - "Община" Genesis & Citizen Zero:** Establish the absolute core of the system. This includes project setup, the database schema for the Ledger, and the complete, secure onboarding flow for the very first "Citizen" (the Initiator). The goal is a running application that can support a single user.
+2.  **Epic 2: Community Expansion & The First "Cell":** Focus on growing the "Община". This epic introduces the invitation system for new "Citizens" and implements the entire lifecycle of a financial "Cell" — from creation, participation by Consumers and Executors, to final payment confirmations. The goal is to have a fully functional system for managing one-time shared expenses.
+3.  **Epic 3: The "Vault" & Social Recovery:** Introduce the optional "Vault" feature. This includes creating the login/password mechanism for server-side key storage and implementing the crucial social recovery flow, where Citizens can approve a recovery request for another user. The goal is to add a layer of user-friendliness and safety for key management.
+
+---
diff --git a/docs/prd/goals-and-background-context.md b/docs/prd/goals-and-background-context.md
new file mode 100644
index 0000000..8d21f6e
--- /dev/null
+++ b/docs/prd/goals-and-background-context.md
@@ -0,0 +1,21 @@
+# 1. Goals and Background Context
+
+## Goals
+
+Based on our brief, the primary goals for the MVP are:
+*   To establish a fully functional, self-hosted system that replaces informal financial tracking with a trusted, cryptographically secure ledger.
+*   To achieve complete adoption by all members of the initial "Община" (community).
+*   To ensure every transaction is immutable, auditable, and requires the consensus of the participants involved.
+*   To create a system that is not only functional but also engaging and fast for simple, everyday tasks.
+
+## Background Context
+
+The core problem is that the current methods of managing shared domestic finances (like chat groups or spreadsheets) are inefficient, prone to error, and lack transparency. This creates friction and mental overhead for a group of friends living together. Project SYSTEM aims to solve this by providing a single, reliable source of truth that automates calculations, enforces fairness through cryptographic signatures, and introduces a unique, engaging user experience tailored to the community's culture.
+
+## Change Log
+
+| Date | Version | Description | Author |
+| :--- | :--- | :--- | :--- |
+| 2025-08-31 | 1.0 | Initial PRD draft | PM (John) |
+
+---
diff --git a/docs/prd/index.md b/docs/prd/index.md
new file mode 100644
index 0000000..ecdd0b0
--- /dev/null
+++ b/docs/prd/index.md
@@ -0,0 +1,13 @@
+# SYSTEM Project Requirements Document
+
+## Table of Contents
+
+- [Table of Contents](#table-of-contents)
+  - [1. Goals and Background Context](goals-and-background-context.md)
+  - [2. Requirements](requirements.md)
+  - [3. User Interface Design Goals](user-interface-design-goals.md)
+  - [4. Technical Assumptions](technical-assumptions.md)
+  - [5. Epic List](epic-list.md)
+  - [6. Epic 1: The Foundation - "Община" Genesis & Citizen Zero](epic-1-the-foundation-genesis-citizen-zero.md)
+  - [7. Epic 2: Community Expansion & The First "Cell"](epic-2-community-expansion-the-first-cell.md)
+  - [8. Epic 3: The "Vault" & Social Recovery](epic-3-the-vault-social-recovery.md)
diff --git a/docs/prd/requirements.md b/docs/prd/requirements.md
new file mode 100644
index 0000000..e9c3a5a
--- /dev/null
+++ b/docs/prd/requirements.md
@@ -0,0 +1,24 @@
+# 2. Requirements
+
+## Functional
+
+1.  **FR1: System Initialization:** The system must provide an interface for the first user ("Initiator") to create the "Община" and generate their initial cryptographic key pair.
+2.  **FR2: Citizen Onboarding:** The Initiator must be able to generate a unique, single-use invitation link to onboard new "Citizens". The onboarding process must include key pair generation and profile creation in the "Registry".
+3.  **FR3: Optional Key Vault:** During onboarding, a new "Citizen" must have the option to create a login/password account to store their private key in the server-side "Vault".
+4.  **FR4: Immutable Ledger:** Every state-changing action within the system (e.g., creating a Cell, joining, confirming payment) must be recorded as a new, cryptographically signed transaction in "The Main Ledger". The system must not allow direct modification or deletion of past transactions.
+5.  **FR5: Cell Creation:** Any "Citizen" must be able to create a financial "Cell" for a "Common Good", specifying the goal and the required items/costs ("Executor" roles).
+6.  **FR6: Cell Participation:** "Citizens" must be able to join a "Cell" as either an "Executor" (committing to purchase an item) or a "Consumer" (sharing the cost of the "Common Good").
+7.  **FR7: Real-Time Calculation:** The system must automatically and transparently calculate and display the financial obligations between all "Consumers" and "Executors" of a "Cell" as participants join or leave.
+8.  **FR8: Payment Confirmation:** An "Executor" must have the ability to sign a transaction confirming the receipt of payment from a specific "Consumer" for a specific "Cell".
+9.  **FR9: Social Key Recovery:** A "Citizen" who uses the "Vault" and has forgotten their password must be able to initiate a recovery process that requires cryptographic confirmation from a quorum of other "Citizens" (1 confirmation if <=4 members; 2 confirmations if >=5 members).
+
+## Non-Functional
+
+1.  **NFR1: Performance on Embedded Hardware:** The entire system (backend and database) must be optimized to run efficiently on a Raspberry Pi (Model 4 or newer recommended).
+2.  **NFR2: High-Trust Environment Security:** While designed for a trusted, private network, the application must include baseline web security practices (e.g., CSRF protection, secure headers). Direct database access should not be exposed.
+3.  **NFR3: Cryptographic Integrity:** All transactions must be signed using the Ed25519 algorithm or a similarly secure and lightweight standard. The integrity of the ledger's chain (verified by linking transaction hashes) must be maintained.
+4.  **NFR4: Multi-Currency Support:** The system must be able to handle calculations and record transactions in multiple fiat currencies (e.g., UAH, PLN, USD), with the currency specified at the "Cell" or "Plan" level.
+5.  **NFR5: Internationalization (i18n) Readiness:** The frontend architecture must be built to support multiple languages, even if the MVP only includes one language pack.
+6.  **NFR6: Usability:** The user interface for common, simple actions (like creating a quick "Cell") must be low-friction and require a minimal number of steps to encourage daily use.
+
+---
diff --git a/docs/prd/technical-assumptions.md b/docs/prd/technical-assumptions.md
new file mode 100644
index 0000000..23f336e
--- /dev/null
+++ b/docs/prd/technical-assumptions.md
@@ -0,0 +1,26 @@
+# 4. Technical Assumptions
+
+## Repository Structure: Monorepo
+
+The project will be developed within a single monorepo. This approach is chosen to simplify dependency management and ensure consistency between the frontend and backend components, especially since they will be tightly coupled and share types and logic.
+
+## Service Architecture
+
+For the MVP, the backend will be a **Monolith**. This simplifies development, deployment, and hosting on a single Raspberry Pi. The architecture should be internally modular to allow for potential future extraction of services if needed, but the initial deployment will be a single service.
+
+## Testing Requirements
+
+The project requires a robust testing strategy focused on data integrity. The minimum requirement is **Unit + Integration Testing**.
+*   **Unit Tests:** Every individual function, especially cryptographic helpers and business logic calculators, must be covered by unit tests.
+*   **Integration Tests:** These are critical to validate the end-to-end flow of transactions within "The Main Ledger". Tests must cover scenarios like: creating a "Cell", adding participants, confirming payments, and verifying that the final calculated state is correct.
+
+## Additional Technical Assumptions and Requests
+
+*   **Hosting:** The entire application must be deployable and performant on a **Raspberry Pi** (Model 4 or newer). Deployment will be managed via **Docker Compose**.
+*   **Core Tech Stack:** The primary technology stack is **Nuxt 4 (Vue 3)** for the frontend and **PostgreSQL** for the database. The backend can be implemented using Nuxt 4's server capabilities.
+*   **Styling:** Styling will be implemented using **SCSS** and **Tailwind CSS**. A component framework (e.g., Nuxt UI, PrimeVue) is anticipated and will be chosen during the architecture phase.
+*   **Cryptography:** Transaction signing will use the **Ed25519** algorithm or a similar lightweight, secure standard. The client is responsible for signing transactions unless the user opts into the server-side "Vault".
+*   **Internationalization (i18n):** The frontend application must be architected with i18n support from the ground up, even though the MVP will only ship with a single language pack.
+*   **API Design:** The API should be designed internally. No requirement for a public-facing REST/GraphQL API in the MVP, as the frontend and backend are tightly coupled.
+
+---
diff --git a/docs/prd/user-interface-design-goals.md b/docs/prd/user-interface-design-goals.md
new file mode 100644
index 0000000..34545c5
--- /dev/null
+++ b/docs/prd/user-interface-design-goals.md
@@ -0,0 +1,37 @@
+# 3. User Interface Design Goals
+
+## Overall UX Vision
+
+The user experience of SYSTEM should feel like interacting with a reliable, slightly mysterious, but ultimately transparent terminal or government console. The design must build trust by visualizing the cryptographic processes (e.g., showing transaction hashes, signed confirmations) without overwhelming the user. The primary goal is clarity and efficiency: a Citizen should always understand what's happening, what is required of them, and trust the integrity of the data presented. The overall aesthetic should lean into the thematic, "dystopian/communistic" vibe in a subtle, engaging way.
+
+## Key Interaction Paradigms
+
+*   **Low-Friction for Common Tasks:** Creating a simple "Cell" should be achievable in a few clicks. The interface should be fast and responsive.
+*   **Seamless Signing:** The process of signing transactions with the private key should be as unobtrusive as possible, perhaps by "unlocking" a session with the key rather than confirming every single action.
+*   **Visual Trust:** The UI should use visual cues to signify the status of data – e.g., a "finalized" transaction looks solid and permanent, while a "pending" transaction (in "Mushroom Mode") might appear hazy or watermarked.
+
+## Core Screens and Views
+
+For the MVP, the following core screens are necessary:
+*   **Onboarding/Setup Screen:** For the first user to create the "Община" and for new Citizens to join via an invite link.
+*   **Dashboard/Main View:** A central hub showing all active "Cells" and "Plans" requiring the user's attention or participation. It should clearly display the user's current financial state (what they owe, what is owed to them).
+*   **"Cell" Detail View:** A screen showing all information for a single "Cell": the "Common Good", all "Executors" and "Consumers", payment status for each participant, and the transaction history from "The Main Ledger".
+*   **"Cell" Creation Form:** A simple, guided form to create a new "Cell".
+*   **Profile/Keys Management View:** A section where a "Citizen" can view their public key and manage their optional "Vault" account.
+
+## Accessibility: WCAG AA
+
+The application should strive to meet WCAG 2.1 Level AA compliance to ensure it is usable by people with a wide range of disabilities.
+
+## Branding
+
+The branding will be built around the chosen thematic elements of retro-futuristic communism and dystopia. This should be reflected in:
+*   **Terminology:** Using "Citizen," "Cell," "Common Good," "Five-Year Plan" consistently throughout the UI.
+*   **Color Palette:** A limited, functional color palette, perhaps with one striking accent color (e.g., red).
+*   **Typography:** Potentially a monospaced or "terminal-like" font for key data elements to enhance the console feel.
+
+## Target Device and Platforms: Web Responsive
+
+The primary platform is a responsive web application that works seamlessly on both desktop and mobile browsers. A mobile-first design approach is recommended.
+
+---
diff --git a/docs/project-brief.md b/docs/project-brief.md
new file mode 100644
index 0000000..01e6979
--- /dev/null
+++ b/docs/project-brief.md
@@ -0,0 +1,103 @@
+# **Project Brief: SYSTEM**
+
+## Executive Summary
+
+Project SYSTEM is a self-hosted platform for communal living management, designed to bring cryptographic trust and transparency to shared domestic life. Initially focusing on financial coordination, it will manage shared expenses ("Cells") and recurring bills ("Plans") within a community ("Община"). The system's core is "The Main Ledger," an immutable, cryptographically-signed log of all transactions, ensuring a verifiable and auditable history. Identity is decentralized, based on public/private key pairs ("Citizens"), not traditional accounts, with an optional, socially-recoverable "Vault" for key storage. Key differentiators include multi-currency support, a unique dystopian/communistic theming for terminology (e.g., "Five-Year Plans" for long-term goals), and an innovative "Mushroom Mode" that allows for a "delayed finality" on decisions. Built on a Nuxt 4 + PostgreSQL stack, SYSTEM aims to be a comprehensive, modular, and engaging solution for resolving all domestic challenges.
+
+## Problem Statement
+
+A cohesive group of friends living together ("Община") lacks a centralized, transparent, and trusted system for managing shared finances and domestic responsibilities. Current methods (e.g., chat groups, spreadsheets) are prone to confusion, manual calculation errors, and a lack of clear, auditable history for who paid for what and for whom. This creates unnecessary mental overhead and friction in coordinating everything from daily groceries ("Common Goods") to recurring shared bills ("Plans"). There is a need for a system that automates calculations, ensures every participant's consensus through undeniable cryptographic proof, and brings both structure and a unique, engaging thematic experience to communal life.
+
+## Proposed Solution
+
+SYSTEM is a web application that replaces informal coordination with a structured, event-sourced platform. It operates on a single, trusted node (a self-hosted Raspberry Pi) and provides a single source of truth for all domestic agreements.
+
+**Core Concepts:**
+1.  **The Main Ledger:** An immutable, append-only log (stored in PostgreSQL) where every action (creating a "Cell," joining, confirming payment) is a signed transaction. This ensures a permanent, auditable history that cannot be altered.
+2.  **Citizen Identity:** Users ("Citizens") are identified by their public/private key pair, not by username/password. This decentralizes identity and ties all actions directly to a cryptographic signature.
+3.  **The Registry & The Vault:** A user-friendly "Registry" maps public keys to user-provided names/avatars. The optional "Vault" provides a login/password system for securely storing the private key on the server, with a social recovery mechanism requiring confirmation from other Citizens.
+4.  **Cells, Plans, and Five-Year Plans:** A flexible structure for financial coordination:
+    *   **Cells:** One-time collections for a specific "Common Good" (e.g., groceries for a soup).
+    *   **Plans:** Recurring collections (e.g., monthly internet bill).
+    *   **Five-Year Plans:** Time-bound collections for a larger goal (e.g., saving for a new appliance).
+5.  **Real-Time Coordination Flow:** The system calculates who owes whom in real-time. The flow is: Consumer joins Cell -> System calculates debt -> Consumer pays Executor -> Executor cryptographically confirms payment -> Cell moves towards completion.
+6.  **Mushroom Mode:** A unique feature allowing for "delayed finality." Actions taken in this mode are logged as `PENDING` and can be superseded by a new action within a set time frame, before being finalized in the Ledger. This preserves immutability while allowing for human flexibility.
+7.  **Push Notifications:** A proactive notification system will inform Citizens of required actions (e.g., payment confirmations, recovery requests), ensuring the system is interactive and engaging.
+
+## Target Users
+
+*   **Primary User Segment: The "Citizen"**
+    *   **Profile:** A member of a small, co-living community of friends (2-10 people) who share expenses and responsibilities. They are generally tech-savvy but may not be cryptocurrency experts. They value transparency, fairness, and efficiency.
+    *   **Behaviors:** Currently uses ad-hoc methods like messaging apps and manual calculations to manage shared finances. Participates in group decisions and activities.
+    *   **Needs:** A simple way to initiate and track shared expenses, clarity on who owes whom, a single source of truth for financial history, and an engaging user experience that fits their community's culture.
+
+## Goals & Success Metrics
+
+*   **Business/Project Objectives:**
+    *   Successfully launch a self-hosted MVP that manages shared financial "Cells" and "Plans."
+    *   Achieve 100% adoption within the initial "Община."
+    *   Create a stable, immutable, and fully auditable "Main Ledger" of all transactions.
+*   **User Success Metrics:**
+    *   Reduce the time spent on manual calculations for shared expenses to zero.
+    *   Eliminate disagreements or confusion over who paid for what.
+    *   Users feel the system is trustworthy and transparent.
+*   **Key Performance Indicators (KPIs):**
+    *   Number of "Cells" created and successfully completed per month.
+    *   Average time from "Cell" creation to completion.
+    *   User engagement (daily/weekly active "Citizens").
+
+## MVP Scope
+
+*   **Core Features (Must Have):**
+    *   **Onboarding & Identity:** First-user setup to create the "Община." Invitation system for new "Citizens." Generation and management of key pairs, with the optional "Vault" for storage.
+    *   **The Main Ledger:** Functional implementation of the append-only, signed transaction log in PostgreSQL.
+    *   **Cell Creation & Management:** Ability for any "Citizen" to create a "Cell" for a "Common Good" with defined Executor roles.
+    *   **Participation Flow:** Citizens can join as "Executors" or "Consumers." The system must calculate and display all financial obligations in real-time.
+    *   **Payment Confirmation:** Executors can cryptographically confirm they've received funds from Consumers.
+    *   **Core UI:** A basic, functional interface to view, create, and interact with "Cells."
+*   **Out of Scope for MVP:**
+    *   "Plans" and "Five-Year Plans" (recurring and long-term collections).
+    *   "Mushroom Mode."
+    *   Advanced statistics, achievements, and gamification.
+    *   Management of non-financial resources (chores, shared items).
+    *   Full i18n support (interface will be in one primary language).
+    *   Push notifications (will be handled by manually checking the UI in MVP).
+
+## Post-MVP Vision
+
+*   **Phase 2 Features:** Introduce "Plans" and "Five-Year Plans." Implement "Mushroom Mode" and the push notification system. Develop the first iteration of the "Statistics" module.
+*   **Long-term Vision:** Expand SYSTEM to be a complete domestic operating system. Introduce modules for chore tracking, managing shared inventory (food, supplies), scheduling events, and resolving other communal living challenges, all logged within The Main Ledger.
+*   **Expansion Opportunities:** Create a distributable version that other communities can easily deploy for themselves.
+
+## Technical Considerations
+
+*   **Platform Requirements:** The backend will be self-hosted on a Raspberry Pi. The frontend will be a responsive web application accessible from any modern browser.
+*   **Technology Preferences:**
+    *   **Frontend:** Nuxt 4 (Vue 3).
+    *   **Backend:** Nuxt 4 server routes or a separate Node.js framework.
+    *   **Database:** PostgreSQL.
+    *   **Cryptography:** Standard libraries for key generation (e.g., `crypto.subtle`) and signing (e.g., `noble-ed25519`).
+*   **Architecture Considerations:**
+    *   **Repository Structure:** Monorepo.
+    *   **Service Architecture:** A single monolithic service for the MVP.
+    *   **Security:** Primary security is based on cryptographic signatures. The self-hosted nature implies a trusted network environment, but basic protections (e.g., against CSRF) should be in place. All keys stored in the server-side "Vault" must be encrypted at rest.
+
+## Constraints & Assumptions
+
+*   **Constraints:**
+    *   Must run efficiently on a Raspberry Pi.
+    *   The system is designed for a high-trust environment among a small group of users. It is not intended for public, untrusted networks.
+*   **Key Assumptions:**
+    *   Users will reliably save their private keys or opt-in to the "Vault."
+    *   The single-node (Raspberry Pi) is considered the single source of truth and is assumed to be secure and available.
+    *   The "social recovery" mechanism is sufficient for key recovery and preventing unauthorized access.
+
+## Risks & Open Questions
+
+*   **Key Risks:**
+    *   **Key Management:** A user losing their private key without using the "Vault" means a permanent loss of access. The UI must be extremely clear about this responsibility.
+    *   **User Adoption:** The unique terminology and crypto concepts, while engaging, could create a learning curve. The onboarding process must be exceptionally clear and simple.
+    *   **Usability vs. Security:** The process of signing every action could become tedious. The UI/UX must make this as seamless as possible (e.g., by holding the key in a browser session).
+*   **Open Questions:**
+    *   How will database schema migrations be handled in a self-hosted environment?
+    *   What is the most user-friendly way to present transaction signing to a non-technical user?