Version. 0.1 Date. 2026-05-16 (evening) Author. Marvin Percival (DUNIN7 Operator) with Claude.ai Status. Self-contained handoff for a fresh chat. All scoping decisions in this document are settled; the next chat picks up at mockup production.
What this document is. A handoff capturing the engagement-addressing and grouping decisions settled during the 2026-05-16 architectural rethink session. The next chat picks up by producing v0.2 of the Stream 1 mockup space, focused on engagement-level navigation with these decisions baked in.
What's settled. Fifteen design decisions across engagement addressing, grouping (workspaces, tags), surface organization, and operator vocabulary. The model is complete enough that the mockup can be drawn without further scoping discussion.
What's NOT settled. Anything below the engagement-level navigation surface — specifically, the session-within-engagement navigation problem from Stream 1 v0.1 (three layout alternatives: sidebar / below-fold / card stack). That's a separate mockup track and isn't touched in this handoff.
What the fresh chat does first. Reads this handoff. Confirms shared understanding by restating the model (or asking clarifying questions on anything ambiguous). Then produces v0.2 of the Stream 1 mockup — single HTML file, engagement-level navigation, all fifteen decisions visible in the rendering.
The Loomworks architectural rethink scoping arc opened earlier in the session (Stream 1 — Operator surface design). The original v0.1 mockup showed three layouts for session-within-engagement navigation (the "session-as-unit-of-work" model). That mockup is intact and reactable; it's not what this handoff is about.
This handoff captures a second design problem that surfaced during the same session: engagement-level navigation. How does an operator address engagements? How are engagements grouped? What's the surface organization that lets an operator move between engagements?
These two problems (within-engagement and across-engagement) are related but distinct. The within-engagement Stream 1 v0.1 mockup sits as a parallel track waiting for its own reaction. The engagement-level mockup is what comes next, in v0.2.
Several substantial design moves landed across the conversation:
0 + name Personal, dual-addressable)E####, e.g., E4729)Engagements carry multiple identifiers, each serving a different addressing need:
| Identifier | Format | Example | Scope | Used for |
|---|---|---|---|---|
| Global engagement ID | E#### | E4729 | Universal — same value for every contributor in the engagement | Cross-person disambiguation; external references (emails, shared docs) |
| Personal engagement number | Integer | 23 | Per-operator sequence; Operator A's 23 may be Operator B's 15 for the same engagement | Operator's own working-set handle; quick recall ("get engagement 23") |
| Text description | Free-form string | "Loomworks commons" | Editable per-engagement | Human-readable name/meaning |
Reserved special-case. Every operator has their own Personal engagement.
0 (number) or Personal (name) — both work0 is reserved system-wide for this purpose1, not 2)Sessions are bounded units-of-work within engagements (per the Stream 1 v0.1 "session-as-unit-of-work" framing). They have their own numbering scoped to the engagement, but the recall use case is rare. Most session navigation happens implicitly through the within-engagement surface (Stream 1 v0.1 territory). Direct invocation ("jump to session 7 of engagement 23") is power-user behavior, not the common case.
Append-only. When an engagement is archived or closed, its personal number stays reserved forever. The operator's "engagement 23" five years from now is the same engagement, even if it's been dormant for years. Personal-number space grows monotonically.
Pure integer prefixed with E. No separator. Example: E4729.
Format rationale (filed as methodology principles in §4):
E stands for Engagement (carries information without brand-locking)E was chosen because uppercase E and lowercase e are both unambiguously distinct from any digit (unlike L/l which can be confused with 1)S####, T####, etc. follow the same patternAlways visible in the engagement list and engagement header. Not behind a hover state or a click. The reasoning: cross-person disambiguation is the use case the global ID exists for; making operators dig to find it defeats the point.
Visible-but-subtle treatment expected — small monospace-ish styling near the engagement description, not dominant.
In engagement lists, the canonical rendering is:
{personal_number} · {description} · {global_id}
Examples:
0 · Personal
23 · Loomworks commons · E4729
24 · FarmGuard September pricing · E5102
25 · Smith Q3 contract · E5118
Personal engagement (0) renders with name only; its global ID exists but the personal number 0 plus name Personal carry sufficient signal.
Sortable by personal number, description, last activity, etc. (decisions on default sort and available sorts can be made at mockup time — not load-bearing).
Lateral grouping. Free-form strings. Many per engagement.
Vertical containment. Named places. Many per engagement. Navigation context.
Peer to workspaces. Filtered views without navigation state-shift.
Expandable, above workspaces. Pinned at the top of the surface (sidebar or left rail), expandable when in use, collapsible when not.
The "above" placement signals foundationality — Personal sits structurally above the workspace organization, available regardless of which workspace is current. The "expandable" treatment respects that Personal is always there but doesn't always need to be loud.
SURFACE LEFT-RAIL (or equivalent)
├── Personal engagement (always at the top, expandable)
├── Workspaces (places-you-enter; navigation state)
│ ├── Smith Account
│ ├── Q3 Planning
│ └── (etc.)
└── Cross-cutting (filtered views; no state-shift)
├── Everywhere (all engagements)
├── Recent activity
├── Tagged urgent (operator-defined)
└── (other operator-defined filters)
Worth filing for v0.21 candidacy. Several of these came out of the architectural decisions and should be carried forward independent of this surface:
E#### for engagements; future entities can use S####, T####, etc. Scales without rebuild.0 and name Personal. Sets precedent for similar dual-addressing on other system-special entities if any are added.When the fresh chat produces the mockup, it should render:
These are the right kind of open questions for a mockup to resolve — visual reactability is the cheapest way to settle them.
This handoff covers Stream 1's engagement-level navigation only. Other streams of the rethink remain in various states:
Suggested opening for the next chat:
Opening the next step of the Loomworks architectural rethink. Read the
handoff document loomworks-stream1-engagement-navigation-handoff-v0_1.md
first. All fifteen decisions in that document are settled; do not re-open
them.
Confirm shared understanding by briefly restating the model — or ask
clarifying questions on anything ambiguous in the handoff.
Then produce v0.2 of the Stream 1 mockup space, focused on engagement-
level navigation with all settled decisions visible. Single HTML file.
Annotation conventions: deliberately-open visual decisions called out
inline. Versioning: this is v0.2 in the Stream 1 series because it
extends the same architectural rethink stream as v0.1 (the session-within-
engagement mockup), even though the focus is different.
Filename: loomworks-stream1-engagement-navigation-mockup-v0_1.html
(this is the first mockup focused on engagement-level navigation; the
v0_1 versioning is local to this sub-track; the Stream 1 v0.2 lineage
is conceptual rather than filename-encoded).
Discovery-record discipline applied. Plain English throughout.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks architectural rethink · Stream 1 · Engagement Addressing & Grouping · session handoff v0.1 · 2026-05-16 Hands off to a fresh chat for v0.2 mockup production.