toga-ai 1.0.490 → 1.0.491

package/knowledge/1.0/apps/tools/features/errors-curation-console.md

@@ -6,7 +6,7 @@ project: Tools
 client: shared
 type: feature
 status: active
-updated: 2026-07-30
+updated: 2026-08-01
 owners: ["jcardinal"]
 files:
   - tools/mvc/errors/get.php
@@ -32,10 +32,10 @@ happening and were deliberately never ticketed. Nobody had that view before.
 ## How it works
 
 - **Curate** subject, description, `minimumUrgency`, assignee, and mute window.
-- **Manage per-client email recipients** (`IssueEmailAddresses`). `clientId = 0` means **all
+- **Manage per-client email recipients** (`IssueEmailAddress`). `clientId = 0` means **all
   clients** and requires an explicit confirmation flag; the list view renders it as
   **"ALL CLIENTS"**.
-- **Merge fingerprints** — repoint an `IssueFingerprints` row at an existing Issue. Without this,
+- **Merge fingerprints** — repoint an `IssueFingerprint` row at an existing Issue. Without this,
   the fingerprint/Issue split is inert: a refactor that shifts line numbers produces a new Issue
   and the curated one is orphaned.
 - **Any save sets `isManaged`**, which does double duty: it protects the curated text from being
@@ -59,8 +59,21 @@ from `Core.Databases` id **11** (`worker2` `CORE_LOGS_DATABASE_ID`); `Logs` is o
 `_underscore` *register alias*. Read the real name from `Core.Databases` before configuring a new
 environment, or the console silently points at a database that may not exist.
 
+## Table names are SINGULAR
+
+The Core Logs tables this console queries are `Issue`, `Event`, `IssueFingerprint`,
+`IssueClickupTask`, `IssueEmailAddress`, `IssueAreaOwner` — **singular**, unlike every other
+table this app touches. That is the deliberate `Logs`-cluster convention (see the
+[2.0 error-reporting doc](../../../2.0/apps/_underscore/features/error-reporting-issue-event.md)).
+They were renamed from plural on 2026-08-01, after the pipeline was already in production.
+
 ## Gotchas / known issues
 
+- **A 2.0 table rename breaks this page silently until it is run.** This console has **no model
+  layer** — `get.php` and `post.php` interpolate table names into hand-written `App_Database`
+  SQL (40+ literal occurrences between them). Nothing here fails at deploy time; it fails when
+  a curator opens the page. Any rename in the shared Core Logs DB must be applied to both files
+  in the same release as the migration.
 - **This is a 1.0 app reading a 2.0 shared database.** Access is plain `App_Database` via the
   `db_toga2logs` alias, not the `_Model` layer — so none of the 2.0 model protections apply.
   Escape every interpolated value and allowlist every identifier (see the 1.0 back-end standard).
@@ -72,6 +85,11 @@ environment, or the console silently points at a database that may not exist.
 
 ## Change history
 
+- 2026-08-01 — Updated every hardcoded table name in `tools/mvc/errors/get.php` (25+ refs) and
+  `post.php` (15+ refs) for the Core Logs singular rename (`Issues`→`Issue`, `Events`→`Event`,
+  `IssueFingerprints`→`IssueFingerprint`, `IssueClickupTasks`→`IssueClickupTask`,
+  `IssueEmailAddresses`→`IssueEmailAddress`, `IssueAreaOwners`→`IssueAreaOwner`). Recorded that
+  this 1.0 console has no model layer to absorb a 2.0 shared-schema rename. (jcardinal)
 - 2026-07-30 — Built as part of TRUE-78188: new `/errors` triage/curation console over the
   shared Core Logs DB via a new `db_toga2logs` alias; curation sets `isManaged` (protects text
   and exempts from GC); fingerprint merging; per-client recipient management with an explicit

package/knowledge/2.0/apps/_underscore/INDEX.md

@@ -16,7 +16,7 @@
 | [Re-pointing a DB alias mid-request (_Database::register park/restore)](features/database-alias-repointing.md) | `_Database` keys **all live per-database runtime state by the connection ALIAS** (`Client` / `_underscore::DB_CLIENT`, `ClientLogs`, `Archive`), **not** by the | _underscore/Database.php, _underscore/Query.php, api2/Component/Api/V2/V2.php, api2/Component/Api/CrossClient/CrossClient.php |
 | [2.0 Email Send Pipeline (queue + Send worker)](features/email-send-pipeline.md) | In 2.0, `_Email::send()` **does not transmit** — it queues the message. | _underscore/Email.php, worker2/Worker/Infrastructure/Email/Send.php |
 | [Client Email Template Sending](features/email-template-sending.md) | `_Model_Client_EmailTemplate` sends a stored, client-defined email template by UUID. | _underscore/Model/Client/EmailTemplate.php, _underscore/Model/Client/EmailTemplateOutgoingEmailAddress.php, _underscore/Email.php |
-| [Error Reporting — Issue/Event Capture, Fingerprinting & Aggregation](features/error-reporting-issue-event.md) | Platform-wide error reporting for TOGA 2.0, built on an **Issue / Event** aggregation model in the **shared Core Logs DB**. | _underscore/Error.php, _underscore/Exception/Business.php, _underscore/Model/Core/Logs/Issue.php, _underscore/Model/Core/Logs/Event.php, _underscore/Model/Core/Logs/IssueFingerprint.php, _underscore/Model/Core/Logs/IssueClickupTask.php, _underscore/Model/Core/Logs/IssueEmailAddress.php, _underscore/Model/Core/Logs/IssueAreaOwner.php, dbchanges2/Logs/2026-07-30a - Error reporting Issues and Events.sql, dbchanges2/Core/2026-07-30a - Error escalation cron job.sql |
+| [Error Reporting — Issue/Event Capture, Fingerprinting & Aggregation](features/error-reporting-issue-event.md) | Platform-wide error reporting for TOGA 2.0, built on an **Issue / Event** aggregation model in the **shared Core Logs DB**. | _underscore/Error.php, _underscore/Exception/Business.php, _underscore/Model/Core/Logs/Issue.php, _underscore/Model/Core/Logs/Event.php, _underscore/Model/Core/Logs/IssueFingerprint.php, _underscore/Model/Core/Logs/IssueClickupTask.php, _underscore/Model/Core/Logs/IssueEmailAddress.php, _underscore/Model/Core/Logs/IssueAreaOwner.php, dbchanges2/Logs/2026-07-30a - Error reporting Issues and Events.sql, dbchanges2/Logs/2026-08-01a - Rename tables to singular.sql, dbchanges2/Logs_Client/2026-08-01a - Drop Error table.sql, dbchanges2/Core/2026-07-30a - Error escalation cron job.sql |
 | [Record-Changed Event Publishing (_Event::publish to SQS)](features/event-publish-sqs.md) | `_Event::publish()` (in `_underscore/Event.php`) is the PHP side of the real-time event pipeline. | _underscore/Event.php |
 | [Forecast.Sales NetSuite import engine (real-time webhook)](features/forecast-sale-import.md) | Real-time importer that takes a NetSuite **sale** record and writes its lines into `Forecast.Sales` (the Forecast2 revenue table). | worker2/Component/Forecast/SaleImport/SaleImport.php, worker2/Component/Forecast/Db/Db.php, _underscore/Component/Api/Netsuite/Netsuite.php, worker2/Worker/Netsuite/Invoice.php, worker2/Worker/Netsuite/CashSale.php, worker2/Worker/Netsuite/CreditMemo.php, worker2/Worker/Netsuite/CashRefund.php, worker2/Worker/Netsuite/JournalEntry.php, worker2/Worker/Netsuite/Opportunity.php, worker2/Worker/Netsuite/SalesOrder.php, dbchanges2/Forecast/2026-06-26a - Add journalEntry to Sales transaction type enum.sql, test/@dave/test_invoice_lifecycle.php, test/@dave/test_je_lifecycle.php, test/@dave/test_creditmemo_lifecycle.php, test/@dave/test_cashsale_lifecycle.php, test/@dave/test_cashrefund_lifecycle.php, test/@dave/test_fetchrecord_routes.php, test/@dave/verify_je_classification.php, test/@dave/probe_je_accounts.php, test/@dave/probe_je_shape.php, test/@dave/fixer.php, test/@dave/Junk Drawer/NetSuite/api-message-queue/ue_api_msg_queue_enqueue.js, test/@dave/Junk Drawer/NetSuite/api-message-queue/dev_ue_api_msg_queue_enqueue.js |
 | [isFulfillable Propagation Up the SO↔PO Chain](features/fulfillable-item-propagation.md) | `Items.isFulfillable` is a boolean that gates whether a storefront line's **Qty Fulfilled** cell is actionable. | _underscore/Model/Client/Item.php, _underscore/Model/Compass/Item.php, dbchanges2/Core/2026-07-17 - Items isFulfillable RecordField.sql, dbchanges2/Core/2026-07-17 - RegisterItemIsFulfillableInterceptors.sql, dbchanges2/Client/2026-07-17 - ItemsisFulfillable.sql |

package/knowledge/2.0/apps/_underscore/features/error-reporting-issue-event.md

@@ -6,7 +6,7 @@ project: _Underscore
 client: shared
 type: feature
 status: active
-updated: 2026-07-30
+updated: 2026-08-01
 owners: ["dfranks", "jcardinal"]
 files:
   - _underscore/Error.php
@@ -18,6 +18,8 @@ files:
   - _underscore/Model/Core/Logs/IssueEmailAddress.php
   - _underscore/Model/Core/Logs/IssueAreaOwner.php
   - dbchanges2/Logs/2026-07-30a - Error reporting Issues and Events.sql
+  - dbchanges2/Logs/2026-08-01a - Rename tables to singular.sql
+  - dbchanges2/Logs_Client/2026-08-01a - Drop Error table.sql
   - dbchanges2/Core/2026-07-30a - Error escalation cron job.sql
 related:
   - ../architecture.md
@@ -45,9 +47,23 @@ re-implementing persistence.
 
 ## Data model (shared Core Logs DB)
 
-Six tables, created by `dbchanges2/Logs/2026-07-30a - Error reporting Issues and Events.sql`:
-`Issues`, `IssueFingerprints`, `Events`, `IssueEmailAddresses`, `IssueClickupTasks`,
-`IssueAreaOwners`.
+Six tables, created by `dbchanges2/Logs/2026-07-30a - Error reporting Issues and Events.sql` and
+renamed to their final **singular** names by
+`dbchanges2/Logs/2026-08-01a - Rename tables to singular.sql`:
+`Issue`, `IssueFingerprint`, `Event`, `IssueEmailAddress`, `IssueClickupTask`, `IssueAreaOwner`.
+
+> **⚠ The `Logs` cluster is the one place that uses SINGULAR table names.** Everywhere else on
+> the platform tables are plural (`Orders`, `Customers`) — see the 2.0 back-end standard. In
+> `Logs` the tables are named for the *thing* (`Issue`, `Event`), matching how they are referred
+> to verbally ("the Issue table", "API Logs", not "APIs Logs"). **When you add a new table to the
+> `Logs` cluster, name it singular.** Do not "fix" these to plural, and do not carry the singular
+> form outside `Logs`.
+
+Renamed 2026-08-01 (`Issues`→`Issue`, `Events`→`Event`, `IssueFingerprints`→`IssueFingerprint`,
+`IssueClickupTasks`→`IssueClickupTask`, `IssueEmailAddresses`→`IssueEmailAddress`,
+`IssueAreaOwners`→`IssueAreaOwner`). The migration renames the tables *and* their foreign keys
+and indexes; the `const TABLE` on every `_Model_Core_Logs_*` model was updated to match. Older
+notes below and in related docs may still quote the plural names — the shape is unchanged.
 
 **An Issue is never client-scoped.** An Issue is identified by *code*, and code is global — the
 same bug hitting six clients is **one** Issue. Per-client scoping lives on the occurrence
@@ -183,6 +199,18 @@ Sentry-removal ticket cannot complete until the 1.0 port does.
   `varchar(255)` (`errorMessage`, `subject`) **throws** on `->save()`. Inside the handler's
   `catch(Throwable)` the throw is swallowed and the row is silently dropped — precisely when a
   long message matters most. Truncate to column width before `save()`.
+- **`const TABLE` must track a table rename, and nothing warns you.** A `_Model` subclass whose
+  `const TABLE` points at a renamed table fails only at query time. When a `Logs` table is
+  renamed, the matching `_underscore/Model/Core/Logs/*.php` `const TABLE` must change in the
+  **same** deploy as the migration.
+- **1.0 apps break on a 2.0 table rename.** Tools' `/errors` console reads the shared Core Logs
+  DB with hand-written `App_Database` SQL, so it has no model layer to absorb a rename — every
+  literal table name in `tools/mvc/errors/get.php` and `post.php` had to be edited by hand.
+  Grep the 1.0 side before renaming anything in a **shared** 2.0 database.
+- **The per-client `Logs_Client.Error` table is dead.** Superseded by the Issue/Event pipeline;
+  the code that wrote it is commented out in `_Error.php`, the `Model/Core/Logs/Error.php` and
+  `Model/Client/Logs/Error.php` models were deleted, and the table is dropped by
+  `dbchanges2/Logs_Client/2026-08-01a - Drop Error table.sql`. Do not reintroduce it.
 - **Shared-schema migration collision.** Because these tables live in the *shared* Core Logs
   DB, only **one** migration may `CREATE` them; later migrations only `ALTER`.
 - **Pre-existing committed secrets in this area (not fixed — out of scope, report only).**
@@ -239,6 +267,16 @@ clientUserId). **Neither was built.** As built instead:
 
 ## Change history
 
+- 2026-08-01 — **Decided: `Logs` cluster tables use SINGULAR names.** Renamed all six
+  post-deployment (`Issues`→`Issue`, `Events`→`Event`, `IssueFingerprints`→`IssueFingerprint`,
+  `IssueClickupTasks`→`IssueClickupTask`, `IssueEmailAddresses`→`IssueEmailAddress`,
+  `IssueAreaOwners`→`IssueAreaOwner`) via
+  `dbchanges2/Logs/2026-08-01a - Rename tables to singular.sql` (tables + FKs + indexes), and
+  updated `const TABLE` on every `_Model_Core_Logs_*` model. This is a naming-convention
+  alignment, not a behavior change: the `Logs` cluster is named for the thing ("API Logs", not
+  "APIs Logs") while the rest of the platform stays plural. Also deleted the obsolete
+  `Model/Core/Logs/Error.php` and `Model/Client/Logs/Error.php` and dropped the per-client
+  `Logs_Client.Error` table. (jcardinal)
 - 2026-07-30 — Reworked TRUE-78188: six-table schema in the shared Core Logs DB (Issue is
   global by code; client scope lives on Events/IssueEmailAddresses); `_Error::captureException()`
   as the single capture entry point; trace-frame fingerprinting with the message excluded

package/knowledge/2.0/apps/worker2/features/error-escalation-cron.md

@@ -6,7 +6,7 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-07-30
+updated: 2026-08-01
 owners: ["jcardinal"]
 files:
   - worker2/Worker/Infrastructure/Errors.php
@@ -71,7 +71,7 @@ range contains today.
 
 ### Recurrence (episodes)
 
-One `IssueClickupTasks` row per ClickUp **episode**. Closing the task fires a webhook that stamps
+One `IssueClickupTask` row per ClickUp **episode**. Closing the task fires a webhook that stamps
 `dtResolved` and increments `recurrenceCount`. A later occurrence opens a **new** task linked to
 its predecessors via `POST /task/{id}/link/{links_to}` — a **link, not a dependency**; a
 dependency would *block* the task. A cooldown prevents recreating a task 60 seconds after
@@ -85,7 +85,7 @@ which is safe only because the automation never sets status itself.
 
 ### Area-level owner learning (observation only)
 
-`IssueAreaOwners` learns an owner after **5 in a row** and ships **observation-only** — a hint in
+`IssueAreaOwner` learns an owner after **5 in a row** and ships **observation-only** — a hint in
 the task body, never an auto-assignment. Misassignment is expensive: a few wrong tickets and
 developers stop trusting the queue. Learning is per **area**, not per issue, because one issue
 rarely recurs enough to learn from before it is fixed.
@@ -119,7 +119,7 @@ recipients away** after a quiet month.
 
 - **The working-set query must be a UNION, not an OR.** It is a UNION of three separately
   indexable branches. MySQL will **not** `index_merge` across an `OR` when one branch is a
-  correlated `EXISTS`, so the OR form **full-scans `Issues` every 60 seconds, forever**.
+  correlated `EXISTS`, so the OR form **full-scans `Issue` every 60 seconds, forever**.
 - **`INSERT ... SELECT ... WHERE NOT EXISTS` is not a concurrency guard** under REPEATABLE READ.
   The open-episode guard is a UNIQUE key on a VIRTUAL generated column, and the code **claims
   the episode before calling ClickUp** so a losing run fails before creating a duplicate
@@ -131,7 +131,7 @@ recipients away** after a quiet month.
 - **Business email bodies/subjects must not carry `errorMessage` or `trace`.** Both are seeded
   once from whichever client created the Issue and are never re-scoped. An uncurated business
   issue gets a **neutral** subject rather than another client's raw error text.
-- **`IssueEmailAddresses.clientId = 0` means "all clients"** and requires an explicit
+- **`IssueEmailAddress.clientId = 0` means "all clients"** and requires an explicit
   confirmation flag in the Tools console; list views render it as **"ALL CLIENTS"**.
 - **The ClickUp webhook has no HMAC signature verification** (pre-existing, unfixed). A forged
   POST can mark issues acknowledged — freezing the neglect axis — or resolve episodes. That is
@@ -143,6 +143,12 @@ recipients away** after a quiet month.
 
 ## Change history
 
+- 2026-08-01 — Table names updated for the Core Logs **singular** rename (`Issue`, `Event`,
+  `IssueFingerprint`, `IssueClickupTask`, `IssueEmailAddress`, `IssueAreaOwner`). Naming-only;
+  the cron's behavior is unchanged. See
+  [error-reporting-issue-event](../../_underscore/features/error-reporting-issue-event.md).
+  (jcardinal)
+
 - 2026-07-30 — Built as part of TRUE-78188: action renamed `SyncWithClickup` → `Escalate`; new
   `Worker/Clickup/ErrorTask.php`. Two-axis urgency (volume 20/50/100 + neglect 1/4/24) with a
   `minimumUrgency` floor; fast-up/slow-down with release bands 12/35/70 over 3 windows; a

package/knowledge/2.0/apps/worker2/features/monitoring-framework.md

@@ -58,7 +58,7 @@ Lambda, the EB worker tier + SQS delivery (see [worker2 architecture](../archite
 
 worker2 has **two** monitoring patterns and neither writes to the central **`Logs` Issues/Events**
 tables. That is deliberate — **`Logs.Issues`/`Logs.Events` are strictly for application
-errors/exceptions** that escalate to ClickUp or email (business-routed by `IssueEmailAddresses`
+errors/exceptions** that escalate to ClickUp or email (business-routed by `IssueEmailAddress`
 presence; see the escalation-cron work). **Periodic health-check, integration-health, and
 data-quality RESULTS do NOT go there** — they belong in the Monitor framework:
 

package/knowledge/2.0/standards/backend-php.md

@@ -5,7 +5,7 @@ project: _Underscore
 client: shared
 type: standard
 status: active
-updated: 2026-07-27
+updated: 2026-08-01
 owners: [jcardinal, mhammontree]
 files: []
 related:
@@ -292,6 +292,34 @@ WHERE
 
 ### **SQL Naming Conventions**
 
+#### **Table Names — plural, except the `Logs` cluster**
+
+* Table names are **plural**: `Orders`, `Customers`, `PurchaseOrderItems`. This is the default
+  and applies to every database on the platform with one exception.
+* **Exception — the shared Core `Logs` database uses SINGULAR table names**: `Issue`, `Event`,
+  `IssueFingerprint`, `IssueClickupTask`, `IssueEmailAddress`, `IssueAreaOwner`. The `Logs`
+  cluster is named for the *thing being logged*, matching how it is referred to verbally —
+  "API Logs", not "APIs Logs"; "the Issue table", not "the Issues table".
+* **When adding a table to `Logs`, name it singular.** Do not "fix" existing `Logs` tables to
+  plural, and do not carry the singular form into any other database.
+* Foreign keys are unaffected: a key referencing `Issue` is still `issueId` (the FK rule already
+  singularizes).
+
+```
+# Good — non-Logs databases
+Orders
+Customers
+Locations_LocationAttributes
+
+# Good — the Logs database only
+Issue
+IssueFingerprint
+
+# Bad
+Logs.Issues            # Logs tables are singular
+Core.Order             # non-Logs tables are plural
+```
+
 #### **Bridge Tables**
 
 * Most bridge tables need to include an underscore between the two tables they are joining. If you are joining a parent with a child table, the parent should come first. Exceptions may be made for inherent child records like `SalesOrderItems` being a child yet also a bridge of `SalesOrders`
@@ -756,3 +784,7 @@ client sending a shallow depth.
 ### Code Documentation
 
 * Ensure code is well-documented with comments and usage examples.
+
+## Change history
+
+- 2026-08-01 — Recorded the Logs-cluster singular table-naming exception to the otherwise-plural table convention. (jcardinal)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "toga-ai",
-  "version": "1.0.490",
+  "version": "1.0.491",
   "description": "TOGA Technology Team Claude Knowledge System — shared AI coding harness with skills, knowledge base CLI, and project installer for Claude Code.",
   "keywords": [
     "claude",