Space context: working inside a branch › space

Status: plan, decisions resolved 2026-10-12, nothing built · Linear: TKN-459 (parent TKN-358) · Owner: Saar Companions: wireframes.md · prototype/index.html (open the file directly; no build, no network) Builds on: ADR-0024 (spaces, buckets, layered policy) · ADR-0023 (capability without a role) · ADR-0004 (org isolation)

Three levels (decision 16, 2026-10-15, TKN-479; ADR-0024 D13):

This document is the source of truth for the working-context model. Saar resolved the open decisions on 2026-10-12 (§14). It specifies no visual world beyond the existing Deep Ocean system (apps/web/DESIGN.md).

Summary

• Staff work inside a space (for example Parquet) or in All spaces. One control, in the place of today’s org switcher, shows and changes Business › Space.
• Spaces are for focus, not restriction. Every staff member can see and switch to every space by default. The owner may restrict a specific staff member to chosen spaces; that is an explicit opt-in, enforced by the server and presented quietly.
• The active space lives in the URL (?space=<id>). A cookie remembers the last choice per business and fills the URL only when a link carries no space. The server checks the parameter against the caller’s spaces.
• Every session has a space. Each business has a default space. A session inherits its class type’s space, and changing a class type’s space moves its future sessions that still follow it, after a preview.
• The schedule folds by space inside each view, like the coaching program board: every view groups its grid into collapsible space sections. The active space is open and pinned first; the other spaces fold to a count per day. Dragging a card to another space section moves the session.
• Money is always the whole business. Reports that can be attributed to a space (attendance, sessions, fill rate, check-ins, trials) follow the space; revenue, payments, debt and plans say “Whole business”.
• Businesses with one space (most customers) see no change at all: no URL parameter, no chip, no extra request, and the control is today’s org switcher. Their one space is the default space and stays invisible.
• One flag, spaces (it shipped behind its own space-context flag, folded into spaces on 2026-10-18). The network level (HQ) has a reserved slot in the control, the URL and the type, and nothing is built for it (TKN-386 is not validated).

1. Job and audience

Visitor mode: Operate. Scanability, consistency, native expectations and the real usage scene outrank expression.

The person arriving is staff at a fitness business, usually on a phone between classes or at the desk by the door. They come to do one thing in one place: run the 18:00 class in Parquet, book a walk-in, call a lead about a trial. Today the product makes them configure the space per entity (class type default, then each session) and gives them no way to look at one space first. On a phone they can’t even see which business they are in: at 390px the top bar shows the page title and nothing else.

The job: let staff work inside the space they are in, always show them which context they are in, and put new things in that space without being asked.

Personas × scenarios

The table describes the default, where every staff member has every space. An owner can restrict a staff member (§6.5); the last column says what that changes.

A nutrition expert or physio is not a persona here: they are staff (usually a coach) and use the same defaults. PRODUCT.md keeps “not nutrition coaching”.

2. Outcome and proof

Primary outcome: in a business with 2+ spaces, staff stop setting the space by hand, every session lands in a space, and every screen tells them which space they are looking at.

Product truth. PRODUCT.md now says users are “almost always a single branch; most train in one space, and a minority (Pro) run two to five spaces” and keeps “not an enterprise multi-location platform” (applied 2026-10-12, §15.3). The design therefore treats multiple spaces as a Pro feature that appears only when it is used, never as a new navigation layer for everyone.

3. Selected direction

Thesis: a lens, with an optional fence. The working context is a lens carried in the URL and shown in one switcher. It decides what comes first, what is expanded, and where new things go. It never hides another space from someone allowed to see it. A fence exists only where the owner builds one for a specific staff member; the server enforces it, and the interface mentions it in one quiet line.

• Visual authority: Deep Ocean (apps/web/DESIGN.md), the shadcn sidebar shell, unchanged. No new colour, no new component family. The control is today’s org-switcher block with a second line. The schedule board reuses the coaching program board’s WeekGrid, row toggle and CollapsedCell.
• Focal moment: the switcher, exactly one on screen: the sidebar header on desktop (business, then the space line), or one button at the start of the top bar when the sidebar isn’t visible: [(o) Parquet ▾] Schedule. One of the two is visible at every width, including phone, where today nothing shows the context.
• Sequence: login → context resolved before the first scoped fetch → every scoped region loads for that context → switching keeps the route and re-focuses in place.
• Implementation consequence: one useWorkingContext() hook, one spaceId query parameter on space-bound reads, one SpaceScopeService on the server, one default space per business. Pages don’t invent their own space filters or second space controls; the switcher is the only one.

Rejected alternatives

4. Scope and anti-goals

In scope: the context model (shape, URL, default, API, optional restrictions), the switcher and the context indicator, the scope of every dashboard route and key action, creation defaults, the default space and the session-space invariant, the folded schedule and moving sessions, the class-type space cascade, reports scoping, how ADR-0024 surfaces in context, implementation slices. Deliverables: this plan, wireframes.md, and a lo-fi clickable prototype.

Fidelity: planning and lo-fi wireframes. No production code, migrations or app UI changes in this pass. The one product-doc change is the PRODUCT.md positioning, applied on Saar’s decision.

Anti-goals

• No HQ dashboard, network role, network table or consolidated cross-branch report (reserved only; TKN-386, TKN-387).
• No new membership_role values (no sales, front-desk or nutrition role). Capabilities follow the ADR-0023 pattern.
• No restriction by default, and no forbidden page.
• No space for business-wide money: payments, subscriptions, debt and revenue are never allocated to a space.
• No per-space colour theme, no per-space branding.
• No change for one-space businesses.
• No member-app context switcher. The member sees spaces as facts on sessions and as a schedule filter.
• No capacity pooling or utilisation planning across spaces (TKN-391).

5. Scope map

Legend: Space: the data carries a space; the page focuses on the active space and keeps the others reachable. Business: the data has no space, so the page ignores the context and shows a “Whole business” tag when a single space is active. Both: in a single space the page focuses or filters (a removable chip, never a hidden row); in All spaces it aggregates, with a breakdown by space. Either way, a space is named only in the places listed in §7.6; rows, items and tiles carry no space name.

For a staff member the owner restricted, space-bound data from other spaces is never returned by the server (§6.5); business data follows the role matrix as today.

5.1 Dashboard routes

All routes are under /[lang]/dashboard/ unless noted.

5.2 Key actions

5.3 The hard ones, settled

• Members. A member belongs to the business, never to a space, and no one’s member list is limited by space, including restricted staff. The server derives two read-only facts per member (§6.8) and the client never computes them (PRODUCT.md principle 4):
  • activeInSpaceIds: the spaces where they checked in at least once in the last 60 days (attended bookings only). Many members are active in two or three spaces. Plan coverage is not part of it (§6.8).
  • mainSpaceId: the space where they checked in most in the last 60 days (§6.8). It orders the list and attributes counts; it is never shown on a row and never limits anything.
  • In a space, the list shows three groups in this order: members whose main space is this space, other members active in this space, then “No check-ins in the last 60 days (n)”: members with no attended booking in the window, which covers new joiners, freshly converted leads, and members of a business that rarely checks people in. The “Active in Parquet” chip, which anyone can clear, filters the first two groups only; the third group always shows, so a new joiner is never invisible from a space view.
  • The count line reads “{active} active in Parquet · {notActive} not active here”, with a separate line “{n} with no check-ins in the last 60 days”. notActive excludes that group.
  • Rows carry no space names: no “Active in” column, no chips, no ”· main”. The focus chip and the count line carry the context; the one per-space line under “Classes this month” on the member page is the only place a member’s spaces are listed (§7.6). In All spaces the list is today’s list.
  • Search always covers the whole business, so a walk-in from another hall is one search away.
• Plans. Business-wide catalogue, the same in every context: no coverage badge, column or reordering. A plan’s spaces are set in its bucket editor (TKN-446) and reported only in the Reports block “Plan coverage vs. check-ins by space” (§12.2).
• Leads and trials. A lead belongs to the business. A trial is where a space appears: lead_trial_appointments gets a nullable location_id (today it has trial_type text and no session link). In a space, the Sales queue shows leads with a trial in this space plus leads with no trial yet, and a line “12 more in other spaces”. Lead and trial rows carry no space name. Space never narrows the Sales grant (ADR-0023 own/team still decides which leads).
• Tasks. tasks gets a nullable location_id. A space shows its tasks, then whole-business tasks; task rows carry no space name. Lead tasks follow the Sales scope (ADR-0023 R6), not the space.
• Messages and announcements. Direct conversations stay business-wide. Announcements gain an audience scope using the ADR-0024 D9 condition model (space in [...], meaning members active in those spaces). When the audience is “members active in Parquet”, the author also sees an opt-in checkbox ”+ n with no check-ins in the last 60 days”, unchecked by default, so a new joiner can get the welcome note without receiving every hall’s news. Recipients are resolved and stored when the announcement is sent, so a member who moves later doesn’t change who received it.
• Analytics. Space reports come from sessions and trials (attendance, sessions, fill rate, check-ins, no-shows, trials). In All spaces: totals, then one row per space. Distinct-person counts by “active in” are not additive; the table says so in a footnote. Next to them, a “by main space” view counts each person once, under their main space (plus a “No check-ins in the last 60 days” row), so its rows add up to the total. Revenue, payments, debt, plans, active members and retention stay whole-business, tagged, and ignore the space (S5). Plan coverage appears only in Reports, in one aggregated block, “Plan coverage vs. check-ins by space” (§12.2).
• Spotter AI. The <org_context> block gains the space (Parquet (id) or all spaces). Read tools focus on the active space; write tools default locationId to it; a write’s confirmation names the space (“Create 12 sessions in Parquet”), the same job as the sheet’s Space field. A restricted caller’s tools go through the same services, so the restriction holds. Each user turn stores the context it was sent from.
• Automations. Business-wide and owner/admin only. A later trigger condition can name a space (“trial booked in Parquet”) through the D9 model. No context default.
• Check-in kiosk. Today’s kiosk is per session (/kiosk/:sessionId) and inherits the session’s space; its header will show the space. A new door mode (/kiosk/space/:spaceId) follows the current and next session in one space, for the tablet at the Parquet door. GPS self check-in keeps using each space’s coordinates (ADR-0024 D1).
• Settings and policies. Settings are business-wide except the booking policy tab, which shows the effective rule for the active space under TKN-447/448 (§9). Spaces, the default space and staff restrictions are edited at business level.

6. Context model

6.1 Shape

// libs/shared — illustrative, not code to add in this pass
type SpaceSelection = { kind: 'all' } | { kind: 'one'; spaceId: string };
 
type WorkingContext = {
  level: 'branch';          // 'network' reserved for TKN-386; not implemented
  orgId: string;
  space: SpaceSelection;    // always { kind: 'all' } when the org has 0–1 active spaces
};

The context is {orgId, spaceId | 'all'}. The level discriminant is the only HQ seam in the type: adding 'network' later is additive.

6.2 Where it lives (decision 1)

• ?space=<locationId> or ?space=all on every dashboard URL of a business with 2+ active spaces. Never written for 0–1 spaces. Analytics already keeps its state in the URL (?tab=…&from=…&to=…), so this follows an existing pattern and meets the Web Interface Guidelines rule “URL reflects state”.
• Several tabs: each tab owns its URL. Deep links: schedule?space=<parquet>&week=2026-10-12 opens Parquet for anyone allowed to see it.
• Remembering: cookie taikan_space, a map { [orgId]: spaceId | 'all' }, written only on an explicit switch. It fills a URL that has no space (login, links in emails and push notifications, old bookmarks). It never overrides a URL that has one.
• Server default: the protected layout already reads the active-org cookie and /users/me on the server (lib/api.ts). It resolves the default space the same way and passes it down, following the ActiveOrgProvider pattern. The client replaces the URL without a history entry. Scoped queries wait for the resolved context, so nothing flashes the wrong space.
• Org stays where it is: the active business remains in the taikan_active_org cookie. A space id implies its org, so a deep link with a space from another business the user works in switches the business (full navigation) and announces “Opened in {org}“.

6.3 Default context on login (no space in the URL)

1. The business has 0–1 active spaces → no space. Stop.
2. The cookie remembers a space for this business and the caller may still use it → that space (or all).
3. The caller is restricted to exactly one space → that space.
4. The caller coaches a session in the next 24 hours → that session’s space (/users/me nextSessionSpaceId).
5. Otherwise → all (“All my spaces (n)” for a restricted caller).

6.4 How the API receives it

• Query parameter spaceId on space-bound reads, matching existing camelCase filters (weekStart, programId). For example GET /organizations/:orgId/class-sessions?weekStart=…&spaceId=….
• For the board, spaceId orders and expands; it does not filter. The week endpoint returns every space the caller may see, with per-day counts for every row and full cards for expanded rows (expand=<ids>), so a folded row costs a count, not a payload.
• No parameter means everything the caller may see. Clients that don’t know about spaces keep working: the mobile app, MCP, older web builds.
• Writes use locationId in the body (it already exists on sessions). When omitted, the server fills it: class type space, else the org default (§8.3). It never stores null.
• Business-wide endpoints don’t accept spaceId.
• Why not a header: React Query keys come from path and query, so a parameter separates the cache per space by construction. MCP and Spotter tools map a parameter to an argument one-to-one. Logs and Sentry show it.
• /users/me adds, per membership, the business’s active spaces (id, name, sortOrder, isDefault) and the caller’s spaceScope, so the switcher renders with no extra request.

6.5 Optional staff restrictions (decisions 2, 3, 7)

Default: no restriction. Every staff member has every space and switches freely. The owner may restrict a specific staff member to chosen spaces; that is the only restriction mechanism.

memberships.space_scope   enum('all','assigned') NOT NULL DEFAULT 'all'

membership_spaces
  membership_id    uuid  FK memberships(id) ON DELETE CASCADE
  location_id      uuid  FK locations(id)
  organization_id  uuid  FK organizations(id)
  granted_by_id    uuid  FK users(id)
  created_at       timestamptz
  PRIMARY KEY (membership_id, location_id)
  INDEX (organization_id, location_id)

• Why a table and an explicit mode: foreign keys, cascade, one audit row per change, an index for “who works in Parquet” (TKN-313), and an empty set never means “everything”: assigned with no rows means no space-bound data.
• Who: the owner restricts coaches and admins. The owner is never restricted; the API refuses it. Members have no working context. Every existing membership starts as all, which is today’s behavior, so the migration is additive.
• Where: Settings → Staff, on the staff row: “Spaces: All spaces ▾” with “Only these spaces…”. Audited as membership.spaces_updated with before and after.

Enforcement (decision 1). SpaceScopeService.scopeFor(membership) is read on every request, so a change applies on the next request.

• A space-bound read with an explicit spaceId outside the caller’s scope returns 403 space_not_in_scope and no data. A read without spaceId returns only the caller’s spaces.
• Space-bound rows (sessions, bookings, check-ins, course sessions, kiosk rosters, template applies, trials) filter on location_id IN (allowed) or coach_membership_id = the caller: a coach always sees the sessions they coach.
• Writes with a locationId outside scope are refused; a restricted caller’s create defaults to their first space.
• Members, plans, leads and business data are not space-filtered for anyone. The role matrix still decides access to modules; PermissionsService.enforce does not change.
• Spotter and MCP tools inherit enforcement because they call the same services.

Relaxed presentation. The client resolves the URL against /users/me before any fetch, so the 403 is a backstop the UI never shows. A link to a space outside the caller’s scope opens their own space with one quiet line: “Main hall isn’t in your spaces, showing Parquet”. No lock, no error page.

6.6 What “All spaces” means

• Board: every space row, in sort_order; with more than 5 spaces, rows fold and a search appears (the program board’s COMPACT_ABOVE).
• Lists: the union of the caller’s spaces; rows carry no space name (§7.6). Where the split matters, a breakdown block shows it.
• Counts and sums: totals first, then one row per space. Every session has exactly one space (§8.3), so session-based totals equal the sum of the rows.
• Distinct people (unique attendees, members active) are not additive; the breakdown says so in a footnote.
• For a restricted caller, “All my spaces (n)” is the union of their spaces plus sessions they coach.
• Business-wide numbers (revenue, payments, debt, active members, retention) appear once, never split, and untagged: nothing in All spaces is filtered, so no tag is needed.

6.7 Missing, other-business and closed spaces

6.8 The member read model: presence is check-ins (approved 2026-10-12, revised the same day)

Members belong to the business. Plan and attendance are separate signals. The plan is the booking gate (TKN-446 buckets decide where a member may book) and changes over time; it drives no widget and is not part of any field below. Presence is what the member actually did: attended (checked-in) bookings only, bookings.status = 'attended' (equivalently checked_in_at not null), on sessions in the space. Booked, confirmed, waitlisted and no-show bookings don’t count. Note that the auto no-show job turns an unchecked booking into no_show 2 hours after class, so a business that never checks people in has almost no presence.

Three facts are derived by the server on read, returned on member lists and the member detail, and never stored or edited.

The same presence rule drives every member-based space metric: “active in”, “trained in {space}”, main space, training across spaces, “new to {space}” (first-ever check-in in that space) and “last active in”. Session-derived widgets that count bookings (Today’s classes, fill, hall load, waitlist, no-show rate) are unchanged: they describe sessions, not member presence.

Few check-ins. When fewer than 10% of the business’s (or the space’s) past bookings in the 60-day window were checked in, every member-based space widget and the members list show one quiet line, “Space numbers come from check-ins. Few check-ins were recorded in the last 60 days.” with a link “Set up check-in” (kiosk door mode, QR). The widget stays; it is never hidden.

• Computed in one SQL pass per page of members (a grouped count of attended bookings joined to class_sessions for the window), next to the existing member list query; no new column, no cache table. If EXPLAIN shows it is heavy, an index on bookings (membership_id, status, checked_in_at) is the first step.
• The 60-day window matches “active in”, so the two never disagree about whether a member trains somewhere.
• In a one-space business the fields exist but nothing renders them.

7. Switcher behavior

7.1 One control, one placement at a time

Exactly one switcher is on screen at any time (decision 15). It is one component with one menu; where it sits depends on whether the sidebar is visible.

• The switcher is the context indicator. With the sidebar open it is the sidebar header; otherwise it is the top-bar button. Either way one is always visible, which keeps the context in view for every persona, the HQ user included.
• Page titles carry no ”· Parquet” suffix (§7.6). In a single space the only space label in the chrome is the switcher itself.
• On a phone the menu opens as a bottom sheet; on desktop it is a popover anchored to the switcher.
• When the placement changes while the menu is open (the sidebar is toggled, or the window crosses the phone breakpoint), the menu closes.

7.2 Menu content

1. Spaces group (2+ spaces the caller may use): All spaces first (“All my spaces (n)” when restricted), then each space in sort_order. A check marks the current one. With more than 7 spaces a filter field appears at the top.
2. Switch organization group (only with 2+ memberships, reusing today’s label and rows): each business with the caller’s role.
3. Reserved, not rendered: a leading Network group for TKN-386.

Someone restricted to one space has no Spaces group; with one membership as well, the switcher is a plain label, not a button.

7.3 Keyboard and screen reader

• The trigger is a button with aria-haspopup="menu", aria-expanded, aria-controls, and an accessible name such as “Working context: CrossFit Rishon City, Parquet. Change.” Enter, Space and ArrowDown open the menu.
• The menu is role="menu"; each group is role="group" labelled by its heading; items are menuitemradio with aria-checked, the Radix pattern today’s switcher already uses. Radix receives dir so arrow keys follow reading order.
• ArrowUp and ArrowDown move, Home and End jump, typing a letter jumps to the matching item, Enter or Space selects, Escape closes and returns focus to the switcher that opened the menu, Tab closes.
• After a switch, focus returns to the switcher that opened the menu. If the switch hid it (on a phone the sidebar sheet closes on switch), focus goes to the switcher now on screen, the top-bar button. A polite live region says “Now working in Parquet”. No toast.
• No global keyboard shortcut in v1: ⌘J already opens Spotter.
• Touch targets are at least 44px on phone; visible focus uses the DESIGN.md ring.

7.4 What happens on switch

• Space to space (same business): the route stays and re-focuses. The URL is replaced with the new space; other parameters (week, tab, from, to) are kept. On the board, the new space’s row expands and moves first, and the previous one folds; nothing disappears. Scoped regions show skeletons in their own geometry; business-wide regions don’t refetch.
• Detail page of a space-bound entity (session builder, kiosk): stays on the entity; the switcher shows the new context. Detail pages of business entities (member, plan) stay.
• Business to business: a full navigation, as today, which clears the cache and re-runs the server role redirects. It lands on the same route when the target role can open it (entity ids dropped), else on the role home.
• The cookie is updated on every explicit switch.

7.5 Unsaved changes

When a form is dirty (an open session sheet with edits, a task draft, an announcement draft), the switch is held and a dialog asks “Discard unsaved changes?”, “Switching to Main hall closes the new session without saving.” The buttons are Keep editing (ghost, focused by default) and Discard and switch (destructive). A clean form switches without asking. The same guard covers beforeunload for business switches.

When the switcher is in the top bar (phone, or desktop with the sidebar hidden), sheets open below the top bar and leave it live, so the switcher stays visible and reachable while a sheet is open and the guard above catches the switch; the sidebar and the page behind the sheet become inert. With the sidebar open on desktop, sheets behave as today: the sidebar header stays visible but is inert until the sheet closes.

7.6 Where a space is shown (decision 5, revised 2026-10-12)

The rule is an allowlist. A space name appears only in these places; everywhere else the switcher is the indicator, and rows, items, cards and tiles carry no space name.

1. The switcher (§7.1): the sidebar header or the top-bar button, whichever is on screen, and its menu, plus the switcher’s own one-line notices (§6.7) and the switch announcement.
2. The folded schedule board: the row headers (on a phone, the section headers), because the rows are the spaces. Session cards inside the rows carry none.
3. The session sheet: the Space field at the top, where you see and change it; the “Move to space” menu; the override dialog; and the move’s own “moved to {space} · Undo” line. Spotter’s write confirmation does the same job, so it names the space too.
4. Breakdown blocks, in All spaces only: per-space rows inside a widget or report (“Main hall 112 · Parquet 45 · Open gym 46”), the Overview “Spaces this week” panel, the Reports space tables (including “Plan coverage vs. check-ins by space”) and “Training across spaces”. These blocks are the space data. In a single-space view they don’t render.
5. Member detail stats: one small per-space line under “Classes this month” (“Parquet 6 · Main hall 3”). This is the only place a member’s spaces are listed.
6. Where a space is configured: Settings → Spaces (with the per-space booking rules in Settings → Booking, TKN-447/448), the template-slot and class-type space pickers, the trial’s session picker, a plan’s bucket scope (TKN-446), and the kiosk header.
7. The area label (§8.5): an area’s name, never a hall’s, as a small muted label on the session card and in the session sheet’s Area field, and in the schedule’s area filter chip. Areas appear nowhere else: not in the switcher, breakdowns, report splits, plan coverage or schedule sections.

Everything else carries no space name, in particular:

• Members list: no “Active in” column, no chips, no ”· main”. The focus chip in the search bar and the count line (“131 active in Parquet · 174 not active here”) stay, because they state the context, not a row’s space.
• ActionCenter: no per-space counts or labels on items. In All spaces each item is one plain total; the switch narrows it.
• At-risk callout rows, Today’s classes rows, task rows, session cards, the coach’s agenda (next class, later today, “Yours in other spaces”), search results, lead and trial rows.
• Announcements: the audience selector names the space once, because it is a choice (“Members active in Parquet”); nothing else does.
• Page titles: no ”· Parquet” suffix; the switcher already says it.

How a name is written: plain text, no colour, no monogram. Always the full name, never abbreviated; on narrow widths it truncates with an ellipsis and keeps the full name in title and the accessible name. Plain text survives colour blindness, dark mode and RTL.

The “Whole business” tag is quiet and rare: small muted text, no border or fill, shown only in a single space where a number ignores the space.

• Once in the page header when the whole page ignores the space (Payments, Coaching, Plans, Settings; tooltip “This page isn’t filtered by space.”), or once in a section header when a whole section or tab does (Reports → Revenue, Reports → Retention, the Overview’s business trend row).
• On a card only where cards on the same screen differ. On Members, “Trained this week” follows the space and carries nothing, while “New this month” and “Churned this month” are tagged.
• In All spaces nothing is filtered, so there are no tags. “By main space” is never a tag either: an attributed number says how it was counted in its muted sub-line.

One-space businesses show none of this.

7.7 Creating inside a space: the main payoff

7.8 One-space businesses and one-membership users

• 0–1 active spaces: the control is exactly today’s org switcher: a plain block with one membership, the dropdown with two or more. No space line, no top-bar button, no space parameter, no “Whole business” tags, no extra request. The schedule looks as it does today (one row, no row header, no toggle).
• The top-bar button appears (when the switcher is in the top bar) when the business has 2+ active spaces or the user has 2+ active memberships. In the second case it shows only the business name, which fixes the phone gap for people who work in several businesses (TKN-28). A user with one membership in a one-space business sees nothing new.
• Going from 1 to 2 spaces turns the control on at the next navigation. Going from 2 to 1 turns it off and strips the parameter.

8. The folded schedule and the session’s space

8.1 Space sections in every view (replaces the space filter and the per-space lanes)

The schedule folds by space inside each of its existing views (Expanded, Condensed, Programming); there is no separate “spaces” view. Each space is a collapsible section holding that view’s normal grid for the space’s sessions. The shared layer is apps/web/src/components/overview/schedule/space-sections.tsx; the folding follows the coaching program board (program-board.tsx: chevron toggle, folded counts, COMPACT_ABOVE, search, attention first).

• A section is the space’s header (name, capacity, mode, a chevron toggle with aria-expanded) and, while open, the view’s own grid for that space: the expanded view’s hour grid, the condensed view’s day columns, or the programming view’s class-type × day matrix. Cards in a section carry no space label; an empty slot or “add” in a section creates the session in that space.
• Folded section: the header plus one count per day (“3”, or ”·” for none), and an “overlapping classes” badge when it holds a clash.
• All spaces: every section in sort_order. Up to 5 start open; above COMPACT_ABOVE = 5 they start folded and a search field filters them.
• One space active: its section is open and pinned first; the others fold to counts. They are never filtered away (except for a restricted caller, whose other spaces don’t exist). Folding is local view state, not context.
• Attention first: within the folded sections, one with a clash in an exclusive space sorts before the others.
• Clashes: two live sessions overlapping in an exclusive space each show an amber marker with a visible tooltip (“Overlaps another class in this space”); the marker is focusable and opens the session. Clashes come from overrides and from data created before the spaces rules applied, since every space starts exclusive.
• Expanded view: stacked sections, each with its own hour grid for that space (never side-by-side space columns: lanes were rejected).
• Programming view: each section lists the class types with sessions in that space, with that space’s counts. Assigning a workout still sets the class type’s day for every space.
• Sessions in a closed space gather in an “Other spaces” section, which takes no new sessions or drops.
• One space in the business, or the spaces flag off: no sections; the three views are today’s.
• Phone: the same stacked collapsible sections.

8.2 Moving a session to another space

• Drag: dragging a session card from one space section onto the same day in another section moves the session; the same day in other sections are the only move targets, so a move never changes the time, and those day columns highlight as targets while dragging. A drop on another day copies the session there instead (TKN-478, unflagged: scheduling › copy a session to another day).
• Keyboard and touch alternative: each card’s menu has “Move to Main hall / Open gym”. The sheet has the same control at its top.
• Checks: the TKN-444 rules run on the target space: an exclusive overlap returns space_conflict, a capacity above the space returns space_capacity_exceeded. Owner/admin see the existing override dialog with a reason (audited class_session.space_override); a coach sees why and can’t override. Nothing moves until the server accepts.
• Feedback: the card appears in its new row with a brief teal edge; a polite live region says “CrossFit 18:00 moved to Main hall”; an “Undo” link in the line moves it back with the same checks.
• Restricted callers can drag only between their own spaces.

8.3 Every session has a space (decision 4)

• Default space. Every business has exactly one default space: locations.is_default boolean NOT NULL DEFAULT false with a partial unique index (organization_id) WHERE is_default AND is_active. A business with no space gets an auto-created “Main space”, invisible while it is the only one. Settings → Spaces marks the default and lets owner/admin change it; the default can’t be deactivated until another is chosen.
• Resolution on create: explicit locationId → class type’s space → org default. The server applies it for every writer (web, Spotter create_many, templates, copy-week, MCP, mobile), so no client has to know.
• Migration sequence, each step a separate migration reviewed with db:generate and applied only with owner approval:
  1. M1 add locations.is_default and the partial unique index.
  2. M2 (data) mark the lowest sort_order active space of each business as default; create “Main space” where a business has none.
  3. M3 (data) backfill class_sessions.location_id where null: the class type’s default_location_id, else the org default. Report counts per business before and after.
  4. M4 class_sessions.location_id SET NOT NULL (migration 0177_session_hall_required). course_sessions.location_id stays nullable (online events use location_text); program_template_slots.location_id stays nullable (null = inherit).
• Tier: the auto-created space counts as the one space Lite allows (maxSpaces).

8.4 The class type’s space is inherited, with a preview

• class_types.default_location_id stops being a one-time prefill and becomes the class type’s space: its sessions inherit it. Null means “the org default space”. The UI label changes from “Default space” to “Space”.
• A session follows its class type while its space equals the class type’s current space (or the org default when the class type has none). A session moved by hand to another space no longer matches, so it stays where it was put. No new column.
• Changing a class type’s space (A → B) moves every future session of that class type whose space is still A. Past sessions never move. Sessions in other spaces don’t move.
• Preview first: the save shows “12 future sessions move from Parquet to Main hall. 2 clash in Main hall (exclusive)”, listing the clashing sessions with date, time and the session they clash with. The owner/admin can override the clashes with one reason, or leave them where they are. Nothing changes until “Move 12 sessions” is confirmed. The same TKN-444 checks and audit run per session.
• Deactivating a space uses the same preview to move its future sessions to the org default first.

8.5 Areas inside a hall (decision 16, TKN-479)

Why. Every prod business has spaces off, so no locations row has ever meant a hall: each one is a place inside the business, like Kinetics’ “Main Floor” and “Floor B” at the same address. Treating them as halls (the earlier M2/M3) would have made Floor B, first by name, Kinetics’ default hall and put its 126 unplaced sessions there.

Model.

• locations.kind (hall | area, enum location_kind, default hall) and locations.parent_id. An area’s parent_id is a hall of the same business; a hall has none. Guarded by a check (kind = 'area' ⇔ parent_id IS NOT NULL) and a composite foreign key (parent_id, organization_id) → (id, organization_id), so an area can’t point at another business; the service refuses an area under an area.
• An area has a name, a capacity and its own concurrency (exclusive/shared). is_default, auto_created and sort_order mean what they did for halls; only a hall can be the default (the partial unique index is over halls).
• class_sessions.location_id is the hall (required, §8.3; NOT NULL in M4). class_sessions.area_id is the optional area, always one of that hall’s areas.
• class_types.default_location_id is the class type’s hall (null = the business default, §8.4); class_types.default_area_id its optional area. program_template_slots.area_id likewise next to the slot’s hall.
• Course sessions keep their one optional location_id (it names an area after the migration; display only).

Migration (replaces the earlier 0174–0176, which ran on no shared database).

1. Schema (0174): the enum and columns above. Existing rows keep the default kind = 'hall' until step 2.
2. Each business gets one hidden default hall (auto_created, shared, is_default, named in its locale: “Main space” / מתחם ראשי / Основной зал), and every existing location becomes one of its areas, shared: 0173 had defaulted every row to exclusive, but no business ever chose a rule and nothing clashed before spaces. With spaces on nothing clashes until staff mark an area or hall exclusive. New halls and areas start shared too; exclusive is an opt-in (ADR-0024 D2, amended 2026-10-16).
3. Sessions: area_id ← the old location_id; location_id ← the business’s hall. Sessions with no location get the hall and no area. Class types and template slots move their location to the area column the same way, leaving the hall column null (the default hall).

Kinetics afterwards: one hidden hall; areas Main Floor and Floor B; its three placed sessions keep their floor; the other 126 are in the hall with no area. Nothing visible changes.

spaces off (every business today): identical to now.

• The “Location” field, picker and Settings → Locations list the default hall’s areas, and create areas under it. Nothing else uses areas.
• A locationId sent by any client (web, mobile, MCP, Spotter) that names an area is read as that area in its hall, so old clients keep working.
• Responses keep locationId (the hall) and add areaId and area; location, the display object mobile, emails and the minisite show, is the area if there is one, else the hall unless it is hidden. Today’s location names therefore render where they render now.
• The tier limit counts active areas against the old Location limit (Lite 1 / Pro 1 / Elite unlimited, PRE_SPACES_MAX_SPACES), the same rows it counts today.

spaces on.

• Settings → Spaces lists halls, each with its areas. The first hall a business creates adopts the hidden hall (same row, made visible), so its areas and sessions stay with it. Halls count toward the tier hall limit (Lite 1 / Pro 2 / Elite unlimited); areas don’t.
• Halls are the spaces of everything above: the switcher, ?space, spaceId, schedule sections, Overview/Reports splits, events. Areas never enter SpaceScopeService; a spaceId naming an area is space_not_found.
• Areas show only per §7.6 item 7: a small label on the card and sheet, an Area field in the sheet when the session’s hall has areas (default: the class type’s area when it belongs to that hall; its empty choice reads “Whole hall” / כל המתחם / Весь зал, since a session without an area uses the whole hall), and an area filter chip on the schedule (“All areas”, a filter, not a place).
• Moving a session to another hall clears its area (an area belongs to one hall).

One hall (or none of its own) with spaces on. A business with the hidden default hall, or a single visible hall, plus areas (Kinetics’ shape) has no hall to choose:

• The session sheets (create, and the detail sheet’s fields) show no Hall field, only the Area field with the default hall’s areas. The create sends the lone hall, or no locationId at all, which the server reads as the default hall. The Hall field and the sheet’s space control appear from two visible halls, the same rule that makes the hall required on create (choosesHall in session-places.ts).
• Booking rules (Settings → Booking) and plan entry quotas offer no hall picker, and a rule or quota for every hall reads with no hall at all (no “in all halls”): with one hall a hall scope is the whole business. A rule or quota already scoped to a hall (set when there were two) still names it, and keeps its picker so the hall can be cleared. Same rule, hasHallChoice in session-places.ts, read through useScopeOptions.
• Settings → Spaces, while no hall is listed, offers Add area (en “Add area” / he הוספת אזור / ru Добавить зону) next to Add hall. It creates with kind: 'area' and no parentId, so the area joins the hidden hall with the other areas waiting there; the first hall added still adopts it with them. With one visible hall its row’s own “Add area” does the same.
• POST …/locations takes an optional kind: area without parentId goes into the default hall (defaultSpaceId), hidden or not; hall with a parentId is a 400, and so is hall with the flag off. Without kind the earlier rules stand: parentId or the flag off makes an area, otherwise a hall.

Clash and capacity rules (ADR-0024 D2/D3, enforced only with spaces on, as before).

• A session in an area clashes with live sessions overlapping it in the same area when the area is exclusive.
• A session without an area clashes with any live session overlapping it in the hall when the hall is exclusive.
• An exclusive hall makes any overlap in the hall a clash, whatever the areas.
• Capacity must not exceed the area’s capacity and the hall’s capacity, where set.
• Every hall and area is shared unless staff opt into exclusive (ADR-0024 D2, amended 2026-10-16): the hidden default hall, every legacy area and every new one. A business meets no clash until staff mark an area or hall exclusive.
• Override, audit (class_session.space_override, now recording areaId too) and the 409 codes are unchanged.

9. Interaction with ADR-0024

• Policies show the effective rule for the active space. In a single space, Settings → Booking (TKN-448) asks the resolver for {space: Parquet} and shows each setting with its value and decidedBy (“Business default”, “This space’s rule”). Editing writes a space-layer rule. In All spaces the page shows the org default layer, then a list of per-space overrides. Precedence stays pinned session > class type > space > program > org (D10).
• The session sheet’s “Rules for this class” panel (TKN-448) uses the session’s own hall, not the context.
• Policy scopes name halls only. A rule’s or bucket’s space condition lists hall ids (locations.kind='hall', Hebrew מתחם); a session in an area is judged by its hall. Areas are never a scope. Built: scheduling behavior › Booking policy rules.
• The board shows conflicts per space (D2): an exclusive clash created with an override shows both cards in the same cell with a warning edge; a shared space allows overlapping cards. The row header shows the space capacity (D3); each card shows booked / capacity.
• D4 changes: “a class type does not belong to a space” still holds (no ownership), but default_location_id is now inherited (§8.4) and class_sessions.location_id becomes NOT NULL (§8.3). This amends D4; record it in ADR-0024’s changelog when S4 lands.
• Template apply groups the conflicts[] report by space (D2).
• Buckets (D5) drive the plan focus on the plans page and the booking gate. They are not part of “active in” or the main space; plan coverage appears only in the Reports block “Plan coverage vs. check-ins by space”.
• Tier (maxSpaces: Lite 1, Pro 2, Elite unlimited): the control appears only with 2+ active spaces. A business that downgrades with more spaces keeps the control; adding a space stays blocked.
• Flags: spaces governs conflict and capacity enforcement and, since 2026-10-18, everything in this plan too (decision 9; the plan first shipped behind its own space-context flag), except the default-space data migrations, which are invisible on their own.

10. States and ranges

11. Interaction and layout

• Hierarchy: switcher, then page title, then content. In the sidebar header it is today’s org block with the space line; as a top-bar button it is quieter than the page title (13px medium, hairline chip) and louder than body text.
• Topology: one switcher on screen at a time (§7.1): the sidebar header while the sidebar is visible on desktop, else one button at the start of the top bar. The menu is a popover on desktop (288px) and a bottom sheet on phone (48px rows, env(safe-area-inset-bottom), overscroll-behavior: contain).
• Responsive: at 390px the top bar is toggle, switcher button, title (truncates first), Spotter. While the sidebar sheet is open, its header is the switcher and the top bar is inert under the scrim. The board becomes stacked space sections for one day (§8.1).
• RTL: logical properties only. The breadcrumb separator and the row chevron flip (rtl:rotate-180, rtl:rotate-90 as on the program board); never a literal ”›”. Days run from the start side. Hebrew is the default case.
• Motion: menu fade and scale 150ms; row fold 150ms; the moved card’s teal edge fades over 1s; all off under prefers-reduced-motion. Transitions list their properties.
• Light and dark: token colours only. Selection is teal, never green.
• One Teal Rule: the switcher has no filled button. The schedule’s one filled button is “New session”; the cascade preview’s is “Move N sessions”.
• Test ids are a contract: keep org-switcher-trigger, org-switcher-item-<orgId>; add context-switcher-topbar (the top-bar placement; the sidebar placement keeps org-switcher-trigger), space-switcher-item-<spaceId>, space-switcher-item-all, space-section, space-section-toggle, space-section-day-count, space-move-option, space-clash-marker.

11.1 Suggested i18n keys (not added)

Hebrew attaches prepositions to names with a maqaf (ל־{space}, ב־{space}). Russian quotes names in «». Counts use ICU plural forms when the keys are added.

12. Stats widgets: metrics and space breakdown

Requested by Saar on 2026-10-12. Source: a code-verified inventory of every stats widget, done on 2026-10-12. Each inventory ID used below (O1–O11, M1–M8, S1–S6, C1–C7, P1–P7, R…) points to its row there. Only session-derived metrics (class_sessions → bookings → bookings.checked_in_at) can be split by space today. Payments, subscriptions, memberships, leads, tasks, assignments, daily programming and forms have no space. No endpoint takes a space parameter today.

12.1 Rules

1. No space for money, ever. Receipts, MRR, debt, refunds, plan revenue and payment methods are whole business in every view.
2. The switcher labels filtered numbers; tiles don’t. In a single space, a tile that follows the space carries no space name and no tag. A number that ignores the context keeps its value when the space changes and is marked by the quiet “Whole business” rule (§7.6): once per page or section that ignores the space, on a card only where it sits next to cards that follow the space. In All spaces there are no tags. Attributed numbers say “by main space” in their muted sub-line, never as a tag.
3. Space behaviour has three kinds:
   • Follows space: session-derived; filtered by spaceId.
   • Whole business: money, subscriptions, member growth, leads, cancellations, coaching, and tasks without a space. It ignores ?space=.
   • Attributed: people are counted under their derived main space (§6.8, check-ins only). The tile always says how it was attributed. Plan coverage is never a widget; it appears only in the Reports block “Plan coverage vs. check-ins by space”.
4. Breakdowns that don’t add up carry a footnote marker (*). The main-space split of distinct people adds up, including a “No check-ins in the last 60 days” row where people are concerned. The “active in” split overlaps; it is available on a toggle and footnoted.
5. Few check-ins: every member-based space widget shows the quiet line from §6.8 when check-ins are under 10% of past bookings in the window, with a link to check-in setup. The widget is never hidden.
6. In All spaces, every follows-space tile gets a breakdown: a compact row per space with the value, a share bar, and the share of the total. Ratios (fill, attendance rate, no-show rate) show the value per space without a share bar, because ratios have no share.
7. In one space, the tile shows the space’s value and, where it helps, a muted line “of {business total}”. No space name, no breakdown rows, no per-space blocks (§7.6 item 4).
8. Charts.
   • One space: the space’s series, with a faint whole-business line only where comparison helps (attendance by day, fill). Not on counts, where the scales differ.
   • All spaces: stacked areas or bars per space, at most 5 spaces, then “Other”, with a legend using the space names. Heatmaps and tables stay totals, and a cell’s tooltip lists the split.
9. Single-space businesses see exactly today’s widgets: no tags, no breakdowns, no new tiles, no new requests.
10. Roles are unchanged from the matrix: analytics O,A; paymentAnalytics O,A; leads O,A; tasks O,A,C; classSessions O,A,C. Coaches keep the Today panel, Pending tasks, the schedule strip and their ActionCenter rules. A staff member the owner restricted gets breakdowns only for their spaces, and business totals stay hidden from them only where the role already hides them.

12.2 Widget table

API columns:

• “spaceId”: the endpoint takes ?spaceId= and filters.
• “groupBy=space”: the response gains bySpace: [{ spaceId, …same metrics }].
• “groupBy=mainSpace”: people are grouped by the derived main space (§6.8), with a none bucket.

Segmentation column:

• “today” means the API already returns it.
• “new” means it needs a new groupBy. The new values are classType, coach, weekdayHour, plan, newVsReturning and outcome, where outcome is attended, no-show, late cancel or unmarked.

Overview (OverviewV2)

Members, Payments, Schedule, Coaching

Reports workspace (basic-reports)

Built in S5 (TKN-464). Reports follow the switcher’s ?space=; there is no second space control. With the context on, the snapshot (/analytics/dashboard), the attendance report (/analytics/attendance/report) and retention (/analytics/members/cohorts, All spaces only) are read with groupBy=space, which adds the split over every space whatever spaceId narrows the headline to (so a space’s figures equal its row, and session and check-in counts add up). The same groupBy=space adds bySpace to /analytics/attendance/summary, /analytics/attendance/daily and /bookings/attendance-trend; /analytics/classes/utilization has it since S5b. People come back in both views at once, so the “Main space | Active in” toggle never refetches: byMainSpace (each person once, under the space with the most check-ins in the 60 days before the reference time, ties to the latest, a “No check-ins in the last 60 days” row; adds up) and activeIn (every space they checked in at, or for visitors every space they visited in the range; footnoted *). The reference time is now for the snapshot, the range’s end for visitors, asOf for members on the date and each departure for “left”. This is a groupBy=space view rather than a separate groupBy=mainSpace. The “Spaces” section reads GET /analytics/spaces/range?from&to (the week report over a range; 404 space_context_off without the context), whose presence.activeIn is the “Checked in” column of plan coverage; the coverage endpoint itself waits on TKN-446, so its columns read “Available once plans are tied to spaces”. Revenue, payments, debt, plans and membership never take a space; in a single space each tab says so once. Attendance exports carry the space: one row per class and space with groupBy=space, the space’s id and name when scoped. Deferred: the Trials tile and column (S6: trials have no space yet), coverage columns (TKN-446).

12.3 New space widgets (owner and admin, only with 2+ spaces)

These appear on the Overview as one “Spaces this week” panel, under Today and Pending tasks. In Reports they appear as a “Spaces” section on the Attendance tab, over the selected range. Both are breakdown blocks: All spaces only, never in a single space (§7.6 item 4).

Dropped:

• Prevented clashes: a 409 space_conflict is not recorded anywhere, so blocked attempts can’t be counted. A PostHog event could add this later if Victor asks for it.
• Room utilisation against opening hours: spaces have no opening hours, so “hours used ÷ hours open” can’t be computed (TKN-391).

12.4 ActionCenter items with a space

Built in S5b (TKN-467). groupBy=space on /sessions/upcoming-today, /analytics/classes/utilization and /insights returns a split over every space, whatever spaceId narrows the headline figures to (so a space’s figures equal its row), with a spaceId: null row for sessions with no space or in a closed space, so session counts add up to the total. spaceId on /insights narrows the four space rules below and puts them first. The two new rules and “Spaces this week” (GET /analytics/spaces/week, 404 space_context_off without the context) run only while the org has the context (flag on, 2+ active spaces). Overlaps and overrides (the operations.space_overlaps rule and the panel’s overlap line) also need the spaces flag, because a hall or area marked exclusive only means something while the TKN-444 rules are enforced. The O2 “booked” tightening is not applied: the Today split counts confirmed bookings, as the rows do, so a one-space business keeps today’s numbers.

A coach keeps exactly their current rules; their space rules follow the context.

13. Implementation slices

Each slice is a candidate Linear ticket under TKN-459. Every slice follows the TKN-444 constraints: strings in en, he and ru; behavior behind the one per-org PostHog flag (space-context then; spaces since 2026-10-18), default off and identical to today when off; db:generate reviewed and never db:migrate without owner approval; feature docs updated.

New API parameters, all on existing endpoints and all optional:

• spaceId on space-bound reads;
• groupBy=space on session-derived analytics;
• groupBy=mainSpace on people counts;
• asOf reused for the main space on cohorts.

Without them, responses are byte-identical to today.

Downstream tickets that consume the context (not new slices): TKN-446 (plan focus, per-bucket balances), TKN-448 (effective policy per space), the member-app space filter, Spotter tool defaults. ADR-0024 D4 gets an amendment note when S4 lands (§9).

Kiosk door (S7, built)

/[lang]/kiosk/space/[hallId] is one hall’s check-in door: the regular kiosk’s QR code and roster for the session checking in now, the next session in a strip at the bottom, and the hall’s name in the header (§7.6 item 6). It asks GET /organizations/:orgId/sessions/door/:hallId every 30 s and again at the response’s advancesAt, so it moves on by itself:

• Now is the session that hasn’t ended whose check-in opened last (30 minutes before its start, the self check-in window). Back-to-back classes hand over when the next one’s check-in opens. Next is the first session after it within 24 hours. With nothing checking in, the door says so and shows when check-in opens.
• Entry: in the dashboard with one hall active (?space=), a class of that hall opens the hall’s door from the session sheet’s “Open display”. In All spaces, for a class in another hall, or with the context off, it opens that session’s kiosk as before.
• Gate: the API goes through SpaceScopeService.resolveDoor, which calls resolve (the one place S2 will narrow a staff member’s halls) and adds the 2+ active halls rule. Flag off or one hall: 404, and the web route renders Next’s 404, exactly as before the route existed. A 403 on a later poll drops the roster (“This tablet’s access to {hall} ended”).
• Later: an area door (?area=<areaId>, filtering class_sessions.area_id) adds an optional areaId to the door loader (findKioskDoor(orgId, clerkId, { hallId })) and to the route; nothing else changes.

Analytics

Event names live in libs/shared/src/lib/analytics/space-events.ts (SpaceEvents). Server events go through EventTrackingService.track with the organization group. Every event fires only while its flag is on for the org, and none carries a space’s name or any person’s details.

While a business has the context, the web registers space_id (a space id or all) as a PostHog super property, so every client event names the context it happened in. It is cleared when a business has no context and on every business switch, because PostHog persists super properties across page loads.

Sentry and log fields are in docs/architecture/observability.md#space-context.

14. Resolved decisions

Saar, 2026-10-12.

1. URL: query parameter ?space=, enforced on the server against the caller’s spaces; a restricted caller gets no data from a space outside them (§6.2, §6.5).
2. Access is opt-out: every staff member has every space by default; the owner may restrict a specific staff member to chosen spaces (§6.5).
3. Relaxed presentation: no forbidden page; a coach always sees the sessions they coach; members stay business-wide for everyone and are only focused, never hidden (§5.3, §6.7).
4. Every session has a space: a default space per business, a backfill and NOT NULL in separate owner-approved migrations, the class type’s space inherited with a previewed cascade for future followers, easy moves on the sheet and by drag (§8).
5. Where a space is shown (revised 2026-10-12): an allowlist. A space name appears only in the context control, the board’s row headers, the session sheet (Space field, Move to space, the override dialog), breakdown blocks in All spaces, the member detail’s one per-space line, and where a space is configured (Settings → Spaces, the space pickers, the kiosk header). Nowhere else: no “Active in” column, no ”· main”, no page-title suffix, no names on ActionCenter items, Today rows, task rows, session cards, the agenda, search results or trial rows. Names are plain text in full, never abbreviated or coloured. “Whole business” tags are quiet: one per page or section that ignores the space, on a card only where cards on one screen differ, none in All spaces (§7.6).
6. Money is whole business: reports get a space scope for attributable reports only (S5).
7. Out-of-scope link: opens the caller’s own space with one quiet line (§6.7).
8. No specialist persona (§1).
9. One flag: spaces (§13) (it shipped behind its own space-context flag, folded into spaces on 2026-10-18).
10. PRODUCT.md: the positioning proposal is applied (§15.3).
11. Members across spaces (approved 2026-10-12): a “No check-ins in the last 60 days” group in every space view and as an opt-in on announcements; a derived, never-stored mainSpaceId that orders and drives the member app and a “by main space” report, but never limits; the count line “{active} active in {space} · {notActive} not active here” (§5.3, §6.8).
12. Stats widgets (requested 2026-10-12): every widget is classed as follows space, Whole business or attributed (by main space); no space for money; breakdowns per space, in All spaces only, with footnotes where they overlap; a “Spaces this week” panel; ActionCenter items filtered by the space, never labelled (§12, S5, S5b, §7.6).
13. Members page widgets (requested 2026-10-12): the Members header by space: the donut as a people filter over members active in the space, “New to a space” and churn by last main space as All-spaces breakdowns, the at-risk list filtered (never labelled, never a summed debt per space), the cross-space widget in All spaces, and one per-space line on the member detail (§12.2, §12.3).
14. Presence is check-ins; plans are separate (2026-10-12): the plan is the booking gate and drives no widget; plan coverage appears only in the Reports block “Plan coverage vs. check-ins by space”. Active in, trained in, main space, training across spaces, new to and last active in count attended (checked-in) bookings only; no plan fallback for the main space. “Not active in any space yet” becomes “No check-ins in the last 60 days”. Member-based space widgets show a quiet few-check-ins line with a link to check-in setup, never hiding (§6.8, §12).
15. One switcher on screen (2026-10-12): never two at once. With the sidebar open on desktop, the sidebar header is the switcher and the top bar shows the page title only. When the sidebar isn’t visible (phone, or desktop with the sidebar hidden), the switcher is one button at the start of the top bar, with the business inside its menu; while the phone sidebar sheet is open, its header takes over and the top bar is inert. Focus returns to the switcher that opened the menu. No page-title suffix (§7.1, §7.3–7.6).
16. Three levels: branch, hall, area (Saar, 2026-10-15, TKN-479): a branch is its own business; a hall (this document’s “space”) has its own plans, reports and schedule; an area is a place inside a hall that only says where a class runs. Every existing location becomes an area of one hidden default hall; areas show only as a label, a sheet field and a filter chip (§7.6 item 7, §8.5).

Rejected (2026-10-12): the schedule space filter and the per-space lanes, replaced by the folded board (§8.1); access control as a hard boundary, replaced by decisions 2, 3 and 7.

15. Constraints and evidence

15.1 Binding constraints

• Planning only in this pass: no production code, migrations or app UI. The PRODUCT.md positioning edit is the one product-doc change, on Saar’s decision.
• Hebrew-first RTL, light and dark, phone width, logical properties, skeletons not spinners, the shadcn sidebar shell, One Teal Rule (apps/web/DESIGN.md).
• Strings go to libs/shared/src/lib/i18n/dictionaries/{en,he,ru}.json when built (§11.1).
• Test ids and accessible names used by e2e drivers are a contract (PRODUCT.md).
• Every behavior change ships behind spaces, default off, identical to today when off.
• Decisions made on 2026-10-11 and 2026-10-12 are not reopened; ADR-0024 D1–D3 and D5–D12 and maxSpaces stand; D4 is amended by decision 4 (§9).

15.2 What the running app showed (spaces branch, http://localhost:3010 , 1440px and 390px, Hebrew, dark)

• The org switcher sits in the sidebar header and lists every active membership, including those where the user is a customer (“Taikan Demo Gym · לקוח”). Switching hard-navigates to the role home.
• At 390px the top bar shows only the sidebar toggle, the page title and Spotter. The business name is visible only after opening the sidebar sheet. This is the gap the top-bar switcher button closes.
• The new-session sheet hides Space under “Additional details (date, time, title, space, capacity & notes)”, defaulting to “No space”. This is the “remember to set the space” burden in one screen; §7.7 moves the space to the top and §8.3 removes “No space”.
• Settings → Spaces lists spaces as אולמות (Hebrew “halls”); Russian uses Залы. On 2026-10-14 Saar changed the Hebrew term to מתחם / מתחמים (an area or compound, which fits a hall, a studio or an outdoor yard alike); Russian keeps Залы. The copy follows those terms; “branch” is not a UI word today, so the UI says the business name, “business” (עסק, клуб) or “organization” where existing keys already do.
• Analytics already keeps its state in the URL (?tab=attendance&from=…&to=…&months=6): the precedent for ?space=.
• The schedule week view has no space filter, and the session cards carry no space.
• The coaching program board (program-board.tsx, week-grid.tsx) already has the row toggle, CollapsedCell, COMPACT_ABOVE = 5, search, attention ordering and drag between cells with dnd-kit that S4 reuses.
• Pre-existing, outside this scope: at 390px the members header’s primary button (“הזמנת לקוח”) is clipped at the screen edge.

15.3 PRODUCT.md (applied 2026-10-12)

Applied to apps/web/PRODUCT.md in this worktree:

• Users: “almost always a single location” became “almost always a single branch. Most train in one space; a minority (Pro) run two to five spaces, such as halls or rooms, inside that branch.”
• Capabilities and constraints: kept “Not an enterprise multi-location platform” and “not nutrition coaching”, and added “Several spaces inside one branch are supported on Pro and above. Separate branches are separate organizations that a person switches between; there is no consolidated network view.”

15.4 Sources read

Linear: TKN-358 (with the 2026-10-09 comment and the review “Architect review: Arbox vs Taikan subscriptions and policies (2026-10-09)”), TKN-459, TKN-28, TKN-386, TKN-387, TKN-313, TKN-391, TKN-444, TKN-446, TKN-447, TKN-383, TKN-385, TKN-356, TKN-382. Code: libs/shared/src/lib/permissions/matrix.ts, apps/api/src/auth/permissions.service.ts, apps/api/src/auth/sales-workspace-access.service.ts, apps/web/src/components/shared/org-switcher.tsx, apps/web/src/providers/active-org-provider.tsx, apps/web/src/lib/active-org.ts, apps/web/src/components/overview/sidebar-nav.tsx, apps/web/src/config/dashboard-sections.ts, apps/web/src/components/overview/programming/{program-board,week-grid}.tsx, apps/web/PRODUCT.md, libs/db/src/lib/schema/{scheduling,program-templates,courses,tasks,announcements,sales-workspace,sales-workspace-access}.ts, docs/features/locations/behavior.md, docs/features/spotter-agent/behavior.md. Guidelines: Vercel Web Interface Guidelines (command.md).