@hecer/yoke 1.11.0 → 1.12.0

package/dist/dashboard/discovery.js

@@ -1,73 +0,0 @@
-import { opendir, lstat, realpath } from 'node:fs/promises';
-import { delimiter, dirname, join, parse, resolve } from 'node:path';
-import { autoRegisterProject, listProjects } from './registry.js';
-const skip = new Set(['node_modules', 'vendor', 'dist', 'build', 'coverage', 'bench', 'fixtures']);
-export function discoveryRoots() {
-    const configured = process.env.YOKE_PROJECT_ROOTS?.split(delimiter).filter(Boolean);
-    const candidates = configured ?? [dirname(process.cwd()), ...listProjects().filter(p => !p.error).map(p => dirname(p.root))];
-    const roots = [...new Set(candidates.map(p => resolve(p)))].filter(p => p !== parse(p).root);
-    return roots.filter(p => !roots.some(other => other !== p && p.startsWith(other + (process.platform === 'win32' ? '\\' : '/'))));
-}
-/** Incremental traversal keeps directory IO out of the HTTP request path. */
-export function startProjectDiscovery(roots = discoveryRoots) {
-    let stopped = false;
-    let active;
-    let queue = [];
-    let visited = new Set();
-    let current;
-    const scan = async () => {
-        if (!queue.length && !current) {
-            queue = roots();
-            visited = new Set();
-        }
-        let budget = 500;
-        while (!stopped && budget-- > 0 && (current || queue.length)) {
-            if (!current) {
-                const path = queue.shift();
-                try {
-                    if ((await lstat(path)).isSymbolicLink())
-                        continue;
-                    const canonical = await realpath(path);
-                    const key = process.platform === 'win32' ? canonical.toLowerCase() : canonical;
-                    if (visited.has(key))
-                        continue;
-                    visited.add(key);
-                    autoRegisterProject(canonical);
-                    current = await opendir(canonical);
-                }
-                catch {
-                    continue;
-                }
-            }
-            try {
-                const entry = await current.read();
-                if (!entry) {
-                    await current.close();
-                    current = undefined;
-                    continue;
-                }
-                if (entry.isDirectory() && !entry.isSymbolicLink() && !entry.name.startsWith('.') && !skip.has(entry.name.toLowerCase()))
-                    queue.push(join(current.path, entry.name));
-            }
-            catch {
-                try {
-                    await current?.close();
-                }
-                catch { /* Already closed. */ }
-                current = undefined;
-            }
-        }
-    };
-    const tick = () => {
-        if (!active && !stopped)
-            active = scan().catch(() => { }).finally(() => { active = undefined; });
-        return active ?? Promise.resolve();
-    };
-    const timer = setInterval(() => { void tick(); }, 5000);
-    timer.unref();
-    void tick();
-    return { tick, get pending() { return queue.length + (current ? 1 : 0); }, async close() { stopped = true; clearInterval(timer); await active; try {
-            await current?.close();
-        }
-        catch { /* Already closed. */ } } };
-}

package/docs/community-outreach-2026-08-20.md

@@ -1,85 +0,0 @@
-# Yoke community outreach — 2026-08-20
-
-These posts are intentionally feedback-first. They disclose the creator relationship, avoid vote requests, and link directly to the free MIT-licensed project.
-
-## Hacker News — Show HN
-
-**Title**
-
-Show HN: Yoke – safety-gated autonomous coding loops for Claude, Codex, and Gemini
-
-**URL**
-
-https://github.com/HECer/yoke
-
-**First comment**
-
-Hi HN — I built Yoke after repeatedly seeing the same failure mode in long-running coding-agent loops: the agent says a task is done, but the tests were not actually run, the working tree is inconsistent, or a later iteration breaks earlier work.
-
-Yoke is an MIT-licensed TypeScript CLI that puts mechanical gates around those loops. A story only passes after the configured verification command succeeds, review approves it, and the commit lands. Stories run in isolated worktrees, and optional Playwright evidence can attach screenshots to acceptance criteria. It generates native project instructions for Claude Code, Codex CLI, and Gemini CLI from one canon rather than asking all three tools to interpret the same generic prompt.
-
-You can try it without signing up:
-
-    npm i -g @hecer/yoke
-    yoke new my-app
-
-I would especially value feedback from people who already run Ralph-style or overnight agent loops: which gate feels essential, which feels like ceremony, and what would stop you from trying this on a real repository?
-
-I am the creator and will be around to answer technical questions.
-
-## Reddit — r/ClaudeCodeTLDR weekly showcase (English)
-
-I built **Yoke**, a free MIT-licensed harness for running Claude Code, Codex CLI, or Gemini CLI in autonomous coding loops with mechanical safety gates.
-
-The problem I wanted to solve was the gap between an agent saying “done” and the repository actually being in a verified state. Yoke uses isolated worktrees and only marks a story complete after the configured tests pass, review approves it, and the commit lands. It can also require Playwright screenshot evidence for visual acceptance criteria.
-
-Claude Code was both a target runtime and part of the development/review workflow; the project also generates native instructions for Codex and Gemini from the same canon.
-
-It is free to use, requires no account, and the quickstart is:
-
-    npm i -g @hecer/yoke
-    yoke new my-app
-
-Repo: https://github.com/HECer/yoke
-
-I’m the creator. I’d love blunt feedback from people who already use long-running Claude Code loops: would these gates make you trust an overnight run more, or does the workflow look too heavy? If you try it, which part is confusing first?
-
-## Reddit — r/ChatGPTCoding self-promotion thread (English)
-
-I built **Yoke**, an MIT-licensed CLI for people using Claude Code, Codex CLI, or Gemini CLI for longer autonomous coding runs.
-
-Instead of trusting the agent’s “done” message, Yoke gates each story on a real verification command, review approval, and an atomic commit. It also isolates stories in worktrees and can collect Playwright screenshots as acceptance evidence.
-
-Install and try it without an account:
-
-    npm i -g @hecer/yoke
-    yoke new my-app
-
-https://github.com/HECer/yoke
-
-I’m the creator. I’m mainly looking for honest feedback: if you already run coding agents for more than one task at a time, what would make you try this, and what looks like unnecessary process?
-
-## German-language developer communities (draft for communities that explicitly permit project showcases)
-
-**Titel**
-
-Feedback gesucht: Yoke – abgesicherte autonome Coding-Loops für Claude, Codex und Gemini
-
-**Text**
-
-Ich habe **Yoke** gebaut, ein kostenloses, MIT-lizenziertes CLI für längere autonome Coding-Läufe mit Claude Code, Codex CLI oder Gemini CLI.
-
-Der Auslöser war die Lücke zwischen „der Agent sagt, er sei fertig“ und einem tatsächlich verifizierten Repository. Yoke markiert eine Story erst dann als erledigt, wenn der konfigurierte Test-/Verify-Befehl erfolgreich war, ein Review zugestimmt hat und der Commit sauber gelandet ist. Einzelne Stories laufen isoliert in Worktrees; für visuelle Akzeptanzkriterien können Playwright-Screenshots als Nachweis verlangt werden.
-
-Ausprobieren ohne Account:
-
-    npm i -g @hecer/yoke
-    yoke new meine-app
-
-Repo: https://github.com/HECer/yoke
-
-Ich bin der Entwickler des Projekts. Mich interessiert vor allem ehrliches Feedback von Leuten, die Coding-Agents länger oder autonom laufen lassen: Würden solche Gates euer Vertrauen erhöhen, oder wirkt der Ablauf zu schwergewichtig? Was wäre beim ersten Ausprobieren vermutlich die größte Hürde?
-
-## Disclosure note
-
-The outreach copy in this file was drafted with AI assistance on the creator's instructions. Add a human-readable AI-assistance disclosure wherever a community's rules require it; do not infer human authorship from the absence of machine-readable provenance.

package/docs/launch-copy-2026-08-21.md

@@ -1,193 +0,0 @@
-# Yoke launch copy
-
-## 1. Show HN
-
-### Title
-
-Show HN: Yoke – gated coding-agent loops for Claude, Codex, and Gemini
-
-### URL
-
-https://github.com/HECer/yoke
-
-### First comment
-
-I built Yoke after seeing coding agents report that a task was finished when the repository told a different story: tests had not run, the working tree contained unrelated changes, or a later iteration had broken earlier work.
-
-Yoke is an MIT-licensed TypeScript CLI for running coding-agent work as a sequence of verifiable stories. It supports Claude Code, Codex CLI, and Gemini CLI.
-
-The runner, rather than the agent, decides whether a story passed. It checks the configured verification command's exit code, requires review approval, and confirms that the commit landed. Stories run in isolated Git worktrees. For visual acceptance criteria, a run can require Playwright screenshots or video as evidence.
-
-Yoke also generates native project instructions for each supported agent from one versioned skill canon. That part is Markdown. The state transitions, worktree lifecycle, process supervision, gates, and run state are executable TypeScript.
-
-The closest comparison I know is WorkOS Case. Both projects treat the harness as the reliability boundary. Case is focused on turning GitHub or Linear issues into reviewed pull requests. Yoke includes greenfield and retrofit setup, PRD-to-story execution, and portable project configuration across three coding agents.
-
-You can try it without an account:
-
-    npm install -g @hecer/yoke
-    yoke new my-app
-
-I am looking for two kinds of feedback:
-
-1. Which gate would you remove because it adds more process than safety?
-2. What failure from a real autonomous run would Yoke still miss?
-
-I am the maintainer and will be around to answer questions.
-
-## 2. DEV Community (`#showdev`)
-
-### Title
-
-I moved coding-agent verification out of the prompt
-
-### Tags
-
-`showdev`, `ai`, `opensource`, `typescript`
-
-### Article
-
-A coding agent can agree to run the tests and still fail to run them. It can also run the wrong command, overlook a dirty working tree, or declare success before the result is committed.
-
-Adding another sentence to the prompt does not change who controls the completion decision. The same model doing the work still decides whether it followed the instruction.
-
-I built Yoke to put that decision in a TypeScript runner.
-
-Yoke executes work as a sequence of stories. For each story, the runner creates an isolated Git worktree, starts a fresh agent session, runs the configured verification command, requests a separate review, and checks that the resulting commit landed. A story is not marked as passed because the agent says it is done.
-
-For user-interface work, the acceptance criteria can require Playwright screenshots or video. The evidence belongs to the story instead of living in a chat transcript.
-
-Yoke supports Claude Code, Codex CLI, and Gemini CLI. A versioned canon generates the native instructions each agent expects, so a project can keep one methodology without pretending that all three tools use identical configuration formats.
-
-Some of Yoke is Markdown. The skills, policies, and project context should be readable and editable. The enforcement layer is code: process supervision, worktree isolation, persisted run state, verification exit codes, review gates, and commit checks.
-
-The closest existing project is WorkOS Case. Case uses a deterministic TypeScript pipeline to turn issues into reviewed pull requests with evidence. Yoke covers a somewhat different workflow: creating or retrofitting a project, converting a PRD into ordered stories, and running those stories across Claude, Codex, or Gemini. The projects share more philosophy than I realized when I first described Yoke, and I now call that out directly.
-
-Yoke is MIT-licensed and does not require an account.
-
-    npm install -g @hecer/yoke
-    yoke new my-app
-
-Repository: https://github.com/HECer/yoke
-
-I would value examples of failures that prompts and skills do not handle reliably. I am also interested in the opposite feedback: which Yoke gate feels unnecessary in normal development?
-
-Disclosure: I used AI assistance while drafting and editing this article. The product description and technical claims were checked against the repository by the maintainer.
-
-## 3. DevHunt
-
-### Name
-
-Yoke
-
-### Tagline
-
-Run coding agents with tests, review, and commit gates outside the model.
-
-### Short description
-
-Yoke is an MIT-licensed TypeScript CLI for autonomous coding loops with Claude Code, Codex CLI, and Gemini CLI. It runs stories in isolated Git worktrees and only records a pass after the configured verification command succeeds, review approves the change, and the commit lands. Visual stories can require Playwright screenshot or video evidence.
-
-### Maker comment
-
-I built Yoke because instructions such as “run the tests before finishing” leave the completion decision with the same agent doing the work. Yoke moves that decision into an executable runner.
-
-I would like feedback from developers who already run agents unattended: which gate earns its cost, and what would prevent you from using Yoke on an existing repository?
-
-Source: https://github.com/HECer/yoke
-
-## 4. Uneed
-
-### Title
-
-Yoke
-
-### Tagline
-
-A safety-gated coding harness for Claude, Codex, and Gemini.
-
-### Description
-
-Yoke runs autonomous coding work as verifiable stories. Each story gets an isolated Git worktree and must pass the project's real verification command, an independent review, and a commit check. User-interface stories can also require Playwright screenshots or video.
-
-The CLI can create a new project or retrofit an existing one. It generates native instructions for Claude Code, Codex CLI, and Gemini CLI from one versioned canon.
-
-Yoke is open source under the MIT license and requires no account.
-
-### Launch comment
-
-I am the maintainer. I am looking for concrete failure cases from people who use coding agents for long or unattended runs. If Yoke would not catch one of yours, please tell me what happened.
-
-https://github.com/HECer/yoke
-
-## 5. Product Hunt
-
-### Name
-
-Yoke
-
-### Tagline
-
-Mechanical safety gates for autonomous coding agents
-
-### Description
-
-Run Claude Code, Codex CLI, or Gemini CLI through isolated worktrees, real test commands, independent review, commit checks, and optional visual evidence. Open source and local-first.
-
-### First maker comment
-
-Hi Product Hunt,
-
-I built Yoke for developers who let coding agents work through more than one task at a time.
-
-The failure I wanted to address was straightforward: an agent could say that tests passed without giving the repository a reliable completion boundary. Yoke makes the runner responsible for that boundary. A story passes only after the configured verification command exits successfully, review approves the change, and the commit lands.
-
-Yoke supports Claude Code, Codex CLI, and Gemini CLI. It can bootstrap a new project or retrofit an existing repository, and it keeps stories isolated in Git worktrees.
-
-The project is MIT-licensed, runs locally, and requires no account:
-
-https://github.com/HECer/yoke
-
-I would appreciate feedback from anyone already running coding agents unattended. What evidence do you need before trusting the result?
-
-## 6. Peerlist Launchpad
-
-### Project summary
-
-Yoke is an open-source TypeScript CLI for running Claude Code, Codex CLI, and Gemini CLI with completion gates outside the model.
-
-It breaks a PRD into stories, runs each story in an isolated Git worktree, and checks the project's verification command, review result, and final commit before recording a pass. Visual acceptance criteria can require Playwright screenshots or video.
-
-I built it after finding that prompt-level instructions were useful guidance but a weak enforcement boundary for unattended work. The readable methodology lives in versioned Markdown; the enforcement lives in the runner.
-
-Try it:
-
-    npm install -g @hecer/yoke
-    yoke new my-app
-
-Source: https://github.com/HECer/yoke
-
-I am looking for developers willing to try it on an existing repository and report the first confusing or unnecessary step.
-
-## 7. Indie Hackers
-
-### Title
-
-I built a coding-agent harness, then learned that “it is just Markdown” was the right criticism to answer
-
-### Post
-
-I recently shared Yoke, an open-source harness for autonomous coding agents, and received a blunt question: why not encode the workflow in one skill or even one sentence?
-
-That criticism exposed a problem in how I described the project. The interesting part is not the workflow advice. Agents can read instructions telling them to plan, test, review, and commit.
-
-The product decision is who controls the pass condition.
-
-Yoke puts that condition in a TypeScript runner. It creates isolated worktrees, executes the configured verification command, requests review, checks the commit, and persists story state. The agent produces the change, but it cannot mark its own story as passed merely by saying the work is complete.
-
-The skills and policies are Markdown because users should be able to read and change them. If someone only needs those instructions, a skill is enough and Yoke is unnecessary.
-
-I also learned that WorkOS Case already takes a closely related approach. Case focuses on moving an issue through a multi-agent pipeline into a reviewed pull request. Yoke focuses on creating or retrofitting projects, turning PRDs into stories, and running them across Claude Code, Codex CLI, or Gemini CLI. I now describe that overlap directly instead of pretending the category is empty.
-
-The project is MIT-licensed: https://github.com/HECer/yoke
-
-My question for other builders is about scope. Would you keep the product narrow around enforced story completion, or is cross-agent project setup a meaningful part of the value?