toga-ai 1.0.393 → 1.0.394

package/knowledge/2.0/apps/dbchanges2/architecture.md

@@ -6,7 +6,7 @@ project: Database Changes
 client: shared
 type: architecture
 status: active
-updated: 2026-07-20
+updated: 2026-07-21
 owners: [jcardinal, mhammontree, bala]
 files:
   - Core/
@@ -173,6 +173,13 @@ its own header.)
    the relevant clients list `<module>` in their `_modules.txt`.
 5. Never edit or re-date an already-applied file — add a new dated file instead. Never put new
    work in a `HISTORIC` folder.
+6. **Never seed a `uuid` column with MySQL `UUID()`.** The 2.0 standard requires a fully-random
+   **v4** UUID; `UUID()` is time/MAC-based (v1) and violates it. Since a migration can't call
+   `_String::generateUuid()`, **pre-generate a v4 UUID literal** (e.g. a v4 generator) and
+   hardcode the literal string in the `VALUES` clause. One earlier migration
+   (`Core/2026-05-08 … CronJobs_WorkerCleanup_insert`) used `UUID()` — that is a known violation,
+   not a precedent to copy. First applied correctly in
+   `Core/2026-07-21b - Insert - SprintLockScheduled CronJob.sql`.
 
 ## Bulk data loads — batch, and stage large sets in a temp table
 
@@ -285,3 +292,10 @@ platform-wide infrastructure, not a single application. It has no code dependenc
 folder names mirror the DB families (`Core`, `Logs`, `Client_<Tenant>`, `Logs_<Tenant>`)
 defined in `2.0/apps/_underscore/architecture.md`, and its change files create/alter the
 tables that `_Model_*` classes map to.
+
+## Change history
+- 2026-07-21 — Added rule #6 to *Adding a new change*: never seed a `uuid` column with MySQL
+  `UUID()` (time/MAC-based v1, violates the 2.0 v4-UUID standard); pre-generate a v4 UUID
+  literal and hardcode it in `VALUES`. `Core/2026-05-08 … CronJobs_WorkerCleanup_insert` is a
+  known violation, not a precedent; first applied correctly in
+  `Core/2026-07-21b - Insert - SprintLockScheduled CronJob.sql`. (jcardinal)

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

@@ -28,7 +28,7 @@
 | [Talos (TOGa IQ) Meeting-Notes Integration & Token Auto-Refresh (consumer)](features/talos-meeting-notes-integration.md) | How a **dev tool / agent consumes Talos (TOGa IQ)** to query the team meeting-notes corpus programmatically. | .claude/skills/plan-ticket/scripts/talos.js |
 | [Talos Pricing Automation (worker2 Cron — AWS Actuals, Calibration, Monthly Report)](features/talos-pricing-automation.md) | The worker2 half of the **Talos Pricing Platform** (see the talos `pricing-cogs-model` and tools `talos-pricing-ui` docs for the other halves). | worker2/Worker/Talos/Pricing.php, worker2/Database/TalosPricingCrons.sql |
 | [Talos Transcript Ingestion Pipeline (worker2 → AWS Bedrock KBs)](features/talos-transcript-ingestion.md) | `_Worker_Team_Transcripts` runs a fully automated, cron-driven pipeline that ingests raw Teams transcripts into the **Talos / TOGa IQ** AWS Bedrock knowledge ba | worker2/Worker/Team/Transcripts.php, worker2/bin/sync-knowledge-bases.php, worker2/Config/production.ini, worker2/Database/TeamsTranscriptExports.sql, dbchanges2/Team/2026-06-30a, dbchanges2/Team/2026-06-30b, dbchanges2/Team/2026-06-30c, dbchanges2/Team/2026-06-30d, dbchanges2/Team/2026-06-30e, dbchanges2/Core/2026-06-30a, dbchanges2/Core/2026-07-02a, dbchanges2/Team/2026-07-02a, dbchanges2/Team/2026-07-08a, dbchanges2/Team/2026-07-09a, dbchanges2/Team/2026-07-10a |
-| [Team Sprint Management & Reporting](features/team-sprint-management.md) | `_Worker_Team_Sprint` (file `Worker/Team/Sprint.php`) is the engine behind TOGA's internal **development-sprint process and reporting**. | worker2/Worker/Team/Sprint.php |
+| [Team Sprint Management & Reporting](features/team-sprint-management.md) | `_Worker_Team_Sprint` (file `Worker/Team/Sprint.php`) is the engine behind TOGA's internal **development-sprint process and reporting**. | worker2/Worker/Team/Sprint.php, dbchanges2/Core/CronJobs (SprintLockScheduled seed) |
 | [Teams Meeting Transcript Export](features/teams-transcript-export.md) | > **SUPERSEDED (2026-07-09) — the S3-staging model below is history.** `Export` is now a thin > **GRAPH-DIRECT** cron poller: it no longer archives raw VTT to ` | worker2/Worker/Team/Transcripts.php, worker2/Config/production.ini, worker2/Database/TeamsTranscriptExports.sql, dbchanges2/Core/2026-06-18a - Teams Transcript Export schedule.sql |
 | [VAPI Webhook Handler (worker2 — AI-BDR end-of-call processing)](features/vapi-webhook-handler.md) | `_Worker_Vapi` ([worker2/Worker/Vapi.php](worker2/Worker/Vapi.php)) is the **PHP side of the AI-BDR call loop** — the webhook that receives VAPI's end-of-call r | worker2/Worker/Vapi.php, worker2/Worker/Ai/Bdr/Vapi.php |
 | [WJE Freshservice Sync (worker2)](features/wje-freshservice-sync.md) | WJE ("WJE IT", helpdesk `wje.freshservice.com`) is a **Freshservice**-based help-desk client whose tickets, contacts, assets, groups, categories, and canned res | worker2/Worker/Wje.php, _underscore/Component/Api/Wje/Wje.php, _underscore/Model/Wje/Ticket.php, _underscore/Model/Wje/TicketNote.php, _underscore/Model/Wje/Contact.php, _underscore/Model/Wje/Unit.php, _underscore/Model/Wje/TicketTeam.php, _underscore/Model/Wje/TicketCategory.php, _underscore/Model/Wje/AssetType.php, _underscore/Model/Wje/PredefinedReply.php, library/app/api/wje.php, worker/crons/toga2/wje/import_supporting_records.php, worker/crons/toga2/wje/sync_togasupply_wje.php, worker/crons/notifications/reports/wje/wje_common.php, library/app/systemmonitor/wje.php, dbchanges2/Client_Wje/2024-10-04 - WjeOnboarding.sql |

package/knowledge/2.0/apps/worker2/features/creating-worker-actions.md

@@ -111,11 +111,29 @@ No Lambda/routing changes — just create the file:
 2. Insert a `Core.CronJobs` row:
    ```sql
    INSERT INTO Core.CronJobs (uuid, isActive, name, schedule, maxExecutionTime, action, parameters)
-   VALUES (UUID(), 1, 'Daily Report Generation', '0 6 * * *', 300, 'Reports/Daily/Generate', NULL);
+   VALUES ('xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx', 1, 'Daily Report Generation', '0 6 * * *', 300, 'Reports/Daily/Generate', NULL);
+   -- uuid MUST be a pre-generated v4 UUID literal, NOT MySQL UUID() (v1) — see dbchanges2 architecture.md rule #6
    ```
    `schedule` is evaluated in **Central time**; `maxExecutionTime` is the watchdog timeout.
 3. CronScheduler fires it at the next matching minute — no code wiring needed.
 
+Adding a recurring job is **pure data**: inserting the `Core.CronJobs` row (uuid, isActive,
+name, schedule, maxExecutionTime, action, parameters) is all that's needed. The CronScheduler
+Lambda runs every minute, matches active schedules via `croniter`, and enqueues a `WorkerJobs`
+job. There is **no Lambda/code change** beyond the row — but the referenced `action` must exist
+in the deployed worker code, so ship the code deploy and the dbchanges2 cron-row migration
+**together**.
+
+> **Biweekly / non-cron schedules — run often, self-gate in PHP.** Cron (5-field) can express
+> "every Wednesday" but **not** "every *other* Wednesday" (or any period cron can't name).
+> Don't try to encode it in the schedule. Instead schedule the job at the coarser recurring
+> interval it fits (e.g. `0 10 * * 3`) and have the action **self-gate against a date/state
+> table** at the top of the method — run the real work only when the gate says today qualifies,
+> otherwise return a skip message (captured to `Core.WorkerJobs.output`). Proven by
+> `Team/Sprint/SprintLockScheduled`, which fires every Wednesday but only runs `SprintLock()`
+> when a `Sprints` row ends yesterday — see
+> [team-sprint-management](./team-sprint-management.md).
+
 ## Test any action directly
 
 ```bash
@@ -175,6 +193,12 @@ be reattempted.
   commit-before-SQS transaction pattern that the worker relies on.
 
 ## Change history
+- 2026-07-21 — Documented that adding a recurring job is **pure data** (a `Core.CronJobs` row;
+  CronScheduler Lambda matches via croniter every minute, no code wiring beyond the row — but
+  the action must be deployed), and the **biweekly self-gating pattern**: for schedules cron
+  can't express (e.g. every-other-Wednesday), run at a coarser cron interval and gate in PHP
+  against a date/state table, returning a skip otherwise. Proven by
+  `Team/Sprint/SprintLockScheduled`. (jcardinal)
 - 2026-07-21 — `WorkerJobs.failureReason` column renamed to **`output`** and repurposed to store
   successful execution results as well as failure text; success now writes the composed
   "Successfully Executed" message (return value `json_encode`d for arrays/objects). (jcardinal)

package/knowledge/2.0/apps/worker2/features/team-sprint-management.md

@@ -6,10 +6,11 @@ project: Worker
 client: shared
 type: feature
 status: active
-updated: 2026-06-24
+updated: 2026-07-21
 owners: ["jcardinal"]
 files:
   - worker2/Worker/Team/Sprint.php
+  - dbchanges2/Core/CronJobs (SprintLockScheduled seed)
 related:
   - ../architecture.md
   - ./creating-worker-actions.md
@@ -64,6 +65,10 @@ A sprint runs ~14 days. Across the cycle these actions fire (scheduled as crons)
 2. **~9:00 AM** — `SprintEnd` captures and scores the just-finished sprint, emails reports,
    and (optionally) sends release notes.
 3. **~9:45 AM (after launch ceremony)** — `SprintLock` freezes the new sprint's plan.
+   In production this is now invoked via the scheduled self-gating wrapper
+   `SprintLockScheduled` (see below), not by a cron that targets `SprintLock` directly —
+   because the launch day is **every other Wednesday** and cron cannot express a biweekly
+   schedule.
 4. **Daily during the sprint** — `SprintDaily` emails leadership a progress dashboard.
 
 Most methods accept an optional `$sprint` number; when omitted they resolve the relevant
@@ -89,6 +94,21 @@ alert. With `$generateSprintLockReport`, emits an Excel lock report of committed
 unplanned/stretch points and tasks. When `$allowUnplannedTasks` is false, tasks appearing
 after lock with an UNPLANNED work type are flagged.
 
+### `SprintLockScheduled(): string`
+A thin **scheduled wrapper around `SprintLock()`** that solves the biweekly-schedule problem.
+The launch/lock ceremony runs every *other* Wednesday, but cron has no biweekly expression, so
+its `CronJobs` row fires **every** Wednesday (`0 10 * * 3`, 10:00 AM Central) and this method
+**self-gates in PHP** against the `Sprints` table: it queries for a sprint whose `dateEnd` =
+**yesterday**. If one exists, today is a new-sprint start day → it calls `self::SprintLock()`.
+Otherwise it returns a skip message (captured to `Core.WorkerJobs.output`) and does nothing.
+`SprintLock()` itself is unchanged — this only decides *whether* to run it today. Action path
+`Team/Sprint/SprintLockScheduled` → `_Worker_Team_Sprint::SprintLockScheduled`.
+
+> **Deploy coupling.** The worker2 code deploy and the dbchanges2 migration that seeds the
+> `Core.CronJobs` row must be **released together** — the cron row references the
+> `Team/Sprint/SprintLockScheduled` action, which must exist in the deployed code or the
+> scheduled job fails when it fires.
+
 ### `SprintDaily($sprint = null, …)`
 In-sprint **leadership dashboard**, read-only with respect to metrics. Optionally re-captures
 ClickUp data, then builds a multi-sheet workbook:
@@ -210,6 +230,13 @@ backfills `workTypeAtLock` the first time a task is seen).
 
 ## Change history
 
+- 2026-07-21 — Added `SprintLockScheduled()` action + a `Core.CronJobs` seed
+  (`0 10 * * 3`, every Wednesday 10 AM Central, action `Team/Sprint/SprintLockScheduled`,
+  maxExecutionTime 600) to run **Sprint Lock automatically at the start of each biweekly
+  sprint**. Cron can't express "every other Wednesday", so the job runs every Wednesday and
+  self-gates in PHP: it calls the unchanged `SprintLock()` only when a `Sprints` row has
+  `dateEnd = yesterday` (i.e. today starts a new sprint), else returns a skip. Worker code and
+  the dbchanges2 cron-row migration must deploy together. (jcardinal)
 - 2026-06-24 — Fixed a duplicate-key crash (`Tasks.sprintId_clickupIdentifier`) in the
   ClickUp→DB sync: ClickUp pagination can return the same task on multiple pages, and the
   loop was overloading one map (`$lookupTaskByClickUpId`) for both update-vs-insert and

package/package.json

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