Likelihood and impact use low, medium, or high. A risk remains open until its closure condition has evidence. Product scope does not expand to reduce a risk unless the owner approves the change.
| ID | Risk | Likelihood | Impact | Required mitigation | Closure condition |
|---|---|---|---|---|---|
| R-01 | Database exhaustion affects the control plane | Low | High | Use separate PostgreSQL services, credentials, and connection limits | Isolation test proves target exhaustion while control-plane writes and reads continue |
| R-02 | Fault connections survive operator or control-plane loss | Medium | High | Runner-local lease, active-action journal, automatic stop, restart reconciliation | Disconnect and restart tests show zero held connections within lease plus 15 seconds |
| R-03 | Runner becomes a general remote execution tool | Medium | High | Compiled action registry, strict schemas, no shell, no Docker socket, pinned targets | Security contract suite rejects command fields, scripts, arbitrary destinations, and unknown actions |
| R-04 | Reset is flaky and later runs start from contaminated state | Medium | High | Idempotent reset, baseline fingerprint, global reset-failure lock | Two reset calls yield the same fingerprint; failed reset blocks a new run |
| R-05 | Connection exhaustion does not reliably create both symptoms | Medium | High | Dedicated target database limits, bounded workload seed, activation contract | Three consecutive runs show API degradation and worker backlog within 30 seconds |
| R-06 | Recovery verification passes on a shallow health check | Medium | High | Verify API transaction, database, worker, backlog, stability, and held connections | Breaking each dependency causes unverified even when liveness is healthy |
| R-07 | Logs or notes leak credentials into evidence and reports | Medium | High | Structured allowlist, redaction, bounded excerpts, restricted evidence state | Seeded test secrets are absent from persisted evidence payloads and reports |
| R-08 | Concurrent runs corrupt target state or evidence | Low | High | Control-plane run lock, Runner target lock, exercise correlation ID | A second injection is rejected at both boundaries |
| R-09 | Timing-dependent tests become unreliable | High | Medium | Explicit windows, monotonic deadlines, bounded retries, deterministic workload and fixture | End-to-end suite passes three consecutive clean runs without increased timeouts |
| R-10 | Built-in target looks like a toy rather than a useful system | Medium | Medium | Use real persistence, async work, logs, health checks, and recovery behavior | Demo proves a stored request, completed job, real degradation, recovery, and reset |
| R-11 | The project expands into ITSM, cloud, or plugin work before v0.1 | High | High | Enforce non-goals and phase exit criteria; require separate owner decision | v0.1 diff contains only capabilities required by the vertical slice |
| R-12 | Reports overstate what the evidence proves | Medium | Medium | Fixed result vocabulary, evidence links, explicit missing evidence, no manual verification override | Review can trace every machine conclusion to evidence or a recorded missing-evidence state |
| R-13 | Target reset changes or deletes exercise evidence | Low | High | Separate databases; reset target only; hash evidence before and after reset | Evidence IDs and hashes remain unchanged across reset |
| R-14 | Probe configuration enables SSRF | Medium | High | Registered probe keys, pinned destinations, no redirects, isolated network | Contract tests reject custom schemes, hosts, ports, paths, and redirects |
| R-15 | Local account is exposed on an untrusted network | Medium | High | Local/lab binding, no default password, secure session and CSRF controls, clear limitation | Installation requires operator setup and docs prohibit internet exposure |
| R-16 | Framework or dependency work dominates the product loop | Medium | Medium | Choose common maintained components during implementation planning and keep adapters internal | Phase reviews show work mapped to a v0.1 acceptance criterion |
| R-17 | Automatic cleanup failure is hidden by reset | Low | High | Store cleanup and reset as separate results; preserve both in report | Tests show cleanup failure remains visible after a successful reset |
| R-18 | Documentation and implementation drift | Medium | Medium | Turn normative contracts into tests and review docs at each release gate | Release checklist maps current behavior to every definition-of-done item |
Implementation must stop before release if any of these conditions remains:
- a fault can target the control-plane database;
- the Runner accepts executable text or arbitrary destinations;
- fault resources can outlive their lease;
- reset cannot prove the baseline fingerprint;
- a failed reset does not block the next run;
- verification can pass without API, database, worker, backlog, and stability evidence;
- reports expose seeded credentials;
- three consecutive exercises are not repeatable.
Requests for Kubernetes, cloud targets, generic scripts, SSO, multi-tenancy, plugins, AI analysis, or complete ITSM features are recorded as later candidates. They do not enter v0.1 issue or implementation plans without a new product decision and threat-model review.