Follow-up from #450 (Read-only mode).
Problem
isReadOnlyMode() currently gates RocksDB writes plus analytics/audit writes, but management operations that mutate filesystem state outside the database are not guarded:
- Component deployments —
components/operations.js (writes the components directory).
- Config updates —
config/configUtils.js (writes harperdb-config.yaml).
- Roles/users —
security/role.js, security/user.ts (system-level identity changes).
A read-only Harper instance can still accept these operations and partially mutate filesystem state, which is inconsistent with the "read-only" contract.
Proposed change
Add isReadOnlyMode() guards at each management entrypoint. Reject with a clear error (HTTP 405) before any filesystem write.
Benefit
Coherent read-only contract across the database and the surrounding application config/assets. Prevents partial state mutations on instances callers expect to be inert.
🤖 Identified by Gemini CLI during review of #450; relayed by Claude.
Follow-up from #450 (Read-only mode).
Problem
isReadOnlyMode()currently gates RocksDB writes plus analytics/audit writes, but management operations that mutate filesystem state outside the database are not guarded:components/operations.js(writes the components directory).config/configUtils.js(writesharperdb-config.yaml).security/role.js,security/user.ts(system-level identity changes).A read-only Harper instance can still accept these operations and partially mutate filesystem state, which is inconsistent with the "read-only" contract.
Proposed change
Add
isReadOnlyMode()guards at each management entrypoint. Reject with a clear error (HTTP 405) before any filesystem write.Benefit
Coherent read-only contract across the database and the surrounding application config/assets. Prevents partial state mutations on instances callers expect to be inert.
🤖 Identified by Gemini CLI during review of #450; relayed by Claude.