Decide a stability discipline for the public library surface consumed by downstream projects #296

New Issue

2026-07-20T23:29:21+02:00

claude commented

2026-07-20 23:29:21 +02:00

Motivation

The workspace's library crates have at least one real external consumer: the first downstream research project consumes the engine as a cargo git dependency (surveyed in #295). The shell-boundary work (#295) deliberately enlarges the public library surface — the member-run recipe, its decomposed building blocks, and a public default MemberRunner implementation become documented library API that downstream World programs are invited to build against.

Problem

The project's working discipline to date is "behaviour-preserving refactor, everything still movable" — crate rosters, module homes, and signatures have been reshaped freely cycle over cycle (the C28 stratification alone relocated whole rosters twice). That freedom and an invited external consumer are in tension, and the design ledger currently addresses it nowhere: there is no stated compatibility contract for the public library surface (what may break per commit, what a downstream pin should look like, whether/when versions are bumped, what — if anything — is stable API vs internal seam).

Needed: a deliberate, recorded decision on the stability discipline for the public library surface — even if the decision is "no stability promised before 1.0; downstream pins a commit" — so the expectation is explicit rather than accidental.

refs #295

## Motivation The workspace's library crates have at least one real external consumer: the first downstream research project consumes the engine as a cargo git dependency (surveyed in #295). The shell-boundary work (#295) deliberately enlarges the public library surface — the member-run recipe, its decomposed building blocks, and a public default `MemberRunner` implementation become documented library API that downstream World programs are invited to build against. ## Problem The project's working discipline to date is "behaviour-preserving refactor, everything still movable" — crate rosters, module homes, and signatures have been reshaped freely cycle over cycle (the C28 stratification alone relocated whole rosters twice). That freedom and an invited external consumer are in tension, and the design ledger currently addresses it nowhere: there is no stated compatibility contract for the public library surface (what may break per commit, what a downstream pin should look like, whether/when versions are bumped, what — if anything — is stable API vs internal seam). Needed: a deliberate, recorded decision on the stability discipline for the public library surface — even if the decision is "no stability promised before 1.0; downstream pins a commit" — so the expectation is explicit rather than accidental. refs #295

claude added the idea label 2026-07-20 23:29:30 +02:00

claude referenced this issue

2026-07-21 07:36:40 +02:00

Enforce the shell boundary structurally and evaluate a text-operable successor to the one-shot CLI #295

claude added this to the Safe to embed — a Result-clean library surface under a stated compatibility contract milestone 2026-07-23 13:42:57 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/Aura#296