@jenga-ai/agent 3.5.0 → 4.0.0

package/skills/j-init/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: j.init
-description: Polyfill alias of the init skill under a collision-safe directory name. Identical behavior to /init — initializes a new project with the standard directory structure, PROJECT_SUMMARY.md, workflow.json, git repo, and gitignore. Use when the built-in "/init" command (e.g. GH Copilot's own init) shadows Jenga's /init alias.
+description: initializes a new project with the standard directory structure, PROJECT_SUMMARY.md, workflow.json, git repo, and gitignore. Use when the built-in "/init" command (e.g. GH Copilot's own init) shadows Jenga's /init alias.
 keywords:
   - init
   - initialize
@@ -8,7 +8,6 @@ keywords:
   - new project
   - scaffold
   - j-init
-  - polyfill
 examples:
   - "initialize a new project"
   - "set up a new workspace"
@@ -17,15 +16,25 @@ examples:
 
 # J-Init — Project Setup (polyfill alias of Init)
 
-This skill is a literal-directory-name duplicate of `skills/init/`. It exists because
-some host tools/harnesses (e.g. GH Copilot) ship their own built-in command literally
-named `/init`, which can shadow or override Jenga AI's own `/init` alias (Claude Code's
-native skill resolution is a literal-string, directory-name-based match — see
-`docs/skill-authoring.md`'s "Invocation Convention"). `/j-init` (and `j.j-init`) give
-users a guaranteed-unshadowed way to reach the exact same setup flow.
-
-Keep this file's instructions in lockstep with `skills/init/SKILL.md` — any change made
-there should be mirrored here.
+`skills/j-init/` is the **sole canonical directory** for this skill. The `j-` prefix is
+there for collision safety: some host tools/harnesses (e.g. GH Copilot) ship their own
+built-in command literally named `/init`, which would shadow a bare `/init` alias, since
+Claude Code's native skill resolution is a literal-string, directory-name-based match —
+see `docs/skill-authoring.md`'s "Invocation Convention". Invoke it as `j.init` or
+`/j-init`.
+
+> **This file was previously described as a duplicate of `skills/init/`, with an
+> instruction to keep the two in lockstep. That instruction is void.** `E50_S15_T04`
+> deleted every bare-name `skills/<name>/` directory on 2026-09-19, making
+> `skills/j-<name>/` the sole canonical form (see `docs/skill-authoring.md`'s "The
+> Canonical Naming Contract"), and `scripts/generate-j-alias.sh` — which had excluded this
+> hand-maintained pair from generation anyway — was retired by `E50_S14_T01`. There is no
+> second copy to mirror a change into, and none should be created. Edit this file directly.
+>
+> Corrected by `E42_S07_T01`'s follow-up, per
+> `project/rapports/problems/E42_S07_T01-j-init-skill-md-lockstep-instruction-still-stale.md`.
+> The same correction already landed one level down, in
+> `skills/j-init/scripts/apply-scaffold-visibility.sh`.
 
 ## Instructions
 
@@ -101,7 +110,7 @@ run can never silently relocate directories or edit `.gitignore`.
 > `.agents/`/`.claude/` convention), was built and then withdrawn before release —
 > testing found it left board resolution and session-end hooks writing to two
 > different trees. It is not offered here. See
-> `skills/distribute/CONFIG_SCHEMA.md` for the root-cause note and the tracked
+> `skills/j-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 4. Do not apply it yourself — the script owns all
@@ -116,7 +125,7 @@ framework scaffold (skill and agent definitions), which is a separate tree with
 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
+`skills/j-distribute/CONFIG_SCHEMA.md`'s "Scaffold visibility" section for the full
 rationale.
 
 Ask the user this question, verbatim, before running any script:
@@ -195,7 +204,7 @@ 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` and
+See `skills/j-distribute/CONFIG_SCHEMA.md` for the full `project_files_visibility` and
 `scaffold_visibility` field reference.
 
 ### 5. Prompt next step

package/skills/j-init/assets/scope-thresholds_template.json

@@ -1,7 +1,10 @@
 {
-  "threshold_version": 2,
+  "threshold_version": 3,
   "inline_max_files": 3,
   "inline_max_lines": 75,
   "story_max_files": 5,
-  "bundle_lock_ttl_minutes": 30
+  "bundle_lock_ttl_minutes": 30,
+  "max_concurrent_developers": 3,
+  "max_concurrent_testers": 3,
+  "slot_ttl_minutes": 45
 }

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

@@ -11,15 +11,17 @@
 # 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
+# skills/j-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.
+# This file is the sole copy. It was added by E31_S07_T03 as skills/j-init/'s own
+# hand-maintained duplicate of a then-existing skills/init/scripts/ copy, with an
+# instruction to keep the two in lockstep. That instruction is void: E50_S15_T04
+# deleted every bare-name skills/<name>/ directory on 2026-09-19, making
+# skills/j-<name>/ the sole canonical form (see docs/skill-authoring.md's "The
+# Canonical Naming Contract"), and scripts/generate-j-alias.sh — which had excluded
+# this pair from generation as hand-maintained — was itself retired by E50_S14_T01.
+# There is no second copy to mirror a change into, and none should be created.
 #
 # Usage:
 #   apply-scaffold-visibility.sh <mode> [project_root]

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

@@ -30,7 +30,7 @@ fi
 # 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
+# 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}"
@@ -79,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
@@ -93,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
@@ -138,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-jbp/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: j.jbp
-description: Polyfill alias of the jbp skill under a collision-safe directory name. Identical behavior to /jbp — Scaffold the project using the JengaBasePlate boilerplate repo template from https://github.com/samwelmunga/JengaBasePlate.git. Use when the bare /jbp form is shadowed by another tool's own built-in command of the same name.
+description: Scaffold the project using the JengaBasePlate boilerplate repo template from https://github.com/samwelmunga/JengaBasePlate.git.
 keywords:
   - jbp
   - boilerplate
@@ -8,7 +8,6 @@ keywords:
   - template
   - jenga base
   - j-jbp
-  - polyfill
 examples:
   - "scaffold with JengaBasePlate"
   - "set up the base template"
@@ -17,9 +16,9 @@ examples:
 
 # JBP — JengaBasePlate Scaffold
 
-This skill is a literal-directory-name duplicate of `skills/jbp/`. It exists so that `/j-jbp` (and `j.j-jbp`) give a guaranteed-unshadowed way to reach the same flow as `/jbp`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/jbp` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+`skills/j-jbp/` is the **canonical, hand-edited** directory for this skill, per CLAUDE.md's "The Canonical Naming Contract" (the `E50` reopening of 2026-09-09, which promoted `skills/j-jbp/` from generated twin to sole canonical form). The `j-` prefix is there for collision safety — a real directory under a distinct name, so a host tool shipping its own same-named built-in command cannot shadow it (Claude Code's native skill resolution is a literal-string, directory-name-based match; see `docs/skill-authoring.md`'s "Invocation Convention").
 
-This file is generated/synced by `scripts/generate-j-alias.sh jbp` from `skills/jbp/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+> ⚠️ **`scripts/generate-j-alias.sh` was retired by `E50_S14` and no longer exists — there is nothing to run.** This file was previously generated from a bare `skills/jbp/SKILL.md` source; `E50_S15` deleted that directory. This file is now the sole canonical, hand-edited source for this skill — edit it directly.
 
 ## Instructions
 

package/skills/j-lgtm/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: j.lgtm
-description: Polyfill alias of the lgtm skill under a collision-safe directory name. Identical behavior to /lgtm — Approve and commit the current work, then continue to the next task. Shortcut that chains /commit followed by /continue. Use when the bare /lgtm form is shadowed by another tool's own built-in command of the same name.
+description: Approve and commit the current work, then continue to the next task. Shortcut that chains /commit followed by /continue.
 keywords:
   - lgtm
   - approve
@@ -8,7 +8,6 @@ keywords:
   - done
   - commit and continue
   - j-lgtm
-  - polyfill
 examples:
   - "lgtm, commit this"
   - "looks good, move on"
@@ -17,9 +16,9 @@ examples:
 
 # LGTM — Approve, Commit, and Continue
 
-This skill is a literal-directory-name duplicate of `skills/lgtm/`. It exists so that `/j-lgtm` (and `j.j-lgtm`) give a guaranteed-unshadowed way to reach the same flow as `/lgtm`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/lgtm` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+`skills/j-lgtm/` is the **canonical, hand-edited** directory for this skill, per CLAUDE.md's "The Canonical Naming Contract" (the `E50` reopening of 2026-09-09, which promoted `skills/j-lgtm/` from generated twin to sole canonical form). The `j-` prefix is there for collision safety — a real directory under a distinct name, so a host tool shipping its own same-named built-in command cannot shadow it (Claude Code's native skill resolution is a literal-string, directory-name-based match; see `docs/skill-authoring.md`'s "Invocation Convention").
 
-This file is generated/synced by `scripts/generate-j-alias.sh lgtm` from `skills/lgtm/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+> ⚠️ **`scripts/generate-j-alias.sh` was retired by `E50_S14` and no longer exists — there is nothing to run.** This file was previously generated from a bare `skills/lgtm/SKILL.md` source; `E50_S15` deleted that directory. This file is now the sole canonical, hand-edited source for this skill — edit it directly.
 
 ## Instructions
 

package/skills/j-pi-plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: j.pi-plan
-description: Polyfill alias of the pi-plan skill under a collision-safe directory name. Identical behavior to /pi-plan — Define or expand project Epics in PROJECT_SUMMARY.md. Use this at the start of a project to establish its foundation, AND whenever the user wants to add major new features, plan a significant new area of work, or make epic-level changes to an existing project. Trigger whenever you hear things like "new feature area", "big change", "new epic", "expand the project", "add a major capability", or "plan a new phase" — even mid-project. Use when the bare /pi-plan form is shadowed by another tool's own built-in command of the same name.
+description: Define or expand project Epics in PROJECT_SUMMARY.md. Use this at the start of a project to establish its foundation, AND whenever the user wants to add major new features, plan a significant new area of work, or make epic-level changes to an existing project. Trigger whenever you hear things like "new feature area", "big change", "new epic", "expand the project", "add a major capability", or "plan a new phase" — even mid-project.
 keywords:
   - epic
   - template
@@ -8,7 +8,6 @@ keywords:
   - new feature area
   - project structure
   - j-pi-plan
-  - polyfill
 examples:
   - "add a new epic for X"
   - "expand the project with a new feature area"
@@ -19,9 +18,9 @@ metadata:
 
 # Pi-plan — Define and Expand Project Epics
 
-This skill is a literal-directory-name duplicate of `skills/pi-plan/`. It exists so that `/j-pi-plan` (and `j.j-pi-plan`) give a guaranteed-unshadowed way to reach the same flow as `/pi-plan`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/pi-plan` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+`skills/j-pi-plan/` is the **canonical, hand-edited** directory for this skill, per CLAUDE.md's "The Canonical Naming Contract" (the `E50` reopening of 2026-09-09, which promoted `skills/j-pi-plan/` from generated twin to sole canonical form). The `j-` prefix is there for collision safety — a real directory under a distinct name, so a host tool shipping its own same-named built-in command cannot shadow it (Claude Code's native skill resolution is a literal-string, directory-name-based match; see `docs/skill-authoring.md`'s "Invocation Convention").
 
-This file is generated/synced by `scripts/generate-j-alias.sh pi-plan` from `skills/pi-plan/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+> ⚠️ **`scripts/generate-j-alias.sh` was retired by `E50_S14` and no longer exists — there is nothing to run.** This file was previously generated from a bare `skills/pi-plan/SKILL.md` source; `E50_S15` deleted that directory. This file is now the sole canonical, hand-edited source for this skill — edit it directly.
 
 ## When to use this skill
 

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

@@ -1,13 +1,12 @@
 ---
 name: j.proceed
-description: Polyfill alias of the proceed skill under a collision-safe directory name. Identical behavior to /proceed — Review project progress by checking epics and stories, optionally consulting PROJECT_SUMMARY.md and WARP.md, then continue executing the project plan. Use when the bare /proceed form is shadowed by another tool's own built-in command of the same name.
+description: Review project progress by checking epics and stories, optionally consulting PROJECT_SUMMARY.md and WARP.md, then continue executing the project plan.
 keywords:
   - proceed
   - review progress
   - check epics
   - continue executing
   - j-proceed
-  - polyfill
 examples:
   - "proceed with the plan"
   - "review progress and continue"
@@ -18,9 +17,9 @@ metadata:
 
 # Proceed — Resume Project Execution
 
-This skill is a literal-directory-name duplicate of `skills/proceed/`. It exists so that `/j-proceed` (and `j.j-proceed`) give a guaranteed-unshadowed way to reach the same flow as `/proceed`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/proceed` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+`skills/j-proceed/` is the **canonical, hand-edited** directory for this skill, per CLAUDE.md's "The Canonical Naming Contract" (the `E50` reopening of 2026-09-09, which promoted `skills/j-proceed/` from generated twin to sole canonical form). The `j-` prefix is there for collision safety — a real directory under a distinct name, so a host tool shipping its own same-named built-in command cannot shadow it (Claude Code's native skill resolution is a literal-string, directory-name-based match; see `docs/skill-authoring.md`'s "Invocation Convention").
 
-This file is generated/synced by `scripts/generate-j-alias.sh proceed` from `skills/proceed/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+> ⚠️ **`scripts/generate-j-alias.sh` was retired by `E50_S14` and no longer exists — there is nothing to run.** This file was previously generated from a bare `skills/proceed/SKILL.md` source; `E50_S15` deleted that directory. This file is now the sole canonical, hand-edited source for this skill — edit it directly.
 
 ## Instructions
 

package/skills/j-publish/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: j.publish
-description: Polyfill alias of the publish skill under a collision-safe directory name. Identical behavior to /publish — Configure, validate, and orchestrate scaffolded release workflows through a single `/publish` entry point with bounded sub-commands. Use when the bare /publish form is shadowed by another tool's own built-in command of the same name.
+description: Configure, validate, and orchestrate scaffolded release workflows through a single `/publish` entry point with bounded sub-commands.
 keywords:
   - publish
   - deploy
@@ -12,7 +12,6 @@ keywords:
   - staged publishing
   - stage
   - j-publish
-  - polyfill
 examples:
   - "publish setup --target staging-appstore"
   - "publish setup --type mobile-ios"
@@ -42,9 +41,9 @@ metadata:
 
 # Publish — Deployment Pipeline Orchestrator
 
-This skill is a literal-directory-name duplicate of `skills/publish/`. It exists so that `/j-publish` (and `j.j-publish`) give a guaranteed-unshadowed way to reach the same flow as `/publish`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/publish` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+`skills/j-publish/` is the **canonical, hand-edited** directory for this skill, per CLAUDE.md's "The Canonical Naming Contract" (the `E50` reopening of 2026-09-09, which promoted `skills/j-publish/` from generated twin to sole canonical form). The `j-` prefix is there for collision safety — a real directory under a distinct name, so a host tool shipping its own same-named built-in command cannot shadow it (Claude Code's native skill resolution is a literal-string, directory-name-based match; see `docs/skill-authoring.md`'s "Invocation Convention").
 
-This file is generated/synced by `scripts/generate-j-alias.sh publish` from `skills/publish/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+> ⚠️ **`scripts/generate-j-alias.sh` was retired by `E50_S14` and no longer exists — there is nothing to run.** This file was previously generated from a bare `skills/publish/SKILL.md` source; `E50_S15` deleted that directory. This file is now the sole canonical, hand-edited source for this skill — edit it directly.
 
 `/publish` is the single entry point for release workflows in this repository. It wires configuration validation, setup, gated deployment, release-note drafting, and ledger history into one end-to-end flow, and dispatches the final publish step to a per-type adapter.
 
@@ -265,7 +264,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-publish/scripts/run_gates.sh

@@ -292,7 +292,7 @@ run_command_capture() {
   local command="$1"
   LAST_GATE_COMMAND="$command"
   set +e
-  RUN_OUTPUT="$(bash -lc "$command" 2>&1)"
+  RUN_OUTPUT="$(bash -c "$command" 2>&1)"
   RUN_STATUS=$?
   set -e
 }

package/skills/j-reconcile/SKILL.md

@@ -1,19 +1,18 @@
 ---
 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.
+description: 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".
 metadata:
   prefered_agent: scrum-master
-output_types: text
+output_types: id_list
 keywords:
   - j-reconcile
-  - polyfill
 ---
 
 # Reconcile — Board ↔ Code Synchronisation
 
-This skill is a literal-directory-name duplicate of `skills/reconcile/`. It exists so that `/j-reconcile` (and `j.j-reconcile`) give a guaranteed-unshadowed way to reach the same flow as `/reconcile`, even if a host tool's own built-in command of the same name would otherwise shadow or override the bare `/reconcile` alias (Claude Code's native skill resolution is a literal-string, directory-name-based match — see `docs/skill-authoring.md`'s "Invocation Convention").
+`skills/j-reconcile/` is the **canonical, hand-edited** directory for this skill, per CLAUDE.md's "The Canonical Naming Contract" (the `E50` reopening of 2026-09-09, which promoted `skills/j-reconcile/` from generated twin to sole canonical form). The `j-` prefix is there for collision safety — a real directory under a distinct name, so a host tool shipping its own same-named built-in command cannot shadow it (Claude Code's native skill resolution is a literal-string, directory-name-based match; see `docs/skill-authoring.md`'s "Invocation Convention").
 
-This file is generated/synced by `scripts/generate-j-alias.sh reconcile` from `skills/reconcile/SKILL.md` — do not hand-edit it; re-run the generator instead to pick up source changes.
+> ⚠️ **`scripts/generate-j-alias.sh` was retired by `E50_S14` and no longer exists — there is nothing to run.** This file was previously generated from a bare `skills/reconcile/SKILL.md` source; `E50_S15` deleted that directory. This file is now the sole canonical, hand-edited source for this skill — edit it directly.
 
 Walks the full board (epics → stories → tasks), verifies each item's status against what actually exists in git, and fixes any drift. Also cleans `project/todo.md` of entries that are already done. Then runs the same check in reverse — code that exists with no board item and no EST-tagged commit behind it — and offers `/uncharted segment` for what it finds.
 
@@ -136,7 +135,41 @@ in-scope tasks when scoped) whose status is **not** a completed status (Pending,
 2. **Check documentation artefacts** as in phase 2.
 3. **Spot-check acceptance criteria** against the codebase.
 
-If implementation **is confirmed**:
+Before treating a matching commit as grounds to promote, run two more checks. These exist because
+a commit referencing a task ID is evidence the code was *touched*, not evidence it is *finished* —
+a separate, still-running `/do` pipeline for this exact task may have a real fix sitting unmerged
+in a worktree while an earlier, incomplete commit already landed on the branch this `/reconcile`
+pass is reading. This is the exact race documented in
+`project/rapports/problems/E40_S01_T05-premature-main-reconcile-vs-worktree-fix.md` — a `/reconcile`
+pass promoted a task to `Passed`/`Done` from a matching commit alone while a fallback developer/tester
+pipeline for that same task still had its bugfix unmerged on a worktree branch.
+
+4. **Check for an active concurrency-slot holder** — glob `project/queue/concurrency-slots-*.json`
+   (there can be several; one per orchestrating session, per `skills/j-do/SKILL.md`'s
+   `### 4.4. Developer Concurrency Slot Enforcement`). For each file found, check both
+   `.developer.holders` and `.tester.holders` for a key matching this task's id (`E##_S##_T##`) —
+   or, if this task belongs to a story-bundle dispatch, the containing story's id (`E##_S##`),
+   since a bundle acquires one shared slot keyed to the story id rather than one per task (`### 1.5`
+   step 3 of that skill). A matching key means a developer or tester subagent for this exact item is
+   (or very recently was) live in another session.
+5. **Check for an unmerged worktree or branch** — run `git worktree list` and `git branch --all`,
+   and look for an entry matching this task's `<E##_S##_T##-short-slug>` naming convention
+   (`skills/j-do/SKILL.md`'s worktree-naming convention, e.g. its Light Execution Path and Fallback
+   to Full Task-Scope Pipeline sections) that has not yet been merged into the branch this
+   `/reconcile` run is executing against. A match means real work for this task exists on a branch
+   this reconcile pass hasn't accounted for yet.
+
+If **either** check 4 or 5 matches, skip promotion for this task:
+- Leave the task's status exactly as it is now — do not touch `date_started`, `date_completed`, or
+  its `project/todo.md` entry.
+- Do **not** merge the branch/worktree found in check 5 yourself — that is a live pipeline's own
+  work-in-progress, not an orphaned branch like phase 2's merge case.
+- Report it in the reconcile report as **"likely still in-flight — skipped"** (see
+  `assets/report_format.md`'s "⏳ IN-FLIGHT — SKIPPED" section) — not silently promoted, and not
+  silently left unmentioned.
+- Continue to the next task in Phase 3 — this is a per-task skip, not a phase abort.
+
+If implementation **is confirmed** and **neither** check 4 nor 5 matched:
 - Update the task's status to **Passed** in its board file.
 - Set `date_completed` to today (ISO 8601).
 - If the task is listed in `project/todo.md`, **comment it out** by wrapping the line:
@@ -200,7 +233,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/assets/report_format.md

@@ -18,6 +18,10 @@ Scope: <resolved scope — see forms below>
 ⬆️  PROMOTED (were incomplete → now Passed)
    🔧 E##_S##_T## · <Task Title>  — commits found, acceptance criteria met
 
+⏳ IN-FLIGHT — SKIPPED (implementation confirmed by commit, but not promoted — active work appears ongoing)
+   🔧 E##_S##_T## · <Task Title>  — concurrency-slot holder found in <concurrency-slots-file>
+   🔧 E##_S##_T## · <Task Title>  — unmerged branch <branch-name>
+
 🔄 ROLL-UP CHANGES
    📖 E##_S## · <Story Title>  — <old status> → <new status>
    📦 E## · <Epic Title>  — <old status> → <new status>
@@ -51,6 +55,13 @@ Scope: <resolved scope — see forms below>
   own epics/stories/tasks only — not the whole board's.
 - Omit any section that has zero items (e.g. if nothing was demoted, skip the DEMOTED block entirely).
 - The MERGED section should include the branch name that was merged.
+- The IN-FLIGHT — SKIPPED section is distinct from both PROMOTED and the ordinary "implementation
+  not confirmed, no action" case (which is never reported at all): it means Phase 3 found a
+  matching commit (implementation confirmed) but withheld promotion because an active
+  concurrency-slot holder or an unmerged matching worktree/branch was also found — see
+  `/reconcile`'s Phase 3. Name the specific reason found (the concurrency-slots file, or the
+  branch/worktree name) so the report is checkable, not just asserted. Omit this section entirely
+  when no task was skipped for this reason.
 - The TODO CLEANUP section is always shown if `project/todo.md` existed at the start, even if zero changes were made (in that case show all counts as 0).
 - If `project/todo.md` did not exist, omit the TODO CLEANUP section.
 - The DOD GAPS section is omitted if no completed stories have unchecked DoD checkboxes.