@htechcs/harness-kit 0.1.0 → 0.1.1

package/templates/long-running/README.md

@@ -1,48 +1,49 @@
-# Long-running — việc kéo dài quá một session (Mức 4)
+# Long-running — work that spans more than one session (Level 4)
 
-Mức 4 giữ agent làm việc *đáng tin* trên thứ dài hơi: refactor nhiều ngày, migration lớn,
-agent chạy nền hàng giờ. Việc dài chết vì 3 thứ — mỗi file ở đây chặn một thứ.
+Level 4 keeps the agent working *reliably* on long-horizon work: multi-day refactors, big migrations,
+an agent running in the background for hours. Long work dies from 3 things — each file here blocks one.
 
-## 3 file, 3 vấn đề
+## 3 files, 3 problems
 
-| File | Chặn cái chết nào |
-|------|-------------------|
-| [`setup.sh`](../setup.sh) | Không về được trạng thái chạy-được (clone/agent mới không biết cài gì) |
-| [`TASK.md`](./TASK.md) | Mất trạng thái qua session / sau `/clear` |
-| [`new-worktree.sh`](../new-worktree.sh) | Nhiều task song song giẫm chân nhau |
+| File | Which death it blocks |
+|------|-----------------------|
+| [`setup.sh`](../setup.sh) | Can't get back to a runnable state (a fresh clone/agent doesn't know what to install) |
+| [`TASK.md`](./TASK.md) | State lost across sessions / after `/clear` |
+| [`new-worktree.sh`](../new-worktree.sh) | Parallel tasks step on each other |
 
-## Cài đặt
+## Install
 
 ```bash
-cp setup.sh new-worktree.sh .          # vào root repo
+cp setup.sh new-worktree.sh .          # into the repo root
 chmod +x setup.sh new-worktree.sh
-cp long-running/TASK.md .              # khi bắt đầu một việc dài cụ thể
+cp long-running/TASK.md .              # when you start a specific long task
 ```
 
-Rồi **trỏ `CLAUDE.md`** vào chúng để agent biết dùng:
+Then **point `CLAUDE.md`** at them so the agent knows to use them:
 
 ```md
 ## Build / Test / Run
-- Dựng môi trường: ./setup.sh   (idempotent — chạy lại an toàn)
+- Set up the environment: ./setup.sh   (idempotent — safe to re-run)
 
 ## Long-running
-- Việc dài đang chạy ghi ở TASK.md — đọc trước khi bắt đầu, cập nhật khi tới mốc.
+- An in-flight long task is tracked in TASK.md — read it before starting, update it at milestones.
 ```
 
-## Khi nào dùng cái nào (đây là phần discipline)
+## When to use which (this is the discipline part)
 
-File chỉ là công cụ — biết *khi nào* rút ra mới là kỹ năng:
+The files are just tools — knowing *when* to reach for them is the skill:
 
-- **`setup.sh`** — chạy ngay khi vào checkout mới, và bất cứ khi nào nghi môi trường lệch.
-  Giữ nó **idempotent + fail-fast**: agent nền phải dựng lại được mà không cần hỏi.
-- **`TASK.md`** — mở ra khi việc *sẽ vắt qua nhiều session* hoặc bạn sắp `/clear`. Cập nhật ở
-  **mốc** (xong một phần, chốt một quyết định), không phải mỗi dòng code. Nó là thứ agent kế
-  tiếp đọc để tiếp tục — viết cho "người lạ" hiểu, không viết tốc ký cho riêng mình.
-- **`new-worktree.sh`** — tách worktree khi chạy **≥2 hướng song song**, hoặc khi một task dài
-  cần cô lập khỏi nhánh chính. Một task = một worktree. Xong: `git worktree remove <dir>`.
+- **`setup.sh`** — run it the moment you enter a fresh checkout, and whenever you suspect the
+  environment drifted. Keep it **idempotent + fail-fast**: a background agent must be able to rebuild
+  it without asking.
+- **`TASK.md`** — open it when the work *will span multiple sessions* or you're about to `/clear`.
+  Update it at **milestones** (a part done, a decision locked), not every line of code. It's what the
+  next agent reads to continue — write it so a "stranger" understands, not as shorthand for yourself.
+- **`new-worktree.sh`** — split off a worktree when running **2+ directions in parallel**, or when a
+  long task needs isolation from the main branch. One task = one worktree. Done: `git worktree remove <dir>`.
 
-## Chạy nền & quay lại kiểm
+## Running in the background & checking back
 
-Việc thật dài có thể chạy ở background rồi quay lại xem (không ngồi canh). Nguyên tắc:
-khúc việc phải **resume được** — nếu đứt giữa chừng, `TASK.md` + `setup.sh` đủ để bắt lại từ
-mốc gần nhất, không phải làm lại từ đầu. Đó là lý do hai file kia tồn tại.
+Genuinely long work can run in the background while you check back (no babysitting). The principle:
+a chunk of work must be **resumable** — if it's cut off mid-way, `TASK.md` + `setup.sh` are enough to
+pick up from the latest milestone instead of starting over. That's why those two files exist.

package/templates/long-running/TASK.md

@@ -1,33 +1,33 @@
 <!--
-TASK.md — bộ nhớ sống sót của một việc dài (Mức 4).
+TASK.md — the memory that survives a long task (Level 4).
 
-Việc kéo dài quá một session sẽ mất trạng thái khi `/clear` hoặc khi mở session mới.
-File này là nơi agent (và agent kế tiếp) đọc để TIẾP TỤC, thay vì dựng lại từ đầu.
+Work that spans more than one session loses its state on `/clear` or when a new session opens.
+This file is where the agent (and the next agent) reads to CONTINUE, instead of rebuilding from scratch.
 
-Cách dùng:
-  - Đặt ở root repo hoặc thư mục task. Cập nhật KHI có mốc đáng nhớ, không cập nhật mỗi dòng.
-  - Trỏ CLAUDE.md tới nó: "Việc dài đang chạy ghi ở TASK.md — đọc trước khi bắt đầu."
-  - Xong việc thì xoá / archive, đừng để TASK.md cũ làm nhiễu.
-Xoá phần comment này khi bắt đầu dùng thật.
+How to use:
+  - Put it at the repo root or the task folder. Update it AT milestones, not every line.
+  - Point CLAUDE.md at it: "An in-flight long task is tracked in TASK.md — read it before starting."
+  - When the work is done, delete / archive it; don't let a stale TASK.md add noise.
+Delete this comment when you start using it for real.
 -->
 
-# Task: <một dòng — đang làm gì>
+# Task: <one line — what you're doing>
 
-## Mục tiêu
-<Định nghĩa "xong" đo được. Việc này coi là hoàn thành khi nào?>
+## Goal
+<A measurable definition of "done". When is this task complete?>
 
-## Đang ở đâu (cập nhật mỗi mốc)
-<Trạng thái hiện tại trong 2–4 gạch đầu dòng. Cái gì đã chạy được, cái gì chưa.>
+## Where things stand (update at each milestone)
+<Current state in 2–4 bullets. What already works, what doesn't yet.>
 - 
 
-## Bước tiếp theo
-<Hành động cụ thể kế tiếp, đủ rõ để bắt tay ngay mà không phải nghĩ lại.>
+## Next steps
+<The concrete next action, clear enough to start immediately without re-thinking.>
 - [ ] 
 
-## Quyết định đã chốt (đừng mở lại)
-<Lựa chọn đã quyết + LÝ DO ngắn. Để agent sau không bàn lại từ đầu.>
+## Decisions locked (don't reopen)
+<Choices already made + a short WHY. So the next agent doesn't re-litigate from scratch.>
 - 
 
-## Cạm bẫy đã gặp
-<Thứ đã thử mà hỏng, ngõ cụt — để khỏi đâm lại.>
+## Pitfalls hit
+<Things tried that failed, dead ends — so you don't walk into them again.>
 - 

package/templates/mcp-audit.md

@@ -1,26 +1,26 @@
-# MCP hygiene — checklist dọn tool thừa (Mức 2)
+# MCP hygiene — a checklist for pruning surplus tools (Level 2)
 
-Mỗi MCP server bạn cắm sẽ **bơm toàn bộ định nghĩa tool của nó vào context ở MỌI lượt** —
-dù lượt đó không dùng tới. 5 server ít dùng có thể ngốn hàng nghìn token mỗi lượt và làm
-model "rối tay" khi chọn tool. Đây là **thuế context vĩnh viễn**, không phải vấn đề an toàn
-(an toàn là Mức 3).
+Every MCP server you plug in **injects all of its tool definitions into context on EVERY turn** —
+even turns that don't use it. Five rarely-used servers can eat thousands of tokens per turn and
+make the model "fumble" when choosing a tool. This is a **permanent context tax**, not a safety
+issue (safety is Level 3).
 
-## Cách xem đang cắm những gì
+## See what's plugged in
 
 ```bash
-claude mcp list        # liệt kê MCP server đang cấu hình
+claude mcp list        # list the configured MCP servers
 ```
 
-## Với MỖI server, hỏi 3 câu
+## For EACH server, ask 3 questions
 
-- [ ] **Tháng qua có thực sự gọi tool của nó không?** Không → gỡ.
-- [ ] **Nó thêm bao nhiêu tool vào mỗi lượt, mà bạn chỉ dùng 1–2?** Thừa nhiều → gỡ hoặc tìm bản gọn hơn.
-- [ ] **Có thể thay bằng CLI sẵn có không?** (vd `gh` thay vì MCP GitHub cho việc đơn giản) → ưu tiên CLI, gỡ MCP.
+- [ ] **Did you actually call its tools in the past month?** No → remove it.
+- [ ] **How many tools does it add per turn when you only use 1–2?** Lots of surplus → remove it or find a leaner build.
+- [ ] **Can an existing CLI replace it?** (e.g. `gh` instead of a GitHub MCP for simple things) → prefer the CLI, drop the MCP.
 
-## Nguyên tắc
+## Principle
 
-> **Tool ít mà rõ > nhiều tool chồng chéo.** Giữ đúng cái bạn dùng hằng tuần.
-> Cắm thêm khi *thật sự* cần một nguồn/khả năng mới, không cắm "để sẵn cho chắc".
+> **Few clear tools > many overlapping ones.** Keep exactly what you use weekly.
+> Add more only when you *genuinely* need a new source/capability, not "just in case".
 
-Cắm MCP "để sẵn cho chắc" là cái bẫy phổ biến nhất ở Mức 2: nó âm thầm làm mọi session
-đắt hơn và kém chính xác hơn, mà không ai để ý.
+Plugging in an MCP "just in case" is the most common Level 2 trap: it quietly makes every session
+more expensive and less accurate, without anyone noticing.

package/templates/new-worktree.sh

@@ -1,35 +1,35 @@
 #!/usr/bin/env bash
-# new-worktree.sh — tạo một git worktree + branch riêng cho một task song song/dài.
+# new-worktree.sh — create a git worktree + its own branch for a parallel/long task.
 #
-# Mức 4 (long-running): mỗi task nặng nên có cây làm việc RIÊNG, để chạy song song
-# mà không giẫm chân (không stash/switch liên tục, không sửa đè lên nhau).
+# Level 4 (long-running): each heavy task should have its OWN working tree, so parallel runs
+# don't step on each other (no constant stash/switch, no overwriting each other's edits).
 #
-# Dùng:   ./new-worktree.sh <tên-task>
-# Vd:     ./new-worktree.sh refactor-auth
-#   -> tạo branch 'refactor-auth' + thư mục ../<repo>-refactor-auth (cạnh repo, KHÔNG lồng trong).
+# Usage:  ./new-worktree.sh <task-name>
+# E.g.:   ./new-worktree.sh refactor-auth
+#   -> creates branch 'refactor-auth' + dir ../<repo>-refactor-auth (NEXT TO the repo, not nested).
 
 set -euo pipefail
 
 name="${1:-}"
-[ -n "$name" ] || { echo "dùng: $0 <tên-task>   (vd: refactor-auth)"; exit 1; }
+[ -n "$name" ] || { echo "usage: $0 <task-name>   (e.g. refactor-auth)"; exit 1; }
 
-# Phải đứng trong một git repo.
-git rev-parse --is-inside-work-tree >/dev/null 2>&1 || { echo "✗ không phải git repo"; exit 1; }
+# Must be inside a git repo.
+git rev-parse --is-inside-work-tree >/dev/null 2>&1 || { echo "not a git repo"; exit 1; }
 
 root="$(git rev-parse --show-toplevel)"
 repo="$(basename "$root")"
-dir="$root/../${repo}-${name}"          # đặt CẠNH repo, không lồng -> git status không nhiễu
+dir="$root/../${repo}-${name}"          # place it NEXT TO the repo, not nested -> git status stays clean
 
-[ -e "$dir" ] && { echo "✗ đã tồn tại: $dir"; exit 1; }   # fail-fast, không ghi đè
+[ -e "$dir" ] && { echo "already exists: $dir"; exit 1; }   # fail-fast, don't overwrite
 
-# Tách từ base mới nhất. Đổi 'main' nếu repo bạn dùng tên khác.
+# Branch from the latest base. Change 'main' if your repo uses a different name.
 base="$(git symbolic-ref --quiet --short HEAD || echo main)"
 
 if git show-ref --verify --quiet "refs/heads/${name}"; then
-  git worktree add "$dir" "$name"            # branch đã có -> checkout vào worktree mới
+  git worktree add "$dir" "$name"            # branch exists -> check it out into the new worktree
 else
-  git worktree add -b "$name" "$dir" "$base" # branch mới tách từ base hiện tại
+  git worktree add -b "$name" "$dir" "$base" # new branch from the current base
 fi
 
-echo "✓ worktree: $dir   (branch: $name)"
-echo "  cd \"$dir\" để bắt đầu. Xong việc: git worktree remove \"$dir\""
+echo "worktree: $dir   (branch: $name)"
+echo "  cd \"$dir\" to start. When done: git worktree remove \"$dir\""

package/templates/setup.sh

@@ -1,51 +1,51 @@
 #!/usr/bin/env bash
-# setup.sh — bootstrap môi trường: "một lệnh là repo chạy được".
+# setup.sh — environment bootstrap: "one command makes the repo runnable".
 #
-# Mức 4 (long-running): agent chạy nền/lặp KHÔNG thể dừng hỏi "cài gì giờ".
-# Script này phải đưa một checkout sạch về trạng thái chạy-được, không cần tương tác.
+# Level 4 (long-running): a background/looping agent CANNOT stop to ask "what do I install now".
+# This script must bring a clean checkout to a runnable state, non-interactively.
 #
-# 2 nguyên tắc bắt buộc:
-#   - IDEMPOTENT: chạy lại nhiều lần vẫn an toàn (không nhân đôi, không hỏng state).
-#   - FAIL-FAST:  thiếu thứ gì báo NGAY rồi dừng, đừng chạy tiếp trong trạng thái mù.
+# 2 mandatory principles:
+#   - IDEMPOTENT: safe to run many times (no duplication, no broken state).
+#   - FAIL-FAST:  if something is missing, report it NOW and stop; don't continue blind.
 #
-# ĐÂY LÀ SKELETON — mỗi repo cài thứ khác nhau. Điền phần TODO cho repo của bạn,
-# rồi trỏ CLAUDE.md tới đây ("Build / Test / Run: chạy ./setup.sh trước").
+# THIS IS A SKELETON — every repo installs different things. Fill in the TODOs for your repo,
+# then point CLAUDE.md here ("Build / Test / Run: run ./setup.sh first").
 
-set -euo pipefail   # lỗi -> dừng; biến chưa set -> dừng; lỗi giữa pipe -> dừng
+set -euo pipefail   # error -> stop; unset var -> stop; mid-pipe error -> stop
 
 cd "$(dirname "$0")"
 
-# --- 1. Kiểm điều kiện cần (fail-fast) -------------------------------------
-# Thiếu tool nền là báo ngay, đừng để lỗi mơ hồ ở bước sau.
+# --- 1. Check prerequisites (fail-fast) ------------------------------------
+# Missing base tools are reported immediately; don't let a vague error surface later.
 require() {
-  command -v "$1" >/dev/null 2>&1 || { echo "✗ thiếu '$1' — cài rồi chạy lại"; exit 1; }
+  command -v "$1" >/dev/null 2>&1 || { echo "missing '$1' — install it then re-run"; exit 1; }
 }
-# TODO: liệt kê tool repo bạn cần
+# TODO: list the tools your repo needs
 require git
 # require node
 # require python3
 
-# --- 2. Cài dependencies (idempotent) --------------------------------------
-# Hầu hết package manager đã idempotent sẵn — chạy lại chỉ no-op.
-# TODO: thay bằng lệnh của repo bạn
+# --- 2. Install dependencies (idempotent) ----------------------------------
+# Most package managers are already idempotent — re-running is a no-op.
+# TODO: replace with your repo's commands
 # npm ci
 # uv sync
 # go mod download
 
-# --- 3. Cấu hình / secrets (fail-fast, KHÔNG tự tạo bừa) --------------------
-# Có .env.example mà chưa có .env -> báo cho người chạy tự điền, đừng đoán giá trị.
+# --- 3. Config / secrets (fail-fast, do NOT invent values) -----------------
+# If .env.example exists but .env doesn't -> tell the runner to fill it in; don't guess values.
 # if [ -f .env.example ] && [ ! -f .env ]; then
-#   echo "✗ chưa có .env — copy .env.example rồi điền secrets"; exit 1
+#   echo "no .env yet — copy .env.example and fill in the secrets"; exit 1
 # fi
 
-# --- 4. Dịch vụ phụ trợ (idempotent) ---------------------------------------
-# TODO: DB/queue... — dùng lệnh chỉ-tạo-nếu-chưa-có
+# --- 4. Supporting services (idempotent) -----------------------------------
+# TODO: DB/queue... — use create-only-if-missing commands
 # docker compose up -d
 
-# --- 5. Verify: chứng minh môi trường thật sự chạy được --------------------
-# Đừng kết thúc bằng "xong" mù — chạy một check rẻ để chắc chắn.
-# TODO: lệnh smoke-test nhanh nhất của repo
+# --- 5. Verify: prove the environment actually runs ------------------------
+# Don't end with a blind "done" — run one cheap check to be sure.
+# TODO: your repo's fastest smoke test
 # npm run build --silent
 # python -c "import yourpkg"
 
-echo "✓ môi trường sẵn sàng"
+echo "environment ready"

package/templates/spec/FEATURE.md

@@ -1,40 +1,40 @@
 <!--
-FEATURE.md — spec một feature TRƯỚC khi viết code (spec-driven development).
+FEATURE.md — spec one feature BEFORE writing code (spec-driven development).
 
-Đây là nửa "Specs" của trụ cột "Repo-local instructions & Specs": CLAUDE.md (Mức 1) lo luật bền
-xuyên MỌI task; FEATURE.md lo định nghĩa MỘT feature cụ thể trước khi bắt tay. Spec rõ → agent
-chạy đúng hướng, ít lạc; acceptance criteria rõ → có cái để eval (Mức 5) chấm đậu/rớt.
+This is the "Specs" half of the "Repo-local instructions & Specs" pillar: CLAUDE.md (Level 1) covers
+durable rules across EVERY task; FEATURE.md defines ONE specific feature before you start. A clear spec
+→ the agent runs in the right direction; clear acceptance criteria → something a Level 5 eval can grade.
 
-Cách dùng: copy cho mỗi feature đáng-kể (vd docs/specs/<feature>.md). Việc nhỏ thì bỏ qua —
-đừng nghi thức hoá. Điền đủ phần, xoá comment này khi dùng thật.
+How to use: copy it per significant feature (e.g. docs/specs/<feature>.md). Skip small jobs — don't
+ritualize it. Fill in the sections, delete this comment when you use it for real.
 -->
 
-# Feature: <tên ngắn gọn>
+# Feature: <short name>
 
-## Vấn đề / vì sao
-<Giải quyết cái gì cho ai. 1–3 câu. Nếu không nói rõ được "vì sao", khoan code.>
+## Problem / why
+<What it solves and for whom. 1–3 sentences. If you can't state the "why", don't code yet.>
 
-## Phạm vi
+## Scope
 
-### Trong phạm vi
+### In scope
 - 
 
-### NGOÀI phạm vi (quan trọng — chặn scope creep)
+### OUT of scope (important — blocks scope creep)
 - 
 
-## Ràng buộc
-<Bắt buộc kỹ thuật/nghiệp vụ: API phải giữ nguyên, không thêm dependency, giới hạn hiệu năng…>
+## Constraints
+<Technical/business musts: API must stay stable, no new dependencies, performance limits…>
 - 
 
-## Acceptance criteria (đo được — đậu/rớt rõ ràng)
-<Cái PHẢI đúng thì feature mới coi là xong. Đây cũng là nguồn cho golden task ở Mức 5.>
+## Acceptance criteria (measurable — clear pass/fail)
+<What MUST be true for the feature to count as done. This also feeds the Level 5 golden task.>
 - [ ] 
 - [ ] 
 
 ## Test hooks
-<Sẽ kiểm bằng test nào / lệnh nào. Ưu tiên tự động hoá được.>
+<Which tests / commands will check it. Prefer things that can be automated.>
 - 
 
-## Ghi chú thiết kế & quyết định đã chốt
-<Hướng tiếp cận + lý do ngắn. Để người sau (và agent) không bàn lại từ đầu.>
+## Design notes & decisions locked
+<Approach + a short why. So the next person (and the agent) don't re-litigate from scratch.>
 - 

package/templates/spec/README.md

@@ -1,34 +1,34 @@
-# Specs — spec-driven development (nửa còn lại của Trụ cột 2)
+# Specs — spec-driven development (the other half of Pillar 2)
 
-Trụ cột 2 là **"Repo-local instructions & Specs"**. Mức 1 (`/init-harness` → `CLAUDE.md`) lo nửa
-**instructions**: luật bền, đúng xuyên *mọi* task. `FEATURE.md` lo nửa **specs**: định nghĩa **một
-feature cụ thể TRƯỚC khi code**. Spec rõ → agent ít lạc hướng; acceptance criteria rõ → có sẵn cái
-cho eval Mức 5 chấm đậu/rớt.
+Pillar 2 is **"Repo-local instructions & Specs"**. Level 1 (`/init-harness` → `CLAUDE.md`) covers the
+**instructions** half: durable rules that hold across *every* task. `FEATURE.md` covers the **specs**
+half: defining **one specific feature BEFORE you code it**. A clear spec → the agent strays less; clear
+acceptance criteria → you already have what a Level 5 eval grades pass/fail.
 
-## Khi nào dùng
+## When to use it
 
-- Feature **đủ lớn để dễ lạc** / nhiều bước / nhiều người → viết spec trước.
-- Việc nhỏ, một-phát-xong → **bỏ qua**. Đừng biến spec thành nghi thức.
+- A feature **big enough to get lost in** / multi-step / multi-person → write a spec first.
+- A small, one-shot job → **skip it**. Don't turn specs into ritual.
 
-## `FEATURE.md` vs `TASK.md` (đừng nhầm — chúng bổ sung nhau)
+## `FEATURE.md` vs `TASK.md` (don't confuse them — they complement each other)
 
-| | `FEATURE.md` (ở đây) | `TASK.md` (Mức 4) |
+| | `FEATURE.md` (here) | `TASK.md` (Level 4) |
 |---|---|---|
-| Mục đích | **plan TRƯỚC khi code**: cái gì + tiêu chí đậu | **trạng thái sống còn QUA session** |
-| Vòng đời | viết 1 lần đầu feature, ít đổi | cập nhật liên tục ở mỗi mốc |
-| Trả lời | "feature này *là gì*, xong khi nào" | "*đang* làm tới đâu, bước kế" |
+| Purpose | **plan BEFORE coding**: what + pass criteria | **state that survives ACROSS sessions** |
+| Lifecycle | written once at the feature's start, changes little | updated continuously at each milestone |
+| Answers | "what *is* this feature, when is it done" | "where am I *right now*, what's next" |
 
-Feature lớn thường dùng **cả hai**: `FEATURE.md` chốt đích, `TASK.md` theo dõi đường đi.
+A big feature usually uses **both**: `FEATURE.md` fixes the target, `TASK.md` tracks the path.
 
-## Cài
+## Install
 
 ```bash
 mkdir -p docs/specs
-cp FEATURE.md docs/specs/<tên-feature>.md
+cp FEATURE.md docs/specs/<feature-name>.md
 ```
 
-## Nâng cao
+## Advanced
 
-Feature lớn / cả team → dùng framework chuyên: **GitHub Spec Kit**, **12-Factor Agents** (link
-trong `docs/harness-engineering-tutorial.md`). `FEATURE.md` chỉ là bản tối giản để bắt đầu — đủ
-để có spec, không bắt bạn nuốt cả framework.
+Big feature / whole team → use a dedicated framework: **GitHub Spec Kit**, **12-Factor Agents** (links
+in `docs/harness-engineering-tutorial.md`). `FEATURE.md` is just a minimal starting point — enough to
+have a spec, without forcing you to adopt a whole framework.