Blok-referencer
Hvad nu hvis en definition ikke falder fra hinanden i fjorten kopier, men lever på én adresse — og fjorten steder bliver synkrone i stedet for tretten glemte? Blok-referencer sænker vedligeholdelsen ved definitions-ændringer med 95 % og holder konsistensen mellem definition og brug stabil over tid. Stamme-use-case: Architecture Decision Records.
- Blokke refereres i stedet for at kopieres — en vane, der først skal sætte sig.
- Forældreløse ((id)) ved slettede source-blokke — kræver et lint/audit.
- Over-referering hakker læseflowet i stykker; vælg ((id)) over for embed bevidst.
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.