Use one small Laravel change to experience the central Atlas loop:
Define the goal → bound the instruction → inspect the change → review evidence → decide.
You do not need the private product source or a running Laravel project. This repository includes a starting point, two prompts, a proposed diff, an evidence checklist, and a completed decision example. Nothing in this exercise runs an AI or changes your computer automatically.
A teammate asks:
Improve the status page so a reviewer knows the application is ready for a human check.
The starting code has one controller-provided label and one Blade view. Open
STARTING_POINT.md before continuing.
Write one sentence in your own words. A useful answer is:
Show a short review-ready explanation on the existing status page without changing routing, authentication, dependencies, or unrelated UI.
That sentence describes the desired outcome, but it does not yet control the implementation.
Open the blank Change Contract template, then compare it
with the completed Atlas instruction.
The worked contract allows only:
app/Http/Controllers/StatusController.phpresources/views/status.blade.php
It protects routes, authentication, dependencies, tests, layout structure, and every unrelated file. Suggestions outside that boundary must be parked rather than implemented.
Read the baseline prompt and the
Atlas instruction.
| Prompt property | Baseline | Atlas-controlled |
|---|---|---|
| Goal stated | Yes | Yes |
| Allowed files | No | Yes |
| Protected behavior | No | Yes |
| Acceptance criteria | No | Yes |
| Verification honesty | No | Yes |
| Out-of-scope ideas parked | No | Yes |
This table compares the supplied prompt text. It is not a claim about model quality or measured market outcomes.
Open PROPOSED_PATCH.diff. Review it as
if an AI coding tool supplied it.
Ask:
- Did it touch only the two allowed files?
- Did it preserve the route and controller method?
- Is the new copy understandable without adding architecture?
- Did it claim that tests passed?
- Did it implement any parked suggestion?
The proposed patch is intentionally small. Small does not mean accepted; it still needs evidence.
Use VERIFICATION_CHECKLIST.md.
The repository-only exercise lets you verify scope and readability, but it does not contain a real
Laravel runtime. Therefore php artisan test is not run here.
The completed SAMPLE_EVIDENCE.md
records that limitation instead of inventing a passing result.
Choose one:
- Accept only when the required evidence is sufficient.
- Revise when the change is promising but required evidence or behavior is incomplete.
- Reject when the change violates the goal, boundaries, or trust requirements.
Fill in the Decision Record template, then compare your
choice with the worked DECISION_RECORD.md.
The worked example requests revision because runtime verification is absent. That is a complete,
honest control-loop outcome—not a failure of the exercise.
You did not ask Atlas to decide whether the code was good. You used Atlas-shaped artifacts to make scope, evidence, uncertainty, and human authority visible.
Next: