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.

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):

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.