Render filter (conditions → the rule table)

One table shape for every response that shows the user a filters.js rule, so a rule reads the same whether it is about to be written, was found matching a message, or is only being proposed.

Input is one or more conditions and the actions of the entry each belongs to. Output is a markdown table, one row per condition, followed by a one-sentence plain-language reading of it.

Examples in this file are invented. The privacy rule in AGENTS.md applies to anything written into committed files; check a new example against the real spec before committing it.

The table

Six columns — Change, Sender, Subject, List-Id, Actions, Replaces — in that order:

Change	Sender	Subject	Actions	Replaces
widen	*@acme.com	Weekly digest	Newsletters, archive	news@acme.com
add	*@*.acme.com	Weekly digest	Newsletters, archive	—

Mail from Acme whose subject contains "Weekly digest" gets the Newsletters label and skips the inbox.

• Change — what is happening to the spec: add, widen, update, remove, or duplicate (the row already exists; nothing is written).
• Sender / Subject / List-Id — the exact values in the spec, in backticks, — when the condition has no such criterion. A glob is shown as the glob, not paraphrased.
• Actions — the entry's labels, then its inbox effect: archive, trash, or nothing when the mail stays in the inbox; then never spam when the entry files into neverspam.
• Replaces — the condition(s) this row supersedes; — when it supersedes none.

Drop a column no row uses. A column where every row would read — carries nothing, so it is left out rather than rendered empty — which is why most tables show three or four columns, not six. The order of the ones that remain never changes. Dropping is per table, not per row: one row with a List-Id keeps the column for every row.

A condition's comment goes in the plain-language sentence, not a column.

The sentence

One sentence under the table, reading the rule in plain language: which mail, and what happens to it. It is what the user checks the table against, so it states the rule's effect rather than restating its cells — "gets the Newsletters label and skips the inbox", not "Newsletters, archive".

For several rows that are one rule seen from two angles (a widen and the add beside it), one sentence covers them both. For rows that are genuinely different rules, one sentence each.

Which columns a caller uses

The columns are one vocabulary; a caller fills the ones its job gives it and the drop rule removes the rest. Never invent a column outside the six — a verdict, a reason, an entry index belongs in the prose around the table.

• Writing a rule (filter, archive) fills Change on every row, and Replaces on a widen or update.
• Explaining a rule that already exists (match) writes nothing, so Change and Replaces are empty on every row and drop out. What is left says what the rule matches and what it does. Which entry a row came from, and whether it fired in sieve, in Gmail or neither, go in the prose.
• Proposing a fix fills Change with what the edit would be, and says in the prose that nothing has been written yet.