Doc 1 — Master Plan (strikethrough = merged into Doc 3)
Strikethrough gray = merged into Doc 3
Normal black = NOT yet in Doc 3 (review these)
Start here
What this page is: A live master plan + handoff doc for consolidating the workspace safely (inventory-first, keeper-first, no destructive actions without approval).
How to use it: Work from NEXT ACTIONS only. Everything else is reference/supporting detail.
Do-not-touch rule: The “Exact Duplicates — Verified Delete List” section is formatting-fragile; do not rewrite its internal formatting unless explicitly requested.
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.
Reference pages (link here; don’t duplicate text)
Operating Standards (in Navigation map)
Integrated Reconnect Checklist + Phases (in Navigation map)
Backend Rebuild Changelog (in Navigation map)
Cleanup Review List — Merge / Rename / Archive / Delete (in Navigation map)
Exact Duplicates — Verified Delete List (in Navigation map)
🗑️ Exact Duplicate Pages Queue (in Navigation map)
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).
When a task is completed, add a done: timestamp on the same line when checking it off.
✅ NEXT ACTIONS (single source of truth)
Use this as the only “what do I do next?” checklist. Add new tasks here the moment they are discovered, and check them off when finished. Add timestamps per the Start here rule.
Now (next 1–3 actions)
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.
Build the next approval-ready cleanup batch (no deletions): produce a clickable review list with keeper decisions + why.
Always-on rules you must follow while doing the tasks above
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).
Navigation map (where to find things)
Databases for planning → where the inventory databases and audit queue live (toggle below).
Rules (global + task-specific) → standing rules + task-specific rules (toggle below).
Operating Standards → deeper operating procedures for backend/reconnect work (toggle below).
Progress tracker (subjects × steps) → high-level status scoreboard (toggle below).
Execution phases (global) → the full multi-phase plan (toggle below).
Integrated Reconnect Checklist + Phases → combined reconnect+plan checklist (toggle below).
Cleanup Review List — Merge / Rename / Archive / Delete → comparison findings + approval gating (toggle below).
Exact Duplicates — Verified Delete List → formatting-stable list of delete/keep pairs (toggle below; do not reformat unless requested).
Backend Rebuild Changelog → change log for reconnect (toggle below).
Databases for planning
Purpose
This is the running execution plan for consolidating all planners + databases across the workspace into a clean, frontend-ready backend—without moving anything until we’ve audited and logged it.🟫 Master — Databases Inventory🟫 Master — Views Inventory🟫 Master — Subject SectionsLinked Systems — Planners (Index)Audit Queue
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.
Reference pages (keep as toggles; avoid duplicating text)
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 (toggle below)
Integrated Reconnect Checklist + Phases (toggle below)
Backend Rebuild Changelog (toggle below)
Cleanup Review List — Merge / Rename / Archive / Delete (toggle below)
Exact Duplicates — Verified Delete List (toggle below)
🗑️ Exact Duplicate Pages Queue (database below)
Rules (global + task-specific)
Standing rules — apply to every planner
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 (don’t “just delete” a duplicate section): When two sections/toggles exist for the same topic, do a true merge:
compare both sections line-by-line,
keep one canonical header/toggle,
move any unique lines from the other copy into the canonical one,
then remove only the now-empty duplicate shell.
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
🟫 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.
Task-specific rules (add new rules here, under the task they apply to)
Put new “one-off” rules here so they don’t get duplicated across other sections.
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,
whether it is safe yet.
Progress tracker (subjects × steps)
This is the canonical scoreboard. I will:
Update this section as we complete each step per subject.
Mirror the same status in chat when reporting progress.
Step 1 — Compile / “moving by links”
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)
Added per-subject Review sections (workspace-wide sweep links; link-only, no moves) across all subject pages.
Step 1 addendum — Toggle UX pass (complete)
Products & Inventory
Creative & Production
Templates Reference
Projects & Tasks
Finances (subject page link to finance planner)
Bookings & Scheduling (VIP Events + additional headers toggled)
Services & Content
Dashboards & Analytics
People & Contacts
Documents & Media (nested under top toggle)
Business Planner
Personal Planner (nested under top toggle)
Step 1 addendum — Linked views bundle per database (links only; not started)
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.
Tracking (complete one subject at a time):
Finance
Projects & Tasks
Products & Inventory
Services & Content
Bookings & Scheduling
Dashboards & Analytics
People & Contacts
Creative & Production
Documents & Media
Business Planner
Personal Planner
Templates Reference (started: Quotes)
Step 1 addendum — Populate master inventory databases (complete)
Goal: Copy the inventory structure from each subject page into:
🟫 Master — Databases Inventory (one row per underlying database)
🟫 Master — Views Inventory (one row per view/location reference)
Tracking (complete one subject at a time):
Templates Reference (Quotes added)
Bookings & Scheduling (databases added)
Products & Inventory
Services & Content
People & Contacts
Creative & Production
Dashboards & Analytics
Documents & Media
Business Planner
Personal Planner
Projects & Tasks
Finance
Step 1 addendum — Views Inventory completeness + cleanup review (complete)
Captured all available direct subject-page database/view coverage in 🟫 Master — Views Inventory.
Loaded remaining System Config databases in batches and added non-default views into 🟫 Master — Views Inventory.
Completed workspace-wide scattered linked-view/location sweep for remaining planner, legacy, and duplicate locations.
Bulk-reviewed Needs settings review rows and reduced them to the smallest current true review/manual/UI list.
Preserved true UI/filter/settings review flags instead of clearing uncertain rows.
Step 1 addendum — Normalization / relations pass (complete)
Matched Views Inventory rows to 🟫 Master — Databases Inventory by underlying database link.
Filled Audit Queue subject relation for all Views Inventory rows.
Filled Subject section relation for all Views Inventory rows.
Filled Master database inventory item relation for all Views Inventory rows.
Reconciled unmatched source databases by creating missing Master Databases Inventory rows where needed.
Completed Learning/University, Meal Planner, Weekly Planner, Productivity Planner, Study Room/Winter, Recipe/Kitchen/Meal, Posting Planner, Personal Schedule, Quotes, and remaining legacy clusters.
Verified zero Views Inventory rows still missing the three core relation fields.
Removed the redundant Subject select from the main Views Inventory table display so the relation fields are the working source of truth.
Step 1 addendum — Section pages (toggles → pages) + Master “Subject Sections” database (complete)
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.
Master structure (Option 2):
🟫 Master — Subject Sections: one row per subject section/sub-page.
🟫 Master — Databases Inventory rows point to:
Subject page
Subject section row (so each database is tied to a section sub-page)
🟫 Master — Views Inventory rows point to:
Audit Queue subject page (relation)
Master database inventory item (relation)
Subject section row (relation)
Progress:
Created 🟫 Master — Subject Sections database
Linked Subject Sections ↔ Views Inventory (two-way relation)
Link Subject Sections ↔ Databases Inventory (two-way relation)
Create section sub-pages for each subject (starting with Bookings & Scheduling)
Populate Subject Sections rows (one row per section page)
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
Documents & Media
Business Planner
Personal Planner
Projects & Tasks
Finance
Templates Reference
Step 1 addendum — Clear subject pages after migration (not started)
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).
Keep on each subject page:
A short “This subject is now tracked in the Master inventory” note
Links to: 🟫 Master — Databases Inventory and 🟫 Master — Views Inventory
Tracking (complete one subject at a time):
Finance
Projects & Tasks
Products & Inventory
Services & Content
Bookings & Scheduling
Dashboards & Analytics
People & Contacts
Creative & Production
Documents & Media
Business Planner
Personal Planner
Templates Reference
Later cleanup / technical debt
Remove or retire the redundant Subject select property from 🟫 Master — Views Inventory after confirming the relation-based setup is stable. Source of truth should be the relation fields: Audit Queue subject, Subject section, and Master database inventory item.
Step 2 setup — Exact duplicate linked-view + database merge audit (in progress)
Goal: Reduce manual merge work by identifying what is truly identical before reviewing “similar but not identical” databases later.
For each underlying database, group linked views by exact view name and compare all captured view settings:
view type
displayed properties
filters / advanced filters
sorts
group and subgroup settings
calendar / timeline / map settings
chart / dashboard / form settings
default template
linked location/page
Mark exact duplicate linked views where the only acceptable difference is location/page placement.
For exact duplicate linked views, choose the keeper view/location based on richer page content, cover/photos/media, useful layout, and completeness.
Do not delete linked views yet; produce a clickable review/removal list first for Jillian approval.
For duplicate underlying databases, compare:
schema/properties/property types
relation targets
rollup targets
formulas
options/statuses
views/templates
rows/pages
page content, covers, icons, files, and media
frontend dependencies / Genspark mapping needs
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.
Convert useful linked views into actual views on the keeper database where appropriate, so final planner pages use the canonical database instead of duplicate linked databases.
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 will be handled later under Jillian’s next rules.
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.
Add/confirm a platform/frontend connection mapping property for personal, business, and other subject pages/sections once Jillian sends the Genspark mapping links.
Confirm task/request linkage model: notes/tasks 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.
Step 2 — Merge / consolidate
Finance
Projects & Tasks
Products & Inventory
Services & Content
Bookings & Scheduling
Dashboards & Analytics
People & Contacts
Creative & Production
Documents & Media
Business Planner
Personal Planner
Templates Reference
Step 3 — Final placement into official planner (then LIFE PLANNER)
Finance
Projects & Tasks
Products & Inventory
Services & Content
Bookings & Scheduling
Dashboards & Analytics
People & Contacts
Creative & Production
Documents & Media
Business Planner
Personal Planner
Templates Reference
Cleanup Review List — Merge / Rename / Archive / Delete🧹
This is the cleanup review list. It is 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.
Status
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 names/notes containing ready to archive, DELETE?, dup, merge, official, legacy, and do not delete.
Full schema/view/template/page comparison not completed yet.
Keeper decisions not finalized.
No deletions approved.
No archives approved.
Review rules for this page
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. This does not mean the underlying database should be deleted. The likely final action is to keep one inventory row and remove/merge duplicate inventory rows only after approval.Underlying DBInventory rowsNames foundInitial actionWhyStatus✨Affiliate Statuses (duplicate check)
✨Affiliate Statuses
✨Affiliate Statuses (verify underlying)✨Affiliate Statuses duplicate/check/verify rowsMerge inventory rows laterSame underlying database appears 3 times.Needs approval✨Connected Account Statuses (verify underlying)
✨Connected Account Statuses (dup check)
✨Connected Account Statuses✨Connected Account Statuses duplicate/check/verify rowsMerge inventory rows laterSame underlying database appears 3 times.Needs approval✨Personal File Extensions DatabasePersonal File Extensions Database
✨Personal File Extensions DatabasePersonal File Extensions Database / ✨Personal File Extensions DatabaseMerge inventory rows laterSame underlying database appears twice.Needs approval✨Personal Formats DatabasePersonal Formats Database
Personal Formats DatabasePersonal Formats DatabaseMerge inventory rows laterSame underlying database appears twice.Needs approval✨Personal Finance Database✨Personal Finance
✨Personal Finance✨Personal FinanceMerge inventory rows laterSame underlying database appears twice.Needs approval✨Personal Habits✨Personal Habits (dup check)
✨Personal Habits✨Personal Habits / ✨Personal Habits dup checkMerge inventory rows laterSame underlying database appears twice.Needs approval✨Referral Statuses (verify already added)
✨Referral Statuses✨Referral Statuses verify/already addedMerge inventory rows laterSame underlying database appears twice.Needs approval🌿Habit Tracker (merge)🌿 Habit Tracker (merge)
🌿 Habit Tracker (merge) (dup check)🌿 Habit Tracker (merge) / dup checkMerge inventory rows later; database itself still needs merge reviewSame underlying database appears twice, and the DB label also says merge.Needs comparison
B. Ready-to-archive / DELETE? / label-warning candidates
These need verification before the label is trusted. If the label is wrong, the action is rename/remove the warning label, not archive/delete.ItemSubjectCurrent label signalInitial actionWhyStatus✨Formats Database (DELETE?)Documents & MediaDELETE?Compare against Personal Formats / canonical Formats before decidingPrevious setup label may be outdated. Need concept + schema + rows comparison.Needs comparisonService Formats (ready to archive)Services & Contentready to archiveCompare against other Formats hubs before decidingCould be domain-specific service format or true duplicate; do not assume.Needs comparisonMusic (ready to archive)Personal Plannerready to archiveLikely rename/remove label unless proven duplicateInventory note says this is a page hub, not necessarily a database.Needs reviewReading & Entertainment (ready to archive)Personal Plannerready to archiveLikely rename/remove label unless proven duplicateInventory note says page hub captured for inventory, not necessarily a database.Needs reviewCourse 1 (ready to archive)University & Educationready to archiveCompare with Course 1 and CoursesMay be mislabeled; must verify pages/properties/views/templates.Needs comparisonFinal Exam (ready to archive)University & Educationready to archiveCompare with Final ExamMay be mislabeled; must verify pages/properties/views/templates.Needs comparisonMidterm 1 (ready to archive)University & Educationready to archiveCompare with Midterm 1May be mislabeled; must verify pages/properties/views/templates.Needs comparisonMidterm 2 (ready to archive)University & Educationready to archiveCompare with Midterm 2May be mislabeled; must verify pages/properties/views/templates.Needs comparison
C. Merge-review candidates
These appear to need true schema/data comparison, not just inventory row cleanup.Candidate groupItemsInitial actionWhyStatusHealth / habit trackersHealth Tracker (review for merge)
🌿 Habit Tracker (merge)
Weekly Habits Tracker (merge and keep DB)
✨Personal HabitsCompare concepts and lifecycle before mergingSome may track daily logs, some habit definitions, some weekly checklists. Same area does not mean same database.Needs comparisonPeople / personal people✨Personal People Database merge with (💫💫💫People) and People & Contacts keepersCompare against canonical People/Contacts database(s)Could be personal contact subset, gift recipient list, or true duplicate. Need relations/content review.Needs comparisonFormats✨Formats Database (DELETE?)
Personal Formats Database
Service Formats (ready to archive)Determine global vs domain-specific“Format” may be shared globally or may differ by documents, personal media, services/content.Needs comparisonEmail templates/categoriesDocuments & Media Email Templates/Categories and Services & Content Email Templates/CategoriesCompare meaning and frontend usageSame labels across subjects may be shared template infrastructure or different workflow contexts.Needs comparisonShot ListShot List and Shot ListCompare before merging; likely separate concepts unless proven sameOne is Creative & Production, one is Bookings & Scheduling. Same name may represent different workflow surfaces.Needs comparisonUntitled Booking DBs✨Countries linked view wrapper and ✨US States linked view wrapperLoad underlying databases and rename/compareSame blank label but different underlying links. Need identity and purpose check.Needs load/rename
D. Protected / do-not-delete signals
These should stay protected until reviewed. Do not delete simply because they look like duplicates.
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. Next comparison batches
Recommended order:
Same-underlying inventory duplicates — safest, because they are inventory row duplicates, not database duplicates.
University & Education ready-to-archive pairs — likely label-risk and easier to compare within one subject.
Formats group — important global-vs-domain taxonomy decision.
Health / habit trackers — merge-sensitive because logs and definitions may differ.
People / Personal People — merge-sensitive due to contacts, gift recipients, and frontend/person semantics.
Email templates/categories — decide shared template hub vs subject-specific.
Shot List and untitled Booking DBs — compare after loading underlying structures.
F. Approval status
The confirmed exact-duplicate cleanup above has been executed. No broader similar-but-not-identical merge/delete/archive work is approved yet.
F1. Comparison findings — University & Education ready-to-archive batch
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)Course 1Schema, view, and visible rows match. Assignment, Final Exam, Midterm, Participation, and Quiz rows match by title/date/grade/weighting. Loaded page contents matched for the checked rows, including the essay/callout content on Final Exam.Archive/delete candidate only after Jillian approves. Keep Course 1 as likely keeper.Pending approvalFinal Exam (ready to archive)Final ExamSchema, view, visible Topic A/B/C rows, checkbox values, priority values, and loaded page contents match.Archive/delete candidate only after Jillian approves. Keep Final Exam as likely keeper.Pending approvalMidterm 1 (ready to archive)Midterm 1Schema, view, visible Topic A/B/C rows, checkbox values, priority values, and loaded page contents match.Archive/delete candidate only after Jillian approves. Keep Midterm 1 as likely keeper.Pending approvalMidterm 2 (ready to archive)Midterm 2Schema, view, visible Topic A/B/C rows, checkbox values, priority values, and loaded page contents match.Archive/delete candidate only after Jillian approves. Keep Midterm 2 as likely keeper.Pending approval
Important: These four are candidates only. I have not archived or deleted anything.
F2. Comparison findings — Formats group
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 Resolution Presets, Container, Default Export Settings, Delivery Requirements, Deliverables, Deliverable Types, and Deliverables Status Flow.Do not delete based on the DELETE? label. Likely keep or rename as a canonical Documents/Media Formats hub unless a better global file-format keeper exists.Not approvedPersonal Formats Database✨Formats Database (DELETE?)This is a much simpler personal file-format database with Format Name, Description, File Extension, and Note. It points to Personal File Extensions.Potential merge/mirror into a broader canonical file-format hub, but only after row comparison and relation mapping. Do not delete yet.Not approvedService Formats (ready to archive)✨Formats Database (DELETE?)
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 Used in Requests, Interaction Styles, Scene Types, Duration, Quantity, Active, Featured, and Average Price.Remove “ready to archive” label unless a true service-format keeper exists. Do not merge into file/document formats just because the label says “Formats.”Not approved
Conclusion: The Formats group contains at least two different concepts: file/media formats and service/request formats. The “DELETE?” and “ready to archive” labels are not enough to delete/archive anything here.
F3. Comparison findings — Health / habit tracker group
Status: Compared at schema and row-count level. No deletion or archive approved.CandidateRow countFindingsRecommendationApproval statusHealth Tracker (review for merge)51Daily health log / stats database. Tracks Date, mood, anxiety, depression, sleep, symptoms, medications, week/month stats, and habit checkboxes.Keep as a health/daily log candidate. Do not merge directly into Personal Habits; it represents logged daily records, not habit definitions.Not approved🌿 Habit Tracker (merge)5Simple weekly habit checkbox grid with weekday checkbox columns and multiple week views. Same underlying DB is duplicated in inventory by 🌿 Habit Tracker (merge) (dup check).Inventory duplicate can be merged later. Database itself may be legacy/simple tracker, but not safe to delete until rows are reviewed against the keeper.Not approvedWeekly Habits Tracker (merge and keep DB)0Weekly habit template/checklist database with Habit 1–10 checkboxes, Progress formula, and a default template. Empty row count, but it may still have useful template/view structure.Potential template/structure keeper or template source. Do not delete until template value is checked and/or mirrored.Not approved✨Personal Habits3Structured habit-definition database with relations to Status, Frequency, Goal, Habit Logs, Dashboard, and rollups/formulas for streak/completion/status.Likely canonical habit-definition keeper. It should not absorb daily health logs unless a relation-based model is designed.Not approved
Conclusion: These are related but not identical. The likely model is Personal Habits = habit definitions, Health Tracker = daily health log, and simple/weekly trackers need row/template review before deciding whether to mirror, merge, or retire.
F4. Comparison findings — Email templates/categories
Status: Compared at schema and row-count level. No deletion or archive approved.CandidateRow countFindingsRecommendationApproval statusServices & Content ✨Email Templates0Template database with Name, Active, Subject, Body, Category/Tags legacy fields, and relation-backed Category/Tags fields.Could be mirrored/merged into a shared email template hub later, but currently empty. Do not delete without approval.Not approvedDocuments & Media ✨Email Templates0Template database with Name, Active, Subject, Last Used, Open Rate, Category legacy field, and Category relation.Could be mirrored/merged into a shared email template hub later, but schema differs from Services templates. Do not delete without approval.Not approvedServices & Content / Documents & Media Email Template Categories0 / 0Both category databases are empty and share the simple Category title structure, but they are separate underlying databases.Likely candidates for one shared Email Template Categories hub if email templates become global. Needs approval before any row/property consolidation or deletion.Not approved
Conclusion: These are empty but not automatically deletable. If email templates are intended to be global, use one shared template/categories hub; if they serve different workflows, keep separate and rename clearly.
F5. Comparison findings — Shot List group
Status: Compared at schema, view, row-count, and row-content level. No deletion or archive approved.CandidateRow countFindingsRecommendationApproval statusShot List1Richer creative shot-planning DB. Has relations for Chapter, Tags, Shot, FPS, and Location in addition to legacy select/multi-select fields. The one row contains a real shot: “Drone shot of the mountains, wide angle, 45mm lens, Mavic 3 pro” with A-Roll, Wide, 100 FPS, Alps, and comments.Likely keeper for creative shot planning.Not approvedShot List1Similar shot-list structure but fewer relation-backed taxonomy fields. Its one row is blank and has no page content.Possible archive/delete candidate only after confirming it is not used as a required layout/view surface. Could also be replaced by a linked view of the creative keeper later.Pending approval
Conclusion: These are same-label but not equal-value. Creative Shot List appears to be the better keeper because it has the richer schema and the real row.
F6. Comparison findings — Untitled Booking DBs
Status: Loaded, identified, and renamed inventory rows. No deletion/archive approved.Former labelResolved nameFindingsRecommendationApproval status✨Countries linked view wrapper✨Countries linked view wrapperWrapper database has an empty owned Countries source and a linked view of canonical Countries.Keep as linked-view wrapper or replace with a cleaner linked view later; do not delete without approval.Not approved✨US States linked view wrapper✨US States linked view wrapperWrapper database has an empty owned US States source and a linked view of canonical States.Keep as linked-view wrapper or replace with a cleaner linked view later; do not delete without approval.Not approved
Conclusion: These were not true unnamed content databases; they are linked-view wrappers for canonical geography hubs. I renamed the inventory rows so they are no longer ambiguous.
F7. Comparison findings — Personal People vs Contacts
Status: Compared at schema and row-count level. No deletion/archive approved.CandidateRow countFindingsRecommendationApproval status✨Personal People Database merge with (💫💫💫People)9Personal/gift-recipient style people database with rows such as Babe, Braelyn, Harper, Isabella, Me, Merissa, Mom, N/A, Summer. Schema includes Birthday, Address text, Type, Gift, Gift Receipts, Personal Wishlist, Professional Wishlists, Task, and Total Gifts Given.Do not directly delete. Likely needs migration/mirroring into the canonical Contacts/People system while preserving gift/wishlist recipient semantics.Not approved❓✨Contacts Database16Broader contact database with Contact Name, Company, Person, Role, Email, Phone, Address, Agent, Bookings, Customer Roles, Creator Roles, Invoices, Projects, Talent, Venues, and income/address relations.Likely broader canonical contact keeper, but many rows appear blank or placeholder. Needs row-by-row review before merging Personal People into it.Not approved
Conclusion: Personal People is not an identical duplicate. It appears to represent personal people / gift recipients, while Contacts is broader operational contacts. Merge requires preserving personal/gift/wishlist relationships, not simply deleting one database.
F8. Comparison findings — same-underlying inventory-row duplicates
Status: Reviewed as inventory-row duplicates. These point to the same underlying database links, so they are not database-delete candidates. No deletion/archive approved.Underlying databaseLikely canonical inventory rowDuplicate / review rowsRecommendationApproval status✨Affiliate Statuses✨Affiliate Statuses (duplicate check)
✨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✨Connected Account Statuses✨Connected Account Statuses (dup check)
✨Connected Account 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✨Personal File Extensions Database✨Personal File Extensions DatabasePersonal File Extensions DatabaseKeep the more specific titled row with the sparkle/canonical naming; merge any notes/relations from the plain duplicate row later if needed.Not approved✨Personal Formats DatabasePersonal Formats DatabasePersonal Formats DatabaseRows have the same displayed name and same underlying link. Choose one inventory row later after checking relation completeness; do not delete yet.Not approved✨Personal Finance Database✨Personal Finance✨Personal FinanceRows have the same displayed name and same underlying link. Choose one inventory row later after checking relation completeness; do not delete yet.Not approved✨Personal Habits✨Personal Habits✨Personal Habits (dup check)Keep the clean canonical inventory row; duplicate-check row can only be removed during final approved cleanup after preserving any notes/relations.Not approved✨Referral Statuses✨Referral Statuses (verify already added)Keep the clean canonical inventory row; duplicate verification row can only be removed during final approved cleanup after preserving any notes/relations.Not approved🌿Habit Tracker (merge)🌿 Habit Tracker (merge)🌿 Habit Tracker (merge) (dup check)Inventory rows point to the same habit-tracker database. Database-level merge review remains separate; duplicate inventory row can only be removed during final approved cleanup.Not approved
Conclusion: These are inventory cleanup candidates, not database deletion candidates. The likely future action is to merge/remove duplicate inventory rows after approval, while keeping the underlying databases untouched unless separately approved.
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 table view, same one placeholder meal row.Duplicate database candidates after approval.Thursday meal planner
Same schema, same table view, same one placeholder meal row.Duplicate database candidates after approval.Friday meal planner
Same schema, same table view, same one placeholder meal row.Duplicate database candidates after approval.Saturday meal planner
Same schema, same table view, same one placeholder meal row.Duplicate database candidates after approval.Sunday meal planner
Same schema, same table view, same one placeholder meal row.Duplicate database candidates after approval.Grocery’s
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:
Affiliate Statuses
Connected Account Statuses
Personal File Extensions
Personal Finance
Personal Habits
Referral Statuses
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.
Same-title pages such as To do still and Calendar organization still need property/content comparison before any cleanup.
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
Dashboards & Analytics: add sections (Dashboards, Analytics, OKRs, Taxonomy); file DBs accordingly; add (NEW) headers where needed
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.
Remaining
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.
Remaining
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
Completed from Reconnect Map
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.
Remaining
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
Completed from Reconnect Map
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.
Remaining
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
Remaining
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
Remaining
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
Connection Blueprint
Forms 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.
Blocked address-like source logged for later access follow-up.
Finance
Finance sign convention and refund policy implemented.
Finance dashboards converted to system fields.
Legacy subscriptions migrated into canonical Subscriptions Database.
Legacy income migrated into canonical Income Database.
Many legacy expenses/income rows migrated into canonical finance keepers.
Migrated legacy rows were archived in source databases to prevent future edits.
Planner consolidation / master inventory
Master inventory databases created under 🟫🟫 Workspace Planner Consolidation — Master Plan (1) - Backup for Restructure in case anything ends up broken.
Subject Sections relation created.
All current database inventory rows linked to Subject Section homes.
All “(Unnamed…)” inventory rows resolved by loading underlying database names.
All subject pages in the audit queue marked reviewed for the database-home pass.
Pending / not final yet
Full Master Views Inventory population.
Cleanup candidate approval list.
Duplicate/merge comparison pass.
Ready-to-archive verification pass.
DELETE? label review pass.
Taxonomy/config duplicate sweep continuation.
Address normalization continuation for remaining accessible databases.
Blocked legacy address source follow-up.
Remaining legacy finance database review.
Final frontend reconnect delta list.
Final deletion/archive approval and execution.
Blocked / needs access
Blocked legacy Address-like data source: New database
Follow-up after access:
identify every relation pointing to it,
repoint to canonical ✨Addresses Database where appropriate,
preserve legacy fields,
do not delete anything without approval.
Latest merged update
Genspark Reconnect Map content was reorganized under the Master Plan into:
Operating Standards,
Integrated Checklist + Phases,
Backend Rebuild Changelog.
The original Genspark Reconnect Map remains as a historical source page unless Jillian later approves archival.
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)
Projects Database (Projects Database)
• 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<empty-block/> 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<empty-block/> 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<empty-block/> 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<empty-block/> 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<empty-block/> 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<empty-block/> 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)
Next in audit
Booking Types
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)
Canonical checkbook sign convention + refund system implemented (Net Spend / Ignore refunds policy). (Source: Convo 3 Part 1–3 + Finance System Spec)
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).
Connection Blueprint notes (how to use it during re-org)
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 more legacy “Subscription” placeholder rows (dates: 2026-05-01, 2026-06-01, 2024-06-01, 2024-01-01; amounts blank) 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: 2024-04-01, 2024-02-01, 2024-11-01, 2024-05-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 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 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 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 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 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)
— 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) — 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)
Next in audit
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: 🟫 <Name> (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:
🟫 Month breakdown (by Date)
🟫 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)
Income
🟫 Needs classification (Transaction Type empty) should trend toward zero (now 0)
C) Canonical sign checks (ongoing guardrails)
Expenses
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)
Income
Transaction Type = 🟢 Income ➝ Amount should be positive (0 violations)
Transaction Type = 🔁 Refund ➝ 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)
Expenses:
Transaction Type empty: 0
Category missing: 0
Subcategory missing: 0
Income:
Transaction Type empty: 0
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 🟫 <Name> (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
Groceries
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
Subscriptions
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
Net Spend (default)
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
Groceries
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
Subscriptions
Tuition Fees
Utilities
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)
Income
Aligned Transaction Type to include 🔁 Refund (kept for future unified Transactions compatibility)
Categories
Added 🟫 Refund policy
Added rollups:
🟫 Total Spent (gross)
🟫 Total Refunded
🟫 Net Spend
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)
Keep Income/Expenses as separate ledgers for now, but plan migration to Transactions views later.
Appendix — Wishlist Purchased → Expenses (future planner rule)
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)
🗂️ Linked Index — All Planners & Databases (Inventory Only)
Inventory only — do not move anything yet
This page is a read-only-style index of planners + databases across the workspace using linked views.
Linked views
Systems (all planners)
FINAL PLANNER hub
LIFE PLANNER hub (reference only; no edits)
Database home mapping (no new pages)
Use this as a move checklist (move each database block into the existing “home” page listed in the right column). If there is no dedicated home page, leave the database on the subject page.
Phase 1 — Finance sweep (capture candidates before moving)
Primary Finance hub/pages (FINAL PLANNER)
💰Finances (canonical Finance hub)
Finances (hub)
finance planner (keep for visual layout)
Finance subpages spotted (inside finance planner page)
Savings Tracker
Debt Tracker
Subscription Tracker
Annual Metrics (ready to archive)
Company Database
Customer Database (ready to archive)
Item Inventory Tracker (ready to archive)
Core embedded databases spotted (inside finance planner page)
(pinned view)
(pinned view)
Untitled (callout view)
Untitled (Monthly overview dashboard — Monthly Overview)
Untitled (Monthly overview dashboard — Yearly Overview)
Subscriptions (embedded DB block)
Subscriptions A (Legacy — Do Not Use) (embedded DB block)
✨Subscriptions Database
Subscription (Legacy — Do Not Use) (embedded DB block)
Categories (Budget Template) (embedded DB block)
Type (Budget Template) (embedded DB block)
Accounts (Accounts view placeholder)
Untitled (Accounts pinned view)
Categories (Expense Categories view)
Untitled (Income + Expenses combined view)
Untitled (Categories view — Subscriptions filtered)
Month View
Untitled (Annual Goals view)
Untitled (Recent expenses view)
Untitled (Monthly/Weekly expense boards)
Profile (embedded DB block)
Year (embedded DB block)
(Monthly Income gallery — 🟢 Income only)
(Monthly Expense gallery — ⭕️ Expense only)
Subcategories
Legacy/secondary finance pages spotted (to 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
Subject sweep index (links only — no moves)
Use this section to review all “hub pages” + standalone database pages found during the workspace-wide sweep, grouped by subject.
Projects & Tasks
Subject page: 📁Projects & Tasks
Intended planner candidate: projects planner
Other hubs / DB pages found elsewhere:
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 / DB pages found elsewhere:
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 elsewhere:
posting planner
Content Hub
Media Library (LIFE PLANNER ▸ Databases ▸ Learning)
Review list:
✨Community Events
✨Marketplace Listings
✨Content Calendar
✨Content Database
✨Content Scheduling
Bookings & Scheduling
Subject page: 📅Bookings & Scheduling
Hubs found elsewhere:
✨Booking Calendar (systems page)
Events (LIFE PLANNER ▸ Productivity)
Review list:
Booking Request & Availability System — Plan
Calendar
Personal Schedule
Dashboards & Analytics
Subject page: 📈Dashboards & Analytics
Hubs found elsewhere:
Master Dashboard Page
OTHER DASHBOARDS
Review list:
OKRs
Active Brain
People & Contacts
Subject page: 👥People & Contacts
Hubs found elsewhere:
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 elsewhere:
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 elsewhere:
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 elsewhere:
🤎work planner —
Indulgon Social Media
Review list:
Freelance Business —
Untitled (Gain business insights)
Content Hub
Personal Planner
Subject page: 👤Personal Planner
Hubs found elsewhere:
Master Dashboard Page
home planner
travel planner
Review list:
meal planner
〰️reads
Templates Reference
Subject page: 🎨Templates Reference
Hubs found elsewhere:
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