Skip to content

docs: add DR-010 S-CORE Compatibility Test Suite (SCTS) overview - #3315

Draft
antonkri wants to merge 5 commits into
mainfrom
feat/dr-010-scts-overview
Draft

antonkri wants to merge 5 commits into
mainfrom
feat/dr-010-scts-overview

Conversation

@antonkri

@antonkri antonkri commented Oct 7, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds DR-010-Strat — a strategic Decision Record giving an overview of the S-CORE Compatibility Test Suite (SCTS): a portable way for third-party distributions to demonstrate conformance against S-CORE module contracts.

Why

There is currently no portable, distributor-runnable conformance mechanism. Two structural subtleties make a naive test suite insufficient:

  • Libraries are consumed at build/link time, not runtime — API conformance must be proven by compiling and linking against the candidate, not just by running it.
  • Bzlmod root-module governance — the root module resolves versions and overrides, so a test module that is not bound to a concrete implementation can "pass" vacuously. The design must fail closed.

What the DR proposes

SCTS as a separately versioned Bazel test module with two stages:

  • Stage 1 — Build & Bind conformance: compile/link against the candidate library (API proof), bind implementations via label_flag; an unbound binding is a hard error (fail-closed). Provenance is recorded in the report.
  • Stage 2 — Runtime conformance: behaviour + wire-contract checks on the built image (incl. QEMU/ITF for services).

Conformance is defined at the artifact boundary, not the build-method boundary. reference_integration acts as the first consumer / self-test, and existing stkh_req traceability is reused.

Status

draft — scoped deliberately at overview level. The concrete mechanisms (unbound_binding rule, compliance.bind() extension, Stage-1 baseline generator, per-module conformance) are called out as follow-up DRs/issues.

Note: :tracking: is a placeholder pending a Shepherd / tracking issue.

@anmittag

anmittag commented Oct 8, 2026

Copy link
Copy Markdown
Member

you should put it under the folder of strategy decissions and add the dr-xxx-strat in your naming

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we not move that to the new project

behavior and, for service modules, exercise the IPC/SOME-IP **wire contract**
across the process boundary.

Each conformance test links to the stakeholder requirement(s) it verifies

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should bundle then the stakeholder requirements tests as SCTS


## Decision

Introduce the **S-CORE Compatibility Test Suite (SCTS)** as a dedicated,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also add a definition document like https://source.android.com/docs/compatibility/17/android-17-cdd?hl=de#31_managed_api_compatibility. We should start with a small list like only use score logging as logging lib etc.

@antonkri
antonkri force-pushed the feat/dr-010-scts-overview branch from 732fb65 to 0a02233 Compare October 13, 2026 14:54

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Backlog
Status: No status

Development

Successfully merging this pull request may close these issues.

3 participants