[Dobbes]

Summary

Add repeatable Python-client/develop compatibility acceptance, exact semantic-dependency provisioning, and a detailed report of the live blocker found during local testing.

Python-only scope: every changed file is under python-client/. This PR targets feature/python-client, does not merge develop, and includes no Java/API, worldview, ODO, or root-documentation changes. The earlier local mixed Java integration work is deliberately excluded.

Changes

• Add the named develop-compatibility functional suite and invoke it from the local acceptance runner; expose it in the exporter-enabled runner.
• Require accepted semantic knowledge rather than treating an HTTP 200 or local-authoring operational flag as scientific readiness. Preserve a redacted status record and fail explicitly when publication is rejected/unresolved.
• Verify ownership of all test processes, retain the explicitly selected compiled server checkout on Runtime restart, and reuse existing scientific/unit and cold-context ACL checks. Restart/roundtrip checks remain behind the readiness gate.
• Capture the declared numbered ODO document from an immutable upstream commit, verify its SHA-256, and stage the exact bytes plus source-catalog locator/hash into disposable TEST state through --semantic-catalog. No bundled substitution, remote fallback, or weakened server validation.
• Add offline safety/provisioning regressions, machine-readable verification records, and the issue report with exact Java/source locations and revision boundaries.
• Review fixes: add --server-repo for every local-runner build/prepare/start/cleanup path and record client/server checkout identities, including dirty/merge state. Preserve the primary scientific exception if session cleanup also fails; attach only the cleanup exception type as a redacted note.
• Add --readiness-only / the named semantic-readiness suite to reproduce semantic publication on unchanged develop without Runtime test controls. This mode starts only graphdb/Resources/Reasoner and explicitly does not certify scientific/restart acceptance. Full-fixture control requirements are unchanged.
• Expand the issue report into an exact-pins reproduction runbook, with Java diagnostic/repair acceptance steps and a trigger/impact/ownership table explaining which fixes cannot belong in Python.

Detailed issue report

Develop/worldview compatibility issue: symptoms, exact inputs, Java call chain, throw site, evidence and resolution boundary

Provisioning the exact ODO import resolves the initial CANDIDATE_ISOLATION_UNSUPPORTED: uncaptured OWL import failure. The next actual live result is:

acceptedGeneration: 0
beanStatus: VALID
logicalStatus: FAILED
Candidate build failed: ONTOLOGY_DOMAIN_INVALID: land requires a resolved domain

The same failure was reproduced on unchanged develop 671a81815 with identical 28 worldview source hashes and identical pinned ODO bytes. The throw site is WorldviewDomainSupport.validate, called by ReasonerService.compileStagedOntologies. This does not establish whether the ultimate cause is a Java defect, worldview semantics, or unsupported version pairing; no Python regression or Java fix is claimed.

Validation

• Latest Windows/Python 3.12: 1,028 offline unit/local-integration tests passed, zero failures/errors/skips; existing Ruff E9/F63/F7/F82 selection passed.
• Exact ODO capture CLI executed successfully; hash, redirect/size limits, owned-state staging and overwrite refusal have offline regressions.
• Actual combined Java stack: all five services started; named live functional suite failed at the semantic-readiness gate (1 failure, 0 errors/skips).
• Unchanged-develop graphdb/Resources/Reasoner reproduction: same post-provisioning semantic failure. This is a readiness-only baseline comparison, not a full workflow pass.
• New readiness-only runner exercised against clean unchanged develop 671a81815, with its previously compiled outputs: prepare and all three starts passed; 1 readiness test failed with the same diagnostic and identical 28 candidate source hashes. Cleanup exit 0; all owned service exits confirmed; no remaining test listeners. New --build selection is covered offline; the fresh-clone build recipe was not executed in this pass.
• Scientific before/after roundtrips, Runtime restart, cold ACL checks and later suites were not reached. They are not reported as passing or converted into skips.
• All owned service exits were confirmed; no remaining TEST-port listeners or production deployment changes.

The earlier live records describe the uncommitted combined-server test tree and separate unchanged-develop baseline, not a newly tested Java merge in this PR. The new develop-readiness-runner-verification.json identifies the tested review fixes by executable hashes and records the actual explicit-server command/outcome. Linux/Python-version matrix and hosted checks must report their own results for the updated head.

Remaining gate

Identify a supported semantically valid server/worldview/ODO combination (or resolve the Java/domain contract separately), then rerun live acceptance. Keep this PR draft while that acceptance remains blocked; it is not promotion to develop or a declaration of deployment compatibility.