Skip to content

feat: job registry — scalable job architecture #79

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jonit-dev merged 5 commits into from
Mar 12, 2026
Merged

feat: job registry — scalable job architecture #79

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
64be92e
feat: job registry — scalable job architecture (#75)
Mar 12, 2026
6199982
fix: remove unused Provider import in config.ts
Mar 12, 2026
79c1f6b
fix(job-registry): remove dead migrateLegacy code and fix DRY violati…
Mar 12, 2026
0feba5f
fixes
Mar 12, 2026
b289dce
chore: merge master into job-registry branch, resolve useStore conflict
Mar 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 20 additions & 16 deletions .github/prompts/pr-review.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ Review the pull request and produce one standardized markdown review comment.
The output must be concise, specific, and action-oriented. Avoid generic praise, nitpicks, or repeated points.

**Focus areas**

1. Code quality and maintainability
2. Functional correctness
3. Architecture and best practices
Expand All @@ -14,6 +15,7 @@ The output must be concise, specific, and action-oriented. Avoid generic praise,
8. Non-blocking issues worth tracking

**Critical rules**

- Use the exact section order and heading names defined below.
- Always include the score line exactly as `**🏆 Overall Score:** XX/100`.
- Keep the summary and conclusion short.
Expand All @@ -23,6 +25,7 @@ The output must be concise, specific, and action-oriented. Avoid generic praise,
- Do not output review boilerplate outside the required structure.

**Scoring guidance**

- 90-100: Exceptional quality, merge-ready with no meaningful concerns
- 75-89: Strong implementation with minor issues or follow-ups
- 60-74: Functional but has notable quality, correctness, or testing gaps
Expand All @@ -37,7 +40,7 @@ Use this exact structure:

**🏆 Overall Score:** XX/100

*1-2 sentence high-level summary of what the PR does and the overall quality assessment.*
_1-2 sentence high-level summary of what the PR does and the overall quality assessment._

---

Expand All @@ -63,27 +66,28 @@ If there are fewer than 3 real improvements, include only the meaningful ones.

Include this section only when you found at least one likely bug. Use this exact table shape:

| Bug Name | Affected Files | Description | Confidence |
|----------|---------------|-------------|------------|
| <bug name> | `<path>` | <why this is a bug and likely impact> | High 🟢 / Medium 🟡 / Low 🔴 |
| Bug Name | Affected Files | Description | Confidence |
| ---------- | -------------- | ------------------------------------- | ---------------------------- |
| <bug name> | `<path>` | <why this is a bug and likely impact> | High 🟢 / Medium 🟡 / Low 🔴 |

---

### **📋 Issues Found**

Include this section only when you found non-bug issues worth flagging, such as performance, testing, maintainability, or design concerns. Use this exact table shape:

| Issue Type | Issue Name | Affected Components | Description | Impact/Severity |
|------------|------------|---------------------|-------------|-----------------|
| Issue Type | Issue Name | Affected Components | Description | Impact/Severity |
| -------------------------------------------------- | ------------ | --------------------- | ------------------ | ------------------- |
| Performance / Testing / Maintainability / Security | <issue name> | `<component or file>` | <specific concern> | High / Medium / Low |

---

### **🔚 Conclusion**

*1-2 sentence conclusion on merge readiness, seriousness of findings, and whether fixes are required before merge.*
_1-2 sentence conclusion on merge readiness, seriousness of findings, and whether fixes are required before merge._

**Review quality bar**

- Prefer 2-3 substantial strengths and 0-3 meaningful improvements.
- Distinguish clearly between bugs and non-bug issues.
- Do not call something a bug unless there is a concrete failure mode.
Expand All @@ -95,7 +99,7 @@ Include this section only when you found non-bug issues worth flagging, such as

**🏆 Overall Score:** 85/100

*The PR implements a comprehensive feature with solid structure, good coverage, and only a few medium-priority follow-ups.*
_The PR implements a comprehensive feature with solid structure, good coverage, and only a few medium-priority follow-ups._

---

Expand All @@ -116,21 +120,21 @@ Include this section only when you found non-bug issues worth flagging, such as

### **🐛 Bugs Found**

| Bug Name | Affected Files | Description | Confidence |
|----------|---------------|-------------|------------|
| Example Integration Mismatch | `server/example.ts` | The endpoint path appears inconsistent with the client call, which could cause the integration to fail at runtime. | Medium 🟡 |
| Bug Name | Affected Files | Description | Confidence |
| ---------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------ | ---------- |
| Example Integration Mismatch | `server/example.ts` | The endpoint path appears inconsistent with the client call, which could cause the integration to fail at runtime. | Medium 🟡 |

---

### **📋 Issues Found**

| Issue Type | Issue Name | Affected Components | Description | Impact/Severity |
|------------|------------|---------------------|-------------|-----------------|
| Performance | Sequential Checks | `matching.service.ts` | Multiple serial queries are executed per item, which may increase latency at scale. | Medium |
| Testing | Fragile Mocks | `service.spec.ts` | Nested mocks make test setup hard to maintain and reason about. | Low |
| Issue Type | Issue Name | Affected Components | Description | Impact/Severity |
| ----------- | ----------------- | --------------------- | ----------------------------------------------------------------------------------- | --------------- |
| Performance | Sequential Checks | `matching.service.ts` | Multiple serial queries are executed per item, which may increase latency at scale. | Medium |
| Testing | Fragile Mocks | `service.spec.ts` | Nested mocks make test setup hard to maintain and reason about. | Low |

---

### **🔚 Conclusion**

*This is a strong PR with a clear structure and solid test coverage. The main follow-ups are manageable, but any real bugs identified should be addressed before merge.*
_This is a strong PR with a clear structure and solid test coverage. The main follow-ups are manageable, but any real bugs identified should be addressed before merge._
44 changes: 27 additions & 17 deletions docs/marketing/landing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,16 +38,20 @@ Marketing landing page for Night Watch CLI to convert visitors (developers, solo
### 2. Hero Section

**Headline (large, bold):**

> Your repo's night shift.

**Subheadline (slate-400, 1-2 lines max):**

> Define work during the day. Night Watch executes overnight. Wake up to pull requests, reviewed code, and tested features.

**CTA buttons:**

- Primary: `npm install -g @jonit-dev/night-watch-cli` (copyable code block styled as a button, click-to-copy)
- Secondary: "Read the docs" (ghost/outline button, links to docs)

**Below the fold teaser:**

- A single animated terminal recording (asciinema or typed.js simulation) showing:
```
$ night-watch init
Expand All @@ -63,11 +67,11 @@ Marketing landing page for Night Watch CLI to convert visitors (developers, solo

Three cards in a row, each with an icon, title, and 1-line description:

| Icon | Title | Description |
|------|-------|-------------|
| Moon/Clock | Async-first | Not pair-programming. Queued execution while you sleep. |
| GitBranch | Safe isolation | Every task runs in its own git worktree. Your main branch stays clean. |
| Eye/Shield | Human-in-the-loop | You review every PR. Configurable trust dials control auto-merge. |
| Icon | Title | Description |
| ---------- | ----------------- | ---------------------------------------------------------------------- |
| Moon/Clock | Async-first | Not pair-programming. Queued execution while you sleep. |
| GitBranch | Safe isolation | Every task runs in its own git worktree. Your main branch stays clean. |
| Eye/Shield | Human-in-the-loop | You review every PR. Configurable trust dials control auto-merge. |

### 4. How It Works (horizontal stepper or vertical timeline)

Expand All @@ -86,13 +90,13 @@ Four steps, each with a number, title, short description, and a small illustrati

Grid of 5 agent cards (2x3 or horizontal scroll on mobile). Each card:

| Agent | Role | Schedule hint |
|-------|------|---------------|
| Executor | Implements specs as code, opens PRs | Hourly |
| Reviewer | Scores PRs, requests fixes, auto-merges | Every 3 hours |
| QA | Generates and runs Playwright e2e tests | 4x daily |
| Auditor | Scans codebase for quality issues | Weekly |
| Slicer | Breaks roadmap items into granular specs | Every 6 hours |
| Agent | Role | Schedule hint |
| -------- | ---------------------------------------- | ------------- |
| Executor | Implements specs as code, opens PRs | Hourly |
| Reviewer | Scores PRs, requests fixes, auto-merges | Every 3 hours |
| QA | Generates and runs Playwright e2e tests | 4x daily |
| Auditor | Scans codebase for quality issues | Weekly |
| Slicer | Breaks roadmap items into granular specs | Every 6 hours |

Each card should have a subtle colored accent bar on top (different color per agent) and a small icon. On hover, show a brief example of what the agent outputs (e.g., Reviewer: "Score: 87/100 — ready to merge").

Expand All @@ -113,12 +117,14 @@ Each card should have a subtle colored accent bar on top (different color per ag
Two-column layout:

**Night Watch is strongest when:** (green checkmarks)

- You already use structured specs, PRDs, or queued board items
- You want async execution, not another pair-programming UI
- Your work can be broken into small, reviewable pull requests
- You care about overnight throughput on bounded tasks

**Night Watch is a weaker fit when:** (gray x-marks)

- Work starts vague and gets clarified only during implementation
- Your team is not comfortable reviewing AI-generated pull requests
- You want a general-purpose AI coding assistant
Expand Down Expand Up @@ -147,6 +153,7 @@ night-watch install # setup automated cron
```

Below the code block:

- Link: "5-minute walkthrough" (→ docs/walkthrough.md)
- Link: "Full docs" (→ docs/)
- Link: "Commands reference" (→ docs/commands.md)
Expand All @@ -155,11 +162,11 @@ Below the code block:

Small horizontal strip showing supported providers:

| Provider | Mode |
|----------|------|
| Claude CLI | Default, with rate-limit fallback |
| Codex CLI | Full support |
| GLM-5 / Custom endpoints | Via `providerEnv` config |
| Provider | Mode |
| ------------------------ | --------------------------------- |
| Claude CLI | Default, with rate-limit fallback |
| Codex CLI | Full support |
| GLM-5 / Custom endpoints | Via `providerEnv` config |

Caption: "Bring your own AI provider. Night Watch wraps the CLI — you stay in control of credentials and costs."

Expand Down Expand Up @@ -209,14 +216,17 @@ Caption: "Bring your own AI provider. Night Watch wraps the CLI — you stay in
## Copy Alternatives for Hero

Option A (current recommendation):

> **Your repo's night shift.**
> Define work during the day. Night Watch executes overnight. Wake up to pull requests.

Option B:

> **Ship while you sleep.**
> Night Watch turns your specs into reviewed pull requests — overnight, automatically, safely.

Option C:

> **Async PRD execution for AI-native teams.**
> Queue specs. Night Watch implements, reviews, tests, and opens PRs while you're offline.

Expand Down
32 changes: 21 additions & 11 deletions docs/marketing/naming-branding.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,12 +3,14 @@
## Name Decision: Keep "Night Watch CLI"

### Why It's Fine

- npm package is scoped (`@jonit-dev/night-watch-cli`) — no npm conflict
- CLI binary is `night-watch` — different from `nightwatch` (Nightwatch.js)
- Target audience finds the tool via GitHub, word-of-mouth, direct links — not by Googling "nightwatch"
- Search intent is completely different: testers find Nightwatch.js, developers automating spec execution find Night Watch CLI

### Nightwatch.js Overlap — Mitigated By

- Owning different keyword territory (see SEO section below)
- Scoped npm package
- Different CLI binary name
Expand All @@ -18,14 +20,17 @@
## GitHub Description

**Recommended:**

> Turn GitHub issues into pull requests automatically. AI agents that implement, review, and test your specs on a schedule.

**Alternatives considered:**

- `Async AI execution layer for spec-driven teams. Queue work, wake up to PRs.`
- `Cron-based AI coding agent. Specs in, pull requests out.`
- `AI agent that implements your specs, opens PRs, reviews code, and runs tests — on a schedule.`

**What was rejected and why:**

- "Semi-autonomous software engineering app factory" — "app factory" implies it builds entire apps; "semi-autonomous" hedges weakly
- "Autonomous PRD execution using AI Provider CLIs + cron" — too technical, not outcome-first

Expand All @@ -34,6 +39,7 @@
## SEO Strategy

### Keywords We Own (Nightwatch.js does NOT compete here)

- AI PR automation
- async coding agent
- PRD automation tool
Expand All @@ -44,6 +50,7 @@
- spec to PR automation

### Keywords to Avoid (Nightwatch.js dominates)

- nightwatch e2e
- nightwatch testing
- nightwatchjs
Expand All @@ -54,24 +61,27 @@
## Names Researched & Rejected

### Fully Available (domains + npm) — Rejected Alternatives
| Name | Reason rejected |
|------|----------------|
| sentinelcli | Good but loses brand continuity |
| nightcrew | Good vibe, weaker SEO |
| nightshift | Best alternative if rebrand needed |
| autohelm | Nautical metaphor, niche |
| repocrew | Clear but generic |
| cronpilot | Technical, not memorable |
| specforge | SEO-strong but cold |
| agentforge | Rides hype wave |

| Name | Reason rejected |
| ----------- | ---------------------------------- |
| sentinelcli | Good but loses brand continuity |
| nightcrew | Good vibe, weaker SEO |
| nightshift | Best alternative if rebrand needed |
| autohelm | Nautical metaphor, niche |
| repocrew | Clear but generic |
| cronpilot | Technical, not memorable |
| specforge | SEO-strong but cold |
| agentforge | Rides hype wave |

### Why "AgenticSwarmCLI" Was Rejected

- "Agentic" is overused buzzword, will age poorly
- "Swarm" implies chaos — opposite of the controlled, spec-driven philosophy
- No personality or memorability
- Describes *how* it works, not *what it does for you*
- Describes _how_ it works, not _what it does for you_

### Naming Principles Applied

- Outcome-first over mechanism-first
- Evocative metaphor > technical description
- Short, speakable, memorable
Expand Down
Loading
Loading