@jenga-ai/agent 3.4.0 → 3.6.0

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
@@ -156,7 +183,7 @@ fi
 # and .agents/ — scripts/ (which owns with-lock.sh) is never copied there, so
 # this script — itself shipped under skills/j-uncharted/scripts/ and mirrored
 # alongside it — cannot assume "$REPO_ROOT/scripts/with-lock.sh" exists.
-# Mirrors skills/init/scripts/init.sh's PKG_ROOT fallback: prefer a monorepo
+# Mirrors skills/j-init/scripts/init.sh's PKG_ROOT fallback: prefer a monorepo
 # checkout's sibling scripts/ dir, else fall back to the installed npm
 # package under node_modules/@jenga-ai/agent.
 if [ -f "$SCRIPT_DIR/../../../scripts/with-lock.sh" ]; then
@@ -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/j-uncharted/scripts/validate-proposed-items.sh

@@ -53,7 +53,7 @@ REPO_ROOT=$(git -C "$SCRIPT_DIR" rev-parse --show-toplevel 2>/dev/null || true)
 # and .agents/ — scripts/ (which owns both validators) is never copied there,
 # so this script — itself shipped under skills/j-uncharted/scripts/ and mirrored
 # alongside it — cannot assume "$REPO_ROOT/scripts/..." exists. Mirrors
-# skills/init/scripts/init.sh's PKG_ROOT fallback (same pattern already
+# skills/j-init/scripts/init.sh's PKG_ROOT fallback (same pattern already
 # applied to this skill's elicitation-state.sh WITH_LOCK resolution): prefer
 # a monorepo checkout's sibling scripts/ dir, else fall back to the installed
 # npm package under node_modules/@jenga-ai/agent.

package/skills/j-wtf/SKILL.md

@@ -24,4 +24,4 @@ This file is generated/synced by `scripts/generate-j-alias.sh wtf` from `skills/
 
 ## Instructions
 
-`/wtf` is an alias of `/clearify`. Follow `skills/clearify/SKILL.md` in full — do not duplicate or reimplement its ambiguity-detection logic here. Read that file's `## Instructions` section and execute it exactly as written, using whatever prompt or conversation context is attached to this `/wtf` invocation.
+`/wtf` is an alias of `/clearify`. Follow `skills/j-clearify/SKILL.md` in full — do not duplicate or reimplement its ambiguity-detection logic here. Read that file's `## Instructions` section and execute it exactly as written, using whatever prompt or conversation context is attached to this `/wtf` invocation.

package/skills/jenga/SKILL.md

@@ -169,8 +169,8 @@ This branch is entered when `detect-nl-intent.sh` (invoked above) classifies the
 This branch is entered when `detect-nl-intent.sh` classifies the argument as `nl_intent` — every comma-delimited segment failed the ID grammar, so the raw argument is treated as natural-language intent rather than a malformed ID list. This is purely a new *outcome* of the same argument-shape detection above — no new sigil, trigger prefix, or separate entry point is introduced.
 
 1. **Load the catalog** — invoke `skills/jenga/scripts/load-nl-catalog.sh` with no arguments (E53_S01_T02). Its stdout is the full skill catalog (`name`/`description`/`keywords`/`examples`/`prefered_agent` per skill), sourced exclusively from `lib/generate-skill-allow-list.js`'s generated inventory — see the script's own header for the full contract. Never re-derive this catalog by re-scanning `skills/` inline.
-2. **Match** — run `skills/route/SKILL.md`'s **Step 2 — Match the Prompt to a Skill** (the three-pass keyword → example-similarity → description match, including its tie-break and no-match handling) against this catalog, treating `detect-nl-intent.sh`'s `raw_argument` field as the prompt. Reuse that section's matching logic by reference — do not re-author its prose here.
-3. **Confident single match** — report the routing decision using `skills/route/SKILL.md`'s **Step 7 — Report Routing Decision** format (substitute `/jenga` for `/route` as the invoking command named in the report), then invoke the matched skill exactly as `skills/route/SKILL.md`'s **Step 6 — Invoke the Matched Skill** already does: load `agents/<prefered_agent>.md` when the matched skill specifies `metadata.prefered_agent`, otherwise execute the skill instructions directly. The matched skill's own execution takes over from here — do not continue into this `/jenga` invocation's Phase 1.
+2. **Match** — run `skills/j-route/SKILL.md`'s **Step 2 — Match the Prompt to a Skill** (the three-pass keyword → example-similarity → description match, including its tie-break and no-match handling) against this catalog, treating `detect-nl-intent.sh`'s `raw_argument` field as the prompt. Reuse that section's matching logic by reference — do not re-author its prose here.
+3. **Confident single match** — report the routing decision using `skills/j-route/SKILL.md`'s **Step 7 — Report Routing Decision** format (substitute `/jenga` for `/route` as the invoking command named in the report), then invoke the matched skill exactly as `skills/j-route/SKILL.md`'s **Step 6 — Invoke the Matched Skill** already does: load `agents/<prefered_agent>.md` when the matched skill specifies `metadata.prefered_agent`, otherwise execute the skill instructions directly. The matched skill's own execution takes over from here — do not continue into this `/jenga` invocation's Phase 1.
 4. **No match, or an ambiguous multi-way tie (single-skill match)** — before surfacing `/route`'s generic disambiguation options, attempt a **playbook fallback** (E53_S02): invoke `skills/jenga/scripts/match-playbook.sh "<raw_argument>"`. This step only ever runs when step 3 above did NOT already commit to a confident single-skill match — a confident single-skill match always wins outright and this playbook fallback is never even invoked in that case. Branch on `match-playbook.sh`'s `classification` field:
    - `playbook_match` → continue to **step 5 (Playbook proposal and execution)** below.
    - `ambiguous` or `no_match` → continue to **step 6 (Fall through to `/route`'s disambiguation)** below — the exact behavior this branch already had before E53_S02, unchanged.
@@ -208,12 +208,12 @@ This branch is entered when `detect-nl-intent.sh` classifies the argument as `nl
          - **Apply the transform** — when both `forward_from` (successfully resolved immediately above) and `resolve` are present, use your own LLM judgment to reshape/filter/type-bridge the forwarded value per `resolve`'s natural-language instructions (e.g. "pick the first three items", "convert this file_list to a text summary"). The transformed value — never the raw forwarded value — becomes this step's actual invocation input.
          - **Hard-fail, never silent pass-through** — if the transform cannot cleanly produce a usable, type-compatible result (the instructions don't plausibly apply to the actual value, the value is empty/malformed for what's being asked, or the result would not plausibly satisfy the target step's expected input shape), do **not** invoke this step and do **not** guess or pass through a differently-shaped value. Instead call `skills/jenga/scripts/run-playbook-step.sh advance <state_file> failed "<note>"`, where `<note>` follows the format `resolve failed on step '<step name>': could not apply "<resolve text>" to raw value <raw pre-transform value> — <short reason>` (the raw pre-transform value is always included, for debugging). Then follow the `halted` handling in 5e-vi below exactly as any other step failure — immediately stop executing further steps, report `failed_step`/`failed_note`/`completed`/`skipped`/`never_run` verbatim.
 
-         Then invoke the step exactly as `skills/route/SKILL.md`'s **Step 6 — Invoke the Matched Skill** already does for a single matched skill: load `agents/<prefered_agent>.md` when that step's own `SKILL.md` specifies `metadata.prefered_agent`, otherwise execute its instructions directly.
+         Then invoke the step exactly as `skills/j-route/SKILL.md`'s **Step 6 — Invoke the Matched Skill** already does for a single matched skill: load `agents/<prefered_agent>.md` when that step's own `SKILL.md` specifies `metadata.prefered_agent`, otherwise execute its instructions directly.
       iii. After a normally-invoked step's execution concludes, call `skills/jenga/scripts/run-playbook-step.sh advance <state_file> passed ["<typed-output-value>"]` (the step completed successfully — supply the step's declared typed output, per its `output_types`, if it produced one) or `... advance <state_file> failed "<short failure note>"` (the step failed).
       iv. On a `step_ready` result, repeat step 5e for the newly-named step.
       v. On a `complete` result, report the full lists of `completed` AND `skipped` steps to the user and stop — the playbook run is finished; do not continue into this `/jenga` invocation's Phase 1.
       vi. On a `halted` result, **immediately stop executing any further steps** — no silent skip-ahead. Report `failed_step`, `failed_note`, `completed`, `skipped` (steps that already finished or were skipped), and `never_run` (steps that never got a chance to run) to the user verbatim from the halt report. Do not continue into this `/jenga` invocation's Phase 1.
-6. **Fall through to `/route`'s disambiguation** — entered when step 4 found no playbook match (`ambiguous` or `no_match`). Surface the same disambiguation options `skills/route/SKILL.md`'s **Step 2** already defines for these cases (browse `/help`, create a new skill via `/btw`, or proceed with the raw prompt) by reference to that section — do not re-copy its prose. Halt this `/jenga` invocation once the user picks an option; none of Phase 0.75's remaining steps or Phases 1-4 run for this branch.
+6. **Fall through to `/route`'s disambiguation** — entered when step 4 found no playbook match (`ambiguous` or `no_match`). Surface the same disambiguation options `skills/j-route/SKILL.md`'s **Step 2** already defines for these cases (browse `/help`, create a new skill via `/btw`, or proceed with the raw prompt) by reference to that section — do not re-copy its prose. Halt this `/jenga` invocation once the user picks an option; none of Phase 0.75's remaining steps or Phases 1-4 run for this branch.
 
 #### Shared confirmation step (bare and scoped branches only)
 
@@ -228,6 +228,39 @@ After this phase completes (bare and scoped branches via confirmation, wildcard
 
 ---
 
+### Phase 0.9 — Generate the Run's Shared `orchestrator_session_id`
+
+This phase runs for every entry mode that reaches Phase 1 at all — bare, scoped, and wildcard (`*`) —
+immediately after Phase 0.75 completes and before Phase 1 begins. It does not run for the
+natural-language branch's playbook/single-skill-match outcomes (E53_S01/E53_S02), since those hand off
+entirely to another skill or playbook and never reach Phase 1-4 of this document.
+
+Generate exactly **one** `orchestrator_session_id` for this entire `/jenga` run, here and only here.
+Both Phase 3.5's bundle dispatch and Phase 4's first (and every later) wave dispatch need this same
+value, which is why it is generated once, early, before either call site runs.
+
+**Format.** Generate it as `jenga-<UTC ISO 8601 basic-format timestamp>` (e.g.
+`jenga-20260917T162349Z`) — a short prefix naming the orchestrating skill, plus a UTC timestamp, with no
+`/` or `..` characters. This follows the same session-id string convention this repo already uses for
+other orchestrator-minted session ids (e.g. `/do`'s own dispatch sessions), and stays compatible with
+`scripts/acquire-concurrency-slot.sh`'s own validation, which refuses a `<session_id>` argument
+containing a path separator or traversal sequence, because the value is used verbatim in filenames such
+as `project/queue/concurrency-slots-<session_id>.json`.
+
+**Generate once, reuse everywhere in this run — never regenerate.** This value MUST be reused,
+byte-for-byte unchanged, across:
+- Phase 3.5 step 7b's bundle `/do <E##_S##>` call.
+- Every wave dispatched by Phase 4 step 3, across every loop-back at Phase 4 step 5b. The loop-back
+  never mints a new value — it only ever references the one value generated here.
+
+This is what allows `E32_S15`'s per-session `max_concurrent_developers`/`max_concurrent_testers` cap
+(`skills/j-do/SKILL.md`'s `### 4.4`) to actually contend across an entire `/jenga` run's dispatches,
+instead of every spawned `/do` sub-agent minting its own private `orchestrator_session_id` and getting
+its own private, uncontended `project/queue/concurrency-slots-<id>.json` counter file — the root-cause
+defect this story (`E32_S16`) fixes.
+
+---
+
 ### Phase 1 — Decompose Epics into Stories
 
 If Phase 0.75 produced a scoped set, restrict this phase to epics that are members of that set (directly selected, or flagged in its `undecomposed` list). Under `/jenga *`, this phase is unrestricted, exactly as before.
@@ -272,7 +305,7 @@ For each in-scope story that has one or more tasks listed in `todo.md`:
       BUNDLE DETECTED: story <E##_S##> — <N> story-scoped tasks will execute as a bundle.
       ```
       where `<E##_S##>` is the story ID and `<N>` is the count of tasks in the list.
-   b. Call `/do <E##_S##>` once (with the story ID, not individual task IDs). This invokes the bundle execution path in `/do` (implemented in E32_S05_T02), which runs all tasks sequentially in one shared worktree.
+   b. Call `/do <E##_S##>` once (with the story ID, not individual task IDs), passing this run's shared `orchestrator_session_id` (generated once in Phase 0.9) into the bundle's sender object as its `session_id` field — a caller-supplied session id per `skills/j-do/SKILL.md`'s standalone-vs-caller-supplied contract (`### 4.4`/`### 5`, `E32_S16_T02`), so the bundle path's own `### 4.4` slot acquire shares this run's one counter file too, rather than minting a private one. This invokes the bundle execution path in `/do` (implemented in E32_S05_T02), which runs all tasks sequentially in one shared worktree.
    c. **Mark these tasks as bundled** — record their task IDs so Phase 4 skips individual dispatch for them.
 8. **Non-bundle stories** — stories with a mixed scope, a zero-length task list, any task missing `execution_scope: story`, or any task with `crucial_level: locked` (step 5) use the normal per-task dispatch in Phase 4 without any change.
 
@@ -282,11 +315,11 @@ Loop through `todo.md` and execute all eligible items, running independent ones
 
 1. **Collect eligible items** — from `todo.md`, find all items whose board file has `status: Pending` and no unresolved dependencies, **excluding tasks already dispatched as part of a story bundle in Phase 3.5**. If Phase 0.75 produced a scoped set, also exclude any item not a member of that set — execution never runs outside the confirmed/resolved scope. Under `/jenga *`, no such exclusion applies. A dependency is resolved if the blocking item's status is at least `In Progress` or `Passed`.
 2. **Group by parallelism** — items with no shared dependencies and no overlapping output files can run concurrently. Items that depend on each other must be sequenced.
-3. **Invoke `/do` in parallel** — launch each independent item as a **background sub-agent** simultaneously. Do not wait for one to finish before starting another if they are independent.
+3. **Invoke `/do` in parallel** — launch each independent item as a **background sub-agent** simultaneously. Do not wait for one to finish before starting another if they are independent. Pass this run's shared `orchestrator_session_id` (generated once in Phase 0.9, unchanged across every wave) into each sub-agent's sender object as its `session_id` field, per `assets/sender_template.json`'s existing shape and `skills/j-do/SKILL.md`'s caller-supplied-session-id case (`### 4.4`/`### 5`, `E32_S16_T02`) — this is what lets `E32_S15`'s per-session developer/tester concurrency cap actually contend across every sub-agent dispatched within (and across) this run's waves, instead of each one minting its own private session id and its own private, uncontended counter file.
 4. **Mark In Progress** — update `status: In Progress` in each launched item's board file (YAML front-matter) immediately after launch.
 5. **Wait, drain, and loop** — once all active background agents in the wave have completed:
    a. **Drain the scrum triggers queue** — invoke the `## Drain Scrum Triggers Queue` procedure from `agents/scrum-master.md` against `project/queue/scrum_triggers.jsonl`. `/jenga`'s orchestrating agent is the scrum-master, and this is the same session-start procedure applied mid-run: process any `rapport_review`, `status_review`, and `story_rollup` triggers written by the tester sub-sessions that just completed, then clear the file. This ensures rollups become visible on the board (story/epic status updates) before the next wave is collected, instead of sitting unprocessed until some future scrum-master session start.
-   b. **Return to step 1** of this phase to pick up any newly unblocked items — including items unblocked by the rollups just processed in (a).
+   b. **Return to step 1** of this phase to pick up any newly unblocked items — including items unblocked by the rollups just processed in (a). This loop-back reuses the SAME `orchestrator_session_id` generated once in Phase 0.9 for every subsequent wave's `/do` dispatches — it is never regenerated here or anywhere else in this phase.
 
 ### Exit condition
 
@@ -312,8 +345,8 @@ When no eligible candidates remain in Phase 4, exit and output:
 - **Picker cancelled (bare branch)** — the entire `/jenga` run halts immediately after relaying the cancellation acknowledgement; no phase past 0.75 runs, and nothing on the board is modified.
 - **Confirmation cancelled (bare or scoped branch)** — same as picker cancellation: the entire `/jenga` run halts immediately; no scoped set is produced and no later phase runs.
 - **`detect-nl-intent.sh` classifies the argument as `mixed` (scoped branch)** — the whole invocation halts at Phase 0.75 with each rejected segment's `input`/`reason` reported verbatim, per `detect-nl-intent.sh`'s own classification contract (E53_S01_T01); no partial scope is assembled from the segments that did resolve, and no fallback guess is made for the rejected ones. The user must re-invoke `/jenga <ids>` with corrected input.
-- **`detect-nl-intent.sh` classifies the argument as `nl_intent`, no confident single-skill match, and `match-playbook.sh` (E53_S02) also finds no playbook match** — the natural-language branch's step 4 attempts the playbook fallback first (see the Natural-language branch's step 4/6), and only THEN surfaces `skills/route/SKILL.md`'s Step 2 no-match disambiguation options (browse `/help`, create a new skill via `/btw`, proceed with the raw prompt) instead of guessing; no phase past 0.75 runs until the user picks one.
-- **`detect-nl-intent.sh` classifies the argument as `nl_intent`, no confident single-skill match, and `match-playbook.sh` returns an ambiguous multi-way tie between playbooks** — treated the same as the no-playbook-match case above: falls through to `skills/route/SKILL.md`'s Step 2 tie-break prompt (top candidates + a "neither, describe what you need" option) instead of guessing; no phase past 0.75 runs until the user picks one. (`match-playbook.sh`'s own `ambiguous` result — a tie between playbooks — is intentionally not given its own separate disambiguation UI; it is treated identically to `no_match` and routed to the same `/route` Step 2 fallback prose, which already has its own tie-break handling.)
+- **`detect-nl-intent.sh` classifies the argument as `nl_intent`, no confident single-skill match, and `match-playbook.sh` (E53_S02) also finds no playbook match** — the natural-language branch's step 4 attempts the playbook fallback first (see the Natural-language branch's step 4/6), and only THEN surfaces `skills/j-route/SKILL.md`'s Step 2 no-match disambiguation options (browse `/help`, create a new skill via `/btw`, proceed with the raw prompt) instead of guessing; no phase past 0.75 runs until the user picks one.
+- **`detect-nl-intent.sh` classifies the argument as `nl_intent`, no confident single-skill match, and `match-playbook.sh` returns an ambiguous multi-way tie between playbooks** — treated the same as the no-playbook-match case above: falls through to `skills/j-route/SKILL.md`'s Step 2 tie-break prompt (top candidates + a "neither, describe what you need" option) instead of guessing; no phase past 0.75 runs until the user picks one. (`match-playbook.sh`'s own `ambiguous` result — a tie between playbooks — is intentionally not given its own separate disambiguation UI; it is treated identically to `no_match` and routed to the same `/route` Step 2 fallback prose, which already has its own tie-break handling.)
 - **`match-playbook.sh` returns `playbook_match` and the user confirms the full chain, and every step succeeds** — the Natural-language branch's step 5e reports the full `completed` AND `skipped` steps lists to the user and stops; `/jenga`'s own Phase 1 never runs for this invocation (execution was already fully handled by the playbook's own steps, e.g. `j.do`/`j.dev-done`).
 - **`match-playbook.sh` returns `playbook_match` but the user cancels at the chain confirmation step (step 5c)** — identical posture to the existing picker/confirmation cancellation cases above: the entire `/jenga` run halts immediately after relaying the cancellation acknowledgement, with NO step of the chain executed; nothing on the board is modified by this invocation.
 - **`match-playbook.sh` returns `playbook_match`, the user confirms, and a step mid-chain fails** — the Natural-language branch's step 5e(vi) halts immediately on `run-playbook-step.sh`'s `halted` result: no step after the failed one runs (no silent skip-ahead), and the user is shown exactly which steps already completed or were skipped, which step failed (with its note), and which steps never ran.
@@ -329,3 +362,4 @@ When no eligible candidates remain in Phase 4, exit and output:
 - **A playbook step carries composition origin metadata (depth > 1), shown at confirmation (`E53_S05_T03`)** — the Natural-language branch's step 5b relays `render-playbook-confirmation.sh`'s rendered chain, which now visibly indents and labels that step's line with "(from playbook: <id>, depth N)" — composing another playbook's steps into a chain never hides where one playbook ends and another begins from the user, even though the whole chain is still ONE numbered, editable, confirmable list (never a separate confirmation per nested playbook) and checking/unchecking a composed step still works exactly like any other step.
 - **`/jenga *` (wildcard branch)** — never produces a scoped set; Phases 1-4 run fully unrestricted over the entire board, identical to `/jenga`'s behavior before Phase 0.75 existed.
 - **Stale out-of-scope story queued in `todo.md` from an earlier run (scoped run only)** — Phase 3.5's scoped-set guard skips it entirely (not considered for bundling), so it cannot be dispatched via a bundle `/do <E##_S##>` call that would otherwise bypass Phase 4's own scoped-set exclusion; it remains untouched in `todo.md` until a future run's scope includes it.
+- **`orchestrator_session_id` reuse across waves and phases (`E32_S16_T01`)** — the value generated once in Phase 0.9 is the exact same value threaded into Phase 3.5's bundle `/do` call and into every wave's `/do` sub-agent sender objects dispatched by Phase 4, for the entire duration of a single `/jenga` run; Phase 4 step 5b's loop-back never mints a new one. A run that halts before Phase 0.9 completes (e.g. cancelled at Phase 0.75's picker/confirmation) never reaches Phase 3.5 or Phase 4, so the value it would have generated is simply never used.

package/skills/jenga/playbooks/board-hygiene.json

@@ -0,0 +1,32 @@
+{
+  "id": "board-hygiene",
+  "name": "Board Hygiene",
+  "description": "Reconciles the scrum board against what is actually implemented, captures whatever drift that turns up as follow-up todos, and reports the resulting board state -- a read-only triage chain that writes no code and produces no commit of its own.",
+  "keywords": [
+    "board hygiene",
+    "board triage",
+    "board health",
+    "tidy the board",
+    "board audit"
+  ],
+  "examples": [
+    "reconcile the board, capture whatever drift you find as todos, then show me the status",
+    "do a full board hygiene pass -- sync it with what's really implemented, queue follow-ups for anything off, and report where we stand",
+    "check the board against reality, turn any discrepancies into todo items, and give me an overview at the end",
+    "the board feels out of sync -- triage it, capture the fixes, and summarise the state afterwards",
+    "audit the board end to end and only queue follow-up work if something is actually wrong"
+  ],
+  "steps": [
+    "j-reconcile",
+    {
+      "skill": "j-todo",
+      "forward_from": "j-reconcile",
+      "conditional": {
+        "depends_on": "j-reconcile",
+        "predicate": "non_empty"
+      },
+      "instruction": "capture each reconciliation finding as a follow-up todo"
+    },
+    "j-status"
+  ]
+}

package/skills/jenga/playbooks/schema.json

@@ -2,7 +2,7 @@
   "$schema": "http://json-schema.org/draft-07/schema#",
   "$id": "https://jenga.local/schemas/jenga-playbook.schema.json",
   "title": "Jenga Multi-Skill Playbook",
-  "description": "Schema for a single multi-skill playbook definition consumed by skills/jenga/scripts/load-playbooks.sh (E53_S02_T01). A playbook is a dedicated, versionable data file describing an ORDERED chain of skills that /jenga's natural-language branch may propose (as an editable, confirmable numbered list -- see skills/jenga/scripts/render-playbook-confirmation.sh, E53_S02_T03) when free-text intent spans more than one skill and does not cleanly resolve to a single one via skills/route/SKILL.md's Step 2 matching. This file itself (schema.json) is never treated as a playbook -- load-playbooks.sh explicitly excludes it by filename when scanning skills/jenga/playbooks/*.json.",
+  "description": "Schema for a single multi-skill playbook definition consumed by skills/jenga/scripts/load-playbooks.sh (E53_S02_T01). A playbook is a dedicated, versionable data file describing an ORDERED chain of skills that /jenga's natural-language branch may propose (as an editable, confirmable numbered list -- see skills/jenga/scripts/render-playbook-confirmation.sh, E53_S02_T03) when free-text intent spans more than one skill and does not cleanly resolve to a single one via skills/j-route/SKILL.md's Step 2 matching. This file itself (schema.json) is never treated as a playbook -- load-playbooks.sh explicitly excludes it by filename when scanning skills/jenga/playbooks/*.json.",
   "type": "object",
   "required": ["id", "name", "description", "keywords", "examples", "steps"],
   "additionalProperties": false,
@@ -18,25 +18,92 @@
     },
     "description": {
       "type": "string",
-      "description": "One-sentence explanation of what this playbook accomplishes end-to-end, used as the lowest-priority match signal (description match, same as skills/route/SKILL.md's Step 2 Pass 3) when keywords/examples don't produce a confident match."
+      "description": "One-sentence explanation of what this playbook accomplishes end-to-end, used as the lowest-priority match signal (description match, same as skills/j-route/SKILL.md's Step 2 Pass 3) when keywords/examples don't produce a confident match."
     },
     "keywords": {
       "type": "array",
-      "description": "Short phrases (1-3 words) for verbatim, case-insensitive keyword matching against the raw natural-language prompt -- the highest-priority match signal (Pass 1), mirroring skills/route/SKILL.md's Step 2 Pass 1 semantics exactly, but scoped to this playbook's catalog rather than the single-skill catalog.",
+      "description": "Short phrases (1-3 words) for verbatim, case-insensitive keyword matching against the raw natural-language prompt -- the highest-priority match signal (Pass 1), mirroring skills/j-route/SKILL.md's Step 2 Pass 1 semantics exactly, but scoped to this playbook's catalog rather than the single-skill catalog.",
       "items": { "type": "string" },
       "minItems": 1
     },
     "examples": {
       "type": "array",
-      "description": "Natural-language example prompts a user might type that should resolve to this playbook. Used for the semantic similarity match (Pass 2), mirroring skills/route/SKILL.md's Step 2 Pass 2 semantics. At least one example must plausibly span the full breadth of this playbook's steps (not just its first step) so it is distinguishable from a plain single-skill match.",
+      "description": "Natural-language example prompts a user might type that should resolve to this playbook. Used for the semantic similarity match (Pass 2), mirroring skills/j-route/SKILL.md's Step 2 Pass 2 semantics. At least one example must plausibly span the full breadth of this playbook's steps (not just its first step) so it is distinguishable from a plain single-skill match.",
       "items": { "type": "string" },
       "minItems": 1
     },
     "steps": {
       "type": "array",
-      "description": "Ordered list of canonical skill DIRECTORY names (the directory under skills/<dir>/SKILL.md, e.g. \"j-brainstorm\", not the \"j.brainstorm\" frontmatter/invocation form and not the retired bare \"brainstorm\") that make up this playbook's chain, in the exact execution order. Per E50_S10's canonical naming contract the canonical directory is skills/j-<name>/, so a step value carries the j- prefix; the three permanent exceptions (jenga, jenga-permission-level, index) keep their bare directory names and are written bare. Each entry MUST resolve to an existing skills/<dir>/SKILL.md at load time -- load-playbooks.sh skips (with a stderr warning) any playbook referencing a nonexistent skill rather than silently including a broken chain in the catalog.",
-      "items": { "type": "string" },
+      "description": "Ordered list of steps making up this playbook's chain, in the exact execution order. A step is either a BARE STRING or a STEPOBJECT (E53_S03; composition added by E53_S05). A bare string is shorthand for {\"skill\": \"<name>\"} -- \"bare\" describes the JSON shape, never a bare skill NAME. A skill name is always a canonical skill DIRECTORY name (the directory under skills/<dir>/SKILL.md, e.g. \"j-brainstorm\", not the \"j.brainstorm\" frontmatter/invocation form and not the retired bare \"brainstorm\"); per E50_S10's canonical naming contract the canonical directory is skills/j-<name>/, so a step value carries the j- prefix, while the three permanent exceptions (jenga, jenga-permission-level, index) keep their bare directory names and are written bare. Each skill name MUST resolve to an existing skills/<dir>/SKILL.md at load time -- load-playbooks.sh skips (with a stderr warning) any playbook referencing a nonexistent skill rather than silently including a broken chain in the catalog. NOTE: this schema documents SHAPE only. The cross-step rules -- forward_from naming an EARLIER step whose skill declares a non-empty output_types, conditional.depends_on naming an EARLIER step, composition cycle/depth limits -- are not expressible here and are enforced by load-playbooks.sh, which remains the single source of truth for validation.",
+      "items": {
+        "oneOf": [
+          {
+            "type": "string",
+            "description": "Bare-string step: shorthand for {\"skill\": \"<name>\"}, unchanged original behavior. An all-bare-string playbook loads byte-for-byte the same as it did before E53_S03, and a bare-string step is never rewritten into object form in the loader's output."
+          },
+          { "$ref": "#/definitions/stepObject" }
+        ]
+      },
       "minItems": 2
     }
+  },
+  "definitions": {
+    "stepObject": {
+      "type": "object",
+      "description": "A StepObject step (E53_S03_T01). Carries EXACTLY ONE of the mutually exclusive target fields `skill` or `playbook` -- a step naming both, or naming neither, is rejected by load-playbooks.sh.",
+      "additionalProperties": false,
+      "oneOf": [
+        { "required": ["skill"], "not": { "required": ["playbook"] } },
+        { "required": ["playbook"], "not": { "required": ["skill"] } }
+      ],
+      "properties": {
+        "skill": {
+          "type": "string",
+          "description": "Invokes a single skill, same as a bare string. Value is a canonical skill directory name (see the `steps` description above)."
+        },
+        "playbook": {
+          "type": "string",
+          "description": "Composes another playbook by ID (E53_S05). Resolved and flattened in place at load time, so the emitted catalog's `steps` array never contains a raw playbook-type entry. Existence validation, cycle detection, and a configurable nesting-depth limit (project/configs/playbook-config.json's max_composition_depth, default 3) all apply."
+        },
+        "instruction": {
+          "type": "string",
+          "description": "Static natural-language text appended to this step's own invocation message."
+        },
+        "forward_from": {
+          "type": "string",
+          "description": "Names an EARLIER step in the same playbook (by that step's skill name) whose typed output becomes this step's actual invocation input. The named source's SKILL.md must declare a non-empty output_types -- a skill declaring nothing can never be a forward source. Transparent across composition boundaries, since composition resolution runs before this validation."
+        },
+        "resolve": {
+          "type": "string",
+          "description": "Natural-language instructions for reshaping/filtering/type-bridging the value forwarded into this step (e.g. \"pick the first three items\"). A step carrying both `resolve` and `playbook` is rejected at load time: resolve may never pre-authorize a downstream confirmation gate (E53_S07's safety review, permanently rejected)."
+        },
+        "conditional": {
+          "type": "object",
+          "description": "Runs this step only when the predicate holds against a named earlier step's captured output; otherwise the step is marked `skipped` and the chain continues without halting (E53_S04_T02). Unlike forward_from, this does NOT require the depended-on step to declare output_types.",
+          "additionalProperties": false,
+          "required": ["depends_on", "predicate"],
+          "properties": {
+            "depends_on": {
+              "type": "string",
+              "description": "Names an EARLIER skill step in this playbook whose captured output the predicate is evaluated against.",
+              "minLength": 1
+            },
+            "predicate": {
+              "type": "string",
+              "description": "The recognized predicate grammar, whose single source of truth is skills/jenga/scripts/run-playbook-step.sh: non_empty | empty | equals:<value> | not_equals:<value>.",
+              "pattern": "^(non_empty|empty|equals:.+|not_equals:.+)$"
+            }
+          }
+        },
+        "version": {
+          "type": "string",
+          "description": "RESERVED, currently a no-op. Accepted and passed through unchanged; not acted upon by anything yet. Exists so a future schema revision has a place to declare itself without a retroactive migration of every existing playbook."
+        },
+        "schema_version": {
+          "type": "string",
+          "description": "Alternate key name for `version`. Same reserved no-op semantics."
+        }
+      }
+    }
   }
 }

package/skills/jenga/playbooks/understand-then-commit.json

@@ -0,0 +1,19 @@
+{
+  "id": "understand-then-commit",
+  "name": "Understand Then Build",
+  "description": "Investigates existing or unfamiliar code first, then runs the full idea-to-commit pipeline on top of what was learned -- a composed chain built from the canonical idea-to-committed playbook, terminating at the commit.",
+  "keywords": [
+    "understand then build",
+    "investigate then build",
+    "explore then implement",
+    "onboard and build",
+    "learn the codebase first"
+  ],
+  "examples": [
+    "help me understand this codebase first, then plan a change here, build it, and commit it",
+    "investigate this existing code, then take an idea through planning, implementation, and a commit",
+    "look into what's already here, then brainstorm a fix, build it, and commit the work",
+    "onboard me to this project and then walk a new idea from planning through to a committed change"
+  ],
+  "steps": ["j-uncharted", {"playbook": "idea-to-committed"}]
+}

package/skills/jenga/scripts/load-nl-catalog.sh

@@ -46,7 +46,7 @@ fi
 
 # Resolve the jenga-agent PACKAGE root (where lib/generate-skill-allow-list.js and the canonical
 # skills/ tree actually live) — same monorepo-checkout vs. installed-npm-package detection used
-# by skills/init/scripts/init.sh's PKG_ROOT resolution.
+# by skills/j-init/scripts/init.sh's PKG_ROOT resolution.
 if [ -d "$SCRIPT_DIR/../../../templates" ]; then
   PKG_ROOT="$SCRIPT_DIR/../../.."
 elif [ -d "$JENGA_PROJECT_DIR/node_modules/@jenga-ai/agent/templates" ]; then

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/j-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"

package/skills/jenga/scripts/match-playbook.sh

@@ -3,7 +3,7 @@
 # skills/jenga/scripts/match-playbook.sh
 #
 # Deterministic PLAYBOOK matcher for `/jenga`'s natural-language branch (E53_S02_T02). Runs the
-# same three-pass matching *philosophy* as `skills/route/SKILL.md`'s Step 2 (keyword ->
+# same three-pass matching *philosophy* as `skills/j-route/SKILL.md`'s Step 2 (keyword ->
 # example similarity -> description), but scoped to the playbook catalog produced by
 # `load-playbooks.sh` (E53_S02_T01) instead of the single-skill catalog `load-nl-catalog.sh`
 # produces for `/route`/`/jenga`'s existing single-skill matching.

package/templates/SCRUM_BOARD_SCHEMA.md

@@ -297,7 +297,7 @@ currently gates on its presence.
 
 ### `[SPIKE]` — Bounded Research
 
-**Scope:** story and task level only.
+**Scope:** story and task level, **and rapports** (extended by `E35_S03_T01`, see below).
 
 **Meaning:** a time-boxed research or exploration effort whose output is a decision, a design note,
 or an answered question — **not** shippable implementation code. Existing usage (`E06_S03_spike-editable-board.md`,
@@ -312,6 +312,19 @@ or an answered question — **not** shippable implementation code. Existing usag
 `[SPIKE]` predates this document; this section formalizes an existing informal convention rather
 than introducing new behavior.
 
+**Rapport scope extension (`E35_S03_T01`):** `[SPIKE]` also applies to a problem rapport (see
+`project/rapports/problems/`) via the same title-text convention — a `[SPIKE] <Topic>` prefix on
+the rapport's own title/header field, not a frontmatter key (rapports don't carry board
+frontmatter at all). This marks a rapport as itself surfacing a bounded research question or a
+distinct idea worth tracking, independent of whatever problem the rapport was originally filed
+to report. In practice this happens as part of the idea-lifecycle outcome-record mechanism
+(`E35_S03`): when a `project/ideas.md` entry that originated from a rapport (see
+`skills/idea/SKILL.md`'s "Source-Rapport Link Convention") is later promoted or rejected, the
+outcome-record step updates that rapport with the decision and prefixes its title `[SPIKE]` if
+it isn't already tagged. As with the story/task usage above, this is advisory only — nothing
+validates or enforces the prefix's presence, and a rapport's normal `Type:`/`Related
+Epic/Story/Task` fields (per `templates/PROBLEM_RAPPORT_TEMPLATE.md`) are unaffected by it.
+
 ### `[ARCH]` — Durable Architectural Inventory
 
 **Scope:** epic, story, and task level. This is the **first tag extended to epic level** — `[SPIKE]`

package/templates/SKILL_TEMPLATE.md

@@ -3,8 +3,20 @@ name: <skill-name>
 description: <One-sentence description of what this skill does and when to use it.>
 metadata:
   prefered_agent: <agent-name>   # optional — remove if not applicable
+output_types: <type>             # optional — forwardable output type(s) this skill produces; a single
+                                 #   type string or a list of {when, type} entries. Declare only if this
+                                 #   skill genuinely produces output a playbook step could consume
+                                 #   (honesty over breadth, E53_S11). Remove if not applicable.
+input_types: <type>              # optional — forwarded input type(s) this skill accepts; same two
+                                 #   shapes as output_types. May be broadly declared — honesty over
+                                 #   breadth is scoped to output_types only (E62_S01_T03).
+                                 #   Remove if not applicable.
 ---
 
+> Type values come from the canonical vocabulary in `templates/playbook-types.json`. See
+> `docs/skill-authoring.md`'s `output_types` and `input_types` sections for the full contract,
+> including the `text` rule and the normalize-versus-convert boundary.
+
 # <Skill Title> — <Short tagline>
 
 ## Instructions

package/templates/permission-levels/level-4-elevated.json

@@ -6,7 +6,7 @@
   "autoMode": {
     "allow": [
       "$defaults",
-      "Bash(bash skills/mirror-public/scripts/mirror.sh*)"
+      "Bash(bash skills/j-mirror-public/scripts/mirror.sh*)"
     ]
   },
   "permissions": {

package/templates/permission-levels/level-5-unrestricted.json

@@ -6,7 +6,7 @@
   "autoMode": {
     "allow": [
       "$defaults",
-      "Bash(bash skills/mirror-public/scripts/mirror.sh*)"
+      "Bash(bash skills/j-mirror-public/scripts/mirror.sh*)"
     ]
   },
   "permissions": {

package/templates/playbook-types.json

@@ -1,8 +1,36 @@
 {
-  "_comment": "Canonical playbook output-type vocabulary for Epic E53's Playbooks v2 StepObject/output_types contract (E53_S03_T02). Extend this vocabulary by adding entries to the 'types' array below -- NEVER by code changes; skills/jenga/scripts/load-playbooks.sh references this file by name in its own header contract (see that script's 'TYPE REGISTRY' section). Governed by the Scrum Master: registry additions/changes route through the normal board-item process rather than an ungoverned edit to this file -- see docs/skill-authoring.md's 'Playbook Type Registry Governance' section for the full policy.",
-  "types": [
-    "text",
-    "id_list",
-    "file_list"
-  ]
+  "_comment": "Canonical playbook type registry for Epic E53's Playbooks v2 StepObject/output_types contract (E53_S03_T02), converted from a bare list of type names into a map of type descriptors by E62_S01_T01. -- FORMAT: 'types' maps each type name to a descriptor object {\"verify\": <rule-object|null>, \"normalize\": [<transform-name>, ...]}. Both members are optional in the sense that 'verify' may be null and 'normalize' may be empty; a descriptor never carries any other key. -- VERIFY: null means the type has no checkable shape and runtime verification is a deliberate no-op. Otherwise it is an object whose keys are drawn ONLY from the enumerated 'verify_rules' below. The single rule kind defined today is 'per_line': a regex that every element of the normalized value must match. Regexes here are POSIX ERE, not PCRE -- write [0-9] and [^[:space:]], never \\d or \\S -- because the consuming validator is a shell script (E62_S01_T02). -- NORMALIZE: an ordered list of named transforms applied left to right BEFORE verification. The value is treated as a list of lines; 'split_on_comma' further splits each element on commas, 'trim' strips leading and trailing whitespace from each element, 'drop_empty' removes elements that are empty after trimming. Every entry MUST be a bare identifier matching ^[a-z][a-z0-9_]*$ AND a member of 'normalize_vocabulary' below. That closure is the single most important property of this format: because an entry cannot contain whitespace, a free-text or semantic-extraction instruction (e.g. 'extract the ids the skill meant to return') is STRUCTURALLY UNREPRESENTABLE here, not merely discouraged. LLM-driven auto-conversion and a type-repair skill were both rejected at epic level (E62); a transform name the validator does not implement is a hard error, never a string for anything to interpret. -- THE 'text' RULE: 'text' carries \"verify\": null because prose has no checkable shape. This is NOT a licence to treat 'text' as an 'any' in the load-time compatibility lattice. Unverifiable at runtime: yes. Universal acceptor at load time: no -- a universal acceptor would make every text-declaring skill compatible with everything, disarming exactly what E53_S11's honesty-over-breadth policy protects. -- EXTENDING: adding a TYPE is a DATA-ONLY edit and NEVER a code change -- add a key to 'types' whose verify/normalize are composed from the already-enumerated 'verify_rules' and 'normalize_vocabulary'. Adding a new TRANSFORM or a new RULE KIND is the one thing that does require code, since the validator has to implement it; extend the corresponding enumeration here in that same change. Removing or renaming an existing type is a breaking change: it invalidates every SKILL.md declaring it. skills/jenga/scripts/load-playbooks.sh references this file by name in its own header contract (see that script's 'TYPE REGISTRY' section). -- GOVERNANCE: owned by the Scrum Master. Registry additions or changes route through the normal board-item process rather than an ungoverned edit to this file -- see docs/skill-authoring.md's 'Playbook Type Registry Governance' section for the full policy.",
+  "verify_rules": [
+    "per_line"
+  ],
+  "normalize_vocabulary": [
+    "split_on_comma",
+    "trim",
+    "drop_empty"
+  ],
+  "types": {
+    "text": {
+      "verify": null,
+      "normalize": []
+    },
+    "id_list": {
+      "verify": {
+        "per_line": "^E[0-9]+(_S[0-9]+(_T[0-9]+)?)?$"
+      },
+      "normalize": [
+        "split_on_comma",
+        "trim",
+        "drop_empty"
+      ]
+    },
+    "file_list": {
+      "verify": {
+        "per_line": "^[^[:space:]]"
+      },
+      "normalize": [
+        "trim",
+        "drop_empty"
+      ]
+    }
+  }
 }