busya/ss-tools
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

semantic update

Browse Source
This commit is contained in:
busya
2026-02-08 22:53:54 +03:00
parent e6087bd3c1
commit 235b0e3c9f
71 changed files with 68034 additions and 62417 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
specs/018-task-logging-v2/spec.md
View File

@@ -53,6 +53,23 @@ As a developer, I want to use a dedicated logger that automatically tags my logs
---
### User Story 4 - Configurable Logging Levels (Priority: P1)
As an admin, I want to configure logging levels through the frontend so that I can control verbosity and filter noise during debugging.
**Why this priority**: Essential for production debugging and performance tuning.
**Independent Test**: Change the log level from INFO to DEBUG in admin settings, run a task, and verify that DEBUG-level logs (including belief_scope) now appear.
**Acceptance Scenarios**:
1. **Given** I am an admin user, **When** I navigate to Admin Settings > Logging, **Then** I see options for log level, task log level, and belief_scope toggle.
2. **Given** belief_scope logging is enabled, **When** I set log level to DEBUG, **Then** all belief_scope Entry/Exit/Coherence logs are visible.
3. **Given** belief_scope logging is enabled, **When** I set log level to INFO, **Then** belief_scope logs are hidden (they are DEBUG level).
4. **Given** I set task_log_level to WARNING, **When** a task runs, **Then** only WARNING and ERROR logs are persisted for that task.
---
### Edge Cases
- **High Volume Logs**: How does the system handle a task generating 10,000+ logs in a few seconds? (Requirement: Batching and virtual scrolling).
@@ -74,6 +91,11 @@ As a developer, I want to use a dedicated logger that automatically tags my logs
- **FR-009**: Task logs MUST follow the same retention policy as task records (logs are kept as long as the task record exists).
- **FR-010**: The default log level filter in the UI MUST be set to INFO and above (hiding DEBUG logs by default).
- **FR-011**: System MUST support filtering logs by specific keys within the `metadata` JSON (e.g., `dashboard_id`, `database_uuid`).
- **FR-012**: System MUST separate log levels clearly: DEBUG (development/tracing), INFO (normal operations), WARNING (potential issues), ERROR (failures).
- **FR-013**: `belief_scope` context manager MUST log at DEBUG level (not INFO) to reduce noise in production.
- **FR-014**: Admin users MUST be able to configure logging levels through the frontend settings UI.
- **FR-015**: System MUST support separate log level configuration for application logs vs task-specific logs.
- **FR-016**: All plugins MUST support `TaskContext` for proper source attribution and log level filtering.
## Clarifications
@@ -97,3 +119,5 @@ As a developer, I want to use a dedicated logger that automatically tags my logs
- **SC-002**: Database write overhead for logging does not increase task execution time by more than 5%.
- **SC-003**: 100% of logs generated by a task are available after a server restart.
- **SC-004**: Users can filter logs by source and see results in under 100ms on the frontend.
- **SC-005**: Admin users can change logging levels via frontend UI without server restart.
- **SC-006**: All plugins use TaskContext for logging with proper source attribution.