Remove the parked moderator project

The moderator was parked (not deployed, router route pointing at a
Lambda that is not maintained). Delete the project, its CI workflow and
dependabot entry, and drop it from the docs.

The router's button-click route now just acknowledges the request so
Slack does not retry, since nothing consumes those payloads anymore.

Author: alexeygrigorev

.github/dependabot.yml

@@ -17,14 +17,6 @@ updates:
       automator-deps:
         patterns: ["*"]
 
-  - package-ecosystem: "uv"
-    directory: "/moderator"
-    schedule:
-      interval: "weekly"
-    groups:
-      moderator-deps:
-        patterns: ["*"]
-
   # GitHub Actions used by the test/deploy workflows.
   - package-ecosystem: "github-actions"
     directory: "/"

.github/workflows/test-moderator.yml

@@ -4,35 +4,33 @@ A Slack moderation bot that runs on AWS Lambda. It lets you moderate from your p
 
 ## Repository layout
 
-The backend is **three independent Lambda projects**, each self-contained with
+The backend is **two independent Lambda projects**, each self-contained with
 its own source, build scripts, tests, and dependencies (`uv`). There is no
 shared root package — a change to one project never triggers another's CI.
 
 ```
 .
 ├── router/        🟢 active  — Slack entry point; routes events       (Test + Deploy Router)
 ├── automator/     🟢 active  — reaction & FAQ actions                 (Test + Deploy Automator)
-├── moderator/     ⚪ parked  — message-rate watch (not deployed)      (Test Moderator only)
 └── docs/                     — shared cross-project docs
 
 each project:
   <project>/
   ├── src/            # Lambda code (handler: lambda_function.lambda_handler)
   ├── scripts/        # package.sh, deploy.sh (+ publish.sh for router)
   ├── tests/          # unit tests (+ e2e mocked tests for automator)
-  ├── integration/    # integration tests (moderator only — LocalStack)
   ├── pyproject.toml  # self-contained deps
   ├── uv.lock
   └── README.md
 ```
 
 CI is per-project and path-filtered (`.github/workflows/test-*.yml` and
-`deploy-*.yml`): a project's tests run only when its files change, and the two
-active projects deploy only after their own tests pass on `main`.
+`deploy-*.yml`): a project's tests run only when its files change, and each
+project deploys only after its own tests pass on `main`.
 
 ## How the AuTomator Works
 
-The backend is split into **three Lambdas**, each with a clear responsibility.
+The backend is split into **two Lambdas**, each with a clear responsibility.
 
 ### 1. Router — Routes Slack events to the right Lambda
 
@@ -45,9 +43,9 @@ Its only job is to look at the incoming event and quickly decide where it should
 | **Reaction added by admin** | Automator |
 | **App mention** | Automator / FAQ Assistant |
 | **Message event** | Disabled for now |
-| **Button click** (e.g. from an alert) | Moderator |
+| **Button click** (e.g. from an alert) | Acknowledged only |
 
-The router and automator are separate on purpose: Slack expects a response within about 3 seconds. The router responds immediately and invokes the automator (or moderator) asynchronously, so longer work doesn’t time out.
+The router and automator are separate on purpose: Slack expects a response within about 3 seconds. The router responds immediately and invokes the automator asynchronously, so longer work doesn’t time out.
 
 ### 2. Automator — Acts based on emoji reactions by the admin and FAQ mentions
 
@@ -67,28 +65,16 @@ Examples:
 
 The automator can also send a relevant reply to the author of the message you reacted to, so they get clear feedback.
 
-### 3. Moderator — Watches message activity and helps you react quickly
-
-The moderator **does not** decide what is spam by itself. It:
-
-- Keeps track of how often people post (e.g. messages per user in a time window).
-- Notices patterns like “too many messages too quickly.”
-- When that happens, **alerts an admin** and provides **buttons** to act immediately.
-
-Those buttons let you **delete recent messages**, **deactivate a user**, or **ignore** the alert—all from Slack, including on your phone. So you get early signals and can intervene quickly without opening a laptop.
-
-For more on the moderator (DynamoDB, thresholds, LocalStack, etc.), see [moderator/README.md](moderator/README.md).
-
 ---
 
 ## Deployment
 
 Each project is self-contained under its own directory (`src/`, `scripts/`,
-`tests/`, `pyproject.toml`). CI deploys the two active projects automatically:
+`tests/`, `pyproject.toml`). CI deploys both projects automatically:
 each `Deploy *` workflow runs after its `Test *` workflow passes on `main`, and
 only when files under that project changed. Deploy in this order:
 
-**1. Router** (active)
+**1. Router**
 
 ```bash
 cd router
@@ -104,7 +90,7 @@ the repository variable `ROUTER_FUNCTION_NAME`; otherwise it defaults to
 The AWS credentials used by GitHub Actions need `lambda:UpdateFunctionCode`,
 `lambda:GetFunction`, and `lambda:GetFunctionConfiguration` for `slack-test`.
 
-**2. Automator** (active)
+**2. Automator**
 
 ```bash
 cd automator
@@ -115,30 +101,6 @@ bash scripts/deploy.sh
 Deployed by `.github/workflows/deploy-automator.yml` after `Test Automator`
 passes on `main`.
 
-**3. Moderator** (parked — not deployed)
-
-The moderator is currently parked: its router route is disabled and it has no
-deploy workflow. Its tests still run in CI (`Test Moderator`). To deploy it
-manually:
-
-```bash
-cd moderator
-bash scripts/package.sh
-bash scripts/deploy.sh
-```
-
----
-
-## Message Moderator (reference)
-
-- Tracks messages per user using **DynamoDB**.
-- Configurable threshold (default: 5 messages in 3 minutes).
-- Interactive admin alerts with action buttons.
-- Bulk message deletion and user deactivation.
-- LocalStack support for testing.
-
-See [moderator/README.md](moderator/README.md) and [moderator/SLACK_SETUP.md](moderator/SLACK_SETUP.md) for setup and details.
-
 ---
 
 ## Application Configuration

README.md

@@ -15,7 +15,7 @@
 lambda_function = importlib.util.module_from_spec(spec)
 
 # Register in sys.modules so patching works
-# This is needed because we load the module dynamically to avoid conflicts with moderator tests
+# This is needed because we load the module dynamically to avoid name conflicts with other projects' tests
 sys.modules['automator_lambda_function'] = lambda_function
 
 # Add automator to sys.path temporarily for imports within lambda_function