---
id: w3/m1/t004
title: Log-type split — application vs request logs
worker: worker3
status: done
estimate: 30m
depends_on: [w3/m1/t001]
---

## Objective

Model Render's `Application logs` / `Request logs` filter: label each line with its type and let the `type` query param filter on it.

## Context

- `application` = pod stdout/stderr (already available from t001).
- `request` = HTTP access logs, sourced from Traefik (the ingress). Traefik must be configured to emit access logs; if not yet wired in the cluster, expose the `request` filter and label but return empty with a documented note (source deferred to platform/w1).
- Decision recorded in `docs/ADR010-observability.md` (`w3/001`).

## Steps

1. Add a `type` field to normalized log lines; classify pod logs as `application`.
2. Wire the `type` filter (`all`/`application`/`request`) through `Core.Logs` and the REST/subscribe handlers.
3. If Traefik access logs are available, source `request` lines; else return empty for `type=request` and note the deferred source in `docs/ADR010-observability.md`.

## Files

- `operator/internal/api/logs.go`, `operator/internal/api/rest.go`, `docs/ADR010-observability.md`

## Acceptance criteria

- [ ] Lines carry a `type`; `type=application` filters correctly.
- [ ] `type=request` is accepted and labelled (sourced if Traefik access logs exist, else documented as deferred).

## Out of scope

- Enabling Traefik access logs in-cluster (platform/w1 dependency).
