toga-ai 1.0.511 → 1.0.513

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

@@ -49,6 +49,26 @@ happening and were deliberately never ticketed. Nobody had that view before.
 Filesystem routing (1.0 Tools MVC): `mvc/errors/` = **`/errors`** (the listing) and
 `mvc/errors/issue/` = **`/errors/issue`** (the detail page).
 
+**`/errors/issue` takes two parameters, one meaning each** (2026-08-04):
+
+| Parameter | Means | Use |
+| --- | --- | --- |
+| `?issue=4KP` | `Issue.reference` — the identifier everything else quotes (ClickUp title, escalation email, neglect digest, production error page) | **all new links**, including the listing rows and worker2's `buildToolsIssueUrl()` |
+| `?issueId=9` | `Issue.id` | the original form, kept working **indefinitely** |
+
+`?issueId=` is never removed: links built from it are already sitting in ClickUp tasks and emails
+sent months ago that cannot be rewritten.
+
+> **Why two parameters instead of one that accepts either.** References are **base 32 over an
+> alphabet that includes digits**, so an ordinary reference — `'68'`, `'137'`, `'400'` — is all
+> digits and **cannot be distinguished from a primary key by inspection**. A combined parameter
+> would have to guess; naming the parameter after the column removes the ambiguity. An earlier
+> combined `?issue=` with reference-first/id-fallback precedence was written and then replaced.
+
+`?issue=` also accepts the **event** form (`?issue=4KP-12` strips the event half), because that is
+what people copy out of an error page or ClickUp comment. An unknown reference leaves the id at 0
+and renders the existing "no such issue" view.
+
 **Listing** — 25 per page with a filtered `COUNT` (it was previously a silent `LIMIT 200`, so
 older issues simply did not exist as far as a curator could tell); bold monospace Issue ID; an
 **EB Environment** column read from the newest event's context; a **Type** column showing
@@ -75,6 +95,22 @@ curated text, affected clients) right, with an always-present Type chip.
 - Header chip order is **Issue / Environment / Type / Urgency** — Type was moved ahead of Urgency so
   urgency finishes the row at the far right.
 
+### Neglect indicator (2026-08-04)
+
+Both pages now surface the **neglect** contribution to urgency: the listing computes
+`openTaskAgeHours` as a correlated subquery and renders a `$describeNeglect` amber note
+(`.neglect-note`, `#8a5a00`) **under the urgency badge**; the detail page's *Acknowledged* fact row
+reads "not yet — waiting 3 days" alongside a NORMAL/HIGH neglect chip.
+
+**Why:** the urgency badge alone is genuinely misleading. A **HIGH beside "Lifetime 1"** is a
+statement about *response time*, not about the error, and nothing on the page let a reader tell
+those apart. **Nothing renders while the clock is running but under 24h** — below that the clock
+contributes nothing to urgency, so saying "neglect" would overstate it.
+
+**Deliberately scoped to the neglect contribution only.** The console never claims *which* axis is
+winning: computing the full driving axis in Tools would mean copying the volume, sustained and
+release-band thresholds too, and that much duplicated policy would rot.
+
 ### Table presentation rules (established 2026-08-04)
 
 **Stacked datetimes in every table on both pages** — listing *Last seen*; detail *Events → When*,
@@ -143,6 +179,17 @@ They were renamed from plural on 2026-08-01, after the pipeline was already in p
 
 ## Gotchas / known issues
 
+- **⚠ OPEN BUG (found 2026-08-04, deliberately left unfixed pending the developer's go-ahead):
+  `tools/mvc/errors/post.php` ~line 181, the merge-fingerprint action, will merge into the WRONG
+  issue.** It takes a reference **or** a numeric id in **one** field and disambiguates with
+  `ctype_digit()`. That was safe under the old **base-26** scheme, where every reference contained a
+  letter. Under the new **base-32** alphabet an all-digit reference like `'68'` is treated as **id
+  68** and silently repoints the fingerprint at the wrong Issue. Fix is either reference-first-then-id
+  precedence or two separate inputs (as `/errors/issue` now does).
+- **The 24/48 neglect thresholds are duplicated as plain numbers in both Tools views.** Tools is
+  1.0 and cannot read worker2's `NEGLECT_NORMAL_HOURS` / `NEGLECT_HIGH_HOURS`; both sites carry a
+  comment naming those constants as the source of truth. **Changing the policy means changing three
+  places** (worker2 + both Tools views).
 - **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
@@ -170,6 +217,22 @@ They were renamed from plural on 2026-08-01, after the pipeline was already in p
 
 ## Change history
 
+- 2026-08-04 (latest, **uncommitted/undeployed** at time of writing) — **Built:** a **neglect
+  indicator** on both pages — listing gained an `openTaskAgeHours` correlated subquery and a
+  `$describeNeglect` amber note (`.neglect-note`, `#8a5a00`) under the urgency badge; the detail
+  page's *Acknowledged* row now reads "not yet — waiting 3 days" with a NORMAL/HIGH neglect chip.
+  The urgency badge alone was misleading (a HIGH beside "Lifetime 1" describes response time, not
+  the error) and nothing distinguished the two; nothing renders under 24h since the clock is
+  contributing nothing yet. Scoped to the neglect contribution only — computing the winning axis
+  would mean duplicating the volume/sustained/release-band thresholds as well. **Built:**
+  `/errors/issue` now accepts **`?issue=<reference>`** (also tolerating the `4KP-12` event form) and
+  the listing links by reference; `?issueId=<id>` is kept working **indefinitely** for links already
+  sitting in old ClickUp tasks and emails. Two parameters rather than one, because base-32
+  references can be all digits and are indistinguishable from a primary key. **Recorded two
+  maintenance hazards:** the 24/48 thresholds are now duplicated as literals in both Tools views
+  (Tools is 1.0 and cannot read worker2's constants — three places to change), and an **open bug** in
+  `post.php`'s merge-fingerprint `ctype_digit()` disambiguation, which under base-32 will merge into
+  the wrong Issue (flagged, left unfixed). (jcardinal)
 - 2026-08-04 (later, **uncommitted/undeployed** at time of writing) — UI pass on both `/errors`
   pages: **stacked datetimes** in every table via a shared `$datetime` closure emitting
   `.dt`/`.dt-date`/`.dt-time` (a naturally wrapping datetime broke inside the day of the month), and

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

@@ -364,6 +364,18 @@ in `_underscore` and `library` in the **same** release, and the `/errors` consol
   `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`.
+- **The `dbchanges2/Logs/` migration files LAG the deployed schema — read the live cluster, not the
+  migrations.** `dbchanges2/Logs/2026-07-30a - Error reporting Issues and Events.sql` does **not**
+  describe the live `Logs.Issue`: notably the identity column is **`issueKey` (varchar 128)**, not
+  `code`. Live columns include `reference`, `dtLastOccurred`, `isManaged`, `urgency`,
+  `minimumUrgency`, `consecutiveQuietWindows`, `subject`, `errorMessage`, `occurrences`,
+  `totalOccurrences`, `recurrenceCount`, `dtLastNotified`, `notificationCount`, `dtAcknowledged`,
+  `dtMutedUntil`, `createsClickupTask`, `clickupPriority`, `clickupAssigneeId`. Query
+  `information_schema` (or `SHOW TABLES` / `SHOW COLUMNS`) against the live Logs cluster **before**
+  writing any SQL against this feature — reading the migrations instead produced confidently wrong
+  conclusions twice on 2026-08-04. Same trap for the **singular** table names
+  (`Issue`/`Event`/`IssueFingerprint`/`IssueAreaOwner`/`IssueClickupTask`/`IssueEmailAddress`,
+  renamed by `2026-08-01a` and confirmed applied in prod).
 - **Pre-existing committed secrets in this area (not fixed — out of scope, report only).**
   A ClickUp API token at `_underscore/Component/Api/Clickup/Clickup.php:5`; SES SMTP
   credentials at `_underscore/Email.php:11-12`; a named individual's Sentry personal access
@@ -418,6 +430,12 @@ clientUserId). **Neither was built.** As built instead:
 
 ## Change history
 
+- 2026-08-04 — **Correction/diagnostic:** recorded that the `dbchanges2/Logs/` migration files lag
+  the deployed schema — `2026-07-30a` describes a `code` identity column, but live `Logs.Issue` is
+  keyed on **`issueKey` (varchar 128)** — and listed the live column set. Query
+  `information_schema` against the live Logs cluster before writing SQL here; trusting the
+  migrations (and forgetting the applied singular rename) produced two confidently wrong
+  conclusions in one session. No code change. (dfranks)
 - 2026-08-04 (later, **uncommitted/undeployed** at time of writing) — **Reference encoding reworked
   to base 32** over `'0123456789ACDEFGHJKMNPQRSTUVWXYZ'` (all digits kept; `O`/`I`/`L`/`B` dropped
   as impersonators of `0`/`1`/`1`/`8`), replacing the base-26 decimal-counter+letter scheme, with

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

@@ -18,7 +18,7 @@
 | [Compass VIP Support Importer (worker2)](features/compass-vip-support-importer.md) | A worker2 action that ingests Compass's quarterly VIP spreadsheet and assigns each VIP user's support technician by setting `Users.c_supportedByUserId` in `Clie | worker2/Worker/Client/Compass/VipSupport.php |
 | [Creating Worker Actions](features/creating-worker-actions.md) | How to add a new callable Worker action — a PHP class whose `public static` methods are invoked as background jobs (via webhook, cron, or `_Worker::runTask()`). | worker2/Worker/, worker2/Controller/Index.php, _underscore/Worker.php |
 | [Elite Freshservice Sync (worker2)](features/elite-freshservice-sync.md) | `_Worker_Elite` processes Freshservice webhook events and syncs them into TOGA 2. | worker2/Worker/Elite.php, worker2/Config/dev-kmaramreddy-laptop.ini |
-| [Error Escalation Cron (Errors::Escalate → ClickUp / email)](features/error-escalation-cron.md) | `_Worker_Infrastructure_Errors::Escalate` (renamed from `SyncWithClickup`) is the sole owner of **escalation, de-escalation, ClickUp ticketing, reminders, busin | worker2/Worker/Infrastructure/Errors.php, worker2/Worker/Notification/Email.php, worker2/Worker/Notification/EmailTemplate.php, worker2/Worker/Client/True.php, worker2/Worker/Clickup/ErrorTask.php, worker2/Worker/Clickup.php, worker2/Controller/Index.php, worker2/Config/production.ini, _underscore/Model/Core/Logs/Issue.php, dbchanges2/Core/2026-07-30a - Error escalation cron job.sql, dbchanges2/Logs/2026-08-03a - Issue clickupPriority.sql |
+| [Error Escalation Cron (Errors::Escalate → ClickUp / email)](features/error-escalation-cron.md) | `_Worker_Infrastructure_Errors::Escalate` (renamed from `SyncWithClickup`) is the sole owner of **escalation, de-escalation, ClickUp ticketing, reminders, busin | worker2/Worker/Infrastructure/Errors.php, worker2/Worker/Notification/Email.php, worker2/Worker/Notification/EmailTemplate.php, worker2/Worker/Client/True.php, worker2/Worker/Clickup/ErrorTask.php, worker2/Worker/Clickup.php, worker2/Controller/Index.php, worker2/Config/production.ini, _underscore/Model/Core/Logs/Issue.php, dbchanges2/Core/2026-07-30a - Error escalation cron job.sql, dbchanges2/Logs/2026-08-03a - Issue clickupPriority.sql, dbchanges2/Core/2026-08-04a - Error neglect digest cron job.sql |
 | [Etilize Catalog Item Import & Refresh](features/etilize-catalog-item-import.md) | Client-generic catalog onboarding from an S3 CSV plus an Etilize re-pull. | worker2/Worker/Etilize/Items.php |
 | [Etilize Item Translation Import](features/etilize-item-translation-import.md) | The abstract worker class `_Worker_Etilize_ItemTranslations` imports **non-English** item text from Etilize into the client's `ItemTranslations` table. | worker2/Worker/Etilize/ItemTranslations.php |
 | [Monitoring Framework (Orchestrator + Child Monitors)](features/monitoring-framework.md) | A unified, DB-driven monitoring framework for business-critical data flows (Compass POs, Prudential asset imports, AIG closed claims, …). | worker2/Worker/Monitor.php, worker2/Worker/Monitors/, worker2/Worker/Monitors/RateEntitlement.php, worker2/Worker/Notification/Email.php, worker2/Worker/Rate.php, dbchanges2/Core/2026-05-21 - Monitors.sql, dbchanges2/Core/2026-06-29a - Rate Entitlement Contract Monitor.sql |

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

@@ -7,7 +7,7 @@ client: shared
 type: feature
 status: active
 updated: 2026-08-04
-owners: ["jcardinal"]
+owners: ["jcardinal", "dfranks"]
 files:
   - worker2/Worker/Infrastructure/Errors.php
   - worker2/Worker/Notification/Email.php
@@ -20,6 +20,7 @@ files:
   - _underscore/Model/Core/Logs/Issue.php
   - dbchanges2/Core/2026-07-30a - Error escalation cron job.sql
   - dbchanges2/Logs/2026-08-03a - Issue clickupPriority.sql
+  - dbchanges2/Core/2026-08-04a - Error neglect digest cron job.sql
 related:
   - ../../_underscore/features/error-reporting-issue-event.md
   - ../../../1.0/apps/tools/features/errors-curation-console.md
@@ -28,6 +29,7 @@ related:
   - ./clickup-project-routing.md
   - ./notification-email.md
   - ./notification-email-template.md
+  - ../../../clients/compass-usa/features/mits-sales-order-transmission-alerting.md
 ---
 
 ## Summary
@@ -46,13 +48,93 @@ through this one action, so there is exactly one place to mute or debug alerting
 - **Volume** — occurrences in a **1-hour** window: **NORMAL 5 / HIGH 10 / URGENT 20** (retuned
   2026-08-04 from 20/50/100 over 10 minutes — a 10-minute window never fired for the
   low-and-steady failures that actually matter).
-- **Neglect** — hours an *unacknowledged* ClickUp task has sat: **1 / 4 / 24**.
+- **Neglect** — hours an *unacknowledged* ClickUp task has sat: **NORMAL 24 / HIGH 48. Capped at
+  HIGH — there is no URGENT rung.**
 - **Sustained-24h** — an issue still occurring a day later escalates on duration alone.
 - **Floor** — the Issue's declared `minimumUrgency` applies under *all* axes.
 
 The neglect axis exists because volume alone cannot see a rare-but-serious error, nor a serious
 error that everyone is ignoring.
 
+#### ⚠ Neglect is capped at HIGH and slowed to 24h/48h (decided + fixed 2026-08-04)
+
+`NEGLECT_NORMAL_HOURS` 1 → **24**, `NEGLECT_HIGH_HOURS` 4 → **48**, and
+**`NEGLECT_URGENT_HOURS` and its branch were removed** from `resolveNeglectUrgency()`. This
+**supersedes** the earlier 1/4/24 ladder with an URGENT rung.
+
+**Why:** neglect answers *"is anyone on this"* — a question about the **team's response**, never
+about how much damage the error is doing. Only the volume axes measure damage, so only they may
+claim URGENT. Left uncapped on the old clock, any error that fired once and went unacknowledged
+for an afternoon became HIGH, then URGENT the next day. That is how the queue filled up:
+**48 of 68 issues sat at HIGH**, and issue **3H (id 60) was HIGH off a single lifetime
+occurrence** — volume 0 in the 60-minute window, sustained 1 against a threshold of 50,
+`minimumUrgency` LOW, with the entire HIGH coming from its ClickUp task sitting unacknowledged
+for 4.93 hours.
+
+**The neglect axis is a FLOOR, not a ceiling.** `resolveNeglectUrgency()` is one of four inputs
+to `highestUrgency()`, which takes the **max** — so a neglected issue that starts firing still
+escalates on volume: two days unacknowledged contributes HIGH, and 20 occurrences in the window
+take it straight to URGENT regardless. Capping the axis lowers the floor *neglect alone* can
+raise; it takes nothing away from the occurrence count. Upward moves apply the same run (only
+**downward** moves go through the `REQUIRED_QUIET_RUNS` dwell), so volume takeover is same-run.
+
+**Intended side effect, accepted:** `SPRINT_PROMOTION_URGENCY` is `'URGENT'`, so with neglect
+capped at HIGH, **neglect alone can no longer promote an issue into the sprint** — only a genuine
+occurrence rate can.
+
+**Deploy effect.** All 50 then-HIGH issues had open unacknowledged tasks younger than 24h, so
+their neglect contribution becomes LOW and they recompute from volume/sustained/floor within ~3
+runs of the worker2 deploy. Expect a **burst of ClickUp priority PUTs** on the first runs as
+`clickupPriority` re-syncs.
+
+### Daily neglect digest email (`Infrastructure/Errors/NeglectDigest`)
+
+A second worker action — `public NeglectDigest()`, with `loadNeglectedIssues()` and
+`buildNeglectDigestBody()` — registered in `Core.CronJobs` as action
+`Infrastructure/Errors/NeglectDigest` at **`0 8 * * *`** (08:00 CT: after the overnight cleanup
+jobs, before the working day), `maxExecutionTime` 300. Migration:
+`dbchanges2/Core/2026-08-04a - Error neglect digest cron job.sql`.
+
+**Why a digest exists at all — the governing principle:** neglect means *"nobody is looking"*, so
+**every signal that requires somebody to look is self-defeating.** It is also the necessary
+counterpart to capping the axis: with neglect slowed and capped, an ignored issue no longer
+announces itself by climbing the urgency scale, so something has to come and tell you.
+
+Sends via `_Worker::runTask('Notification/EmailTemplate/Send')` with the TOGA Technology stored
+template — the **same path as the technical escalation email**. Recipient is `[_underscore]
+error_escalation_email`, gated by the same `error_escalation_enabled` key, so non-production mails
+nobody. The body is a **fragment** for the template's `{body}` (600px cell; the template owns font
+and width), exactly like `buildTechnicalEmailBody()`.
+
+Three design decisions, each load-bearing:
+
+- **It sends even when the list is empty.** An empty digest states *"nothing is neglected"*;
+  silence cannot be distinguished from a broken notifier — which is precisely the failure that hid
+  the escalation email being dead for days while every run reported success. The **subject
+  reflects the state** ("No neglected error issues" vs "2 error issues nobody has picked up") so
+  it is triageable from the inbox list without opening it.
+- **One email covering every issue, never one per issue.** A per-issue alert for a condition that
+  by nature affects many issues at once is how a channel becomes wallpaper — and the reminder
+  ladder already carries the per-issue nagging.
+- **Floored at `NEGLECT_NORMAL_HOURS`**, not "everything open". That constant is where the cron
+  itself starts treating an issue as neglected, so the digest reports only things that have
+  crossed a line. A task opened this morning is not neglected, it is new. Ordered **oldest
+  first** so the worst case is the first line read.
+
+Verified against production: the query returns **2 rows** today (1B and 1I, both 24h
+unacknowledged).
+
+**Rejected alternatives:**
+
+- *Mutating the ClickUp task **title** to say "neglected"* — the title is deliberately just the
+  reference and is never rewritten; rewriting churns the activity feed and breaks the
+  quote-the-reference contract, and it only helps someone already looking at the task.
+- *A new `Issue` column (`dtNeglectedSince`, `neglectLevel`)* — fully derivable from
+  `IssueClickupTask.dtCreated` + `Issue.dtAcknowledged`, so storing it is denormalised state that
+  can drift, and it still needs something to read it out.
+- *A ClickUp custom field* — **deferred, not rejected**: it writes every run and duplicates what
+  the digest says. Revisit only if the digest proves insufficient.
+
 ### Fast up, slow down
 
 Escalation applies **the same run** a band is crossed. De-escalation requires the count to sit
@@ -107,6 +189,15 @@ ClickUp is the acknowledge/resolve system — developers already live there, and
 Tools would just be ignored. **Any** status change on an error task counts as acknowledgement,
 which is safe only because the automation never sets status itself.
 
+> **`dtAcknowledged` is set by a status change OR by an assignee being added** — both, and this was
+> already implemented (confirmed 2026-08-04, no change needed). `worker2/Worker/Clickup.php:856`
+> routes the ClickUp `taskUpdated` webhook into
+> `_Worker_Clickup_ErrorTask::handleAssigneeChange()`, which calls `markAcknowledged()` (and also
+> feeds the per-area ownership learner). Both routes are subject to the 60-second creation grace
+> window below. Production: 8 of 71 issues acknowledged. **Worth stating explicitly, because the
+> acknowledgement definition is what both the neglect axis and the daily digest key off**, and it
+> is not visible from the escalation-cron side.
+
 > **60-second creation grace window (fix, 2026-08-04).** ClickUp fires a status webhook for a
 > task's *initial* status, so the automation was acknowledging its **own** newly created tasks —
 > stamping `dtAcknowledged` ~1s after `dtCreated` and permanently disabling the neglect axis for
@@ -175,6 +266,32 @@ healthy — cannot recur silently.
 - **Occurrences** and **Last Occurrence** custom fields are synced, and task bodies open with a
   **"Debug in Tools"** deep link.
 
+#### Tools deep links address the issue by REFERENCE, not id
+
+`TOOLS_ISSUE_PATH` changed from `'/errors/issue?issueId='` to **`'/errors/issue?issue='`**, and
+`buildToolsIssueUrl()` now emits the **reference**, `rawurlencode`d, falling back to the id only
+when a row has no reference. **Two parameters, one meaning each** — deliberately not one parameter
+that accepts either:
+
+| Parameter | Means | Use |
+| --- | --- | --- |
+| `?issue=4KP` | `Issue.reference` — what everything else quotes (ClickUp title, escalation email, digest, production error page) | **all new links** |
+| `?issueId=9` | `Issue.id` | the original form, kept working **indefinitely** |
+
+`?issueId=` stays supported forever because links built from it are already sitting in ClickUp
+tasks and emails sent months ago that cannot be rewritten.
+
+> **Why separate parameters rather than one that accepts either.** References are **base 32 over
+> an alphabet that includes digits**, so an ordinary reference — `'68'`, `'137'`, `'400'` — is all
+> digits and **cannot be told apart from a primary key by inspection**. A single combined parameter
+> would have to guess; naming the parameter after the column removes the ambiguity entirely. (An
+> earlier combined `?issue=` with reference-first / id-fallback precedence was written and then
+> replaced by this.)
+
+`?issue=` also accepts the **event** form — `?issue=4KP-12` strips the event half and lands on the
+issue — because that is what people copy out of an error page or a ClickUp comment. An unknown
+reference leaves the id at 0 and renders the existing "no such issue" view.
+
 ### Area-level owner learning (observation only)
 
 `IssueAreaOwner` learns an owner after **5 in a row** and ships **observation-only** — a hint in
@@ -231,6 +348,12 @@ this controller needs the same treatment.**
 
 ## Gotchas / known issues
 
+- **An issue held at HIGH purely by neglect never de-escalates on its own.**
+  `applyDeEscalationDwell()` needs the computed target to sit **below** the stored urgency for
+  `REQUIRED_QUIET_RUNS` (3) consecutive runs, but the neglect axis keeps recomputing the target
+  **at** the stored level — so the dwell counter never starts. That is why issue 3H showed
+  `consecutiveQuietWindows = 0` after five hours of total silence. **Acknowledging the ClickUp task
+  is what releases it**, and it then drops within 3 cron runs (~3 min).
 - **Never send email inline inside this cron's open transaction — enqueue it.** `_Email::send()`
   registers a second connection and toggles the read host, and a throw from in there was only ever
   `error_log`'d. Use `_Worker::runTask` so a failure becomes a visible failed `WorkerJobs` row.
@@ -263,6 +386,22 @@ this controller needs the same treatment.**
   issue gets a **neutral** subject rather than another client's raw error text.
 - **`IssueEmailAddress.clientId = 0` means "all clients"** and requires an explicit
   confirmation flag in the Tools console; list views render it as **"ALL CLIENTS"**.
+- **A recipient scoped to a specific `clientId` delivers NOTHING for occurrences recorded without
+  client attribution.** `loadRecentClientIds()` maps an occurrence whose `clientId` is NULL to
+  **`0`**, and `resolveRecipientsForClient()` resolves scope `0` **plus** the erroring client. So
+  the rule is: scope to **`0`** when the `issueKey` is raised from a **single client-specific code
+  path** (a Compass-only cron, say); **never** scope to `0` for an `issueKey` raised from shared
+  code, which would leak one client's alerts to another's recipients.
+- **Configuring a recipient is never retroactive.** `shouldNotify()` notifies on first occurrence
+  (`notificationCount` 0), on escalation, or when the backed-off reminder interval has elapsed —
+  and returns **false when the current window has zero events**. The first email therefore lands on
+  the **next live occurrence**, not on the backlog. Do not read silence right after a config change
+  as a failure.
+- **Adding a business recipient is purely additive — it cannot switch ClickUp ticketing off.**
+  Routing is **both**, not either: `if ($recipients !== null)` emails the business recipients and
+  `if ($issue->createsClickupTask)` tickets the dev team, evaluated **independently**. The in-code
+  comment marking this records the earlier `elseif` form, where adding one recipient silently
+  disabled an issue's dev-team ticket.
 - **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
   alert suppression against the error-reporting system itself. Fix before relying on this
@@ -273,6 +412,38 @@ this controller needs the same treatment.**
 
 ## Change history
 
+- 2026-08-04 (verified against `origin/_production` + the prod Logs cluster) — Recorded the
+  **recipient-routing semantics** a developer needs before configuring a business alert: routing is
+  **both** business email and dev-team ClickUp, evaluated independently (adding a recipient is
+  purely additive); `IssueEmailAddress.clientId` scoping means a client-scoped row delivers nothing
+  for occurrences with NULL `clientId` (mapped to `0`), so single-client `issueKey`s scope to `0`
+  and shared-code `issueKey`s never do; and `shouldNotify()` makes configuration
+  **non-retroactive** — the first email lands on the next live occurrence. Also noted that prod
+  `Logs.IssueEmailAddress` was still empty, making Compass's MITS rejection the platform's first
+  business-routed issue. No code change. (dfranks)
+- 2026-08-04 (latest, **uncommitted/undeployed** at time of writing) — **Decided + fixed: the
+  neglect urgency axis is capped at HIGH and slowed to 24h/48h**, superseding the 1/4/24 ladder
+  recorded earlier the same day (`NEGLECT_NORMAL_HOURS` 1→24, `NEGLECT_HIGH_HOURS` 4→48,
+  `NEGLECT_URGENT_HOURS` and its branch removed). Neglect measures the **team's response**, not the
+  damage the error is doing, so only the volume axes may claim URGENT; uncapped on the old clock a
+  single-occurrence error became HIGH in an afternoon and URGENT the next day — 48 of 68 issues were
+  at HIGH and issue 3H (id 60) was HIGH off one lifetime occurrence. The axis remains a **floor, not
+  a ceiling** (`highestUrgency()` takes the max, so volume still escalates immediately). Accepted
+  side effect: `SPRINT_PROMOTION_URGENCY` is URGENT, so neglect alone can no longer promote into the
+  sprint. **Built:** a **daily neglect digest** (`Infrastructure/Errors/NeglectDigest`,
+  `Core.CronJobs` at `0 8 * * *`, migration `dbchanges2/Core/2026-08-04a`) — the counterpart to the
+  cap, since a capped axis no longer announces an ignored issue; it **sends even when empty** (a
+  broken notifier is indistinguishable from silence), is **one email for all issues**, and floors at
+  `NEGLECT_NORMAL_HOURS`, oldest first. Rejected: rewriting the ClickUp title, a derived
+  `dtNeglectedSince`/`neglectLevel` column; deferred: a ClickUp custom field. **Built:**
+  `TOOLS_ISSUE_PATH` now emits `?issue=<reference>` (rawurlencoded, id fallback) with `?issueId=`
+  kept working indefinitely — separate parameters because base-32 references can be all digits and
+  are indistinguishable from a primary key. **Discovered:** assignee-based acknowledgement was
+  already implemented (`Clickup.php:856` → `handleAssigneeChange()` → `markAcknowledged()`), and
+  that a neglect-held HIGH never de-escalates until the task is acknowledged. Verification:
+  `php -l` clean on every changed file; the digest SQL run against production (2 rows); neglect
+  impact quantified across all 68 issues; `0 8 * * *` checked against existing daily job
+  conventions. (jcardinal)
 - 2026-08-04 (later, **uncommitted/undeployed** at time of writing) — **Fixed: escalation email had
   never been sent, ever**, for two independent reasons. (A) `processTechnicalIssue()` returned early
   when the ClickUp task would read identically, and that return sat *above* the `if ($shouldNotify)`

package/knowledge/INDEX.md

@@ -39,7 +39,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 - **togatech** (TOGA Technology Website) — 4 doc(s) → [standalone/apps/togatech/INDEX.md](standalone/apps/togatech/INDEX.md)
 - **websocket** (WebSocket Server) — 2 doc(s) → [standalone/apps/websocket/INDEX.md](standalone/apps/websocket/INDEX.md)
 - **forward** (Forwarder) — 3 doc(s) → [standalone/apps/forward/INDEX.md](standalone/apps/forward/INDEX.md)
-- **claude** (Claude Harness) — 3 doc(s) → [standalone/apps/claude/INDEX.md](standalone/apps/claude/INDEX.md)
+- **claude** (Claude Harness) — 4 doc(s) → [standalone/apps/claude/INDEX.md](standalone/apps/claude/INDEX.md)
 
 ## Clients
 

package/knowledge/clients/compass-usa/INDEX.md

@@ -8,6 +8,7 @@
 | [Compass: Item-Fulfillment TableViews (for-sales-order-items & for-sales-orders, tracking via bridge)](features/item-fulfillment-tracking-tableview.md) | 2.0 | Two sibling Compass TableViews in `Client_Compass` display fulfilled items in toga2-supply, both driven by `TableViews` / `TableViewJoins` / `TableViewFields` c | dbchanges2/Client_Compass/2026-06-10 - ItemFulfillmentsForSalesOrderItemsTableView.sql, dbchanges2/Client_Compass/2026-06-11 - ItemFulfillmentsForSalesOrdersTableView.sql, dbchanges2/Client_Compass/2026-06-15a - FixItemFulfillmentTrackingNumberJoins.sql, dbchanges2/Client/2026-07-15a - ExcludeFeeItemsFromItemFulfillmentsForSalesOrdersView.sql |
 | [Compass MITS PO → SO Item Linking](features/mits-po-to-so-item-linking.md) | 2.0 | MITS sends Compass inbound Purchase Orders (`POST /v2/purchase-orders`) against a Sales Order (`mitsSalesOrder`). | _underscore/Model/Compass/PurchaseOrder.php, worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php |
 | [Compass MITS PO Transmission to Vendors](features/mits-po-transmission-to-vendors.md) | 2.0 | The 1.0 worker cron `2_transmit_mits_purchase_orders_to_vendors.php` transmits Compass PurchaseOrders to their vendors (Office Depot, Strategic Systems, Compass | worker/crons/toga2/compass/workflow/2_transmit_mits_purchase_orders_to_vendors.php, worker/crons/toga2/compasscanada/workflow/2_transmit_mits_purchase_orders_to_vendors.php, library/app/client/compass.php |
+| [Compass MITS Sales-Order Transmission — Rejection Alerting (Issue/Event, not email-in-cron)](features/mits-sales-order-transmission-alerting.md) | 2.0 | When MITS **rejects** a Compass sales order transmitted by the 1.0 cron `1_transmit_compass_sales_orders_to_mits.php`, the alert is no longer an email built ins | worker/crons/toga2/compass/workflow/1_transmit_compass_sales_orders_to_mits.php, worker2/Worker/Infrastructure/Errors.php, _underscore/Model/Core/Logs/Issue.php, _underscore/Model/Core/Logs/IssueEmailAddress.php, dbchanges2/Logs/2026-08-04a - MITS rejection business recipients.sql |
 | [Compass MR/MA Order Auto-Approval & Status Gate](features/mr-ma-order-approval-and-status.md) | 2.0 | Compass **MR** and **MA** sales orders are system-generated from the MITS / Office Depot EDI pipeline (they do not originate as user-entered SA orders) and must | _underscore/Model/Compass/SalesOrder.php, _underscore/Model/Compass/PurchaseOrder.php, worker/crons/toga2/compass/workflow/3a_import_office_depot_purchase_orders.php |
 | [Compass USA](profile.md) | 2.0 | Compass USA is a TOGA client running a multi-tier supply-chain commerce operation. |  |
 | [Compass Cross-Kit Bundle Corruption — Detection & Repair](workflows/cross-kit-bundle-corruption.md) | 2.0 | A frontend regression in `toga2-commerce`'s edit-order bundle submission mis-attributed bundle (kit) line items and **fees/warranties** to the **wrong kit**, pe | src/api/syncSalesOrderItemsFromLocalStorageCartToApi.ts |

package/knowledge/clients/compass-usa/features/mits-sales-order-transmission-alerting.md

@@ -0,0 +1,89 @@
+---
+title: Compass MITS Sales-Order Transmission — Rejection Alerting (Issue/Event, not email-in-cron)
+framework: "2.0"
+project: _Underscore
+client: compass-usa
+type: client-feature
+status: active
+updated: 2026-08-04
+owners: ["dfranks"]
+files:
+  - worker/crons/toga2/compass/workflow/1_transmit_compass_sales_orders_to_mits.php
+  - worker2/Worker/Infrastructure/Errors.php
+  - _underscore/Model/Core/Logs/Issue.php
+  - _underscore/Model/Core/Logs/IssueEmailAddress.php
+  - dbchanges2/Logs/2026-08-04a - MITS rejection business recipients.sql
+related:
+  - mits-po-transmission-to-vendors.md
+  - ../../../2.0/apps/worker2/features/error-escalation-cron.md
+  - ../../../2.0/apps/_underscore/features/error-reporting-issue-event.md
+  - ../../../1.0/apps/library/features/error-capture-1-0.md
+---
+
+## Summary
+
+When MITS **rejects** a Compass sales order transmitted by the 1.0 cron
+`1_transmit_compass_sales_orders_to_mits.php`, the alert is no longer an email built inside the
+cron. It is a **business exception** raised into the shared Logs Issue/Event pipeline, and its
+recipients are **rows in `Logs.IssueEmailAddress`**.
+
+**Consequence for anyone handed a ticket like "add <person> to the MITS error emails": there is
+no PHP to change.** It is a one-row data change delivered as a `dbchanges2/Logs/` migration.
+
+## How it works
+
+- The cron raises
+  `throw new App_Exception_Business('COMPASS_SALES_ORDER_MITS_TRANSMIT_REJECTED', …, URGENCY_HIGH)`
+  on a MITS rejection. (Before 2026-08-03 this block was a hardcoded `new App_Email_Agilant()`
+  with `addTo('devteam@togatech.com')`.)
+- Capture creates/dedupes a `Logs.Issue` keyed on the `issueKey`, and the worker2
+  `Infrastructure/Errors/Escalate` cron does all outbound notification — business email to the
+  configured recipients **and**, independently, the dev-team ClickUp task. See
+  [error-escalation-cron](../../../2.0/apps/worker2/features/error-escalation-cron.md).
+- Recipients live in `Logs.IssueEmailAddress` (FK `issueId` → `Logs.Issue`), scoped by
+  `clientId` (`0` = all clients).
+
+### Adding a recipient (the correct pattern)
+
+Write a `dbchanges2/Logs/YYYY-MM-DD<letter>` migration that:
+
+1. **Looks the issue up by `issueKey`**, never by its `id`. The id is assigned on the issue's
+   **first occurrence** and is therefore not stable across environments.
+2. Uses **`clientId = 0`**. This `issueKey` is raised from a Compass-only code path, and an
+   occurrence recorded without client attribution resolves against scope `0` only — a row scoped
+   to the Compass `clientId` can deliver nothing. (Never use `0` for an `issueKey` raised from
+   shared code — that is a cross-tenant leak.)
+3. Is **idempotent** via `INSERT … WHERE NOT EXISTS`, mirroring the unique key
+   `uq_issue_client_address_type`.
+
+Configuration is **never retroactive**: `shouldNotify()` fires on the first occurrence, on
+escalation, or when the backed-off reminder interval elapses, and returns false for a window with
+zero events. The first email lands on the **next live rejection**, not on existing history.
+
+## Gotchas / known issues
+
+- **Do not "modernize" this alert back into the cron.** Migrating it to
+  `_Model_Client_EmailTemplate::send` (or any in-cron email) reverts the move to the Issue/Event
+  pipeline and removes the recipient configuration surface entirely.
+- **Never re-introduce the payload dump into the alert.** The original email included the
+  transmission payload, which carries ship-to addressee, attention line, street address and phone
+  number. The Issue message is stored in a table **shared across every client**, displayed to
+  internal staff in the Tools `/errors` console, pushed to ClickUp, and emailed — so the payload
+  was deliberately removed. Alerts here name the order, not the person.
+- **The MITS cron holds its API credentials inline in the file.** Treat that file as
+  secret-bearing when copying snippets anywhere (tickets, PR bodies, knowledge docs).
+- **Adding a recipient does not turn ClickUp ticketing off.** Routing is both-and, not
+  either-or — see the escalation-cron doc for the `elseif` bug this used to be.
+- As of 2026-08-04 prod `Logs.IssueEmailAddress` is empty, so this is the **first business-routed
+  issue on the platform**: `processBusinessIssue()` will execute in production for the first time
+  when this issue next fires. Watch that run rather than assuming it works.
+
+## Change history
+- 2026-08-04 — Documented that MITS rejection alerting moved (worker `5521854b`, 2026-08-03) from a
+  hardcoded in-cron `App_Email_Agilant` to `App_Exception_Business` +
+  `Logs.IssueEmailAddress` recipients, so adding an alert recipient is a data change, not a code
+  change. Recorded the deliberate removal of the PII-bearing payload dump from the alert, the
+  look-up-by-`issueKey` / `clientId = 0` / `NOT EXISTS` migration pattern, and that recipient
+  configuration only takes effect on the next live occurrence. (dfranks)
+</content>
+</invoke>

package/knowledge/clients/compass-usa/profile.md

@@ -16,10 +16,11 @@ project: _Underscore
 client: compass-usa
 type: profile
 status: active
-updated: 2026-07-16
-owners: [jcardinal, bala, tcox, apeterson]
+updated: 2026-08-04
+owners: [jcardinal, bala, tcox, apeterson, dfranks]
 files: []
 related:
+  - features/mits-sales-order-transmission-alerting.md
   - features/asn-to-item-fulfillment.md
   - features/cost-centers.md
   - features/approval-decision-flow.md
@@ -75,6 +76,10 @@ separate, related client (see its own profile).
   `worker/crons/toga2/compass/workflow/3b_import_strategic_systems_advance_shipping_notices.php`.
 
 ## Key features (this client)
+- [MITS Sales-Order Transmission — Rejection Alerting](features/mits-sales-order-transmission-alerting.md)
+  — MITS rejection alerts are `App_Exception_Business` Issues with recipients in
+  `Logs.IssueEmailAddress`, **not** an email in the cron: adding an alert recipient is a
+  `dbchanges2/Logs/` data change with no PHP.
 - [Compass ASN → ItemFulfillment Auto-Creation](features/asn-to-item-fulfillment.md) — the
   `_Model_Compass_AdvanceShippingNotice::postPost` handler.
 - [Cost Centers (Unit Locations, numeric-only)](features/cost-centers.md) — what a Compass

package/knowledge/standalone/apps/claude/INDEX.md

@@ -5,3 +5,4 @@
 | [Harness Distribution — How a knowledge.js Fix Reaches Teammates](workflows/harness-distribution.md) | There are **two copies** of `knowledge.js` on a developer's machine, and the skills use only one of them. | claude/scripts/install.js, claude/knowledge.js |
 | [Knowledge Base Publish / Push Pipeline](workflows/knowledge-publish-pipeline.md) | How `/capture` and `/session-save` get knowledge docs from your working tree into `agilantsolutions/claude` on `_main`. | claude/knowledge.js |
 | [MCP Tool Usage — "Talos" Means the Internal Knowledge Base, and Run Your Own SELECTs](workflows/mcp-tool-usage.md) | Two MCP connections are available in every session, and **Claude is expected to reach for them on its own judgement — nobody should have to say the word "MCP".* | claude/.claude/skills/kickoff/SKILL.md, claude/.claude/skills/capture/SKILL.md |
+| [Ticket-Branch Creation Safety — How /work-ticket Armed Pushes to Production Branches](workflows/ticket-branch-creation-safety.md) | For roughly a month, `/work-ticket` created ticket branches whose **git upstream was the production branch**. | claude/skills/work-ticket/SKILL.md |

package/knowledge/standalone/apps/claude/workflows/ticket-branch-creation-safety.md

@@ -0,0 +1,91 @@
+---
+title: Ticket-Branch Creation Safety — How /work-ticket Armed Pushes to Production Branches
+framework: "standalone"
+repo: claude
+project: Claude Harness
+client: shared
+type: workflow
+status: active
+updated: 2026-08-04
+owners: ["dfranks"]
+files:
+  - claude/skills/work-ticket/SKILL.md
+related:
+  - ./harness-distribution.md
+  - ../../../2.0/apps/worker2/workflows/ticket-to-pseudocode-planning.md
+---
+
+## Summary
+
+For roughly a month, `/work-ticket` created ticket branches whose **git upstream was the
+production branch**. Claude's own pushes were unaffected, but a developer using VS Code's
+**Commit + Sync** mid-session pushed ticket code straight to `_main`/`_production` — no PR, no
+review. Two such pushes landed in two days before it was found.
+
+The mechanism is generic git behavior, so it is worth understanding beyond this one skill.
+
+## Root cause
+
+Branch creation was `git checkout -b TRUE-XXXX "origin/$DEFAULT"`. Git's
+**`branch.autoSetupMerge` defaults to `true`**, so branching from a *remote-tracking ref* adopts
+that ref as the new branch's **upstream**. The ticket branch therefore tracked
+`origin/_main` / `origin/_production` until the skill's later `git push -u` re-pointed it.
+
+**Trigger asymmetry is why it hid.** Claude pushes with `git push -u origin <TICKET>` — an
+explicit refspec, which ignores the upstream and was always safe. VS Code's Commit + Sync resolves
+the destination **from the upstream**, so any developer commit made before the skill's first push
+went to the production branch.
+
+**A safety fix created the exposure.** Commit `6d155f7` (2026-07-09) moved branch creation from
+*after* implementation to *before* any code is written — itself a genuine fix, because a stale
+local `_production` 12 commits behind nearly reverted upstream work. But it turned a seconds-long
+armed window into the **entire implementation phase**. Correctness fixes can lengthen an existing
+window; check what else depends on the timing you moved.
+
+## The fixes
+
+1. **Skill:** branch creation uses **`--no-track`** *and* publishes the empty branch immediately
+   (`git push -u origin TRUE-XXXX`), so the branch has a correct upstream before any code exists.
+   The later push is a plain `git push origin <TICKET>`.
+2. **Global git config:** `branch.autoSetupMerge=simple` (a checkout can no longer adopt a
+   production upstream, even outside the skill) plus `push.autoSetupRemote=true`.
+3. **`pre-push` hook** in each app repo rejecting
+   `refs/heads/(_main|_production|_beta|_alpha|master)`, override `ALLOW_PROD_PUSH=1`. This also
+   catches Claude, because Claude shells out to real `git`.
+4. **Deny rules** in `.claude/settings.json`.
+5. Existing branches still tracking a production branch were **disarmed** individually.
+
+`rework-ticket` was never affected — it checks out an existing remote branch.
+
+## Recovery: getting an unreviewed commit off an unprotected default branch
+
+Do **not** force-push. Instead:
+
+1. **Revert via PR** on the default branch.
+2. **Rebuild the ticket branch as a NEW commit** on the post-revert base.
+
+> **The revert-remerge trap:** if you keep the original commit and merge that branch later, the
+> original commit is already an **ancestor** of the default branch, so the merge is a silent no-op
+> and the change **never comes back**. The revert wins and nothing warns you.
+
+## Gotchas / known issues
+
+- **Everything installed here is local and does not survive a fresh clone.** Hooks and git config
+  are per-machine; a teammate or a new laptop is unprotected until they redo it.
+- **Standing exposure (not fixed):** `dbchanges2/_main`, `worker/_production`,
+  `worker2/_production` and `api2/_production` have **no branch protection and no rulesets**.
+  Server-side protection is the only durable fix and needs an admin GitHub account.
+- **Diagnosing this class of incident:** `git reflog` on the remote-tracking branch shows
+  `update by push` entries — that is how both incidents were confirmed and how the other four
+  repos were cleared. Pre-existing `_beta` pushes are normal manual practice; check dates before
+  calling something an incident.
+- Auditing "did this ever happen elsewhere?" requires sweeping **every** repo the skill touches,
+  not just the one that surfaced the bug.
+
+## Change history
+- 2026-08-04 — Documented the `branch.autoSetupMerge` root cause, the Claude-vs-VS-Code trigger
+  asymmetry that hid it for a month, and the fixes (`--no-track` + immediate branch publish,
+  global `autoSetupMerge=simple`, per-repo `pre-push` hook, settings deny rules). Recorded the
+  revert-then-rebuild recovery pattern and its revert-remerge no-op trap, plus the standing lack
+  of server-side branch protection on four app repos. (dfranks)
+</content>

package/package.json

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