[argszero]

Summary

The roles table in docs/user-stories.md is what a deployer reads to decide who should be granted each role, and its third column is headed "key capabilities". The operator row listed what role=ops can see — runtime status, the point ledger, the user list — but not the one write it can perform: topping up a member's balance.

Three independent carriers say an operator can add points:

• src/routes/ops.rs:208 — the credits handler, documented in place as topping up permanent points for any user. It bumps quotas.balance and records a type='topup' transaction; it is routed at src/routes/mod.rs:716.
• docs/architecture.md:93 — lists POST /api/ops/credits under the operator view (role=ops).
• The view's own subtitle, view.ops.sub, names member top-ups in both the Chinese and the English pack.

The table also contradicts itself within the same block: the admin row directly above already lists top-ups, so two roles in this table can add points while the roster names only one of them. A reader who takes the roster at face value would grant role=ops believing it is read-only.

Change

One line in docs/user-stories.md: the operator's capability cell gains member top-ups, placed after the read capabilities and before the existing note that the view is operator-only. Every existing entry is kept as it was — including the point ledger, which the runtime handler really does compute, so it is not a gap.

Tests

• cargo fmt --check — clean
• cargo clippy --all-targets — no warnings
• cargo test — 579 passed, 0 failed

No gate reads docs/user-stories.md (the only mention anywhere under src/ is a source comment in gift.rs), so this is a documentation-only change with no test to add.

Related Issue

None — self-contained documentation fix.