mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 22:56:55 +01:00

Michael Dieringer dd5637b1db Custom-laget bestaar nu begge CI-checks: 72 validator-fejl -> 0

Normalisering af alle 39 custom knowledge-filer til READ-kontraktens
skema (validate_frontmatter.py + Test-KnowledgeIndex.ps1 begge groenne):

- R01/R02: 28 filer manglede frontmatter eller brugte aeldre skemaer
  (title/category/severity/rule-id m.fl.) - alle har nu praecis de 6
  kraevede noegler; keywords haandskrevet pr. fil da de driver
  worklist-selektionen i INDEX/knowledge-index
- R09: manglende Description-sektion - regel-agtige foersteoverskrifter
  (Core Rule/Rule/Regel/Core Principle) omdoebt, eller sektion indsat
  efter titlen hvor intro-tekst fandtes
- R10: fenced code blocks konverteret til 4-space indrykkede blokke
  i alle filer (indhold uaendret)
- R11: 4 filer over 100 linjer fortaettet redaktionelt uden semantisk
  tab (ai-eval-scores 143->100, git-lifecycle 121->97,
  permission-sets 113->99, test-feature-scenario-tags 105->91)
- R05: AL0197->al0197, add_repo->add-repo; keyword-lister trimmet
  til maks 10

Ingen regler er fjernet eller aendret i betydning - kun form.

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

2026-07-01 23:47:31 +02:00

3.7 KiB

Raw Blame History

bc-version

domain

keywords

technologies

countries

application-area

all

mcp

git

lifecycle

bc-status

dev-status

sync

all

Git lifecycle must sync BC subtask dev status

Description

Every AL feature branch is linked to a BC subtask. The gitHubDevStatus and gitHubBranch fields on the subtask must reflect the real state of the branch at all times — automatically, without manual steps.

Track branch

Each project declares its track branch in CLAUDE.md — the merge target for all feature branches in the current development track:

Declaration in CLAUDE.md	Meaning
`trackBranch: main` (or absent)	Simple project: merge directly to `main`
`trackBranch: purchase`	Multi-track: merge to `purchase`; `main` stays clean for hotfixes

The track branch is the authoritative "done" marker. A task is Done when its feature branch is merged into the track branch — not necessarily main.

Branch naming convention

Branches must follow this pattern so automation can parse the BC task reference — type is feature/bugfix/hotfix, projectNo matches [A-Z]{2,4}\d{4}-\d{5}, taskNo is a plain or zero-padded integer, description is optional:

<type>/<projectNo>-<taskNo>[-optional-description]

Valid:   feature/DEV2023-00027-004-bc-agent-semantic-tools
         bugfix/DEV2023-00027-003-odata-string-key
         feature/DEV2023-00027-4
Invalid: my-feature / fix-thing / DEV2023-00027   (no automation)

Status mapping

Git event	gitHubDevStatus	gitHubBranch
New branch created (`git checkout -b`)	`In Progress`	`<branch-name>`
Branch abandoned (switch away without committing)	`Backlog`	`""`
Merged to track branch	`Done`	`<track-branch>`
Branch parked (manual)	`On Hold`	`<branch-name>`

Automated implementation (git hooks)

Two git hooks in .githooks/ (activated via git config core.hooksPath .githooks) call Scripts/Invoke-BCGitSync.ps1: post-checkout detects branch creation and abandonment; post-commit detects commits/merges on the track branch. The script calls the BC OData API directly (same credentials as bc-agent.js), never blocks the git operation, and ignores branches that do not follow the naming convention.

Claude-driven synchronization

When Claude executes git operations, the hooks may not fire — hooks unconfigured, or branch name outside the convention. Claude MUST call BC MCP explicitly at two points:

Moment	BC MCP action
Feature branch created	`gitHubDevStatus = "In Progress"`, `gitHubBranch = <branch>`
Feature branch merged to track branch	`gitHubDevStatus = "Done"`, `gitHubBranch = <track-branch>`

Steps: find the active task using the recipe in [[bc-mcp-find-active-task-for-branch]], then call Modify_activeTask_PAG6102900 with the two writable fields. This applies regardless of branch naming and regardless of whether hooks are also active — if both run they write identical values.

Safety rules

CURABIS-BCMCP-008 The sync script NEVER writes BC subtask status (Created/Accepted/In progress/Finished/Invoiced). It only writes gitHubDevStatus and gitHubBranch (see CURABIS-BCMCP-001).

CURABIS-BCMCP-009 The sync script exits 0 on all errors. It must never block a git commit, checkout, or merge. BC sync is best-effort.

CURABIS-BCMCP-010 Only tasks in activeTasks (status = Accepted or In progress) are updated. A branch against a Created task is silently ignored until the task is approved in BC.

BCApps reference

Branch naming and git workflow integration follow microsoft/BCApps conventions — see its .github/CONTRIBUTING.md for feature-branch and work-item-referencing patterns.

3.7 KiB Raw Blame History