Agentic Development Lifecycle: What the Verify Number Counts

A developer comes back from lunch and opens AuricIDE. Mission Control fills the screen with four boxes in a row, each with a number in it: Spec, Plan, Execute, Verify. The last one reads 6/9. The developer takes that to mean six requirements passed out of nine, without opening a single requirement. Then they return to the agent panel.

That reading is wrong twice. The four boxes are independent counters, not stages of one pipeline. And the Verify number is a click with an expiry date, not a test result.

Does finishing one station feed the next?

No. Every station in the agentic development lifecycle view reports its own records. Finishing one does not create or change records in the next.

Each station is a button that opens the place its number comes from. Spec opens the spec files, Plan opens the tickets, Execute opens the agents panel, Verify opens the requirements. Nothing advances. The faint arrows between the boxes only show on a wide pane, and they are decoration. No stage gate sits behind them. No step waits for another. Narrow the pane and the arrows vanish. Every counter keeps its meaning.

A car dashboard works the same way. Fuel, speed and the maintenance light share one panel, and a full tank says nothing about the oil. The panel groups readings. It does not connect them. Mission Control groups four readings of one project, and the left-to-right layout is what makes them look like a flow.

What does each station count?

Each one counts a different kind of record, and only one of them is easy to misread.

Spec is the number of markdown and Excalidraw files under a specs/ folder. A README elsewhere does not count. Click it with no spec files and AuricIDE starts a new one. With one file, the editor opens it. With several, a picker appears.

Plan is the number of tickets that are not done, archived or discarded. It says nothing about whether a ticket has a spec or an agent behind it. Execute is the number of agents running right now. Zero means nothing runs now. It does not mean the work is done.

Verify takes more care. The denominator is every requirement whose status is active, implemented or verified, so drafts and deprecated ones stay out. The numerator is the verified requirements whose last verified date is not older than 30 days. A requirement that is only "implemented" sits in the nine but not in the six, however finished it feels.

An amber button under the boxes counts the rest. It reads "N stale/unverified", and N is the denominator minus the numerator. The tooltip on the Verify box says "Verified / total", and that label is fair. The trouble is the word "verified".

Take nine requirements to see how 6/9 comes about. Four were verified last week and two were verified three weeks ago, so those six are held. One was verified 40 days ago, and its 30 days ran out. Two are implemented and nobody has verified them yet. The amber button shows 3, because those last three are exactly the ones outside the six. Six plus three makes nine. The sum always holds. Two of the six may have been checked with real care, and the other four may have been clicked in a hurry. The counter cannot tell.

What does a verified requirement actually prove?

Less than the word suggests. AuricIDE records a click, not a check.

The "Verify Now" button in a requirement's detail panel does two things. It sets the status to verified, and it writes the current time as the last verified date. An agent that calls the verify_requirement tool in the project's MCP server does the same two things, so an agent can mark its own finished work as verified. Neither path runs a test, opens the code or records who or what did the verifying.

Think of the inspection sticker on a fire extinguisher. It says somebody signed off and when. It does not say whether they weighed the cylinder or only glanced at the gauge. Verify works like that sticker, with one addition: the sticker expires. After 30 days the requirement drops out of the six and into the amber count, whether or not the code under it changed.

The clock is the only freshness signal in the number, and it measures the age of a click. A requirement verified yesterday still counts after somebody rewrites the feature today. Nothing links the two. The status dropdown in the edit form adds a quirk. Pick "verified" there. Only the status changes. The list then shows "never" under last verified, and the requirement counts toward the six for good. The 30-day rule can only expire a date, and this one has none.

So 6/9 can mean six careful reviews, or six clicks made before a release meeting. The figure looks the same either way.

To see what the six are made of, open the requirements list. Each row shows a green dot and "fresh", an amber dot and "stale", or a dash when nobody ever verified it. That column shows the age of each mark. It cannot show the care behind it.

What does it cost to keep the stations independent?

It costs a number that is only as honest as the habit behind it.

A strict pipeline was possible. A requirement would need a spec file before it got a ticket, a ticket before an agent run, and a recorded check before it counted. That design would make the screen easy to read. It would also block how people actually work: importing a pile of requirements before any plan exists, launching an agent straight from a ticket, or verifying later once a review is ready.

AuricIDE chose the loose version, so the stations describe current records and never gate each other. The price is the one above. A healthy Verify number says somebody marked things verified recently, and it cannot say what they looked at. Whether verifying means reading a diff, running a test or asking a colleague is left open. The team has to settle that before a release review leans on the number.

What carries over to other dashboards?

Any status board that shows one clean number deserves two questions: which event changes it, and what makes it expire?

For Verify the answers are a status flip with a timestamp, and 30 days. For a test coverage badge, a compliance checklist or the numbers behind AI agent monitoring, the answers will differ, and they decide how much weight the number can carry. A label can be accurate while a reader's interpretation is not. "Verified / total" is accurate here. "Six tests passed" would not be.

So find the event, find the expiry rule, and check what the number leaves out. The layout of a lifecycle screen suggests flow, but the definitions behind it say what was counted.