Browser & annotations.

This is my first annotation on this page. When it arrives:

1. Tell me what element you received — tag, role, and your best description of what it is on the page.
2. Tell me which file and lines of code render it.
3. Restate my note as the change you're about to make (or the question you're about to answer).
4. If my note could mean two different things, pick the most likely, say so, and proceed — don't stall.

Then do it, reload the page, and tell me where to look.

I'm about to send you a stacked batch of annotations from a full-page sweep. Process it as one work order:

1. List every annotation in the batch: element, note, your read of the intent.
2. Check the set for conflicts and overlaps — notes that touch the same component, requests that contradict each other, changes that should share one implementation. Tell me what you found before coding.
3. Propose the implementation order and where you'll consolidate (one CSS change serving three notes beats three patches).
4. Execute, then reload the page and give me a checklist mapping each annotation to what changed, so I can verify them one by one.

Explain how you're currently handling input that arrives while you're working.

1. When I submit an annotation or message mid-run, does it queue for your next pause or steer you immediately? Tell me what my current default is if you can see it, and where I change it.
2. From this thread so far: did any of my messages queue or steer a run in flight? Reconstruct what happened to each.
3. Give me your honest recommendation: for annotation batches during long tasks, should I queue or steer — and what's the one situation where the other choice is right?

Bug-hunt contract for the annotations that follow:

Each note describes a visual defect as: what I see / what I expect / when it happens. For each one:
1. Diagnose before you fix — name the cause in one line (CSS specificity, state not updating, layout overflow, stale data, whatever it truly is).
2. Fix the cause, not the symptom. If the honest fix is bigger than the annotation implies, say so and ask before the big version.
3. After the batch: reload, then walk me through each defect — cause, fix, and exactly where to look to confirm it's gone.

Design-pass contract for the incoming annotation stack:

1. These notes are taste calls, not bug reports — implement them as a single coherent polish pass.
2. Where several notes point at the same underlying token (one spacing scale, one color variable, one type size), fix the token, not each instance — and tell me you did.
3. Respect the existing design system: if a note fights the project's established patterns, flag it instead of silently complying.
4. After: reload and summarize the pass in design language (what got tightened, aligned, unified), then list anything you flagged as fighting the system.

Copy-QA contract for the incoming annotations:

1. Notes with replacement text in quotes: apply verbatim, exactly as written.
2. Notes asking for improvement without text: rewrite in the page's existing voice — match the register of the copy around it, don't import a new tone.
3. Hard rule: touch ONLY annotated copy. No drive-by rewording of text I didn't click.
4. Watch the containers: if new copy threatens to wrap badly or overflow at mobile widths, shorten it and tell me.
5. After: a before/after table of every string you changed.

The annotations that follow are questions, not change requests. For each clicked element:

1. What it is: the component's job on this page, in plain language.
2. Where it lives: file, the key lines, and what data flows into it.
3. Why it's here: what breaks or degrades if it's removed.
4. Anything surprising: known quirks, tech debt, or history visible in the code or comments.

Change nothing. This is a guided tour, and the page is the map.