@openhi/constructs 0.0.159 → 0.0.160

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -30,16 +30,54 @@ declare const DEMO_PERIOD: {
30
30
  readonly start: "2026-01-01T00:00:00Z";
31
31
  };
32
32
 
33
- /** Placeholder Tenant id seeded by the workflow as the dev-user `currentTenant`. */
33
+ /**
34
+ * Placeholder Tenant id.
35
+ *
36
+ * The placeholder is a **system sentinel**, not a user-facing demo
37
+ * tenant. It exists for two reasons:
38
+ *
39
+ * 1. `pre-token-generation.handler.ts` stamps this id into the
40
+ * JWT `ohi_tid` claim when a User cannot be resolved (no
41
+ * DynamoDB record, missing `currentTenant`/`currentWorkspace`,
42
+ * etc.) so the token still satisfies `openHiContextMiddleware`
43
+ * and downstream APIs return a deterministic 403 instead of
44
+ * crashing on a missing claim.
45
+ * 2. The seed workflow re-asserts a Tenant + Workspace record at
46
+ * these ids so the JWT fallback dereferences to a real DynamoDB
47
+ * row (avoids dangling references on read paths that follow
48
+ * `Tenant/placeholder-tenant-id`).
49
+ *
50
+ * Dev users' `currentTenant`/`currentWorkspace` no longer point here
51
+ * (issue #1301) — they point at the on-site demo tenant below. The
52
+ * placeholder records remain seeded purely as a structural sentinel.
53
+ */
34
54
  declare const PLACEHOLDER_TENANT_ID = "placeholder-tenant-id";
35
- /** Placeholder Workspace id seeded by the workflow as the dev-user `currentWorkspace`. */
55
+ /** Placeholder Workspace id. See {@link PLACEHOLDER_TENANT_ID}. */
36
56
  declare const PLACEHOLDER_WORKSPACE_ID = "placeholder-workspace-id";
57
+ /**
58
+ * Stable Tenant id for the on-site-medical UAT demo tenant
59
+ * (issue #1301). Downstream demo-data tickets (#1302 providers,
60
+ * #1303 facilities, #1304 patients/encounters, etc.) import this
61
+ * constant to attach their fixture resources without re-discovering
62
+ * the tenant.
63
+ *
64
+ * This is the tenant every seeded dev user lands on at sign-in
65
+ * (`currentTenant` on the seeded User resource). UAT testers see
66
+ * "On-Site Medical — Demo" in the Tenant Switcher on first sign-in.
67
+ */
68
+ declare const ON_SITE_DEMO_TENANT_ID = "on-site-demo-tenant";
69
+ /**
70
+ * Stable Workspace id under {@link ON_SITE_DEMO_TENANT_ID}. Single
71
+ * workspace for v1 UAT; workspace topology (per business line vs
72
+ * per jurisdiction) is deferred pending an ADR (#1301 design note).
73
+ */
74
+ declare const ON_SITE_DEMO_WORKSPACE_ID = "on-site-demo-workspace";
37
75
  /**
38
76
  * Dev-user descriptor. Every entry produces:
39
77
  * - one Cognito user (idempotent create-then-skip),
40
78
  * - one DynamoDB User record (id = `dev-<email-local-part>`),
41
- * - four Memberships (placeholder + the three demo tenants),
42
- * - four `tenant-admin` RoleAssignments (one per tenant the user
79
+ * - five Memberships (placeholder + on-site demo + three demo tenants),
80
+ * - five `tenant-admin` RoleAssignments (one per tenant the user
43
81
  * belongs to),
44
82
  * - one `system-admin` RoleAssignment scoped to {@link PLATFORM_SCOPE_TENANT_ID}.
45
83
  */
@@ -48,6 +86,10 @@ interface DemoDevUser {
48
86
  readonly id: string;
49
87
  /** Email used as the Cognito `Username` and as the seed for the password algorithm. */
50
88
  readonly email: string;
89
+ /** Given name, populated on the seeded User FHIR resource as `name[0].given[0]`. */
90
+ readonly firstName: string;
91
+ /** Family name, populated on the seeded User FHIR resource as `name[0].family`. */
92
+ readonly lastName: string;
51
93
  }
52
94
  /**
53
95
  * Hardcoded dev-user roster. Adding a new developer is a one-line
@@ -58,8 +100,9 @@ interface DemoDevUser {
58
100
  declare const DEV_USERS: ReadonlyArray<DemoDevUser>;
59
101
  /**
60
102
  * A single workspace inside a demo tenant. The mixed tenant has two
61
- * workspaces (wound-care and primary-care sub-workspaces); the other
62
- * two tenants have one each.
103
+ * workspaces (wound-care and primary-care sub-workspaces); every
104
+ * other tenant (placeholder, on-site demo, wound-care, primary-care)
105
+ * has exactly one.
63
106
  */
64
107
  interface DemoWorkspaceSpec {
65
108
  /** Stable id (DynamoDB record id; also drives the canonical OHI URN). */
@@ -80,9 +123,10 @@ interface DemoWorkspaceSpec {
80
123
  */
81
124
  interface DemoTenantSpec {
82
125
  /**
83
- * Scenario slug — `placeholder`, `demo-wound-care`, `demo-primary-care`,
84
- * `demo-mixed`. The placeholder tenant's slug is `placeholder`; the
85
- * three demo tenants use `demo-*` slugs.
126
+ * Scenario slug — `placeholder`, `on-site-demo`, `demo-wound-care`,
127
+ * `demo-primary-care`, `demo-mixed`. The placeholder tenant uses
128
+ * `placeholder`; the on-site UAT demo tenant uses `on-site-demo`
129
+ * (#1301); the three demo tenants use `demo-*` slugs.
86
130
  */
87
131
  readonly scenario: string;
88
132
  /** Stable id (DynamoDB record id; also drives the canonical OHI URN). */
@@ -93,17 +137,22 @@ interface DemoTenantSpec {
93
137
  readonly workspaces: ReadonlyArray<DemoWorkspaceSpec>;
94
138
  }
95
139
  /**
96
- * The full demo-tenant graph. Four entries: the placeholder tenant the
97
- * JWT-claim fallback resolves to, plus the three v1 demo scenarios
98
- * (OPS-009 §"v1 scenarios"):
140
+ * The full demo-tenant graph. Five entries: the placeholder tenant
141
+ * the JWT-claim fallback resolves to, the on-site-medical UAT demo
142
+ * tenant every dev user lands on at sign-in (#1301), and the three
143
+ * v1 demo scenarios (OPS-009 §"v1 scenarios"):
99
144
  *
100
145
  * 0. Placeholder tenant — dereferences the JWT-claim fallback in
101
- * `pre-token-generation.handler.ts` and acts as every dev user's
102
- * `currentTenant`/`currentWorkspace` so Post-Confirmation skips
103
- * default provisioning when a seeded User signs in.
104
- * 1. Single-workspace wound-care tenant.
105
- * 2. Single-workspace primary-care tenant.
106
- * 3. Two-workspace mixed tenant exercises the cross-workspace
146
+ * `pre-token-generation.handler.ts`. Carries no user-facing
147
+ * content; exists purely so the JWT fallback resolves to a real
148
+ * DynamoDB row instead of dangling.
149
+ * 1. On-site-medical UAT demo tenant — every seeded dev user's
150
+ * `currentTenant`/`currentWorkspace`. Downstream demo-data
151
+ * tickets (providers, facilities, patients) attach to this
152
+ * tenant via {@link ON_SITE_DEMO_TENANT_ID}.
153
+ * 2. Single-workspace wound-care tenant.
154
+ * 3. Single-workspace primary-care tenant.
155
+ * 4. Two-workspace mixed tenant — exercises the cross-workspace
107
156
  * isolation flow that single-workspace tenants cannot.
108
157
  */
109
158
  declare const DEMO_TENANT_SPECS: ReadonlyArray<DemoTenantSpec>;
@@ -146,4 +195,4 @@ declare const openhiResourceIdentifier: (params: {
146
195
  */
147
196
  declare const demoRolesForUserInTenant: (_user: DemoDevUser, _tenantId: string) => ReadonlyArray<PlatformRoleCode>;
148
197
 
149
- export { DEMO_PERIOD as D, OPENHI_RESOURCE_URN_SYSTEM as O, PLACEHOLDER_TENANT_ID as P, SEED_DEMO_DATA_CONSUMER_NAME as S, DEMO_TENANT_SPECS as a, DEMO_URN_SYSTEM as b, DEV_USERS as c, type DemoDevUser as d, type DemoTenantSpec as e, type DemoWorkspaceSpec as f, PLACEHOLDER_WORKSPACE_ID as g, demoMembershipId as h, demoRoleAssignmentId as i, demoRolesForUserInTenant as j, demoScenarioIdentifier as k, openhiResourceIdentifier as o };
198
+ export { DEMO_PERIOD as D, ON_SITE_DEMO_TENANT_ID as O, PLACEHOLDER_TENANT_ID as P, SEED_DEMO_DATA_CONSUMER_NAME as S, DEMO_TENANT_SPECS as a, DEMO_URN_SYSTEM as b, DEV_USERS as c, type DemoDevUser as d, type DemoTenantSpec as e, type DemoWorkspaceSpec as f, ON_SITE_DEMO_WORKSPACE_ID as g, OPENHI_RESOURCE_URN_SYSTEM as h, PLACEHOLDER_WORKSPACE_ID as i, demoMembershipId as j, demoRoleAssignmentId as k, demoRolesForUserInTenant as l, demoScenarioIdentifier as m, openhiResourceIdentifier as o };
@@ -30,16 +30,54 @@ declare const DEMO_PERIOD: {
30
30
  readonly start: "2026-01-01T00:00:00Z";
31
31
  };
32
32
 
33
- /** Placeholder Tenant id seeded by the workflow as the dev-user `currentTenant`. */
33
+ /**
34
+ * Placeholder Tenant id.
35
+ *
36
+ * The placeholder is a **system sentinel**, not a user-facing demo
37
+ * tenant. It exists for two reasons:
38
+ *
39
+ * 1. `pre-token-generation.handler.ts` stamps this id into the
40
+ * JWT `ohi_tid` claim when a User cannot be resolved (no
41
+ * DynamoDB record, missing `currentTenant`/`currentWorkspace`,
42
+ * etc.) so the token still satisfies `openHiContextMiddleware`
43
+ * and downstream APIs return a deterministic 403 instead of
44
+ * crashing on a missing claim.
45
+ * 2. The seed workflow re-asserts a Tenant + Workspace record at
46
+ * these ids so the JWT fallback dereferences to a real DynamoDB
47
+ * row (avoids dangling references on read paths that follow
48
+ * `Tenant/placeholder-tenant-id`).
49
+ *
50
+ * Dev users' `currentTenant`/`currentWorkspace` no longer point here
51
+ * (issue #1301) — they point at the on-site demo tenant below. The
52
+ * placeholder records remain seeded purely as a structural sentinel.
53
+ */
34
54
  declare const PLACEHOLDER_TENANT_ID = "placeholder-tenant-id";
35
- /** Placeholder Workspace id seeded by the workflow as the dev-user `currentWorkspace`. */
55
+ /** Placeholder Workspace id. See {@link PLACEHOLDER_TENANT_ID}. */
36
56
  declare const PLACEHOLDER_WORKSPACE_ID = "placeholder-workspace-id";
57
+ /**
58
+ * Stable Tenant id for the on-site-medical UAT demo tenant
59
+ * (issue #1301). Downstream demo-data tickets (#1302 providers,
60
+ * #1303 facilities, #1304 patients/encounters, etc.) import this
61
+ * constant to attach their fixture resources without re-discovering
62
+ * the tenant.
63
+ *
64
+ * This is the tenant every seeded dev user lands on at sign-in
65
+ * (`currentTenant` on the seeded User resource). UAT testers see
66
+ * "On-Site Medical — Demo" in the Tenant Switcher on first sign-in.
67
+ */
68
+ declare const ON_SITE_DEMO_TENANT_ID = "on-site-demo-tenant";
69
+ /**
70
+ * Stable Workspace id under {@link ON_SITE_DEMO_TENANT_ID}. Single
71
+ * workspace for v1 UAT; workspace topology (per business line vs
72
+ * per jurisdiction) is deferred pending an ADR (#1301 design note).
73
+ */
74
+ declare const ON_SITE_DEMO_WORKSPACE_ID = "on-site-demo-workspace";
37
75
  /**
38
76
  * Dev-user descriptor. Every entry produces:
39
77
  * - one Cognito user (idempotent create-then-skip),
40
78
  * - one DynamoDB User record (id = `dev-<email-local-part>`),
41
- * - four Memberships (placeholder + the three demo tenants),
42
- * - four `tenant-admin` RoleAssignments (one per tenant the user
79
+ * - five Memberships (placeholder + on-site demo + three demo tenants),
80
+ * - five `tenant-admin` RoleAssignments (one per tenant the user
43
81
  * belongs to),
44
82
  * - one `system-admin` RoleAssignment scoped to {@link PLATFORM_SCOPE_TENANT_ID}.
45
83
  */
@@ -48,6 +86,10 @@ interface DemoDevUser {
48
86
  readonly id: string;
49
87
  /** Email used as the Cognito `Username` and as the seed for the password algorithm. */
50
88
  readonly email: string;
89
+ /** Given name, populated on the seeded User FHIR resource as `name[0].given[0]`. */
90
+ readonly firstName: string;
91
+ /** Family name, populated on the seeded User FHIR resource as `name[0].family`. */
92
+ readonly lastName: string;
51
93
  }
52
94
  /**
53
95
  * Hardcoded dev-user roster. Adding a new developer is a one-line
@@ -58,8 +100,9 @@ interface DemoDevUser {
58
100
  declare const DEV_USERS: ReadonlyArray<DemoDevUser>;
59
101
  /**
60
102
  * A single workspace inside a demo tenant. The mixed tenant has two
61
- * workspaces (wound-care and primary-care sub-workspaces); the other
62
- * two tenants have one each.
103
+ * workspaces (wound-care and primary-care sub-workspaces); every
104
+ * other tenant (placeholder, on-site demo, wound-care, primary-care)
105
+ * has exactly one.
63
106
  */
64
107
  interface DemoWorkspaceSpec {
65
108
  /** Stable id (DynamoDB record id; also drives the canonical OHI URN). */
@@ -80,9 +123,10 @@ interface DemoWorkspaceSpec {
80
123
  */
81
124
  interface DemoTenantSpec {
82
125
  /**
83
- * Scenario slug — `placeholder`, `demo-wound-care`, `demo-primary-care`,
84
- * `demo-mixed`. The placeholder tenant's slug is `placeholder`; the
85
- * three demo tenants use `demo-*` slugs.
126
+ * Scenario slug — `placeholder`, `on-site-demo`, `demo-wound-care`,
127
+ * `demo-primary-care`, `demo-mixed`. The placeholder tenant uses
128
+ * `placeholder`; the on-site UAT demo tenant uses `on-site-demo`
129
+ * (#1301); the three demo tenants use `demo-*` slugs.
86
130
  */
87
131
  readonly scenario: string;
88
132
  /** Stable id (DynamoDB record id; also drives the canonical OHI URN). */
@@ -93,17 +137,22 @@ interface DemoTenantSpec {
93
137
  readonly workspaces: ReadonlyArray<DemoWorkspaceSpec>;
94
138
  }
95
139
  /**
96
- * The full demo-tenant graph. Four entries: the placeholder tenant the
97
- * JWT-claim fallback resolves to, plus the three v1 demo scenarios
98
- * (OPS-009 §"v1 scenarios"):
140
+ * The full demo-tenant graph. Five entries: the placeholder tenant
141
+ * the JWT-claim fallback resolves to, the on-site-medical UAT demo
142
+ * tenant every dev user lands on at sign-in (#1301), and the three
143
+ * v1 demo scenarios (OPS-009 §"v1 scenarios"):
99
144
  *
100
145
  * 0. Placeholder tenant — dereferences the JWT-claim fallback in
101
- * `pre-token-generation.handler.ts` and acts as every dev user's
102
- * `currentTenant`/`currentWorkspace` so Post-Confirmation skips
103
- * default provisioning when a seeded User signs in.
104
- * 1. Single-workspace wound-care tenant.
105
- * 2. Single-workspace primary-care tenant.
106
- * 3. Two-workspace mixed tenant exercises the cross-workspace
146
+ * `pre-token-generation.handler.ts`. Carries no user-facing
147
+ * content; exists purely so the JWT fallback resolves to a real
148
+ * DynamoDB row instead of dangling.
149
+ * 1. On-site-medical UAT demo tenant — every seeded dev user's
150
+ * `currentTenant`/`currentWorkspace`. Downstream demo-data
151
+ * tickets (providers, facilities, patients) attach to this
152
+ * tenant via {@link ON_SITE_DEMO_TENANT_ID}.
153
+ * 2. Single-workspace wound-care tenant.
154
+ * 3. Single-workspace primary-care tenant.
155
+ * 4. Two-workspace mixed tenant — exercises the cross-workspace
107
156
  * isolation flow that single-workspace tenants cannot.
108
157
  */
109
158
  declare const DEMO_TENANT_SPECS: ReadonlyArray<DemoTenantSpec>;
@@ -146,4 +195,4 @@ declare const openhiResourceIdentifier: (params: {
146
195
  */
147
196
  declare const demoRolesForUserInTenant: (_user: DemoDevUser, _tenantId: string) => ReadonlyArray<PlatformRoleCode>;
148
197
 
149
- export { DEMO_PERIOD as D, OPENHI_RESOURCE_URN_SYSTEM as O, PLACEHOLDER_TENANT_ID as P, SEED_DEMO_DATA_CONSUMER_NAME as S, DEMO_TENANT_SPECS as a, DEMO_URN_SYSTEM as b, DEV_USERS as c, type DemoDevUser as d, type DemoTenantSpec as e, type DemoWorkspaceSpec as f, PLACEHOLDER_WORKSPACE_ID as g, demoMembershipId as h, demoRoleAssignmentId as i, demoRolesForUserInTenant as j, demoScenarioIdentifier as k, openhiResourceIdentifier as o };
198
+ export { DEMO_PERIOD as D, ON_SITE_DEMO_TENANT_ID as O, PLACEHOLDER_TENANT_ID as P, SEED_DEMO_DATA_CONSUMER_NAME as S, DEMO_TENANT_SPECS as a, DEMO_URN_SYSTEM as b, DEV_USERS as c, type DemoDevUser as d, type DemoTenantSpec as e, type DemoWorkspaceSpec as f, ON_SITE_DEMO_WORKSPACE_ID as g, OPENHI_RESOURCE_URN_SYSTEM as h, PLACEHOLDER_WORKSPACE_ID as i, demoMembershipId as j, demoRoleAssignmentId as k, demoRolesForUserInTenant as l, demoScenarioIdentifier as m, openhiResourceIdentifier as o };