fix: les cinq types de champs de EventuallyConfig rejoignent la barriere polyfill-era
NgLike, UseShapeLike, OrmSubscriptionLike, GetObjectsLike et InsertObjectLike n'existent que pour decrire ce que configure() recoit (les champs de EventuallyConfig), et configure()/EventuallyConfig sont deja, sans ambiguite, sur la liste de suppression - verifie en relisant index.ts : configure et EventuallyConfig sont bien sous la barriere POLYFILL-ERA. Les cinq portaient deja l'annotation honnete kind=invention level=none ref=none (aucun equivalent cible), mais siegeaient sous l'entete qui promet un equivalent cible pour chaque symbole liste. Deplace les cinq exports sous la barriere, a cote de EventuallyConfig. Aucune signature ne change - memes noms, memes formes, toujours exportes depuis cette entree unique - seule la classification qui dit a un consommateur ce qu'il supprimera a la migration est corrigee. C'est un PATCH au sens de la politique de version du contrat concept : rien ne bouge sous ## Surface ni ## Guarantees. Version 1.0.0-dev.12 -> 1.0.0-dev.13, entree ajoutee au contrat concept et a docs/api-contract.md section 14, dans le meme commit que le changement.
This commit is contained in:
@@ -91,21 +91,21 @@
|
||||
// is named only in prose describing what `useShape`'s result envelope carries, never as
|
||||
// an actual type anywhere in this package. Unlike `ReadCap` / `InboxScope`, neither has
|
||||
// an internal use to stay DEFINED for: they are simply gone, not moved.
|
||||
// Each one, and the signature that earns it its place:
|
||||
//
|
||||
// `NgLike`, `UseShapeLike`, `OrmSubscriptionLike`, `GetObjectsLike` and `InsertObjectLike`
|
||||
// left THIS section on 2026-09-28, for a third reason again the opposite of the first two:
|
||||
// each is honestly `kind=invention level=none ref=none` - no counterpart answers, at any
|
||||
// level - and this section's own heading promises one for every symbol it lists. All five
|
||||
// exist only to describe what `configure` receives (they type `EventuallyConfig`'s
|
||||
// fields), and `configure` / `EventuallyConfig` are already below, on the deletion list:
|
||||
// they go with it. The move changes no signature - same names, same shapes, still
|
||||
// exported from this one entry - it only corrects which of the two lists tells a consumer
|
||||
// their fate at migration. See them beside `EventuallyConfig` below.
|
||||
// Each one still SDK-shaped, and the signature that earns it its place:
|
||||
// Nuri every reference the surface RETURNS
|
||||
// NuriLike every reference the surface ACCEPTS
|
||||
// PrincipalId `ensureIdentity`, `inbox.Deposit`/`PostOptions`, `EventuallyConfig`
|
||||
// NgLike `EventuallyConfig.ng`
|
||||
// UseShapeLike `EventuallyConfig.useShape`
|
||||
// OrmSubscriptionLike `EventuallyConfig.ormSubscription`
|
||||
// GetObjectsLike `EventuallyConfig.getObjects`
|
||||
// InsertObjectLike `EventuallyConfig.insertObject`
|
||||
// RdfOrmConfig `getObjects`
|
||||
//
|
||||
// `OrmSubscriptionHandle` - what that last one RETURNS - is deliberately NOT here. An
|
||||
// application hands the shape query in and reads the snapshot back; it never holds a
|
||||
// subscription, and publishing the handle would offer a path around the capability filter
|
||||
// and the shared-wallet identity boundary. It stays defined in `model/types.ts`.
|
||||
// RdfOrmConfig `getObjects`
|
||||
//
|
||||
// `Scope` left this list in `1.0.0-dev.5`, and it is the only one that left because the
|
||||
// TYPE was wrong rather than unreachable. It was `"public" | "protected" | "private"` -
|
||||
@@ -115,16 +115,7 @@
|
||||
// takes the SDK's `Scope` now (re-exported below, from the SDK itself), and a store is
|
||||
// named by its reference. The three strings stay DEFINED in `model/types.ts` as
|
||||
// `StoreType`, where the library's own modules still tell the three apart.
|
||||
export type {
|
||||
Nuri,
|
||||
NuriLike,
|
||||
PrincipalId,
|
||||
NgLike,
|
||||
UseShapeLike,
|
||||
OrmSubscriptionLike,
|
||||
GetObjectsLike,
|
||||
InsertObjectLike,
|
||||
} from "./model/types";
|
||||
export type { Nuri, NuriLike, PrincipalId } from "./model/types";
|
||||
export { useShape } from "./surface/use-shape";
|
||||
export { useShapeQuery } from "./surface/use-shape-query";
|
||||
export type { ShapeQuery, ShapeObservable } from "./surface/use-shape-query";
|
||||
@@ -182,6 +173,28 @@ export type { NG } from "@ng-org/web";
|
||||
*/
|
||||
export { configure } from "./shared-wallet/bootstrap";
|
||||
export type { EventuallyConfig } from "./shared-wallet/bootstrap";
|
||||
// The five field types of `EventuallyConfig` above, moved down beside it on 2026-09-28 -
|
||||
// they used to sit in the SDK-SHAPED section, which was wrong: each is honestly `kind=
|
||||
// invention level=none ref=none`, and each exists only to describe what `configure`
|
||||
// receives. They go with `configure` at migration; nothing here survives it.
|
||||
// NgLike `EventuallyConfig.ng`
|
||||
// UseShapeLike `EventuallyConfig.useShape`
|
||||
// OrmSubscriptionLike `EventuallyConfig.ormSubscription`
|
||||
// GetObjectsLike `EventuallyConfig.getObjects`
|
||||
// InsertObjectLike `EventuallyConfig.insertObject`
|
||||
//
|
||||
// `OrmSubscriptionHandle` - what `OrmSubscriptionLike` RETURNS - is deliberately NOT
|
||||
// here either. An application hands the shape query in and reads the snapshot back; it
|
||||
// never holds a subscription, and publishing the handle would offer a path around the
|
||||
// capability filter and the shared-wallet identity boundary. It stays defined in
|
||||
// `model/types.ts`.
|
||||
export type {
|
||||
NgLike,
|
||||
UseShapeLike,
|
||||
OrmSubscriptionLike,
|
||||
GetObjectsLike,
|
||||
InsertObjectLike,
|
||||
} from "./model/types";
|
||||
// `RegistrySession` went with `getSession` (2026-08-12): it was published for exactly one
|
||||
// reason — an application typed the session thunk it injected with it — and a published
|
||||
// type whose signature is gone is a promise about the target that nothing keeps. Upstream a
|
||||
|
||||
Reference in New Issue
Block a user