feat: add draft data, gap analysis report, and workspace config
This commit is contained in:
@@ -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.
|
||||
Reference in New Issue
Block a user