Same brief
Each tool receives the same repository, constraints, and acceptance criteria.
The brief comes first. Readers should be able to reproduce the task, inspect the acceptance criteria, and challenge the result.
Build and verify one production-ready web feature inside the same repository, using the same requirements and time boundary.
Each tool receives the same repository, constraints, and acceptance criteria.
We keep prompts, artifacts, failures, costs, and the final verification output.
A recommendation remains planned until the test has actually been run and checked.
Every claim carries a checked date because these products change quickly.
A review can use the Tested label only after its evidence package is complete and the stated acceptance checks have run.
Every comparison, workflow, and best-of page follows the same audit trail so another builder can apply or challenge it.
State the decision being tested, who it is for, and what the review will not claim.
Record tool version, plan, repository, hardware, date, dependencies, and starting conditions.
Publish the fixed brief, inputs, steps, time boundary, and acceptance checks in execution order.
Separate direct measurements from observations, estimates, and unknown values.
Keep failed attempts, corrections, retries, and the human work required to reach the result.
Report attributable spend and elapsed work without implying precision the evidence cannot support.
Name confounders, missing evidence, version drift, and scenarios the result does not cover.
Conclude who the tool fits, who should avoid it, and which facts support that boundary.
Give readers the inputs, commands, checks, and evidence locations needed to repeat the test.