oh-my-pr 2.6.0 → 2.7.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/README.md +22 -4
  2. package/dist/index.cjs +138 -75
  3. package/package.json +1 -1
package/README.md CHANGED
@@ -1,4 +1,5 @@
1
- # Oh-my-PR
1
+ # Oh-my-PR
2
+ **This project is going to save you tons of time by automating the whole PR process.**
2
3
 
3
4
  **Local-first GitHub PR babysitter for Codex and Claude**
4
5
 
@@ -20,9 +21,19 @@ Oh-my-pr babysits your PRs from your local machine, reads all PR comments and CI
20
21
 
21
22
  - Watch multiple repositories or add a single PR by URL.
22
23
  - Auto-register open PRs, archive closed or merged PRs, and keep syncing review activity.
23
- - Evaluate review comments and failing CI statuses, post GitHub follow-ups, resolve review threads, and heal any CI failures.
24
- - Detect merge conflicts and let the agent resolve them automatically.
24
+ - Pause background automation for an individual tracked PR while keeping manual runs available.
25
+ - Store PR state, background jobs, questions, release runs, logs, and social changelogs in SQLite with mirrored log files.
26
+ - Queue repo sync, babysit/apply runs, PR questions, release processing, deployment healing, and social changelog generation in a durable SQLite-backed dispatcher that survives restarts.
27
+ - Triage feedback into `accept`, `reject`, or `flag`, with manual overrides and retry for failed or warned items.
28
+ - Run `codex` or `claude` in isolated worktrees under `~/.oh-my-pr`, then push verified fixes back to the PR branch.
29
+ - Evaluate review comments and failing CI statuses, post GitHub follow-ups, resolve review threads, and heal CI failures through persisted CI healing sessions per PR head.
30
+ - Monitor merged Vercel or Railway deployments, capture deployment logs on failure, and open follow-up `deploy-fix/*` PRs when deployment healing is enabled.
31
+ - Detect merge conflicts and optionally let the agent resolve them automatically.
25
32
  - Ask natural-language questions about any tracked PR from the dashboard or via MCP.
33
+ - Configure trusted reviewers, ignored bots, polling, batching, run limits, and CI-healing retry budgets from settings.
34
+ - Enable drain mode to stop claiming new queued work and optionally wait for active queue handlers to finish before deploys or upgrades.
35
+ - Check onboarding status, install Claude or Codex review workflows, and generate social changelogs every 5 PRs merged to `main`.
36
+ - Use the React dashboard, local REST API, MCP server, or optional Tauri desktop shell.
26
37
 
27
38
  ## How It Works
28
39
 
@@ -32,12 +43,18 @@ Oh-my-pr babysits your PRs from your local machine, reads all PR comments and CI
32
43
  4. Manual apply/babysit requests, PR questions, release processing, and social changelog generation go through the same durable queue before work executes in an app-owned repo cache and isolated git worktree under `~/.oh-my-pr`.
33
44
  5. The agent applies fixes, verifies the result, pushes to the PR branch, updates GitHub threads, and writes logs for the full run.
34
45
 
35
- Repo sync, babysit/apply, PR Q&A, release processing, and social changelog generation all run through durable background jobs stored in `state.sqlite`. On startup the dispatcher reclaims expired job leases, and interrupted babysitter runs are resumed from stored run context when possible.
46
+ Repo sync, babysit/apply, PR Q&A, release processing, deployment healing, and social changelog generation all run through durable background jobs stored in `state.sqlite`. On startup the dispatcher reclaims expired job leases, and interrupted babysitter runs are resumed from stored run context when possible.
36
47
 
37
48
  ## CI Healing
38
49
 
39
50
  When `Automatic CI healing` is enabled, Code Factory creates a healing session for each failing PR head SHA, classifies failures as safe to fix in-branch or blocked external, and runs bounded repair attempts in isolated worktrees. The dashboard surfaces the current session state and retry budget, and the local API exposes `GET /api/healing-sessions` plus `GET /api/healing-sessions/:id` for operator visibility.
40
51
 
52
+ ## Deployment Healing
53
+
54
+ When deployment healing is enabled through `PATCH /api/config`, Code Factory inspects merged PRs for supported deployment markers, waits for the post-merge deployment to appear, and polls the matching platform CLI for success or failure. On failure, it captures deployment logs, runs the configured agent from the merge commit in the app-owned repo cache, pushes a `deploy-fix/<platform>-<timestamp>` branch, and opens a follow-up PR against the merged base branch.
55
+
56
+ Deployment healing currently supports Vercel and Railway repositories detected from common repo-local config files. It requires the matching CLI in `PATH` and authenticated on the same machine running Code Factory. Session history is exposed through `GET /api/deployment-healing-sessions`, `GET /api/deployment-healing-sessions/:id`, and the matching MCP read tools.
57
+
41
58
  ## Quick Start
42
59
 
43
60
  ```bash
@@ -53,6 +70,7 @@ That's it. The dashboard opens in your browser at `http://localhost:5001`.
53
70
  - **git**
54
71
  - GitHub auth via `gh auth login`, `GITHUB_TOKEN`, app config, or a saved dashboard token
55
72
  - Either the `codex` CLI or `claude` CLI installed and authenticated locally
73
+ - Optional for deployment healing: the `vercel` CLI and/or `railway` CLI installed and authenticated for repositories you want to auto-heal after merge
56
74
 
57
75
  ### CLI Usage
58
76