Progress bar

# Implement Progress bar in your agent

## Objective
Implement Progress bar for this verified behavior: A visual and semantic indicator for task completion: it exposes a value within a known range when measurable and remains indeterminate when no reliable value exists.

## Prerequisites
- Inspect the repository, design system, and existing tests first.
- Preserve unrelated changes and keep the file scope bounded.
- Confirm that Progress bar matches the need before writing code.

## Required behavior
- The current value advances within a known minimum and maximum without excessive announcements.
- The content region exposes its busy state while a separate visual indicator remains redundant.

## States to cover
- Upload idle
- Upload with measured progress
- Upload without a reliable estimate
- Upload cancelled
- Upload complete

## Accessibility
- ARIA role: progress
- The primary control or named region for Progress bar has a stable accessible name from visible text or an explicit programmatic label; placeholder text and tooltips are not names.
- The progress indicator does not receive focus; focus remains on the operation controls or current task.
- It ends only on completion, failure, or explicit cancellation and is replaced by the matching final status.
- The accessible name and current value are exposed; announcements are paced to avoid reading every tiny update.
- Tab skips the noninteractive bar
- Tab reaches a separate Cancel action when available

## When not to use
- The value is guessed or jumps unpredictably
- Only the content shape, not completion, matters

## Acceptance criteria
- Minimum, maximum, and current value are real
- A visible or accessible label names the operation
- Updates are understandable rather than noisy
- Completion, failure, and cancellation have final states

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Web platform
• Requires · Access to the repository, design system, and tests

# Verify Progress bar after implementation

## Objective
Audit the Progress bar implementation against its behavior, states, and accessibility requirements without changing it automatically.

## Checks
- Replay the smallest representative journey.
- Check keyboard behavior, focus, accessible name, and announcements.
- Tie each gap to a specific acceptance criterion.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:9c6137e2f9cd57e453ba01e247450339be6eb8478e35cc7d5ce22ba5c5f474f2

# Debug Progress bar in your agent

## Observed symptom
[DESCRIBE THE SYMPTOM HERE]

## Observable checks
- Reproduce the issue with the smallest relevant journey.
- Compare behavior with the documented states and transitions for Progress bar.
- Verify keyboard behavior, focus, accessible name, and announcements.

## Possible causes
- The chosen primitive does not match the expected behavior.
- A state, transition, or focus return is missing.
- A neighboring component captures an event or hides an accessible signal.

## Bounded corrections
- Fix the reproduced cause without recreating neighboring components.
- Preserve the public contract and add a focused regression test.
- Do not install dependencies or change remote state without authorization.

## Final verification
- Minimum, maximum, and current value are real
- A visible or accessible label names the operation
- Updates are understandable rather than noisy
- Completion, failure, and cancellation have final states

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Web platform
• Requires · Access to the repository, design system, and tests

# Prevent the Progress bar regression

## Objective
Turn the reproduced cause into a focused regression test and compare Progress bar with neighboring concepts before widening the fix.

## Checks
- Prove that the test fails before the fix.
- Prove that it passes after the bounded fix.
- Verify that no neighboring component changed behavior.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:2feb1cc80fc0079cee31339c0dde05cccd5b7d7c1d8eacb9a8fdc7fc5da2c519