Photographer Portfolio Site
Make the smallest complete change that leaves the portfolio easy for its owner to edit and verify.
Start by locating the truth
Before editing, identify and report briefly:
- the website source directory;
- the content source used by the live pages;
- the owner-facing editor or admin, if one exists;
- the deployment target and whether the request includes publishing.
Inspect existing files and current changes before choosing an architecture. Preserve user work. Never infer permission to publish, change DNS, remove remote assets, or make a repository public.
Route the task
- For page structure, portfolio categories, admin fields, uploads, or media behaviour, read references/build-and-edit.md.
- For GitHub, hosting, domains, DNS, HTTPS, redirects, or Search Console, read references/publish-and-domain.md.
- For testing, deletion checks, responsive review, or handoff, read references/qa-and-maintenance.md.
Read only the references needed for the current request.
Operating boundaries
- Advice, drafting, editing, publishing, and infrastructure changes are separate permissions.
- Keep an existing visual direction unless the user asks for redesign.
- Keep front-end controls and owner-facing editor controls aligned. If the front end gains an editable category, label, image, video, SEO field, price, FAQ, navigation item, footer item, or button, update the editor in the same task unless the user explicitly excludes it.
- Store public portfolio content only. Do not put contracts, RAW files, complete client galleries, identity documents, private contact data, passwords, tokens, or API secrets in the repository or browser-delivered content.
- Treat names, locations, captions, image metadata, and admin-entered content as potentially public.
- Do not claim a change is live from a local check, a saved file, or a successful commit. Verify the stage actually requested.
- Prefer reversible edits and one visible next action when the owner must use an unfamiliar dashboard.
Evidence language
Use precise status labels when useful:
edited locally: files changed, not necessarily saved through the admin;saved: content persisted to the intended source;committed: recorded in Git, not necessarily deployed;deployed: hosting reports success, not necessarily visually correct;verified live: the public URL was loaded and the requested result was observed.
Stop when the requested stage is complete and supported by evidence.