mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 14:46: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

2.3 KiB

Raw Blame History

bc-version

domain

keywords

technologies

countries

application-area

all

architecture

git

feature-branch

track-branch

merge

workflow

all

Feature branches must merge into the project's declared track branch

Description

When a project declares a track branch in CLAUDE.md, all feature branches MUST merge into that track branch — not into main directly. main is reserved for releases and hotfixes.

Track branch declaration

The track branch is declared once in CLAUDE.md:

# Declares the integration target for this development sprint/module
trackBranch: purchase

If no trackBranch is declared, main is the default and feature branches merge there directly.

Why

In multi-module or multi-sprint projects, a named track branch acts as an integration buffer:

Without track branch	With track branch
Every feature branch merges to `main`	Features collect on track branch
`main` accumulates partial, in-flight work	`main` stays clean for hotfixes
A hotfix requires reverting or cherry-picking	A hotfix branches from `main` unaffected

The rule protects the invariant: main is deployable at any moment.

Merge requirements

Feature branch must compile and pass before merge
Merge uses --no-ff to preserve branch history in the log
After merge: BC dev status is set to Done (see [[git-lifecycle-must-sync-bc-status]])

The branching model

main
 └── <track-branch>          (e.g. "purchase" — lives for one sprint/module)
       └── feature/<name>    ← development happens here
       └── feature/<name>
       └── bugfix/<name>
 └── hotfix/<name>           ← branches from main, merges back to main

At release: track-branch → main (via PR, after full QA).

Non-compliant

# Merging a feature directly to main when a track branch is declared in CLAUDE.md
git checkout main
git merge feature/my-feature   # violates rule

Compliant

# Read track branch from CLAUDE.md → merge there
git checkout purchase
git merge --no-ff feature/my-feature
# Then sync BC: gitHubDevStatus = "Done"

Scope

Applies to every CURABIS project with a trackBranch declaration in CLAUDE.md. Projects without a declaration use main as the track branch — no change needed.

2.3 KiB Raw Blame History