Skip to content

A12 — Creator submission and payout history views ​

Status: blocked. Updated: 2026-09-06. Assigned agent: unassigned. Implementation PR: none.

Issues and acceptance covered ​

#51. The acceptance boundary is the implementation scope and completion checks below; see the issue acceptance matrix for parent coverage. Shared definitions: financial contract; proof anchors: evidence index.

Dependencies and blockers ​

A04/A05 backend contracts and A11 shared exact amount/coverage primitives. Payout eligibility/request workflow stays with payout owner.

Repository and expected files ​

Frontend: features/submissions, features/payouts, corresponding screens/submissions and screens/payouts; history summary/row/cards and API/types/hooks.

Existing behavior and verified gap ​

Submission summary totals only loaded 10 rows; local search not full dataset. Payout history receives 50 undrillable rows and net amount only; page does not explain campaign allocation or unknown/released history (E16/E17).

Proposed implementation boundary ​

Use full-filter summaries independent of page, server filters/cursors and entry-position details. Render operation/allocation history and gross/net/fee/status/time/coverage from API. Keep pending review count distinct from pending earnings. No client estimate of missing campaign allocation, net eligibility or finality date.

Expected API / data contract ​

Consume additive history/summary DTOs and preserve explicit legacy fallback. Date filters declare completion versus accrual basis. Request endpoint and payment-method/tax controls unchanged.

Required tests ​

More than 10 submissions/50 payouts; pagination/search with stable summary; paid source now denied; unknown/released state; crosscampaign drilldown; missing completedAt and legacy allocation; no accidental string concatenation; 403/503/error retry. Focused API/formatter tests, lint/build, manual fixture.

Suggested agent tier ​

Lower-cost UI/wiring agent; smart review of gross/net, page versus global semantics and history reconciliation.

Expected PR boundary and reason ​

One creator history UI PR stacked on A04/A05/A11. Coherent history contract avoids mixing current performance estimates into payment history. Unlocks A17. Keep compatibility additive, avoid unrelated cleanup, and list exact stacked commits and later units unlocked in the PR. If observed scope grows beyond this boundary, update the plan before splitting or adding work.

RBAC requirements / TODOs ​

Preserve authenticated creator shell and own endpoints. TODO(RBAC): Keep history scoped to current creator; do not reuse staff financial DTO or expose provider IDs/destinations through drilldown.

Completion and reconciliation checks ​

Full-filter summary stable when paging. Paid history agrees with own paid positions on same date/basis; allocation sum shown once. Missing evidence visibly remains incomplete, never a synthetic date/zero.

Record actual tests, source schema/contract versions, PR/merge SHA, manual evidence and residual coverage before changing status to review/complete. Any unexpected migration must first satisfy the migration gates; never bundle upstream financial writer work into this analytics unit.