Ran ce-compound on an infrastructure/SRE repo (observability, cloud infra, device fleets — no Rails anywhere) that already had ~40 documented learnings. The classification step fought the repo rather than fitting it.
The enum still describes the origin repo
skills/ce-compound/references/schema.yaml — verified at HEAD today — enumerates component with 17 values. Eight only make sense in the app the plugin was extracted from:
rails_model, rails_controller, rails_view, frontend_stimulus,
hotwire_turbo, email_processing, brief_system, assistant
root_cause has the same problem — missing_association, missing_include, missing_index, scope_issue, thread_violation is ActiveRecord vocabulary.
For a repo about metrics pipelines and alerting, nothing in either list fits. The classifier agent picked component: development_workflow as least-wrong, while the repo's own 40 documents consistently use a different, self-consistent set (observability, governance, tooling, and so on).
Why that's a correctness problem, not a cosmetic one
The repo's agent instructions state that these documents are searched by module, component, tags, and problem_type. So a document written to the plugin's enum is a document the repo's own retrieval doesn't surface — the exact opposite of what ce-compound exists to do.
I ended up overriding the schema in favour of the local vocabulary. That means the plugin's contract lost to local convention on first contact, which seems like the wrong default.
Same issue in the directory mapping
references/yaml-schema.md maps workflow_issue → <root>/solutions/workflow-issues/. That directory didn't exist in this repo, which had an established six-directory taxonomy. Following the mapping would have added a seventh that nothing else used and no reader would think to look in.
Credit where due
The classifier agent did notice the divergence and flagged it explicitly, with a recommendation about which field to bend. That's good behaviour. It had no rule telling it which side wins, so it escalated — which is the right failure mode, but it means every non-Rails user resolves this by hand, every time.
Suggested fix
Before classifying, sample the frontmatter actually used by the existing documents and prefer those values; fall back to the built-in enum only when docs/solutions/ is empty or has no usable signal. The agent already opens two reference files at this step — reading its neighbours is one extra glob, and it makes the enum a sensible default rather than a mismatch to argue with.
An enum that's advisory-with-corpus-override would also make the plugin land better in any repo with existing documentation conventions, not only non-Rails ones.
Related
Version: cache showed 3.12.0; all claims above re-verified against HEAD via the contents API before filing.
Ran
ce-compoundon an infrastructure/SRE repo (observability, cloud infra, device fleets — no Rails anywhere) that already had ~40 documented learnings. The classification step fought the repo rather than fitting it.The enum still describes the origin repo
skills/ce-compound/references/schema.yaml— verified at HEAD today — enumeratescomponentwith 17 values. Eight only make sense in the app the plugin was extracted from:root_causehas the same problem —missing_association,missing_include,missing_index,scope_issue,thread_violationis ActiveRecord vocabulary.For a repo about metrics pipelines and alerting, nothing in either list fits. The classifier agent picked
component: development_workflowas least-wrong, while the repo's own 40 documents consistently use a different, self-consistent set (observability,governance,tooling, and so on).Why that's a correctness problem, not a cosmetic one
The repo's agent instructions state that these documents are searched by
module,component,tags, andproblem_type. So a document written to the plugin's enum is a document the repo's own retrieval doesn't surface — the exact opposite of whatce-compoundexists to do.I ended up overriding the schema in favour of the local vocabulary. That means the plugin's contract lost to local convention on first contact, which seems like the wrong default.
Same issue in the directory mapping
references/yaml-schema.mdmapsworkflow_issue→<root>/solutions/workflow-issues/. That directory didn't exist in this repo, which had an established six-directory taxonomy. Following the mapping would have added a seventh that nothing else used and no reader would think to look in.Credit where due
The classifier agent did notice the divergence and flagged it explicitly, with a recommendation about which field to bend. That's good behaviour. It had no rule telling it which side wins, so it escalated — which is the right failure mode, but it means every non-Rails user resolves this by hand, every time.
Suggested fix
Before classifying, sample the frontmatter actually used by the existing documents and prefer those values; fall back to the built-in enum only when
docs/solutions/is empty or has no usable signal. The agent already opens two reference files at this step — reading its neighbours is one extra glob, and it makes the enum a sensible default rather than a mismatch to argue with.An
enumthat's advisory-with-corpus-override would also make the plugin land better in any repo with existing documentation conventions, not only non-Rails ones.Related
Version: cache showed 3.12.0; all claims above re-verified against HEAD via the contents API before filing.