toga-ai 1.0.755 → 1.0.757

package/.claude/settings.json

@@ -112,6 +112,36 @@
             "timeout": 3000
           }
         ]
+      },
+      {
+        "matcher": "Write|Edit|MultiEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/toga/remind-frontend-review.js\"",
+            "timeout": 3000
+          }
+        ]
+      },
+      {
+        "matcher": "Write|Edit|MultiEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/toga/sql-cross-cluster-check.js\"",
+            "timeout": 3000
+          }
+        ]
+      },
+      {
+        "matcher": "Write|Edit|MultiEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/toga/dbchanges2-file-sprawl.js\"",
+            "timeout": 3000
+          }
+        ]
       }
     ],
     "SessionStart": [

package/knowledge/1.0/apps/tools/features/oneuptime-monitor-status-panel.md

@@ -6,7 +6,7 @@ project: Tools
 client: shared
 type: feature
 status: active
-updated: 2026-08-19
+updated: 2026-09-03
 owners: [kyalamarthi, jcardinal]
 files:
   - tools/assets/clickup/sprint-dashboard.html
@@ -119,6 +119,15 @@ Status bucketing is **derived, not hardcoded**: `isOperationalState` → good; w
 non-operational → offline/critical; anything between → degraded. A renamed or new status still
 buckets correctly.
 
+**Display label — the UI never shows the word "Offline"; it shows "Outage".** OneUptime's API
+still returns the status name "Offline" and the good/degraded/critical bucketing (from
+`isOperationalState`, not the name) is untouched — the swap is a **display-layer** transform only.
+A helper `outageLabel(name)` replaces the whole word "Offline" (case-insensitive) with "Outage"
+at the per-monitor subtext render (`r.statusName`), so live and dev mock-mode rows match. The two
+hardcoded critical-state labels also read **"OUTAGE"**: the alert popup title (was "OFFLINE") and
+the top-right main band. "DEGRADED" (warning) and "OPERATIONAL" (good) are unchanged. Do not
+rename the raw OneUptime status or the server proxy data to achieve this.
+
 ### Panel presentation — state-adaptive (supersedes the solid status circle)
 
 The old design (a solid `MonitorCircle`, a per-status legend with counts + percentages, and a
@@ -258,6 +267,11 @@ so a reduced-motion viewer never lands on a fully-invisible glow.
   `.alert-flash`, this same rule also covers the slow `alert-breathe` breathe.
 
 ## Change history
+- 2026-09-03 — UI now shows **"Outage" instead of "Offline"** everywhere. Added a display-layer
+  `outageLabel(name)` helper (whole-word, case-insensitive) applied at the per-monitor subtext
+  render (`r.statusName`, two spots, covers dev mock rows); set the alert popup title "OFFLINE" →
+  "OUTAGE" (top-right band already "OUTAGE"). Raw OneUptime status names and the good/degraded/
+  critical role bucketing (from `isOperationalState`) are untouched — display-only. (jcardinal)
 - 2026-08-19 — Removed the monitor panel header entirely. The `mon-head` block — the "Status"
   title (`mon-title`) and the "live · updated Xs ago" meta line (`mon-meta`) — was dropped from
   `MonitorPanel`, together with the now-unused `meta` computation and the `okAt` prop. `now =

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

@@ -72,6 +72,20 @@ team-maintained `id`s** — ask the developer for the next value before insertin
 > 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.
 
+## One file per type per build (keep change files consolidated)
+
+**Prefer a single `.sql` file per database type (folder) per build.** When a session produces
+several changes for the same target — e.g. three separate files under `Core/`, or four under
+`Client/` — **consolidate them into one dated file** for that folder instead. Multiple same-type
+files in one build are not forbidden, but they have become too common; keep it to one per type
+unless they genuinely must be separate (for example, an ordering gap where another folder's file
+must run between them).
+
+- Combine same-folder statements into one `YYYY-MM-DD<letter> - <Description>.sql`.
+- Different folders (types) stay in their own files — that split is required (see isolation).
+- The `dbchanges2-file-sprawl` hook warns when a second file of the same type is created in a
+  session, as a reminder to consolidate.
+
 ## Folder → database mapping
 
 Each top-level folder targets a database or a **fan-out set** of databases. Tenant naming

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "toga-ai",
-  "version": "1.0.755",
+  "version": "1.0.757",
   "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/rules/common/auto-review.md

@@ -0,0 +1,48 @@
+# Auto-Review Rules
+
+After you write or change code, run the right reviewer yourself — **as a sub-agent** — before
+you call the work done. The developer should not have to ask. Running reviews off the main
+thread also keeps the main conversation small.
+
+## Run the matching reviewer — always, automatically
+
+| You wrote… | Run this reviewer (as a sub-agent) |
+|---|---|
+| PHP | `php-reviewer` (TOGA) |
+| A **new** PHP class | also `framework-pattern-checker` (TOGA) |
+| SQL — a `.sql` file, or SQL inside PHP | `sql-reviewer` (TOGA) |
+| React — `.jsx` / `.tsx` | `ecc:react-reviewer` |
+| TypeScript (non-React) — `.ts` | `ecc:typescript-reviewer` |
+| Anything touching auth, user input, credentials, or queries | also `cso` (security) |
+
+Rules:
+
+- **Run it in a sub-agent, not the main thread.** Run independent reviews at the same time
+  (one message, several agents) so the main conversation stays lean.
+- **Run it before you commit, ship, or say "done".** If it finds real problems, fix them and
+  re-run until it is clean.
+- **The reviewer must check the code against our team standards** — the rules in `rules/` and
+  the standards in the knowledge base. Point it at the standard for that language. For SQL that
+  includes the escaping rules and the "never mix two database families in one query" rule
+  (see `security.md` and the `_underscore` / `dbchanges2` architecture docs).
+- **Opt-out:** if the developer says "skip review", skip it for that change. Otherwise it runs
+  on its own.
+
+## Get a CTO second opinion for moderate or bigger changes
+
+Run the `cto` agent for an independent second opinion — on your own, in a sub-agent — when a
+change is **moderate or complex**. That means any of:
+
+- it touches more than ~2 files,
+- it is a schema or migration change (`dbchanges` / `dbchanges2`),
+- it is a new feature, or
+- it is hard to undo (a data migration, an API or contract change, an architecture choice).
+
+Do this **before you finalize the approach** — for a design choice, before you write the code.
+The developer should not have to ask for it.
+
+## Why
+
+These reviews and the CTO opinion catch framework breaks, security holes, and bad calls before
+they ship. Making them automatic — and running them off the main thread — means the developer
+gets the safety without asking, and the main conversation stays small.

package/rules/common/communication.md

@@ -73,21 +73,34 @@ back to dense wording and teammates missed critical details. To stop that, a hoo
 - The hook is wired in `.claude/settings.json` and ships to every repo on `npx toga-ai`.
 - It never blocks anything; it only nudges. To silence it, set `TOGA_PLAIN_TALK_DISABLED=1`.
 
-## Remember each person across sessions
-
-The "mirror the person" rule (rule 7) only sees the current session. That is not enough —
-you should learn how each developer likes to be talked to and remember it **for good**, so
-they never have to tell you twice. Use the developer's **local Claude memory** for this.
-
-- **Keep a per-person communication profile in local memory** — e.g. a `user`-type memory
-  named `user-communication-profile`. It loads at the start of every session, so you apply
-  their known style before you write a word.
-- **Save a preference the moment they state it — do not wait to be asked.** If a developer
-  says "speak plainly", "don't use the word X", "keep it short", or corrects your wording,
-  write it into their profile right then. An explicit preference is the strongest signal.
-- **At `/capture`, review and update the profile** with any clear new pattern in how they
-  communicated this session (see the capture skill's step for this).
-- **Only record clear signals.** Prefer what they say directly over what you infer. Keep the
-  note short and readable; a wrong guess is worse than no guess.
-- **This profile is private and per-person. Never put it in the team knowledge base** — it
-  lives only in that developer's local memory, on their machine.
+## Remember each person across sessions — style AND how they like to work
+
+The "mirror the person" rule (rule 7) only sees the current session. That is not enough.
+Actively learn how each developer likes to be talked to **and how they like you to work**, and
+remember it **for good**, so they never have to tell you twice. Store it in the developer's
+**local Claude memory**. Build this profile on purpose — do not wait to be asked to remember.
+
+Capture **two** kinds of things:
+
+1. **How they like to be talked to** — plain vs detailed, short vs long, words to avoid, tone.
+2. **How they like you to work** — the standing habits they expect every session. For example:
+   - checks they always want run (a lint, a specific review, a security pass, a test),
+   - tools or commands they prefer, or forbid,
+   - how they want results shown (deploy steps first, SQL file + order, and so on),
+   - workflow do's and don'ts ("don't commit unless I say so", "investigate before asking me",
+     "always run the DB query yourself").
+
+How to keep it:
+
+- **Save it the moment they state it — don't wait to be asked.** An explicit preference, or a
+  correction of something you did, is the strongest signal. Write it down right then.
+- **At `/capture`, review and update** with any clear new pattern from the session (see the
+  capture skill's step for this).
+- **Only record clear signals.** Prefer what they say directly over what you infer. Keep each
+  note short; a wrong guess is worse than no guess.
+- **Store it as local memory, per person.** A `user`-type note like `user-communication-profile`
+  holds the talking style; work habits are their own memory notes (one habit per note, the way
+  the memory system already loads them every session). Both load at session start, so you apply
+  the developer's known style and habits before you write a word.
+- **This profile is private and per-person. Never put it in the team knowledge base** — it lives
+  only in that developer's local memory, on their machine.

package/rules/common/security.md

@@ -73,6 +73,25 @@ One caveat on 2.0's helpers: `_Database::escape()` is the correct one. Do **not*
 `_Database::protect()`, which *strips* `% \ / * " '` and the literal ` or` — lossy filtering, not
 escaping, and it will corrupt data you meant to store intact.
 
+## Never query across database clusters (2.0)
+
+In 2.0 the database families live on **separate production clusters**: `Core` / `Forecast` /
+`Team` (prod-core), `Client_<Tenant>` (prod-client), `Archive_<Tenant>` (prod-archive), and
+`Logs` / `Logs_<Tenant>` (prod-logs). A single SQL statement that joins or sub-selects across
+two families **cannot run in production** — the other database is on a different server. It
+works locally only because every database shares one endpoint there, so the break shows up
+only after release.
+
+- **Never mix two database families (e.g. `Core` and a `Client_<Tenant>` DB) in one query.**
+  Keep every query inside one database.
+- To use data from another family, reference it by a stable **id / uuid / slug** and assemble
+  the result in **PHP across two `_Database` connections** — one per family — never in one SQL
+  statement.
+- In `dbchanges2` this is a **hard rule**, blocked by the `dbchanges2-cluster-isolation` hook.
+  In app code (hand-written SQL) it is not blocked, but the `sql-cross-cluster-check` hook
+  warns, and the `sql-reviewer` must flag it. See the `_underscore` and `dbchanges2`
+  architecture docs.
+
 ## XSS prevention
 
 Never output user-supplied data to HTML without escaping.

package/scripts/hooks/dbchanges2-file-sprawl.js

@@ -0,0 +1,106 @@
+#!/usr/bin/env node
+'use strict';
+
+/*
+ * dbchanges2-file-sprawl.js — WARNS when more than one dbchanges2 .sql file of the
+ * SAME type (same target folder) is created in a session.
+ *
+ * WHY: we have seen builds emit 3–4 separate Client (or Core) change files in one
+ * conversation. It is not fatal, but it is too much, too often. The standard now
+ * asks for one file per type per build — consolidate same-type changes into a
+ * single dated file unless they truly must be separate. This hook nudges toward
+ * that; it never blocks.
+ *
+ * "Type" = the top-level folder under dbchanges2 (Core, Logs, Client,
+ * Client_<Name>, Logs_Client, _modules/<module>) — the same buckets the isolation
+ * hook uses. Two different Client_<Name> folders are different types (different
+ * client databases); two files in Core/ are the same type.
+ *
+ * Session state is a small JSON file in the OS temp dir keyed by the parent pid,
+ * mapping type -> [file paths seen]. Fail-open; never blocks.
+ *
+ * Escape hatch: DBCHANGES2_SPRAWL_DISABLED=1
+ */
+
+const fs = require('fs');
+const os = require('os');
+const path = require('path');
+
+function readPayload() {
+  let raw = '';
+  try { raw = fs.readFileSync(0, 'utf8'); } catch (e) { /* no stdin */ }
+  let data = {};
+  if (raw && raw.trim()) {
+    try { data = JSON.parse(raw); } catch (e) { data = {}; }
+  }
+  if (!data.tool_name && process.env.CLAUDE_TOOL_NAME) data.tool_name = process.env.CLAUDE_TOOL_NAME;
+  if (!data.tool_input && process.env.CLAUDE_TOOL_INPUT) {
+    try { data.tool_input = JSON.parse(process.env.CLAUDE_TOOL_INPUT); } catch (e) {}
+  }
+  if (!data.session_id) data.session_id = process.env.CLAUDE_SESSION_ID || process.env.CLAUDE_CODE_SESSION_ID;
+  return data;
+}
+
+/* Key session state on the CC session id (stable for the whole session), not
+ * process.ppid — on Windows git-bash ppid varies per spawn, so it is a last resort. */
+function sessionKey(data) {
+  const sid = (data && data.session_id) || String(process.ppid || process.pid);
+  return String(sid).replace(/[^A-Za-z0-9_-]/g, '').slice(0, 64) || 'x';
+}
+
+/* Type bucket = first path segment after /dbchanges2/. Null if not a dbchanges2 file. */
+function resolveType(filePath) {
+  const norm = filePath.replace(/\\/g, '/');
+  const m = norm.match(/(?:^|\/)dbchanges2\/(.+)$/i);
+  if (!m) return null;
+  const rel = m[1];
+  if (/\/HISTORIC\//i.test(norm)) return null;           // archive, never executed
+  const seg = rel.split('/')[0];
+  if (!seg || seg === rel) return null;                  // file at repo root, no folder
+  if (/^_modules$/i.test(seg)) {
+    const parts = rel.split('/');
+    return parts[1] ? '_modules/' + parts[1] : '_modules';
+  }
+  return seg;
+}
+
+function stateFile(key) {
+  return path.join(os.tmpdir(), 'toga-dbchanges2-sprawl-' + key + '.json');
+}
+
+function main() {
+  if (process.env.DBCHANGES2_SPRAWL_DISABLED === '1') return;
+
+  const data = readPayload();
+  if (!/^(Write|Edit|MultiEdit)$/.test(data.tool_name || '')) return;
+
+  const input = data.tool_input || {};
+  const filePath = typeof input.file_path === 'string' ? input.file_path : '';
+  if (!/\.sql$/i.test(filePath)) return;
+
+  const type = resolveType(filePath);
+  if (!type) return;
+
+  const normPath = filePath.replace(/\\/g, '/');
+  const sf = stateFile(sessionKey(data));
+  let state = {};
+  try { state = JSON.parse(fs.readFileSync(sf, 'utf8')) || {}; } catch (e) { state = {}; }
+
+  const seen = Array.isArray(state[type]) ? state[type] : [];
+  if (seen.includes(normPath)) return;                   // same file touched again — not a new file
+  seen.push(normPath);
+  state[type] = seen;
+  try { fs.writeFileSync(sf, JSON.stringify(state)); } catch (e) { /* non-fatal */ }
+
+  if (seen.length >= 2) {
+    console.log(
+      'DBCHANGES2 FILE SPRAWL: this is the ' + seen.length + ' "' + type + '" change file this ' +
+      'session. Standard is ONE file per type per build — prefer consolidating same-type changes ' +
+      'into a single dated file unless they genuinely must be separate (e.g. ordering that needs a ' +
+      'gap). Files so far for ' + type + ':\n' + seen.map((p) => '    ' + p.split('/').pop()).join('\n') +
+      '\nSee knowledge/2.0/apps/dbchanges2/architecture.md → "One file per type per build".'
+    );
+  }
+}
+
+try { main(); } catch (e) { /* fail-open */ }

package/scripts/hooks/plain-talk.js

@@ -57,10 +57,12 @@ function reminder() {
     'register. Reuse their own terms for things. Match their length: if they write short,',
     'you write short. Never fake misspellings or bad grammar; be natural, just familiar.',
     '',
-    'REMEMBER THEM ACROSS SESSIONS: this developer may have a saved communication profile in',
-    'their local Claude memory (e.g. user-communication-profile) — apply it. If they state a',
-    'preference (a word to avoid, a length, a tone), save it to that profile right away so it',
-    'persists to the next session; do not make them tell you twice.',
+    'REMEMBER THEM ACROSS SESSIONS: this developer has a saved profile in their local Claude',
+    'memory — how they like to be talked to (e.g. user-communication-profile) AND how they like',
+    'you to work (standing checks, preferred/forbidden tools, workflow do\'s and don\'ts, saved',
+    'as memory notes). Apply it. If they state any preference — a word to avoid, a length, a',
+    'tone, a check they always want, a habit — save it to memory right away so it persists to',
+    'the next session; do not make them tell you twice.',
     '',
     'Before you send: could you cut half the words and keep the meaning? Is any word too',
     'rare for a non-native reader? Is the main point on the first line?',

package/scripts/hooks/remind-frontend-review.js

@@ -0,0 +1,39 @@
+'use strict';
+
+/*
+ * PostToolUse (Write|Edit|MultiEdit) hook: front-end review reminder.
+ *
+ * PHP and SQL already have review reminders (remind-php-review.js,
+ * remind-sql-review.js). This covers the gap: React and TypeScript. When a write
+ * touches a React (.jsx/.tsx) or TypeScript (.ts) file, it emits a directive to
+ * run the matching reviewer AS A SUB-AGENT before the change is done. A
+ * deterministic hook cannot spawn the (LLM) reviewer itself, so it forces the
+ * routing instead. See rules/common/auto-review.md.
+ *
+ * Plain .js/.mjs/.cjs is intentionally NOT matched — in this codebase that is
+ * mostly tooling, config, and hook scripts, so reminding on it would be noise.
+ *
+ * Escape hatch: TOGA_FRONTEND_REVIEW_DISABLED=1
+ */
+
+if (process.env.TOGA_FRONTEND_REVIEW_DISABLED === '1') process.exit(0);
+
+const input = (() => {
+  try { return JSON.parse(process.env.CLAUDE_TOOL_INPUT || '{}'); } catch { return {}; }
+})();
+
+const filePath = typeof input.file_path === 'string' ? input.file_path : '';
+
+if (/\.(jsx|tsx)$/i.test(filePath)) {
+  console.log(
+    'REACT file edited (' + filePath + '). You MUST run the ecc:react-reviewer agent ' +
+    '(as a sub-agent) on this change before treating it as done — hook correctness, render ' +
+    'performance, server/client boundaries, and our team standards. See rules/common/auto-review.md.'
+  );
+} else if (/\.ts$/i.test(filePath)) {
+  console.log(
+    'TYPESCRIPT file edited (' + filePath + '). You MUST run the ecc:typescript-reviewer agent ' +
+    '(as a sub-agent) on this change before treating it as done — type safety, async correctness, ' +
+    'and our team standards. See rules/common/auto-review.md.'
+  );
+}

package/scripts/hooks/scope-counter.js

@@ -2,11 +2,30 @@
 const os = require('os');
 const fs = require('fs');
 const path = require('path');
-const scopeFile = path.join(os.tmpdir(), 'toga-scope-' + (process.ppid || process.pid) + '.count');
+
+/* Key the per-session counter on the CC session id — stable for the whole session
+ * and passed to hooks on stdin (and often in env). process.ppid is NOT reliable as
+ * a session key (on Windows git-bash it varies per spawn), so it is only the last
+ * resort. */
+function sessionKey() {
+  let sid = '';
+  try {
+    const raw = fs.readFileSync(0, 'utf8');
+    if (raw && raw.trim()) sid = JSON.parse(raw).session_id || '';
+  } catch (e) { /* no stdin */ }
+  sid = sid || process.env.CLAUDE_SESSION_ID || process.env.CLAUDE_CODE_SESSION_ID ||
+    String(process.ppid || process.pid);
+  return sid.replace(/[^A-Za-z0-9_-]/g, '').slice(0, 64) || 'x';
+}
+
+const scopeFile = path.join(os.tmpdir(), 'toga-scope-' + sessionKey() + '.count');
 let count = 0;
 try { count = parseInt(fs.readFileSync(scopeFile, 'utf8').trim(), 10) || 0; } catch {}
 count += 1;
 try { fs.writeFileSync(scopeFile, String(count)); } catch {}
+if (count === 3) {
+  console.log('MODERATE CHANGE: 3 files modified this session. Per rules/common/auto-review.md, for a moderate or bigger code change get a CTO second opinion on the approach (cto agent, as a sub-agent) before finalizing — unless the developer said to skip it.');
+}
 if (count >= 20) {
   console.log('SCOPE WARNING: ' + count + ' files modified this session. Consider whether changes are too scattered.');
 }

package/scripts/hooks/sql-cross-cluster-check.js

@@ -0,0 +1,118 @@
+#!/usr/bin/env node
+'use strict';
+
+/*
+ * sql-cross-cluster-check.js — best-effort WARNING when one piece of code
+ * references two different 2.0 database families in what looks like a single
+ * query.
+ *
+ * WHY: in production the 2.0 database families live on SEPARATE clusters — Core /
+ * Forecast / Team, Client_<Tenant>, Archive_<Tenant>, Logs / Logs_<Tenant>, Cache.
+ * A query that joins or sub-selects across two of them cannot resolve in
+ * production; it only works locally, where every database shares one endpoint. So
+ * a query must stay inside ONE database; cross-family data is assembled in PHP
+ * across two connections, referencing the other side by id / uuid / slug.
+ *
+ * SCOPE: this covers HAND-WRITTEN SQL in app code (.php) and .sql files OUTSIDE
+ * dbchanges2. dbchanges2 .sql files are HARD-BLOCKED by
+ * dbchanges2-cluster-isolation.js — this hook deliberately skips them. Here a hard
+ * block would be too blunt (a .php file legitimately runs separate queries on
+ * separate connections), so this only WARNS. The sql-reviewer is still expected to
+ * confirm.
+ *
+ * Fail-open; never blocks. Disable: SQL_CROSS_CLUSTER_DISABLED=1
+ */
+
+const fs = require('fs');
+
+function readPayload() {
+  let raw = '';
+  try { raw = fs.readFileSync(0, 'utf8'); } catch (e) { /* no stdin */ }
+  let data = {};
+  if (raw && raw.trim()) {
+    try { data = JSON.parse(raw); } catch (e) { data = {}; }
+  }
+  if (!data.tool_name && process.env.CLAUDE_TOOL_NAME) data.tool_name = process.env.CLAUDE_TOOL_NAME;
+  if (!data.tool_input && process.env.CLAUDE_TOOL_INPUT) {
+    try { data.tool_input = JSON.parse(process.env.CLAUDE_TOOL_INPUT); } catch (e) {}
+  }
+  return data;
+}
+
+const DB_FAMILIES = ['Core', 'Client', 'Logs', 'Archive', 'Cache', 'Team', 'Forecast'];
+
+/* Blank ONLY comments — NOT string literals. In PHP the SQL we need to inspect
+ * lives inside quoted strings, so stripping strings (as the dbchanges2 .sql hook
+ * does) would erase the very query we are checking. Keeping strings can add a rare
+ * false positive from a DB name mentioned in an unrelated string, which is fine for
+ * a warning. Newlines preserved so line numbers still match. */
+function stripComments(sql) {
+  const blanked = (m) => m.replace(/[^\n]/g, ' ');
+  return sql
+    .replace(/\/\*[\s\S]*?\*\//g, blanked)   // /* block */
+    .replace(/\/\/[^\n]*/g, blanked)         // // line (php)
+    .replace(/--[ \t][^\n]*/g, blanked)      // -- line (sql)
+    .replace(/(^|[^\w$])#[^\n]*/g, (m) => (m[0] === '#' ? blanked(m) : m[0] + blanked(m.slice(1)))); // # line
+}
+
+/* Distinct qualified database references, e.g. `Core`.`Records`, Client_Aig.SalesOrders. */
+function findQualifiedDbs(sql) {
+  const code = stripComments(sql);
+  const names = DB_FAMILIES.join('|');
+  const re = new RegExp(
+    '`?\\b((?:' + names + ')(?:_[A-Za-z0-9]+)?)`?\\s*\\.\\s*`?[A-Za-z_][A-Za-z0-9_]*`?',
+    'g'
+  );
+  const seen = new Map(); // full db name -> first matched text
+  let hit;
+  while ((hit = re.exec(code)) !== null) {
+    if (!seen.has(hit[1])) seen.set(hit[1], hit[0].trim());
+  }
+  return seen;
+}
+
+function collectNewText(inp) {
+  const parts = [];
+  if (typeof inp.content === 'string') parts.push(inp.content);
+  if (typeof inp.new_string === 'string') parts.push(inp.new_string);
+  if (Array.isArray(inp.edits)) {
+    for (const e of inp.edits) if (e && typeof e.new_string === 'string') parts.push(e.new_string);
+  }
+  return parts.join('\n');
+}
+
+function main() {
+  if (process.env.SQL_CROSS_CLUSTER_DISABLED === '1') return;
+
+  const data = readPayload();
+  if (!/^(Write|Edit|MultiEdit)$/.test(data.tool_name || '')) return;
+
+  const input = data.tool_input || {};
+  const filePath = typeof input.file_path === 'string' ? input.file_path : '';
+  const norm = filePath.replace(/\\/g, '/');
+
+  if (/(?:^|\/)dbchanges2\//i.test(norm)) return;        // hard-blocked elsewhere
+  if (!/\.(php|sql)$/i.test(norm)) return;
+
+  const text = collectNewText(input);
+  if (!text.trim()) return;
+
+  const dbs = findQualifiedDbs(text);
+  if (dbs.size < 2) return;                              // one (or zero) DB referenced — fine
+
+  const list = [...dbs.entries()].slice(0, 10)
+    .map(([db, ex]) => '    ' + ex + '   ← database ' + db)
+    .join('\n');
+
+  console.log(
+    'POSSIBLE CROSS-CLUSTER SQL in ' + (filePath || 'this edit') + '. This code references ' +
+    dbs.size + ' different database families:\n' + list + '\n' +
+    'In production these families are on SEPARATE clusters, so a single query spanning them ' +
+    'cannot resolve there — it only works locally. VERIFY each query stays inside ONE database. ' +
+    'If you need data from another family, reference it by id / uuid / slug and assemble the ' +
+    'result in PHP across two _Database connections — never in one SQL statement. Then run the ' +
+    'sql-reviewer agent to confirm. See security.md → "Never query across database clusters".'
+  );
+}
+
+try { main(); } catch (e) { /* fail-open */ }

package/skills/capture/SKILL.md

@@ -155,24 +155,29 @@ Relay the subagent's final report to the developer: what was written, the publis
 standards/architecture). If the subagent reported everything was NO-OP, relay: "Nothing here
 is durable team knowledge — KB unchanged."
 
-## Step 6 — Update how to talk to this developer (local memory, private — never pushed)
-
-Capture is also when you record **how the developer likes to be communicated with**, so the
-next session already knows. This is a **main-thread, LOCAL memory** action — it never touches
-`knowledge/` and is never pushed to the team repo. (See "Remember each person across
-sessions" in `rules/common/communication.md`.)
-
-1. Look back at how the developer communicated this session — the words they used, the length
-   and tone they preferred, and any preference they stated ("speak plainly", "don't use the
-   word X", "keep it short") or any wording of yours they corrected.
-2. Update their per-person profile in **local Claude memory** (a `user`-type memory named
-   `user-communication-profile`, plus its `MEMORY.md` pointer). Add any clear new signal;
-   don't duplicate what's already there.
-3. **Only record clear signals** — prefer what they said directly over what you infer. Keep
-   the note short and readable. If nothing new came up, do nothing.
-
-An explicit preference should already have been saved the moment it was stated; this step is
-the backstop that also catches patterns.
+## Step 6 — Update the developer's profile: how to talk to them AND how they like to work (local memory, private — never pushed)
+
+Capture is also when you record **how the developer likes to be communicated with, and how they
+like you to work**, so the next session already knows. This is a **main-thread, LOCAL memory**
+action — it never touches `knowledge/` and is never pushed to the team repo. (See "Remember each
+person across sessions" in `rules/common/communication.md`.)
+
+1. Look back at the session for **two** kinds of signal:
+   - **Talking style** — the words they used, the length and tone they preferred, any preference
+     they stated ("speak plainly", "don't use the word X", "keep it short") or any wording of
+     yours they corrected.
+   - **Working habits** — standing things they expect every session: checks they always want run
+     (a lint, a review, a test), tools or commands they prefer or forbid, how they want results
+     shown (deploy steps first, SQL file + order), and workflow do's and don'ts ("don't commit
+     unless I say so", "investigate before asking me", "run the DB query yourself").
+2. Update their profile in **local Claude memory** — talking style in a `user`-type note named
+   `user-communication-profile`; each working habit as its own memory note (with its `MEMORY.md`
+   pointer). Add any clear new signal; don't duplicate what's already there.
+3. **Only record clear signals** — prefer what they said directly over what you infer. Keep the
+   notes short. If nothing new came up, do nothing.
+
+Anything they stated explicitly should already have been saved the moment it was said; this step
+is the backstop that also catches patterns.
 
 ### After Capture
 

package/skills/kickoff/SKILL.md

@@ -410,7 +410,16 @@ loaded here.
 After priming, analyze what the developer is building and **propose a concrete plan
 before writing code**. The plan's *shape* depends on size — and the default for anything
 non-trivial is to **orchestrate specialist subagents**, not to do everything in this
-thread. This keeps the main conversation as the orchestrator (light, durable) while the
+thread.
+
+> **Standing directive — auto-review and CTO (see `rules/common/auto-review.md`).** After you
+> write code, run the matching reviewer yourself **as a sub-agent**, before you call it done —
+> PHP → `php-reviewer`, SQL → `sql-reviewer`, React (`.jsx`/`.tsx`) → `ecc:react-reviewer`,
+> TypeScript (`.ts`) → `ecc:typescript-reviewer`, a new PHP class → also
+> `framework-pattern-checker`; anything touching auth/input/credentials/queries → also `cso`.
+> For a **moderate or bigger** change (more than ~2 files, a schema/migration, a new feature,
+> or a hard-to-undo choice) get a `cto` second opinion on the approach first. The developer
+> should not have to ask. Keep all of this off the main thread. This keeps the main conversation as the orchestrator (light, durable) while the
 heavy reading/writing/verifying happens in subagents — the same discipline as Step 4.
 
 The developer does not know what "sub-agents" or "loops" are — never use that jargon.