docs(a4): etterregistrer friksjon #16-18 per masterplan § A4
#16 passiv-gate-svikt (S14e vindu-regel-feil passerte 0-annotasjons-review), #17 revisjonslogg-eksplosjon (743→4523 ord, embedded pre-A2-mekanikk — bevis for A2s sidecar-beslutning, ikke motstrid mot den), #18 versjonsdisiplin-brudd (b59928buten bump, rettet i A3/4f152c7). Kilder: Akashic state.json S14-S15 + git-historikk, verifisert med wc -w og git show mot A2-commitba0e8a6. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017HThHmdVXhw7mYcC8Yj2pK
This commit is contained in:
parent
4f152c71e4
commit
3dea665b4a
1 changed files with 56 additions and 0 deletions
|
|
@ -497,3 +497,59 @@ Prosess-/spec-merknader fra S13 (ikke nummererte friksjons-poeng):
|
|||
- **Opus-direktiv (operatør S12):** "bruk Opus for alt" gjelder fortsatt for S13's design-revisjon-arbeid. Ingen subagenter spawnes i S13 — alt arbeid skjer i hovedkontekst (les + skriv + reasoning er mid-vekt).
|
||||
|
||||
---
|
||||
|
||||
## #16: Review-gate er formelt aktivt men innholdsmessig passivt — retroaktiv 0-annotasjons-review godkjente en faktafeil
|
||||
|
||||
**Fase:** 7 (observert S14e, etterregistrert 2026-08-10)
|
||||
**Type:** mekanikk-friksjon
|
||||
**Observert:** 2026-05-14 (S14e)
|
||||
|
||||
**Beskrivelse:** #15 innførte review-gate (Voyage `annotate.mjs`-mønsteret) som hard-obligatorisk mellom faseoverganger. Mekanismen ble anvendt retroaktivt på `features/01-sun-position/` (F-001-brief skrevet i S12, før gaten fantes) — men review-runden mottok **0 annotasjoner** (`review_gate_history[1].annotations_received: 0`) og ble likevel markert `status: complete` i `state.json`. Gaten sjekker *at* en review-runde fant sted, ikke *hvor grundig* den var. Konsekvens: F-001 brief.md gikk videre til Voyage-klar status (rev 0→1 via AQ-004-arbeidet) med en feil i vindu-reglene urørt — Sadhguru Surya Kriya-tradisjonen bruker 3 tidspunkter (sunrise, 30°-stigende, sunset), men brief.md rev 0–3 spesifiserte 4. Feilen ble ikke fanget av review-gaten (som passerte med 0 annotasjoner), men av at operatøren **aktivt ba om verifisering** i S14e — en ad hoc-handling utenfor gate-mekanikken. WebSearch bekreftet 3-punkts-tradisjonen; brief rev 3→4 og research rev 3→4 rettet feilen (jf. Akashic `state.json.session.log` S14e: "KRITISK FIX av F-001 vindu-regler... Konsekvens: case A strict = 1/3 vindu (kveld), ikke 3 reduserte").
|
||||
|
||||
**Hva som mangler:** Review-gaten (§ "Review-gate mellom faser", innført via #15) har et fullført/ufullført-vokabular (`annotations_received`, `status: complete`), men intet grundighets-signal. En 0-annotasjons-runde og en 12-annotasjons-runde er strukturelt identiske i `state.json` — begge blir `complete`. Det finnes ingen mekanisme som skiller "operatør leste og fant ingenting å endre" fra "operatør scrollet forbi" eller "operatør stolte blindt på AI-produsert innhold". Domenefakta (som Surya Kriya-tradisjonens 3 vs 4 tidspunkter) er ikke noe review-gate-mønsteret er designet for å fange — det fanger *prosess*-avvik (feil rekkefølge, manglende godkjenning), ikke *faktuelle* avvik i innholdet selv.
|
||||
|
||||
**Foreslått revisjon:** En **aktiv gate-sjekkliste** — operatøren bekrefter eksplisitt (ikke bare stilltiende ved at runden settes til `complete`) et lite sett spørsmål før en 0-annotasjons-review kan lukkes: (1) Er hele artefakten lest, ikke skummet? (2) Er domenepåstander (presedens/regler/tall AI-en har lagt til grunn) sjekket mot en kilde utenfor AI-ens egen skriving? (3) Er minst ett element i artefakten aktivt vurdert for annotering, selv om utfallet ble "ingen endring nødvendig"? Dette svarer direkte på hva #15s gate-mønster mangler i dag: en 0-annotasjons-runde og en 12-annotasjons-runde er strukturelt identiske i `state.json` (`status: complete` uansett) — sjekklisten gjør den stilltiende antakelsen ("gaten passerte, altså ble det sett") til en eksplisitt handling. Hedge: skulle sjekklisten vise seg tung å håndheve i praksis, kan et enklere `reviewed_actively: true/false`-flagg operatøren selv setter vurderes som alternativ — men sjekklisten er hovedforslaget.
|
||||
|
||||
---
|
||||
|
||||
## #17: Revisjonslogg-eksplosjon — brief.md vokste fra 743 til 4523 ord over 6 revisjoner, drevet av akkumulerende revisjonslogg-seksjon
|
||||
|
||||
**Fase:** 7 (observert S14b–S14g, etterregistrert 2026-08-10)
|
||||
**Type:** design-friksjon
|
||||
**Observert:** 2026-05-14 (S14b gjennom S14g)
|
||||
|
||||
**Beskrivelse:** `features/01-sun-position/brief.md` var 743 ord ved rev 0 (S12, jf. #14). Over seks revisjonsrunder innenfor én dag (S14b: rev 0→1, S14c: rev 1→2, S14d: rev 2→3, S14e: rev 3→4, S14f: rev 4→5, S14g: rev 5→6 — hver drevet av AQ-004-iterasjonen: polare edge cases → case-taksonomi → skip-dag-fallback → vindu-regel-fix → pragmatisk hybrid → lås) vokste filen til 4523 ord (verifisert `wc -w`, 2026-08-10) — en 6× økning. Drivkraften er ikke innholdsvekst i selve brief-en (task/Goal/Preferences/Success Criteria), men at `## Revisjons-logg`-seksjonen akkumulerer én fullstendig "Endringer i brief.md (rev N → N+1)"-oppføring **per runde, uten trimming eller sammendrag** — hver oppføring gjentar kontekst fra forrige (jf. `grep -n "Endringer i brief.md" features/01-sun-position/brief.md` i Akashic: 6 separate blokker). Dette kobler til #10/#12/#13/#14-mønsteret (bredde- vs dybde- vs fokus-per-feature-lengdegrense) men er et **nytt** friksjonsmønster: ikke lengden på *innholdet*, men lengden på *historikken om innholdet*, som vokser ubegrenset med antall review-gate-runder.
|
||||
|
||||
**Kobling til A2 — presisert:** Denne friksjonen kobler til A2 (revisjonslogg-plassering, 2026-08-10), men motsatt av hva en overflatisk lesning skulle tilsi. A2 besluttet at revisjonslogg **flyttes ut** av kilde-artefakten til en append-only sidecar (`<artefakt>.revisions.md`; for fase 7: `features/{NN}-{slug}/revisions.md`) og teller uttrykkelig **ikke** mot lengdegrensen — nettopp fordi historikk ikke skal ha tak: «Sidecaren er ikke unntatt fordi den er uviktig, men fordi den er append-only per definisjon: å sette tak på den ville bety å slette historikk» (`phase-design-draft.md`, A2-beslutning 2026-08-10). F-001s 743→4523-ord-vekst i S14b–S14g brukte den **eldre** mekanikken — revisjonslogg embedded i `brief.md` selv — fordi A2 ikke fantes ennå da veksten skjedde. Denne entryen er derfor ikke et åpent problem A2 lot stå, men **empirisk bevis for hvorfor A2s beslutning er riktig**: den observerte veksten er nøyaktig symptomet en uncapped-i-artefakten revisjonslogg produserer.
|
||||
|
||||
**Foreslått revisjon:** Ingen ny revisjon foreslås her — A2 har allerede løst dette for fase 1–7-artefakter generelt (sidecar, uncapped, teller ikke mot lengdegrensen). Gjenstående fakta, utenfor A4s scope å foreslå løsning på: `akashic-intelligence/features/01-sun-position/brief.md` bærer fortsatt den gamle embedded-revisjonsloggen fra før A2 eksisterte — filen er ikke migrert til sidecar-mønsteret. Om og når denne migreringen skal skje er en operatør-/B-fase-beslutning.
|
||||
|
||||
---
|
||||
|
||||
## #18: Versjonsdisiplin-brudd — pack-endring committet uten versjonsbump eller changelog-entry
|
||||
|
||||
**Fase:** cross-cutting / domain-pack-vedlikehold (observert S15, etterregistrert 2026-08-10)
|
||||
**Type:** kontrakt-friksjon
|
||||
**Observert:** 2026-05-14 (S15)
|
||||
|
||||
**Beskrivelse:** Under S15 (Xcode-bootstrap) ble `domain-packs/ios-app/`-pakken utvidet med MCP-toolchain-gotchas (XcodeBuildMCPs `mcp`-subkommando + mcpbridge-krav om aktivt workspace-prosjekt) i commit `b59928b` — men pakkens `version`-felt i `pack.json` ble **ikke** bumpet, og ingen changelog-entry ble skrevet for endringen. `domain-pack-spec.md` § D5 krever patch-bump + changelog-entry for denne typen tillegg (nytt pattern-innhold, ikke et brytende skjema-endring). Bruddet ble stående umerket til A3 (2026-08-10, tre måneder senere) oppdaget det ved premiss-verifisering (`git log -- domain-packs/ios-app/` mot manifestert `version`-felt) og rettet det (`version` 0.2.0 → 0.2.1 + changelog-entry, commit `4f152c7`). I mellomtiden hadde Akashic-instansen konsumert `ios-app@0.2.0`-pinnen mens det faktiske pack-innholdet allerede var 0.2.1-verdig — en **stille skjema-drift**: konsumenten pekte på en versjon som ikke lenger representerte hva filene faktisk inneholdt.
|
||||
|
||||
**Kobling til A3:** A3s app-creator-halvdel (committet `4f152c7`) rettet symptomet (versjonsnummer + changelog). Akashic-halvdelen (re-materialisering av snapshot + pin-oppdatering til `ios-app@0.2.1`) er sendt som coord-melding og utestående ved etterregistrering av denne entryen (2026-08-10) — se STATE.md § Åpne tråder.
|
||||
|
||||
**Hva som mangler:** Ingen mekanisk gate hindrer at en pack-endrende commit går inn uten tilhørende versjonsbump. `domain-pack-spec.md` § D5 er en *prosa*-regel, ikke en håndhevet en — den forutsetter at forfatteren husker å følge den midt i en Xcode-bootstrap-sesjon med mye annet i fokus (S15 var en tung miljø-/verktøy-sesjon, ikke en pack-vedlikeholdssesjon; pack-endringen var et sideprodukt av læring fanget "på farten").
|
||||
|
||||
**Foreslått revisjon:** Vurder en lettvekts pack-lint-sjekk (nevnt som mulig D8 i masterplanen) som en pre-commit- eller pre-materialiserings-sjekk: diff `domain-packs/<pack>/` mot siste tag/manifestert versjon, og flagg (ikke blokker — dette er solo-fork-and-own, ingen CI) hvis innhold har endret seg uten at `version` fulgte med. Enklere alternativ uten ny tooling: `phase-design-draft.md` eller `domain-pack-spec.md` § D5 legger til en eksplisitt sjekkliste-linje i pre-pipeline/fase-avslutning: "endret du noe under `domain-packs/`? bump `version` + changelog nå, ikke senere."
|
||||
|
||||
---
|
||||
|
||||
## Ny friksjon etterregistrert i A4 (2026-08-10)
|
||||
|
||||
Tre nummererte friksjons-entries etterregistrert per masterplanens § A4-scope-grense (kun etterregistrering av allerede-observert friksjon fra Akashic `state.json` S14–S15-loggen og git-historikk; ingen nye design-forslag utover det kildene bærer):
|
||||
|
||||
- **#16** (over — passiv-gate-svikt: retroaktiv 0-annotasjons-review i S14 markerte `complete` uten at noen faktisk fant den 4-punkts-vindu-regel-feilen review-gaten var ment å fange; operatørens aktive spørring i S14e fanget den i stedet. Foreslått revisjon: aktiv gate-sjekkliste, per masterplanens ordlyd).
|
||||
- **#17** (over — revisjonslogg-eksplosjon: `features/01-sun-position/brief.md` 743→4523 ord over rev 0→6 i S14b–S14g, drevet av embedded `## Revisjons-logg` uten tak — den *eldre* mekanikken, fra før A2 flyttet revisjonslogg til uncapped sidecar. Entryen er bevis for hvorfor A2s beslutning er riktig, ikke et åpent problem den lot stå).
|
||||
- **#18** (over — versjonsdisiplin-brudd: `ios-app`-pack endret i `b59928b` (S15) uten versjonsbump/changelog, stod urettet i tre måneder til A3 fant og rettet det i `4f152c7`).
|
||||
|
||||
Alle tre er etterregistrert 2026-08-10 — betydelig etter observasjonstidspunktet (S14–S15, 2026-05-14) — per R-08s funn om at friksjonsloggen lå åtte sesjoner bak. Ingen S16-kjøring fant sted; dette er en dedikert etterregistrerings-sesjon (A4), ikke en ny prototype-fase-sesjon.
|
||||
|
||||
---
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue