The Refine seam travels to this base, deliberately unwired

The seam that puts Festipod's persistence behind interchangeable Refine backends
was built on `festipod-refine`, over a base this one has since overtaken
everywhere else. Carrying the seam rather than the branch keeps the evolved data
layer intact and costs nothing: the backend contract, the registry and the
provider that mounts Refine depend only on the domain types, so they compile
here untouched once `@refinedev/core` is present — the one dependency this adds,
installed through pnpm as this project requires.

Nothing imports them and the registry is empty, which is the intended state.
Wiring the seam means rewriting `FestipodDataContext` against this base's
version of it — its own decision, with its own failure modes, and not one to
smuggle into a transfer. Landing the files first makes that decision reviewable
against real code instead of a diff between two branches.

The doctrine travels with the code, because the seam is unreadable without it:
the reconstructed observation of `@activitypods/refine-providers` — a package
that publishes no engagement at all, hence `type: reconstruct` and a pin on the
commit it was read at — our usage declaration beside it, and the brief that
arbitrates one data shape for two rights models. So the manifest grows a
`publish:` section: this repo still offers no interface, but it does now publish
what it consumes, which is the only channel a provider has for learning that.

The brief was written where three of the leaves it cites did not exist, and
named them in prose to say so. Here they exist, so it links them; and its open
deduplication point now reads against this repo's own `materializeAttendance`
instead of against a sibling branch. It stays open, and the finding is
unchanged: the active set is keyed per deposit, which buys replay idempotence
and not person identity, so the count counts deposits rather than people.

Two comment zones came over knowingly superseded — runtime hot-switching as what
shapes the provider, and a sign-in barrier waiting on something `AuthGate` no
longer does. They are recorded as data-layer doc-debt instead of being quietly
rewritten, so the rewrite lands with the wiring that settles what they should
say.

.project/concepts/data-layer/_debt.md

@@ -0,0 +1,15 @@
+# Doc-debt — data-layer
+
+> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
+> One block = one "big change": `why` + `files` + `verify` (leaves to review).
+
+## Block: the Refine seam's comments describe a switching design this base superseded
+
+- **why**: The Refine seam was carried over verbatim from `festipod-refine` and lands here as unreferenced scaffolding, on a base that has moved past two of its stated premises. `RefineProvider.tsx` presents **runtime hot-switching** as what shapes the file (selection held in React state, `key={backend.name}` remounting `<Refine>` so the previous backend's cache is discarded); the product decision since is **one app variant per provider set, selected by URL, with a full page reload** — there is no in-session switch left for the file to be shaped by. And both `RefineProvider.tsx` and `providers/index.ts` say the per-backend sign-in barrier is "the next piece" because `AuthGate` gates on the NextGraph session; on this base `AuthGate` renders no access screen of its own and delegates the whole access experience to the SDK. The prose was left untouched on transfer on purpose — it is settled with the wiring, not during the carry-over.
+- **files**: `src/shared/refine/RefineProvider.tsx`, `src/shared/refine/providers/index.ts`, `src/shared/refine/providers/types.ts`
+- **verify (what must be updated)**:
+  - `RefineProvider.tsx` header — "SWITCHING AT RUNTIME is what shapes this file", the `key`/remount rationale, and whether `switchTo` / `useBackendSelection` survive at all once the selection is a URL plus a reload.
+  - `RefineProvider.tsx` — the "What is NOT solved here is the sign-in: `AuthGate` still gates on the NextGraph session … That is the next piece" paragraph, against this base's `src/app/AuthGate.tsx`.
+  - `providers/index.ts` — same sign-in claim, plus the build-injected `__FESTIPOD_BACKEND__` global it reads: `build.ts` on this base defines no such thing, so `initialBackendName()` can only ever fall back to the first registered backend.
+  - Branch-relative phrasing that points nowhere from here: `types.ts` "the inbox on the sibling branch" (that inbox is local — `src/shared/data/registration.ts`) and `providers/index.ts` "the worked implementation is in this branch's history" (it is on `festipod-refine`, not in this branch's ancestry).
+  - Leaves: `data-layer/_overview.md` gained the seam's triggers but still describes no seam, and `brief_2026-10-03_structure-for-two-rights-models` states the contract is in code — both to revisit once the seam is actually wired.

.project/concepts/data-layer/_overview.md

@@ -2,8 +2,8 @@
 type: _overview
 summary: How Festipod persists its data through the @ng-eventually/polyfill SDK — entities stored as documents placed by scope, direct SPARQL writes + reactive shape reads, SHEX stack, connected/demo modes, seed
 triggers:
-  keywords: [nextgraph, "@ng-eventually", polyfill, watchShape, useShape, useShapeQuery, SHEX, shape, scope, "@graph", NURI, inbox, share, sparql, seed, wallet, FestipodData, ngSession, ngGraph, storeRegistry, bootstrap, document, entité, déconnexion, reconnexion]
-  paths: ["src/shared/shapes/**", "src/shared/data/**", "src/shared/context/NextGraphContext.tsx", "src/shared/context/FestipodDataContext.tsx", "src/shared/utils/*", "src/shared/data/seedData.ts"]
+  keywords: [nextgraph, "@ng-eventually", polyfill, watchShape, useShape, useShapeQuery, SHEX, shape, scope, "@graph", NURI, inbox, share, sparql, seed, wallet, FestipodData, ngSession, ngGraph, storeRegistry, bootstrap, document, entité, déconnexion, reconnexion, refine, provider, activitypods, participation, WAC]
+  paths: ["src/shared/shapes/**", "src/shared/data/**", "src/shared/context/NextGraphContext.tsx", "src/shared/context/FestipodDataContext.tsx", "src/shared/utils/*", "src/shared/data/seedData.ts", "src/shared/refine/**"]
 ---
 
 # Data layer

.project/concepts/data-layer/activitypods-providers/contract_activitypods-providers.md

@@ -0,0 +1,88 @@
+---
+type: contract
+summary: The Refine data, auth and live providers @activitypods/refine-providers exposes to an application over a Solid Pod — what each operation does, what a record looks like, and what the package does not offer
+built_from: https://github.com/activitypods/refine-providers.git/src
+built_version: 66616484b96fb2227cd8cdf02321aacfb4811365
+built_at: 2026-10-02
+---
+
+# contract_activitypods-providers — `@activitypods/refine-providers`
+
+**This is a RECONSTRUCTION, not the provider's promise.** The package publishes no engagement and no change policy, so this document is an observation made once, at adoption time, and pinned to the commit named in `built_version`. Nothing here is committed to by its authors: any release may move any of it. Re-observe at each upgrade — the pin is what makes a difference visible.
+
+## Scope
+
+Three Refine providers over a Solid Pod running ActivityPods: a `dataProvider` (CRUD over LDP containers), an `authProvider` (Solid-OIDC sign-in plus the app-registration dance ActivityPods requires), and a `liveProvider` (push over the Solid Notifications Protocol). Resources are not addressed by a path the caller chooses: each configured resource is mapped at runtime to an LDP container discovered in a WebID's Solid TypeIndex.
+
+Two Ant Design components also ship (`antd-auth-page`, `antd-background-checks`) and are outside this scope — `antd` and `@ant-design/icons` are optional peer dependencies, so an app with its own interface consumes the three providers without them. `react-router` is likewise an optional peer dependency.
+
+Package `@activitypods/refine-providers`, version 0.1.5 at the pinned commit. Peer dependency `@refinedev/core ^5.0.12`. Full typed shape: the package's shipped declarations, `./types` (`dist/types.d.ts`) and `./index` (`dist/index.d.ts`).
+
+## Surface
+
+```ts
+dataProvider({ resources, authProvider, jsonContext? }): DataProvider
+authProvider({ clientId, redirectUri?, allowAnonymous?, appStatusCheckInterval? }): AuthProvider
+liveProvider({ resources, authProvider, jsonContext? }): LiveProvider
+
+type ResourceConfig  = { shapeTreeUri?: string; types?: string | string[] }
+type ResourcesConfig = Record<string, ResourceConfig>   // keyed by Refine resource name
+type JsonContext     = string | string[] | Record<string, any>
+type AuthSession     = { token: string; webId: string }
+```
+
+`AuthProvider` is Refine's `AuthProvider` plus four members: `getSession(): AuthSession | undefined` (synchronous), `handleCallback(): Promise<{ webId, redirect }>`, `registerApp(webId?): Promise<string | undefined>`, `getAppStatus(): Promise<AppStatus>`. Its `login`/`register` take `{ issuer, redirect?, isSignup? }` — the Pod provider's base URL is a caller-supplied parameter, so the app must let the user pick one.
+
+`DataProvider` implements `getList`, `getOne`, `getMany`, `create`, `update`, `deleteOne` and `getApiUrl`. Nothing else.
+
+Utility functions are exported from the package root as well (notably the TypeIndex discovery and container resolution used internally); they are not part of what this document engages.
+
+## Guarantees
+
+Observed at the pinned commit.
+
+**A record is a JSON-LD resource with an `id`.** `id` is the resource's own URI — `id` or `@id` of the fetched document, whichever is present; a resource carrying neither raises. The record also carries `@context` (the container's, on a listed record) and every other predicate verbatim. There is exactly ONE identifier: `getOne`, `update` and `deleteOne` take that same `id` and use it directly as the URL they fetch.
+
+**`getList`** resolves the resource's container, fetches it whole, and maps `ldp:contains`. Refine's filters and sorters are then applied **in memory**, and pagination slices the result; `total` is the count before slicing. The filter set is broad (equality, `in`, substring, prefix/suffix, ordering, `between`, null checks, and `and`/`or` nesting), string comparison being case-insensitive unless the case-sensitive variant is used, and a filter field may be a dotted path.
+
+**`create`** POSTs `{ "@context": jsonContext, "@type": <resolved types>, ...variables }` to the container, requires a `Location` response header, and returns the record re-fetched from it. The `@type` is the resource's configured `types` expanded through `jsonContext`, or, when only `shapeTreeUri` is configured, the `sh:targetClass` of the shape the shape tree points at.
+
+**`update` merges — a partial write is safe.** It fetches the current resource, drops its `id` and `@context`, and PUTs `{ "@context": jsonContext, ...current, ...variables }`. So values the caller omits survive. The merge is **shallow**: a nested object in `variables` replaces its counterpart whole. It returns the record re-fetched after the write.
+
+**`deleteOne`** DELETEs the resource and returns `{ id }` only.
+
+**A configured resource's container is discovered, not configured.** Resolution reads the WebID document, then its `solid:publicTypeIndex`, then best-effort its `pim:preferencesFile` → `solid:privateTypeIndex`, and takes the first type registration whose `solid:forClass` matches the resource's resolved types and which carries a `solid:instanceContainer`. No match raises, naming the WebID and the types. A `shapeTreeUri` is fetched over plain HTTP, as is the shape it points at — so a shape tree the caller hosts itself works, provided it is reachable and carries `st:shape` → `sh:targetClass`.
+
+**`jsonContext`** is sent as `@context` on every create and update, and is what expands configured CURIE types. It defaults to the ActivityStreams 2 context; an application with its own vocabulary passes its own.
+
+**`liveProvider` pushes — the caller never polls.** It opens a `notify:WebSocketChannel2023` channel per topic, discovering the subscription endpoint from the Pod origin's `.well-known/solid`. Watching specific records subscribes to each record and reports `Update` → `updated`, `Delete`/`Remove` → `deleted`. Watching a list subscribes to the **container** and reports `Add` → `created`, `Remove` → `deleted`. Unsubscribing closes the socket and deletes the channel best-effort. A resource absent from `resources` yields a no-op unsubscribe rather than an error.
+
+**Auth is Solid-OIDC with PKCE.** `login` redirects to the issuer's authorization endpoint with scope `openid webid offline_access`; `handleCallback`, called from the redirect route, completes the code grant and stores the ID token. The session's `webId` is the token's `webid` claim, and an expired token reads as no session. `logout` clears local state. `check` reports unauthenticated with `redirectTo: "/login"` unless `allowAnonymous` is set. `getIdentity` returns `{ id: webId, name, avatar }`, name and avatar read from the WebID document and the profile it links — ActivityPods' own profile vocabulary, unrelated to any vocabulary the app defines for its own user records. `registerApp` returns the AppRegistration URI when the app is registered and its grants current, and otherwise redirects the browser to the user's authorization agent and resolves `undefined`.
+
+**Failures throw, and carry the HTTP status.** Every Pod call that returns non-2xx raises an `Error` with `status` and `body` attached, its message taken from the response body's error message when there is one. `onError` maps a 401 to logout.
+
+## Non-guarantees
+
+**Every read and write is scoped to the logged-in user's own Pod.** Container resolution always runs against the session's own WebID — in `getList`, in `create`, and in a list subscription alike. There is no parameter, filter or option through which an operation reaches another user's resources: `getList` returns what the current user holds, and nothing else. (`getOne`/`getMany` fetch a URI directly and so are not bound this way, but they require the caller to already hold that URI.)
+
+**No server-side querying.** Filtering, sorting and pagination are applied after the whole container has been fetched, so cost grows with the container, not with the page.
+
+**`getManyReference` is not implemented**, despite the data provider's own documentation mentioning it. Neither are `createMany`, `updateMany` and `deleteMany`.
+
+**`getMany` drops what it cannot fetch.** Failed fetches are filtered out silently, so the returned array may be shorter than `ids` with no indication of which are missing.
+
+**Caches are module-level and never invalidated** — shape trees by URI, type registrations by WebID, subscription endpoints by origin. A container that becomes available after a first lookup (the user granting access, for instance) is not seen until the page reloads, which is what the registration flow expects.
+
+**`authProvider` installs process-global timers it never removes.** Unless `appStatusCheckInterval: false` is passed, construction registers a `setInterval` and a `visibilitychange` listener, with no teardown; constructing the provider more than once per page accumulates them.
+
+**One session per page.** The token lives at a fixed `localStorage` key, so two concurrent sessions cannot coexist.
+
+**A list subscription does not report field changes.** A container notifies about membership only, so a member's own predicates changing is invisible to a list; the record has to be watched directly.
+
+**`types` wins over `shapeTreeUri` when both are set** — the opposite of what the configuration type's own documentation states. Configure exactly one. Likewise, when several type registrations match a resource's types, the first encountered wins, with no stated ordering.
+
+**Unregistered apps read and write nothing.** An ActivityPods app must hold an AppRegistration before any data operation succeeds, and keeping it current is the app's business, through `registerApp` and `getAppStatus`.
+
+## Change policy
+
+None is published. The package carries no engagement document, no stated versioning commitment and, at the pinned commit, no git tags — its released versions are visible only as `package.json` version bumps. Treat every upgrade as potentially breaking: re-read the surface against the new commit and re-stamp this document. Divergences found between this reconstruction and observed behaviour are defects in this document, to be fixed here.

.project/concepts/data-layer/activitypods-providers/usage_festipod.md

@@ -0,0 +1,71 @@
+---
+type: usage
+summary: What Festipod consumes from @activitypods/refine-providers as one of its interchangeable Refine backends, and the conditions its own vocabulary and confidentiality model put on that backend
+against: 66616484b96fb2227cd8cdf02321aacfb4811365
+---
+
+# usage_festipod — Festipod on `@activitypods/refine-providers`
+
+Festipod is a mobile-first web application: users create **meeting points** grafted onto public events, and sign up to them. Its entire persistence goes through Refine, behind a **backend seam** that exists so the app can support several Refine backends and let the user switch between them at runtime. This package is one of the two backends targeted; the other is a Refine provider over NextGraph plus its polyfill. The seam's own contract — what a backend must answer before it can be added — lives in code, in `src/shared/refine/providers/types.ts`.
+
+Nothing is wired yet, so the list below is **declared, not measured**: it is what Festipod will call, derived from the seam's requirements and from the observation of the package pinned beside this declaration. `against:` names that observation's commit. The package publishes no engagement, so there is nothing to pull and nothing that can drift — what is recorded here is read against our own reconstruction, and re-read when it is re-stamped.
+
+## Consumed surface
+
+### Provider construction
+
+- `authProvider({ clientId, redirectUri, appStatusCheckInterval: false })` — one call site, per backend selection. `appStatusCheckInterval` is disabled deliberately, see friction 1; Festipod drives the check itself.
+- `dataProvider({ authProvider, resources, jsonContext })` — one call site, handed the `authProvider` above.
+- `liveProvider({ authProvider, resources, jsonContext })` — same, so Refine can subscribe behind every query.
+
+All three are built together, **per backend instance**, inside the seam's `build()`.
+
+### Auth members
+
+`login({ issuer, redirect })` and `register(...)` — Festipod supplies its own Pod-provider picker. `handleCallback()` from its own callback route. `logout()`. `check()`. `getSession()` for the `webId` and the token. `registerApp()` and `getAppStatus()`, the second one on Festipod's own schedule since the built-in interval is off.
+
+### Resources and operations
+
+Four resources, one per persisted entity: **events**, **meeting points**, **participations** and **user profiles**. Each is configured with `types` naming Festipod's own class URIs, and `jsonContext` carries the context that expands them.
+
+Through Refine's hooks only, never the provider directly: `useList` → `getList`, `useCreate` → `create`, `useUpdate` → `update`, `useDelete` → `deleteOne`. `getOne` is reached by Refine's cache plumbing rather than an explicit call. The app mounts Refine with `liveMode: 'auto'` and `mutationMode: 'optimistic'`.
+
+### Record handling
+
+A record's `id` — the resource's URI — is the **only** identifier Festipod uses: the seam's `recordKey` and `domainId` both return it. `update` merging the fields it is given means the seam declares this backend as patching, and sends only what changed.
+
+### Not consumed
+
+- `shapeTreeUri` — exactly one of the two resource identifiers must be configured, and `types` names Festipod's classes directly, without a shape tree to host and keep reachable.
+- `getIdentity` — the signed-in identity and a Festipod user profile are two unrelated things in this app; the profile is read as an ordinary record, and only `getSession`'s `webId` is needed.
+- `getMany`, `getApiUrl`, `allowAnonymous`, and both Ant Design entry points — Festipod has its own interface.
+
+## Constraints
+
+What must keep holding for this backend to serve the app.
+
+1. **Festipod's own vocabulary, not ActivityStreams.** The four entities are Festipod domain types defined by SHEX shapes this repo holds; none is an ActivityStreams type. A caller-supplied `jsonContext` and caller-supplied `types` are what make that possible, and both must stay caller-supplied.
+2. **The identifier a record is addressed by must stay the identifier other records reference.** The seam carries the two separately because they differ on the other targeted backend; here they coincide, and the app relies on that. Splitting them later would break every cross-entity reference silently.
+3. **A partial update must stay partial.** The app sends only changed fields. A move to replacing the resource would drop every field omitted, with no error.
+4. **Every participation must be readable by every user.** The participant count is the number of participations of an event, counted with no filtering. What is confidential is the **link between a participation and a person** — only a connection can read the profile a participation points at and recognise who it is — never the participation record itself. See need 1: this is the constraint the package does not currently let the app satisfy.
+5. **The count is never a stored, incremented field.** Reading a counter, adding one and writing it back derives each write from a read of the previous one and races itself through any data provider. This is measured, not theoretical, and it is why the app derives the count from the participation list at read time.
+6. **Changes must be pushed, not polled.** Neither the app nor its BDD suites has a polling loop, and adding one is ruled out by project doctrine. `liveMode: 'auto'` is mounted on that basis.
+7. **No process-global state that outlives a remount.** Two backends coexist in one page and the user switches between them at runtime; switching remounts Refine to discard the cache of the backend being left. Building this backend's providers must have no side effect that accumulates across switches — see friction 1, which is where this currently bites.
+8. **Each entity carries a declared visibility** — public, protected or private, per the product's confidentiality model — and it is the backend that honours it. Refine has no notion of it, so the intent is declared at the seam and enforcement is the backend's.
+
+## Frictions
+
+1. **`authProvider` installs a timer and a listener it never removes.** Construction registers a `setInterval` and a `visibilitychange` listener with no teardown. Festipod builds providers once per backend selection, so every switch to this backend would accumulate another pair — directly against constraint 7. Workaround carried: pass `appStatusCheckInterval: false` and call `getAppStatus()` on the app's own schedule. That works, but it means the package's own staleness handling is unusable here, and the only way to opt out is to opt out entirely.
+2. **`getList` fetches the whole container on every call.** Filtering, sorting and pagination run in memory afterwards, so the cost of listing an event's participations grows with the user's total number of participations rather than with the event. No workaround; it is why a filter on a `getList` buys nothing beyond convenience.
+3. **A list subscription reports membership only.** A container channel delivers `Add`/`Remove`, not a member's own fields changing, so a list of events does not refresh when an event's title, place or time is edited. Watching each record instead would open one channel per row. The event list is exactly the screen where this is visible.
+4. **`types` takes precedence over `shapeTreeUri`, the opposite of what the configuration type documents.** The declared behaviour is that `types` is "only used as a fallback when `shapeTreeUri` is not set"; a resource setting both is in fact resolved from `types`. Establishing which one actually wins cost a read of the resolution path. Configuring exactly one avoids it, but the documentation should say which wins.
+
+## Needs
+
+1. **A read that is not scoped to the logged-in user's own Pod.** Every container resolution — in `getList`, in `create`, and in a list subscription — runs against the session's own WebID. So `getList('events')` returns only the events the current user created, and `getList('participations')` only their own participations.
+
+   This blocks the product, not a detail of it. Festipod exists to let a user **discover other people's public events** and see **how many people have signed up** to a meeting point. Through this provider the app can show neither: no other user's event is reachable, and the participant count of constraint 4 cannot be computed from participations it cannot read.
+
+   The request is modest in shape, because the capability already sits one layer down: the package's own TypeIndex discovery takes a WebID as a parameter, and notes that the public TypeIndex is readable without any special grant. What is missing is a way to reach it **through the data provider** — a way to scope a `getList` (and the matching list subscription) to a given WebID, or to a set of them. Festipod has no interest in reimplementing container resolution beside the provider; that would put the app back in the business the provider exists to hold.
+
+2. **Releases that can be pinned, and a statement of what changes between them.** The package carries no git tags, so the only thing this repo can pin is a commit on a moving branch, and the only way to learn what an upgrade changed is to re-read the source. Tagged releases plus a note of what moved in each — in whatever form suits the project — would let a consumer upgrade deliberately instead of re-observing from scratch every time.

.project/concepts/data-layer/brief_2026-10-03_structure-for-two-rights-models.md

@@ -0,0 +1,100 @@
+---
+type: brief
+summary: One persisted shape holding on BOTH backends — NextGraph (per-document encryption) and ActivityPods (WAC) — references rather than embedded content, no stored counter, with the acl:Append behaviour and the deduplication gap left open
+---
+
+# Brief (2026-10-03) — One data shape for two rights models
+
+Festipod puts all its persistence behind interchangeable Refine backends (the seam's own contract is in code, `src/shared/refine/providers/types.ts`). Two are targeted: NextGraph plus its polyfill, and `@activitypods/refine-providers`, whose reconstructed observation is pinned beside this leaf ([[contract_activitypods-providers]]). The question this brief answers: what structure survives both rights models unchanged.
+
+## The primitives, side by side
+
+| What is needed | ActivityPods | NextGraph |
+|---|---|---|
+| Unit of rights | LDP resource + WAC | **document** |
+| List attached to a resource | `as:Collection` attached by a predicate, `semapps:dereferenceItems` | a Set inside the document |
+| Let a third party contribute | `acl:Append`, or `apods:PostOutbox` to the recipient's inbox | `inbox.postToDocument` |
+| Grant "my connections" | `acl:agentGroup` + a WAC group | per-document sharing, once per connection |
+| Name without granting access | reference + WAC refuses the GET | reference carrying no key |
+| Revoke | `pod-permissions.remove` exists | not published |
+| Write offline | no (client-server) | yes (local-first) |
+
+## The design rule that follows
+
+**The common denominator is NextGraph**, whose model is the strict subset: no groups, no revocation, sharing wholesale per document. So structure for NextGraph and ActivityPods will serve that structure — more cheaply even, with groups. The converse does not hold: any structure that needs a server-side projection or a revocation is untenable on NextGraph.
+
+## The structure
+
+```
+Event                      own document, public, written by its creator
+  └─ participations        an attached list of REFERENCES (never embedded content)
+Participation              own document, owned by THE PARTICIPANT
+  ├─ event       → ref
+  ├─ active      → boolean
+  └─ participant → ref to the Profile
+Profile                    own document, protected
+```
+
+## Why references and not embedded content — three facts
+
+1. **Ownership.** The participation must be writable by its participant and by nobody else (withdrawal must be authoritative — [[caveat_participation-deletion]]). On NextGraph write access is granted per document, so the participation **must be** a document; embedded in the event it would be writable only by the event's creator.
+2. **Per-reader variation is impossible inside a single document on NextGraph**, because encryption and sharing are per document. It is obtained by **indirection**: the reference is always present, and what varies is the ability to **follow** it.
+3. [[rule_document-per-entity]] already says this, and says it for exactly this reason.
+
+## The non-visibility mechanism differs — PO precision, 2026-10-03
+
+On NextGraph the target is **undecipherable** for want of a key: nothing is absent, the reference itself is readable. On ActivityPods it is either inaccessible (WAC refuses the GET) or the reference is omitted by server-side projection. Both land on the same application state: **a reference one may or may not resolve.**
+
+## Consequence on the domain types
+
+The type models the NextGraph shape, where everything is present:
+
+```ts
+interface FpParticipationData {
+  id: string;
+  event: string;
+  active: boolean;       // NOT optional — the participation is readable by everyone
+  participant: string;   // NOT optional — a reference, which names without granting access
+}
+```
+
+Resolution alone may fail: `resolveParticipant(ref)` yields `FpUserData | undefined`, where `undefined` means "not a connection". ActivityPods' omission is a **degradation the binding absorbs**: it reports "a participation whose participant does not resolve" — the same state as "I do not hold the key".
+
+An error made in session and corrected here: `active?` and `participant?` were proposed first, which lifted the ActivityPods adaptation into the common model.
+
+## The count
+
+**No stored counter, ever.** The number of participants is `participations.length`. `knownParticipants` is the participations whose participant resolves — a presence test, not an access check. Withdrawal is `active: false` on one's own document.
+
+## The three invariants that make the app platform-indifferent
+
+1. One document per entity; never embedded content.
+2. A reference may be unresolvable, and that is a **normal state** — neither an error nor an absence (the app shows "someone").
+3. The list is an **upper bound that converges**; never assume it is complete at the instant (already documented by [[caveat_participant-count-one-connection-lag]]).
+
+## Open points
+
+### NOT VERIFIED — does `acl:Append` on a collection let a third party insert an item without being able to remove one?
+
+WAC mode enforcement lives in `@semapps/webacl`, absent from the ActivityPods checkout consulted and not installed. The mode is real and genuinely used (`tests/apps/example.app.js` declares `accessMode: ['acl:Read', 'acl:Append']`), but its behaviour on a SparqlPatch `INSERT DATA` / `DELETE DATA` was not observed.
+
+**The structure does not depend on the answer.** If Append works that way, the participant appends directly and the count is immediate. Otherwise the route is `apods:PostOutbox` to the creator's inbox, whose app adds the reference — which is exactly the NextGraph shape. Only the latency changes.
+
+### OPEN — deduplication: neither platform counts people, and the implementation here does not either
+
+[[brief_2026-07-20_attendance-set-model]] requires that the creator tell two references from the *same* person apart from two references from different people, **without knowing who** — otherwise the count is not a count of people and a participant can inflate it. **The code here does not do that** (verified 2026-10-05). A different problem is solved, and solved well: `materializeAttendance` (`src/shared/data/registration.ts`) keys its active set by a **per-deposit** `uid` minted from time plus randomness, so a broker re-sync replaying the same deposits converges instead of double-counting — that is **replay idempotence**, not person identity. The count is therefore a count of **deposits**: the same person joining twice counts twice. Three further findings about the current implementation:
+
+- **The plaintext `userId` travels in the deposit**, and the cancellation fallback depends on it — a leave without a known `regUid` cancels the earliest still-active join carrying that `userId`, so N leaves cancel N joins. The attendance-set brief's own change *"drop the `userId` from inbox deposits"* was never made, so the creator **does** know who and the anonymity property does not hold today. The privacy-preserving discriminator was never needed because the privacy was never implemented.
+- **Participations live in the protected scope**, not public, and withdrawal is still a deletion ([[caveat_participation-deletion]]) — so the target model is not in place either. The attendance-set brief's own status line, *model settled / implementation gated*, still holds.
+- **The gap was never raised through the declared channel.** The five frictions in this app's polyfill declaration (`polyfill-surface/usage_festipod.md`) cover inbox idempotence, the absence of a push on one's own deposit, the reactive read not seeing one's own write, the impossibility of resetting the test wallet, and a wrong published signature. None asks for a per-person discriminator.
+
+So the divergence is not "NextGraph has an upstream gap while ActivityPods does not": **both count deposits rather than people.** ActivityPods could arbitrate server-side because the server sees everything; NextGraph awaits a primitive. And the gap sits in **neither Refine provider** — it is in the polyfill on one side and the server on the other, which is what matters when deciding what to contribute where. The upper bound remains the common fallback position, already accepted by the PO.
+
+## Two ActivityPods constraints not to rediscover later
+
+- **The Refine providers cover CRUD only.** Creating the collection, setting WAC, creating a group, posting to the outbox are not in the data provider, which does not implement Refine's `custom` either — so there is no escape hatch through Refine and those calls happen beside it.
+- **A custom ontology prefix must be registered at prefix.cc**, the Pod provider requiring every ontology to have a known prefix; this concerns our `fp:`. Shape trees must also sit at a public URL, one per entity, since they cannot reference other shapes — no sharing cascade.
+
+## Reservation to keep alive
+
+The reference to the profile is readable by everyone and therefore collectable: it is a **correlatable pseudonym, not anonymity**, and must never be presented as such. The reservation comes from the attendance-set-model brief, and the 2026-10-03 precision reactivates it.

.project/contracts.yaml

@@ -1,7 +1,10 @@
-# Inter-repo contracts. Festipod is a CONSUMER only: it publishes no interface of its own,
-# and it consumes two — the SDK surface `@ng-eventually/polyfill` engages toward the
-# applications built on it, and the indexing layer `ng-helpers` engages toward the
-# applications that need to make things findable.
+# Inter-repo contracts. Festipod publishes no interface of its own — what it lists under
+# `publish:` is its own consumer-side DECLARATION, the channel a provider pulls to learn
+# what this app calls, what it needs and what blocks it. It consumes three — the SDK
+# surface `@ng-eventually/polyfill` engages toward the applications built on it, the
+# indexing layer `ng-helpers` engages toward the applications that need to make things
+# findable, and the Refine data providers `@activitypods/refine-providers`, which engage
+# nothing at all.
 #
 # The pulled copy under `into:` IS the specification Festipod codes against. An agent
 # working here reads that copy and never opens the provider's own source: a gap is raised
@@ -9,7 +12,7 @@
 #
 # Each interface gets its own FOLDER inside the concept that owns it, holding the pulled
 # engagement and — once Festipod actually consumes the interface — the `usage_festipod.md`
-# declaration beside it. Both interfaces land in `data-layer`: it is the concept that owns
+# declaration beside it. All three land in `data-layer`: it is the concept that owns
 # how Festipod uses an external data surface, including the machinery behind discovery
 # (`functional-domain` owns the product intent of discovery and explicitly delegates its
 # technical how to the data SDK).
@@ -19,6 +22,11 @@
 # access to a local checkout lives in `.project/contracts.local.yaml`, which is never
 # committed.
 
+publish:
+  # Key qualified by interface: a second declaration is coming for the NextGraph+polyfill
+  # backend, and publish keys must stay unique.
+  activitypods-providers--festipod: concepts/data-layer/activitypods-providers/usage_festipod.md
+
 consume:
   - contract: polyfill-surface
     into: concepts/data-layer/polyfill-surface/
@@ -43,3 +51,21 @@ consume:
     # Pinned on the TAG, never on a branch: a branch moves under us and the pin would stop
     # naming a state anyone can go back to. Re-pin to the next tag at each upgrade.
     ref: v1.0.1
+
+  - contract: activitypods-providers
+    into: concepts/data-layer/activitypods-providers/
+    # `@activitypods/refine-providers` publishes NO engagement: no contract document, no
+    # stated change policy, not even a git tag. So this entry is `type: reconstruct` — the
+    # one bounded crossing this protocol allows, made once at adoption time: the leaf under
+    # `into:` is OUR observation of that package, authored here and pinned to the commit it
+    # was read at. It is not a promise anyone made us, and every upgrade has to re-observe
+    # it. Once reconstructed, that leaf IS the specification this app codes against.
+    type: reconstruct
+    # Canonical identity: the package's git remote plus the repo-relative folder the
+    # observation was made from. Per-developer access to a checkout of it lives in
+    # `.project/contracts.local.yaml`, which is never committed.
+    reconstructFrom: https://github.com/activitypods/refine-providers.git/src
+    # The branch the observation was read from. A tag would be the better pin, but this
+    # repository publishes none — the resolver turns this into the commit actually read,
+    # which is what `built_version` records.
+    ref: master