@jenga-ai/agent 3.4.0 → 3.6.0

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/j-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..."
@@ -68,7 +79,7 @@ echo "→ Copying test-config.json from template..."
 cp "$ASSETS_DIR/test-config_template.json" project/configs/test-config.json
 
 # ─── 6.5. Create project/configs/scope-thresholds.json ───────────────────────
-# Consumed by skills/jenga (Phase 0) and skills/do (Step 0); both halt if it's
+# Consumed by skills/jenga (Phase 0) and skills/j-do (Step 0); both halt if it's
 # missing, so it must exist immediately after scaffold.
 echo "→ Copying scope-thresholds.json from template..."
 cp "$ASSETS_DIR/scope-thresholds_template.json" project/configs/scope-thresholds.json
@@ -82,7 +93,7 @@ echo "→ Creating events.json..."
 echo '[]' > project/logs/events.json
 
 # ─── 8.5. Create project/knowledge-graph/{STUB_SCHEMA.md,graph.json} ─────────
-# Consumed by skills/uncharted's conversational elicitation flow (`onboard`,
+# Consumed by skills/j-uncharted's conversational elicitation flow (`onboard`,
 # `segment --mode investigate`), which writes coarse graph nodes/edges to
 # graph.json per the stub schema — both must exist before that flow's first
 # write, per templates/KNOWLEDGE_GRAPH_STUB_SCHEMA_TEMPLATE.md's own header
@@ -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-
@@ -124,4 +138,4 @@ git add -A
 git commit -m "init: scaffold project structure and workflow config"
 
 echo ""
-echo "✓ Project scaffold complete."
+echo "✓ Project scaffold complete."

package/skills/j-playbook/SKILL.md

@@ -8,7 +8,7 @@ keywords:
   - execute playbook
 examples:
   - "j.playbook brainstorm-to-mirror"
-  - "run the understand-then-ship playbook"
+  - "run the understand-then-commit playbook"
   - "invoke playbook by id"
 ---
 

package/skills/j-publish/SKILL.md

@@ -265,7 +265,7 @@ Release-note rules:
 - **`--output <path>`:** writes a standalone, disposable draft to that path instead (the pre-E36 behavior) — `CHANGELOG.md` is not touched in this mode.
 - If no prior ledger-backed tag exists, a `--output` draft includes `> First release — full history included`; the standing `CHANGELOG.md` merge mode has no equivalent banner (it just merges full history into `[Unreleased]` like any other run).
 - Scrum-board enrichment is best-effort only; missing or unreadable board data never fails the command.
-- **`.publicignore` filtering:** when a repo-root `.publicignore` exists (the blocklist `/mirror-public` also reads), a candidate commit — or a completed task's associated commit(s), matched via the `task(E##_S##_T##):` commit-message convention — is dropped entirely when every changed file it touches is covered by that blocklist. A commit touching a mix of blocked and unblocked files is still logged normally; only full coverage excludes an entry. This exists because `CHANGELOG.md` itself is not blocklisted and ships to the public mirror, so an unfiltered entry referencing a private-only path (e.g. `project/board/`) would leak. Absent `.publicignore`, this is a strict no-op — unchanged from pre-E36_S02_T02 behavior. Matching reuses `skills/mirror-public/scripts/mirror.sh`'s `rsync --exclude-from` evaluation rather than a separate glob implementation, so a path classified "blocked" by `/mirror-public --dry-run` is classified "blocked" here too.
+- **`.publicignore` filtering:** when a repo-root `.publicignore` exists (the blocklist `/mirror-public` also reads), a candidate commit — or a completed task's associated commit(s), matched via the `task(E##_S##_T##):` commit-message convention — is dropped entirely when every changed file it touches is covered by that blocklist. A commit touching a mix of blocked and unblocked files is still logged normally; only full coverage excludes an entry. This exists because `CHANGELOG.md` itself is not blocklisted and ships to the public mirror, so an unfiltered entry referencing a private-only path (e.g. `project/board/`) would leak. Absent `.publicignore`, this is a strict no-op — unchanged from pre-E36_S02_T02 behavior. Matching reuses `skills/j-mirror-public/scripts/mirror.sh`'s `rsync --exclude-from` evaluation rather than a separate glob implementation, so a path classified "blocked" by `/mirror-public --dry-run` is classified "blocked" here too.
 
 ## Ledger & Tagging
 

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

@@ -239,7 +239,12 @@ automated and human halves of the flow:
   relies on the automated CI-staged test result) and then
   `bash skills/j-publish/scripts/npm_stage_inspect.sh approve <stage-id> --otp <otp>`
   from their own machine. `reject` (same script) is available to either
-  side to discard a staged candidate.
+  side to discard a staged candidate. On success, `approve` also generates
+  release notes into `CHANGELOG.md`'s `[Unreleased]` section and finalizes
+  it with the approved version — the same behavior described in
+  `adapters/npm.md`'s Staged Publishing section, shared by both target
+  types since it lives in `npm_stage_inspect.sh` itself, not in either
+  target-type-specific pipeline (E22_S09_T08).
 - **Stage-id capture reads the CI run's own log, not a local `npm stage
   list` call.** Because the actual `npm stage publish --provenance` call
   runs inside the dispatched Actions run, the local `npm_stage_pipeline.sh`

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

@@ -119,7 +119,7 @@ becomes visible on the registry. See `skills/j-publish/SKILL.md`'s
 
 - `bash skills/j-publish/scripts/npm_stage_pipeline.sh <target> <path-to-publish.json> [--dry-run] [--non-interactive] [--otp <otp>]` runs validate → gates → pack → stage → capture → ledger and writes a `staged` ledger entry.
 - `bash skills/j-publish/scripts/npm_stage_inspect.sh test <stage-id>` installs the staged tarball into an isolated scratch directory and smoke-tests it, writing a `stage_tested` ledger entry.
-- `bash skills/j-publish/scripts/npm_stage_inspect.sh approve <stage-id>` requires an npm 2FA one-time password and refuses without a passing `test` on record unless `--force <reason>` is given.
+- `bash skills/j-publish/scripts/npm_stage_inspect.sh approve <stage-id>` requires an npm 2FA one-time password and refuses without a passing `test` on record unless `--force <reason>` is given. On a successful `npm stage approve`, it also generates release notes into `CHANGELOG.md`'s `[Unreleased]` section and finalizes that section with the approved version — the same `generate_release_notes.sh` + `finalize_changelog.sh` pair `/publish deploy` runs, reused rather than duplicated (E22_S09_T08). `--dry-run` skips this (it exits before the real approve call runs at all); a failed `npm stage approve` skips it too (no changelog write on a failed approve); `--force` still runs it — `--force` only bypasses the passing-test requirement, not the changelog step.
 - `bash skills/j-publish/scripts/npm_stage_inspect.sh reject <stage-id>` discards the staged version.
 
 Same registry-existence precondition as a normal `npm` publish: staged

package/skills/j-publish/scripts/generate_release_notes.sh

@@ -76,7 +76,7 @@ git rev-parse --verify "$TO_REF" >/dev/null 2>&1 || {
 # Absence of .publicignore is a strict no-op — PI_ACTIVE stays 0 and every
 # _pi_* helper below fails open immediately.
 #
-# Matching semantics are borrowed from skills/mirror-public/scripts/mirror.sh
+# Matching semantics are borrowed from skills/j-mirror-public/scripts/mirror.sh
 # rather than reimplemented: that script's compute_ship_list asks rsync
 # itself "what would transfer past --exclude-from=.publicignore?" and that
 # is the single source of truth /mirror-public --dry-run reports as

package/skills/j-publish/scripts/npm_stage_inspect.sh

@@ -86,6 +86,8 @@ fi
 source "${SCRIPT_DIR}/publish_common.sh"
 
 WRITE_LEDGER_SCRIPT="${SCRIPT_DIR}/write_ledger_entry.sh"
+GENERATE_RELEASE_NOTES_SCRIPT="${SCRIPT_DIR}/generate_release_notes.sh"
+FINALIZE_CHANGELOG_SCRIPT="${SCRIPT_DIR}/finalize_changelog.sh"
 
 # ---------------------------------------------------------------------------
 # OTP tracing guard — MUST run at the top level, before `main "$@"` is ever
@@ -397,6 +399,53 @@ _write_stage_tested_ledger() {
   "${cmd[@]}" || log_warn "failed to write 'stage_tested' ledger entry for stage ${stage_id} (result: ${result})"
 }
 
+# _finalize_stage_changelog <target_name> <config_path> <package_version>
+#
+# `approve`'s equivalent of publish_deploy.sh's generate_release_notes() +
+# finalize_changelog() pair (E22_S09_T08) — reused verbatim, not
+# reimplemented. Only ever called AFTER a real `npm stage approve` call has
+# already succeeded, so a failure here never masks (nor is masked by) the
+# approve result itself; the caller decides how to report it.
+#
+# Mirrors publish_deploy.sh's resolve_last_tag(): resolves the last publish
+# tag from the ledger via publish_resolve_last_publish_tag, never a
+# hardcoded/guessed tag. Passes --from-tag only when a tag was actually
+# resolved, and passes the config path positional only when one is
+# resolved -- generate_release_notes.sh treats an omitted config the same
+# way it treats an unresolved one internally (falls back to its own
+# defaults via publish_resolve_history_file "").
+#
+# Uses the already-resolved package_version (from the stage's own `npm
+# stage view` output) for finalize_changelog.sh, per the task's acceptance
+# criteria -- never a re-derived version.
+_finalize_stage_changelog() {
+  local target_name="$1" config_path="$2" package_version="$3"
+  local history_file last_tag
+  local -a notes_cmd=(bash "${GENERATE_RELEASE_NOTES_SCRIPT}" --target "${target_name}")
+
+  history_file="$(publish_resolve_history_file "${config_path}")"
+  last_tag="$(publish_resolve_last_publish_tag "${history_file}" HEAD 2>/dev/null || true)"
+  [[ -n "${last_tag}" ]] && notes_cmd+=(--from-tag "${last_tag}")
+  [[ -n "${config_path}" ]] && notes_cmd+=("${config_path}")
+
+  if ! "${notes_cmd[@]}"; then
+    log_warn "failed to generate release notes for stage approve (target: ${target_name})"
+    return 1
+  fi
+
+  if [[ -z "${package_version}" ]]; then
+    log_warn "no package version resolved from stage view — skipping CHANGELOG.md finalization"
+    return 1
+  fi
+
+  if ! bash "${FINALIZE_CHANGELOG_SCRIPT}" "${package_version}" "${REPO_ROOT}/CHANGELOG.md"; then
+    log_warn "failed to finalize CHANGELOG.md for stage approve (version: ${package_version})"
+    return 1
+  fi
+
+  return 0
+}
+
 # ---------------------------------------------------------------------------
 # list [<package-spec>] [--config <path>] [--dry-run] [--json]
 # ---------------------------------------------------------------------------
@@ -772,6 +821,18 @@ cmd_approve() {
     exit "${EXIT_OP_FAILED}"
   fi
 
+  # Generate release notes into CHANGELOG.md's [Unreleased] section and
+  # stamp it with the approved version — mirroring publish_deploy.sh's own
+  # generate_release_notes() + finalize_changelog() pair (E22_S09_T08).
+  # Only reached after a confirmed successful `npm stage approve` above, so
+  # a failed approve never gets a changelog write, and --force only ever
+  # affects the test-interlock check earlier in this function — this step
+  # runs identically on both the normal and --force paths, no divergent
+  # logic. Never reached at all under --dry-run, which already exited
+  # earlier, before the real approve call.
+  _finalize_stage_changelog "${target_name}" "${config_path}" "${package_version}" \
+    || log_warn "stage ${stage_id} was approved, but CHANGELOG.md was not updated — see warnings above"
+
   local -a ledger_cmd=(bash "${WRITE_LEDGER_SCRIPT}" "${target_name}" "${target_type}" approved "" --stage-id "${stage_id}")
   [[ -n "${config_path}" ]] && ledger_cmd+=(--config "${config_path}")
   [[ -n "${package_version}" ]] && ledger_cmd+=(--version "${package_version}")

package/skills/j-reconcile/SKILL.md

@@ -3,7 +3,7 @@ name: j.reconcile
 description: Polyfill alias of the reconcile skill under a collision-safe directory name. Identical behavior to /reconcile — Reconcile the scrum board with actual implementation state. Cross-checks every task's board status against git history and worktrees, merges orphaned worktree branches, demotes unimplemented "Done" items, promotes secretly-implemented items, flags code with no board provenance and offers /uncharted segment for it, and cleans stale entries from todo.md. Use when the board feels out of sync, after a big merge session, when tasks were completed outside the normal workflow, or when todo.md has grown stale. Trigger on phrases like "sync the board", "clean up the board", "reconcile", "board is out of date", "todo is stale", or "check what's really done". Use when the bare /reconcile form is shadowed by another tool's own built-in command of the same name.
 metadata:
   prefered_agent: scrum-master
-output_types: text
+output_types: id_list
 keywords:
   - j-reconcile
   - polyfill
@@ -200,7 +200,7 @@ older conventions still present in this repo's history (`E04_S01: ...` and
 `feat(train): implement E01_S05 - ...`).
 
 The script reuses the board-linkage check from
-`skills/uncharted/scripts/resolve-segment-target.sh` through its batch interface. Do not
+`skills/j-uncharted/scripts/resolve-segment-target.sh` through its batch interface. Do not
 re-derive linkage yourself, and do not substitute a `grep` over `project/board/` if the script
 fails — a second answer to "is this path on the board" is what that reuse exists to prevent.
 If the script exits non-zero, report the failure in the reconcile report and continue to phase 6.

package/skills/j-reconcile/scripts/detect-unlinked-code.sh

@@ -37,7 +37,7 @@
 # SIGNAL A IS BORROWED, NOT REBUILT
 # ---------------------------------------------------------------------------
 # The board-linkage question is answered by
-# `skills/uncharted/scripts/resolve-segment-target.sh` (E40_S02_T01) through its
+# `skills/j-uncharted/scripts/resolve-segment-target.sh` (E40_S02_T01) through its
 # documented batch interface:
 #
 #     git ls-files | resolve-segment-target.sh --paths-from -
@@ -70,7 +70,7 @@
 #
 # This is deliberate. `run-engine.sh` currently renders the out-of-repo
 # `not_checked` case as `unlinked` in its understanding document, which asserts
-# a verified absence that was never verified. `skills/uncharted/SKILL.md` names
+# a verified absence that was never verified. `skills/j-uncharted/SKILL.md` names
 # Step 1 (`resolve-segment-target.sh`) authoritative on linkage where the two
 # disagree, so this script passes the resolver's status through unchanged and
 # does not repeat that conflation.
@@ -104,8 +104,8 @@
 # Classifying files and then reporting directories would assert about a
 # directory something that was only ever verified about its contents. Because
 # the resolver's match is a path-boundary test, a board item naming
-# `skills/convert/` links THAT DIRECTORY without linking
-# `skills/convert/convert_cli.py`. Both facts are true, and the directory-level
+# `skills/j-convert/` links THAT DIRECTORY without linking
+# `skills/j-convert/convert_cli.py`. Both facts are true, and the directory-level
 # one is what decides whether a segment is worth investigating -- offering
 # `/uncharted segment` there would duplicate a board item that already exists.
 #
@@ -125,7 +125,7 @@
 # MIRROR SPELLINGS. Per CLAUDE.md the canonical file lives in the root tree and
 # `.agents/`, `.claude/` are generated build outputs -- but older board items
 # were often written against the mirror path. E17_S05 owns `/reconcile-origin`
-# and names it `.agents/skills/reconcile-origin/SKILL.md`, so a match on the
+# and names it `.agents/skills/j-reconcile-origin/SKILL.md`, so a match on the
 # root path alone misses a board item that plainly owns the directory. Each
 # group directory is therefore asked about under its own name and under both
 # mirror prefixes, and `directory_linkage.matched_as` records which spelling
@@ -187,14 +187,14 @@
 #                  "not_checked_paths": N,
 #                  "groups": N, "covered_groups": N },
 #     "groups": [
-#       { "directory": "skills/skillify",
+#       { "directory": "skills/j-skillify",
 #         "unlinked_count": N,        // files keyed to THIS group
 #         "subtree_candidates": N,    // all candidates under the directory
 #         "subtree_unlinked": N,      // all unlinked under the directory
 #         "fully_unlinked": true,
 #         "directory_linkage": { "status": "unlinked", "reason": "...",
 #                                "items": [], "match_count": 0,
-#                                "matched_as": "skills/skillify" },
+#                                "matched_as": "skills/j-skillify" },
 #         "files": ["..."],           // capped by --limit
 #         "files_truncated": N }
 #     ],
@@ -295,7 +295,7 @@ REPO_ROOT=$(cd -- "$REPO_ROOT" && pwd -P)
 [ -n "$RESOLVER" ] || RESOLVER="$SCRIPT_DIR/../../uncharted/scripts/resolve-segment-target.sh"
 [ -f "$RESOLVER" ] || die 4 "board-linkage checker not found: $RESOLVER
   This script deliberately has no fallback implementation -- see the header. Restore
-  skills/uncharted/scripts/resolve-segment-target.sh or pass --resolver <path>."
+  skills/j-uncharted/scripts/resolve-segment-target.sh or pass --resolver <path>."
 [ -x "$RESOLVER" ] || die 4 "board-linkage checker is not executable: $RESOLVER"
 RESOLVER=$(cd -- "$(dirname -- "$RESOLVER")" && pwd -P)/$(basename -- "$RESOLVER")
 
@@ -572,8 +572,8 @@ for path, status in sorted(status_of.items()):
 # --- second pass: is the GROUP DIRECTORY itself on the board? ---------------------------------
 # Reporting a directory while only ever having checked the files inside it asserts an absence
 # that was never verified -- the same error this script is careful to avoid for `not_checked`.
-# The resolver's match is a path-boundary test, so a board item naming `skills/convert/` links
-# that directory without linking `skills/convert/convert_cli.py`. Both facts are true and the
+# The resolver's match is a path-boundary test, so a board item naming `skills/j-convert/` links
+# that directory without linking `skills/j-convert/convert_cli.py`. Both facts are true and the
 # directory-level one is the one that decides whether a segment is worth investigating.
 #
 # Same borrowed checker, same batch interface, one extra call. No new linkage logic -- the only
@@ -582,7 +582,7 @@ for path, status in sorted(status_of.items()):
 # MIRROR SPELLINGS. Per CLAUDE.md the canonical file lives in the root tree and `.agents/` and
 # `.claude/` are generated build outputs, but plenty of older board items were written against
 # the mirror path -- E17_S05 owns `/reconcile-origin` and names it as
-# `.agents/skills/reconcile-origin/SKILL.md`. A boundary match on the root path alone therefore
+# `.agents/skills/j-reconcile-origin/SKILL.md`. A boundary match on the root path alone therefore
 # misses a board item that plainly owns the directory. So each directory is asked about under its
 # own name and under both mirror prefixes, and a hit on any spelling is board provenance. This
 # adds path spellings to the QUESTION; it does not add a second answer to it.

package/skills/j-redo/SKILL.md

@@ -60,7 +60,7 @@ Compare the user's redo description against the original implementation to deter
 Summarise scope findings to the user in a brief list before continuing.
 
 ### 3. Plan the redo
-Populate `skills/todo/assets/todo_handoff_template.md` with the following pre-collected context:
+Populate `skills/j-todo/assets/todo_handoff_template.md` with the following pre-collected context:
 - **Mission title**: a short name for the redo work
 - **Goal / objective**: the redo objective — what is changing and the desired outcome
 - **Affected files or scope**: code, tests, and documentation files identified in step 2

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-spinoff/SKILL.md

@@ -44,7 +44,7 @@ This file is generated/synced by `scripts/generate-j-alias.sh spinoff` from `ski
 
 4. **Run /brainstorm (if chosen)** — Invoke the `/brainstorm` skill, passing the diverging topic and collected context as the opening prompt. After `/brainstorm` completes, use the refined output as the idea description.
 
-5. **Save via `/idea`** — Populate `skills/idea/assets/idea_handoff_template.md` with the context collected so far:
+5. **Save via `/idea`** — Populate `skills/j-idea/assets/idea_handoff_template.md` with the context collected so far:
    - **Mission title**: the diverging topic name (as confirmed in step 1)
    - **Goal / objective**: what the diverging topic aims to achieve
    - **Affected files or scope**: any files or modules identified during the conversation

package/skills/j-status/SKILL.md

@@ -36,6 +36,21 @@ This file is generated/synced by `scripts/generate-j-alias.sh status` from `skil
 
 6. **Check the queue** — If `project/queue/scrum_triggers.jsonl` is non-empty, note the number of pending triggers awaiting the scrum master.
 
+6.5. **Run the deploy-reconcile pass** (`E51_S05`) before printing the summary — `/status` has no
+`scripts/` directory of its own comparable to `/self-sync`'s, so invoke the shared pipeline
+directly rather than adding a third skill-local wrapper script:
+   ```
+   bash scripts/mark-deployed.sh
+   ```
+   This defaults to invoking its own sibling `scripts/compute-deploy-reconcile.sh`, which
+   discovers any not-yet-reconciled `vX.Y.Z-stage`/`vX.Y.Z` tags on the public `jenga-npm` repo
+   (unauthenticated read — no credential required) and promotes matching `Publicized`/
+   `Deployed to Stage` tickets to `Deployed to Stage`/`Deployed to Prod` (writing
+   `date_deployed_prod` on a Prod promotion) by commit ancestry, before this skill re-scans the
+   board in steps 2-4 above. This step is **non-fatal**: a failure anywhere in the pipeline
+   (including an unreachable public repo) is logged as a warning only and never prevents `/status`
+   from printing whatever board state it already has, and never causes a non-zero exit.
+
 7. **Print the summary** following the layout and icon conventions in `assets/output_format.md`.
 
 8. If no epics exist, print: `No board items found. Run /pi-plan to define epics or /todo to add items.`

package/skills/j-todo/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: j.todo
 description: Polyfill alias of the todo skill under a collision-safe directory name. Identical behavior to /todo — Add missions to the project todo list (project/todo.md), optionally linking them to epics and stories. Loops until the user is done, then optionally executes the list. Use when the bare /todo form is shadowed by another tool's own built-in command of the same name.
+output_types: id_list
+input_types: id_list
 keywords:
   - todo
   - add task
@@ -29,7 +31,7 @@ This file is generated/synced by `scripts/generate-j-alias.sh todo` from `skills
 
 When `--trivial` is present, the mission is written as a **fully-formed task board file immediately** (not just a raw `todo.md` line deferred to `/do`'s own breakdown pass) with `execution_scope: inline` forced unconditionally — no threshold computation is consulted for the scope value itself. See step 4.5 below for the mechanics.
 
-**Human-only override.** `--trivial` is invoked by a human typing `/todo --trivial ...` — it is never applied by the scrum-master to itself during autonomous story/epic breakdown elsewhere (e.g. `/jenga`'s Phase 0.5, or `/do`'s own scrum-master decomposition step in `skills/do/SKILL.md` step 3). Those paths keep using the normal heuristic-only `execution_scope` assignment documented in `agents/scrum-master.md`'s Execution Scope Assignment section, unmodified by this flag.
+**Human-only override.** `--trivial` is invoked by a human typing `/todo --trivial ...` — it is never applied by the scrum-master to itself during autonomous story/epic breakdown elsewhere (e.g. `/jenga`'s Phase 0.5, or `/do`'s own scrum-master decomposition step in `skills/j-do/SKILL.md` step 3). Those paths keep using the normal heuristic-only `execution_scope` assignment documented in `agents/scrum-master.md`'s Execution Scope Assignment section, unmodified by this flag.
 
 **Fallback on failure is out of scope here.** If a `--trivial`-forced inline run fails the smoke-harness or shows scope creep at dispatch time, `/do`'s own `--trivial` handling (a separate task, E32_S14_T02) is responsible for falling back to the full `task` pipeline — this skill only ever writes the initial forced-inline task.
 

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.
 
 ---
@@ -813,7 +860,7 @@ sections of `project/PROJECT_SUMMARY.md`:
 
 **Step B — Check both sections for existing content before proposing anything.** A section counts
 as a **stub** only if its body is empty, whitespace-only, or is (or is limited to) the literal
-placeholder text from `skills/init/assets/PROJECT_SUMMARY_template.md` — `_To be completed._`.
+placeholder text from `skills/j-init/assets/PROJECT_SUMMARY_template.md` — `_To be completed._`.
 Anything else — a sentence, a partial list, a paragraph someone already wrote by hand — is real,
 non-stub content, however short, and is never silently overwritten. Check the Overview and
 Architecture & Structure sections independently; one can be a stub while the other is not.

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/detect-dependencies.sh

@@ -97,7 +97,7 @@ Options:
   -h, --help      Show this help and exit.
 
 Examples:
-  $(basename "$0") skills/reconcile/
+  $(basename "$0") skills/j-reconcile/
   $(basename "$0") scripts/board_resolver.sh
 EOF
 }

package/skills/j-uncharted/scripts/detect-tests.sh

@@ -104,7 +104,7 @@ Options:
   -h, --help      Show this help and exit.
 
 Examples:
-  $(basename "$0") skills/reconcile/
+  $(basename "$0") skills/j-reconcile/
   $(basename "$0") scripts/board_resolver.sh
 EOF
 }