@eventmodelers/cli 1.0.163 → 2.0.1

package/shared/bridge/spec-kitty/bridge-spec-kitty-specify/SKILL.md

@@ -1,125 +0,0 @@
----
-name: bridge-spec-kitty-specify
-description: "Adapter: generate a Spec Kitty mission spec.md (and auto-evaluate its quality checklist) from an Eventmodelers board's exported event model, instead of running the /spec-kitty.specify interview. Use when the user says \"use the event model as the spec\", \"sync the board to spec-kitty\", \"generate the spec from the event model\", or when a .slices/ export exists and a Spec Kitty mission needs to start or refresh from it."
----
-
-# bridge-spec-kitty-specify
-
-Replaces the human interview in `/spec-kitty.specify` with a direct read of an
-Eventmodelers board export. The event model is the source of truth; `spec.md`
-becomes a **generated, read-only artifact** derived from it. Everything
-downstream of specify (`/spec-kitty.plan`, `/spec-kitty.tasks`,
-implement/review/merge) is untouched — this skill only produces the two
-artifacts that phase gate expects: `spec.md` and `checklists/requirements.md`.
-
-Do not use this to hand-author or hand-edit `spec.md` — if the event model is
-wrong, fix it on the board and re-run this skill. A `spec.md` produced here
-that gets manually edited afterward will be silently overwritten on the next
-sync; there is no merge/diff in this version (see Limitations).
-
-## Inputs
-
-The Eventmodelers `listen` server (`npx @eventmodelers/cli listen`) writes the
-board export locally. Read it directly — do not call the board API:
-
-- `.slices/current_context.json` → `{ "name": "<context>" }` — which context
-  to ingest if the user didn't name one.
-- `.slices/<context>/index.json` → `{ "slices": [{ id, slice, index, context,
-  folder, status, group }] }` — the ordered slice list.
-- `.slices/<context>/context.json` → context-level name/package info.
-- `.slices/<context>/<folder>/slice.json` → full slice detail per the
-  [event-modeling-spec](https://github.com/dilgerma/event-modeling-spec)
-  contract: `commands[]`, `events[]`, `readModels[]` (projections/queries),
-  `screens[]`, `automations[]`/`processors[]`, `specifications[]` (given/when/
-  then), plus free-text `description`/`notes`.
-
-If `.slices/` doesn't exist yet, stop and tell the user to run
-`npx @eventmodelers/cli listen` (or `init-modeling` first if the kit isn't
-installed) and push the board export before retrying.
-
-## Flow
-
-1. **Resolve the mission.** If an existing `kitty-specs/<slug>/meta.json`
-   already points at this context (check `purpose_tldr`/a stored context
-   reference), re-sync into it. Otherwise create a new mission dir the same
-   way `/spec-kitty.specify` does: kebab-case name + 8-char ULID suffix,
-   `mission_type: software-dev` (this adapter does not introduce a new
-   mission type — see project memory on why). Write `meta.json` matching the
-   shape in an existing mission (`mission_id`, `mission_slug`, `purpose_tldr`,
-   `purpose_context`, `target_branch`, etc.).
-2. **Load every slice** referenced in `index.json` by reading each
-   `<folder>/slice.json`. Do not skip slices with empty `specifications` —
-   surface them as gaps in the checklist instead (step 4).
-3. **Compose `spec.md`** using the standard Spec Kitty template sections,
-   sourced only from what the model actually states — never invent detail
-   the board doesn't have:
-   - **Purpose** ← `context.json` name/description, or ask the user for a
-     one-paragraph purpose if the board has none.
-   - **Primary User Story** ← walk the slices in `index.json` order (this is
-     already the chronological/timeline order from the board) and narrate
-     the SCREEN → COMMAND → EVENT → READMODEL flow across them.
-   - **Acceptance Scenarios** ← one bullet per `specifications[]` entry,
-     copied straight from its given/when/then — do not paraphrase away
-     precision the model already captured.
-   - **Edge Cases** ← `specifications[]` entries that describe rejection/
-     negative/boundary behavior (reject, invalid, already-exists, etc.).
-   - **Domain Language** ← distinct nouns from event/command/read-model field
-     names and titles, deduped.
-   - **Functional Requirements (FR-###)** ← one row per COMMAND (state-change
-     slice) and per AUTOMATION slice; wording from the command/automation
-     name + `description`.
-   - **Non-Functional Requirements / Constraints** ← only from explicit
-     `notes`/`description` content tagged as timing/authorization/volume
-     constraints. If the model states none, leave the table empty — do not
-     fabricate NFRs to fill it.
-   - **Key Entities** ← distinct read-model/event payload shapes.
-   - **Interfaces to Other Teams** ← any `TRANSLATION`-type slice or external
-     system mentioned in a slice's `description`.
-4. **Evaluate `checklists/requirements.md`** against the ingested model
-   instead of a human review pass. Check an item only if the model
-   demonstrably satisfies it:
-   - "No [NEEDS CLARIFICATION] markers remain" → fails if any slice has an
-     empty `specifications[]` or a `description` containing `TODO`/`TBD`.
-   - "Requirements are testable and unambiguous" → fails if an FR/NFR row has
-     no backing `specifications[]` entry.
-   - "Non-functional requirements include measurable thresholds" → fails
-     (leave unchecked, don't skip the row) if the NFR table is empty but the
-     model contains AUTOMATION slices implying a timing constraint the board
-     never made explicit.
-   - Leave any check unchecked with a `## Notes` explanation when the event
-     model genuinely doesn't provide enough to verify it — this checklist
-     gates `/spec-kitty.plan`, so a false pass defeats the point of the gate.
-5. **Hand off.** Once `spec.md` + `checklists/requirements.md` are written,
-   tell the user the mission is ready for `/spec-kitty.plan` as normal — do
-   not run plan/tasks yourself from this skill.
-
-## Re-sync behavior
-
-Re-running this skill against the same mission regenerates `spec.md` and
-`checklists/requirements.md` wholesale from the current `.slices/` state.
-There is no field-level diff against the previous generation — if the spec
-needs to reflect board changes, re-run this skill rather than hand-patching
-`spec.md`.
-
-## Guardrail
-
-If a required section can't be populated from the event model (e.g. no
-Purpose anywhere on the board), ask the user rather than inventing one — an
-invented Purpose defeats the reason this adapter exists (the event model,
-not the LLM, is the source of truth for product intent).
-
-## Limitations (by design, v1)
-
-- Does not itself generate `tasks/WP##-*.md` from slices — see the companion
-  `bridge-spec-kitty-tasks` skill, which enforces a 1:1
-  slice-to-WP mapping when `wps.yaml` is written during
-  `/spec-kitty.tasks-outline`.
-- Does not introduce a new Spec Kitty mission type. Spec Kitty 3.2.5's
-  built-in mission types are loaded from a flat directory inside the
-  installed package (`doctrine/missions/mission_types/*.yaml`) via
-  `MissionTypeRepository.default()`, and org-pack extension for the
-  `mission_types` kind is unwired in this version (fragments only add
-  governance-graph metadata, not an executable type). A real native mission
-  type would require patching the installed `spec-kitty-cli` package itself.
-  This adapter avoids that entirely — it stays inside `mission_type:
-  software-dev` and only replaces the specify phase's *inputs*.

package/shared/bridge/spec-kitty/bridge-spec-kitty-tasks/SKILL.md

@@ -1,95 +0,0 @@
----
-name: bridge-spec-kitty-tasks
-description: "Adapter: enforce a 1:1 mapping between Eventmodelers board slices and Spec Kitty work packages when writing wps.yaml. Use when the user says \"one slice should become one task/WP\", \"generate tasks from the event model\", or right after bridge-spec-kitty-specify, in place of freeform subtask-grouping judgment in /spec-kitty.tasks-outline."
----
-
-# bridge-spec-kitty-tasks
-
-Companion to `bridge-spec-kitty-specify`. That skill turns the event model into
-`spec.md`; this one enforces that each **slice** on the board becomes exactly
-**one work package** — never split across WPs, never merged with another
-slice — when Spec Kitty's task-planning pipeline builds `wps.yaml`.
-
-This replaces only step 3–6 of `/spec-kitty.tasks-outline` (deriving
-subtasks and rolling them into WPs). `/spec-kitty.tasks-packages` and
-`/spec-kitty.tasks-finalize` run completely unmodified afterward — they only
-ever consume `wps.yaml`, and don't care where its groupings came from.
-
-## Why a hard 1:1 boundary
-
-Spec Kitty's default `tasks-outline` groups subtasks into WPs by
-judgment (target 3–7 subtasks, merge small ones, split large ones). That's
-the right default when subtask boundaries come from an LLM reading prose. It
-is the *wrong* default here: the event model already drew the real
-boundaries (each SLICE_BORDER is a reviewable, independently buildable unit
-the board's `Planned → InProgress → Done` slice lifecycle already governs).
-Re-grouping at the WP layer would create a second, competing notion of "unit
-of work" that drifts from the board over time. So this skill trades away
-`tasks-outline`'s sizing flexibility on purpose: WP boundary = slice
-boundary, full stop.
-
-## Inputs
-
-Same event-model export as `bridge-spec-kitty-specify`:
-`.slices/<context>/index.json` (slice list, board/timeline order) and each
-`.slices/<context>/<folder>/slice.json` (commands, events, readModels,
-automations, `specifications`). Also read, from `feature_dir`:
-`spec.md` (for FR/NFR ids — already generated by `bridge-spec-kitty-specify`) and
-`plan.md` (for the tech-stack/file-layout context needed to fill
-`owned_files`, since the event model doesn't know the codebase's directory
-structure).
-
-## Flow
-
-1. **One WP per slice, in board order.** Assign `WP01`, `WP02`, ... following
-   `index.json`'s order (already the board's chronological/timeline order).
-   Do not reorder for "phase grouping" the way default `tasks-outline` does —
-   the board order already encodes the intended build sequence.
-2. **Subtasks come from inside the slice, not across slices.** For each
-   slice, break its own commands/read-models/screens/automations into T-ids
-   (one per command handler, one per read-model endpoint, one per
-   screen/automation, one for its tests) — all nested under that slice's one
-   WP. Every subtask must trace to exactly one slice; never let a subtask
-   span two slices.
-3. **Dependencies from event flow, not guesswork.** WP *B* depends on WP *A*
-   iff slice B's commands/queries/automations consume an event that slice
-   A's commands/automations produce. Derive this by diffing each slice's
-   emitted event names against every other slice's consumed event names —
-   this is mechanical, not judgment-based, so don't also apply
-   `tasks-outline`'s "Phase 2 typically depends on Phase 1" heuristic on top
-   of it.
-4. **`requirement_refs` from the spec's own FR/NFR table.** Match each
-   slice's command/read-model/automation names against `spec.md`'s FR/NFR
-   rows (written by `bridge-spec-kitty-specify` from these same slices) and cite
-   whichever ids trace to this slice. A slice with no matching row means
-   `bridge-spec-kitty-specify` needs a re-run, not a fabricated ref here.
-5. **Write `wps.yaml`** using the exact schema `/spec-kitty.tasks-outline`
-   expects (`id`, `title`, `dependencies`, `owned_files`, `requirement_refs`,
-   `plan_concern_refs` or `cross_cutting: true`, `subtasks`, `prompt_file:
-   null`) — so `tasks-packages`/`finalize-tasks` need no awareness that this
-   skill (rather than default `tasks-outline`) produced it.
-6. **Hand off.** Tell the user to continue with `/spec-kitty.tasks-packages`
-   then `/spec-kitty.tasks-finalize` (or `spec-kitty next`) exactly as normal.
-
-## Guardrail: don't fix boundary problems here
-
-If a slice's own scope would blow past Spec Kitty's WP sizing ceiling (>10
-subtasks / >700 lines), **do not silently split it into two WPs** — that
-breaks the 1:1 invariant this skill exists to enforce, and produces the
-exact spec/code drift it's meant to prevent. Instead, flag it to the user:
-the slice is too coarse on the board itself, so split the SLICE_BORDER
-there and re-run both `bridge-spec-kitty-specify` and this skill. The event model
-stays the single place slice boundaries get decided.
-
-The same holds in the other direction: never merge two small slices into
-one WP for tidiness, even if `tasks-outline`'s default guidance would.
-
-## Limitations (v1)
-
-- `owned_files`/file-layout ownership still comes from `plan.md`, which is
-  still produced by the normal, LLM-authored `/spec-kitty.plan` — the event
-  model has no notion of source-file structure, so this isn't something to
-  push onto it.
-- Re-running this skill after the board changes regenerates `wps.yaml`
-  wholesale from the current slice set, same as `bridge-spec-kitty-specify`'s
-  re-sync behavior — no field-level diff against a prior run.

package/shared/build-kit/lib/agent.sh

@@ -1,20 +0,0 @@
-#!/bin/bash
-# Runs the AI agent with the given prompt in the project directory.
-# Called by ralph.sh with cwd already set to the project root.
-# Usage: ./agent.sh "<prompt>"
-
-set -euo pipefail
-
-PROMPT="${1:-}"
-if [[ -z "$PROMPT" ]]; then
-  echo "ERROR: No prompt provided"
-  exit 1
-fi
-
-claude --dangerously-skip-permissions -p "$PROMPT"
-
-# --- To use a local Ollama model instead, comment out the line above
-#     and uncomment the block below. Run `ollama serve` first.
-#
-# MODEL="${OLLAMA_MODEL:-qwen3.5:9b}"
-# node "$(dirname "$0")/ollama-agent.js" "$MODEL"

package/shared/build-kit/ralph.sh

@@ -1,111 +0,0 @@
-#!/bin/bash
-# Ralph agent loop — two independent loops, each triggered by their own condition
-#
-# onTask:        tasks.json has entries  → load slice from board, update .build-kit/.slices/
-# onPlannedSlice: .build-kit/.slices/ has a "Planned" slice → build it
-#
-# The loops are NOT causally linked — either can trigger on its own.
-#
-# Usage: ./ralph.sh [iterations] [project_dir]
-#   iterations  — number of loop cycles to run; 0 or omitted means run forever
-#   project_dir — path to the project root; defaults to the parent of .build-kit
-
-set -euo pipefail
-
-KIT_DIR="$(cd "$(dirname "$0")" && pwd)"
-ITERATIONS="${1:-0}"
-PROJECT_DIR="${2:-"$KIT_DIR/.."}"
-TASKS_FILE="$KIT_DIR/tasks.json"
-PROMPT_FILE="$KIT_DIR/lib/prompt.md"
-BACKEND_PROMPT_FILE="$KIT_DIR/lib/backend-prompt.md"
-AGENT_SCRIPT="$KIT_DIR/lib/agent.sh"
-
-HAS_CREDENTIALS=true
-if [[ "${RALPH_LOCAL:-}" == "1" ]]; then
-  echo "[ralph] --local — platform sync disabled." >&2
-  HAS_CREDENTIALS=false
-elif [[ ! -f "$KIT_DIR/.eventmodelers/config.json" ]]; then
-  echo "[ralph] Note: no .eventmodelers/config.json found — platform sync disabled." >&2
-  echo "        To enable board sync, follow: https://app.eventmodelers.ai/documentation#build" >&2
-  echo "        Code generation from local slice definitions will still run." >&2
-  HAS_CREDENTIALS=false
-fi
-
-echo "Ralph — kit: $KIT_DIR  project: $PROJECT_DIR"
-
-# Returns 0 if tasks.json has at least one task
-has_pending_tasks() {
-  [[ -f "$TASKS_FILE" ]] || return 1
-  local content
-  content=$(cat "$TASKS_FILE")
-  [[ "$content" != "[]" && -n "$content" ]]
-}
-
-# Status this loop picks work up from — `run --status-trigger <status>` (RALPH_STATUS_TRIGGER), default Planned
-PICKUP_STATUS="${RALPH_STATUS_TRIGGER:-Planned}"
-
-# Returns 0 if any JSON under .build-kit/.slices/ contains a slice in the pickup status
-has_planned_slices() {
-  grep -rqi "\"status\"[[:space:]]*:[[:space:]]*\"$PICKUP_STATUS\"" "$KIT_DIR/.slices/" --include='index.json' 2>/dev/null
-}
-
-# Returns the title of the first "Planned" slice, or empty string
-get_planned_slice_title() {
-  for index_file in "$KIT_DIR/.slices/"*/index.json; do
-    [[ -f "$index_file" ]] || continue
-    local title
-    title=$(node -e "
-      try {
-        const d = JSON.parse(require('fs').readFileSync(process.argv[1], 'utf-8'));
-        const s = (d.slices||[]).find(s => (s.status||'').toLowerCase() === process.argv[2].toLowerCase());
-        if (s) process.stdout.write(s.slice || s.id || '');
-      } catch(e) {}
-    " "$index_file" "$PICKUP_STATUS" 2>/dev/null)
-    if [[ -n "$title" ]]; then
-      echo "$title"
-      return
-    fi
-  done
-}
-
-# prompt.md and backend-prompt.md are instruction manuals with no request in them — handed one
-# alone, the agent may read it as background and ask what to do. Every turn ends with the concrete
-# request, the same one lib/ralph.js's taskRequest() appends.
-task_request() {
-  printf '\n\n---\n\nYour task now: %s, following the instructions above. Start immediately.\n' "$1"
-}
-
-# Runs agent.sh with the given prompt; retries on non-zero exit
-run_agent() {
-  local label="$1"
-  local prompt="$2"
-  while true; do
-    echo "[$(date -u +%H:%M:%S)] $label"
-    (cd "$PROJECT_DIR" && bash "$AGENT_SCRIPT" "$prompt") 2>&1 && return 0
-    echo "[$(date -u +%H:%M:%S)] Agent error — retrying in 60s..."
-    sleep 60
-  done
-}
-
-cycle=0
-while [[ "$ITERATIONS" -eq 0 || "$cycle" -lt "$ITERATIONS" ]]; do
-  ran_something=false
-
-  if [[ "$HAS_CREDENTIALS" == true ]] && has_pending_tasks; then
-    run_agent "onTask: loading slice from board..." "$(cat "$PROMPT_FILE"; task_request 'process the pending tasks in tasks.json')"
-    ran_something=true
-  fi
-
-  if has_planned_slices; then
-    slice_title=$(get_planned_slice_title)
-    run_agent "onPlannedSlice: building \"$slice_title\"..." "$(cat "$BACKEND_PROMPT_FILE"; task_request "build the $PICKUP_STATUS slice \"$slice_title\"")"
-    echo "[$(date -u +%H:%M:%S)] Slice \"$slice_title\" build complete — waiting for next slice"
-    ran_something=true
-  fi
-
-  if [[ "$ran_something" == false ]]; then
-    sleep 3
-  fi
-
-  (( cycle++ )) || true
-done

package/shared/build-kit/realtime-agent.js

@@ -1,20 +0,0 @@
-#!/usr/bin/env node
-// Standalone realtime agent — subscribes to board events and writes tasks.json.
-// The same logic runs embedded inside ralph-claude.js / ralph-local-ai.js, so you
-// only need this if you want to run the agent independently (e.g. separate terminal).
-// Usage: node realtime-agent.js [kit_dir]
-
-import { loadLocalConfig, fetchPlatformConfig, retryTransient, startRealtimeAgent } from './lib/ralph.js';
-import { redactConsole } from './lib/redact.js';
-import { dirname, resolve } from 'path';
-import { fileURLToPath } from 'url';
-
-const kitDir = process.argv[2] ? resolve(process.argv[2]) : dirname(fileURLToPath(import.meta.url));
-
-const local = loadLocalConfig(kitDir);
-redactConsole([local.token]);
-const cfg = await retryTransient('fetchPlatformConfig', () => fetchPlatformConfig(local));
-
-console.log(`[agent] Starting — org=${cfg.organizationId}${cfg.boardId ? `, board=${cfg.boardId}` : ''}, base=${cfg.baseUrl}`);
-
-await startRealtimeAgent(cfg, kitDir);

package/stacks/bridge/templates/bridge/lib/AGENT.md

@@ -1,47 +0,0 @@
-# Agent Learnings
-
-Patterns and gotchas discovered during task processing. Update this file
-whenever you encounter something reusable.
-
-## tasks.json
-
-- Tasks are objects with `id`, `createdAt`, and `payload` (a
-  `SliceChangedPayload`).
-- Unlike build-kit, every status change is queued (not just non-`Planned`
-  ones) — see `queueAllStatuses` in `lib/ralph.js`.
-- After completing a task, remove it from the array entirely — do not add a
-  status field.
-- Write `[]` to `tasks.json` if the last task is completed.
-
-## SliceChangedPayload fields
-
-```
-event           always "slice:changed"
-organizationId  org UUID or null
-boardId         board UUID
-sliceId         SLICE_BORDER node UUID
-sliceTitle      human-readable slice name (may be null)
-sliceStatus     e.g. "Created", "Planned", "InProgress", "Done" (may be null)
-timestamp       unix ms when the change was emitted
-```
-
-## Bridge target
-
-- The active target framework lives in `.bridge-kit/bridge.json`'s `target`
-  field, written at `init --bridge --target <name>` time. This file is
-  committed (unlike `.eventmodelers/config.json`, which is gitignored) since
-  it's project policy shared by every teammate and CI runner, not a
-  per-machine credential.
-- Skill naming convention: `bridge-<target>-specify` (kept in sync every
-  task) and `bridge-<target>-tasks` (invoked separately, by that framework's
-  own task-planning phase — not from this loop).
-
-## Executors
-
-- Claude (`ralph-claude.js`, this prompt) is the default. `bridge --local-ai`
-  swaps in a local model instead — same prompt, different executor.
-- `bridge --hook "<command>"` (or a `hookCommand` persisted in
-  `bridge.json`) bypasses this prompt entirely: `ralph-hook.js` runs an
-  arbitrary shell command per batch of changes instead of any AI agent — e.g.
-  commit + push `.slices/` and let a CI pipeline do the actual translation.
-  If you're reading this file, a hook wasn't configured for this run.

package/stacks/bridge/templates/bridge/lib/prompt.md

@@ -1,111 +0,0 @@
-# Bridge Task Instructions
-
-You are an autonomous agent reacting to slice status change events on an
-Eventmodelers board. Unlike a build-kit agent, you do **not** write
-application code — you translate the board's event model into artifacts for
-another spec framework (e.g. Spec Kitty), keeping that framework's files in
-sync with the board as it changes.
-
-## Your Loop
-
-1. Read `AGENT.md` to load accumulated learnings before doing anything else.
-2. Read `.bridge-kit/tasks.json`.
-3. If `tasks.json` is empty or missing, reply with:
-   <promise>IDLE</promise>
-   and stop.
-4. Pick the **oldest task** (earliest `createdAt`).
-5. Execute the task — see the Execution section below.
-6. After execution, remove that task from the array and write
-   `.bridge-kit/tasks.json` back.
-7. Append a progress entry to `progress.txt` (create if missing).
-8. Update `AGENT.md` with any new reusable learnings discovered this
-   iteration.
-9. Reply normally so the next iteration can pick up the next task.
-
-## Execution
-
-Each task has a single `payload` of type `SliceChangedPayload`:
-
-```
-{
-  event:          "slice:changed"
-  organizationId: string | null
-  boardId:        string
-  sliceId:        string   ← SLICE_BORDER node UUID
-  sliceTitle:     string | null
-  sliceStatus:    string | null   ← e.g. "Planned", "InProgress", "Done"
-  timestamp:      number
-}
-```
-
-Unlike a build-kit agent, a bridge agent reacts to **every** status change
-(including `Planned`) — a task is queued regardless of `sliceStatus`. There
-is no separate "claim and build" step, so don't invoke `/update-slice-status`
-here; translation doesn't take ownership of a slice the way building does.
-
-### Step 1 — Load credentials
-
-Run `/connect` to resolve `TOKEN`, `BOARD_ID`, `ORG_ID`, and `BASE_URL` from
-`.eventmodelers/config.json`.
-
-### Step 2 — Resolve the bridge target
-
-Read `.bridge-kit/bridge.json`'s `target` field (e.g. `"spec-kitty"`). The
-matching translation skill is named `bridge-<target>-specify`.
-
-### Step 3 — Translate
-
-Invoke the `bridge-<target>-specify` skill. It reads `.slices/` (written by
-`npx @eventmodelers/cli listen`, which must be running separately — see that
-skill's own guardrail if `.slices/` doesn't exist yet) and regenerates that
-framework's spec artifacts **wholesale** from the current board state. Do
-not hand-author or patch those artifacts yourself — if they're wrong, the
-event model is wrong; fix it on the board and let the next slice change
-re-trigger this skill.
-
-Do **not** also invoke `bridge-<target>-tasks` from this loop. That
-companion skill enforces the 1:1 slice-to-work-package mapping during that
-framework's own task-planning phase (e.g. Spec Kitty's
-`/spec-kitty.tasks-outline`) — it's triggered by that framework's own
-tooling when the user reaches that phase, not by every board change.
-
-## Updating tasks.json
-
-After completing a task, remove it from the array and write the updated
-array back to `.bridge-kit/tasks.json`. If the array is now empty, write
-`[]`.
-
-## Progress Report Format
-
-APPEND to `progress.txt` (never replace):
-```
-## [ISO timestamp] — Task [task.id]
-
-Slice: [sliceTitle] ([sliceId])
-Status change: [sliceStatus]
-
-Action taken:
-- [what was translated / regenerated in response to the slice change]
-
-Learnings:
-- [any patterns, gotchas, or reusable knowledge discovered]
----
-```
-
-## Stop Condition
-
-If `.bridge-kit/tasks.json` is empty (`[]`) or does not exist, reply with:
-<promise>IDLE</promise>
-
-## Updating AGENT.md
-
-After completing a task, add any **reusable** learnings to `AGENT.md` —
-patterns, gotchas, or skill behaviour that future iterations should know.
-Only add things that are general and applicable beyond this single task. Do
-not duplicate what is already there.
-
-## Important
-
-- Process **one task per iteration**.
-- Read `AGENT.md` first — it contains patterns from previous iterations.
-- Always start with `/connect` if credentials are not yet loaded.

package/stacks/bridge/templates/bridge/ralph-claude.js

@@ -1,50 +0,0 @@
-#!/usr/bin/env node
-// Bridge loop using Claude Code as the executor. Unlike build-kit's
-// ralph-claude.js, there is no onPlannedSlice consumer — a bridge agent
-// doesn't "build" a Planned slice, it just translates every slice change as
-// it arrives via tasks.json (see lib/prompt.md and queueAllStatuses below).
-// Usage: node ralph-claude.js [project_dir]
-
-import { startRalph, loadLocalConfig } from './lib/ralph.js';
-import { spawn } from 'child_process';
-import { dirname, resolve } from 'path';
-import { fileURLToPath } from 'url';
-
-const kitDir = dirname(fileURLToPath(import.meta.url));
-const projectDir = process.argv[2] ? resolve(process.argv[2]) : resolve(kitDir, '..');
-
-const cfg = loadLocalConfig(kitDir);
-const inlineHeader = cfg.boardId
-  ? `board=${cfg.boardId} token=${cfg.token} org=${cfg.organizationId} baseUrl=${cfg.baseUrl}\n\n`
-  : '';
-
-const claudeArgs = ['--dangerously-skip-permissions'];
-if (cfg.model) claudeArgs.push('--model', cfg.model);
-const claudeEnv = cfg.anthropicBaseUrl
-  ? { ...process.env, ANTHROPIC_BASE_URL: cfg.anthropicBaseUrl }
-  : process.env;
-
-function runClaude(prompt) {
-  return new Promise((resolve, reject) => {
-    // Prompt on stdin, not as a `-p` argument — Windows cuts a multi-line argv entry at its first newline.
-    const proc = spawn('claude', [...claudeArgs, '-p'], {
-      cwd: projectDir,
-      stdio: ['pipe', 'inherit', 'inherit'],
-      env: claudeEnv,
-    });
-    proc.stdin.end(inlineHeader + prompt);
-    proc.on('close', (code) => (code === 0 ? resolve() : reject(new Error(`Claude exited ${code}`))));
-    proc.on('error', reject);
-  });
-}
-
-startRalph({
-  kitDir,
-  projectDir,
-  onTask: runClaude,
-  agentType: 'BRIDGE',
-  queueAllStatuses: true,
-}).catch((err) => {
-  console.error('[ralph] Fatal:', err);
-  process.exit(1);
-});