bcquality/CONSUMPTION.md

How CURABIS consumes BCQuality today

agent-consumption.md describes the upstream Microsoft/BCQuality architecture: an orchestrator invokes /skills/entry.md, Entry dispatches layer action skills, each skill runs Source → Relevance → Worklist → Action and emits DO-shaped findings. That document is the architecture. This document is the actual state — which consumption paths are live in the CURABIS fork, and which are dormant upstream inheritance.

Active: the CURABIS Standard session model

The only consumption path in production. Deployed and updated by custom/setup/curabis-standard.agent.md:

• Knowledge is mirrored to each developer's machine at ~/.claude/bcquality-knowledge/ (all three layers + INDEX.md) by custom/setup/sync-bcquality-knowledge.ps1. The mirror is machine-local, never committed to a project repo — see rule custom/knowledge/architecture/bcquality-knowledge-must-mirror-to-machine-not-repo.md.
• Sessions (Claude Code, and Copilot via each repo's copilot-instructions.md) read the project's .github/.agents/bcquality.agent.md plus the machine mirror at session start: custom/ in full, community/ and microsoft/ on relevance via INDEX.md.
• Agents (.github/.agents/*.agent.md) are per-repo copies fetched from custom/agents/ and custom/setup/templates/, reconciled by Mode B.

Dormant: the Entry/orchestrator flow

Inherited from upstream and kept in sync with it, but no orchestrator invokes it today — no CURABIS AL-Go workflow references entry.md. Reserved for a future CI/PR-review integration:

• /skills/entry.md + READ · DO · WRITE contracts
• Layer action skills (microsoft/skills/review/* — 12 review skills)
• tools/Build-KnowledgeIndex.ps1 + knowledge-index.json generation
• .github/bcquality.config.yaml in project repos: the consumer pruning policy for this flow (repo, ref, enabled-layers, disabled-skills). It is currently consumed by nothing. Keep it — but do not mistake it for active configuration of the session model.

Access model: PRIVATE repo, git-based consumption

BCQuality is a private repository. All consumption is git-based through the channel clone at %USERPROFILE%\.claude\BCQuality, pinned to the stable branch. Authentication is Git Credential Manager — the developer's existing GitHub login; the first git contact opens a browser login, and that is the entire token story. raw.githubusercontent.com and unauthenticated GitHub-API calls are dead and must not appear in any consumer.

Machine onboarding (new developer)

Two lines (idempotent — safe to re-run; the clone prompts the GCM login):

git clone --branch stable --single-branch https://github.com/Curabis/BCQuality.git "$env:USERPROFILE\.claude\BCQuality"
powershell -ExecutionPolicy Bypass -File "$env:USERPROFILE\.claude\BCQuality\custom\setup\machine\Install-CurabisMachine.ps1"

It installs the global CLAUDE.md (identity substituted from git config), bc-mcp-bridge.js, the bc-mcp config template (the developer inserts their personal client secret), the knowledge sync script, and syncs the machine mirror from the clone. Per repo afterwards: "Opdater CURABIS Standard fra BCQuality" — it deploys .vscode/find-altool.ps1 and the AL MCP wiring itself. The AL Language extension from the Marketplace is the only per-machine prerequisite for AL MCP.

Auto-trigger: the lines above rarely need to be run by hand. Every project CLAUDE.md (setup v15+) carries a machine self-heal: any Claude Code session in any configured CURABIS repo detects an un-onboarded machine (missing ~/.claude/CLAUDE.md or bridge) and runs the onboarding itself — cloning a CURABIS repo IS the onboarding. Only the personal client secret and the VS Code AL extension remain manual by design.

Release channel: stable

Merging to main is not a deployment. All consumers — the machine CLAUDE.md auto-update, sync-bcquality-knowledge.ps1, the setup agent's fetch URLs, and the agent templates' knowledge references — read from the stable branch, never from main. main is where PRs land and CI runs; stable is what every developer machine actually executes.

Deploying is a deliberate act (Michael only). Three equivalent ways, safest first:

The button (works from any device): GitHub → Actions → Promote to stable → Run workflow. Refuses to run if the channel has diverged; writes a summary of the promoted commits.

The one-liner (from any up-to-date clone, touches no working tree):

git fetch origin
git push origin origin/main:stable

Git itself refuses a non-fast-forward push — if it is rejected, someone has committed directly to stable: that is a finding, never a reason to force.

The explicit form (for understanding what a promote IS):

git checkout stable
git merge --ff-only main
git push origin stable
git checkout main

Optionally cut a version tag at the same commit (git tag vX.Y.Z && git push origin vX.Y.Z) for a historical record. If a bad change reaches stable, roll back by force-moving stable to the previous good commit — consumers follow the branch, so recovery is one push.

Rationale: main used to be the live deploy channel — any merge silently overwrote bc-mcp-bridge.js (which handles S2S credentials) on every developer machine at next session start. The stable gate separates "CI accepted it" from "the organization runs it".

Known deltas to close before activating the Entry flow

1. custom/skills/ is empty. The CURABIS review pass lives in the per-project bcquality.agent.md template, which Entry's skill discovery (*/skills/**/*.md) never sees. Before wiring an orchestrator, move or mirror the CURABIS review skill into custom/skills/review/.
2. Two index generators. The session model's INDEX.md is generated by sync-bcquality-knowledge.ps1's own frontmatter parser; the Entry flow uses tools/Build-KnowledgeIndex.ps1 (CI-validated, schema in lockstep with the Source contract). Converge on the official generator.
3. Layer precedence is not mirrored. The READ contract defines what wins when layers conflict; the machine mirror carries knowledge only, so sessions have no formal precedence rule.