From space to item
An app on Real Life Stack has three levels, and each answers a different question. The frame asks: who are you, which Space Der gemeinsame Arbeits-, Mitgliedschafts- und Sichtbarkeitskontext. Im Datenvertrag heißt er Group. GlossarSpace The shared context for work, membership and visibility. In the data contract it is called Group. Glossary are you in, which module are you looking at? The space asks: what belongs here, who belongs to it? The item is the thing itself, an event, a place, a task, a post. The modules in between are views onto the same items, not owners.
Try it in the garden: open the harvest festival, switch to the calendar, then to the map. It is the same address, the same item, shown three times.
A community garden: pick a space, switch modules, open an item. The sample data is fictional. Changes last only for this session.
The frame
The frame (AppFrame, in an app with a router RoutedAppFrame) is the same everywhere: the space switcher on the left, the module tabs in the middle, notifications and the user menu on the right; below it the surface of the active module and the one shared panel for detail, create and history. An app does not build it, it provides it (spec 01, “what stays with the app”). That is why every app on the stack looks the same at this point, and why Storybook can show the same frame as the apps.
Light or dark is up to the person, not the space. The button for it on the right of the header is ColorSchemeToggle from the toolkit. It sets the dark class and data-theme on the root element, remembers a choice per browser and, without one, follows the system setting, also when that changes later. So that sign-in and loading already show the right scheme, the app calls applyInitialColorScheme() before anything else. The moment before its script runs is only covered by a script in the app’s <head>.
The frame holds the focus: which space, which module, which item is open, whether it is being edited. In an app with a router this lives in the address (/{space}/{module}/{item}), in a story in memory, with the same contract. Back in the browser closes the detail, a link to the address opens it.
The space
A space is the working context: a group (Group in the data model) with Mitglied Vorgeschlagen: wer zu einem Space gehört. Die Anwendungsschicht liest Mitgliedschaft über den Connector und konstruiert sie nicht selbst; wie sie gespeichert und belegt wird, entscheidet der jeweilige Connector (der lokale Connector hält sie in groupMembers, der RLTP-Connector leitet sie aus Gruppen-Log und Schlüssel ab). GlossarMember Proposed: who belongs to a space. The application layer reads membership through the connector and does not construct it; how it is stored and proven is decided by the connector in use (the local connector keeps it in groupMembers, the RLTP connector derives it from the group log and key). Glossary, items and the list of its modules in tab order. The space chooses from the register what it shows; it does not extend it (spec 01). A space “Community garden” can carry calendar, map and list, a space “Open workshop” only the list. The personal space is a space like any other, just with one member.
What all modules of a space share belongs to the surface, not to the module: the search, the vocabulary of tags and types, the filter card, the chips. That is why a filter survives switching modules, and why no module offers a selection of its own that another one does not know (spec 01, rule 2a).
A surface that is not a module under the host, such as a board of the app’s own, filters the same way without assembling the filter itself: wrapped in <ModuleSurfaceScope items={…}> it reads useSurfaceItems(); without that wrapper, useModuleFilteredItems(items) returns its list filtered by search, tags and types.
The item, shown twice
The preview (ItemPreview) is the card in the feed, in the list, on the kanban board: recognise and select. The detail view is the whole item with its actions and the discussion; it opens in the shared panel, and there is only this one panel. A second click on another item swaps the content, it does not stack.
The one panel: detail, create and history swap the content instead of stacking. The sample data is fictional. Changes last only for this session.
A person’s Personenprofil Die fachliche Darstellung einer Person als Item nach Profilvertrag. Die User-Identität ist ein eigener Begriff. GlossarPerson profile The domain representation of a person as an item under the profile contract. The user identity is a separate term. Glossary is not a second UI system here. It is the detail view of an item of type person (spec 12); “profile” names the content, not another surface.
Which level does what
- Frame: hold space, module and focus; panel, header, notifications, space administration; the three navigation rules (a field leads into its module, a comment into its discussion, a tag into the filter).
- Host of the module: produce from the register entry what the module needs: the items by
presents, filtered by search and filter; members, authors, colours; detail, create, plus button. A module loads none of this itself (spec 01, rule 2). - Module: its rendering and its own interactions, nothing more.
- Detail content: title, facts, content, matching actions, comments.
- Connector Die Implementierung des DataInterface für eine konkrete Datenquelle, ergänzt um unterstützte Capabilities. Die Steckstelle des Stacks nach unten. GlossarConnector The implementation of the DataInterface for one data source, plus the capabilities it supports. The stack's socket downward. Glossary: read, observe, permitted writes.
Whoever finds something from a lower level inside an upper one is looking at a violation of the spec; that is the rule that holds all apps together.
Where to go next
In Storybook, RLS → App shows register, host, loading contract, focus and create one by one, RLS → App shell the frame and its parts. The next page follows a click down into the connector: From click to shared change.