bc-carver

name	bc-carver
description	Carve candidate business components from the confirmed domain concepts — cluster by CONCEPTS.md co-occurrence, name each BC with a canonical glossary term — and document the as-is → to-be diff in migration/CARVING.md without changing any code. Step between concept-clarifier and sbce in a legacy-to-BCE migration; the diff is the backlog for incremental (strangler) refactoring. Invoke explicitly as /bc-carver in the analyzed project. Never restructures code — /sbce and the composed stack skill execute the carving.
disable-model-invocation	true

BC Carver

Decide the decomposition, don't perform it. Carving and executing are different acts: the carver produces a written, reviewable cut of the system into business components — the diff a human argues about before the first class moves. Candidates, not verdicts.

Inputs

• migration/GLOSSARY.md — canonical terms and ## Decisions: ground truth, never contradicted.
• migration/CONCEPTS.md — co-occurrence graph and evidence pointers.

No mining, no new concepts. Vocabulary missing here is an extractor defect — stop and re-run /concept-extractor, don't improvise.

Carving Heuristics

• BCs are the dense clusters in the co-occurrence graph; cut along sparse edges.
• Homonym splits settled by the clarifier are the strongest boundary signals — a word that means two things marks two components.
• Name each BC with one canonical glossary term as a single lowercase token (contracts, pricing) — this is the future sbce BC name.
• Give each BC a one-line responsibility phrased in glossary language. If the line needs "and", reconsider the cut.