mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-05 14:46:55 +01:00
3f2fdb06c3
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> |
||
|---|---|---|
| .. | ||
| architecture | ||
| mcp | ||
| testing | ||
| .gitkeep | ||