Daily workflow: reading code, planning, editing and testing

You will finish a small feature with source preservation, a diff and behavior checks. Outputs are illustrations, not a filmed result.

Official workflow and best-practice sources checked September 30, 2026 recommend giving Claude a way to verify work. For a visual feature, tests and actual browser inspection matter together.

Use the static index.html from the first-session lesson and preserve a copy or Git baseline. Confirm it contains a title, three units and an unset date. No framework, network service or user data is needed.

Start in the intended directory and suitable oversight mode. Read existing changes before making new ones so another person's work is not overwritten.

Inspect index.html only.
Plan a dependency-free button to show/hide the unit list.
Keep title, all three units and the unset date unchanged.
List accessibility behavior and tests. Do not edit yet.

Expected plan:

One file: index.html.
Native button toggles list visibility.
aria-expanded reflects visibility; keyboard activation works.
Tests: two clicks, Enter/Space, narrow viewport and preserved content.
No dependency, storage or publication.

Check scope before moving to implementation. A package installation is not necessary for this feature.

Implement that plan in index.html only.
Preserve source facts. Add no external link, dependency, tracking or storage.
Show diff and distinguish tests run from tests still needed.
Do not commit, push or publish.

Inspect approval prompts. Then read the actual diff: list entries remain intact, date unchanged, no extra files or external requests.

Open the page locally. Click twice. Use Tab and Enter or Space. Inspect focus visibility and aria-expanded. Test a narrow viewport and read the title, button and date. A screenshot alone does not establish interaction; a passing script alone does not establish readable layout.

Review the change against the original plan.
Report failed or unrun checks before making any new edit.
Do not describe unobserved browser behavior as tested.

If a check fails, request a targeted repair and repeat affected checks. Do not regenerate the entire page for one focus issue.

Summarize changed file, preserved facts, actual checks and remaining limitations.
State explicitly that nothing was committed or published.

A useful handoff names evidence rather than merely “works”. Keep the reviewed file separate from untested alternatives.

Easy: reviewed plan

Produce the plan without writes. Success: exact scope and checkable criteria.

Intermediate: working feature

Implement and inspect. Success: toggle, keyboard, narrow layout and preserved facts all pass.

Challenging: minimal repair

Fix one failing check without touching valid parts. Success: focused diff and repeat verification.

Button looks right but fails: inspect handler and both state transitions.

Test command runs unknown code: inspect it before execution.

Extra dependency proposed: return to native HTML.

No browser available: mark visual/interaction checks unverified rather than claiming completion.

Unrelated diff: stop and separate prior changes from your feature.