# How CURABIS consumes BCQuality today

[agent-consumption.md](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](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.