feat: conditions for automations

.github/ISSUE_TEMPLATE/bug-issue.md

@@ -1,10 +1,9 @@
 ---
 name: Bug Report
 about: Find something broken or odd? Report it here.
-title: ''
+title: ""
 labels: bug
-assignees: ''
-
+assignees: ""
 ---
 
 <!--
@@ -14,6 +13,7 @@ To fill out the report, please fill out each section below. If a section isn't a
 -->
 
 ### What went wrong, step-by-step?
+
 1.
 2. ...
 

.github/ISSUE_TEMPLATE/feature-issue.md

@@ -1,19 +1,21 @@
 ---
 name: Feature Issue
 about: Suggest a new feature at a high level.
-title: ''
+title: ""
 labels: feature
-assignees: ''
-
+assignees: ""
 ---
 
 ## Motivation
+
 <!-- Why are we building this? -->
 
 ## Requirements
+
 <!-- What does this accomplish? -->
 
 ## Acceptance Criteria
+
 <!-- What technical work must be completed for this to be accepted? -->
 
 <!-- ## Extra work -->

DEVELOPMENT.md

@@ -4,14 +4,14 @@
 
 Docker-compose provides a means to run all the code components as containers. It has these advantages:
 
--   more realistically emulating the setting where this code is run in production.
--   less contamination of environment, so spurious failures (or successes) can be avoided.
--   easy to boot from nothing without system dependencies except Docker
+- more realistically emulating the setting where this code is run in production.
+- less contamination of environment, so spurious failures (or successes) can be avoided.
+- easy to boot from nothing without system dependencies except Docker
 
 With disadvantages:
 
--   doesn't support hot-reloading
--   slightly slower iteration due to `docker build` between runs
+- doesn't support hot-reloading
+- slightly slower iteration due to `docker build` between runs
 
 With these properties, this is useful for end-to-end tests and locally verifying that the code works when removed from some of the fast-iteration features of `next.js`, such as
 JIT compilation. Because a `docker build` is needed to build the containers to run, hot-reloading is not available in this environment; so faster iteration
@@ -39,17 +39,17 @@ you can now address on `localhost:3000` as before. note that `pnpm dev` uses the
 
 Two hooks are defined using `husky` and stored in `.husky`.
 
--   The first runs Prettier on commit
--   The second runs a type-check before pushing. Since our deployment setup builds on each push, the intent here is to not trigger a build with known type errors.
+- The first runs Prettier on commit
+- The second runs a type-check before pushing. Since our deployment setup builds on each push, the intent here is to not trigger a build with known type errors.
 
 Sometimes you want to push up changes even though there is a type error. To do so, include `--no-verify` at the end of your command. For example: `git push origin main --no-verify`.
 
 ## Turborepo race conditions
 
 We currently have a race condition where dev will sometimes fail because we can't specify the order of dependency builds. Tied to the fact that we clean out the dist folder on build, but upstream packages are watching dist.
 
--   https://github.com/vercel/turbo/discussions/1299?sort=top?sort=top
--   https://github.com/vercel/turbo/issues/460
+- https://github.com/vercel/turbo/discussions/1299?sort=top?sort=top
+- https://github.com/vercel/turbo/issues/460
 
 `core` depends on `ui` which depends on `utils`. `utils` often takes longer to build than it does for `ui` to start building, which causes an error to be thrown because `utils` d.ts file has been cleared out during its build and hasn't been replaced yet. This generates an error, but is quick to resolve, so doesn't break actual dev work from beginning. It does make the console output messier though.
 
@@ -137,4 +137,4 @@ Images tagged with a SHA alone should be idempotently built, but `-dirty` can be
 
 **TODO:**
 
--   [ ] allow deploying without a rebuild, so that a rollback is convenient
+- [ ] allow deploying without a rebuild, so that a rollback is convenient

README.md

@@ -30,10 +30,10 @@ root
 └── ...
 ```
 
--   `core` holds the primary web application.
--   `infrastructure` holds the deployment infrastructure for the centrally hosted version of PubPub Platform run by the Knowledge Futures team.
--   `jobs` holds the job queueing and scheduling service used by `core`.
--   `packages` holds libraries and npm packages that are shared by `core`, `jobs`, and `infrastructure`.
+- `core` holds the primary web application.
+- `infrastructure` holds the deployment infrastructure for the centrally hosted version of PubPub Platform run by the Knowledge Futures team.
+- `jobs` holds the job queueing and scheduling service used by `core`.
+- `packages` holds libraries and npm packages that are shared by `core`, `jobs`, and `infrastructure`.
 
 To avoid inconsistencies and difficult-to-track errors, we specify a particular version of node in `/.nvmrc` (currently `v22.13.1`). We recommend using [nvm](https://github.com/nvm-sh/nvm) to ensure you're using the same version.
 
@@ -103,10 +103,10 @@ If you have a feature request, idea, general feedback, or need help with PubPub,
 
 In the coming weeks, we'll be developing more thorough contribution guides, particularly for contributors interested in:
 
--   Extending PubPub Platform with new Actions and Rules
--   Extending the PubPub Platform API
--   Contributing to self-hosting scripts and guides on common cloud hosting
--   Contributing documentation for developers or users
+- Extending PubPub Platform with new Actions and Rules
+- Extending the PubPub Platform API
+- Contributing to self-hosting scripts and guides on common cloud hosting
+- Contributing documentation for developers or users
 
 For now, you can browse the [issue list](https://github.com/pubpub/platform/issues) and comment on any issues you may want
 to take on. We'll be in touch shortly
@@ -117,10 +117,10 @@ Our preferred practice is for contributors to create a branch using the format `
 
 Request names should be prefixed with one of the following categories:
 
--   fix: for commits focused on specific bug fixes
--   feature: for commits that introduce a new feature
--   update: for commits that improve an existing feature
--   dev: for commits that focus solely on documentation, refactoring code, or developer experience updates
+- fix: for commits focused on specific bug fixes
+- feature: for commits that introduce a new feature
+- update: for commits that improve an existing feature
+- dev: for commits that focus solely on documentation, refactoring code, or developer experience updates
 
 Request descriptions should use to our Pull Request template, including a clear rationale for the PR, listing any issues resolved, and describing the test plan for the request, including both tests you wrote and step-by-step descriptions of any manual QA that may be needed.