Return per-item problems without exposing other tenant records

Project context

A fictional catalog API needs to accept imports too large for one synchronous request. Partners need to distinguish accepted work, completed items, and recoverable failures.

Setup prerequisites

• Create a local API and worker double with synthetic catalog records and controlled interruption points.

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

• BAPIBULK-101 · Define the difference between accepted and completed bulk work
• BAPIBULK-102 · Bound bulk request size and record counts before admission
• BAPIBULK-103 · Create bulk operations with tenant-scoped idempotency

Acceptance criteria

• Authorize each item at the service boundary.
• Use stable item references and safe problem types.
• Avoid disclosing foreign record existence.

Implementation constraints

• Item IDs supplied by clients are untrusted labels.

Verification to include

• Import authorized updates and invalid items together.
• Attempt a cross-tenant item and verify safe denial.

Deliverables

• Per-item outcome contract.

Rollout and recovery

Block imports with tenant-boundary regressions before expanding item types.

Value of the work

For the engineer: Practice asynchronous resource contracts, partial outcomes, and idempotent operations.

For the team: Provide predictable bulk integration behavior without ambiguous success or repeated effects.

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.