Context
Our codebase_mapper/vocab/ carries SKOS concepts under intent_first_ontology — the same ontology that the code-mapper and code-whisper bundles (analyzed in this session) encode as Python enums in their models.py (BehaviorKind, IntentCategory, OperationKind, EffectKind, EdgeKind, EntityKind, MappingKind, etc.).
Both representations describe the same domain. If one drifts (e.g. code-mapper adds BehaviorKind.coroutine and our vocab doesn't know about it), our concept-tagging silently degrades on bundles built from those projects.
Scope
Add tests/verify_vocab_drift.py — a one-shot drift detector that:
- Parses an external project's
models.py (path passed as CLI arg, defaulting to _tmp/code-mapper/code_mapper/models.py if the bundle is mounted).
- Walks the AST with
ast.parse and extracts every class Foo(str, Enum): member's literal value.
- Compares the set of extracted values against the canonical-term slugs in our SKOS vocab (via
codebase_mapper.vocab.builtin_vocabulary()).
- Reports:
- Missing in our vocab (external project has a concept we don't carry)
- Extra in our vocab (we carry concepts the external project doesn't have — usually fine)
- Aliased successfully (external term matches a known alias)
Implementation notes
- ~80 lines of stdlib
ast walking, no extra dependencies.
- Run as a standalone script
python tests/verify_vocab_drift.py path/to/models.py.
- Exit 0 if no drift; exit 1 with a diff report if drift detected.
Acceptance
- Running against
code-mapper's current models.py (commit 976b3b0) prints either "no drift" or a concrete list of mismatches.
- Running against
code-whisper's models.py (commit adb885d) produces the same kind of report.
Out of scope
- Auto-fixing drift. The script is read-only — it reports, the operator decides.
- Wiring this into CI. Drift detection against an external repo isn't a CI-stable check (the upstream can change at any time). Run on demand.
Use case
When the intent_first_ontology family ships a new release, run this script against their models.py to know which of their new enum members we need to mirror in our vocab YAML.
Context
Our
codebase_mapper/vocab/carries SKOS concepts underintent_first_ontology— the same ontology that thecode-mapperandcode-whisperbundles (analyzed in this session) encode as Python enums in theirmodels.py(BehaviorKind,IntentCategory,OperationKind,EffectKind,EdgeKind,EntityKind,MappingKind, etc.).Both representations describe the same domain. If one drifts (e.g.
code-mapperaddsBehaviorKind.coroutineand our vocab doesn't know about it), our concept-tagging silently degrades on bundles built from those projects.Scope
Add
tests/verify_vocab_drift.py— a one-shot drift detector that:models.py(path passed as CLI arg, defaulting to_tmp/code-mapper/code_mapper/models.pyif the bundle is mounted).ast.parseand extracts everyclass Foo(str, Enum):member's literal value.codebase_mapper.vocab.builtin_vocabulary()).Implementation notes
astwalking, no extra dependencies.python tests/verify_vocab_drift.py path/to/models.py.Acceptance
code-mapper's currentmodels.py(commit976b3b0) prints either "no drift" or a concrete list of mismatches.code-whisper'smodels.py(commitadb885d) produces the same kind of report.Out of scope
Use case
When the
intent_first_ontologyfamily ships a new release, run this script against theirmodels.pyto know which of their new enum members we need to mirror in our vocab YAML.