docs: analyze the PI-only research workflow interface - #1
Conversation
Define the product problem, structured workflow model, configuration-parity requirement, progressive prototype strategy, and validation plan for the research-oriented fork.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a5ad507881
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ### Stage 1 — `Research Workflow` plugin | ||
|
|
||
| Use plugin API v2 to add a workspace panel and actions backed by a server plugin. Validate: |
There was a problem hiding this comment.
On the existing ParaFM/Git workspaces that this stage is meant to test, a paired browser plugin does not have a general-purpose server backend: WorkspaceProviderRegistry.request() dispatches only when the requesting plugin is the selected workspace owner and otherwise returns owner-mismatch, while actions have no backend context at all. A standalone Research Workflow panel/action plugin therefore cannot persist these records through its server entry unless it replaces or extends the owning workspace provider, or core adds a non-owner backend API; Stage 1 needs to specify one of those strategies.
Useful? React with 👍 / 👎.
|
|
||
| ### Stage 1 — `Research Workflow` plugin | ||
|
|
||
| Use plugin API v2 to add a workspace panel and actions backed by a server plugin. Validate: |
There was a problem hiding this comment.
apiVersion: 2 applies only to the browser entry that contributes the panel and actions; the paired server entry must implement PiWebServerPlugin with apiVersion: 1, and the server runtime rejects v2. Describing the whole server-backed plugin as using API v2 can direct the prototype toward an incompatible server entry, so this should explicitly name browser API v2 and server API v1.
Useful? React with 👍 / 👎.
1 participant
Summary\n- define the PI-only research workflow product problem\n- propose work-item, run, decision, and machine-profile models\n- outline plugin validation followed by core-shell redesign\n- add measurable validation criteria and open decisions\n\nThis is an analysis artifact for review; it does not change runtime behavior.