Development and verification
Make one storefront change you can review and reverse
A small development assignment should end with a clear diff and verification record. Limit the change, confirm the tools and agree which existing behaviours must remain intact.
On this page
Write a contract small enough to test
This illustrative brief concerns one menu defect. Replace the details with your own evidence.
Problem: the product menu extends beyond the mobile viewport. Affected view: [URL, locale and theme] Baseline: [revision or supplied source version] Allowed scope: menu component and its existing shared styles. Success: the menu stays within the agreed viewport; its links and keyboard navigation remain usable. Preserve: existing routes, authentication and checkout behaviour. Approval: [reviewer], before release. Rollback trigger: broken navigation or a failed agreed check.
Make the working materials explicit
A screenshot shows a symptom; source establishes its context.
Relevant source
Provide the component, associated styles and enough surrounding code to understand the existing pattern. Identify the base revision and any unrelated local changes.
Reproduction
Supply the failing URL or view, viewport, language, theme and interaction steps. Include the expected result so a visual preference is not mistaken for a functional requirement.
Working environment
Confirm file access, dependency installation, test commands and browser availability in the actual runtime. Share only necessary material through supported channels; keep credentials out of the brief.
Establish what the workspace can actually do
SmaugBrain already provides accounts, plans, Agent creation and a controlled workspace launch. The Token page shows recorded model calls and usage trends. These controls help you start an assignment and review resource use; they do not establish that a particular Agent has your repository, a shell, a browser or deployment credentials.
Confirm those capabilities before promising an executable patch. Authorized file and command access permits editing and available checks. Supplied source alone supports a proposed patch or review. The website does not supply an automatic repository import, pull-request submission or deployment workflow.
Keep implementation decisions visible
Use the repository’s existing conventions and make the change independently reviewable.
Inspect the current behaviour
Locate the owning component and shared rules. Check whether the symptom comes from positioning, clipping, content length or a different breakpoint before choosing a fix.
Apply a bounded patch
Change the smallest appropriate owner. Preserve nearby user work, route behaviour and established tokens. Explain any necessary scope expansion before proceeding.
Review the diff
Read the final changes against the contract. Remove unrelated cleanup and explain why each changed file belongs in the assignment.
Separate successful execution from unverified claims
Report the command or observation, its outcome and the boundary of that evidence. A skipped check needs an owner and a reason, rather than a pass.
| Check | Evidence to retain | Limit to state |
|---|---|---|
| Syntax or build | Exact command and exit result | A successful build alone does not verify interaction. |
| Behaviour | Relevant test or repeatable manual steps | Record unavailable dependencies or inaccessible services. |
| Visual result | Agreed viewport, locale and theme observations | List variants that were not checked. |
| Regression | Previously working paths revisited | Do not label the entire application verified after a narrow change. |
Hand over a decision, not just a patch
Make the final record usable for the release owner.
Changed behaviour
Describe the original trigger, the resulting behaviour and the files involved. Attach the agreed evidence through the delivery channel available to the team.
Remaining work
List failed checks, assumptions and work outside the contract. Name the person who can accept the change and identify any required follow-up.
Agree the way back before release
Record the known baseline and how to restore only the affected change without discarding unrelated work. If the agreed regression trigger occurs, the release owner can use that plan and repeat the relevant checks. Production deployment, changes to credentials and destructive operations require explicit authorization. A patch that passes its local checks is ready for a release decision; it is not automatically a deployed result.
Before assigning development work
Can I connect a repository with one click here?
The website has no one-click Git importer. Confirm how repository materials reach the runtime and which permissions the assignment needs.
What if execution tools are unavailable?
It can propose a patch or review supplied material. Builds, tests and browser checks that did not run remain explicitly unverified.
Does opening an Agent publish the change?
Opening the workspace triggers no release. A human approves production changes; repository and deployment tools need separate access and authorization.
Prepare a bounded Agent assignment
Check plans and Agent access from your account overview. Bring the contract and confirm runtime tools before implementation.
Open your account overview