@open-tomato/rafa 0.7.1

package/dist/plan/index.js

@@ -0,0 +1,47 @@
+// @bun
+import {
+  FINDING_KINDS,
+  FINDING_SIGNALS,
+  PLAN_BLOCK_KINDS,
+  PLAN_HEADER_FIELDS,
+  PROBE_TIMEOUT_MS,
+  REPORT_STATUSES,
+  loadPlanPrerequisites,
+  mergePlanPrerequisites,
+  parsePlan,
+  parsePrerequisites,
+  parseReport,
+  planPrerequisites,
+  prerequisitesPathForPlan,
+  renderInjection,
+  runPreflight,
+  runShellProbe
+} from "../index-adgde7x3.js";
+import {
+  INJECT_MODES,
+  RAFA_BLOCK_KINDS,
+  isRafaBlockKind,
+  readRafaBlocks
+} from "../index-akz06erg.js";
+export {
+  runShellProbe,
+  runPreflight,
+  renderInjection,
+  readRafaBlocks,
+  prerequisitesPathForPlan,
+  planPrerequisites,
+  parseReport,
+  parsePrerequisites,
+  parsePlan,
+  mergePlanPrerequisites,
+  loadPlanPrerequisites,
+  isRafaBlockKind,
+  REPORT_STATUSES,
+  RAFA_BLOCK_KINDS,
+  PROBE_TIMEOUT_MS,
+  PLAN_HEADER_FIELDS,
+  PLAN_BLOCK_KINDS,
+  INJECT_MODES,
+  FINDING_SIGNALS,
+  FINDING_KINDS
+};

package/dist/plan-prompt.md

@@ -0,0 +1,65 @@
+# Plan-generation instructions
+
+## Naming conventions
+
+All rafa work follows a consistent naming scheme across specifications,
+plans, branches, and pull requests. The board is GitHub Issues on
+`open-tomato/rafa`; every spec has one issue labelled `type:spec`, whose
+ID appears as `rafa-<n>`.
+
+| Artifact | Pattern | Example |
+| --- | --- | --- |
+| Specification file | `.rafa/specs/rafa-<n>-<slug>.md` | `.rafa/specs/rafa-20-pr-commands.md` |
+| Plan stub and directory | `rafa-<n>-<slug>` | `rafa-20-pr-commands` |
+| `issue:` field in `rafa:plan` | `<n>` (number only) | `issue: 20` |
+| Git branch | `feat/rafa-<n>-<slug>` | `feat/rafa-20-pr-commands` |
+| Pull request title | `rafa-<n>: <title>` | `rafa-20: Add pull-request commands` |
+| Pull request body | `Closes #<n>` | `Closes #20` |
+
+The slug summarizes what the user gets, using two to four words joined by
+hyphens. The order of work lives in ONE place: the pinned "Roadmap" issue
+on the `open-tomato/rafa` board.
+
+* Before planning, review the spec as written, and report that review at the
+  END of your final message as a `rafa:spec-review` block carrying
+  `verdict: ready` or `verdict: not-ready`, with empty `gaps:` for ready, or a
+  list of `{heading, what}` gaps for not-ready — only continue planning after
+  you have judged the spec ready. The block is the LAST thing you write: end
+  the final message with it, after the summary, and write nothing after it.
+* Inspect each definition-of-done item: can it be shown by running a command
+  or demonstrating a UI interaction, or is it worded too broadly for a reader
+  to measure?
+* Inspect each task name and the sentence that follows it: does it name what
+  the task changes, and is that claim defensible from the text, or must the
+  plan guess?
+* Inspect the headers the spec names: are they the ones the dev-planner
+  format requires, and does each hold actual content or only placeholders?
+* If any inspection finds a gap, write its heading as it appears in the spec,
+  the `what` explaining the gap clearly, and list them all under `gaps:` in
+  that closing block.
+
+Create a plan based on the spec at the end of this prompt, following the
+dev-planner format specification that precedes it. Produce the required
+checklists, technical assessments, feature requirements and acceptance
+criteria — **do not execute the plan**.
+
+{PROGRESS_SECTION}
+
+## Files to produce
+
+* Store the plan in `{PLAN_FILE}` (the plans directory is untracked unless
+  the project opts into tracking it — plans may describe unpatched issues;
+  never move them into a tracked path).
+* If the plan assumes any prerequisite — a service running, a credential in an
+  env var, an installed tool — create `{PREREQUISITES_FILE}` with those steps
+  as a checklist in the PREREQUISITES.md format of the dev-planner
+  specification below. Only genuinely non-automatable steps; do not duplicate
+  what `README.md`/`AGENTS.md` already require of every contributor. Link to
+  it from the plan.
+* Do not create or touch any tracker file — the loop derives it from the plan.
+
+{PLAN_FORMAT}
+
+## Spec
+
+{SPEC_CONTENT}

package/dist/plans/resolve-ci-install.md

@@ -0,0 +1,24 @@
+<!-- eslint-disable markdown/no-multiple-h1 -->
+# Plan: Resolve CI install failure
+
+```rafa:plan
+stub: resolve-ci-install
+issue: "20"
+spec: .rafa/specs/rafa-20-pr-commands.md
+```
+
+```rafa:context
+The `bun install` step in CI failed. This plan routes the repair task to the build-error-resolver agent with the CI log excerpt, allowing it to diagnose and fix dependency-related issues.
+
+This triage already read the failing job's log, and the excerpt below is what it read; do not fetch it again.
+
+{FAILING_LOG}
+```
+
+## Description
+
+This plan resolves a pull request with a failed `bun install` step in CI by delegating diagnosis and repair to the build-error-resolver agent, which will analyze the log excerpt and implement the necessary fix.
+
+# Stage: Resolve
+
+- [ ] Analyze the CI install failure log excerpt and repair the dependency or manifest issues that caused the install to fail {agent=build-error-resolver}

package/dist/plans/resolve-ci-lint.md

@@ -0,0 +1,24 @@
+<!-- eslint-disable markdown/no-multiple-h1 -->
+# Plan: Resolve CI lint failure
+
+```rafa:plan
+stub: resolve-ci-lint
+issue: "20"
+spec: .rafa/specs/rafa-20-pr-commands.md
+```
+
+```rafa:context
+The `bunx eslint .` step in CI failed. This plan routes the repair task to the build-error-resolver agent with the CI log excerpt, allowing it to diagnose and fix lint violations.
+
+This triage already read the failing job's log, and the excerpt below is what it read; do not fetch it again.
+
+{FAILING_LOG}
+```
+
+## Description
+
+This plan resolves a pull request with a failed `bunx eslint .` step in CI by delegating diagnosis and repair to the build-error-resolver agent, which will analyze the log excerpt and implement the necessary lint fixes.
+
+# Stage: Resolve
+
+- [ ] Analyze the CI lint failure log excerpt and repair the lint violations that caused the check to fail {agent=build-error-resolver}

package/dist/plans/resolve-conflict-lockfile.md

@@ -0,0 +1,28 @@
+<!-- eslint-disable markdown/no-multiple-h1 -->
+# Plan: Resolve lockfile conflict
+
+```rafa:plan
+stub: resolve-conflict-lockfile
+issue: "20"
+spec: .rafa/specs/rafa-20-pr-commands.md
+```
+
+```rafa:context
+{CONFLICT_SENTENCE}
+
+For lockfile conflicts specifically: merge the base, take the base's lockfile, then reinstall to re-anchor the branch's dependencies to the base's versions. This triage read the conflict from {CONFLICT_FILES}.
+```
+
+## Description
+
+This plan resolves a pull request with a `bun.lock` conflict by taking the base's lockfile version, reinstalling to verify the merged manifests are consistent, and confirming all gates pass before pushing.
+
+# Stage: Resolve
+
+- [ ] Merge the base branch into the current branch using `git merge origin/main` {agent=loop-implementer}
+- [ ] Take the base's `bun.lock` with `git checkout origin/main -- bun.lock` {agent=loop-implementer}
+- [ ] Run `bun install` (plain, not `--frozen-lockfile`) to re-anchor dependencies to the merged state {agent=loop-implementer}
+- [ ] Run `bun install --frozen-lockfile` to verify the lockfile is now consistent with the merged manifests {agent=loop-implementer}
+- [ ] Run the gates (`env -u CLAUDECODE bun test`, `bunx tsc --noEmit`, `bunx eslint .`) to verify no other conflicts arose {agent=loop-implementer}
+- [ ] Commit the merge and lockfile changes to the branch {agent=loop-implementer}
+- [ ] Push the resolved branch to the current branch on GitHub {agent=loop-implementer}

package/dist/plans/resolve-conflict-manifest.md

@@ -0,0 +1,28 @@
+<!-- eslint-disable markdown/no-multiple-h1 -->
+# Plan: Resolve manifest conflict
+
+```rafa:plan
+stub: resolve-conflict-manifest
+issue: "20"
+spec: .rafa/specs/rafa-20-pr-commands.md
+```
+
+```rafa:context
+{CONFLICT_SENTENCE}
+
+For manifest conflicts specifically: merge the base, keep both sides' entries and take the higher version where both bumped one, then reinstall to verify consistency and confirm all gates pass before pushing. This triage read the conflict from {CONFLICT_FILES}.
+```
+
+## Description
+
+This plan resolves a pull request with a `package.json` conflict by merging the base branch, keeping both sides' entries and taking the higher version where both dependencies were bumped, reinstalling to verify consistency, and confirming all gates pass before pushing.
+
+# Stage: Resolve
+
+- [ ] Merge the base branch into the current branch using `git merge origin/main` {agent=loop-implementer}
+- [ ] Resolve the `package.json` conflict by keeping both sides' entries and taking the higher version where both sides bumped a dependency {agent=loop-implementer}
+- [ ] Run `bun install` (plain, not `--frozen-lockfile`) to ensure both sides' dependencies are installed and the lockfile is updated {agent=loop-implementer}
+- [ ] Run `bun install --frozen-lockfile` to verify the lockfile is now consistent with the merged manifests {agent=loop-implementer}
+- [ ] Run the gates (`env -u CLAUDECODE bun test`, `bunx tsc --noEmit`, `bunx eslint .`) to verify no other conflicts arose {agent=loop-implementer}
+- [ ] Commit the merge and manifest changes to the branch {agent=loop-implementer}
+- [ ] Push the resolved branch to the current branch on GitHub {agent=loop-implementer}

package/dist/ports/index.js

@@ -0,0 +1 @@
+// @bun

package/dist/templates/spec.md

@@ -0,0 +1,37 @@
+---
+name: Spec
+about: A change described well enough that rafa can plan from it
+title: 'Spec: '
+labels: 'type:spec'
+assignees: ''
+---
+
+<!-- This issue is public. No local paths, no internal hostnames, no credentials: machine-specific notes belong in the local notes file beside the spec, never in this body. Delete every comment in this template as you fill it in. -->
+
+## What you get
+
+<!-- The change from the outside: what somebody can do after it that they cannot do now. One paragraph. -->
+
+## Starting position
+
+<!-- What exists today that this builds on: the modules, the commands and the readings that are already true. Name them. -->
+
+## Design
+
+<!-- How it works: the pieces, where each one lives, and which decision each of them owns. Name the alternative you rejected and why. -->
+
+## What can go wrong
+
+<!-- The failure modes, and what each one costs. A reading that could be a false negative belongs here with the control that would catch it. -->
+
+## Tasks the plan must carry
+
+<!-- One list item per piece of work, each naming what it changes. The plan is written from these items, so a paragraph here plans nothing. -->
+
+-
+
+## Definition of done
+
+<!-- One list item per thing that can be shown by a command. "Works well" is not an item; "bun test is green with the new cases" is. -->
+
+-

package/package.json

@@ -0,0 +1,74 @@
+{
+  "name": "@open-tomato/rafa",
+  "version": "0.7.1",
+  "description": "Alpha. Runs a plan through the ralph loop: one Claude Code session per task, one commit per task, then a pull request and a CI wait.",
+  "private": false,
+  "publishConfig": {
+    "access": "public",
+    "registry": "https://registry.npmjs.org/",
+    "@open-tomato:registry": "https://registry.npmjs.org/"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/open-tomato/rafa.git"
+  },
+  "homepage": "https://github.com/open-tomato/rafa#readme",
+  "bugs": {
+    "url": "https://github.com/open-tomato/rafa/issues"
+  },
+  "keywords": [
+    "claude-code",
+    "agent",
+    "loop",
+    "ralph",
+    "cli",
+    "bun"
+  ],
+  "license": "Apache-2.0",
+  "author": "Marcos Tomatti <marcos@opentomato.io>",
+  "packageManager": "bun@1.3.14",
+  "type": "module",
+  "module": "./dist/index.js",
+  "bin": {
+    "rafa": "./dist/cli.js"
+  },
+  "exports": {
+    ".": "./dist/index.js",
+    "./cli": "./dist/cli.js",
+    "./plan": "./dist/plan/index.js",
+    "./store": "./dist/effort/store/index.js",
+    "./ports": "./dist/ports/index.js"
+  },
+  "files": [
+    "dist",
+    "NOTICE"
+  ],
+  "engines": {
+    "bun": ">=1.3.14"
+  },
+  "scripts": {
+    "build": "rm -rf dist && bun build src/rafa.ts --target=bun --outfile=dist/cli.js && bun build src/index.ts src/plan/index.ts src/effort/store/index.ts src/ports/index.ts --target=bun --splitting --root=src --outdir=dist && cp src/PROMPT.md src/plan-prompt.md .claude/skills/dev-planner/SKILL.md dist/ && for tree in pr/plans:plans board/templates:templates; do src=src/${tree%:*}; out=dist/${tree#*:}; [ -d \"$src\" ] || continue; mkdir -p \"$out\" && cp \"$src\"/*.md \"$out\"/ || exit 1; done",
+    "prepack": "bun run build",
+    "test": "bun test",
+    "lint": "eslint .",
+    "check-types": "tsc --noEmit",
+    "gate:control-bytes": "bun scripts/control-byte-gate/control-byte-gate.ts",
+    "snapshot": "bun scripts/snapshot-runtime.ts"
+  },
+  "devDependencies": {
+    "@eslint/js": "^10.0.1",
+    "@eslint/markdown": "^8.0.3",
+    "@stylistic/eslint-plugin": "^5.10.0",
+    "@types/bun": "^1.4.0",
+    "@types/node": "^26.4.1",
+    "@typescript-eslint/parser": "^8.69.0",
+    "eslint": "^9.39.4",
+    "eslint-import-resolver-typescript": "^4.4.4",
+    "eslint-plugin-import": "^2.32.0",
+    "eslint-plugin-jsonc": "^3.4.2",
+    "globals": "^17.12.0",
+    "jsonc-eslint-parser": "^3.1.0",
+    "typescript": "^5.9.3",
+    "typescript-eslint": "^8.69.0"
+  }
+}