VibeMeta Blog
Vibe Coding Life OS: 15 Prompt per Creare la Tua App
Guida Vibe Coding: crea una Life OS con 15 prompt modulari e zero spaghetti code. Genera il tuo blueprint su VibeMeta ora.
Lucenx9
Creatore di VibeMeta
Pubblicato 6 mar 2026 · Aggiornato 6 mar 2026 · 13 min di lettura ·
Sfoglia tutti gli articoli in italiano · Browse all English posts
Condividi questo articolo
Condividilo con il tuo team o salvalo per dopo.
Tutti partono allo stesso modo: "Costruiscimi un Life OS stile Notion con task, journal, habit tracker, pomodoro, spese, finanza, note vocali e AI."
Funziona per cinque minuti.
Poi arriva il secondo modulo. L'AI rimette mano a file che funzionavano, mischia i formati data, duplica lo stato, rompe la persistenza e ti lascia un'elegante montagna di spaghetti code.
Questo è il vero collo di bottiglia del vibe coding nel 2026. Non le idee. Non la UI. L'architettura.
Un vero Life OS non è una singola app. È l'incastro di più sistemi:
- stato della lista task
- editing del journal
- rendering Markdown
- parsing CSV
- calcoli finanziari
- logica del timer
- speech-to-text
- sintesi AI
- widget cross-modulo
- persistenza condivisa
- tema condiviso
- export/import condiviso
Se chiedi a Cursor o Claude Code di costruire tutto in una botta sola, costringi il modello a inventarsi l'architettura mentre prova già a consegnare il prodotto.
Da lì parte il context drift. Da lì il codice stabile viene riscritto senza motivo. Da lì "veloce" diventa "perché il timer mi ha cancellato le abitudini?"
Il segreto non è un mega-prompt più lungo.
Il segreto è lavorare per moduli.
Prima di incollare il Prompt #1, genera un vero Blueprint / PRD.
Questa è l'unica assicurazione seria contro bug, regressioni e contro un'AI che si inventa l'architettura fino a sabotarla.
Usa VibeMeta per generare prima il tuo Blueprint gratuito, salvalo nel repo come /docs/BLUEPRINT.md e trattalo come fonte unica di verità per tutto quello che viene dopo.
Il tuo Blueprint deve bloccare:
- problema e obiettivi
- cosa l'app non farà
- flussi utente
- modelli dati canonici
- confini dei moduli
- definition of done
- ordine di costruzione
I prompt qui sotto sono i mattoni. VibeMeta è la planimetria.
Inizia da qui: https://vibemeta.app/
- Genera prima il Blueprint
- Salvalo come
/docs/BLUEPRINT.md - Incolla un prompt per volta in Cursor o Claude Code
- Non passare al Prompt #2 finché il Prompt #1 non è verificato
- Fai un commit dopo ogni prompt riuscito
La Fase 1 fissa stack, regole del repo e contratto di persistenza prima di toccare i moduli veri.
Prompt 1 - Inizializzazione stack
You are a senior full-stack engineer working inside this repository via Cursor or Claude Code.
Before writing any code, read /docs/BLUEPRINT.md. If that file does not exist, stop immediately and tell me to create it first.
Goal:
Initialize a modular Life OS web app using Next.js 15 App Router, TypeScript, Tailwind CSS, shadcn/ui, Zod, date-fns, Recharts, react-hook-form, @hookform/resolvers, lucide-react, clsx, tailwind-merge, Papa Parse, react-markdown, remark-gfm, and Framer Motion.
Constraints:
- Setup only. Do NOT implement any feature modules yet.
- Prefer pnpm.
- Keep changes reviewable and PR-sized.
- No auth, no backend, no cloud sync unless explicitly required by /docs/BLUEPRINT.md.
- Use a feature-folder architecture from day one.
- All end-user visible UI copy must be in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Tasks:
1) Scaffold the Next.js app with App Router, TypeScript, Tailwind, and ESLint.
2) Install and initialize shadcn/ui.
3) Create this folder structure:
/app
/components
/context
/features/todo
/features/journal
/features/expenses
/features/habits
/features/pomodoro
/features/finance
/features/voice-journal
/lib
/types
/docs
4) Create a minimal app shell with:
- left sidebar navigation
- top header
- /app/dashboard/page.tsx placeholder
5) Create CLAUDE.md and .cursorrules with strict repo rules:
- always read /docs/BLUEPRINT.md before implementation
- one prompt = one measurable deliverable
- no giant refactors
- run typecheck + lint before marking work done
- all user-facing UI copy must be in Italian
6) Create /docs/ARCHITECTURE.md, /docs/DATA_MODEL.md, /docs/UI_STATE.md, /docs/PLAN.md, and /docs/TASKS.md as starter docs.
7) Run typecheck + lint and fix any setup issues.
Deliverable:
- The app boots into a clean dashboard shell.
- Print a concise summary of commands run, files created, and any manual follow-up.
- Stop after setup.Prompt 2 - Setup del Local Storage e della Context API globale
Read these files first:
- /docs/BLUEPRINT.md
- /docs/ARCHITECTURE.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
Implement the app foundation only: versioned local-first persistence plus a THIN global React Context API layer. Do NOT build feature UIs yet.
Architecture rules:
- Use localStorage with schema validation and versioned migrations.
- React Context is allowed only as a global orchestration layer.
- Do NOT put every module's raw business state into Context if it belongs in a feature repository/service.
- Each feature must own its own schema, repo, and selectors.
- Prevent SSR hydration mismatch.
- All end-user visible UI copy must be in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Work:
1) Create /lib/storage with:
- storage keys registry
- versioned serializers
- safe parse helpers
- migration helpers
- corruption fallback behavior
2) Create /context/app-context.tsx and typed hooks:
- AppProvider
- useAppContext
- useAppSelectors
- useAppActions
3) The global context should manage only shared cross-module concerns:
- hydration status
- theme mode
- dashboard-level filters
- reminder queue
- command palette open/close state
- cross-module refresh signals
4) Add a StoreHydration boundary component so the app does not flash broken UI on reload.
5) Wire the provider into the root layout.
6) Document the storage strategy in /docs/ARCHITECTURE.md and the global app contract in /docs/UI_STATE.md and /docs/DATA_MODEL.md.
Definition of Done:
- App boots cleanly.
- Global context is fully typed.
- Storage utilities are reusable and version-aware.
- No feature module UI exists yet.
- Typecheck + lint pass.
Stop after this foundation layer is complete.La Fase 2 costruisce un modulo alla volta. Un prompt per volta. Niente riscritture cross-modulo. Niente scorciatoie furbe.
Prompt 3 - Todo list con Local Storage
Implement ONLY the Todo module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
- /docs/TASKS.md
Constraints:
- Local-first persistence only.
- Use the shared storage helpers from /lib/storage.
- Do not touch unrelated feature modules.
- Store due dates as local date strings in YYYY-MM-DD format.
- Use UUIDs for stable IDs.
UI localization:
- All end-user visible UI copy must be in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Build:
1) /features/todo/schema.ts
2) /features/todo/types.ts
3) /features/todo/repo.ts
4) /features/todo/services.ts
5) /features/todo/components/*
6) /app/todo/page.tsx
Todo requirements:
- Task fields: id, title, optional notes, status, priority, category, dueDate, createdAt, updatedAt
- Add task
- Edit task
- Toggle complete
- Delete task with confirmation
- Search tasks
- Filters: All, Open, Completed, Due Soon, Overdue
- Bulk actions: Complete All, Clear Completed
- Undo destructive actions via toast
- Export tasks to JSON
- Import tasks from JSON with validation and merge-by-id
Documentation updates:
- Update /docs/DATA_MODEL.md with the final Todo schema
- Update /docs/UI_STATE.md with filters, empty states, and import/export behavior
Definition of Done:
- Todo page works end-to-end in the browser
- Data persists across reloads
- Invalid imports fail safely
- No console errors
- Typecheck + lint pass
Stop after the Todo module is complete.Prompt 4 - Daily journal con editor Markdown e sintesi AI
Implement ONLY the Daily Journal module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- Local-first persistence only
- Markdown is the source format
- AI summaries must be abstracted behind a provider interface
- If no AI provider key/config exists, create a deterministic local fallback summarizer so the feature remains testable
- Do not modify other modules
UI localization:
- All end-user visible UI copy must be in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Build:
1) /features/journal/schema.ts
2) /features/journal/types.ts
3) /features/journal/repo.ts
4) /features/journal/summary-provider.ts
5) /features/journal/components/*
6) /app/journal/page.tsx
Journal requirements:
- Entry fields: id, title, markdown, mood, tags, createdAt, updatedAt
- Create, edit, delete entries
- Markdown editor with live preview
- Search by title/content
- Filter by mood or tag
- "Generate summary" action for each entry
- Store generated summaries locally with the entry
- Draft-safe editing so refresh does not destroy unsaved work
Documentation updates:
- Update /docs/DATA_MODEL.md with the journal schema
- Update /docs/UI_STATE.md with editor states, summary states, and fallback behavior
Definition of Done:
- Users can write Markdown entries and preview them
- AI summary generation works through a provider abstraction
- Local fallback summary works if no external AI is configured
- Entries persist across reloads
- Typecheck + lint pass
Stop after the Daily Journal module is complete.Prompt 5 - Expense tracker con grafici Recharts e import CSV
Implement ONLY the Expense Tracker module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- Local-first persistence only
- Store money as integer cents to avoid floating-point errors
- Store dates as local date strings YYYY-MM-DD
- Use Papa Parse for CSV import
- Use Recharts for all charts
- Do not touch unrelated feature modules
UI localization:
- All end-user visible UI copy must be in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Build:
1) /features/expenses/schema.ts
2) /features/expenses/types.ts
3) /features/expenses/repo.ts
4) /features/expenses/money.ts
5) /features/expenses/csv.ts
6) /features/expenses/selectors.ts
7) /features/expenses/components/*
8) /app/expenses/page.tsx
Expense Tracker requirements:
- Fields: id, date, amountCents, category, merchant, note, source
- Add, edit, delete expenses
- Filter by month and category
- Import CSV with preview + validation
- Reject invalid rows safely
- Summary cards for total spend, average spend, and top category
- Recharts visualizations:
- spend by category
- spend trend by month
Documentation updates:
- Update /docs/DATA_MODEL.md with the expense schema
- Update /docs/UI_STATE.md with the import flow and chart states
Definition of Done:
- CRUD works end-to-end
- CSV import validates and previews before save
- Charts match the underlying aggregation math
- No NaN or formatting bugs
- Typecheck + lint pass
Stop after the Expense Tracker module is complete.Prompt 6 - Habit tracker con calendario stile GitHub
Implement ONLY the Habit Tracker module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- Store habit completion using local date strings only: YYYY-MM-DD
- No timezone objects in persisted data
- All streak and progress logic must be implemented with pure functions
- Do not modify unrelated modules
UI localization:
- All end-user visible UI copy must be in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Build:
1) /features/habits/schema.ts
2) /features/habits/types.ts
3) /features/habits/repo.ts
4) /features/habits/streak.ts
5) /features/habits/selectors.ts
6) /features/habits/components/*
7) /app/habits/page.tsx
Habit Tracker requirements:
- Fields: id, name, cadence, optional goalPerWeek, createdAt, completedDates
- Add, edit, delete habits
- Mark today complete/incomplete
- Compute current streak
- Compute longest streak
- Compute weekly completion rate
- Show a GitHub-style heatmap grid for the last 90 days
- Show Today, This Week, and Streak summary cards
Documentation updates:
- Update /docs/DATA_MODEL.md with habit schema and date rules
- Update /docs/UI_STATE.md with heatmap and summary states
Definition of Done:
- Streak logic is correct
- Heatmap updates instantly when completion changes
- Data persists across reloads
- Typecheck + lint pass
Stop after the Habit Tracker module is complete.Prompt 7 - Pomodoro timer + dashboard statistiche
Implement ONLY the Pomodoro module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- Local-first persistence only
- Timer must survive reloads using persisted timestamps, not fragile in-memory countdown math
- Keep timing logic separate from UI
- Do not touch unrelated modules
UI localization:
- All end-user visible UI copy must be in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Build:
1) /features/pomodoro/schema.ts
2) /features/pomodoro/types.ts
3) /features/pomodoro/repo.ts
4) /features/pomodoro/timer-engine.ts
5) /features/pomodoro/selectors.ts
6) /features/pomodoro/components/*
7) /app/pomodoro/page.tsx
Pomodoro requirements:
- Modes: focus, short break, long break
- Configurable durations
- Start, pause, resume, reset
- Persist active session state across refresh
- Track completed sessions history
- Statistics dashboard with:
- focus minutes today
- sessions completed today
- sessions completed this week
- average session length
- completion streak by day
- Optional local notification when a session ends
Documentation updates:
- Update /docs/DATA_MODEL.md with timer/session schema
- Update /docs/UI_STATE.md with timer states and dashboard states
Definition of Done:
- Timer remains accurate after refresh
- Statistics reflect the stored session history
- No double-counting or ghost sessions
- Typecheck + lint pass
Stop after the Pomodoro module is complete.Prompt 8 - Personal finance tracker con import da banca
Implement ONLY the Personal Finance module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- This module is separate from the simpler Expense Tracker
- Reuse shared money/date helpers where appropriate
- Local-first persistence only
- Bank import must be validated and deduplicated
- Do not modify unrelated modules
UI localization:
- All end-user visible UI copy must be in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Build:
1) /features/finance/schema.ts
2) /features/finance/types.ts
3) /features/finance/repo.ts
4) /features/finance/import-bank.ts
5) /features/finance/selectors.ts
6) /features/finance/components/*
7) /app/finance/page.tsx
Personal Finance requirements:
- Account fields: id, name, type, currency, openingBalanceCents, currentBalanceCents
- Transaction fields: id, accountId, date, amountCents, direction, category, description, source
- Add/edit/delete accounts
- Import bank CSV with column-mapping preview
- Deduplicate imported transactions using a stable fingerprint strategy
- Show monthly cash flow
- Show account balances
- Show net cash position
- Show recurring income/expense summary if supported by the Blueprint
Documentation updates:
- Update /docs/DATA_MODEL.md with account and transaction schemas
- Update /docs/UI_STATE.md with import mapping and dashboard states
Definition of Done:
- Bank CSV import works with preview and validation
- Duplicate rows are not re-imported
- Balances and cash-flow widgets are correct
- Typecheck + lint pass
Stop after the Personal Finance module is complete.Prompt 9 - Voice journal con speech-to-text e sintesi AI
Implement ONLY the Voice Journal module.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- /docs/PLAN.md
Constraints:
- Local-first persistence only
- Use the Web Speech API for speech-to-text if available
- If speech recognition is unavailable, provide a manual transcript fallback
- AI summaries must use a provider interface with a deterministic local fallback
- Do not modify unrelated modules
UI localization:
- All end-user visible UI copy must be in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Build:
1) /features/voice-journal/schema.ts
2) /features/voice-journal/types.ts
3) /features/voice-journal/repo.ts
4) /features/voice-journal/transcription.ts
5) /features/voice-journal/summary-provider.ts
6) /features/voice-journal/components/*
7) /app/voice-journal/page.tsx
Voice Journal requirements:
- Fields: id, title, transcript, summary, mood, tags, createdAt, updatedAt
- Record/transcribe voice input when supported
- Manual transcript entry fallback
- Create, edit, delete entries
- Generate AI summary for each entry
- Search by transcript/title/tag
- Persist transcript and summary locally
Documentation updates:
- Update /docs/DATA_MODEL.md with the voice journal schema
- Update /docs/UI_STATE.md with recording, fallback, and summary states
Definition of Done:
- Voice capture/transcription flow works when supported
- Manual fallback works when speech APIs are unavailable
- AI summary generation is abstracted and testable
- Typecheck + lint pass
Stop after the Voice Journal module is complete.La Fase 3 unisce il sistema, aggiunge l'assistente, ripulisce i confini tra moduli, risolve i conflitti, rifinisce la UX e chiude con il passaggio di sicurezza finale.
Prompt 10 - Dashboard tutto-in-uno (Life OS)
Implement the unified Life OS dashboard.
Read first:
- /docs/BLUEPRINT.md
- /docs/ARCHITECTURE.md
- /docs/UI_STATE.md
- /docs/PLAN.md
- all existing feature selectors/services
Constraints:
- Dashboard must consume only public selectors/services from each feature
- Do NOT reach into internal module implementation details
- Do NOT rewrite working feature logic
- Focus on composition, not reinvention
UI localization:
- All end-user visible UI copy must be in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Build:
1) /app/dashboard/page.tsx
2) Any small shared dashboard widget components under /components or /features/*/components as appropriate
Dashboard requirements:
- Responsive widget-based layout
- Todo widget: due today, overdue count, quick-add shortcut
- Daily Journal widget: latest entry + latest AI summary preview
- Expense widget: current month total + top category
- Habit widget: habits completed today + best active streak
- Pomodoro widget: focus minutes today + next timer action
- Personal Finance widget: current cash flow snapshot
- Voice Journal widget: latest transcript summary
- Every widget links to its full module page
Documentation updates:
- Update /docs/UI_STATE.md with the final dashboard layout and widget rules
Definition of Done:
- Dashboard numbers are correct
- Each module still works independently
- No widget bypasses module boundaries
- Typecheck + lint pass
Stop after the dashboard is complete.Prompt 11 - Integrazione di un AI agent che gestisce task e reminder
Implement an AI assistant layer for the Life OS without allowing silent state mutations.
Read first:
- /docs/BLUEPRINT.md
- /docs/ARCHITECTURE.md
- /docs/UI_STATE.md
- existing feature selectors/services
- /context/app-context.tsx
Constraints:
- The AI agent may read state through typed selectors only
- The AI agent must propose actions before applying them
- No silent writes
- If no external AI is configured, provide a deterministic mock agent
- Reminders must be stored locally
- Do not rewrite unrelated modules
UI localization:
- All end-user visible UI copy must be in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Build:
1) /features/assistant/types.ts
2) /features/assistant/agent-provider.ts
3) /features/assistant/tooling.ts
4) /features/assistant/components/*
5) Integrate the assistant into the dashboard or app shell
Assistant capabilities:
- Create a task from natural language
- Suggest a reminder
- Summarize "today so far"
- Suggest the next Pomodoro block
- Flag overspending trends from finance/expenses
- Turn a voice transcript into a task suggestion
UX rules:
- Show proposed actions in a review card
- Require user confirmation before applying changes
- Log accepted/rejected suggestions in local state
Documentation updates:
- Update /docs/UI_STATE.md with assistant flows and confirmation rules
Definition of Done:
- Assistant can read app state safely
- Suggested actions are reviewable and confirmable
- No silent mutations occur
- Typecheck + lint pass
Stop after the assistant layer is complete.Prompt 12 - Refactoring per isolare i componenti
Perform a refactor pass focused ONLY on modular boundaries and component isolation.
Read first:
- /docs/BLUEPRINT.md
- /docs/ARCHITECTURE.md
- /docs/PLAN.md
- the full existing repository
Constraints:
- No feature additions
- No visual redesign
- No business-logic rewrites unless strictly required to preserve behavior during extraction
- Prefer small file moves and public API cleanup over clever architecture experiments
UI localization:
- Preserve Italian for all end-user visible UI copy.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Goals:
- Reduce coupling
- Make each feature easier to maintain
- Prepare the repo for future additions without context collapse
Work:
1) Identify oversized files, mixed concerns, and hidden cross-module dependencies
2) Extract shared UI primitives where duplication is legitimate
3) Ensure each feature exposes a clean public surface:
- schema
- types
- repo
- selectors
- components
4) Add or clean up barrel exports where useful
5) Remove dead code and duplicate helpers
6) Update /docs/ARCHITECTURE.md with the final module boundaries
Definition of Done:
- Module boundaries are cleaner than before
- No behavior regressions
- Imports are simpler and more intentional
- Typecheck + lint pass
Stop after the refactor pass is complete.Prompt 13 - Risoluzione conflitti di stato tra i vari moduli
Audit and fix cross-module state conflicts across the entire Life OS.
Read first:
- /docs/BLUEPRINT.md
- /docs/ARCHITECTURE.md
- /docs/DATA_MODEL.md
- /docs/UI_STATE.md
- the full repository
Constraints:
- Keep each module's ownership clear
- Do not collapse everything into one mega-store
- Fix conflicts at the contract level: data format, selector boundaries, hydration, imports, storage keys
UI localization:
- Preserve Italian for all end-user visible UI copy.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Audit for:
- inconsistent date formats
- inconsistent money formats
- storage key collisions
- duplicate entity IDs
- stale selectors
- hydration mismatch
- hidden writes across modules
- duplicate imports/exports of the same concept
Implement:
1) Canonical shared rules:
- local dates use YYYY-MM-DD
- money uses integer cents
- IDs use crypto.randomUUID()
- storage keys are namespaced per module
2) Integrity checks on app boot and import
3) Safer cross-module refresh signals through the global context
4) Any missing type guards or validation needed to stop invalid state propagation
Documentation updates:
- Update /docs/DATA_MODEL.md and /docs/ARCHITECTURE.md with the final cross-module contracts
Definition of Done:
- No module corrupts another module's state
- Shared formats are consistent
- App reload and import flows remain stable
- Typecheck + lint pass
Stop after the state-conflict audit and fixes are complete.Prompt 14 - Polishing UI/UX: animazioni, dark mode coerente
Execute a UI/UX polish pass across the whole Life OS.
Read first:
- /docs/BLUEPRINT.md
- /docs/UI_STATE.md
- the existing UI components and routes
Constraints:
- Preserve existing business logic
- Focus on consistency, accessibility, motion, and dark mode coherence
- Only make structural UI changes that improve usability
UI localization:
- All end-user visible UI copy must remain in Italian.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Polish goals:
- consistent spacing, typography, and card hierarchy
- coherent dark mode
- smooth but restrained animations
- keyboard accessibility
- empty states, loading states, and scroll behavior that feel intentional
Work:
1) Standardize button, input, card, badge, and dialog usage across modules
2) Use Framer Motion for subtle transitions where it improves perceived quality
3) Ensure dark mode styling is consistent in every route
4) Add skeleton/loading placeholders where needed
5) Prevent long lists from breaking layout; make them scroll internally
6) Improve dashboard scanability and mobile responsiveness
7) Add a Settings page theme toggle if not already present
Documentation updates:
- Update /docs/UI_STATE.md with the final UI behavior and visual consistency notes
Definition of Done:
- The app feels cohesive
- Mobile and desktop layouts both work
- Dark mode is consistent
- No logic regressions
- Typecheck + lint pass
Stop after the polish pass is complete.Prompt 15 - Check sicurezza e salvataggio dati con export JSON
Perform a final security and data-portability pass across the Life OS.
Read first:
- /docs/BLUEPRINT.md
- /docs/DATA_MODEL.md
- /docs/ARCHITECTURE.md
- the full repository
Constraints:
- Keep the app local-first
- Validate every import path
- Do not weaken feature isolation
- Preserve existing UX unless needed for safety
UI localization:
- Preserve Italian for all end-user visible UI copy.
- Keep source code, file names, variables, function names, comments, and prompts in English.
Work:
1) Create a full-app JSON export/import flow in /app/settings/page.tsx
2) Create /lib/backup.ts to orchestrate export/import for all modules:
- todo
- journal
- expenses
- habits
- pomodoro
- finance
- voice journal
- assistant state if applicable
3) Add versioned backup schema validation with Zod
4) Add an import preview/diff summary before applying a restore
5) Sanitize Markdown rendering paths to reduce XSS risk
6) Validate CSV imports defensively
7) Fail safely on corrupt or partial JSON
8) Update docs with backup schema and versioning policy
Definition of Done:
- A single JSON export can restore the full app in a clean browser profile
- Corrupt imports fail safely
- Markdown and CSV flows are handled defensively
- Typecheck + lint pass
Stop after the final security + backup pass is complete.Questi 15 prompt funzionano. Ma se salti l'architettura, possono farti male.
Ed è proprio qui che la maggior parte dei progetti Life OS deraglia.
Il motivo per cui la maggior parte degli esperimenti "build me a Life OS" implode non è che Cursor sia scarso o che Claude Code sia debole.
Il problema è provare a spedire sette prodotti dentro un solo contesto AI senza un vero piano.
È lì che arrivano gli spaghetti code.
È lì che sbatti contro il muro della complessità.
È lì che l'AI inizia ad "aiutarti" nel modo sbagliato e ti rompe codice che prima funzionava.
Quindi sì, usa i prompt.
Ma fai prima la cosa giusta: genera il Blueprint su VibeMeta, blocca l'architettura e poi esegui un prompt per volta.
Parti dal Blueprint
Definisci prima l'architettura, poi esegui i 15 prompt con più controllo e meno drift.
Prossimo passo
Vuoi un blueprint completo su questo tema? Apri il generatore con l'idea precompilata.
Scritto da Lucenx9
Builder e creatore di VibeMeta. Costruisce strumenti per chi fa vibe coding.
Potrebbe interessarti
Cursor vs Claude Code vs Codex per chi inizia: cosa conta davvero nel vibe coding
4 min di lettura
The 2026 Vibe Coding Cheat Sheet: gli unici prompt che ti servono per Cursor, Claude Code e Codex
6 min di lettura
L'AI ti ha rotto di nuovo l'app? Guida alla Sopravvivenza per il Debugging nel Vibe Coding
5 min di lettura
Pronto a costruire? Genera il tuo blueprint.
Da idea a piano completo in 30 secondi.
Apri il Generatore