Decision: apply the `## Info` metadata table to canonical notes #1

New issue

Closed

opened 2026-07-23 14:46:21 +02:00 by cloudbot · 1 comment

cloudbot commented

2026-07-23 14:46:21 +02:00

Collaborator

Decision #1 — apply the proposed ## Info metadata table to the four canonical notes?

The app treats a single key-value table at the top of each canonical note as parseable "frontmatter" (like Obsidian YAML, but an Outline-native markdown table). None of the four notes currently follow this pattern, so adopting it means restructuring real family documents.

Current state of each note (reviewed 22 Jul 2026)

Member	Current structure
Ben	Bold key-value pairs under H1 sections (Vital Statistics, Passport, Driving License) — no table
Ari	Free headings (Education & Extra Curricular, Measurements, Documents) — no key-value data
Ada	Documents + a link to a shared sizes doc — no key-value data
Nathalie	Attachments only — no labelled fields at all

Proposed shared key vocabulary

A single ## Info table at the top of each note, existing content left untouched below it:

Key	Applies to	Type	Example
`dob`	all	date	`1984-09-18`
`passport_number`	adults	string	`PU3296827`
`passport_expiry`	adults	date	`2027-11-15`
`driving_license_number`	adults	string	`0001U3DQ4C`
`driving_license_expiry`	adults	date	`2028-04-12`
`shoe_size`	kids	string	—
`clothing_size`	kids	string	—

What to decide

Proceed with the ## Info table convention at all?
If so, is this key set right (add/remove keys; adults-vs-kids split)?
Sign-off that each note gets a careful, non-destructive restructure — this is a write to real family notes and each doc's existing content must be preserved.

Blocks: the metadata parser and the Person Info sheet's data source (#9).

Recommendation: proceed with the convention and this key set — it's the smallest structured layer that makes all four notes parseable. But treat the actual edits as a separate, per-document confirmed write (one note at a time, diff reviewed) rather than a batch. Nathalie's note has no fields today, so it's the cleanest place to validate the shape first.

Source: Solution Design — Family App v1 §4 (doc vpBNbG4TsV), decision §13 #1.

**Decision #1 — apply the proposed `## Info` metadata table to the four canonical notes?** The app treats a single key-value table at the top of each canonical note as parseable "frontmatter" (like Obsidian YAML, but an Outline-native markdown table). **None of the four notes currently follow this pattern**, so adopting it means restructuring real family documents. ### Current state of each note (reviewed 22 Jul 2026) | Member | Current structure | |--------|-------------------| | Ben | Bold key-value pairs under H1 sections (Vital Statistics, Passport, Driving License) — no table | | Ari | Free headings (Education & Extra Curricular, Measurements, Documents) — no key-value data | | Ada | Documents + a link to a shared sizes doc — no key-value data | | Nathalie | Attachments only — no labelled fields at all | ### Proposed shared key vocabulary A single `## Info` table at the top of each note, existing content left untouched below it: | Key | Applies to | Type | Example | |-----|------------|------|---------| | `dob` | all | date | `1984-09-18` | | `passport_number` | adults | string | `PU3296827` | | `passport_expiry` | adults | date | `2027-11-15` | | `driving_license_number` | adults | string | `0001U3DQ4C` | | `driving_license_expiry` | adults | date | `2028-04-12` | | `shoe_size` | kids | string | — | | `clothing_size` | kids | string | — | ### What to decide 1. Proceed with the `## Info` table convention at all? 2. If so, is this key set right (add/remove keys; adults-vs-kids split)? 3. Sign-off that each note gets a **careful, non-destructive** restructure — this is a **write to real family notes** and each doc's existing content must be preserved. **Blocks:** the metadata parser and the Person Info sheet's data source (#9). **Recommendation:** proceed with the convention and this key set — it's the smallest structured layer that makes all four notes parseable. But treat the actual edits as a separate, per-document confirmed write (one note at a time, diff reviewed) rather than a batch. Nathalie's note has no fields today, so it's the cleanest place to validate the shape first. **Source:** Solution Design — Family App v1 §4 ([doc vpBNbG4TsV](https://outline.marquezkeenan.family/doc/solution-design-family-app-v1-vpBNbG4TsV)), decision §13 #1.

cloudbot added this to the M0 · Open Questions & Decisions milestone

2026-07-23 14:46:21 +02:00

cloudbot added the

spike

label

2026-07-23 14:46:21 +02:00

cloudbot added a new dependency

2026-07-23 14:46:42 +02:00

#25 ## Info metadata table parser

cloudbot referenced this issue

2026-07-23 15:02:52 +02:00

Decision: Person Info sheet scope + document source #9