BC
Brad CodyAdministrator
Current productEntities and profiles
Reverse spec drafted

Designer Studio Profile

Studio identity, Matching Profile, qualifications, capacity, Credentials, team relationships, Assignments and network standing.

Observed route/admin/designer-network/:idFuture Spec 04
Current maturityBroad Studio Profile with inconsistent shared data and several placeholder modules
Evidence confidenceVerified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

Atelier Maison has a substantial Designer Studio Profile with identity, Network Status, Matching Profile, capacity, person-level Designer Profile, Credentials, Assignments and reusable Activity, Notes, Files, Tasks and Communication modules. Performance is a placeholder. Activity and History show the same administrative-access events. The Team tab badge says two while the embedded Teammates grid initially reports zero, and the profile’s Log in to workspace action represents privileged cross-Workspace access without safe terminology or an exposed reason/expiry flow.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
Identity headerStudio initials, display and legal names, Toronto, update date, Active status and internal slug in the subtitle.Verified live
ActionsLog in to workspace and Change status.Verified; administrative access not initiated
Profile tabsOverview, Team, Credentials, Assignments, Activity, Notes, Files, Tasks, Communication, Performance and History.All tabs reviewed
Matching ProfilePrimary Designer, address, Service Areas, specialties, styles, Project types, budget bands, languages and incomplete social/team/travel fields.Verified live
Capacity and standingProfile Completeness 100%, Available, next start Aug 31, Capacity 65%, one active Assignment and Demo Administrator Network owner.Verified live
Designer ProfilesAmelia Martin is rendered as a person-level shared-user extension with biography.Verified live
Status transitionActive may transition to Paused, Suspended or Offboarding with required reason and Activity impact preview.Modal reviewed without confirming
Profile editorIdentity, contact, social, address, matching, capacity, primary Designer, visibility and person-level availability/languages/biography.Full editor reviewed without saving

User journeys

Current flows

01

Review Studio readiness

  1. Open Studio Profile
  2. Review Matching Profile, Capacity and Credentials
  3. Review Assignments and Activity
  4. Identify missing or stale requirements
Observed result

Working for seeded data.

02

Change Network Status

  1. Select Change Status
  2. Choose allowed transition
  3. Provide reason
  4. Review impact
  5. Confirm
  6. Write Activity and audit
Observed result

Transition modal verified; no mutation performed.

03

Administrative Workspace access

  1. Request access
  2. Provide reason and support/incident reference
  3. Use recent authentication
  4. Start time-limited session with visible banner
  5. Exit and preserve audit
Observed result

Current UI exposes Log in to workspace; only enter/exit audit events prove the feature has been used. Safety gates were not observed.

State model

Current and expected states

Active

Profile and Matchmaking data are available.

Paused, Suspended or Offboarding

Valid transitions appear with reason requirement.

People loading/conflict

Team badge shows 2 while embedded metrics show zero and table says Loading teammates….

Empty shared modules

Notes, Tasks, Communication and Performance have empty states.

Credential verified

One Professional Liability Insurance Credential is verified through Dec 31, 2026.

Product rules

Non-negotiable boundaries

  • Designer Studio Profile and individual Designer Profile are distinct canonical records.
  • Team data comes from Workspace Memberships; badge, metrics and grid use the same authorized query.
  • Administrative Access Sessions require authority, reason, recent authentication, narrow scope, expiry, a persistent banner and immutable audit.
  • Activity and History have distinct purposes and may not be identical aliases.
  • Profile Completeness is explainable and does not itself grant eligibility.
  • Network Status transitions execute a governed impact transaction.
Dependencies
Designer Studio EntityWorkspace and MembershipsDesigner ProfilesMatching ProfileCredentials and FilesOffers and Project AssignmentsTasks, Communication and ActivityPermissions and administrative access controls

Known current limitations · 7 mapped

What is missing, broken or unverified

Future Spec 04 owns closure →
  1. Profile subtitle exposes an internal slug instead of the Studio ID.
  2. Team badge and embedded Teammate counts conflict.
  3. Assignments still says Leads & Assignments, Manage brokerage, Shared CRM lead and Open lead.
  4. Activity and History are duplicates.
  5. Performance has no snapshots.
  6. Shared platform connection IDs such as crm-account-am are implementation-facing.
  7. Administrative access safety controls are not visible.

Future alignment

Required evolution

  • 01Adopt the Entity Profile architecture and canonical Studio ID.
  • 02Resolve Membership-backed people counts.
  • 03Replace legacy Assignment and brokerage language.
  • 04Separate Activity from History.
  • 05Harden and rename cross-Workspace access.
  • 06Connect Projects, reporting and shared modules to canonical records rather than readiness placeholders.

Current baseline

Acceptance record

  • All eleven Profile tabs and key Overview fields are inventoried.
  • No status, profile or Workspace mutation occurred.
  • Privileged access and data-count conflicts are release issues.

Reverse-spec completeness

Documentation coverage

The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.

Purpose and user outcome

Documented

Roles and access

Documented

Routes and entry points

Documented

Page and component anatomy

Documented

Fields and displayed data

Documented

Primary actions

Documented

Forms and validation

Documented

States and transitions

Documented

Empty, loading and error states

Documented

Responsive behavior

Partial

Accessibility behavior

Partial

Activity and audit events

Partial

Data sources and persistence

Documented

Notifications and automation

Partial

Known defects and limitations

Documented

Reusable component dependencies

Documented

Future-spec conflicts

Partial

Visual and repository evidence

Deferred

Acceptance of current baseline

Documented