Show attachment quarantine and upload recovery clearly
Quotes look attached immediately even though the upload service can reject or quarantine them. Requesters submit before learning the reviewer cannot open the PDF.
- Focused work estimate
- 2h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Upload UX · State modeling · Untrusted input
Estimated field mix
- Frontend80%
- Security20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
The fictional Beacon operations team buys equipment through a browser form. Finance checks totals, departments, and quotes. Scope is one currency per request and an approval API contract; payments and accounting integration are excluded.
Setup prerequisites
- Synthetic department and cost-center directory
- Draft, submission, and approval API fixtures
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Uploading, scanning, accepted, rejected, and failed have distinct labels.
- Submission stays unavailable while a required quote is pending or rejected.
- Retry uses the upload operation contract; removal cancels pending UI work.
Implementation constraints
- Treat names and service messages as untrusted text; scanning uses API fixtures here.
Verification to include
- Advance an upload from scanning to accepted and verify submission becomes available.
- Reject a file and resolve a removed upload late; neither appears accepted.
Deliverables
- Attachment state component and upload fixture scenarios
Rollout and recovery
Pilot quote-required requests; disable new attachment submissions if accepted state cannot be reconciled.
Value of the work
For the engineer: Practice form modeling, exact totals, revision handling, and collaboration under failure.
For the team: Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.