toga-ai 1.0.139 → 1.0.141

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

@@ -9,4 +9,4 @@
 | [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/Notification/Email.php, dbchanges2/Core/2026-05-21 - Monitors.sql |
 | [NetSuite → TOGA Opportunity Sync (API Message Queue + worker2 webhook)](features/netsuite-opportunity-sync.md) | Outbound sync from NetSuite to TOGA for the record types the Forecast2 importer pulls (opportunities first; sales/items/etc. | worker2/Worker/Netsuite.php, worker2/Worker/Netsuite/Opportunity.php, worker2/Controller/Index.php, _underscore/Worker.php, test/@dave/NetSuite/api-message-queue/lib_amq_queue.js, test/@dave/NetSuite/api-message-queue/ue_api_msg_queue_enqueue.js, test/@dave/NetSuite/api-message-queue/ue_amq_drain.js, test/@dave/NetSuite/api-message-queue/ss_amq_drain.js, test/@dave/NetSuite/api-message-queue/DEPLOY_RUNBOOK.md, test/@dave/clickup/backfill_opportunity_numbers.php, test/@dave/clickup/probe_opportunity_fields.php, test/@dave/probe_clickup_desc_match.php, worker/crons/toga2/forecast2/common_import_sales_from_netsuite.php |
 | [NetSuite → Forecast Open-Orders Sync (salesOrder webhook → OpenOrderItems)](features/netsuite-salesorder-open-orders-sync.md) | Webhook-driven, single-record port of the legacy open-orders importer (TRUE-79142). | worker2/Worker/Netsuite/SalesOrder.php, worker2/Worker/Netsuite.php, test/@dave/probe_salesorder_rest_shape.php, test/@dave/probe_open_order_lines.php, test/@dave/check_so_status.php, test/@dave/check_so_history.php, test/@dave/probe_so_rest_lines.php, worker/crons/toga2/forecast2/import_open_orders.php, worker/crons/toga2/forecast2/common_import_sales_from_netsuite.php |
-| [Teams Meeting Transcript Export](features/teams-transcript-export.md) | `_Worker_Team_Transcripts` (action `Team/Transcripts/Export`) polls Microsoft Graph for Teams meeting transcripts produced by a set of organizers, classifies ea | worker2/Worker/Team/Transcripts.php, worker2/Config/production.ini |
+| [Teams Meeting Transcript Export](features/teams-transcript-export.md) | `_Worker_Team_Transcripts` (action `Team/Transcripts/Export`) polls Microsoft Graph for Teams meeting transcripts produced by a set of organizers, classifies ea | worker2/Worker/Team/Transcripts.php, worker2/Config/production.ini, worker2/Database/TeamsTranscriptExports.sql, dbchanges2/Core/2026-06-18a - Teams Transcript Export schedule.sql |

package/knowledge/2.0/apps/worker2/features/teams-transcript-export.md

@@ -6,11 +6,13 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-06-12
+updated: 2026-06-18
 owners: ["ajean"]
 files:
   - worker2/Worker/Team/Transcripts.php
   - worker2/Config/production.ini
+  - worker2/Database/TeamsTranscriptExports.sql
+  - dbchanges2/Core/2026-06-18a - Teams Transcript Export schedule.sql
 related:
   - ../architecture.md
   - ./creating-worker-actions.md
@@ -20,8 +22,9 @@ related:
 
 `_Worker_Team_Transcripts` (action `Team/Transcripts/Export`) polls Microsoft Graph for
 Teams meeting transcripts produced by a set of organizers, classifies each meeting by
-client (from the meeting title), and archives the raw WebVTT to S3. Scheduled via three
-`Core.CronJobs` rows (weekdays 10:00 / 13:00 / 17:30 Central).
+client (from the meeting title), and archives the raw WebVTT to S3. Scheduled via a single
+`Core.CronJobs` row firing weekdays at 9:30 / 11:30 / 13:30 / 14:30 / 15:30 / 16:30 / 17:30
+Central (`30 9,11,13,14,15,16,17 * * 1-5`).
 
 ## Key files / entry points
 
@@ -29,6 +32,9 @@ client (from the meeting title), and archives the raw WebVTT to S3. Scheduled vi
 - `Config/production.ini` `[teams]` section — Entra app creds, organizer source, S3 target.
 - `[teamsClientAliases]` config section — alias → canonical client name for classification.
 - Ledger table `Team.TranscriptExports` (DB alias `_underscore::DB_TEAM`, core cluster).
+- `Backfill(bool $dryRun = true, int $limit = 0)` — re-files already-misdated S3 objects (see *Gotchas*).
+- DDL + cron seed: `worker2/Database/TeamsTranscriptExports.sql`; prod schedule change:
+  `dbchanges2/Core/2026-06-18a - Teams Transcript Export schedule.sql`.
 
 ## How it works
 
@@ -51,9 +57,17 @@ Per run, after acquiring a Graph client-credentials token:
 3. `getAllTranscripts(meetingOrganizerUserId='{guid}', startDateTime, endDateTime)`
    over an incremental window (`MAX(dtCreated)` watermark from the ledger, else `now − lookbackDays`),
    following `@odata.nextLink`.
-4. Per new transcript (dedup by `transcriptIdentifier`): fetch meeting `subject`+`startDateTime`
-   (cached per meeting), classify, download VTT (`?$format=text/vtt`), `putObject` to S3, insert
-   ledger row.
+4. Per new transcript (dedup by `transcriptIdentifier`): fetch meeting `subject` (cached per
+   meeting) for classification, classify, download VTT (`?$format=text/vtt`), `putObject` to S3,
+   insert ledger row.
+
+**Archive date source (important):** the S3 path date and `dtMeeting` come from the
+transcript's own **`createdDateTime`**, NOT the meeting's `startDateTime`. For a recurring
+meeting, `getMeeting()` (`onlineMeetings/{id}`) returns the **series-anchor** start (the first
+occurrence), so `startDateTime` misfiles every occurrence under one frozen — sometimes future —
+date. `createdDateTime` is stamped minutes after the actual occurrence, so it dates the archive
+correctly. `getMeeting()` is therefore used only for the subject. `dtExported` uses
+`UTC_TIMESTAMP()` (not `NOW()`) so all three timestamps are UTC.
 
 **Classification:** case-insensitive substring match of the meeting title against active
 `Core.Clients` names + `[teamsClientAliases]`, longest needle wins, min length 3. No match → `general`.
@@ -88,6 +102,30 @@ process is identical for all.
 
 ## Gotchas / known issues
 
+- **Recurring meetings return the SERIES-ANCHOR `startDateTime`.** Graph's
+  `onlineMeetings/{id}` gives the first-occurrence (or even a future) start for a recurring
+  series, not the occurrence that was recorded. Driving the archive date off it misfiled every
+  occurrence under one frozen date and produced future-dated folders (e.g. a 6-17 occurrence
+  filed under `…/2026-06-03/…`; a "Rebranding Weekly Sync" under `2026-06-19/`). Fixed by
+  dating off the transcript's `createdDateTime`. The transcript object does **not** carry the
+  occurrence start, so `createdDateTime` (≈ minutes after the meeting) is the best reliable
+  signal. The `Backfill()` action re-files objects already written under the wrong date:
+  recomputes the correct key purely from ledger columns (no Graph calls), `copyObject` →
+  `deleteObject` (idempotent — `NoSuchKey` + `doesObjectExist` treats an already-moved row as a
+  no-op), then updates `s3Key` + `dtMeeting`. Run `dryRun:true` first, inspect `sample[]`, then
+  `dryRun:false` (optional `limit` for a first batch). `$limit` caps candidates touched, not
+  rows scanned, so a run of failures stops at `$limit` instead of sweeping the table.
+  **`Backfill()` recomputes the WHOLE key, not just the date.** Rows written by an earlier
+  `buildS3Key` produce a different `shortId`/time even when the date was already right, so a
+  full table run flags every row (the 2026-06-18 run moved 61/66 for this reason) and renames
+  those files. Acceptable as a one-off — the ledger `s3Key` is updated to match — but if you
+  ever need a minimal re-file, change the move test to compare only the `YYYY-MM-DD` folder
+  segment and relocate while preserving the original filename.
+- **Cron rows cannot be `DELETE`d once they have fired.** `Core.WorkerJobs.cronJobId` has a FK
+  (`WorkerJobs_CronJobs_FK`) to `CronJobs.id`, so a schedule change must `UPDATE` an existing
+  row (and set `isActive = 0` on the ones being retired), not delete-and-reinsert. The historical
+  `WorkerJobs` rows are preserved.
+
 - **`getAllTranscripts` requires an AAD object-id (GUID), NOT a UPN.** Passing a UPN
   (e.g. `ajean@togatech.com`) returns the opaque `HTTP 400 BadRequest / "UnknownError"`.
   This is the single most likely cause of an export failure.
@@ -124,6 +162,12 @@ Policy gap; a `400` only on a UPN means the id was never resolved to a GUID. (A
 
 ## Change history
 
+- 2026-06-18 — Fixed recurring-meeting date misfiling: archive date + `dtMeeting` now come from
+  the transcript `createdDateTime`, not the series-anchor `meeting->startDateTime` (worker2 PR
+  #82, merged + deployed). Added `Backfill()` and ran it in prod (61/66 objects re-filed, 0
+  errors). `dtExported` → `UTC_TIMESTAMP()`. Rescheduled to weekdays 9:30–17:30 CT via a single
+  consolidated cron row, applied by UPDATE+deactivate (DELETE blocked by the WorkerJobs FK) —
+  dbchanges2 PR #398, merged + applied. (ajean)
 - 2026-06-12 — **Merged (PR #78) and verified in production**: a real `Team/Transcripts/Export`
   run returned 6/6 organizers, 33 found, 33 exported, 0 errors (classified 30 general / 3 Elite).
   Added fail-fast on unresolvable organizers (`resolveUserId` → null, loop throws clear error

package/package.json

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