DUNIN7 · Loomworks · Companion Design · Mockup
A design illustration of the dual-pane Companion: conversation left, a workspace right that renders engine results as approved cards. The four rooms (Memory, Manifestation, Shaping, Rendering) are all reachable as workspace tabs — including Manifestation and Shaping, which have no conversational path today. Card actions feed verbs back into conversation. Voice is foregrounded. Illustration, not specification.
How to read this. The left pane is where the Operator speaks verbs; the right pane is where the engine's results render as cards. The pages of the current app become what the Companion shows in response, not a tree the Operator navigates. The four-room tabs make Manifestation and Shaping reachable — today they have no conversational path at all.
The context chip ("here: 7 · Goosey · E0007") is the visible form of the one genuinely-new engine capability the design needs: a notion of conversational context (which engagement am I in), so that "commit held 14" and "open FieldPilot" resolve to somewhere. The engine has no such concept today; it is purely frontend.
Addressing (per the engagement-identity decision record): all three handles are instance-local — the per-Operator number ("7", your own handle), the name ("Goosey", for speaking), and the shared E#### ("E0007"). The UUID is the invisible cross-boundary identity, never shown. Personal is an engagement with visibility='personal', not a separate object.
Status. Design illustration with real Loomworks data shapes — not a specification. Card layouts, tab treatment, and the context-chip placement are CR-level decisions against live components.