An agent won't start work on a task that can't be done
An AI agent doesn't ask again. Given an incomplete description, it fills in the gaps itself — and builds the wrong thing. It looks like it works, it passes review, it surfaces at acceptance. noomoo doesn't advise, it stops you: while a task is described badly, no work on it begins.
closed testing · access on requestdead-pathA closed task references a file that no longer exists in the project. The document describes something the code no longer has.feature-without-reqA feature is being built, but it is tied to no client requirement. Nobody can explain why it exists.req-without-ucA requirement went into work with no description of how a person uses it. The developer will be guessing.Real output captured from a run. Not a mockup.
The later you catch it, the more it costs
The same badly described task costs wildly different amounts depending on the step at which it was stopped.
Orders of magnitude, not our measurements. We do not publish our own numbers yet — see the «Numbers» section.
«Build a user account page»
A task that can't be done
It does not say what exactly changes, how to verify the result, or what is out of scope. The agent fills in the rest as it sees fit.
«As we agreed on Friday»
An agreement that exists nowhere
The decision stayed in a chat or in someone’s head. A month later neither a person nor an agent can recover it.
The docs say one thing, the code does another
Documentation quietly lies
Nothing breaks, so nobody notices. Until a new person starts working from it.
«Eighty percent done, I’d say»
Status by hearsay
The manager trusts a claim, not a fact. The gap surfaces at the demo.
The whole difference, in five seconds
On the left is the task description. Switch the variant and press «Check»: you will see exactly what a developer sees in their terminal.
Demo: the finding texts and codes are real, from a working check. The run here is replayed, not executed in the browser. The line «Covers: REQ-031-2; UC-14» in the third tab is what answers «why does this code exist» six months later.
Five steps, three of them done by the machine
It installs into a project like an ordinary library. Nothing leaves for someone else’s cloud: the documents stay in your repository and the tool runs on the developer’s machine. The commands below are real — a developer or an agent types them.
Traceability chain
REQ-014-2
Client requirement
UC-08
Use case
FEAT-013
Feature
TASK-207
Task
feature-without-req — the feature references no «REQ-NNN-I» requirement. The chain is broken at the third node.
An idea enters the work list
DP-217 · kind: workEvery thought gets a number and a kind: work, idea, decision or research. The kind determines what it turns into — and the thought stops getting lost in chat.
The chain is built
npx noomoo scaffoldClient requirement → use case → feature → task. The command creates a document of the right shape: nobody writes them by hand, so the shape is not reinvented every time.
The gate lets the task into work
npx noomoo task-ready TASK-142Is the goal clear, is every criterion verifiable, is the scope named, does it lean on an agreement absent from the documents. Green — take it. Red — fix it.
Code is written under supervision
.githooks/pre-commitThirty rules fire at the moment code is committed — automatically, with no separate command. Red does not get saved, and it cannot be bypassed silently.
Status comes from facts
npx noomoo validate«Done» is a consequence of what happened in the repository, not a line someone set by hand.
Thirty-three rules, thirty-one of them without AI
A rule looks at a fact: does the file exist, does the link exist, was the document changed after approval. That is why the same project always gives the same answer — you cannot negotiate with the check, you can only satisfy it. Below are thirteen of the thirty-three, grouped by what they protect.
Agreement with the client
What was approved does not change silently
spec-integrity
Agreement integrity
error
«The requirement was changed after the client approved it»
error — work stops
changed-drift
Edited after sign-off
warn
«The document was edited after approval and nobody re-approved it»
warn — warning
deliverable-drift
Stale deliverable
warn
«A file published to the client lags behind the original»
warn — warning
Connectivity
Every piece of work is explainable through «why»
links
Connectivity
error
«A link to nowhere, a circular task dependency, a document nobody references»
error — work stops
coverage
Coverage
error
«A client requirement nobody created a task for»
error — work stops
req-without-uc
Requirement without a use case
error
«requirement «REQ-001-2» is covered by a product ([FE]/[BE]) task, but by no use case»
error — work stops
feature-without-req
Feature without a requirement
error
«the feature references no «REQ-NNN-I» requirement»
error — work stops
Match with the code
Documents describe what is on disk
dead-path
Dead reference
error
««Implementation» references a file that does not exist: «src/nonexistent/dead-module.ts» (a done task, the path must exist)»
error — work stops
file-scope
Edit scope
warn
«The task promised to touch certain files, and other ones were touched»
warn — warning
impl-collision
Collision
error
«Two people started creating the same module in different tasks»
error — work stops
Order of work
Work does not start ahead of time
tests-after-impl
Tests after code
warn
««Tests first (red)» must come before «Implementation (green)»»
warn — warning
gate-not-passed
Gate not passed
error
«no green review artefact docs/tasks/reviews/task-048-review.md — the task:ready gate has not been passed»
error — work stops
possible-duplicate
Duplicate
warn
«req-024 and req-025 are similar (0.92) — an obvious duplicate. Resolve it: refine one and add «- Replaces: req-NNN», or «- Not-a-duplicate: req-NNN» if they differ»
warn — warning
Five separate ways documents drift from reality are caught on their own: a stale reference to a requirement, a descendant lagging behind its source, a document changed after approval, a spec changed after the client signed off, and a file published to the client that lags behind the original.
The project stops depending on one person’s memory
«Developers stopped asking me: what is this task about? what needs to be done? Tasks were written with agents before, but they were a mess, agents lost context, the format varied, no rules. Now everything is clear both to the developer and to me».
A new person ramps up in days
Not weeks. The documents are linked to each other and any answer from them can be verified — because the machine holds the links, not somebody’s memory.
The client gets what was agreed
If an approved requirement is changed after sign-off, it shows immediately, not at acceptance.
The agent works within limits, not on inspiration
Everyone on the team — people and agents — goes through the same check. You cannot negotiate with it, you can only fix things.
Less dependence on a single expert
Decisions live in documents and are linked to code. A person leaving stops meaning a loss of context.
What we know and how it was measured
Some numbers come from runs, some are estimates from two projects. We label them honestly so you can judge.
The product checks itself the same way it checks other projects
noomoo has kept a log of its own runs from day one. Over two months — 3,408 entries: which profile ran, on which branch, how it ended, how many findings. The log was never prepared for publication, it is a by-product of the work — which is why it also counts the things that are inconvenient for us.
A branch roughly corresponds to one task, but not strictly: one branch can carry several runs for different tasks. We are still refining the counting method, so we present this as a first estimate from the log, not as a final metric.
The median number of findings in a rejected run is deliberately left out: the warning counter collects check noise from the whole corpus rather than findings on the task itself, and the number would be wrong.
Every number above is computed by a single command over the log file in the repository: docs/validation/history.jsonl
A run on noomoo’s own documentation: 1,404 documents, 249 requirements, 581 tasks. The product runs itself by its own rules — that is our entire test bench.
Who it is not for
Better to find out now than a week after installing.
The tool Task Force runs its own projects with
noomoo is not a methodology for sale. It is the internal tool of the Task Force engineering team. We built it because our own documents and code kept drifting apart and agents kept building the wrong thing. The rules come from our own failures, not from a whiteboard.
Today it runs our production projects — the ones we are accountable for. We are now opening it to a limited number of outside teams.