Doc 3 — Workspace Planner Consolidation — Annotated Merge

Structure from Doc 2. Each line annotated to show its merge status. Yellow sections = unique content added from Doc 1.

Color key:
COVERED — same content in both docs, kept once
EXPANDED — Doc2 is superset of Doc1 version; unique Doc1 detail added to Doc3
NEW IN DOC2 — only exists in Doc2, no Doc1 equivalent
NEEDS CHECK — may have Doc1 content not yet confirmed merged

Yellow highlighted sections = content added from Doc 1 that was not in Doc 2

DOC 2 BASE — every line annotated

Start here
Both docs have identical 'Start here' header
What this page is: A live master plan + handoff doc for consolidating the workspace safely. It is both a policy/runbook and an execution log for database/planner consolidation, cleanup review, taxonomy normalization, finance cleanup, and frontend ↔ backend reconnect work.
Doc2 expands 'What this page is' — adds 'policy/runbook' and 'execution log' detail. Doc1 says 'live master plan + handoff doc'. Superset kept.
How to use it: Start here first, work only from ✅ NEXT ACTIONS / Master Checklist, and use Navigation map / Reference library for evidence, source material, databases, specs, cleanup lists, changelogs, and source references.
Doc2 expands 'How to use it' — adds 3-toggle structure. Doc1 just says 'Work from NEXT ACTIONS only'. Superset kept.
Do-not-touch rule: The “Exact Duplicates — Verified Delete List” section is formatting-fragile in the source page; do not rewrite its internal formatting unless explicitly requested.
Do-not-touch rule is identical in both docs.
Scope / goal
Scope / goal header — identical in both docs.
Clean up and consolidate Notion workspace databases + planners, then ensure platform frontend ↔ Notion backend routing stays correct after moves/renames, with bidirectional syncing.
Scope text is identical in both docs.
Mission
'Mission' section is NEW — only in Doc2. Not in Doc1.
Build one clean, frontend-ready workspace backend without losing useful content, breaking existing planner layouts, deleting unapproved items, or disconnecting platform routes/forms/dashboards from the correct Notion sources.
Mission text is NEW — only in Doc2.
Guiding principles / standing rules
Doc2 renames 'Standing rules' → 'Guiding principles / standing rules'. Same rules, better organized. Doc1 has same rules scattered across Rules toggle.
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.
Inventory-first: Compile same/similar pages and databases with links first. Do not move, delete, or merge until inventory and dependency context is visible.
Keeper-first: Choose the keeper before merging. Improve the keeper first, then migrate or mirror useful content into it.
Labels are signals, not decisions: “ready to archive,” “DELETE?,” “dup check,” “merge,” “official,” “keeper,” and “do not delete” are review labels only.
Soft-retire before delete: Legacy items stay until dependency sweep, data migration, frontend reconnect, and verification are complete.
Preserve UX, layouts, content, and media: Preserve useful planner layouts, linked views, page contents, covers, icons, files, templates, comments where available, and meaningful media.
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 reconnect is ready.
Master inventory is source of truth: Use the Master Databases Inventory, Master Views Inventory, and Master Subject Sections databases as the working source of truth.
Brown-square keeper marker: Confirmed keeper pages/databases use the brown-square keeper convention until the final icon pass.
True merge / dedupe standard
Doc2 adds 'True merge / dedupe standard' as its own section. Doc1 has this buried inside Standing rules as one rule. Superset version in Doc2 kept.
Treat every old section as if it was “floating,” assign it to one of the three top-level toggles, and merge it into the matching canonical section.
Compare duplicate/similar sections line-by-line.
Keep one canonical header/section.
Keep unique lines.
For exact duplicate lines, keep only one copy.
For partial duplicates where one line is a subset of another, keep the fuller/superset version and add only the missing unique part if needed.
Example: “apple” + “apple” = keep one “apple.”
Example: “apple and banana” + “apple and banana and lime” = keep “apple and banana and lime.”
Example: same base task + extra status/detail/date/context = keep the more complete version and merge any missing useful detail into it.
Update checked/unchecked status so the canonical checklist is accurate.
Remove only the now-empty duplicate shell.
Do not delete unique content just because the heading was duplicated.
Timestamp rule for tasks going forward
Doc2 expands timestamp rule — adds 'Do not invent timestamps' line. Doc1 has only 2 lines. Doc2 superset kept.
Format: (added: YYYY-MM-DD h:mm AM/PM ET; done: YYYY-MM-DD h:mm AM/PM ET).
When a task is completed, add a done: timestamp on the same line when checking it off.
Do not invent exact timestamps for historical completed work. If the old page already has a timestamp, preserve it; otherwise leave historical items untimestamped or label them as historical only when needed.
Operating standards — how work must be done
Doc2 merges Operating Standards into single-line format per rule. Doc1 has each rule as multi-line toggle. Same content, Doc2 is more readable. UNIQUE Doc1 detail: 'Examples of likely global hubs: Platforms, Addresses...' list — added to Doc3.
Global hubs only when the concept is truly shared: Platforms, Addresses, Cities, States, Countries, and truly shared categories/types/tags can be canonical global hubs.
Do not consolidate just because labels match: 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 select/multi-select/text-option/relation/rollup/formula setup, convert option-like fields to relation-backed fields where appropriate, preserve legacy fields until reconnect is stable, and update views after renames.
Ready-to-archive rule: A database is only safe to archive if a keeper exists, all needed properties/settings/rows/views/templates/content/media are preserved or migrated, relations/rollups/formulas still work, and Jillian approves the exact archive/delete list.
Duplicate database merge rule: Compare purpose, schema, properties, relation targets, rollups, formulas, options, templates, views, rows/pages, page content, covers, icons, files, media, and frontend dependencies before any duplicate is retired.
Identical duplicate rule: A possible duplicate can be deleted only if it is confirmed identical or fully migrated and no frontend dependency remains.
Address normalization standard: Operational databases should point to the canonical Addresses database; City/State/Country/ZIP should not remain long-term free text/select when structured reusable relations are intended.
Closet / owned item lifecycle standard: Physical items should be trackable from acquired → owned/in closet → packed/used/listed → sold/donated/archived, tied to purchases, sales, events, schedule blocks, customer requests, and inventory where applicable.
Frontend reconnect governance: Any database/property renamed, replaced, merged, or made canonical must be logged, legacy references preserved until reconnect is stable, reconnect mapping updated, and routes/forms/dashboards verified before legacy removal.
Permission-blocked items: Log as blocked, do not make destructive assumptions, do not delete/archive related items, and revisit after access is available.
Frontend ↔ backend audit logic
'Frontend ↔ backend audit logic' section is NEW — only in Doc2. Not in Doc1 as own section.
Frontend ↔ backend audit and gap logic belong together in one canonical section.
Compare the platform blueprint/schema/routes/forms/connection docs against current canonical Notion databases.
Build a reconnect delta list showing old DB/property, new canonical DB/property, affected feature/route/form, migration note, and status.
Confirm no frontend references point to deleted or legacy databases before final cleanup.
Product intent — unified personal + business operating system
'Product intent' section is NEW — only in Doc2. Not in Doc1.
The backend should support one day-in-the-life operating model across personal + business work.
Today surfaces should be able to connect tasks, schedule blocks, events, expenses, income, sales, subscriptions, purchases, inventory, wishlists, closet items, bookings, customer requests, and content work.
Finance, commerce, scheduling, inventory, and customer-request routing should remain connected through canonical databases and relation-backed taxonomy.
✅ NEXT ACTIONS / Master Checklist
Use this as the only “what do I do next?” checklist. Add new tasks here the moment they are discovered, check them off when finished, and add timestamps per the Start here rule.
Doc2 renames to 'NEXT ACTIONS / Master Checklist'. Doc1 has same section as 'NEXT ACTIONS (single source of truth)'. UNIQUE in Doc1: 3 specific current tasks ('Decide canonical Next Actions flow', 'Finish Views Inventory', 'Build next approval batch') + 2 always-on rules. These are OLDER tasks — added to Doc3 as historical context.
Current next actions
Continue workspace-wide page/bookmark duplicate sweep beyond the first exact-empty batch. (added: 2026-06-21 10:45 PM ET)
Build the next approval-ready cleanup batch with clickable keeper/delete/archive decisions and reasons; no deletions before approval. (added: 2026-06-21 10:45 PM ET)
Continue similar-but-not-identical database merge review after exact duplicates, preserving unique rows/properties/views/templates/content/media first. (added: 2026-06-21 10:45 PM ET)
Continue taxonomy/config duplicate sweep and confirm global-vs-lifecycle-specific taxonomy hubs. (added: 2026-06-21 10:45 PM ET)
Continue frontend reconnect delta list after Genspark/platform mapping links are available. (added: 2026-06-21 10:45 PM ET)
Done / completed work
Inventory and section structure
Doc2 'Done / completed work' is a reorganized + expanded version of Doc1's Progress tracker (lines 168-359). Doc2 is superset — combines Step 1 addendums into clean checkboxes. UNIQUE in Doc1: detailed step-by-step addendums (Linked views bundle, Populate master inventory, Views Inventory completeness, Normalization pass, Section pages, Clear subject pages) with per-subject tracking. Added to Doc3.
Master inventory databases created.
Master Subject Sections database created.
Subject section relations created between Master Databases Inventory, Master Views Inventory, and Master Subject Sections.
Every captured database inventory row has a Subject Section relation.
All “(Unnamed…)” database inventory rows resolved using underlying database names.
Direct subject-page database/view coverage captured in Master Views Inventory.
Workspace-wide scattered linked-view/location sweep completed for remaining planner, legacy, and duplicate locations.
Views Inventory relation normalization completed: Audit Queue subject, Subject section, and Master database inventory item filled.
Zero Views Inventory rows remain missing the three core relation fields.
Cleanup / duplicate review
Initial cleanup candidate scan completed from Master Databases Inventory.
Duplicate inventory-row groups found by repeated underlying database link.
Label-based review candidates found from ready-to-archive, DELETE?, dup, merge, official, legacy, and do-not-delete signals.
First-pass comparison findings added for University & Education, Formats, Health/Habits, Email Templates, Shot List, Untitled Booking wrappers, Personal People vs Contacts, and same-underlying inventory-row duplicates.
Exact duplicate linked-view comparison pass completed.
Exact duplicate Weekly Planner Duplicate 1–5 databases removed after confirmation.
Same-underlying inventory-row duplicate groups cleaned after confirmation while keeping active underlying databases.
Email template/categories duplicate cleanup executed after preserving keeper fields.
Shot List duplicate cleanup executed after preserving useful Booking Location relation.
First exact-empty page/bookmark duplicate batch completed.
Backend / reconnect / taxonomy / finance
Genspark reconnect material reorganized into operating standards, integrated checklist/phases, and changelog source material.
Platforms, Cities, States, Countries, Addresses, and Statuses canonical hubs documented.
Address normalization standard documented.
Global-vs-lifecycle-specific taxonomy rule documented.
Customer Requests relation replacements and content modeling decisions documented.
Scheduling canonical stack documented: Booking Calendar, Availability, Unified Schedule.
Unified personal + business day-in-the-life intent documented.
Finance sign convention and refund policy implemented.
Legacy subscriptions and legacy income migrated into canonical keepers.
Remaining work
Cleanup review / merge / consolidation
Doc2 'Remaining work' combines Doc1's Step 2/3 + Execution phases + Integrated Reconnect Checklist. UNIQUE in Doc1: full Execution phases (Phase 0-5), full Integrated Reconnect Checklist with detailed phase tracking, detailed Step 2 setup checklist. Added to Doc3.
Continue workspace-wide page/bookmark duplicate sweep for non-empty and same-title pages.
Compare remaining duplicate/similar database clusters by schema, relation targets, rollups, formulas, options, views, templates, rows/pages, page content, covers, icons, files, media, and frontend dependencies.
Choose keepers only after comparison.
Add missing useful schema/views/templates to keepers before retiring duplicates.
Move or mirror unique rows/pages/content/media into keepers.
Convert useful linked views into actual views on keeper databases where appropriate.
Produce approval list before any archive/delete.
Subject pages / planner structure
Clear remaining subject pages into lightweight references after inventory is fully captured.
Finish structural-page UI hygiene sweep: Operational, Taxonomy/Config, Dashboards/Reports, Protected Legacy, Review, Cleanup Queue.
Continue final planner placement after merge/consolidation.
Taxonomy/config and address normalization
Continue taxonomy/config duplicate sweep.
Confirm every taxonomy hub that should be global is global.
Confirm lifecycle-specific taxonomies stay separate and are named clearly.
Continue address normalization sweep for accessible databases.
Revisit blocked legacy address-like source when access is available.
Finance
Identify remaining legacy embedded finance databases with unique rows.
Migrate unique finance rows into canonical keepers.
Only archive/delete legacy finance databases after confirmation and reconnect verification.
Frontend reconnect
Compare Connection Blueprint property maps against current canonical Notion databases.
Build Reconnect Delta List: old DB/property, new canonical DB/property, feature/route/form affected, migration note, status.
Verify every route/form/dashboard connects to canonical Notion sources.
Confirm no frontend references point to deleted or legacy databases.
Handoff final reconnect packet to Genspark.
Blocked / needs access
Extract “rules / instructions / steps” from Convo 1–3 PDFs and convert from chat-format into clean rules + tasks.
Blocker: attachments were flagged as potentially risky / not viewable in the prior pass.
Revisit blocked legacy Address-like data source when access is available.
Add/confirm frontend/platform mapping fields for subject pages/sections after Jillian sends or confirms Genspark mapping links.
Verification checklist
Verify Master Databases Inventory, Master Views Inventory, and Master Subject Sections still agree after each cleanup batch.
Doc2 'Verification checklist' is NEW as own section. Doc1 has verification items scattered across phases. Superset kept.
Verify no stale Views Inventory references point to deleted duplicate inventory rows.
Verify no duplicate linked-view groups remain after each exact duplicate pass.
Verify no repeated underlying database links remain in Master Databases Inventory after same-underlying row cleanup.
Verify keeper databases contain all useful fields/views/templates/rows/content/media before any duplicate is retired.
Verify frontend reconnect before deleting or archiving legacy sources.
Navigation map / Reference library
Use this as the map/reference library. The canonical rules are in Start here and the canonical tasks are in NEXT ACTIONS. Source details, database blocks, and evidence remain in the duplicate backup page and should be pulled into this reference library in true-merge passes as needed.
Databases for planning
Doc2 'Navigation map' is cleaner reorganization. UNIQUE in Doc1: full Backend Rebuild Changelog (50 lines), full Cleanup Review List (A-G sections with F1-F8 comparison findings), full Exact Duplicates Verified Delete List, Finance Planner Master Plan, full Linked Index, Integrated Reconnect Checklist details. All added to Doc3.
🟫 Master — Databases Inventory
🟫 Master — Views Inventory
🟫 Master — Subject Sections
Linked Systems — Planners (Index)
Audit Queue
Main reference groups
Cleanup Review List → comparison findings, approval gating, exact duplicate audit findings, merge/archive/delete evidence.
Exact Duplicates — Verified Delete List → formatting-stable exact delete/keep pairs; do not reformat internally unless explicitly requested.
Backend Rebuild Changelog → backend changes, completed migrations, reconnect notes, blocked items, high-impact historical changes.
Taxonomy & Config → taxonomy/config lists, canonical global hubs, address normalization, global-vs-lifecycle-specific taxonomy reference.
Dashboards & Reports → reporting surfaces and dashboard/analytics reference.
Protected Legacy → protected/do-not-delete sets and legacy removal references.
Finance reference/spec → finance canonical semantics, refund policy, finance verification source material, finance refactor notes.
Linked Index → all-planners/databases inventory-only reference index.
Source archive / prior structure
Original duplicate backup page: 🟫🟫 Workspace Planner Consolidation — Master Plan (1) - Backup for Restructure in case anything ends up broken
Use the original duplicate as the preserved source archive for full legacy detail, then true-merge source sections into this page only when needed.
If moving archive material into this page later, keep it under this Navigation map toggle, not as new top-level toggles.

UNIQUE CONTENT FROM DOC 1 — added to Doc 3 (not in Doc 2)

Everything below was in Doc 1 but not covered by Doc 2. Organized by section.

SECTION: Start here / Setup (10 lines)
What this page is: A live master plan + handoff doc for consolidating the workspace safely (inventory-first, keeper-first, no destructive actions with
How to use it: Work from NEXT ACTIONS only. Everything else is reference/supporting detail.
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)
SECTION: NEXT ACTIONS — original tasks (historical) (28 lines)
✅ NEXT ACTIONS (single source of truth)
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).
Purpose
This is the running execution plan for consolidating all planners + databases across the workspace into a clean, frontend-ready backend—without moving
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 t
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)
SECTION: Rules (global + task-specific) — detailed (13 lines)
Rules (global + task-specific)
Standing rules — apply to every planner
Labels are signals, not decisions: “ready to archive,” “DELETE?,” “dup check,” “merge,” “official,” “keeper,” and “do not delete” are review labels on
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,
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 canon
Preserve content and media: When merging pages or databases, preserve page contents, covers, icons, files, templates, comments where available, and me
Master inventory is source of truth: Subject-page inventory should be represented in:
Audit queue pattern: Once a subject is fully captured in the master inventory databases, its subject page can be reduced to a lightweight reference pa
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.
SECTION: Operating Standards — detailed multi-line (97 lines)
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
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.
... and 17 more lines in this section
SECTION: Progress Tracker — per-subject step tracking (73 lines)
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)
Finances (subject page link to finance planner)
Bookings & Scheduling (VIP Events + additional headers toggled)
Documents & Media (nested under top toggle)
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
Rule: Add a short bulleted list of clickable links to the existing linked-view locations directly under the same toggle section as the original databa
Tracking (complete one subject at a time):
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)
Templates Reference (Quotes added)
Bookings & Scheduling (databases added)
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.
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 S
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 inven
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:
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)
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
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
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
SECTION: Step 2 Setup — exact duplicate merge audit checklist (34 lines)
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, mi
Convert useful linked views into actual views on the keeper database where appropriate, so final planner pages use the canonical database instead of d
List any databases that should become properties/relations instead of standalone databases, following Rules + Operating Standards and the Genspark rec
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
Add/confirm a platform/frontend connection mapping property for personal, business, and other subject pages/sections once Jillian sends the Genspark m
Confirm task/request linkage model: notes/tasks should connect to customer requests and individual user requests, with rollups showing needed action c
SECTION: Step 2/3 — per-subject merge/consolidate/placement tracking (14 lines)
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)
SECTION: Cleanup Review List — full A–G sections + F1–F8 findings (89 lines)
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
Status
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 fina
✨Affiliate Statuses
✨Affiliate Statuses (verify underlying)✨Affiliate Statuses duplicate/check/verify rowsMerge inventory rows laterSame underlying database appears 3 tim
✨Connected Account Statuses (dup check)
✨Connected Account Statuses✨Connected Account Statuses duplicate/check/verify rowsMerge inventory rows laterSame underlying database appears 3 times.N
✨Personal File Extensions DatabasePersonal File Extensions Database / ✨Personal File Extensions DatabaseMerge inventory rows laterSame underlying data
Personal Formats DatabasePersonal Formats DatabaseMerge inventory rows laterSame underlying database appears twice.Needs approval✨Personal Finance Dat
✨Personal Finance✨Personal FinanceMerge inventory rows laterSame underlying database appears twice.Needs approval✨Personal Habits✨Personal Habits (dup
✨Personal Habits✨Personal Habits / ✨Personal Habits dup checkMerge inventory rows laterSame underlying database appears twice.Needs approval✨Referral
✨Referral Statuses✨Referral Statuses verify/already addedMerge inventory rows laterSame underlying database appears twice.Needs approval🌿Habit Tracker
🌿 Habit Tracker (merge) (dup check)🌿 Habit Tracker (merge) / dup checkMerge inventory rows later; database itself still needs merge reviewSame underly
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.ItemSubj
C. Merge-review candidates
These appear to need true schema/data comparison, not just inventory row cleanup.Candidate groupItemsInitial actionWhyStatusHealth / habit trackersHea
🌿 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
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, servi
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 withFindingsRecommendat
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 Da
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
Personal Formats DatabaseThis is not the same concept as file formats. Rows include Custom Video, Personalized Item, Photo Set, Premade Video, and Sky
Conclusion: The Formats group contains at least two different concepts: file/media formats and service/request formats. The “DELETE?” and “ready to ar
F3. Comparison findings — Health / habit tracker group
Status: Compared at schema and row-count level. No deletion or archive approved.CandidateRow countFindingsRecommendationApproval statusHealth Tracker
Conclusion: These are related but not identical. The likely model is Personal Habits = habit definitions, Health Tracker = daily health log, and simpl
F4. Comparison findings — Email templates/categories
Conclusion: These are empty but not automatically deletable. If email templates are intended to be global, use one shared template/categories hub; if
F5. Comparison findings — Shot List group
Status: Compared at schema, view, row-count, and row-content level. No deletion or archive approved.CandidateRow countFindingsRecommendationApproval s
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
F6. Comparison findings — Untitled Booking DBs
Status: Loaded, identified, and renamed inventory rows. No deletion/archive approved.Former labelResolved nameFindingsRecommendationApproval status✨Co
... and 9 more lines in this section
SECTION: G sections — exact duplicate audit findings (153 lines)
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
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 da
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 p
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, v
Same schema: Status, Category, Name, Checked. Same board view. Same 3 placeholder rows. Sample pages had no page content.Keep main Weekly Planner copy
Same schema, same table view, same one placeholder meal row, sample page content empty.Duplicate database candidates after approval.Tuesday meal plann
Same schema, same table view, same one placeholder meal row.Duplicate database candidates after approval.Wednesday meal planner
Same schema, same list view, same four placeholder rows, sample page content empty.Duplicate database candidates after approval.Recipe Book
Same schema, same seven gallery views, same nine placeholder rows. Sample recipe pages have matching text/content structure and each has an image/file
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/temp
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 Ro
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 i
However, I did not see a direct Tasks ↔ Customer Requests / Master Requests Queue relation or rollups that would surface request needs directly on a t
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
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
... and 73 more lines in this section
SECTION: Integrated Reconnect + Backend Rebuild Changelog (53 lines)
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 link
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 subj
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
People & Contacts: refine sections (People core, Customers, Roles, Safety, Affiliate/Referrals, Vendors/Talent); file DBs accordingly; add (NEW) heade
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
SECTION: Integrated Reconnect Checklist + Phases — full detail (60 lines)
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 recon
Current top-level status
Subject section relation exists between Master Databases Inventory and Master Subject Sections.
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
Views Inventory still needs the full linked-view/location pass, including all view settings: filters, sorts, grouping/subgrouping, displayed propertie
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.
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.
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
SECTION: Backend Rebuild Changelog — detailed (69 lines)
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/dashboa
Treat linked views as exact duplicates only when settings are identical; the only allowed difference is the page/location where the linked view appear
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 con
For underlying duplicate databases, compare schema, properties, relation targets, rollups, formulas, options, views, templates, rows, page content, co
Choose the keeper database based on richest schema, most complete data/content/media, best relations, best views/templates, and best frontend/canonica
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 propert
Confirm the task/request model supports notes → tasks → customer requests / individual user requests, with rollups for request needs, closet/outfit ne
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.
Taxonomy & Config index updated historically.
Hub-specific geo/platform duplicates converted into linked views where appropriate.
Remaining
Confirm every lifecycle-specific taxonomy stays separate and is named clearly.
Phase E — Customer Requests and commerce backbone
Completed from Reconnect Map
Customer Requests relation replacements added/confirmed:
Pay Status (Rel)
Shoot Status (Rel)
Scene/request metadata relations
Inventory items relation
Address relation
Content modeling decisions documented:
JOI + CEI → Interaction Styles
POV → Content Type
Countdown → Scene Elements
Cowgirl → Positions
Backbone target set documented:
❤️Customer Requests
❤️Items & Deliverables
❤️Item Catalog Titles
❤️Inventory
❤️Item Classes
Closet lifecycle standard documented.
Wishlist / purchase / event / schedule-block routing documented.
Keep legacy Customer Requests fields until all values/options are verified migrated.
Verify the final commerce + closet + inventory graph during reconnect.
Confirm every frontend commerce route/form points to the correct canonical database.
Phase F — Scheduling and unified day backbone
Canonical scheduling databases confirmed:
✨Booking Calendar
✨Availability
❤️Unified Schedule
Event Types updated for unified calendar surface.
Paid Call Queue requirements recorded.
Schedule Blocks created/connected.
Routine / Checklist Templates created/connected.
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 correctl
Add missing relation/view surfaces discovered during the reconnect audit.
Phase G — Finance and legacy finance migration
SECTION: Finance — all finance sections (575 lines)
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.
Phase H — Structural planner UI and subject pages
Completed
Career subject pages re-sectioned.
Database blocks filed under subject headers.
Master Subject Sections structure established.
Database inventory home relation pass completed.
Structural-page UI hygiene sweep:
Operational,
Taxonomy / Config,
Dashboards / Reports,
Protected Legacy,
Review,
Cleanup Queue.
Finish master Views Inventory.
Reduce subject pages to lightweight references after inventory is complete.
Phase I — Genspark frontend reconnect
Build Reconnect Delta List:
old DB/property,
new canonical DB/property,
feature/route/form affected,
migration note,
status.
Phase J — Final cleanup
Show Jillian final deletion/archive approval list.
Delete/archive only explicitly approved items.
Replace temporary brown-square keeper markers with final meaningful icons.
Final verification pass across all master inventory databases.
Next up
Build inventory page + linked views first (no moves):
Start with FINAL PLANNER → Finance sweep
Start Phase 1: Finance sweep (identify any finance DBs/pages still living outside Finances; log in Systems + decide keep/move)finance planner (keep fo
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
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
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)
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
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
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
... and 495 more lines in this section
SECTION: Start here when reorganizing Notion (Genspark reference) (311 lines)
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
✨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 co
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 hi
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 prese
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 prope
Batch update: added canonical linked views inside legacy Subscriptions pages and the Item Inventory Tracker (ready to archive) page (Inventory + Close
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 Subscr
Audit note: found a separate "Income Database (ready to archive)" data source; canonical Income views are embedded, but legacy DB still exists pending
Batch update: added + cleaned Today-focused canonical linked views for legacy pages (Subscriptions Today; Income Due Today; Inventory Arrivals Today;
Migration batch: moved 4 legacy subscription rows (Disney Plus, New York Times, Dropbox, HBO Max) from Subscriptions A (Legacy — Do Not Use) into ✨Sub
Migration batch: moved 4 legacy subscription rows (Notion, Netflix, Google One, Greyscalegorilla Plus) from Subscriptions A (Legacy — Do Not Use) into
Migration batch: moved 4 legacy subscription rows (Github, Namecheap, Hulu, 1Password) from Subscriptions A (Legacy — Do Not Use) into ✨Subscriptions
Migration batch: moved remaining legacy subscription rows (X Blue, YouTube, Adobe Creative Cloud) from Subscriptions A (Legacy — Do Not Use) into ✨Sub
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 ✨Ex
Migration batch: moved 4 legacy expense rows (Rent, Hulu, Groceries, Hulu) from legacy Expenses (ready to archive) into ✨Expenses Database, then archi
Migration batch: moved 4 legacy expense rows (Paper Towels, Movie Tix 🍿, Student OS, New Expense) from legacy Expenses (ready to archive) into ✨Expens
Migration batch: moved 4 legacy expense rows (Cell Phone, Laundry, Dinner w/Cheryl, Rent) from legacy Expenses (ready to archive) into ✨Expenses Datab
(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
Migration batch: moved 3 legacy spending-history rows (Retreat Food, Spring Retreat Cabin, Rental Cars) plus 1 blank row marker from “2022 Finances” (
Migration batch: moved 1 legacy travel-expense row (“expenses name” / $100 hotel) plus 3 blank travel-expense rows from Travel Planner → Expenses (rea
Migration batch: moved 4 legacy expense rows (Subscription x4 monthly placeholders with dates) from legacy Expenses (ready to archive) (Expenses) into
... and 231 more lines in this section
SECTION: Finance Planner — Master Plan (Merged) — full finance spec (269 lines)
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 re
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 re
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
... and 189 more lines in this section
SECTION: Appendix — Wishlist → Expenses rule (5 lines)
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)
SECTION: Linked Index — All Planners & Databases (167 lines)
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,
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)
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
... and 87 more lines in this section