Scheduled reviews and campaigns

On configured owner installations, scheduled DevAd runs can review files, prepare proposals and advance queued campaigns. Availability depends on your local models, settings and remaining run budget. These preparation runs do not establish that DevAd can publish releases independently.

The larger unit of work is a campaign: one goal, in plain words, with evidence and a way to know when it is done. DevAd files campaigns itself from the gaps it finds (a defect its own review rated high, a competitor claim that no longer holds, a support report with a reproduction, a release that was refused), and you can file one from the Release desk. The campaign workflow is designed around these stages; check the recorded result of each stage rather than assuming it completed:

• Read the code the goal touches and write a plan: which files change, in what order, and which test must fail first.
• Build in a separate copy of the code, never in the copy you are using. The failing test is written first, then the change, then a comment saying why.
• Check everything itself: the tests, the search for names that are used but never defined, the rule that no capability may be removed, the release scan. A generated summary does not replace a passing check.
• Review with a different model than the one that built, following a fixed procedure: remove each fix, confirm its test fails without it, then restore the fix.
• Merge in order, and rehearse the result: the whole test suite, the build, the release checks, the pages rendered, the panel started and driven.
• Report what changed, what was measured, and what was left, with the numbers.

A step that fails is retried with another model from your machine before it is given up on. When every retry fails, the campaign stops and files a card that names the step and the reason.

Review and release controls

• It will not merge a change that removes a tool, a route, a fallback or a check. A replacement has to land in the same change and handle the same inputs, or the change stays a proposal.
• It will not settle a merge conflict its rules cannot settle. The campaign is held, and the card names the file and the lines.
• It will not publish a release when any release check fails. The release stays on your disk and the verdict names the reason.
• It will not change the checks that limit what it may do. A proposal that touches them is marked for you and cannot be promoted by DevAd.
• It will not use a paid model unless Allow premium models is on in Settings.
• It will not take a request from anyone but the owner of the copy. The Release desk and its routes refuse every other account.

How to read a report

Open the Release desk panel. Each campaign is one row: the goal, its state (running, done, held), how many stages are done of how many, how long it has taken, and the last piece of evidence it recorded. Read the report opens three sections:

Under the report, What happened lists every recorded step: when, which model or person did it, what it did, the confidence number, and the command that puts that step back. A held campaign says in its row why it is held.

How to ask for a change

In the Release desk, Ask DevAd to build takes the goal in one or two sentences and, if you want, one line per way you will know it is done. Eligible campaigns can advance on a scheduled run. Holds, approvals and the run budget can delay work; follow its recorded state in the Release desk. From the console, /campaign followed by the goal does the same. A copy whose release predates campaigns says Not available on this copy yet in the box; update from the News panel.

The numbers it publishes

Use these commands from the install folder to inspect the available measurements. Check the run date, model and test conditions before comparing results: