toga-ai 1.0.1206 → 1.0.1208

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

@@ -50,6 +50,7 @@
 | [_Model::save() vs raw _Query — no atomic conditional update](features/model-save-vs-query-atomic-update.md) | `_Model::save()` can't do an atomic conditional update or a second write on the same instance; open before writing a row-claim/optimistic-concurrency guard, a r |
 | [NetSuite REST Client (_Component_Api_Netsuite) — record writes & SuiteQL](features/netsuite-rest-client.md) | Shared 2.0 `_underscore` NetSuite REST client (`_Component_Api_Netsuite`) — record GET/write, SuiteQL, auth, escaping, logging; open before any 2.0 NetSuite cal |
 | [NetSuite Sales Order sync — ship-to address, phone, and PO reference sourcing](features/netsuite-salesorder-address-phone-sync.md) | Where the shared NetSuite SO importer (`_Trait_Netsuite_SalesOrder`) sources SO#, PO#, and ship-to phone, and the traps in changing it; open before editing this |
+| [Non-prod Aurora clusters (account 975050298201) — layout, settings, recovery, access limits](features/nonprod-aurora-clusters.md) | Which non-prod 2.0 Aurora MySQL clusters exist in account 975050298201 (us-east-1) after TRUE-83406, the settings every one copies, how to delete/restore a clus |
 | [Note records have NO author — every `*Notes` model's `contactId` is unwritten](features/note-record-authorship.md) | Every `*Notes` model declares a `contactId` FK but no code writes it — note authorship is unrecoverable from 2.0 data; open before building any note author disp |
 | [NOTIFICATION email templates — block JSON rendered server side (_Component_EmailBlocks + _Component_EmailBranding)](features/notification-email-blocks.md) | How client-built (NOTIFICATION) emails are stored as block JSON, rendered to safe HTML on the server, merged with `{{group.field}}` tokens and branded per clien |
 | [Notification engine (rule-driven in-app notifications from record change logs)](features/notification-engine.md) | Platform (all 2.0 apps) in-app notifications: data rules on Core turn a record's change log into Client.Notifications rows; open when adding a notification kind |

package/knowledge/2.0/apps/_underscore/features/aurora-binlog-configuration.md

@@ -11,6 +11,7 @@ owners: ["rgirish"]
 files: []
 related:
   - ../architecture.md
+  - nonprod-aurora-clusters.md
   - ../../../../1.0/apps/worker1.5/features/database-backups.md
 ---
 
@@ -48,7 +49,7 @@ Live check on us-east-1 writers: `log_bin = ON`.
 
 ### Non-prod (account 975050298201, us-east-1)
 
-- 19 single-instance clusters (`sandbox-dev`, `sandbox-client`, `stage`, `demo`, `client-*`, `qa-*`, `qc-*`), engine `3.10.3`.
+- Single-instance clusters, engine `3.10.3` — current list in [Non-prod Aurora clusters](nonprod-aurora-clusters.md).
 - All on `true-rds-cluster-parameters` with `binlog_format = OFF` (`log_bin = 0`). No Global Database.
 
 ### Who reads the binlog (2026-10-29: nobody)

package/knowledge/2.0/apps/_underscore/features/nonprod-aurora-clusters.md

@@ -0,0 +1,81 @@
+---
+title: Non-prod Aurora clusters (account 975050298201) — layout, settings, recovery, access limits
+framework: "2.0"
+repo: _underscore
+project: _Underscore
+client: shared
+type: feature
+status: active
+updated: 2026-10-29
+owners: ["rgirish"]
+files: []
+related:
+  - ../architecture.md
+  - aurora-binlog-configuration.md
+  - ../../api2/workflows/environment-configuration-and-provisioning.md
+  - ../workflows/local-db-refresh-from-beta.md
+---
+
+Which non-prod 2.0 Aurora MySQL clusters exist in account 975050298201 (us-east-1) after TRUE-83406, the settings every one copies, how to delete/restore a cluster safely, how to tell an empty cluster without DB access, and what the GoAgilant-Developers SSO role cannot do (KMS); open before creating, deleting or loading a non-prod DB cluster.
+
+## Summary
+
+One **all-in-one** Aurora MySQL cluster per non-prod environment: `Core`, `Client_*`, `Logs`, `Logs_*`, `Archive_*` all in the same cluster. No environment shares a cluster. Production is separate: 4 per-family clusters in account `654654170868` (see [binlog doc](aurora-binlog-configuration.md)).
+
+## How it works
+
+### Clusters (as of 2026-10-29)
+
+| Cluster | Databases |
+|---|---|
+| `sandbox-dev`, `sandbox-client` | full DB sets (unchanged) |
+| `qa-alpha` | `Core`, `Logs`, `Client_True`, `Client_Elite`, `Logs_True`, `Logs_Elite`, `Archive_True` (restored from final snapshot) |
+| `qc-security` | `Core`, `Logs`, `Client_Compass`, `Logs_Compass` (restored from final snapshot) |
+| `dev`, `qa`, `stage`, `uat`, `hotfix`, `demo`, `sandbox` | **empty** — created 2026-10-29, no TOGA databases yet |
+
+- The 7 new clusters match the environment list. AWS identifiers cannot start with `_`, so env `_qa` → cluster `qa`.
+- Endpoint: `<name>.cluster-cb860gg2qw2n.us-east-1.rds.amazonaws.com`.
+- Loading `Core` / `Client_*` / `Logs` into the new clusters is a follow-up ticket. Seed them per [environment provisioning](../../api2/workflows/environment-configuration-and-provisioning.md) (base `Logs` included).
+- Prod data into non-prod: only `stage` and `demo`, masked (ticket rule A17). Prod is 4 clusters, so it is dump + load per database, not a snapshot copy.
+
+### Settings every non-prod cluster copies (from `sandbox-dev`)
+
+- Engine `aurora-mysql` `8.0.mysql_aurora.3.10.3`.
+- One writer `<name>-writer`, `db.t4g.medium`, `us-east-1a`.
+- Subnet group `true-test-db-subnet-group`; security group `sg-075195ac9152313d3`.
+- Cluster parameter group `true-rds-cluster-parameters`; instance parameter group `true-rds-parameters`.
+- Encrypted with the account's RDS KMS key; not public; backup retention 1 day.
+- Enhanced monitoring 60 s via `rds-monitoring-role`.
+- Master user `admin`, plain `--master-user-password` (not Secrets Manager — see Gotchas).
+- Tags `Environment=<name>`, `Ticket=<ticket>`.
+
+### Admin passwords — where they live (never copy values here)
+
+- `dev`, `sandbox`: same as `api2/Config/sandbox-dev.ini` `[database]`.
+- `qa`, `stage`, `uat`, `hotfix`, `demo`: same as `api2/Config/stage.ini` `[database]`.
+- Developer plans to rotate them; after that, the ini files are the source.
+
+### Delete and restore a cluster
+
+1. Always delete with `--final-db-snapshot-identifier final-<name>-<date>`.
+2. To bring it back: `restore-db-cluster-from-snapshot` with the same cluster id → same endpoint, data, and admin password.
+3. Restore creates **no instance**. Run `create-db-instance` for a new writer (`<name>-writer`) or the cluster cannot serve.
+
+### Is a cluster empty? (no DB access needed)
+
+- CloudWatch `AWS/RDS` `VolumeBytesUsed` ~140 MB = MySQL system files only, no TOGA databases.
+- toga-db MCP `list_schemas` returns `[]` for clusters it cannot see, so an empty list alone is not proof.
+
+## Gotchas
+
+- **No KMS rights for `GoAgilant-Developers`** in 975050298201 (`kms:DescribeKey` denied):
+  - `create-db-cluster --manage-master-user-password` fails `KMSKeyNotAccessibleFault ... KMS key [null]` (the Secrets Manager key). Use `--master-user-password` with the RDS key — that works.
+  - Restoring encrypted snapshots in the same account works.
+  - Copying prod snapshots across accounts needs KMS rights the role does not have.
+- **us-west-1 RDS** is blocked for this role by an org SCP.
+- **`api2/Config/stage.ini` is CRLF.** A script reading values from it must strip `\r`, or AWS rejects the password with "Input can't contain control characters".
+- **RDS console "Databases" count** lists each cluster AND its writer instance as rows (19 clusters showed as "38").
+- **Leftovers from the 2026-10-29 cleanup:** 15 deleted clusters (`qa-task`, `qa-hotfix`, `qa-beta`, `qa-gamma`, `qc-task`, `qc-hotfix`, `qc-alpha`, `qc-beta`, `qc-gamma`, `qc-performance`, `client-alpha`, `client-beta`, `client-gamma`, old `stage`, old `demo`) keep final snapshots `final-<name>-2026-10-29` (storage cost; cleanup is a separate task). Their Elastic Beanstalk envs (`api-*`, `worker-*`, `websocket-*`) still exist and point at missing databases — separate ticket.
+
+## Change history
+- 2026-10-29 — First version: 7 new empty env clusters, 15 old clusters deleted, qa-alpha/qc-security restored, KMS limits, recovery steps (TRUE-83406) (rgirish)

package/knowledge/2.0/apps/worker2/features/clickup-github-autolink.md

@@ -6,8 +6,8 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-10-15
-owners: [dfranks, jcardinal]
+updated: 2026-10-29
+owners: [dfranks, jcardinal, mhammontree]
 files: []
 related:
   - ../../../../standalone/apps/claude/workflows/clickup-ticket-workflow.md
@@ -35,9 +35,11 @@ How ClickUp surfaces branches/PRs/commits in a ticket's GitHub tab and the branc
   2. GitHub Settings → "Connect Repositories to Spaces": add each repo AND link it to the **Development** space. A repo not linked to that space never links its PRs.
   3. Repos added 2026-10-08: worker2, dbchanges2, toga25-desk, toga25-iq, toga25-blox, toga25-supply, toga2-commerce, toga2-supply, toga2-template, toga-blox-npm, saml, forward, apiproxy (`test` and `claude` skipped). A PR titled with the ticket id then linked automatically (verified).
 - **Settings:** leave "auto-generated branch name" as `:taskId:`. Do not turn on "Update Task Status from GitHub" — worker2 owns status automation.
+- **A shared branch links its PRs to EVERY ticket it names.** One branch carrying several tickets (e.g. `TRUE-82776` for 82776/82778/82779) shows its PRs on all of them, even tickets whose work is not in it. Before closing a PR because "the ticket shows a PR", check the PR's head branch (2026-10-29, TRUE-82779).
 
 ## Change history
 
+- 2026-10-29 — Gotcha: a shared branch's PRs show on every ticket it names; check the head branch (TRUE-82779). (mhammontree)
 - 2026-10-15 — PR base now follows the ticket's project (Desk/IQ → `toga25`); links to git-workflow.md instead of restating. (jcardinal)
 - 2026-10-08 — Added reconnect fix, Development-space repo linking, and settings to leave alone. (jcardinal)
 - 2026-10-08 — `/work-ticket` and `/plan-ticket` retired; `/finish` opens the PRs. PR title = ticket id first; base = repo default branch; git-workflow now uses bare ticket-id branches. (jcardinal)

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

@@ -578,6 +578,12 @@ instance: [Staples SFTP folder monitors](../../../clients/staples/features/oneup
 `loadImportConfigs()` + `connect()` (CronJobs config + Secrets Manager, one login per account) — see
 [NYCDOE stuck ASN files monitor](../../../clients/nycdoe/features/oneuptime-stuck-asn-files-monitor.md).
 
+**Private-key login** (first in worker2, [NYCDOE EDI 850 queue monitor](../../../clients/nycdoe/features/oneuptime-edi-850-sftp-queue-monitor.md)):
+`$key = PublicKeyLoader::load(_Component_Secrets::resolve($secretRef)); $sftp->login($username, $key);`
+(`phpseclib3\Crypt\PublicKeyLoader`). Store the secret as the **raw PEM in Secrets Manager's Plaintext
+tab** (BEGIN/END lines and line breaks kept) — the default key/value JSON (`{"":""}`) fails every run.
+`_Worker_Sftp_Import::connect()` still has PRIVATE_KEY as a TODO; copy this.
+
 Two runtime facts about the installed phpseclib3 (v3.0.49) that bite silently — verified at runtime
 against the live SFTP:
 
@@ -693,6 +699,7 @@ production deploy.**
 - [OneUptime 1.0 worker uptime monitoring](../../../1.0/apps/worker/features/oneuptime-worker-uptime-monitoring.md) — the 1.0 push-heartbeat predecessor
 
 ## Change history
+- 2026-10-29 — SFTP: first private-key login (raw PEM secret) via NYCDOE `EdiPurchaseOrderSftpQueue` (TRUE-82779). (mhammontree)
 - 2026-10-29 — Gotcha: never run a monitor from local worker2, the hardcoded push URL feeds local numbers into the prod monitor; `CompassSalesOrderTransmission` triage now in the MITS alerting doc (TRUE-83407). (bala)
 - 2026-10-29 — Every OneUptime push retries once (`setAutoRetry`, 1 retry, 2s; `PUSH_RETRY_*` consts on every monitor class); worker1.5 heartbeat too (TRUE-83398). (bala)
 - 2026-10-29 — Gotcha: "stopped reporting" incidents from failed OneUptime pushes (`OneUptime push FAILED.` + `alarm=OK` in `WorkerJobs.output`) and how to tell them from a real outage (TRUE-83380). (bala)

package/knowledge/INDEX.md

@@ -22,8 +22,8 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 
 ## 2.0 framework
 
-- **_underscore** (_Underscore) _(framework core)_ — 118 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
-- **worker2** (Worker) — 102 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
+- **_underscore** (_Underscore) _(framework core)_ — 119 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
+- **worker2** (Worker) — 103 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
 - **api2** (API) — 29 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
 - **dbchanges2** (Database Changes) _(framework core)_ — 24 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
 - **toga2-supply** (TOGa Supply) — 9 doc(s) → [2.0/apps/toga2-supply/INDEX.md](2.0/apps/toga2-supply/INDEX.md)

package/knowledge/clients/nycdoe/INDEX.md

@@ -5,6 +5,7 @@
 | [NYCDOE 2.0 ASN SFTP Ingestion + Parsing (Sftp/Import → Sftp/Parse → Case/ServiceRequest)](features/asn-sftp-ingestion-2-0.md) | 2.0 | 2.0 rewrite of DOE's vendor-SFTP ASN intake (TRUE-80519 Phases 1–2): per-manufacturer fetch to `Files`, header-validated parse into one Case per customer PO + o |
 | [NYCDOE EDI 850 Receive & 997 Acknowledgement](features/edi-850-receive-and-997-ack.md) | 1.0 | DOE's EDI 850-in → NetSuite SO + inline 997-out ack; open for the 997 build, its "always accept" stub, or a DOE ack complaint. |
 | [NYCDOE Ticket Hold-Status Sync (ServiceNow ⇄ TOGaDesk)](features/hold-status-sync.md) | 1.0 | Bidirectional DOE ticket hold-status sync (ServiceNow ⇄ TOGaDesk), the four defects that let holds silently revert or never re-send, the held→complete close clo |
+| [NYCDOE: EDI 850 SFTP queue monitor (Monitor/Nycdoe/EdiPurchaseOrderSftpQueue)](features/oneuptime-edi-850-sftp-queue-monitor.md) | 2.0 | worker2 OneUptime monitor that alarms when a DOE EDI 850 sits 19h+ in `/outbound` on DOE's SFTP (= the 1.0 receiver failed, no SO, no 997); open when it fires o |
 | [NYCDOE: ServiceNow update-rejection monitor (Monitor/Nycdoe/ServiceNowUpdateRejections)](features/oneuptime-servicenow-update-rejections-monitor.md) | 2.0 | worker2 OneUptime monitor that alarms when ServiceNow refuses NYC DOE ticket updates (HTTP 200 with an empty body) in the 1.0 `Logs.API` log; open when it fires |
 | [NYCDOE: stuck ASN files monitor (Monitor/Nycdoe/StuckAsnFiles)](features/oneuptime-stuck-asn-files-monitor.md) | 2.0 | worker2 OneUptime monitor that alarms when any file sits 24h+ on a NYC DOE vendor ASN SFTP folder; open when it fires, when a DOE ASN file is stuck, or when cha |
 | [NYCDOE ServiceNow / ASN Integration](features/servicenow-integration.md) | 1.0 | Full DOE ServiceNow/ASN integration map — ticket mirror, ASN → NetSuite SO/TOGa Desk pipeline, outbound status/POD, EDI; open for any DOE cron/pipeline work or |

package/knowledge/clients/nycdoe/features/edi-850-receive-and-997-ack.md

@@ -6,14 +6,16 @@ project: Worker
 client: nycdoe
 type: client-feature
 status: active
-updated: 2026-09-16
+updated: 2026-10-29
 owners: [mhammontree]
 files:
   - worker/crons/sync/nycdoe/receive_edi_purchase_orders.php
+  - worker/crons/sync/nycdoe/send_edi_open_invoices.php
   - worker/schedules/cron.worker.sync.json
   - library/app/edi.php
 related:
   - servicenow-integration.md
+  - oneuptime-edi-850-sftp-queue-monitor.md
   - ../profile.md
   - ../../../1.0/apps/worker/architecture.md
   - ../../../1.0/apps/library/architecture.md
@@ -23,7 +25,11 @@ DOE's EDI 850-in → NetSuite SO + inline 997-out ack; open for the 997 build, i
 
 ## Summary
 
-DOE sends purchase orders as **EDI 850** files over their SFTP; TOGA turns each into a NetSuite Sales Order and sends back an **EDI 997** functional acknowledgement. There is **no separate 997 cron** — the 997 is built and uploaded inline at the end of the 850 receiver, so anything that aborts the receiver means DOE never gets an ack. Broader DOE ticket + ASN pipeline: [servicenow-integration.md](servicenow-integration.md).
+DOE sends purchase orders as **EDI 850** files over their SFTP; TOGA turns each into a NetSuite Sales Order and sends back an **EDI 997** functional acknowledgement. There is **no separate 997 cron** — the 997 is built and uploaded inline at the end of the 850 receiver, so anything that aborts the receiver means DOE never gets an ack. Broader DOE ticket + ASN pipeline: [servicenow-integration.md](servicenow-integration.md). A stuck 850 is caught by the 2.0 [EDI 850 SFTP queue monitor](oneuptime-edi-850-sftp-queue-monitor.md) (TRUE-82779).
+
+**SFTP folder roles (named from DOE's side — easy to mix up):**
+- `/outbound` = DOE drops 850s here **for us**; the receiver reads it (cron line ~33) and deletes each file after success.
+- `/inbound` = **we** drop 997s and invoices (`send_edi_open_invoices.php`) here for DOE to pick up.
 
 ## How it works
 
@@ -63,6 +69,7 @@ Field mapping (verified against 850 FileLog id 880810):
 ## Related
 
 - [NYCDOE ServiceNow / ASN Integration](servicenow-integration.md)
+- [EDI 850 SFTP queue monitor](oneuptime-edi-850-sftp-queue-monitor.md)
 - [NYC DOE client profile](../profile.md)
 - [Worker (1.0) architecture](../../../1.0/apps/worker/architecture.md)
 - [Library (1.0) architecture](../../../1.0/apps/library/architecture.md)

package/knowledge/clients/nycdoe/features/oneuptime-edi-850-sftp-queue-monitor.md

@@ -0,0 +1,44 @@
+---
+title: "NYCDOE: EDI 850 SFTP queue monitor (Monitor/Nycdoe/EdiPurchaseOrderSftpQueue)"
+framework: "2.0"
+repo: worker2
+project: Worker
+client: nycdoe
+type: client-feature
+status: active
+updated: 2026-10-29
+owners: ["mhammontree"]
+files:
+  - worker2/Worker/Monitor/Nycdoe.php
+  - dbchanges2/Core/2026-10-28a - NYCDOE EDI 850 SFTP Queue Monitor CronJob.sql
+related:
+  - ./edi-850-receive-and-997-ack.md
+  - ./oneuptime-stuck-asn-files-monitor.md
+  - ../../../2.0/apps/worker2/features/oneuptime-worker2-monitoring.md
+  - ../profile.md
+---
+worker2 OneUptime monitor that alarms when a DOE EDI 850 sits 19h+ in `/outbound` on DOE's SFTP (= the 1.0 receiver failed, no SO, no 997); open when it fires or when changing the DOE EDI SFTP login.
+
+## Summary
+`Monitor/Nycdoe/EdiPurchaseOrderSftpQueue(string $host, string $username, string $secretRef, string $remoteDirectory, int $port = 22)` (`_Worker_Monitor_Nycdoe`, TRUE-82779). SFTP-backlog monitor; shared pattern in [OneUptime push-metric monitors](../../../2.0/apps/worker2/features/oneuptime-worker2-monitoring.md#sftp-monitoring-phpseclib3). Watches the folder the 1.0 [EDI 850 receiver](edi-850-receive-and-997-ack.md) empties.
+
+- `Core.CronJobs` uuid `94f6d0ed-a67b-4862-b844-215d3ccc44cf`, `0 * * * *`, `maxExecutionTime` 300, ships `isActive = 0`. `parameters` `{host: transfer.schools.nyc, port: 22, username, secretRef, remoteDirectory: "/outbound"}` — config lives in the row, not PHP.
+- Key: AWS Secrets Manager `sftp/nycdoe/edi` (the `doedimedu.pem` private key). Login: see [private-key SFTP login](../../../2.0/apps/worker2/features/oneuptime-worker2-monitoring.md#sftp-monitoring-phpseclib3).
+- Push URL = in-method `$ONEUPTIME_URL` local (credential; never record the value).
+
+## How it works
+- **Stale rule** (`findStaleFiles(entries, staleFileMinutes, nowEpoch)`, public pure filter for tests): any plain file, hidden included (only `.`/`..` and directories skipped — same as the 1.0 receiver), mtime >= `STALE_EDI_FILE_MINUTES` (1140 = 19h). Constant at the top of the class.
+- **Why 19h:** receiver runs 9:30 and 15:30 and deletes each 850 after the SO + 997; a file landing just after 15:30 waits ~18h normally.
+- **Retry:** 3 tries, 5s apart, per-step timeout min(15s, remaining / 4), floor 5s, 240s deadline. Login refused is not retried.
+- **Body:** `status` (`reporting` / `error`), `alarm` (`HIGH` / `OK`), `staleFileCount`, `staleFileMinutes`, `staleFiles` (max 20: name, ageHours, oldest first), `checkedAtUtc`. Errors: `secret_load_failed`, `sftp_read_failed` (+ `attempts`). SFTP error text is kept only in the `WorkerJobs` return string, never sent to OneUptime.
+- **OneUptime (set up by Mark):** Incoming Request. Offline (Match Any): body contains `"alarm":"HIGH"` OR `"status":"error"` OR no request in 120 min (add after first push). Online (Match All): `"alarm":"OK"` AND not `"status":"error"`.
+
+## Gotchas
+- **When it fires:** the receiver failed for that file — DOE has no SO and no 997. Debug per [EDI 850 receive](edi-850-receive-and-997-ack.md).
+- **`secret_load_failed` keeps only the exception class** — a key parse error can echo key material.
+- **No SFTP host-key pinning** (same as Staples / `Sftp/Import`; CSO rated Low).
+- **Do not run it locally** — no AWS role, so it pushes `status:"error"` and opens a real incident. Test the filter with `test/@Mark/TRUE-82779/test_find_stale_files.php`.
+- **After deploy:** run the Core SQL, set `isActive = 1`, check the first `WorkerJobs` result.
+
+## Change history
+- 2026-10-29 — Created; built, ships inactive (TRUE-82779). (mhammontree)

package/knowledge/clients/nycdoe/features/oneuptime-stuck-asn-files-monitor.md

@@ -6,7 +6,7 @@ project: Worker
 client: nycdoe
 type: client-feature
 status: active
-updated: 2026-10-27
+updated: 2026-10-29
 owners: ["mhammontree"]
 files:
   - worker2/Worker/Monitor/Nycdoe.php
@@ -43,6 +43,7 @@ worker2 OneUptime monitor that alarms when any file sits 24h+ on a NYC DOE vendo
 ### Decisions
 - **SFTP listing is the source of truth, not `Client_Nycdoe.Files`.** 2.0 deletes only after a good parse; `not_matched_kept` files have no `Files` row; a `failed` row goes stale when a same-name file later succeeds (seen: `DOE-CDW-ASN-10-20-2026.csv`). 1.0 `Logs.FileLog` logs each file once in gated mode, so it cannot show wait time.
 - Hourly — "we don't really know when customers plan to upload files" (Mark). Any file name counts (Mark).
+- **TRUE-82778** (`Nycdoe/VendorAsnSftpQueue`, vendor ASN file age) is covered by this monitor — closed as duplicate, nothing built (Mark, 2026-10-27).
 
 ## Gotchas
 - **Known gap:** a same-name re-upload resets mtime, so a file the vendor keeps replacing never alarms.
@@ -51,4 +52,5 @@ worker2 OneUptime monitor that alarms when any file sits 24h+ on a NYC DOE vendo
 - **Do not run it locally once the real URL is in code** — no AWS role on a dev machine, so `_Component_Secrets::resolve()` fails (instance metadata `169.254.169.254`), pushes `status:"error"`, and opens a real incident. Local `Core_2` also has only 1 of 4 `Sftp/Import/Run` rows. Local test: `test/@Mark/TRUE-82941/run_stuck_asn_monitor.php` (read-only listing with the 1.0 library asnprocessor FTP password).
 
 ## Change history
+- 2026-10-29 — TRUE-82778 closed as duplicate of this monitor. (mhammontree)
 - 2026-10-27 — Created; built, ships inactive. `Sftp/Import` `loadImportConfigs()` / `connect()` made public for reuse (TRUE-82941). (mhammontree)

package/knowledge/clients/nycdoe/profile.md

@@ -14,7 +14,7 @@ project: Worker
 client: nycdoe
 type: profile
 status: active
-updated: 2026-10-27
+updated: 2026-10-29
 owners: [mhammontree, sking, bala, rgirish]
 files: []
 related:
@@ -23,6 +23,7 @@ related:
   - features/asn-sftp-ingestion-2-0.md
   - features/oneuptime-servicenow-update-rejections-monitor.md
   - features/oneuptime-stuck-asn-files-monitor.md
+  - features/oneuptime-edi-850-sftp-queue-monitor.md
 ---
 
 NYC DOE client profile (1.0 worker tier live; 2.0 ASN rewrite in progress), ServiceNow + EDI; open for DOE's platform scope, endpoints, API clients, and where its ticket/ASN/EDI logic lives.
@@ -32,7 +33,7 @@ NYC DOE — TOGA client whose **live** integration runs in the **1.0 worker tier
 
 ## Platforms & data
 - **1.0 worker tier** — all live business logic. Local mirror tables in `db_common` (`NYCDOETickets`, `NYCDOELocations`, `AdvanceShippingNotice*`).
-- **2.0 (`worker2` + `_underscore` + `dbchanges2`, tenant `Client_Nycdoe`)** — (1) the OneUptime liveness probe `Monitor/Nycdoe/ServiceNowEndpointHealth` (`worker2/Worker/Monitor/Nycdoe.php`, TRUE-80587, live) the [ServiceNow update-rejection monitor](features/oneuptime-servicenow-update-rejections-monitor.md) (TRUE-82776, ships inactive), and the [stuck ASN files monitor](features/oneuptime-stuck-asn-files-monitor.md) (TRUE-82941, ships inactive); (2) the ASN rewrite `Sftp/Import` → `Sftp/Parse` → Case/ServiceRequest (Phases 1–2; gated delete live in prod since ~2026-10-11, scheduled crons still off) — see [2.0 ASN SFTP Ingestion](features/asn-sftp-ingestion-2-0.md). Entity map: `Case` = 1.0 managed_service_order, `ServiceRequest` = 1.0 repair_order; DOE does not use `Ticket`. Client models: `_underscore/Model/Nycdoe/`. 2.0 does **not** write to ServiceNow yet — the 1.0 RITM/POD crons keep sending until 2.0 takes over, then 1.0 is turned off.
+- **2.0 (`worker2` + `_underscore` + `dbchanges2`, tenant `Client_Nycdoe`)** — (1) the OneUptime liveness probe `Monitor/Nycdoe/ServiceNowEndpointHealth` (`worker2/Worker/Monitor/Nycdoe.php`, TRUE-80587, live) the [ServiceNow update-rejection monitor](features/oneuptime-servicenow-update-rejections-monitor.md) (TRUE-82776, ships inactive), the [stuck ASN files monitor](features/oneuptime-stuck-asn-files-monitor.md) (TRUE-82941, ships inactive), and the [EDI 850 SFTP queue monitor](features/oneuptime-edi-850-sftp-queue-monitor.md) (TRUE-82779, ships inactive); (2) the ASN rewrite `Sftp/Import` → `Sftp/Parse` → Case/ServiceRequest (Phases 1–2; gated delete live in prod since ~2026-10-11, scheduled crons still off) — see [2.0 ASN SFTP Ingestion](features/asn-sftp-ingestion-2-0.md). Entity map: `Case` = 1.0 managed_service_order, `ServiceRequest` = 1.0 repair_order; DOE does not use `Ticket`. Client models: `_underscore/Model/Nycdoe/`. 2.0 does **not** write to ServiceNow yet — the 1.0 RITM/POD crons keep sending until 2.0 takes over, then 1.0 is turned off.
 - **TOGa Desk:** DOE is client id **16** (`db_togadesk`) — repair orders, managed service orders, the "#received / #ordered" Receiving Summary UI.
 - **NetSuite:** Sales Orders, PO reconciliation, item receipts, Item Fulfillments, invoices (SuiteTalk toolkit in `library`).
 - **`dbchanges` (1.0):** DOE schema + **data-repair** changes ship here (`dbchanges/Core/` targets the legacy/V1 `Core` schema). Stranded-ASN recoveries are data-only repairs — see the [1.0 dbchanges authoring workflow](../../1.0/apps/dbchanges/workflows/authoring-and-shipping-sql-files.md).

package/knowledge/clients/nychh/profile.md

@@ -20,7 +20,7 @@ project: _Underscore
 client: nychh
 type: profile
 status: active
-updated: 2026-10-22
+updated: 2026-10-29
 owners: [jcardinal, apeterson, bala, akhokhani, mhammontree, rgirish]
 files:
   - dbchanges2/Client_Nychh/2026-10-18a - NewYorkWarehouseLocation.sql
@@ -128,7 +128,7 @@ TOGA 2.0 client on `_underscore`, prod schema `Client_Nychh`. Supply-chain / ful
 - **PO links are UPSTREAM (`PurchaseOrders_SalesOrders`), not downstream.** The downstream `sales-order-purchase-orders` route returns an empty array for NYCHH by design, and the shared `_purchaseOrders` field (downstream-only) resolves to `null` for this tenant — open gap. See [PO Number direction](./features/po-number-upstream-direction.md).
 
 ## Notes
-- **1.0 cron "Send NYCHH Sales Orders" sends nothing (2026-10-15, TRUE-82761, parked).** `worker/crons/toga2/nychh/send_sales_order.php` (`*/5`) emails each `SalesOrders` row with `c_dtTransmittedToNYCHH IS NULL` as an xlsx to the warehouse. In prod all 125 rows have it NULL and none has `createdByUserId` (all NetSuite-imported), so its `INNER JOIN Users ON createdByUserId` drops every row. Supply orders are now `TransferOrders`. A monitor on that column would be always HIGH or always OK — don't build one. Open: ask Jelena if the transmission is still used.
+- **1.0 cron "Send NYCHH Sales Orders" sends nothing (2026-10-15, TRUE-82761, parked).** `worker/crons/toga2/nychh/send_sales_order.php` (`*/5`) emails each `SalesOrders` row with `c_dtTransmittedToNYCHH IS NULL` as an xlsx to the warehouse. In prod all 125 rows have it NULL and none has `createdByUserId` (all NetSuite-imported), so its `INNER JOIN Users ON createdByUserId` drops every row. Supply orders are now `TransferOrders`. A monitor on that column would be always HIGH or always OK — don't build one. Open: is the transmission still used? Owner unknown — Jelena has left TOGA Technology (2026-10-29).
 - **`Items.title` is NULL on most NYCHH rows — `description` is the populated label field.** Confirmed 2026-09-03 on client-sandbox (a `transfer-order-items` line returned `"title": null` with a real `partNumber`). Every screen that labels an item for this tenant needs the `title || description` chain — the Transfer Order record modal and the Create modal's item picker both carry it. The real fix is populating `Items.title`.
 - **Role ids in `Client_Nychh` (verified 2026-09-01):** `1 = Base`, `2 = Developer`, `3 = API`. Role ids differ per client DB — resolve by **name** in migrations, never hard-code these.
 - **The Agilant API (`Client_Nychh.Apis` id 1) holds BOTH Base (1) and API (3) via `Apis_Roles` (2026-10-06).** Record ACL = union, so checking only the API role misleads. Base grants full CRUD on 28/312/313 (ItemFulfillments, TransferOrders, TransferOrderItems); API role has no DELETE on 312/313 and no row for 28. Interceptors: record 312 has POST/POST + POST/PUT only (none on DELETE).

package/package.json

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