ent#297 / PR #1893 added validation and an audit entry (ops_settings_change) to PUT /api/settings/ops/config. It did not add one to POST /api/settings/ops/reset, but both the PR body and the architecture.md prose it landed read as though it covered both:
Writes are audited. Neither this endpoint nor /ops/reset logged anything, while the generic PUT /{key} directly above them does…
…neither this route nor /ops/reset logged anything before…
reset_ops_settings (src/backend/routers/settings.py:2661) is admin-only, deletes rows for every key in OPS_SETTINGS_DEFAULTS, and writes no audit entry.
Scope of what's still unlogged
The retention claim in that prose does hold — reset correctly continues over RETENTION_OPS_KEYS (#1638), so it cannot shrink a retention window. What it can silently reset with no trace:
ssh_access_enabled — the security-relevant one; resetting it changes whether ephemeral SSH credentials can be minted at allops_context_warning_threshold / ops_context_critical_thresholdops_idle_timeout_minutes, ops_max_execution_minutes, ops_alert_suppression_minutesops_cost_limit_daily_usdops_health_check_intervalops_log_retention_days
So the asymmetry ent#297 objected to still exists one route over: the generic PUT /{key} audits, /ops/config now audits, /ops/reset doesn't.
Fix
Mirror the /ops/config call — platform_audit_service.log(event_type=AuditEventType.CONFIGURATION, event_action="ops_settings_reset", …) with the reset and skipped key lists in details (keys and counts only; the values are being deleted, and none of these keys is a secret). request is already a parameter on the handler, so actor_ip / endpoint / request_id need no signature change.
Either that, or narrow the two prose claims to /ops/config — but auditing it is four lines and closes the class rather than documenting around it.
Acceptance
Follow-up to trinity-enterprise#297 · surfaced in review of #1893.
ent#297 / PR #1893 added validation and an audit entry (
ops_settings_change) toPUT /api/settings/ops/config. It did not add one toPOST /api/settings/ops/reset, but both the PR body and thearchitecture.mdprose it landed read as though it covered both:reset_ops_settings(src/backend/routers/settings.py:2661) is admin-only, deletes rows for every key inOPS_SETTINGS_DEFAULTS, and writes no audit entry.Scope of what's still unlogged
The retention claim in that prose does hold — reset correctly
continues overRETENTION_OPS_KEYS(#1638), so it cannot shrink a retention window. What it can silently reset with no trace:ssh_access_enabled— the security-relevant one; resetting it changes whether ephemeral SSH credentials can be minted at allops_context_warning_threshold/ops_context_critical_thresholdops_idle_timeout_minutes,ops_max_execution_minutes,ops_alert_suppression_minutesops_cost_limit_daily_usdops_health_check_intervalops_log_retention_daysSo the asymmetry ent#297 objected to still exists one route over: the generic
PUT /{key}audits,/ops/confignow audits,/ops/resetdoesn't.Fix
Mirror the
/ops/configcall —platform_audit_service.log(event_type=AuditEventType.CONFIGURATION, event_action="ops_settings_reset", …)with theresetandskippedkey lists indetails(keys and counts only; the values are being deleted, and none of these keys is a secret).requestis already a parameter on the handler, soactor_ip/endpoint/request_idneed no signature change.Either that, or narrow the two prose claims to
/ops/config— but auditing it is four lines and closes the class rather than documenting around it.Acceptance
POST /api/settings/ops/resetwrites aCONFIGURATIONaudit entry naming which keys were reset and which were skippedskipped, neverreset)architecture.md's "neither this route nor/ops/resetlogged anything before" is true after the changeFollow-up to trinity-enterprise#297 · surfaced in review of #1893.