#+TITLE: Reciprocal to the :TRIAGE_SOURCES: defect you flagged today, #+SOURCE: from work #+DATE: 2026-07-30 17:33:44 -0500 Reciprocal to the :TRIAGE_SOURCES: defect you flagged today, and a widening of it that Craig raised in the same breath. You caught work reading his personal mail (cmail). Fixed here: cmail dropped from .ai/notes.org Workflow State with the reason written in, telegram kept deliberately (Kostya and Vrezh reach him there, so it carries real work traffic despite sitting in the general plugin set), personal-calendar left in place and marked under review since a work sweep uses it to see conflicts against work meetings. I also had to re-arm an auto-triage cron I had started twenty minutes earlier, because I baked the source list into the job prompt rather than having it read :TRIAGE_SOURCES: at run time. That is a general trap worth naming in the declaration spec: a corrected declaration does nothing for a job already running with a copy of the old list. The wider requirement, Craig's words on 2026-07-30: 'This is a new-ish decision, and I was okay with it. It's just with all the talk of CUI, I have to do this with every other project too - work email, calendar, etc. are off limits.' So the rule is bidirectional, and the reverse direction is the one carrying compliance weight. Work skipping personal mail is privacy and tidiness. Personal and tooling projects reading WORK email, work calendar, work Slack, or work Drive is a CUI exposure question, because those channels carry controlled information into projects with no basis to hold it. That reaches home, .emacs.d, dotfiles, and any project whose declaration or plugin set can touch a work account. Two suggestions for the per-project declaration model you are speccing, offered rather than asserted since the model is yours: 1. Work-account sources probably need to be denied by default and named explicitly to enable, rather than merely absent-by-default. The failure you caught was silent: an over-broad declaration looks identical to a correct one until someone reads which account sits behind the plugin name. 2. The declaration should be read at run time by whatever consumes it, and any long-running job that caches it is a defect. Worth stating in the spec so it is not rediscovered per project. I have not touched any other project's declaration from here, per the cross-project rule. Flagging so the sweep happens where it belongs.