toga-ai 1.0.43 → 1.0.45

package/knowledge/clients/compass-canada/profile.md

@@ -1,6 +1,5 @@
 ---
 title: Compass Canada
-name: "Compass Canada"
 framework: "2.0"
 project: _Underscore
 client: compass-canada

package/knowledge/clients/compass-usa/profile.md

@@ -1,6 +1,5 @@
 ---
 title: Compass USA
-name: "Compass USA"
 framework: "2.0"
 project: _Underscore
 client: compass-usa

package/knowledge/clients/elite/INDEX.md

@@ -2,4 +2,4 @@
 
 | Doc | Framework | Summary | Files |
 |-----|-----------|---------|-------|
-| [Elite Client Profile](profile.md) | 2.0 | Elite is a managed-services client that uses **Freshservice** as their helpdesk platform. | worker2/Worker/Elite.php, library/app/api/toga2.php |
+| [Elite](profile.md) | 2.0 | Elite is a managed-services client that uses **Freshservice** as their helpdesk platform. | worker2/Worker/Elite.php, library/app/api/toga2.php |

package/knowledge/clients/elite/profile.md

@@ -1,6 +1,5 @@
 ---
-title: Elite Client Profile
-name: "Elite"
+title: Elite
 framework: "2.0"
 project: Worker
 client: elite

package/knowledge/clients/nycdoe/INDEX.md

@@ -3,4 +3,4 @@
 | Doc | Framework | Summary | Files |
 |-----|-----------|---------|-------|
 | [NYCDOE ServiceNow / ASN Integration](features/servicenow-integration.md) | 1.0 | The NYCDOE/ServiceNow integration mirrors DOE's ServiceNow tickets (Incidents + RITMs) into local tables, turns vendor shipment notices into NetSuite Sales Orde | worker/crons/sync/nycdoe/import_asn.php, worker/crons/sync/nycdoe/import_inc.php, worker/crons/sync/nycdoe/legacy_import_asn.php, worker/crons/sync/nycdoe/legacy_process_asn_queue.php, worker/crons/sync/nycdoe/process_tickets.php, worker/crons/sync/nycdoe/1_send_asn_to_netsuite.php, worker/crons/sync/nycdoe/2_send_serials_to_netsuite.php, worker/crons/sync/nycdoe/3_create_installation_ticket.php, worker/crons/sync/nycdoe/send_ticket_updates.php, worker/crons/sync/nycdoe/send_request_item_updates.php, worker/crons/sync/nycdoe/send_nycdoe_proof_of_delivery.php, worker/crons/sync/nycdoe/sync_nycdoe_locations.php, worker/crons/sync/nycdoe/receive_edi_purchase_orders.php, worker/crons/sync/nycdoe/send_edi_open_invoices.php, worker/crons/notifications/nycdoe/, worker/schedules/cron.worker.sync.json, worker/schedules/cron.worker.notification.json, library/app/api/nycdoe.php, library/app/api/nycdoev2.php, library/app/asnprocessor/manufacturer.php, library/app/edi.php |
-| [NYC DOE (New York City Department of Education)](profile.md) | 1.0 | NYC DOE (New York City Department of Education) is a TOGA client whose entire integration runs in the **1.0 worker tier** (~30 cron scripts under `worker/crons/ |  |
+| [New York City Department of Education](profile.md) | 1.0 | NYC DOE (New York City Department of Education) is a TOGA client whose entire integration runs in the **1.0 worker tier** (~30 cron scripts under `worker/crons/ |  |

package/knowledge/clients/nycdoe/profile.md

@@ -1,6 +1,5 @@
 ---
-title: NYC DOE (New York City Department of Education)
-name: "New York City Department of Education"
+title: New York City Department of Education
 framework: "1.0"
 project: Worker
 client: nycdoe

package/knowledge/clients/prudential/INDEX.md

@@ -3,4 +3,4 @@
 | Doc | Framework | Summary | Files |
 |-----|-----------|---------|-------|
 | [Prudential: Dell ASN units PRE/POST interceptor (legacy key + flat tracking)](features/dell-asn-units-interceptor.md) | 2.0 | After the tracking-number bridge migration, the ASN unit route was renamed (`advance-shipping-notice-units` → `advance-shipping-notice-item-units`), so the inhe | _underscore/Model/Prudential/AdvanceShippingNotice.php, dbchanges2/Client_Prudential/2026-06-10 - AsnUnitsInterceptor.sql |
-| [Prudential](profile.md) | 2.0 | Prudential is a TOGA client whose device-fulfillment flow is driven by **Dell** via the Dell API (`Client_Prudential.Apis.id = 2`). |  |
+| [Prudential Financial](profile.md) | 2.0 | Prudential is a TOGA client whose device-fulfillment flow is driven by **Dell** via the Dell API (`Client_Prudential.Apis.id = 2`). |  |

package/knowledge/clients/prudential/profile.md

@@ -1,6 +1,5 @@
 ---
-title: Prudential
-name: "Prudential Financial"
+title: Prudential Financial
 framework: "2.0"
 project: _Underscore
 client: prudential

package/knowledge.js

@@ -145,6 +145,31 @@ function coreReposFor(registry, framework) {
     return registry.filter(r => r.framework === framework && r.role === 'core').map(r => r.repo);
 }
 
+/* ------------------------------------------------------------------ */
+/* command: manifest — compact pickable lists for kickoff (one call,   */
+/* no profile reads). Prints minified JSON {repos:[...],clients:[...]}. */
+/* ------------------------------------------------------------------ */
+
+function cmdManifest() {
+    const registry = loadRegistry();
+    const repos = registry.map(r => ({ repo: r.repo, project: r.project, framework: r.framework, role: r.role }));
+    const clients = [];
+    const clientsDir = path.join(ROOT, 'clients');
+    if (fs.existsSync(clientsDir)) {
+        for (const slug of fs.readdirSync(clientsDir, { withFileTypes: true }).filter(e => e.isDirectory()).map(e => e.name)) {
+            const profile = path.join(clientsDir, slug, 'profile.md');
+            let title = slug, framework = '';
+            if (fs.existsSync(profile)) {
+                const { data } = parseFrontmatter(fs.readFileSync(profile, 'utf8'));
+                title = data.title || slug;
+                framework = data.framework || '';
+            }
+            clients.push({ slug, title, framework });
+        }
+    }
+    console.log(JSON.stringify({ repos, clients }));
+}
+
 /* ------------------------------------------------------------------ */
 /* command: deps                                                       */
 /* ------------------------------------------------------------------ */
@@ -258,7 +283,7 @@ function cmdIndex() {
             const clientDir = path.join(clientsDir, client);
             const clientDocs = docs.filter(d => d.file.startsWith(clientDir + path.sep));
             const profileDoc = clientDocs.find(d => path.basename(d.file) === 'profile.md');
-            const formalName = (profileDoc && profileDoc.data.name) || client;
+            const formalName = (profileDoc && profileDoc.data.title) || client;
             clientFormalNames[client] = formalName;
             const lines = [
                 `# Client: ${formalName} \`${client}\``,
@@ -344,7 +369,6 @@ function cmdValidate() {
         const isClientDoc = d.rel.startsWith('clients/');
         if (isClientDoc) {
             if (!d.data.client || d.data.client === 'shared') { fail(`${d.rel}: client doc must set a real "client"`); ok = false; }
-            if (path.basename(d.rel) === 'profile.md' && !d.data.name) { fail(`${d.rel}: client profile must set a formal "name" (e.g. name: "Compass USA")`); ok = false; }
         } else {
             // framework/apps doc: framework + repo must match the path
             const parts = d.rel.split('/'); // <fw>/apps/<repo>/...  OR <fw>/standards/...
@@ -380,8 +404,9 @@ function main() {
         case 'index': return cmdIndex();
         case 'deps': return cmdDeps(args);
         case 'validate': return cmdValidate();
+        case 'manifest': return cmdManifest();
         default:
-            console.log('Usage: node knowledge.js <search|index|deps|validate> [--flags]');
+            console.log('Usage: node knowledge.js <search|index|deps|validate|manifest> [--flags]');
             process.exitCode = 1;
     }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "toga-ai",
-  "version": "1.0.43",
+  "version": "1.0.45",
   "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

@@ -11,17 +11,10 @@ assume**. Nothing is written until the developer approves your proposal.
 
 ### Contribution model
 
-Every `/capture` automatically pushes new knowledge back to the team git repo after
-validate + index succeed:
-
-- Teammates get it on their **next `npx toga-harness`** run, which pulls the git repo
-  before installing — so the two-way loop is:
-  1. `npx toga-harness` seeds knowledge from the npm bundle
-  2. `/capture` grows the knowledge base and pushes it back to git
-  3. Teammates run `npx toga-harness` → git pull delivers the new docs → they get it
-- The push is **non-blocking**: if offline or credentials are missing, capture is still
-  successful and you report a reminder to push manually.
-- Only `knowledge/` files are ever staged — source code is never touched.
+Every `/capture` validates, indexes, then **pushes** `knowledge/` to the team git repo
+(only `knowledge/` is ever staged — never source code). Teammates receive it on their next
+`npx toga-ai` run (which git-pulls before installing). The push is **non-blocking**: if
+offline or unauthenticated, the capture still succeeds — report a manual-push reminder.
 
 ## Core data model (same as `knowledge/CONVENTIONS.md` and the `kickoff` skill)
 
@@ -146,8 +139,8 @@ For every doc, set/refresh frontmatter: `framework`, `repo`, `project`, `client`
 `type`, `status`, `updated` (today's date), `owners`, `files`, `related`.
 Set `owners` to `["<AUTHOR_USERNAME>"]` from Step 1b — **never leave it empty**; when a doc
 already has owners, add `AUTHOR_USERNAME` if missing rather than replacing.
-For a client `profile.md`, set the dedicated `name:` field to the client's **formal name**
-(distinct from `title`, the doc title) — `validate` requires it; see New-client onboarding.
+For a client `profile.md`, the `title:` **is** the client's formal name (e.g. "Compass USA") —
+there is no separate name field; `validate` requires `title`. See New-client onboarding.
 Add `related:` cross-links. Append new repos to `<TEAM_REPO>/knowledge/registry.json`.
 
 ## Step 6 — Validate, index, mirror back (mandatory)
@@ -366,14 +359,13 @@ any client docs:
    is used only for the folder name.
 2. **Formal name** — **ASK the developer for the client's formal name** (e.g. "Compass USA",
    "New York City Department of Education"). **Never invent it from the slug.**
-3. Create `clients/<slug>/profile.md` with the formal name in the dedicated `name:` field
-   (distinct from `title`). `validate` **requires** `name:` on every client profile — a
-   profile missing it fails the build.
+3. Create `clients/<slug>/profile.md` using the formal name as the `title:` (the slug is only
+   the folder key — the profile's `title` carries the human-readable client name). `validate`
+   **requires** `title` on every doc — a profile missing it fails the build.
 
 ```markdown
 ---
-title: <Client> Profile
-name: "<Formal Client Name>"   # formal name; the slug is only the folder
+title: "<Formal Client Name>"   # the client's formal name IS the title; slug is only the folder
 framework: "<1.0|2.0>"
 project: <Project>
 client: <slug>
@@ -393,34 +385,15 @@ Who the client is and what their integration does.
 
 ### After Capture
 
-Once you have completed a capture session and confirmed the changes are committed to
-the knowledge base, suggest the following to the developer:
+After the push is confirmed, suggest the developer persist session state:
+> "Captured. If you might not finish this thread in one sitting, run `/session-save` to
+> record what worked, what failed, what's pending, and your next step — so you can resume
+> later without losing context."
 
-> "Session captured successfully. If you're done for today or may not finish this
-> thread in one sitting, run `/session-save` to persist your session state. This
-> records exactly what worked, what failed, what's pending, and your exact next step —
-> so you can resume without losing context, even days later."
-
-Provide the suggested command with a name hint:
-```
-/session-save <suggested-slug-based-on-what-was-worked-on>
-```
-
-For example, if the session was about "ClickUp deploy worker actions", suggest:
-```
-/session-save clickup-deploy-worker
-```
+Suggest a slug from the work, e.g. `/session-save clickup-deploy-worker`.
 
 ### PostToolUse hook auto-validation
 
-The `.claude/settings.json` in this repo includes a `PostToolUse` hook that
-automatically runs `node knowledge.js validate` after any file write to `knowledge/`.
-This means:
-
-- As each doc is written during the capture step, validation runs immediately.
-- You will see inline output with any `ERROR:` or `OK` messages.
-- If validation fails after a write, address the error before writing the next doc —
-  do not proceed to Step 6's explicit `validate` run while errors are outstanding.
-- Step 6's explicit `node knowledge.js validate` call is still required as the final
-  gate — the hook fires per-write, but the explicit call confirms global consistency
-  after all writes are complete.
+`.claude/settings.json` runs `node knowledge.js validate` after every write to `knowledge/`,
+so `ERROR:`/`OK` output appears inline as each doc is written — fix any error before writing
+the next. Step 6's explicit `validate` is still required as the final global-consistency gate.

package/skills/kickoff/SKILL.md

@@ -14,7 +14,7 @@ shortcut the flow.
 - **Step 0 (auto-update check) ALWAYS runs first**, with or without arguments.
 - Use the argument text to **pre-fill answers** to the Step 2 interview (framework, layer,
   repo, client, task). Only ask about whatever is still missing or ambiguous.
-- Never treat the argument as an instruction to start coding before Steps 0–5 complete.
+- Never treat the argument as an instruction to start coding before Steps 0–6 complete.
 
 ## Step 0 — Auto-update check (runs before anything else, even with arguments)
 
@@ -107,52 +107,26 @@ When resolved, if there was no `team-repo-path` memory, **write one** (memory ty
 
 ## Step 2 — Interview the developer (ask the work questions FIRST)
 
-Ask these in one message. **Present the repos/projects you already know** (read
-`registry.json`) so the developer can just pick:
+Get the pickable lists in **one call**: `node "<TEAM_REPO>/knowledge.js" manifest` returns
+minified JSON `{repos:[{repo,project,framework,role}], clients:[{slug,title,framework}]}`.
+**Do not read `registry.json` or any `profile.md` to build these lists.** Ask all questions
+in one message:
 
 1. **Framework** — 1.0, 2.0, or **both**?
 2. **Layer** — front-end, back-end, or hybrid?
-3. **Repo(s) / project(s)** — **list EVERY registered repo for the chosen framework(s)** —
-   do not abbreviate or show only a few. **This is a multi-select (checkbox), not a single
-   choice;** a session often spans more than one repo/project, so always let the developer
-   pick several. If they pick a repo not listed, run **New-repo onboarding** (below) for
-   each new repo before continuing.
-4. **Client** — which client is this for, or "shared / internal"? **List EVERY client by its
-   formal name** — read the `name:` field from each `knowledge/clients/<slug>/profile.md`
-   and show the **formal name, not the slug** (fall back to a title-cased slug only if
-   `name:` is missing). Include "shared / internal" and "a new client". Do not show only a
-   subset.
+3. **Repo(s) / project(s)** — list EVERY manifest repo for the chosen framework(s).
+   **Multi-select (checkbox), not single choice** — a session often spans several repos. If
+   they name a repo not listed, run **New-repo onboarding** (below) for each before continuing.
+4. **Client** — list EVERY manifest client by its **`title`** (the formal name, not the slug),
+   plus "shared / internal" and "a new client".
 5. **What are you building or changing?** (a sentence — used to pick relevant feature docs.)
 
-If any answer is unclear, ask again. Do not guess the framework, repo, project, or client.
+If any answer is unclear, ask again. Do not guess framework, repo, project, or client.
 
-### How to present the repo and client choices (questions 3 and 4)
-
-**Do NOT use the option-chip / radio question control for questions 3 and 4.** That
-control caps at ~4 options, which silently truncates the list — with 7+ repos or 3+
-clients the developer never sees the full set. Instead, **render the full list as a
-numbered markdown list in a normal message** and ask the developer to reply with the
-numbers they want (e.g. "1, 3, 5"). This shows every repo and every client with no cap
-and naturally supports multi-select.
-
-```
-**Which repo(s)/project(s)?** (reply with the numbers, multiple OK)
-  1. _underscore  (_Underscore — 2.0 core)
-  2. worker2      (Worker — 2.0 app)
-  3. api2         (API — 2.0 app)
-  ... every registered repo for the chosen framework(s) ...
-  N. a new repo not listed
-
-**Which client?** (one, or "shared / internal")
-  1. Compass Canada
-  2. Compass USA
-  3. Elite
-  ... every client's FORMAL name (from clients/<slug>/profile.md `name:`), not the slug ...
-  S. shared / internal
-  X. a new client
-```
-
-Framework (q1) and layer (q2) have ≤4 options, so the chip control is fine for those.
+**Presenting q3 and q4:** do NOT use the option-chip / radio control — it caps at ~4 options
+and silently truncates a 7-repo / 5-client list. Render the full list as a numbered markdown
+list and have the developer reply with numbers (e.g. "1, 3, 5") — no cap, supports
+multi-select. Framework (q1) and layer (q2) have ≤4 options, so chips are fine there.
 
 ## Step 3 — Resolve the repos this work needs (local paths, lazily)
 
@@ -251,7 +225,7 @@ If they have already run `/session-resume` and are now running `/kickoff`, proce
 normally — the session context they loaded will complement the framework knowledge
 loaded here.
 
-## Step 5 — Propose a multi-agent workflow plan
+## Step 6 — Propose a multi-agent workflow plan
 
 After loading context, analyze what the developer said they're building and **propose a
 concrete agent plan before writing a single line of code**. This gives them visibility