# Build Your Personal AI Operating System in Seven Days Create an owned memory system, focused daily dashboard, intelligent task capture flow, and practical review routine based on the workflow demonstrated in the source. ## What you will achieve By the end of Day 7, you will have a tested V1 personal operating system with a structured Supabase memory database, a custom dashboard, task prioritization, habits, goals, journaling, calendar space, secure access, backups, and a clear path for adding Telegram voice capture. ## Who this is for Busy professionals, founders, creators, and operators who want a custom system for capturing tasks, organizing priorities, and preserving personal context for AI assistance. **Difficulty:** Intermediate ## Start Here Understand the system, prepare the required tools, and collect the complete build kit before beginning. ### Orientation: Understand the Personal Operating System You Will Build **Time:** 12 minutes ## Purpose This tutorial turns the source workflow into a focused seven-day build. The central idea is simple: your database is the durable memory, while your dashboard is a replaceable interface for viewing and updating that memory. ## The V1 system Your first version will contain: 1. A database for tasks, categories, habits, goals, journal entries, and reusable memory. 2. A dashboard showing key tasks, habits, goals, and calendar space. 3. A task inbox that can accept text immediately and voice later. 4. An AI classification step that proposes category and priority. 5. A journal that stores both a summary and the original entry. 6. Security, backup, testing, and iteration procedures. ## How to approach the build 1. Start with the pain points that cause missed work. 2. Store data before polishing the interface. 3. Build one reliable capture route before adding voice. 4. Test every write, refresh, edit, completion, and archive action. 5. Use the system daily so real friction determines later changes. ## Example A captured message such as `Send the revised proposal to Acme before Friday afternoon` should become a task with a business category, a due date for Friday, and a high priority proposal that you can confirm. ## Tangible result You now understand the intended V1, its major components, and the principle that owned memory matters more than any single dashboard design. ### Setup: Prepare the Accounts, Tools, and Safety Boundaries **Time:** 20 minutes ## Purpose Prepare a safe workspace without placing sensitive data or secret keys inside prompts, screenshots, or source control. ## Prerequisites You need: 1. Access to Claude Code, Codex, or another coding assistant capable of editing an application. 2. A Supabase project for the memory database. 3. A local code editor and terminal. 4. A deployment target that can run server functions, such as the Vercel function approach described in the source. 5. Optional accounts for Telegram, Google Calendar, OpenAI Whisper, and an AI model API. ## Setup steps 1. Create a private project folder named `personal-os`. 2. Create separate development and production database projects if your workflow permits. 3. Create a local environment file named `.env.local`. 4. Add secret values only to that file and your deployment provider's secret settings. 5. Add `.env.local` to `.gitignore` before making a commit. 6. Decide which data is safe for V1. Begin with ordinary tasks and test journal entries, not banking credentials, medical records, or confidential client documents. 7. Write down one recovery route, such as a recurring database export. ## Example environment names ```text SUPABASE_URL= SUPABASE_ANON_KEY= SUPABASE_SERVICE_ROLE_KEY= AI_API_KEY= TELEGRAM_BOT_TOKEN= TELEGRAM_WEBHOOK_SECRET= ``` Leave values blank until the relevant integration is configured. ## Tangible result You have a private workspace, a database project, named environment variables, and clear safety boundaries for your first build. ### Free Asset Kit: Use the Centralized Build Kit **Time:** 10 minutes ## Purpose The asset kit contains the worksheets, prompts, database schema, tests, and operational checks used throughout the tutorial. ## Included assets 1. `v1-requirements.csv`: define pain points, modules, inputs, outputs, and acceptance criteria. 2. `architecture-prompt.txt`: instruct a coding assistant to scaffold the application. 3. `supabase-schema.sql`: create the core owned-memory tables and access policies. 4. `task-classification-prompt.txt`: classify captured text into a structured task proposal. 5. `acceptance-tests.csv`: test capture, refresh, completion, archiving, and privacy behavior. 6. `security-backup-checklist.txt`: review access, secrets, backups, and recovery. 7. `daily-review-prompts.txt`: run morning, evening, and weekly reviews. ## Steps 1. Save the kit beside your project folder. 2. Open `v1-requirements.csv` in a spreadsheet application. 3. Keep prompt files available for your coding assistant and AI model configuration. 4. Run the SQL file only after reviewing the Day 2 database lessons. 5. Reserve the tests and security checklist for repeated use during Days 4 through 7. ## Example organization ```text personal-os/ app/ assets/ .env.local .gitignore ``` ## Tangible result You have one centralized set of reusable files for planning, building, testing, and operating the personal OS. ## Day 1: Define a Personal OS That Solves Your Real Bottlenecks Turn vague productivity ambitions into a small, testable V1 based on capture failures and daily decisions. ### Study: Extract the Architecture and Operating Principles **Time:** 18 minutes ## Purpose Identify the source system's essential architecture before choosing features. ## Steps 1. Separate the system into four layers: capture, processing, memory, and interface. 2. Map the demonstrated tools to those layers. 3. Note that Telegram accepts mobile text or voice, Whisper transcribes voice, AI classifies the text, Supabase stores the data, and the dashboard displays it. 4. Record the distinction between active information and stable reference material. The source keeps active tasks in the application while retaining some big-picture information elsewhere. 5. Note the implementation warning: custom systems provide flexibility but require debugging and continuous improvement. ## Architecture example ```text Capture: dashboard text, desktop dictation, Telegram voice Processing: transcription, classification, prioritization Memory: Supabase tables and archives Interface: home dashboard, CRM, journal, habits, goals, calendar ``` ## Design principle Do not begin by copying every source module. Nutrition and finance were useful to the source creator, but your V1 should reflect your own repeated problems. ## Tangible result You have a four-layer architecture and a clear rule for deciding which source features belong in your V1. ### Learn: Find the Moments Where Tasks and Context Are Lost **Time:** 25 minutes ## Purpose Build around observable failures instead of a generic wish to become more productive. ## Steps 1. Review the last seven days of messages, notes, calendar events, and unfinished tasks. 2. List five moments when something was forgotten, recorded too late, or stored in the wrong place. 3. For each moment, record where you were, what you needed to capture, and why the current method failed. 4. Estimate the consequence using a simple label: low inconvenience, delayed work, missed commitment, or material risk. 5. Select the two failures that recur most often. ## Example ```text Failure: Client follow-up stayed in a chat thread. Context: I was away from my desk. Cause: Opening the task system required too many steps. Consequence: Delayed work. Required capability: Mobile capture in under 30 seconds. ``` The source emphasizes this exact class of problem. A system that depends on remembering to open a separate application will not reliably capture work. ## Tangible result You have two evidence-based bottlenecks that your personal OS must solve. ### Build: Write the V1 Scope and Acceptance Criteria **Time:** 35 minutes ## Purpose Convert your bottlenecks into a build small enough to finish and test. ## Steps 1. Open `v1-requirements.csv`. 2. Keep the core task, habit, goal, journal, and memory rows if they fit your needs. 3. Edit the pain point and acceptance criterion columns using measurable language. 4. Mark integrations such as Telegram, calendar, nutrition, and finance as either V1, later, or excluded. 5. Limit the home dashboard to information you need to see every day. 6. Define the first useful workflow from capture to archive. ## Copy-ready V1 statement ```text My V1 captures a task in under 30 seconds, stores it in my own database, proposes a category and priority, lets me select three to five key tasks, and preserves completed work in an archive. It also records habits, goals, and daily journal entries. Voice, finance, and health integrations will be added only after the core workflow is reliable. ``` ## Example acceptance criterion ```text After I submit a task and refresh the dashboard, the same task remains visible with no duplicated record. ``` ## Tangible result You have a written V1 boundary and acceptance criteria that can guide both you and your coding assistant. ### Checkpoint: Approve the Build Boundary Before Writing Code **Time:** 15 minutes ## Purpose Prevent feature sprawl before database and interface work begins. ## Steps 1. Read every V1 requirement aloud. 2. Ask whether it directly solves one of your two selected bottlenecks. 3. Move anything without a direct connection into a later list. 4. Confirm that finance data is excluded unless you already have a secure and reliable source. The source treats finance as a separate, deeper integration. 5. Confirm that your V1 can be tested with non-sensitive sample data. 6. Freeze the scope until the end of Day 6. ## Approval questions ```text Can I explain the V1 in one paragraph? Can I test every feature within one day? Does each module have a clear input and output? Have I excluded features that are merely interesting? Can the system still be useful if voice capture is delayed? ``` If any answer is no, simplify the requirements. ## Tangible result You finish Day 1 with an approved, testable scope rather than an open-ended application idea. ## Day 2: Create an Owned Memory System in Supabase Design and install the database that will remain valuable even if the dashboard changes. ### Learn: Model Durable Memory Before Designing Screens **Time:** 25 minutes ## Purpose Create a data model that separates durable records from temporary interface choices. ## Core entities 1. Categories group related areas such as content, products, operations, finance, legal, or personal administration. 2. Tasks record work, priority, status, due date, source, and archive state. 3. Habits and habit items represent routines with smaller required actions. 4. Habit logs record what was completed on a particular date. 5. Journal entries preserve both summarized and raw reflections. 6. Goals keep weekly and monthly outcomes visible. 7. Memory items store notes, links, risks, and summaries associated with categories. ## Steps 1. Review your V1 requirements. 2. Assign each input to one entity. 3. Assign each dashboard card to a database query. 4. Add timestamps to records that may need auditing or sorting. 5. Prefer archiving to deletion for completed tasks. ## Example mapping ```text Input: Evening voice reflection Stored as: Journal entry Fields: entry date, raw text, summary, created timestamp Displayed in: Journal history and daily review ``` ## Tangible result You have a data model that can support different future interfaces without losing the underlying memory. ### Build: Install the Core Database Schema **Time:** 40 minutes ## Purpose Create the database tables, relationships, indexes, and owner-based access policies used by the V1. ## Steps 1. Open your Supabase SQL editor. 2. Review `supabase-schema.sql` and confirm the table names match your V1. 3. Run the script in your development project. 4. Confirm that the following tables exist: `categories`, `tasks`, `habits`, `habit_items`, `habit_logs`, `journal_entries`, `goals`, and `memory_items`. 5. Confirm row level security is enabled. 6. Sign in through your application before attempting normal client-side writes, because the policies require an authenticated owner. ## Verification query ```sql select table_name from information_schema.tables where table_schema = 'public' order by table_name; ``` ## Expected behavior An authenticated user should access only rows where `user_id` matches that user's authentication identifier. A different signed-in user should not see those rows. Do not place a service role key in browser code. It belongs only in protected server settings when a trusted server operation genuinely requires it. ## Tangible result Your Supabase project contains a structured, owner-scoped memory system ready for application data. ### Build: Seed Categories and Realistic Test Records **Time:** 30 minutes ## Purpose Give the interface useful development data without exposing private information. ## Steps 1. Sign in through the application so you have a valid user identifier. 2. Create three categories relevant to your life or work. 3. Add five ordinary test tasks across those categories. 4. Add one weekly goal and one monthly goal. 5. Create one habit with at least two habit items. 6. Add one fictional journal entry that contains no confidential information. ## Example records ```text Categories: Business Operations, Content, Personal Administration Tasks: Send revised proposal, Review content outline, Renew software license Weekly goal: Publish two videos Monthly goal: Ship the client onboarding update Habit: Morning creative session Habit items: Review current research, Write three ideas ``` Use the application or authenticated database client for inserts. Avoid manually assigning another user's identifier. ## Check Refresh the data view and verify that every record remains present. Persistence after refresh is a core requirement because the source encountered failures where records appeared to save but were later missing. ## Tangible result Your database contains safe, realistic records that can drive interface development and persistence testing. ### Checkpoint: Prove That Memory Persists and Remains Owner Scoped **Time:** 20 minutes ## Purpose Verify the back end before depending on it as your personal memory. ## Steps 1. Create a test task through an authenticated path. 2. Refresh the page and confirm it remains. 3. Edit its title, refresh again, and confirm the edit remains. 4. Mark it complete and confirm it is archived rather than removed permanently. 5. Sign out and confirm protected records are unavailable. 6. If possible, use a second test account and confirm it cannot read the first account's records. 7. Record any failure before beginning interface work. ## Example test record ```text Title: Confirm persistence test Priority: medium Status: inbox Source: manual ``` ## Pass condition The record survives refreshes, respects edits, moves to the archived state when completed, and is visible only to its owner. If a test fails, inspect authentication, row level security policies, application error handling, and the exact database response. Do not hide write failures behind optimistic interface updates. ## Tangible result You finish Day 2 with evidence that the memory layer is persistent, recoverable, and scoped to the authenticated owner. ## Day 3: Turn the Memory System Into a Focused Dashboard Mock and scaffold a dashboard that reveals daily priorities without trying to display everything. ### Learn: Design the Home View Around Daily Decisions **Time:** 25 minutes ## Purpose Choose dashboard cards based on decisions you make each day, not on the total amount of data available. ## Steps 1. Put identity and operator context near the top. 2. Reserve the most visible space for three to five key tasks. 3. Add daily habits with completion state. 4. Show a small set of weekly and monthly goals. 5. Include upcoming calendar information or a clearly labeled calendar placeholder. 6. Keep sensitive information hidden by default. 7. Place deeper modules, such as journal history and category memory, on separate views. ## Example wireframe ```text Top: Operator, date, private-data reveal control Left: Key tasks and upcoming meetings Center: Habit groups and completion Right: Weekly goals and monthly goals Navigation: Home, Tasks, Brain, Journal, Archive ``` The source deliberately limits visible monthly goals to a small number and keeps finance values concealed until revealed. These choices reduce clutter and accidental exposure. ## Tangible result You have a dashboard layout centered on focus, routines, goals, and upcoming commitments. ### Build: Generate the Application Scaffold With a Coding Assistant **Time:** 50 minutes ## Purpose Turn the approved requirements and layout into a functional application scaffold connected to Supabase. ## Steps 1. Open your project in your coding assistant. 2. Provide `architecture-prompt.txt` together with your V1 requirements. 3. Ask the assistant to inspect the existing project before selecting or changing its structure. 4. Require authentication, database reads, explicit loading states, empty states, and visible error messages. 5. Require the home, tasks, journal, brain, and archive views. 6. Ask for a short file-by-file implementation summary after changes are made. 7. Run the application and correct build errors before requesting visual polish. ## Follow-up prompt ```text Now audit the implementation against every acceptance criterion. List missing behavior before editing anything. Then make the smallest changes needed to satisfy the criteria. Do not add finance, nutrition, wearable, or voice features during this pass. ``` ## Verification The application should load authenticated records from Supabase rather than a hardcoded array. Refreshing the browser must not remove saved records. ## Tangible result You have a running application scaffold backed by your owned database instead of a static design mock. ### Build: Add List, Kanban, Brain, and Archive Views **Time:** 45 minutes ## Purpose Provide different views of the same memory without duplicating the underlying records. ## Steps 1. Build a task list with title, category, priority, status, and due date. 2. Add a Kanban view that groups tasks by status, such as inbox, today, this week, and this month. 3. Ensure dragging a task updates its existing database record. 4. Build a brain view that lists categories and opens related tasks and memory items. 5. Add a journal history view showing date and summary, with an option to reveal raw text. 6. Add an archive view for completed tasks. ## Example query behavior ```text Brain category selected: Business Operations Show: open tasks, stored notes, relevant links, and highlighted risks ``` The list and Kanban interfaces must reference the same task identifiers. A move should never create a second task. ## Test Move one task from inbox to today, refresh, and open the list view. It should appear once with the updated status. ## Tangible result Your application offers focused views over one consistent memory system. ### Checkpoint: Complete a Dashboard Usability Walkthrough **Time:** 20 minutes ## Purpose Confirm that the interface supports a real workday before adding automation. ## Steps 1. Open the home view and identify today's key tasks within five seconds. 2. Find your next calendar commitment or the calendar integration placeholder. 3. Complete one habit item and confirm the parent habit updates correctly. 4. Move a task using Kanban, then verify it in list view. 5. Open a category in the brain view and locate its notes. 6. Complete a task and recover it from the archive view. 7. Check the layout at a narrow mobile width. ## Pass questions ```text Can I see what matters today without scrolling through everything? Can I reach capture in one obvious action? Does every database write show success or failure? Are private values concealed by default? Does the mobile layout remain usable? ``` Write down no more than five corrections. Fix data integrity and navigation before visual styling. ## Tangible result You finish Day 3 with a usable dashboard and a short, prioritized correction list. ## Day 4: Capture and Classify Tasks From Anywhere Build a reliable capture pipeline, then prepare the Telegram and voice extension described in the source. ### Learn: Design Capture as a Confirmed Data Pipeline **Time:** 20 minutes ## Purpose Prevent transcription or classification errors from silently becoming trusted memory. ## Pipeline 1. Receive text or audio. 2. Transcribe audio when necessary. 3. Preserve the original input. 4. Ask AI for structured fields. 5. Validate the response against allowed values. 6. Show the proposed task for confirmation when confidence is low or details are important. 7. Store the approved record in Supabase. 8. Return a clear success or error response. ## Example Input: ```text Tomorrow morning remind me to review the client proposal before the 2 PM call. ``` Proposed result: ```json { "title": "Review the client proposal", "priority": "high", "status": "inbox", "due_date_text": "tomorrow morning", "category_name": "Business Operations" } ``` A model proposal is not automatically correct. Date interpretation and category selection should be validated by application logic or confirmed by the user. ## Tangible result You have a capture flow that preserves original context and treats AI output as structured assistance rather than unquestionable truth. ### Build: Implement Fast Text Capture First **Time:** 45 minutes ## Purpose Create the shortest reliable route into your task system before introducing audio and messaging dependencies. ## Steps 1. Add a capture field that is available from every main view. 2. Accept ordinary text without forcing the user to choose fields first. 3. Send the text to a protected server function. 4. Use `task-classification-prompt.txt` to request structured JSON. 5. Validate category, priority, status, and date fields. 6. Display a confirmation form containing the proposed values. 7. Store the original text in `source_text` when the user confirms. 8. Show the new task immediately and verify it after refresh. ## Test input ```text Send the revised launch plan to Jordan by Friday. This blocks the client review. ``` ## Expected proposal The title should describe sending the plan. The blocking language should produce a high priority proposal. The date should remain a proposed value until interpreted and confirmed. ## Error behavior If AI classification fails, save the text as an inbox task with a visible `classification pending` state rather than discarding it. ## Tangible result You can capture a task quickly, review the AI proposal, and persist the confirmed record. ### Deep Dive: Prepare Telegram and Voice Capture as a Second Input **Time:** 40 minutes ## Purpose Extend the working capture pipeline using the source architecture without creating a separate task system. ## Steps 1. Create a Telegram bot through BotFather. 2. Configure a protected webhook route in your deployed application. 3. Verify a webhook secret before processing an update. 4. For text messages, pass the message text into the existing classification pipeline. 5. For voice messages, retrieve the audio on the server and transcribe it with Whisper. 6. Store the transcript as the original source text. 7. Run the same validation and task creation logic used by dashboard capture. 8. Return a concise confirmation containing the proposed or created task. ## Coding assistant prompt ```text Add a Telegram webhook adapter to the existing capture service. Do not duplicate classification or database logic. Verify a webhook secret, accept Telegram text messages, and define a server-only voice branch that sends audio to the configured Whisper transcription service. Preserve the transcript in source_text. Return explicit errors without exposing tokens. Add tests proving that text and voice transcripts use the same task creation function. ``` Keep tokens in server environment settings. Never expose them in browser code or repository files. ## Tangible result You have either a connected Telegram route or a precise, secure implementation plan that reuses the proven text capture pipeline. ### Checkpoint: Pass the Capture Reliability Test **Time:** 30 minutes ## Purpose Prove that capture is reliable enough to replace scattered notes. ## Steps 1. Run the capture-related rows in `acceptance-tests.csv`. 2. Submit a clear task with a date. 3. Submit a vague idea with no date. 4. Submit an urgent task with blocking language. 5. Submit identical text twice and inspect whether the system warns about a likely duplicate. 6. Force the classifier to fail by using a temporary invalid configuration in development. 7. Confirm that the original text is preserved and no input disappears silently. 8. Refresh after each successful write. ## Required outcomes ```text Clear task: structured proposal appears. Vague idea: stored safely in inbox. Urgent task: high priority is proposed, not silently forced. Failure: visible error or pending state appears. Refresh: one persistent record remains for each confirmed task. ``` Do not proceed if records disappear after refresh or if failures are hidden. ## Tangible result You finish Day 4 with a tested capture route and evidence that raw input survives classification problems. ## Day 5: Build a Daily Cockpit for Priorities, Habits, Goals, and Time Transform stored data into a repeatable morning and workday routine. ### Learn: Select Three to Five Key Tasks Without Losing the Backlog **Time:** 20 minutes ## Purpose Separate today's meaningful commitments from the larger task inventory. ## Steps 1. Review inbox, today, and this week tasks each morning. 2. Evaluate urgency, impact, dependencies, and goal alignment. 3. Star only three to five tasks as key tasks. 4. Display starred tasks on the home view. 5. Complete key tasks before promoting replacements. 6. Leave all other work searchable in task views rather than crowding the home screen. ## Strategic review prompt ```text Review the supplied task records. Recommend the three tasks most likely to move my current goals forward today. Consider urgency, impact, dependencies, and stated deadlines. Explain each recommendation in one sentence. Do not mark or edit any task automatically. ``` This follows the source workflow, where the user chooses the final three to five priorities after reviewing the CRM. AI can recommend, but the operator decides. ## Tangible result You have a clear daily selection method and a home view limited to a manageable set of key tasks. ### Build: Make Habit Groups Complete From Their Subtasks **Time:** 40 minutes ## Purpose Reduce the mental effort required to remember recurring routines. ## Steps 1. Create two or three daily habits that support your actual work or wellbeing. 2. Give each habit a small set of observable habit items. 3. Record completion by date in `habit_logs`. 4. Calculate a parent habit as complete only when all required items are complete. 5. Show the percentage of all required items completed for the day. 6. Prevent tomorrow's state from reusing today's completion records. ## Example ```text Habit: Morning creative session Items: 1. Review current research 2. Write three ideas 3. Select one idea to develop ``` If two of the three items are complete, the parent habit remains incomplete while its progress shows two of three. ## Test Complete the final item and verify that the parent habit changes automatically. Change the selected date and confirm that completion is date specific. ## Tangible result Your dashboard now turns recurring routines into clear, date-based actions with automatic parent completion. ### Build: Connect Daily Work to Goals and Calendar Context **Time:** 45 minutes ## Purpose Keep outcomes and upcoming commitments visible while avoiding an overloaded dashboard. ## Steps 1. Add weekly and monthly goal sections to the home view. 2. Limit each visible section to three to five active goals. 3. Allow goals to be completed or archived without deleting their history. 4. Add an upcoming meetings section. 5. If Google Calendar is already configured, connect it through a protected integration and display upcoming events. 6. If it is not configured, retain a clear calendar component boundary and use test events until the integration is ready. 7. Keep calendar editing in Google Calendar if that remains your preferred workflow, as the source creator does. ## Example goals ```text Weekly: Deliver the onboarding revision Weekly: Publish two videos Monthly: Ship the new product page ``` ## Privacy rule Display only the event details required for planning. Avoid exposing private notes or attendee information on a screen that may remain open. ## Tangible result Your home dashboard connects today's tasks with a short list of goals and upcoming time commitments. ### Checkpoint: Run a Complete Morning Planning Session **Time:** 25 minutes ## Purpose Test the dashboard as an operating routine rather than a collection of features. ## Steps 1. Review the morning section in `daily-review-prompts.txt`. 2. Check upcoming meetings and fixed commitments. 3. Review inbox, today, and this week tasks. 4. Select three to five key tasks. 5. Confirm that each key task supports a goal, deadline, or important responsibility. 6. Review habit groups without marking anything complete prematurely. 7. Capture one new task and verify it appears in the correct workflow. 8. Keep the dashboard visible while completing one focused work block. ## Example final plan ```text Key task 1: Send revised proposal Key task 2: Review launch plan Key task 3: Draft video outline Fixed commitment: Client call at 2 PM Habit focus: Complete morning creative session ``` ## Tangible result You finish Day 5 with a dashboard that can organize a real morning and remain useful during active work. ## Day 6: Turn Journals and Category Memory Into Useful Context Capture reflections, preserve raw history, and ask grounded questions across your stored records. ### Learn: Store Both the Reflection and Its Summary **Time:** 20 minutes ## Purpose Preserve detailed personal context while keeping journal history easy to scan. ## Steps 1. Create one journal record per intended reflection period, usually daily. 2. Store the original typed text or voice transcript in `raw_text`. 3. Generate a concise summary in `summary`. 4. Keep the raw text available behind an intentional reveal action. 5. Record the entry date separately from the creation timestamp. 6. Never replace the raw entry with the generated summary. ## Copy-ready summarization prompt ```text Summarize this journal entry in four parts: what happened, what went well, what was difficult, and what deserves attention next. Use only details present in the entry. Do not diagnose the writer or invent causes. Keep the summary under 140 words. ``` ## Example raw input ```text The proposal took longer than expected, but the client call went well. I felt unfocused after lunch and delayed the outline until evening. ``` ## Tangible result You have a journal structure that is quick to review while preserving the complete original reflection. ### Build: Create the Evening Journal and Review Flow **Time:** 40 minutes ## Purpose Make reflection easy enough to repeat and valuable enough to inform tomorrow. ## Steps 1. Add a prominent journal action to the evening routine. 2. Support typed input first and microphone input if your voice pipeline is ready. 3. Ask the four evening questions in `daily-review-prompts.txt`. 4. Save the complete response as raw text. 5. Generate a grounded summary with the journal prompt. 6. Show a success state only after the database confirms the write. 7. Open journal history and verify that both summary and raw text are available. ## Evening prompt ```text What happened today? What went well? Where did I struggle? What should I change or prioritize tomorrow? ``` ## Test Submit an entry, refresh, and compare the summary with the raw text. Remove any summary claim that is not supported by the original entry. ## Tangible result Your personal OS now records a durable daily reflection and presents it in a reviewable format. ### Build: Query the Brain Without Pretending It Knows More Than It Does **Time:** 45 minutes ## Purpose Use stored tasks, goals, journal summaries, and category memory to support decisions while preserving evidence and uncertainty. ## Steps 1. Let the user select a category or review period. 2. Retrieve only records owned by the signed-in user. 3. Send relevant records to the model with identifiers and dates. 4. Require recommendations to cite the supporting record titles or dates. 5. Ask the model to state when the available memory is insufficient. 6. Present recommendations without automatically changing tasks or goals. ## Copy-ready strategy prompt ```text Act as a strategic operating reviewer. Using only the supplied records, recommend the three actions most likely to improve progress toward the active goals. For each action, cite the task, goal, journal date, or memory item that supports it. Separate urgent risks from high-impact opportunities. If evidence is missing, say what is missing. Do not invent personal history and do not edit records. ``` ## Example output structure ```text Recommendation Supporting records Reason Uncertainty or missing information ``` ## Tangible result You can ask grounded strategic questions across your owned memory and inspect the evidence behind each recommendation. ### Checkpoint: Complete a Grounded Memory Review **Time:** 30 minutes ## Purpose Check whether accumulated records produce useful context without unsupported conclusions. ## Steps 1. Add at least three journal entries or clearly labeled test entries. 2. Ensure the database also contains active goals and tasks. 3. Run the strategic review prompt. 4. Check every recommendation against the cited records. 5. Reject recommendations that introduce facts not present in memory. 6. Inspect whether sensitive raw journal text is unnecessarily exposed. 7. Record one useful recommendation and one missing data point. 8. Decide whether the missing point should become a future structured field or remain outside the system. ## Review questions ```text Is the recommendation supported by stored evidence? Can I trace it to a record and date? Does it acknowledge uncertainty? Is it advice rather than an automatic action? Did the system reveal more private detail than necessary? ``` The source describes long-term pattern recognition as a potential benefit. Treat early conclusions cautiously because a small number of entries cannot establish a reliable pattern. ## Tangible result You finish Day 6 with a grounded memory review and a safer standard for future AI recommendations. ## Day 7: Secure, Test, Ship, and Operate Your V1 Harden the system, validate the complete workflow, and establish an evidence-based improvement cycle. ### Learn: Protect Secrets, Private Records, and Sensitive Views **Time:** 30 minutes ## Purpose Reduce the risk created by placing personal tasks, goals, journal entries, and integrations in one application. ## Steps 1. Complete every access and secret-management item in `security-backup-checklist.txt`. 2. Confirm authentication is required before loading personal data. 3. Confirm row level security is active on every personal table. 4. Search the client bundle and repository for service keys and bot tokens. 5. Protect webhook routes with a secret and reject invalid requests. 6. Hide sensitive dashboard values by default. 7. Remove private test data from screenshots, recordings, and logs. 8. Review application errors so they are useful without exposing secrets or full private payloads. ## Example rule ```text Browser code may use the public anonymous key under row level security. The service role key must remain in trusted server settings and must never be shipped to the browser. ``` Password protection alone is not a substitute for database access controls. Apply protection at both the interface and data layers. ## Tangible result Your V1 has explicit controls for authentication, database ownership, secret handling, webhook verification, and private display behavior. ### Build: Create and Prove a Backup and Recovery Procedure **Time:** 35 minutes ## Purpose Ensure that a coding mistake, faulty update, or accidental deletion does not erase your memory. ## Steps 1. Choose a recurring Supabase backup or export method available to your project. 2. Export the core tables to a protected location. 3. Record the export date and the database environment. 4. Inspect the files and confirm that expected tables contain records. 5. Restore the export into a separate test environment or follow a documented dry run. 6. Verify counts for tasks, goals, journal entries, and memory items. 7. Repeat the process after major schema changes. ## Recovery verification ```text Original task count: 12 Restored task count: 12 Original journal count: 3 Restored journal count: 3 Archive records present: yes Owner identifiers preserved: yes ``` Do not treat an untested export as a completed recovery plan. The source emphasizes that data can be backed up, archived, and re-exported if the interface or coding process causes a problem. ## Tangible result You have a documented and tested route for recovering the memory behind your dashboard. ### Build: Run the Full V1 Acceptance Test **Time:** 50 minutes ## Purpose Validate the complete daily workflow before depending on it for important commitments. ## Steps 1. Run every applicable row in `acceptance-tests.csv`. 2. Capture a task and confirm its classification proposal. 3. Refresh and verify persistence. 4. Select it as a key task and verify the home view. 5. Move it through Kanban and verify the list view. 6. Complete it and verify the archive. 7. Complete all items in a habit and verify parent completion. 8. Add a goal and a journal entry. 9. Run a grounded brain review. 10. Sign out and confirm protected data is inaccessible. 11. Test at mobile width. 12. Record failures with reproduction steps and visible error details. ## Bug report format ```text Title: Starting state: Steps to reproduce: Expected result: Actual result: Database record state: Frequency: ``` Fix data loss, access control, duplicate creation, and hidden errors before addressing cosmetic issues. ## Tangible result You have a completed acceptance test and a prioritized list of defects based on operational risk. ### Checkpoint: Ship the V1 and Begin the Real Usage Loop **Time:** 35 minutes ## Purpose Move from building to daily operation while keeping future changes tied to observed friction. ## Steps 1. Deploy the tested version with production environment secrets. 2. Confirm authentication, capture, database writes, and archive behavior in production. 3. Add the dashboard to an easy-to-reach browser tab or desktop workspace. 4. If mobile capture is connected, place Telegram or your chosen capture route somewhere quickly accessible. 5. Run the morning review and choose three to five key tasks. 6. Capture new work through the system during the day. 7. Complete the evening journal. 8. After several real usage sessions, list repeated friction rather than immediately adding every requested feature. 9. Choose one reliability improvement and one usability improvement for the next release. ## V1 completion definition ```text The system captures work quickly, preserves it after refresh, keeps daily priorities visible, records habits and reflections, protects owner data, and can be restored from backup. ``` Possible later modules include deeper finance, nutrition, health, wearable, and calendar integrations. Add them only when the core workflow is stable and the data can be handled safely. ## Tangible result You have shipped a working personal AI operating system and established the trial, error, testing, and improvement loop emphasized in the source. ## Free asset kit - **V1 Requirements Worksheet:** A CSV worksheet for connecting personal bottlenecks to modules, inputs, outputs, and measurable acceptance criteria. - **Personal OS Architecture Prompt:** A copy-ready prompt for scaffolding the application with a coding assistant while preserving scope and data safety. - **Supabase Core Memory Schema:** A complete SQL schema for owner-scoped categories, tasks, habits, journals, goals, and category memory. - **Task Classification Prompt:** A structured prompt that converts captured text into a reviewable task proposal without inventing missing details. - **V1 Acceptance Tests:** A practical CSV test suite covering persistence, duplicate prevention, habits, journals, privacy, and responsive behavior. - **Security and Backup Checklist:** A concise operational checklist for protecting personal memory and proving that it can be recovered. - **Daily and Weekly Review Prompts:** Copy-ready prompts for selecting priorities, recording reflections, and reviewing stored evidence.