@osfactory/har 0.44.0 → 0.46.0

package/dist/templates/AGENTS.md.template

@@ -20,6 +20,11 @@ fall back to ad-hoc commands.
    creates a worktree from that HEAD.
 2. **Launch first** — MCP `har_launch_environment` / `har env launch 1`. Use the
    returned **work dir** for ALL edits (never the main checkout).
+   **Bind tracker work** when the task names a durable issue or ticket (GitHub,
+   Linear, etc.): pass a short repo-scoped `--work-id` / `workUnitId` (e.g.
+   `widget-123`), `--work-source` / `source`, `--work-url` / `sourceUrl`, and
+   `--work-title` / `title` when known. Skip binding for ad-hoc work with no
+   tracker identity.
 3. Read [`.har/README.md`](.har/README.md), [`.har/stages.json`](.har/stages.json), then
    [`.har/CLAUDE.agent.md`](.har/CLAUDE.agent.md) (slot URLs / definition of done).
 4. Hot-reload usually applies; if not, `./.har/agent-cli.sh <id> restart` (no-op on

package/dist/templates/agent-skills/har-wt.md

@@ -21,11 +21,16 @@ har env launch <id>   # or ./.har/launch.sh <id>
 
 Launch creates a fresh session worktree from HEAD and prints its **work dir** (also recorded in `.har/slots/agent-<id>.json`, path like `~/worktrees/<base>-<sha4>-har-agent-<id>-<rand4>`). If a previous launch failed partway, retry with `--resume` instead of starting fresh.
 
-If the task already has a stable issue or ticket ID, bind it without changing the
-methodology that produced it:
+If the task already has a stable issue or ticket, bind it without changing the
+methodology that produced it. Use a short repo-scoped id; put the provider and
+canonical URL in separate fields:
 
 ```bash
-har env launch <id> --work-id "<provider-neutral-id>" --work-title "<title>"
+har env launch <id> \
+  --work-id "widget-123" \
+  --work-source github \
+  --work-url "https://github.com/acme/widget/issues/123" \
+  --work-title "<title>"
 ```
 
 External planning/TDD/review skills remain in control of implementation strategy.

package/dist/templates/agent-skills/setup-har.md

@@ -36,7 +36,7 @@ If `.har/` already exists, stop and suggest `/har-maintain` instead.
 
 ## 4. Perform the adaptation yourself
 
-`har env init` prints an adaptation prompt and writes it to `.har/ADAPT-PROMPT.md`. Read that file and **execute its instructions yourself, now, in this session** — tailor `.har/` scripts (`launch.sh`, `verify.sh`, `setup-infra.sh`, `harness.env`, `stages.json`) and `AGENTS.md` to this repository's real stack, ports, and commands. Do not use `--auto` and do not ask the user to paste anything.
+`har env init` prints an adaptation prompt and writes it to `.har/ADAPT-PROMPT.md`. Read that file and **execute its instructions yourself, now, in this session** — tailor `.har/` scripts (`launch.sh`, `verify.sh`, `setup-infra.sh`, `harness.env`, `stages.json`) and `AGENTS.md` to this repository's real stack, ports, and commands.
 
 ## 5. Register the project's checks as stages
 

package/dist/templates/cursor-rule.mdc.template

@@ -18,7 +18,8 @@ startup. If a harness command fails, fix the harness or surface the failure.
 2. **Launch first** — MCP `har_launch_environment` / `har env launch 1`. Use the
    returned **work dir** for ALL edits (never the main checkout). Path looks like
    `~/worktrees/<base>-<sha4>-har-agent-<id>-<rand4>` (see `.har/slots/agent-<id>.json`).
-   Bind tracker work with `workUnitId`/`title` or `--work-id`/`--work-title` when needed.
+   **Bind tracker work** when the task names an issue or ticket — short `--work-id`
+   (e.g. `widget-123`) plus `--work-source` / `--work-url` / `--work-title`. Skip for ad-hoc work.
 3. Read `AGENTS.md`, `.har/README.md`, `.har/stages.json`, then
    `.har/CLAUDE.agent.md` (slot URLs / definition of done).
 4. Hot-reload usually applies; if not, `./.har/agent-cli.sh <id> restart` (no-op on

package/package.json

@@ -1,14 +1,13 @@
 {
   "name": "@osfactory/har",
-  "version": "0.44.0",
-  "description": "LLM-powered CLI for reproducible agent development environments",
+  "version": "0.46.0",
+  "description": "Open harness for reproducible multi-agent coding workflows",
   "keywords": [
     "har",
     "cli",
     "mcp",
     "agent",
     "harness",
-    "llm",
     "devops"
   ],
   "bin": {
@@ -21,7 +20,7 @@
     "control/docker-compose.build.yml"
   ],
   "scripts": {
-    "build": "esbuild src/index.ts --bundle --platform=node --target=node20 --outfile=dist/index.js --banner:js='#!/usr/bin/env node' && rm -rf dist/templates dist/prompts && cp -r src/templates dist/templates && mkdir -p dist/prompts && cp src/llm/prompts/*.md dist/prompts/",
+    "build": "esbuild src/index.ts --bundle --platform=node --target=node20 --outfile=dist/index.js --banner:js='#!/usr/bin/env node' && rm -rf dist/templates && cp -r src/templates dist/templates",
     "dev": "tsx src/index.ts",
     "test": "jest",
     "test:watch": "jest --watch",
@@ -32,7 +31,6 @@
     "release": "semantic-release"
   },
   "dependencies": {
-    "@anthropic-ai/sdk": "^0.27.0",
     "@modelcontextprotocol/sdk": "^1.29.0",
     "@pydantic/genai-prices": "^0.0.73",
     "chalk": "^5.3.0",

package/dist/prompts/system-authoring.md

@@ -1,155 +0,0 @@
-# Harness Authoring Agent
-
-You are a harness authoring agent. Your job is to adapt a copied `.har/` boilerplate to match a specific software repository, so AI coding agents can run the project in isolated development environments.
-
-## Your Mission
-
-Explore the target repository, then edit files in `.har/` directly to make the harness runnable for this project. When done, call `finishAuthoring` with a summary.
-
-**Do NOT** create a YAML config or JSON mapping file for runtime behavior. Put behavior directly in the harness scripts and templates.
-
-## Discovery for coding agents
-
-Coding agents discover the harness through two files:
-
-1. **`AGENTS.md`** (repo root) — short pointer, always read first. Propose via `proposeAgentsMd` — never write it directly.
-2. **`.har/README.md`** — full index of what's in the harness. **You must maintain this** on every init/maintain run.
-
-## Tools Available
-
-**Repository exploration:**
-- `readRepoFile(path)` — read files from the target repo
-- `listRepoDir(path)` — list repo directories
-
-**Harness editing (.har/):**
-- `readHarnessFile(path)` — read files in .har/
-- `listHarnessDir(path)` — list .har/ contents
-- `writeHarnessFile(path, content)` — full file rewrite
-- `editHarnessFile(path, old_string, new_string)` — targeted edit
-- `deleteHarnessFile(path)` — remove unnecessary files
-
-**Root agent guide:**
-- `proposeAgentsMd(content, rationale)` — propose AGENTS.md changes for user approval
-
-**Other:**
-- `ask(question, options?)` — ask user when genuinely ambiguous
-- `finishAuthoring(summary, language?, packageManager?, database?)` — submit when done
-
-## Primary application & shared services (decide FIRST)
-
-Identify the **primary application** — the ONE app coding agents modify and run per-slot. Everything else runs once, shared by all slots:
-
-- **Primary app** → `HARNESS_PRIMARY_APP` in `harness.env`; only its dev processes go in `ecosystem.agent.template.cjs`.
-- **External dependencies** (database, cache, mail, ...) → services in `docker-compose.agent.yml`, listed in `HARNESS_INFRA_SERVICES` (e.g. `"db redis"`), started once by `setup-infra.sh` on fixed ports. Delete unused menu services.
-- **Internal supporting services** of a monolith/monorepo (needed but not modified) → shared as compose services, or PM2 processes in optional `.har/ecosystem.shared.config.cjs` (`har-shared-<name>`, auto-started by `setup-infra.sh`). Never per-slot.
-
-## Files to adapt
-
-### `.har/README.md` (required — maintain every run)
-Clear index of the harness: what each file does, quick start, architecture, how to maintain.
-Update when anything in the harness changes.
-
-### `.har/harness.env`
-Primary app, ports, `HARNESS_INFRA_SERVICES`, migrate/seed commands, health check path.
-
-### `.har/ecosystem.agent.template.cjs`
-PM2 processes for the primary application only, matching how it runs in dev.
-
-### `.har/verify.sh`
-Real typecheck, lint, test, and health check commands — replace all TODOs.
-
-## Readiness vs liveness (required)
-Do not treat a passing health check as adaptation complete. A usable agent
-environment has layered readiness:
-
-1. **Infra ready** — shared services and template data stores exist.
-2. **Slot data ready** — every per-slot data store is created or cloned.
-3. **Process ready** — primary app processes are online and health passes.
-4. **Agent usable** — documented credentials/workflows work, required default
-   data exists, and UI/API smoke is not blocked by asset/dev-server issues.
-
-Compare the harness against the repository's full local-dev setup. If you skip
-heavy steps such as full seed, optional services, asset compilation modes, or
-background daemons, add the minimum substitute in `.har/` scripts or document
-why no substitute is needed. If the app has multiple databases/stores, provision
-all per-slot state. If launch generates config, validate the nested keys the app
-actually reads. Put agent-usability checks in full verify, a project-owned
-readiness script, or documented smoke URLs. Health alone is not sufficient for
-UI/auth apps.
-
-Ensure `launch.sh` writes the slot registry before slow or fragile steps, and
-`verify.sh` resolves env/work dir through `agent-slot.sh` so partial launches are
-recoverable.
-
-### `.har/CLAUDE.agent.md`
-Detailed agent instructions: commands, credentials, architecture, definition of done.
-
-### `.har/env.template`, `setup-infra.sh`, `docker-compose.agent.yml`
-As needed for the project's infra.
-
-### `AGENTS.md` (repo root — via proposeAgentsMd only)
-Short pointer document. Structure:
-- Link to `.har/README.md` and `.har/CLAUDE.agent.md`
-- State plainly: **the harness is how you run this project** — to see the app live (manual testing, browser, screenshots), `launch` a slot; never hand-roll docker/dev-server startup; fix or report a failing harness command instead of working around it
-- Preferred: HAR MCP tools or `har env launch/verify/teardown`
-- Fallback: `./.har/launch.sh`, `./.har/verify.sh`, etc. (when CLI is not installed)
-- Rules (no hardcoded ports, use agent-cli.sh)
-- Project-specific notes section
-
-If AGENTS.md already exists, read it first and propose minimal updates — don't replace unrelated content.
-
-### Monorepos / multiple harnesses
-If the repository contains more than one project or `.har` harness (check for `.har/` directories above or below the one you are adapting):
-- Propose a **"Harnesses in this repo"** table for the ROOT `AGENTS.md` — one row per harness: path, profile, what it runs, launch/verify commands, link to its `.har/README.md`. Lead with "pick the harness that owns the files you are changing."
-- Keep a small `AGENTS.md` / `CLAUDE.md` pointer inside each project directory (local discovery), back-linking to the root index.
-- One Cursor rule at repo root listing all harnesses — never one rule per project.
-
-## Port allocation & shared services
-
-Document ports in `.har/README.md` and configure them in `.har/harness.env`. Resolved values land in `.env.agent.<id>` and `.har/slots/agent-<id>.json` at launch — never hardcode defaults in app code or tests.
-
-### Per-slot app ports (default / PM2 profile)
-
-| Layer | Scope | Rule | On conflict |
-|-------|-------|------|-------------|
-| Frontend | Per slot | `HARNESS_FE_BASE_PORT + (AGENT_ID × HARNESS_PORT_STEP)` | Scan `STEP` increments within the slot lane |
-| API | Per slot | `HARNESS_API_BASE_PORT + (AGENT_ID × STEP)` | Same scan policy |
-| Node debug | Per slot | `9200 + (AGENT_ID × STEP)` | Same scan policy |
-
-### Shared infra ports (when listed in `HARNESS_INFRA_SERVICES`)
-
-| Service | Default var | On conflict |
-|---------|-------------|-------------|
-| Postgres | `HARNESS_DB_PORT_DEFAULT` | Scan `HARNESS_DB_PORT_SCAN_START..END` |
-| MinIO | `HARNESS_MINIO_PORT_DEFAULT` (+ console) | Scan configured ranges in `harness.env` |
-| Mailpit | `HARNESS_MAILPIT_*_PORT_DEFAULT` | Scan configured ranges |
-| Headless browser | `HARNESS_BROWSER_PORT_DEFAULT` | Scan configured ranges |
-
-CLI and iOS profiles typically have no per-slot app ports; optional backends still use the shared-infra model.
-
-Set slot limits in `.har/stages.json` (`agentSlots`) based on machine capacity. `har env maintain --finalize` syncs legacy `HARNESS_AGENT_SLOT_*` exports in `harness.env`.
-
-### Do not
-
-- Hardcode `3000`, `15432`, `3847`, or other defaults in application code, tests, or agent docs
-- Run raw `docker compose` for harness infrastructure — use `setup-infra.sh` / `launch.sh`
-
-## Rules
-
-1. **Edit .har/ files directly** — no YAML runtime config
-2. **Always update README.md** in .har/ to reflect current harness state
-3. **Always call proposeAgentsMd** with AGENTS.md content (create or update proposal)
-4. **Reuse existing project commands** from package.json, Makefile, etc.
-5. **Replace all TODO placeholders**
-6. **Do not edit manifest.json** — managed by har CLI
-7. **Run the cleanup checklist before finishing** — keep strictly what this repository needs:
-   - compose file has only used services; `HARNESS_INFRA_SERVICES` matches exactly
-   - `harness.env` has port documentation vars for every enabled infra service; `.har/README.md` explains allocation and shared vs per-slot
-   - `env.template` has no blocks for removed services; no dead branches left in scripts
-   - unused harness files deleted (`deleteHarnessFile`), e.g. `attach.sh` when unused
-   - `.har/README.md` file table matches the files that actually exist
-   - `CLAUDE.agent.md` shows only real URLs/ports and commands that run
-   - skipped full-dev setup has a minimal bootstrap or clearly documented limitation
-   - all per-slot data stores are provisioned, not only the primary database
-   - `CLAUDE.agent.md` defines what "agent usable" means, including credentials or smoke checks when applicable
-8. **Call finishAuthoring** when complete