[VS-NfD] Mark the Markdown ZIP export with frontmatter and a visible imprint #210

New Issue

fable-5 · 2026-07-30T01:43:43+02:00

fable-5 commented

2026-07-30 01:43:43 +02:00

Plan reference: 20-massnahmenplan.md -> P1-2 (output channels)
ADR: ADR 0022
Effort: S (1 AT)
Depends on: #204

Context

The ZIP export is the bulk egress path: many pages at once, as plain files
that get copied onward. It needs both a machine-readable marker and a
human-visible one.

Current state

apps/api/src/import-export/export.service.ts builds the pond ZIP
(Content-Disposition at :68); page selection at :95–108 filters by
read permission.
apps/api/src/import-export/export-markdown.ts emits the Markdown; it
writes no YAML frontmatter — frontmatter handling exists only on the
Obsidian import side (obsidian-vault.ts:203,528).
Verified: labels do not appear in any export (see §0.2), so no existing
metadata block can carry the marking.

Acceptance criteria

Each exported Markdown file carries the classification in YAML
frontmatter and as a visible line at the top and bottom of the
file.
The ZIP contains a manifest listing every file with its
classification, and the highest classification contained is stated
once at archive level.
Unclassified pages get no marking; existing round-trip and fidelity
tests still pass (frontmatter must not confuse our own importer —
asserted by a round-trip test).
Documented in #228.

Out of scope

The Obsidian vault export variant's own frontmatter modes, beyond keeping
them working.

**Plan reference:** `20-massnahmenplan.md` -> P1-2 (output channels) **ADR:** ADR 0022 **Effort:** S (1 AT) **Depends on:** #204 ## Context The ZIP export is the bulk egress path: many pages at once, as plain files that get copied onward. It needs both a machine-readable marker and a human-visible one. ## Current state - `apps/api/src/import-export/export.service.ts` builds the pond ZIP (`Content-Disposition` at `:68`); page selection at `:95–108` filters by read permission. - `apps/api/src/import-export/export-markdown.ts` emits the Markdown; it writes **no** YAML frontmatter — frontmatter handling exists only on the Obsidian *import* side (`obsidian-vault.ts:203,528`). - Verified: labels do not appear in any export (see §0.2), so no existing metadata block can carry the marking. ## Acceptance criteria - [ ] Each exported Markdown file carries the classification in YAML frontmatter **and** as a visible line at the top and bottom of the file. - [ ] The ZIP contains a manifest listing every file with its classification, and the highest classification contained is stated once at archive level. - [ ] Unclassified pages get no marking; existing round-trip and fidelity tests still pass (frontmatter must not confuse our own importer — asserted by a round-trip test). - [ ] Documented in #228. ## Out of scope The Obsidian vault export variant's own frontmatter modes, beyond keeping them working.

fable-5 added this to the M26 — VS-NfD: classification metadata milestone 2026-07-30 01:43:43 +02:00

fable-5 added the

labels 2026-07-30 01:43:43 +02:00

fable-5 referenced this issue from a commit

2026-07-31 07:13:55 +02:00

#210: mark the Markdown ZIP export with frontmatter, imprint and manifest

fable-5 referenced this issue

2026-07-31 07:14:10 +02:00

#210: Markdown ZIP with frontmatter, imprint and manifest #269

fable-5 referenced this issue

2026-07-31 07:29:17 +02:00

#212: attachment downloads marked by filename prefix + companion #271

fable-5 referenced this issue from a commit

2026-07-31 07:29:18 +02:00

#212: mark attachment downloads by filename prefix and companion file

fable-5 commented

2026-07-31 07:37:33 +02:00

Done in PR #269 (commit 6849704, CI run 552 green, fast-forward merged on Stefan's standing merge instruction).

Evidence:

Every classified .md in the pond ZIP carries YAML frontmatter (classification: vs_nfd) AND the visible marking line at top and bottom; unclassified files are byte-identical to before.
manifest.json per archive (and per pond folder of the account data export): every file with its level, the highest level stated once at archive level; media inherits the highest classification among the readable pages referencing it (fail-closed).
Round trip: the importer recognizes exactly our frontmatter block, strips it and the imprint lines, and creates the page AT LEAST at the imported level (content cannot escape its marking through a ZIP) - pinned by classified-markdown.test.ts and an e2e export-import round-trip. Foreign frontmatter passes through unchanged; Obsidian vault frontmatter modes untouched.

Done in PR #269 (commit 6849704, CI run 552 green, fast-forward merged on Stefan's standing merge instruction). Evidence: - Every classified .md in the pond ZIP carries YAML frontmatter (classification: vs_nfd) AND the visible marking line at top and bottom; unclassified files are byte-identical to before. - manifest.json per archive (and per pond folder of the account data export): every file with its level, the highest level stated once at archive level; media inherits the highest classification among the readable pages referencing it (fail-closed). - Round trip: the importer recognizes exactly our frontmatter block, strips it and the imprint lines, and creates the page AT LEAST at the imported level (content cannot escape its marking through a ZIP) - pinned by classified-markdown.test.ts and an e2e export-import round-trip. Foreign frontmatter passes through unchanged; Obsidian vault frontmatter modes untouched.

fable-5 closed this issue

2026-07-31 07:37:33 +02:00

fable-5 referenced this issue

2026-07-31 07:38:10 +02:00

[VS-NfD] Write the security documentation (architecture, data flows, network plan, ports, trust boundaries) #228

fable-5 referenced this issue

2026-07-31 07:59:06 +02:00

[VS-NfD] Mark attachment downloads by filename prefix and companion file #212

opus-5 referenced this issue

2026-08-01 06:25:53 +02:00

Offer a full pond archive before deletion and before purge #305

opus-5 referenced this issue