fix/mark pushed refreshes index

Knowledge-BP-General/Docusaurus-ClientApps.md

@@ -367,7 +367,11 @@ Live doc: https://docs.tylerdev.io/app-guides/client/admin-center/products
 
 ### Workspaces
 
-Workspaces are provisioned by Tyler — customers cannot create new ones through Admin Center. If a workspace is missing, contact Tyler Support.
+Workspaces are provisioned by Tyler — customers cannot create new ones through Admin Center.
+
+**How a workspace actually gets created:** Tyler staff create it in **Ops Center** (organization details → **Manage workspaces** → **+ Add a workspace**), or it is created through **Ops Center APIs** called by a deployment tool such as **Tyler Deploy** or **Cloud Provisioner**. A customer who needs a new workspace, or finds one missing, asks Tyler — they have no Admin Center path to it. Do **not** answer "contact Tyler Support" as though no mechanism existed; name the mechanism.
+
+**What Admin Center can and cannot do here.** Admin Center is where a customer **views** workspace details and edits presentation-level settings (title, links, contacts, banner, ACLs). It **cannot create a workspace, and cannot change licensing or product availability** — both of those are Ops Center, and therefore Tyler staff. Ops Center is the tool for creating organizations and workspaces, licensing products to an organization, and activating them on a workspace.
 
 **Workspace > Overview:** Shows type (production/non-production), status (enabled/disabled). Workspace ID, title (controls Community App Directory banner text and nav rail), and a "Danger Zone: Disable Workspace" section. Disabling a workspace affects all applications within it — contact Tyler Support first.
 
@@ -571,7 +575,7 @@ For full integration guidance, see the Blueprint docs at the source URL above.
 
 6. **Community users not in Users:** Admin Center > Users only shows Workforce users. Community (public) users are managed separately; direct community user support queries to CAPM or the Identity agent.
 
-7. **Workspaces are Tyler-provisioned:** Customers cannot create workspaces. If a workspace is missing, Tyler Support must be contacted.
+7. **Workspaces are Tyler-provisioned:** Customers cannot create workspaces from Admin Center. Creation happens in **Ops Center** (**Manage workspaces** → **+ Add a workspace**) or through **Ops Center APIs** driven by a deployment tool (**Tyler Deploy**, **Cloud Provisioner**). Name that mechanism rather than answering only "contact Tyler Support". (Repeated from the Workspaces section on purpose — retrieval returns whichever chunk matches the question.)
 
 8. **Products page vs. Admin Apps page:** Products shows licensed products and their app links. Admin Apps shows only apps the signed-in user can access via ACLs — an empty Admin Apps page means the user has no ACL with admin apps.
 

Knowledge-BP-General/Docusaurus-PlatformOverview.md

@@ -265,7 +265,21 @@ For deep Identity questions, also point the user to the **Identity specialized a
 
 **Vendor** — (Tyler business) an entity providing software/services to Tyler or its customers under a formal agreement; (in software) a public customer/user of Tyler's customers.
 
-**Workspace** — a consistent **logical** construct grouping Tyler solutions regardless of each solution's hosting environment; associated 1:1 with a **tenant**. Some platforms (e.g., TCP) host all a customer's workspaces (prod/test/train/staging) in one environment with virtual data segregation.
+**Workspace** — a **logical construct** that groups Tyler solutions together for a given customer organization and business use (for example, production use or test use), regardless of each solution's hosting environments. All product instances, datasets, and integrations participating in that customer and business use are tagged with the same **workspace key**, which gives customers a "single pane of glass" experience both within a product and across products.
+
+- A logical construct, **independent of product tenancy, datasets, and integrations** — a workspace is **not** 1:1 with a tenant, because it groups several solutions and each carries its own product tenancy
+- Every deployment and provisioning action across Tyler must be tagged with a workspace key
+- When multiple instances of a product are installed for production use, all of those instances receive the **same** workspace key
+- For a **customer organization**, Tyler allows by default **one production workspace and six non-production workspaces**
+- Represents a "customer business purpose"
+- Each workspace has a unique **Workspace ID** (`portalId` / `workspaceKey`). The production workspace key is the same as `{orgKey}`; for a customer organization the six standard non-production workspaces have keys of the form `{orgKey}-{test|train|staging|impl|uat|dev}`
+- Each workspace has a configurable title that controls Community App Directory banner text and navigation
+
+The workspace concept is defined primarily for **customer organizations**, and the rules above describe them. Internal organizations use the workspace only as a construct for compatibility with deployment workflows — nothing there depends on a customer business purpose — which is why their suffix rules are deliberately more liberal. Do not apply the customer suffix set to an internal org.
+
+**Creating one:** Tyler staff create workspaces in **Ops Center** (organization details → **Manage workspaces** → **+ Add a workspace**), or they are created through **Ops Center APIs** called by a deployment tool such as **Tyler Deploy** or **Cloud Provisioner**. Customers cannot create workspaces from Admin Center, so a customer needing one asks Tyler. When answering "how do I get a workspace", name that mechanism — not just "contact Tyler Support".
+
+Some platforms (for example, TCP) host all of a customer's workspaces in one environment with virtual data segregation; other products may host the same workspaces in entirely different environments running different versions.
 
 **Workforce App Directory** — a directory of all Workforce applications a user can discover and navigate to. → `Docusaurus-ClientApps.md`.
 

Knowledge-OpsCenter/Docusaurus-OpsCenter.md

@@ -366,7 +366,13 @@ Available behavior differs sharply by tier:
 
 ## Workspaces
 
-A **Workspace** is analogous to a client environment in which solutions are installed for a particular need: production use, testing, training, etc. Each customer typically has **1 production workspace** and optionally **3–7 non-production workspaces**. (Some org-to-org relationships folded into one Customer Id may exhibit multiple production portals.) A workspace often has multiple products licensed on it; product teams should test with co-existing products on shared workspaces (not separate-workspace-per-product) to simulate real client usage. **Test with at least 2 organizations** to better reflect production diversity.
+A **Workspace** is a **logical construct** that groups Tyler solutions together for a given customer organization and business use — production use, testing, training, and so on — regardless of each solution's hosting environments. All product instances, datasets, and integrations participating in that customer and business use are tagged with the same **workspace key**, which gives customers a "single pane of glass" experience both within a product and across products.
+
+For a **customer organization**, Tyler allows by default **one production workspace and six non-production workspaces**. The production workspace key is the same as `{orgKey}`; the six standard non-production workspaces have keys of the form `{orgKey}-{test|train|staging|impl|uat|dev}`. Anything beyond that set is a **non-standard workspace** and needs justification through the Tickets portal (see *Naming convention* below). (Some org-to-org relationships folded into one Customer Id may exhibit multiple production portals.)
+
+**The workspace concept is defined primarily for customer organizations**, and the rules above describe them. Internal organizations use the workspace only as a construct for compatibility with deployment workflows — nothing there depends on a customer business purpose — which is why their suffix rules are deliberately more liberal. Do not apply the customer suffix set to an internal org.
+
+A workspace is **independent of product tenancy** — it is not 1:1 with a tenant, because it groups several solutions and each carries its own product tenancy. A workspace often has multiple products licensed on it; product teams should test with co-existing products on shared workspaces (not separate-workspace-per-product) to simulate real client usage. **Test with at least 2 organizations** to better reflect production diversity.
 
 ### Workspaces — create
 
@@ -377,10 +383,14 @@ Use the standard customers (`demo`, `dev`, `test` or `testinprod` for unscripted
 
 Under organization details → **Manage workspaces** → **+ Add a workspace**.
 
+**Ops Center is not the only route.** Workspaces are also created through **Ops Center APIs**, called by a deployment tool such as **Tyler Deploy** or **Cloud Provisioner** — that is the usual path when workspace creation is part of a provisioning pipeline rather than a person doing it by hand. Customers have no path of their own: they cannot create workspaces from Admin Center.
+
 **Naming convention:**
 - Production workspace key = `<organization id>` (only 1 allowed; for standard orgs, this already exists).
 - Non-production workspace key = `<organization id>-<unique workspace id>`. The user-selectable suffix must be **alphanumeric only**, no spaces, no special characters, **no `-`** in the suffix.
-- Examples: `demo-notify001`, `demo-vijayvenkataraman`, `demo-cityofrentonwa`.
+- **For a customer organization, the suffix must be one of the six standard values: `test`, `train`, `staging`, `impl`, `uat`, `dev`.** These are what the default allowance of six non-production workspaces refers to. Anything else is a non-standard workspace and needs a business justification through the Tickets portal explaining how the suffix reflects a customer business purpose; numbered variants of the standard set (`impl2`, `test2`, `train2`) are the most common exception.
+- The suffix cannot be `admin` (case-insensitive).
+- **Internal organizations are deliberately more liberal** — they use the workspace only as a construct for compatibility with deployment workflows, so the six-value customer set does not apply to them. Keys such as `demo-notify001` are internal-org keys and are not counter-examples to the customer rule.
 
 Wizard tabs:
 

Knowledge-OpsCenter/Docusaurus-Terminology.md

@@ -230,15 +230,35 @@ In software, an identifier assigned to software licenses, products, services, bu
 
 ### Workspace
 
-A consistent, **logical** construct that groups Tyler solutions regardless of each solution's hosting environment. On TCP, all of a customer's workspaces (prod, test, train, staging, etc.) typically share the same environment and software version with data segregated virtually. For other products, the same workspaces may be hosted in entirely different environments using different versions. From a customer's perspective, the group of solutions in "production" relate to one another even if they sit in different hosting environments. In the One Tyler Ecosystem, a workspace is **1:1 with a *Tenant***.
+A **logical construct** that groups Tyler solutions together for a given customer organization and business use (for example, production use or test use), regardless of each solution's hosting environments. All product instances, datasets, and integrations participating in that customer and business use are tagged with the same workspace key, which gives customers a "single pane of glass" experience both within a product and across products.
+
+**Core definition:**
+- A logical construct, **independent of product tenancy, datasets, and integrations**
+- Every deployment and provisioning action across Tyler must be tagged with a workspace key
+- When multiple instances of a product are installed for production use, all of those instances receive the **same** workspace key
+- For a **customer organization**, Tyler allows by default **one production workspace and six non-production workspaces**
+- Represents a "customer business purpose"
+
+**Identifiers:**
+- Each workspace has a unique **Workspace ID** (`portalId` / `workspaceKey`)
+- The production workspace key is the same as `{orgKey}`
+- For a customer organization, the six standard non-production workspaces have keys of the form `{orgKey}-{test|train|staging|impl|uat|dev}`. The suffix cannot be `admin`.
+- **The workspace concept is defined primarily for CUSTOMER organizations**, and the rules above describe them. Internal organizations use the workspace only as a construct for compatibility with deployment workflows — nothing there depends on a customer business purpose — which is why their suffix rules are deliberately more liberal. Do not apply the customer suffix set to an internal org.
+
+**Creating one:** Tyler staff create workspaces in **Ops Center** (organization details → **Manage workspaces** → **+ Add a workspace**), or they are created through **Ops Center APIs** called by a deployment tool such as **Tyler Deploy** or **Cloud Provisioner**. Customers cannot create workspaces from Admin Center. Answer "how do I get a workspace" with that mechanism, not with "contact Tyler Support" alone.
+- Each workspace has a configurable title that controls Community App Directory banner text and navigation
+
+On TCP, all of a customer's workspaces typically share the same environment and software version, with data segregated virtually. For other products, the same workspaces may be hosted in entirely different environments running different versions. From a customer's perspective, the group of solutions in "production" relate to one another even if they sit in different hosting environments.
+
+**A workspace is NOT 1:1 with a tenant.** A workspace groups several Tyler solutions, and each of those solutions carries its own product tenancy — so one workspace generally spans many tenants. "Tenant" is a product-level *technical* construct; "workspace" is the cross-product *logical* one. (Stated here as well as under **Tenant** below on purpose: retrieval returns whichever entry matches the question, and the earlier wording asserting 1:1 was wrong.)
 
 ### Environment
 
 The infrastructure on which a product is hosted for a specific organizational use case. **Environment ≠ Workspace.** Environment usually points to specific infrastructure that allows data segregation. Workspace is a logical construct describing different business uses of data segregation without concern for the underlying infrastructure or how segregation is accomplished.
 
 ### Tenant
 
-A technical construct that virtually segregates data and configuration in a system designed to share infrastructure. Typically relates to **Workspaces** for most Tyler products. ("Workspace" is the functional term; "Tenant" is the technical term.)
+A technical construct that virtually segregates data and configuration in a system designed to share infrastructure. Tenancy is a property of an individual **product**, so a single **Workspace** generally spans several tenants — one per participating product instance. ("Workspace" is the cross-product functional term; "Tenant" is the per-product technical term. They are **not** 1:1 — see **Workspace** above.)
 
 ### System
 
@@ -451,7 +471,7 @@ In **technical** discussions: an API or micro-service that serves functionality.
   - Authentication ↔ Authorization (who vs what)
   - Licensing ↔ Availability (org-level vs workspace-level; BOTH required)
   - Customer/Client ↔ Organization (business relationship vs deployment entity)
-  - Tenant ↔ Workspace (technical vs functional/logical, 1:1)
+  - Tenant ↔ Workspace (per-product technical vs cross-product logical; **not 1:1** — one workspace spans many tenants)
   - Environment ↔ Workspace (infra vs logical)
   - Deployment ↔ Release management (engineering vs business; can differ in cloud-native)
   - Workforce Direct ↔ Workforce Managed ↔ Workforce Delegated

scripts/mark_pushed.py

@@ -21,7 +21,7 @@
 Re-reviewing something already `pushed` is fine — use the Re-review button, which raises
 `review_round` and sets it back to `reviewed`.
 """
-import argparse, re, sys
+import argparse, re, subprocess, sys
 from pathlib import Path
 
 REPO = Path(__file__).resolve().parent.parent
@@ -111,8 +111,29 @@ def main():
     for f, why in skipped:
         print(f"  skipped  {f.relative_to(REPO) if f.exists() else f}: {why}", file=sys.stderr)
     print(f"\n{len(moved)} closed out, {len(skipped)} skipped")
+    # REGENERATE INDEX.md HERE, rather than telling the human to.
+    #
+    # This script rewrites `review_status` in every file it closes, which is exactly what
+    # INDEX.md summarises - so leaving it stale is not a tidiness problem, it is a CI failure
+    # on the next pull request. `validate` regenerates the index and fails if it differs, and
+    # closing out 11 transcripts moved the header from "11 reviewed, 16 pushed" to "0 reviewed,
+    # 27 pushed" while the committed file still claimed the old counts. Observed twice: run
+    # 33260021601 and run 33888825829.
+    #
+    # A printed "Next:" line cannot be relied on. The review server has always called
+    # review_status.py itself after a write (refresh_index()); this is the CLI equivalent, and
+    # the only write path that changes review_status.
     if moved and not a.dry_run:
-        print("Next: python3 scripts/review_status.py   (refreshes INDEX.md)")
+        r = subprocess.run([sys.executable, str(REPO / "scripts" / "review_status.py")],
+                           cwd=REPO, capture_output=True, text=True, timeout=120)
+        if r.returncode == 0:
+            print("INDEX.md refreshed")
+        else:
+            # Reported, not fatal: the close-out itself succeeded and is already on disk.
+            # Saying so beats a silent stale index, which is the failure this replaces.
+            print("could NOT refresh INDEX.md - run 'python3 scripts/review_status.py' and "
+                  f"commit it, or the next pull request fails validate:\n{r.stderr.strip()[:300]}",
+                  file=sys.stderr)
     return 0