Dan Allan

I was too vague here; let me try again. Short of building a full scraper (or in addition to building a full scraper) we might run a service that regularly...

We'll need to think about this as a best-effort designation, as it's subject to judgement calls and ultimately serves the purpose of making changes comprehensible to humans. Here's a thought:...

I agree with that. Specifically, I notice that Mechanisms 1 and 3 are _compatible_ with the normal `RE(...)` usage, so if users follow the documentation, what the docs say will...

That is worth some thought. But wouldn’t there still be confusion? The scientist would have typed `trigger_and_read(...)` and wondered, “Why won’t this plan run?!” If they haven’t yet encountered the...

Or an option to the decorator: ```python @plan(if_run_alone_raise=IllegalMessageSequence("This needs to be used inside a plan that...")) def trigger_and_read(...): ... ``` But this approach would _only_ help users that were operating...

I solicited some feedback from Stuart Wilkins as well, who weighed in in favor of Mechanism 1 as well. Via Slack: > FWIW I really like [Mechanism] 1. Seems very...

Agreed with @awalter-bnl about `mv[r]`. In fact, the majority of plan stubs make sense on their own in a debugging context: `trigger`, `read`, etc. Only the state-management plans (create, save,...

Thanks, @tacaswell. A `@plan` decorator is starting to sound like a good idea _regardless_ of whether we bless people using it to auto-run plans. Let's move the discussion about the...

Well, let's get a temperature check on this. Before @tacaswell's comment, it sounded like his favorite is everyone else's _least_ favorite and vice versa. How do things stand in light...

I propose these initial steps. :+1:s? - Create the `@plan` decorator for all the other benefits discussed (assuming the stack depth increase doesn't turn out to be awful). - Document...