Production plan for lifting LTL v1.2.0 -> v2.0.0 (full-spectrum content
engine + /linkedin:newsletter + render migration + net-fewer commands/agents).
- docs/voyage-build/{brief.md,plan.md}: Voyage project dir. plan.md = 21 steps
(S1..S20+S1a), each with a per-step Manifest. Validator: valid, 0 warnings.
- docs/{brief,plan}-fullspektrum-innholdsmotor.md + voyage-build-brief.md:
the directional brief, hardened fasit (authoritative WHAT), and Voyage input.
- Built via /trekplan: confirmatory swarm verified the fasit against real files
(13 corrections folded in); scope-guardian ALIGNED; plan-critic REPLAN ->
revised (3 blockers + 5/6 major + 4/5 minor closed).
- plan.html (annotation surface) left untracked: regenerable via annotate.mjs.
Next: /trekexecute --fg --project docs/voyage-build (fresh session) -> S1.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
160 lines
8.7 KiB
Markdown
160 lines
8.7 KiB
Markdown
# Brief — LTL som fullspektrum LinkedIn-innholdsmotor (idé → publisering)
|
|
|
|
> **Til:** linkedin-thought-leadership-pluginens utviklingsrepo.
|
|
> **Skrevet:** 2026-05-26, etter produksjon av den første kronikkserien (Seres-serien, 6 deler).
|
|
> **Type:** retningsbrief — beslutningsgrunnlag før planlegging/bygging. Selvstendig (kan leses uten annen kontekst).
|
|
|
|
---
|
|
|
|
## 1. Hva vi skal oppnå
|
|
|
|
Løft LTL fra en kortform-fokusert plugin til **den komplette motoren for ALT LinkedIn-innhold,
|
|
fra idé til publisering** — inkludert **nyhetsbrev/langform**, som i dag er pluginens svakeste område.
|
|
|
|
Én plugin skal eie hele kjeden: **idé → research → utkast → faktasjekk → review → hook/distribusjon →
|
|
planlegging → publisering → analyse** — for alle formater: posts, carousels, reaksjoner, video, og
|
|
**nyhetsbrev-editions**.
|
|
|
|
Begrunnelsen: scopet er LinkedIn. Da hører nyhetsbrev hjemme i LTL (det ER et LinkedIn-native format),
|
|
sømmene mot en separat plugin koster mer enn de gir, og brukeren bruker uansett LTL for alt LinkedIn.
|
|
|
|
---
|
|
|
|
## 2. Kontekst: hvor dette innholdet lages
|
|
|
|
**`~/repos/maskinrommet`** er det private, lokale repoet der **ALT innhold produseres**. Der brukes
|
|
**LTL-pluginen til all innholdsproduksjon**. Arbeidsdelingen:
|
|
|
|
- **maskinrommet** = arbeidsbenken (innhold, serier, og en delt `tools/`-mappe med deterministiske
|
|
render-skript: `build-linkedin.mjs` → POST.html, `build-carousel.mjs`, `build-html.mjs` annoterbar
|
|
HTML, `build-pdf.mjs` avis-PDF).
|
|
- **LTL** = verktøyet/hjernen som driver produksjonen i det repoet.
|
|
- **dette LTL-repoet** = der selve plugin-utviklingen skjer. Erfaringene kommer fra maskinrommet;
|
|
endringene gjøres her.
|
|
|
|
Render-skriptene i `maskinrommet/tools/` er den mekaniske utføreren som LTL-pipelinen *kaller*.
|
|
«LTL eier prosessen» krever ikke at LTL *hoster* render-skriptet — se åpen beslutning C.
|
|
|
|
---
|
|
|
|
## 3. Live-status (baseline å bygge for)
|
|
|
|
Nyhetsbrevet **Maskinrommet** er etablert på LinkedIn:
|
|
- **Første post ute**, **30 abonnenter**, **6 nyhetsbrev i pipen** (Seres-serien, ferdig produsert).
|
|
- Publisering er manuell (LinkedIn har ingen API for newsletter/long-form), men kan native-planlegges.
|
|
|
|
Dette er en reell, kjørende kadens — ikke en hypotese. Forbedringene skal støtte å produsere de neste
|
|
seriene raskere og med samme kvalitet.
|
|
|
|
---
|
|
|
|
## 4. Erfaringsgrunnlag: hva en kronikk faktisk krever
|
|
|
|
Seres-serien (6 kronikker, ~10 sesjoner) avdekket at langform-produksjon ikke er «skriving» — det er en
|
|
**research- og adversarial-review-pipeline**. Den faktiske flyten som ga kvalitet:
|
|
|
|
1. **Brief** — vinkel, tenkt stemme, målgruppe-personaer (med primær), nøkkelpoeng, tone, leder-takeaway.
|
|
2. **Research** — flere parallelle, avgrensede mandater → verifiserte notater.
|
|
3. **Faktasjekk-sweep** — risikosortert (🔴/🟡/🟢), parallelle WebSearch-agenter, «hver påstand skyldig
|
|
til motbevist». Fanget ~13 feil — flere som egne research-filer hadde bommet på.
|
|
4. **Skriving** — dramaturgisk rekkefølge, multi-sesjon med vedlikeholdt HANDOVER.
|
|
5. **Konsistens + kvalitet** — på tvers av tekstene (gjentakelser, tone, premiss→konklusjon-bue).
|
|
6. **Persona-/audience-sweep FØR lås** — 3 definerte leser-juryer leser read-only, primær trumfer.
|
|
(«Lander poenget?»). Kjørt til konvergens (LØST/DELVIS/IKKE per flagg).
|
|
7. **Hook-/konverterings-gate** — egen persona-gate på distribusjons-teksten: «ville DU klikket?»,
|
|
hold tilbake leveransen (tall/case/grep), ikke konklusjonen.
|
|
8. **Lås → leveranse** — POST.html «alt på ett sted» (dato, hook, hashtags, første kommentar,
|
|
cover-caption, brødtekst som rik tekst).
|
|
|
|
**De tre suksessfaktorene:** front-loadet kontekst, skreddersydd annoteringsverktøy, vedlikeholdt
|
|
single-source HANDOVER før hver kontekst-reset.
|
|
|
|
**Største prosessfeil å unngå:** persona-sweep ble kjørt ETTER lås → måtte åpne låste tekster. Den
|
|
generaliserte malen MÅ ha persona-sweep FØR lås.
|
|
|
|
---
|
|
|
|
## 5. Byggeprinsipp: løft Voyage-mønstrene, ikke fork dem
|
|
|
|
Denne pipelinen mapper nesten 1:1 på **Voyage**-pluginen (trekbrief → trekresearch → trekplan →
|
|
trekexecute → trekreview, med parallelle agenter + adversarielle reviewere + multi-sesjon).
|
|
|
|
**Men IKKE fork Voyage og IKKE reimplementer den blindt.** Voyage er kode-spesifikk (`file:line`,
|
|
kode-reviewere, RULE_CATALOGUE). Løft i stedet **mønstrene** inn i LTL som et nytt **langform-/
|
|
nyhetsbrev-spor** ved siden av de eksisterende kortform-kommandoene:
|
|
|
|
- faset pipeline med parallelle research-agenter
|
|
- faktasjekk-sweep som eget steg
|
|
- multi-persona adversarial jury (leser-personaer erstatter kode-reviewere; primær trumfer)
|
|
- multi-sesjons-kontinuitet (HANDOVER-mønster)
|
|
|
|
**Delte agenter, variabel intensitet:** research- og faktasjekk-agentene skal kunne kalles på *lav*
|
|
intensitet fra en kortform-post som siterer ett tall, og *full* sweep fra et nyhetsbrev. Voice og
|
|
hook-gate deles på tvers — aldri to systemer.
|
|
|
|
Voyage er **referanse/inspirasjon**, ikke en avhengighet å vedlikeholde.
|
|
|
|
---
|
|
|
|
## 6. Hva LTL allerede har (ikke bygg på nytt)
|
|
|
|
- Skrive-workflows for kortform: `/linkedin:post` (vinkel→draft→kvalitet→refinement),
|
|
`/linkedin:pipeline` (idé→draft→optimer→planlegg→engasjer→publiser→analyse), `batch`, `react`,
|
|
`quick`, `carousel`, `video`, `templates`.
|
|
- Voice-system (`config/user-profile.local.md`, voice-samples, voice-trainer-agent).
|
|
- Hook-/optimaliserings-støtte (content-optimizer, differentiation-checker).
|
|
- Planlegging/sporing/analyse (`calendar`, `publish`, `import`, `report`; queue.json; state-fil).
|
|
- 16 agenter, fler-stegs-kommandoer, REMEMBER-kontinuitet — arkitekturen *kan* være vert for et tyngre
|
|
pipeline-spor.
|
|
|
|
---
|
|
|
|
## 7. Gapet å fylle (LTLs svake punkt = langform/nyhetsbrev)
|
|
|
|
1. **Langform-/nyhetsbrev-pipeline** som eget kommandospor (idé→publisering for editions, ikke bare posts).
|
|
2. **Research-orkestrering** — parallelle mandater, verifiserte notater.
|
|
3. **Faktasjekk-sweep** — risikosortert, kildekritisk, verifiseringslogg, «skyldig til motbevist».
|
|
4. **Multi-persona adversarial review FØR lås** — konfigurerbare leser-juryer, primær trumfer,
|
|
konvergens-loop til rent JA.
|
|
5. **Multi-sesjons-kontinuitet** — HANDOVER-mønster for produksjon som spenner flere økter.
|
|
6. **Nyhetsbrev-leveranse** — edition-format (POST.html-stil «alt på ett sted»), delingstekst-system,
|
|
ferskvare-flagg for tidssensitive tall, native planlegging.
|
|
7. **Annoteringssteg** — integrer annoterbar review-HTML i flyten (render bor i maskinrommet/tools).
|
|
|
|
---
|
|
|
|
## 8. Åpne beslutninger (landes før bygging i dette repoet)
|
|
|
|
- **A. Pipeline som nye kommandoer vs. utvidelse av `pipeline`.** Eget `/linkedin:longform`/`:newsletter`-
|
|
spor, eller utvid eksisterende `pipeline` med en «long-form»-modus?
|
|
- **B. Agent-deling.** Bygges research/faktasjekk/persona-jury som nye delte agenter brukt på variabel
|
|
intensitet av både kort- og langform? (Anbefalt.)
|
|
- **C. Render-eierskap.** Forblir `build-linkedin.mjs`/`build-carousel.mjs` i `maskinrommet/tools/`
|
|
(LTL kaller dem), eller flyttes LinkedIn-render inn i pluginen? (Anbefalt: bli i tools/ — render-familien
|
|
deler fonts/identitet; pluginen holdes lean.)
|
|
- **D. Personasett.** Defineres leser-personaene per prosjekt (fra målgruppen) eller som gjenbrukbare
|
|
profiler i config?
|
|
- **E. Faktasjekk-omfang.** Eget steg, eller integrert i research + review?
|
|
|
|
---
|
|
|
|
## 8b. Merknad: brukeren trenger onboarding i pluginen
|
|
|
|
Brukeren kjenner ikke pluginen sin godt ennå og vil «ta ut potensialet». Tilby tidlig i
|
|
LTL-sesjonen: **`/linkedin`** (oversikt over alle kommandoer) + **`/linkedin:setup`**
|
|
(personaliserings-score + fyll inn voice-samples/case/rammeverk/demografi/profil). Personalisering
|
|
er nøkkelen — voice-matching, differensiering og hook-gate avhenger av ekte innmatede data.
|
|
|
|
## 9. Referanser (i `~/repos/maskinrommet` og memory)
|
|
|
|
- **Plan (supersedes-kandidat):** `~/repos/maskinrommet/planer/2026-05-26-kronikk-voyage-companion.md`
|
|
— skrevet før denne retningen (foreslo separat companion). Behold som historikk; *denne briefen* er
|
|
gjeldende retning.
|
|
- **Erfaringskatalog:** produsert i sesjon 2026-05-26 (16 prosessfaser, suksessfaktorer, friksjon, verktøy).
|
|
- **HANDOVER:** `~/repos/maskinrommet/serier/silvija-seres-motsvar/HANDOVER.md` (§3 leveranse, §4 regler, §5 metode).
|
|
- **Memory (`~/.claude/projects/-Users-ktg-repos-svv/memory/`):**
|
|
`project_kronikk_produksjonsprosess.md` (Voyage-mapping, persona-sweep-FØR-lås, kalibrering),
|
|
`project_maskinrommet_newsletter.md`, `project_kronikk_faktasjekk_sweep.md`,
|
|
`feedback_dokumentprosjekt_suksessfaktorer.md`, `feedback_hook_post_persona_gate.md`,
|
|
`feedback_persona_audience_sweep.md`, `feedback_use_linkedin_plugin.md`,
|
|
`feedback_post_html_single_sheet.md`.
|