Opus Vault

Error Logging & Notification

3 min read

Decisions

  • Pending: Error log format — single file vs folder with daily files?
  • Pending: Severity levels for Phase 1 (simple vs structured)?

User Tasks

Summary

Capture and surface errors from hooks, scripts, and automation so failures don’t go unnoticed.

Problem / Motivation

As Opus adds automation (hooks, Python scripts, scheduled tasks), failures can happen silently. A hook might exit non-zero, a script might crash, a briefing might fail to generate — and nobody notices. Without error visibility, problems accumulate and trust erodes.

Proposed Solution

A simple error logging system that captures failures and surfaces them where the user will see them (briefings, session start recap).

  • Phase 1: Local error log file with integration into briefings and session recap.
  • Phase 2: Smart notifications via VPS/Telegram with severity levels and auto-retry.

Open Questions

No open questions.

Phase Overview

PhaseDescriptionStatus
Phase 1Local error log file + recap integration—
Phase 2Smart notifications (VPS, Telegram)—

Phase 1: Local Error Log —

Goal: Capture errors from hooks and scripts into a local log and surface them in briefings and session recaps.

File / FeatureDetailsOwnerStatus
Error log locationvault/30_daily/errors/ or single error-log.mdopus—
Log formatTimestamp, source (hook/script/skill), error message, contextopus—
Hook error captureWrapper for hooks that logs failuresopus—
Script error captureTry/except patterns in Python code that log to the error fileopus—
Briefing integrationFR-037 includes error summary if errors existopus—
Session start integrationFR-004 recap mentions recent errorsopus—

Phase 2: Smart Notifications —

Goal: Add severity levels, notification routing, and an error dashboard.

File / FeatureDetailsOwnerStatus
Severity levelsInfo / warning / error / criticalopus—
Notification routingCritical errors → Telegram (pairs with FR-032)opus—
Error dashboardSummary view in vault/00_system/opus—
Auto-retryFor transient failures, retry once before loggingopus—

Prerequisites / Gap Analysis

Requirements

RequirementDescription
REQ-1FR-037 (Daily Briefings) — as consumer of error data
REQ-2FR-009 (Python Scaffold) — for Python error handling patterns

Current State

ComponentStatusDetails
Hook infrastructuredoneHooks exist in .claude/hooks/
Python codebase—Not yet started
Briefing system—FR-037 not yet built

Gap (What’s missing?)

GapEffortBlocker?
Error log format definitionLowNo
Hook wrapper for error captureLowNo
Python error patternsMedYes (needs FR-009)

Test

Manual tests

TestExpectedOwnerActualLast
Failed hook logs error to known locationError entry in log fileopuspending-
Daily briefing includes error summary when errors existError section in briefingopuspending-
Session start recap flags recent errorsErrors mentioned in recapopuspending-
Error log is readable in ObsidianProper markdown formattingopuspending-

AI-verified tests

ScenarioExpected behaviorVerification method
………

E2E tests

ScenarioAssertion
……

Integration tests

ComponentCoverage
……

Unit tests

ComponentTestsCoverage
………

History

DateEventDetails
2026-02-27Promoted from idea to FRFrom vault/10_features/01_ideas/error-logging-notification.md
2026-02-27RenumberedFrom FR-022 to FR-049
2026-02-28ReformattedAligned to feature-request template

References

  • FR-037 (Daily Briefings) — consumer of error data
  • FR-009 (Python Scaffold) — error handling patterns
  • FR-004 (Session Start Recap) — surfaces errors at session start
  • FR-025 (VPS Deployment) — needed for Phase 2 notifications
  • FR-044 (Task Scheduler) — monitors scheduler task failures

Graph View

Backlinks