refactor: type safety - replace any with proper types in middleware and services

[lionrooter]

Summary

• Add ResponseWithErrorContext interface to eliminate (res as any).__errorContext casts
• Replace dbOrTx: any with Db type in issues and projects services
• Replace permissionKey: any with proper PERMISSION_KEYS type
• Add Db type import to index.ts
• Replace (req as any) with typed request extensions in logger

Verification

• Zero new TypeScript errors (verified with npx tsc --noEmit)

Test plan

• npx tsc --noEmit passes
• Existing tests pass

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR bundles two logically distinct efforts under a "type safety refactor" label: (1) genuine any-elimination across server middleware, services, and routes, and (2) the introduction of a full new OpenClaw webhook adapter (packages/adapters/openclaw) along with Dockerfile, isLoopbackHost, and monorepo wiring changes. The type-safety improvements are well-executed — ResponseWithErrorContext, Db type substitutions, (typeof PERMISSION_KEYS)[number], and extracted helpers like sanitizeRecordField/assertNonEmptyString all read cleanly and carry no behavioral regression.

However, a few items deserve attention:

• Security — 0.0.0.0 incorrectly treated as loopback (server/src/index.ts:170): Treating the wildcard bind address as loopback allows local_trusted mode (unauthenticated) to start when the server is exposed on all network interfaces, defeating the guard that was placed there to prevent exactly that scenario.
• Dockerfile reproducibility risk: The server build step has been removed, so Docker images silently use pre-committed dist artifacts. The comment calls this a temporary workaround but provides no clear follow-up path.
• PR scope and description: Per the CONTRIBUTING.md guidelines, a PR should be one logical change with a meaningful description explaining the why, risks, and verification path. This PR mixes a new adapter, infra changes, and type refactoring — each of which would benefit from its own focused PR and description.

Confidence Score: 3/5

• Mergeable after addressing the 0.0.0.0 loopback security issue; the type-safety changes themselves are safe.
• The type-safety refactoring is correct and well-scoped. The score is reduced primarily due to the isLoopbackHost change, which weakens an authentication bypass guard by treating the all-interfaces bind address as a trusted loopback. The Dockerfile workaround is also a reliability concern. The PR description does not include the thinking path, rationale, or risk assessment required by CONTRIBUTING.md.
• server/src/index.ts (loopback security guard) and Dockerfile (pre-built dist workaround) need the most attention before merge.

Important Files Changed

Filename	Overview
server/src/index.ts	Adds Db type to ensureLocalTrustedBoardPrincipal, but also extends isLoopbackHost to treat 0.0.0.0 as loopback — a semantically incorrect and security-risky change.
server/src/middleware/error-handler.ts	Adds ResponseWithErrorContext interface and replaces (res as any) casts with typed variable — clean, correct type safety improvement.
server/src/middleware/logger.ts	Imports and uses ResponseWithErrorContext to replace (res as any) casts; adds typed routeReq intersection for route.path access — clean type safety improvement.
server/src/services/issues.ts	Replaces dbOrTx: any with Db type across helper functions; refactors status guard to a lookup table; extracts applyStatusSideEffects reuse. Logic is equivalent to prior code.
server/src/routes/access.ts	Replaces permissionKey: any with (typeof PERMISSION_KEYS)[number]; refactors canReplayOpenClawGatewayInviteAccept for readability with no logic change.
server/src/services/agents.ts	Extracts sanitizeRecordField, assertNonEmptyString, and asNullableString helpers; behavior is equivalent to prior inline code.
Dockerfile	Removes server build step from Docker image, relying on pre-built dist artifacts committed to the repo — documented as an intentional fork workaround but reduces build reproducibility.
packages/adapters/openclaw/src/server/execute.ts	New OpenClaw webhook adapter executor — sends wake payload via HTTP; logic is straightforward with proper timeout/abort handling.

Comments Outside Diff (1)

1. Dockerfile, line 72-73 (link)

   Pre-built dist artifacts in Docker reduce reproducibility

   Removing the pnpm --filter @paperclipai/server build step means the Docker image silently uses whatever server/dist/ files are committed to the repository. If those files are stale or were built with different settings (e.g., different env vars, different TS config), the running container will differ from the source code without any build error.

   The comment acknowledges this is a temporary workaround ("until the server build is confirmed stable in this image"), but there is no tracking ticket or acceptance criterion documented. Consider adding an explicit CI step or a TODO with a reference to the follow-up task so this workaround doesn't become permanent.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: Dockerfile
   Line: 72-73
   
   Comment:
   **Pre-built dist artifacts in Docker reduce reproducibility**
   
   Removing the `pnpm --filter @paperclipai/server build` step means the Docker image silently uses whatever `server/dist/` files are committed to the repository. If those files are stale or were built with different settings (e.g., different env vars, different TS config), the running container will differ from the source code without any build error.
   
   The comment acknowledges this is a temporary workaround ("until the server build is confirmed stable in this image"), but there is no tracking ticket or acceptance criterion documented. Consider adding an explicit CI step or a TODO with a reference to the follow-up task so this workaround doesn't become permanent.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: server/src/index.ts
Line: 170

Comment:
**`0.0.0.0` is not a loopback address**

`0.0.0.0` is the wildcard/unspecified address used for *binding* to all network interfaces — it is not a loopback address. When a server binds to `0.0.0.0`, it accepts connections from any network (LAN, VPN, internet depending on firewall), not only from localhost.

The `local_trusted` mode guard at line 387 exists specifically to prevent non-loopback deployments from bypassing authentication. Adding `0.0.0.0` here undermines that protection: an operator who starts the server with `host: "0.0.0.0"` and `deploymentMode: "local_trusted"` will expose a trust-bypassing endpoint to the entire network.

If the intent is to allow an all-interfaces binding for a local-only deployment, the check should be on the *incoming request's source IP* (confirmed loopback), not on the *bind address*. Alternatively, the deployment documentation should warn that using `host: "0.0.0.0"` with `local_trusted` requires an external firewall.

```suggestion
    return normalized === "127.0.0.1" || normalized === "localhost" || normalized === "::1";
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: Dockerfile
Line: 72-73

Comment:
**Pre-built dist artifacts in Docker reduce reproducibility**

Removing the `pnpm --filter @paperclipai/server build` step means the Docker image silently uses whatever `server/dist/` files are committed to the repository. If those files are stale or were built with different settings (e.g., different env vars, different TS config), the running container will differ from the source code without any build error.

The comment acknowledges this is a temporary workaround ("until the server build is confirmed stable in this image"), but there is no tracking ticket or acceptance criterion documented. Consider adding an explicit CI step or a TODO with a reference to the follow-up task so this workaround doesn't become permanent.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: "refactor: replace an..."}

[greptile-apps]

0.0.0.0 is not a loopback address

0.0.0.0 is the wildcard/unspecified address used for binding to all network interfaces — it is not a loopback address. When a server binds to 0.0.0.0, it accepts connections from any network (LAN, VPN, internet depending on firewall), not only from localhost.

The local_trusted mode guard at line 387 exists specifically to prevent non-loopback deployments from bypassing authentication. Adding 0.0.0.0 here undermines that protection: an operator who starts the server with host: "0.0.0.0" and deploymentMode: "local_trusted" will expose a trust-bypassing endpoint to the entire network.

If the intent is to allow an all-interfaces binding for a local-only deployment, the check should be on the incoming request's source IP (confirmed loopback), not on the bind address. Alternatively, the deployment documentation should warn that using host: "0.0.0.0" with local_trusted requires an external firewall.

Suggested change

	return normalized === "127.0.0.1" || normalized === "localhost" || normalized === "::1" || normalized === "0.0.0.0";
	return normalized === "127.0.0.1" || normalized === "localhost" || normalized === "::1";

Prompt To Fix With AI

This is a comment left during a code review.
Path: server/src/index.ts
Line: 170

Comment:
**`0.0.0.0` is not a loopback address**

`0.0.0.0` is the wildcard/unspecified address used for *binding* to all network interfaces — it is not a loopback address. When a server binds to `0.0.0.0`, it accepts connections from any network (LAN, VPN, internet depending on firewall), not only from localhost.

The `local_trusted` mode guard at line 387 exists specifically to prevent non-loopback deployments from bypassing authentication. Adding `0.0.0.0` here undermines that protection: an operator who starts the server with `host: "0.0.0.0"` and `deploymentMode: "local_trusted"` will expose a trust-bypassing endpoint to the entire network.

If the intent is to allow an all-interfaces binding for a local-only deployment, the check should be on the *incoming request's source IP* (confirmed loopback), not on the *bind address*. Alternatively, the deployment documentation should warn that using `host: "0.0.0.0"` with `local_trusted` requires an external firewall.

```suggestion
    return normalized === "127.0.0.1" || normalized === "localhost" || normalized === "::1";
```

How can I resolve this? If you propose a fix, please make it concise.