danielyayla

veri-decide

The gate where two or more real ways forward with different sacrifices become one proposed decision carrying the paths that lost. Use it when the choice is the live thing: "should we scan uploads inline on the request, or queue them to a worker?", "we already agreed uploads must be scanned, now it is a Postgres queue versus SQS", "DEC-062 says advisory by default and I now think that is wrong, I want to revisit it". It forces at least two alternatives that could genuinely have been chosen, pressure-tests each against the requirements it strains, and files the choice as proposed with its revisit conditions and rejection reasons. Not for a wanted property with no alternatives on the table: "every uploaded file has to be virus-scanned before anyone can download it, and that has to stay true", "I want search results to feel faster" are veri:define's, because what is missing is a requirement, not a choice. Not for a chore with only one way to do it — "bump zod to the latest 3.x and fix whatever breaks", "reformat

veri-define

Interrogates a want until the requirement writes itself — the gate between a rough want and a requirement worth approving, correctly typed and carrying criteria a machine could check. Use it when a property is wanted and no alternatives are on the table: "turn the export idea into a requirement with acceptance criteria I can actually check", "every uploaded file has to be virus-scanned before anyone can download it, and that has to stay true", "I want search results to feel faster, I think it would cut bounce on the results page". It pushes on every vague word until the criteria are observable, or until the thing is admitted to be a bet with a metric and a target. Not for a choice between named options: "should we scan uploads inline on the request, or queue them to a worker?", "we already agreed uploads must be scanned, now it is a Postgres queue versus SQS" are veri:decide's, because what is open is which way to satisfy something already wanted. Not for ordinary work inside existing intent — "add a null che

veri-did-it-work

The learning gate: after the work orders ship, the questions a receipt cannot answer. Use it when the shipping is finished and the verdict is not: "did the caching work actually move p95 latency to the target REQ-028 declared?", "we shipped the onboarding rewrite six weeks ago — did it actually help activation?", "all of REQ-035's work orders are done, was the bet right or do we retire it?". It keeps three questions apart — criteria met, constraints still holding, and what the declared metric did against its target — reaches one of four verdicts including inconclusive, and files reality's answer as an outcome source linked to the bet and to the work that shipped, without applying it to the requirement. Not for checking code against its spec before anything ships: "go through the diff on the wo-118 branch against its work order before I mark it done", "WO-124's acceptance criteria are all ticked — check whether we actually did what we said" are veri:review's, because nothing has shipped and there is no outcome

veri-evidence-intake

Staffs the evidence door: takes material arriving from outside — user feedback, metrics, a support ticket, a competitor move, an incident, research findings — and files it as a source linked to what it bears on, so it lands on the graph instead of in a drawer. Use it when something external is pointed at the record: "here is a support thread where three customers hit the same import failure, get it on the record against whatever it bears on", "last month's activation numbers came back for the onboarding release, file them", "a competitor just shipped the thing REQ-021 bets against, where does that go?". It files the material faithfully, with tests, supports or refutes links to the requirements and outcome-of links to the shipping work orders, and leaves what it means to you. Not for judging a bet whose evidence is already in: "did the caching work actually move p95 latency to the target REQ-028 declared?", "all of REQ-035's work orders are done, was the bet right or do we retire it?" are veri:did-it-work's, w

Data & Documents Listed

veri-health

The periodic inspection: the decay `veri check`'s hard rules cannot catch, swept and filed so two sweeps months apart compare. Use it when the question is the record's condition rather than its content: "how healthy is this project? anything rotting?", "it has been a quarter — sweep the record for decisions whose revisit conditions have arrived and claims nobody ever finished", "tell me what we left behind after three hard weeks". It reports first and triaged — stale documents, arrived revisit conditions, abandoned claims, untested bets, orphans, the age of your stamp queue — then asks only which you want to act on, and files a health-report source with a fixed shape so the next sweep is a comparison, not a fresh impression. It proposes; it repairs nothing. Not for running the stamp queue itself: "what is waiting on me?", "walk me through everything that needs my stamp before we plan the next batch" are veri:approval-session's, which needs you present document by document. Not for "run the test suite", "why i

veri-implement

Steers implementation of a work order that already exists — the gate between a ready work order and a receipt. Use it when a work order is named or already claimed: "WO-131 is ready — start it", "claim WO-118 and pick up where I left off", "walk the scope back to me before any code", "build it" with a work order id on the table. It claims the work order, reads its whole context package, reads the scope back before typing, guards the boundary, files decisions made en route as proposals, and appends the closing receipt. Not for cutting work up: "start building the CSV export, there is no work order for it yet", "REQ-014 is accepted — turn it into work orders", "this one is too big to verify, split it into slices" are veri:plan-work's, because an implementer may not code from a chat prompt alone. Not for ordinary work inside a boundary already drawn — a null check, a rename, a unit test, a failing CI matrix, "summarise what you just changed" — no gate is being crossed.

veri-plan-work

The gate between approved intent and work orders somebody could verify one at a time. Use it when intent is settled and nothing is queued against it: "REQ-014 is accepted — cut it into work orders", "the backlog is empty but REQ-039 and REQ-041 are both accepted, turn them into work", "start building the CSV export, there is no work order for it yet", "this one is too big to verify in one go, split it into slices that each ship on their own". It reads what is already accepted and already queued, pushes each slice until it can be proven alone, ties every acceptance criterion to the requirement clause it proves, and files the work orders in backlog awaiting your stamp. Not for work inside a boundary already drawn: "WO-131 is ready — start it", "pick up my in-progress claim on WO-118 and keep going where I left off" are veri:implement's, because the lines exist and what is left is execution. Not for ordinary work with no boundary in question — "run the test suite", "the CI matrix is failing on Node 18, fix it".

veri-product-discovery

Turns a vague idea into a defined problem, a direction, non-goals and the first named bets — the gate an empty or reopened record passes through before anything can be required of it. Use it when the utterance carries enough to argue with: "I have an idea for a tool that helps freelance designers chase unpaid invoices, nothing is written down yet", "we are pivoting, the team-collaboration angle is not landing and I want to restart from the solo user's problem", "nobody is using the free tier and we never defined the problem it solves". It interviews Socratically, one question at a time, then files a product-brief source and one draft requirement per foundational bet. Not for a record whose problem is settled and whose user is the thing in doubt: "we keep writing 'small teams' into every requirement and I could not tell you who that actually is" is veri:user-discovery's, because what is undefined is who rather than what. Not for a bare "I have an idea" carrying nothing — that is veri:wayfinder's triage — nor f

veri-wayfinder

Routes an utterance to the gate it belongs to — the front door, standing before every gate rather than at one. Use it when a session opens with a want and no document: "I have an idea for a product", "what should I work on next?", "I need to change something in this codebase", "why is search built this way?". It asks one triage question, then stops asking and shows — the current intent, the ready queue and who holds what, the subgraph around whatever was named, what is approved versus still pending — and hands over to the gate that owns it with the ids already gathered. Not for a question that already names its target and asks for the record: "why does the importer normalise dates in two places, and who decided that?", "what alternatives did we reject when we picked the file-based store?" are veri:archaeology's, because there is a named artifact to walk backwards from. Not for ordinary work — "where is the retry logic for the upload queue?", "run the test suite", "good morning" — where no gate is in question