tiny-spec 1.0.0__tar.gz → 1.1.0__tar.gz

{tiny_spec-1.0.0 → tiny_spec-1.1.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: tiny-spec
-Version: 1.0.0
+Version: 1.1.0
 Summary: A tiny, opinionated take on spec-driven development.
 Project-URL: Homepage, https://github.com/GrayMa77er/tiny-spec
 Project-URL: Source, https://github.com/GrayMa77er/tiny-spec
@@ -115,54 +115,36 @@ receipt rather than the adjective:
 | [OpenSpec](https://github.com/Fission-AI/OpenSpec) | 12 | — | `.openspec.yaml` | `proposal` `design` `tasks` `specs/` |
 | [BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) | 58 | 5 personas | 35 × `customize.toml` | `PRD` `architecture` `epics` `stories` `UX` `brief` `sprint-plan` |
 
-The whole of tiny-spec is **2,195 lines** of markdown across 7 skills and 2 agents.
-There is no config file, no build step, no orchestrator, and no CLI to initialize a
-project — the skills are the product. (That line count went *up* slightly in 1.0 while
-the skill count went down: `tiny-spec-adopt` is genuinely new capability, and merging
-four skills into two removed commands to learn rather than words to read.)
-
-<sub>Counts taken from each project's own repository on 2026-08-03 by listing its
-command/skill/agent directories and templates, not from its marketing copy. Spec Kit:
-`templates/commands/` (10 files) and the artifact set named in `templates/plan-template.md`.
-OpenSpec: `skills/` (12 directories). BMAD: `SKILL.md` files on `main` (58), agent
-personas in `src/bmm-skills/agents/` (analyst, architect, dev, pm, ux-designer), and
-`customize.toml` files (35). These projects are all substantially more popular than
-tiny-spec — Spec Kit ~125k stars, OpenSpec ~64k, BMAD ~51k — and being smaller is a
-bet, not a proof of quality. Re-run the counts yourself before believing them.</sub>
+The whole of tiny-spec is **2,195 lines** of markdown across 7 skills and 2 agents. No
+config file, no build step, no orchestrator, no CLI to initialize a project — the skills
+are the product.
 
-## Why it's small
+<sub>Counted on 2026-08-03 from each project's own repository, not its marketing copy —
+Spec Kit's `templates/commands/`, OpenSpec's `skills/`, BMAD's `SKILL.md` and
+`customize.toml` files on `main`. All three are far more popular than tiny-spec, and
+being smaller is a bet, not a proof of quality — re-run the counts yourself before
+believing them.</sub>
 
-Most spec frameworks are generous by default:
-many phases, many agents, many generated documents. tiny-spec makes the opposite
-bet. Keep one safeguard, drop the rest.
+## Why it's small
 
-A green unit test suite is not the same as working software, so the reviewer
-exercises acceptance criteria end to end and a final smoke test confirms the whole
-spec. That independent review is the safeguard — not the volume of planning
-artifacts. One task, one commit, an external reviewer. Nothing gets added unless
-it earns its place.
+Most spec frameworks are generous by default: many phases, many agents, many generated
+documents. tiny-spec makes the opposite bet — keep one safeguard, drop the rest. That
+safeguard is the independent reviewer, which exercises acceptance criteria end to end,
+because a green unit test suite is not the same as working software.
 
 The case for staying small:
 
-- **Documents are context, and context isn't free.** Generating large `spec.md`,
-  `plan.md`, `research.md`, and `data-model.md` files costs tokens to write, then
-  costs context to carry. Every paragraph the agent has to hold is room it no
-  longer has for your actual code. tiny-spec keeps the spine small — a
-  constitution and a short memory — and injects only what each task needs.
-- **Real work is a ticket inside a system, not a greenfield repo.** Bigger kits
-  assume you're bootstrapping a project from a blank page. Day to day, you pick up
-  a ticket and change part of a system that already exists. tiny-spec binds to a
-  ticket, works one at a time, and references your task platform instead of
-  re-describing the world.
-- **Rigid pipelines fight the user.** Mandatory phases and required sections
-  impose ceremony on work that doesn't need it. tiny-spec's extra structure is
-  optional by design — add shape where it pays, skip it where it doesn't.
-- **More moving parts is more to maintain.** Orchestrators, ownership contracts,
-  checkpoint matrices, and config files are themselves a system you have to learn
-  and keep in sync. A few small skills and two agents are not.
-- **Generated docs can fake rigor.** A folder of polished planning artifacts looks
-  like progress, but it isn't proof. The proof is the reviewer running your real
-  tests before each commit.
+- **Documents are context, and context isn't free.** Every paragraph the agent has to
+  hold is room it no longer has for your actual code. tiny-spec keeps the spine small —
+  a constitution and a short memory — and injects only what each task needs.
+- **Real work is a ticket inside a system, not a greenfield repo.** tiny-spec binds to a
+  ticket and references your task platform instead of re-describing the world.
+- **Rigid pipelines fight the user.** Mandatory phases impose ceremony on work that
+  doesn't need it. The extra structure here is optional — add shape where it pays.
+- **More moving parts is more to maintain.** Orchestrators, ownership contracts, and
+  config files are themselves a system you have to keep in sync. Two agents are not.
+- **Generated docs can fake rigor.** A folder of polished planning artifacts looks like
+  progress, but the proof is the reviewer running your real tests before each commit.
 
 That's the whole trade: where larger kits add machinery, tiny-spec adds one
 independent reviewer and stops.
@@ -172,10 +154,10 @@ independent reviewer and stops.
 Smaller is easy to claim, so the suite ships a harness that measures it. `docs/eval/`
 runs tiny-spec headlessly on benchmark tasks in hermetic sandboxes, grades the produced
 code with held-out tests the suite never sees, and checks the reviewer's own verdict
-against that ground truth — the number that matters being **false-PASS rate**, how
-often the gate blesses code that is actually broken.
+against that ground truth. The number that matters is **false-PASS rate** — how often
+the gate blesses code that is actually broken.
 
-Most recent run — 5 benchmark tasks, v1.0.0 (`b18e32a`), 2026-09-07:
+Most recent run — 5 benchmark tasks on v1.0.0:
 
 | | |
 |---|---|
@@ -184,29 +166,24 @@ Most recent run — 5 benchmark tasks, v1.0.0 (`b18e32a`), 2026-09-07:
 | **false-PASS rate** | **0%** — it never called broken code done |
 | blocker rate | 0% |
 
-Two earlier runs — `7810074` (2026-08-03) and `f973c85` a month before it — scored
-identically, which is the more interesting result: the loop is stable across versions
-rather than tuned to a single commit. The 1.0 run matters most of the three, because
-1.0 rebuilt the planning chain around it — `tiny-spec-plan` now writes the task list
-that `tiny-spec-build` executes — and the gate came through unchanged.
+Two earlier versions scored identically, which is the more interesting result: the loop
+is stable across releases rather than tuned to one commit — including through 1.0, which
+rebuilt the planning chain underneath it.
 
 See [`docs/eval/README.md`](docs/eval/README.md) for the method and
-[`docs/sdd-evaluation-rubric.md`](docs/sdd-evaluation-rubric.md) for the scoring rubric
-this repo grades itself against. **Read both skeptically: it is my benchmark, of my own
-tool, scored by me.** The rubric says so itself — *"treat the tiny-spec column as
-self-assessment to pressure-test, not gospel."* The tasks are small and self-contained,
-so the harness measures the loop on well-specified work, not large-codebase performance.
-The harness is in the repo precisely so you don't have to take my word for it.
+[`docs/sdd-evaluation-rubric.md`](docs/sdd-evaluation-rubric.md) for the rubric. **Read
+both skeptically: it is my benchmark, of my own tool, scored by me**, on small
+self-contained tasks — so it measures the loop on well-specified work, not
+large-codebase performance. The harness is in the repo so you don't have to take my
+word for it.
 
 ## New to spec-driven development?
 
-Spec-driven development (SDD) means writing down *what* you want and *why* before
-any code exists, then letting that spec drive the build. Instead of prompting an
-agent and hoping, you hand it a small, explicit contract — the intent, a design,
-and an ordered list of tasks — and it implements against that. The payoff: the
-agent stops guessing. It knows what "done" looks like, you can review the plan
-before a single line is written, and the result is checked against the spec
-rather than vibes. tiny-spec is one small take on that idea.
+Spec-driven development (SDD) means writing down *what* you want and *why* before any
+code exists, then letting that spec drive the build. Instead of prompting an agent and
+hoping, you hand it a small, explicit contract — the intent, a design, and an ordered
+list of tasks. The payoff: the agent stops guessing, you review the plan before a line
+is written, and the result is checked against the spec rather than vibes.
 
 ## Quickstart
 
@@ -297,13 +274,12 @@ hardens it with concrete engineering rules, and `tiny-spec-build` injects it who
 every task. It holds your style, standards, invariants, definition of done, and
 verification commands.
 
-**On an existing codebase, deriving beats asking.** Your test command, your layout, and
-your conventions are already written down — in `package.json`, in CI, in your linter
-config, in the shape of the tree. `tiny-spec-adopt` reads them and marks each section
-as declared or inferred, so you know which parts to distrust. It then *runs* the
-verification commands it derived and reports which went green: a gate that has never
-been run is the most dangerous thing in the file, because it turns every future review
-into theatre.
+**On an existing codebase, deriving beats asking.** Your test command, layout, and
+conventions are already written down — in `package.json`, in CI, in your linter config,
+in the shape of the tree. `tiny-spec-adopt` reads them, marks each section as declared
+or inferred so you know which parts to distrust, then *runs* the verification commands
+it derived and reports which went green. A gate that has never been run turns every
+future review into theatre.
 
 Because it is project-wide the constitution can also go missing — deleted, or never
 committed — while your specs survive. Re-running `tiny-spec-adopt` (or
@@ -404,13 +380,12 @@ FINDINGS:
 
 Numbers first, and never a screenshot diff — pixel comparison goes flaky on font
 antialiasing and teams end up muting it. But no measurement catches an element that is
-present, on-token, and still not on screen — occluded, clipped, truncated, or the same
+present, on-token, and still not on screen: occluded, clipped, truncated, or the same
 color as what's behind it. So the last step reads a screenshot of each state next to
 your export and grades presence, legibility, and correspondence. **Where a number
-already settled the question the eye may only flag** — on-scale-but-cramped is never a
-fail — which keeps the two halves from contradicting each other. Measurable or visible
-violations fail; taste comes back as `flag:` notes so a bounded fix loop can't thrash. A
-task with no `design:` tag is graded exactly as before.
+already settled the question the eye may only flag**, which keeps the two halves from
+contradicting each other — measurable or visible violations fail, taste comes back as
+`flag:` notes. A task with no `design:` tag is graded exactly as before.
 
 <details>
 <summary>The <code>visual:</code> command (you write this once)</summary>
@@ -454,14 +429,12 @@ await b.close();
 ```
 
 The missing-selector branch **must print something** — that is what turns a renamed
-element into a failure instead of a silent skip. `top` is what the layout-order check
-reads, and `opacity`/`visibility` are worth printing because they turn the cheapest kind
-of invisible element into a numeric failure. The `SCREENSHOT` line is what the reviewer
-reads back to look at the render and catch the rest — occlusion, clipping, truncation,
-same-color-on-same-color — none of which any single property reports. Drop it and the
-numeric half still gates exactly as before, with the reviewer reporting `judge: not run`
-rather than quietly skipping it. Without a `visual:` command at all, a task tagged
-`design:` raises a blocker rather than passing quietly.
+element into a failure instead of a silent skip. `top` feeds the layout-order check, and
+`opacity`/`visibility` turn the cheapest kind of invisible element into a numeric
+failure. The `SCREENSHOT` line arms the judge; drop it and the numeric half still gates
+exactly as before, with the reviewer reporting `judge: not run` rather than quietly
+skipping it. Without a `visual:` command at all, a task tagged `design:` raises a
+blocker rather than passing quietly.
 
 </details>
 
@@ -476,10 +449,19 @@ unnoticed.
 1. Plan the task against the constitution (inline, brief).
 2. Implement it with a fresh `tiny-spec-build-executor` agent.
 3. Review it with an independent `tiny-spec-build-reviewer` agent that runs the gate
-   end to end and grades against the constitution and the task's acceptance.
+   and grades against the constitution and the task's acceptance.
 4. On pass, commit the code plus a checklist tick. On fail, loop back to the
    executor with the findings. After two failed attempts the run halts `exhausted`.
 
+Every task's acceptance is exercised end to end, black-box, by the reviewer — that part
+never varies. What does vary is how much of the toolchain gets re-proven around it: a
+clean `install → build` runs on the first task, the last one, anything touching
+dependency or build config, and anything carrying `design:`; in between the reviewer runs
+lint and tests against the existing build. It escalates back to the full gate whenever the
+narrower one can't carry the verdict, and the authoritative clean run happens once more
+over the whole project as the final smoke. Re-installing from scratch on every task
+proved the same thing repeatedly and was the slowest part of the loop.
+
 ```mermaid
 flowchart TB
     SPEC[SPEC.md<br/>intent] --> PLAN[PLAN.md<br/>design] --> TASKS[tasks.md<br/>checklist]
@@ -487,7 +469,7 @@ flowchart TB
     TASKS -->|pause: set| H[Halt — paused<br/>task stays unchecked]
     TASKS --> P[Plan task]
     P --> I[Implement<br/>executor]
-    I --> R[Review + run gate<br/>reviewer]
+    I --> R[Review + run gate<br/>full or scoped<br/>reviewer]
     I -->|blocker| B
     R -->|pass| C[Commit + tick]
     C --> TASKS
@@ -543,10 +525,9 @@ honest trade: a breakdown runs unattended, a pasted list is supervised.
 | `fork` | a real either/or the plan doesn't answer |
 | `conflict` | a story's branch wouldn't merge cleanly |
 
-**Only `done` means the work is built** — and in a story run that means *all* of them.
-A run that stopped at story 2 of 7 reporting "done" is the single thing autonomous loops
-get wrong most often, so the state is always named, along with what got merged and how
-many stories are still untouched.
+**Only `done` means the work is built** — and in a story run, that means *all* of them.
+Stopping at story 2 of 7 and reporting "done" is what autonomous loops get wrong most
+often, so the state is always named alongside what merged and what's still untouched.
 
 **A halt stops the whole run, not just that story.** Later stories in a list you wrote
 top to bottom usually assume the earlier ones landed, so skipping ahead past a failure
@@ -573,27 +554,26 @@ never opens a PR. Merges are local, so a bad run is one `git reset` away; publis
 stays yours. If the gate goes red after a merge it leaves the merge alone and tells you
 the undo command rather than running it.
 
-**Walk away and come back.** Nothing is written down to track progress — it's derived:
-a story whose ticked `tasks.md` is on `main` is done, a `.spec/<slug>/` with an unchecked
-task is in progress, no directory means not started. So asking `/tiny-spec-run` to build
-the backlog again tomorrow in a fresh session picks up exactly where it stopped. No
-run-state file, no lock, and no budget to configure: the story list *is* the budget.
+**Walk away and come back.** Progress isn't written down, it's derived: a story whose
+ticked `tasks.md` is on `main` is done, a `.spec/<slug>/` with an unchecked task is in
+progress, no directory means not started. Ask again tomorrow in a fresh session and it
+picks up where it stopped. No run-state file, no lock, no budget to configure — the
+story list *is* the budget.
 
 **It never fixes a blocker for you.** A blocker means one of your documents is wrong,
 and a run allowed to rewrite the requirement its own task just failed would be grading
 its own homework. It reports and stops; the upstream edit is yours.
 
 **And it never decides to build on its own.** Whether a run stops before the build or
-goes all the way is fixed from your opening request and never revised — not by a stage's
-closing line, not by a follow-up message. Build is your review gate, so promoting
-yourself into it is the one thing a router doesn't get to do.
+goes all the way is fixed from your opening request and never revised. Build is your
+review gate, so promoting itself into it is the one thing a router doesn't get to do.
 
 ## Project layout
 
 Each skill is one self-contained `SKILL.md`, with every document skeleton inline in
-it — no companion template files, no absolute paths, and no shared parent required
-at runtime, so a skill works wherever you drop it. (It also means a run never stops
-to ask permission to read a template out of your Claude config directory.)
+it — no companion template files, no absolute paths, no shared parent required at
+runtime. A skill works wherever you drop it, and a run never stops to ask permission to
+read a template out of your Claude config directory.
 
 tiny-spec creates a `.spec/` directory in your project root, never inside a skill.
 It is namespaced per ticket, with a shared spine at the root:

{tiny_spec-1.0.0 → tiny_spec-1.1.0}/README.md

@@ -78,54 +78,36 @@ receipt rather than the adjective:
 | [OpenSpec](https://github.com/Fission-AI/OpenSpec) | 12 | — | `.openspec.yaml` | `proposal` `design` `tasks` `specs/` |
 | [BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) | 58 | 5 personas | 35 × `customize.toml` | `PRD` `architecture` `epics` `stories` `UX` `brief` `sprint-plan` |
 
-The whole of tiny-spec is **2,195 lines** of markdown across 7 skills and 2 agents.
-There is no config file, no build step, no orchestrator, and no CLI to initialize a
-project — the skills are the product. (That line count went *up* slightly in 1.0 while
-the skill count went down: `tiny-spec-adopt` is genuinely new capability, and merging
-four skills into two removed commands to learn rather than words to read.)
-
-<sub>Counts taken from each project's own repository on 2026-08-03 by listing its
-command/skill/agent directories and templates, not from its marketing copy. Spec Kit:
-`templates/commands/` (10 files) and the artifact set named in `templates/plan-template.md`.
-OpenSpec: `skills/` (12 directories). BMAD: `SKILL.md` files on `main` (58), agent
-personas in `src/bmm-skills/agents/` (analyst, architect, dev, pm, ux-designer), and
-`customize.toml` files (35). These projects are all substantially more popular than
-tiny-spec — Spec Kit ~125k stars, OpenSpec ~64k, BMAD ~51k — and being smaller is a
-bet, not a proof of quality. Re-run the counts yourself before believing them.</sub>
+The whole of tiny-spec is **2,195 lines** of markdown across 7 skills and 2 agents. No
+config file, no build step, no orchestrator, no CLI to initialize a project — the skills
+are the product.
 
-## Why it's small
+<sub>Counted on 2026-08-03 from each project's own repository, not its marketing copy —
+Spec Kit's `templates/commands/`, OpenSpec's `skills/`, BMAD's `SKILL.md` and
+`customize.toml` files on `main`. All three are far more popular than tiny-spec, and
+being smaller is a bet, not a proof of quality — re-run the counts yourself before
+believing them.</sub>
 
-Most spec frameworks are generous by default:
-many phases, many agents, many generated documents. tiny-spec makes the opposite
-bet. Keep one safeguard, drop the rest.
+## Why it's small
 
-A green unit test suite is not the same as working software, so the reviewer
-exercises acceptance criteria end to end and a final smoke test confirms the whole
-spec. That independent review is the safeguard — not the volume of planning
-artifacts. One task, one commit, an external reviewer. Nothing gets added unless
-it earns its place.
+Most spec frameworks are generous by default: many phases, many agents, many generated
+documents. tiny-spec makes the opposite bet — keep one safeguard, drop the rest. That
+safeguard is the independent reviewer, which exercises acceptance criteria end to end,
+because a green unit test suite is not the same as working software.
 
 The case for staying small:
 
-- **Documents are context, and context isn't free.** Generating large `spec.md`,
-  `plan.md`, `research.md`, and `data-model.md` files costs tokens to write, then
-  costs context to carry. Every paragraph the agent has to hold is room it no
-  longer has for your actual code. tiny-spec keeps the spine small — a
-  constitution and a short memory — and injects only what each task needs.
-- **Real work is a ticket inside a system, not a greenfield repo.** Bigger kits
-  assume you're bootstrapping a project from a blank page. Day to day, you pick up
-  a ticket and change part of a system that already exists. tiny-spec binds to a
-  ticket, works one at a time, and references your task platform instead of
-  re-describing the world.
-- **Rigid pipelines fight the user.** Mandatory phases and required sections
-  impose ceremony on work that doesn't need it. tiny-spec's extra structure is
-  optional by design — add shape where it pays, skip it where it doesn't.
-- **More moving parts is more to maintain.** Orchestrators, ownership contracts,
-  checkpoint matrices, and config files are themselves a system you have to learn
-  and keep in sync. A few small skills and two agents are not.
-- **Generated docs can fake rigor.** A folder of polished planning artifacts looks
-  like progress, but it isn't proof. The proof is the reviewer running your real
-  tests before each commit.
+- **Documents are context, and context isn't free.** Every paragraph the agent has to
+  hold is room it no longer has for your actual code. tiny-spec keeps the spine small —
+  a constitution and a short memory — and injects only what each task needs.
+- **Real work is a ticket inside a system, not a greenfield repo.** tiny-spec binds to a
+  ticket and references your task platform instead of re-describing the world.
+- **Rigid pipelines fight the user.** Mandatory phases impose ceremony on work that
+  doesn't need it. The extra structure here is optional — add shape where it pays.
+- **More moving parts is more to maintain.** Orchestrators, ownership contracts, and
+  config files are themselves a system you have to keep in sync. Two agents are not.
+- **Generated docs can fake rigor.** A folder of polished planning artifacts looks like
+  progress, but the proof is the reviewer running your real tests before each commit.
 
 That's the whole trade: where larger kits add machinery, tiny-spec adds one
 independent reviewer and stops.
@@ -135,10 +117,10 @@ independent reviewer and stops.
 Smaller is easy to claim, so the suite ships a harness that measures it. `docs/eval/`
 runs tiny-spec headlessly on benchmark tasks in hermetic sandboxes, grades the produced
 code with held-out tests the suite never sees, and checks the reviewer's own verdict
-against that ground truth — the number that matters being **false-PASS rate**, how
-often the gate blesses code that is actually broken.
+against that ground truth. The number that matters is **false-PASS rate** — how often
+the gate blesses code that is actually broken.
 
-Most recent run — 5 benchmark tasks, v1.0.0 (`b18e32a`), 2026-09-07:
+Most recent run — 5 benchmark tasks on v1.0.0:
 
 | | |
 |---|---|
@@ -147,29 +129,24 @@ Most recent run — 5 benchmark tasks, v1.0.0 (`b18e32a`), 2026-09-07:
 | **false-PASS rate** | **0%** — it never called broken code done |
 | blocker rate | 0% |
 
-Two earlier runs — `7810074` (2026-08-03) and `f973c85` a month before it — scored
-identically, which is the more interesting result: the loop is stable across versions
-rather than tuned to a single commit. The 1.0 run matters most of the three, because
-1.0 rebuilt the planning chain around it — `tiny-spec-plan` now writes the task list
-that `tiny-spec-build` executes — and the gate came through unchanged.
+Two earlier versions scored identically, which is the more interesting result: the loop
+is stable across releases rather than tuned to one commit — including through 1.0, which
+rebuilt the planning chain underneath it.
 
 See [`docs/eval/README.md`](docs/eval/README.md) for the method and
-[`docs/sdd-evaluation-rubric.md`](docs/sdd-evaluation-rubric.md) for the scoring rubric
-this repo grades itself against. **Read both skeptically: it is my benchmark, of my own
-tool, scored by me.** The rubric says so itself — *"treat the tiny-spec column as
-self-assessment to pressure-test, not gospel."* The tasks are small and self-contained,
-so the harness measures the loop on well-specified work, not large-codebase performance.
-The harness is in the repo precisely so you don't have to take my word for it.
+[`docs/sdd-evaluation-rubric.md`](docs/sdd-evaluation-rubric.md) for the rubric. **Read
+both skeptically: it is my benchmark, of my own tool, scored by me**, on small
+self-contained tasks — so it measures the loop on well-specified work, not
+large-codebase performance. The harness is in the repo so you don't have to take my
+word for it.
 
 ## New to spec-driven development?
 
-Spec-driven development (SDD) means writing down *what* you want and *why* before
-any code exists, then letting that spec drive the build. Instead of prompting an
-agent and hoping, you hand it a small, explicit contract — the intent, a design,
-and an ordered list of tasks — and it implements against that. The payoff: the
-agent stops guessing. It knows what "done" looks like, you can review the plan
-before a single line is written, and the result is checked against the spec
-rather than vibes. tiny-spec is one small take on that idea.
+Spec-driven development (SDD) means writing down *what* you want and *why* before any
+code exists, then letting that spec drive the build. Instead of prompting an agent and
+hoping, you hand it a small, explicit contract — the intent, a design, and an ordered
+list of tasks. The payoff: the agent stops guessing, you review the plan before a line
+is written, and the result is checked against the spec rather than vibes.
 
 ## Quickstart
 
@@ -260,13 +237,12 @@ hardens it with concrete engineering rules, and `tiny-spec-build` injects it who
 every task. It holds your style, standards, invariants, definition of done, and
 verification commands.
 
-**On an existing codebase, deriving beats asking.** Your test command, your layout, and
-your conventions are already written down — in `package.json`, in CI, in your linter
-config, in the shape of the tree. `tiny-spec-adopt` reads them and marks each section
-as declared or inferred, so you know which parts to distrust. It then *runs* the
-verification commands it derived and reports which went green: a gate that has never
-been run is the most dangerous thing in the file, because it turns every future review
-into theatre.
+**On an existing codebase, deriving beats asking.** Your test command, layout, and
+conventions are already written down — in `package.json`, in CI, in your linter config,
+in the shape of the tree. `tiny-spec-adopt` reads them, marks each section as declared
+or inferred so you know which parts to distrust, then *runs* the verification commands
+it derived and reports which went green. A gate that has never been run turns every
+future review into theatre.
 
 Because it is project-wide the constitution can also go missing — deleted, or never
 committed — while your specs survive. Re-running `tiny-spec-adopt` (or
@@ -367,13 +343,12 @@ FINDINGS:
 
 Numbers first, and never a screenshot diff — pixel comparison goes flaky on font
 antialiasing and teams end up muting it. But no measurement catches an element that is
-present, on-token, and still not on screen — occluded, clipped, truncated, or the same
+present, on-token, and still not on screen: occluded, clipped, truncated, or the same
 color as what's behind it. So the last step reads a screenshot of each state next to
 your export and grades presence, legibility, and correspondence. **Where a number
-already settled the question the eye may only flag** — on-scale-but-cramped is never a
-fail — which keeps the two halves from contradicting each other. Measurable or visible
-violations fail; taste comes back as `flag:` notes so a bounded fix loop can't thrash. A
-task with no `design:` tag is graded exactly as before.
+already settled the question the eye may only flag**, which keeps the two halves from
+contradicting each other — measurable or visible violations fail, taste comes back as
+`flag:` notes. A task with no `design:` tag is graded exactly as before.
 
 <details>
 <summary>The <code>visual:</code> command (you write this once)</summary>
@@ -417,14 +392,12 @@ await b.close();
 ```
 
 The missing-selector branch **must print something** — that is what turns a renamed
-element into a failure instead of a silent skip. `top` is what the layout-order check
-reads, and `opacity`/`visibility` are worth printing because they turn the cheapest kind
-of invisible element into a numeric failure. The `SCREENSHOT` line is what the reviewer
-reads back to look at the render and catch the rest — occlusion, clipping, truncation,
-same-color-on-same-color — none of which any single property reports. Drop it and the
-numeric half still gates exactly as before, with the reviewer reporting `judge: not run`
-rather than quietly skipping it. Without a `visual:` command at all, a task tagged
-`design:` raises a blocker rather than passing quietly.
+element into a failure instead of a silent skip. `top` feeds the layout-order check, and
+`opacity`/`visibility` turn the cheapest kind of invisible element into a numeric
+failure. The `SCREENSHOT` line arms the judge; drop it and the numeric half still gates
+exactly as before, with the reviewer reporting `judge: not run` rather than quietly
+skipping it. Without a `visual:` command at all, a task tagged `design:` raises a
+blocker rather than passing quietly.
 
 </details>
 
@@ -439,10 +412,19 @@ unnoticed.
 1. Plan the task against the constitution (inline, brief).
 2. Implement it with a fresh `tiny-spec-build-executor` agent.
 3. Review it with an independent `tiny-spec-build-reviewer` agent that runs the gate
-   end to end and grades against the constitution and the task's acceptance.
+   and grades against the constitution and the task's acceptance.
 4. On pass, commit the code plus a checklist tick. On fail, loop back to the
    executor with the findings. After two failed attempts the run halts `exhausted`.
 
+Every task's acceptance is exercised end to end, black-box, by the reviewer — that part
+never varies. What does vary is how much of the toolchain gets re-proven around it: a
+clean `install → build` runs on the first task, the last one, anything touching
+dependency or build config, and anything carrying `design:`; in between the reviewer runs
+lint and tests against the existing build. It escalates back to the full gate whenever the
+narrower one can't carry the verdict, and the authoritative clean run happens once more
+over the whole project as the final smoke. Re-installing from scratch on every task
+proved the same thing repeatedly and was the slowest part of the loop.
+
 ```mermaid
 flowchart TB
     SPEC[SPEC.md<br/>intent] --> PLAN[PLAN.md<br/>design] --> TASKS[tasks.md<br/>checklist]
@@ -450,7 +432,7 @@ flowchart TB
     TASKS -->|pause: set| H[Halt — paused<br/>task stays unchecked]
     TASKS --> P[Plan task]
     P --> I[Implement<br/>executor]
-    I --> R[Review + run gate<br/>reviewer]
+    I --> R[Review + run gate<br/>full or scoped<br/>reviewer]
     I -->|blocker| B
     R -->|pass| C[Commit + tick]
     C --> TASKS
@@ -506,10 +488,9 @@ honest trade: a breakdown runs unattended, a pasted list is supervised.
 | `fork` | a real either/or the plan doesn't answer |
 | `conflict` | a story's branch wouldn't merge cleanly |
 
-**Only `done` means the work is built** — and in a story run that means *all* of them.
-A run that stopped at story 2 of 7 reporting "done" is the single thing autonomous loops
-get wrong most often, so the state is always named, along with what got merged and how
-many stories are still untouched.
+**Only `done` means the work is built** — and in a story run, that means *all* of them.
+Stopping at story 2 of 7 and reporting "done" is what autonomous loops get wrong most
+often, so the state is always named alongside what merged and what's still untouched.
 
 **A halt stops the whole run, not just that story.** Later stories in a list you wrote
 top to bottom usually assume the earlier ones landed, so skipping ahead past a failure
@@ -536,27 +517,26 @@ never opens a PR. Merges are local, so a bad run is one `git reset` away; publis
 stays yours. If the gate goes red after a merge it leaves the merge alone and tells you
 the undo command rather than running it.
 
-**Walk away and come back.** Nothing is written down to track progress — it's derived:
-a story whose ticked `tasks.md` is on `main` is done, a `.spec/<slug>/` with an unchecked
-task is in progress, no directory means not started. So asking `/tiny-spec-run` to build
-the backlog again tomorrow in a fresh session picks up exactly where it stopped. No
-run-state file, no lock, and no budget to configure: the story list *is* the budget.
+**Walk away and come back.** Progress isn't written down, it's derived: a story whose
+ticked `tasks.md` is on `main` is done, a `.spec/<slug>/` with an unchecked task is in
+progress, no directory means not started. Ask again tomorrow in a fresh session and it
+picks up where it stopped. No run-state file, no lock, no budget to configure — the
+story list *is* the budget.
 
 **It never fixes a blocker for you.** A blocker means one of your documents is wrong,
 and a run allowed to rewrite the requirement its own task just failed would be grading
 its own homework. It reports and stops; the upstream edit is yours.
 
 **And it never decides to build on its own.** Whether a run stops before the build or
-goes all the way is fixed from your opening request and never revised — not by a stage's
-closing line, not by a follow-up message. Build is your review gate, so promoting
-yourself into it is the one thing a router doesn't get to do.
+goes all the way is fixed from your opening request and never revised. Build is your
+review gate, so promoting itself into it is the one thing a router doesn't get to do.
 
 ## Project layout
 
 Each skill is one self-contained `SKILL.md`, with every document skeleton inline in
-it — no companion template files, no absolute paths, and no shared parent required
-at runtime, so a skill works wherever you drop it. (It also means a run never stops
-to ask permission to read a template out of your Claude config directory.)
+it — no companion template files, no absolute paths, no shared parent required at
+runtime. A skill works wherever you drop it, and a run never stops to ask permission to
+read a template out of your Claude config directory.
 
 tiny-spec creates a `.spec/` directory in your project root, never inside a skill.
 It is namespaced per ticket, with a shared spine at the root:

{tiny_spec-1.0.0 → tiny_spec-1.1.0}/agents/tiny-spec-build-executor.md

@@ -24,7 +24,10 @@ Everything you need and nothing you don't:
   so you don't re-learn a pitfall a past run already paid for;
 - **if the task carries `design:`** — that screen's `D<n>` entry from `SPEC.md` and
   the path to its committed export;
-- the specific existing files that are your starting point, named explicitly.
+- the specific existing files that are your starting point, named explicitly;
+- sometimes, **the files the previous task left behind** — paths only. Start there when
+  orienting: it is the most recently moved ground in the codebase and the most likely
+  place your task connects to.
 
 You are **blind to the workflow, not to the codebase.** You don't get the plan,
 other tasks, or shared state. But the named files are a launch point, not the whole
@@ -64,7 +67,11 @@ violated.
 6. You MAY run a **narrow self-check** of your own work (the one test file you
    wrote, a syntax/import check). You do **not** need to run the full gate — the
    independent **reviewer** runs the authoritative Verification commands next.
-   Leave the tree in a clean, buildable state for it.
+   **Leave the tree in a clean, buildable, installed state for it** — the reviewer may
+   run against the existing build rather than rebuilding from scratch, so a tree you
+   left half-migrated or with a stale artifact costs the task a review cycle. If you
+   changed dependencies or build configuration, apply them (install, regenerate the
+   lockfile) rather than leaving it for someone else, and say so in `CHANGES`.
 
 ## Hard constraints
 

{tiny_spec-1.0.0 → tiny_spec-1.1.0}/agents/tiny-spec-build-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: tiny-spec-build-reviewer
-description: Independently reviews a single finished task — runs the project's real gate end-to-end and checks the code against the constitution and the task's acceptance. Blind to how the code was written. Returns PASS/FAIL plus findings. Spawned (one per task) by tiny-spec-build. Does not fix code, plan, spawn agents, or invoke skills.
+description: Independently reviews a single finished task — runs the project's real gate at the scope it was given (full or scoped, escalating when scoped can't carry the verdict), exercises the acceptance end-to-end, and checks the code against the constitution. Blind to how the code was written. Returns PASS/FAIL plus findings. Spawned (one per task) by tiny-spec-build. Does not fix code, plan, spawn agents, or invoke skills.
 tools: Read, Write, Edit, Bash, Grep, Glob
 ---
 
@@ -17,6 +17,9 @@ back to `tiny-spec-build`; return data, not pleasantries.
 - the full **constitution** (`constitution.md`) — especially **Guiding invariants**,
   **Definition of Done**, and **Verification commands**, plus the **Design system**
   token table if the project has one;
+- the **gate scope** for this task — `full` or `scoped`. `tiny-spec-build` sets it; it
+  knows where this task sits in the run and you don't. If the brief names no scope,
+  treat it as `full`;
 - the project's **memory** if any (`memory.md`) — operational lessons (e.g. the
   gate needs the package installed first); honor them so you don't false-fail on a
   known precondition;
@@ -32,10 +35,26 @@ acceptance and the constitution — verified, not inferred?**
 1. **Read the changed code.** Check it against the constitution: does it honor the
    **Guiding invariants**, match the **Style** and **Layout**, meet the
    **Definition of Done**? Note any violation as a finding.
-2. **Run the real gate.** Execute the constitution's **Verification commands**
-   end-to-end (install → lint → test → build → run, as applicable) from a clean
-   state, after the documented setup — not a test-runner shortcut. Capture the
-   real output.
+2. **Run the real gate, at the scope you were given.** Capture the real output either
+   way — never a test-runner shortcut, never an inferred result.
+
+   - **`full`** — execute the constitution's **Verification commands** end-to-end
+     (install → lint → test → build → run, as applicable) from a clean state, after the
+     documented setup.
+   - **`scoped`** — run `lint:` and `test:` against the working tree, and rely on the
+     existing install/build state rather than rebuilding it from clean. Step 3 below is
+     **not** scoped: you still exercise the acceptance end-to-end, black-box, with real
+     input. A scoped gate skips re-proving the toolchain; it never skips proving the task.
+
+   **Escalate rather than guess.** Move a `scoped` gate up to `full` the moment the
+   narrower one can't carry the verdict — you need a build artifact that isn't there or
+   looks stale, `install`/`build` state seems inconsistent with the changed files, a
+   command fails in a way that might be environmental, or you simply cannot exercise the
+   acceptance without building. Escalation is always allowed and always safe. **Passing a
+   task on evidence you found insufficient is not** — that is the one thing this whole
+   role exists to prevent. Never narrow a `full` gate to `scoped`.
+
+   Say which scope you actually ran in `GATE:`, including that you escalated and why.
 3. **Exercise the acceptance.** Trigger the task's stated outcome the most
    black-box way available (CLI > HTTP > public API) with realistic input,
    including a negative case if the acceptance implies a boundary or rejection.
@@ -158,7 +177,8 @@ Never spawn subagents or invoke skills.
 ```
 TASK: <task id>
 VERDICT: PASS | FAIL
-GATE: <the Verification commands you ran + the real result (pass/fail + key output)>
+GATE: <scope: full | scoped (+ "escalated from scoped: <why>" if you moved it up);
+  the Verification commands you ran + the real result (pass/fail + key output)>
 ACCEPTANCE: <how you exercised it + the observed effect, or why you couldn't>
 DESIGN: <omit unless the task carried `design:`. The D<n> checked, the measurements
   you read back vs the tokens they should match, and which states you exercised —

{tiny_spec-1.0.0 → tiny_spec-1.1.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "tiny-spec"
-version = "1.0.0"
+version = "1.1.0"
 description = "A tiny, opinionated take on spec-driven development."
 readme = "README.md"
 requires-python = ">=3.9"

{tiny_spec-1.0.0 → tiny_spec-1.1.0}/tiny-spec-build/SKILL.md

@@ -68,7 +68,11 @@ Spawn one **`tiny-spec-build-executor`** with a fresh, self-contained prompt:
   `.spec/<active>/SPEC.md` plus its `export:` path, so the executor can look at the
   design instead of guessing at it;
 - only the specific existing files the task starts from, named explicitly (so it
-  edits with the real current contents, not blind).
+  edits with the real current contents, not blind);
+- the **previous passed task's `CHANGES` list**, if there is one, labelled as what the
+  last task left behind. Every executor starts cold and re-derives the codebase; naming
+  the files that just moved is the cheapest way to cut that, and you already have the
+  list in hand. Paths only — not the previous task's description, findings, or report.
 
 Do **not** pass the plan, sibling tasks, or other chatter. It returns a structured
 report (`STATUS`, `CHANGES`, `DECISIONS`, `BLOCKER`). A `STATUS: blocked` →
@@ -80,11 +84,29 @@ Spawn one **`tiny-spec-build-reviewer`**, **blind to step 2**, with:
 - the task id, description, and **acceptance**;
 - the **whole** `.spec/constitution.md`;
 - the list of changed files (from the executor's `CHANGES`) to read;
-- the **Verification commands** from the constitution to run;
+- the **Verification commands** from the constitution to run, and the **gate scope**
+  for this task — `full` or `scoped` (decide it as below; you have the run context,
+  the reviewer does not);
 - **if the task has a `design:` field** — the same `D<n>` entry and `export:` path
   you gave the executor, so it grades against the contract rather than its taste.
 
-It runs the real gate end-to-end, checks the code against the constitution's
+**Gate scope.** A clean `install → build` proves the same thing on task 7 that it proved
+on task 1 unless a task changed what it installs or builds, so running it every time buys
+little and costs the most wall-clock in the loop. Name the scope in the brief:
+
+- **`full`** — the whole gate from a clean state (install → lint → test → build → run).
+  Use it on: the **first** task of this run; any task whose `CHANGES` touch dependency or
+  build configuration (`package.json`/lockfiles, `pyproject.toml`, `go.mod`, `Cargo.toml`,
+  `Dockerfile`, CI config, build scripts); any task carrying `design:`; and the **last**
+  task in `tasks.md`.
+- **`scoped`** — otherwise. `lint:` + `test:` plus the acceptance exercised end-to-end,
+  black-box, exactly as on a full gate. The acceptance exercise is never scoped away; it
+  is the whole reason the reviewer exists.
+
+The reviewer may **escalate** `scoped` to `full` on its own and will say so — that
+direction is always safe. It may never go the other way.
+
+It runs the gate at the scope you named, checks the code against the constitution's
 **Definition of Done** and **invariants**, confirms the **acceptance** actually
 holds (exercised, not inferred), and returns `VERDICT: PASS | FAIL` + findings.
 On a `design:` task it also runs the constitution's `visual:` command, measures the
@@ -94,11 +116,15 @@ numbers can't reach, like an element that measures perfectly and shows up invisi
 It fails on what it measured or saw, and merely flags what is taste.
 
 > Why independent: unit-green ≠ working, and the author is the worst judge of its
-> own blind spots. The reviewer running the gate from a clean state is the
-> safeguard that keeps scope and quality honest without an ownership contract.
+> own blind spots. The reviewer exercising the acceptance black-box — on every task,
+> at either scope — is the safeguard that keeps scope and quality honest without an
+> ownership contract.
 
 ### 4. CONVERGE (on FAIL)
-Re-dispatch the **executor** with the reviewer's findings appended to its brief.
+Re-dispatch the **executor** with the reviewer's findings appended to its brief, then
+review again — recomputing the **gate scope** from the fix's `CHANGES`, and using `full`
+if the failure was in the gate itself or the reviewer escalated last time. A task that
+already failed once has earned the wider check.
 Bound this to **2 fix attempts**. If it still fails after that, stop and **halt
 `exhausted`** (see **Halting** below) — don't keep grinding or hand-fix past the loop
 silently. `exhausted` is recorded as a blocker, because a task that three attempts
@@ -274,6 +300,12 @@ When every task in `tasks.md` is `[x]`:
    setup — install/build, not a test-runner shortcut). There is no separate
    verify skill — this final smoke confirms the requirements actually work end-to-end, not
    just that tasks are ticked.
+
+   **This is the authoritative clean-state run for the whole build**, and it is never
+   scoped or skipped. Per-task gates run at the scope step 3 named; this one always runs
+   everything from clean. A build or install regression that a `scoped` task gate did not
+   re-prove surfaces here — which is why a red final smoke is a gap to fix or route
+   upstream, never a pass and never `done`.
 2. **Report** — the terminal state by name (`done` here, since every task is `[x]`
    and the smoke passed), what was built, the commits made (with the branch), and any
    open `decisions.md` items (blockers, tasks unchecked by a reconcile). If the final

{tiny_spec-1.0.0 → tiny_spec-1.1.0}/tiny-spec-plan/SKILL.md

@@ -138,25 +138,59 @@ past it into a task list — say what's unresolved and route back to `tiny-spec-
 ## Step 3 — slice the approach into tasks
 
 Walk the `## Approach` you just wrote and break it into tasks. No waves, no
-parallelism, no `owns:` contracts — tasks run one at a time, top to bottom. Each task is:
-
-- **Small and independently checkable** — one slice a single executor can finish and a
-  reviewer can grade in one pass. If you can't write a one-line acceptance for it, it's
-  too big — split it.
+parallelism, no `owns:` contracts — tasks run one at a time, top to bottom.
+
+**The unit is one coherent commit** — what a competent engineer does in one focused
+sitting and commits as a single unit of work. That typically touches several files and
+often satisfies several `REQ-N` at once. It is the size you would open as one reviewable
+change, not the smallest thing you could name.
+
+**Know what a task costs, so size has something to trade against.** Every task you write
+spends two cold-start agents that must re-orient in the codebase from scratch, a reviewer
+that runs the gate and exercises the acceptance end-to-end, and two commits. That
+overhead is **fixed** — it does not shrink for a small task. A task the executor
+finishes in thirty seconds still pays all of it. Size each task so the work inside it
+clearly outweighs the machinery around it.
+
+So:
+
+- **Split on independent failure, not on sentence length.** Split a task when it carries
+  two **unrelated** observable outcomes that could fail independently of each other. Do
+  **not** split because the acceptance got long — a good acceptance is usually several
+  clauses covering the happy path *and* its negatives. See `T4` in the `examples/todo-cli`
+  task list: two CLI commands, four requirements, and three negative cases, in one task,
+  with one acceptance. That is the calibration point, not the exception.
+- **One task may satisfy several `REQ-N`** — `req:` takes a list. Coverage means every
+  requirement has a *home*, not that every requirement gets its *own* task. **A 1:1
+  REQ→task mapping is the single most common way this list comes out too granular.**
+  Group the requirements that one coherent change delivers together.
 - **Ordered so each builds on the last.** Tasks run sequentially, so a later task may
   freely assume an earlier task's code already exists. Put foundational work (types,
   schema, scaffolding) first. Order by dependency, not by guesswork.
-- **Right-sized, not fragmented.** Don't split a cohesive change into five files' worth
-  of micro-tasks just to look granular. Earned ceremony: fewer, meaningful tasks beat
-  many trivial ones.
+
+**Smells that mean you sliced below the commit line** — fold each of these back into the
+task it belongs to:
+
+- a task that only defines types, interfaces, or schema with no behavior behind them;
+- a task that only adds tests for the task before it (the constitution's **Definition of
+  Done** already requires the tests to ship with the code);
+- one task per file, or one task per function;
+- a "wire it up" / "integrate the pieces" task trailing the pieces it wires.
+
+**Count is a smell, not a cap.** A story sized the way `tiny-spec-scope` describes
+usually lands in **3–6 tasks**. If you are past about eight, re-read the list: you have
+either sliced below the commit line, or the story itself was too big and should have been
+split upstream. Check the list against that; do **not** enforce a number, and never drop
+or merge coverage just to hit one.
 
 For each task, write:
 
 ```
 - [ ] T<n> — <imperative description>
-  - acceptance: <one user-observable outcome that proves it's done>
+  - acceptance: <one user-observable outcome that proves it's done — happy path and the
+                 negatives that bound it, in one entry>
   - type: feat            # optional; Conventional Commit type (defaults to feat)
-  - req: REQ-n            # optional; the REQ-N this task delivers
+  - req: REQ-n, REQ-n     # optional; the REQ-N this task delivers — a list, not one
   - design: D-n           # optional; the SPEC.md D<n> screen this task builds — arms the visual gate
   - pause: <why>          # optional; halt the build before this task so a human looks first
   - files: <comma-separated hint of files it will touch>
@@ -164,7 +198,11 @@ For each task, write:
 
 The **acceptance** is what the reviewer checks against — make it observable
 ("`spec --version` prints the version and exits 0"), not internal ("version logic
-added"). **type** picks the Conventional Commit type `tiny-spec-build` uses for this
+added"). It states **one outcome**, but one outcome is not one clause: spell out the
+happy path and the negatives that bound it in the same acceptance, separated by
+semicolons. A long acceptance is a well-specified task, not an oversized one — it is the
+*number of unrelated things that could fail* that decides whether to split, not the
+length of the line. **type** picks the Conventional Commit type `tiny-spec-build` uses for this
 task's code commit (`feat | fix | docs | refactor | test | chore | build | ci | perf | style`);
 set it when the task is clearly not a feature, otherwise omit and it defaults to `feat`.
 **req** ties the task to the requirement it satisfies (traceability). The **files** line
@@ -211,7 +249,9 @@ anyway. A policy that matches nothing here is not an error — say so and move o
 than stretching a task to fit it.
 
 Cover **every** part of the approach — together the tasks must deliver all `REQ-N`.
-Don't leave a requirement with no task. Likewise, if `SPEC.md` has a `## Design`
+Don't leave a requirement with no task. Coverage is about requirements having a home,
+not about the shape of the mapping: several `REQ-N` on one task is the normal case, and
+a task per requirement is the anti-pattern. Likewise, if `SPEC.md` has a `## Design`
 section, every `D<n>` in it needs at least one task carrying that `design:` reference —
 a screen nobody is graded against is a screen that will be built wrong.
 
@@ -236,25 +276,31 @@ updated: <ISO date>
 
 ## Tasks
 
-- [ ] T1 — <one small, independently-checkable slice of work>
-  - acceptance: <one user-observable outcome that proves T1 is done>
+- [ ] T1 — <one coherent commit's worth of foundational work; usually several files>
+  - acceptance: <the observable outcome; happy path; and the negative case that bounds it>
   - type: feat            # optional; Conventional Commit type for this task's commit (defaults to feat)
-  - req: REQ-1            # optional; the REQ-N this task delivers
-  - files: <path, path>
+  - req: REQ-1, REQ-2     # optional; the REQ-N this task delivers — several is normal
+  - files: <path, path, path>
 
-- [ ] T2 — <next slice; assume T1's code exists>
-  - acceptance: <observable outcome>
+- [ ] T2 — <next coherent change; assume T1's code exists>
+  - acceptance: <observable outcome; plus what it rejects and how it fails>
   - type: feat
-  - req: REQ-2
+  - req: REQ-3, REQ-4, REQ-5
   - design: D1            # optional; only on tasks that build the visible surface
   - files: <path, path>
 
 - [ ] T3 — <…>
   - acceptance: <observable outcome>
+  - req: REQ-6
   - pause: <optional; what to check before this runs — irreversible work only>
   - files: <path, path>
 ```
 
+The `req:` lists above are the shape to aim for, not filler: a handful of tasks each
+carrying the requirements one coherent change delivers. A skeleton filled in as
+`REQ-1`, `REQ-2`, `REQ-3` down a column of single-requirement tasks is the granularity
+failure described in Step 3.
+
 ## Update mode (SPEC changed → PLAN and tasks are stale)
 
 When `PLAN.md` or `tasks.md` is `status: stale`, reconcile **both in one pass** — they

{tiny_spec-1.0.0 → tiny_spec-1.1.0}/tiny_spec/__init__.py

@@ -5,4 +5,4 @@ into your Claude Code config directory (``~/.claude/`` by default). It adds no
 runtime behavior to the suite itself.
 """
 
-__version__ = "0.5.0"
+__version__ = "1.1.0"