docs: hand-written inventory counts are deleted across skills, docs, READMEs and code comments; the names and the source of truth stay

.changeset/27522-inventory-counts.md

@@ -0,0 +1,21 @@
+---
+'@objectstack/skills': patch
+'@objectstack/spec': patch
+'@objectstack/metadata': patch
+'@object-ui/i18n': patch
+'@object-ui/plugin-grid': patch
+'@object-ui/components': patch
+'@object-ui/fields': patch
+'@object-ui/types': patch
+'@object-ui/plugin-form': patch
+'@object-ui/console': patch
+---
+
+docs(skills): hand-written inventory counts are deleted; the names and the source of truth stay
+
+Clause-②: no
+Metadata-protocol: none
+
+- **Before.** `objectstack-data` counted its field types ("49") in SKILL.md and in `rules/field-types.md`, and its lifecycle events ("8") in SKILL.md and `references/data-hooks.md`; `objectstack-automation` counted its built-in node types ("20"); `objectui/README.md` counted its plugins ("18"); `objectui/guides/schema-expressions.md` counted the formula registry ("30 functions"); `objectstack-query` counted the aggregate functions ("six"). No gate reads any of those numbers against the tree, so each one goes wrong the moment the inventory moves, and a wrong count misleads the reader more than no count.
+- **Now.** The numbers are gone; every enumeration that taught something (the node-type tables, the plugin names, the function table, the aggregate names) stays, and each page still points at the file or schema that is the source of truth. Deletion only: every touched file shrinks under its unchanged token ceiling.
+- The same deletion in shipped READMEs and one shipped source comment: `@objectstack/spec` (a `//` comment in `src/kernel/metadata-plugin.zod.ts`, which ships), `@objectstack/metadata` (README), and the `@object-ui/*` READMEs of i18n, plugin-grid, components, fields, types, plugin-form and console. No schema, key or behaviour changes.

content/docs/api/error-catalog.mdx

@@ -4,7 +4,7 @@ navTitle: Error Code Catalog
 description: Complete reference for all ObjectStack error codes with causes, fixes, and retry strategies
 ---
 
-ObjectStack uses a structured error system with **9 error categories** and **56 error codes reachable on the wire**. Every error includes a machine-readable code, HTTP status mapping, and retry guidance.
+ObjectStack uses a structured error system of **error categories** and **56 error codes reachable on the wire**, catalogued in full below (that count is pinned by `packages/spec/src/api/error-catalog-docs.test.ts` against the wire face). Every error includes a machine-readable code, HTTP status mapping, and retry guidance.
 
 This catalog documents the **wire face** — the codes a client can actually receive. That is not quite the
 `StandardErrorCode` enum: the enum also carries in-process spellings the REST door translates at the

content/docs/capabilities/analytics.mdx

@@ -1,15 +1,15 @@
 ---
 title: Analytics — dashboards, reports and charts
 navTitle: Analytics & Dashboards
-description: ~20 chart families, period-over-period comparison, runtime filters, TV display pages, and four report shapes
+description: Chart families, period-over-period comparison, runtime filters, TV display pages, and the report shapes
 ---
 
 
 The executive cockpit and the ops detail report are both configured, not built. Data is live, and permissions apply inside every chart — each viewer sees only the numbers they are allowed to see.
 
 ## Dashboards
 
-Compose from roughly twenty chart families:
+Compose from the chart families:
 
 - **Single values**: KPI tiles, gauges, progress rings — total pipeline, quarter-to-date closed, target attainment.
 - **Comparisons**: bar and column by stage, rep, or product line.
@@ -26,7 +26,7 @@ Dashboard extras that matter in practice:
 
 ## Reports
 
-Four shapes — **tabular** (detail rows), **summary** (grouped totals), **matrix** (regions × quarters), and **joined** (several dataset panels) — with runtime filters and export.
+The shapes — **tabular** (detail rows), **summary** (grouped totals), **matrix** (regions × quarters), and **joined** (several dataset panels) — with runtime filters and export.
 
 > **In HotCRM**: four dashboards (executive, sales, service, CRM overview) and six reports (lead, opportunity, account, case, churn), fed by six shared datasets covering accounts, contacts, leads, opportunities, products, and cases. The executive dashboard carries quarter and owner filters plus the funnel and trend widgets described above.
 

content/docs/capabilities/approvals.mdx

@@ -1,13 +1,13 @@
 ---
 title: Approvals — routing, queues and audit trail
 navTitle: Approvals
-description: Seven ways to pick approvers, four decision modes including group sign-off, record locking, overdue escalation, and send-back-for-revision
+description: Ways to pick approvers, decision modes including group sign-off, record locking, overdue escalation, and send-back-for-revision
 ---
 
 
 Discounts, contracts, spend — anything that needs a human "yes" becomes an approval step in a flow, replacing the group-chat shoulder tap with a tracked, enforceable decision.
 
-## Who approves — seven resolution styles
+## Who approves — the resolution styles
 
 A specific person · everyone holding a position (e.g. sales managers) · the submitter's direct manager (needs each user's manager set — see below) · a team · a department (optionally including sub-departments) · organization leadership · **a person named on the record itself** (e.g. the "regional director" field).
 
@@ -23,7 +23,7 @@ request opens and waits for an administrator. The details, and the fallback that
 data at all, are in [Automation → Approvals](/docs/automation/approvals).
 </Callout>
 
-## How it passes — four decision modes
+## How it passes — the decision modes
 
 | Mode | Rule | Fits |
 |---|---|---|

content/docs/capabilities/automation.mdx

@@ -1,7 +1,7 @@
 ---
 title: Automation — processes that run themselves
 navTitle: Automation — Processes That Run Themselves
-description: Five trigger styles, visual flow diagrams, notifications, branching, loops, waits, and external calls — the work nobody should have to remember
+description: Trigger styles, visual flow diagrams, notifications, branching, loops, waits, and external calls — the work nobody should have to remember
 ---
 
 

content/docs/capabilities/data.mdx

@@ -1,7 +1,7 @@
 ---
 title: Business data — objects, fields and records
 navTitle: Manage Business Data
-description: Objects, 40+ field types, auto-computed fields, and relationships — every spreadsheet you run the business on, structured and governed
+description: Objects, field types, auto-computed fields, and relationships — every spreadsheet you run the business on, structured and governed
 ---
 
 

content/docs/capabilities/index.mdx

@@ -12,13 +12,13 @@ If you are a developer, the [Build sections](/docs/data-modeling) cover the same
 ## The capabilities
 
 <Cards>
-  <Card href="/docs/capabilities/data" title="Manage Business Data" description="Objects, 40+ field types, formula and roll-up fields, relationships from lookups to hierarchies" />
-  <Card href="/docs/capabilities/views" title="Views — See Data Your Way" description="Nine lenses over the same records: table, kanban, calendar, gantt, map and more — plus saved filters and global search" />
+  <Card href="/docs/capabilities/data" title="Manage Business Data" description="Objects, field types, formula and roll-up fields, relationships from lookups to hierarchies" />
+  <Card href="/docs/capabilities/views" title="Views — See Data Your Way" description="Many lenses over the same records: table, kanban, calendar, gantt, map and more — plus saved filters and global search" />
   <Card href="/docs/capabilities/forms" title="Forms & Data Quality" description="Wizards, conditional fields, validation on save, legal stage transitions, public web-to-lead forms" />
-  <Card href="/docs/capabilities/automation" title="Automation" description="Five trigger styles and visual flows: reminders, hand-offs, escalations, and scheduled work that runs itself" />
-  <Card href="/docs/capabilities/approvals" title="Approvals" description="Seven approver styles, four decision modes including group sign-off, locking, SLA escalation, send-back" />
-  <Card href="/docs/capabilities/permissions" title="Permissions — Who Sees What" description="Four layers from object capability to per-field visibility, five data-depth scopes, audit, and an explain API" />
-  <Card href="/docs/capabilities/analytics" title="Analytics & Dashboards" description="~20 chart families, period-over-period, runtime filters, TV display pages and reports" />
+  <Card href="/docs/capabilities/automation" title="Automation" description="Trigger styles and visual flows: reminders, hand-offs, escalations, and scheduled work that runs itself" />
+  <Card href="/docs/capabilities/approvals" title="Approvals" description="Approver styles and decision modes including group sign-off, locking, SLA escalation, send-back" />
+  <Card href="/docs/capabilities/permissions" title="Permissions — Who Sees What" description="Layers from object capability to per-field visibility, data-depth scopes, audit, and an explain API" />
+  <Card href="/docs/capabilities/analytics" title="Analytics & Dashboards" description="Chart families, period-over-period, runtime filters, TV display pages and reports" />
   <Card href="/docs/capabilities/ai" title="AI Under Governance" description="Ask questions and get charts; AI acts under the same permissions and audit as people; bring your own agent over MCP" />
   <Card href="/docs/capabilities/integrations" title="Integrations & Everyday Work" description="Import/export, generated APIs, webhooks, connectors, federated databases, marketplace templates, languages" />
   <Card href="/docs/capabilities/request-template" title="How to Request Features" description="A one-page template that turns business needs into configuration — hand it to your team or an AI agent" />

content/docs/capabilities/views.mdx

@@ -27,7 +27,7 @@ One object can carry many named views at once — "My open deals (table)", "East
 
 - **Global search** (`⌘K`) spans objects and understands partial matches — including **pinyin search**, so typing `zhangsan` finds 张三.
 - **Filters** combine any fields with and/or logic and a full operator set (equals, contains, greater than, between, is empty…).
-- **Relative dates**: "this quarter", "last month", "past 7 days", "next 30 days" — 36 built-in tokens plus custom offsets. A saved view filtered on "this quarter" rolls forward every day by itself.
+- **Relative dates**: "this quarter", "last month", "past 7 days", "next 30 days" — built-in tokens plus custom offsets. A saved view filtered on "this quarter" rolls forward every day by itself.
 - **Per-person scoping**: views like "My accounts" or "My team's opportunities" resolve per viewer automatically, following the permission model.
 
 > **In HotCRM**: twelve view files cover every object — open the Opportunity object and switch between its pipeline kanban, forecast table, and close-date calendar to feel the difference lenses make.

content/docs/frontend/architecture-overview.mdx

@@ -314,20 +314,20 @@ packages/
 │   ├── SchemaRenderer.tsx
 │   ├── LazyPluginLoader.tsx
 │   ├── context/         # All React contexts
-│   └── hooks/           # 20+ hooks (useExpression, useActionRunner, etc.)
-├── components/          # 91+ Shadcn UI atoms
-├── fields/              # 35+ field renderers
+│   └── hooks/           # Hooks (useExpression, useActionRunner, etc.)
+├── components/          # Shadcn UI atoms
+├── fields/              # Field renderers
 ├── layout/              # AppShell, Header, Sidebar
 ├── i18n/                # Internationalization
 ├── auth/                # AuthContext + providers
 ├── permissions/         # RBAC/ABAC
-└── plugin-*/            # 20 plugin packages
+└── plugin-*/            # Plugin packages
     ├── plugin-grid/
     ├── plugin-kanban/
     ├── plugin-charts/
     ├── plugin-dashboard/
     ├── plugin-form/
-    └── ... (15 more)
+    └── ...
 ```
 
 ## Further Reading

content/docs/frontend/plugins/index.mdx

@@ -21,7 +21,7 @@ Plugins are lazy-loaded component packages that:
 
 ## Official Plugins
 
-ObjectUI provides 14+ official plugins for common use cases:
+ObjectUI provides official plugins for common use cases:
 
 ### Data Visualization & Dashboards
 

content/docs/plugins/packages.mdx

@@ -4,7 +4,7 @@ navTitle: Package Overview
 description: Complete guide to all ObjectStack packages, services, drivers, plugins, and adapters
 ---
 
-ObjectStack is organized into **72 package manifests** across multiple categories. This guide provides an overview of the framework packages, services, drivers, plugins, and adapters in the [framework repository](https://github.com/objectstack-ai/objectstack/tree/main/packages).
+ObjectStack is organized into package manifests across multiple categories. This guide provides an overview of the framework packages, services, drivers, plugins, and adapters in the [framework repository](https://github.com/objectstack-ai/objectstack/tree/main/packages).
 
 ### Package categories at a glance
 
@@ -24,7 +24,7 @@ ObjectStack is organized into **72 package manifests** across multiple categorie
 
 **The Constitution** — Protocol schemas, types, and constants for the entire ObjectStack ecosystem.
 
-- **Purpose**: Zod-first schema definitions for all 15 protocol domains
+- **Purpose**: Zod-first schema definitions for every protocol domain
 - **Exports**: Builder functions (`defineStack`, `defineView`, `defineApp`, `defineFlow`, `defineAgent`, `defineTool`, `defineSkill`) from the root entry, plus `ObjectSchema.create()` for objects from the `@objectstack/spec/data` subpath. Protocol namespaces (Data, UI, System, Automation, AI, API, Identity, Security, Kernel, Marketplace, QA, Contracts, Integration, Studio, Shared) are not re-exported from the top-level entry for tree-shaking reasons — import them from subpaths such as `@objectstack/spec/data` and `@objectstack/spec/ui`.
 - **When to use**: Import types, schemas, and builder functions when authoring metadata.
 - **Documentation**: [Protocol Reference](/docs/references)

content/docs/protocol/kernel/config-resolution.mdx

@@ -146,7 +146,7 @@ settings.registerManifest(crmSettingsManifest);
 ```
 
 Keys are `snake_case` storage paths inside the namespace — `(namespace, key)`,
-not a dotted global path. The full specifier vocabulary (19 types, visibility
+not a dotted global path. The full specifier vocabulary (specifier types, visibility
 expressions, action buttons, per-key permissions) is documented in the
 [Settings Manifest reference](/docs/references/system/settings-manifest).
 

content/docs/protocol/objectql/index.mdx

@@ -111,7 +111,7 @@ fields:
 
 ### 2. Fields: Rich Type System
 
-ObjectQL provides 20+ field types that encode business semantics:
+ObjectQL's field types encode business semantics:
 
 | Field Type | Business Meaning | Example |
 |------------|------------------|---------|

content/docs/protocol/objectql/query-syntax.mdx

@@ -347,7 +347,7 @@ metacharacters — `{ name: { $icontains: 'a.b' } }` matches `a.b` and not `axb`
   **If you were relying on `$contains` being loose on the in-memory driver, that
   is a row-set change: write `$icontains` when you want a fold.** The shared
   standard both halves are measured against is `FILTER_TEXT_CASES`
-  (`@objectstack/spec/data`), which all five drivers now run.
+  (`@objectstack/spec/data`), which every driver now runs.
 </Callout>
 
 ### `$regex` — removed
@@ -1038,7 +1038,7 @@ const query: QueryAST = {
 **Schema enum:** `count`, `sum`, `avg`, `min`, `max`, `count_distinct`.
 
 <Callout type="info">
-All six functions are computed on every backend. `count_distinct` lowers to
+All of them are computed on every backend. `count_distinct` lowers to
 `COUNT(DISTINCT field)` on `SqlDriver` and on the Turso driver (both transports), and is
 computed by the MongoDB driver, the in-memory driver and the engine's in-memory
 aggregation fallback. A function the schema enum never declared (`median`) is
@@ -1214,7 +1214,7 @@ label→value mapping in the expansion rather than by the operator.
   `driver-memory` used on its query and analytics faces. **On CASE** — this callout's
   subject — the divergence it warned about is closed: running your tests on the
   in-memory double no longer returns rows a SQL or MongoDB deployment would not
-  because of a fold, and `FILTER_TEXT_CASES` holds all five drivers to that rule.
+  because of a fold, and `FILTER_TEXT_CASES` holds every driver to that rule.
   ⚠️ **One axis is NOT aligned, it is not a case question, and which answer you see
   depends on how you reach the data.** **Through the engine** — `ql.find()` and every
   surface above it (REST `where` / `$filter`, flow node filters, list views) — a text

content/docs/protocol/objectql/schema.mdx

@@ -1033,7 +1033,7 @@ indexes:
   <Card
     title="Type System"
     href="/docs/protocol/objectql/types"
-    description="Learn all 20+ field types: scalars, relationships, formulas"
+    description="Learn every field type: scalars, relationships, formulas"
   />
   <Card
     title="Query Syntax"

docs/qa/platform-checklist/README.md

@@ -371,7 +371,7 @@ disappeared is flagged too (the entry outlived the capability). This is the
 `examples/app-showcase/src/coverage.ts` demonstrated-or-waived ratchet, applied to
 testing instead of demonstration.
 
-Enumerable surfaces *inside* a capability (49 field types, 20 chart types, flow node
+Enumerable surfaces *inside* a capability (field types, chart types, flow node
 types, query operators, decision actions, …) are covered by `variants` matrices on the
 items themselves, each derived from the spec's own Zod enums with the source cited.
 

examples/app-showcase/README.md

@@ -16,7 +16,7 @@ suite checks against the protocol's own Zod enums.
 Demonstration and verification pull in opposite directions:
 
 - **Demo** wants a believable, connected app — but a realistic app never
-  naturally uses all 49 field types, all 8 view types, or all 38 chart types.
+  naturally uses every field type, every view type, or every chart type.
 - **Verify** wants every variant present and *asserted* — which a single
   realistic domain can't provide.
 
@@ -69,7 +69,7 @@ stable across restarts of the same database.
 ## What it covers
 
 ### Data layer (ObjectQL)
-- **All 49 field types** — `src/data/objects/field-zoo.object.ts` carries one
+- **All field types** — `src/data/objects/field-zoo.object.ts` carries one
   field of every `FieldType`, with the remainder appearing naturally on the
   backbone objects.
 - **Every relationship kind** — `lookup` (project → account, category → self),
@@ -156,7 +156,7 @@ served publicly via the library portal.
 
 ## Directory layout
 
-`src/` mirrors the six protocol domains of the metadata registry
+`src/` mirrors the protocol domains of the metadata registry
 (`DEFAULT_METADATA_TYPE_REGISTRY`), with per-type directories inside each:
 
 ```

examples/app-todo/README.md

@@ -48,7 +48,7 @@ examples/app-todo/
 ## 📋 Features Demonstrated
 
 ### Object Definition
-- **Task Object** (`task`) with 20+ fields covering all common patterns
+- **Task Object** (`task`) with fields covering all common patterns
 
 ### Field Types Covered
 - ✅ **Text** (`subject`) — Task title (required, searchable)
@@ -63,25 +63,25 @@ examples/app-todo/
 - ✅ **Color** (`category_color`) — Color picker with presets
 - ✅ **Rich Text** (`notes`) — Formatted notes
 
-### Actions (8)
+### Actions
 - **Complete Task** / **Start Task** — Status transitions
 - **Defer Task** — Reschedule with reason
 - **Set Reminder** / **Clone Task** — Utility actions
 - **Mass Complete** / **Delete Completed** / **Export CSV** — Bulk operations
 
 ### Dashboard
-- 4 Key Metrics (total, completed today, overdue, completion rate)
+- Key Metrics (total, completed today, overdue, completion rate)
 - Charts (status pie, priority bar, weekly trend line, category donut)
 - Task tables (overdue, due today)
 
-### Reports (5)
+### Reports
 - Tasks by Status / Priority / Owner
 - Completed Tasks
 - Time Tracking (estimated vs actual hours matrix)
 - (Overdue Tasks is deliberately **not** a report — a flat record list is a
   ListView lens, ADR-0021; see `src/views/task.view.ts`)
 
-### Automation Flows (4)
+### Automation Flows
 - **Task Reminder** — Daily scheduled reminder for tasks due tomorrow
 - **Overdue Escalation** — Auto-escalate tasks overdue by 3+ days
 - **Task Completion** — Auto-create next occurrence for recurring tasks