How this runs
The two checklists say what "good" is. This page says how a project actually gets through the gate, so nobody has to guess.
The two documents
| For | When | |
|---|---|---|
| Build checklist | The developer building the project | Read at the start, then again at the end of each stage |
| Production gate | The review before go-live | Once the project is feature-complete on a stable URL |
They are the same 66 rules under the same ids, ordered differently: the first by the order the work happens, the second by how each item is verified. Both are generated from one source, so they cannot disagree with each other.
What I need to review a project
Send these together. Missing items do not stop a review, but they turn checks into unverified,
and unverified never counts as a pass.
| Why | Without it | |
|---|---|---|
| A stable URL, staging or production | Almost every check runs against a live page | No review is possible |
| Repository access | Bundle budgets, build output, source-level checks | Those rules come back unverified |
| An admin or editor login | Empty states, editable content, form submission | Content rules come back unverified |
| The list of templates | So the sample covers every template rather than every page | I sample by guesswork |
| For a relaunch: the old site's URL list | Redirect mapping | The redirect rule comes back unverified |
The URL must be stable for the duration of the review. Deploying into a review invalidates it, and we start again.
Turnaround
Two business days from receiving everything above, for a first review. One business day for a re-review, because the second round only diffs against the first.
This sits inside the five business days the framework agreement allows for accepting a deliverable, so a project reviewed on receipt still leaves time to act on the result.
The verdict
One of three, plus the reasons.
| Verdict | Means |
|---|---|
| PASS | Ship it |
| CONDITIONAL | Ship it once the listed waivers are signed, or once the unverified items are verified |
| FAIL | A blocker is open. Not production ready |
The report lists, in order: blocking items, required items, waived items, items that could not be verified and why, and advisory notes. Each line carries the rule id, what is wrong, the measured value, and the fix, so it can be handed straight to a developer.
Rounds, and who fixes
Round one is a full review. I report; the project's developer fixes.
Round two diffs against round one and reads as "3 fixed, 1 regressed, 1 still open". That is what keeps a second round cheap, and it is why the review can be priced per project rather than per hour.
If you would rather I did the fixing on a given project, that is separate work and I quote it separately. It is not inside the review.
Waivers
A required item that cannot be met can be waived. A waiver needs a written reason from Colibrity,
gets an id, and is recorded in the report. It expires at that project's next release, so it is a
decision rather than a permanent exemption.
blocker items are not waivable. They are the ones with legal exposure, a broken index, or a
violated house rule.
If the same rule gets waived on two different projects, I will say so. It means either the rule is wrong and should change, or the starter theme should absorb it so it stops being failable.
Scope
- Front-end only: markup, styles, scripts, media, the head, and what the server sends with them.
- New projects. Work already delivered is not retroactively in scope.
- Review time is scoped per project, agreed in that project's purchase order alongside the build.
When the rules change
The rules live in a git repository, so every change is dated and visible. A rule added after a project's build started applies to that project's next release, not to the one in flight.