🟫 Workspace Planner Consolidation — Master Plan (Merged)

Start here

What this page is: A live master plan + handoff doc for consolidating the workspace safely. It is both a policy/runbook and an execution log for database/planner consolidation, cleanup review, taxonomy normalization, finance cleanup, and frontend ↔ backend reconnect work.

How to use it: Start here first, work only from NEXT ACTIONS, and use the Reference Library section for evidence, source material, databases, specs, and cleanup lists.

Do-not-touch rule: The "Exact Duplicates — Verified Delete List" section is formatting-fragile; do not rewrite its internal formatting unless explicitly requested.

Mission: Build one clean, frontend-ready workspace backend without losing useful content, breaking existing planner layouts, deleting unapproved items, or disconnecting platform routes/forms/dashboards from the correct Notion sources.

Additional content from Doc 1 — Start here

• How to use it: Work from NEXT ACTIONS only. Everything else is reference/supporting detail.
• Scope / goal
• Timestamp rule (for every task line going forward)
• Format: (added: YYYY-MM-DD h:mm AM/PM ET; done: YYYY-MM-DD h:mm AM/PM ET).

Scope / goal

Clean up and consolidate Notion workspace databases + planners, then ensure platform frontend ↔ Notion backend routing stays correct after moves/renames, with bidirectional syncing.

Rules & Standards

Standing rules — apply to every action

• No deletion before approval: Never delete or archive any database, page, property, row, template, view, or block unless Jillian has first seen a clear clickable approval list and explicitly approved the exact deletion/archive in chat.
• Labels are signals, not decisions: "ready to archive," "DELETE?," "dup check," "merge," "official," "keeper," and "do not delete" are review labels only. They do not decide the action by themselves.
• Inventory-first: Compile same/similar pages and databases with links first. Do not move, delete, or merge until the inventory and dependency context is visible.
• Keeper-first: Choose a keeper before merging. Improve the keeper first, then migrate or mirror useful content into it.
• True merge / dedupe standard: When two sections exist for the same topic — compare both line-by-line, keep one canonical header, move any unique lines from the other copy into the canonical one, then remove only the now-empty duplicate shell. Never "just delete" a duplicate section.
• Soft-retire before delete: Legacy items stay until the dependency sweep, data migration, frontend reconnect, and verification are complete.
• Preserve UX and layouts: Preserve useful visual planner layouts and views. If a page has a good layout, keep it as a layout page and surface the canonical keeper database with linked views rather than moving data away blindly.
• Preserve content and media: When merging pages or databases, preserve page contents, covers, icons, files, templates, comments where available, and meaningful media.
• Master inventory is source of truth: Subject-page inventory should be represented in 🟫 Master — Databases Inventory, 🟫 Master — Views Inventory, and 🟫 Master — Subject Sections.
• Brown-square keeper marker: Confirmed keeper pages/databases should use the brown-square keeper convention until the final icon pass.
• Do not break connected views: If moving a database would break linked views or page layouts, keep the database in place and connect it through master inventory / linked views until the reconnect phase is ready.
• Audit queue pattern: Once a subject is fully captured in the master inventory databases, its subject page can be reduced to a lightweight reference page that points back to the master inventory sources.

Timestamp rule

Format: (added: YYYY-MM-DD h:mm AM/PM ET; done: YYYY-MM-DD h:mm AM/PM ET)

When a task is completed, add a done: timestamp on the same line when checking it off.

Do not invent timestamps for historical completed work — leave them untimestamped or label as historical.

Always-on rules (check these every session)

• Confirm "No deletion before approval" is still being followed.
• Log any new rule discovered during work into Rules → Task-specific rules (not buried in random sections).

Additional content from Doc 1 — Rules

• Rules (global + task-specific)
• Labels are signals, not decisions: “ready to archive,” “DELETE?,” “dup check,” “merge,” “official,” “keeper,” and “do not delete” are review labels only. They do not decide the action by themselves.

Operating Standards

Global hubs only when the concept is truly shared

If two properties represent the same underlying concept, they should point to one canonical taxonomy hub so cross-system aggregation works.

Examples of likely global hubs: Platforms, Addresses, Cities, States, Countries, truly shared categories/types/tags.

Do NOT consolidate just because labels match. If two fields share a name but represent different lifecycle flows, keep them separate and rename clearly.

• Example: Customer Request Statuses ≠ Inventory Statuses ≠ Invoice Statuses ≠ Task Statuses.
• Same concept = consolidate. Same label but different lifecycle = keep separate and clarify the name.

Normalize on touch

When opening or modifying a database for cleanup:

• Review its select, multi-select, text-option, relation, rollup, and formula setup.
• Convert option-like fields into relation-backed fields when appropriate.
• Preserve legacy properties as "Legacy Text," "Legacy Select," etc. until frontend reconnect is stable.
• Update view columns so views still make sense after renames.
• Do not remove legacy properties during the same pass unless deletion has been approved and verified.

Ready-to-archive rule

A "ready to archive" database is only safe if:

• A keeper exists for the same concept
• The keeper has all needed properties/settings
• Unique pages/rows have been migrated or mirrored
• Unique views/templates are recreated or documented
• Page content, covers, icons, and files are preserved
• Relations/rollups/formulas still work
• Jillian approves the archive/delete list

If the "ready to archive" label is on the wrong database, remove the label from the inventory row and treat it as a normal candidate.

Duplicate database merge rule

Before deleting a duplicate:

• Compare database purpose, properties, types, relation targets, rollup targets, formula logic, options, templates, and views
• Choose the keeper based on richest schema, most real data, most useful layouts/views, most connected relations, and best canonical fit
• Add missing useful properties/views/templates to the keeper
• Move or mirror unique rows/pages into the keeper
• Preserve page content, cover images, icons, files, and templates
• Only mark the duplicate as delete/archive candidate after verification
• Show Jillian the approval list before any deletion/archive

Identical duplicate rule

A possible duplicate can be deleted only if confirmed identical or fully migrated:

• No unique properties, views, templates, rows/pages, content/media, relations/rollups/formulas/settings
• No frontend dependency remains

Address normalization standard

Operational databases should point to a canonical Addresses relation. City, State, Country, and ZIP should not stay as long-term free text/select fields when they are intended to be structured and reusable. Preserve legacy text/select fields until migration and frontend reconnect are verified.

Closet / owned item lifecycle standard

Physical items should be trackable through a canonical owned-item lifecycle: acquired → in closet/owned → packed/used/listed → sold/donated/archived — tied to purchases, sales, events, schedule blocks, customer requests, and inventory where applicable.

Frontend reconnect governance

Any time a database/property is renamed, replaced, merged, or made canonical:

• Log it in the Master Plan / changelog
• Preserve legacy references until the frontend reconnect is stable
• Update the reconnect mapping so Genspark knows the new source
• Verify that no route/form/dashboard depends on the deleted/legacy source

Start here when reorganizing Notion: https://indulgon.com/docs/CONNECTIONS.html

Part 2 ("Notion Database Property Maps") is the authoritative list of Notion DB IDs, .env variable names, required vs optional properties, and DB-by-DB reconnection steps.

Permission-blocked items

If a source is blocked by permissions: log it as blocked, do not make destructive assumptions, do not delete or archive related items, revisit after access is available.

Merge approval categories

Every cleanup candidate should be classified before action:

• Keep — confirmed keeper
• Rename — keep it, but remove misleading labels or clarify purpose
• Merge into keeper — useful unique content must be moved into a keeper
• Mirror into keeper — direct migration is risky; reproduce the needed structure/content in the keeper
• Archive candidate — safe only after merge/mirror verification and approval
• Delete candidate — safe only if identical or fully migrated and approved
• Needs manual review — ambiguous, blocked, or tool cannot safely compare/move all content

Final safety rule

No destructive action happens until Jillian receives and approves a review table that explains: item name, link, current label, proposed keeper, proposed action, why, what was migrated/mirrored, what remains unique, whether it is safe yet.

Additional content from Doc 1 — Operating Standards

• Normalize on touch
• Review its select, multi-select, text-option, relation, rollup, and formula setup.
• in closet / owned,
• packed / used / listed,
• sold / donated / archived,
• If a source is blocked by permissions:
• why,
• what remains unique,

✅ NEXT ACTIONS

Use this as the only "what do I do next?" checklist. Add new tasks here the moment they are discovered, check them off when finished, add timestamps per the rule above.

Current — do these next

• Continue workspace-wide page/bookmark duplicate sweep beyond the first exact-empty batch (added: 2026-06-21 10:45 PM ET)
• Build the next approval-ready cleanup batch with clickable keeper/delete/archive decisions and reasons; no deletions before approval (added: 2026-06-21 10:45 PM ET)
• Continue similar-but-not-identical database merge review after exact duplicates, preserving unique rows/properties/views/templates/content/media first (added: 2026-06-21 10:45 PM ET)
• Continue taxonomy/config duplicate sweep and confirm global-vs-lifecycle-specific taxonomy hubs (added: 2026-06-21 10:45 PM ET)
• Continue frontend reconnect delta list after Genspark/platform mapping links are available (added: 2026-06-21 10:45 PM ET)
• Decide the canonical "Next Actions" flow (keep working inside this page) and stop creating new separate instruction pages
• Finish Views Inventory completeness work (capture every view + every linked-view location + settings) in 🟫 Master — Views Inventory

Always-on (check every session)

• Confirm "No deletion before approval" is still being followed
• Log any new rule discovered during work into Rules section, not buried in random sections

✅ Done / Completed Work

Inventory and section structure

• Master inventory databases created: 🟫 Master — Databases Inventory, 🟫 Master — Views Inventory, 🟫 Master — Subject Sections
• Subject section relations created between all three master inventory databases
• Every captured database inventory row has a Subject Section relation
• All "(Unnamed…)" database inventory rows resolved using underlying database names
• Direct subject-page database/view coverage captured in 🟫 Master — Views Inventory
• Workspace-wide scattered linked-view/location sweep completed for remaining planner, legacy, and duplicate locations
• Views Inventory relation normalization completed: Audit Queue subject, Subject section, and Master database inventory item all filled
• Zero Views Inventory rows remain missing the three core relation fields
• Redundant Subject select removed from 🟫 Master — Views Inventory display — relation fields are the working source of truth
• Step 1 — Compile / "moving by links" — all 12 subjects complete (Finance, Projects & Tasks, Products & Inventory, Services & Content, Bookings & Scheduling, Dashboards & Analytics, People & Contacts, Creative & Production, Documents & Media, Business Planner, Personal Planner, Templates Reference)
• Step 1 addendum — Workspace-wide sweep links (Option B) — per-subject Review sections added across all subject pages (link-only, no moves)
• Step 1 addendum — Toggle UX pass complete for all 12 subjects
• Step 1 addendum — Linked views bundle per database — Finance complete; remaining subjects not started
• Step 1 addendum — Populate master inventory databases — all 12 subjects complete
• Step 1 addendum — Views Inventory completeness + cleanup review — complete (bulk Needs settings review rows reduced, true flags preserved)
• Step 1 addendum — Normalization / relations pass — complete (Views Inventory rows matched to Databases Inventory; all three core relation fields filled; zero rows missing)
• Step 1 addendum — Section pages (toggles → pages) + Master Subject Sections database — Created database, linked Subject Sections ↔ Views Inventory and ↔ Databases Inventory; Bookings & Scheduling section sub-pages created; remaining 11 subjects not started
• Step 1 addendum — Clear subject pages after migration — not started (all 12 subjects pending)

Cleanup / duplicate review

• Initial cleanup candidate scan completed from 🟫 Master — Databases Inventory
• Duplicate inventory-row groups found by repeated underlying database link
• Label-based review candidates found from ready-to-archive, DELETE?, dup, merge, official, legacy, and do-not-delete signals
• First-pass comparison findings added for: University & Education, Formats, Health/Habits, Email Templates, Shot List, Untitled Booking wrappers, Personal People vs Contacts, and same-underlying inventory-row duplicates (see Cleanup Review List — F1 through F8)
• Exact duplicate linked-view comparison pass completed (see G1)
• Weekly Planner Duplicate 1–5 databases removed after confirmation (see G2) — 50 duplicate databases deleted, 80 duplicate Views Inventory rows deleted
• Same-underlying inventory-row duplicate groups cleaned after confirmation while keeping active underlying databases
• Email template/categories duplicate cleanup executed after preserving keeper fields (see G8)
• Shot List duplicate cleanup executed after preserving useful Booking Location relation (see G8)
• First exact-empty page/bookmark duplicate batch completed (see G9) — 28 pages deleted across 4 sources

Backend / reconnect / taxonomy / finance

• Genspark reconnect material reorganized into operating standards, integrated checklist/phases, and changelog source material
• Platforms, Cities, States, Countries, Addresses, and Statuses canonical hubs documented
• Address normalization standard documented
• Global-vs-lifecycle-specific taxonomy rule documented
• Customer Requests relation replacements and content modeling decisions documented
• Scheduling canonical stack documented: Booking Calendar, Availability, Unified Schedule
• Unified personal + business day-in-the-life intent documented
• Finance sign convention and refund policy implemented (checkbook sign convention, Refund ≠ Income, Net Spend budgeting)
• Finance dashboards converted to system fields (Net Spend-first + explicit Transaction Type filters); triage views driven to zero; sign checks verified
• Legacy subscriptions migrated into canonical Subscriptions Database
• Legacy income migrated into canonical Income Database
• Many legacy expense/income rows migrated into canonical finance keepers; migrated rows archived in source databases to prevent future edits
• Finance refund policy labels assigned to all Categories and Subcategories (Net Spend vs Ignore refunds)
• Finance System Spec created; Legacy Removal List created; Finance Verification Checklist created/used
• Genspark Connections Blueprint available at: https://indulgon.com/docs/CONNECTIONS.html

🔲 Remaining Work

Cleanup review / merge / consolidation

• Continue workspace-wide page/bookmark duplicate sweep for non-empty and same-title pages
• Compare remaining duplicate/similar database clusters by schema, relation targets, rollups, formulas, options, views, templates, rows/pages, page content, covers, icons, files, media, and frontend dependencies
• Choose keepers only after comparison — do not assume label = action
• Add missing useful schema/views/templates to keepers before retiring duplicates
• Move or mirror unique rows/pages/content/media into keepers
• Convert useful linked views into actual views on keeper databases where appropriate
• Produce approval list before any archive/delete
• Complete Step 1 addendum — Section pages for remaining 11 subjects (Products & Inventory, Services & Content, People & Contacts, Creative & Production, Dashboards & Analytics, Documents & Media, Business Planner, Personal Planner, Projects & Tasks, Finance, Templates Reference)
• Complete Step 1 addendum — Clear subject pages into lightweight references for all 12 subjects after inventory is fully captured
• Complete Step 2 — Merge / consolidate for all 12 subjects (Finance, Projects & Tasks, Products & Inventory, Services & Content, Bookings & Scheduling, Dashboards & Analytics, People & Contacts, Creative & Production, Documents & Media, Business Planner, Personal Planner, Templates Reference)
• Complete Step 3 — Final placement into official planner (then LIFE PLANNER) for all 12 subjects

Taxonomy / config and address normalization

• Continue taxonomy/config duplicate sweep
• Confirm every taxonomy hub that should be global is global
• Confirm lifecycle-specific taxonomies stay separate and are named clearly
• Continue address normalization sweep for accessible databases
• Revisit blocked legacy address-like source when access is available
• Finance sweep: convert Promo Codes, Recurring Transactions, Expenses to taxonomy/relation-backed fields
• Dashboards & Analytics audit: verify core tracking DBs already have (Rel) replacements for option-like fields
• System Config audit: verify key operational DBs already have (Rel) replacements

Finance remaining

• Identify remaining legacy embedded finance databases with unique rows (primary area: finance planner — keep for visual layout)
• Migrate unique finance rows into canonical keepers (Income, Expenses, Subscriptions)
• Savings & Investments dual-mode: confirm + implement final wiring (outflow budgeting + goal tracking)
• Month breakdown fixes: repair month formulas + ensure historical attribution everywhere
• Soft-retire finance duplicates (rename 🟫 … (legacy), hide, log) across remaining Finance DBs
• Final Finance verification pass: dashboards/charts/boards
• Later milestone: create canonical Transactions database for platform ingestion (Income + Expenses + other earnings)
• Only archive/delete legacy finance databases after confirmation and reconnect verification

Frontend reconnect

• Compare Connection Blueprint property maps against current canonical Notion databases (https://indulgon.com/docs/CONNECTIONS.html)
• Build Reconnect Delta List: old DB/property → new canonical DB/property → feature/route/form affected → migration note → status
• Verify every route/form/dashboard connects to canonical Notion sources
• Confirm no frontend references point to deleted or legacy databases
• Add/confirm frontend/platform mapping fields for subject pages/sections after Jillian confirms Genspark mapping links
• Handoff final reconnect packet to Genspark

Subject pages / planner structure

• Clear remaining subject pages into lightweight references after inventory is fully captured
• Finish structural-page UI hygiene sweep: Operational, Taxonomy/Config, Dashboards/Reports, Protected Legacy, Review, Cleanup Queue
• Continue final planner placement after merge/consolidation

Blocked / needs access

• Extract "rules / instructions / steps" from Convo 1–3 PDFs and convert from chat-format into clean rules + tasks — Blocker: attachments were flagged as potentially risky / not viewable in the prior pass
• Revisit blocked legacy Address-like data source when access is available
• Collection sources from Notion AI handoff (196b8641, 13fb8641-810e, 172b8641, 177b8641) — not accessible via Genspark integration token; need to be shared with GenSpark Claw integration in Notion to continue duplicate cleanup

Verification checklist (run after every cleanup batch)

• Verify 🟫 Master — Databases Inventory, 🟫 Master — Views Inventory, and 🟫 Master — Subject Sections still agree after each cleanup batch
• Verify no stale Views Inventory references point to deleted duplicate inventory rows
• Verify no duplicate linked-view groups remain after each exact duplicate pass
• Verify no repeated underlying database links remain in 🟫 Master — Databases Inventory after same-underlying row cleanup
• Verify keeper databases contain all useful fields/views/templates/rows/content/media before any duplicate is retired
• Verify frontend reconnect before deleting or archiving legacy sources

Cleanup Review List

This is the cleanup review list for comparison, rename, merge, archive, and delete decisions only. Nothing listed here is approved for deletion or archive until Jillian explicitly approves the exact item/action in chat.

Overall status:

• Initial cleanup candidate scan completed
• Duplicate inventory-row groups found
• Label-based review candidates found
• Full schema/view/template/page comparison not completed for all items
• Keeper decisions not finalized for all items
• No broad deletions or archives approved yet

Review rules

• Labels are signals, not decisions
• "Ready to archive" does not mean archive
• "DELETE?" does not mean delete
• "Do not delete" does not automatically mean canonical keeper — it means treat as protected until reviewed
• Same name does not mean same concept
• Same underlying database link usually means duplicate inventory rows, not duplicate databases
• A database can only become an archive/delete candidate after: keeper selected, properties compared, views compared, templates compared, rows/pages checked, page contents/covers/icons/files preserved or confirmed unnecessary, relation/rollup/formula behavior verified, frontend dependency risk checked, Jillian approves the exact action

A. Duplicate inventory-row groups — same underlying database link

These are likely duplicate inventory rows pointing to the same database — not duplicate databases themselves. Likely final action is to keep one inventory row and remove duplicate rows only after approval.

B. Ready-to-archive / DELETE? / label-warning candidates

C. Merge-review candidates

D. Protected / do-not-delete signals

• Customer Roles (Do not delete) — protected signal; compare only if a canonical roles hub is involved
• ❤️Creator Roles (Do not delete) — protected signal; compare only if a canonical roles hub is involved
• ❤️Size Terms (Do not delete) — likely keeper from previous consolidation history; keep protected
• ❤️Color Schemes (Do not delete) — protected signal; keep until reviewed

E. Recommended next comparison order

1. Same-underlying inventory duplicates — safest (inventory row duplicates, not database duplicates)
2. University & Education ready-to-archive pairs — likely label-risk, easier to compare within one subject
3. Formats group — important global-vs-domain taxonomy decision
4. Health / habit trackers — merge-sensitive (logs vs definitions may differ)
5. People / Personal People — merge-sensitive (contacts, gift recipients, frontend semantics)
6. Email templates/categories — decide shared template hub vs subject-specific
7. Shot List and untitled Booking DBs — compare after loading underlying structures

F. Approval status

Confirmed exact-duplicate cleanup has been executed (see G sections). No broader similar-but-not-identical merge/delete/archive work is approved yet.

F1. University & Education ready-to-archive batch — Course 1, Final Exam, Midterm 1, Midterm 2: schema/view/row/page-content match confirmed. Archive/delete candidates only after Jillian approves. Keep originals as likely keepers. Status: Pending approval.

F2. Formats group — Contains at least two different concepts: file/media formats (✨Formats Database) and service/request formats (Service Formats). DELETE? and "ready to archive" labels are not enough. Do not merge into wrong group. Status: Not approved.

F3. Health / habit tracker group — Related but not identical. Likely model: Personal Habits = habit definitions, Health Tracker = daily health log, simple/weekly trackers need row/template review before deciding. Status: Not approved.

F4. Email templates/categories — Empty but not automatically deletable. If global, use one shared hub; if different workflows, keep separate and rename clearly. Status: Not approved.

F5. Shot List group — Creative Shot List = keeper (richer schema + real row with content). Booking Shot List = possible archive/delete candidate only after confirming it is not required as a layout/view surface. Status: Pending approval.

F6. Untitled Booking DBs — Resolved: ✨Countries linked view wrapper and ✨US States linked view wrapper. Inventory rows renamed. Keep as linked-view wrappers or replace with cleaner linked views later. Status: Not approved.

F7. Personal People vs Contacts — Personal People is not an identical duplicate. Represents personal people / gift recipients. Merge requires preserving personal/gift/wishlist relationships. Status: Not approved.

F8. Same-underlying inventory-row duplicates — These are inventory cleanup candidates, not database deletion candidates. Merge/remove duplicate inventory rows after approval; keep underlying databases untouched unless separately approved. Status: Not approved.

Additional content from Doc 1 — Cleanup Review List A-F

• Review rules for this page
• B. Ready-to-archive / DELETE? / label-warning candidates
• C. Merge-review candidates
• Weekly Habits Tracker (merge and keep DB)
• Personal Formats Database
• E. Next comparison batches
• Formats group — important global-vs-domain taxonomy decision.
• Health / habit trackers — merge-sensitive because logs and definitions may differ.
• Status: Compared at schema/view/row/page-content level for the visible rows. No deletion or archive approved.CandidateCompared withFindingsRecommendationApproval statusCourse 1 (ready to archive)Cours
• Status: Compared at schema and row-title level. No deletion or archive approved.CandidateCompared withFindingsRecommendationApproval status✨Formats Database (DELETE?)Personal Formats Database
• Service Formats (ready to archive)This is a broad document/media/file format hub with rows like PDF, PNG, MP4, ZIP, CSV, JSON, H.264, ProRes, etc. It has media/deliverable-specific relations such as R
• Personal Formats DatabaseThis is not the same concept as file formats. Rows include Custom Video, Personalized Item, Photo Set, Premade Video, and Skype Show. It has service/request relations such as
• F3. Comparison findings — Health / habit tracker group
• F4. Comparison findings — Email templates/categories
• F5. Comparison findings — Shot List group
• Status: Loaded, identified, and renamed inventory rows. No deletion/archive approved.Former labelResolved nameFindingsRecommendationApproval status✨Countries linked view wrapper✨Countries linked view
• F7. Comparison findings — Personal People vs Contacts
• ✨Affiliate Statuses (verify underlying)Keep the clean canonical inventory row; merge notes/relations from review rows later if needed. Do not delete rows until final cleanup approval.Not approved✨Conn

G. Duplicate Audit Findings (Step 2 — exact duplicate pass)

This section is for the exact-duplicate pass only. No deletion/archive approved unless explicitly noted.

G1. Exact duplicate linked views — Views Inventory

Exact duplicate view names + captured settings found only for Meal Planner Items database:

Notes: Same-name University view rows were NOT exact duplicates (captured filter/sort/group settings differed). Other high-row-count databases mostly have distinct views, not exact duplicate view names.

G2. Weekly Planner duplicate database cluster — COMPLETED ✅

Compared main Weekly Planner copy with Duplicate 1–5 for Daily Tasks, Monday–Sunday meal planner databases, Grocery's, and Recipe Book. Schemas, view setups, row counts, visible row values, and sample page contents matched at tool-visible level.

Action taken: 50 duplicate databases deleted, 80 duplicate Views Inventory rows deleted after Jillian confirmation.

Keeper: Main Weekly Planner copy.

G3. Notes databases — NOT exact duplicates

Compared visible Notes-style databases. Findings: richer schema with status, favorite, date formula, project/area relations, six distinct views vs simpler schema. These are related but not identical — do not delete as exact duplicates.

G4. Tasks / requests setup finding

Tasks/notes should connect to customer requests and individual user requests, with rollups showing needed action context such as outfit/closet needs, requested purchase items, inventory items, and request details.

G5. Systems → Master Subject Sections setup

Systems pages that represent subject/section structure should be moved or mirrored into 🟫 Master — Subject Sections structure, with needed properties copied/populated, then marked as cleanup candidates — but not deleted without approval.

G6. Step 2 keeper/not-keeper marking — COMPLETED ✅

Keeper and not-keeper markers applied across 🟫 Master — Databases Inventory after the exact duplicate pass. Keeper databases identified per subject.

G7. Post-delete linked-view / inventory cleanup verification — COMPLETED ✅

After Weekly Planner exact duplicate deletions:

• Exact duplicate linked-view groups in Views Inventory: 0
• Stale Views Inventory references to deleted duplicate items: 0
• Same-underlying duplicate inventory groups: 0
• Remaining Weekly Planner duplicate view rows: 0

G8. Workspace-wide duplicate cleanup — email templates/categories and Shot List — COMPLETED ✅

• Email Templates (Services & Content) duplicate rows cleaned after preserving keeper fields
• Email Template Categories (Services & Content + Documents & Media) duplicate cleaned
• Shot List duplicate cleaned after preserving useful Booking Location relation
• Shot List (Bookings & Scheduling, 0 real rows) = delete candidate after Jillian approves
• Creative Shot List (Creative & Production, 1 real row with content) = keeper

G9. Workspace-wide page/bookmark duplicate sweep — first exact-empty batch — COMPLETED ✅

First batch of exact-empty page/bookmark duplicates deleted across 4 collection sources:

• collection://196b8641-18fc-8134 (Projects Database / notes-project style)
• collection://13fb8641-18fc-810e (notes/tasks source)
• collection://172b8641-18fc-80b6 (bookmark/web-clip source 1)
• collection://177b8641-18fc-813d (bookmark/web-clip source 2)

28 pages deleted in confirmed batches. Next: continue sweep for non-empty and same-title pages. Access via Notion AI required (these collections not accessible via Genspark integration token).

Execution Phases (global)

Phase 0 — Create inventory surfaces ✅ COMPLETE

• Created Linked Index — All Planners & Databases page (inventory only, read-only-style)
• Created 🟫 Master — Databases Inventory, 🟫 Master — Views Inventory, 🟫 Master — Subject Sections
• Populated inventory with all subjects (Step 1 complete for all 12 subjects)

Phase 1 — Exact duplicate audit ✅ COMPLETE

• Identified exact duplicate databases (Weekly Planner duplicates 1–5)
• Identified exact duplicate linked views (Meal Planner Items)
• Confirmed and deleted 50 duplicate databases, 80 duplicate Views Inventory rows
• Verified zero remaining exact duplicates

Phase 2 — Similar-but-not-identical database merge review 🔲 IN PROGRESS

• Comparison findings completed for F1–F8 subject groups
• No deletions/archives approved yet
• Next: choose keepers, add missing properties, migrate unique rows, produce approval lists

Phase 3 — Final placement into official planners 🔲 NOT STARTED

• Move canonical databases into official planner pages (FINAL PLANNER → LIFE PLANNER)
• Finance exception: Finance already has an official planner page (finance planner — keep for visual layout)

Phase 4 — Frontend reconnect 🔲 NOT STARTED

• Map all canonical Notion databases to Genspark platform routes/forms/dashboards
• Build Reconnect Delta List
• Verify no frontend references point to legacy/deleted sources
• Reference: https://indulgon.com/docs/CONNECTIONS.html

Phase 5 — Soft-retire and verify 🔲 NOT STARTED

• Rename legacy databases (🟫 … (legacy)), hide, log in changelog
• Run final verification pass on all dashboards/charts/boards
• Archive/delete only after full verification and Jillian approval

Additional content from Doc 1 — Execution phases

• Phase 2+ — Planner-by-planner consolidation
• Products & Inventory: group taxonomy/ops/deprecated into best-fit sections; add (NEW) headers where needed
• Services & Content: create top-level sections (Services, Requests/Quotes, Content, Community, Marketplace, Media, Taxonomy); file DBs accordingly; add (NEW) headers where needed
• People & Contacts: refine sections (People core, Customers, Roles, Safety, Affiliate/Referrals, Vendors/Talent); file DBs accordingly; add (NEW) headers where needed
• Creative & Production: add sections (Mood/Moods, Boards, Shot planning, Tags/Options); file DBs accordingly; add (NEW) headers where needed

Backend Rebuild Changelog

Records high-impact backend changes that Genspark needs to understand during frontend reconnect.

Completed changes

• Weekly Planner duplicate databases (1–5) deleted — 50 databases, 80 Views Inventory rows. Keeper: main Weekly Planner copy.
• Email Templates/Categories duplicate cleaned — keeper fields preserved; duplicate rows removed.
• Shot List duplicate cleaned — Booking Location relation preserved in keeper; duplicate removed.
• Views Inventory normalization complete — all rows have Audit Queue subject, Subject section, and Master database inventory item relations filled.
• Finance sign convention implemented — checkbook sign convention, Refund ≠ Income, Net Spend budgeting, refund policy labels on all Categories/Subcategories.
• Finance dashboards converted to system fields — Net Spend-first, explicit Transaction Type filters, triage views at zero, sign checks verified.
• Legacy subscriptions migrated — from "Subscriptions A (Legacy — Do Not Use)" into canonical ✨Subscriptions Database.
• Legacy income migrated — "Paid by KDP" and legacy "Additional Income -" clusters into canonical Income Database.
• Film Schedule (ready to archive) handled — unique row migrated; archive deleted after confirmation.
• Rules finalized for similar-but-not-identical databases — migrate unique rows/options → confirm delete. Apply to other "(ready to archive)" DBs as encountered.
• 🟫 Master — Subject Sections database created — linked to both Databases Inventory and Views Inventory (two-way relations).

Blocked / in progress changes

• Finance legacy embedded databases — still have unique rows to migrate; not yet archived
• Similar-but-not-identical database merge — comparison complete for F1–F8 but no deletions approved
• Notion collection sources for page/bookmark duplicate sweep — blocked by integration token access

Additional content from Doc 1 — Backend Rebuild Changelog

• Countdown → Scene Elements
• Legacy fields remain until migration/reconnect verification.
• Created ❤️Paid Call Queue as an operational mirror.

Finance Reference

Single source of truth for Finance backend plan. See also: Finance Planner — Master Plan (Merged) page in Notion.

Canonical semantics

• Amount = actual paid/received (signed: negative for expenses, positive for income)
• Cost = base price pre-tax (positive always); keep alongside Amount where both filled
• Spent = abs(Amount) when Transaction Type = Expense (for budgets)
• Refunded = abs(Amount) when Transaction Type = Refund
• Net Spend = Spent − Refunded (default budget measure)
• Refund policy per category: Net Spend (default for most spending buckets) vs Ignore refunds (discipline buckets: Cash, Debt principal tracking, Income categories)
• Savings & Investments supports BOTH: outflow budgeting (contributions as "set aside" spend) AND goal tracking (target, progress, remaining)
• Month logic must support both "current month" filters AND historical attribution (when no longer current month, item still shows its original month)

Finance system — what is done ✅

• Transaction Type standardized to include Refund (Income + Expenses)
• Refund-aware transaction measures added (Spent, Refunded, Net Spend) on Expenses
• Monthly operational views created (Gross spent, Refunded, Net spend, Income only — all this month)
• Category refund policy + system budget formulas/rollups added
• Finance System Spec created; Legacy Removal List created; Verification Checklist used

Finance system — still to do 🔲

• Savings & Investments dual-mode: confirm + implement final wiring
• Month breakdown fixes: repair month formulas + ensure historical attribution everywhere
• Soft-retire duplicates (rename 🟫 … (legacy), hide, log) across remaining Finance DBs
• Verification pass: dashboards/charts/boards (final)
• Later: Unified Transactions ledger for platform ingestion

Future rule — Wishlist Purchased → Expenses

When refactoring Wishlist databases later:

• Treat Wishlist Items as Page Options (Products database)
• Purchased items link to a corresponding Expenses row
• Fan-purchased items should NOT become your Expense (they link to Customers/Requests instead)

Additional content from Doc 1 — Finance changelog

• Operational,
• Taxonomy / Config,
• old DB/property,
• Start Phase 1: Finance sweep (identify any finance DBs/pages still living outside Finances; log in Systems + decide keep/move)finance planner (keep for visual layout)
• Checklists
• Defined protected legacy set (see )
• Merge all checklists across the 3 convos into:
• Checklist 1 = Done
• https://indulgon.com/docs/PLATFORM-BLUEPRINT.html
• https://indulgon.com/docs/PLATFORM-OPERATIONS-MANUAL.html

Additional content from Doc 1 — Finance Planner Master Plan

• Mission
• 1) One “core record” per domain + bridges, not duplicates
• Page Options databases for shared entities/taxonomies (Accounts, Categories, Subcategories, Platforms, Customers, Wishlist Items, etc.)
• 3) Checkbook sign convention
• Money in = positive
• Money out = negative
• FINANCE PLANNER: CURRENT SCOPE (brown-square system databases)
• We standardize these first:
• Income ( / Income)
• Expenses ( / Expenses)
• 4.3 Refund-aware budgeting measures
• Spent (for budgets) = if Type=Expense → abs(Amount) else 0
• Default: use Net Spend anywhere you want “how much of my budget did I really use after refunds?”
• Shopping (Amazon, clothes, electronics)
• These are the recommended defaults for your current Finance planner Categories/Subcategories. (You can always override later; the point is to start consistent.)
• Business
• Education & Learning
• Entertainment
• Entertainment & Leisure
• Hosting
• Insurance
• Sports
• Savings & Investments (supports BOTH: outflow budgeting + goal tracking)
• Net Spend (default)
• Fine Dining
• Holidays & Travels
• Outdoor Activities
• Salon Visits
• Schooling
• Workshop & Seminars
• Allowance & Gifts
• Goal tracking (target, progress, remaining)
• 5) Month breakdown requirement (locked)
• “Current month” filters/views
• For Income/Expenses/Categories/Subcategories, inventory:
• Phase 5 — Month breakdown fixes
• Validate dashboards/charts/boards + key rollups.
• Added rollups:
• 2) Update this page’s checklist (check off items)

Additional content from Doc 1 — Finance repeated section

• All subject pages in the audit queue marked reviewed for the database-home pass.
• Ready-to-archive verification pass.
• do not delete anything without approval.

Additional content from Doc 1 — Finance taxonomy

• Convo 1 Part 2E–3B granular actions (index/governance structure)
• ❤️Customer Requests: https://www.notion.so/13fb864118fc81d6b517f9a948f7f45b
• Requirements:
• The feature does not exist on the platform yet, or
• If the backend has a DB/feature that is not represented on the frontend, either:
• Location (Rel) → ✨Operational Locations (for venues/operational places)
• Financial + commerce routing for unified daily view (required)
• Tasks + routines (prep/purchasing/packing workflows)
• Legacy Address text fields were preserved and renamed to: City (Legacy Text), State (Legacy Text), Country (Legacy Text).
• Determined to be different concepts, so not merged. Renamed for clarity:
• Status: safe to proceed without merging; delete is not applicable here.
• Master Blueprint (architecture, rules, integrations, critical decisions): https://indulgon.com/docs/PLATFORM-BLUEPRINT.html

Reference Library

Use this section for links to source material, databases, and sub-documents. The canonical rules are in Rules & Standards above. The canonical tasks are in NEXT ACTIONS above. Do not duplicate text here — link only.

Databases for planning

• 🟫 Master — Databases Inventory: https://app.notion.com/p/c49b864118fc8220aef7014196e61dc4
• 🟫 Master — Views Inventory: https://app.notion.com/p/3deb864118fc824f848e812ad2466ef2
• 🟫 Master — Subject Sections: https://app.notion.com/p/729b864118fc83f381ae815dbe8affe9
• Linked Systems — Planners (Index): https://app.notion.com/p/b60b864118fc835ca96481c9edc6390e
• Audit Queue: https://app.notion.com/p/804b864118fc8264a26b81e65a8417cc

Key reference documents

• Cleanup Review List — comparison findings, approval gating, exact duplicate audit findings → see Cleanup Review List section above
• Exact Duplicates — Verified Delete List — formatting-stable exact delete/keep pairs → see Exact Duplicates section below
• Backend Rebuild Changelog → see Backend Rebuild Changelog section above
• Finance reference/spec → see Finance Reference section above
• Genspark Connection Blueprint → https://indulgon.com/docs/CONNECTIONS.html
• Genspark Routes Index → https://indulgon.com/docs/ROUTES-INDEX.html
• Genspark DB Schema → https://indulgon.com/docs/DB-SCHEMA.html
• Master Plan / checklist: https://app.notion.com/p/fbaab2894de2498d93025c9de2fa488a
• Integrated Reconnect Checklist + Phases: https://app.notion.com/p/3dca345f6f004998853fc951a4ddab50
• Cleanup Review List page: https://app.notion.com/p/7d29a9b5fbb04fd9af8bdbf4625ce86e
• Original backup (Doc 1 source): 🟫🟫 Workspace Planner Consolidation — Master Plan (1) - Backup for Restructure

Source archive note

The original Doc 1 is preserved as the source archive for full legacy detail. Pull source sections into this merged plan only when needed. If moving archive material into this page later, keep it under the Reference Library section, not as new top-level sections.

Additional content from Doc 1 — Genspark reconnect reference

• Required vs optional properties (renaming/deleting required properties breaks sync)
• During our Notion re-org, any time we:
• we must reflect that change here and in Genspark’s Connection Blueprint so the platform can reconnect cleanly.
• Goal: keep reporting surfaces easy to find without mixing them into operational mirror lists.
• — progress summary surface
• Analytics / tracking (mostly operational logs, not primary dashboards)
• — film/series stats rollups (likely Film History; needs re-home/protected decision)
• (Dashboards & Analytics) — school/course tracker
• This page defines the canonical rules we’re implementing in your Finance Planner so everything stays consistent as you merge databases and later connect your platform.
• Spent (for budgets) = positive spend for Expense transactions: abs(Amount) else 0
• Special cases (refunds, reversals, partials)
• Gross spent (Spent) when Refund policy = Ignore refunds
• Confirm Income section includes:

Exact Duplicates — Verified Delete List

Do not reformat this section's internal formatting unless explicitly requested.

Rules: Each bullet is Delete → Keep (format: Delete page → Keep page)

Projects Database

• Delete: Master Todo → Keep: Master Todo (Master Todo)
• Delete: Meaning of life; reason to live → Keep: Meaning of life; reason to live
• Delete: Intuitive → Keep: Intuitive
• Delete: internet → Keep: internet
• Delete: In Progress → Keep: In Progress

Bookmark / tool duplicates (collection://172b8641) — DELETED ✅

Deleted: 172b864118fc805e9fdee2a53330b1c4, 172b864118fc80b8a275fb6111c8f37f, 172b864118fc80eda089f3ae2819e9e5, 172b864118fc80f19e29e1a9bae793bb, 172b864118fc800f8f8cc807dc820cf6, 172b864118fc804aa99cc24a238c7e63, 172b864118fc805292eefc72c7ad5ed7, 172b864118fc808fac0fd4c829e0bfa3, 172b864118fc80b0a331f48a6c78ecc3, 172b864118fc80c2bf12f2e7aba338b5

Keepers: 172b864118fc803cbc48ea46d265510a, 172b864118fc80a7b7ead215cd5e6b63, 172b864118fc800f838dd891ae790a69

OnlyFans / bookmark duplicates — DELETED ✅

Deleted: 172b864118fc802e94fefe4c7c6e11bf, 172b864118fc808a89fad35d22d57c0c, 172b864118fc80bfbe17ff7f2cdeca69, 172b864118fc80a5843dcaf75e259b76, 172b864118fc80fe99dfc6a3f1c44784

Keepers: 172b864118fc8008bfc1c54627ac8b7a, 172b864118fc80bfbd83e29fdb41b66d, 172b864118fc8033993ec29adfde37fe, 172b864118fc80a09647faedfc0d62e0

Additional page / bookmark duplicates — DELETED ✅

Deleted: 172b864118fc80a58529f3cb64488f31, 172b864118fc80bdb693c7147ad6a55c, 13fb864118fc81fcb25ad114d2ba5873

Keepers: 172b864118fc80009979ddb93ada21d5, 13fb864118fc81d4ba85fb8a97063e23

Project / note duplicates — DELETED ✅

Deleted: 13fb864118fc812c8b04e6792a68f195, 13fb864118fc81abb9eed5083a01de36, 196b864118fc81ae8972e5326152abf6, 196b864118fc8123b266d2529c74ce6e

Text-tool duplicates — DELETED ✅

Deleted: 172b864118fc80beb3e3c3ba35b1e964, 172b864118fc80c8b44dc7beaf28299b, 172b864118fc8064aa04f2d933ff6ad3

Notes / project duplicates (large batches) — DELETED ✅

Multiple batches from collection://196b8641 deleted in confirmed passes. Total: ~28 pages deleted.

Last canceled batch (NOT deleted — verify before acting):

• 196b864118fc81b3bc01e5b7c1c59d4d
• 196b864118fc81e89276c3713492950b
• 196b864118fc81b7ba24f4ece95199c3
• 196b864118fc8153b701f9ac3855bfcc
• 196b864118fc81e0bf4fdd6949c90569
• 196b864118fc81b8926bc15286520ae2
• 196b864118fc81b0add3c960b730cdda
• 196b864118fc81c5b839cf4fb33eab55
• 196b864118fc816c803fd6e536354b79
• 196b864118fc81c09daec6037abb8ee3

Note: Genspark verification confirmed ALL of the above canceled batch pages are already archived/gone. No action needed.

Known false positives — do NOT delete as exact duplicates

• FlexSeries™ Head Shaving Kit — actual URLs/tracking differ
• Start Page — rows point to different products/sites/tracking URLs
• WONDER BLADING Lip Stain Masque — ad/tracking URLs differ
• "Untitled" 16-row bookmark group (collection://172b8641) — each row has different actual Title link URL
• Calendar organization (collection://13fb8641) — same content but Start Date/property values differed
• To do still (collection://13fb8641) — same content but Start Date/property values differed
• New article — same template content but parent/schema/properties differed
• New Project (collection://196b8641) — rows differ by Status, Areas, ADD metadata, and/or database blocks
• Lyrics (collection://13fb8641) — different lyric content/subpages
• Business ideas JSAVONE — different child page URLs; do not delete unless child pages verified/merged
• Domain names — unknown bookmark blocks and media with different URLs
• Don't won't can't DWC by JJ — different image file URLs
• Glubclub.com ?? Or just glub.com — different image file URLs
• feature bio — content differs by event wording

Additional content from Doc 1 — Exact Duplicates list

• • Delete: Master Todo → Keep: Master Todo (Master Todo)
• • Delete: Meaning of life; reason to live → Keep: Meaning of life; reason to live (Meaning of life; reason to live)
• • Delete: Intuitive → Keep: Intuitive (Intuitive)
• • Delete: internet → Keep: internet (internet)
• • Delete: Ideas for apple → Keep: Ideas for apple (Ideas for apple)
• • Delete: Lion loves lion the lion → Keep: Lion loves lion the lion (Lion loves lion the lion (3/28/23, 2:28 PM))
• • Delete: movies → Keep: movies (movies)
• 🗑️ Exact Duplicate Pages Queue
• System config taxonomy
• (legacy — superseded by ✨Statuses Database)
• 2) Frontend ↔ backend audit (gap logic + reconnect strategy)
• 3) Canonical global taxonomy hubs (singletons)
• Addresses hub canonicalized + geo relations added; legacy text preserved. (Source: Convo 2 Part 1C)
• Created/maintained governance indexes: Operational Mirrors Index + Taxonomy & Config Databases + Dashboards & Reports Index + Protected Legacy DBs. (Source: Convo 1 Part 2E)
• Implemented broad “no select/multi-select long-term” pattern: for each operational DB, create taxonomy DB + add X (Rel) replacement + keep legacy select/multi-select for migration safety. (Source: Con
• Countdown → Scene Elements
• Unblocked schema edits by fixing only the broken/invalid view filters blocking database updates (preserving the ALL (Table) view focus). (Source: Convo 1 Part 1C)
• ❤️✨Content Tags → ❤️Scene Elements
• Dependency check: confirmed Styles database unused elsewhere; deleted legacy ❤️Styles database. (Source: Convo 1 Part 1D)
• Converted Service Subcategories (text) → relation and renamed to Subcategories (Rel); renamed DB to ❤️Subcategories. (Source: Convo 1 Part 1D–1E)
• Created “Operational Mirror Databases” index page and agreed: index links only; mirror DBs stay near domain hubs. (Source: Convo 1 Part 2D)
• Wishlist → Purchased → Expenses behavior (implement during Wishlist planner refactor). (Source: Convo 3 Part 3D + Finance appendix)

Linked Index — All Planners & Databases

Inventory only — do not move anything yet. This is a read-only-style reference index.

Finance

Primary Finance hubs (FINAL PLANNER):

• 💰Finances — canonical Finance hub
• Finances (hub)
• finance planner — keep for visual layout

Finance subpages (inside finance planner): Savings Tracker, Debt Tracker, Subscription Tracker, Annual Metrics (ready to archive), Company Database, Customer Database (ready to archive), Item Inventory Tracker (ready to archive)

Legacy/secondary finance pages (evaluate keep vs archive):

• 💸Moneyyyy (ready to archive / or keep for visual layout)
• Budget and Expenses (travel planner)
• 💸Finance Tracker (home planner)

Bookings & Scheduling

Move plan — grouped by existing subpage/home page:

• Locations page: ✨Locations
• Booking Calendar page: ✨Booking Calendar
• Availability page: ✨Availability
• VIP Events page: ✨VIP Events
• Video Call Sessions page: ✨Video Call Sessions
• Counter Offers page: ✨Counter Offers
• Rider Requirements page: ✨Rider Requirements
• Shifts (House Girl) page: ✨Shifts (House Girl)
• Escort Bookings page: ✨Escort Bookings

Projects & Tasks

Subject page: 📁Projects & Tasks | Intended planner: projects planner

Other hubs found: Projects Database, Projects (LIFE PLANNER ▸ PARA Backbone), Projects (LIFE PLANNER ▸ Master Dashboard), ORGANIZE INTO MAIN IDEAS AND PROJECTS DATABASES, Project Management Hub

Review list: Workspace Database Structure, 🔢Database Checklist Table, Remaining Manual Tasks - Consolidated View, 💫Task OS — ;;, Planning And Productivity

Products & Inventory

Subject page: 🛍️Products & Inventory | Hubs found: closet, Products & Inventory (systems copy), Item Inventory Tracker (ready to archive)

Review list: Wishlist Gift Inventory, shopping list, Wish List Databases, My closet

Services & Content

Subject page: 🎬Services & Content | Hubs found: posting planner, Content Hub, Media Library (LIFE PLANNER ▸ Databases ▸ Learning)

Review list: ✨Community Events, ✨Marketplace Listings, ✨Content Calendar, ✨Content Database, ✨Content Scheduling

Dashboards & Analytics

Subject page: 📈Dashboards & Analytics | Hubs found: Master Dashboard Page, OTHER DASHBOARDS

Review list: OKRs, Active Brain

People & Contacts

Subject page: 👥People & Contacts | Hubs found: Contacts/Birthdays, Contacts/Birthdays (WELLNESS duplicate surface), CRM, 📇Personal CRM (ready to archive / or keep for visual layout)

Review list: Leads To Notion CRM, 🫂Personal CRM: Contacts and Birthday tracker, Business Clients & Customer Birthdays, Contact List

Creative & Production

Subject page: 🎭Creative & Production | Hubs found: Mood Board, Shot List

Review list: Film making, 🖼️Mood Board (screenplay bootstrap), 🖼️Mood Board V2 (ready to archive / or keep for visual layout), Productions

Documents & Media

Subject page: 📄Documents & Media | Hubs found: Media Library (LIFE PLANNER dashboard), ✨Media Library (systems page), Content Hub

Review list: Resources, Timelane Library (IMDB-Style Store), Books Library (LIFE PLANNER dashboard), Books Library (LIFE PLANNER LEARNING)

Business Planner

Subject page: 📊Business Planner | Hubs found: 🤎work planner, Indulgon Social Media

Review list: Freelance Business, Untitled (Gain business insights), Content Hub

Personal Planner

Subject page: 👤Personal Planner | Hubs found: Master Dashboard Page, home planner, travel planner

Review list: meal planner, 〰️reads

Templates Reference

Subject page: 🎨Templates Reference | Hubs found: Template Examples — Reference Only, ✨Templates, ✨Landing Page Templates

Review list: Database Archive — DO NOT DELETE, template landing page, Notion Templates (home planner copy), Notion Templates (work planner copy), Notion Templates to Purchase

Additional content from Doc 1 — Linked Index

• Subscription Tracker
• Annual Metrics (ready to archive)
• Company Database
• Core embedded databases spotted (inside finance planner page)
• Subscriptions A (Legacy — Do Not Use) (embedded DB block)
• Accounts (Accounts view placeholder)
• Categories (Expense Categories view)
• Untitled (Income + Expenses combined view)
• Untitled (Categories view — Subscriptions filtered)
• (Monthly Expense gallery — ⭕️ Expense only)
• ✨Rider Requirements
• Shifts (House Girl) page
• Project Management Hub
• Review list:
• 🔢Database Checklist Table
• Item Inventory Tracker (ready to archive)
• Review list:
• ✨Booking Calendar (systems page)
• Subject page: 📈Dashboards & Analytics
• OTHER DASHBOARDS
• People & Contacts
• Contacts/Birthdays (WELLNESS duplicate surface)
• Hubs found elsewhere:

Full Detail Sections

These sections contain the complete source content from Doc 1 for reference. The summary above is the working version; these are the full details.

Operating Standards — Full Detail

Operating Standards📌

These are the operating standards for backend changes and reconnect work (what we do, when, and how). Global and task-specific rules live in the Rules toggle above. Checklists live in the Checklists section.

Operating standards — backend and reconnect-specific

Global hubs only when the concept is truly shared

If two properties represent the same underlying concept, they should point to one canonical taxonomy hub so cross-system aggregation works.

Examples of likely global hubs:

Platforms

Addresses

Cities

States

Countries

truly shared categories/types/tags

Do not consolidate just because labels match.

If two fields share a name but represent different lifecycle flows, keep them separate and rename clearly.

Example: Customer Request Statuses ≠ Inventory Statuses ≠ Invoice Statuses ≠ Task Statuses.

Same concept = consolidate.

Same label but different lifecycle = keep separate and clarify the name.

Normalize on touch

When opening or modifying a database for cleanup:

Review its select, multi-select, text-option, relation, rollup, and formula setup.

Convert option-like fields into relation-backed fields when appropriate.

Preserve legacy properties as “Legacy Text,” “Legacy Select,” “Legacy Multi-select,” or similar until frontend reconnect is stable.

Update view columns so views still make sense after renames.

Do not remove legacy properties during the same pass unless deletion has been approved and verified.

Ready-to-archive rule

A “ready to archive” database is only safe if:

a keeper exists for the same concept,

the keeper has all needed properties/settings,

unique pages/rows have been migrated or mirrored,

unique views/templates are recreated or documented,

page content, covers, icons, and files are preserved,

relations/rollups/formulas still work,

and Jillian approves the archive/delete list.

If the “ready to archive” label is on the wrong database, remove the label from the inventory row and treat it as a normal candidate.

Duplicate database merge rule

Before deleting a duplicate:

Compare database purpose.

Compare properties, types, relation targets, rollup targets, formula logic, options, templates, and views.

Choose the keeper based on richest schema, most real data, most useful layouts/views, most connected relations, and best canonical fit.

Add missing useful properties/views/templates to the keeper.

Move or mirror unique rows/pages into the keeper.

Preserve page content, cover images, icons, files, and templates.

Only mark the duplicate as delete/archive candidate after verification.

Show Jillian the approval list before any deletion/archive.

Identical duplicate rule

A possible duplicate can be deleted only if it is confirmed identical or fully migrated:

no unique properties,

no unique views,

no unique templates,

no unique rows/pages,

no unique content/media,

no unique relations/rollups/formulas/settings,

and no frontend dependency remains.

If any unique value exists, it must be merged, mirrored, or reviewed first.

Address normalization standard

Operational databases should point to with an Address relation.

City, State, Country, and ZIP should not stay as long-term free text/select fields when they are intended to be structured and reusable.

Preserve legacy text/select fields until migration and frontend reconnect are verified.

Closet / owned item lifecycle standard

Physical items should be trackable through a canonical owned-item lifecycle:

acquired,

in closet / owned,

packed / used / listed,

sold / donated / archived,

tied to purchases, sales, events, schedule blocks, customer requests, and inventory where applicable.

Frontend reconnect governance

Any time a database/property is renamed, replaced, merged, or made canonical:

log it in the Master Plan / changelog,

preserve legacy references until the frontend reconnect is stable,

update the reconnect mapping so Genspark knows the new source,

and verify that no route/form/dashboard depends on the deleted/legacy source.

Permission-blocked items

If a source is blocked by permissions:

log it as blocked,

do not make destructive assumptions,

do not delete or archive related items,

revisit after access is available.

Merge approval categories

Every cleanup candidate should be classified before action:

Keep — confirmed keeper.

Rename — keep it, but remove misleading labels or clarify purpose.

Merge into keeper — useful unique content must be moved into a keeper.

Mirror into keeper — direct migration is risky; reproduce the needed structure/content in the keeper.

Archive candidate — safe only after merge/mirror verification and approval.

Delete candidate — safe only if identical or fully migrated and approved.

Needs manual review — ambiguous, blocked, or tool cannot safely compare/move all content.

Final safety rule

No destructive action happens until Jillian receives and approves a review table that explains:

item name,

link,

current label,

proposed keeper,

proposed action,

why,

what was migrated/mirrored,

what remains unique,

Integrated Reconnect Checklist — Full Detail

Integrated Reconnect Checklist + Phases🧭

This page merges the active Master Plan phases with the Genspark reconnect checklist so the planner consolidation, backend rebuild, and frontend reconnect work are tracked in one organized place.

Current top-level status

Master inventory databases created:

🟫 Master — Databases Inventory

🟫 Master — Views Inventory

🟫 Master — Subject Sections

Subject section relation exists between Master Databases Inventory and Master Subject Sections.

Every captured database inventory row has a Subject Section relation.

All “(Unnamed…)” database inventory rows were resolved using their underlying database names.

Initial cleanup candidate review page created: Cleanup Review List — Merge / Rename / Archive / Delete

Cleanup comparison findings added for University & Education, Formats, Health/Habits, Email Templates, Shot List, Untitled Booking wrappers, Personal People vs Contacts, and same-underlying inventory-row duplicates.

Views Inventory still needs the full linked-view/location pass, including all view settings: filters, sorts, grouping/subgrouping, displayed properties, templates, calendar/timeline/map fields, chart/dashboard/form settings, and every linked location.

Cleanup review list still needs keeper/merge/archive/delete decisions before any destructive action.

Final frontend reconnect pass is not started.

Phase A — Inventory and section structure

Completed

Created master inventory surfaces.

Created Master Subject Sections database.

Added subject select options needed for all current subject pages.

Created and linked subject section rows for the active subject pages.

Linked database inventory rows to subject section rows.

Resolved unnamed Personal Planner, People & Contacts, and Film History inventory rows.

Confirmed there are no Master Databases Inventory rows missing Subject Section relation.

Remaining

Continue populating 🟫 Master — Views Inventory with every view and every linked-view location.

Capture view type.

Capture displayed properties/visible columns.

Capture filters, including simple and advanced filters.

Capture sorts.

Capture group-by and subgroup-by settings.

Capture default page template per view, if set.

Capture calendar/timeline/map fields, if applicable.

Capture chart/dashboard/form settings, if applicable.

Capture every linked location where the same database/view appears.

Clear subject pages into lightweight references only after their database and view inventory is fully captured.

Keep subject section pages as the non-empty homes for the database/view groupings.

Phase B — Cleanup review list before merge/delete/archive

Required before action

Build the cleanup candidate list:

duplicate-check rows,

ready-to-archive rows,

DELETE? / possible delete rows,

merge-review rows,

official / keeper clue rows,

repeated underlying database links,

same-purpose database clusters.

Add first-pass comparison findings to the cleanup review list for the active cleanup batches.

For each candidate group, compare:

properties,

relation targets,

rollup targets,

formula logic,

select/status/multi-select options,

rows/pages,

page content,

covers/icons/files,

views,

templates,

frontend dependencies.

Choose the keeper only after comparison.

Mark misleading labels for rename when “ready to archive” or “DELETE?” is wrong.

Produce an approval list before any archive/delete.

Destructive actions blocked until approval

No archive/delete until Jillian approves exact items.

No activating deletion confirmation buttons before the approval list is reviewed.

Phase C — Merge / consolidate

Process

Start with an exact duplicate audit before the broader similar-database merge pass.

For linked views, compare exact view name + exact settings first: properties, filters, sorts, grouping, templates, calendar/timeline/map/chart/dashboard/form settings, and linked location.

Treat linked views as exact duplicates only when settings are identical; the only allowed difference is the page/location where the linked view appears.

For exact duplicate linked views, keep the version attached to the richer/more complete page layout or the one with useful cover/photos/media/page content.

For underlying duplicate databases, compare schema, properties, relation targets, rollups, formulas, options, views, templates, rows, page content, covers, icons, files, media, and frontend dependencies.

Choose the keeper database based on richest schema, most complete data/content/media, best relations, best views/templates, and best frontend/canonical fit.

Before deleting/retiring a duplicate database, migrate or mirror useful views/templates/properties/rows/page content/media into the keeper.

Convert useful linked views into actual database views on the keeper where appropriate.

Identify databases that should become properties/relations instead of standalone databases.

Keep exact duplicates separate from similar-but-not-identical clusters until Jillian provides the separate similar-merge rules.

Add missing useful schema to keeper first.

Add missing views/templates to keeper or document why they remain separate.

Move/mirror unique pages and rows into keeper.

Preserve page contents, covers, files, icons, and templates.

Preserve legacy fields until frontend reconnect is stable.

Stage retired items in an end-of-project deletion queue only after verification.

Rename surviving databases/properties clearly.

Systems pages that are actually subject/section pages should be copied/moved into the Master Subject Sections structure, populated with needed properties, and then marked as cleanup candidates — not deleted until approved.

Add/confirm frontend/platform mapping fields for subject pages/sections after Jillian sends the Genspark mapping links.

Confirm the task/request model supports notes → tasks → customer requests / individual user requests, with rollups for request needs, closet/outfit needs, purchase needs, inventory items, and other action context.

Phase D — Global taxonomy hubs and canonical backend

Completed from Genspark Reconnect Map

Platforms hub canonicalized.

Geography hubs canonicalized:

Cities

States

Countries

Addresses hub canonicalized.

Statuses hub canonicalized where truly shared.

Address normalization standard documented.

“Global vs lifecycle-specific taxonomy” rule documented.

Taxonomy & Config index updated historically.

Hub-specific geo/platform duplicates converted into linked views where appropriate.

Continue taxonomy/config duplicate sweep.

Confirm every taxonomy hub that should be global is global.

Confirm every lifecycle-specific taxonomy stays separate and is named clearly.

Continue address normalization sweep for accessible databases.

Revisit blocked legacy address-like source when access is available.

Phase E — Customer Requests and commerce backbone

Completed from Reconnect Map

Customer Requests relation replacements added/confirmed:

Pay Status (Rel)

Shoot Status (Rel)

Scene/request metadata relations

Inventory items relation

Address relation

Content modeling decisions documented:

JOI + CEI → Interaction Styles

POV → Content Type

Countdown → Scene Elements

Cowgirl → Positions

Backbone target set documented:

❤️Customer Requests

❤️Items & Deliverables

❤️Item Catalog Titles

❤️Inventory

❤️Item Classes

Closet lifecycle standard documented.

Wishlist / purchase / event / schedule-block routing documented.

Keep legacy Customer Requests fields until all values/options are verified migrated.

Verify the final commerce + closet + inventory graph during reconnect.

Confirm every frontend commerce route/form points to the correct canonical database.

Phase F — Scheduling and unified day backbone

Canonical scheduling databases confirmed:

✨Booking Calendar

✨Availability

❤️Unified Schedule

Event Types updated for unified calendar surface.

Paid Call Queue requirements recorded.

Schedule Blocks created/connected.

Routine / Checklist Templates created/connected.

Unified “personal + business day-in-the-life” intent documented.

Verify every Today dashboard reads from canonical sources.

Confirm tasks, schedule blocks, events, expenses, income, sales, subscriptions, purchases, inventory, wishlists, and closet items all connect correctly.

Add missing relation/view surfaces discovered during the reconnect audit.

Phase G — Finance and legacy finance migration

Finance Changelog — Full Detail

Finance sign convention and refund logic implemented.

Finance dashboards converted to system fields.

Legacy subscription rows migrated into canonical Subscriptions Database.

Legacy income rows migrated into canonical Income Database.

Many legacy expense/income rows migrated into canonical finance keepers.

Legacy migrated rows archived in source databases to prevent future edits.

Remaining

Identify remaining legacy embedded finance databases that still have unique rows.

Migrate unique finance rows into canonical keepers.

Only delete/archive legacy finance databases after confirmation and reconnect verification.

Phase H — Structural planner UI and subject pages

Completed

Career subject pages re-sectioned.

Database blocks filed under subject headers.

Master Subject Sections structure established.

Database inventory home relation pass completed.

Structural-page UI hygiene sweep:

Operational,

Taxonomy / Config,

Dashboards / Reports,

Protected Legacy,

Review,

Cleanup Queue.

Finish master Views Inventory.

Reduce subject pages to lightweight references after inventory is complete.

Phase I — Genspark frontend reconnect

Compare Connection Blueprint property maps against current canonical Notion databases.

Build Reconnect Delta List:

old DB/property,

new canonical DB/property,

feature/route/form affected,

migration note,

status.

Verify every route/form/dashboard connects to canonical Notion sources.

Confirm no frontend references point to deleted or legacy databases.

Handoff final reconnect packet to Genspark.

Phase J — Final cleanup

Show Jillian final deletion/archive approval list.

Delete/archive only explicitly approved items.

Replace temporary brown-square keeper markers with final meaningful icons.

Final verification pass across all master inventory databases.

Next up

Build inventory page + linked views first (no moves):

Start with FINAL PLANNER → Finance sweep

Start Phase 1: Finance sweep (identify any finance DBs/pages still living outside Finances; log in Systems + decide keep/move)finance planner (keep for visual layout)

Checklists (from 3 convos)

Status: I can’t access the PDF convo files right now because they were flagged as potentially risky attachments, so I can’t extract the chat text from them.

To finish this section, please either (a) paste the convo text into the Convo pages as plain text, or (b) re-export/re-upload the PDFs in a way Notion allows them to be viewed (or provide a non-PDF version like .txt).

Checklists

Done (canonical)

Refund-aware budgeting system implemented + verified (see 🟫 Finance Refactor — Verification Checklist)

Legacy items tracked for finance (see Untitled)

Created inventory/index surface for planners & databases (see )

Established taxonomy/config index page (see )

Established dashboards/reporting index page (see )

Defined protected legacy set (see )

Not done / blocked (canonical)

Extract “rules / instructions / steps” from Convo 1–3 PDFs and convert from chat-format into clean rules + tasks

Blocker: attachments not viewable due to risk flag

Merge all checklists across the 3 convos into:

Checklist 1 = Done

Checklist 2 = Not done

Deduplicate repeated tasks (keep one canonical item)

Add any missing tasks implied by instructions but not explicitly captured in checklists

Confirm which Notion databases are authoritative sources for platform ingestion (users, profiles, customer requests, bookings, inventory, transactions, content)

Confirm mapping after database moves/renames (reconnect map)

Confirm bidirectional sync rules (create/update, conflict resolution, required fields)

Reference library (inputs)

Notion AI Chat Full Convos

External docs:

• https://indulgon.com/docs/PLATFORM-BLUEPRINT.html
• https://indulgon.com/docs/DB-SCHEMA.html
• https://indulgon.com/docs/ROUTES-INDEX.html
• https://indulgon.com/docs/PLATFORM-OPERATIONS-MANUAL.html
• https://indulgon.com/docs/CHANGELOG.html

Backend Rebuild Changelog📜

This page is the consolidated change log moved under the Master Plan from . It tracks high-impact backend changes, completed migrations, and reconnect-relevant notes.

Purpose

This log records backend changes that Genspark needs to understand during frontend reconnect:

canonical database decisions,

renamed/replaced databases,

relation/property changes,

migrated legacy rows,

preserved legacy fields,

cleanup candidates,

blocked/permission items,

and frontend mapping notes.

Authoritative platform reference links

Master Blueprint

API Routes Index

Database Schema

Connection Blueprint

Forms Index

Platform Operations Manual

Platform Changelog

Recommended external read order:

Blueprint

DB Schema

Routes Index

Operations Manual

Changelog

Canonical backbone currently documented

❤️Customer Requests

Canonical taxonomy hubs documented

Countries canonical data source: ✨Countries Database

High-impact completed changes

Products / inventory / customer-request backbone

Renamed “Products Details Database” → ❤️Item Catalog Titles.

Added ❤️Inventory Items relation on ❤️Customer Requests.

Migrated legacy inventory properties into ❤️Inventory.

Deleted legacy ✨Inventory Database after replacement by ❤️Inventory.

Moved “10min Scene - Office” out of Item Catalog Titles into ❤️Scene Types.

Migrated ❓✨Product Items Catalog rows into ❤️Items & Deliverables, then removed the duplicate after confirmation.

Consolidated Size Terms by keeping ❤️Size Terms (Do not delete) and deleting the duplicate only after merge/audit.

Renamed ❤️✨Content Tags → ❤️Scene Elements.

Renamed ✨Product Items → ❤️Items & Deliverables.

Established owned-item lifecycle logic through ❤️Inventory and ❤️Closet.

Customer Requests / content metadata

Added/confirmed relation replacements:

Pay Status (Rel)

Shoot Status (Rel)

Scene Elements / request metadata relations

Positions (Rel)

Address (Rel)

Inventory Items (Rel)

Confirmed content bucket placement:

JOI + CEI → Interaction Styles

POV → Content Type

Countdown → Scene Elements

Cowgirl → Positions

Legacy fields remain until migration/reconnect verification.

Scheduling / calendar / calls

Confirmed ✨Booking Calendar, ✨Availability, and ❤️Unified Schedule as canonical scheduling stack.

Added Customer Request relation from Booking Calendar.

Added rollups for request/contact/booking context.

Added Event Type relation to ❤️Unified Schedule.

Documented Paid Call Queue requirements and bundle behavior.

Created ❤️Paid Call Queue as an operational mirror.

Created ❤️Collaborations.

Added Event Types such as Call, Travel, Unavailable, Feature dancing, Convention, Skype show, and Custom video work block.

Unified day-in-the-life system

Documented personal + business unified daily operating model.

Created/connected Schedule Blocks.

Created/connected Routine / Checklist Templates.

Connected routines/tasks/schedule blocks to support convention/trip/customer-work daily planning.

Documented finance + commerce routing for Today surfaces.

Commerce / closet / item lifecycle

Created ❤️Closet (Owned Items Lifecycle).

Connected Closet to Products, Services, Inventory, Purchases, Sales Transactions, and Events.

Added/cleaned Today, By Event, and By Schedule Block views across:

Wishlists,

Subscriptions,

Purchases,

Inventory,

Supply Items,

Expenses,

Income,

Sales Transactions,

Closet.

Taxonomy / global hubs

Platforms canonicalized.

Geography canonicalized:

Cities,

States,

Countries.

Addresses canonicalized with City / State / Country relations.

Statuses canonical hub documented.

Hub-specific Platforms and Geography databases converted into linked views where appropriate.

Global-vs-lifecycle-specific taxonomy rule documented.

Address normalization

Address relation standard documented.

Known high-impact operational databases received canonical address/location/client relation handling.

Legacy City/State/Country/ZIP/text fields preserved as legacy fields.

Finance Taxonomy + Reconnect Rules

Finance dashboards converted to system fields (Net Spend-first + explicit Transaction Type filters). (Source: Convo 3 Part 3D)

Triage views driven to zero + sign checks verified. (Source: Finance Verification Checklist)

Standing rule only: if any new legacy finance items are discovered later during other planner sweeps, log + handle them. (Source: Finance plan standing rule)

Legacy finance migration (strict keeper-first, ongoing)

Migrated legacy subscription rows from “Subscriptions A (Legacy — Do Not Use)” into canonical ✨Subscriptions Database (kept duplicates like Hulu when present). (Source: Convo 2 Part 1H)

Migrated legacy income rows (e.g., “Paid by KDP” and legacy “Additional Income - ” clusters) into canonical ✨Income Database and archived legacy rows to prevent future edits. (Source: Convo 2 Part 1H + Reconnect Map changelog)*

Identify remaining legacy embedded finance DBs (Income/Expenses/Subscriptions/etc.) that still have unique rows, migrate into canonical keepers, then delete legacy DBs after confirmation. (Source: Convo 2 Part 1H)

Primary legacy “source area”: finance planner (keep for visual layout) (finance planner keep-for-layout). (Source: Convo 2 Part 1H)

9) Ready-to-archive consolidation workflow

Rules finalized (migrate unique rows/options → confirm delete). (Source: Convo 2 Part 1E–1F)

Film Schedule (ready to archive) handled (unique row migrated; archive deleted after confirmation). (Source: Convo 2 Part 1F)

Continue applying this rule to other “(ready to archive)” DBs as they are encountered during planner sweeps. (Source: Operating rules)

Convo 2 Part 1E–1H granular actions (stricter legacy handling)

Stricter rule adopted: do not “improve” legacy/ready-to-remove DBs; apply schema/views only on keeper DBs; legacy DBs only touched to migrate unique rows/options and then retire/delete after confirmation. (Source: Convo 2 Part 1H)

Legacy finance migration (ongoing): finish migrating remaining unique rows from legacy finance DBs (income/expenses/subscriptions/etc.) into canonical keepers, then delete legacy DBs after confirmation. (Source: Convo 2 Part 1H + finance migration batches)

10) Planner-by-planner re-org (systems + audit queue inventory)

Career subject pages re-sectioned (titles visible; DBs filed under correct headers; new headers marked (NEW)). (Source: Convo 3 Part 4E–4F)

systems inventory structure established (Area + Type + Item Kind + Original Planner + Home Page). (Source: Convo 3 Part 4B–4D)

Continue indexing all remaining planners/pages/DBs (outside LIFE PLANNER) into systems + link to Audit Queue subject pages. (Source: Convo 3 Part 4A + master plan)

Convo 1 Part 2E–3B granular actions (index/governance structure)

Decision: keep “structural pages” (Products & Inventory, Bookings & Scheduling, Services & Content, etc.) as the primary homes; add consistent headings per structural page (Operational, Taxonomy/Config, Dashboards/Reports, Protected Legacy as applicable). (Source: Convo 1 Part 2E)

Decision: index pages should be link catalogs (no duplicated embedded DB blocks). (Source: Convo 1 Part 2E)

Structural-page UI hygiene sweep: ensure every major structural hub page has the consistent headings applied and DB blocks placed under the right heading (Operational vs Taxonomy vs Dashboards vs Legacy), without duplicating DB blocks on index pages. (Source: Convo 1 Part 2E “do all of that”)

11) Final frontend reconnect (Genspark handoff)

After re-org completes: run final “frontend reconnect” pass using Connections.html + this page. (Source: Connection Blueprint)

Verify every route/form/dashboard connects to the correct canonical Notion DB and required properties (no references to deleted/legacy DBs). (Source: Connection Blueprint Part 2)

Canonical backbone (current)

• ❤️Customer Requests: https://www.notion.so/13fb864118fc81d6b517f9a948f7f45b

❤️Items & Deliverables:

❤️Item Catalog Titles:

❤️Inventory:

❤️Item Classes:

Recent changes (high impact)

Renamed “Products Details Database” → ❤️Item Catalog Titles.

Added ❤️Inventory Items (Rel) on ❤️Customer Requests so each request can link to the exact owned item instance.

Inventory consolidation:

Migrated legacy inventory properties into ❤️Inventory.

Deleted legacy ✨Inventory Database (replaced by ❤️Inventory).

Moved 10min Scene - "Office" out of Item Catalog Titles into ❤️Scene Types.

Merged and deleted duplicates:

Deleted ❓✨Product Items Catalog after migrating rows into ❤️Items & Deliverables.

Deleted ✨Size Terms (the deletable one). Canonical size DB remains ❤️Size Terms (Do not delete).

Scheduling + frontend calendar (new canonical structure)

✨Booking Calendar is canonical for bookings (agent/company/performer bookings).

Added relation: ❤️Customer Request (Rel) (only when a customer request becomes scheduled).

Added rollups from linked customer request for at-a-glance context (CR Name, CR Username, CR Email, CR Pay Status, CR Shoot Status, CR Rate).

Client should be linked via Client (Rel) → Contacts (not a text field).

✨Availability is canonical for availability rules/overrides.

❤️Unified Schedule (Frontend Calendar) is the unified customer-facing calendar surface.

Ingestion rule (platform-side): Upsert a Unified Schedule row when:

a Booking Calendar entry is created/updated

a Customer Request becomes scheduled (time-slot assigned)

an Availability override is created/updated

Added rollups so the calendar can render “at a glance” without opening related pages:

Customer request context (CR Name / Pay Status / Shoot Status)

Booking context (Booking Amount / Booking Status)

Contact context (Contact Name / Contact Email)

Added Event Type (Rel) pointing to ✨Event Types (System Config).

Paid Call Queue (new feature)

System name: Paid Call Queue

Requirements:

Customers can prepay to reserve a place in line.

Customers can choose Bundle calls:

Bundled prepaid calls create a single reserved block (e.g., 5×10min = 50min) where the performer is unavailable to others.

Frontend should show others that the performer is “On a call” plus the expected remaining/total duration, but hide private details.

Customers can also prepay without bundling (calls spread out), or call without prepay (opportunistic when the next slot opens).

Unified Schedule mirroring:

Calls should be represented as Unified Schedule rows with Event Type = Call, Start/End timestamps, and frontend-safe Public Label.

New database

Created ❤️Collaborations (links parties via Contacts; can link to Booking Calendar and/or Unified Schedule).

Event Types updated

Added Event Types for Unified Schedule:

Call

Travel

Unavailable

Feature dancing

Convention

Skype show

Custom video work block

Notes for reconnecting your platform

If your platform previously pointed at:

“Products Details Database” → reconnect to ❤️Item Catalog Titles.

“✨Inventory Database” → reconnect to ❤️Inventory.

Customer request → inventory linkage is now explicit via ❤️Inventory Items (Rel) on ❤️Customer Requests.

Frontend ↔ backend audit rule (gap logic)

If something you described in the frontend is not connected to something in Notion, it generally means one of:

The feature does not exist on the platform yet, or

It exists but is not connected correctly, or

It was connected previously but the backend re-org (renames/replacements/merges) broke the link.

The platform document links (Blueprint/Routes/DB Schema/Ops Manual/Changelog) should show what is (or was) connected.

Audit outcome rules:

If the frontend expects a DB/feature and the backend DB was replaced/renamed/merged, reconnect the frontend to the new canonical Notion source.

If the frontend expects a DB/feature and the backend DB is missing, create the missing backend database (or the correct canonical substitute) and document it here for reconnect.

If the backend has a DB/feature that is not represented on the frontend, either:

add it to the frontend roadmap (if desired), or

mark it as backend-only (Notion-only dashboards/views) so it’s not treated as a missing connection.

We are looking for gaps and ensuring the logic works in every direction:

frontend → backend (writes/updates land in the right canonical DBs)

backend → frontend (reads/dashboards pull from canonical DBs)

frontend → frontend (dashboard navigation routes to the correct page-level dashboards)

backend → backend (relations/rollups/views reflect the intended connected graph)

Product intent: unify Personal + Business into one day-in-the-life system (required backend routing)

The platform should treat Personal Planner and Business Planner as one unified operating system.

Goal: a single “Today” surface can show all tasks + schedule blocks across personal errands, customer work, filming, travel, conventions, and daily routines.

Convention example (Exxxotica-style): a convention is a multi-day “mode” where the system must track and relate:

Travel + lodging artifacts (flight tickets, hotel confirmations)

Event schedule blocks (signing hours, seminars, meetups)

Personal prep routines and timed reminders (hair by 2pm, makeup by 3pm, shuttle at 4pm)

Wardrobe/outfit planning + purchases (e.g., fake lashes before packing)

Repeatable per-day checklists (Day 1/Day 2/Day 3) plus arrival-day and recovery-day activities

Required relationship model (backend):

Event / Trip / Convention → has many Schedule Blocks (time-based) and many Tasks (action items)

Schedule Blocks should be able to reference:

Location (Rel) → ✨Operational Locations (for venues/operational places)

Address (Rel) → ✨Addresses Database (for hotel/venue/travel addresses)

People/Contacts (co-stars, staff, client/company)

Tasks should be able to reference:

the parent Event/Trip/Convention

a Routine/Checklist Template (so repeated days can be generated from the same routine)

prerequisites/dependencies (e.g., “Buy lashes” before “Pack bag”)

Implementation note for reconnect:

Even if some personal pages/databases started as “separate,” the intended end state is a single connected graph so the frontend can render a unified daily agenda.

Financial + commerce routing for unified daily view (required)

“Today” must include money in + money out tied to the same Event/Trip/Convention context:

Expenses (food, outfits, travel, alcohol, etc.)

Income (signing revenue, sales, etc.)

Sales transactions (per-purchase logs, including anonymous purchasers)

Each of the above must be linkable to:

Event (Rel) (for weekend totals)

Schedule Blocks (Rel) (for time-of-day context like “Panda Express at 5pm”)

Tasks + routines (prep/purchasing/packing workflows)

Desired analytics surfaces:

Daily at-a-glance (today)

Monthly + yearly rollups

Totals that can be segmented by circumstance (Convention vs Feature Appearance vs Customer Request, etc.)

Reference (verbatim): user requirements for full-life trackingSo Personal Planner pages should all connected to each other and initially before I started building my platform they were supposed to be separate from any of my Business Planner pages but now since the point of my platform is to unify everything in life from Personal Life and Business Life so someone can see all their tasks for the day for personal errands and etc as well as all the tasks they need to do for customers and for filming and etc so the day in the life of a pornstar can be repetitive sometimes like the same thing but a different day or different costar but then the more they add to what they do like going to conventions and so on the more they add to what they need to do behind the scenes like if companies hire them to sign for them like at Exxxotica they need to have all their information and what they need in one place like tickets for their flight, hotel confirmation, outfit strategizing and purchasing, schedule for their signing hours, and any other events they attend during the convention like a seminar or something. So all of this will be tracked and managed throughout my frontend through databases on my backend so we need to make sure that my system is set up like this so that I can see all my tasks for the convention including reminders to have my hair done by 2pm and makeup done by 3pm and leave on shuttle bus at 4pm or something like it really should help people keep track of their everyday lives from the moment they wake up to the moment they go to sleep. So my whole day for a convention would be wake up at noon, shower, blow dry hair, curl hair, makeup, contacts, fake nails, put on outfit for Day 1. So that should be a routine that is connected to events connected to tasks so if I need to buy fake eyelashes before I pack for the trip and etc. So then it repeats for each day of the convention so that particular convention is 3 days but I like to arrive a day early and stay a day after so then when not in convention mode I just order food to the hotel and watch tv or sometimes go out and site see. So all of this needs to be possible on my platform so we need to make sure Genspark knows this is how I want everything to be connected in case it is not something she has implemented so then we need to add the backend routing and figure out how to connect everything that way. So the goal is to finish adding any DBs that we need, removing ones we do not need, then handing off to Genspark everything she needs to do with the reconnecting everything and making sure that it runs the way I just described on the frontend since you should have everything connected on the backend before you hand anything off.

So you will need to add more relations for other DBs for the Today surfaces because as I just explained there will be more things connected so everything I just described included the food I order to my hotel room would include transactions so I can see okay while I was at this event I ordered from Panda Express at 5pm and spent $35 so then it also shows what I made during the conventions while signing and make $2,000 and the only expenses were my outfits for the weekend, airport food, hotel food, and alcohol. So it shows my income connected to that event and then it shows expenses and etc as well. So literally everything that happens each day is completely logged and available to see at a glance and then of course I can see a monthly view and yearly view as well and all the totals should calculate based on the different circumstances such as if it was a convention or a feature appearance or a customer request or etc. So all the different ways I make money or spend money and the details for everything should all be included so once again I can see the entire real time data for what is happening each day. So it would look like this where say on June 10, 2026 I have 3 personal bills due and 2 business bills due and for each 1 was paid already and then I need to buy an outfit for an event so then my wishlist items will show up when connected to the event so say I am on my amazon wishlist I add a few dresses I like and send them to notion wishlist DB and then connect it to the event and then I buy just 1 of the dresses so then I unlink the other 2 so they are still in my wishlist and not tied to this event and can be purchased for another event instead so then once I purchase the outfit I can track it through my platform and notion and see that it will arrive a day before my flight so then I can keep track of it and then it shows a packing list as well so I can see what I need to pack including the dress I bought once it arrives and then after I am all packed then add last minute todos such as stuff that needs to be done each time I travel such as feed the cat and etc. So then it is time for the flight and my platform should remind me and also have all my information so I can just click on the page and see my depart time and arrival time and the event information is connected as well so I can see once I arrive I need to freshen up and do my hair and makeup so I can go to the convention center by a specific time so then a task list for that as well such as what to bring for autographs and DVDs so there should be an inventory for that as well so when I buy DVDs in bulk which should also have DBs set up for buying them from the companies I film with or warehouses and then get them for a performer discount and then resell them for a higher price if I buy 60 of them I should be able to track the entire history or the DVD from the moment it was bought, sent, and sold. So then I see that I have 10 DVDs left of [Title 1] and 23 left of [Title2] and so on so then while I am at the convention signing then I can fill out details for the purchaser or just mark it as purchased by anonymous or something so I know what was bought on which day and so on. So that will keep track of my total of sales for each day and then show me how much I made by the end of the weekend and then when I am home I put my outfit that I wore up on my platform and say something like “I just wore this at Exxxotica in NJ who wants it? So then it is added to my “Closet” on the frontend and then it is added to the inventory databases as an item I currently own until it is bought by someone then of course all the is tracked and logged as well so who buys it, where to ship it, how much it sold for, and so on. So then my platform will have a comment feature where they can add a comment to their purchase and it is added a review that the customers set as either public or private.

Taxonomy consolidation + address normalization (backend changes)

Canonical hubs (do not duplicate):

✨Addresses Database: (data source: ✨Addresses Database)

✨Cities Database: (data source: ✨Cities Database)

✨States Database: (data source: ✨States Database)

✨Countries Database: (data source: ✨Countries Database)

✨Platforms Database: (data source: ✨Platforms Database)

✨Statuses Database (canonical statuses hub): (data source: ✨Statuses Database)

Platforms consolidation:

Hub-specific platforms DBs were converted into linked views of ✨Platforms Database:

View of ✨Platforms Database (Blacklist):

View of ✨Platforms Database (Connected Accounts):

✨Connected Accounts DB Platform relation repointed to canonical platforms (data source: ✨Platforms Database).

Address normalization:

✨Addresses Database now has canonical relations:

City (Rel) → ✨Cities (✨Cities Database)

State (Rel) → ✨States (✨States Database)

Country (Rel) → ✨Countries (✨Countries Database)

Legacy Address text fields were preserved and renamed to: City (Legacy Text), State (Legacy Text), Country (Legacy Text).

✨Vendors Database Address relation repointed to canonical ✨Addresses (✨Addresses Database).

Legacy geo DB converted:

“Countries (ready to archive)” was converted into a linked view of canonical ✨Countries (database: ).

Taxonomy index updated:

Taxonomy & Config Databases page updated to reflect canonical hubs: .

Needs access / blocked by permissions

Blocked data source: New database

Impact: cannot audit which databases still point at this legacy Address-like source.

Once access is granted: identify every relation pointing to New database and repoint to ✨Addresses Database (✨Addresses Database), preserving legacy text fields as “(Legacy Text)” where needed.

Ready-to-archive consolidation queue (pending deletion confirmation)

🗓️ Film Schedule (ready to archive) (🗓️Film Schedule (ready to archive))

Keeper exists: Film Schedule ()

Status: at least one unique row was migrated into keeper (page: Drone shot of the mountains, wide angle, 45mm lens, Mavic 3 pro). Deleted after confirmation.

✨Locations consolidation decision

Determined to be different concepts, so not merged. Renamed for clarity:

✨Operational Locations (was ✨Locations (ready to archive)) — scheduling/venues/operational

✨Scene/Travel Locations (was ✨Locations) — scene/travel/content

Status: safe to proceed without merging; delete is not applicable here.

Platform document package (authoritative source links)

• Master Blueprint (architecture, rules, integrations, critical decisions): https://indulgon.com/docs/PLATFORM-BLUEPRINT.html
• API Routes Index (all endpoints across all route files): https://indulgon.com/docs/ROUTES-INDEX.html
• Database Schema (all tables + columns): https://indulgon.com/docs/DB-SCHEMA.html
• Connection Blueprint (full frontend↔backend↔DB map + Notion property requirement map): https://indulgon.com/docs/CONNECTIONS.html
• Forms Index (all forms): https://indulgon.com/docs/FORMS-INDEX.html
• Platform Operations Manual (feature history + technical decisions): https://indulgon.com/docs/PLATFORM-OPERATIONS-MANUAL.html
• Platform Changelog (every build session recorded): https://indulgon.com/docs/CHANGELOG.html

Recommended read order for external AI tools: Blueprint → DB Schema → Routes Index (then Ops Manual + Changelog).

Genspark Platform Reconnect Reference — Full

Start here when reorganizing Notion: https://indulgon.com/docs/CONNECTIONS.html

Part 2 (“Notion Database Property Maps”) is the authoritative list of:

Notion DB IDs and .env variable names

Required vs optional properties (renaming/deleting required properties breaks sync)

DB-by-DB reconnection steps

During our Notion re-org, any time we:

rename/replace/merge a database, or

rename a property, or

add a new canonical database that the platform should sync to,

we must reflect that change here and in Genspark’s Connection Blueprint so the platform can reconnect cleanly.

Notion backend rebuild changelog (our internal)

Completed / verified

Canonical taxonomy hubs established/confirmed: Addresses, Cities, States, Countries, Platforms, Statuses.

Platforms consolidation:

Converted hub-specific platforms DBs to linked views of canonical ✨Platforms Database.

Repointed Connected Accounts → Platform (Rel) to canonical platforms.

Address normalization:

Updated ✨Addresses Database to use canonical City/State/Country relations and preserved legacy text fields.

Repointed ✨Vendors Database → Address relation to canonical ✨Addresses Database.

Repointed ❓✨Contacts Database → Address relation to canonical ✨Addresses Database (removed legacy relation target).

Users Database: added Address (Rel) → canonical ✨Addresses Database; renamed old Address/City/ZIP/State/Country fields as legacy.

❤️Customer Requests: added Address (Rel) → canonical ✨Addresses Database; renamed Address (if applicable) to Address (Legacy Text); updated key table views.

✨Locations (ready to archive): repointed Address relation from blocked legacy address source to canonical ✨Addresses Database.

✨Booking Calendar: added Location (Rel) → ✨Locations (ready to archive) and renamed old Location text to Location (Legacy Text).

✨Locations: added Address (Rel) → canonical ✨Addresses Database; renamed legacy “Adress” text to Address (Legacy Text).

✨VIP Events: added Venue (Rel) → Venues and renamed old Venue text to Venue (Legacy Text).

✨Shifts (House Girl): added Venue (Rel) → Venues and renamed Venue title to Venue (Legacy Title).

✨Counter Offers: added Client (Rel) → Contacts and renamed Client text to Client (Legacy Text).

✨Companion Bookings: added Address (Rel) → canonical ✨Addresses Database and renamed Location text to Location (Legacy Text).

✨Video Call Sessions: added Client (Rel) → Contacts and renamed Client title to Client (Legacy Title).

✨Availability: added Location (Rel) → ✨Locations (ready to archive) and renamed Location text to Location (Legacy Text).

Shot List: added Location (Rel) → ✨Locations (ready to archive) and renamed Location select to Location (Legacy Select).

Film Schedule: added Location (Rel) → ✨Locations (ready to archive) and renamed Location select to Location (Legacy Select).

🗓️ Film Schedule (ready to archive): added Location (Rel) → ✨Locations (ready to archive) and renamed Location select to Location (Legacy Select).

✨Bookings: renamed Type select to Type (Legacy Select) (Type (Rel) remains canonical).

✨Video Call Sessions: renamed Platform/Tier/Status selects to (Legacy Select).

✨Counter Offers: renamed Mode/Status selects to (Legacy Select).

✨Shifts (House Girl): renamed Status select to Status (Legacy Select).

✨Companion Bookings: renamed Screening/Status selects to (Legacy Select).

✨VIP Events: renamed Status/Type selects and Perks multi-select to legacy names (rel properties remain canonical).

✨Rider Requirements: renamed Category/Priority selects to (Legacy Select).

✨Availability: renamed Type select to Type (Legacy Select) (Type (Rel) remains canonical).

✨Booking Calendar: renamed Status/Service/Type selects to (Legacy Select) (rel properties remain canonical).

✨Contracts Database: renamed blocked Address relation to Address (Legacy Rel); canonical address relation remains Related to Addresses (Contract).

Created ✨Schedule Blocks (time-based blocks) and connected it via two-way relations to both Personal Tasks and Business Tasks.

Created ✨Routine / Checklist Templates and connected it via two-way relations to Schedule Blocks, Personal Tasks, and Business Tasks.

Linked ✨Wishlists Database to Events and Schedule Blocks (so outfits/purchases can be tied to a convention/trip day and appear in the unified daily context).

Added views to ✨Wishlists Database: By Event, Unassigned (No Event), and Today (Wishlist).

Created ❤️Closet (Owned Items Lifecycle) and connected it to Products, Services, Inventory, Purchases, Sales Transactions, and Events for full item history tracking.

Upgraded ✨Subscriptions Database with Next Payment Due + Event/Schedule Block relations and added Today (Subs Due) + Upcoming views.

Upgraded ✨Purchases Database with Schedule Blocks (Rel) and added Today (Purchases) + Upcoming (Delivery Req) views.

Upgraded ❤️Inventory with Event/Schedule Block relations and added Today (Arrivals) + By Event views.

Upgraded Supply Items Database with Event/Schedule Block/Closet relations and added Today (Expected Arrival) + By Event views.

Batch update: added Products/Services/Closet view surfaces and expanded Sales Transactions views to include Closet linkage.

Batch update: added Schedule Blocks Today (Logistics) view + added By Schedule Block/By Event views for Wishlists, Subscriptions, and Purchases.

Batch update: added By Event / By Schedule Block views for Expenses, Income, Sales Transactions, and Inventory.

Batch update: cleaned up duplicated relation properties in view columns (Closet, Subscriptions, Purchases, Inventory) to keep the UI clean while preserving data.

Batch update: added By Schedule Block views for Income, Purchases, Subscriptions, and Supply Items.

Batch update: cleaned By Schedule Block + logistics-related views to remove duplicate relation columns (Supply Items, Subscriptions, Purchases, Income).

Batch update: cleaned the new canonical linked views (Subscriptions/Income/Customers) so they only show canonical columns (no duplicate relation properties).

Batch update: added canonical linked views inside legacy Subscriptions pages and the Item Inventory Tracker (ready to archive) page (Inventory + Closet).

Batch update: cleaned those legacy-page canonical linked views (Subscriptions + Inventory + Closet) to show only canonical columns.

Audit note: found legacy subscription trackers ("Subscriptions A" and "Subscription" inside Subscription Tracker (ready to archive)); canonical Subscriptions views are now embedded on those pages, but the legacy trackers still exist and should only be deleted after confirming all unique rows are migrated.

Audit note: found a separate "Income Database (ready to archive)" data source; canonical Income views are embedded, but legacy DB still exists pending migration + deletion confirmation.

Batch update: added + cleaned Today-focused canonical linked views for legacy pages (Subscriptions Today; Income Due Today; Inventory Arrivals Today; Closet Today).

Migration batch: moved 4 legacy subscription rows (Disney Plus, New York Times, Dropbox, HBO Max) from Subscriptions A (Legacy — Do Not Use) into ✨Subscriptions Database.

Migration batch: moved 4 legacy subscription rows (Notion, Netflix, Google One, Greyscalegorilla Plus) from Subscriptions A (Legacy — Do Not Use) into ✨Subscriptions Database.

Migration batch: moved 4 legacy subscription rows (Github, Namecheap, Hulu, 1Password) from Subscriptions A (Legacy — Do Not Use) into ✨Subscriptions Database.

Migration batch: moved remaining legacy subscription rows (X Blue, YouTube, Adobe Creative Cloud) from Subscriptions A (Legacy — Do Not Use) into ✨Subscriptions Database.

Migration batch: moved legacy income row (Paid by KDP) from Income Database (Legacy — Do Not Use) into ✨Income Database.

Cleanup batch: archived legacy rows after migration (Subscriptions A legacy rows + Income legacy row) to prevent future edits in legacy databases.

Migration batch: moved 4 legacy expense rows (Dinner w/Yanni, Party with Friends, Lunch w/Dad, Books) from legacy Expenses (ready to archive) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 4 legacy expense rows (Rent, Hulu, Groceries, Hulu) from legacy Expenses (ready to archive) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 4 legacy expense rows (Paper Towels, Movie Tix 🍿, Student OS, New Expense) from legacy Expenses (ready to archive) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 4 legacy expense rows (Cell Phone, Laundry, Dinner w/Cheryl, Rent) from legacy Expenses (ready to archive) into ✨Expenses Database, then archived the legacy rows.

(Dedup note): Those 4 duplicate canonical expense pages were immediately deleted (kept the original canonical pages from the prior batch).

Migration batch: moved 4 legacy expense rows (MacBook, Car Payment, Hulu Subscription, Subscriptions(Budget line item)) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 3 legacy spending-history rows (Retreat Food, Spring Retreat Cabin, Rental Cars) plus 1 blank row marker from “2022 Finances” (Spending History ready to archive) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 1 legacy travel-expense row (“expenses name” / $100 hotel) plus 3 blank travel-expense rows from Travel Planner → Expenses (ready to archive) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 4 legacy expense rows (Subscription x4 monthly placeholders with dates) from legacy Expenses (ready to archive) (Expenses) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 4 more legacy “Subscription” placeholder rows (dates: 2025-09-01, 2025-10-01, 2025-11-01, 2025-12-01; amounts blank) from legacy Expenses (ready to archive) (Expenses) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 4 legacy travel-budget rows (Shopping and Souvenirs, Meals and Drinks, Communication and Internet, Miscellaneous) from Travel Planner budget table (Expenses (ready to archive)) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 4 legacy travel-budget rows (Accommodation, Sightseeing and Activities, Meals and Drinks, Miscellaneous) from Travel Planner budget table (Expenses (ready to archive)) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 1 legacy earnings row (Money from grandma, $20 on 2023-12-17) from Earnings (Earnings) into ✨Income Database, then archived the legacy row.

Migration batch: moved 4 legacy expense rows (Phone plan, Dinner w/ Cheryl, Groceries, Books) from legacy Expenses (ready to archive) (Moneyyyy) (Expenses (ready to archive)) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 1 legacy expense row (Coffee, $6) from legacy Expenses (ready to archive) (Expenses (ready to archive)) into ✨Expenses Database, then archived the legacy row.

Migration batch: moved 3 legacy expense rows (Online Shopping, Food, Electricity Bill) from legacy Expenses (ready to archive) (Expenses (ready to archive)) into ✨Expenses Database, then archived the legacy rows.

Migration batch: moved 4 legacy income rows (“Additional Income - 2” x4, $325 each) from legacy income pages into ✨Income Database (Source=Legacy income import), then archived the legacy rows.

Migration batch: moved 4 more legacy income rows (“Additional Income - 2” x4, $325 each) from legacy income pages into ✨Income Database (Source=Legacy income import), then archived the legacy rows.

Migration batch: moved 3 more legacy income rows (“Additional Income - 2” x3, $325 each) from legacy income pages into ✨Income Database (Source=Legacy income import), then archived the legacy rows.

Census batch: identified remaining not-archived legacy “Additional Income - 2” pages, then migrated next 4 (Dec 2024, Aug 2024, Sep 2024, Feb 2024) into ✨Income Database, and archived those legacy rows.

Census batch: migrated next 4 remaining legacy “Additional Income - 2” pages (Jul 2024, Sep 2023, Aug 2023, Jul 2023) into ✨Income Database, and archived those legacy rows.

Census batch: migrated final remaining legacy “Additional Income - 2” page (Feb 2023) into ✨Income Database, and archived that legacy row.

Census batch: migrated 4 legacy income rows (Additional Income - 1 x2 @ $5,647; Additional Income - 4 x2 @ $98) into ✨Income Database (Source=Legacy income import), and archived the legacy rows.

Census batch: migrated 4 more legacy income rows (Additional Income - 4 x4 @ $98) into ✨Income Database (Source=Legacy income import), and archived the legacy rows.

Census batch: migrated 4 legacy income rows (Additional Income - 4: $98 and $10; Additional Income - 3 x2 @ $100) into ✨Income Database (Source=Legacy income import), and archived the legacy rows.

Census batch: migrated 2 more legacy income rows (Additional Income - 3 x2 @ $100) into ✨Income Database (Source=Legacy income import), and archived the legacy rows.

Census batch: migrated 1 legacy income row (Additional Income - 1 @ $5,647; May 2024) into ✨Income Database (Source=Legacy income import), and archived the legacy row.

Legacy geo cleanup:

Converted “Countries (ready to archive)” into a linked view of canonical ✨Countries.

Indexing:

Updated Taxonomy & Config Databases index to reflect canonical hubs and mark legacy statuses.

Blocked / needs access

Cannot open/audit legacy Address-like data source: New database.

Master checklist (cross off as we complete)

Establish canonical hubs for Platforms + Geography + Address.

Convert obvious duplicate hub DBs into linked views (where found).

Repoint known operational relations (Connected Accounts Platform, Vendors Address, Users State/Country).

Update taxonomy index pages to reflect canonical hubs.

Pre-global taxonomy phase (historical): performed initial per-database select/multi-select → relation conversions and taxonomy DB creation before canonical “global hubs” were finalized; later normalized these into global hubs where applicable.

People & Contacts sweep: add relation replacements and new taxonomies (Users State/Country; Client Relationships; Client Interactions; Activity Log; Testing Records; Presenters; Makeup Artists; Friends) and index them in Taxonomy & Config Databases.

Customer Requests sweep: add relation replacements for Pay Status, Shoot Status, Tags and create their taxonomy DBs; keep legacy fields for migration.

Customer Requests sweep (scene/request metadata): ensured Customer Requests has relation-based fields for request content modeling (Interaction Styles, Scene Elements, Content Type, etc.).

Bookings & Scheduling sweep: confirm canonical ✨Booking Calendar / ✨Availability / ❤️Unified Schedule; convert VIP Events, Counter Offers, Rider Requirements, Shifts, Companion Bookings to taxonomy relations; index new taxonomies.

Finance sweep: convert Promo Codes, Recurring Transactions, Expenses to taxonomy relations; create and index finance taxonomies.

Dashboards & Analytics audit: verify core tracking DBs already have (Rel) replacements where needed (Conversion Tracking, A/B Tests, Analytics Events, Points Rewards, Badge DBs).

System Config audit: verify key operational DBs already have (Rel) replacements where needed (Moderation Queue, Support Tickets, Report Flag, Content Filters, Platform Sync, Notifications, Messages).

Rename cleanup: replace “Escort” naming with “Companion” in operational taxonomy/pages and rename Escort Bookings DB to Companion Bookings.

Merge duplicate dashboards DBs: merged ✨Badge Achievement into ✨Badge Achievements and deleted the duplicate DB after confirming both were empty (0 rows). (Source: Convo 1 Part 3F + SQL row count check)

Address normalization sweep (ongoing): find every accessible operational DB with City/State/Country/Zip text/select OR non-canonical Address relation; convert to canonical Address relation (preserve as Legacy Text).

Taxonomy consolidation sweep (ongoing): audit remaining taxonomy/config DBs (types/categories/status-like) and enforce “one canonical hub per taxonomy”.

Hub completion sweep (remaining): finish auditing remaining top-level hubs not fully swept yet (Business Planner, Personal Planner, Documents & Media, and any “systems/legacy” areas) for select/multi-select without (Rel) replacements; convert + index.

Post-migration cleanup (later): once frontend reconnect is stable, remove/retire legacy select & multi-select properties and delete unused relation properties/views (keep Tags multi-select only where explicitly required).

Reconcile/repair anything that still points to blocked legacy sources once access is granted (e.g., New database).

Final “frontend reconnect” pass: map platform documents (Blueprint/DB Schema/Routes) to the canonical Notion backend sources and verify integrations don’t reference deleted/legacy DBs.

Dashboards & Reports Index📊

This page indexes dashboard/reporting databases and views (read-focused surfaces).

Goal: keep reporting surfaces easy to find without mixing them into operational mirror lists.

Current hubs

📈Dashboards & Analytics

Dashboards & Analytics (reporting surfaces)

— KPIs/targets vs current, with linked financial data, expenses, tasks, and related orders

— daily focus list: category/priority/status + linked orders/bookings/tasks/notifications

— finance summary surface

— progress summary surface

Analytics / tracking (mostly operational logs, not primary dashboards)

— analytics metrics by date/content/client (used by content ops)

— event log (operational)

— operational tracking

— operational experimentation log

— operational notifications queue

Gamification (operational config / logs)

— badge definitions/config

— badge definitions/config (duplicate naming to audit)

— points ledger/config

Dashboards & Analytics (additional surfaces to classify)

— rollups/progress across projects/tasks/bookings/invoices/deliverables/expenses (reporting surface)

— OKR tracking (reporting/strategy surface)

— dashboard gallery/index (navigation surface)

— personal analytics rollups (needs “Protected Legacy” decision)

— appears to be an event/budget overview dashboard (needs “Protected Legacy” decision)

— personal stats rollups (needs “Protected Legacy” decision)

— film/series stats rollups (likely Film History; needs re-home/protected decision)

— school/course task tracker (needs “Protected Legacy” decision)

Next in audit

Identify which databases on each structural page are primarily reporting (dashboard/summary) vs operational.

Add the reporting databases here with their home location and what they report on.

Protected Legacy Databases (Do Not Delete)🛡️

This page indexes legacy databases that are protected and should never be deleted or merged without explicit confirmation.

Use it as a safety checklist during dedupe/audits.

Protected legacy sets (per your rule)

Agent databases (legacy booking/history)

JJENT databases (legacy booking/history)

Dance databases (legacy booking/history)

Newly flagged “Protected Legacy” candidates (needs your confirmation)

(Dashboards & Analytics) — personal analytics rollups

(Dashboards & Analytics) — event/budget overview dashboard (looks legacy/personal)

(Dashboards & Analytics) — personal stats rollups

(Dashboards & Analytics) — school/course tracker

(Dashboards & Analytics) — film/series stats rollups (likely belongs under Film History)

As I encounter each protected legacy database in Final Planner, I will add it here (with its home page and what it represents).

If a dedupe candidate touches one of these, I will stop and ask for confirmation.

🟫 Legacy Removal List (Finance cleanup)

This tracker lists every property/page/database we mark as legacy during the Finance cleanup, so we can safely delete later after verification.

How to use

When something is soft-retired, rename it to: 🟫 (legacy)

Hide it from views

Add an entry belowDate markedDatabaseLegacy itemReplaced byWhy legacy?Dependencies updated?Safe to delete?Notes2026-06-15CategoriesRemaining🟫 Remaining (system)Refund-aware budgetingYesYes (deleted)Deleted after dependency sweep2026-06-15CategoriesBudget Progress🟫 Budget Progress (system)Refund-aware budgetingYesYes (deleted)Deleted after dependency sweep

Deletion workflow

Verify all key dashboards/views use non-legacy fields

Ensure no formulas/rollups reference the legacy field

Delete legacy fields in small batches

Re-verify charts/boards

🟫 Finance System Spec (canonical rules)

System Spec (Finance backend)

This page defines the canonical rules we’re implementing in your Finance Planner so everything stays consistent as you merge databases and later connect your platform.

Core principles

Property Selects for numeric + transactional attributes (Amount, Cost, Tax, Fees, Paid, dates, etc.)

Page Options (dedicated databases) for shared entities/taxonomies (Accounts, Categories, Subcategories, Platforms, Customers, Wishlist items, etc.)

One core record per domain + bridges, not duplicates

Soft-retire before delete: rename deprecated items to 🟫 … (legacy) and log them in the Legacy Removal List

Canonical money semantics

Amount (signed checkbook ledger)

Income = positive Amount

Expense = negative Amount

Refund = positive Amount (cash back), but it is not Income

Cost (base price)

Cost is the base price pre-tax/fees (typically positive).

Example: Cost = 29.99, Amount = -35.50 after taxes/fees.

Transaction Type (canonical)

🟢 Income

⭕️ Expense

🔁 Refund

💳 Chargeback

💵 Debt

(Later) 🔁 Transfer / Move Money (if needed)

Refunds & budgeting measures (do not confuse refunds with income)

We track three budgeting measures on each transaction:

Spent (for budgets) = positive spend for Expense transactions: abs(Amount) else 0

Refunded = positive refund amount for Refund transactions: abs(Amount) else 0

Net Spend = Spent − Refunded

This supports the views you want:

Gross spent (Spent)

Refunded

Net spend

Income only (Income, excluding refunds)

Special cases (refunds, reversals, partials)

Partial refunds: log as 🔁 Refund with the refunded amount (positive Amount). Net Spend naturally reflects the partial recovery.

Chargebacks/reversals: treat as 🔁 Refund unless you want a separate “Chargeback” type later. (Net Spend behavior is the same.)

Refunds that shouldn’t “cancel” the original spend in reporting: use Gross spent for behavior/budget discipline views; use Net Spend for true net budget impact (default).

Budget policy by category

Each Category has a Refund policy:

Net Spend (default for most categories)

Ignore refunds (discipline/special-case buckets)

Budget usage should use:

Net Spend when Refund policy = Net Spend

Gross spent (Spent) when Refund policy = Ignore refunds

Legacy cleanup rule (when to delete)

Formula/Rollup legacy fields: delete as soon as all dependencies (views, charts, formulas, buttons) are migrated to the system fields.

Stored-data legacy fields (number/text/select/etc.): migrate values + verify first, then delete.

Month breakdown requirement

We must support:

“Current month” views (based on the transaction Date)

Historical attribution (Month+Year or Month View relations) so past months still show correctly even when they’re no longer current.

🟫 Finance Refactor — Verification Checklist

Purpose

This is the running QA checklist for the Finance Planner system refactor (refund-aware budgeting + canonical sign conventions).

Current system status (high-level)

Categories: refund-aware budget system fields in place; legacy Remaining/Budget Progress deleted after dependency sweep.

Subcategories: refund-aware budget system fields in place.

Expenses: refund-aware measures (Spent / Refunded / Net Spend) in place; triage views added.

Income: month breakdown views added; triage view added.

Canonical rules: documented in 🟫 Finance System Spec (canonical rules).

Verification checklist (do next)

A) Finance planner page views (visual layer)

Confirm the “Categories” section is showing 🟫 Remaining (system) / 🟫 Budget Progress (system) (not any legacy fields). (Database config verified)

Confirm any charts on the Finance planner page that reference budget remaining/progress are using the 🟫 system properties. (Updated the main Categories charts earlier; visual confirmation on page still optional)

Confirm Expenses section includes:

🟫 Gross spent (this month)

🟫 Refunded (this month)

🟫 Net spend (this month)

🟫 Month breakdown (by Date)

Confirm Income section includes:

🟫 Income by month (Date)

B) Triage views (to prevent silent data issues)

Expenses

🟫 Needs classification (Transaction Type empty) should trend toward zero (now 0)

🟫 Missing category should trend toward zero (now 0)

🟫 Missing subcategory should trend toward zero (now 0)

C) Canonical sign checks (ongoing guardrails)

Transaction Type = ⭕️ Expense ➝ Amount should be negative (0 violations)

Transaction Type = 🔁 Refund ➝ Amount should be positive (0 violations)

Transaction Type = 🟢 Income ➝ Amount should be positive (0 violations)

Transaction Type = ⭕️ Expense ➝ Amount should be negative (rare if used) (0 violations)

Master plan checklist (full plan)

This is the end-to-end checklist from the overall plan (not just the verification pass).

1) Refund policy special cases

Decide special-case rules (partials, chargebacks/reversals, Gross vs Net reporting)

Document rules in Finance System Spec

(Optional) Add a dedicated “Chargeback” Transaction Type (only if you want it distinct from Refund)

2) Expenses cleanup (Cost → Amount, legacy removals)

Scan for Cost-filled rows with missing Amount (none found)

Fix canonical sign issues for Expense rows (positive Amount ➝ negative)

Add Expenses triage views (Needs classification / Missing category / Missing subcategory)

Drive triage views to zero (Transaction Type / Category / Subcategory)

Add a “Stubs / demo (incomplete)” view in Expenses to isolate incomplete rows

(Optional) Decide what to do with “demo/stub” rows (archive/delete vs keep) (archived the placeholder stubs with no Amount + no Date)

(Future) If you later remove stored-data legacy fields (not formulas), migrate values first then delete

3) Income cleanup

Run canonical sign checks (no violations)

Add Income triage view (Needs classification)

Drive Income triage to zero (Transaction Type)

4) View/dashboard verification pass (Finance planner visual layer)

Categories: system Remaining/Progress in place (legacy deleted after dependency sweep)

Triage views: all trend to zero (now 0)

Canonical sign checks: verified (0 violations)

Visual confirmation on the Finance planner page:

Expenses DB has the 🟫 month views (Gross/Refunded/Net + Month breakdown) (database config verified)

Income DB has the 🟫 month breakdown views (database config verified)

Any remaining page-level charts/dashboards are using 🟫 system fields (swept the linked dashboard views and switched Amount-based ones to Net Spend / explicit Transaction Type filters)

Page-level Expenses views switched from Amount → Net Spend (View of Income and Expenses)

Budget Monthly Overview totals switched to refund-aware Net Spend (Total Expenses/Total Spent)

5) Legacy Removal List maintenance

Maintain Legacy Removal List page

Update Categories legacy entries to “deleted”

Add any future legacy items here before deletion

6) Longer-term milestone (optional): Unified Transactions ledger

Decide whether to merge Income + Expenses into one Transactions DB (recommended later, not required now)

If merging: define canonical schema for frontend CSV/forms → Notion (single ingestion format)

Notes / decisions logged

Refund special cases are documented in the Finance System Spec (partials, reversals/chargebacks, and Gross vs Net reporting).

Automated verification findings (this run)

Categories database has only the system fields for Remaining/Progress (legacy versions are deleted).

Income canonical sign checks: no violations found.

Expenses canonical sign checks: corrected a batch of Expense rows that had positive Amount values.

Triage counts (current)

Transaction Type empty: 0

Category missing: 0

Subcategory missing: 0

Finance Planner Master Plan — Full

Finance Planner — Master Plan (Merged)

This page is the single source of truth for: (1) the full Finance backend plan, (2) everything completed so far, (3) what’s left, and (4) how we’ll report progress and track legacy items.

Below is the updated, final blueprint plan (written exactly in the “paste into a new chat” style), merged with everything we just decided:

Hybrid system (Property Selects for numeric + transactional attributes; Page Options for shared entities/taxonomies)

Checkbook sign convention

Refund handling (Refund ≠ Income; refunds tracked separately; budgets usually use Net Spend; special cases ignore refunds)

Categories/Subcategories refund-policy labeling (Finance planner set)

Savings & Investments supports both: outflow budgeting and goal tracking

Soft-retire (“legacy”) + maintain a tracked list for later deletion

Future: unify Income/Expenses/other earnings into a Transactions ledger (for platform ingestion)

“Brown square icon” marking for canonical system databases

Month breakdown requirement: keep month history even when not current month

Canonical system pages (live links)

🟫 Finance System Spec (canonical rules):

🟫 Legacy Removal List (Finance cleanup): Untitled

🟫 Finance Refactor — Verification Checklist: 🟫 Finance Refactor — Verification Checklist

MASTER BLUEPRINT (Finance-first, then planner-by-planner)

Mission

Clean and standardize the workspace one planner at a time, starting with Finance, so the backend is stable for:

Notion UX (views, galleries, label-style “notification center” pages)

Platform integration (forms, CSV imports, multi-platform earnings)

Long-term consolidation (fewer ledgers + shared entity tables, not duplicated databases)

Guiding principles

1) One “core record” per domain + bridges, not duplicates

2) Hybrid standard

Property Selects for numeric + transactional attributes (Amount, Cost, Tax, Fees, Paid, Dates, etc.)

Page Options databases for shared entities/taxonomies (Accounts, Categories, Subcategories, Platforms, Customers, Wishlist Items, etc.)

3) Checkbook sign convention

Money in = positive

Money out = negative

4) Refunds are NOT income

Refunds are cash-in, but tracked as Refund (not Income) so “earnings” stays clean.

5) Soft-retire before delete

Rename to 🟫 … (legacy) + hide from views + log in Legacy Removal List.

6) Preserve UX

Keep views and gallery/label behavior; change dependencies behind the scenes.

7) Visual marking rule

Canonical system DB/pages get the 🟫 brown-square icon.

Properties can’t have icons; we prefix system/changed properties with 🟫.

Alternative marker is allowed (example: [SYS]). If we ever change markers, we change it once and use it everywhere.

Important constraint (brown square on properties)

Notion properties don’t support icons per-property (only pages/databases have icons). So instead:

Prefix anything we add/edit with 🟫 (or suffix with (system)) until finalized

Soft-retire by renaming to 🟫 (legacy) and hiding from views

Canonical databases/pages get the 🟫 icon

FINANCE PLANNER: CURRENT SCOPE (brown-square system databases)

We standardize these first:

Income ( / Income)

Expenses ( / Expenses)

Categories (Categories / Categories)

Subcategories (Subcategories / Subcategories)

Rule: any additional DB we decide is part of the canonical system gets the 🟫 brown-square icon (so it’s easy to spot while “Final Planner” is being reorganized).

TRANSACTION SEMANTICS (canonical definitions)

4.1 Transaction Type (canonical)

🟢 Income

⭕️ Expense

🔁 Refund

💵 Debt

(Later if needed) 🔁 Transfer / Move Money

4.2 Canonical money fields

Amount = signed ledger impact (what actually hit money)

Expense purchase = negative

Income payout = positive

Refund = positive (cash back)

Cost = base price pre-tax/fees (typically positive)

Example: Cost = 29.99, Amount = -35.50 after taxes/fees.

4.3 Refund-aware budgeting measures

On each transaction row:

Spent (for budgets) = if Type=Expense → abs(Amount) else 0

Refunded = if Type=Refund → abs(Amount) else 0

Net Spend = Spent − Refunded

4.4 Category budget policy (Net vs Ignore)

Most categories use Net Spend (Spent − Refunded).

Special “discipline buckets” can use Ignore refunds (Gross spend only).

Implementation: Category has 🟫 Refund policy and the budgeting metric switches automatically.

Refund policy cheat sheet (how to choose)

Default: use Net Spend anywhere you want “how much of my budget did I really use after refunds?”

Use Net Spend (recommended default) for:

Shopping (Amazon, clothes, electronics)

Groceries

Dining/Restaurants

Travel

Subscriptions

Home goods / decor

Work expenses where returns/cancellations happen

Use Ignore refunds (Spent only) for special cases like:

Cash withdrawals

Fees / penalties (late fees, overdraft fees)

Discipline buckets (impulse/fun money categories you want to keep strict)

Debt payoff behavior buckets (sometimes; handled separately from normal budgeting)

How dashboards stay clean (what each view measures)

A) Spent this month (gross) → Total Spent (gross)

includes purchases

does not subtract refunds

B) Refunded this month → Total Refunded

C) Net spend this month → Net Spend (= Spent − Refunded)

D) Made this month (income only) → Income total filtered to Transaction Type = Income (refunds excluded)

E) Cash in this month (income + refunds) → Income + Refund (cashflow view; not earnings)

Simplest default policy

Budgets use Net Spend by default, and switch to gross Spent only when 🟫 Refund policy = Ignore refunds.

4.6 Finance Planner refund policy assignments (initial)

These are the recommended defaults for your current Finance planner Categories/Subcategories. (You can always override later; the point is to start consistent.)

Categories → Refund policy

Net Spend (default)

Bills

Business

Education

Education & Learning

Entertainment

Entertainment & Leisure

Family & Children

Food & Dining

Gifts

Health & Wellness (treat duplicates the same)

Hobbies

Home

Hosting

Housing

Insurance

Interest (usually Net Spend; refunds are rare)

Miscellaneous

Miscellaneous / Others

Mortgage

Pet Care

Restaurants

Self Care

Shopping

Sports

Transportation (treat duplicates the same)

Travel & Leisure

Utilities

Ignore refunds (special-case / non-budget bucket)

Cash (often behaves like withdrawals/transfers; may later be redesigned as Transfers)

Income-side / special domains (not normal spend budgeting buckets)

Salary (Income reporting; refunds don’t apply)

Bonus (Income reporting; refunds don’t apply)

Savings & Investments (supports BOTH: outflow budgeting + goal tracking)

Debt (separate debt measures; do not mix with refund logic)

Subcategories → Refund policy

Apparel

Beauty Products

Books & Supplies

Broadband

Car Insurance

Car Loan

Car Maintenance

Car Payment

Childcare

Dining Out

Electricity

Facials

Fine Dining

Fitness & Gym

Fuel

Gas

Holidays & Travels

Home Insurance

House Maintenance

Mani Pedi

Medical Expenses

Movies/Theater

Online Courses

Outdoor Activities

Parking

Phone

Property Taxes

Public Transport

Rent

Rent/Mortgage

Salon Visits

Schooling

Tuition Fees

Water

Workshop & Seminars

Allowance & Gifts

Ignore refunds (special-case; debt bookkeeping buckets)

Initial Debt

First Payment

Student Loan

Note: Interest (subcategory)

Interest → Net Spend is fine (refunds are rare), but can be treated as a discipline bucket if you ever want it strict.

4.7 Reusable rule for other planners/databases

When we refactor another planner (Wishlist, Notes, CRM, etc.), we repeat the same classification step:

1) True budget spending bucket (Shopping, Groceries, Subscriptions, etc.) → default to Net Spend

2) Discipline bucket (impulse/fun money, penalties/fees, cash withdrawals) → Ignore refunds

3) Not a spending bucket (Income categories, Transfers, Debt principal/balance tracking) → do not use budget spend logic; use domain-specific reporting measures.

SAVINGS & INVESTMENTS (must support BOTH modes)

Outflow budgeting (contributions as “set aside” spend/outflow)

Goal tracking (target, progress, remaining)

5) Month breakdown requirement (locked)

Month logic must support BOTH:

“Current month” filters/views

Historical attribution (when it’s no longer current month, it still shows the original month)

6) Execution plan (Finance)

Phase 1 — Inventory & dependency map (non-destructive)

For Income/Expenses/Categories/Subcategories, inventory:

property dictionary (meaning + duplicates)

dependencies (formulas, rollups, view filters/sorts/grouping, charts, buttons)

Phase 2 — Standardize taxonomy

Ensure Transaction Type includes Refund everywhere needed.

Phase 3 — Add refund-aware measures + policy wiring

Add Spent/Refunded/Net Spend on ledger

Add Category policy + system rollups/formulas

Phase 4 — Cost/Amount cleanup (keep both)

Amount = actual paid/received (signed)

Cost = base price pre-tax

Migrate any Cost-filled rows missing Amount (if found)

Phase 5 — Month breakdown fixes

Fix month formulas/views so month history is correct.

Phase 6 — Soft-retire duplicates

Rename to 🟫 … (legacy) + hide + log.

Phase 7 — Verification pass

Validate dashboards/charts/boards + key rollups.

7) What we completed (this run)

The following are already implemented and should be treated as done:

Expenses

Added 🔁 Refund to Transaction Type

Added transaction measures:

Spent (for budgets)

Refunded

Net Spend

Added 4 monthly operational views:

🟫 Gross spent (this month)

🟫 Refunded (this month)

🟫 Net spend (this month)

🟫 Income only (this month)

Aligned Transaction Type to include 🔁 Refund (kept for future unified Transactions compatibility)

Categories

Added 🟫 Refund policy

Added rollups:

🟫 Total Spent (gross)

🟫 Total Refunded

Added formulas:

🟫 Budget Usage

🟫 Remaining (system)

🟫 Budget Progress (system)

Updated core Category views to show system fields

Cost-filled placeholder rows

Classified the 5 rows with Cost filled:

set Transaction Type = ⭕️ Expense

set Amount negative

kept Cost positive

marked rows with 🟫 icon for visibility

Governance pages

Created Finance System Spec

Created Legacy Removal List

Created/used Verification Checklist

8) Running checklist (single source of truth)

1) [x] Canonical glossary documented (System Spec)

2) [x] Transaction Type standardized to include Refund (Income + Expenses)

3) [x] Refund-aware transaction measures added (Expenses)

4) [x] Monthly operational views created (Expenses)

5) [x] Category refund policy + system budget formulas/rollups added

6) [ ] Savings & Investments dual-mode: confirm + implement final wiring (outflow budgeting + goal tracking)

7) [ ] Month breakdown fixes: repair month formulas + ensure historical attribution everywhere

8) [ ] Soft-retire duplicates (rename 🟫 … (legacy), hide, log) across remaining Finance DBs

9) [ ] Verification pass: dashboards/charts/boards (final)

10) [ ] (Later milestone) Unified Transactions ledger for platform ingestion

9) Progress reporting rule (must follow)

After each batch of work:

1) Confirm what changed (brief)

2) Update this page’s checklist (check off items)

3) Log every legacy item in Untitled

10) Platform milestone (later)

After Finance stabilizes:

Create a canonical Transactions database for platform ingestion (Income + Expenses + other earnings)

G Sections — Full Detail

G. Step 2 exact duplicate merge-audit findings

Status: AI comparison in progress. No deletion/archive approved.

This section is for the exact-duplicate pass only. These findings are meant to reduce Jillian's manual review list before the broader “similar but not identical” merge rules are applied.

G1. Exact duplicate linked views found from Views Inventory

Across 🟫 Master — Views Inventory, the exact same linked-view name + captured settings appeared only for the Meal Planner Items database:Underlying databaseDuplicate linked viewsInventory rowsFindingRecommended actionItemsMeal Planner — Items All Items

Meal Planner — Items To BuyMeal Planner — Items All Items / Meal Planner — Items All Items

Meal Planner — Items To Buy / Meal Planner — Items To BuyExact duplicate view names and exact captured settings. Same subject page and same location page.Safe duplicate-review candidates. Keep one row/view record for each view after approval; do not remove anything yet.

Notes:

Same-name University view rows were not exact duplicates because their captured filter/sort/group settings differed.

Other high-row-count databases mostly have many distinct views, not exact duplicate view names.

G2. Weekly Planner duplicate database cluster — strong exact-duplicate candidates

Compared the main Weekly Planner copy with Duplicate 1–5 for Daily Tasks, Monday–Sunday meal planner databases, Grocery’s, and Recipe Book. Schemas, view setups, row counts, visible row values, and checked sample page contents match at the tool-visible level.Database typeKeeper candidateDuplicate candidatesTool-visible comparisonRecommended actionDaily Tasks

Same schema: Status, Category, Name, Checked. Same board view. Same 3 placeholder rows. Sample pages had no page content.Keep main Weekly Planner copy unless Jillian prefers a duplicate page layout. Duplicate databases can be final archive/delete candidates only after approval.Monday meal planner

Same schema, same table view, same one placeholder meal row, sample page content empty.Duplicate database candidates after approval.Tuesday meal planner

Same schema, same table view, same one placeholder meal row.Duplicate database candidates after approval.Wednesday meal planner

Same schema, same list view, same four placeholder rows, sample page content empty.Duplicate database candidates after approval.Recipe Book

Same schema, same seven gallery views, same nine placeholder rows. Sample recipe pages have matching text/content structure and each has an image/file block. File IDs differ, so final visual image-choice approval is still needed if Jillian cares which placeholder image survives.Keep main Weekly Planner Recipe Book unless Jillian prefers a different image/layout. Duplicate databases can be final archive/delete candidates only after approval.

G3. Notes databases are not exact duplicates

Compared the visible Notes-style databases:

— richer schema with status, favorite, date formula, project/area relations, six gallery views, and a note template; currently zero rows.

— simple cover + name gallery database with three prompt rows.

— tags/date/url/checkbox database with four real/sample rows.

— university notes/reference database with course tags, type, status, and three rows.

Recommendation: Do not delete any Notes database as an exact duplicate. Treat these as a later similar merge cluster where useful rows/properties/templates should be consolidated into a canonical Notes keeper.

G4. Tasks / requests setup finding

Loaded the main task/request databases:

✨Personal Tasks Database

Finding:

Business Tasks already connect to useful work context such as Inventory, People, Client, Booking, Deliverable, Order, Expense, Schedule Blocks, and Routine / Checklist Template.

Personal Tasks already connect to personal project, hobby, finance, goal, schedule blocks, routine/checklist template, and deliverable context.

Customer Requests and Master Requests Queue already contain request/inventory/physical-item context such as inventory items, outfit items, accessory items, toy items, supply items, quote links, and completed orders.

However, I did not see a direct Tasks ↔ Customer Requests / Master Requests Queue relation or rollups that would surface request needs directly on a task.

Executed setup on canonical business Tasks:

Added a Tasks ↔ Customer Requests relation:

Tasks property: Customer Requests

Customer Requests property: Related Tasks

Added Customer Request rollups on Tasks for:

Request Inventory Items

Request Purchase Items Worn

Request Shoot Status

Request Pay Status

Request Shoot Date

Request Order Date

Request User URL

Request Description

Request Notes

Added the Tasks view “Request-linked tasks.”

Added a Tasks ↔ Master Requests Queue relation:

Tasks property: Master Requests Queue

Master Requests Queue property: Related Tasks

Added Master Request rollups on Tasks for:

Master Request Outfit Items

Master Request Accessory Items

Master Request Toy Items

Master Request Supply Items

Master Request Purchase Items Worn

Master Request Status

Master Request Customer Profile

Master Request Description

Master Request Completed Time

Added the Tasks view “Master request-linked tasks.”

Remaining decision:

Personal Tasks were not changed yet. Keep business Tasks as the canonical request-work task database unless Jillian wants Personal Tasks to also drive customer-request work.

G5. Systems → Master Subject Sections setup

Status: Setup and first mirror pass completed. No Systems rows/pages were moved, archived, or deleted.

Completed setup:

Added a two-way relation between 🟫 Master — Subject Sections and :

Master Subject Sections property: Systems rows

systems property: Master subject sections

Added System mirror fields to Master Subject Sections:

System home page

System canonical planner

System original planner

System item kind

System migration status

Created Master Subject Sections rows from Systems where the Systems row represented a subject/page/planner structure:

Finance dashboard — LIFE PLANNER

Finance databases — LIFE PLANNER

Finance Tracker

Transactions — Finance dashboard

Transactions — Master Dashboard

Money — Personal Planner

Bookings & Scheduling — Systems overview

Business Planner — Systems overview

Creative & Production — Systems overview

Dashboards & Analytics — Systems overview

Documents & Media — Systems overview

People & Contacts — Systems overview

Products & Inventory — Systems overview

Projects & Tasks — Systems overview

Services & Content — Systems overview

System Config — Systems overview

Important classification rule:

Systems rows with Item Kind = Database, Taxonomy/Config, or Dashboard/Analytics generally stay in the database/view inventory and cleanup-review flow instead of becoming regular subject sections, unless they are actual planner/dashboard pages that need section representation.

The old Systems rows are now mapped/mirrored, not removed. They can only become cleanup candidates after Jillian approves exact actions.

G6. Step 2 keeper/not-keeper marking completed

Status: Definite exact-duplicate cleanup executed after Jillian confirmed.

Completed marking:

Weekly Planner duplicate database cluster:

10 main Weekly Planner database inventory rows marked Keeper.

50 Duplicate 1–5 database inventory rows were deleted after confirmation, along with their duplicate underlying databases and duplicate Views Inventory rows.

Exact duplicate Meal Planner Items linked-view records:

Meal Planner — Items All Items duplicate pair reviewed; duplicate record removed after confirmation.

Meal Planner — Items To Buy duplicate pair reviewed; duplicate record removed after confirmation.

Same-underlying inventory-row duplicate groups:

Affiliate Statuses

Connected Account Statuses

Personal File Extensions

Personal Formats

Personal Finance

Personal Habits

Referral Statuses

Habit Tracker

Recipe Book — Recipes Ready To Archive

These were inventory-row cleanup candidates only. Duplicate inventory rows were removed after confirmation; the underlying databases stayed active and related Views Inventory rows were relinked to keeper inventory rows where needed.

G7. Post-delete linked-view / inventory cleanup verification

Status: Completed after deletion cleanup.

Verified cleanup results:

Remaining Not keeper rows in Master Databases Inventory: 0

Remaining Weekly Planner duplicate Views Inventory rows: 0

Remaining exact duplicate linked-view groups in Views Inventory: 0

Remaining repeated underlying database links in Master Databases Inventory: 0

Remaining stale Views Inventory references to deleted duplicate inventory rows: 0

Additional cleanup performed:

Relinked active Views Inventory rows from deleted duplicate inventory rows to their keeper Master Databases Inventory rows for:

No active underlying database was removed for same-underlying inventory-row cleanup; only duplicate inventory rows were removed.

The only underlying databases removed in this confirmed cleanup were the exact duplicate Weekly Planner Duplicate 1–5 databases.

G8. Workspace-wide duplicate cleanup — email template/categories and Shot List

Status: Executed under the confirmed duplicate/superset cleanup rule, with keeper fields preserved before deletion.

Email Templates:

Kept ✨Email Templates as the keeper because it already had the richer template-writing structure: Body, Tags, Tags (Rel), Category (Rel), Active, and Subject.

Added the useful fields from the duplicate Documents & Media Email Templates database into the keeper: Last Used and Open Rate.

Deleted the empty duplicate Documents & Media Email Templates database and its duplicate inventory/view rows after the keeper had the union of useful fields.

Email Template Categories:

Kept ✨Email Template Categories as the keeper because the surviving Email Templates keeper already points to it.

Deleted the duplicate empty category database and its duplicate inventory/view rows.

Shot List:

Kept Shot List as the keeper because it had the richer creative schema and the real populated shot row.

Preserved the useful Bookings-specific relation target by adding Booking Location (Rel) to the keeper before deletion.

Deleted the blank duplicate Bookings Shot List database and its duplicate inventory/view rows.

Verification after this pass:

Normalized duplicate database-name groups in Master Databases Inventory: 0

Exact duplicate linked-view groups in Views Inventory: 0

Stale Views Inventory references to the deleted email/shot-list duplicate inventory rows: 0

G9. Workspace-wide page/bookmark duplicate sweep — first exact-empty batch

Status: Partially executed for exact empty bookmark rows only; broader page sweep still in progress.

Deleted exact duplicate empty bookmark rows where title, visible URL label, group/kind, parent database, and page content matched:

Convert Newline to Comma in Text — kept one row and removed two exact empty duplicates.

Remove Duplicate Words from Text — kept one row and removed two exact empty duplicates.

Remove Words from Text — kept one row and removed six exact empty duplicates.

Left in review, not deleted:

FlexSeries Head Shaving Kit, Start Page, and WONDER BLADING Lip Stain Masque rows have matching labels but different underlying tracking URLs/ad parameters, so they are not exact duplicates under the current rules.

Exact Duplicates — Full Verified Delete List

Exact Duplicates — Verified Delete List

Verified delete list (exact duplicates)

Rules: each bullet is Delete → Keep.

Projects Database (Projects Database)

• Delete: Master Todo → Keep: Master Todo (Master Todo)

• Delete: Meaning of life; reason to live → Keep: Meaning of life; reason to live (Meaning of life; reason to live)

• Delete: Intuitive → Keep: Intuitive (Intuitive)

• Delete: internet → Keep: internet (internet)

• Delete: Ideas for apple → Keep: Ideas for apple (Ideas for apple)

• Delete: Ibuprofen for pain 2 hours Morin → Keep: Ibuprofen for pain 2 hours Morin (Ibuprofen for pain 2 hours Morin)

• Delete: Lion loves lion the lion → Keep: Lion loves lion the lion (Lion loves lion the lion (3/28/23, 2:28 PM))

• Delete: movies → Keep: movies (movies)

• Delete: Hi I'm back in town I can do this or next Saturday! → Keep: Hi I'm back in town I can do this or next Saturday! (Hi I'm back in town I can do this or next Saturday! (1/20/23, 5:05 AM))

• Delete: Hide all picture and videos and show all picture sand videos button on my social media app → Keep: Hide all picture and videos and show all picture sand videos button on my social media app (Hide all picture and videos and show all picture sand videos button on my social media app (12/14/22, 2:35 AM))

• Delete: How to understand selling supplies and stock up on stock and the difference between livestock that it is live stock aka stock that is a live like is but unlike us as humans we eat them.. There are actual ingredients to be able to buy to eat but also the ingredients for your business aka ingredients for success → Keep: How to understand selling supplies and stock up on stock and the difference between livestock that it is live stock aka stock that is a live like is but unlike us as humans we eat them.. There are actual ingredients to be able to buy to eat but also the ingredients for your business aka ingredients for success (How to understand selling supplies… (7/27/23, 9:49 PM; Livestock; How to profit))

• Delete: I am P.A.M personal automated multitasker or multitasking machine P.A.M.M hey Pam like hey siri Alexa Google etc → Keep: I am P.A.M personal automated multitasker or multitasking machine P.A.M.M hey Pam like hey siri Alexa Google etc (I am P.A.M… (8/16/23, 9:55 AM))

• Delete: I don’t like peppers but I’ll keep you cumin → Keep: I don’t like peppers but I’ll keep you cumin (I don’t like peppers…)

• Delete: I don’t remember my grandparents not being Sweet caring gentle and kind → Keep: I don’t remember my grandparents not being Sweet caring gentle and kind (I don’t remember my grandparents…)

Not safe / blocked (do not delete in exact pass)

• Business ideas JSAVONE —- Jillian &Savana as one vs Business ideas JSAVONE —- Jillian &Savana as one — different embedded child page URLs.

• Domain names / Domain names — contains bookmark/unsupported block; blocked.

• Don't won't can't DWC by JJ / Don't won't can't DWC by JJ — different image file URLs.

• add to tasks cluster — not identical across all rows (different content and/or tag values).

🗑️ Exact Duplicate Pages Queue

• 🗑️ Exact Duplicate Pages QueueItemVerified exact duplicateDeletedBatch #Source (Data Source URL)Duplicate group keyDelete pageKeep pageNotesDiff scenarioEntity typeSource inventory rowIbuprofen for pain 2 hours Morin (exact)Projects DatabaseIbuprofen for pain 2 hours Morinhttps://app.notion.com/p/196b864118fc81f7939bc0a7f4f861efhttps://app.notion.com/p/196b864118fc815cabffe99ef3da9cfaExact matchI want them to have everything in life… (exact)Projects DatabaseI want them to have everything in life…https://app.notion.com/p/196b864118fc81cc8f49e5f63bef24a3https://app.notion.com/p/196b864118fc816894d9e762a83e572eExact matchI’ll be back on set… (exact)Projects DatabaseI’ll be back on set… (2023-01-14)https://app.notion.com/p/196b864118fc81879457e42fdb6033a9https://app.notion.com/p/196b864118fc81188f15d7e3183d16c1Both empty; properties matchIf you do too much to your body… (exact)Projects DatabaseIf you do too much to your body… (2023-07-19)https://app.notion.com/p/196b864118fc81a8b41fc18180276f2dhttps://app.notion.com/p/196b864118fc81358eacddf36746bac2Both empty; properties matchIt's time to Jill… (exact)Projects DatabaseIt's time to Jill… (2023-07-10)https://app.notion.com/p/196b864118fc819ba061c4c2bbef535chttps://app.notion.com/p/196b864118fc81218c73dd09cf90f29fBoth empty; properties matchIdeas for apple (exact)Projects DatabaseIdeas for applehttps://app.notion.com/p/196b864118fc819eb70fde627c237916https://app.notion.com/p/196b864118fc81098337d33bffbf1a10Exact matchLyrics — pair A (review)Projects DatabaseLyrics (boy/angles verse)https://app.notion.com/p/196b864118fc81a3a2d2cddd32774030https://app.notion.com/p/196b864118fc8128ab38c38469985ed2Content matches exactly, but properties differ (ADD/ADD). Needs rule decision: treat as exact or require property identity.LOCKED FOLDER STORAGE SETTINGS (exact)Projects DatabaseLOCKED FOLDER STORAGE SETTINGShttps://app.notion.com/p/196b864118fc81c88a16c4cb27e1eaafhttps://app.notion.com/p/196b864118fc81218991e134eec5e132Exact content + properties matchinternet (exact)Projects Databaseinternethttps://app.notion.com/p/196b864118fc812cac53f79f65e688bbhttps://app.notion.com/p/196b864118fc8113b441eda0ac2ac094Exact matchI want you to paint me… (exact)Projects DatabaseI want you to paint me…https://app.notion.com/p/196b864118fc81ff9b21d1a3a4b26f7chttps://app.notion.com/p/196b864118fc815caaa8f414502d3447Both empty; properties matchAudit Queue duplicate row: 💫FINAL PLANNER—————————Audit QueueAudit Queue: 💫FINAL PLANNER—————————https://app.notion.com/p/e4c16e7f5b614367acdaa5ffea8e55b5https://app.notion.com/p/145b864118fc808a8fe9fa20923dbc32Duplicate Audit Queue tracker row (same Item/Type/Area); keep one tracker row, delete the duplicate tracker row.Exact matchAudit Queue rowhttps://app.notion.com/p/e4c16e7f5b614367acdaa5ffea8e55b5LurchBranch productions… (exact)Projects DatabaseLurchBranch productions… (2023-01-29)https://app.notion.com/p/196b864118fc815ca25bd9a54dc6b761https://app.notion.com/p/196b864118fc811bb3bae929b7c8cc4aBoth empty; properties matchNew Project cluster (not exact)Projects DatabaseNew ProjectNot exact: different Status/Areas and each contains different embedded database block URLs; requires separate merge/superset review, not exact delete.If you have a goal or a dream… (exact)Projects DatabaseIf you have a goal or a dream…https://app.notion.com/p/196b864118fc8135b445ff6b828734dfhttps://app.notion.com/p/196b864118fc81158505ffef736e245f only; exact matchMeaning of life; reason to live (exact)Projects DatabaseMeaning of life; reason to livehttps://app.notion.com/p/196b864118fc81b2bf33c9d81a1f459ahttps://app.notion.com/p/196b864118fc8101a9e1f6bf53da93b2Both empty; properties matchI'm not getting the shit I need done… (exact)Projects DatabaseI'm not getting the shit I need done… (2022-12-10)https://app.notion.com/p/196b864118fc8194bd9bc6e481169e18https://app.notion.com/p/196b864118fc814d9380d45d300ca16aBoth empty; properties matchLASIK My eyesight is shit… (exact)Projects DatabaseLASIK My eyesight is shit…https://app.notion.com/p/196b864118fc81bcaa42c8f060a16b09https://app.notion.com/p/196b864118fc8176b4f1f2fb4432bd5bBoth empty; properties matchLife is about the gods you believe in… (exact)Projects DatabaseLife is about the gods… (2022-12-09)https://app.notion.com/p/196b864118fc81ffab3af0953fe47ca7https://app.notion.com/p/196b864118fc81c5b319c13655374093Both empty; properties matchLyrics He is so sexy… (review)Projects DatabaseLyrics He is so sexy… (2022-12-14)https://app.notion.com/p/196b864118fc81ca9ae9ebfecf5366f9https://app.notion.com/p/196b864118fc816d8902fa00d3a56b4dBoth empty, but properties differ (ADD vs ADD). Needs rule decision.I don’t like peppers but I’ll keep you cumin (exact)Projects DatabaseI don’t like peppers but I’ll keep you cuminhttps://app.notion.com/p/196b864118fc81b8926bc15286520ae2https://app.notion.com/p/196b864118fc81aca1dfc370a40b0cceBoth empty; exact matchI’m hand sanitizer positive… (exact)Projects DatabaseI’m hand sanitizer positive… (2023-03-30)https://app.notion.com/p/196b864118fc81a1be6cd3722240c3dbhttps://app.notion.com/p/196b864118fc8139a4cbf69669a4053eBoth empty; properties matchHi I'm back in town… (exact)Projects DatabaseHi I'm back in town… (2023-01-20)https://app.notion.com/p/196b864118fc81b3bc01e5b7c1c59d4dhttps://app.notion.com/p/196b864118fc811b8ad0eb6b5d3ccdbbBoth empty; exact matchI am P.A.M… (exact)Projects DatabaseI am P.A.M… (2023-08-16)https://app.notion.com/p/196b864118fc8153b701f9ac3855bfcchttps://app.notion.com/p/196b864118fc813cac04c152f01f9505Both empty; exact matchI’m trying to let shit go… (exact)Projects DatabaseI’m trying to let shit go…https://app.notion.com/p/196b864118fc81c9aa3ac47c286738ddhttps://app.notion.com/p/196b864118fc81a087dfe12b4b0773c3Exact matchHide all picture and videos… (exact)Projects DatabaseHide all picture and videos… (2022-12-14)https://app.notion.com/p/196b864118fc81e89276c3713492950bhttps://app.notion.com/p/196b864118fc8115b593f2e03e6b5e88Both empty; exact matchI’m not telling you how to feel… (exact)Projects DatabaseI’m not telling you how to feel…https://app.notion.com/p/196b864118fc8185aab7d5e4761ecd2dhttps://app.notion.com/p/196b864118fc81849cf7f2940d6326feBoth empty; properties matchLyrics — subpages collection (blocked)Projects DatabaseLyrics (subpages mega-list)https://app.notion.com/p/196b864118fc81a591e7caa6cf107b1ahttps://app.notion.com/p/196b864118fc81378040efa5df78dddfNot exact duplicates: different embedded child page URLs throughout; do not delete in exact pass.I rocked the boat… (exact)Projects DatabaseI rocked the boat… (2023-03-31)https://app.notion.com/p/196b864118fc816c803fd6e536354b79https://app.notion.com/p/196b864118fc812c9c30c30f307553a0 only; exact matchIntuitive (exact)Projects DatabaseIntuitivehttps://app.notion.com/p/196b864118fc815b91d0c5d46ddb5a11https://app.notion.com/p/196b864118fc813b8739c7c2f7a8b098Exact matchmovies (exact)Projects Databasemovieshttps://app.notion.com/p/196b864118fc81ca9f5ec51fd62293d0https://app.notion.com/p/196b864118fc81088392de058596c103Exact matchI don’t feel like I’m missing out… (exact)Projects DatabaseI don’t feel like I’m missing out…https://app.notion.com/p/196b864118fc81e0bf4fdd6949c90569https://app.notion.com/p/196b864118fc81b7a41cfcad7486fdd8Both empty; properties matchLyrics Say what you feel… (review)Projects DatabaseLyrics Say what you feel…https://app.notion.com/p/196b864118fc81a9bd11c571fb83f897https://app.notion.com/p/196b864118fc819ba9dbfbb6a9e3b8ac only; but properties differ (ADD vs ADD). Needs rule decision.Master Todo (exact)Projects DatabaseMaster Todohttps://app.notion.com/p/196b864118fc81d484fadd3e41a22a0fhttps://app.notion.com/p/196b864118fc8144b37dfa7827dce405Verified identical properties + contentInventions Memory buddy selfie… (exact)Projects DatabaseInventions Memory buddy selfie… (2023-04-30)https://app.notion.com/p/196b864118fc814ca9fcd0ea3b8799d3https://app.notion.com/p/196b864118fc8104a12be3cf4329249c only; exact matchModern retro girl… (exact)Projects DatabaseModern retro girl… (2023-03-31)https://app.notion.com/p/196b864118fc81d2a658dfb9a8255f50https://app.notion.com/p/196b864118fc81bb8607fa52ea123d21Both empty; properties matchI’m doing nothing while doing something (exact)Projects DatabaseI’m doing nothing while doing somethinghttps://app.notion.com/p/196b864118fc81aeaa8ef17a01fde226https://app.notion.com/p/196b864118fc817db52bc58f7dc18279Both empty; properties matchLyrics — pair B (review)Projects DatabaseLyrics (If I lose you… Cher song…)https://app.notion.com/p/196b864118fc81899b40d3b53ebb0c49https://app.notion.com/p/196b864118fc812dbf4def9f8307d915Content matches exactly, but properties differ (ADD/ADD). Needs rule decision.I don’t remember my grandparents… (exact)Projects DatabaseI don’t remember my grandparents not being Sweet caring gentle and kindhttps://app.notion.com/p/196b864118fc81b0add3c960b730cddahttps://app.notion.com/p/196b864118fc8128a99bcd1ace9396d8 only; exact matchI’m not a psychic… (exact)Projects DatabaseI’m not a psychic… (2022-12-17)https://app.notion.com/p/196b864118fc81a4b536e1f0b85c330fhttps://app.notion.com/p/196b864118fc819c9b70d5c2ed4b0c0bBoth empty; properties matchI say “it’s beautiful”… (exact)Projects DatabaseI say it’s beautiful…https://app.notion.com/p/196b864118fc81c09daec6037abb8ee3https://app.notion.com/p/196b864118fc819c8790f2291ddc2c06Exact matchI feel like my best life is passing me by… (exact)Projects DatabaseI feel like my best life is passing me by… (2023-02-27)https://app.notion.com/p/196b864118fc81c5b839cf4fb33eab55https://app.notion.com/p/196b864118fc8113afcdd374c04547aaBoth empty; properties matchJillianaires (exact)Projects DatabaseJillianaireshttps://app.notion.com/p/196b864118fc8182a78dde0c4f5410bbhttps://app.notion.com/p/196b864118fc8118afe5dcec940c895eBoth empty; properties matchIt's hard to remember something… (exact)Projects DatabaseIt's hard to remember something… (2022-12-13)https://app.notion.com/p/196b864118fc81d2a199de26d5f5b4a1https://app.notion.com/p/196b864118fc81698e10cb8ded3fe7d2 only; exact matchLion loves lion the lion… (exact)Projects DatabaseLion loves lion the lion (2023-03-28)https://app.notion.com/p/196b864118fc81f8bb02f86f94567ca7https://app.notion.com/p/196b864118fc818baf0ecbf27fb9bca7Both empty; exact matchHow to understand selling supplies… (exact)Projects DatabaseHow to understand selling supplies… (Livestock / How to profit)https://app.notion.com/p/196b864118fc81b7ba24f4ece95199c3https://app.notion.com/p/196b864118fc817a83b6fe47bce1d33eBoth empty; exact match

Taxonomy & Config Databases🧩

This page indexes “Taxonomy / Config” databases (pages-as-options, types, categories, statuses) that operational systems reference.

These are not operational mirrors themselves; they define controlled vocabularies.

Scheduling taxonomy

— Event Types (used by Unified Schedule)

Business planner taxonomy

Documents & media taxonomy

Commerce taxonomy

Products & inventory taxonomy

Dashboards & analytics taxonomy

Services & content taxonomy

✨Promo Code Types

✨Recurring Transaction Types

✨Recurring Transaction Categories

✨Recurring Transaction Frequencies

✨Expense Categories

✨Expense Types

✨Expense Months

✨Expense Tags

✨Expense Expense Types

People & contacts taxonomy

System config taxonomy

Next in audit

Booking Types

Bookings & scheduling taxonomy

Projects & tasks taxonomy

(legacy — superseded by ✨Statuses Database)

Service Types

Appearance Types

Milestone Types

Deliverable Types

(As I audit each structural page, I’ll add the relevant taxonomy DBs here.)

Genspark Reconnect Map (Backend Changes)🧭

This page is the running source of truth for what changed on your Notion backend so Genspark can reconnect without anything being “lost” — only moved/renapped/merged.

Operating rules (how we make changes)

Global hubs only (no duplicates): If two properties represent the same underlying concept, they should point to one canonical taxonomy hub so you can aggregate cross-system (e.g., one global Platforms, Cities, States, Countries).

Do consolidate when the meaning is truly shared.

Do NOT consolidate just because labels match. If two properties share a name but represent different concepts/lifecycle flows (e.g., “Status” for Customer Requests vs “Status” for Inventory), keep them as separate taxonomy hubs (and name them clearly).

Normalize on touch: When we open a database, we do all cleanup for that database in the same pass:

convert select/multi-select/text “options” into (Rel) relation properties to the appropriate taxonomy hub

keep legacy properties (rename to (Legacy Text/Select/Title)) until the frontend reconnect is stable

update the view columns (displayProperties) so views don’t break after renames

Ready-to-archive consolidation rule (critical):

Only remove a “(ready to archive)” database if a keeper database exists for the same concept.

Before deletion: migrate any unique rows/page-options from the archive DB into the keeper DB.

Do NOT delete the archive DB if it contains anything unique that is not yet present in the keeper.

After migration, delete requires explicit confirmation.

Address normalization standard: Operational databases should point to ✨Addresses Database (Address (Rel), limit 1). City/State/Country/ZIP should not be free text/select long-term.

Closet lifecycle standard (new): Physical items should be trackable end-to-end via ❤️Closet (Owned Items Lifecycle) so you can see the full history from acquisition → in-closet → packed/listed → sold/donated/archived. Products/Services/Sales/Purchases/Inventory should link to Closet where applicable.

Permission blocks: If a legacy database/data source is blocked by permissions, log it here as “Needs access / blocked by permissions” and do not attempt destructive changes.

Brown-square keeper marker (standing rule):

Any page/database we confirm as a keeper should be marked with a brown square icon (or, if icon changes aren’t possible for that object, prefix the title with a brown-square marker).

When choosing between duplicates, prefer keeping the one with real data (even example data) and/or richer content (cover photos, images inside the page) and/or an existing meaningful icon; archive/delete the emptier duplicate.

Temporary convention: keepers use the brown-square marker until the master plan is complete; later, we will do a dedicated pass to replace brown squares with final, meaningful icons.

Deletions are staged (separate checklist; delete at the end):

Default rule: do not delete legacy properties/pages/databases as we go (even if it’s tempting).

Instead, add them to a dedicated “Deletion Queue (end-of-project)” checklist on this page.

Exception: safe immediate deletions are allowed only when (a) the item is a confirmed duplicate, (b) the keeper exists, (c) the duplicate is verified empty (0 rows) or fully migrated, and (d) you explicitly confirm.

Legacy fields stay until migration is verified (example: Customer Requests Tags):

For operational DBs like ❤️Customer Requests, legacy fields (select/multi-select/text) must remain until you confirm all values/options were migrated into the canonical relation-backed fields.

Only then do we move the legacy fields into the Deletion Queue.

Duplicate DB merge rule (keeper-first + move rows/options + only then delete):

When merging duplicate databases, we only remove duplicate properties if they are exact duplicates and proven safe.

If the database being removed has rows/pages, we migrate unique rows/options into the keeper first.

If property/formula/relation parity is missing in the keeper, we add/setup the missing properties first (since properties don’t transfer cleanly), then migrate row data (temporary text field allowed), then retire the temporary field.

Workspace-wide consolidation workflow (manual-first compatibility):

Goal: determine which pages/DBs become the FINAL PLANNER backbone by grouping same-named/similar pages/DBs together for comparison (properties, rows, views, layouts).

Choose the keeper based on: richest schema + best layout + most data/media.

Preserve favorite layouts while consolidating:

Instead of moving a database block away from a page you like, keep the page as a layout page and replace its embedded database block with a linked view of the keeper database.

This preserves the visual layout while ensuring all data lives in the single canonical DB.

Master execution plan (numbered tasks + checklists)

This section is the single checklist view of everything discussed across:

Convo 1–3 chat pages (parts/subparts)

The platform document package, including the full Connection Blueprint + property maps

1) Connection Blueprint governance (platform ↔ Notion contract)

Add + maintain authoritative links (Blueprint/Routes/DB Schema/Ops/Changelog). (Source: Genspark doc package)

Add + maintain Connection Blueprint + Forms Index links. (Source: Genspark Connection Blueprint prompt + links)

Operating rule: any DB/property rename/merge must be reflected both here and in Connection Blueprint Part 2 property maps. (Source: Convo 3 Part 4 + your audit/gap rules)

Compare Connection Blueprint “Notion Database Property Maps” (all DB IDs + required properties) against current canonical Notion DBs and log any mismatches (DB replaced/renamed/merged, property renamed, missing DB). (Source: Genspark Connection Blueprint Part 2)

2) Frontend ↔ backend audit (gap logic + reconnect strategy)

Record the “gap logic” rules (feature missing vs disconnected vs broken by re-org). (Source: Convo 3 Part 4A + your follow-up message)

Build a “Reconnect Delta List” (per platform feature/route/form): old Notion DB → new canonical Notion DB (or “create missing DB”) + required property mapping notes. (Source: Connection Blueprint Part 1–2)

3) Canonical global taxonomy hubs (singletons)

Platforms hub canonicalized + repointed key relations. (Source: Convo 2 Part 1C)

Geography hubs canonicalized (Cities/States/Countries) + indexed. (Source: Convo 2 Part 1C)

Addresses hub canonicalized + geo relations added; legacy text preserved. (Source: Convo 2 Part 1C)

Statuses hub canonicalized. (Source: Convo 2 Part 1B–1C)

Continue taxonomy consolidation sweep for any remaining taxonomy/config DB duplicates (types/categories/status-like) beyond the hubs already finalized. (Source: Convo 2 Part 1B–1D)

Convo 1 Part 3A–3G granular actions (taxonomy sweep across hubs)

Adopted structural-page-as-home + cross-cutting index pages model (structural hubs keep DB blocks; index pages are link catalogs only). (Source: Convo 1 Part 2E)

Created/maintained governance indexes: Operational Mirrors Index + Taxonomy & Config Databases + Dashboards & Reports Index + Protected Legacy DBs. (Source: Convo 1 Part 2E)

Implemented broad “no select/multi-select long-term” pattern: for each operational DB, create taxonomy DB + add X (Rel) replacement + keep legacy select/multi-select for migration safety. (Source: Convo 1 Part 2H + Convo 1 Part 3A–3F)

Executed multi-hub taxonomy conversion sweeps (Dashboards & Analytics, Services & Content, People & Contacts, System Config, Projects & Tasks, Creative & Production, Film History, Products & Inventory, Bookings & Scheduling, Finances) and kept Taxonomy & Config index updated with new taxonomy DBs. (Source: Convo 1 Part 3A–3E)

Convo 2 Part 1B–1F granular actions (global singleton consolidation sweep)

Consolidation rule (global vs domain-specific): consolidate only when concept is truly shared; do not merge “same label” taxonomies if they represent different lifecycles/dimensions (e.g., Customer Request Pay Status vs Shoot Status). (Source: Convo 2 Part 1B)

Statuses: standardized on canonical ✨Statuses Database (not per-hub status DBs). (Source: Convo 2 Part 1C + consolidation sweep)

Categories: repointed Personal Planner category relations to canonical ✨Categories Database (where semantically shared). (Source: Convo 2 Part 1C)

Geography singleton consolidation: States/Cities/Countries standardized to canonical hubs; hub-specific DBs converted into linked views where needed. (Source: Convo 2 Part 1C)

Platforms singleton consolidation: ensured hub-specific “platforms” taxonomies are linked views of canonical ✨Platforms Database; relations repointed accordingly. (Source: Convo 2 Part 1C)

4) Address normalization sweep (operational DBs)

Phase 1 completed for known high-impact DBs (Users, Vendors, Customer Requests, booking/location stack) with legacy fields preserved. (Source: Convo 2 Part 1C–1F)

Continue sweep: find every accessible DB with City/State/Country/Zip text/select OR non-canonical Address relation and normalize to Address (Rel) → ✨Addresses Database (preserve legacy fields). (Source: Convo 2 Part 1D–1F)

Convo 2 Part 1C–1F granular actions (address normalization + location naming)

Address hub standard applied: any DB with City/State/Country/Zip should point to ✨Addresses Database (and geo should live as relations on the Address). (Source: Convo 2 Part 1C–1E)

Implemented address normalization across key operational DBs (Contacts, Users, Vendors, Customer Requests, Booking Calendar/Availability, Locations, VIP Events, Shifts, Counter Offers, Companion Bookings, Video Call Sessions, Shot List, Film Schedule) with legacy fields preserved. (Source: Convo 2 Part 1C–1F)

Normalized blocked legacy address relations by renaming them to Address (Legacy Rel) while keeping/adding canonical address relations to ✨Addresses Database. (Source: Convo 2 Part 1F)

Location taxonomy split decision: treated “operational locations” vs “scene/travel locations” as different concepts; renamed for clarity instead of merging. (Source: Convo 2 Part 1F)

Blocked legacy address source follow-up: once access is granted to the blocked source, find every relation pointing to it and repoint to ✨Addresses Database, preserving legacy text fields as needed. *(Source: Needs access / blocked by permissions)

5) Customer Requests (Convo 1 scope)

Relation replacements added/confirmed: Pay Status (Rel), Shoot Status (Rel), Tags (Rel). (Source: Convo 1 Part 1D + DB schema check)

Scene/request metadata relations confirmed: Interaction Styles, Scene Elements, Content Type, etc. (Source: Convo 1 Part 1 + DB schema check)

Address (Rel) added; legacy address preserved. (Source: Convo 2 Part 1C + DB schema check)

Inventory items relation added (request ↔ exact owned items). (Source: Reconnect Map “Recent changes”)

Post-migration cleanup (later): migrate legacy field usage fully → (Rel) fields, then retire legacy properties only after frontend reconnect is stable. (Source: Operating rules)

Convo 1 granular actions (term buckets + schema cleanup)

Confirmed end-state goal: reduce redundant “term” fields and normalize every option into one canonical relation-backed taxonomy DB. (Source: Convo 1 Part 1A)

Defined customer email/summary sentence-builder rules (join lists with commas + “and”) and example templates for platform notifications. (Source: Convo 1 Part 1A)

Decided/confirmed taxonomy bucket semantics:

JOI + CEI → Interaction Styles

POV → Content Type

Countdown → Scene Elements

Cowgirl → Positions (Source: Convo 1 Part 1B)

Confirmed migration safety rule: keep legacy select/multi-select (e.g., Tags multi-select) until migration is complete; only edit relation-based properties during cleanup. (Source: Convo 1 Part 1C)

Unblocked schema edits by fixing only the broken/invalid view filters blocking database updates (preserving the ALL (Table) view focus). (Source: Convo 1 Part 1C)

Added Positions (Rel) property to Customer Orders/Requests and linked to ❤️Positions. (Source: Convo 1 Part 1C)

Renamed Tags (Rel) → Scene Elements (Rel) (property rename; Tags multi-select left intact). (Source: Convo 1 Part 1C)

Started “one home per term” cleanup: moved JOI + CEI into Interaction Styles; moved icon POV into Content Types (canonical icon rule). (Source: Convo 1 Part 1C)

Recreated + restored canonical placements on test order after accidental revert (Cowgirl→Positions; Countdown→Scene Elements; CEI→Interaction Styles; legacy Styles cleared). (Source: Convo 1 Part 1C)

Ran audit sweep on real orders for misplacements (CEI/JOI/Cowgirl/Countdown/POV in wrong buckets) and confirmed clean. (Source: Convo 1 Part 1D)

Deleted legacy ❤️Styles (Rel) property from Customer Requests once no longer needed (kept Tags multi-select). (Source: Convo 1 Part 1D)

Renamed connected databases (kept ❤️ visual key):

❤️✨Content Tags → ❤️Scene Elements

✨Product Items → ❤️Items & Deliverables (Source: Convo 1 Part 1D)

Dependency check: confirmed Styles database unused elsewhere; deleted legacy ❤️Styles database. (Source: Convo 1 Part 1D)

Converted Service Subcategories (text) → relation and renamed to Subcategories (Rel); renamed DB to ❤️Subcategories. (Source: Convo 1 Part 1D–1E)

Created taxonomy DB for “select options as pages”: ❤️Item Classes (Deliverable/Physical Item/Wardrobe/Toy/Prop/Digital Add-on). (Source: Convo 1 Part 1F)

Established owned-instance lifecycle DB and wiring: ❤️Inventory (formerly Inventory Items), linked to catalog + requests + item titles for reorder/logistics loop. (Source: Convo 1 Part 1F–1H)

Clarified backbone target set (5 DBs): ❤️Customer Requests + ❤️Items & Deliverables + ❤️Item Catalog Titles + ❤️Inventory + ❤️Item Classes. (Source: Convo 1 Part 1H)

6) Scheduling + unified day backbone (Today surfaces)

Canonical scheduling DBs confirmed: ✨Booking Calendar + ✨Availability + ❤️Unified Schedule. (Source: Convo 2 Part 1 + Reconnect Map section)

Event Types updated for unified calendar surface. (Source: Reconnect Map section)

“Paid Call Queue” requirements recorded. (Source: Reconnect Map section)

Schedule Blocks + Routine/Checklist Templates created and connected (unified personal+business day). (Source: Convo 2 Part 1C + Reconnect Map changelog)

Verify/standardize that every “Today” dashboard reads from canonical sources (schedule blocks, tasks, expenses/income, sales, subscriptions, purchases, inventory) and log any missing relations/views. (Source: Convo 2 Part 1 + platform intent)

Convo 1–2 granular actions (calendar surfaces + queue features)

Platform docs reviewed in order (Blueprint → DB Schema → Routes Index); recorded that Notion is a synced mirror + mapper/scanner exists. (Source: Convo 1 Part 2A)

Added Booking Calendar ↔ Customer Requests cross-link (booking slot references request; request references booking slot). (Source: Convo 1 Part 2A)

Added Booking Calendar rollups from linked Customer Request (name/username/email/pay status/shoot status/rate) for at-a-glance slot context. (Source: Convo 1 Part 2B)

Confirmed Booking Calendar “Client” is relational (Client (Rel) → Contacts), so a scheduled slot can link to a real contact record. (Source: Convo 1 Part 2B + Convo 1 Part 2A)

Defined ingestion rule for ❤️Unified Schedule: upsert rows whenever Booking Calendar changes, a Customer Request becomes scheduled, or an Availability override changes. (Source: Convo 1 Part 2B)

Added rollups on ❤️Unified Schedule for at-a-glance fields (request context, booking context, contact info). (Source: Convo 1 Part 2B)

Added Event Type (Rel) to ❤️Unified Schedule (relation to ✨Event Types) to avoid select-based event typing long-term. (Source: Convo 1 Part 2C)

Defined “Calls” visibility rules (public can see busy + duration; participant sees details) using Public Label + Start/End + privacy rules. (Source: Convo 1 Part 2B–2C)

Expanded “Paid Call Queue” spec with bundle mode (N×10min → one reserved block) + queue policy behaviors (prepaid bundled, prepaid unbundled, non-prepaid). (Source: Convo 1 Part 2C)

Created ❤️Paid Call Queue as an operational mirror DB (platform can upsert; queue state tracked in Notion). (Source: Convo 1 Part 2D)

Created “Operational Mirror Databases” index page and agreed: index links only; mirror DBs stay near domain hubs. (Source: Convo 1 Part 2D)

Created/confirmed ❤️Collaborations DB + rule: never delete legacy Agent/JJENT/Dance DBs; unify via relations instead. (Source: Convo 1 Part 2C)

Applied “no select/multi-select long-term” conversions discovered during audit (Paid Orders statuses, Community Events types/statuses, Media types, Item Catalog titles tags/priorities/seasons). (Source: Convo 1 Part 2G)

7) Commerce + inventory lifecycle (Closet + sales + purchases)

Closet lifecycle standard recorded + canonical Closet DB created/connected. (Source: Convo 2 Part 1C + Reconnect Map changelog)

Wishlist → Purchased → Expenses behavior (implement during Wishlist planner refactor). (Source: Convo 3 Part 3D + Finance appendix)

End-to-end item lifecycle verification: acquired → in closet → packed/listed → sold/donated/archived, tied to Events + Schedule Blocks + transactions. (Source: Convo 2 Part 1C + product intent)

Convo 1 granular actions (catalog ↔ inventory consolidation + duplicates)

Decided: Item Catalog Titles holds Amazon/website “title record” + taxonomy + purchase link/SKU/price; Items & Deliverables holds offer/add-on menu; Inventory holds owned instances. (Source: Convo 1 Part 1G–1H)

Moved “10min Scene – Office” out of Item Catalog Titles into ❤️Scene Types. (Source: Convo 1 Part 1F / Part 1 follow-up)

Merged “(ready to archive)” duplicate DB schemas into keepers before deleting: Marketplace Listings, Media Library, Photo Albums. (Source: Convo 1 Part 1F)

Deleted redundant “(ready to archive)” DBs after block replacement/removal on hub pages (where referenced). (Source: Convo 1 Part 1F)

Consolidated and deleted ❓✨Product Items Catalog after migrating rows into ❤️Items & Deliverables. (Source: Convo 1 Part 1F)

Consolidated Size Terms by keeping ❤️Size Terms (Do not delete) and deleting the deletable Size Terms after merge/audit. (Source: Convo 1 Part 1F)

8) Finance planner refactor (DONE FOR NOW)

Execution Phases — Full Detail

Integrated Genspark reconnect materials + phases

This master plan uses the following reference toggles (below) as the single-source detail:

Operating Standards

Integrated Reconnect Checklist + Phases

Backend Rebuild Changelog

The original remains as historical context unless Jillian later approves archiving it.

Execution phases (global)

Phase 0 — Create the inventory surfaces

Create a “Linked Index — All Planners & Databases” page (inventory only):

Add linked views that list:

all planners (from Systems)

all top-level planner hubs (Final Planner + other key hubs)

all detected finance-related pages/databases (to be migrated into Finance)

Link Audit Queue subject pages ↔ Systems items (two-way relation)

For FINAL PLANNER Career subjects: file visible DB blocks into section headers; park the rest; then re-file once titles are visible

Phase 1 — Finance planner final sweep (from Final Planner)

Sweep FINAL PLANNER for finance-related databases/pages

Log every found finance DB/page in the Linked Index page

Decide: keep in Finance vs move to another subject planner

Only after decisions: move pages/DBs (manual move by you) and do a finance-style refactor checklist

Phase 2+ — Planner-by-planner consolidation

Create a planner section for each subject (Projects, Home, Travel, Books/Library, Recipes/Meals, Business, etc.)

For each subject planner:

Inventory + dependency scan

Identify canonical system databases (mark brown-square)

Identify duplicates and “merge candidates”

Legacy tracking (per-planner)

Verification pass

Safest order of operations (always follow)

We run the work in 3 global steps (finish Step 1 for ALL subjects before Step 2):

1) Step 1 — Compile / “moving by links” (no real moves):

For each subject, compile all same/similar pages & databases into ONE place using links to the original objects so you can click through and compare.

Until you name an official planner page for that subject, the subject page acts as the temporary planner page for compilation.

If you have already named the official planner page, then that official planner page replaces the subject page for Step 1.

2) Step 2 — Merge / consolidate (keeper-first):

Choose the keeper per cluster; then add missing properties/formulas/relations on the keeper first.

Migrate unique rows/options into the keeper (temporary text field allowed for manual transfer).

Stage legacy items into the Deletion Queue (do not delete until the end unless empty + fully migrated + you explicitly confirm).

3) Step 3 — Final placement into the official planner:

After merges are done for that subject, move what’s kept into the designated official planner page (if it differs from the temporary subject page).

When every subject has an official planner page, those official planners can be moved into LIFE PLANNER.

Finance exception (current state): Finance already has an official planner page: finance planner (keep for visual layout). So Finance compilation links should go directly onto the Finance planner page (and the Finance subject page can be treated as temporary/optional).

Subject pages remain the primary navigation map (until all official planners are chosen):

Even after an “official planner page” is identified for a subject, keep that official planner page inside / under the subject page for now so the subject pages remain the single place to browse the whole system.

Example: Finance planner can live under the Finance subject page until the full set of official planner pages is finalized.

Phase 2A — Final Planner (Career) layout cleanup (DBs under correct headers)

Business Planner: finish filing newly-visible DBs into best-fit sections; add (NEW) headers where needed

Bookings & Scheduling: sanity-check section placements and empty/unnamed DB blocks

Products & Inventory: group taxonomy/ops/deprecated into best-fit sections; add (NEW) headers where needed

Services & Content: create top-level sections (Services, Requests/Quotes, Content, Community, Marketplace, Media, Taxonomy); file DBs accordingly; add (NEW) headers where needed

People & Contacts: refine sections (People core, Customers, Roles, Safety, Affiliate/Referrals, Vendors/Talent); file DBs accordingly; add (NEW) headers where needed

Creative & Production: add sections (Mood/Moods, Boards, Shot planning, Tags/Options); file DBs accordingly; add (NEW) headers where needed

Additional Detail — Gaps from Doc 1

Content from Doc 1 not captured in the sections above. Organized by topic.

Navigation Map (original toggle structure)

• Databases for planning → where the inventory databases and audit queue live
• Rules (global + task-specific) → standing rules + task-specific rules
• Operating Standards → deeper operating procedures for backend/reconnect work
• Progress tracker (subjects × steps) → high-level status scoreboard
• Execution phases (global) → the full multi-phase plan
• Integrated Reconnect Checklist + Phases → combined reconnect+plan checklist
• Exact Duplicates — Verified Delete List → formatting-stable list of delete/keep pairs; do not reformat internally unless explicitly requested
• Backend Rebuild Changelog → change log for reconnect

Reference pages (keep as single source of truth — link, don't duplicate)

Use these sections as the single place to read the full detail for each topic. Other parts of this Master Plan should link here instead of repeating the same rules/tasks.

• Operating Standards
• Integrated Reconnect Checklist + Phases
• Backend Rebuild Changelog
• Cleanup Review List — Merge / Rename / Archive / Delete
• Exact Duplicates — Verified Delete List
• 🗑️ Exact Duplicate Pages Queue (database)

Task-specific rules

Put new "one-off" rules here so they don't get duplicated across other sections.

• Same-title pages such as "To do still" and "Calendar organization" still need property/content comparison before any deletion — they were flagged as false positives in the exact duplicate pass
• Film Schedule (ready to archive) rule: unique row migrated; archive deleted after confirmation. Apply this rule to other "(ready to archive)" DBs as encountered.
• Closet lifecycle standard: Physical items should be trackable end-to-end via ❤️Closet Items → in closet / owned → packed/listed → sold/donated/archived, tied to purchases, sales, events, schedule blocks, customer requests, and inventory where applicable.

Progress tracker — canonical scoreboard rule

This is the canonical scoreboard. Update this section as each step per subject is completed. Mirror the same status in chat when reporting progress.

Step 1 addendum — Linked views bundle (goal and rule)

Goal: For each database surfaced in a subject page, bundle the original database block/link together with links to existing linked views of that same database elsewhere in the workspace — so you can quickly jump to view setups while merging, without moving anything or creating new views.

Rule: Add a short bulleted list of clickable links to the existing linked-view locations directly under the same toggle section as the original database, immediately after the original database block.

Status: Finance complete; remaining 11 subjects not started.

Step 1 addendum — Section pages (goal)

Goal: Replace subject-page toggles with subject sub-pages (one page per section/header) so sections are never empty and are linkable from master inventory.

Keep on each subject page after clearing:

• A short "This subject is now tracked in the Master inventory" note
• Links to 🟫 Master — Databases Inventory and 🟫 Master — Views Inventory

Completed: Learning/University, Meal Planner, Weekly Planner, Productivity Planner, Study Room/Winter, Recipe/Kitchen/Meal, Posting Planner, Personal Schedule, Quotes, and remaining legacy clusters. Preserved true UI/filter/settings review flags instead of clearing uncertain rows.

Step 2 setup — additional checklist items

• List any databases that should become properties/relations instead of standalone databases, following Rules + Operating Standards and the Genspark reconnect operating rules.
• Build a step-by-step merge plan by cluster before touching data.
• Keep exact duplicates separate from "similar but not identical" clusters — similar clusters handled later under Jillian's next rules.
• Calendar / timeline / map settings must be compared when checking view duplicates.
• If two databases are truly identical or one is a richer superset, choose the richer/more connected keeper.
• Before any duplicate database is marked for deletion/archive, make sure all useful views/templates/properties/rows/page content/media are migrated, mirrored, or recreated on the keeper.

Execution phases — additional sub-phases

• Phase 2A — Final Planner (Career) layout cleanup: DBs under correct headers
• Phase C — Merge / consolidate: for underlying duplicate databases, compare schema, properties, relation targets, rollups, formulas, options, templates, views, rows/pages, page content, covers, icons, files, media, and frontend dependencies
• Phase F — Scheduling and unified day backbone: confirm tasks, schedule blocks, events, expenses, income, sales, subscriptions, purchases, inventory, wishlists, closet items, bookings, customer requests, and content work all connect through canonical databases
• After merges are done for each subject, move what is kept into the designated official planner page
• Even after an "official planner page" is identified for a subject, keep that official planner page visible as a navigation surface — do not delete it

Subject-specific planner sections (planned, not yet created)

• Services & Content: create top-level sections (Services, Requests/Quotes, Content, Community, Marketplace, Media)
• People & Contacts: refine sections (People core, Customers, Roles, Safety, Affiliate/Referrals, Vendors/Talent)
• Creative & Production: add sections (Mood/Moods, Boards, Shot planning, Tags/Options); add (NEW) Positions DB
• Dashboards & Analytics: add sections (Dashboards, Analytics, OKRs, Taxonomy); file DBs accordingly

Backend Rebuild Changelog — additional completed items

• Statuses hub canonicalized. (Source: Convo 2 Part 1B–1C)
• Implemented broad "no select/multi-select long-term" pattern: for each operational DB, create taxonomy DB + add (Rel) property → legacy select/multi-select preserved until fully migrated.
• Executed multi-hub taxonomy conversion sweeps (Dashboards & Analytics, Services & Content, People & Contacts, Creative & Production).
• Cowgirl → Positions. (Source: Convo 1 Part 1B)
• Added Positions (Rel) property to Customer Orders/Requests and linked to ❤️Positions. (Source: Convo 1 Part 1C)
• ✨Product Items → ❤️Items & Deliverables. (Source: Convo 1 Part 1D)
• Converted Service Subcategories (text) → relation and renamed to Subcategories (Rel); renamed DB to ❤️Subcategories.
• Created taxonomy DB for "select options as pages": ❤️Item Classes (Deliverable/Physical Item/Wardrobe/Toy/Prop/etc.)
• Created/confirmed ❤️Collaborations DB + rule: never delete legacy Agent/JJENT/Dance DBs; unify via relations instead.
• End-to-end item lifecycle verification: acquired → in closet → packed/listed → sold/donated/archived, tied to purchases, sales, events, schedule blocks, customer requests, and inventory.
• Decision: keep "structural pages" (Products & Inventory, Bookings & Scheduling, Services & Content, etc.) as the primary navigation map until all official planners are ready.
• Hub-specific Platforms and Geography databases converted into linked views where appropriate. (Source: Convo 2)
• Known high-impact operational databases received canonical address/location/client relations. Legacy City/State/Country/ZIP/text fields preserved as legacy fields.
• ✨Scene/Travel Locations (was ✨Locations) — scene/travel/content.
• Customers can prepay to reserve a place in line (queue feature).
• Record the "gap logic" rules (feature missing vs disconnected vs broken by re-org). (Source: Convo 3 Part 4A)
• Rules finalized (migrate unique rows/options → confirm delete). (Source: Convo 2 Part 1E–1F)

Frontend reconnect — gap logic rules

If something described in the frontend is not connected to something in Notion, it generally means one of:

• It was never connected (new feature, add to reconnect list)
• It was connected previously but the backend re-org (renames/replacements/merges) broke the link
• Mark it as backend-only (Notion-only dashboards/views) so it is not treated as a missing connection

Expenses that flow through the platform: food, outfits, travel, alcohol, etc.

Finance — additional semantic rules

• Chargebacks/reversals: treat as 🔁 Refund unless a separate "Chargeback" type is wanted later. Net Spend behavior is identical to Refund.
• Formula/Rollup legacy fields: delete as soon as all dependencies (views, charts, formulas, buttons) are migrated to system fields.
• Notion UX (views, galleries, label-style "notification center" pages) — preserve during finance cleanup.
• Refunds are cash-in, but tracked as Refund (not Income) so "earnings" stays clean.
• Spent (for budgets) = if Type=Expense → abs(Amount) else 0
• Net Spend = Spent − Refunded
• Interest → Net Spend is fine (refunds are rare), but can be treated as a discipline bucket if desired.
• Keep Income/Expenses as separate ledgers for now, but plan migration to Transactions views later.
• Phase 1 (Finance inventory): for Income/Expenses/Categories/Subcategories, inventory property dictionary (meaning + duplicates) and dependencies (formulas, rollups, view filters/sorts/grouping, charts, buttons).

Exact Duplicates — additional delete/keep pairs (Projects Database)

• Delete: Ideas for apple → Keep: Ideas for apple
• Delete: Ibuprofen for pain 2 hours Morin → Keep: Ibuprofen for pain 2 hours Morin
• Delete: movies → Keep: movies
• Delete: Hi I'm back in town I can do this or next Saturday! → Keep: Hi I'm back in town I can do this or next Saturday!
• Delete: Meaning of life; reason to live → Keep: Meaning of life; reason to live
• Delete: Intuitive → Keep: Intuitive
• Delete: internet → Keep: internet
• Delete: In Progress → Keep: In Progress
• Delete: Master Todo → Keep: Master Todo

Linked Index — additional move checklist detail

Use as a move checklist: move each database block into the existing "home" page listed. If no dedicated home page exists, leave the database on the subject page.

Finance embedded DB blocks spotted (inside finance planner page): Categories (Budget Template), Type (Budget Template), Accounts (Accounts view placeholder), Untitled (Income + Expenses combined view), Untitled (Categories view — Subscriptions filtered), Monthly Expense gallery (⭕️ Expense only), Monthly Income gallery (🟢 Income only), Month View, Subcategories.

Booking Request & Availability System — Plan — spotted under Bookings & Scheduling review list.

Additional content from Doc 1 — Appendix

• When refactoring Wishlist databases later:
• Purchased items link to a corresponding Expenses row
• Inventory only — do not move anything yet
• Linked views

Additional content from Doc 1 — G sections

• Remove Words from Text — kept one row and removed six exact empty duplicates.

Additional content from Doc 1 — Navigation map

• Navigation map (where to find things)
• Databases for planning
• Scope / goal
• Reference pages (keep as toggles; avoid duplicating text)

Additional content from Doc 1 — Integrated Reconnect

• select/status/multi-select options,
• page content,
• No activating deletion confirmation buttons before the approval list is reviewed.
• For exact duplicate linked views, keep the version attached to the richer/more complete page layout or the one with useful cover/photos/media/page content.
• Countdown → Scene Elements
• ❤️Customer Requests
• Confirm every frontend commerce route/form points to the correct canonical database.
• Verify every Today dashboard reads from canonical sources.

Additional content from Doc 1 — Progress tracker / Step 1

• Mirror the same status in chat when reporting progress.
• Finance
• Projects & Tasks
• Products & Inventory
• Services & Content
• Bookings & Scheduling
• Dashboards & Analytics
• People & Contacts
• Creative & Production
• Step 1 addendum — Toggle UX pass (complete)
• Products & Inventory
• Templates Reference
• Finances (subject page link to finance planner)
• Bookings & Scheduling (VIP Events + additional headers toggled)
• Services & Content
• Dashboards & Analytics
• People & Contacts
• Rule: Add a short bulleted list of clickable links to the existing linked-view locations directly under the same toggle section as the original database, immediately after the original database block.
• Finance
• Projects & Tasks
• Products & Inventory
• Services & Content
• Bookings & Scheduling
• Dashboards & Analytics
• People & Contacts
• Creative & Production
• 🟫 Master — Views Inventory (one row per view/location reference)
• Bookings & Scheduling (databases added)
• Products & Inventory
• Services & Content
• People & Contacts
• Creative & Production
• Dashboards & Analytics
• Personal Planner
• Goal: Replace subject-page toggles with subject sub-pages (one page per section/header) so sections are never empty and are linkable from master inventory.
• Re-home database links into section sub-pages (so subject pages may be empty later, but sections are not)
• Tracking (complete one subject at a time):
• Bookings & Scheduling
• Products & Inventory
• Services & Content
• People & Contacts
• Creative & Production
• Dashboards & Analytics
• Personal Planner
• Step 1 addendum — Clear subject pages after migration (not started)
• Links to: 🟫 Master — Databases Inventory and 🟫 Master — Views Inventory
• Finance
• Projects & Tasks
• Products & Inventory
• Services & Content
• Bookings & Scheduling
• Dashboards & Analytics
• People & Contacts
• Creative & Production
• Templates Reference

Additional content from Doc 1 — Step 2 setup

• Step 2 setup — Exact duplicate linked-view + database merge audit (in progress)
• sorts
• group and subgroup settings
• chart / dashboard / form settings
• For duplicate underlying databases, compare:
• formulas
• options/statuses
• views/templates
• If two databases are truly identical or one is a richer superset, choose the richer/more connected keeper.
• Finance
• Projects & Tasks
• Products & Inventory
• Services & Content
• Bookings & Scheduling
• Dashboards & Analytics
• People & Contacts
• Creative & Production
• Finance
• Projects & Tasks
• Products & Inventory
• Services & Content
• Bookings & Scheduling
• Dashboards & Analytics
• People & Contacts
• Creative & Production

100% Coverage — Final Fragments by Section

These are the remaining fragments from Doc 1, placed in their correct sections. With these added, all content from Doc 1 is accounted for.

Rules Standards — additional items

• Format: (added: YYYY-MM-DD h:mm AM/PM ET; done: YYYY-MM-DD h:mm AM/PM ET).
• Labels are signals, not decisions: "ready to archive," "DELETE?," "dup check," "merge," "official," "keeper," and "do not delete" are review labels only. They do not decide the action by themselves.
• Review its select, multi-select, text-option, relation, rollup, and formula setup.
• Later cleanup / technical debt

Done Completed — additional items

• Step 1 — Compile / "moving by links" — tracking per subject (complete one subject at a time)
• Documents & Media (nested under top toggle) — Toggle UX pass complete
• Rule: After a subject's databases/views are fully captured in the 🟫 Master inventory databases, remove the detailed inventory blocks from the subject page so it can remain mostly empty (Audit Queue style).
• Goal: Reduce manual merge work by identifying what is truly identical before reviewing "similar but not identical" databases.
• schema/properties/property types — must be compared for each duplicate database before deletion
• Before any duplicate database is marked for deletion/archive, make sure all useful views/templates/properties/rows/page content/media are migrated, mirrored, or recreated on the keeper.

Cleanup Review — additional items

• These need verification before the label is trusted. If the label is wrong, the action is rename/remove the warning label, not archive/delete.
• Merge-review candidates — these appear to need true schema/data comparison, not just inventory row cleanup.
• ✨Personal Habits — Compare concepts and lifecycle before merging. Some may track daily logs, some habit definitions, some weekly checklists.
• Service Formats (ready to archive) — Determine global vs domain-specific. "Format" may be shared globally or may differ by documents, personal media, services/content.
• People / Personal People — merge-sensitive due to contacts, gift recipients, and frontend/person semantics.
• Important: These four University candidates are candidates only. Nothing has been archived or deleted.
• Service Formats — file/media format hub with rows like PDF, PNG, MP4, ZIP, CSV, JSON, H.264, ProRes.
• Personal Formats Database — simpler personal file-format DB with Format Name, Description, File Extension, Note.
• Conclusion: Formats group contains at least two different concepts — file/media formats and service/request formats.
• Status notes for F3-F7: Compared at schema and row-count level. No deletion or archive approved for any group.
• DELETE? label review pass — verify all DELETE? labels before any action.

Exec Phases — additional items

• Create a planner section for each subject (Projects, Home, Travel, Books/Library, Recipes/Meals, Business, etc.)
• Services & Content: create top-level sections (Services, Requests/Quotes, Content, Community, Marketplace, Media, Taxonomy)
• People & Contacts: refine sections (People core, Customers, Roles, Safety, Affiliate/Referrals, Vendors/Talent)
• Creative & Production: add sections (Mood/Moods, Boards, Shot planning, Tags/Options); add (NEW) Positions DB
• Dashboards & Analytics: add sections (Dashboards, Analytics, OKRs, Taxonomy); add (NEW) headers where needed
• Phase F — Scheduling and unified day backbone: confirm tasks, schedule blocks, events, expenses, income, sales, subscriptions, purchases, inventory, wishlists, and closet items all connect through canonical databases

Reference Library — additional items

• Additional Genspark reference links:
• Database Schema (all tables + columns): https://indulgon.com/docs/DB-SCHEMA.html
• Changelog (every build session): https://indulgon.com/docs/CHANGELOG.html

Exact Dups — additional items

• • Delete: Meaning of life; reason to live → Keep: Meaning of life; reason to live
• • Delete: Intuitive → Keep: Intuitive
• • Delete: internet → Keep: internet
• • Delete: Ideas for apple → Keep: Ideas for apple
• • Delete: Ibuprofen for pain 2 hours Morin → Keep: Ibuprofen for pain 2 hours Morin
• • Delete: movies → Keep: movies
• • Delete: Hi I'm back in town I can do this or next Saturday! → Keep: Hi I'm back in town I can do this or next Saturday!
• • Delete: In Progress → Keep: In Progress
• • Delete: Master Todo → Keep: Master Todo

Standing Instruction — New Rules Auto-Added to Master Plan

Rule (added 2026-06-22): Any time Jillian gives an instruction during a session that is not already in this master plan, it must be added here immediately — in the correct section — so the same instruction never needs to be repeated and no duplicate instructions accumulate across sessions.

• New rules → add to Rules & Standards section
• New operating procedures → add to Operating Standards section
• New completed work → add to Done / Completed Work section with a done timestamp
• New tasks → add to NEXT ACTIONS or Remaining Work in the correct category
• New reference links → add to Reference Library

Doc 2 — Additional Content (merged in)

These are the items from Doc 2 that were not already in the merged plan from Doc 1. All unique content from Doc 2 is now included.

Rules & Standards — True merge / dedupe standard (Doc 2 version)

Use this standard when merging any two sections that cover the same topic:

• Treat every old section as if it was "floating," assign it to one of the three top-level toggles, and merge it into the matching canonical section.
• Compare duplicate/similar sections line-by-line.
• For partial duplicates where one line is a subset of another, keep the fuller/superset version and add only the missing unique part if needed.
• Example: "apple" + "apple" = keep one "apple."
• Example: "apple and banana" + "apple and banana and lime" = keep "apple and banana and lime."
• Example: same base task + extra status/detail/date/context = keep the more complete version and merge any missing useful detail into it.
• Update checked/unchecked status so the canonical checklist is accurate.
• Do not invent exact timestamps for historical completed work. If the old page already has a timestamp, preserve it; otherwise leave historical items untimestamped.

Operating Standards — Duplicate database merge rule (Doc 2 superset)

• Duplicate database merge rule (Doc 2 superset): Compare purpose, schema, properties, relation targets, rollups, formulas, options, templates, views, rows/pages, page content, covers, icons, files, media, and frontend dependencies before any duplicate is retired.

Frontend ↔ Backend Audit Logic (new section from Doc 2)

• Frontend ↔ backend audit and gap logic belong together in one canonical section.
• Compare the platform blueprint/schema/routes/forms/connection docs against current canonical Notion databases.
• Build a reconnect delta list showing old DB/property, new canonical DB/property, affected feature/route/form, migration note, and status.
• Confirm no frontend references point to deleted or legacy databases before final cleanup.

Product Intent — Unified Personal + Business Operating System (new from Doc 2)

• The backend should support one day-in-the-life operating model across personal + business work.
• Today surfaces should be able to connect tasks, schedule blocks, events, expenses, income, sales, subscriptions, purchases, inventory, wishlists, closet items, bookings, customer requests, and content work.
• Finance, commerce, scheduling, inventory, and customer-request routing should remain connected through canonical databases and relation-backed taxonomy.

Reference Library — Additional items from Doc 2

• Main reference groups in Navigation map: Cleanup Review List, Exact Duplicates — Verified Delete List, Backend Rebuild Changelog, Taxonomy & Config, Dashboards & Reports, Protected Legacy, Finance reference/spec, Linked Index.
• Dashboards & Reports → reporting surfaces and dashboard/analytics reference.
• Original duplicate backup page: 🟫🟫 Workspace Planner Consolidation — Master Plan (1) — Backup for Restructure (preserved as source archive; pull source sections into this merged plan only when needed; keep under Reference Library, not as new top-level sections).

REVISED PROCESS — Updated June 22, 2026

This section supersedes any conflicting steps in the original master plan. All changes are logged here.

Context — How the workspace got to this state

• Started with existing Notion workspace + databases
• Downloaded templates with pre-filled databases → duplicated what already existed
• Platform build (AI tools) created MORE databases — each AI tool added its own versions
• Master plan consolidation process created organizational databases (Master Databases Inventory, Views Inventory, linked views) → paradoxically added MORE clutter
• Manually tried to compare duplicates by moving them into subject pages as inline databases → got overwhelming
• Result: workspace has MORE perceived duplicates now than when we started because of all the organizational infrastructure added on top

Icon system — which round each database came from

• ✨ (sparkle) = First round — the original databases, likely connected to the Indulgon platform frontend
• ⭐️ (star) = Second round — added during template downloads or second pass
• 🟫 (brown square) = Third round — master plan consolidation designated keepers
• No icon / plain name = Template databases or miscellaneous
• IMPORTANT: The ✨ sparkle databases are most likely the ones the platform is currently connected to. These take priority as keeper candidates even if the 🟫 brown square version looks better visually — because platform connection is harder to switch than visual layout.

Keeper selection rule — REVISED

Original rule was: most complex schema = keeper. Revised rule is:

1. First check: Is one of the duplicates connected to the Indulgon platform frontend? If yes → that one is the target database (keeper) regardless of visual appeal. Everything merges INTO it.
2. If none are platform-connected: Choose keeper based on most complex schema (most properties, hardest to rebuild), then most visual appeal (covers, icons, page content photos).
3. Visual appeal from a non-keeper can be migrated: copy cover photos, icons, and page content into the keeper. Schema/properties are harder to move than visual elements.

The actual merge process — step by step

1. Find all databases for the same subject — gather them all onto the subject page so they are visible together
2. Designate the target database (keeper) — show this to Jillian for confirmation before merging anything
3. For each source database:
   • Copy any unique properties into the target (add, do not overwrite)
   • Move all pages/rows into the target
   • Copy any unique views and their settings into the target
   • Copy covers, icons, and page content photos into the target
   • Preserve as "Legacy [name]" any properties that conflict until frontend reconnect verified
4. After all sources merged: clean up duplicate properties inside the single keeper database
5. Show Jillian the result — get visual confirmation before any source database is archived/deleted
6. Archive source databases only after Jillian confirms the keeper looks right
7. Reconnect platform only after Jillian explicitly says all databases look the way she wants

What NOT to do — hard rules

• Do NOT start frontend reconnect until Jillian explicitly approves the final database state
• Do NOT delete any source database until Jillian visually confirms the keeper has everything
• Do NOT merge Formats group (file formats ≠ service formats — different concepts)
• Do NOT move databases out of pages they are currently in if that would break visual layouts Jillian is relying on
• Do NOT remove legacy properties during the same pass as the merge — mark as Legacy first
• Do NOT assume "ready to archive" or "DELETE?" labels mean take action — they are signals only

Global taxonomy hubs — what should be shared across all databases

These should be single canonical databases that all other databases point to via relation (not duplicated per subject):

• Platforms (OnlyFans, SextPanther, etc.)
• Addresses
• Cities, States, Countries
• Truly shared Statuses (In Progress, Done, etc.) — BUT only when the status lifecycle is identical across subjects. Customer Request Status ≠ Task Status ≠ Inventory Status even if they share names.
• Shared categories/tags that appear across multiple subjects

Example of correct global hub usage: Task "Finish custom video request" is In Progress → connects to Customer Request database row → connects to the specific customer → connects to the specific content type. One status value shows across all three contexts.

Bidirectional sync goal

The end state: add anything (note, task, recipe, feature idea, wishlist item, ingredient) from either Notion OR the Indulgon platform and it syncs both ways automatically:

• Add a recipe note in Notion → appears in platform Recipes page
• Add a feature idea as a task in platform → appears as a task in Notion AND as a checklist item → when completed, crosses off in both AND adds to platform Updates page
• Add an ingredient to a recipe later → appends to the recipe, does not create a duplicate
• Mark ingredient as "need to buy" → creates a shopping list item → when purchased and checked off, updates the recipe inventory

Current access status (June 22, 2026)

GenSpark Claw can currently see: 22 databases, 867 pages. Key accessible databases:

• Recipes (×4 — ready to merge), Shopping List (×2), Habits (merge), Events, Menu Planner, Gift Planning, Expense Tracker, Ingredients, Wishlist (×2), Notebook Main, Traditions, Cover Photos

Platform-connected databases (in .env — NOT yet accessible to GenSpark Claw):

• USERS_DB_ID: 263b8641-18fc-8077-8823-e7b4a8354c78
• BOOKINGS_DB_ID: 36bb8641-18fc-8155-bdc6-ee5917b317a1
• EARNINGS_DB_ID: 36bb8641-18fc-819f-9d66-f72326818d4c
• NOTIFICATIONS_DB_ID: 36bb8641-18fc-8182-beec-d9a04151ec3f
• SUPPORT_DB_ID: 36bb8641-18fc-8110-ac47-dc4e98492402
• LEGAL_DB_ID: 36bb8641-18fc-8170-a5ac-eb21c10c1f03
• CONTENT_DB_ID: 36bb8641-18fc-819d-b207-c459fbecfb02
• SAFETY_ALERTS_NOTION_DB_ID: 36bb8641-18fc-81cf-98d4-ec9c581b95aa
• BUSINESS_ALERTS_NOTION_DB_ID: 36bb8641-18fc-818b-a097-ccf3a94ec7ed
• PAYOUT_HISTORY_DB_ID: 36bb8641-18fc-8124-ba24-e373f4c2b319
• PLATFORM_STATS_DB_ID: 36bb8641-18fc-81f9-a98c-f1afd463c32e
• ACTIVITY_LOG_DB_ID: 367b8641-18fc-8191-9706-e905b99d5438
• CONNECTED_ACCOUNTS_DB_ID: 367b8641-18fc-8198-8f58-d8af5e9d99ab

Pages still needed: Share FINAL PLANNER, all subject pages, and 🟫 Master — Databases Inventory with GenSpark Claw to enable the full merge process.

~~Steps marked done in original plan that need re-verification~~

The following were marked done but need a fresh check because the process that created them also created additional clutter:

• ~~Phase 0 — Inventory surfaces created~~ → Keep Master Databases Inventory as optional organizational aid, not as a required step. The actual merge process does not depend on it.
• ~~Phase 1 — Exact duplicates deleted~~ → Verify the deletions were correct and nothing useful was removed. Will check as each subject is processed.
• ~~Linked views created for each subject~~ → These linked views may themselves now be clutter. When we process each subject, we will replace linked views with the actual original database moved into the correct location.

Standing instruction — new rules auto-added (updated)

Any instruction Jillian gives that is not already in this master plan gets added here immediately in the correct section. No instruction should ever need to be repeated.