@jenga-ai/agent 3.4.0 → 3.5.0

package/lib/skill-allow-list.json

@@ -1,5 +1,5 @@
 {
-  "generated_at": "2026-09-14T18:42:41.263Z",
+  "generated_at": "2026-09-16T15:30:19.120Z",
   "skill_count": 41,
   "skills": [
     "brainstorm",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jenga-ai/agent",
-  "version": "3.4.0",
+  "version": "3.5.0",
   "description": "An agentic development workflow for Claude Code, Copilot, and Codex — with a persistent Epic/Story/Task board, an isolated git worktree per task, and a separate tester agent that runs your test suite before anything is marked done.",
   "type": "module",
   "publishConfig": {

package/skills/j-init/SKILL.md

@@ -104,10 +104,41 @@ run can never silently relocate directories or edit `.gitignore`.
 > `skills/distribute/CONFIG_SCHEMA.md` for the root-cause note and the tracked
 > follow-up to reintroduce it once fixed.
 
-Carry the chosen value into step 3. Do not apply it yourself — the script owns all
+Carry the chosen value into step 4. Do not apply it yourself — the script owns all
 of the mechanical work.
 
-### 3. Run the scaffold script
+### 3. Ask whether the distributed scaffold should be committed
+
+This is a **distinct** question from step 2 — `project_files_visibility` (step 2)
+covers only the `project/` working tree (the scrum board, `todo.md`, `queue/`,
+`rapports/`, `logs/`). It has no effect on `.claude/`/`.agents/`, the distributed
+framework scaffold (skill and agent definitions), which is a separate tree with a
+separate lifecycle — it gets overwritten wholesale by every `/distribute` run or npm
+upgrade, unlike `project/`. Kept as its own flag (`scaffold_visibility`) rather than
+folded into `project_files_visibility`'s enum; see
+`skills/distribute/CONFIG_SCHEMA.md`'s "Scaffold visibility" section for the full
+rationale.
+
+Ask the user this question, verbatim, before running any script:
+
+    Should the distributed .claude/.agents Jenga AI framework scaffold (skills, agent
+    definitions — implementation detail, not your own code) be committed into this
+    project's git history?
+    1. Yes, commit it — keep it tracked and visible, exactly like today
+    2. No, keep it on disk but add it to .gitignore so it's never committed
+    3. Not sure — explain the trade-offs and ask me again
+
+If the user picks option 3, explain the trade-offs and re-ask. Do not proceed until
+the answer maps to one of `visible` (option 1) or `ignored` (option 2).
+
+If the run is non-interactive (no user available to answer), use the default:
+**`visible`**. It is the only choice that changes nothing on disk, so an unattended
+run reproduces exactly today's behavior — the scaffold is still committed by default.
+
+Carry the chosen value into step 4 as well. Do not apply it yourself — the script
+owns all of the mechanical work.
+
+### 4. Run the scaffold script
 
 `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/j-init/scripts/`
@@ -117,7 +148,7 @@ source checkout, where it lives at the bare `skills/j-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:
+root, passing the choices from steps 2 and 3:
 
 ```bash
 INIT_SCRIPT=""
@@ -128,11 +159,14 @@ 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>
+chmod +x "$INIT_SCRIPT" && "$INIT_SCRIPT" --visibility <visible|ignored> --scaffold-visibility <visible|ignored>
 ```
 
 Omitting `--visibility` falls back to the `JENGA_PROJECT_FILES_VISIBILITY`
-environment variable, then to `visible`.
+environment variable, then to `visible`. Omitting `--scaffold-visibility` falls
+back to the `JENGA_SCAFFOLD_VISIBILITY` environment variable, then to `visible`
+— the same default-preserving fallback chain, applied independently to the
+distributed-scaffold question from step 3.
 
 This script handles all scaffolding in one step:
 1. Initializes the git repository
@@ -148,22 +182,27 @@ This script handles all scaffolding in one step:
 11. Creates `docs/STRATEGY.md` — a strategic brief stub intended for investors, partners, and the product team
 12. Creates `CHANGELOG.md` from the shared template — a running log of notable changes, seeded with an `[Unreleased]` section
 13. Applies the chosen visibility mode via `scripts/apply-project-visibility.sh`, which records it as `project_files_visibility` in `jenga.config.json` and performs any `.gitignore` change
-14. Stages and commits all files with the message `init: scaffold project structure and workflow config`
+14. Applies the chosen scaffold visibility mode via `scripts/apply-scaffold-visibility.sh`, which records it as `scaffold_visibility` in `jenga.config.json` and, when `ignored`, adds `.claude/` and `.agents/` to `.gitignore`
+15. Stages and commits all files with the message `init: scaffold project structure and workflow config`
 
-The visibility mode is validated before any scaffolding happens, so an invalid
-value fails fast and leaves nothing behind. It is applied before the commit, so
-the `.gitignore` entry is captured in the initial commit.
+Both visibility modes are validated before any scaffolding happens, so an invalid
+value fails fast and leaves nothing behind. Both are applied before the commit, so
+any resulting `.gitignore` entries are captured in the initial commit — this is what
+lets `scaffold_visibility: ignored` keep `.claude/`/`.agents/` out of the commit even
+though they may already exist on disk (from npm postinstall or a prior `/distribute`
+run) by the time `/init` runs `git add -A`.
 
 If the script fails, check that you are in the project root and that git and `jq`
 are available.
 
-See `skills/distribute/CONFIG_SCHEMA.md` for the full `project_files_visibility`
-field reference.
+See `skills/distribute/CONFIG_SCHEMA.md` for the full `project_files_visibility` and
+`scaffold_visibility` field reference.
 
-### 4. Prompt next step
+### 5. Prompt next step
 
 Inform the user that setup is complete, and state which visibility mode was applied
-and where the working files now live. Mention that `docs/STRATEGY.md` was created as
+for both `project_files_visibility` and `scaffold_visibility`, and where the working
+files and scaffold now live. Mention that `docs/STRATEGY.md` was created as
 a strategic brief stub for investors, partners, and the product team — they can fill
 it in now or return to it later. Suggest running `/pi-plan` to define project goals
 and epics.

package/skills/j-init/assets/.gitignore_template

@@ -11,5 +11,4 @@ Desktop.ini
 # Dependency directories
 node_modules/
 vendor/
-.venv/
-EOF
+.venv/

package/skills/j-init/scripts/apply-scaffold-visibility.sh

@@ -0,0 +1,192 @@
+#!/usr/bin/env bash
+#
+# apply-scaffold-visibility.sh — apply the `scaffold_visibility` mode to a project.
+#
+# This is a DISTINCT flag from `project_files_visibility` (see
+# apply-project-visibility.sh). `project_files_visibility` covers the
+# project/ working tree (scrum board, todo.md, queue/, rapports/, logs/) —
+# E31_S05's own Background section scopes it to that tree only. This script
+# instead covers the *distributed framework scaffold* — `.claude/` and
+# `.agents/` — which is a different tree with a different lifecycle (it is
+# overwritten wholesale by every `/distribute` run or npm upgrade; project/
+# is not). Filed as new, adjacent scope under E31_S07 rather than folded
+# silently into project_files_visibility's existing enum. See
+# skills/distribute/CONFIG_SCHEMA.md's "Scaffold visibility" section for the
+# full rationale.
+#
+# This is skills/j-init/'s own copy of skills/init/scripts/apply-scaffold-visibility.sh
+# (E31_S07_T03) — skills/j-init/ is a separate, hand-maintained directory, not
+# auto-synced with skills/init/ (scripts/generate-j-alias.sh explicitly excludes
+# this pair), and is the copy that actually ships to public-GitHub-mirror and
+# npm-package consumers. Keep this file's logic in lockstep with skills/init/'s
+# copy — any behavioral change made there should be mirrored here.
+#
+# Usage:
+#   apply-scaffold-visibility.sh <mode> [project_root]
+#   apply-scaffold-visibility.sh --check-only <mode>
+#
+# Modes:
+#   visible   Scaffold directories stay where they are. No-op on disk beyond
+#             the config write. This is the default — matches the behavior
+#             of every /init run before this flag existed.
+#   ignored   .claude/ and .agents/ are added to the project's .gitignore —
+#             present on disk (whenever npm postinstall or /distribute
+#             places them, whether that happens before or after this runs),
+#             never committed. Entries are written unconditionally, the same
+#             way apply-project-visibility.sh gitignores project/ whether or
+#             not it exists yet, so a scaffold created by a later
+#             /distribute run is covered too, not just one already on disk.
+#
+# Exit codes:
+#   0  Success
+#   1  Bad usage or missing prerequisite
+#   2  Invalid mode (outside the two-value enum)
+#   3  Filesystem apply failure
+#   4  jenga.config.json write failure
+
+# Do NOT use set -e globally — each step handles its own errors.
+set -uo pipefail
+
+info() { echo "[scaffold-visibility] $*"; }
+warn() { echo "[scaffold-visibility] WARNING: $*"; }
+err()  { echo "[scaffold-visibility] ERROR: $*" >&2; }
+
+usage() {
+  echo "Usage: $(basename "$0") <visible|ignored> [project_root]" >&2
+  echo "       $(basename "$0") --check-only <visible|ignored>" >&2
+  exit 1
+}
+
+# The distributed framework scaffold — mirrored copies of skills/agents for
+# Claude Code and Copilot/other agents. Distinct from JENGA_WORKING_PATHS in
+# apply-project-visibility.sh, which covers project/ only.
+JENGA_SCAFFOLD_PATHS=(".claude" ".agents")
+
+VALID_MODES="visible ignored"
+
+validate_mode() {
+  local mode="$1"
+  for valid in $VALID_MODES; do
+    [ "$mode" = "$valid" ] && return 0
+  done
+  err "Invalid scaffold_visibility value: '${mode}'"
+  err "Allowed values are: ${VALID_MODES// /, }"
+  exit 2
+}
+
+# ---------------------------------------------------------------------------
+# Argument parsing
+# ---------------------------------------------------------------------------
+
+CHECK_ONLY=0
+if [ "${1:-}" = "--check-only" ]; then
+  CHECK_ONLY=1
+  shift
+fi
+
+MODE="${1:-}"
+[ -n "$MODE" ] || usage
+
+validate_mode "$MODE"
+
+if [ "$CHECK_ONLY" -eq 1 ]; then
+  info "Mode '$MODE' is valid."
+  exit 0
+fi
+
+PROJECT_ROOT="${2:-$PWD}"
+if [ ! -d "$PROJECT_ROOT" ]; then
+  err "Project root does not exist: $PROJECT_ROOT"
+  exit 1
+fi
+cd "$PROJECT_ROOT" || { err "Cannot enter project root: $PROJECT_ROOT"; exit 1; }
+
+if ! command -v jq >/dev/null 2>&1; then
+  err "jq is required to write jenga.config.json but was not found on PATH."
+  exit 1
+fi
+
+# ---------------------------------------------------------------------------
+# ignored — append to .gitignore, without ever duplicating an entry
+# ---------------------------------------------------------------------------
+
+gitignore_append() {
+  local entry="$1"
+  local gitignore=".gitignore"
+
+  if [ -f "$gitignore" ] && grep -qxF -- "$entry" "$gitignore"; then
+    info "'$entry' already present in .gitignore — skipping."
+    return 0
+  fi
+
+  # Don't glue our entry onto a final line that lacks a newline.
+  if [ -s "$gitignore" ] && [ -n "$(tail -c 1 "$gitignore")" ]; then
+    printf '\n' >> "$gitignore"
+  fi
+
+  if ! printf '%s\n' "$entry" >> "$gitignore"; then
+    err "Failed to append '$entry' to .gitignore"
+    exit 3
+  fi
+  info "Added '$entry' to .gitignore"
+}
+
+# ---------------------------------------------------------------------------
+# jenga.config.json — merge the field in, written atomically (temp + mv)
+# ---------------------------------------------------------------------------
+
+write_scaffold_config() {
+  local mode="$1"
+  local config="jenga.config.json"
+  local tmp="${config}.tmp"
+  local existing='{}'
+
+  # /init normally runs before any /distribute, so the file usually does not
+  # exist yet. Merge rather than overwrite so other fields survive.
+  if [ -f "$config" ]; then
+    if ! jq empty "$config" 2>/dev/null; then
+      err "$config exists but contains malformed JSON — refusing to overwrite it."
+      exit 4
+    fi
+    existing="$(cat "$config")"
+  fi
+
+  local content
+  content="$(jq --arg v "$mode" '.scaffold_visibility = $v' <<< "$existing")"
+  if [ -z "$content" ]; then
+    err "Failed to construct $config content."
+    exit 4
+  fi
+
+  if ! printf '%s\n' "$content" > "$tmp"; then
+    err "Failed to write temporary config file: $tmp"
+    exit 4
+  fi
+
+  if ! mv "$tmp" "$config"; then
+    err "Failed to atomically move $tmp to $config"
+    rm -f "$tmp"
+    exit 4
+  fi
+
+  info "Wrote scaffold_visibility = \"$mode\" to $config"
+}
+
+# ---------------------------------------------------------------------------
+# Apply
+# ---------------------------------------------------------------------------
+
+case "$MODE" in
+  visible)
+    info "Mode 'visible' — scaffold directories stay in place; nothing to change on disk."
+    ;;
+  ignored)
+    for path in "${JENGA_SCAFFOLD_PATHS[@]}"; do
+      gitignore_append "${path}/"
+    done
+    ;;
+esac
+
+write_scaffold_config "$MODE"
+
+info "Applied scaffold_visibility '$MODE' to $PROJECT_ROOT"

package/skills/j-init/scripts/init.sh

@@ -4,6 +4,7 @@ set -euo pipefail
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 ASSETS_DIR="$SCRIPT_DIR/../assets"
 VISIBILITY_SCRIPT="$SCRIPT_DIR/apply-project-visibility.sh"
+SCAFFOLD_VISIBILITY_SCRIPT="$SCRIPT_DIR/apply-scaffold-visibility.sh"
 
 # ─── Resolve the package root that owns templates/ and lib/ ──────────────────
 # postinstall.js mirrors only skills/ and agents/ into .claude/ and .agents/ —
@@ -22,23 +23,33 @@ else
   exit 1
 fi
 
-# ─── 0. Resolve project_files_visibility ─────────────────────────────────────
+# ─── 0. Resolve project_files_visibility and scaffold_visibility ─────────────
 # Defaults to `visible` — the only value that touches nothing on disk — so an
 # unattended run can never silently relocate directories or edit .gitignore.
+# project_files_visibility covers the project/ working tree (board, todo.md,
+# queue/, rapports/, logs/). scaffold_visibility is a distinct, independent
+# flag (E31_S07_T01, ported here in E31_S07_T03) covering the distributed
+# .claude/.agents framework scaffold — kept separate per
+# skills/distribute/CONFIG_SCHEMA.md's "Scaffold visibility" section, rather
+# than folded into project_files_visibility's existing enum.
 VISIBILITY="${JENGA_PROJECT_FILES_VISIBILITY:-visible}"
+SCAFFOLD_VISIBILITY="${JENGA_SCAFFOLD_VISIBILITY:-visible}"
 
 while [[ $# -gt 0 ]]; do
   case "$1" in
     --visibility)   VISIBILITY="${2:-}"; shift 2 ;;
     --visibility=*) VISIBILITY="${1#*=}"; shift ;;
+    --scaffold-visibility)   SCAFFOLD_VISIBILITY="${2:-}"; shift 2 ;;
+    --scaffold-visibility=*) SCAFFOLD_VISIBILITY="${1#*=}"; shift ;;
     *) echo "Unknown argument: $1" >&2
-       echo "Usage: $(basename "$0") [--visibility <visible|ignored>]" >&2
+       echo "Usage: $(basename "$0") [--visibility <visible|ignored>] [--scaffold-visibility <visible|ignored>]" >&2
        exit 1 ;;
   esac
 done
 
 # Validate before scaffolding so a typo cannot leave a half-initialised project.
 bash "$VISIBILITY_SCRIPT" --check-only "$VISIBILITY"
+bash "$SCAFFOLD_VISIBILITY_SCRIPT" --check-only "$SCAFFOLD_VISIBILITY"
 
 # ─── 1. Initialize git repository ────────────────────────────────────────────
 echo "→ Initializing git repository..."
@@ -101,11 +112,14 @@ cp "$ASSETS_DIR/strategy_stub_template.md" docs/STRATEGY.md
 echo "→ Creating CHANGELOG.md from template..."
 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
-# initial commit.
+# ─── 11. Apply project_files_visibility and scaffold_visibility ─────────────
+# Both run before the commit so any resulting .gitignore entries (ignored)
+# are captured in the initial commit rather than left for the user to notice
+# after the fact.
 echo "→ Applying project files visibility ($VISIBILITY)..."
 bash "$VISIBILITY_SCRIPT" "$VISIBILITY" "$PWD"
+echo "→ Applying scaffold visibility ($SCAFFOLD_VISIBILITY)..."
+bash "$SCAFFOLD_VISIBILITY_SCRIPT" "$SCAFFOLD_VISIBILITY" "$PWD"
 
 # ─── 12. Generate CLAUDE.md / AGENTS.md ──────────────────────────────────────
 # Unconditional — never gated on agentTarget (E41_S04). Applies the J-

package/skills/j-skillify/assets/init-new/assets/.gitignore_template

@@ -11,5 +11,4 @@ Desktop.ini
 # Dependency directories
 node_modules/
 vendor/
-.venv/
-EOF
+.venv/

package/skills/j-uncharted/SKILL.md

@@ -168,6 +168,7 @@ For genuinely undocumented code, there is often no reliable human oracle to conf
 
 - **The deterministic pipeline remains the tool of record for zero-oracle codebases.** `onboard --legacy` and `segment --mode delivery` never depend on anyone confirming intent — they ground everything in mechanical evidence (file structure, dependencies, test coverage) and say so explicitly under `Open Questions` when the evidence doesn't support a conclusion. When there is no one left who understands the code, reach for one of those, not the conversational flow.
 - **When running the conversational flow, do not manufacture confidence.** If the user's answer is uncertain, hedged, or contradicts what discovery/Investigative Mode found, write the node honestly — do not round an uncertain answer up to a confirmed one. There is no schema field yet to tag confidence (the stub schema is intentionally minimal); until one exists, say so in the node's `description` text itself (e.g. "per the user, this module retries failed charges — unconfirmed against the code, which shows only a single retry attempt") rather than silently dropping the caveat.
+- **`verification_depth: strict` is this guidance's concrete implementation, not a separate idea (E40_S06_T02).** When a candidate's Familiarity Check answer is `No` (Convergence Loop Step 1), Step 4's risk-weighted gating never lets an escalating finding round up to a false confirmation by asking the user to bless it — it auto-flags the node with exactly the hedged-`description` convention this bullet describes and converges it without a prompt. This bullet states the principle; Step 4's `strict` branch is what enforces it mechanically, so the two sections should be read as one mechanism, not two independently-arrived-at claims.
 - **A confidently wrong answer is not detectable by this flow.** Corroboration against a second signal (commit history, existing docs, a second person) is the only mitigation, and it is not built here — this is the accepted residual risk, not a gap to engineer around mid-conversation.
 
 ### Directory Triage
@@ -213,10 +214,56 @@ Silence, a counter-question, or an ambiguous reply is not consent — re-ask, th
 
 Runs once per surviving candidate (a subsystem, a named flow, a directory) after Directory Triage. This is the "propose understanding, ask the user to confirm or correct" cycle at the center of the redesign — and the one the scrutiny flagged as having no termination bound and no defense against confirmation fatigue. Both gaps are closed mechanically, not by agent discipline alone:
 
-1. **Dispatch Investigative Mode.** Per `agents/developer.md`'s and `agents/tester.md`'s Investigative Mode sections (E20_S08_T02), dispatch the developer to trace what the code actually does for the candidate, and the tester to trace what the test suite actually exercises and verifies for the same candidate — two distinct vantage points, not two names for the same read. Both are read-only, worktree-sandboxed, no commits, no board writes.
-2. **Propose understanding.** From both traces, draft the candidate's coarse graph node(s)/edge(s) (per the stub schema) and a plain-language summary of what they represent.
-3. **Risk-weighted gating — not every finding gets a prompt.** This is the fix for confirmation fatigue (solution assessment, Problem 6, Solution B — RECOMMENDED): force an explicit confirmation only for **high-uncertainty or high-impact** findings — a node whose description depends on an inference the traces don't fully support, a node with many outgoing edges (structurally central), or one the Human-Oracle-Availability Limitation above already flagged as uncertain. **Auto-accept** low-risk, high-confidence findings — the traces agree, the finding is narrow in scope, nothing about it is surprising — without a prompt, but **log every auto-accepted node** in the elicitation state's checkpoint data (see below) so the decision is auditable later, per that solution's own mitigation for "the scoring mechanism itself misjudges impact."
-4. **Confirm/correct, one round per call to `elicitation-state.sh turn`.** For a node requiring confirmation, present the draft and ask the user to confirm or correct it (per the Interaction Pattern in `CLAUDE.md` — confirm / correct-with-detail / defer as "unconfirmed" / other). Each round, call:
+1. **Familiarity Check — once per candidate, before Investigative Mode dispatch.** Ask (per the Interaction Pattern in `CLAUDE.md` — numbered list, free-text last):
+
+   ```
+   Are you familiar with this service/segment?
+   1. Yes
+   2. A little
+   3. No
+   4. Other (describe below)
+   ```
+
+   Silence, a counter-question, or an ambiguous reply is not consent — re-ask, the same convention used at every other confirmation gate in this skill. Map the answer to a `verification_depth` scoped to this candidate only — `Yes` → `shallow`, `A little` → `moderate`, `No` → `strict` — and persist it immediately, keyed by this candidate's node id, via `elicitation-state.sh`'s checkpoint mechanism (see Multi-Session Persistence below for the exact call and merge semantics):
+
+   ```bash
+   printf '{"verification_depth": {"%s": "%s"}}' "<candidate-id>" "<shallow|moderate|strict>" \
+     | bash skills/j-uncharted/scripts/elicitation-state.sh checkpoint --id <elicitation-id> --json -
+   ```
+
+   **Check before asking.** A candidate whose `verification_depth` is already present in the state file's `checkpoint.verification_depth` (per Multi-Session Persistence below) has already answered this — do not re-ask it, on a fresh session or otherwise.
+
+   This question operationalizes the Human-Oracle-Availability Limitation above — it is the mechanism for finding out, per candidate, how much weight the user's own confirmations should carry, rather than assuming a uniform level of trust for every candidate in one run. **`verification_depth` is read back and consumed by Step 4's risk-weighted gating below (`E40_S06_T02`)**, which branches its auto-accept/confirm/auto-flag behavior per depth. The fixed internal/external question template used whenever shallow/moderate gating does decide to prompt (Step 5) is `skills/j-uncharted/assets/NODE_QUESTION_TEMPLATE.md` (`E40_S06_T03`) — this step's job remains asking the question and making the answer durable for those steps to read.
+2. **Dispatch Investigative Mode.** Per `agents/developer.md`'s and `agents/tester.md`'s Investigative Mode sections (E20_S08_T02), dispatch the developer to trace what the code actually does for the candidate, and the tester to trace what the test suite actually exercises and verifies for the same candidate — two distinct vantage points, not two names for the same read. Both are read-only, worktree-sandboxed, no commits, no board writes.
+3. **Propose understanding.** From both traces, draft the candidate's coarse graph node(s)/edge(s) (per the stub schema) and a plain-language summary of what they represent.
+4. **Risk-weighted gating — not every finding gets a prompt, and `verification_depth` (Step 1) decides how gating itself behaves, not just what counts as risky.** This is the fix for confirmation fatigue (solution assessment, Problem 6, Solution B — RECOMMENDED). The baseline escalation criteria — the three triggers that force an explicit confirmation — are unchanged from before `E40_S06`:
+
+   - **T1 — inference-dependent:** the node's description depends on an inference the traces don't fully support.
+   - **T2 — structurally central:** the node has many outgoing edges.
+   - **T3 — already-flagged uncertain:** the Human-Oracle-Availability Limitation above already flagged this finding as uncertain.
+
+   A finding tripping none of T1-T3 is **low-risk** and auto-accepts regardless of depth. A finding tripping any of T1-T3 is **escalating**, and what happens to it now branches on the current candidate's `verification_depth` (read from `checkpoint.verification_depth.<candidate-id>`, per Step 1):
+
+   - **`moderate` (the default, unchanged calibration)** — exactly today's behavior: every escalating finding (any of T1-T3) forces a confirm prompt (Step 5); every low-risk finding auto-accepts without a prompt. **Log every auto-accepted node** in the elicitation state's checkpoint data (see Multi-Session Persistence below) so the decision is auditable later, per that solution's own mitigation for "the scoring mechanism itself misjudges impact."
+   - **`shallow` (widened auto-accept)** — the concrete widening rule: **drop T2 (structurally central) as an escalation trigger.** A finding tripping T2 alone — structurally central, but not inference-dependent and not already flagged uncertain — is reclassified low-risk and auto-accepted (still logged, same as above) instead of escalating. T1 and T3 still force a confirm prompt exactly as under `moderate`; only the T2-alone case widens. This is the literal reading of "findings that would sit just below today's high-impact bar" from the task's own framing — a purely structural signal with no corroborating uncertainty is no longer, by itself, enough to interrupt the user.
+   - **`strict` (no confirm prompt for escalating findings, ever)** — a finding tripping any of T1-T3 is **never presented to the user**. Instead:
+     1. Write the node directly with a hedged, low-confidence `description`, reusing the exact hedging convention the Human-Oracle-Availability Limitation section already specifies (e.g. "unconfirmed — traces did not fully corroborate this," adapted to name the specific gap).
+     2. Call `elicitation-state.sh converge` directly — **do not call `elicitation-state.sh turn` for this node.** No confirmation round is spent; the node goes straight from "proposed" to "converged," never "pending":
+
+        ```bash
+        bash skills/j-uncharted/scripts/elicitation-state.sh converge --id <elicitation-id> --node <node-id> --note "auto-flagged under strict depth: <one-line reason, e.g. 'structurally central, traces disagree on scope'>"
+        ```
+     3. **Log the auto-flag** in the elicitation state's checkpoint data, the same way `moderate`/`shallow` auto-accepts are logged — this is an automatic decision, not a silent one, and stays auditable exactly like every other gating outcome.
+
+     Low-risk findings under `strict` are unaffected — they auto-accept exactly as under `moderate`/`shallow`. `strict` only changes what happens to the escalating case.
+
+   The fixed internal/external question template used whenever `shallow`/`moderate` gating does decide to prompt is `skills/j-uncharted/assets/NODE_QUESTION_TEMPLATE.md` (Step 5, `E40_S06_T03`) — dormant under `strict`, since no prompt ever fires there.
+5. **Confirm/correct, one round per call to `elicitation-state.sh turn`.** Never reached for a `strict`-depth candidate's escalating findings — those converge directly per Step 4 above. For a node requiring confirmation under `shallow`/`moderate`, do **not** present the draft with a fully open-ended "propose understanding, ask to confirm or correct" prompt. Instead use the fixed question set in `skills/j-uncharted/assets/NODE_QUESTION_TEMPLATE.md` (`E40_S06_T03`), selecting the variant by node kind:
+
+   - **Internal variant** — the node represents the candidate/service itself (the thing this investigation is about).
+   - **External variant** — the node represents a dependency or consumer the traces surfaced outside the candidate (something it calls, or something that calls it).
+
+   Present the drafted node/edge summary from Step 3 first, then ask the selected variant's fixed questions, then offer the same confirm / correct-with-detail / defer-as-unconfirmed / other choice as before (per the Interaction Pattern in `CLAUDE.md`) — the template file spells out both the questions and this response block verbatim, so read it rather than reconstructing either from memory. Each round, call:
 
    ```bash
    bash skills/j-uncharted/scripts/elicitation-state.sh turn --id <elicitation-id> --node <node-id>
@@ -233,7 +280,7 @@ Runs once per surviving candidate (a subsystem, a named flow, a directory) after
    ```
 
    Option 3 is the only way past the cap, and it is a per-node, explicit, one-time override — it does not raise the cap for the rest of the run.
-5. **On convergence** (confirmed, corrected-and-accepted, or resolved via the cap choice above), call:
+6. **On convergence** (confirmed, corrected-and-accepted, or resolved via the cap choice above), call:
 
    ```bash
    bash skills/j-uncharted/scripts/elicitation-state.sh converge --id <elicitation-id> --node <node-id> --note "<one-line summary of what was confirmed>"
@@ -252,9 +299,9 @@ A whole-codebase `onboard` conversation, or an investigation of a large director
   ```
 
   Idempotent — safe to call again on a resumed `<elicitation-id>` without resetting progress. Choose `<elicitation-id>` so it is stable and re-derivable across sessions (e.g. `onboard-<root-slug>-<date>`, or `segment-investigate-<target-slug>`), since a resuming session must be able to reconstruct it to call `init` again.
-- **`checkpoint` after every converged node and after the Directory Triage confirmation gate** — never only at the end. This is what makes a mid-run pause lossless: `checkpoint --id <id> --json <file>` merges arbitrary progress data (triage results, draft nodes not yet converged, anything else worth surviving a pause) into the state file.
+- **`checkpoint` after every converged node, after the Directory Triage confirmation gate, and after every Familiarity Check answer** — never only at the end. This is what makes a mid-run pause lossless: `checkpoint --id <id> --json <file>` merges arbitrary progress data (triage results, draft nodes not yet converged, per-candidate `verification_depth`, anything else worth surviving a pause) into the state file. `verification_depth` is stored as one object keyed by candidate id — `checkpoint.verification_depth.<candidate-id>` — and, per the script's own merge semantics (see its header), checking one candidate in never clobbers another candidate already recorded there.
 - **`pause` when a session must end before the elicitation has converged.** Immediately after calling `elicitation-state.sh pause --id <elicitation-id>`, write the scrum-master's own `SessionEnd` handoff (per `$([ -f templates/SCRUM_BOARD_SCHEMA.md ] && echo templates/SCRUM_BOARD_SCHEMA.md || echo node_modules/@jenga-ai/agent/templates/SCRUM_BOARD_SCHEMA.md)`'s `handoffs/` convention) with `status: "elicitation_paused"` and both `elicitation_id` and `state_file` set — `hooks/on_session_end.sh` routes that into an `elicitation_resume` trigger on `scrum_triggers.jsonl`, which the next scrum-master session's Drain Scrum Triggers Queue procedure picks up (`agents/scrum-master.md`).
-- **On resume**, read `state_file` directly — every converged node, every flagged node, and the checkpoint data (including the confirmed directory-triage lists) are already there. Do not re-run Directory Triage or re-ask about an already-converged node; resume the Convergence Loop only for nodes still `pending` or explicitly deferred.
+- **On resume**, read `state_file` directly — every converged node, every flagged node, and the checkpoint data (including the confirmed directory-triage lists and any per-candidate `verification_depth` already recorded) are already there. Do not re-run Directory Triage, re-ask the Familiarity Check for a candidate already present under `checkpoint.verification_depth`, or re-ask about an already-converged node; resume the Convergence Loop only for nodes still `pending` or explicitly deferred, and only ask the Familiarity Check for a candidate that has neither.
 - **`complete` when every candidate has converged, been deferred, or been explicitly accepted past the cap.** The state file is left on disk afterward as an audit trail — nothing currently prunes a completed elicitation's state file.
 
 ---

package/skills/j-uncharted/assets/NODE_QUESTION_TEMPLATE.md

@@ -0,0 +1,69 @@
+<!--
+  NODE QUESTION TEMPLATE — /uncharted Convergence Loop.
+
+  Added by E40_S06_T03. Consumed by the Convergence Loop's Step 5
+  ("Confirm/correct", skills/j-uncharted/SKILL.md) whenever risk-weighted
+  gating (Step 4) decides a finding needs a confirm prompt under
+  `verification_depth: shallow` or `moderate`. Never reached under `strict`
+  — Step 4's strict branch converges the node directly, without ever
+  reaching Step 5, so this template is simply not invoked in that case.
+
+  Two fixed variants, selected by node kind:
+
+    INTERNAL — the node represents the candidate/service itself (the thing
+      `/uncharted` is investigating).
+    EXTERNAL — the node represents something outside the candidate that the
+      traces surfaced: a dependency it calls, or a consumer that calls it.
+
+  This replaces a fully open-ended "propose understanding, ask the user to
+  confirm or correct it" prompt for any node that fits one of these two
+  kinds — which, per the Convergence Loop, is every node this flow drafts.
+  Wording is fixed and matches the brainstorm's agreed phrasing verbatim
+  (project/documentation/examples/uncharted-conversational-elicitation-procedure.md);
+  do not paraphrase it when presenting the prompt.
+
+  Usage: present the drafted node/edge summary first (per Step 3's draft),
+  then ask the questions below for the selected variant, then offer the
+  same confirm / correct-with-detail / defer-as-unconfirmed / other choice
+  Step 5 already documents. This file supplies the fixed *questions*; the
+  response mechanics (turn cap, converge call) are unchanged and live in
+  SKILL.md, not here.
+-->
+
+# Node Question Template
+
+## Internal Node
+
+Use when the node represents the candidate/service itself — the thing this investigation is about,
+not something external to it.
+
+1. What is this?
+2. What does it do?
+3. Who consumes it?
+4. Other (describe below)
+
+## External Node
+
+Use when the node represents a dependency or consumer the traces surfaced outside the candidate —
+something the service calls, or something that calls the service.
+
+1. What is this?
+2. What does it do?
+3. Is the service producing to it, or consuming from it?
+4. Who is the producer, and who is the consumer?
+5. Other (describe below)
+
+---
+
+After the selected question set, present the standard confirm/correct choice (per the Interaction
+Pattern in `CLAUDE.md` and Convergence Loop Step 5):
+
+```
+1. Confirm the draft as accurate
+2. Correct it — describe what's wrong
+3. Defer — mark this node "unconfirmed" for now
+4. Other (describe below)
+```
+
+Silence, a counter-question, or an ambiguous reply is not consent — re-ask, the same convention used
+at every other confirmation gate in this skill.

package/skills/j-uncharted/scripts/elicitation-state.sh

@@ -53,7 +53,23 @@
 #     "nodes": {
 #       "<node-id>": { "turns": <int>, "status": "pending"|"converged"|"flagged", "note": "<text>" }
 #     },
-#     "checkpoint": { ...arbitrary, agent-defined fields, e.g. directory-triage results... }
+#     "checkpoint": {
+#       ...arbitrary, agent-defined fields, e.g. directory-triage results...
+#       "verification_depth": {
+#         // Recognized field (E40_S06_T01). Per-candidate Familiarity Check
+#         // answer from skills/j-uncharted/SKILL.md's Convergence Loop Step 1,
+#         // keyed by candidate/node id so a resumed elicitation can tell which
+#         // candidates already answered. Values are "shallow" | "moderate" |
+#         // "strict". Written and read by the agent driving /uncharted, same
+#         // as every other checkpoint field — this script assigns it no
+#         // special handling beyond the dict-merge behavior documented under
+#         // `checkpoint` below (which exists so that checking in one
+#         // candidate's depth never clobbers another's already recorded
+#         // here). Consumed by E40_S06_T02's risk-weighted gating; unread by
+#         // anything in this script or E40_S06_T01's own scope.
+#         "<candidate-id>": "shallow" | "moderate" | "strict"
+#       }
+#     }
 #   }
 #
 # ---------------------------------------------------------------------------
@@ -79,11 +95,22 @@
 #       the node's note (e.g. a one-line summary of what was confirmed).
 #
 #   checkpoint --id ID --json FILE
-#       Shallow-merge the JSON object in FILE (or stdin when FILE is "-")
-#       into the state's top-level "checkpoint" field. New keys are added;
-#       existing keys are overwritten by the new value. This is the generic
-#       "save progress" primitive — directory-triage results, draft node
-#       content, anything else the flow wants durable before it might pause.
+#       Merge the JSON object in FILE (or stdin when FILE is "-") into the
+#       state's top-level "checkpoint" field. New keys are added; existing
+#       keys are overwritten by the new value — EXCEPT when both the existing
+#       value and the new value for a given key are themselves JSON objects,
+#       in which case they are merged one level deep instead of one replacing
+#       the other (existing sub-keys are kept, new sub-keys are added,
+#       conflicting sub-keys take the new value). This one-level dict merge
+#       is what lets a map-shaped field addressed by its own sub-keys — e.g.
+#       "verification_depth", keyed per candidate id (E40_S06_T01) — accumulate
+#       entries across separate checkpoint calls instead of each call
+#       clobbering every entry a previous call wrote. Plain (non-dict)
+#       values — strings, numbers, lists, directory-triage's own arrays —
+#       still simply overwrite, exactly as before this addition. This is the
+#       generic "save progress" primitive — directory-triage results, draft
+#       node content, anything else the flow wants durable before it might
+#       pause.
 #
 #   pause --id ID
 #       Set status "paused" and update "updated_at". The caller (the agent
@@ -422,7 +449,18 @@ elif subcommand == "checkpoint":
     state = load()
     payload = json.loads(checkpoint_json)
     cp = state.setdefault("checkpoint", {})
-    cp.update(payload)
+    # One-level-deep merge when both sides are dicts (E40_S06_T01) — lets a
+    # map-shaped field keyed by its own sub-keys (e.g. verification_depth,
+    # keyed per candidate id) accumulate entries across separate checkpoint
+    # calls instead of each call replacing the whole field. Anything else
+    # (strings, numbers, lists, or a dict landing on a non-dict/absent key)
+    # keeps the prior plain overwrite behavior.
+    for key, value in payload.items():
+        existing = cp.get(key)
+        if isinstance(existing, dict) and isinstance(value, dict):
+            existing.update(value)
+        else:
+            cp[key] = value
     state["updated_at"] = now
     atomic_write(state)
     result = {"checkpoint_keys": list(payload.keys())}

package/skills/jenga/scripts/load-playbooks.sh

@@ -461,18 +461,30 @@ if [ -n "${JENGA_PLAYBOOKS_TEST_ROOT:-}" ]; then
   # E53_S05_T01 to also cover playbook-config.json resolution). Never set in a real invocation.
   PKG_ROOT="$JENGA_PLAYBOOKS_TEST_ROOT"
   PROJECT_DIR="$JENGA_PLAYBOOKS_TEST_ROOT"
-# Resolve the jenga-agent PACKAGE root (where the canonical skills/ tree actually lives) — same
-# monorepo-checkout vs. installed-npm-package detection used by
-# skills/jenga/scripts/load-nl-catalog.sh's PKG_ROOT resolution and skills/init/scripts/init.sh.
-elif [ -d "$SCRIPT_DIR/../../../templates" ]; then
-  PKG_ROOT="$SCRIPT_DIR/../../.."
-  PROJECT_DIR="${JENGA_PROJECT_DIR:-${CLAUDE_PROJECT_DIR:-$(git -C "$SCRIPT_DIR" rev-parse --show-toplevel 2>/dev/null || pwd)}}"
-elif [ -n "${CLAUDE_PROJECT_DIR:-}" ] && [ -d "${CLAUDE_PROJECT_DIR}/node_modules/@jenga-ai/agent/templates" ]; then
-  PKG_ROOT="${CLAUDE_PROJECT_DIR}/node_modules/@jenga-ai/agent"
-  PROJECT_DIR="${JENGA_PROJECT_DIR:-$CLAUDE_PROJECT_DIR}"
 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 2
+  # Resolve JENGA_PROJECT_DIR the same way every other script in skills/jenga/scripts/ does.
+  if [ -f "$SCRIPT_DIR/../../../lib/resolve-project-dir.sh" ]; then
+    # shellcheck source=/dev/null
+    source "$SCRIPT_DIR/../../../lib/resolve-project-dir.sh"
+  elif [ -n "${CLAUDE_PROJECT_DIR:-}" ]; then
+    JENGA_PROJECT_DIR="$CLAUDE_PROJECT_DIR"
+  else
+    JENGA_PROJECT_DIR="$(git -C "$SCRIPT_DIR" rev-parse --show-toplevel 2>/dev/null || pwd)"
+  fi
+
+  # Resolve the jenga-agent PACKAGE root (where the canonical skills/ tree actually lives) — same
+  # monorepo-checkout vs. installed-npm-package detection used by
+  # skills/jenga/scripts/load-nl-catalog.sh's PKG_ROOT resolution and skills/init/scripts/init.sh.
+  if [ -d "$SCRIPT_DIR/../../../templates" ]; then
+    PKG_ROOT="$SCRIPT_DIR/../../.."
+    PROJECT_DIR="$JENGA_PROJECT_DIR"
+  elif [ -d "$JENGA_PROJECT_DIR/node_modules/@jenga-ai/agent/templates" ]; then
+    PKG_ROOT="$JENGA_PROJECT_DIR/node_modules/@jenga-ai/agent"
+    PROJECT_DIR="$JENGA_PROJECT_DIR"
+  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 2
+  fi
 fi
 
 PLAYBOOKS_DIR="$PKG_ROOT/skills/jenga/playbooks"