Blok-referencer
Én definition, én adresse — og 14 steder er synkrone i stedet for 13 glemte.
- ··Block-ID'er er UUIDv4: ét kanonisk sted, vilkårligt mange ((id))-citater.
- ··Vedligeholdelsen ved definitions-ændring falder med 95 % — du redigerer ét sted.
- ··ADR er den naturlige stamme-use-case: beslutning én gang, refereret overalt.
Transskription
Hvad nu hvis den samme definition ikke faldt fra hinanden i fjorten kopier, men levede på én adresse — og fjorten steder forblev synkrone i stedet for tretten glemte? Det er præcis, hvad blok-referencer gør, og i de næste minutter hører du, hvordan de virker, og hvorfor de presser vedligeholdelsen ned til næsten ingenting.
Et Block-ID er en UUIDv4 — ét kanonisk sted, hvor et udsagn faktisk lever. Med dobbelte parenteser og ID'et imellem citerer du den blok overalt, ((id)). Blokken bliver på sin hjemmeplads, og citatet viser altid den aktuelle version. Ændrer du sourcen, følger fjorten citater straks med.
Smerten uden referencer er stille og dyr. En definition vandrer via Ctrl+C ind på fjorten sider. Seks måneder senere ændrer noget sig, du retter ét sted og glemmer tretten. Konsistensen mellem definition og brug falder under det halve, uden at nogen opdager det — indtil to sider modsiger hinanden, og begge lyder plausible.
Forskellen mellem reference og embed betyder noget. Referencen ((id)) linker — læseren hopper med Ctrl+klik hen til blokken på dens hjemmeplads. Embed spejler blokken inline, så den bliver en del af læseflowet. Tommelfingerregel: ((id)) når læseren skal hoppe ind i konteksten, embed når blokken skal læse med.
Den naturlige stamme-use-case er Architecture Decision Record. Du formulerer en beslutning præcis én gang, med sit eget ID. Roadmap, onboarding og postmortem citerer den via ((id)). Når beslutningen ændrer sig, er rettelsen ét sted synlig i hvert citat — ingen forgrening, ingen forældet kopi.
Her er forskellen i tal. Før: fjorten sider med en kopieret definition, tretten af dem stille forældede, en vedligeholdelse der vokser med hver brug. Efter: én blok, fjorten referencer, ét redigeringssted, alt synkront. Vedligeholdelsen forbliver konstant, uanset hvor ofte du citerer.
Det ærlige spørgsmål til sidst: hvor mange steder er „kunde“, „lead“ eller „done“ defineret i din wiki? Er tallet over ét, er mindst ét af dem forældet. Ét udsagn, én adresse — alt andet er spejl. Din anden hjerne holder trådene samlet og giver tilbage, hvad du betror den.
Block-ID'er er UUIDv4. Én definition, én adresse. ((id)) citerer dem overalt. Vedligeholdelsen ved definitions-ændring falder med 95 %, fordi du redigerer præcis én blok, og 14 steder er synkrone.
Copy-paste på tværs af sider skaber drift
En definition vandrer via Ctrl+C ind på 14 sider. Seks måneder senere ændrer definitionen sig. Du retter ét sted, glemmer 13. Konsistensen mellem definition og brug falder under 50 %, uden at du opdager det.
- Drift-symptom 1: To sider modsiger hinanden, begge virker plausible.
- Drift-symptom 2: Søgning på „ICP“ giver 14 hits med 4 forskellige definitioner.
- Drift-symptom 3: Ingen ved, hvilken version der gælder — så skrives en ny. Nu er der 15.
5 regler for blok-referencer
- UUIDv4 pr. blok. Hver blok får et ID ved oprettelse, fx 6c1b9a2e-4f3d-47a1-9e10-c0b7e2a55f12. Stabilt, kollisionsfrit, ikke til at gætte.
- Blok-reference ≠ blok-embed. ((id)) linker — blokken bliver synlig på sin hjemmeplads. {{embed ((id))}} spejler — blokken vises inline på citatstedet.
- ((id))-syntaks. Dobbelte parenteser, UUID imellem, intet mellemrum. Autoudfyldning efter indtastning af ((.
- Single source vs spejl. Definitionen lever præcis ét sted (source). Alle andre steder er spejle via ((id)). Edit på spejlet = edit på sourcen.
- ADR som stamme-use-case. Architecture Decision Records er den naturlige source: formuler beslutningen én gang, referer den i roadmap, onboarding og postmortem via ((id)).
## ADR-007: Block-ID'er er UUIDv4
id:: 6c1b9a2e-4f3d-47a1-9e10-c0b7e2a55f12
Vi bruger UUIDv4 til Block-ID'er, fordi:
- kollisionsfri uden central tildeling
- 122 bit entropi rækker til 10^36 blokke
- offline-genererbar (crypto.randomUUID())
---
## Roadmap Q3
Se beslutning: ((6c1b9a2e-4f3d-47a1-9e10-c0b7e2a55f12))
## Onboarding for nye devs
ID-skema: ((6c1b9a2e-4f3d-47a1-9e10-c0b7e2a55f12))Før/efter — 14 Wikipedia-kloner vs. én blok, embedded 14 gange
| Før | Efter |
|---|---|
| 14 sider med kopieret ICP-definition | 1 blok, 14 referencer via ((id)) |
| Edit på 14 steder, 13 glemt | Edit på 1 sted, 14 steder synkrone |
| Søgning „ICP“ → 14 hits, 4 versioner | Søgning „ICP“ → 1 source, 14 backlinks |
| Drift ubemærket, modsigelser i wikien | Drift strukturelt udelukket |
| Vedligehold vokser lineært med antal brug | Vedligehold konstant, uafhængigt af antal brug |
<!-- Source-blok (lever i /glossar/icp.md) -->
id:: a8e2d710-3b9f-4c25-8d6a-1f2e7b3c4d50
ICP (Ideal Customer Profile): beskrivelse af den kontotype, mium gavner mest — branche, størrelse, vidensvolumen, compliance-ramme.
<!-- Brug i /sales/playbook.md -->
Vores ICP: ((a8e2d710-3b9f-4c25-8d6a-1f2e7b3c4d50))
<!-- Brug i /onboarding/uge-1.md -->
Læs først: ((a8e2d710-3b9f-4c25-8d6a-1f2e7b3c4d50))
<!-- Brug i /roadmap/2026.md -->
Fokus 2026: ((a8e2d710-3b9f-4c25-8d6a-1f2e7b3c4d50))Et ærligt spørgsmål
Hvor ofte har du måttet vedligeholde den samme definition på flere steder? Tæl de steder, hvor „kunde“, „lead“ eller „done“ er defineret i din wiki. Er tallet over 1, er mindst én af dem forældet.
Ét udsagn, én adresse. Alt andet er spejl.