mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-06 15:16:56 +01:00
dd5637b1db
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>
84 lines
2.8 KiB
Markdown
84 lines
2.8 KiB
Markdown
---
|
|
bc-version: [all]
|
|
domain: mcp
|
|
keywords: [mcp, bc-task, repository-scope, project]
|
|
technologies: [al]
|
|
countries: [w1]
|
|
application-area: [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).
|