feat: add draft data, gap analysis report, and workspace config

workspace/draft-team/cycles/agent-error-recovery-rollback/50-reviews-v1/security.md

@@ -0,0 +1,28 @@
+# Security Review
+
+## Findings
+
+### High: rollback authorization is left entirely to the lower layer without a required authorization decision point
+
+The draft says recovery events need authenticated and authorized carriage, but it never states when a receiver is required to evaluate authorization before acting on a `rollback-request`. Two compliant implementations could therefore both authenticate the requester yet differ on whether task-level rollback authority is required. The draft should require an explicit authorization check before any irreversible rollback action is attempted.
+
+### High: replay protection is mentioned but underspecified for interoperable use
+
+The draft says implementations SHOULD provide replay resistance, but `rollback-request` already defines an idempotency token and stable identifiers. That is enough structure to make stronger requirements possible. Without a minimum replay-handling rule, an attacker can reuse stale rollback requests in a way that different implementations will treat inconsistently.
+
+### Medium: failure-event spoofing risk is identified, but the draft does not require correlation between failure and rollback flows
+
+An attacker who can inject a plausible `failure` event may induce unnecessary rollback decisions. The draft should at least require that a `rollback-request` reference a specific task or failure context and that receivers preserve the linkage in the `rollback-result`.
+
+### Medium: partial rollback can leave exploitable inconsistent state, but no minimum disclosure is mandated
+
+The draft correctly notes the risk, yet "residual risk description" is only a SHOULD. For partial-success and irreversible outcomes, a stronger requirement is warranted so downstream agents can react safely.
+
+## Open questions
+
+- Should authorization be expressed as a generic requirement only, or should the document define a task-scope authorization concept for rollback actions?
+- Should replay resistance be a MUST for all deployments, or only when rollback has externally visible effects?
+
+## Residual risk
+
+Even with the fixes above, the draft will still depend heavily on lower-layer identity and authorization systems. That is acceptable, but the security section should say so more concretely and bind protocol behavior to those assumptions.