feat: CR-CATALOG-STRUCT-07c AF smoke test for catalog/model drift

[emmanuel-a-otchere]

CR-CATALOG-STRUCT-07c: AF Smoke Test for Catalog/Model Drift

What this PR is

Third and final PR of the three-PR STRUCT-07 stack. Closes the consumer triangle by validating that each catalog's actual content matches the model's status declaration. Walks the OpenDEAM root model, finds every entity whose catalog_repo is a known conformant adopter (BP/BC/DBSF/SH), fetches each adopter's CATALOG.yaml via the vendored cross-repo consumer, and checks for status/content drift.

Distribution

Bucket	Count	Notes
Vendored modules	3	scripts/cross_repo_consumer/{__init__.py,fetch.py,cli.py}
New scripts	1	scripts/check_catalog_index_matches_model.py (~280 lines)
Tests	17	tests/test_check_catalog_index_matches_model.py
CR doc	1	change-requests/CR-CATALOG-STRUCT-07c.md

Severity matrix

Model status	Catalog canonical count	Severity
existing	0	FAIL (catastrophic drift)
existing	>=1	pass
planned	0	WARN (model content lagging catalog)
planned	>=1	pass
scaffold	0	pass (expected scaffold state)
scaffold	>=1	WARN (model status is stale)
proposed / retired	any	skip (no backing expected)

Hard failures exit non-zero; soft warnings print to stderr but do not block CI. The consumer operator triages warnings out-of-band.

Live run

$ PYTHONPATH=scripts python3 scripts/check_catalog_index_matches_model.py \
    --model model/opendeam-model.yaml \
    --cache-dir .cache/cross_repo_consumer --offline

INFO: 54 model entities; 4 reference known adopters (['dea-catalog-business-capabilities', 'dea-catalog-digital-business-service-factory', 'dea-catalog-processes', 'dea-catalog-stakeholders'])
  dea:entity-business-process (dea-catalog-processes): WARN: status=scaffold but catalog has 2 canonical entities (model status is stale; promote to 'existing' or 'planned')

result: 0 failure(s), 1 warning(s)

The 1 warning is real drift that the smoke test is designed to catch: dea:entity-business-process is marked status: scaffold in the model, yet the process catalog actually has 2 canonical Process entries. The smoke test surfaces this; the model's status field is what gets updated (out of scope for STRUCT-07c).

Where this fits in the consumer triangle

1. validate_model.py (existing): validates the model itself (entity shapes, layer assignments).
2. validate_consumer.py (existing): validates each catalog's metamodel-pointer.yaml against the pinned model (allocation drift).
3. check_catalog_index_matches_model.py (NEW, this PR): validates that each catalog's content matches the model's status declaration.

(1) checks "the model is internally consistent", (2) checks "the catalog claims the right allocation", (3) checks "the catalog has content where the model says it should".

CI

This PR does NOT modify model-ci.yml or any other workflow. The smoke test is a manual diagnostic tool. A follow-up PR can wire it into CI (PYTHONPATH=scripts python3 scripts/check_catalog_index_matches_model.py --cache-dir .cache/... --offline on every push). The cache dir is gitignored.

Verification

• PYTHONPATH=scripts python -m pytest tests/test_check_catalog_index_matches_model.py returns 17 passed.
• Live smoke against cached adopters: 0 failures, 1 warning (the documented dea:entity-business-process status-drift case).
• All 30 upstream dea-metaframework consumer tests still pass.
• Dash sweep on new prose: clean.
• Secret scan: 0.
• git diff --check: clean.

Sequencing

Slice	Status
STRUCT-01 + STRUCT-06a + 06b	Merged
STRUCT-02..05 (four adopters)	Merged
STRUCT-07a (consumer module, dea-metaframework)	Merged (PR #19)
STRUCT-07b (viewer integration)	Merged (PR #164 + #22)
STRUCT-07c (AF smoke test)	This PR

After this merges, STRUCT-07 is complete and the cross-repo consumer pattern is fully wired: catalog repos produce CATALOG.yaml; the consumer reads them; the viewer surfaces them; the architecture framework validates them.

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.