Blok-referencer
Ét udsagn, én adresse — single source of truth
- 1Marker den blok, der bærer det kanoniske udsagn — ét udsagn, én blok.☐Tjekpunkt: Blokken indeholder præcis ét udsagn.
- 2Kopier blok-referencen (højreklik → Copy block ref). UUIDv4'en er adressen.☐Tjekpunkt: ((id)) ligger i udklipsholderen.
- 3Indsæt ((id)) på målstedet, når læseren skal hoppe til kilden; vælg embed, når blokken skal vises i læseflowet.☐Tjekpunkt: Referencen renderer; Ctrl+klik fokuserer målblokken.
- 4For beslutninger: opret et ADR og citer det fra alle berørte sider via ((id)).☐Tjekpunkt: En ændring i ADR'et er synkront synlig overalt.
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.
Ét udsagn. Én adresse.
Byg din viden, så en ændring lander overalt — din anden hjerne holder trådene samlet.
Reserver din plads··gratis →