@super-ic/app-patterns

Display-only application patterns for SuperIC product surfaces: the browse listing card, the filter grammar (bar, chip, chip row), the category tile strip, the messaging run and conversation preview rows, and the step-flow progress and footer chrome.

Every pattern is a projection renderer. The consumer computes every string (prices, dates, counts, verbs, labels) and the pattern only arranges them. Data fetching, auth, favourite state, routing and the full-filter sheet all stay in the consumer. Icons and media enter as ReactNode slots, so this package pulls in no icon vendor and no image loader of its own.

Install

npm install @super-ic/app-patterns @super-ic/foundation

Peer dependencies

| Peer | Range | Why | | --- | --- | --- | | react | >=19.0.0 | Components return JSX and use the React 19 automatic runtime. |

react-dom is not a peer dependency. Nothing in dist/ imports it; the patterns are renderer-agnostic and work under react-dom, react-dom/server or any other React 19 renderer the consumer supplies.

The foundation token layer is required

Most existing patterns carry Tailwind utility strings that resolve colour, elevation, radius and motion through CSS custom properties. HomeRecipe and BrowseListingCard also ship an ordinary scoped stylesheet. The properties live in @super-ic/foundation, and the token sheet must be imported once, high in the application:

// app/layout.tsx (or your single global CSS entry)
import "@super-ic/foundation/tokens.css";
import "@super-ic/app-patterns/home.css";

@super-ic/foundation is a peer dependency of this package (^0.2.0). npm warns when it is missing. Install it explicitly and import the token sheet once, high in the application.

The custom properties consumed by dist/ are:

--control-elevation-surface, --elev-card, --elev-pill, --foreground, --motion-ease-quiet, --motion-hover-duration, --muted, --muted-2, --muted-foreground, --primary, --primary-foreground, --radius-lg, --ring, --shadow-lg, --surface, --surface-2.

Tailwind v4

Tailwind v4 does not scan node_modules. Import the package's public bridge after importing Tailwind once. The bridge scans this package's distributed JavaScript and includes the public primitives bridge. HomeRecipe and BrowseListingCard are fully styled by the public home.css entry and do not depend on this scan:

@import "tailwindcss";
@import "@super-ic/app-patterns/tailwind.css";

Usage

import "@super-ic/app-patterns/home.css";
import { BrowseListingCard, FilterBar, FilterChipRow } from "@super-ic/app-patterns";
import { Icon } from "@super-ic/icon-contracts";

<BrowseListingCard
  href="/listings/hedge-trimmer"
  listing={{
    title: "Hedge trimmer",
    verb: "Borrow",
    priceLine: "$12/day",
    neighborhood: "Riverside",
    media: <img alt="" src={photo} />,
    mediaPresentation: "image",
    specCells: [{ key: "power", label: "Corded" }],
    rating: { average: "4.8", count: 26 },
  }}
  favoriteIcon={<Icon name="action.favorite" decorative />}
  onToggleFavorite={toggle}
/>;

BrowseListingCard uses a noninteractive outer article. Its primary anchor contains the media and body, while Save and Quick View are sibling buttons. The DOM and focus order are primary link, Save, then Quick View. Supply only noninteractive content through media. mediaPresentation defaults to image and keeps the 16:9 media geometry. Set it to symbol for a deliberate compact no-photo well with a semantic icon.

Discovery workspace

DiscoveryWorkspace is a controlled search-and-results projection. Import it from @super-ic/app-patterns with @super-ic/app-patterns/discovery.css and @super-ic/app-patterns/need-entry.css. Its optional sort projection supplies a visible label, current value, options and onChange; it does not rank or update URLs. Ready results may supply pagination with more, loading, failed, or end state. The product owns cursors and appends or replaces records. Pagination preserves current rows, has no automatic fetch or scrolling, and temporarily disables its action while a background refresh is loading. Empty results may include a decorative illustration. The recipe hides a failed illustration without hiding the supplied explanation or actions.

HomeRecipe renders activity, browse and asks in that order without adding a main or h1. Each section receives a controlled loading, ready, empty or failed state. Ready content can carry refreshing or failed refresh status while keeping the supplied rows or cards mounted. The product adapter supplies all labels, links, callbacks and state changes.

Exports

All exports come from the package root; there are no subpath entry points.

| Group | Exports | | --- | --- | | Browse card | BrowseListingCard, BrowseListingCardProps, BrowseListingCardProjection, BrowseListingHeadingLevel, BROWSE_LISTING_FIXTURES | | Member home | HomeRecipe and its HomeRecipe* state, section, row, card-slot, action and density types | | Filtering | FilterBar, FilterBarProps, FilterChip, FilterChipProps, FilterChipRow, FilterChipRowProps | | Categories | CategoryTile, CategoryTileProps, CategoryTileProjection, CategoryTileStrip, CategoryTileStripProps, CATEGORY_FIXTURES | | Messaging | MessageRun, MessageRunProps, MessageRunProjection, MessageProjection, ConversationPreviewRow, ConversationPreviewRowProps, ConversationPreviewProjection, MESSAGE_RUN_FIXTURES, CONVERSATION_PREVIEW_FIXTURES | | Create flow | StepFlowProgress, StepFlowProgressProps, StepFlowFooter, StepFlowFooterProps, CREATE_FLOW_STEP_FIXTURE |

The *_FIXTURES values are display-only sample projections for stories and visual tests. They are not product data and must never be rendered to users.

Shared composition rules

• Surface separation. BrowseListingCard uses the documented elevated card treatment. Agreement panels and member collections use their own accepted border and row recipes; the browse card's treatment is not a rule for every surface.
• 44px effective targets. Interactive affordances meet the minimum touch target even where the painted box is smaller.
• Real cells only. A null projection field contributes no spec cell, ever. The patterns never render an empty slot or a placeholder dash.
• Reduced motion respected. Every transition carries a motion-reduce: escape.

Member collections

Import MemberRecordList and its types from @super-ic/app-patterns, with @super-ic/app-patterns/member-record-list.css. Compose it inside MemberShell, which owns the main landmark and page heading. One native destination per row opens the full offer, request, notice context or support case. Opening a row does not accept terms, mark a notice read or submit a money command.

The consumer supplies authorized MemberRecord summaries and a MemberCollection projection. Ready, empty, loading and failed are distinct. A failed background refresh and failed load-more retain existing rows. Filters are controlled buttons with pressed state; pagination remains an explicit consumer callback. Replace the projection immediately when the actor changes or access is withdrawn. This component does not authorize, fetch, sort, paginate or mutate records itself.

The named Saved offers composition uses existing BrowseListingCard instances inside a semantic ul with the public home-recipe-card-grid layout from home.css. It supplies actual media or an explicit no-photo label, native detail links and controlled saved-state buttons. Products own persistence, failure recovery, undo and focus after an item is removed. Example state is local and fictional; no example callback establishes server success.

Package shape

ESM only ("type": "module"), with types alongside JavaScript in dist/ and scoped ordinary CSS in css/. The manifest marks CSS as a side effect so bundlers retain explicit stylesheet imports. Sources, tests and build tooling are not packed.

Message payloads

MessageProjection requires one text body or one media slot. Split a caption into a separate text message. MessageRun rejects mixed payloads, blank text and absent or null/boolean media instead of silently dropping written content. The consumer owns accessible media content, server projection validation and error recovery. This is a candidate API change; update existing object types before adopting the package.

Member entry candidate

MemberEntryFrame, MemberAccess and ResidencyEntry are controlled web recipes, not authentication or membership authorities. Import them from @super-ic/app-patterns and import @super-ic/app-patterns/member-entry.css. Compile the public app-patterns Tailwind bridge at the consumer root. Optional self-hosted font CSS belongs in direct JS/root-layout imports, outside the Tailwind stylesheet import chain.

The frame keeps the resident's original intention visible beside a single task on wide screens and above it in a narrow container. The optional, captioned context image is omitted on narrow screens. The recipe uses current canonical type, spacing, neutral controls, error colors and border-based surfaces. It has no invented density modes.

| Export | Controlled responsibility | | --- | --- | | MemberEntryFrame | Supplied brand/home route, context and optional captioned media, help/back actions, busy, screenKey, optional focusOnTransition and skipLabel. Owns the page's single main landmark. | | MemberAccess | Supplied heading plus one form or notice. Intended for account entry, email-link acknowledgment, password setup/recovery and interrupted setup. | | ResidencyEntry | Supplied heading plus one form or notice. A form may include radio methods with explicit available/unavailable reasons before its fields. Selected method limitations and all unavailable reasons remain visible. | | MemberEntryForm | Current MemberEntryBinding, controlled fields, optional bound consent, submit/pending labels, MemberEntrySubmission, callbacks, real route links and optional secondary actions. | | MemberEntryNotice | Product-supplied facts, note, acknowledgment, async submission state and actions. No status or eligibility is inferred from these values. |

MemberEntryField supports text/email/password/textarea and a select with consumer-supplied options. Each field needs a unique stable id and visible label. Use the appropriate autoComplete; password reveal needs both showLabel and hideLabel. Uploads are not part of this recipe. Fields, methods, facts and links must have unique IDs/keys. Do not place interactive controls inside method descriptions or the frame's image.

Forms use consumer validation. Supply the inline field/consent/method error and increment validationAttempt on every submit attempt so repeated identical errors focus the first invalid control. The recipe binds the visible label, hint and error; radio names use only the method title, with details separately described. Tab, Space and arrow keys retain the primitive's behavior. Password visibility is local presentation state only.

During submission, the consumer passes the same busy state to the frame and form/notice. The form disables fields and actions while submission.state is submitting. The consumer must also lock commands synchronously before awaiting a response; a rendered busy state alone cannot prevent two submissions in the same event turn. Server idempotency remains required. Its consent region is inert so embedded legal links cannot escape the in-flight command. Navigation links become explicitly unavailable until the command settles. Failures retain consumer values and are announced; successful refresh/resend acknowledgments need a truthful supplied acknowledgment. The frame's skip link focuses main. On a changed screenKey, it focuses the new h1 and brings the task into view. Pass focusOnTransition={false} while a consumer-owned dialog or other focus boundary is active; a suppressed transition is not replayed when the boundary closes. Dialog focus restoration belongs to that dialog.

Providers, commands, session checks, password policy, eligibility, residency decisions, reference-directory access, safe same-origin routing, expiration/attempt limits, retention, draft persistence and opaque return-to-intent handles belong to the consumer. Never use client phase/state, disabled controls or onboarding_complete alone as authorization. Keep secrets out of URLs, telemetry and persistent draft storage. A password is never an intent field. Authentication success and residency approval are distinct results.

The fictional Candidates/Member entry controller demonstrates signup link, verified-email password setup, password login/recovery, all three residency paths, pending/correction, decision/appeal, withdrawal and approval-to-first-ask/offer. Its scenario controls do not send email, write accounts, verify references or decide residency. It keeps drafts only in memory and uses clearly fictional reference choices. Product reverify/expired/conflict/ evidence-deleted projections, real delivery, attempt exhaustion, cross-device callbacks and provider-bound E2E remain product work. The candidate is not DS or product acceptance.

Named source/proof bindings for coordinator integration are staged alongside the handoff; they must be merged into the canonical catalog and regenerated against the final package. The executable browser source is stories/candidates/member-entry.browser.test.ts and the built specimens are stories/candidates/member-entry.stories.tsx. Public types live with recipes/MemberEntry.tsx; migration is additive and does not accept legacy exports.

Removed historical screen helpers

The candidate release removes the 64 display-only functions formerly re-exported from screens.tsx, together with ListingDetailHeaderProps. Some of those controls could not accept input or dispatch an action. Their historical Storybook examples remain under Legacy / Templates, outside the package. Do not replace a missing import with a local copy of an inert control.

Use the controlled Discovery, NeedEntry, Agreement and MemberEntry recipes for their documented responsibilities. Replacement work for the remaining template families is still open. TEMPLATES_OF_RECORD preserves the full twenty-archetype route/journey inventory and now exposes explicit maturity; a legacy or candidate row is not ready for release.

The removed groups are listing detail and request helpers; create/edit selectors and summaries; conversation wrappers and composer; activity, notification and confirmation helpers; auth/residency wrappers; profile/settings/privacy panels; checkout placeholders; provider summaries; ride/bundle helpers; case/appeal and operator helpers; four Home wrappers; and PreviewAccessGate. The source authoring catalog records every removed symbol and replacement gap in design-system/retired-screen-exports.json and design-system/TEMPLATE-MIGRATION.md.

MemberHub, Activity and private conversations (candidate)

import { MemberHub, MemberActivity, MemberInbox, MemberConversation } from "@super-ic/app-patterns";
import "@super-ic/app-patterns/member-hub.css";
import "@super-ic/app-patterns/need-entry.css";

Compile the public @super-ic/app-patterns/tailwind.css bridge at the consumer root. It includes the primitive bridge and scans the package's built MessageRun utilities. Foundation tokens remain canonical. Import optional foundation fonts directly from JS/root layout, outside the Tailwind import chain. The consumer supplies semantic icon slots and their provider binding; the new recipes do not import an icon vendor.

MemberShell remains the owner of main, h1 and five navigation destinations. MemberHub shows one supplied next obligation followed by one compact NeedSearch, at most two owned posts and at most two conversation previews. Passing larger collections throws. posts.all is an optional native link to the consumer's complete owned-post route.

An empty next projection may supply media and secondaryAction. The media appears only in that quiet state beside the supplied state copy, uses its explicit dimensions with contain fit and preserved colors, lazy-loads, and disappears after an image error until its source changes. Do not use it for a ready, loading, failed, listing, or actual-exchange claim. The consumer provides the approved public media import, truthful alternative text, and exact navigation destinations. No counters, predicted demand, activity, or artwork meaning is inferred by the recipe.

MemberActivity owns the complete active/completed commitment collection. Its native filter buttons have aria-pressed; the product owns filtering and URL/query persistence. Each row supplies a relationship, actual state, next step, timing and exact destination. The list opens AgreementWorkspace or the real request/receipt destination. It does not confirm pickup/return, change terms, authorize money or derive a deadline. Do not expose private meeting locations in list previews. Use MemberTiming.accessibleLabel for a full absolute time and timezone when the visual label is relative or shortened.

MemberConversationList is a reusable linked preview collection. MemberInbox composes that list and an optional selected MemberConversation: two panes when the container is wide, the selected route's single pane when narrow. Supplied href values remain real links, including modified-click browser behavior. Products own routing, safe destinations, route focus, list-row focus restoration and retained selection. A standalone conversation can be mounted without the two-pane composition.

MemberCollection<T> separates loading, empty, failed, and ready data. A ready refresh may retain last loaded rows with an explicit loading/failed notice and retry. Use explicit empty data rather than a ready empty array. Opening a retained row does not grant authority; its destination must revalidate the current object and allowed actions. Display-ready collections must use unique stable IDs. Candidate collections are not virtualized or paged.

MemberConversationData contains ordered server-supplied text messages, agreement context, a controlled composer and a per-thread MemberScrollPosition bookmark. Never reorder messages by a client clock. A bookmark holds the first visible message ID, its relative pixel offset and a fallback scroll top; persist it separately per thread. Appended messages do not move focus or scroll. Prepended history preserves the visible anchor. A deliberate Show latest button moves the viewport and focuses that region. The history is not a live region that repeatedly reads older messages. New-message and send outcomes have separate polite status text; failures are alerts. Use distinct sent/delivered/read facts supplied by the product, never a checkmark inferred from a successful local click.

The composer renders the accepted Textarea/Button and the thread uses the current validated MessageRun text renderer. Enter in the textarea inserts a newline; Tab reaches Send, then Enter or Space submits. Whitespace-only messages cannot send. The consumer supplies a positive maxLength, labels, draft, optional validation error and actual SubmissionState. During submission the draft is read-only and repeat submits are blocked synchronously. The callback must promptly reflect submitting and later a settled result in props. The consumer must also hold an idempotent per-thread command lock and bind the immutable thread ID/request identity before awaiting. Never let an old result insert into a newly selected thread. On failure keep the draft. Only append a sent message after an authoritative result; no optimistic delivery is fabricated. The local specimen demonstrates these ownership rules, including navigation to another conversation during a pending send.

An unavailable composer has an explicit explanation and optional recovery route while retaining the authorized context/history. Products own authorization, blocking, restricted membership, retention, persistence, realtime delivery, server idempotency and help/report commands. Attachments, pagination, thread search, read-marker mutation, offline persistence, virtual-keyboard/device testing and backend E2E are outside this candidate. Do not import the legacy inert MessageComposer or fabricated fixture arrays as a production substitute.

Source: recipes/MemberHub.tsx and css/member-hub.css. Bound specimens/tests: stories/candidates/member-hub.stories.tsx and member-hub.browser.test.ts. The source catalog proposal accompanies the isolated handoff. Maturity remains candidate until the coordinator reviews and integrates the actual artifact; legacy template acceptance is not inherited. Template mapping is selective: replace home and activity lists, compose existing AgreementWorkspace for detail, replace inbox/conversation, preserve request-sent receipts and the separate notification/account/safety/money/operator scopes.

Member account candidate recipes

MemberProfile, AccountPreferences and AccountPrivacy are controlled candidate recipes. Import their values and types from @super-ic/app-patterns and load @super-ic/app-patterns/account.css. Compile the public @super-ic/app-patterns/tailwind.css bridge for the primitives. Optional public foundation fonts load through direct JavaScript imports, not a nested CSS import.

import { MemberProfile, AccountPreferences, AccountPrivacy } from "@super-ic/app-patterns";
import "@super-ic/app-patterns/account.css";

Use these inside MemberShell, which owns the only page h1 and main landmark. Preserve Home, Explore, Create, Activity and Inbox. Account is a secondary utility destination: use currentNavigationId={null} rather than marking a primary destination current. The optional AccountNavigation contains unique IDs, real link targets and one matching current ID. The recipes do not own application navigation or route history.

MemberProfile distinguishes neighbor, own and edit views. NeighborProfile is an explicit safe projection. Never adapt a database row by spreading private properties. Only the own view accepts private community meaning, restrictions and membership actions. Supplied residency wording explains its actual scope, not a safety assessment. Completed-exchange count is optional; pass it only when authorized and current. Display name, bio and an optional approved avatar are editable. Neighbor avatars only accept ready/none; runtime rendering also ignores hostile quarantined/rejected input. The own edit view alone renders private ready/quarantined/rejected processing details. The DS never uploads a File or authorizes an asset.

AccountDraftIdentity binds actor, draft key and base revision. A saved state displays its success message only when the receipt matches all three. Consumers must capture immutable command identity before awaiting, lock repeated commands synchronously, enforce revision/idempotency at the server, and discard late results after navigation, account change, auth loss or draft replacement. The DS matching guard is additional presentation protection, not server authorization. Change the draft key when the draft changes. A failure attempt identifies a newly received error so focus can move once without stealing focus on initial render. Validation attempts focus the first invalid profile field. Cancel behavior and persistent draft policy belong to the consumer.

AccountPreferences accepts only consumer-supported email rows with effective and draft values. The fictional SBR specimen supplies messages, incoming requests and agreement updates, based on the inherited delivery categories. Switches change a local draft and one Save boundary sends the batch. The status model distinguishes unsaved, saving, failed, saved and stale revisions. Essential in-app notices remain independent. A saved preference is not email delivery. Background changes retain the current draft until an explicit review and revision reconciliation.

AccountPrivacy separates export from deletion. Every private export/deletion projection has a subject key that must match the current authorized actor. Ended access and completed deletion use separate unions that render no private profile or download. The product must replace an authorized projection immediately when authority changes; this recipe does not independently discover session expiry.

Export distinguishes not-requested, requesting, preparing, ready, partial, expired and failed. Only a current authorized ready/partial projection can carry a download with format and explicit expiry text/datetime. Products own the clock, expiry, URL authorization, safe file contents and category completeness. An expired projection removes its link. Partial results name missing categories and a recovery action. A link or download filename is not proof a file was saved.

Deletion uses a focused review page with consequences, obligations, retained categories/reasons and acknowledgment. The shell supplies the title Request account deletion. The recipe moves focus into review only after an explicit transition, restores the invoking control on cancellation, and preserves controlled acknowledgment. Outstanding agreements remain actionable and do not prevent initiating a request. Escape cancels from the review region before dispatch; controls lock while dispatching. Uncertain receipt is a separate failed variant with required checkStatus and no retry request in its review projection. Its status check is an outline action independent of acknowledgment; closing says Back to account and must preserve uncertainty. Requesting also distinguishes request-deletion from check-status so this behavior remains stable while pending. Reauthentication, received/pending, needs-action and explicit completed projections are distinct. A ban, anonymized profile or absent response is never a completion receipt. Products supply consequences, retention reasons, lawful authority, job status and follow-up links.

The fictional controller is in stories/candidates/account.stories.tsx; it uses only in-memory state, timers and a safe fictional data download. Out-of-family routes and reauthentication callbacks are explicit local boundaries, not implementations of those destinations or provider commands. Name/bio limits of 80/400 characters are specimen choices, not DS policy. Account IDs and command counts are harness metadata. No production session, email, export job, deletion, legal compliance or provider state is represented.

Browser requirements bind to literal ACC-01 through ACC-20 tests in stories/candidates/account.browser.test.ts. Compile-only negative controls are in account.typecheck.ts; they are not executed privacy proof. Full-document axe runs independently without disabled rules; only this candidate uses manual addon scheduling to avoid duplicate axe ownership. Native/mobile-device keyboards, accepted-photo upload/storage, persistence across reload, and installed nine-package/product authorization proof remain open. This is additive candidate source and does not inherit acceptance from the retired profile/settings/privacy helpers.

Recovery candidate

SupportIntake, ProtectiveAction and SupportCaseWorkspace are controlled recovery recipes. Import them from @super-ic/app-patterns, import @super-ic/app-patterns/recovery.css, and compile the public app-patterns Tailwind bridge through @super-ic/app-patterns/tailwind.css once at the consumer root.

SupportIntake keeps public and member access in separate TypeScript branches. Public intake supports a bounded purpose list, explicit anonymous or reply-contact choice, consumer-supplied privacy and retention notice, optional attachment projections, repeated validation focus, submission failure retention and a supplied receipt. A public receipt does not grant membership or private case access, and its non-secret reference must stay separate from the consumer's authorized continuation route. Member intake accepts only a supplied object and safe counterpart projection.

SupportIntake may receive contextual media and a controlled view.honeypot. Media is informative only and renders solely for an idle, valid, non-safety form with a current idle commitment; it is absent for boundaries, submission states and receipts. A failed image removes only the image while retaining its supplied caption. The honeypot renders as an excluded website field and stays consumer-owned; this package does not persist or inspect its value. See contracts/support-intake-refinement.json for the packaged source contract.

For a current original operation in pending, checking, unknown or earlier-recorded, SupportIntake places its status actions after the heading and supplied context. The retained draft is a closed native disclosure labeled Your request details. A selected safety purpose keeps emergency guidance ahead of that disclosure. These recovery states do not render duplicate form actions or contextual media.

ProtectiveAction keeps contact blocking and safe stop distinct. The consumer supplies eligibility, exact consequences, confirmation state, command status and any successful outcome. Its confirmation uses the public primitives Sheet. Effects render as completed only when the consumer supplies a confirmed outcome. Re-evaluate eligibility while the Sheet is open. An unavailable state disables confirmation, shows its reason inside the Sheet, and guards the callback.

SupportCaseWorkspace accepts loading, degraded, unavailable, restricted and ready projections. Ready cases discriminate draft, submitted, received, waiting-on-you, investigating, proposed-resolution, resolved, appealed and closed states. Reply and appeal composers retain consumer-owned text after failure. A stale proposal exposes only its refresh action. Current proposal acceptance receives the exact rendered proposal ID and has its own controlled pending and failure state. Money state and actions remain separate links.

Each recipe defaults to a level-one task heading for a standalone route. Set headingLevel={2} when a surrounding MemberShell or product route owns the h1; recipe subsections then move to level three. Products must preserve a complete heading hierarchy.

The package does not call support providers, classify severity, fetch people or cases, persist attachments, decide eligibility, move money, grant access or promise response times. Products own commands, durable idempotency, routes, authorization, notice version, abuse controls, data retention, per-object drafts, operation identity, actor/object/route generation guards, proposal version checks and safe projections. Candidate stories use fictional in-memory values and do not send reports or protective actions.

OfferingEditor renders the controlled item, service-family and free cart offering recipe. The consumer supplies every discriminated draft value, eligibility decision, financial projection, policy acknowledgment projection, validation error, per-branch upload state and durable command result. The shell owns the stage-specific page heading. The fixture focuses the shell main landmark, which is labelled by that heading, only after a real view transition. Initial render does not move focus. Validation focuses the first invalid control, and Review edit actions focus the requested field. Review edits stay disabled while publication is pending.

Paid branches require a ready financial projection whose branch and raw price input exactly match the current draft. Missing, loading, stale and unavailable projections block publication. The design system displays supplied monetary strings and never calculates fees. A required policy acknowledgment stores an exact snapshot of its revision, wording, link, link label and acceptance label. Any supplied content change invalidates that acceptance. A consumer-declared current acknowledgment remains readable without requiring another checkbox. Incomplete required policy content blocks the protected action. An acknowledgment projection may supply onNavigate to open a controlled readable document view while retaining its real href. Opening and returning from that view must preserve the draft and must not mark the acknowledgment accepted.

Consumers must keep photo state per branch and guard asynchronous photo and publish results with current operation, route, actor, branch and draft identity. Import the recipe CSS through @super-ic/app-patterns/offering.css. Load the optional public font sheets from the application JavaScript entry, for example @super-ic/foundation/fonts/superic.css and @super-ic/foundation/fonts/tenants.css; do not flatten those asset URLs through a Tailwind CSS import. The component does not authorize a branch, upload a file, infer legal readiness, persist an offer or display a saved receipt without the consumer's saved result.

Add OfferingEditor and its Offering* controlled draft, eligibility, financial, acknowledgment, media, command, receipt and configuration types to the public exports table.

Rides recipes (candidate)

RideComposer, RideRequests and RideWorkspace present an offered trip or requested trip through review, request coordination, changed terms and a recorded outcome. They are controlled web presentation, not ride activation, server authorization, payment processing or a legal policy.

import { RideComposer, RideRequests, RideWorkspace } from "@super-ic/app-patterns";
import { PortalContainerProvider } from "@super-ic/primitives/portal-container";
import "@super-ic/app-patterns/rides.css";
import "@super-ic/app-patterns/agreement.css";

Compile @super-ic/app-patterns/tailwind.css with the canonical foundation entry. It includes the primitive source bridge. Import optional foundation fonts directly from JavaScript. RideWorkspace reuses the package's DecisionPanel and AgreementTimeline anatomy, so agreement.css is a required CSS dependency. Place the portal provider inside the same actual tenant/theme boundary as the recipe; the Sheet must inherit that scope.

RideComposer distinguishes a driver's offer from a passenger's request. An existing-offer request carries the selected offer's trip/revision/policy context and renders that offer's route/time. The product supplies eligibility, available destinations, integer limits, raw monetary validation, the licence claim and current acknowledgment. The form retains strings rather than silently clamping invalid input. A review and receipt carry an exact RideBinding; a changed binding disables the reviewed command. Every review group supplies an edit action.

RideRequests shows one specific trip's safe request rows and current shared capacity. Use its explicit ready, empty, loading, failed or stale projection. The product atomically consumes seats and contribution capacity when it accepts a request. All passengers share one trip-level contribution cap. Messages and pending requests never reserve a fresh whole-trip cap.

RideWorkspace receives status separately from current/stale/restricted command authority. Every visible command must be declared in allowedActionIds. Accepted terms remain separate from a proposal, and confirmations bind the exact actor, trip, revision, draft, selected request/proposal and policy version. Preserve request identity across asynchronous results and use synchronous command locks. Keep an uncertain operation available for read-only status checking across route/review closure; do not turn it into a fresh submission. Product persistence and idempotency remain required.

Safe summaries and request rows omit raw database coordinates, exact address and private profile data. RidePickupAccess is a separate purpose-bound projection; only a matching actor/trip, ride-pickup purpose and current authority render its instructions. Expiry, revocation and unavailable projections must remove old instructions. The product owns grant issuance and revocation, not the component.

A single confirmation by either participant can record trip completion. It is not a contribution-paid receipt. Supplied received-only, stopped, cancelled and no-show states must retain their distinct consequences and help path. Full local date/time and timezone labels are required; no live tracking, ratings, guarantees, licence uploads, payment provider or invented support hours are part of this recipe.

Use the focused shell without primary navigation for composition. Coordination uses the existing Home, Explore, Create, Activity and Inbox destinations. The product supplies real same-origin routes, private conversation entry, acknowledgment/reference content and help. The local candidate's reference extract is draft context, not activated or legally approved terms.

The recipe remains a candidate pending root's source and visual review. Its local controller stores fictional state only for the mounted visit. Actual provider commands, durable drafts, legal classification, activation, adult eligibility decisions, named destinations and the unresolved unaccompanied-minor rule remain product work. Native and real product implementation are outside this slice.

Operator work recipes (candidate)

OperatorQueue, OperatorReview, CommunityProvisioning and CommunityRelationships compose scoped operator work through the public shadcn controls. Import them from @super-ic/app-patterns and import @super-ic/app-patterns/operations.css alongside the compiled public Tailwind bridge.

The product owns safe data, current assignments, purpose/expiry/conflict decisions, allowed commands, stable operation IDs, durable drafts, history, receipts, routes and provider status. The recipe compares the full OperationsBinding before displaying protected information. This guard does not look up or authorize a grant.

OperatorQueue accepts a current scope, controlled filter and explicit ready/loading/empty/failed/restricted/conflict/unavailable projection. OperatorReview accepts one closed residency/case/money/privacy evidence family, permitted decisions, controlled reason and recipient explanation, separate private notes, current confirmation, command status and separately bound decision/notice receipt. CommunityProvisioning composes reviewed boundary and community fields with explicit initial availability. CommunityRelationships displays the server-supplied bilateral state and permitted version-bound commands. Local checkboxes never activate a relationship.

Uncertain commands expose status checking and cannot resubmit. Decisions and notice delivery remain independent. Navigation must preserve a dispatched operation and retrieve its authoritative result without applying it to another actor, assignment, community, object or revision. Consumers should fetch the current record after resolving an older-revision operation, retaining its original receipt separately.

The Money exception may include OperationsMoneyRecordAccess: available requires purpose money-record, the exact review binding, a related record key and its already-authorized link; unavailable includes safe explanatory copy. This is a read projection only. The family never supplies a ledger, payment instrument or settlement command.

These are local DS candidates. Their fictional controller proves interaction and presentation paths during one mounted visit. Backend authorization, durable operations, live activation, independent reviewer availability, providers and complete installed consumer acceptance remain product/integration responsibilities.

Current entry binding and uncertain requests

MemberEntryForm.binding identifies the actor, application, revision and policy version. The consent stores the exact binding it acknowledged; a stale checked value is rendered unchecked and cannot submit. Changing applicant or address details invalidates affected adult acknowledgment, address-code input and verification challenge. Reading a supplied document through PublicDocumentDialog never accepts it.

MemberEntrySubmission adds explicit unknown and checking states. Unknown commands expose status checking while disabling resubmission. The consumer registers dispatch synchronously and keeps its identity until an authoritative result. A failed status read preserves uncertainty. These local examples do not send email, verify a real code, establish a session or approve residency.

Money recipes (candidate)

PaymentReview, PaymentRecord, PayoutSetup and ProviderLedger consume product-owned projections and commands. Import @super-ic/app-patterns/money.css alongside the public Tailwind bridge. The review binds actor, agreement/version, quote, terms document/version and exact acknowledgment identity/version/wording. The product owns authoritative amounts, eligible actions, provider integrations and durable idempotency.

An uncertain payment stays blocked across quote or terms changes until its original status is known. A confirmed earlier payment retains its original receipt facts and prevents another full agreement charge. Payment, refund, transfer and payout outcomes remain separate. Displaying any retained receipt still requires current actor/agreement access. Bank setup and checkout destinations are supplied by the application; returning from them is not confirmation of success.

Shared visual cues

Search, filters, ask dates and success receipts use public semantic Nucleo icons. Bind @super-ic/icon-contracts/nucleo at both server and client roots. Visible labels remain the accessible names. Invitation warmth uses foundation brand-warm-surface and brand-warm-accent; confirmed receipts use brand accent roles. Motion uses foundation durations/easing, remains optional under reduced motion, and never delays an action or implies an unconfirmed result.

Entry form readiness

MemberAccess and ResidencyEntry render credential and application forms with an explicit POST method. Editable controls and submission stay disabled during server rendering and first hydration, then enable when the client mounts. Without JavaScript, the form explains the requirement and cannot submit fields into a URL. Consumers must retain this guard; never replace it with a default GET form. Busy, unknown-command and binding checks continue to gate hydrated submissions.