toga-ai 1.0.25 → 1.0.27

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

@@ -0,0 +1,5 @@
+# dbchanges2 (Database Changes) — 2.0 knowledge
+
+| Doc | Summary | Files |
+|-----|---------|-------|
+| [Database Changes (dbchanges2) Repository Architecture](architecture.md) | `dbchanges2` is the **schema-migration / SQL change-set repository** for the entire 2.0 platform. | Core/, Client/, Client_<Tenant>/, Logs/, Logs_Client/, _modules/ |

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

@@ -0,0 +1,137 @@
+---
+title: Database Changes (dbchanges2) Repository Architecture
+framework: "2.0"
+repo: dbchanges2
+project: Database Changes
+client: shared
+type: architecture
+status: active
+updated: 2026-06-09
+owners: [jcardinal]
+files:
+  - Core/
+  - Client/
+  - Client_<Tenant>/
+  - Logs/
+  - Logs_Client/
+  - _modules/
+related:
+  - 2.0/apps/_underscore/architecture.md
+---
+
+## Summary
+
+`dbchanges2` is the **schema-migration / SQL change-set repository** for the entire 2.0
+platform. It contains **only `.sql` files organized into folders** — there is no PHP, no
+runner script, and no Composer manifest in the repo. Each top-level folder maps to a
+**database (or database family)** in the 2.0 infrastructure (see
+`2.0/apps/_underscore/architecture.md` → *Database architecture*). An **external executor**
+(not stored in this repo) walks each folder and runs its SQL files **in alphabetical order**
+against the corresponding database(s).
+
+Because execution order is purely alphabetical, **file naming is the contract.** Files are
+named with a leading **`YYYY-MM-DD`** date so alphabetical sort = chronological order, which
+is the intended execution order.
+
+## File naming convention (the execution contract)
+
+1. **Date prefix, ISO format:** every file starts `YYYY-MM-DD`. ISO ordering means
+   alphabetical = chronological = execution order.
+2. **Optional description suffix:** a short human phrase describing the change, and/or a
+   ticket number — e.g. `2026-06-04 - RecursiveItemFulfillmentPut.sql`,
+   `2024-11-27 49875 AddAdminNoteToSalesOrderTable.sql`. The phrase is informational; only
+   the leading date governs order.
+3. **Same-day ordering with letter suffixes:** when multiple files share a date and must run
+   in a specific sequence, append `a`, `b`, `c`, … directly after the date to force order —
+   e.g. `2024-05-16.sql` then `2024-05-16b.sql`; `2024-09-06a …`, `2024-09-11a …`,
+   `2024-09-11c …`. The letter sits right after the date so the alphabetical sort stays
+   correct.
+
+> Naming is loose in punctuation (some files have ` - `, some a bare space, occasionally a
+> trailing-space quirk like `2026-06-03- BLANK_CLIENT_DATABASE.sql`). The **only** hard rule
+> is the leading `YYYY-MM-DD[letter]` so ordering holds.
+
+## Folder → database mapping
+
+Each top-level folder targets a database or a **fan-out set** of databases. Tenant naming
+(`Client_<Tenant>`, `Logs_<Tenant>`) follows the `_underscore` convention: single leading
+capital, rest lower-case (e.g. `Compass`, `Compasscanada`).
+
+| Folder | Target database(s) | Fan-out |
+|---|---|---|
+| `Core/` | `Core` (shared platform DB) | single DB |
+| `Logs/` | `Logs` (framework-level logs, not tenant-scoped) | single DB |
+| `Client/` | **every** `Client_<Tenant>` database | fan-out to all active clients |
+| `Client_<Name>/` | the **one** `Client_<Name>` DB only | single tenant |
+| `Logs_Client/` | **every** `Logs_<Tenant>` database | fan-out to all client-log DBs |
+| `_modules/` | reusable change-sets, opt-in per client (see below) | indirection |
+
+Key distinction: **`Client/` is the shared changes applied to every client database**, while
+**`Client_<Name>/` holds changes scoped to that single client.** As of 2026-06-09 there are
+**30 `Client_<Name>` folders** (Aig, Bankofamerica, Browardsheriff, Canon, Compass,
+CompassCanada, Elite, Endeavorhealth, Erau, Growrk, Managelife, Masonite, Mcgrawhill,
+Miamidade, Ncci, Northwell, Nycdoe, Nychh, Pcmatic, Prudential, Quad, Rate, Sbasite, Shrss,
+Spglobal, Trividiahealth, True, Wje, Wmchealth, Ynhh).
+
+`Client/` and `Logs_Client/` also contain `BLANK_CLIENT_DATABASE` / `BLANK_CLIENT_LOGS_DATABASE`
+seed scripts used to provision a brand-new tenant DB from scratch.
+
+## `_modules` — reusable, opt-in change-sets
+
+Some change-sets aren't applied to every client — only to clients that use a given **module**
+(a feature/integration). This is modeled with two pieces:
+
+1. **`_modules.txt` inside a client folder** — a plain-text manifest listing the module names
+   that client depends on, **one per line**. Example: `Client_Compass/_modules.txt` contains
+   `netsuite`; `Client_Pcmatic/_modules.txt` contains `startech`. An empty/absent file means
+   no extra modules. (Note: the file is literally named **`_modules.txt`**.)
+2. **`_modules/<module>/` folder** — holds the dated SQL change-set for that module. Each
+   value in a client's `_modules.txt` matches a **subfolder name** under `_modules/`.
+
+When the executor processes a client, it applies that client's own folder **plus** the
+change-sets of every module named in its `_modules.txt`. Current modules:
+
+| Module value | Folder | Used by (examples) |
+|---|---|---|
+| `netsuite` | `_modules/netsuite/` | Compass, Canon, Ncci, Sbasite, Spglobal, … (most clients) |
+| `startech` | `_modules/startech/` | Pcmatic |
+
+Module folders use the **same `YYYY-MM-DD` naming + ordering rules** as client folders.
+
+> **Module names should be lower-case**, and a module value may be a **nested path** that
+> maps to a nested subfolder — e.g. a `_modules.txt` entry of `ai/bdr` would reference
+> `_modules/ai/bdr/`. The repo currently contains an `_modules/Ai/Bdr/` folder whose casing
+> is a **typo** (it should be `_modules/ai/bdr/`); no client references it yet, so there is no
+> live example of a nested module in use. Treat lower-case as the convention going forward.
+
+## HISTORIC folders — always skipped
+
+Any folder named **`HISTORIC`** is **ignored by the executor** — it is an archive of old,
+already-applied change files moved aside to keep the live list short. Present under
+`Client/HISTORIC/`, `Core/HISTORIC/`, `Logs_Client/HISTORIC/`, and `_modules/netsuite/HISTORIC/`,
+typically bucketed as `FILES BEFORE <date>` (or by year under `Core/`). **Never** rely on a
+file inside `HISTORIC` running; **never** add new changes there.
+
+## Adding a new change (the rules)
+
+1. Pick the right folder for the target DB: `Core/`, `Logs/`, the shared `Client/` (every
+   tenant), a specific `Client_<Name>/`, `Logs_Client/` (every tenant log), or a module under
+   `_modules/<module>/`.
+2. Name the file `YYYY-MM-DD - <ShortDescription>.sql` using **today's date**. If another
+   file already exists for today in that folder and yours must run after it, append the next
+   free letter (`b`, `c`, …) right after the date.
+3. Write **idempotent / forward-only** SQL that is safe to run in alphabetical order after all
+   prior files in the folder. Follow `rules/common/security.md` — no credentials in the file.
+4. To make a change reach only module-using clients, put it in `_modules/<module>/` and ensure
+   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.
+
+## Relationship to the rest of 2.0
+
+`dbchanges2` is registered as a **2.0 core repo** (`role: core` in `registry.json`) — it is
+platform-wide infrastructure, not a single application. It has no code dependency on
+`_underscore`, but it is **conceptually coupled** to the `_underscore` database model: its
+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.

package/knowledge/INDEX.md

@@ -12,6 +12,7 @@ _Auto-generated by `knowledge.js index`. Do not hand-edit._
 - **_underscore** (_Underscore) _(framework core)_ — 2 doc(s) → [2.0/apps/_underscore/INDEX.md](2.0/apps/_underscore/INDEX.md)
 - **worker2** (Worker) — 3 doc(s) → [2.0/apps/worker2/INDEX.md](2.0/apps/worker2/INDEX.md)
 - **api2** (API) — 1 doc(s) → [2.0/apps/api2/INDEX.md](2.0/apps/api2/INDEX.md)
+- **dbchanges2** (Database Changes) _(framework core)_ — 1 doc(s) → [2.0/apps/dbchanges2/INDEX.md](2.0/apps/dbchanges2/INDEX.md)
 
 ## Clients
 

package/knowledge/registry.json

@@ -2,6 +2,7 @@
   { "repo": "_underscore", "project": "_Underscore", "framework": "2.0", "role": "core", "dependsOn": [] },
   { "repo": "worker2",     "project": "Worker",      "framework": "2.0", "role": "app",  "dependsOn": [] },
   { "repo": "api2",        "project": "API",         "framework": "2.0", "role": "app",  "dependsOn": [] },
+  { "repo": "dbchanges2",  "project": "Database Changes", "framework": "2.0", "role": "core", "dependsOn": [] },
   { "repo": "library",     "project": "Library",     "framework": "1.0", "role": "core", "dependsOn": [] },
   { "repo": "worker",      "project": "Worker",      "framework": "1.0", "role": "app",  "dependsOn": [] }
 ]

package/package.json

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

package/skills/capture/SKILL.md

@@ -138,6 +138,13 @@ Skip mirror-back if the paths are the same directory.
 
 ## Step 7 — Push (only when IS_GIT_CLONE is true)
 
+**This push is pre-authorized and mandatory — never ask the developer to confirm it.**
+Running `/capture` IS the authorization to publish. After validate + index pass and the
+staged set is confined to `knowledge/`, commit and push automatically as the final step of
+every capture. Do not pause, do not present a "ready to push?" prompt, do not offer to "leave
+it staged locally." The only reasons to stop are the guardrails already listed below: nothing
+new to push (Check B empty), files staged outside `knowledge/`, or a push that errors.
+
 If `IS_GIT_CLONE` is false — skip this step entirely and show:
 > "⚠ Docs written to `.claude/knowledge/` only (no git clone). Run `npx toga-ai`
 > to create `~/toga-tech`, then re-run /capture to push."