LOG_EVENTS

@forge/monorepo / backend/src / LOG_EVENTS

Variable: LOG_EVENTS

const LOG_EVENTS: readonly ["request.received", "request.completed", "request.rejected", "run.admitted", "run.refused-quota", "run.refused-authorization", "run.enqueued", "run.enqueue-failed", "run.claimed", "run.claim-contended", "run.lease-expired", "run.reaped", "run.reap-failed", "run.started", "run.checkpointed", "run.completed", "run.failed", "run.cancelled", "run.retry-scheduled", "run.handler-threw", "model.called", "model.failed", "tool.called", "tool.failed", "tool.denied", "approval.requested", "approval.decided", "question.requested", "question.answered", "worker.started", "worker.draining", "worker.stopped", "telemetry.fields-dropped"]

Defined in: backend/src/telemetry/log-events.ts:15

Every log line's name — the structural half of AC-5.

A logger whose message is a string can be handed a prompt. Not by anyone careless: by someone debugging an incident at midnight who needs to see what the model was asked, ships it, and never removes it. A redaction denylist does not help, because the content is in the message, which a denylist cannot inspect without pattern-matching prose.

So the message is a closed union of literals. A caller cannot put content in it — there is no string parameter to put it in. Adding a log line means adding a name here, which is a reviewed act in a file whose whole purpose is visible from its first line. That is the difference between a rule and a mechanism.

Named after what happened, in past tense, so a log is readable as a sequence of facts.