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/bc-mcp.agent.md

@@ -1,9 +1,9 @@
 ---
 kind: action-skill
 id: curabis-bc-mcp
-version: 2
+version: 3
 title: CURABIS Business Central MCP usage
-description: How to use the CURABIS Business Central MCP server to read project-management work from BC and write GitHub dev status back. Company-default workflow for syncing Claude Code / GitHub work with BC tasks. v2 (2026-07-30) - BC MCP switched from Dynamic to Static Tool Mode; 14 directly-named tools replace the old search/describe/invoke indirection.
+description: How to use the CURABIS Business Central MCP server to read project-management work from BC and write GitHub dev status back. Company-default workflow for syncing Claude Code / GitHub work with BC tasks. v2 (2026-07-30) - BC MCP switched from Dynamic to Static Tool Mode; 14 directly-named tools replace the old search/describe/invoke indirection. v3 (2026-08-03) - task-comment state checkpoints for resumability across machine/operator changes.
 inputs: [project-no, task-no, branch, dev-status, comment]
 outputs: [task-list, updated-task, posted-comment]
 bc-version: [all]
@@ -125,6 +125,18 @@ Moving to `Accepted` requires `Starting date`, `Estimated time` and `Expected De
 4. **Finish.** Set `gitHubDevStatus = Done` automatically when branch is merged to main.
    Set `On Hold` if the branch is parked.
 
+**State checkpoints (2026-08-03):** at each Smiley Task Lifecycle transition
+(see `smiley.agent.md`), call `Create_TaskComment_PAG6102902` with a one-line
+`[CURABIS-STATE] <STAGE> — <date>, <developer>` comment —
+`TASK_STARTED`/`RED_CONFIRMED`/`ON_HOLD: <why>`/`GREEN_CONFIRMED`/
+`REVIEW: <verdict>`/`MERGED`. This is what makes the task resumable by a
+different developer or a different machine without re-deriving where things
+stood from `gitHubDevStatus` alone (that enum only has four values and can't
+distinguish "red confirmed" from "blocked in review"). To resume: call
+`List_TaskComments_PAG6102902` scoped to the task, filter for
+`[CURABIS-STATE]`, the last one is current. See
+`[[task-state-lives-in-the-mandatory-artifact]]`.
+
 ## Create task workflow (PAG6102905)
 
 Use `Create_NewTask_PAG6102905` when a developer wants to register a new task from VS Code.