toga-ai 1.0.532 → 1.0.533

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

@@ -20,6 +20,7 @@ related:
   - ./mvc-data-access-patterns.md
   - ../../../2.0/apps/_underscore/features/error-reporting-issue-event.md
   - ../../../2.0/apps/worker2/features/error-escalation-cron.md
+  - ../../../2.0/apps/worker2/features/error-issue-auto-resolution.md
   - ../../library/features/error-capture-1-0.md
 ---
 
@@ -183,6 +184,20 @@ second line — the two halves then read as unrelated fragments. It is now `disp
 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.
 
+### Issue status: Resolved vs. Closed (2026-08-05)
+
+Both pages surface the new Issue-level **OPEN → RESOLVED** lifecycle (owned by the worker2
+frequency-decay cron — see
+[error-issue-auto-resolution](../../../2.0/apps/worker2/features/error-issue-auto-resolution.md)):
+
+- An **Open / Resolved / All** status filter (**default Open**; the submitted value is
+  **allowlisted** before it reaches the query).
+- A **Resolved badge** on the listing rows and the detail header.
+- A **`dtAutoResolved`** fact row on the detail page.
+- **⚠ The ClickUp-episodes table column "Resolved" was renamed to "Closed"** to break the naming
+  collision. In this console an **episode** is *Closed* (`IssueClickupTask.dtResolved`); an
+  **Issue** is *Resolved* (`Issue.status` / `dtAutoResolved`). Keep the two labels distinct.
+
 ### Table presentation rules (established 2026-08-04)
 
 **Stacked datetimes in every table on both pages** — listing *Last seen*; detail *Events → When*,
@@ -297,6 +312,13 @@ They were renamed from plural on 2026-08-01, after the pipeline was already in p
 
 ## Change history
 
+- 2026-08-05 — **Built:** the `/errors` console surfaces the new Issue-level RESOLVED lifecycle —
+  an **Open/Resolved/All** status filter (default Open, allowlisted value), a **Resolved badge**
+  (listing + detail header), a **`dtAutoResolved`** fact row, and the ClickUp-episodes column
+  header renamed **"Resolved" → "Closed"** to break the collision with the new Issue-level status
+  (an *episode* is Closed; an *Issue* is Resolved). Lifecycle behaviour is owned by the worker2 cron
+  ([error-issue-auto-resolution](../../../2.0/apps/worker2/features/error-issue-auto-resolution.md)).
+  (jcardinal)
 - 2026-08-04 (latest, **uncommitted/undeployed**; CSS/markup/nav only — no PHP logic, schema or
   worker change) — **Fixed:** the context cards were too narrow and too short. `.context-card-body`
   `max-height` 340px → 510px, and the grid's `repeat(auto-fit, minmax(320px, 1fr))` (five columns on

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

@@ -29,6 +29,7 @@ related:
   - ./per-client-database-connections.md
   - ./email-send-pipeline.md
   - ../../worker2/features/error-escalation-cron.md
+  - ../../worker2/features/error-issue-auto-resolution.md
   - ../../../1.0/apps/tools/features/errors-curation-console.md
   - ../../../1.0/apps/library/features/error-capture-1-0.md
   - ../../api2/features/v2-api-error-codes.md
@@ -77,6 +78,24 @@ Issue itself. Anything that reads like "this client's issue" is a modelling erro
 
 `IssueEmailAddresses.clientId = 0` means **all clients**.
 
+### Issue-level lifecycle columns (added 2026-08-05)
+
+`Issue` carries an **OPEN → RESOLVED** lifecycle written only by the worker2 frequency-decay cron:
+`status enum('OPEN','RESOLVED')`, `dtAutoResolved`, and a durable firing baseline
+(`baselineGapSeconds`, `baselineSampleCount`, `dtBaselineAnchor`, `baselineAnchorOccurrences`) —
+migration `dbchanges2/Logs/2026-08-05a`. Full behaviour lives in
+[error-issue-auto-resolution](../../worker2/features/error-issue-auto-resolution.md). Two identity
+rules matter from the data-model side:
+
+> **⚠ `Issue.dtAutoResolved` is deliberately NOT named `dtResolved`.** `dtResolved` already means
+> the **episode**-level `IssueClickupTask.dtResolved`; a same-named `Issue` column would invite a
+> wrong join between the Issue lifecycle and an episode close. Keep the two levels distinct — an
+> **episode** closes on every ClickUp completion; an **Issue** resolves only when firing stops.
+>
+> **⚠ Never maintain the baseline scalars from the capture path** (`_underscore/Error.php` or the
+> mirrored `library/app/error/capture.php`) — they are owned by the cron, because `Event` purges at
+> 7 days but a low-frequency Issue's baseline must persist for months.
+
 ## How it works
 
 ### Fingerprinting (identity)
@@ -520,6 +539,14 @@ clientUserId). **Neither was built.** As built instead:
 
 ## Change history
 
+- 2026-08-05 — **Data model:** `Issue` gained an Issue-level **OPEN → RESOLVED** lifecycle
+  (`status`, `dtAutoResolved`) plus a durable firing baseline (`baselineGapSeconds`,
+  `baselineSampleCount`, `dtBaselineAnchor`, `baselineAnchorOccurrences`), migration
+  `dbchanges2/Logs/2026-08-05a`. Recorded the two identity rules: `dtAutoResolved` is **not**
+  `dtResolved` (that token is the episode-level `IssueClickupTask.dtResolved`), and the baseline
+  scalars are cron-owned — **never** written from the capture path, since `Event` purges at 7 days
+  while the baseline must persist for months. Behaviour lives in
+  [error-issue-auto-resolution](../../worker2/features/error-issue-auto-resolution.md). (jcardinal)
 - 2026-08-04 (latest, **uncommitted/undeployed** at time of writing) — **DECISION REVERSED:
   `$GLOBALS` IS now captured**, as a new top-level `GLOBALS` group, in both frameworks. The earlier
   entry recording that `$GLOBALS` would deliberately never be captured is **superseded and has been

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

@@ -19,6 +19,7 @@
 | [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, dbchanges2/Core/2026-08-04a - Error neglect digest cron job.sql |
+| [Error-Issue Auto-Resolution & Reopen (frequency-decay lifecycle)](features/error-issue-auto-resolution.md) | The error system could escalate and de-escalate an Issue's *urgency* but had no concept of an Issue being **resolved**. | worker2/Worker/Infrastructure/Errors.php, worker2/Worker/Clickup/ErrorTask.php, _underscore/Model/Core/Logs/Issue.php, tools/mvc/errors/get.php, tools/mvc/errors/issue/get.php, dbchanges2/Logs/2026-08-05a - Issue status baseline and auto-resolution.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

@@ -25,6 +25,7 @@ related:
   - ../../_underscore/features/error-reporting-issue-event.md
   - ../../../1.0/apps/tools/features/errors-curation-console.md
   - ../../../1.0/apps/library/features/error-capture-1-0.md
+  - ./error-issue-auto-resolution.md
   - ./creating-worker-actions.md
   - ./clickup-project-routing.md
   - ./notification-email.md
@@ -420,6 +421,15 @@ this controller needs the same treatment.**
 
 ## Change history
 
+- 2026-08-05 — **Built (separate doc):** the cron now owns an Issue-level **OPEN → RESOLVED**
+  lifecycle — it auto-resolves an Issue once its events decay to zero for a duration proportional to
+  the Issue's own firing cadence (durable EWMA baseline on `Issue`), closes the ClickUp ticket
+  DB-first, and auto-reopens under the same id on recurrence. Resolution keys only on the baseline +
+  quiet duration, never on `urgency`/`minimumUrgency`. The `ErrorTask.php` webhook still closes
+  episodes/resets counters but **never** sets `Issue.status`; `recurrenceCount` still increments
+  exactly once per episode close. Full mechanics, constants, the two resolution paths
+  (`autoResolveIssue` + the ticketless `sweepResolveQuietIssues` sweep) and the sweep's index live in
+  [error-issue-auto-resolution](./error-issue-auto-resolution.md). (jcardinal)
 - 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

package/knowledge/2.0/apps/worker2/features/error-issue-auto-resolution.md

@@ -0,0 +1,209 @@
+---
+title: Error-Issue Auto-Resolution & Reopen (frequency-decay lifecycle)
+framework: "2.0"
+repo: worker2
+project: Worker
+client: shared
+type: feature
+status: active
+updated: 2026-08-05
+owners: ["jcardinal"]
+files:
+  - worker2/Worker/Infrastructure/Errors.php
+  - worker2/Worker/Clickup/ErrorTask.php
+  - _underscore/Model/Core/Logs/Issue.php
+  - tools/mvc/errors/get.php
+  - tools/mvc/errors/issue/get.php
+  - dbchanges2/Logs/2026-08-05a - Issue status baseline and auto-resolution.sql
+related:
+  - ./error-escalation-cron.md
+  - ../../_underscore/features/error-reporting-issue-event.md
+  - ../../../1.0/apps/tools/features/errors-curation-console.md
+---
+
+## Summary
+
+The error system could escalate and de-escalate an Issue's *urgency* but had no concept of an
+Issue being **resolved**. This feature adds an Issue-level **OPEN → RESOLVED** lifecycle to the
+every-minute escalation cron (`_Worker_Infrastructure_Errors`): once an Issue's events **decay to
+zero for a duration proportional to how often that Issue normally fires**, the cron auto-resolves
+it (and closes its ClickUp ticket); if the same Issue recurs, the cron auto-reopens it **under the
+same internal id**. Resolution keys **only** on a trusted firing baseline plus a quiet duration —
+never on human severity (`urgency`/`minimumUrgency`).
+
+This complements urgency escalation (see
+[error-escalation-cron](./error-escalation-cron.md)) and the Issue/Event capture model (see
+[error-reporting-issue-event](../../_underscore/features/error-reporting-issue-event.md)). It does
+**not** replace the existing episode/recurrence mechanics — episodes and ClickUp task linking were
+already built; this adds the Issue-level status flip on top.
+
+## Data model additions (`Logs.Issue`)
+
+Migration: `dbchanges2/Logs/2026-08-05a - Issue status baseline and auto-resolution.sql` (run on
+the **Logs** cluster).
+
+- **`status enum('OPEN','RESOLVED')`** + **`dtAutoResolved`** — the Issue-level lifecycle.
+- **Durable firing baseline** (all scalars on `Issue`, cron-maintained):
+  `baselineGapSeconds` (EWMA of inter-arrival gap), `baselineSampleCount`, `dtBaselineAnchor`,
+  `baselineAnchorOccurrences`.
+- New index **`Issue_status_dtLastOccurred (status, dtLastOccurred)`** for the ticketless sweep
+  (see Performance).
+
+> **⚠ The resolution column is `dtAutoResolved`, NOT `dtResolved` — deliberately.** The token
+> `dtResolved` already means the **episode**-level `IssueClickupTask.dtResolved` (~6 usages). A
+> same-named column on `Issue` would invite a wrong join between an Issue's lifecycle and an
+> episode's close. The two levels are distinct: an episode closes every time the ClickUp ticket is
+> completed; the Issue resolves only when firing actually stops.
+
+## How it works
+
+### Durable frequency baseline (why not the Event table)
+
+`Events` **purge after 7 days**, but a low-frequency Issue may need to stay quiet for **months**
+before it is safe to call resolved. So "how often does this Issue fire" cannot be recomputed from
+`Event` — it lives on durable `Issue` scalars instead.
+
+- `computeBaselineUpdate` maintains an **EWMA of the inter-arrival gap** (`baselineGapSeconds`),
+  folded into `persistIssueState` on the worker2 cron. `BASELINE_EWMA_ALPHA_PERCENT = 30`.
+- **Bursts** that fire many times between two 1-minute runs are handled by dividing elapsed time
+  by the **`totalOccurrences` delta**, so a burst does not read as one giant gap.
+- The baseline is **trusted** (Issue eligible to resolve) only once
+  `baselineSampleCount >= BASELINE_MIN_SAMPLES (3)`.
+
+> **⚠ The baseline is maintained ONLY on the worker2 cron path, never on the capture path.** Do
+> **not** update these scalars from `_underscore/Error.php` or `library/app/error/capture.php` (the
+> byte-mirrored capture path). Baseline maintenance belongs to `computeBaselineUpdate` /
+> `persistIssueState` in the cron.
+
+### The quiet-window formula
+
+```
+requiredQuiet = clamp(RESOLVE_QUIET_MULTIPLE * baselineGapSeconds,
+                      RESOLVE_MIN_QUIET_HOURS, RESOLVE_MAX_QUIET_DAYS)
+```
+
+Constants in `Errors.php`: `RESOLVE_QUIET_MULTIPLE = 3`, `RESOLVE_MIN_QUIET_HOURS = 24`,
+`RESOLVE_MAX_QUIET_DAYS = 90`. A high-frequency Issue therefore needs only the **24h floor** of
+silence; a monthly Issue needs roughly **90 days**. An Issue with events decayed to zero for
+`requiredQuiet` (and a trusted baseline) is resolved.
+
+> **Resolution keys ONLY on trusted baseline + quiet duration — never on `urgency` or
+> `minimumUrgency`.** Product decision: an Issue that has genuinely stopped firing is resolved
+> regardless of the human severity floor. Severity governs *how loudly* an active Issue is
+> escalated, not *whether a silent one is closed*.
+
+### Two resolution paths (a working-set coverage gap)
+
+The every-minute working set does not select every Issue — a quiet LOW Issue with no open ClickUp
+task is never picked up. Resolution is therefore split by division of labour:
+
+1. **`autoResolveIssue`** (inside `processIssue`) — for Issues **with an open ClickUp ticket**,
+   which are always in the working set via the open-task branch. It also PUTs ClickUp
+   `status = 'complete'`.
+2. **`sweepResolveQuietIssues`** — a **set-based sweep** for **ticketless** Issues that have
+   fallen out of the every-minute working set. This is what closes the coverage gap.
+
+**`autoResolveIssue` is DB-first, then best-effort ClickUp:** close the episode → set
+`status = RESOLVED`, `urgency = LOW`, `occurrences = 0`, `consecutiveQuietWindows = 0`, commit →
+**then** PUT ClickUp `status = 'complete'` (logged and swallowed on failure). DB-first ordering
+makes the ClickUp webhook echo an **idempotent no-op** (episode already closed → 0 rows). The
+ClickUp terminal string is **`'complete'`** (`_Worker_Clickup`, `COMPLETE_STATUS_TYPES =
+['done','closed']`).
+
+**No team email is sent on resolve** — guaranteed by an **unconditional early return in
+`processIssue`** before `shouldNotify` / email / sprint logic.
+
+### Reopen (same id, never the old ticket)
+
+- **`sweepReopenResolvedIssues`** + **`reopenIssue`** flip `status` back to **OPEN** when
+  `dtLastOccurred > dtAutoResolved`.
+- On reopen, the baseline anchor is **re-seeded**: `dtBaselineAnchor = dtLastOccurred` and
+  `baselineAnchorOccurrences = totalOccurrences`, so the long quiet gap is **not** folded into the
+  EWMA (see the reopen bug below).
+- The recurrence ticketing itself (a **new** ClickUp ticket linked to prior episodes via
+  `createClickupTask` + `loadPreviousTaskIdentifiers` + `POST /task/{new}/link/{prev}`) was
+  **already built** — this feature only adds the Issue-level status flip. The **same internal Issue
+  id** is reused; the old ticket is never reopened.
+
+### Webhook safety — the ClickUp side must NEVER set `Issue.status`
+
+`ErrorTask.php` `resolveEpisode` closes the episode and resets counters via the shared
+`_Worker_Infrastructure_Errors::resetIssueForNextEpisode`, but it **never** writes
+`Issue.status`. A developer completing a ClickUp ticket is treated as a *hypothesis* that the cron
+then verifies by watching whether events actually stop — only the frequency-decay cron may write
+`RESOLVED`.
+
+`recurrenceCount` increments **exactly once per episode close** (a single atomic
+`dtResolved IS NULL` guard), whether the closer is the webhook or the cron's `closeOpenEpisode`, so
+the DB-first resolve → webhook echo can never double-count.
+
+## Performance
+
+`sweepResolveQuietIssues` puts a constant `dtLastOccurred < NOW() - INTERVAL 86400 SECOND`
+pre-filter **before** the per-row `LEAST`/`GREATEST` clamp, so the new
+`Issue_status_dtLastOccurred (status, dtLastOccurred)` index can **range-scan** rather than
+degrading to a status-only lookup. The correlated `NOT EXISTS` (ticketless test) uses
+`IssueClickupTask (issueId, dtResolved)`.
+
+## Tools `/errors` UI
+
+(See [errors-curation-console](../../../1.0/apps/tools/features/errors-curation-console.md) for the
+console's own conventions.)
+
+- **Open / Resolved / All** status filter (default **Open**; the request value is allowlisted).
+- **Resolved badge** on both the listing and the detail header.
+- **`dtAutoResolved`** rendered as a fact row on the detail page.
+- The episode-table column header **"Resolved" → "Closed"** — deliberately renamed to break the
+  naming collision with the new **Issue-level** `status`. In the UI, an **episode** is now *Closed*;
+  an **Issue** is *Resolved*.
+
+## Deploy order
+
+**Run the SQL migration first, then deploy the code:**
+
+1. `dbchanges2/Logs/2026-08-05a - Issue status baseline and auto-resolution.sql` on the **Logs**
+   database.
+2. Then deploy `_underscore` + `worker2` + `tools`.
+
+> **⚠ Order-critical.** Code before its migration crashes `loadWorkingSet` on the missing
+> `status` / baseline columns (a missing column in a working-set SELECT is a **runtime exception**
+> in 2.0, not a null — see the escalation-cron doc).
+
+## Gotchas / known issues
+
+- **Only the frequency-decay cron may write `Issue.status = RESOLVED`.** The ClickUp webhook
+  (`ErrorTask.php`) closes episodes and resets counters but must never touch `Issue.status`.
+- **`autoResolveIssue` must stay DB-first.** Closing the episode and committing `RESOLVED` before
+  the ClickUp PUT is what makes the webhook echo a 0-row no-op; reversing the order reintroduces a
+  double-close race.
+- **A RESOLVED Issue with no new events must short-circuit the pipeline.** (Bug caught in review.)
+  For **floored** Issues — whose urgency never reaches LOW — a RESOLVED Issue stayed in the working
+  set and **spuriously created a new ClickUp ticket**. Fixed with an explicit **RESOLVED
+  early-return guard** plus dropping `urgency = LOW` / `occurrences = 0` on resolve.
+- **Reopen must re-seed the baseline anchor.** (Bug caught in review.) Without re-seeding
+  `dtBaselineAnchor` / `baselineAnchorOccurrences` on reopen, the **entire quiet period** was folded
+  into the EWMA, inflating the quiet window roughly **1.6× per resolve→reopen cycle**. Always
+  re-anchor on reopen.
+- **`baselineSampleCount < 3` → not eligible to resolve.** An Issue without a trusted baseline is
+  never auto-resolved, so a brand-new Issue cannot resolve itself out of existence on the strength
+  of one quiet hour.
+
+## Change history
+
+- 2026-08-05 — **Built:** Issue-level auto-resolution and reopen by frequency decay. New
+  `Issue.status enum('OPEN','RESOLVED')` + `dtAutoResolved`, a durable cron-maintained firing
+  baseline (`baselineGapSeconds` EWMA + `baselineSampleCount`/`dtBaselineAnchor`/
+  `baselineAnchorOccurrences`, trusted at sample count ≥ 3), and a quiet-window
+  `clamp(3 × baselineGapSeconds, 24h, 90d)`. Two resolution paths — per-issue `autoResolveIssue`
+  (DB-first, then ClickUp `complete`) for ticketed Issues and a set-based `sweepResolveQuietIssues`
+  for ticketless ones (closing the working-set coverage gap) — plus `sweepReopenResolvedIssues` /
+  `reopenIssue` that flip status back to OPEN and re-anchor the baseline. Resolution keys only on a
+  trusted baseline + quiet duration, never on urgency; no team email on resolve; the ClickUp webhook
+  never sets `Issue.status`. Tools `/errors` gained an Open/Resolved/All filter, a Resolved badge,
+  a `dtAutoResolved` row, and the episode column renamed "Resolved" → "Closed". Two review bugs
+  fixed: a RESOLVED-with-no-events fall-through that spuriously re-ticketed floored issues, and a
+  reopen that folded the quiet period into the EWMA (~1.6× window inflation) until the anchor was
+  re-seeded. Migration `dbchanges2/Logs/2026-08-05a` runs before the `_underscore`+worker2+tools
+  deploy. (jcardinal)
+</content>
+</invoke>

package/knowledge/INDEX.md

@@ -19,7 +19,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 ## 2.0 framework
 
 - **_underscore** (_Underscore) _(framework core)_ — 46 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
-- **worker2** (Worker) — 40 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
+- **worker2** (Worker) — 41 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
 - **api2** (API) — 22 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
 - **dbchanges2** (Database Changes) _(framework core)_ — 5 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
 - **toga2-supply** (TOGa Supply) — 5 doc(s) → [2.0/apps/toga2-supply/INDEX.md](2.0/apps/toga2-supply/INDEX.md)

package/package.json

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