docs(plan): the Fable prompt, with the feature set as its main track and quota as its output
A prompt that lives only in a conversation dies at /clear, so it goes in the repo. Three tracks, in the order the operator weighted them: the MAF feature set, the demo, and -- as the actual deliverable rather than an appendix -- a ranked list of what the week's quota should buy. Each item carries a mechanism, a hard [FØR TORSDAG]/[ETTER DEMOEN] tag, a cost in SESSIONS rather than hours, and what would go red if the item were done. An item nothing can falsify is an opinion, not a finding. The measured starting points are embedded so the session does not re-derive them wrongly: two debate agents rather than three, one orchestration in use out of the installed surface, a hand-rolled portfolio fan-out, and a capability map organised by NEED that therefore never compares TOPOLOGIES. The map is not stale on version -- 1.9.0/1.0.0 is what is installed -- which matters, because "the map is old" would be the easy wrong conclusion. The prompt carries its own discipline because Fable runs without an advisor: every figure must be produced by a command shown beside it, and premises in STATE and in plan documents are named as premises. This repo has measured at least three of them wrong, most recently today. It is also forbidden from smuggling feature work in front of the demo. The demo is a hard date; the feature set is not. Arguing otherwise is allowed -- but only out loud, with the consequence spelled out. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XoHJCKBTjFKcjsfEQyGbzh
This commit is contained in:
parent
295e9665fe
commit
c96ef9032d
1 changed files with 142 additions and 0 deletions
142
docs/plan/2026-08-09-fable-egnethetsreview-prompt.md
Normal file
142
docs/plan/2026-08-09-fable-egnethetsreview-prompt.md
Normal file
|
|
@ -0,0 +1,142 @@
|
|||
# Fable 5 — egnethetsreview: feature-sett, demo, og hva ukeskvoten skal kjøpe
|
||||
|
||||
> **Hva dette er.** En ferdig prompt å lime inn i en Fable 5-økt. Den ligger i repoet fordi en
|
||||
> prompt som bare finnes i en samtale forsvinner ved `/clear`.
|
||||
>
|
||||
> **Hvorfor Fable.** Produktet er dømmekraft — stort bilde, review, prioritering — ikke
|
||||
> implementering. Det er oppgaveformen der Fable er sterkest, og der en feil ikke stopper noe; den
|
||||
> blir bare stående og styrer en uke.
|
||||
>
|
||||
> **Kjøres i denne taben** (`~/repos/portfolio-optimiser`), etter `/exit`:
|
||||
> `claude --model fable --effort xhigh`
|
||||
>
|
||||
> **Merk før du starter:** Fable kjører uten advisor (godtar kun Fable-advisor, ikke valgbar i
|
||||
> CC 2.1.220). Den uavhengige kontrollen finnes ikke. Derfor bærer prompten disiplinen selv.
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
Du reviewer et repo du ikke har skrevet: ~/repos/portfolio-optimiser (Python, bygget på
|
||||
Microsoft Agent Framework). Mandat: EGNETHET, adversarisk. Du skriver INGEN kode og
|
||||
endrer INGEN fil. Produktet ditt er dømmekraft og prioritering.
|
||||
|
||||
KONTEKST DU MÅ HA:
|
||||
Torsdag 13. august er det live demo av alle åtte steg i metoden. Onsdag 12. fryses
|
||||
kjørestien. Operatøren har sagt at BÅDE et fullstendig feature-sett OG demoen er
|
||||
viktige, og at ukeskvoten skal prioritere nettopp disse jobbene. Derfor er ikke en
|
||||
funnliste nok — du skal levere en RANGERT plan der hvert punkt har en kostnad.
|
||||
|
||||
REGEL NR. 1 — DEN VIKTIGSTE:
|
||||
Hvert tall du oppgir skal være produsert av en kommando, og kommandoen skal stå ved
|
||||
siden av tallet. Du kjører UTEN advisor: det finnes ingen uavhengig kontroll på deg.
|
||||
Der du ikke kan måle noe, skriv "ikke verifisert". Aldri fyll et hull med en gjetning.
|
||||
Premisser i STATE.md og i plandokumenter er PREMISSER, ikke fakta — repoet har målt
|
||||
minst tre av dem feil, senest 2026-08-09 ("guarden er v0.2 alpha" var v0.3.4).
|
||||
|
||||
GRENSE: du skriver ALDRI i et annet repo. Funn som hører hjemme i
|
||||
llm-ingestion-okf, llm-ingestion-pipeline-security eller portfolio-optimiser-commons
|
||||
leveres som tekst operatøren kan sende videre. portfolio-optimiser-claude er PARKERT.
|
||||
|
||||
LES, i denne rekkefølgen:
|
||||
docs/qa/2026-08-06-intensjons-qa.md hva repoet ER ment å være (20 påstander)
|
||||
docs/research/2026-06-24-maf-capability-map.md hva av MAF som ER vurdert, og hvordan
|
||||
docs/review-2026-07.md F14 — Magentic-vurderingen
|
||||
docs/plan/2026-08-06-demo-uke-plan.md demoen, åtte kriterier
|
||||
docs/plan/2026-08-09-innholdsgate-og-aerlighet.md innholdsgaten, fire åpne beslutninger
|
||||
CLAUDE.md invariantene
|
||||
src/portfolio_optimiser/workflow.py debatten
|
||||
src/portfolio_optimiser/run.py kjørestien + porteføljens fan-out
|
||||
src/portfolio_optimiser/ingest.py Door A
|
||||
|
||||
MÅL SELV — ikke stol på kartet eller på meg:
|
||||
uv run python -c "import agent_framework.orchestrations as o; \
|
||||
print(sorted(n for n in dir(o) if not n.startswith('_')))"
|
||||
uv run python -c "import importlib.metadata as m; \
|
||||
print(m.version('agent-framework-core'), m.version('agent-framework-orchestrations'))"
|
||||
grep -rn "asyncio.gather\|GroupChatBuilder\|WorkflowBuilder" src/
|
||||
uv run pytest -q
|
||||
uv run python -m portfolio_optimiser.simulation
|
||||
|
||||
MÅLTE UTGANGSPUNKT (2026-08-09 — verifiser stikkprøvevis, ikke blindt):
|
||||
- To agenter i debatten (proposer + checker), ikke tre. Bygget ferskt per kjøring.
|
||||
- Vi bruker ÉN MAF-orkestrering: GroupChatBuilder. Ubrukt: SequentialBuilder,
|
||||
ConcurrentBuilder, HandoffBuilder, MagenticBuilder, og hele graf-laget
|
||||
(WorkflowBuilder/Executor/Edge/SwitchCase/checkpointing/sub-workflows/WorkflowViz).
|
||||
- Porteføljens fan-out er håndrullet asyncio.gather, ikke ConcurrentBuilder.
|
||||
- Kapabilitetskartet er organisert etter BEHOV (token-tak, minne, verktøy, MCP,
|
||||
skills, modell-map) — seks seksjoner, ingen sammenligner orkestrerings-TOPOLOGIER.
|
||||
- Kartet er IKKE utdatert på versjon: skrevet mot core 1.9.0 / orchestrations 1.0.0,
|
||||
som er det som er installert i dag.
|
||||
- Magentic ER vurdert (Spike B footgun + review F14). Handoff og Sequential er nevnt
|
||||
i henholdsvis to og ett dokument. Graf-laget er aldri holdt opp mot metoden.
|
||||
- Door A skriver uten innholds-skanning i dag; guarden (v0.3.4, stdlib-only) er
|
||||
planlagt wiret, ikke wiret. Bundle-fabrikken okf-toolkit finnes ikke (utsatt, O1).
|
||||
- Demoens kjøresti importerer IKKE ingest.
|
||||
|
||||
DEL 1 — FEATURE-SETTET (hovedsporet)
|
||||
|
||||
F1. Group Chat maker-checker ble valgt tidlig og kun falsifisert mot Magentic. Hold
|
||||
metoden (method-spec §3, åtte steg) opp mot HandoffBuilder, SequentialBuilder og
|
||||
graf-laget. Er Group Chat fortsatt riktig? Svar med MEKANISME, ikke preferanse:
|
||||
hvilket steg ville blitt bedre, og hva ville det kostet i determinisme?
|
||||
F2. Steg 5-løkka (informert forbedring) er i dag en for-løkke med tak. I graf-laget
|
||||
er dette en betinget kant (SwitchCase på validator-utfall). Ville grafen gitt oss
|
||||
noe vi ikke har — eller bare en avhengighet vi ikke trenger?
|
||||
F3. Porteføljens fan-out er håndrullet fordi Spike B fant at en gjenbrukt workflow
|
||||
lekker tråd-state. Er håndrullingen fortsatt BEGRUNNET, eller ble den en vane
|
||||
etter at footgun-en var forstått?
|
||||
F4. Budsjett-stopp er i dag fail-fast uten gjenopptakelse. MAF har checkpointing.
|
||||
Er "stopp og gjenoppta et porteføljepass" en feature dette produktet trenger?
|
||||
F5. Hva i MAF 1.9.0 løser et problem vi har LØST SELV, som kapabilitetskartet ikke
|
||||
fanget fordi kartet spurte etter behov og ikke etter topologi?
|
||||
F6. Motsatt vei — og dette er det farligste: hva i intensjons-QA-ens 20 påstander
|
||||
realiserer koden IKKE, og som ingen test ville fanget? Et feature-sett måles mot
|
||||
intensjonen, ikke mot rammeverket.
|
||||
|
||||
DEL 2 — DEMOEN
|
||||
|
||||
D1. Hvilket av de åtte stegene er svakest som DEMO — der en tilhører ikke vil forstå
|
||||
hva de ser, eller vil tro noe sterkere enn det som faktisk vises?
|
||||
D2. Hvor påstår gjennomgangen mer enn koden gjør? Grunnregelen (A5) er at koden ikke
|
||||
får påstå mer enn den gjør, og den binder presentatøren også. Kjent og bevisst:
|
||||
agent-svarene er skriptet, innholdet er kuratert, tallene er modellerte — det er
|
||||
premisset, ikke funn. Se etter det som IKKE sies høyt. Vurder særlig om
|
||||
ærlighets-teksten i 2026-08-09-planen §5 faktisk dekker ingest- og fabrikk-gapet.
|
||||
D3. Er det noe i kjørestien som ikke er deterministisk, og som kan se annerledes ut
|
||||
på scenen enn på generalprøven?
|
||||
D4. Er de åtte kriteriene i demo-uke-planen §5 tilstrekkelige? Hvilket kriterium
|
||||
mangler for at onsdagens frys skal være trygg?
|
||||
|
||||
DEL 3 — DET OPERATØREN FAKTISK SKAL BRUKE KVOTEN PÅ
|
||||
|
||||
Dette er leveransen, ikke et vedlegg. Lag én rangert liste over alt du fant, der
|
||||
hvert punkt har:
|
||||
- hva som er galt, med fil:linje eller kommando-output som belegg
|
||||
- MEKANISME: hvorfor det betyr noe, ikke at det "bør fikses"
|
||||
- tidsmerking, hardt:
|
||||
[FØR TORSDAG] kan lukkes uten å røre kjørestien som fryses onsdag
|
||||
[ETTER DEMOEN] krever bygging; skal IKKE gjøres nå
|
||||
- kostnadsanslag i ØKTER (ikke timer), og hvilken modell/effort formen krever
|
||||
- hva som blir FALSIFISERT hvis punktet gjøres — hvis ingenting kan bli rødt,
|
||||
er punktet en mening, ikke et funn
|
||||
|
||||
Sorter etter verdi per økt, ikke etter alvorlighetsgrad. Si eksplisitt hvilke tre
|
||||
punkter du ville tatt først hvis kvoten holdt til nøyaktig tre økter, og hvorfor
|
||||
akkurat de tre.
|
||||
|
||||
FORBUDT:
|
||||
- Ros. Repoet trenger ikke bekreftelse; det trenger motstand.
|
||||
- Å foreslå refaktorering som [FØR TORSDAG].
|
||||
- Å foreslå at feature-arbeid tas før demoen. Demoen er en hard frist; feature-
|
||||
settet er ikke. Hvis du mener det motsatte, si det som en eksplisitt anbefaling
|
||||
med konsekvensen stavet ut — ikke smugle det inn i en prioritering.
|
||||
- Å telle noe uten å vise kommandoen.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Etterpå
|
||||
|
||||
Funnene hører hjemme i STATE.md's NESTE-blokk (det som skal gjøres) og i git (det som ble
|
||||
avgjort). Ikke la reviewen bli et dokument ingen handler på — det er nøyaktig det som skjedde med
|
||||
`app-creator`- og `app-factory`-reviewene fra 10. juli, som fortsatt står uratifiserte.
|
||||
Loading…
Add table
Add a link
Reference in a new issue