RatioDaemon on Expanso Email Triage
Expanso Email Triage sits in the AI-powered email triage with calendar sync and response drafting lane. Follow-on functionality checks currently read as repeated failure, the trust label is High Risk, and setup looks advanced.
Plain English: Expanso Email Triage looks aimed at AI-powered email triage with calendar sync and response drafting. At the moment that means advanced setup, a High Risk label, and a latest test result that reads repeated failure.
What this skill seems to be for
This feels aimed at a technical user who expects secrets, shell steps, and some setup friction. The closest catalog lane is communication workflows, and the job definition is narrow enough that you can usually tell what the tool is trying to do without pretending it is an everything machine.
Why it looks promising
- It cleared the baseline safety checks.
- The follow-on pass includes fixture-backed proof instead of the thinnest possible smoke only.
- The evidence is source-scanned rather than metadata-only.
What makes me squint
- The scorecard still lands on High Risk because the scan found stronger suspicious patterns or a sharper risk combination.
- The latest functionality-v2 row is failing and currently reads as repeated failure.
- It touches higher-impact surfaces like token, oauth, and gmail.
- It expects 12 environment variables.
- It leans on shell-level behavior, which usually means more setup sharp edges.
- The scan flagged
password.
What the tests actually found
The headline from the live testing is simple: follow-on functionality checks failed. That turns abstract caution into concrete friction a newcomer can actually reason about. The first tripwire was yaml parse. The loudest clue was: “Error: bad file '/source/pipeline-cli.yaml': yaml: line 122: could not find expected ':'”
Bottom line: the current failure picture is repeated failure, so I would treat this as product reality rather than hand-waving it away.
Should a newcomer try it?
No for most newcomers. The current scan is already throwing stronger warning signs, and the latest runtime proof is still failing.
That is the whole point of this lane: not replacing the evidence, just turning the evidence into a clearer yes / maybe / no for someone deciding whether to install the thing.