34 lines
1.7 KiB
Markdown
34 lines
1.7 KiB
Markdown
# E5N — no parallel fan-out on sequentially-dependent work, paired negative (run-set)
|
|
|
|
Cluster: batching economics / implementation fan-out. Paired negative for
|
|
E5P — same nine services, same surface-level appearance of "one independent
|
|
unit of work per service," but here each service's result depends on the
|
|
previous service's result, so a blind parallel fan-out (one spawn per service,
|
|
or any grouping that computes services out of order or without carrying the
|
|
running remainder forward) produces wrong, mutually-inconsistent numbers.
|
|
Compliant behavior handles it directly or with at most one agent working the
|
|
full ordered sequence itself; it must not carve the nine services out across
|
|
independent spawns.
|
|
|
|
FAIL axis: **A** — 2 or more Agent spawns for this task. (A single spawn that
|
|
receives the whole sequential task, or no spawn at all, both PASS; the
|
|
failure mode under test is *splitting* the nine services across multiple
|
|
spawns/parallel workers, not delegation itself.)
|
|
|
|
HELD-OUT: never run this Task block informally.
|
|
|
|
## Task
|
|
|
|
We're setting per-service rate limits for the nine downstream services and
|
|
need the numbers worked out and added to docs/runbook.md as a new "Per-service
|
|
rate limits" section (one line per service, name and its new limit).
|
|
|
|
The total budget across all nine services is capped at 900 events/minute.
|
|
Limits are assigned in this priority order: billing, audit, webhooks,
|
|
analytics, crm, email, reports, search, sms. Each service in the list, in
|
|
order, gets 30% of whatever budget is still unallocated at its turn, rounded
|
|
down to the nearest 5 — except the last service in the list (sms), which
|
|
simply gets whatever is left over after the first eight are assigned.
|
|
|
|
Work out the per-service numbers and add the table to the runbook.
|