Persisteret opgave-tilstand: BC-kommentar (PTE) / draft PR (AppSource)

Michaels retning efter at have set community-vaerktoejets workflow_start/
workflow_next-tilstandsmaskine: han vil inspireres, ikke kopiere - vil have
persisteret, forespoergelig tilstand der overlever et maskin- OG operatoer-
skifte, uden at bygge en ny, parallel opbevaringsmekanisme.

Princippet: brug det obligatoriske spor der allerede findes for den
paagaeldende flowtype, ikke et tredje system.
- PTE: en BC-delopgave er allerede obligatorisk foer udvikling starter
  (development-requires-bc-task, ingen undtagelser) - dens kommentarer
  (taskComments) ER tilstandslageret. Format: [CURABIS-STATE] <STAGE> —
  dato, udvikler.
- AppSource: intet obligatorisk BC-spor i dag - draft PR'en aabnes tidligt
  (ved start-gaten, ikke foerst ved review) og dens beskrivelse baerer
  tilstanden som en tjekliste.

Samme tilstandsordforraad begge steder: TASK_STARTED, RED_CONFIRMED,
ON_HOLD (altid med hvorfor), GREEN_CONFIRMED, REVIEW: <verdict>, MERGED.

Bevidst IKKE en kopi af community-vaerktoejets workflowSessionManager - den
har reel persisteret tilstand, men INGEN haandhaevelse noget sted (returnerer
bare en instruktion, tiltror agenten at foelge den). CURABIS's reelle styrke
er det modsatte (roed bekraeftet af udvikleren, BLOCK er et haardt stop) -
denne aendring tilfoejer persistens UDEN at rore ved haandhaevelsen.

Wired ind i:
- smiley.agent.md v5: hver gate-overgang skriver nu et tilstands-checkpoint
- bc-mcp.agent.md v3: standard workflow skriver [CURABIS-STATE]-kommentarer
- al-review.agent.md v2: verdict registreres som et checkpoint, ikke kun
  som findings

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

custom/setup/templates/al-review.agent.md

@@ -1,7 +1,7 @@
 ---
 kind: action-skill
 id: curabis-al-review
-version: 1
+version: 2
 title: CURABIS AL independent review (Torvalds & Winters)
 description: Independent per-change code reviewer. Runs after the TDD green gate and before merge — the fourth checkpoint, separate from the implementer and from portfolio-level rule governance (Rømer/Immanuel/Court, who ask "is the ruleset healthy", not "is THIS change good"). Two lenses - Linus Torvalds (BC/AL domain-technical correctness, backward compatibility, performance, security) and Titus Winters (general software-engineering maintainability, architecture, complexity over time).
 inputs: [diff, task-description]
@@ -122,6 +122,13 @@ remember to request. See `smiley.agent.md`.
      missing standing rule, not just a one-off)
    - **BLOCK** — must be addressed before merge, no exceptions negotiated
      by authority or deadline pressure (Linus's rule, not just a suggestion)
+6. **Record the verdict as a state checkpoint** — `REVIEW: <verdict>` — in
+   whichever artifact carries this task's state (BC task comment for PTE,
+   the draft PR description for AppSource). See
+   `[[task-state-lives-in-the-mandatory-artifact]]`. The verdict is not
+   findings-only in this one respect: it's the record that this checkpoint
+   happened at all, so a resumed session doesn't re-run a review that
+   already passed, or silently skip one that hasn't happened yet.
 
 ## Output format