toga-ai 1.0.89 → 1.0.91

package/knowledge/1.0/apps/test/INDEX.md

@@ -0,0 +1,14 @@
+# test (Test) — 1.0 knowledge
+
+| Doc | Summary | Files |
+|-----|---------|-------|
+| [Test (test) Architecture](architecture.md) | `test` (project **Test**) is a **repository of ad-hoc developer scripts** — not a deployed application. | test/team/ |
+| [2.0 Deployment — Per-Client SQL Generator](features/2-0-deployment-client-sql.md) | `team/2.0 deployment/generate_client_sql.php` fans a single SQL change-set out across **all 2.0 client databases**. | test/team/2.0 deployment/generate_client_sql.php, test/team/2.0 deployment/Clients_Db.txt, test/team/2.0 deployment/Client.sql |
+| [Active Directory Authentication Test](features/active-directory-auth-test.md) | `team/active_directory_authentication_test.php` is an interactive CLI tool to test **Active Directory authentication**. | test/team/active_directory_authentication_test.php |
+| [Create Elastic Beanstalk Environment (script)](features/create-elastic-beanstalk.md) | `team/aws/create_elastic_beanstalk.php` is a **standalone** (no `App_` framework) constants-driven PHP generator. | test/team/aws/create_elastic_beanstalk.php |
+| [Developer Generators (password, UUID)](features/dev-generators.md) | Two tiny **1.0 `App_` framework** convenience scripts for everyday developer needs. | test/team/generate_password.php, test/team/uuid.php |
+| [Forecast vs NetSuite Discrepancy Analysis](features/forecast-netsuite-discrepancy-analysis.md) | `team/forecast-netsuite/discrepancy_analysis.php` detects discrepancies between our **Forecast database** and **NetSuite** (the source of truth for all sales da | test/team/forecast-netsuite/discrepancy_analysis.php |
+| [TableView Builder (2.0 TableViews SQL generator)](features/tableview-builder.md) | `team/tableViewBuilder/` generates SQL `INSERT` statements for the **2.0 `TableViews`**, `TableViewFields`, and `TableViewJoins` tables from a plain SQL `SELECT | test/team/tableViewBuilder/TableViewGenerator.php, test/team/tableViewBuilder/index.php, test/team/tableViewBuilder/Instructions.md |
+| [TOGa 2.0 Client Onboarding SQL Generator](features/toga2-client-onboarding-sql.md) | `team/generate_toga2_onboarding_sql.php` generates the SQL needed to **onboard a new client** onto the 2.0 platform. | test/team/generate_toga2_onboarding_sql.php |
+| [TOGa 2.0 User Cross-Client Access SQL Generator](features/toga2-user-cross-client-access-sql.md) | `team/generate_toga2_user_access_sql.php` generates SQL to grant an existing 2.0 user from a **home client** access to a **cross client**. | test/team/generate_toga2_user_access_sql.php |
+| [URL & Domain Markdown Document Builder](features/url-domain-markdown-document.md) | `team/build_url_domain_markdown_document.php` generates a **markdown document of our URLs and domains** by pulling environments and domains from the 2.0 platfor | test/team/build_url_domain_markdown_document.php |

package/knowledge/1.0/apps/test/architecture.md

@@ -0,0 +1,89 @@
+---
+title: Test (test) Architecture
+framework: "1.0"
+repo: test
+project: Test
+client: shared
+type: architecture
+status: active
+updated: 2026-06-16
+owners: [jcardinal]
+files:
+  - test/team/
+related:
+  - ./features/create-elastic-beanstalk.md
+  - ./features/forecast-netsuite-discrepancy-analysis.md
+  - ./features/tableview-builder.md
+  - ./features/toga2-client-onboarding-sql.md
+  - ./features/toga2-user-cross-client-access-sql.md
+  - ./features/2-0-deployment-client-sql.md
+  - ./features/active-directory-auth-test.md
+  - ./features/url-domain-markdown-document.md
+  - ./features/dev-generators.md
+---
+
+## Summary
+
+`test` (project **Test**) is a **repository of ad-hoc developer scripts** — not a deployed
+application. It is where developers keep throwaway and semi-permanent PHP scripts they run
+locally to do one-off jobs: generate SQL, probe an integration, build a document, create
+infrastructure, etc.
+
+**Layout convention:**
+
+- **Per-developer folders** — each developer has their own top-level folder for personal
+  scratch scripts. These are private and **not** captured in this knowledge base.
+- **`team/` folder** — shared scripts any team member can use. **This is the documented
+  surface.** Each feature doc under `apps/test/features/` covers one `team/` script (or a
+  small related group).
+
+## Framework relationship
+
+Most `team/` scripts bootstrap the **1.0 `App_` framework** so they can reuse its helpers
+(DB access, API clients, string/crypto utilities):
+
+```php
+require_once('_.php');
+App_Framework_Sandbox::initialize();   // or App_Framework_Worker::initialize()
+```
+
+Common framework helpers used: `App_Api_Toga2` (calls the 2.0 platform API),
+`App_String` (password hashing / support codes), `App_Misc::generateUUID()`,
+`App_ActiveDirectory`, `App_Framework_Sandbox` / `App_Framework_Worker`. The repo therefore
+`dependsOn` the 1.0 core repo **`library`** (see `1.0/apps/library/architecture.md`).
+
+**Some scripts are standalone** (no framework) — pure PHP that only does file processing or
+shells out to the AWS CLI. Examples: `team/aws/create_elastic_beanstalk.php` and
+`team/2.0 deployment/generate_client_sql.php`. These have no `library` dependency.
+
+**Note the cross-framework reach:** several scripts run on the 1.0 framework but **generate
+artifacts for the 2.0 platform** (client onboarding SQL, user-access SQL, TableView SQL,
+URL/domain docs via the 2.0 API). The framework a script *runs on* is not necessarily the
+framework it *targets*.
+
+## How to run
+
+Scripts are run directly from a local dev environment (CLI or browser, depending on the
+script's output). Configuration lives in `const` blocks at the top of each file — set those,
+then run. Several scripts **print SQL/output to stdout** for the developer to review and run
+manually against the target database; they do not execute changes themselves.
+
+## team/ folder index
+
+| Script | Runs on | Targets | Doc |
+|---|---|---|---|
+| `aws/create_elastic_beanstalk.php` | standalone | AWS (EB) | [create-elastic-beanstalk](./features/create-elastic-beanstalk.md) |
+| `2.0 deployment/generate_client_sql.php` | standalone | 2.0 client DBs | [2-0-deployment-client-sql](./features/2-0-deployment-client-sql.md) |
+| `forecast-netsuite/discrepancy_analysis.php` | 1.0 | Forecast DB vs NetSuite | [forecast-netsuite-discrepancy-analysis](./features/forecast-netsuite-discrepancy-analysis.md) |
+| `tableViewBuilder/TableViewGenerator.php` | standalone | 2.0 TableViews | [tableview-builder](./features/tableview-builder.md) |
+| `active_directory_authentication_test.php` | 1.0 | Active Directory | [active-directory-auth-test](./features/active-directory-auth-test.md) |
+| `build_url_domain_markdown_document.php` | 1.0 | 2.0 API (TOGa Hub) | [url-domain-markdown-document](./features/url-domain-markdown-document.md) |
+| `generate_toga2_onboarding_sql.php` | 1.0 | 2.0 client DBs | [toga2-client-onboarding-sql](./features/toga2-client-onboarding-sql.md) |
+| `generate_toga2_user_access_sql.php` | 1.0 | 2.0 client DBs | [toga2-user-cross-client-access-sql](./features/toga2-user-cross-client-access-sql.md) |
+| `generate_password.php`, `uuid.php` | 1.0 | dev utility | [dev-generators](./features/dev-generators.md) |
+
+**Retired / not documented:** `team/DOA_gitbook/` and `team/DOA_talos/` are being retired.
+
+## Change history
+
+- 2026-06-16 — Initial capture of the `team/` folder. Registered repo in `registry.json`.

package/knowledge/1.0/apps/test/features/2-0-deployment-client-sql.md

@@ -0,0 +1,47 @@
+---
+title: 2.0 Deployment — Per-Client SQL Generator
+framework: "1.0"
+repo: test
+project: Test
+client: shared
+type: feature
+status: active
+updated: 2026-06-16
+owners: [jcardinal]
+files:
+  - test/team/2.0 deployment/generate_client_sql.php
+  - test/team/2.0 deployment/Clients_Db.txt
+  - test/team/2.0 deployment/Client.sql
+related:
+  - ../architecture.md
+---
+
+## Summary
+
+`team/2.0 deployment/generate_client_sql.php` fans a single SQL change-set out across **all
+2.0 client databases**. It is **standalone** (no `App_` framework) — pure file processing.
+
+Use it when you have a schema/data change that must run identically against every 2.0 client
+DB and you want one script to paste into a SQL client.
+
+## How it works
+
+1. Reads `Clients_Db.txt` — newline-separated list of client database names (blank lines ignored).
+2. Reads `Client.sql` — the SQL template (e.g. `CREATE TABLE` / `ALTER` statements) to apply per client.
+3. For each client, emits a banner comment, `USE \`<client>\`;`, then the template SQL.
+4. Prints the combined SQL to **stdout** (with a generated-on header and client count). It does
+   **not** execute anything — the developer reviews the output and runs it manually.
+
+Edit `Client.sql` to hold the change, keep `Clients_Db.txt` current, then run
+`php generate_client_sql.php` (or via browser) and run the output against the target cluster.
+
+## Gotchas
+
+- Output is only as correct as `Clients_Db.txt` — a stale/missing client means it is silently
+  skipped. Refresh the list before a deployment.
+- The script wraps each client block in `USE \`db\`;` — make sure `Client.sql` does **not** also
+  switch databases or it will fight the `USE`.
+
+## Change history
+
+- 2026-06-16 — Initial capture.

package/knowledge/1.0/apps/test/features/active-directory-auth-test.md

@@ -0,0 +1,38 @@
+---
+title: Active Directory Authentication Test
+framework: "1.0"
+repo: test
+project: Test
+client: shared
+type: feature
+status: active
+updated: 2026-06-16
+owners: [jcardinal]
+files:
+  - test/team/active_directory_authentication_test.php
+related:
+  - ../architecture.md
+---
+
+## Summary
+
+`team/active_directory_authentication_test.php` is an interactive CLI tool to test **Active
+Directory authentication**. Runs on the **1.0 `App_` framework**
+(`App_Framework_Worker::initialize()`) and calls `App_ActiveDirectory::isAuthenticated()`.
+
+## How it works
+
+A REPL loop: clears the screen, prompts for email and password (password input hidden via
+`stty -echo`), calls `App_ActiveDirectory::isAuthenticated($email, $password)`, and prints
+success/failure. Loops until `Ctrl+C`.
+
+Run from a CLI (it uses `STDIN` and `system('clear')`/`stty`, so it is terminal-only — not browser).
+
+## Gotchas
+
+- Terminal-only: the `stty` calls require a real TTY (won't work over a non-interactive runner).
+- It prints only success/failure, never the password — keep it that way (no credential logging).
+
+## Change history
+
+- 2026-06-16 — Initial capture.

package/knowledge/1.0/apps/test/features/create-elastic-beanstalk.md

@@ -0,0 +1,95 @@
+---
+title: Create Elastic Beanstalk Environment (script)
+framework: "1.0"
+repo: test
+project: Test
+client: shared
+type: feature
+status: active
+updated: 2026-06-16
+owners: [jcardinal]
+files:
+  - test/team/aws/create_elastic_beanstalk.php
+related:
+  - ../architecture.md
+---
+
+## Summary
+
+`team/aws/create_elastic_beanstalk.php` is a **standalone** (no `App_` framework) constants-driven
+PHP generator. Running `php create_elastic_beanstalk.php` **prints** a ready-to-paste AWS
+CloudShell command that creates a new Elastic Beanstalk **environment** inside an **existing**
+EB **application**. The script never calls AWS itself — it only emits the command.
+
+It supersedes the old `create-elastic-beanstalk` Claude skill (removed 2026-06-16).
+
+## How it works
+
+- All knobs are `const` at the top: `PROFILE` (`production` | `nonprod`), `ENVIRONMENT` (the
+  app's ENVIRONMENT env-var value), `APPLICATION_NAME`, `ENVIRONMENT_NAME`, `CNAME_PREFIX`,
+  `INSTANCE_TYPE`, `INSTANCE_COUNT`, `EB_PHP_VERSION`, `SHARED_ALB_NAME`.
+- `PROFILE` selects an entry in the `PROFILES` map → account, VPC, subnets, roles, storage,
+  and load-balancer strategy. **Two accounts:** PROD `654654170868`, NON-PROD `975050298201`.
+- Output: an account-check banner + post-run notes (to **stderr**, so `> cmd.sh` captures only
+  the command), and the command itself (to **stdout**) — a JSON `option-settings` heredoc piped
+  to `aws elasticbeanstalk create-environment`.
+- Baked-in conventions: arm64/`t4g`, Apache, `AllAtOnce` deploys, On-Demand only
+  (`EnableSpot=false`), 10 GB root volume (`gp2` prod / `standard` non-prod), pinned
+  Min=Max instance count, key pair `true-aws-infrastructure-production`, and the
+  **never-trigger CPU autoscaling hack** (watch `CPUUtilization`, `Unit=Percent`, thresholds
+  `2000000`–`6000000` so it never breaches).
+
+### PROD vs NON-PROD differences
+
+| | NON-PROD (`975050298201`) | PROD (`654654170868`) |
+|---|---|---|
+| Load balancer | **Shared** ALB (`SHARED_ALB_NAME`) | **Dedicated** public ALB |
+| Storage | `standard` | `gp2` |
+| Default type / count | `t4g.micro` / 1 | `t4g.large` / 2 |
+| Instance profile | `aws-elasticbeanstalk-ec2-role` | `ElasticBeanstalk-EC2-Instance-Profile` |
+
+## Shared ALB (NON-PROD) — the critical detail
+
+The non-prod shared ALBs (`true-alb-*`) listen on **HTTPS:443 only**. The correct, AWS-documented
+option-settings to attach to them are:
+
+```
+aws:elbv2:loadbalancer            SharedLoadBalancer = <ALB ARN, resolved at runtime>
+aws:elbv2:listener:443            Rules              = default
+aws:elasticbeanstalk:environment:process:default  Port=80  Protocol=HTTP  HealthCheckPath=/
+```
+
+Plus `aws:elasticbeanstalk:environment` `LoadBalancerType=application`, `LoadBalancerIsShared=true`.
+
+**Why `listener:443 Rules=default` is the linchpin:** EB associates its auto-managed *default*
+rule with a **port-80** listener unless you explicitly associate it with the port you actually
+use. On a 443-only shared ALB that fails with *"the load balancer doesn't have a listener on
+port 80."* Setting `aws:elbv2:listener:443 Rules=default` moves the default rule onto 443.
+EB then **auto-creates** the rule and **adds this env's CNAME as the host-header condition**,
+which isolates it from sibling environments on the same shared ALB.
+
+## Gotchas (each cost a failed `create-environment`)
+
+- **Don't** define a custom listener rule named `default` — that name is reserved for EB's
+  auto-created default rule; passing it is rejected.
+- **Don't** try to disable the phantom port-80 listener (`aws:elbv2:listener:80 ListenerEnabled=false`
+  or the bogus `aws:elbv2:listener:default`) — neither works. Associating `default` with 443 is
+  the only correct fix.
+- **You can't** set `aws:elbv2:listener:<port>` to *add* listeners on a shared ALB — EB doesn't
+  manage its listeners. You only associate the existing listener's rules and define rules.
+- `PHP_VERSION` is a reserved PHP built-in constant — the script uses `EB_PHP_VERSION`.
+- The JMESPath number filter must use backticks around the port and be wrapped in single quotes
+  so bash doesn't execute the backticks.
+- The live sibling env `api-client-alpha` runs Rolling deploys + Spot + dual instance types —
+  i.e. it **diverges** from the conventions this script enforces. The script intentionally keeps
+  the team conventions (AllAtOnce / On-Demand / single type), not alpha's drift.
+
+## Verified usage
+
+2026-06-16: generated `api-client-beta` (env id `e-erp8hg9hhx`) under app `API` on shared ALB
+`true-alb-client-beta` in `975050298201` — created successfully (Status `Launching`).
+
+## Change history
+
+- 2026-06-16 — Initial capture. Documented the shared-ALB `listener:443 Rules=default` fix
+  discovered while porting the old skill to this script; first successful create (`api-client-beta`).

package/knowledge/1.0/apps/test/features/dev-generators.md

@@ -0,0 +1,45 @@
+---
+title: Developer Generators (password, UUID)
+framework: "1.0"
+repo: test
+project: Test
+client: shared
+type: feature
+status: active
+updated: 2026-06-16
+owners: [jcardinal]
+files:
+  - test/team/generate_password.php
+  - test/team/uuid.php
+related:
+  - ../architecture.md
+---
+
+## Summary
+
+Two tiny **1.0 `App_` framework** convenience scripts for everyday developer needs. Both
+`require_once('_.php'); App_Framework_Sandbox::initialize();` then call a framework helper.
+
+## `generate_password.php`
+
+Generates a random password **and its hash**. Uses `App_String::generateSupportCode(8)` for the
+password (the "support code" generator deliberately avoids look-alike characters like `O`/`0`
+and `1`/`I`), then prints the password and `App_String::passwordHash($password)`. There is a
+commented line to hardcode your own password instead of generating one.
+
+Use it when you need to seed a user password + a storable hash. Hashing goes through
+`App_String::passwordHash` (the framework's bcrypt/argon wrapper) — don't hand-roll hashes.
+
+## `uuid.php`
+
+Prints a single random UUID via `App_Misc::generateUUID()`. Use it whenever you need a UUID that
+matches the platform's generation (e.g. seeding rows that expect framework-style UUIDs).
+
+## Gotchas
+
+- These reuse framework helpers on purpose — use them rather than ad-hoc `rand()`/manual hashing
+  so output matches what the platform produces and stays consistent with security standards.
+
+## Change history
+
+- 2026-06-16 — Initial capture.

package/knowledge/1.0/apps/test/features/forecast-netsuite-discrepancy-analysis.md

@@ -0,0 +1,47 @@
+---
+title: Forecast vs NetSuite Discrepancy Analysis
+framework: "1.0"
+repo: test
+project: Test
+client: shared
+type: feature
+status: active
+updated: 2026-06-16
+owners: [jcardinal]
+files:
+  - test/team/forecast-netsuite/discrepancy_analysis.php
+related:
+  - ../architecture.md
+---
+
+## Summary
+
+`team/forecast-netsuite/discrepancy_analysis.php` detects discrepancies between our **Forecast
+database** and **NetSuite** (the source of truth for all sales data). It runs on the **1.0
+`App_` framework** (`require_once('_.php'); App_Framework_Sandbox::initialize();`).
+
+## How it works
+
+1. **Input:** a CSV exported from the NetSuite saved search *"Data Dump for Mark H"*
+   (searchid 7276). The developer opens that report, adjusts dates if needed, exports CSV, saves
+   it locally, and points `NETSUITE_FULL_DATA_DUMP_FILEPATH` at it.
+2. Column positions in the CSV are mapped via `NSINDEX_*` constants (doc date, doc type, doc
+   number, item internal id, revenue, profit). Date window is `DATE_RANGE_MINIMUM` /
+   `DATE_RANGE_MAXIMUM` (defaults to the current year; the report exports year-to-date).
+3. Builds a lookup of NetSuite rows keyed by **docType + docNumber**. Doc type is normalized
+   from display text to camelCase; parenthesized amounts like `(1,234)` are converted to
+   negative numbers via `cleanNumber()`.
+4. Compares against the Forecast DB and reports rows that don't reconcile (revenue/profit
+   mismatches, missing documents).
+
+## Gotchas
+
+- The `NSINDEX_*` column indices are **positional** — if the NetSuite saved search columns are
+  reordered or added to, these constants must be updated or the comparison silently reads the
+  wrong fields.
+- The CSV path is a local Windows path constant; update per-machine before running.
+- NetSuite is authoritative — discrepancies mean Forecast is wrong, not NetSuite.
+
+## Change history
+
+- 2026-06-16 — Initial capture.

package/knowledge/1.0/apps/test/features/tableview-builder.md

@@ -0,0 +1,55 @@
+---
+title: TableView Builder (2.0 TableViews SQL generator)
+framework: "1.0"
+repo: test
+project: Test
+client: shared
+type: feature
+status: active
+updated: 2026-06-16
+owners: [jcardinal]
+files:
+  - test/team/tableViewBuilder/TableViewGenerator.php
+  - test/team/tableViewBuilder/index.php
+  - test/team/tableViewBuilder/Instructions.md
+related:
+  - ../architecture.md
+---
+
+## Summary
+
+`team/tableViewBuilder/` generates SQL `INSERT` statements for the **2.0 `TableViews`**,
+`TableViewFields`, and `TableViewJoins` tables from a plain SQL `SELECT` query. It is a
+**standalone** PHP tool (class `TableViewGenerator`, driven by `index.php`).
+
+It turns "here's the query that produces the grid I want" into the metadata rows the 2.0 platform
+needs to render that grid as a TableView.
+
+## How it works
+
+Inputs (see `Instructions.md`):
+- `input/Records.csv` and `input/RecordFields.csv` — metadata exports mapping record routes →
+  `recordId` and field names → `recordFieldId`.
+- A user SQL `SELECT` in `queries/<name>.sql`.
+- A fixed `slug` and a manually-assigned `tableViewId`.
+
+The generator parses the query for the FROM table, selected fields, and JOIN chains, then:
+1. Resolves `recordId` from the table route and `recordFieldId` from field name + recordId.
+2. Emits an `INSERT` into `TableViews` (with a generated UUID, the slug, defaults like
+   `recordsPerPage=25`, `sortPrimaryDirection=ASC`).
+3. Emits `TableViewJoins` for each JOIN (parsing the `ON` clause to resolve child/parent field IDs).
+4. Emits `TableViewFields` for each selected column.
+
+Output SQL goes to `output/` for the developer to review and run.
+
+## Gotchas
+
+- **Manual IDs:** `tableViewId` is supplied by hand and the internal join index starts at a
+  hard-coded number (`$joinIndex = 60`) — must be bumped to avoid collisions with existing rows.
+- The `ON`-clause parser is regex-based and best-effort; it prints a warning and **skips** any
+  join whose `ON` clause it can't parse, so always check the generated SQL for missing joins.
+- Field/record resolution depends entirely on `Records.csv` / `RecordFields.csv` being current.
+
+## Change history
+
+- 2026-06-16 — Initial capture.

package/knowledge/1.0/apps/test/features/toga2-client-onboarding-sql.md

@@ -0,0 +1,53 @@
+---
+title: TOGa 2.0 Client Onboarding SQL Generator
+framework: "1.0"
+repo: test
+project: Test
+client: shared
+type: feature
+status: active
+updated: 2026-06-16
+owners: [jcardinal]
+files:
+  - test/team/generate_toga2_onboarding_sql.php
+related:
+  - ../architecture.md
+  - ./toga2-user-cross-client-access-sql.md
+---
+
+## Summary
+
+`team/generate_toga2_onboarding_sql.php` generates the SQL needed to **onboard a new client**
+onto the 2.0 platform. Runs on the **1.0 `App_` framework**
+(`App_Framework_Sandbox::initialize()`), but the SQL it produces targets the **2.0** client
+databases.
+
+## How it works
+
+Configure the `const` block, then run; the script emits the onboarding SQL to stdout for review.
+
+Key configuration:
+- `CLIENT_NAME` — formal client name, proper case (e.g. `'The Coca-Cola Company'`).
+- `CLIENT_IDENTIFIER` — PascalCase, no spaces (e.g. `'Cocacola'`).
+- `CLIENT_SUBDOMAIN_IDENTIFIER` — lowercase, no spaces; the email domain without TLD.
+- `CLIENT_EMAIL_DOMAINS` — array of permitted email domains **with** TLD.
+- `SHOULD_CREATE_AGILANT_API` — when true, also creates the Agilant API user and api-roles.
+
+Platform topology baked into the script:
+- `DATABASE_PREFIXES = ['Client', 'Logs', 'Archive']` — the three DB families a client gets.
+- `ENVIRONMENTS__DATABASE_PREFIXES__CLUSTERS` — per-environment (`dev` / `beta` / `production`)
+  host endpoints for each DB prefix. Production uses a global Aurora cluster with separate
+  writer/reader endpoints (`writer.client.database.togahub.com` / `reader1.client.database.togahub.com`);
+  dev/beta fall back to a single cluster (reader = writer).
+
+## Gotchas
+
+- The cluster/endpoint map is environment infrastructure encoded as constants — if RDS endpoints
+  change, this script must be updated.
+- Identifiers have strict casing rules (formal vs PascalCase vs lowercase-subdomain); getting
+  them wrong produces inconsistent DB/identity records.
+- Output is SQL to run manually — review before executing against production.
+
+## Change history
+
+- 2026-06-16 — Initial capture.

package/knowledge/1.0/apps/test/features/toga2-user-cross-client-access-sql.md

@@ -0,0 +1,46 @@
+---
+title: TOGa 2.0 User Cross-Client Access SQL Generator
+framework: "1.0"
+repo: test
+project: Test
+client: shared
+type: feature
+status: active
+updated: 2026-06-16
+owners: [jcardinal]
+files:
+  - test/team/generate_toga2_user_access_sql.php
+related:
+  - ../architecture.md
+  - ./toga2-client-onboarding-sql.md
+---
+
+## Summary
+
+`team/generate_toga2_user_access_sql.php` generates SQL to grant an existing 2.0 user from a
+**home client** access to a **cross client**. Runs on the **1.0 `App_` framework**; produces
+SQL for the **2.0** client databases.
+
+## How it works
+
+Configure the `const` block, then run; SQL prints to stdout for manual execution.
+
+- **Home client:** `HOME_CLIENT_DATABASE_NAME` (e.g. `Client_True`), `HOME_CLIENT_ID`,
+  `HOME_CLIENT_USER_ID` — the user being granted access.
+- **Cross client:** `CROSS_CLIENT_DATABASE_NAME` (e.g. `Client_Endeavorhealth`), `CROSS_CLIENT_ID`.
+
+The script builds the `Users_Roles` grants that link the home-client user into the cross client.
+It first emits a `DELETE` of any existing default-role `Users_Roles` rows for that user (cleanup
+so re-runs are idempotent), then the inserts that grant cross-client access.
+
+## Gotchas
+
+- IDs are supplied by hand — a wrong `HOME_CLIENT_USER_ID` / `CROSS_CLIENT_ID` grants the wrong
+  person access. Verify against the actual client DBs before running the output.
+- The leading `DELETE` targets `isDefault = 1` roles for the user; understand it removes existing
+  default-role rows before re-granting.
+- Output is SQL to run manually — review before executing.
+
+## Change history
+
+- 2026-06-16 — Initial capture.

package/knowledge/1.0/apps/test/features/url-domain-markdown-document.md

@@ -0,0 +1,44 @@
+---
+title: URL & Domain Markdown Document Builder
+framework: "1.0"
+repo: test
+project: Test
+client: shared
+type: feature
+status: active
+updated: 2026-06-16
+owners: [jcardinal]
+files:
+  - test/team/build_url_domain_markdown_document.php
+related:
+  - ../architecture.md
+---
+
+## Summary
+
+`team/build_url_domain_markdown_document.php` generates a **markdown document of our URLs and
+domains** by pulling environments and domains from the 2.0 platform API. Runs on the **1.0
+`App_` framework** (`App_Framework_Sandbox::initialize()`) and calls the 2.0 API via
+`App_Api_Toga2::send(...)` against `https://api.togahub.com/v2`.
+
+## How it works
+
+1. `GET /environments` (paged) → collects all environment names.
+2. `GET /domains` (paged, 100/page) → collects domain records with `client.name`, `app.name`,
+   `environment.name`, `domain`.
+3. Assembles the results into a markdown document (URLs/domains grouped for readability).
+
+It authenticates as the **True Solutions** client UUID using an "Infrastructure Documenter"
+API key/secret pair (the credentials are constants in the script — see security note).
+
+## Gotchas / security
+
+- **Hardcoded credentials:** the script embeds `TOGA_CLIENT_UUID`, an API key, and an API secret
+  as constants. These are **redacted here** and must never be copied into the knowledge base or
+  committed elsewhere. **Action:** rotate these credentials and move them to a non-committed
+  config/secret store; the plaintext key/secret in the repo should be treated as compromised.
+- Paging relies on `resp->meta->nextPage`; an API shape change there breaks the loop.
+
+## Change history
+
+- 2026-06-16 — Initial capture. Flagged hardcoded API key/secret for rotation.

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

@@ -0,0 +1,10 @@
+# talos (TOGa IQ) — 2.0 knowledge
+
+| Doc | Summary | Files |
+|-----|---------|-------|
+| [TOGa IQ (talos) Architecture](architecture.md) | **TOGa IQ** is TOGA Technology's AI agent platform. | talos/libs/aegra-api/src/aegra_api/main.py, talos/libs/aegra-api/src/aegra_api/settings.py, talos/libs/aegra-api/src/aegra_api/config.py, talos/libs/aegra-api/src/aegra_api/core/tenant_router.py, talos/libs/aegra-api/src/aegra_api/core/control_plane_db.py, talos/libs/aegra-api/src/aegra_api/core/auth_middleware.py, talos/libs/aegra-api/src/aegra_api/services/run_executor.py, talos/libs/aegra-api/src/aegra_api/services/langgraph_service.py, talos/libs/aegra-api/src/aegra_api/services/graph_factory.py, talos/libs/aegra-api/src/aegra_api/services/streaming_service.py, talos/examples/react_agent/graph.py, talos/docker-compose.yml, talos/deployments/docker/Dockerfile |
+| [aegra-api — Agent Protocol HTTP + Execution Pipeline](features/aegra-api.md) | `aegra-api` is the **FastAPI Agent Protocol server** at the heart of TOGa IQ. | talos/libs/aegra-api/src/aegra_api/main.py, talos/libs/aegra-api/src/aegra_api/settings.py, talos/libs/aegra-api/src/aegra_api/config.py, talos/libs/aegra-api/src/aegra_api/api/assistants.py, talos/libs/aegra-api/src/aegra_api/api/threads.py, talos/libs/aegra-api/src/aegra_api/api/runs.py, talos/libs/aegra-api/src/aegra_api/api/store.py, talos/libs/aegra-api/src/aegra_api/api/mcp.py, talos/libs/aegra-api/src/aegra_api/api/knowledge_bases.py, talos/libs/aegra-api/src/aegra_api/core/auth_middleware.py, talos/libs/aegra-api/src/aegra_api/core/auth_deps.py, talos/libs/aegra-api/src/aegra_api/core/tenant_router.py, talos/libs/aegra-api/src/aegra_api/core/control_plane_db.py, talos/libs/aegra-api/src/aegra_api/core/redis_manager.py, talos/libs/aegra-api/src/aegra_api/core/encryption.py, talos/libs/aegra-api/src/aegra_api/middleware/content_type_fix.py, talos/libs/aegra-api/src/aegra_api/middleware/rate_limiter.py, talos/libs/aegra-api/src/aegra_api/middleware/logger_middleware.py, talos/libs/aegra-api/src/aegra_api/services/broker.py, talos/libs/aegra-api/src/aegra_api/services/redis_broker.py, talos/libs/aegra-api/src/aegra_api/services/executor.py, talos/libs/aegra-api/src/aegra_api/services/local_executor.py, talos/libs/aegra-api/src/aegra_api/services/worker_executor.py, talos/libs/aegra-api/src/aegra_api/services/run_executor.py, talos/libs/aegra-api/src/aegra_api/services/langgraph_service.py, talos/libs/aegra-api/src/aegra_api/services/graph_factory.py, talos/libs/aegra-api/src/aegra_api/services/graph_streaming.py, talos/libs/aegra-api/src/aegra_api/services/streaming_service.py, talos/libs/aegra-api/src/aegra_api/services/event_store.py, talos/libs/aegra-api/alembic/env.py |
+| [Deployment — Docker, Compose, Entrypoint, External PG/Redis](features/deployment.md) | TOGa IQ ships as a **single container** (`aegra` service) wrapping the `aegra-api` FastAPI server. | talos/docker-compose.yml, talos/deployments/docker/Dockerfile, talos/deployments/docker/entrypoint.sh |
+| [MCP Servers — clickup-mcp and toga-db-mcp](features/mcp-servers.md) | Two internal **FastMCP** servers exposed over **HTTP** with API-key auth and PM2 process management: - **`clickup-mcp`** — ClickUp workspace surface (spaces / f | talos/mcp-servers/clickup-mcp/src, talos/mcp-servers/clickup-mcp/ecosystem.config.js, talos/mcp-servers/clickup-mcp/ecosystem.dev.config.js, talos/mcp-servers/clickup-mcp/pyproject.toml, talos/mcp-servers/clickup-mcp/.env.example, talos/mcp-servers/toga-db-mcp/src, talos/mcp-servers/toga-db-mcp/clusters.yaml, talos/mcp-servers/toga-db-mcp/ecosystem.config.js, talos/mcp-servers/toga-db-mcp/pyproject.toml, talos/mcp-servers/toga-db-mcp/.env.example |
+| [Observability — Langfuse, OTEL, Prometheus, OneUptime](features/observability.md) | TOGa IQ uses **two complementary tracing planes** plus optional Prometheus metrics and external uptime monitoring: - **Langfuse (native v3 SDK)** — LLM-shaped t | talos/libs/aegra-api/src/aegra_api/observability/__init__.py, talos/libs/aegra-api/src/aegra_api/observability/setup.py, talos/libs/aegra-api/src/aegra_api/observability/base.py, talos/libs/aegra-api/src/aegra_api/observability/langfuse_provider.py, talos/libs/aegra-api/src/aegra_api/observability/langfuse_client.py, talos/libs/aegra-api/src/aegra_api/observability/otel.py, talos/libs/aegra-api/src/aegra_api/observability/metrics.py, talos/libs/aegra-api/src/aegra_api/observability/span_enrichment.py, talos/libs/aegra-api/src/aegra_api/observability/targets |
+| [react_agent — LangGraph ReAct Agent with Plan, BLP, MCP, Canvas](features/react-agent.md) | `react_agent` is the **reference LangGraph agent** shipped under `examples/react_agent/`. | talos/examples/react_agent/graph.py, talos/examples/react_agent/state.py, talos/examples/react_agent/context.py, talos/examples/react_agent/prompts.py, talos/examples/react_agent/tool_router.py, talos/examples/react_agent/model_helpers.py, talos/examples/react_agent/config/context.py, talos/examples/react_agent/config/model_config.py, talos/examples/react_agent/config/tool_config.py, talos/examples/react_agent/config/plan_config.py, talos/examples/react_agent/config/memory_config.py, talos/examples/react_agent/config/mcp_config.py, talos/examples/react_agent/config/blp_config.py, talos/examples/react_agent/config/interrupt_config.py, talos/examples/react_agent/config/artifact_config.py, talos/examples/react_agent/plan/planner.py, talos/examples/react_agent/plan/nodes.py, talos/examples/react_agent/llm/system_prompt.py, talos/examples/react_agent/llm/tool_binding.py, talos/examples/react_agent/llm/message_ops.py, talos/examples/react_agent/mcp/client.py, talos/examples/react_agent/mcp/security.py, talos/examples/react_agent/mcp/session_manager.py, talos/examples/react_agent/blp/registry.py, talos/examples/react_agent/blp/embedder.py, talos/examples/react_agent/blp/nodes.py, talos/examples/react_agent/tools/__init__.py, talos/examples/react_agent/tools/code_interpreter.py, talos/examples/react_agent/tools/canvas.py, talos/examples/react_agent/tools/knowledge_base.py, talos/examples/react_agent/tools/skill_injector.py, talos/examples/react_agent/thread_name/nodes.py |