Write user stories that pass the INVEST test instead of restating a feature as a story

Turn the feature idea below into properly scoped user stories, checked against the INVEST criteria — independent, negotiable, valuable, estimable, small, testable. Most "user stories" people write are just the feature restated in the "As a... I want... so that..." template with no actual scoping thought behind them; I want the real thing.

FEATURE IDEA
Let users export their order history and also get notified when an export is ready, plus let them schedule recurring exports.

USER TYPES INVOLVED
Individual shoppers exporting their own history; store admins exporting all customers' order history for accounting.

KNOWN TECHNICAL CONSTRAINT OR DEPENDENCY
Export generation runs as an async background job; there's no notification infrastructure yet, that would need to be built first.

For each user type, draft the story in the standard format, then explicitly check it against each INVEST letter and flag any that fail: Independent — can this ship and be tested without another story shipping first, or does it silently depend on one (name the dependency if so, rather than ignoring it). Negotiable — is this a description of value and outcome, or does it specify implementation details that should be left to the team building it (rewrite to remove implementation prescriptions if present). Valuable — does completing this story produce something a real user would notice or benefit from, or is it a technical task disguised as a story (technical tasks belong on the backlog as tasks, not as user-facing stories — say so if this is actually one). Estimable — is there enough clarity here for a team to size it, or is a key unknown blocking estimation (name the unknown). Small — could this reasonably be finished within one sprint, or does it bundle multiple distinct pieces of value that should split into separate stories (if so, split it and show the split). Testable — is there a clear way to know when this is done, even before acceptance criteria are written out in full.

If a story fails Independent or Small, do not just flag it — actually perform the split or note the sequencing dependency explicitly, since flagging without resolving leaves the same scoping problem for someone else to solve later.

WHAT NOT TO DO
Do not write a story so vague it would pass every INVEST check trivially by saying nothing concrete ("As a user, I want a good experience"). Do not invent acceptance criteria in this pass — that's a separate step; keep this focused on story scoping.

OUTPUT FORMAT
For each story: the story text, then a short INVEST check as a bullet under each of the six letters (pass or the specific issue found), then, where a split or dependency was found, the resulting split stories or named dependency.