lda.chat/lda-wf
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: close Python workflow client review

Browse Source
This commit is contained in:
lda
2026-08-31 23:38:03 +07:00 Verified
parent 4f946a35ef
commit 5e3d0b6524
15 changed files with 200 additions and 224 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/current_roadmap.md
+11 -8
View File
@@ -22,14 +22,17 @@ The durable product path is now `wf-rpc-server` plus neutral `wf_config` /
`wf_server` composition. The old `wf-mcp` script remains a legacy/special-purpose
MCP entrypoint and compatibility surface.
Completed: the async `wf_client` Python slice is verified against the real
JSON-RPC ASGI application. It covers capability discovery, local graph
authoring, remote validation, immutable artifact save, deployment selection,
and durable run execution. Rich client objects have bounded, secret-safe
`repr()` and `_repr_html_()` views that never perform remote I/O. Draft
workspaces remain a separate server/admin surface and are not part of the
client; server registration is explicit so the artifact -> deployment -> run
path does not require draft storage.
Delivered, with the repository-wide verification gate still open: the async
`wf_client` Python slice is verified against the real JSON-RPC ASGI application.
It covers capability discovery, local graph authoring, remote validation,
immutable artifact save, deployment selection, and durable run execution. Rich
client objects have bounded, secret-safe `repr()` and `_repr_html_()` views that
never perform remote I/O. Draft workspaces remain a separate server/admin
surface and are not part of the client; server registration is explicit so the
artifact -> deployment -> run path does not require draft storage. All
slice-owned checks pass, while the full repository suite still has its
pre-existing missing-thesis-PDF failure; mark this slice complete only when that
repository asset gate also passes.
## Active Initiative: Workflow Console And Defense Demo
docs/superpowers/plans/2026-08-30-python-workflow-client.md
+7 -1
View File
@@ -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**
docs/superpowers/specs/2026-08-30-python-workflow-client-design.md
+5 -6
View File
@@ -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