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

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

@@ -0,0 +1,24 @@
+# Architecture Review
+
+## Findings
+
+### Medium: the draft is mostly well scoped, but it wavers between abstract event semantics and protocol behavior
+
+The document says it is carrier-agnostic and not a transport binding, which is correct. However, several MUST-level statements already imply protocol behavior. That is acceptable, but the architecture should acknowledge that the document defines an abstract protocol model, not only vocabulary.
+
+### Medium: coordinator role is introduced but not integrated into the model
+
+The coordinator is defined as optional, yet no section explains how peers distinguish coordinator-computed scope from sender-local scope. That leaves a conceptual hole in the actor model.
+
+### Medium: cancellation is declared out of scope, but the boundary with rollback is not fully clean
+
+The text says cancellation of work not yet started is out of scope, except when used internally to satisfy rollback. That line is defensible, but it should be expressed more rigorously to prevent readers from assuming cancellation semantics are standardized here.
+
+## Open questions
+
+- Should the draft describe itself as an abstract recovery protocol profile rather than only "semantics"?
+- Does the optional coordinator need one or two normative constraints, or should it be deferred entirely?
+
+## Residual risk
+
+Scope discipline is good overall. The main remaining architectural risk is ambiguity about whether this document is merely descriptive or actually defines interoperable protocol behavior. It should explicitly choose the latter in a carefully bounded way.

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

@@ -0,0 +1,28 @@
+# IETF Senior Review
+
+## Findings
+
+### High: the draft still reads more like a design sketch than a publishable Internet-Draft
+
+The overall structure is right, but several sections stop at high-level intent. A publishable draft needs more disciplined distinction between required behavior, optional behavior, and explanatory rationale. Sections 5 through 8 are closest to publishable, but they still need slightly more rigor.
+
+### Medium: the abstract is acceptable but could better state the interoperability problem and deployment value
+
+The current abstract says what the document defines, but it could more directly explain why existing agent systems fail to interoperate during recovery and why this document matters.
+
+### Medium: References and IANA sections are too provisional
+
+It is fine to keep placeholders at this stage, but the text currently signals that core dependencies are undecided. Before wider circulation, the draft should either name the expected adjacent substrate or state clearly that no substrate dependency is required.
+
+### Medium: terminology is mostly clean, but some items still need RFC-style definition form
+
+The terms are understandable, yet a few are written more like explanations than stable definitions. Tightening the definition style would help the document feel more standards-native.
+
+## Open questions
+
+- Does the draft intend to progress as a standalone individual draft or as part of a family with a shared terminology base?
+- Should the document explicitly call itself Experimental in the introduction rather than only in external cycle metadata?
+
+## Residual publishability risk
+
+This is a credible start. The remaining publishability risk is not the idea; it is the need for one more iteration of standards-style precision and dependency cleanup.

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.

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

@@ -0,0 +1,28 @@
+# Software Review
+
+## Findings
+
+### High: required fields are defined, but no concrete message shape or example flow is provided
+
+The event model is understandable, but two implementers could still serialize or correlate it differently. A non-normative example showing `failure -> rollback-request -> rollback-result` with task identifiers, dependency references, and partial-success handling would materially reduce ambiguity.
+
+### High: task state transitions are incomplete at the procedure level
+
+The draft lists states but does not specify enough transition rules. For example, can a task move from `completed` directly to `rollback-requested`? Can `compensation-required` be terminal? Can `rollback-failed` later transition to `rolled-back` after manual intervention? Without a transition table or explicit rules, interoperability tests will be hard to design.
+
+### Medium: rollback scope remains too abstract for independent implementations
+
+The draft requires a target checkpoint or explicit rollback set, but it does not describe the structure of a rollback set or how direct and transitive dependencies are represented. The draft needs at least a minimal abstract shape for scope membership.
+
+### Medium: timeout behavior is named but not operationalized
+
+Timeout is listed as an error condition, but no rule says whether timeout yields `failure`, `partial-success`, or local retry. This will fragment behavior.
+
+## Open questions
+
+- Is a compact transition table sufficient, or does the draft need a separate state machine subsection?
+- Should rollback set representation be a list of task identifiers, checkpoint identifiers, or both?
+
+## Residual risk
+
+The current draft is close to implementable, but it still needs one more layer of precision around flow shape and state progression before two vendors would likely build compatible behavior.