@mmerterden/multi-agent-pipeline 17.0.0 → 17.3.0

package/install/templates/multi-agent-autopilot.plist.template

@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+  multi-agent autopilot  -  the schedule for continuous mode.
+
+  Rendered and installed ONLY by /multi-agent:autopilot-on, after an explicit
+  confirmation that names this file's path. A clean install writes nothing here;
+  smoke-autopilot-default-off.sh fails if it ever does.
+
+  A user agent, not a daemon, and that is the correct choice rather than a
+  limitation: it loads at LOGIN. Before login the keychain is locked, so a tick
+  that fired at boot could not read a single token - it would take items it could
+  not work on and burn them. Automatic login means nothing to do after a restart.
+
+  StartInterval does NOT wake a sleeping Mac; it fires on the next wake. The mode
+  therefore holds its own sleep assertion while on AC and releases it on battery,
+  so an overnight queue keeps moving without flattening a laptop off the charger.
+
+  {{PLACEHOLDERS}} are substituted by autopilot-on: NODE, TICK, LABEL, ROOT,
+  INTERVAL.
+-->
+<plist version="1.0">
+<dict>
+  <key>Label</key>
+  <string>{{LABEL}}</string>
+
+  <key>ProgramArguments</key>
+  <array>
+    <string>{{NODE}}</string>
+    <string>{{TICK}}</string>
+  </array>
+
+  <!-- Load at login and run one tick immediately, so turning the mode on does
+       something visible rather than waiting out the first interval. -->
+  <key>RunAtLoad</key>
+  <true/>
+
+  <key>StartInterval</key>
+  <integer>{{INTERVAL}}</integer>
+
+  <!-- One tick at a time. Overlapping ticks would each claim the queue head;
+       the runner's own pid+sessionId check is the real mutual exclusion, and
+       this keeps the common case from ever reaching it. -->
+  <key>AbandonProcessGroup</key>
+  <false/>
+
+  <key>ProcessType</key>
+  <string>Background</string>
+
+  <!-- Nice to the interactive session. The point of this mode is work that
+       happens while you do something else, so it must never be what makes the
+       machine feel slow. -->
+  <key>LowPriorityIO</key>
+  <true/>
+  <key>Nice</key>
+  <integer>5</integer>
+
+  <!-- Both streams go to the runner's own log, inside the 0700 state directory.
+       Not /tmp: a tick's output names tickets, repos and branches, and on a
+       shared machine that is somebody's roadmap. Every file the runner writes
+       is scanned for credentials before it is kept. -->
+  <key>StandardOutPath</key>
+  <string>{{ROOT}}/runner.log</string>
+  <key>StandardErrorPath</key>
+  <string>{{ROOT}}/runner.log</string>
+
+  <key>EnvironmentVariables</key>
+  <dict>
+    <key>PATH</key>
+    <string>/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
+    <!-- No token is set here, deliberately. launchd plists are world-readable
+         and get backed up; credentials are read from the keychain at tick time
+         through credential-store.sh, which streams them over stdin so they never
+         reach argv either. -->
+  </dict>
+
+  <key>WorkingDirectory</key>
+  <string>{{ROOT}}</string>
+</dict>
+</plist>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mmerterden/multi-agent-pipeline",
-  "version": "17.0.0",
+  "version": "17.3.0",
   "description": "8-phase AI development pipeline with full orchestration on Claude Code, Copilot CLI and Codex CLI. Analysis, planning, TDD, CLI-aware parallel review with consensus surfacing + Fable triage, default-FAIL evidence gates, secret + intent guards, per-phase cost ledger, persistent learnings memory, wiki generation, commit automation. Token-preserving uninstall.",
   "type": "module",
   "main": "index.js",

package/pipeline/commands/multi-agent/autopilot-off/SKILL.md

@@ -0,0 +1,64 @@
+---
+description: "Turn off continuous mode on this machine: the schedule is removed, work already running finishes, the repo selection is kept. Use when the machine should stop picking work up."
+description-tr: "Bu makinede sürekli modu kapatır: zamanlama kaldırılır, koşan iş biter, repo seçimi saklanır."
+argument-hint: "[--now]  -  --now also stops the item currently running"
+---
+
+# multi-agent autopilot-off  -  stop picking work up
+
+Removes the schedule. **Work already in flight finishes** unless you pass
+`--now`: an item stopped mid-development leaves a worktree and a half-written
+branch, which is the exact state this release spent its time cleaning up.
+
+## Steps
+
+### 1. Say what is in flight before stopping anything
+
+```bash
+bash "$HOME/.claude/scripts/autopilot-status.sh" --short
+```
+
+When something is running, name it and how long it has been going. "Stopped"
+means something different when an item is 2 minutes from a PR than when the queue
+is idle, and the user is the one who knows which.
+
+### 2. Remove the schedule
+
+```bash
+L="com.multi-agent.autopilot"
+launchctl bootout "gui/$(id -u)/$L" 2>/dev/null || launchctl unload "$HOME/Library/LaunchAgents/$L.plist" 2>/dev/null
+rm -f "$HOME/Library/LaunchAgents/$L.plist"
+```
+
+The plist is removed rather than left disabled, because its presence is the
+definition of on: a disabled-but-present job is a third state nobody can read
+from the outside.
+
+### 3. Release the sleep assertion and the indicator
+
+```bash
+pkill -f 'caffeinate -i -w' 2>/dev/null || true       # only the one this mode holds
+pkill -f "$HOME/.claude/autopilot/bin/menubar" 2>/dev/null || true
+```
+
+### 4. `--now` only: end the in-flight item deliberately
+
+Without `--now` nothing here runs. With it, the child session is stopped and the
+run is marked `abandoned`, its worktree is removed **unless it holds uncommitted
+work**, in which case the work is stashed to `autopilot/abandoned/<task-id>` and
+the worktree is kept. Same contract as `gc-abandoned.sh`; losing a day of edits
+is worse than 750 MB.
+
+### 5. Keep the selection
+
+`~/.claude/autopilot/config.json`, `queue.json` and `attempted.jsonl` all stay.
+Turning the mode back on must not re-ask which repos, and the attempt history is
+what stops an item that already failed twice from being retried forever.
+
+To forget the selection as well: `rm -rf ~/.claude/autopilot`. Say that rather
+than doing it - "off" and "forget everything" are different requests.
+
+### 6. Report
+
+State that it is off, what was left running or finishing, and that the repo
+selection is kept. If an item was stashed, name the branch.

package/pipeline/commands/multi-agent/autopilot-on/SKILL.md

@@ -0,0 +1,181 @@
+---
+description: "Turn on continuous mode on THIS machine: pick the repos it watches; labelled GitHub issues and assigned+labelled Jira items then run in a worktree and stop at an open PR. Use when the machine should pick work up unattended."
+description-tr: "Bu makinede sürekli modu açar: izlenecek repoları seçersin, etiketli GitHub issue'ları ve sana atanmış + etiketli Jira maddeleri worktree'de geliştirilip PR'da durur. Repo listesini değiştirmek için aynı komutu tekrar çalıştır."
+argument-hint: "(no arguments  -  opens the repo picker)"
+---
+
+# multi-agent autopilot-on  -  continuous mode, on this machine
+
+Turns on the mode that picks work up without being asked. **No repo is included
+by default and none is ever added implicitly** - you choose, here, every time.
+
+Why a picker rather than a label alone: measured on one machine, 66 repos grant
+push and a good half belong to other people. A label is a filter; anyone who can
+open an issue in a repo you happen to have push on could add one. The gate is
+this selection, and it is per machine.
+
+## Steps
+
+### 1. Prerequisites, stated before anything is written
+
+```bash
+gh auth status >/dev/null 2>&1 || echo "BLOCKED: gh is not authenticated - run 'gh auth login'"
+command -v jq >/dev/null 2>&1 || echo "BLOCKED: jq is required"
+node "$HOME/.claude/scripts/doctor.mjs" >/dev/null 2>&1; [ "$?" -ge 2 ] && echo "BLOCKED: doctor reports a blocking problem - fix it first"
+```
+
+Any BLOCKED line stops here and is reported. Arming unattended work on an install
+that `doctor` calls broken produces a queue of failures, one per item.
+
+### 2. The repo list, both halves of it
+
+```bash
+bash "$HOME/.claude/lib/autopilot-activation.sh" list
+```
+
+Two states come back and **both are shown**:
+
+- `eligible` - push rights and a checkout on this machine
+- `unavailable` - push rights, no local checkout, listed WITH that reason
+
+Never hide the second list. Dropping 51 of 66 rows silently looks exactly like a
+permissions problem, and the user goes hunting for a token fault that does not
+exist.
+
+### 3. Pick, with the current selection already checked
+
+Read `~/.claude/autopilot/config.json` if it exists, then one `AskUserQuestion`
+(`multiSelect: true`) over the **eligible** rows:
+
+- `question` (in `outputLanguage`): which repos this machine should pick work up from
+- `header`: "Repos" (English, UI contract)
+- `options`: one per eligible repo, currently-selected ones marked "(seçili)" / "(selected)"
+
+**This is how repos are added and removed.** Checking a new one adds it;
+unchecking an existing one removes it. There is no `add-repo` / `remove-repo`
+command, because two entry points to one list is two lists.
+
+Unavailable repos are printed above the question as a plain list with their
+reason, not offered as options.
+
+### 4. Sources and label, per selected repo
+
+One `AskUserQuestion` per newly added repo (already-configured ones keep their
+answers - re-running must not re-ask what was already settled):
+
+- Sources: `GitHub issues` / `Jira` / both
+- Label: default **`agent-queue`** on both sides, editable
+
+The same name works on both sides and both mechanisms already exist:
+
+| Source | Query | Extra condition |
+|---|---|---|
+| GitHub | `gh issue list --repo <r> --label <label> --state open` | none - the label is the whole gate |
+| Jira | `assignee = currentUser() AND labels = "<label>" AND resolution = EMPTY AND status not in (Done, Closed, Cancelled)` | **assigned to you**, so a label somebody else adds is not enough |
+
+Two Jira caveats worth saying out loud when Jira is selected: labels are one
+global namespace across the whole instance and anyone can write them, so on a
+shared instance prefer a qualified name (`agent-queue-<team>`); and the Labels
+field has to be on the edit screen for the issue types in play. An instance where
+neither holds is a `jiraJql` config change - a saved filter, a component - not a
+redesign.
+
+Run the query before saving it, and show the count:
+
+```bash
+bash "$HOME/.claude/scripts/jira-search.sh" --jql "$JQL" --max 5 | jq '.total, [.issues[].key]'
+```
+
+A JQL that returns nothing is not an error and is usually correct on day one
+(nothing is labelled yet), but a JQL that errors is a config that will be silent
+forever - the Labels field missing from an edit screen looks exactly like an
+empty queue from the outside. Saying "0 items, query valid" and "query rejected"
+differently here is the difference between a two-minute fix and a week of
+wondering why nothing happens.
+
+### 5. Write the config
+
+Validate against `schemas/autopilot-config.schema.json`, then write
+`~/.claude/autopilot/config.json` (0600, in a 0700 directory) via
+`ma_ap_write` in `lib/autopilot-state.sh`. Defaults that are not asked:
+`slots: 1`, `scanIntervalSeconds: 120`, `maxAttempts: 2`,
+`askOnLowMaturity: true`, `costCeilingUsd: 25`, `depthRouter: "off"`.
+
+### 6. Build the menu bar indicator (best effort)
+
+```bash
+SRC="$HOME/.claude/scripts/autopilot-menubar.swift"
+OUT="$HOME/.claude/autopilot/bin/menubar"
+if command -v swiftc >/dev/null 2>&1; then
+  swiftc -O "$SRC" -o "$OUT" 2>/dev/null && chmod 700 "$OUT"
+fi
+```
+
+Built from source on demand, never shipped as a binary: the package contains only
+text today, and a compiled artifact in it would need signing and notarization to
+be distributable. No `swiftc` means no indicator and nothing else changes - say
+so in one line rather than failing. `autopilot-status` works either way.
+
+### 7. Confirm the schedule, naming the file
+
+Render `templates/multi-agent-autopilot.plist.template` by substituting its five
+placeholders, then show the resolved **path** and interval and `AskUserQuestion`:
+
+```bash
+. "$HOME/.claude/lib/autopilot-state.sh"
+TPL=$(ma_ap_asset templates/multi-agent-autopilot.plist.template) || {
+  echo "BLOCKED: the plist template is not installed on this host - re-run the installer"; exit 1; }
+DEST="$HOME/Library/LaunchAgents/com.multi-agent.autopilot.plist"
+INTERVAL=$(bash "$HOME/.claude/scripts/autopilot-status.sh" --json | jq -r '.scanIntervalSeconds // 120')
+sed -e "s|{{NODE}}|$(command -v node)|g" \
+    -e "s|{{TICK}}|$HOME/.claude/scripts/autopilot-runner.mjs|g" \
+    -e "s|{{LABEL}}|com.multi-agent.autopilot|g" \
+    -e "s|{{ROOT}}|$HOME/.claude/autopilot|g" \
+    -e "s|{{INTERVAL}}|$INTERVAL|g" \
+    "$TPL" > "$DEST"
+```
+
+`ma_ap_asset` rather than a literal `$HOME/.claude/templates/...`: only
+`install/claude.mjs` used to lay that tree down, so on a Copilot-only or
+Codex-only machine the mode would have written a launchd job from a template
+the host does not have. The state root stays shared on purpose - two CLIs on one
+machine must see one queue, not two.
+
+`command -v node` rather than the bare word: launchd does not read a login
+shell, so its `PATH` is the short one in the plist's own `EnvironmentVariables`,
+and a Homebrew or nvm node that is not on that path would make every tick fail
+with a message nobody is watching for.
+
+- `question`: install the schedule at `~/Library/LaunchAgents/com.multi-agent.autopilot.plist` and start picking work up?
+- options: `{ label: "Start" }` / `{ label: "Configure only", description: "Save the repo selection, do not schedule anything yet" }`
+
+"Configure only" is a real answer and the safe default to offer first: the queue
+can be watched with `autopilot-status` for a while before anything runs.
+
+On **Start**:
+
+```bash
+launchctl bootstrap "gui/$(id -u)" "$HOME/Library/LaunchAgents/com.multi-agent.autopilot.plist" 2>/dev/null \
+  || launchctl load "$HOME/Library/LaunchAgents/com.multi-agent.autopilot.plist"
+```
+
+### 8. Report what is now true
+
+Say all five, because each one is something a user has asked about after the
+fact: which repos and which labels; that it survives a restart with no command to
+run (launchd loads at **login** - not boot, and that is correct, because the login
+keychain is what unlocks the tokens, so a run before login could not reach Jira or
+GitHub anyway); that the machine will be kept awake **only on AC**; the slot count
+and the ceiling this machine would allow (`ma_ap_slot_ceiling`); and that
+`/multi-agent:autopilot-off` is the only way to stop it.
+
+## What this does not do
+
+- **No cap on PRs.** As many items as carry the label become as many PRs. The
+  bounds are `costCeilingUsd` over a rolling 24 hours and what the machine can
+  hold - never a daily count.
+- **Does not merge.** The runner stops at an open PR; the merge decision stays
+  yours.
+- **Does not touch an attended run.** Both are worktrees and per-repo concurrency
+  is 1, so the queue skips a repo you are working in rather than competing for
+  `.git/index.lock`.

package/pipeline/commands/multi-agent/autopilot-status/SKILL.md

@@ -0,0 +1,74 @@
+---
+description: "Show what continuous mode is doing here: what runs at which phase, what is queued, what waits for an answer, what PRs it opened today. Use when asked whether autopilot is on."
+description-tr: "Sürekli modun ne yaptığını gösterir: ne koşuyor hangi fazda, sırada ne var, ne cevap bekliyor, bugün hangi PR'lar açıldı."
+argument-hint: "[--subjects]  -  --subjects prints one widget line per in-flight item"
+---
+
+# multi-agent autopilot-status  -  what is it doing
+
+```bash
+bash "$HOME/.claude/scripts/autopilot-status.sh" ${ARGUMENTS}
+```
+
+That script is the **only** producer. The menu bar indicator, this command and
+the session-start hook all render the same `status.json` it writes, because the
+moment each computes its own answer they start disagreeing - which is the failure
+this whole area was built around: a run reading `in_progress` while its PR was
+already open.
+
+## What the output means
+
+| Line | Meaning |
+|---|---|
+| `KAPALI` with repos selected | the selection is kept, launchd holds no job. `autopilot-on` starts it again without re-asking |
+| `kurulu değil` | never configured on this machine; nothing has been written |
+| `Koşuyor` | in flight now. Phase and elapsed come from the run's own state, not from a guess |
+| `Cevap bekliyor` | the item was not mature enough, the open questions were posted as a comment, and it resumes on its own once answered |
+| `config açık ama launchd'de iş yok` | the failure a `resume` command would have hidden: an OS update dropped the plist, or it was booted out. Re-run `autopilot-on` |
+
+An empty queue is reported with the reason - no item carries the label yet - and
+not as an error. That is the most common "why is nothing happening", and it is
+not a fault.
+
+## The menu bar indicator
+
+When `swiftc` was available at `autopilot-on` time, `~/.claude/autopilot/bin/menubar`
+shows the same thing in the top right, refreshing on its own: one row per item
+with its id, whether it is running Full or Short, the phase as a fraction, the
+elapsed time and the stack, then the queue, then what is waiting, then the PRs of
+the last day - each one clickable.
+
+The indicator only **draws**. It cannot start, stop or change a run: control
+stays here, where it is confirmed. It disappears from the list the moment an item
+finishes, and the item reappears under `Raporlar` with its PR.
+
+No `swiftc` means no indicator and nothing else changes.
+
+## Watching the queue before anything runs
+
+The queue can be read dry, with no scheduling and nothing dispatched:
+
+```bash
+node "$HOME/.claude/scripts/autopilot-intake.mjs" --dry-run | jq '{queued: [.queued[].id], awaiting: [.awaiting[].id], dropped: [.dropped[] | {id, reason}]}'
+```
+
+This is the honest way to decide whether to arm the runner: it queries the same
+sources, applies the same ordering and the same attempt history, and writes
+nothing at all. `dropped` is the part worth reading - it is where "why is my
+issue not being picked up" is answered, one reason per item.
+
+## `--subjects`
+
+One line per in-flight item, shaped for the native task widget, with the numbers
+travelling **inside** the subject string because the widget takes exactly one
+string per row:
+
+```
+PROJ-1234 · Full · Faz 3/8 Dev · ios
+PROJ-1199 · cevap bekliyor
+```
+
+Honest limit, worth saying rather than discovering: that widget belongs to the
+session that calls `TaskUpdate`, and it refreshes when that session takes a turn -
+when you type, or when a hook fires. It is a view, not a live counter. The menu
+bar indicator is the one that updates on its own.

package/pipeline/commands/multi-agent/channels/SKILL.md

@@ -159,16 +159,39 @@ Non-interactive in three cases  -  menu skipped entirely, flag values or prefs u
 
 For each selected **content** source, produce one section body. Each section runs through the `humanizer` skill separately (Jira / Confluence / PR tones differ).
 
+**The Jira body is not the PR body.** Jira is read by the person who filed the
+ticket and by whoever tests it, so its comment carries the four sections
+`channels/jira.md` fixes - `summary` (`Geliştirme Özeti`), `test_scenarios`
+(`Test Senaryoları`), `impact` (`Etki Analizi`) and `context_refs`
+(`Bağlantılar`) - and nothing else. Technical sections go to the PR and to
+Confluence, where the reader is a code reviewer. A shipped Jira comment once
+explained a hash-table mutation across three paragraphs of class names; it was
+correct, and it was the wrong document. When `jira` is a selected channel, drop
+the technical sections from its body rather than converting them: the PR link on
+line 1 is how a Jira reader reaches the detail.
+
+`impact` is not a technical section in disguise. It answers four questions -
+what was wrong, what was changed, which areas must be tested, what else is
+affected - in the same plain register as the summary, and it is the part a test
+lead reads before deciding how wide to test.
+
 | Content option | Generated section |
 |---|---|
 | Normal analiz | `### Analysis`  -  impact summary from Phase 1, risks from Phase 4 (pipeline-log source, high-level only) |
-| Teknik analiz | `### Technical Details`  -  Changes (what/why per file group), Architecture (structural decisions, pattern changes), Dependencies (new imports/frameworks/packages). Source: Phase 2 planning + Phase 3 dev log + `git diff --stat`. Same shape as PR body's Technical Details  -  gives Jira/Confluence readers the code-reviewer view without making them click into the PR. |
+| Teknik analiz | `### Technical Details`  -  Changes (what/why per file group), Architecture (structural decisions, pattern changes), Dependencies (new imports/frameworks/packages). Source: Phase 2 planning + Phase 3 dev log + `git diff --stat`. **PR and Confluence only** - never rendered into a Jira comment. |
 | Test senaryoları | `### Test Scenarios`  -  precondition / steps / expected table (4-8 rows), user perspective |
 | Auto-diff | Old enrich Output Template verbatim  -  Root Cause / Solution / Changed Files / Test Scenarios |
 | Manuel not | `### Notes`  -  user-provided paragraph, or LLM-split into subsections if `--message` is plain text and long |
 | Cost özeti | `### Cost Summary`  -  per-phase token tally + est. USD table. Source: `phase-tracker.sh` phase status + optional OTel spans. See "Cost summary generation" below. |
 | Yapılan iş özeti | `### Work Summary`  -  executive one-screen summary: task + branch + base + PR, scope delivered (done/[pending] per Phase 2 task), changed files with +/- counts (capped at 20 rows), review outcome (accepted/deferred/rejected + approved), phase tick strip. Source: `agent-state.json` + `phase-tracker.json` + `git diff --numstat base...HEAD`. See "Work summary generation" below. |
 
+**The content options are sources, not the body's shape.** Which sections a PR
+body carries and in what order is fixed by `channels/pr.md` (`summary` →
+`technical` → `architecture` → `impact` → `test_scenarios` → `visuals` → `risk`
+→ `dependencies` → `build` → `related`); the options below choose what gets
+gathered to fill them. A content option left unselected means a section has no
+source, not that the section may be reordered or renamed.
+
 **Output template (aggregated across selected content options):**
 
 ```markdown
@@ -197,9 +220,13 @@ For each selected **content** source, produce one section body. Each section run
 | `path/to/File.ext` | +N / -M |
 
 ### Test Scenarios                  ← if "Test senaryoları" OR "Auto-diff" selected
-| # | Precondition | Steps | Expected | Status |
-|---|--------------|-------|----------|--------|
-| 1 | ...          | ...   | ...      | To Test|
+**1. {what this scenario exercises}**
+1. {step the tester performs}
+2. **Expected:** {what they should see}
+
+**2. {regression scenario}**
+1. {step}
+2. **Expected:** {what should still behave as before}
 
 ### Notes                           ← if "Manuel not" selected
 {user message}
@@ -240,13 +267,7 @@ If no cached report exists, skip silently  -  this is augmentation, not a gate.
 
 **Work summary generation:**
 
-Emitted only when `reportContent.workSummary === true` and at least one of (`agent-state.json`, `--branch` flag) is available. The shell adapter is `$HOME/.claude/scripts/render-work-summary.sh <taskId>`:
-
-1. **Task header**  -  `taskId`, `branch`, `baseBranch`, `prNumber` from `agent-state.json` (or explicit flags for post-hoc invocation).
-2. **Scope delivered**  -  Phase 2 `planTodos[]` / `tasks[]` rendered as `done` (status=done) or `pending` (anything else) rows. Task id + title shown; `(deferred  -  rationale)` appended if the task's `status` is `"deferred"`.
-3. **Changed files**  -  `git -C $WORKTREE diff --numstat $baseBranch...HEAD`. Shows `` `path` (+add / -del) `` per row, capped at 20 with a `_... +N more files not shown_` footer when exceeded. Total adds/dels + file count in section header.
-4. **Review outcome**  -  from `reviewConsensus` (pre-v6.1) or `phases["4"].triage`: `{accepted} accepted · {deferred} deferred · {rejected} rejected · approved={bool}`. Hidden entirely when all three buckets are empty (normal for a run that never reached Phase 4).
-5. **Phase tick strip**  -  single line from the tracker state (`render-work-summary.sh` resolves worktree/artifacts copies, then `$HOME/.claude/logs/multi-agent/{taskId}/tracker-state.json`): `0 Init [done] · 1 Analysis [done] · 2 Planning [done] · 3 Dev [done] · 4 Review [done] · 5 Test skipped · 6 Commit [done] · 7 Report active`. Marks: `done` completed · `active` in_progress · `failed` failed · `skipped` skipped · `·` pending.
+Emitted only when `reportContent.workSummary === true` and at least one of (`agent-state.json`, `--branch` flag) is available. The shell adapter is `$HOME/.claude/scripts/render-work-summary.sh <taskId>`, and that script's own header is the spec for what it emits - task header, scope delivered, changed files, review outcome, phase strip - including the caps and the hidden-when-empty rules. Re-stating those five steps here gave the pipeline two specifications of one script, and the prose one is the copy that rots. Exit 2 means the state was unreadable: skip the section, do not substitute a hand-written one.
 
 **Output template:**
 
@@ -369,7 +390,15 @@ Aggregated Markdown from Step 5 → PR description. GitHub uses `gh pr edit --bo
 Full contract: [`$HOME/.claude/multi-agent-refs/channels/pr.md`]($HOME/.claude/multi-agent-refs/channels/pr.md)  -  Bitbucket payload assembly snippet, version-mismatch retry, `--ready` promotion, multi-repo cross-link block.
 
 #### Adapter: Jira comment
-Body converted to Jira wiki markup (`### ...` → `*...*`, `- [ ] ...` → `# ...`, `` `x` `` → `{{x}}`, tables to `||h||h|| |c|c|`); first line is the PR URL. The converted body then goes through `node "$HOME/.claude/scripts/jira-wiki-escape.mjs"` (required, not optional  -  Jira renders `:)` `(x)` `(!)` `(/)` as emoticon images, and a Swift selector like `login(source:input:)` ends in `:)`). POST `/rest/api/2/issue/{id}/comment` via heredoc + `jq --rawfile` + `curl --data-binary @file`, from the escaped file. Token resolved from `keychainMapping.jira`.
+Sections: `summary` + `test_scenarios` + `impact` + `context_refs` only - the technical ones go to the PR and Confluence (`channels/jira.md` fixes the order). The PR URL goes on line 1, above the first heading. The wiki-markup conversion table lives in that same ref and only there: the four-row summary that used to sit here mapped `### ...` to `*...*`, which is italic, not a heading - a shrunken copy of a table is a second answer, and it was the wrong one.
+
+Then post it - do not assemble the request:
+
+```bash
+bash "$HOME/.claude/lib/jira-publish.sh" --issue "$JIRA_ID" --body-file "$F" --target comment
+```
+
+The publisher escapes every body (Jira renders `:)` `(x)` `(!)` `(/)` as emoticon images, and a Swift selector like `login(source:input:)` ends in `:)`) and resolves the token from `keychainMapping.jira` without putting it on argv. The hand-rolled `jq`+`curl` this replaced kept the escape as a separate step, and a shipped comment turned `hash(into:)` into a smiley.
 
 Full contract: [`$HOME/.claude/multi-agent-refs/channels/jira.md`]($HOME/.claude/multi-agent-refs/channels/jira.md)  -  full conversion table, multi-repo PR-list prepend, Wiki→Jira triad interaction.