# Website working agreements

This project follows the website brief and acceptance criteria we have agreed with its owner. Use the existing technology choices unless a concrete requirement calls for a change.

## How to work

- For a substantial feature, explain the proposed changes and verification plan before implementing it. Complete authorized local work in small, reviewable stages.
- Read the files relevant to the task. Keep unrelated pages and configuration intact.
- Explain new technical terms in plain language when reporting to the owner.
- Use the repository's website-design, clean-code, website-testing and website-security skills when their workflows apply.
- Record important decisions and unresolved content in the project's notes. Do not invent business facts, endorsements or publishing rights.

## Verification

- Inspect package.json to find the actual build, type-check and test commands. Do not invent a successful check or create a meaningless test just to make a command pass.
- Run checks appropriate to the change. Local tests use disposable fixtures and have no production access; run them and repair failures caused by the requested change without asking at every step.
- Verify visitor interactions in a browser when browser tools are available. Report checks that remain unavailable or incomplete.
- Show the owner a working local preview and summarise changed behaviour, evidence and remaining limitations.

## Credentials and publication

- Keep API keys and other secrets out of browser code, prompts, logs and Git. Store local secrets in ignored files or the chosen secret store.
- Local build and test work is authorized. Publishing the site, sending a real message, processing a payment or changing production data requires the owner's authorization for that action.
- Preserve a recoverable working version before release. Describe how to restore it.

These are starter agreements for a new tutorial project. Adapt them to the owner's actual requirements and existing authorization.