fix: close Python workflow client review

2026-08-31 23:38:03 +07:00
parent 4f946a35ef
commit 5e3d0b6524
15 changed files with 200 additions and 224 deletions
@@ -1301,7 +1301,13 @@ artifact = await graph.save(version=1)
 run = await artifact.run({})
 ```

-State explicitly that drafts are not part of `wf_client` but remain registered in the server until the separate draft opt-out plan is executed. Update `docs/current_roadmap.md` to mark the Python-client slice complete only after every verification step below passes.
+Drafts are not part of `wf_client`. The shipped server composition uses
+`drafts=False` by default, which excludes draft storage, domain modules, and RPC
+registration; real legacy draft consumers opt in explicitly with `drafts=True`.
+The earlier plan assumption that draft methods would remain registered pending a
+separate opt-out slice is historical. Update `docs/current_roadmap.md` to mark
+the Python-client slice complete only after every verification step below
+passes.

 - [ ] **Step 6: Run focused and cross-layer verification**

@@ -633,12 +633,11 @@ capability, expose secrets, or fetch an unbounded trace.
 authoring compiles a complete workflow and saves it through the existing
 artifact-from-plan operation.

-Making draft support uninitialized by default is a separate server-composition
-slice. Today `WorkflowApi` constructs draft modules unconditionally, durable
-context validation requires a draft store, and the JSON-RPC app always
-registers draft methods. That follow-up must make draft storage, domain modules,
-and RPC registration opt-in without weakening artifact, deployment, or run
-durability.
+Draft support is uninitialized by default across storage, domain modules, and
+JSON-RPC registration. Normal composition uses `drafts=False`; callers that
+still operate the legacy draft workspace surface must opt in explicitly with
+`drafts=True`. This keeps artifact, deployment, and run durability independent
+from draft storage.

 ## Testing Strategy