admin/illusory-mapp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

added file domain logic, updated drizzle package

Browse Source
This commit is contained in:
user
2026-03-01 05:56:15 +02:00
parent 1c2584df58
commit 5a5f565377
27 changed files with 5757 additions and 223 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
AGENTS.md
View File

@@ -102,11 +102,12 @@ Errors are **values**, not exceptions. The codebase uses Result-style handling.
### Current Conventions
1. **Logic package** — Uses `neverthrow` (`ResultAsync`, `okAsync`, `errAsync`) for async operations that may fail.
2. **`@pkg/result`** — Provides `Result<T, Err>`, `ERROR_CODES`, and `tryCatch()`. The `Result` type is legacy; the project may move toward Effect. Use `ERROR_CODES` for consistent error codes.
3. **`getError()`** — From `@pkg/logger`. Use at boundaries when converting a thrown error to an `Err` object:
2. **`@pkg/result`** — Provides `Result<T, Err>`, `ERROR_CODES`, and `tryCatch()`. The `Result` type is legacy; So don't reach for it primarily.
3. Use `ERROR_CODES` for consistent error codes.
4. **`getError()`** — From `@pkg/logger`. Use at boundaries when converting a thrown error to an `Err` object:
`return getError({ code: ERROR_CODES.XXX, message: "...", description: "...", detail: "..." }, e)`.
4. **Domain errors** — Each domain has an `errors.ts` that exports error constructors built with `getError`. Use these instead of ad-hoc error objects.
5. **Check before use** — Always check `result.isOk()` / `result.isErr()` before using `result.value`; never assume success.
5. **Domain errors** — Each domain has an `errors.ts` that exports error constructors built with `getError`. Use these instead of ad-hoc error objects.
6. **Check before use** — Always check `result.isOk()` / `result.isErr()` before using `result.value`; never assume success.
### Err Shape
@@ -119,6 +120,7 @@ type Err = {
detail: string;
actionable?: boolean;
error?: any;
// Flexible, but more "defined base fields" in the future
};
```
@@ -155,26 +157,15 @@ Shared state (`user`, `session`, `breadcrumbs`) lives in `$lib/global.stores.ts`
## 5. Processor App
The processor is a **Hono** server intended for **background workers** and async jobs. Its structure is still evolving.
The processor is a **Hono** server intended for **background work** and async jobs. Its structure is still evolving and it is to be updated soon.
### Current State
- Minimal Hono server; no BullMQ or job processors yet.
- When workers are added, processing logic should live under `src/domains/<domain>/` and call into `@pkg/logic` controllers and repositories.
- HTTP routes will expose internal APIs (e.g. task status, webhooks), secured (e.g. API key), for use by the main app or external services.
- Async work should be triggered by calling the processor HTTP API, not by importing job queues in the main app or logic package.
### Conventions (when implemented)
- The worker processes jobs; do not block it with long-running HTTP logic.
- Job payloads should be validated before processing.
- Follow existing domain patterns for controllers and repositories.
When logic is added, processing logic should live under `src/domains/<domain>/` and call into `@pkg/logic` controllers and repositories.
---
## 6. Observability
The stack uses **OpenTelemetry** end-to-end for traces, logs, and metrics, shipped to a local **SigNoz** instance (via OTel Collector) in development.
The stack uses **OpenTelemetry** end-to-end for traces, logs, and metrics, shipped to a **SigNoz** instance (via OTel Collector).
### How it fits together