feat(sysml-api): add API challenge harness

[de4sdv]

Summary

• Adds a native SysML v2 API challenge harness that treats the API repository as the system under test.
• Seeds/compares a deterministic DE4SDV ASELCM context graph covering packages, part definitions/usages, reference usages, and dependency relationships.
• Handles live SysML v2 API Services behavior where element IDs are reassigned during commit persistence.
• Adds API-to-textual snapshot export for the supported subset.
• Fixes SysON textual document download for v2026.5.0 by using the Sirius Web document endpoint with Accept: text/html.
• Adds an API-centered SysON roundtrip command: API seed -> textual snapshot -> SysON import -> supported graph export -> API re-import -> semantic diff.
• Adds a bounded SysON view publication spike: list/create views and export current SysON/Sirius representation content to GitHub-reviewable JSON/SVG/manifest artifacts.
• Documents the current native SysON exporter gap: SysON imports dependencies, but its textual export drops them from the downloaded .sysml document.

Live evidence

• Local SysML v2 API Services on http://127.0.0.1:9000 accepted the staged DE4SDV context graph.
• Live API challenge result: passed-with-warnings — semantic elements pass; warnings are expected because API Services reassigns element IDs.
• API-exported textual snapshot imported into SysON v2026.5.0 successfully.
• SysON search confirmed the imported model contains packages, part definitions/usages, and dependency objects.
• SysON textual download endpoint found and verified:
  • GET /api/editingcontexts/{editingContextId}/documents/{documentId}
  • Accept: text/html
• SysON native textual export returned 0 dependency declarations, so the roundtrip report marks that leg failed-lossy.
• Supported graph adapter exported 20/20 expected SysON objects, missing 0.
• Re-import from supported graph into SysML v2 API passed semantic diff.
• SysON view publication smoke test listed an existing SysON General View and exported representation content to:
  • /tmp/de4sdv-syson-existing/system-context.view.json
  • /tmp/de4sdv-syson-existing/system-context.svg
  • /tmp/de4sdv-syson-existing/system-context.manifest.json

Roundtrip command exercised

python scripts/sysml_api_challenge.py roundtrip-syson \
  --api-url http://127.0.0.1:9000 \
  --syson-url http://127.0.0.1:8080 \
  --output /tmp/de4sdv-api-syson-roundtrip.json

Observed report summary:

{
  "summary": {"status": "passed-with-warnings"},
  "legs": {
    "api_seed": "passed-with-warnings",
    "api_to_textual_snapshot": "passed",
    "syson_import": "passed",
    "syson_native_textual_export": "failed-lossy",
    "syson_supported_graph_export": "passed-with-warnings",
    "api_reimport": "passed-with-warnings",
    "semantic_diff": "passed"
  },
  "native_export": {"dependency_count": 0, "bytes": 638}
}

View publication command exercised

python scripts/syson_exchange.py --url http://127.0.0.1:8080 list-views <syson-project-id>
python scripts/syson_exchange.py --url http://127.0.0.1:8080 export-view \
  <syson-project-id> \
  <representation-id> \
  docs/views/syson \
  --stem de4sdv-context

Important limitation: this is tool-specific SysON/Sirius representation publication, not native SysML v2 API view roundtrip. The helper reads representation_content from the local SysON PostgreSQL container because GraphQL exposes view metadata while the full diagram payload is delivered through Sirius Web diagram runtime/subscription state.

Validation

• python -m py_compile scripts/syson_exchange.py scripts/sysml_api_challenge.py
• python -m unittest discover -s tests -p 'test*.py' -v
• python scripts/check_repo.py
• python scripts/smoke_test.py
• git diff --check

[de4sdv]

Stale review — status check

This draft PR is 2 weeks old (last updated June 26) and is behind main (needs rebase).

What's here: SysML v2 API challenge harness — scripts/sysml_api_challenge.py, test suite, and documentation. This relates to ADR #5 (use SysML v2 API repository as live model store).

Path forward:

1. Rebase onto main and promote from draft — the API challenge harness supports a key architectural decision (docs: rework CONTRIBUTING into practical contributor guide #5). If the code is functional, rebasing and opening for review is the logical next step.
2. Close if the approach changed — if the SysML API strategy has shifted since the spike, document why and close.

Tagging @OrkunYilmaz for a decision.