Module triage 

Client-side triage and next-action derivation over /api/view: a branch-triage and agent-state view of what needs attention.

Both functions are pure folds of the view JSON the node already serves. Deriving client-side rather than adding endpoints keeps the ACL story unchanged: the node filters /api/view per credential (D29), so a triage computed from the filtered document can only see what its caller may see. The cost is honesty bookkeeping: a ref missing from the response is either not created yet or not granted — indistinguishable by design — so rows carry landed: null rather than a guess when the destination ref is not visible.

Output is bounded: every list is capped at LIST_CAP rows ranked most-actionable-first, and every truncation is marked in-band with an omitted count, never silent.

Constants

LIST_CAP

Cap on every list in a derived document. Twenty rows of the most actionable material bounds the token cost of a poll; the full detail is always one choir view away.

Functions

funnel

The contribution funnel, derived from the view.

next_actions

Derives one bounded next-actions document for channel from a /api/view response fetched from api: what you owe others, what your own changes need, and what you are waiting on, ranked. Command strings carry <key-file> (and other placeholders) literally where only the caller knows the value.

triage

Derives the triage document from a /api/view response: every review and change classified into a bucket, ranked most-actionable-first, capped and counted.