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.8 KiB

Raw Blame History

bc-version

domain

keywords

technologies

countries

application-area

all

mcp

bc-task

repository-scope

project

all

BC MCP: Scope Task Lists to the Current Repository

Description

When a developer asks "what tasks do I have", "what are my open tasks", or any equivalent question about their work queue, only return tasks that belong to the project(s) linked to the current git repository.

Do not return all tasks assigned to the developer across all BC projects. That produces noise from unrelated customers and hides the signal of what is actually in scope for the current repo.

Why

A developer working in a repository is focused on that context. Showing tasks from other projects (other customers, other repos) creates confusion and increases the risk of working on the wrong thing or copying context from the wrong project.

Standard recipe

1. git remote get-url origin
   → e.g. "https://github.com/Curabis/Wareco.git"

2. List_ProjectRepositories_PAG6102904
      filter: "gitHubRepository eq '<url>'"
   → get projectNo(s) for this repo

3. IF no projects found → STOP and flag (see "No linked project" below)

4. List_ActiveTasks_PAG6102900
      filter: "projectNo eq '<projectNo>' and taskResponsible eq '<employeeCode>'"
   → return only tasks in this repo's project(s)

For developer identity (resolving employeeCode from git email), see [[bc-mcp-find-active-task-for-branch]].

No linked project — flag it

If step 2 returns no results, do not fall back to listing all tasks. Instead, surface it explicitly:

Flag: Dette repository (<url>) er ikke knyttet til et BC-projekt. Opgavelisten kan ikke scopetes. Tilknyt repoet via projectRepositories (PAG6102904) eller kontakt projektlederen.

This is a data-quality issue that should be fixed, not silently bypassed.

Multiple projects on one repo

If step 2 returns more than one project for the repo, query tasks from all of them and group the output by project.

What to show

Field	Include
`taskNo`	Yes
`description`	Yes
`status`	Yes
`gitHubDevStatus`	Yes — shows In Progress / Backlog / Done / On Hold
`gitHubBranch`	Yes — shows which branch the task is on
`estimatedTime` / `timeLeft`	Yes — helps prioritize
`expectedDelivery`	Yes — shows urgency
`customerName`	Yes — context

Do not show internal system fields (taskId, etags, @odata.*).

Violations to avoid

Filtering only by taskResponsible without scoping to projectNo → returns tasks from every customer the developer has ever worked on.
Falling back to all-tasks when the repo lookup fails → hides a config problem.
Returning tasks where gitHubRepository on the task matches (this field is obsolete — always scope via the project, not the task field).

2.8 KiB Raw Blame History