Commit

Round 2, all on Q4. Selective fits well, because Supabase is already a separate copy: the static site is built from Supabase rows, not from the vault. Q7 Unit of publish: per note. "Publish" copies that note's current source into its Supabase row, and the row becomes the published snapshot. Vault edits stay private drafts until you publish again. -> Yes. Q8 Derived data (tree, sitegraph, search index, search keys, static HTML) is computed from the published rows, not from the vault. That way a published note can't expose an unpublished note's title or links. -> Yes. Q9 Is public: true still needed? If publishing is explicit, the front matter flag repeats it. I'd drop it as the gate: publishing a note sets public: true in the file, and unpublishing deletes the row and removes the flag. One state, readable from the file. -> Yes, with the file flag kept in sync automatically. Q10 After each publish, rebuild and push the static site automatically (debounced, so publishing 5 notes in a row makes 1 commit to dt.in.th)? -> Yes. Q11 Backoffice shows a "changed since publish" badge (vault version != row version), plus a "publish all changed" batch action, so the old all-or-nothing flow is still one click. -> Yes.