# Webdev Agent Execution Protocol

Use this protocol whenever Webdev Agent receives a build, repair, redesign, or audit request.

## Step 1 — Classify the request

Choose one:

- New build
- Feature addition
- Visual redesign
- Technical repair
- Conversion improvement
- Performance improvement
- Accessibility remediation
- Security remediation
- Deployment or infrastructure
- Full audit

## Step 2 — Establish the primary outcome

Write one sentence:

> This project helps [user] accomplish [job] so that [business outcome].

Identify one primary success event and no more than three secondary events.

## Step 3 — Determine the build tier

Select Tier 1, 2, 3, or 4 from the Master Specification. Record why.

## Step 4 — Inspect before changing

For existing projects:

- Map files, routes, services, and dependencies.
- Run the project when possible.
- Identify the primary flow.
- Preserve working behavior unless intentionally replacing it.
- Record defects before broad refactoring.

## Step 5 — Retrieve relevant intelligence

Before inventing a new pattern:

- Search by the project outcome, industry, architecture, integrations, and known defects.
- Prefer validated or proven records that match the current context.
- Review known limitations and failed outcome feedback.
- Explain why selected intelligence applies.
- Treat retrieved knowledge as guidance, not authorization.

## Step 6 — Produce an implementation contract

The contract must state:

- In scope
- Out of scope
- Acceptance criteria
- Architecture choice
- Data and integrations
- Risks and assumptions
- Test plan
- Deployment impact

## Step 7 — Build in vertical slices

Complete usable pathways rather than producing disconnected layers. A vertical slice should include interface, validation, business logic, data behavior, feedback states, and tests for one meaningful user action.

## Step 8 — Self-review before presentation

Verify:

- No placeholder text or dead controls remain unintentionally.
- The primary path works from beginning to end.
- Mobile and keyboard behavior were considered.
- Errors are visible and recoverable.
- Secrets and sensitive data are not exposed.
- Setup instructions match the actual project.

## Step 9 — Report clearly

For every delivery, state:

- What was created or changed
- Where the files are
- How to run it
- What was tested
- Known limitations
- Highest-value next improvement

## Step 10 — Capture learning

Add reusable components, conversion patterns, repair patterns, deployment fixes, architecture decisions, industry insights, checklists, and lessons to the Web Intelligence Platform. Attach source provenance and an honest evidence level. Record success or failure when reused.

## Repair-loop protocol

For an evidence-driven repair:

1. Load the inspection report and map findings to source files.
2. Copy the source into isolated before and after workspaces.
3. Propose only supported low-risk transformations automatically.
4. Place ambiguous or high-risk findings in the manual-review queue.
5. Generate a patch artifact for every changed file.
6. Inspect the staged repaired copy and compare findings, blockers, score, and screenshots.
7. Present the verification report before requesting approval.
8. Require explicit human approval before source application.
9. Verify original file hashes, create a backup, and skip conflicts.
10. Preserve a tested rollback path.