toga-ai 1.0.188 → 1.0.190

package/knowledge/2.0/apps/toga2-commerce/features/cart-page-config-architecture.md

@@ -30,10 +30,15 @@ related:
 The Cart page (`src/pages/Cart/`) is the most config-heavy page in `toga2-commerce`. As of
 `_production` it is **config-driven at the field level but hardcoded at the section level**, and it
 renders the cart through **two near-duplicate dual-mode forms** (cart-checkout vs edit-order). A
-config-driven refactor is **planned but not yet implemented** (see *Planned refactor* below). This
-doc records both the current architecture and the agreed target so the work can be picked up without
-re-deriving it. The cart consumes the per-tenant `CARTPAGE.ts` config resolved through
-`useAssignClientFields` — see [client-fields](client-fields.md) for that resolution model.
+config-driven refactor to the toga2.5 (`toga25-supply`) pattern is **planned but not yet
+implemented** (see *Planned refactor*). This doc is written to be **self-sufficient** — a teammate
+can pick the work up from here without re-deriving it. The cart consumes the per-tenant
+`CARTPAGE.ts` config resolved through `useAssignClientFields` — see
+[client-fields](client-fields.md) for that resolution model.
+
+> A longer-form plan with the same content also lives in the toga2-commerce repo at
+> `docs/reviews/implement-config-cart-refactor-PLAN.md` (not distributed in the KB bundle). This doc
+> is the authoritative copy for teammates who only have the knowledge base.
 
 ## Current architecture (`_production`)
 
@@ -71,8 +76,8 @@ based on `inEditMode`. `CartFormRenderer.tsx` exists only on the `implement-conf
 - **Config-key naming drift.** `CARTPAGE.ts` uses `inputs:` for the `orderFor` section but
   `formFields:` for `shippingAddress` / `costCenter` / `notifications`, while `CartFormSection`
   reads a `fields` prop. Three names for one concept; `CartForm` hand-maps each section's array into
-  the `fields` prop. This pre-existing drift is what tripped the prior spike. (Target: rename all to
-  a single `fields` key.)
+  the `fields` prop. **This pre-existing drift is what tripped the prior spike.** (Target: rename all
+  to a single `fields` key.)
 - **`useForm` is seeded with a hardcoded union of every client's fields.** `CartPage.tsx`
   (~lines 230–258) calls `useForm` with one static `defaultValues` object that is the **union** of
   all clients' fields, with the **COMPASS-only magic shipping-method UUID `087a9d0b-…` baked in**.
@@ -82,74 +87,201 @@ based on `inEditMode`. `CartFormRenderer.tsx` exists only on the `implement-conf
 - **Client differences are hardcoded, not config.** Examples observed: COMPASS renders
   `DuplicateKitGuardrail`, QUAD does not; COMPASS seeds the cart form (cost center / manager / emails)
   from the order-for user, QUAD does not. These are per-client conditionals in cart code today.
+- **Standards debt in the dual forms** (fold in as each file is touched): silent error swallows
+  (e.g. the cost-center `onError` that never reaches Sentry), the magic Standard-Ground shipping
+  UUID, and a 13-arg `checkIsProceedToCheckoutEnabled` helper (violates the 4+ params rule).
 - `useAssignClientFields.ts` returns `FIELDS?.[clientName]?.[language]?.[role]` with no transform —
   there is no fallback (a missing combo renders empty). See [client-fields](client-fields.md).
 
+## Target: the toga2.5 pattern (what "done" looks like)
+
+Seven conventions, each already demonstrated in `toga25-supply` (read these as the reference
+implementation):
+
+| # | Convention | toga2.5 reference file |
+|---|---|---|
+| **C1** | One key name for a section's input array — toga2.5 uses **`fields`** everywhere. | `orderViewFields.json`, `itemRecordCreateFields.json` |
+| **C2** | A section declares its renderer via a **`type`** discriminator; a `Record<type, fn>` map dispatches it. No hardcoded section list. | `SalesOrderSummaryGrid.tsx` (`sectionRenderers[section.type]`) |
+| **C3** | Visibility is `isVisible` filtered at render; **runtime** visibility is computed in the view-model and **patched into config** (memo that rewrites the section), not branched in JSX. | `useSalesOrderRecordModalViewModel` (`patchedTenantFields`) |
+| **C4** | Config stays **serializable**; behavior (handlers, predicates) is a **string key hydrated → function once** in a memo. | `ItemRecordCreate.tsx` (`hydrateField`, `SECOND_VALUE_VISIBILITY`) |
+| **C5** | Generic fields via one `renderField` + generic input component; specialized layout (totals, address) is a standalone component that **still consumes config `fields`**. | `renderField.tsx`, `OrderSectionCard`, `BaseTotals` |
+| **C6** | **Client-specific behavior is declared in config and evaluated generically — never `if (client === "COMPASS")` in code.** Capabilities are flags; conditional logic is a **named rule** (`{ type: "..." }`) evaluated by a small pure evaluator in the view-model. | `approvalActionFields.json` (`approvalActionStatuses`, `approveButtonRule`) → `evaluateApproveRule()` in `useApprovalModalViewModel.tsx` |
+| **C7** | **Form `defaultValues` are derived from the same config that renders the fields** so each client's defaults match exactly the fields it collects. (Cart-specific extension — see below.) | toga2.5 uses a static `emptyItemDefaults` (single-shape form); cart needs config-derived |
+
+Applied to the cart, "done" = `CartPage` owns state → a `CartFormContext` distributes it → a
+`CartFormRenderer` walks the section config and dispatches each section (generic `CartFormSection`
+or a standalone like Summary/Confirm/Email) → **one** code path serves both cart and edit-order
+modes via an `inEditMode` flag in context + `visibleWhen: { context: "inEditMode" }` in config.
+
+## Gap: `_production` → toga2.5 (the work to close each)
+
+| Std | `_production` today | Work to close it |
+|---|---|---|
+| **C1** one key (`fields`) | `inputs` (orderFor) + `formFields` (others); `CartFormSection` wants `fields` | Rename all section arrays to **`fields`** in every `CARTPAGE.ts`; drop the hand-mapping. |
+| **C2** section `type` + dispatch map | section layout hardcoded in `CartForm.tsx`, built twice | Add `type` (+ `order`/`isVisible`) to each section in config; build `CartFormRenderer` mapping `type → component`. Delete hardcoded layout. |
+| **C3** runtime visibility patched in VM | `isHiddenDuringEditMode`/`inEditMode` branches scattered | Express edit-order differences as `visibleWhen: { context: "inEditMode" }`; resolve once via context. |
+| **C4** string keys hydrated to fns | `labelButton.onClick:"cantFindUser"`, `inputButtons[].valueKey` are strings but `handleModalOpen` is wired ad-hoc + drilled | One `hydrateCartConfig` memo mapping config strings → handlers from context. |
+| **C5** standalone sections consume config | Summary / email / confirm are inline JSX in `CartForm` | Extract to `SummarySection` / `CartEditEmailSection` / `ConfirmSection`, each reading its config slice. |
+| **(state)** context, not props | ~30 props drilled through 4 levels | `CartFormContext` owns watched values + handlers + `inEditMode`; components read it. |
+| **(VMs)** consolidated | `useEditCartViewModel` + `useEditOrderViewModel` + dispatcher, duplicated effects | Merge into `useCartFormViewModel` (data) + `useCartFormSync` (mount / orderFor-cascade / form→store, mode-branched once). |
+| **C6** client behavior in config | client differences hardcoded (DuplicateKitGuardrail, cost-center seeding) | Move each to a config capability flag or named rule (below). |
+
 ## Planned refactor (DECIDED 2026-06-24 — plan only, not implemented)
 
 **Approach (Route B): rebuild the config-driven cart from the working `_production` branch**, using
 the broken `implement-config` spike branch only as a *reference blueprint* (its target-shaped files
 — `CartFormContext`, `CartFormRenderer`, `useCartFormViewModel`, `useCartFormSync`, standalone
 sections — are architecturally sound but mid-rename and non-functional; lift code where correct,
-do not finish that branch). Rationale: the spike's −3,940-line deletion silently dropped real
+do not finish that branch). **Rationale:** the spike's −3,940-line deletion silently dropped real
 behavior (email seeding, duplicate-email validation, edit-order cost-center/address). The risk is
 **behavior parity, not architecture**, so migrate in verifiable slices against the running
-`_production` app as the oracle. Target pattern = toga2.5 (`toga25-supply`): one form, section
-layout from config, state via context, consolidated sync effects.
+`_production` app as the oracle.
+
+### Phases
+
+**Phase 0 — Branch + safety net.** Branch `feature/cart-config-driven-form` off `_production`.
+**Pin a behavior oracle:** no tests cover the cart today, so first document both flows from the
+running app (sections shown, fields, buttons, validation messages, email auto-population, edit-order
+original address) and add RTL smoke tests rendering the cart for one tenant/role in **cart** and
+**edit-order** mode — these guard against the "renders nothing" failure the spike hit. **Inventory
+the hardcoded client branches (C6):** grep `src/pages/Cart` for `clientSlug`/client-name comparisons
+and per-client conditionals (start with `DuplicateKitGuardrail` and the order-for
+cost-center/manager/email seeding) — this list is the C6 work-list for Phases 3–4.
+
+**Phase 1 — Normalize config to one key (C1). 🔴 Do first, standalone, behavior-neutral.**
+In every `CARTPAGE.ts` (COMPASS / COMPASSCANADA EN+FR / QUAD × all roles) rename each section's
+input array to **`fields`** (`inputs → fields`, `formFields → fields`). Update `CartForm.tsx`'s
+per-section hand-mapping to read `section.fields` uniformly. Add a `CartSectionConfig` /
+`CartFieldConfig` type so the key is compiler-enforced (kills the untyped `any` that allowed the
+drift). Grep to prove zero `inputs:` / `formFields:` remain. **Ships as its own PR.**
+
+**Phase 2 — State into context + config-derived defaults.** Add `CartFormContext` (lift from the
+branch) owning watched values, handlers (`handleModalOpen`, email handlers, cost-center search),
+`formMethods`, `advancedSelectConfig`, `managerName`, and **`inEditMode`**. `CartPage` builds the
+context once; `CartForm`/`CartFormSection` read context instead of props. Replace the hardcoded
+union `defaultValues` (CartPage.tsx ~230–258) and the two `reset()` effects (~267, ~282) with the
+config-derived builder (below).
+
+**Phase 3 — Consolidate view-models + sync effects.** Merge `useEditCartViewModel` +
+`useEditOrderViewModel` + the dispatcher into **`useCartFormViewModel`** (data). Move the three
+duplicated effects into **`useCartFormSync`**: (a) on-mount populate from `salesOrder` (use a
+`hasSyncedOnMount` ref for run-once — the branch did this correctly), (b) orderFor-change cascade,
+(c) form→store sync — branching on `inEditMode` *once* inside each effect, not across two files.
+Drive client-specific seeding by **rule (C6.2)**, not client name.
+> **⚠ Parity gates — this is exactly where the prior spike silently regressed. Verify each against the Phase 0 oracle:**
+> - email auto-population (contact / supervisor / supported-by / current user) for **both** modes;
+> - duplicate-email path still surfaces `duplicateEmailAddressError` to the user (dedupe must not swallow it);
+> - edit-order cost-center "prefer fresh user data over stale salesOrder" logic;
+> - effect dependency arrays — no stale closures; justify every `eslint-disable`.
 
-Plan document (in the toga2-commerce repo, not in the KB):
-`docs/reviews/implement-config-cart-refactor-PLAN.md`.
+**Phase 4 — Section layout from config (C2/C3/C5). 🔴 The core of the refactor.** Add
+`type` + `order` + `settings.isVisible` to each section in config. Build **`CartFormRenderer`**:
+order sections, dispatch `SECTION_RENDERERS[section.type]`, with an **explicit fallback (log + skip)**
+for an unknown/missing type so a section can't silently vanish. Extract inline Summary / email /
+Confirm JSX into `SummarySection` / `CartEditEmailSection` / `ConfirmSection`, each consuming its
+config slice via context. Express edit-order-only pieces (original-address block) as
+`visibleWhen: { context: "inEditMode", value: true }` — or confirm with product they're dropped.
+Gate client-optional UI on **capability flags (C6.1)**. **Delete `CartForm.tsx`, `EditCart.tsx`,
+`EditOrder.tsx`** once the renderer covers both modes and the oracle passes.
 
-Phases: **P0** pin a behavior oracle + inventory hardcoded client branches · **P1** behavior-neutral
-config-key rename (`inputs`/`formFields` → single `fields`) · **P2** `CartFormContext` to kill
-prop-drilling + config-derived form defaults · **P3** consolidate the dual view-models and the three
-sync effects into `useCartFormViewModel` + `useCartFormSync`, branching on `inEditMode` once · **P4**
-drive section layout from config (`type` + dispatch map with explicit fallback) + capability flags,
-then delete `CartForm`/`EditCart`/`EditOrder` · **P5** hydration memo + standards sweep (magic UUID
-removed from code, lives in config).
+**Phase 5 — Hydration + standards cleanup (C4).** One `hydrateCartConfig` memo mapping
+`labelButton.onClick` / `inputButtons[].valueKey` / `visibleWhen.context` strings → handlers &
+predicates from context. Standards sweep on every file touched: no commented-out code, no
+`console.log`; restore the cost-center `onError` Sentry path; convert `checkIsProceedToCheckoutEnabled`
+to an options object (4+ params rule); replace remaining `any` (`UseFormReturn<any>`, untyped
+`fields`); the magic shipping UUID is removed from code entirely — it now lives as a config
+`defaultValue` (C7, Phase 2).
 
-### Key principle established — client behavior comes from config, never `if (client === ...)`
+### Key principle — client behavior comes from config, never `if (client === ...)` (C6)
 
-A new client must be onboarded by **editing `CARTPAGE.ts`**, not by adding `clientSlug` branches to
-cart code. Two flavors, modeled exactly on toga2.5's SalesOrder approval pattern (config carries
-`approvalActionStatuses` + `approveButtonRule:{type:"requireStepTwoAssigned"}`; a pure
-`evaluateApproveRule(rule, ctx)` switch over a discriminated union in `useApprovalModalViewModel.tsx`
-interprets it — the component never knows it is COMPASS):
+A new client must be onboarded by **editing `CARTPAGE.ts`**, not by adding `clientSlug` branches.
+Modeled exactly on toga2.5's SalesOrder approval pattern: config carries `approvalActionStatuses`
++ `approveButtonRule:{type:"requireStepTwoAssigned"}`; a pure `evaluateApproveRule(rule, ctx)`
+switch over a discriminated union in `useApprovalModalViewModel.tsx` interprets it — the component
+never knows it is COMPASS. Two flavors:
 
 1. **Capability flags** — pure on/off presence, no runtime data:
-   `capabilities.duplicateKitGuardrail.isEnabled` (COMPASS true, QUAD omits). The renderer reads the
-   flag to decide whether to mount `DuplicateKitGuardrail`.
+   `capabilities.duplicateKitGuardrail.isEnabled` (COMPASS `true`, QUAD omits → safe-off default).
+   The renderer reads the flag to decide whether to mount `DuplicateKitGuardrail`.
 2. **Named rules** — conditional logic depending on runtime data, declared as `{ type }` and
-   evaluated generically: e.g. `orderForSeedRules: [{type:"seedCostCenterFromUser"}, …]` iterated by
+   evaluated generically. e.g. `orderForSeedRules: [{type:"seedCostCenterFromUser"}, …]` iterated by
    an `applySeedRule` evaluator in `useCartFormSync` (mirrors `evaluateApproveRule`). QUAD omits the
    rules → seeds nothing, no branch.
 
-### Config-derived form defaults (cart-specific extension of the toga2.5 pattern)
+**Rule of thumb:** if a behavior differs by client it must be reachable from `CARTPAGE.ts` as a flag
+or a `{ type }` rule. No `clientSlug` comparisons anywhere in `src/pages/Cart`.
+
+### Config-derived form defaults (C7 — cart-specific extension of toga2.5)
 
 The config already enumerates exactly the fields a client renders, so derive `useForm`
-`defaultValues` from it via a `buildCartDefaultValues(fields, ctx)` builder with three sources:
-- per-field `defaultValue` in config (where the COMPASS shipping UUID **moves to**; QUAD omits it);
-- type-derived empties (`text`/`textArea`→`""`, `checkbox`→`false`,
-  `select`/`advancedSelect`→`{uuid:"",name:""}`);
-- dynamic `defaultValueRules` reusing the same `{type}` rule shape
-  (e.g. `currentUserWhenNotEditable`, `fromSalesOrderErpEntity`).
-
-The two mode-change `reset()` effects call the **same builder** so defaults and rendered inputs can
-never drift. Noted honestly: toga2.5 uses a *static* `emptyItemDefaults` because its item-create form
-is a single shape; the cart is genuinely multi-shape per client, so config-derived defaults is a
-**cart-specific extension** of toga2.5's philosophy, not a literal copy.
+`defaultValues` from it via `buildCartDefaultValues(fields, ctx)` (`ctx = { user, salesOrder, emails,
+inEditMode }`) with three sources, in precedence order per field:
+
+1. **per-field `defaultValue` in config** — where the COMPASS shipping UUID **moves to**; QUAD omits
+   it and falls through;
+2. **dynamic `defaultValueRules`** reusing the C6.2 `{type}` rule shape for state-dependent values
+   (e.g. `{valueKey:"orderFor", type:"currentUserWhenNotEditable"}`,
+   `{valueKey:"costCenter", type:"fromSalesOrderErpEntity"}`);
+3. **type-derived empties** otherwise (`text`/`textArea`→`""`, `checkbox`→`false`,
+   `select`/`advancedSelect`→`{uuid:"",name:""}`).
+
+```ts
+const defaultValues = useMemo(() => buildCartDefaultValues(fields, ctx), [fields, /* … */]);
+const formMethods = useForm({ mode: "all", defaultValues });
+// both mode-change reset()s call the SAME builder: reset(buildCartDefaultValues(fields, ctx))
+```
+
+Result: `useForm` registers **exactly** the fields the client collects — no union object, no orphan
+defaults, no controlled/uncontrolled warnings; resets stay config-consistent; the shipping UUID and
+any client default live in `CARTPAGE.ts`; new-client onboarding needs no `CartPage` edit. Noted
+honestly: toga2.5 uses a *static* `emptyItemDefaults` because its item-create form is single-shape;
+the cart is genuinely multi-shape per client, so config-derived defaults is a **cart-specific
+extension** of toga2.5's philosophy, not a literal copy.
 
 > The general "no `if (client === ...)` — drive client behavior from config via capability flags and
-> named rules evaluated by a generic evaluator" rule, applied across 2.0 React frontends beyond just
-> the cart, is being proposed as a team **standard** separately (senior-owned / pending approval).
+> named rules" rule, applied across 2.0 React frontends beyond the cart, was proposed as a team
+> standard separately and **declined** for now (the principle stays scoped to this cart doc).
+
+## Definition of Done
+
+- [ ] Single key name (`fields`) across `src/pages/Cart`; `CartForm`/`EditCart`/`EditOrder` deleted.
+- [ ] One render path serves cart **and** edit-order; renderer has a fallback for unknown section types.
+- [ ] Parity verified against the Phase 0 oracle: all sections render & submit; validation messages
+      fire; email seeding + duplicate-email error reproduced in **both** modes.
+- [ ] No prop-drilling (context); VMs and sync effects consolidated; no stale-closure deps.
+- [ ] **No `clientSlug`/client-name comparisons in `src/pages/Cart` (C6)** — every client difference
+      (DuplicateKitGuardrail, order-for seeding, tax/shipping calc) is a capability flag or named
+      rule; a client that omits a key gets the safe default.
+- [ ] **Form `defaultValues` built from config (C7)** — registers exactly the fields the client
+      collects; no hardcoded union object; shipping-method UUID lives in config; resets use the builder.
+- [ ] Standards clean: no dead code / `console.log`, cost-center error reaches Sentry, no new `any`.
+- [ ] `tsc` clean; smoke tests green; PR body documents both test flows + the
+      `inputs/formFields → fields` migration.
+
+## Sequencing & risk
+
+- **Phase 1 ships independently** (pure rename, behavior-neutral) — land it first to de-risk the rest.
+- **Phase 4 is the heart**; it depends on Phases 2–3 so the renderer has context + consolidated data.
+- **Biggest risk is behavior parity, not rendering.** The dual forms hold real logic (email seeding,
+  duplicate validation, edit-order cost-center/address). Phase 0's oracle and Phase 3's parity gates
+  exist specifically because the prior spike deleted −3,940 lines and lost behavior static reading
+  could not catch. Migrate in verifiable slices against a running `_production`.
+
+## Open questions for kickoff
+
+*(Approach is settled: rebuild from `_production` with the branch as reference.)*
+1. **Config key name** — `fields` (toga2.5 standard, recommended) vs keep per-section names.
+2. **Edit-order original-address block** — still required, or intentionally dropped?
+3. **Edit-order duplicate-user guard** — the prior spike made it "always applied"; intended for
+   edit-order mode?
 
 ## Change history
 - 2026-06-24 — Initial: documented the current `_production` Cart architecture (field-level config
   via `CartFormSection`, hardcoded section layout in `CartForm`, dual `EditCart`/`EditOrder` forms +
-  dispatcher VM, prop-drilling), its gotchas (config-key drift `inputs`/`formFields`/`fields`,
-  hardcoded union `defaultValues` with the COMPASS magic shipping UUID, hardcoded per-client
-  branches), and the DECIDED config-driven refactor approach (rebuild from `_production`, branch as
-  blueprint; capability flags + named rules à la toga2.5 approval; config-derived
-  `buildCartDefaultValues`). Plan only — not implemented (apeterson)
-</content>
-</invoke>
+  dispatcher VM, prop-drilling), its gotchas (config-key drift, hardcoded union `defaultValues` with
+  the COMPASS magic shipping UUID, hardcoded per-client branches), and the DECIDED config-driven
+  refactor approach. (apeterson)
+- 2026-06-24 — Expanded to be self-sufficient for handoff: added the C1–C7 target conventions table
+  with toga2.5 reference files, the gap→work table, the full phased plan (incl. Phase 0 oracle +
+  smoke tests and Phase 3 parity gates), Definition of Done, sequencing/risk, and open questions.
+  Fixed stray closing tags accidentally written into the file. (apeterson)

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

@@ -193,9 +193,30 @@ backfills `workTypeAtLock` the first time a task is seen).
   and the committed values should be rotated. See team coding/security standards.
 - **Worker contract.** Like all 2.0 workers this must return cleanly and commit writes via
   the `_Db`/transaction layer to be durable — uncommitted captures can be silently dropped.
+- **ClickUp pagination returns duplicate tasks — the sync loop must be idempotent.** ClickUp's
+  page-based task API (`/list/{id}/task?page=N`) can return the **same task on more than one
+  page**, especially on large/long runs (a real failure ran ~418s across many pages). If the
+  sync loop treats a re-seen task as new, it builds a second `_Model_Team_Task` (id=NULL) and
+  `save()`s it → a second INSERT → `Duplicate entry '<sprintId>-<clickupId>' for key
+  'Tasks.sprintId_clickupIdentifier'` and the whole run aborts. **Design rule (the two-map
+  pattern):** keep two separate maps keyed by `clickupIdentifier`. `$lookupTaskByClickUpId`
+  drives update-vs-insert and **must stay current for the entire run** — register every
+  newly-created task into it immediately and never `unset()` it mid-loop, so a duplicate page
+  row resolves to the same model and does an UPDATE. A separate `$tasksToDelete` map (seeded
+  from existing tasks) has entries removed as each task is seen; whatever remains after the
+  loop is deleted (SprintLock) / archived to `statusNow = ARCHIVED` (the Capture methods).
+  Do **not** overload one map for both jobs. This pattern is replicated identically in
+  `SprintLock()`, `CaptureSprintEnd()`, and `CaptureSprintDaily()` — fix all three together.
 
 ## Change history
 
+- 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
+  deletion tracking, `unset()`ing entries mid-loop so a re-seen task was treated as new and
+  re-INSERTed. Decoupled into two maps — a persistent `$lookupTaskByClickUpId` (new tasks
+  registered immediately, never unset) and a separate `$tasksToDelete` — making re-processing
+  idempotent. Applied to `SprintLock()`, `CaptureSprintEnd()`, and `CaptureSprintDaily()`. (jcardinal)
 - 2026-06-24 — Initial documentation of `_Worker_Team_Sprint` (`Worker/Team/Sprint.php`):
   the sprint lifecycle (warnings → lock → daily → end → release notes), the four-metric
   developer scoring model (reliability/quality/hygiene/integrity with weights, team-relative

package/package.json

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