feat: upgrade dea:entity-business-process from scaffold to existing - #12
Merged
Merged
Conversation
The cross-repo smoke test (STRUCT-07c) detected status drift: dea:entity-business-process was marked status=scaffold in the model yet the process catalog (dea-catalog-processes) actually has 2 canonical Process entries (dea:process-manage-customer-relationship, dea:process-onboard-supplier). Upgrade the model to status=existing to clear the smoke-test warning. Live smoke result (before): 0 failures, 1 warning (BP drift) Live smoke result (after): 0 failures, 0 warnings The smoke test is wired to run in CI as part of model-ci.yml (follow-up PR), so future status drifts will surface immediately.
|
|
emmanuel-a-otchere
added a commit
that referenced
this pull request
Sep 5, 2026
Add a second job (catalog-smoke-test) to model-ci.yml that runs the cross-repo smoke test (scripts/check_catalog_index_matches_model.py, landed in PR #11) on every push and PR. The new job: 1. Pre-populates .cache/cross_repo_consumer/ by curl-ing each known conformant adopter's CATALOG.yaml from main. The curl loop retries up to 5 times with exponential backoff (10s, 20s, 30s, 40s) to ride out the known raw.githubusercontent.com CDN-cache-miss window (30-60s after a fresh merge). CI does not use the consumer's live-fetch path; it deliberately exercises the offline path so a CDN outage does not falsely fail the smoke test. If a fetch fails after all retries, the corresponding cache file is absent and the smoke test surfaces that as a FAIL (the adoption has regressed or the CDN is down for >3 minutes, both of which warrant operator attention). 2. Runs the smoke test with --offline. Hard failures (model missing, fetch error, schema broken) exit non-zero and fail the job. Soft warnings (status drift) print to the action log but do not block CI; the consumer operator triages them. Adds .cache/ to .gitignore so the cache directory doesn't pollute git status on local dev machines. Verification: - PYTHONPATH=scripts python3 scripts/check_catalog_index_matches_model.py --cache-dir .cache/cross_repo_consumer --offline: 0 failures, 0 warnings (after the BP status upgrade in PR #12). - yaml.safe_load(model-ci.yml): ok. - Dash sweep on new prose: clean. - Secret scan: 0. - git diff --check: clean.
emmanuel-a-otchere
added a commit
that referenced
this pull request
Sep 5, 2026
…reachable) Adds a second job (catalog-smoke-test) to .github/workflows/model-ci.yml that runs scripts/check_catalog_index_matches_model.py on every push and PR. The new job: 1. Pre-populates .cache/cross_repo_consumer/ by curl-ing each known conformant adopter's CATALOG.yaml from main. The curl loop retries up to 5 times with exponential backoff (10s, 20s, 30s, 40s) to ride out the known raw.githubusercontent.com CDN-cache-miss window (30-60s after a fresh merge). 2. Runs the smoke test with --offline --skip-unreachable. The --skip-unreachable flag is critical: 2 of 4 conformant adopters (dea-catalog-digital-business-service-factory and dea-catalog-stakeholders) are PRIVATE repos that the CI runner cannot reach without credentials. Without --skip-unreachable, the smoke test would always fail in CI. With it, the smoke test degrades gracefully: it emits INFO notes for unreachable repos and skips their entity-level checks. Local developer with a PAT can run without --skip-unreachable to validate them all. Only fetch-stage failures are skipped. Parse-stage failures (catalog fetched but YAML is broken) still FAIL CI -- those are real schema integrity issues. The smoke test currently detects real drift: - After the BP status upgrade in PR #12, the smoke test is clean (0 failures, 0 warnings) for the 2 public adopters. - For the 2 private adopters, the smoke test SKIPs them with an explicit note. Local runs with a PAT can validate them. Adds .cache/ to .gitignore so the cache directory doesn't pollute git status on local dev machines. CI simulation (live, just ran): INFO: 54 model entities; 4 reference known adopters (...) INFO: dea-catalog-digital-business-service-factory: skipped INFO: dea-catalog-stakeholders: skipped result: 0 failure(s), 0 warning(s) Tests: 19 passed (added 2 for --skip-unreachable semantics). Verification: - pytest tests/: 19 passed. - yaml.safe_load(model-ci.yml): ok. - Dash sweep on new prose: clean. - Secret scan: 0. - git diff --check: clean. Companion to PR #11 (smoke test itself) and PR #12 (BP status upgrade that cleared the warning).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
feat: upgrade
dea:entity-business-processfromscaffoldtoexistingWhat this PR is
Resolves the one warning surfaced by the cross-repo smoke test (STRUCT-07c, PR #11) on its first run.
The drift
The OpenDEAM root model has:
But the process catalog (
dea-catalog-processes) has actually been populated:dea:process-manage-customer-relationshipentities/v1-alpha/manage-customer-relationship/...dea:process-onboard-supplierentities/v1-alpha/onboard-supplier/...The model's
status: scaffoldwas a holdover from when the catalog was empty (pre-STRUCT-02). The catalog has been populated for weeks now; the model just hasn't been updated.What changes
A single-character status field upgrade:
Nothing else.
Verification
git diff --check: clean.Dash sweep: clean (single field change, no prose).
Out of scope (intentional)
dea:entity-capabilityis alsostatus: plannedwhile the BC catalog has 26 canonical entries. Not upgrading because the model'secf_coordinates: {domain: null, stage: null}is genuinely incomplete: we know it's a capability but haven't pinned its ECF position yet. Upgrading toexistingwould falsely claim ECF coordinates are known. The capability catalog has 26 entries spanning multiple ECF positions; promoting the model status without specifying which ECF coordinates it covers would be a contract violation.dea:entity-stakeholderstaysscaffold(catalog has 0 entities; correct state for pre-Phase-2).dea:entity-business-serviceanddea:entity-solution-componentalreadyexisting; DBSF catalog populated correctly.