Residual Audit — Editorial / Studio / Customer Curation (features.md 1588–1807)

Date: 2026-06-11. Read-only static audit of the residual after the 06-10 ground-truth audit's 57 tasks landed. Evidence = current source only.

Headline verification#

The 06-10 headline — "No persisted authored artifact; lanes are stateless analyzers" — is STILL TRUE for editorial content, with three narrow nuances:

• The /v1/admin/studio/* lane "stores" remain pure analyzers over caller-supplied JSON (verified: approval-workflow-store.ts, comment-thread-store.ts, asset-rendition-store.ts, file-ingestion-store.ts — all documented and implemented as "pure + deterministic; 0 Date.now/random" evaluators with no record persistence). No comment, approval, asset, or i18n state survives a request.
• What DOES persist now: editorial release-streams (durable store + admin panel, see finding on enforcement), the C8 communications loops (banners/help/templates/ status), opaque per-user workspace preferences (studio/workspace-state-store.ts — explicitly "density, viewport mode, saved filters", not artifacts), and the game-domain authoring records (Hathor story-graph/quest, Bellona — out of this slice's editorial-content scope but real persistence).
• @oshun/studio-authoring still has exactly 1 consumer (StudioAuthoringWorkspace.tsx, importing 7 functions from authoring-blocks + evaluatePublishReadiness); @oshun/customer-curation gained exactly 1 consumer (the sharing engine via library/share-policy-store.ts). Everything else in both libs remains orphaned.

Nisaba seeds fabricated notebooks and annotations as the member's own, ungated in production#

Severity: P0-HONESTY

Evidence:

• apps/oshun/bff/src/nisaba/state.ts:847-856 — getInternalRecord lazily calls buildSeedRecord(userId) for EVERY user; no allowFixtures()/production gate anywhere in the file.
• apps/oshun/bff/src/nisaba/state.ts:1563-1581 — seed annotation nisaba-annotation-compassion-1 is attributed author: { userId, displayName: deriveDisplayName(userId) } with note text the member never wrote ("The cessation is framed as a rule, not a feeling.") and fixed timestamps (2026-03-22/23).
• apps/oshun/bff/src/nisaba/state.ts:1586-1625 — two seed notebooks (nisaba-notebook-attention, nisaba-notebook-compare) populated with items.
• apps/oshun/bff/src/search/user-object-candidates.ts:75-79 — C7's universal search ranks nisabaConsumerStateStore.listNotebooks(userId) as the member's "REAL objects", so a brand-new member searches and finds two notebooks "they" curated.
• No seedDataNotice (the E1 labeling pattern) on any /v1/nisaba/notebooks response (grep -i seed routes/nisaba.ts → 0 hits).

Spec promise: features.md 1768 ("Customer-controlled notebooks…"), 1786-1788 (annotation durability tests). D6 fixed PASSAGE reading state to honest-zero (state.ts:876 comment) and C4 killed the identical Iris seed pattern — this same class survived in the notebook/annotation seed.

What the code actually does: serves every member identical fabricated notebooks and self-attributed annotations as durable-looking personal data, and surfaces them in search results among real saves.

Fix sketch: start buildSeedRecord with empty notebooks/annotations maps (keep corpus passages, evidence views), or gate the personal seeds behind allowFixtures() + an explicit seed label, mirroring C4/E1.

Collections exist as two disconnected systems (server store vs localStorage fixtures)#

Severity: P0-STRUCT

Evidence:

• Server system: apps/oshun/bff/src/routes/domain-stubs.ts:2482-2540 — GET/POST /v1/library/collections, auth-scoped, persisted (domain-stubs-store.ts:164-199, snapshot/Postgres-backed); written by apps/oshun/web/src/app/library/collections/new/LibraryNewCollectionForm.tsx:51, read by app/library/collections/page.tsx:45 and by universal search (search/user-object-candidates.ts:57-64).
• Client system: apps/oshun/web/src/components/library/LibraryDashboard.tsx:106-162 ships 4 hardcoded fixture collections (evening-integration, research-to-practice, sky-and-scripture, learning-reentry) + LIBRARY_COLLECTION_ITEM_IDS; all collection CRUD (handleCreateCollectionFromFilters :830, handleSaveCollectionDetails :880, handleToggleCollectionItem :893, handleArchiveCollection :905) mutates React state + localStorage (oshun.library.collections.v1, :642-650). The dashboard NEVER fetches or posts /v1/library/collections (zero network calls for collections in the file).
• LibraryDashboard is the component behind both /library and /library/collection/[collectionId].

Spec promise: features.md 1768-1772 (customer-controlled collections, ordering, import); 1788 ("progress sync across devices").

What the code actually does: a collection created on /library/collections/new is durable and searchable but never appears in the dashboard's collection manager; a collection created/edited/archived in the dashboard is device-local, invisible to the index page, to search, and to other devices. E2 fixed exactly this split for saved ITEMS but left collections behind. The fixture collections are also unlabeled and prod-visible (the BFF-side fixture merge at domain-stubs.ts:2500 is allowFixtures()- gated; the client-side ones are not).

Fix sketch: back the dashboard's collection state with /v1/library/collections (reuse the saved-items LWW sync pattern from webLibraryStore.ts); drop or guest-gate the client fixture collections.

/studio/authoring: unlabeled fixture document, fabricated governance bindings, and a "saved" claim with zero persistence#

Severity: P0-HONESTY

Evidence:

• apps/oshun/web/src/components/studio/StudioAuthoringWorkspace.tsx:23-64 — SEED_DOCUMENT (doc-demo, "Morning Tara Practice"); :101-108 DEMO_BINDINGS with fabricated governance ids (sophiaEvidencePackId: 'ep-tara-baseline', lilithToneReviewId: 'tr-2026-05-12-tara') never read from Sophia/Lilith/Isis.
• :415-438 — edits run the lib's acceptAutosave and set autosaveStatus = 'saved @ lamport=N'; nothing is written anywhere (the only network calls in the file are the readability lane, :170/:220). Reload discards the document. The component doesn't even use the available /v1/studio/workspaces/:id/state preference store.
• :740-741 — publish readiness renders "✓ All bindings satisfied — eligible for normal pipeline" computed from the fabricated DEMO_BINDINGS; :787 — AI assist renders "request is eligible for upstream agent" — no upstream agent exists or is called.
• No demo/preview labeling anywhere in the render; DomainPreviewBanner covers /domains/* only (components/domains/DomainPreviewBanner.tsx:1-13) — this surface is uncovered.

Spec promise: features.md 1638-1640 ("Save, autosave, draft locking, … recovery, named checkpoints"), 1620-1624 (authoring "governed by Sophia grounding, Isis … policy, and Lilith tone policy").

What the code actually does: a demo harness over real lib evaluators, presented with the same visual authority as a live workspace, telling the operator their work is "saved" and governance-bound when neither is true.

Fix sketch: label the surface as a fixture rehearsal until persistence lands, change "saved" to an honest "in-memory only" status, and source bindings from real reads or render them as explicitly unbound.

Atelier/Lilith-studio scenes: global unscoped store with unauthenticated read and write#

Severity: P0-SEC

Evidence:

• apps/oshun/bff/src/routes/domain-stubs.ts:2543 — GET /v1/atelier/scenes has NO preHandler (no auth); it lists domainStubsStore.scenes.list().
• apps/oshun/bff/src/routes/domain-stubs-store.ts:215-246 — the scenes store is a global Map with no ownerUserId; list() returns every row to every caller.
• domain-stubs.ts:2565 (POST /v1/lilith-studio/scenes) and :2597 (POST /v1/atelier/scenes) take only originGuard, csrfGuard — no auth guard — and persist into the same global store.

Spec promise: features.md 1786 ("sharing-permission isolation"); cf. A7, which fixed exactly this for library collections.

What the code actually does: any unauthenticated caller can write scene records, and every user's authored scene titles (e.g. practice/ritual titles, which are personal) are served to every other user and to anonymous callers.

Fix sketch: add the auth preHandler to all three routes, add ownerUserId to StoredAtelierScene/StoredStudioScene, and filter list() by owner exactly as LibraryCollectionStore.list does. (Cross-slice note: atelier may belong to the generation slice; flagged here because it shares the curation route file/store.)

Share-link journey dead-ends: minted URLs route nowhere and the grant carries no content#

Severity: P1

Evidence:

• apps/oshun/bff/src/library/share-policy-store.ts:318-321 — created links point at https://oshun.app/share/<token> / oshun://share/<token>.
• No app/share route exists in the web app (find apps/oshun/web/src/app -d -name "share*" → only a Bellona studio dir); only lib/deep-link-associations.ts:12-13 declares the path for OS association files.
• apps/oshun/bff/src/routes/library-sharing.ts:213-244 — the recipient resolution endpoint GET /v1/library/shared/:collectionId returns ONLY { collectionId, granted, tier, via } — never the collection's label or items — and a repo-wide grep finds zero callers (web, mobile, miniapp).
• Mobile's deepLinkHydration.ts:103-124 parses /share/<token> into a share route, but share/mobileShareIngest.ts is the inbound share-INTO-app system; nothing resolves a collection share token to content.

Spec promise: features.md 1773-1775 (shared via link with view/comment/copy permissions).

What the code actually does: an owner can mint a cryptographically sound link whose recipient lands on a 404 page, and even calling the API directly yields a permission verdict with nothing to view. The engine is real; the journey delivers nothing.

Fix sketch: add a /share/[token] web page that calls the resolve endpoint, and extend the resolve response (on grant) with the collection label + items read from domainStubsStore.collections.

Share-policy ownership is first-writer-wins and collides on fixture collection ids#

Severity: P1

Evidence:

• apps/oshun/bff/src/library/share-policy-store.ts:140-158 (setVisibility) and :186-194 (createShareLink) — when no policy exists for a collectionId, the caller becomes its owner; ownership is never checked against the actual collections store (domainStubsStore.collections has ownerUserId, never consulted).
• apps/oshun/web/src/components/library/LibraryDashboard.tsx:1051 — share controls operate on selectedCollection.id, which for every member includes the SAME four fixture ids (evening-integration …, :106-162).
• Collection ids are guessable (col-<Date.now()>-<seq>, domain-stubs-store.ts:174).

Spec promise: features.md 1786 ("sharing-permission isolation").

What the code actually does: the first member to touch sharing on evening-integration owns it tenant-wide — every other member then gets 403 "Only the collection owner can change its sharing" on a collection their own UI presents as theirs. A malicious member can likewise pre-claim the share policy of another member's real collection id and lock them out of sharing it.

Fix sketch: on first policy creation, verify the caller owns collectionId in domainStubsStore.collections (404/403 otherwise); becomes automatic once finding #2 unifies the two collection systems.

Share policies/links are not durable — every minted link dies on deploy#

Severity: P1

Evidence: librarySharePolicyStore is a plain in-memory Map (share-policy-store.ts:101) with a reset() but no snapshot wiring; it is absent from the wireDurable* roster in apps/oshun/bff/src/server.ts (which durably wires ~40 sibling stores, including living-scene shares at :106).

Spec promise: features.md 1773-1775; links are offered with 30-day and "No expiry" presets (CollectionShareControls.tsx:79-83).

What the code actually does: hands the member a long-lived URL whose server-side grant evaporates on the next restart (library_collection_not_found 404).

Fix sketch: add toSnapshot()/hydrate() + wireDurableLibrarySharePolicies in server.ts, same pattern as wireDurableLivingSceneShares.

User-created Nisaba notebooks/annotations are in-memory only#

Severity: P1

Evidence: nisabaConsumerStateStore (apps/oshun/bff/src/nisaba/state.ts:859) is a plain class instance; no snapshot serialization exists in the file and server.ts has no nisaba wiring (grep nisaba server.ts → 0). Meanwhile createNotebook (:704), addNotebookItem (:764), annotation CRUD (:552-633) are real per-user mutations exposed at POST /v1/nisaba/notebooks (+items) and used by the live web forms (app/nisaba/notebook/new/NisabaNewNotebookForm.tsx:43).

Spec promise: features.md 1786-1788 ("annotation durability and progress sync across devices").

What the code actually does: a member's authored notebooks and annotations — the one real authored-artifact write path in this slice — are lost on every deploy, while the fabricated seeds (finding #1) come back.

Fix sketch: add snapshot persistence (wireDurableNisabaConsumerState) following the Telegram-user-state / iris-memory pattern (explicit Map/Date serialization).

/studio/authoring is an orphan route — nothing links to it#

Severity: P1

Evidence: repo-wide grep for studio/authoring in apps/oshun/web/src matches only the page itself (app/studio/authoring/page.tsx); the studio hub (app/studio/page.tsx) links sibling lanes (e.g. review-approval-workflows is linked from the hub and four other pages) but never authoring. Only e2e specs visit it by URL.

Spec promise: features.md 1592-1596 (authoring "exposed through Oshun Studio rather than buried", "first-class product surfaces").

What the code actually does: the slice's flagship §16.2 surface is unreachable by any in-app navigation.

Fix sketch: add the authoring card/link to the studio hub catalog (and command palette), or fold the workspace into a linked surface.

Editorial lifecycle state machines (×2) have zero runtime consumers; live content uses ad-hoc states#

Severity: P1

Evidence:

• libs/oshun/studio-authoring/src/editorial-lifecycle/lifecycle.ts:15-44 — the full 12-state canonical machine + gate-checked tryEditorialAdvance; zero imports outside the lib (repo grep).
• libs/oshun/domain-veritas/src/editorial/state-machine.ts:1-29 — a SECOND 12-state editorial machine (Veritas variant, exported as EditorialStateMachine); zero imports in any app.
• The content that actually publishes (admin communications help articles/banners, C8) and the release-streams store each use their own small status enums; persona lifecycle (admin/persona-lifecycle-store.ts) reuses 'in-review' textually but not the machine.

Spec promise: features.md 1651-1657 ("Canonical content lifecycle states reused across all domains" + the ARCHITECTURE diagram cross-ref).

What the code actually does: two orphaned canonical machines and N ad-hoc per-store status enums — the canonical-reuse promise is inverted.

Fix sketch: when any artifact persistence lands (notebooks aside, the help-article store is the nearest fit), drive its status transitions through tryEditorialAdvance; retire or delegate the Veritas duplicate.

Editorial release streams: embargo/blocked states stored but never enforced#

Severity: P1

Evidence: apps/oshun/bff/src/admin/admin-editorial-release-streams-store.ts is a real durable store with kinds incl. embargo (requires embargoLiftsAt, :153) and a validated status machine (:209-224); its ONLY consumers are its own routes (routes/admin-editorial-release-streams.ts, mounted at /v1/admin/editorial/release-streams) and the admin panel (apps/oshun/admin/src/components/EditorialReleaseStreamPanel.tsx). No publish, generation, communications, or delivery path reads stream status or embargoLiftsAt (repo grep for the store outside its own route → 0).

Spec promise: features.md 1664-1666 (embargo/takedown/hotfix flows that bind editorial decisions), 1671-1673 ("embargo respect" tests).

What the code actually does: an operator can mark a subject "blocked" or embargoed until a date, and nothing anywhere prevents or delays anything.

Fix sketch: at minimum, have the C8 communications publish path and the generation release leg consult open release streams for their subject ids before serving; or document the store as advisory-only in the route header.

Orphaned engine census: 7 of 9 studio-authoring module families and 5 customer-curation modules still have zero consumers#

Severity: P2

Evidence (repo-wide import grep, non-test):

• @oshun/studio-authoring consumed: authoring-blocks (5 files) + editorial-lifecycle/pipeline.evaluatePublishReadiness — all via the single demo workspace. Zero consumers: creator-roles/ (roles, onboarding, scorecards), asset-metadata/ (metadata, approval-queue, bulk-upload, EXIF/presets, analytics), templates/ (+rehearsal), localization-workflow/ (translation, glossary, locale-formats), versioning/ (+branching), taxonomy-curation/ (+stewardship), collaboration/ (+routing), editorial-lifecycle/lifecycle+recurrence.
• @oshun/customer-curation consumed: sharing/sharing (share-policy-store). Zero consumers: collections/ (ordering, smart-collections, templates, import-from-another), annotations/, share-cards/, version-awareness/. (bookmarks/ non-use is a documented deliberate deviation in library/saved-items-store.ts:9-16 — NOT a finding.)

Spec promises with no runtime today as a result: smart collections (1771), drag-and-drop ordering/nesting/import (1771-1772), customer version awareness "show diff" (1784-1785), embeddable share cards with provenance (1776-1778), per-artifact versioning/diff/rollback (1734-1746), translator workspace (1715-1733), taxonomy curation (1694-1714), template gallery (1793-1806), creator roles/queues (1601-1615).

Fix sketch: this is the wiring backlog the 06-10 audit named ("orphaned libraries are mostly excellent code — the work is wiring"); none of the 57 tasks touched it, and no recorded V1.x deferral covers these sections. Needs an explicit build-or-defer decision per family.

Reading progress is a write-less field#

Severity: P2

Evidence: nisaba/state.ts:891 serves progressPercent: 0 (honest-zero per D6) and lastReadAt: ''; no route or store method ever updates them (grep -i progress routes/nisaba.ts → serialization only, :2131).

Spec promise: features.md 1782-1783 (reading progress, time-to-finish, resume across devices).

What the code actually does: honest, but the field can never change — progress UI downstream will show 0% forever.

Fix sketch: add a POST /v1/nisaba/passages/:id/progress (or fold into the client-state E6 sync) updating the per-user record.

Collections page copy promises interactions that don't exist#

Severity: UX

Evidence: apps/oshun/web/src/app/library/collections/page.tsx:79-81 — "Drag and drop, reorder, share or keep private". No drag-and-drop or manual reorder exists anywhere (the customer-curation/collections/ordering.ts engine is orphaned; the dashboard only toggles membership, LibraryDashboard.tsx:893-903); "share or keep private" routes through the broken journeys in findings #5/#6.

Spec promise: features.md 1771.

Fix sketch: soften the copy until ordering ships, or wire the orphaned ordering engine into the dashboard's collection item list.

Collections deep-links drop the selected collection#

Severity: UX

Evidence: app/library/collections/page.tsx:101 and app/library/collections/new/LibraryNewCollectionForm.tsx:112 both link to /library?collectionId=…, but /library's page reads only domain/kind (app/library/page.tsx:37-44) and passes no initialCollectionId; the working route is /library/collection/[collectionId] (app/library/collection/[collectionId]/page.tsx:35). Compounded by finding #2: even the correct route can't resolve a BFF collection id, because the dashboard's collection list comes from localStorage/fixtures (resolveInitialCollectionId over defaultCollectionSnapshot.collections, LibraryDashboard.tsx:588-590).

Spec promise: features.md 1768-1772.

Fix sketch: point both links at /library/collection/<id>; real resolution requires finding #2's unification.

Telegram /save captures are write-only — no surface ever shows them#

Severity: UX

Evidence: B12 wired real capture writes (telegram/user-state-store.ts) and a self-scoped GET /telegram/captures, but a repo-wide grep finds no web/mobile/miniapp reader of that route; captures never appear in the library, notebooks, or search (search/user-object-candidates.ts reads saved items/collections/notebooks/habits only).

Spec promise: features.md 1768 (notebooks/collections "across all domains") + the messaging capture journey.

Fix sketch: either surface captures in the library (a telegram source lane) or feed them into the saved-items store instead of a parallel silo.

Annotation system exists only in Nisaba#

Severity: UX

Evidence: per-user annotations live solely in nisaba/state.ts and the /v1/nisaba/annotations routes; Veritas stories, Metis lessons, and Tara transcripts have no annotation write path (no annotation routes outside nisaba.ts; the customer-curation/annotations cross-artifact engine is orphaned).

Spec promise: features.md 1779-1781 ("Annotation system across reading surfaces (Nisaba editions, Veritas stories, Metis lessons, Tara transcripts) … cross-artifact backlinks, and export").

Fix sketch: lift the nisaba annotation store to a shared per-user store keyed by (surface, artifactId) (the orphaned lib engine already models this), then mount on Veritas/Metis/Tara readers.

Studio editorial lanes share no artifact identity — authoring can't flow into review, comments, or localization#

Severity: UX

Evidence: /studio/authoring links to review-approval-workflows / commenting-annotation-system / real-time-collaboration-substrate / asset-preview / i18n (app/studio/authoring/page.tsx:20-35), but each console evaluates caller-pasted JSON against its stateless analyzer (e.g. StudioReviewApprovalWorkflowsWorkspace.tsx:116 POSTs a hand-typed stages payload to /v1/admin/studio/approval-workflow); none accepts a document/artifact id, so the authored document (itself unpersisted) cannot enter any of the linked workflows.

Spec promise: features.md 1601-1693 model one pipeline over shared artifacts (author → review → comments → publish → localize).

Fix sketch: once an authored artifact persists (finding #3's fix), thread its id through the lane consoles as the default payload source; until then the cross-links oversell continuity.

Severity counts#

Adversarial scan notes: the mandatory stub-grep over libs/oshun/studio-authoring, libs/oshun/customer-curation, bff/src/library, bff/src/nisaba returned zero actionable hits (both libs are clean, real domain code — the problem is wiring, not fabrication, except where listed above). Math.random() scan clean. Known lane-console architecture and recorded deviations (bookmarks engine non-reuse; BFF fixture merges behind allowFixtures()) were excluded as designed/documented behavior.