@jenga-ai/agent 1.2.1 → 1.2.3

package/README.md

@@ -1,4 +1,4 @@
-# JengaAgent
+# Jenga AI
 
 **A structured multi-agent development workflow that works with any AI agent or AI-native IDE.** Three specialised AI agents — Scrum Master, Developer, and Tester — collaborate through a shared scrum board, an event-driven trigger queue, and 28 slash-command skills to take a project from idea to verified, committed code — across as many sessions as it takes.
 
@@ -34,7 +34,7 @@ npm install @jenga-ai/agent
 
 ## The Problem It Solves
 
-Without a framework like JengaAgent, AI-assisted development has serious structural weaknesses:
+Without a framework like Jenga AI, AI-assisted development has serious structural weaknesses:
 
 | Problem | Reality |
 |---|---|
@@ -45,7 +45,7 @@ Without a framework like JengaAgent, AI-assisted development has serious structu
 | **No audit trail** | You can't replay *why* something was built, by which agent, based on which task |
 | **Sessions just end** | Work-in-progress, unresolved problems, and incomplete stories silently vanish |
 
-JengaAgent solves each of these with structure: persistent board state, strict agent roles, typed inter-agent contracts, and session-end hooks that preserve context between sessions.
+Jenga AI solves each of these with structure: persistent board state, strict agent roles, typed inter-agent contracts, and session-end hooks that preserve context between sessions.
 
 ---
 
@@ -53,7 +53,7 @@ JengaAgent solves each of these with structure: persistent board state, strict a
 
 ### Before / After
 
-**Without JengaAgent:**
+**Without Jenga AI:**
 ```
 You: "Add user authentication"
 AI agent: [writes auth code, declares it works, session ends]
@@ -63,7 +63,7 @@ You: "What's the status of auth?"
 AI agent: "I don't have context from the previous session."
 ```
 
-**With JengaAgent:**
+**With Jenga AI:**
 ```
 /todo → "Add user authentication" → linked to E01_S02
 /do   → Developer creates worktree E01_S02_T01-auth
@@ -81,7 +81,7 @@ Next session:
 
 ### Real-World Scenario: Building a Feature Across Sessions
 
-Imagine you're building a REST API with auth, rate limiting, and an admin dashboard. Each is a separate Epic. Here's how JengaAgent handles that across multiple days:
+Imagine you're building a REST API with auth, rate limiting, and an admin dashboard. Each is a separate Epic. Here's how Jenga AI handles that across multiple days:
 
 **Planning**
 ```
@@ -187,7 +187,7 @@ Run `/status` at any time to see where the project stands.
 
 ## Supported Platforms
 
-JengaAgent has been tested with:
+Jenga AI has been tested with:
 
 | Platform | Type |
 |---|---|
@@ -261,7 +261,7 @@ Skills live in `.agents/skills/<name>/SKILL.md`. Invoke with `/<name>` in your A
 
 ## Distributing the Workflow
 
-JengaAgent can propagate its workflow files to other projects on your machine via `/distribute`.
+Jenga AI can propagate its workflow files to other projects on your machine via `/distribute`.
 
 1. **Register consumer projects** — add each consuming project to `distribute.config.json` at the repo root (or pass a path directly: `/distribute /path/to/project`).
 2. **Run `/distribute`** — choose `major`, `minor`, `patch`, or `amend` release type; the skill handles versioning, dry-run preview, file copy, and a version bump commit.
@@ -375,7 +375,7 @@ All agents log every incoming sender object to `project/logs/events.json` as the
 
 ---
 
-## When to Use JengaAgent
+## When to Use Jenga AI
 
 **Use it when:**
 - You're building a non-trivial project across multiple sessions

package/lib/generate-agent-context.js

@@ -26,7 +26,7 @@
  * ESM, Node built-ins only — mirrors lib/mirror.js and lib/inject-settings.js.
  */
 
-import { readFileSync, writeFileSync, existsSync, mkdirSync, readdirSync } from "fs";
+import { readFileSync, writeFileSync, existsSync, mkdirSync, readdirSync, realpathSync } from "fs";
 import { join, dirname } from "path";
 import { fileURLToPath } from "url";
 
@@ -220,7 +220,16 @@ export function generateAgentContext(projectRoot = process.cwd(), packageRoot =
 // used by skills/init/scripts/init.sh (this repo's own board-scaffolding
 // flow, where node is guaranteed available). The published npm CLI path
 // (lib/commands/init.js) imports generateAgentContext() directly instead.
-if (process.argv[1] === fileURLToPath(import.meta.url)) {
+//
+// process.argv[1] is compared via realpath, not as a raw string: Node
+// resolves import.meta.url through symlinks when loading an ES module, but
+// leaves process.argv[1] exactly as the shell passed it. On macOS, TMPDIR
+// and /tmp are themselves symlinks into /private, so any invocation from a
+// path under either (a very ordinary occurrence — every consumer install
+// under a symlinked, mapped, or `npm link`-ed directory hits this) made the
+// two sides disagree and silently skipped generation with no error.
+const invokedPath = process.argv[1] ? realpathSync(process.argv[1]) : null;
+if (invokedPath === fileURLToPath(import.meta.url)) {
   const projectRoot = process.argv[2] || process.cwd();
   const result = generateAgentContext(projectRoot);
   if (result.skipped) {

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@jenga-ai/agent",
-  "version": "1.2.1",
-  "description": "JengaAgent — agentic project management CLI",
+  "version": "1.2.3",
+  "description": "Structured multi-agent development workflow for AI coding agents — scrum board, role-bounded scrum master / developer / tester agents, and 30+ slash-command skills. Works with Claude Code, GitHub Copilot, and Codex.",
   "type": "module",
   "publishConfig": {
     "access": "public"
@@ -9,8 +9,13 @@
   "bin": {
     "jenga": "./bin/jenga.js"
   },
+  "engines": {
+    "node": ">=14.13.1"
+  },
   "scripts": {
     "postinstall": "node scripts/postinstall.js",
+    "test": "bats tests/*.bats",
+    "validate:npm-metadata": "bash scripts/validate_npm_metadata.sh",
     "ui:dev": "npm run ui:dev --prefix project/app",
     "ui:build": "npm run ui:build --prefix project/app",
     "api:start": "npm run api:start --prefix project/app",
@@ -32,10 +37,35 @@
   ],
   "repository": {
     "type": "git",
-    "url": "https://github.com/samwelmunga/jenga-npm"
+    "url": "git+https://github.com/samwelmunga/jenga-npm.git"
+  },
+  "homepage": "https://github.com/samwelmunga/jenga-npm#readme",
+  "bugs": {
+    "url": "https://github.com/samwelmunga/jenga-npm/issues"
+  },
+  "keywords": [
+    "ai-agents",
+    "agentic",
+    "agentic-workflow",
+    "multi-agent",
+    "agent-framework",
+    "ai-development",
+    "claude",
+    "claude-code",
+    "agents-md",
+    "copilot",
+    "github-copilot",
+    "codex",
+    "skills",
+    "project-management",
+    "developer-tools",
+    "cli"
+  ],
+  "author": {
+    "name": "Samwel Munga",
+    "email": "samwelmunga88@hotmail.se",
+    "url": "https://knappkod.se/jenga-ai"
   },
-  "keywords": [],
-  "author": "",
   "license": "MIT",
   "dependencies": {
     "@huggingface/transformers": "^4.2.0"
@@ -45,5 +75,8 @@
   },
   "comments": {
     "audit": "sharp <0.35.0 and adm-zip <0.6.0 are transitive deps of @huggingface/transformers with no upstream fix available. Not exploitable in this context: only text feature-extraction pipeline is used — no image processing or ZIP handling at application boundary. Review when @huggingface/transformers ships a patched release."
+  },
+  "devDependencies": {
+    "bats": "^1.13.0"
   }
 }

package/scripts/postinstall.js

@@ -1,6 +1,6 @@
 #!/usr/bin/env node
 /**
- * postinstall.js — JengaAgent consumer installation hook
+ * postinstall.js — Jenga AI consumer installation hook
  *
  * Runs automatically when a consumer project installs jenga-agent via npm.
  * Copies the discovery-bound dirs — `skills/` and `agents/` — into BOTH
@@ -65,7 +65,7 @@ function main() {
 
   // Avoid running during development (when INIT_CWD === packageRoot itself)
   if (path.resolve(consumerRoot) === path.resolve(packageRoot)) {
-    console.log('\n  ℹ  JengaAgent postinstall: running inside the package itself — skipping copy.\n');
+    console.log('\n  ℹ  Jenga AI postinstall: running inside the package itself — skipping copy.\n');
     return;
   }
 
@@ -93,7 +93,7 @@ function main() {
   const shouldCopy     = isFirstInstall || isUpgrade;
 
   console.log('\n╔══════════════════════════════════════════════════════╗');
-  console.log('║            JengaAgent — postinstall hook             ║');
+  console.log('║            Jenga AI — postinstall hook             ║');
   console.log('╚══════════════════════════════════════════════════════╝\n');
   console.log(`  Package version  : ${packageVersion}`);
   console.log(`  Installed version: ${installedVersion ?? '(none — first install)'}`);

package/scripts/validate_npm_metadata.sh

@@ -0,0 +1,142 @@
+#!/usr/bin/env bash
+#
+# validate_npm_metadata.sh — deterministic check that package.json carries
+# the metadata npm/GitHub discovery depends on (E41_S01_T02).
+#
+# Rationale: per the repo's "Scripts Over Inline Logic" principle
+# (CLAUDE.md), this is a script rather than an agent instruction so that
+# future drift in package.json's publish-facing fields (e.g. keywords
+# accidentally cleared, or repository.url silently re-pointed at the
+# private samwelmunga/Jenga AI repo instead of the public jenga-npm
+# mirror) is caught deterministically instead of relying on an agent
+# noticing during review.
+#
+# IMPORTANT — no pinned version check:
+#   This script intentionally does NOT compare package.json's `version`
+#   field against any hardcoded literal. E41_S01_T01 established that the
+#   locally committed version and the version actually published to npm
+#   drift independently over time, so pinning a literal here would go
+#   stale on the very next release. If a version check is wanted at all,
+#   it is structural only (present + semver-shaped), never a pinned value.
+#
+# Usage:
+#   bash scripts/validate_npm_metadata.sh
+#   npm run validate:npm-metadata
+#
+# Exit codes:
+#   0  All checks passed.
+#   1  One or more checks failed (each failure is printed with a
+#      descriptive message; a summary count follows).
+#
+# Dependencies: node only (already a required runtime for this project —
+# see package.json's "engines" field). No new dependency is introduced.
+
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+REPO_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
+PACKAGE_JSON="${1:-$REPO_ROOT/package.json}"
+
+if [[ ! -f "$PACKAGE_JSON" ]]; then
+  echo "FAIL: package.json not found at $PACKAGE_JSON" >&2
+  exit 1
+fi
+
+# All validation logic lives in one embedded Node script to avoid the
+# quoting/escaping pitfalls of parsing JSON arrays and nested objects from
+# bash. Node prints one "PASS: ..." or "FAIL: ..." line per check to
+# stdout, plus a final "SUMMARY: <n> failed" line. Bash only interprets
+# the final summary line to decide the exit code and print the banner.
+NODE_OUTPUT="$(node -e '
+const fs = require("fs");
+
+const pkgPath = process.argv[1];
+const pkg = JSON.parse(fs.readFileSync(pkgPath, "utf8"));
+
+const failures = [];
+const pass = (msg) => console.log("PASS: " + msg);
+const fail = (msg) => { failures.push(msg); console.log("FAIL: " + msg); };
+
+// keywords: must exist, be a non-empty array
+if (!Array.isArray(pkg.keywords) || pkg.keywords.length === 0) {
+  fail("keywords is empty or missing — package.json must declare a non-empty keywords array for npm/GitHub discoverability.");
+} else {
+  pass("keywords is present with " + pkg.keywords.length + " entries.");
+}
+
+// author: must exist and be non-empty (string or object form)
+const authorEmpty = (() => {
+  if (pkg.author == null) return true;
+  if (typeof pkg.author === "string") return pkg.author.trim().length === 0;
+  if (typeof pkg.author === "object") {
+    return !pkg.author.name || String(pkg.author.name).trim().length === 0;
+  }
+  return true;
+})();
+if (authorEmpty) {
+  fail("author is empty or missing — package.json must declare an author (string or {name, ...} object).");
+} else {
+  pass("author is present.");
+}
+
+// repository / homepage / bugs: must all be present
+if (pkg.repository == null || (typeof pkg.repository === "object" && Object.keys(pkg.repository).length === 0)) {
+  fail("repository is missing from package.json.");
+} else {
+  pass("repository is present.");
+}
+
+if (!pkg.homepage || String(pkg.homepage).trim().length === 0) {
+  fail("homepage is missing from package.json.");
+} else {
+  pass("homepage is present.");
+}
+
+if (pkg.bugs == null || (typeof pkg.bugs === "object" && Object.keys(pkg.bugs).length === 0)) {
+  fail("bugs is missing from package.json.");
+} else {
+  pass("bugs is present.");
+}
+
+// repository.url (object form) or repository (string form) must point at
+// the PUBLIC mirror (samwelmunga/jenga-npm), never the private repo.
+const PUBLIC_REPO_MARKER = "samwelmunga/jenga-npm";
+if (pkg.repository != null) {
+  const repoUrl = typeof pkg.repository === "string"
+    ? pkg.repository
+    : (pkg.repository.url || "");
+
+  if (!repoUrl || repoUrl.trim().length === 0) {
+    fail("repository is present but has no resolvable url.");
+  } else if (!repoUrl.includes(PUBLIC_REPO_MARKER)) {
+    fail("repository.url (\"" + repoUrl + "\") does not point at the public " + PUBLIC_REPO_MARKER + " repo — it must not reference a private repo (e.g. samwelmunga/Jenga AI) or any other location.");
+  } else {
+    pass("repository.url points at the public " + PUBLIC_REPO_MARKER + " repo.");
+  }
+}
+
+// version: structural semver check only — NEVER a pinned literal value.
+// See header comment for why a pinned check would go stale immediately.
+const SEMVER_RE = /^\d+\.\d+\.\d+/;
+if (!pkg.version || !SEMVER_RE.test(String(pkg.version))) {
+  fail("version (\"" + pkg.version + "\") is missing or not a valid semver-shaped string.");
+} else {
+  pass("version (\"" + pkg.version + "\") is a valid semver-shaped string (no pinned-value check performed, by design).");
+}
+
+console.log("SUMMARY: " + failures.length + " failed");
+process.exit(failures.length > 0 ? 1 : 0);
+' "$PACKAGE_JSON")" && NODE_EXIT=0 || NODE_EXIT=$?
+
+echo "$NODE_OUTPUT"
+echo
+
+FAILED_COUNT="$(echo "$NODE_OUTPUT" | grep -c '^FAIL:' || true)"
+
+if [[ "$NODE_EXIT" -ne 0 || "$FAILED_COUNT" -gt 0 ]]; then
+  echo "npm publish metadata validation FAILED ($FAILED_COUNT check(s) failed). See FAIL lines above." >&2
+  exit 1
+fi
+
+echo "All npm publish metadata checks passed."
+exit 0

package/skills/distribute/CONFIG_SCHEMA.md

@@ -6,7 +6,7 @@ This document is the canonical reference for the `jenga.config.json` file writte
 
 ## Purpose
 
-`jenga.config.json` lives at the root of a consuming project and tracks which version of the JengaAgent framework is currently installed there, where the framework files were placed, and when the last distribution occurred. It is read by the distribution script on subsequent runs to determine the target directory and detect whether an upgrade is needed.
+`jenga.config.json` lives at the root of a consuming project and tracks which version of the Jenga AI framework is currently installed there, where the framework files were placed, and when the last distribution occurred. It is read by the distribution script on subsequent runs to determine the target directory and detect whether an upgrade is needed.
 
 ---
 
@@ -40,17 +40,17 @@ This document is the canonical reference for the `jenga.config.json` file writte
 |---|---|---|---|---|
 | `project_name` | string | yes | — | Human-readable identifier for the consuming project. Must match the `name` field of the corresponding entry in the monorepo's `distribute.config.json`. |
 | `target_dir` | string | yes | `.agents` | The directory under the project root where framework files are copied. `distribute-changes.sh` reads this field to resolve the destination path on every run. Change this only if the consuming project uses a non-standard layout. |
-| `version` | string | yes | — | The JengaAgent semantic version currently installed in this project (e.g. `"2.3.1"`). Compared against the `version` field in the monorepo's `package.json` to determine whether an upgrade is required. |
+| `version` | string | yes | — | The Jenga AI semantic version currently installed in this project (e.g. `"2.3.1"`). Compared against the `version` field in the monorepo's `package.json` to determine whether an upgrade is required. |
 | `updated_at` | string (ISO 8601 date) | yes | — | Date of the last successful distribution, in `YYYY-MM-DD` format. Does **not** include a time component. |
 | `last_distributed` | string (ISO 8601 datetime) | yes | — | Full UTC timestamp of the last successful distribution, in `YYYY-MM-DDTHH:MM:SSZ` format. Provides more precision than `updated_at` and is useful for audit and ordering purposes. |
 | `source` | string | yes | `"private"` | Distribution channel. Always `"private"` for projects that receive updates via the filesystem distribution mechanism. Distinguishes these projects from any future npm-installed consumers. Do not change this value manually. |
-| `project_files_visibility` | string (enum) | no | `"visible"` | How JengaAgent's own working files appear in the consuming project. Exactly one of `visible` or `ignored` — no other value is accepted. Written by `/init`, not by distribution. See [Project files visibility](#project-files-visibility) below. |
+| `project_files_visibility` | string (enum) | no | `"visible"` | How Jenga AI's own working files appear in the consuming project. Exactly one of `visible` or `ignored` — no other value is accepted. Written by `/init`, not by distribution. See [Project files visibility](#project-files-visibility) below. |
 
 ---
 
 ## Project files visibility
 
-`project_files_visibility` controls how JengaAgent's own working files — the `project/` tree containing the scrum board, `todo.md`, `queue/`, `rapports/`, and `logs/` — appear in a consuming project.
+`project_files_visibility` controls how Jenga AI's own working files — the `project/` tree containing the scrum board, `todo.md`, `queue/`, `rapports/`, and `logs/` — appear in a consuming project.
 
 This is distinct from `target_dir`. `target_dir` governs where the **distributed framework files** (skill and agent definitions) land; `project_files_visibility` governs the **working tree** that accumulates as the framework is used.
 

package/skills/distribute/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: distribute
-description: Distribute JengaAgent framework files from this private monorepo to one or more consuming projects via the local filesystem. Manages release type selection, version bumping, dry-run preview, per-target file copy, and a post-distribution git commit.
+description: Distribute Jenga AI framework files from this private monorepo to one or more consuming projects via the local filesystem. Manages release type selection, version bumping, dry-run preview, per-target file copy, and a post-distribution git commit.
 keywords:
   - distribute
   - private distribution
@@ -16,7 +16,7 @@ examples:
 
 # Distribute
 
-Copies JengaAgent framework files from this monorepo to all active consuming projects registered in `distribute.config.json`. Manages the full version lifecycle: release type selection, `package.json` version bump, dry-run preview, per-target file copy, and a final git commit of the version bump.
+Copies Jenga AI framework files from this monorepo to all active consuming projects registered in `distribute.config.json`. Manages the full version lifecycle: release type selection, `package.json` version bump, dry-run preview, per-target file copy, and a final git commit of the version bump.
 
 Distinct from `/self-sync` (which mirrors root → in-repo `.claude/.agents/`) and `/mirror-public` (which syncs to the public GitHub repo). Do not call either of those skills from within this flow.
 

package/skills/distribute/scripts/distribute-changes.sh

@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-# distribute-changes.sh — Copy JengaAgent framework files into a consuming project
+# distribute-changes.sh — Copy Jenga AI framework files into a consuming project
 #
 # Usage:
 #   distribute-changes.sh <project_path> [--dry-run]

package/skills/doc/SKILL.md

@@ -39,7 +39,7 @@ After target resolution, all generation must operate on a synthesis context obje
 ```yaml
 target_path: README.md
 objective: project overview
-project_name: JengaAgent
+project_name: Jenga AI
 project_description: Structured multi-agent development workflow
 features: []
 getting_started: []

package/skills/init/SKILL.md

@@ -67,11 +67,11 @@ changes nothing on disk, so it is the only safe default.
 Never treat `existing-codebase` as if it were `empty`, and never skip straight to step 2
 on that verdict without the user (or the non-interactive default) choosing to.
 
-### 2. Ask how JengaAgent's working files should appear
+### 2. Ask how Jenga AI's working files should appear
 
 Ask the user this question, verbatim, before running any script:
 
-    How should JengaAgent's own working files (project/ — the scrum board, todo.md,
+    How should Jenga AI's own working files (project/ — the scrum board, todo.md,
     queue/, rapports/, and logs/) appear in this project?
     1. Visible — keep them at `project/`, tracked and visible in directory listings
     2. Ignored — keep them at `project/` but add them to `.gitignore` so they are never committed
@@ -96,10 +96,26 @@ of the mechanical work.
 
 ### 3. Run the scaffold script
 
-Execute the init script from the project root, passing the choice from step 2:
+`init.sh` is not guaranteed to live at a single fixed path: in a project that
+installed Jenga via npm, it was mirrored to `.claude/skills/init/scripts/`
+(Claude Code) and `.agents/skills/init/scripts/` (Copilot/other agents) by
+`postinstall.js`, and neither of those exists yet in this framework's own
+source checkout, where it lives at the bare `skills/init/scripts/` path
+instead. This step runs before `CLAUDE.md`/`AGENTS.md` exist, so it cannot
+rely on either file's routing instructions to resolve the path — it must
+locate its own script directly. Execute the init script from the project
+root, passing the choice from step 2:
 
 ```bash
-chmod +x ./scripts/init.sh && ./scripts/init.sh --visibility <visible|ignored>
+INIT_SCRIPT=""
+for candidate in .claude/skills/init/scripts/init.sh .agents/skills/init/scripts/init.sh skills/init/scripts/init.sh; do
+  [[ -f "$candidate" ]] && { INIT_SCRIPT="$candidate"; break; }
+done
+if [[ -z "$INIT_SCRIPT" ]]; then
+  echo "Error: could not locate init.sh under .claude/skills/, .agents/skills/, or skills/" >&2
+  exit 1
+fi
+chmod +x "$INIT_SCRIPT" && "$INIT_SCRIPT" --visibility <visible|ignored>
 ```
 
 Omitting `--visibility` falls back to the `JENGA_PROJECT_FILES_VISIBILITY`

package/skills/init/scripts/apply-project-visibility.sh

@@ -41,7 +41,7 @@ usage() {
   exit 1
 }
 
-# Every JengaAgent working file named in E31_S05 — the scrum board, todo.md,
+# Every Jenga AI working file named in E31_S05 — the scrum board, todo.md,
 # queue/, rapports/ and logs/ — nests under this single root, so one entry
 # covers them all. `ignored` consumes this list.
 JENGA_WORKING_PATHS=("project")

package/skills/init/scripts/init.sh

@@ -5,6 +5,23 @@ SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 ASSETS_DIR="$SCRIPT_DIR/../assets"
 VISIBILITY_SCRIPT="$SCRIPT_DIR/apply-project-visibility.sh"
 
+# ─── Resolve the package root that owns templates/ and lib/ ──────────────────
+# postinstall.js mirrors only skills/ and agents/ into .claude/ and .agents/ —
+# templates/ and lib/ are never copied there, so a script running from a
+# mirrored copy (.claude/skills/init/scripts/ or .agents/skills/init/scripts/)
+# cannot reach its siblings via a fixed ../../../ climb the way it can in this
+# monorepo checkout, where init.sh actually lives at skills/init/scripts/ with
+# templates/ and lib/ three levels up. Consumers instead have them inside the
+# installed npm package.
+if [[ -d "$SCRIPT_DIR/../../../templates" ]]; then
+  PKG_ROOT="$SCRIPT_DIR/../../.."
+elif [[ -d "$PWD/node_modules/@jenga-ai/agent/templates" ]]; then
+  PKG_ROOT="$PWD/node_modules/@jenga-ai/agent"
+else
+  echo "Error: could not locate the jenga-agent package root (templates/ not found via monorepo checkout or node_modules/@jenga-ai/agent)." >&2
+  exit 1
+fi
+
 # ─── 0. Resolve project_files_visibility ─────────────────────────────────────
 # Defaults to `visible` — the only value that touches nothing on disk — so an
 # unattended run can never silently relocate directories or edit .gitignore.
@@ -65,7 +82,7 @@ cp "$ASSETS_DIR/strategy_stub_template.md" docs/STRATEGY.md
 
 # ─── 10. Create CHANGELOG.md ──────────────────────────────────────────────────
 echo "→ Creating CHANGELOG.md from template..."
-cp "$SCRIPT_DIR/../../../templates/CHANGELOG_TEMPLATE.md" CHANGELOG.md
+cp "$PKG_ROOT/templates/CHANGELOG_TEMPLATE.md" CHANGELOG.md
 
 # ─── 11. Apply project_files_visibility ──────────────────────────────────────
 # Runs before the commit so the .gitignore entry (ignored) is captured in the
@@ -79,7 +96,7 @@ bash "$VISIBILITY_SCRIPT" "$VISIBILITY" "$PWD"
 # lib/generate-agent-context.js (shared with the published `jenga init` CLI).
 echo "→ Generating CLAUDE.md / AGENTS.md..."
 if command -v node >/dev/null 2>&1; then
-  node "$SCRIPT_DIR/../../../lib/generate-agent-context.js" "$PWD"
+  node "$PKG_ROOT/lib/generate-agent-context.js" "$PWD"
 else
   echo "  Warning: node not found — skipped CLAUDE.md/AGENTS.md generation." >&2
 fi

package/skills/publish/adapters/npm-ci.md

@@ -190,7 +190,7 @@ A successful non-dry-run produces:
 - A history entry in `project/logs/publish-history.json` written by
   `publish_deploy.sh` with `platform_state: "triggered"`
 
-## Post-Deploy Manual Steps
+## Post-deploy manual steps
 
 After a successful deploy trigger, the adapter prints the workflow run URL.
 The operator should:

package/skills/publish/scripts/npm_pipeline.sh

@@ -1,7 +1,7 @@
 #!/usr/bin/env bash
-# npm_pipeline.sh — Execute the npm publish pipeline for the JengaAgent repo.
+# npm_pipeline.sh — Execute the npm publish pipeline for the Jenga AI repo.
 #
-# Runs from the JengaAgent repo root (where package.json lives) and invokes
+# Runs from the Jenga AI repo root (where package.json lives) and invokes
 # `npm publish --tag <dist_tag>` (or `--dry-run` when requested).
 #
 # Exit codes:

package/skills/publish/scripts/publish_deploy.sh

@@ -465,9 +465,18 @@ print_manual_steps() {
     droplet)
       adapter_doc="$PUBLISH_REPO_ROOT/skills/publish/adapters/droplet.md"
       ;;
-    *)
+    npm)
+      adapter_doc="$PUBLISH_REPO_ROOT/skills/publish/adapters/npm.md"
+      ;;
+    npm-ci)
+      adapter_doc="$PUBLISH_REPO_ROOT/skills/publish/adapters/npm-ci.md"
+      ;;
+    mobile-ios)
       adapter_doc="$PUBLISH_REPO_ROOT/skills/publish/adapters/mobile-ios.md"
       ;;
+    *)
+      return 0
+      ;;
   esac
   [[ -f "$adapter_doc" ]] || return 0
   local manual_steps

package/skills/uncharted/scripts/discover-subsystems.sh

@@ -45,10 +45,10 @@
 #                        itself. The epic cap — and the surfacing of anything it drops — is
 #                        applied by a separate layer on top of this script's output.
 #   --include-framework  Do not exclude Jenga scaffolding. Needed to point the script at the
-#                        JengaAgent repo itself, where the scaffolding IS the application.
+#                        Jenga AI repo itself, where the scaffolding IS the application.
 #   --include-training-scaffolding
 #                        Do not exclude .training/ job-template scaffolding. Needed to point the
-#                        script at JengaAgent's own /train subsystem, or at a project that
+#                        script at Jenga AI's own /train subsystem, or at a project that
 #                        genuinely wants job templates catalogued as a candidate.
 #   --with-dependencies  Additionally compute the "cohesion" signal by calling
 #                        detect-dependencies.sh once per candidate. Off by default: it is an