toga-ai 1.0.44 → 1.0.46

package/knowledge.js

@@ -145,6 +145,107 @@ 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: publish — capture's deterministic finish (validate, index, */
+/* optional mirror, commit knowledge/, rebase-before-push with retry). */
+/* Replaces ~80 lines of skill prose + 6 model-orchestrated git calls.  */
+/* Flags: --msg=<commit msg> --mirror=<project .claude dir> --branch=   */
+/* Prints one PUBLISH: <STATUS> line the skill can branch on.           */
+/* ------------------------------------------------------------------ */
+
+function copyDir(src, dest) {
+    fs.mkdirSync(dest, { recursive: true });
+    for (const e of fs.readdirSync(src, { withFileTypes: true })) {
+        const s = path.join(src, e.name), d = path.join(dest, e.name);
+        if (e.isDirectory()) copyDir(s, d);
+        else fs.copyFileSync(s, d);
+    }
+}
+
+function cmdPublish(args) {
+    const cp = require('child_process');
+    const TEAM = __dirname;
+    const node = process.argv[0];
+    const self = __filename;
+    const branch = args.branch || '_main';
+    const run = (cmd) => cp.execSync(cmd, { cwd: TEAM, encoding: 'utf8', stdio: 'pipe' });
+
+    // 0. must be a git clone
+    try { run('git rev-parse --git-dir'); }
+    catch { console.log('PUBLISH: NOT_GIT — knowledge written locally only; run `npx toga-ai` to create a pushable clone'); return; }
+
+    // 1. validate (inherit output so any ERROR: lines are visible); abort on failure
+    try { cp.execSync(`"${node}" "${self}" validate`, { cwd: TEAM, stdio: 'inherit' }); }
+    catch { console.log('PUBLISH: VALIDATE_FAILED — fix the errors above; nothing pushed'); process.exitCode = 1; return; }
+
+    // 2. rebuild indexes
+    cp.execSync(`"${node}" "${self}" index`, { cwd: TEAM, stdio: 'inherit' });
+
+    // 3. optional mirror back to the project bundle (keeps local reads fresh)
+    if (args.mirror && typeof args.mirror === 'string') {
+        const dest = path.join(args.mirror, 'knowledge');
+        if (path.resolve(dest) !== path.resolve(ROOT)) { copyDir(ROOT, dest); console.log('PUBLISH: mirrored knowledge/ -> ' + dest); }
+    }
+
+    // 4. stage knowledge/ ONLY; bail if anything else slipped in
+    run('git add knowledge/');
+    const staged = run('git diff --cached --name-only').split('\n').map(s => s.trim()).filter(Boolean);
+    if (staged.length === 0) { console.log('PUBLISH: NO_CHANGES — nothing new to push'); return; }
+    const outside = staged.filter(f => !f.startsWith('knowledge/'));
+    if (outside.length) { run('git reset -q'); console.log('PUBLISH: ABORT_OUTSIDE_KNOWLEDGE — refusing to commit non-knowledge files: ' + outside.join(', ')); process.exitCode = 1; return; }
+
+    // 5. commit
+    const msg = String(args.msg || 'knowledge: capture session updates').replace(/["\\]/g, "'").slice(0, 200);
+    run(`git commit -m "${msg}"`);
+
+    // 6. rebase-before-push, retrying the CI version-bump race up to 3x
+    for (let attempt = 1; attempt <= 3; attempt++) {
+        try {
+            run('git fetch origin');
+            run(`git rebase origin/${branch}`);
+            run(`git push origin HEAD:${branch}`);
+            console.log(`PUBLISH: PUSHED to ${branch} — CI publishes a new npm version; teammates get it on \`npx toga-ai\``);
+            return;
+        } catch (e) {
+            let status = '';
+            try { status = run('git status --porcelain'); } catch { /* ignore */ }
+            if (/^(UU|AA|DD|AU|UA|DU|UD) /m.test(status)) {
+                try { run('git rebase --abort'); } catch { /* ignore */ }
+                console.log(`PUBLISH: CONFLICT — rebase onto origin/${branch} hit a real conflict; resolve manually, then re-run publish`);
+                process.exitCode = 1; return;
+            }
+            // else: almost certainly a fresh CI bump (non-fast-forward) — loop and retry
+        }
+    }
+    console.log(`PUBLISH: PUSH_FAILED after 3 attempts — run manually: git -C "${TEAM}" push origin HEAD:${branch}`);
+    process.exitCode = 1;
+}
+
 /* ------------------------------------------------------------------ */
 /* command: deps                                                       */
 /* ------------------------------------------------------------------ */
@@ -379,8 +480,10 @@ function main() {
         case 'index': return cmdIndex();
         case 'deps': return cmdDeps(args);
         case 'validate': return cmdValidate();
+        case 'manifest': return cmdManifest();
+        case 'publish': return cmdPublish(args);
         default:
-            console.log('Usage: node knowledge.js <search|index|deps|validate> [--flags]');
+            console.log('Usage: node knowledge.js <search|index|deps|validate|manifest|publish> [--flags]');
             process.exitCode = 1;
     }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "toga-ai",
-  "version": "1.0.44",
+  "version": "1.0.46",
   "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)
 
@@ -60,8 +53,8 @@ done
 **`~/toga-tech` must be probed first** — `npx toga-ai` runs `initLocalRepo` there, which
 creates a proper git repo seeded from the bundle even when the remote is private.
 
-**If `IS_GIT_CLONE` is false** (only `.claude/` bundle found): warn immediately and skip
-Steps 5–7 for git operations:
+**If `IS_GIT_CLONE` is false** (only `.claude/` bundle found): you can still write docs
+locally (Step 5), but the Step 6 publish will report `NOT_GIT` instead of pushing. Warn:
 > "⚠ No git clone found at standard paths. Docs will be written locally only.
 > Run `npx toga-ai` first (it creates `~/toga-tech` as a pushable git repo),
 > then re-run /capture to push to GitHub."
@@ -150,94 +143,34 @@ For a client `profile.md`, the `title:` **is** the client's formal name (e.g. "C
 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)
+## Step 6 — Publish (validate → index → mirror → rebase-push, one command)
 
-```bash
-node "<TEAM_REPO>/knowledge.js" validate
-node "<TEAM_REPO>/knowledge.js" index
-```
-
-If `validate` reports any ERROR — stop and fix before continuing.
-
-After both pass, **mirror back** to keep the project's local reads fresh:
-```bash
-# Only when TEAM_REPO != <project>/.claude
-cp -r "<TEAM_REPO>/knowledge/" "<project>/.claude/knowledge/"
-```
-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."
-
-Otherwise:
-
-**Check A — origin URL correct?**
-```bash
-git -C "<TEAM_REPO>" remote get-url origin
-```
-If wrong or missing: `git -C "<TEAM_REPO>" remote set-url origin https://github.com/agilantsolutions/claude`
-
-**Check B — anything new to push?**
-```bash
-git -C "<TEAM_REPO>" status --short knowledge/
-```
-If empty — report "No new knowledge to push" and exit cleanly.
-
-**Commit:**
-```bash
-git -C "<TEAM_REPO>" add knowledge/
-git -C "<TEAM_REPO>" diff --cached --quiet || \
-  git -C "<TEAM_REPO>" commit -m "knowledge: <one-line summary>"
-```
-
-Never stage files outside `knowledge/`. If `git diff --cached` includes anything outside
-`knowledge/`, abort and warn before committing.
-
-**Sync, then push (rebase BEFORE pushing — this prevents the version-bump conflict):**
-
-Every push to this branch triggers a CI job that commits a `chore: bump version [skip ci]`
-back to the branch. So after *any* prior push (e.g. an earlier capture in the same session),
-your local branch is one commit behind the remote, and a naive push is rejected as a
-non-fast-forward. Rebase your fresh commit onto the remote **before** pushing — this pulls in
-commits that already exist (no waiting on CI), so the push fast-forwards cleanly:
+Finish every capture with the deterministic publisher — **do not** run validate/index/git
+by hand. The push is **pre-authorized and mandatory**: running `/capture` IS the
+authorization, so never ask "ready to push?".
 
 ```bash
-git -C "<TEAM_REPO>" fetch origin
-git -C "<TEAM_REPO>" rebase origin/_main
-git -C "<TEAM_REPO>" push origin HEAD:_main
+node "<TEAM_REPO>/knowledge.js" publish --msg="knowledge: <one-line summary>" --mirror="<project>/.claude"
 ```
 
-> **Do NOT "pull after push" instead** — the bump commit for *this* push is created
-> asynchronously by CI a few seconds later, so pulling immediately afterward races CI and
-> usually grabs nothing. Rebasing *before* the push is what reliably avoids the conflict,
-> with zero dependency on npm build/publish timing.
-
-**If the push is still rejected** (a bump commit landed in the brief window between your
-rebase and push), simply repeat `fetch` → `rebase` → `push`, up to 2 more times. This is an
-expected occasional race, not an error — do not report it as a failure unless all retries are
-exhausted.
+This validates, rebuilds indexes, mirrors `knowledge/` back to the project bundle, then
+stages **only** `knowledge/`, commits, and rebase-pushes to `_main` (auto-retrying the CI
+version-bump race). Omit `--mirror` if TEAM_REPO already *is* the project bundle. Read the
+final `PUBLISH:` line and act on it:
 
-**If push succeeds:**
-> "✓ Pushed to `_main` — CI publishes new npm version. Teammates get it on `npx toga-ai`."
+- **`PUSHED`** — done. Report: "✓ Pushed to `_main` — teammates get it on `npx toga-ai`."
+- **`NO_CHANGES`** — report "No new knowledge to push" and finish.
+- **`VALIDATE_FAILED`** — fix the printed `ERROR:` lines, then re-run publish. Never push around it.
+- **`CONFLICT`** — a real rebase conflict; resolve manually, then re-run publish.
+- **`ABORT_OUTSIDE_KNOWLEDGE`** — non-`knowledge/` files were staged; investigate before retrying.
+- **`NOT_GIT`** — no git clone; docs are local only. Tell the dev to run `npx toga-ai` first.
+- **`PUSH_FAILED`** — show the printed manual-push command.
 
-**If push fails** — show exact git error, then:
-> "⚠ Push failed: `<error>`. Run manually: `git -C <TEAM_REPO> push origin HEAD:_main`"
-
-## Step 8 — Report
+## Step 7 — Report
 
 List exactly what changed (clickable relative paths), and note any ⚠ ELEVATED docs the
 developer approved so they remember those touched senior-owned standards/architecture.
-If Step 7 pushed successfully, include the push confirmation in the report.
+If Step 6 published successfully (`PUSHED`), include the push confirmation in the report.
 
 ---
 
@@ -392,34 +325,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:
-
-> "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."
+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."
 
-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 `publish` re-runs `validate` as the final global-consistency gate before pushing.

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 `title:` 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 the
-   profile 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 `title:`), 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