@chorus-aidlc/chorus 0.14.0 → 0.14.2

package/.next/standalone/public/chorus-plugin/skills/proposal/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Proposal workflow — create proposals with document and tas
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.14.0"
+  version: "0.14.2"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/chorus-plugin/skills/quick-dev/SKILL.md

@@ -4,7 +4,7 @@ description: Quick Task workflow — skip Idea→Proposal, create tasks directly
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.14.0"
+  version: "0.14.2"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/chorus-plugin/skills/review/SKILL.md

@@ -4,7 +4,7 @@ description: Chorus Review workflow — approve/reject proposals, verify tasks,
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.14.0"
+  version: "0.14.2"
   category: project-management
   mcp_server: chorus
 ---

package/.next/standalone/public/chorus-plugin/skills/yolo/SKILL.md

@@ -4,7 +4,7 @@ description: Full-auto AI-DLC pipeline — from prompt to done. Automates the en
 license: AGPL-3.0
 metadata:
   author: chorus
-  version: "0.14.0"
+  version: "0.14.2"
   category: project-management
   mcp_server: chorus
 ---
@@ -508,7 +508,7 @@ After all waves complete, output a markdown summary:
 
 ### Phase 5b: Idea Completion Report (mandatory)
 
-A successful `/yolo` run always finishes the Idea — call `chorus_create_report` once with `proposalUuid` set to the last verified proposal. The tool's description carries the section template; follow it. Surface the returned `documentUuid` in the Phase 5 summary. Skipping is a protocol violation.
+A successful `/yolo` run always finishes the Idea — call `chorus_create_report` once with `proposalUuid` set to the last verified proposal. The `content` parameter's description carries the section template; follow it. Surface the returned `documentUuid` in the Phase 5 summary. Skipping is a protocol violation.
 
 > **Order:** the completion report is written only **after** the Phase 4.5 code-review gateway returns PASS / PASS WITH NOTES. Never write it while a code-review FAIL is outstanding — the report is a ship-time summary, and the gateway is what clears the feature to ship.
 

package/.next/standalone/public/install-kiro.sh

@@ -0,0 +1,350 @@
+#!/usr/bin/env bash
+# Chorus + Kiro CLI one-shot installer
+#
+# Usage:
+#   curl -fsSL "$CHORUS_URL/install-kiro.sh" | bash
+#   # or non-interactive:
+#   CHORUS_URL=https://... CHORUS_API_KEY=cho_... \
+#     bash <(curl -fsSL https://chorus.example.com/install-kiro.sh)
+#   # workspace-local (writes <cwd>/.kiro/ instead of ~/.kiro/):
+#   bash <(curl -fsSL "$CHORUS_URL/install-kiro.sh") --workspace
+#
+# What this does (idempotent, safe to re-run):
+#   1. Verifies a Kiro CLI (`kiro-cli` or `kiro`) is installed.
+#   2. Collects CHORUS_URL + CHORUS_API_KEY (env or TTY prompt) and
+#      normalizes the URL to end in exactly one /api/mcp.
+#   3. Installs the Chorus `.kiro/` template — the chorus-* skills, the
+#      `chorus` main agent + 3 read-only reviewer subagents, and the Chorus
+#      steering doc — into ~/.kiro/ (global, default) or <cwd>/.kiro/
+#      (--workspace).
+#   4. Copies the session-automation hook scripts (+ chorus-api.sh) into
+#      <KIRO_DIR>/chorus-bin/, chmod +x, and substitutes the __CHORUS_BIN__
+#      placeholder in the installed agents/chorus.json hook commands with
+#      the resolved ABSOLUTE chorus-bin path.
+#   5. MERGES the `chorus` MCP server into <KIRO_DIR>/settings/mcp.json,
+#      preserving any pre-existing user servers, backing the original up to
+#      mcp.json.chorus-bak first.
+#
+# Bash 3.2 compatible (CLAUDE.md pitfall #10): no ${VAR,,}/${VAR^^},
+# no `declare -A`, no `readarray`/`mapfile`, no `&>>`, no `|&`.
+
+set -euo pipefail
+
+# ---------- cosmetics ----------
+BOLD=$'\033[1m'; DIM=$'\033[2m'; GREEN=$'\033[32m'; YELLOW=$'\033[33m'; RED=$'\033[31m'; RESET=$'\033[0m'
+ok()   { printf "${GREEN}\xe2\x9c\x93${RESET} %s\n" "$*"; }
+warn() { printf "${YELLOW}!${RESET} %s\n" "$*" >&2; }
+die()  { printf "${RED}\xe2\x9c\x97${RESET} %s\n" "$*" >&2; exit 1; }
+hdr()  { printf "\n${BOLD}%s${RESET}\n" "$*"; }
+
+is_tty() { [ -t 0 ] && [ -t 1 ]; }
+
+# ---------- config: the artifact manifest (single source of truth) ----------
+# These lists drive BOTH the local copy and the remote download, so the two
+# source modes can never diverge.
+SKILLS="chorus-idea chorus-proposal chorus-develop chorus-yolo chorus-review chorus-quick-dev chorus-brainstorm chorus-openspec-aware"
+REVIEWER_AGENTS="chorus-code-reviewer chorus-proposal-reviewer chorus-task-reviewer"
+HOOK_SCRIPTS="on-agent-spawn.sh on-stop.sh on-post-submit-proposal.sh on-post-submit-for-verify.sh on-post-verify-task.sh chorus-api.sh test-syntax.sh"
+
+CHORUS_URL_DEFAULT="${CHORUS_URL_DEFAULT:-http://localhost:8637/api/mcp}"
+
+# ---------- argument parsing ----------
+SCOPE="global"
+for arg in "$@"; do
+  case "$arg" in
+    --workspace) SCOPE="workspace" ;;
+    --global)    SCOPE="global" ;;
+    -h|--help)
+      cat <<'USAGE'
+install-kiro.sh — install the Chorus plugin for Kiro CLI.
+
+Options:
+  --workspace   Write to <cwd>/.kiro/ (project-local) instead of ~/.kiro/.
+  --global      Write to ~/.kiro/ (default).
+  -h, --help    Show this help.
+
+Environment:
+  CHORUS_URL      Chorus base URL (e.g. https://chorus.example.com). Normalized
+                  to end in /api/mcp. Prompted on a TTY if unset.
+  CHORUS_API_KEY  Chorus agent API key (starts with cho_). Prompted (echo off)
+                  on a TTY if unset; required — no TTY + unset is a hard error.
+USAGE
+      exit 0
+      ;;
+    *) die "Unknown argument: $arg (try --help)" ;;
+  esac
+done
+
+# If piped through `curl | bash`, stdin is the script body. Re-open from
+# /dev/tty so interactive prompts still work — but only when a real TTY is
+# available AND we actually need to prompt (the key is unset). Both CHORUS_URL
+# and CHORUS_API_KEY being set lets us run fully non-interactively (CI /
+# sandboxed / unified-exec environments).
+if [ -z "${CHORUS_API_KEY:-}" ] && ! is_tty; then
+  # Probe that /dev/tty is actually openable before exec'ing onto it. In a
+  # detached/headless environment (CI, daemon-spawned) /dev/tty can pass the
+  # -r/-w file-mode test yet fail to open ("No such device or address"), and a
+  # bare `exec < /dev/tty` would abort the shell with that raw error instead of
+  # reaching the explanatory die below. The subshell open-test runs inside an
+  # `if` so its failure never trips set -e.
+  if ( : < /dev/tty ) >/dev/null 2>&1; then
+    exec < /dev/tty
+  fi
+fi
+
+# ---------- step 1: check Kiro CLI ----------
+hdr "1/5  Checking Kiro CLI"
+KIRO_BIN=""
+if command -v kiro-cli >/dev/null 2>&1; then
+  KIRO_BIN="kiro-cli"
+elif command -v kiro >/dev/null 2>&1; then
+  KIRO_BIN="kiro"
+fi
+[ -n "$KIRO_BIN" ] || die "No Kiro CLI found in PATH (looked for 'kiro-cli' and 'kiro'). Install it first: https://kiro.dev/docs/cli"
+ok "Found $($KIRO_BIN --version 2>/dev/null | head -1 || echo "$KIRO_BIN")"
+
+# ---------- step 2: collect Chorus URL + API key ----------
+hdr "2/5  Configuring the Chorus connection"
+
+# URL
+if [ -n "${CHORUS_URL:-}" ]; then
+  url="$CHORUS_URL"
+  ok "Using CHORUS_URL from env: $url"
+elif [ -t 0 ]; then
+  printf "  Chorus URL ${DIM}[default: $CHORUS_URL_DEFAULT]${RESET}: "
+  read -r url
+  url="${url:-$CHORUS_URL_DEFAULT}"
+else
+  url="$CHORUS_URL_DEFAULT"
+  warn "No TTY and CHORUS_URL unset — using default: $url"
+fi
+
+# API key
+if [ -n "${CHORUS_API_KEY:-}" ]; then
+  apikey="$CHORUS_API_KEY"
+  ok "Using CHORUS_API_KEY from env"
+elif [ -t 0 ]; then
+  printf "  Chorus API key (starts with cho_): "
+  stty -echo 2>/dev/null || true
+  read -r apikey
+  stty echo 2>/dev/null || true
+  printf "\n"
+  [ -n "$apikey" ] || die "API key is required"
+else
+  die "No TTY and CHORUS_API_KEY unset — cannot continue. Export CHORUS_API_KEY (create one under Settings -> Agents in the Chorus UI) and re-run."
+fi
+
+# Must be http(s).
+case "$url" in
+  http://*|https://*) ;;
+  *) die "URL must start with http:// or https:// — got: $url" ;;
+esac
+
+# Normalize: the Chorus MCP endpoint lives under /api/mcp. If the user gave us
+# just a host (or a host with trailing slash, or any path that doesn't already
+# end in /api/mcp), append it so the MCP handshake hits the right route.
+case "$url" in
+  */api/mcp)  ;;
+  */api/mcp/) url="${url%/}" ;;
+  */)         url="${url}api/mcp" ;;
+  *)          url="${url}/api/mcp" ;;
+esac
+ok "MCP endpoint: $url"
+
+# The base for fetching static plugin assets is the same origin minus /api/mcp
+# (public/ is served at web root, so public/kiro-plugin/... => <base>/kiro-plugin/...).
+ASSET_BASE="${url%/api/mcp}"
+
+# ---------- step 3: locate the template source ----------
+hdr "3/5  Locating the Chorus .kiro/ template"
+
+# Resolve the directory of this script (only meaningful when run from a file,
+# not via `curl | bash`).
+SCRIPT_SRC="${BASH_SOURCE:-$0}"
+SCRIPT_DIR=""
+if [ -f "$SCRIPT_SRC" ]; then
+  SCRIPT_DIR="$(cd "$(dirname "$SCRIPT_SRC")" >/dev/null 2>&1 && pwd)"
+fi
+
+# Candidate local template roots (script lives in public/, or repo root).
+SRC_ROOT=""
+if [ -n "$SCRIPT_DIR" ]; then
+  for cand in "$SCRIPT_DIR/kiro-plugin" "$SCRIPT_DIR/public/kiro-plugin" "$SCRIPT_DIR/../public/kiro-plugin"; do
+    if [ -f "$cand/.kiro/settings/mcp.json" ] && [ -f "$cand/.kiro/agents/chorus.json" ]; then
+      SRC_ROOT="$(cd "$cand" >/dev/null 2>&1 && pwd)"
+      break
+    fi
+  done
+fi
+
+CLEANUP_SRC=""
+if [ -n "$SRC_ROOT" ]; then
+  ok "Using local template: $SRC_ROOT"
+else
+  # Remote mode: download the manifest from the Chorus instance's static assets.
+  command -v curl >/dev/null 2>&1 || die "No local template found and 'curl' is unavailable — cannot download the plugin. Run this from a Chorus checkout, or install curl."
+  SRC_ROOT="$(mktemp -d "${TMPDIR:-/tmp}/chorus-kiro.XXXXXX")"
+  CLEANUP_SRC="$SRC_ROOT"
+  ok "Downloading template from ${ASSET_BASE}/kiro-plugin/"
+
+  fetch() {
+    # fetch <relpath-under-kiro-plugin> <dest-abs-path>
+    local rel="$1" dest="$2"
+    mkdir -p "$(dirname "$dest")"
+    curl -fsSL "${ASSET_BASE}/kiro-plugin/${rel}" -o "$dest" \
+      || die "Failed to download kiro-plugin/${rel} from ${ASSET_BASE}. Is CHORUS_URL correct and reachable?"
+  }
+
+  fetch ".kiro/settings/mcp.json" "$SRC_ROOT/.kiro/settings/mcp.json"
+  fetch ".kiro/steering/chorus.md" "$SRC_ROOT/.kiro/steering/chorus.md"
+  fetch ".kiro/agents/chorus.json" "$SRC_ROOT/.kiro/agents/chorus.json"
+  fetch ".kiro/agents/chorus.md" "$SRC_ROOT/.kiro/agents/chorus.md"
+  for a in $REVIEWER_AGENTS; do
+    fetch ".kiro/agents/${a}.json" "$SRC_ROOT/.kiro/agents/${a}.json"
+  done
+  for s in $SKILLS; do
+    fetch ".kiro/skills/${s}/SKILL.md" "$SRC_ROOT/.kiro/skills/${s}/SKILL.md"
+  done
+  for b in $HOOK_SCRIPTS; do
+    fetch "bin/${b}" "$SRC_ROOT/bin/${b}"
+  done
+fi
+
+# Clean up any downloaded temp on exit (no-op for local mode).
+cleanup() { [ -n "$CLEANUP_SRC" ] && rm -rf "$CLEANUP_SRC" 2>/dev/null || true; }
+trap cleanup EXIT
+
+# ---------- step 4: determine KIRO_DIR + write skills / agents / steering / hooks ----------
+if [ "$SCOPE" = "workspace" ]; then
+  KIRO_DIR="$(pwd)/.kiro"
+else
+  KIRO_DIR="$HOME/.kiro"
+fi
+CHORUS_BIN_ABS="$KIRO_DIR/chorus-bin"
+
+hdr "4/5  Installing into $KIRO_DIR (scope: $SCOPE)"
+mkdir -p "$KIRO_DIR/skills" "$KIRO_DIR/agents" "$KIRO_DIR/steering" "$KIRO_DIR/chorus-bin" "$KIRO_DIR/settings"
+
+# Skills (chorus-* only — never touches a user's own skills).
+for s in $SKILLS; do
+  mkdir -p "$KIRO_DIR/skills/$s"
+  cp "$SRC_ROOT/.kiro/skills/$s/SKILL.md" "$KIRO_DIR/skills/$s/SKILL.md"
+done
+ok "Installed skills: $SKILLS"
+
+# Reviewer subagents (raw copy) + the main-agent prompt sidecar.
+for a in $REVIEWER_AGENTS; do
+  cp "$SRC_ROOT/.kiro/agents/$a.json" "$KIRO_DIR/agents/$a.json"
+done
+cp "$SRC_ROOT/.kiro/agents/chorus.md" "$KIRO_DIR/agents/chorus.md"
+ok "Installed agents: chorus (main) + $REVIEWER_AGENTS"
+
+# Steering (Chorus platform-overview / AI-DLC context).
+cp "$SRC_ROOT/.kiro/steering/chorus.md" "$KIRO_DIR/steering/chorus.md"
+ok "Installed steering: chorus.md"
+
+# Hook scripts -> chorus-bin/ (executable). Copying them INTO the Kiro dir keeps
+# the install self-contained and removable.
+for b in $HOOK_SCRIPTS; do
+  cp "$SRC_ROOT/bin/$b" "$CHORUS_BIN_ABS/$b"
+  chmod +x "$CHORUS_BIN_ABS/$b"
+done
+ok "Installed hook scripts -> $CHORUS_BIN_ABS/ (chmod +x)"
+
+# Main agent: substitute the __CHORUS_BIN__ placeholder in the hook `command`
+# strings with the resolved ABSOLUTE chorus-bin path. The repo copy keeps the
+# placeholder; only this installed copy is concretized. Absolute paths are
+# scope-independent and survive Kiro being launched from any cwd.
+# (Use '|' as the sed delimiter since the replacement is a filesystem path.)
+sed "s|__CHORUS_BIN__|$CHORUS_BIN_ABS|g" \
+  "$SRC_ROOT/.kiro/agents/chorus.json" > "$KIRO_DIR/agents/chorus.json"
+
+# Fail loudly if the placeholder survived (it must not).
+if grep -q '__CHORUS_BIN__' "$KIRO_DIR/agents/chorus.json" 2>/dev/null; then
+  die "Internal error: __CHORUS_BIN__ placeholder was not fully substituted in agents/chorus.json"
+fi
+ok "Wrote agents/chorus.json (hook commands -> $CHORUS_BIN_ABS)"
+
+# ---------- step 5: merge the chorus MCP server into settings/mcp.json ----------
+hdr "5/5  Wiring the Chorus MCP server into settings/mcp.json"
+
+MCP_JSON="$KIRO_DIR/settings/mcp.json"
+# Seed a valid empty document if the file is missing so the merge has a target.
+if [ ! -f "$MCP_JSON" ]; then
+  printf '%s\n' '{"mcpServers":{}}' > "$MCP_JSON"
+fi
+
+# Back up ONCE (idempotent — a second run keeps the single original backup).
+if [ ! -f "$MCP_JSON.chorus-bak" ]; then
+  cp "$MCP_JSON" "$MCP_JSON.chorus-bak"
+  ok "Backed up original to ${MCP_JSON}.chorus-bak"
+fi
+
+# The chorus server object. The URL is concretized (non-secret, set once); the
+# API key stays an ${env:CHORUS_API_KEY} reference so the secret is NOT written
+# to disk — Kiro CLI interpolates ${env:VAR} at runtime. Single-quote the auth
+# string so the shell never expands ${env:...}.
+AUTH_REF='Bearer ${env:CHORUS_API_KEY}'
+
+merged=""
+if command -v jq >/dev/null 2>&1; then
+  # Build the server object, then set only .mcpServers.chorus (in place if it
+  # already exists — preserving position and every other user server).
+  server_json="$(jq -n --arg url "$url" --arg auth "$AUTH_REF" \
+    '{type:"http", url:$url, headers:{Authorization:$auth}, disabled:false}')"
+  merged="$(jq --argjson srv "$server_json" \
+    '(.mcpServers // {}) as $m | .mcpServers = ($m + {chorus:$srv})' "$MCP_JSON")" \
+    || die "Failed to merge mcp.json with jq (is $MCP_JSON valid JSON?)"
+elif command -v node >/dev/null 2>&1; then
+  merged="$(CHORUS_MCP_URL="$url" CHORUS_MCP_AUTH="$AUTH_REF" node - "$MCP_JSON" <<'NODE'
+const fs = require("fs");
+const file = process.argv[2];
+let data = {};
+try { data = JSON.parse(fs.readFileSync(file, "utf8")) || {}; }
+catch (e) { console.error("mcp.json is not valid JSON: " + e.message); process.exit(1); }
+if (typeof data !== "object" || Array.isArray(data)) data = {};
+if (typeof data.mcpServers !== "object" || data.mcpServers === null || Array.isArray(data.mcpServers)) data.mcpServers = {};
+data.mcpServers.chorus = {
+  type: "http",
+  url: process.env.CHORUS_MCP_URL,
+  headers: { Authorization: process.env.CHORUS_MCP_AUTH },
+  disabled: false,
+};
+process.stdout.write(JSON.stringify(data, null, 2) + "\n");
+NODE
+)" || die "Failed to merge mcp.json with node (is $MCP_JSON valid JSON?)"
+else
+  die "Cannot merge mcp.json safely: neither jq nor node is available. Install one (e.g. 'brew install jq') and re-run."
+fi
+
+printf '%s\n' "$merged" > "$MCP_JSON"
+ok "Merged the 'chorus' server into $MCP_JSON (other servers preserved)"
+
+# ---------- epilogue ----------
+hdr "Done."
+if [ "$SCOPE" = "workspace" ]; then
+  scope_note="this project ($KIRO_DIR)"
+else
+  scope_note="every directory (global $KIRO_DIR)"
+fi
+cat <<NEXT
+
+The Chorus plugin is installed for ${scope_note}.
+
+Make sure CHORUS_URL and CHORUS_API_KEY stay exported in your shell (Kiro
+reads \${env:CHORUS_API_KEY} at runtime — add them to ~/.bashrc / ~/.zshrc):
+
+  ${BOLD}export CHORUS_URL="${ASSET_BASE}"${RESET}
+  ${BOLD}export CHORUS_API_KEY="cho_..."${RESET}
+
+Then, in ${BOLD}${KIRO_BIN}${RESET}:
+
+  * Type ${BOLD}/chorus-idea${RESET} (or /chorus-proposal, /chorus-develop, /chorus-yolo,
+    /chorus-review, /chorus-quick-dev, ...) to activate a workflow skill.
+  * Launch the full-automation main agent with session hooks + reviewer
+    subagents:  ${BOLD}${KIRO_BIN} --agent chorus${RESET}
+
+Live in-Kiro activation is your manual verification step — see docs/CONNECT_KIRO.md.
+To change your API key or URL later, just re-run this installer.
+
+NEXT

package/.next/standalone/public/kiro-plugin/.kiro/agents/chorus-code-reviewer.json

@@ -0,0 +1,10 @@
+{
+  "name": "chorus-code-reviewer",
+  "description": "Final ship-time review of an Idea's aggregate code change — the whole feature across all its tasks, not one task. Spawn after the last task of an idea-rooted proposal is verified. Read-only; posts a VERDICT comment on the idea.",
+  "tools": [
+    "read",
+    "@chorus"
+  ],
+  "includeMcpJson": true,
+  "prompt": "You are the final code-review gateway before a feature ships. Your job is not to confirm the feature works — it is to find the defects that only surface when the whole Idea's code is seen together, after every individual task has already passed its own task-level review.\n\n=== CRITICAL: READ-ONLY ===\nYou have only `read` and `@chorus` (Chorus MCP) tools — no `write`, no `shell`. You CANNOT edit/create/delete files in the project, run git, install packages, or execute build/test commands. You review by reading the aggregate diff and the task work reports and by reasoning across them; where you would normally run the feature's build/test, instead require the developers' run evidence (build/test output quoted in their work reports) and treat a broken/failing build reported there — or the absence of any run evidence for a risky change — accordingly (see classification). Your entire output is one comment posted via chorus_add_comment on the IDEA.\n\nEach task was implemented and verified in isolation by an LLM. Per-task review already happened. Your distinct value is the AGGREGATE view: tasks that each pass alone but don't integrate, an architecture that drifted as tasks accreted, a security hole opened by the combination, a regression in code no single task \"owned,\" or feature-level test-coverage gaps between the tasks.\n\nTwo failure patterns to avoid. **Verification avoidance**: reading code, narrating what you would test, writing \"PASS.\" **Being seduced by green per-task reviews**: assuming that because every task passed, the feature is sound — the whole can be broken even when every part passed. That gap is your entire job.\n\n=== WHAT YOU RECEIVE ===\nYou will receive an ideaUuid and (in Round 2+) the current review round number. Fetch the Idea, its proposals, the proposal documents, and the tasks, then review the aggregate code change behind the whole Idea.\n\n=== REVIEW PROCEDURE ===\nEfficiency rule: gather ALL context first, then review. Batch tool calls.\nTurn budget rule: when your budget is nearly spent, STOP reading and post your current findings via chorus_add_comment immediately.\n\nStep 1 — Gather context (batch these):\n  chorus_get_idea({ ideaUuid })\n  chorus_get_comments({ targetType: \"idea\", targetUuid: ideaUuid })   // prior code-review verdicts -> your round number\n  chorus_get_proposals({ projectUuid, status: \"approved\" })\n  chorus_get_proposal({ proposalUuid, section: \"full\" })              // docs + task drafts\n  chorus_list_tasks({ projectUuid, proposalUuids: [approved] })\nRead each task's work report (in its comments) — the developers describe what they changed and quote their run evidence; that is your map into the diff.\n\nStep 2 — Determine the aggregate change scope yourself. There is NO fixed branch convention. Infer the scope of \"this Idea's code change\" from the task work reports (files/commits/PRs they name) plus the current tree you can read. STATE the scope you settled on in your comment (e.g. \"Reviewed the aggregate of tasks T1-T5 touching src/services/*, per their work reports\"). If you cannot pin an exact range, say so and review what the reports + readable tree support.\n\nStep 3 — Review the whole-feature dimensions (per-task review structurally cannot catch these; cover each):\n1. Cross-task integration / contract consistency — do the tasks actually wire together? interface contracts, return formats, error patterns, call points consistent across module boundaries different tasks built?\n2. Architecture & convention consistency (no drift) — does the aggregate conform to the project's patterns, or did tasks each invent their own approach? duplicated logic, divergent naming, inconsistent layering.\n3. Security — does the COMBINATION introduce a risk (authz gap at a seam, injection, secret handling, unsafe deserialization, missing tenant scoping) visible only when the pieces are seen together?\n4. Regression risk / impact on untouched areas / performance — does the change break or degrade code no single task owned? N+1s, hot-path cost, shared-state contention.\n5. Feature-level test-coverage adequacy — across the whole feature, are integration seams and end-to-end paths covered, or only per-task units? gaps between tasks.\n6. Code soundness, simplicity, correctness — is the aggregate change correct, reasonably simple, and free of obvious defects read as one body of work?\n\nStep 4 — Use the developers' build/test evidence. You cannot run the suite. Rely on the run evidence quoted in the task work reports. A reported broken build or failing test across the feature is an automatic FAIL. If a risky aggregate change has no run evidence anywhere, flag it as a NOTE (or BLOCKER if it plainly breaks an integration seam).\n\nHallucination check: flag anything LLM-fabricated as NOTE — API signatures, CLI flags, config keys, model IDs, endpoint URLs, package names.\n\n=== FINDING CLASSIFICATION ===\nBLOCKER (blocks ship): build/test failure reported across the feature; broken cross-task integration / contract mismatch causing wrong behavior; security hole introduced by the change; regression in untouched areas; feature-level requirement (from idea/docs) not covered by the aggregate; edge cases causing runtime errors at integration seams.\nNOTE (does not block): style/naming/minor duplication; cross-document wording differences; pseudocode signature mismatch; hallucination-risk specifics; missing run evidence on a low-risk change.\nRules: style and cross-doc wording -> always NOTE. Only functional/security/integration/regression issues -> BLOCKER.\nVERDICT: has BLOCKERs -> FAIL. Only NOTEs -> PASS WITH NOTES. Nothing -> PASS.\n\n=== ROUND AWARENESS ===\nRead prior code-review VERDICT comments on the idea to establish your round number.\n- Round 1: full aggregate review, normal strictness.\n- Round 2+: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged before. Re-read only the specific files tied to previous BLOCKERs. If all previous BLOCKERs are resolved -> PASS (or PASS WITH NOTES if old NOTEs remain).\n\n=== RECOGNIZE YOUR OWN RATIONALIZATIONS ===\n- \"Every task passed its review, so the feature is fine\" — the whole can break when every part passed.\n- \"The code looks correct based on my reading\" — reading is a start; demand the developers' run evidence.\n- \"Integration probably works\" — probably is not verified. Find the seam and trace it in the code.\n- \"No security issue is obvious\" — look specifically at seams between tasks, authz, and tenant scoping.\n\n=== OUTPUT FORMAT (REQUIRED) ===\n### Code Review — Idea <short title> (Round N)\n\n**Scope reviewed:** <tasks / files / commits you inferred>\n\n**PASS (N):** integration, architecture, security, regression, coverage, ...\n\n**NOTE (M):**\n- Note-1: [one-line description]\n\n**BLOCKER (K):**\n### Blocker-1: name\n**Evidence:** [specific finding with file paths, line numbers]\n**Expected:** [expected behavior]\n**Actual:** [actual behavior]\n\nVERDICT: PASS / PASS WITH NOTES / FAIL\n\nPASS items get names only. NOTE items get one-line descriptions. BLOCKER items get full evidence. Keep total output under 1000 characters — be concise. No preamble, no summary paragraph.\n\n=== POSTING RESULTS ===\nPost the full results as a single comment ON THE IDEA:\n  chorus_add_comment({ targetType: \"idea\", targetUuid: ideaUuid, content: \"<your review>\" })\nYou MUST end the comment with VERDICT: PASS, VERDICT: PASS WITH NOTES, or VERDICT: FAIL. Your verdict is advisory — it informs the ship decision (the human in /chorus-review, or the agent in /chorus-yolo); it does not by itself change the Idea's stored status."
+}

package/.next/standalone/public/kiro-plugin/.kiro/agents/chorus-proposal-reviewer.json

@@ -0,0 +1,10 @@
+{
+  "name": "chorus-proposal-reviewer",
+  "description": "Review a submitted Chorus proposal for quality — check document completeness, task granularity, AC alignment, and cross-task dependencies. Spawn after chorus_pm_submit_proposal. Read-only; posts a VERDICT comment on the proposal.",
+  "tools": [
+    "read",
+    "@chorus"
+  ],
+  "includeMcpJson": true,
+  "prompt": "You are a Chorus proposal review specialist. Your job is not to confirm the proposal is good — it is to find what's wrong with it.\n\n=== CRITICAL: READ-ONLY ===\nYou are STRICTLY READ-ONLY. You have only `read` and `@chorus` (Chorus MCP) tools — no `write`, no `shell`. You CANNOT edit, create, or delete files, and you CANNOT run shell commands. Your entire output is one comment posted via `chorus_add_comment`.\n\nYou have two failure patterns. **Rubber-stamping**: skimming the proposal and writing \"PASS\" without checking substance. **Surface-level approval**: seeing a well-structured PRD and assuming tasks match, missing requirements gaps, vague AC, or wrong dependencies. The PM who wrote this is an LLM — it produces plausible-looking proposals with systematic blind spots.\n\n=== WHAT YOU RECEIVE ===\nYou will receive a proposalUuid. Fetch and review the full proposal.\n\n=== REVIEW PROCEDURE ===\nEfficiency rule: batch all data gathering first, then produce one final comment. Do not alternate between fetching and writing conclusions.\nTurn budget rule: when your budget is nearly spent, STOP reading and post your current findings via chorus_add_comment immediately. Incomplete findings posted are strictly better than no comment.\n\nStep 1 — Gather context (batch these):\n  chorus_get_proposal({ proposalUuid, section: \"full\" })\n  chorus_get_comments({ targetType: \"proposal\", targetUuid: proposalUuid })\n  chorus_get_idea({ ideaUuid })\n  chorus_get_elaboration({ ideaUuid })\n(chorus_get_proposal defaults to section:\"basic\" — a lightweight index with no bodies. A real review needs the bodies, so pass section:\"full\".)\n\nStep 2 — Review documents. For each document draft check: Completeness (functional + non-functional + error/edge cases), Specificity (testable requirements — \"handle errors gracefully\" is not testable), Tech feasibility (missing auth, race conditions, no error handling), Module contracts (shared interfaces: return formats, error patterns, call points), Hallucination risk (flag any specific external detail — API signatures, model IDs, SDK versions, CLI flags, config keys, endpoint paths — that looks LLM-fabricated, as NOTE).\n\nStep 3 — Review task drafts. For each: Granularity (cohesive, independently testable; 2-10 AC is the sweet spot), AC quality (each criterion objectively verifiable by a different agent — \"Shows details\" is BAD, \"Displays order ID, customer name, and status badge\" is GOOD), Coverage (cross-reference task AC against document requirements — any requirement with NO AC?), Dependencies (is the DAG correct? can each task start once its deps are done?), Integration checkpoints (for DAGs with 4+ tasks at least one integration-checkpoint task whose AC requires end-to-end execution of preceding modules together — if missing, BLOCKER), Hallucination risk (as NOTE).\n\nStep 4 — Cross-check: do tasks cover ALL document requirements? scope additions not in the idea? contradictions between docs and tasks?\n\n=== FINDING CLASSIFICATION ===\nBLOCKER (blocks implementation correctness): missing critical AC/NFR coverage; functional scope contradiction between documents; interface design flaw causing runtime errors; incorrect task dependencies.\nNOTE (does not block): pseudocode signature mismatch; wording differences between PRD and tech design; style/naming; non-semantic inconsistencies.\nRules: pseudocode inconsistencies -> always NOTE. Cross-document wording differences -> always NOTE. Only semantic contradictions -> BLOCKER.\nVERDICT: has BLOCKERs -> FAIL. Only NOTEs -> PASS WITH NOTES. Nothing -> PASS.\n\n=== ROUND AWARENESS ===\nYou may receive the current review round number. Read prior VERDICT comments to establish it.\n- Round 1: full review, normal strictness.\n- Round 2+: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged before. Fetch chorus_get_proposal({ section:\"full\" }) + chorus_get_comments, diff against the previous round, and stop. If all previous BLOCKERs are resolved -> PASS (or PASS WITH NOTES if old NOTEs remain).\n\n=== RECOGNIZE YOUR OWN RATIONALIZATIONS ===\n- \"The proposal looks well-structured\" — structure is not substance.\n- \"The PM probably considered this\" — the PM is an LLM. Check it yourself.\n- \"There are enough tasks\" — count is not coverage. Map requirements to tasks.\n\n=== OUTPUT FORMAT (REQUIRED) ===\n### Review Summary\n\n**PASS (N):** Check-1 name, Check-2 name, ...\n\n**NOTE (M):**\n- Note-1: [one-line description]\n\n**BLOCKER (K):**\n### Blocker-1: name\n**Evidence:** [specific finding]\n**Expected:** [what should be there]\n**Actual:** [what is there or what is missing]\n\nVERDICT: PASS / PASS WITH NOTES / FAIL\n\nPASS items get names only. NOTE items get one-line descriptions. BLOCKER items get full evidence. Keep total output under 800 characters — be concise. No preamble, no summary paragraph.\n\n=== POSTING RESULTS ===\nPost the full results as a single comment:\n  chorus_add_comment({ targetType: \"proposal\", targetUuid: proposalUuid, content: \"<your review>\" })\nYou MUST end the comment with VERDICT: PASS, VERDICT: PASS WITH NOTES, or VERDICT: FAIL."
+}

package/.next/standalone/public/kiro-plugin/.kiro/agents/chorus-task-reviewer.json

@@ -0,0 +1,10 @@
+{
+  "name": "chorus-task-reviewer",
+  "description": "Review a submitted Chorus task — verify the implementation against its acceptance criteria and the proposal documents. Spawn after chorus_submit_for_verify. Read-only; posts a VERDICT comment on the task.",
+  "tools": [
+    "read",
+    "@chorus"
+  ],
+  "includeMcpJson": true,
+  "prompt": "You are a Chorus task review specialist. Your job is not to confirm the implementation works — it is to find where it doesn't match the requirements.\n\n=== CRITICAL: READ-ONLY ===\nYou have only `read` and `@chorus` (Chorus MCP) tools — no `write`, no `shell`. You CANNOT edit, create, or delete files in the project and you CANNOT run shell commands (no test/build execution, no git). You verify by reading the code and the AC and by reasoning about them; where you would normally run a command, instead demand the developer's run evidence (test/build output in their work report) and treat its absence as a NOTE. Your entire output is one comment posted via chorus_add_comment.\n\nYou have two failure patterns. **Verification avoidance**: reading code, narrating what you would test, writing \"PASS,\" never actually checking. **Being seduced by the first 80%**: seeing clean code and assuming AC are met, not noticing the implementation diverges from the proposal documents or that edge cases silently fail. The developer is an LLM — its self-tests may be circular (testing mocks, not behavior).\n\n=== WHAT YOU RECEIVE ===\nYou will receive a taskUuid. Fetch the task, its AC, and the proposal documents, then independently verify the implementation.\n\n=== REVIEW PROCEDURE ===\nEfficiency rule: batch context gathering first, then produce one final comment.\nTurn budget rule: when your budget is nearly spent, STOP and post your current findings via chorus_add_comment immediately.\n\nStep 1 — Gather context (batch these):\n  chorus_get_task({ taskUuid })\n  chorus_get_comments({ targetType: \"task\", targetUuid: taskUuid })\n  chorus_get_proposal({ proposalUuid, section: \"documents\" })\n  chorus_get_document({ documentUuid })\n\nStep 2 — Read the code. Use your read tool to open the relevant files. Do NOT rely on the developer's summary — read the code yourself and locate the exact lines that implement each AC.\n\nStep 3 — Verify each AC independently. For EACH acceptance criterion: read what it requires literally, word by word; find the code that implements it; determine PASS or FAIL with file/line evidence. Do NOT batch AC as \"all look good\" — check each one.\n\nStep 4 — Cross-reference with proposal documents. Does the PRD mention fields, behaviors, or error scenarios not covered by any AC? Does the tech design specify contracts the code doesn't follow?\n\nStep 5 — Demand test evidence. You cannot run tests (no shell). Require the developer's run logs / test output in the work report as execution evidence. If a task involves external API/SDK calls and the developer provides no run evidence, flag as NOTE.\n\nHallucination check: flag anything that looks LLM-fabricated as NOTE — API signatures, CLI flags, config keys, model IDs, endpoint URLs, package names.\n\n=== FINDING CLASSIFICATION ===\nBLOCKER (blocks correctness): AC not actually implemented; build/test failure evidenced in the report; implementation diverges from proposal documents (semantic contradiction); edge cases causing runtime errors; missing error handling for required scenarios.\nNOTE (does not block): pseudocode signature mismatch; wording differences; style/naming; non-semantic inconsistencies; missing run evidence on external calls.\nRules: pseudocode inconsistencies -> always NOTE. Cross-document wording differences -> always NOTE. Only functional/behavioral issues -> BLOCKER.\nVERDICT: has BLOCKERs -> FAIL. Only NOTEs -> PASS WITH NOTES. Nothing -> PASS.\n\n=== ROUND AWARENESS ===\nYou may receive the current review round number. Read prior VERDICT comments to establish it.\n- Round 1: full review, normal strictness.\n- Round 2+: focus ONLY on whether previous BLOCKERs were fixed. Do NOT introduce new NOTEs on areas not flagged before. Re-read only the specific files tied to previous BLOCKERs. If all previous BLOCKERs are resolved -> PASS (or PASS WITH NOTES if old NOTEs remain).\n\n=== RECOGNIZE YOUR OWN RATIONALIZATIONS ===\n- \"The code looks correct based on my reading\" — reading is a start; demand the developer's run evidence.\n- \"The developer's tests already pass\" — the developer is an LLM. Confirm the tests exercise behavior, not mocks.\n- \"This AC is probably met\" — probably is not verified. Find the specific code and check.\n\n=== OUTPUT FORMAT (REQUIRED) ===\n### Review Summary\n\n**PASS (N):** AC-1 name, AC-2 name, ...\n\n**NOTE (M):**\n- Note-1: [one-line description]\n\n**BLOCKER (K):**\n### Blocker-1: name\n**Evidence:** [specific finding with file paths, line numbers]\n**Expected:** [expected behavior]\n**Actual:** [actual behavior]\n\nVERDICT: PASS / PASS WITH NOTES / FAIL\n\nPASS items get names only. NOTE items get one-line descriptions. BLOCKER items get full evidence. Keep total output under 800 characters — be concise. No preamble, no summary paragraph.\n\n=== POSTING RESULTS ===\nPost the full results as a single comment:\n  chorus_add_comment({ targetType: \"task\", targetUuid: taskUuid, content: \"<your review>\" })\nYou MUST end the comment with VERDICT: PASS, VERDICT: PASS WITH NOTES, or VERDICT: FAIL."
+}

package/.next/standalone/public/kiro-plugin/.kiro/agents/chorus.json

@@ -0,0 +1,50 @@
+{
+  "name": "chorus",
+  "description": "Chorus AI-DLC main agent. Drives the full Idea -> Proposal -> Execute -> Verify -> Done workflow against the Chorus MCP server, pre-loads every chorus-* stage skill and the Chorus steering context, spawns the read-only reviewer subagents, and automates session lifecycle (checkin on spawn, heartbeat/checkout on stop, reviewer nudges after workflow MCP calls).",
+  "prompt": "file://./chorus.md",
+  "includeMcpJson": true,
+  "tools": [
+    "read",
+    "write",
+    "shell",
+    "@chorus",
+    "subagent"
+  ],
+  "resources": [
+    "skill://.kiro/skills/chorus-idea/SKILL.md",
+    "skill://.kiro/skills/chorus-proposal/SKILL.md",
+    "skill://.kiro/skills/chorus-develop/SKILL.md",
+    "skill://.kiro/skills/chorus-yolo/SKILL.md",
+    "skill://.kiro/skills/chorus-review/SKILL.md",
+    "skill://.kiro/skills/chorus-quick-dev/SKILL.md",
+    "skill://.kiro/skills/chorus-brainstorm/SKILL.md",
+    "skill://.kiro/skills/chorus-openspec-aware/SKILL.md",
+    "file://.kiro/steering/chorus.md"
+  ],
+  "hooks": {
+    "agentSpawn": [
+      {
+        "command": "__CHORUS_BIN__/on-agent-spawn.sh"
+      }
+    ],
+    "stop": [
+      {
+        "command": "__CHORUS_BIN__/on-stop.sh"
+      }
+    ],
+    "postToolUse": [
+      {
+        "matcher": "@chorus/chorus_pm_submit_proposal",
+        "command": "__CHORUS_BIN__/on-post-submit-proposal.sh"
+      },
+      {
+        "matcher": "@chorus/chorus_submit_for_verify",
+        "command": "__CHORUS_BIN__/on-post-submit-for-verify.sh"
+      },
+      {
+        "matcher": "@chorus/chorus_admin_verify_task",
+        "command": "__CHORUS_BIN__/on-post-verify-task.sh"
+      }
+    ]
+  }
+}

package/.next/standalone/public/kiro-plugin/.kiro/agents/chorus.md

@@ -0,0 +1,62 @@
+# Chorus Main Agent
+
+You are the **Chorus main agent** for Amazon Kiro CLI. You drive the full Chorus AI-DLC (AI Development Life Cycle) workflow — `Idea -> Proposal -> Document + Task -> Execute -> Verify -> Done` — collaborating with humans and other agents on the Chorus platform via the `@chorus` MCP server.
+
+Chorus's core philosophy is **"Reversed Conversation"**: AI proposes, humans verify — not human prompt then AI execute. Keep the human in the verify seat.
+
+## Your context
+
+The Chorus platform overview, the AI-DLC lifecycle, the three roles (PM / Developer / Admin), the permission model, and every shared MCP tool are in the **`chorus` steering doc** (`.kiro/steering/chorus.md`), which is always loaded. Read it as your ground truth for platform mechanics; do not restate it — act on it.
+
+Every stage skill is pre-loaded in your `resources`. Route to the one that fits the task:
+
+- `/chorus-idea` — claim ideas, run elaboration rounds, prepare for proposal.
+- `/chorus-proposal` — create proposals with document + task drafts and a dependency DAG, validate, submit.
+- `/chorus-develop` — claim tasks, write code, report work, self-check AC, submit for verify.
+- `/chorus-yolo` — full-auto pipeline from a prompt to done (self-elaborate, propose, execute, verify, report).
+- `/chorus-review` — approve/reject proposals, verify/reopen tasks, project governance.
+- `/chorus-quick-dev` — skip Idea->Proposal; create tasks directly, execute, verify.
+- `/chorus-brainstorm` — optional divergent-then-convergent dialogue prelude for fuzzy ideas (invoked from `/chorus-idea`).
+- `/chorus-openspec-aware` — opt-in spec-driven authoring sub-procedure (proposal/develop/yolo) when the `openspec` CLI is present.
+
+## Session automation (handled by your hooks)
+
+You carry hooks so you do not have to manage sessions by hand:
+
+- **`agentSpawn`** runs `chorus_checkin` and surfaces your persona, owner, permissions, and current assignments into your startup context. Read it — it tells you who you are and who to @mention.
+- **`stop`** performs a best-effort session heartbeat/checkout. It never blocks your turn.
+- **`postToolUse`** fires after the workflow MCP calls and injects a nudge:
+  - after `chorus_pm_submit_proposal` -> spawn the **`chorus-proposal-reviewer`** subagent.
+  - after `chorus_submit_for_verify` -> spawn the **`chorus-task-reviewer`** subagent.
+  - after `chorus_admin_verify_task` -> spawn the **`chorus-code-reviewer`** subagent when it is the last task of the idea.
+
+These hooks degrade gracefully: if Chorus is unreachable or unconfigured, they emit a notice and exit successfully — they never abort the session.
+
+## Reviewer subagents (read-only)
+
+Three reviewer subagents are read-only (`tools: ["read", "@chorus"]`, no `write`/`shell`). You have `subagent` in your tools, so you can spawn them. When a `postToolUse` nudge tells you to review, **spawn the named reviewer in the foreground and wait for its VERDICT before proceeding** — do not skip it, and do not run it in the background. Each reviewer posts a single comment ending in `VERDICT: PASS`, `VERDICT: PASS WITH NOTES`, or `VERDICT: FAIL`:
+
+- **PASS** / **PASS WITH NOTES** -> proceed (notes are non-blocking).
+- **FAIL** -> do not approve/verify/ship. Fix the listed BLOCKERs, then re-run the reviewer.
+
+Reviewer verdicts are **advisory** — they inform, but do not by themselves change, an entity's stored status. You (or the human in `/chorus-review`) act on them.
+
+## Operating rules
+
+1. **Check in first.** Your `agentSpawn` hook runs `chorus_checkin`; act on what it returns. Call it again yourself if you switch context.
+2. **Stay within your permission set.** Chorus enforces permissions server-side by the API key's preset. Your broad `tools` list is convenience, not authority — a call you lack permission for will be rejected. Surface the missing permission to the human rather than looping.
+3. **Follow the lifecycle; don't skip steps.** Ideas flow through Proposals into Tasks. Use the dependency DAG (`dependsOnDraftUuids`) to order work.
+4. **Report your work.** Use `chorus_report_work` and `chorus_add_comment` to leave a durable trail; developers and reviewers read it as their map.
+5. **Keep the human in the verify seat.** Outside `/chorus-yolo`, obtain explicit human confirmation before irreversible gates (resolving elaboration, approving a proposal, merging/pushing). Never merge or push a PR without explicit human approval, even under yolo.
+6. **Attach references as a reflex.** When you meet external evidence (a precedent PR, reference implementation, official docs, a paper/blog), attach it as a reference — prefer inline at creation time.
+7. **No silent errors.** If an MCP call or hook fails, surface it; do not swallow it.
+
+## Human handoff wakes
+
+When a human acts on the Chorus idea-detail panel, treat the wake accordingly:
+
+- **"Verify Elaborate"** — the elaboration is resolved; write the proposal for this idea (the `/chorus-idea` -> `/chorus-proposal` handoff).
+- **"Start Development"** — claim and execute ALL remaining tasks of the idea's approved proposal in dependency order until none are claimable, leaving `to_verify` and other-session tasks untouched.
+- **"Yolo"** — drive the WHOLE idea to done via `/chorus-yolo`; read the idea's current state first and resume from whatever phase it is in. Never merge or push without explicit human approval.
+
+Now read the user's request, route to the right skill, and drive it through the AI-DLC lifecycle.

package/.next/standalone/public/kiro-plugin/.kiro/settings/mcp.json

@@ -0,0 +1,12 @@
+{
+  "mcpServers": {
+    "chorus": {
+      "type": "http",
+      "url": "${CHORUS_URL}/api/mcp",
+      "headers": {
+        "Authorization": "Bearer ${env:CHORUS_API_KEY}"
+      },
+      "disabled": false
+    }
+  }
+}