@paradigma-inc/flywheel 0.1.11 → 0.1.13
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/skills/flywheel/SKILL.md +7 -25
- package/skills/flywheel/agents/openai.yaml +2 -2
- package/skills/flywheel/example-workflows/organizing-exploring-and-iterating-on-a-research-topic.md +8 -8
- package/skills/flywheel/example-workflows/reproducing-papers-on-a-budget.md +8 -8
- package/skills/flywheel/getting-started/flywheel-tutorial-overview.md +1 -1
- package/skills/flywheel/references/experiment-design-protocol.md +204 -0
- package/skills/flywheel/references/flywheel-mcp-tool-map.md +160 -0
- package/skills/flywheel/web-ui/flywheel-webui-map.md +1 -1
- package/skills/flywheel-auto/SKILL.md +156 -0
- package/skills/flywheel-auto/agents/openai.yaml +12 -0
- package/skills/flywheel-auto/evals/evals.json +20 -0
- package/skills/flywheel-auto/references/ARTIFACTS.md +218 -0
- package/skills/flywheel-auto/references/INTERFACES.md +201 -0
- package/skills/{flywheel/reference → flywheel-auto/references}/experiment-design-protocol.md +9 -5
- package/skills/flywheel-lookahead/SKILL.md +145 -0
- package/skills/flywheel-lookahead/agents/openai.yaml +12 -0
- package/skills/flywheel-lookahead/evals/evals.json +20 -0
- package/skills/flywheel-lookahead/references/ARTIFACTS.md +218 -0
- package/skills/flywheel-lookahead/references/INTERFACES.md +201 -0
- package/skills/flywheel-lookahead/references/flywheel-mcp-tool-map.md +160 -0
- package/skills/flywheel-reproduce/SKILL.md +212 -0
- package/skills/flywheel-reproduce/agents/openai.yaml +12 -0
- package/skills/flywheel-reproduce/evals/evals.json +20 -0
- package/skills/flywheel-reproduce/references/ARTIFACTS.md +218 -0
- package/skills/flywheel-reproduce/references/INTERFACES.md +201 -0
- package/skills/flywheel-reproduce/references/experiment-design-protocol.md +204 -0
- package/skills/flywheel-reproduce/references/flywheel-mcp-tool-map.md +160 -0
- package/skills/flywheel-to-graph/SKILL.md +187 -0
- package/skills/flywheel-to-graph/agents/openai.yaml +12 -0
- package/skills/flywheel-to-graph/evals/evals.json +20 -0
- package/skills/flywheel-to-graph/references/ARTIFACTS.md +218 -0
- package/skills/flywheel-to-graph/references/INTERFACES.md +201 -0
- package/skills/flywheel-to-graph/references/flywheel-mcp-tool-map.md +160 -0
- package/skills/flywheel/reference/command-presets.md +0 -230
- package/skills/flywheel/reference/wiki-porting.md +0 -92
- /package/skills/{flywheel/reference → flywheel-auto/references}/flywheel-mcp-tool-map.md +0 -0
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: flywheel-lookahead
|
|
3
|
+
description: Stage a single-path next-step frontier from existing Flywheel graph state with Flywheel MCP using lookahead depth `n` and per-hop option width `k`, without execution or compute acquisition. Use for planning what to do next, not claim validation, source-to-graph authoring, or autonomous execution.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# flywheel-lookahead
|
|
7
|
+
|
|
8
|
+
## When To Use
|
|
9
|
+
|
|
10
|
+
Use this skill when the task is to shape information inside Flywheel rather than only discuss it. Use the flywheel-lookahead skill when the user wants Flywheel to plan the next frontier of work from an existing set of nodes without executing it yet. Flywheel MCP is a node-first durable system of record for research work: nodes hold durable state, artifacts hold supporting files, executions record runs, and compute leases provide managed hardware. This skill is planning only: it stages next-step nodes from existing graph state without hidden execution, compute approval, or managed compute acquisition.
|
|
11
|
+
|
|
12
|
+
If exact tool or field semantics are unclear, load [references/flywheel-mcp-tool-map.md](references/flywheel-mcp-tool-map.md) and [references/INTERFACES.md](references/INTERFACES.md) before mutating nodes.
|
|
13
|
+
|
|
14
|
+
## Input Contract
|
|
15
|
+
|
|
16
|
+
Before planning, recover or establish these inputs:
|
|
17
|
+
|
|
18
|
+
- Required before planning: start nodes, objective, lookahead depth `n`, step option width `k`, and an explicit terminal condition.
|
|
19
|
+
- Optional: budget ceiling and budget unit, but only when the user already supplied them or wants them tracked for later execution.
|
|
20
|
+
- Defaults: `lookahead_depth` defaults to `n=1`; `step_option_width` defaults to `k=1`.
|
|
21
|
+
- Recovery rules:
|
|
22
|
+
- Ask only when a required planning input cannot be recovered from explicit user instructions, current conversational context, or recent graph state.
|
|
23
|
+
- If start nodes cannot be recovered from explicit ids/slugs, named current context, or recent graph context, ask once.
|
|
24
|
+
- If the objective is missing, ask once; if the user refuses, infer it from graph context and persist it before planning.
|
|
25
|
+
- If the terminal condition is missing, ask once; if it remains unspecified, persist a planning-local terminal condition such as stopping after staging this lookahead pass through the requested `n` hops with at most `k` considered options per hop and one selected continuation per hop.
|
|
26
|
+
|
|
27
|
+
## Working Terms
|
|
28
|
+
|
|
29
|
+
- `frontier`: the current unresolved next-step nodes or candidate branches worth planning next.
|
|
30
|
+
- `resolved frontier`: the latest resolved nodes from which the next frontier should be expanded, not the original source corpus again.
|
|
31
|
+
- `control node`: the dedicated `insight` node that stores the canonical planning contract for the current frontier.
|
|
32
|
+
- `terminal condition`: the explicit condition that tells this planning pass when to stop staging additional frontier nodes.
|
|
33
|
+
- `expected_revision`: the node's current revision token used for optimistic-locking writes.
|
|
34
|
+
- `lookahead depth (n)`: the number of sequential hops in one planned path.
|
|
35
|
+
- `step option width (k)`: the number of candidate directions evaluated at each hop before choosing one continuation.
|
|
36
|
+
|
|
37
|
+
## Width Semantics (Unambiguous)
|
|
38
|
+
|
|
39
|
+
- Lookahead depth `n`: number of sequential hops in one plan path.
|
|
40
|
+
- Step option width `k`: number of candidate directions to evaluate at each hop.
|
|
41
|
+
- Expansion rule: at hop `i`, generate up to `k` non-redundant options, select exactly 1 winner, and only that winner continues to hop `i+1`.
|
|
42
|
+
- Graph shape for this mode: a single chain of `n` staged nodes (not `k` parallel branches).
|
|
43
|
+
- Each step node must record:
|
|
44
|
+
- the `k` considered options,
|
|
45
|
+
- the selection criterion,
|
|
46
|
+
- the chosen continuation.
|
|
47
|
+
|
|
48
|
+
## Core Rules
|
|
49
|
+
|
|
50
|
+
- Treat the main page body as the node readme/body field (`content` on modern Flywheel surfaces).
|
|
51
|
+
- Use artifacts for supporting files and evidence, not as a substitute for the node's main narrative, because the node body should stay readable as the canonical planning record.
|
|
52
|
+
- Only create graph edges for durable semantic relationships, because graphifying every wiki link floods the graph with noise that hides decision-relevant structure.
|
|
53
|
+
- Treat the flywheel-lookahead skill as frontier planning only. It expands the Flywheel graph with staged next-step nodes but does not execute them, because execution or compute acquisition changes the job into `$flywheel-auto` or `$flywheel-reproduce`.
|
|
54
|
+
- Planned nodes that are expected to produce evidence or artifacts should be typed `empirical`; planned nodes that only encode synthesis, decomposition, or decision structure should be typed `insight`.
|
|
55
|
+
- Ask only the minimum clarification questions needed to establish a coherent planning contract, and ask none when the required answers are already recoverable from user instructions, conversational context, or graph state.
|
|
56
|
+
- Do not request compute approval, acquire managed compute, or launch execution in this skill, because planning should leave the frontier staged for later work rather than spend budget now.
|
|
57
|
+
|
|
58
|
+
## Workflow
|
|
59
|
+
|
|
60
|
+
1. Resolve the starting context.
|
|
61
|
+
- Resolve starting nodes in this order: explicit node ids/slugs, explicitly named current context, focused or recently referenced nodes, then ask the user if nothing stable is recoverable.
|
|
62
|
+
2. Resolve the planning contract.
|
|
63
|
+
- Recover required planning inputs from the current conversation and graph first. Ask only for inputs that remain genuinely missing after that recovery pass.
|
|
64
|
+
- The flywheel-lookahead skill requires a measurable objective. Ask once if it is missing; if the user refuses to specify one, infer it from the available graph context and state it explicitly before continuing.
|
|
65
|
+
- Default `n=1` and `k=1` unless the user specified otherwise.
|
|
66
|
+
- Persist the planning contract in a dedicated `insight` control node for this frontier. Put the canonical contract in node `content`, keep a one-line synopsis in `summary`, and keep brief planning rationale in `insights` so the commit contract stays valid.
|
|
67
|
+
- The control contract must name: objective, decision criterion, start nodes, lookahead depth `n`, step option width `k`, and an explicit terminal condition. Only persist a budget ceiling and unit when the user already supplied one or wants them tracked for later execution.
|
|
68
|
+
- Later lookahead passes must read the control node `content` first and continue from that persisted contract rather than from chat memory.
|
|
69
|
+
3. Map each stable page, claim, or concept to a node.
|
|
70
|
+
- For exact node-mutation shapes, load [references/flywheel-mcp-tool-map.md](references/flywheel-mcp-tool-map.md).
|
|
71
|
+
- Create a new node with `flywheel_stage_node_create` when needed.
|
|
72
|
+
- Update an existing node with `flywheel_get_node` + `flywheel_stage_node_update` when continuing work.
|
|
73
|
+
4. Put the primary page markdown or plan rationale in the node body/readme field (`content`).
|
|
74
|
+
- Keep `summary` concise.
|
|
75
|
+
- Populate `hypothesis`, `insights`, `outcome`, and similar fields only when the source actually supports them.
|
|
76
|
+
5. Publish supporting files with the artifact upload flow.
|
|
77
|
+
- For exact artifact contract details, load [references/ARTIFACTS.md](references/ARTIFACTS.md).
|
|
78
|
+
- Use `flywheel_prepare_artifact_uploads`.
|
|
79
|
+
- Upload raw file bytes to the returned signed URLs.
|
|
80
|
+
- Call `flywheel_finalize_artifact_uploads` once all uploads in the batch are staged.
|
|
81
|
+
- Keep the artifact filename stable enough to reference from markdown when inline rendering matters.
|
|
82
|
+
6. Add graph structure sparingly.
|
|
83
|
+
- Promote only decision-relevant relationships to edges.
|
|
84
|
+
- Leave ordinary cross-links inside the markdown body.
|
|
85
|
+
7. Expand the frontier as a single selected path.
|
|
86
|
+
- Expand from the resolved frontier rather than mirroring the source corpus again.
|
|
87
|
+
- Depth `n` means plan `n` sequential hops ahead from the currently resolved frontier. Default `n=1`.
|
|
88
|
+
- Width `k` means evaluate up to `k` distinct non-redundant candidate directions at each hop. Default `k=1`.
|
|
89
|
+
- At each hop, stage the considered options in the step record, apply the selection criterion, and choose exactly one continuation.
|
|
90
|
+
- Only the chosen continuation advances to hop `i+1`; do not stage `k` parallel continuation branches for this mode.
|
|
91
|
+
- The staged graph shape for this mode is a single chain of up to `n` unresolved step nodes (shorter only when the terminal condition is met early).
|
|
92
|
+
- Each step node must record: the `k` considered options, the selection criterion used, and the chosen continuation.
|
|
93
|
+
8. Commit after the node snapshot is coherent with `flywheel_commit_node`.
|
|
94
|
+
- Commit resolved insight nodes only when they have non-empty `insights`.
|
|
95
|
+
- Commit resolved empirical nodes only when outcome and artifact rules are satisfied.
|
|
96
|
+
- Leave unresolved plan nodes staged.
|
|
97
|
+
|
|
98
|
+
## Result Contract
|
|
99
|
+
|
|
100
|
+
When the skill completes a pass, it should leave behind:
|
|
101
|
+
|
|
102
|
+
- One persisted `insight` control node containing the canonical planning contract.
|
|
103
|
+
- A single staged next-step chain up to the current `n` limit where each hop records up to `k` considered options and one selected continuation.
|
|
104
|
+
- Updated node summaries, rationale, and edges only where the current planning pass justifies them.
|
|
105
|
+
- No hidden execution, no compute approval, and no managed compute acquisition.
|
|
106
|
+
|
|
107
|
+
## Persisted Control Contract
|
|
108
|
+
|
|
109
|
+
Use a dedicated `insight` node as the durable planning controller for the current frontier. Do not rely on unstated product fields or fresh chat context.
|
|
110
|
+
|
|
111
|
+
For the canonical entity model and public contract terminology behind this controller, load [references/INTERFACES.md](references/INTERFACES.md).
|
|
112
|
+
|
|
113
|
+
Use this storage convention:
|
|
114
|
+
|
|
115
|
+
1. Reuse an existing control node when one already governs the same frontier; otherwise create one with `flywheel_stage_node_create`.
|
|
116
|
+
2. Put the canonical contract in node `content`.
|
|
117
|
+
3. Put a one-line synopsis in `summary`.
|
|
118
|
+
4. Put the planning rationale or branch-selection logic in `insights` so the `insight` commit contract is satisfied.
|
|
119
|
+
5. Update the control node with `flywheel_stage_node_update`.
|
|
120
|
+
6. Read the control node with `flywheel_get_node` before later replans that need a fresh `expected_revision`.
|
|
121
|
+
7. Commit the control node with `flywheel_commit_node` once the contract is coherent, even if downstream frontier nodes remain staged.
|
|
122
|
+
|
|
123
|
+
Canonical contract shape:
|
|
124
|
+
|
|
125
|
+
```md
|
|
126
|
+
## Planning contract
|
|
127
|
+
|
|
128
|
+
- Objective:
|
|
129
|
+
- Decision criterion:
|
|
130
|
+
- Start nodes:
|
|
131
|
+
- Lookahead depth:
|
|
132
|
+
- Step option width:
|
|
133
|
+
- Terminal condition:
|
|
134
|
+
- Budget ceiling: optional
|
|
135
|
+
- Budget unit: optional
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
The `Start nodes` line is the recovery anchor for later replans. If multiple frontier nodes are in scope, list the governing node ids or slugs explicitly.
|
|
139
|
+
|
|
140
|
+
## Guardrails
|
|
141
|
+
|
|
142
|
+
- Build the graph explicitly with nodes, artifacts, and selected edges.
|
|
143
|
+
- Do not request compute approval, acquire managed compute, or launch execution just to do planning.
|
|
144
|
+
|
|
145
|
+
See also: invoke `$flywheel-to-graph` to port source material into Flywheel without implicit execution, invoke `$flywheel-reproduce` to graphify claim-bearing sources and run budgeted validation branches, and invoke `$flywheel-auto` to advance a frontier autonomously under an explicit budget and persisted stop condition.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "flywheel-lookahead"
|
|
3
|
+
short_description: "Plan the next Flywheel frontier"
|
|
4
|
+
default_prompt: "Use $flywheel-lookahead to expand this Flywheel frontier into staged next-step nodes."
|
|
5
|
+
|
|
6
|
+
dependencies:
|
|
7
|
+
tools:
|
|
8
|
+
- type: "mcp"
|
|
9
|
+
value: "flywheel"
|
|
10
|
+
description: "Flywheel MCP server"
|
|
11
|
+
transport: "streamable_http"
|
|
12
|
+
url: "https://flywheel.paradigma.inc/mcp-server"
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
[
|
|
2
|
+
{
|
|
3
|
+
"id": "continuation-from-existing-planning-contract",
|
|
4
|
+
"prompt": "Use $flywheel-lookahead to continue planning from an existing Flywheel control node that already contains a coherent planning contract. Expand the next frontier one more hop without execution and do not ask again for the objective or start nodes unless the control node is missing or contradictory.",
|
|
5
|
+
"expected_output": "Read the persisted planning contract from the control node content before replanning, continue from the stored objective and start nodes, avoid re-asking for those inputs when the contract is coherent, and stage additional next-step frontier nodes without execution or compute acquisition.",
|
|
6
|
+
"files": []
|
|
7
|
+
},
|
|
8
|
+
{
|
|
9
|
+
"id": "cold-start-with-no-objective",
|
|
10
|
+
"prompt": "Use $flywheel-lookahead to plan the next Flywheel frontier from the current graph context. If I refuse to specify an objective, infer one from the graph context and make it explicit before you stage any next-step nodes.",
|
|
11
|
+
"expected_output": "Ask for an objective once, infer one from graph context if the user refuses, write that objective and a decision criterion into the planning contract, and only then stage next-step frontier nodes.",
|
|
12
|
+
"files": []
|
|
13
|
+
},
|
|
14
|
+
{
|
|
15
|
+
"id": "planning-only-with-explicit-depth-and-width",
|
|
16
|
+
"prompt": "Use $flywheel-lookahead to stage two sequential hops of next-step work while evaluating up to three non-redundant options at each hop from the current Flywheel frontier. Plan only for later work and do not execute anything.",
|
|
17
|
+
"expected_output": "Persist `n=2` and `k=3` in the planning contract, evaluate up to three non-redundant options at each hop, record the considered options plus selection criterion plus chosen continuation for each step node, continue only along the single chosen path, and avoid compute approval, managed compute acquisition, or execution launch.",
|
|
18
|
+
"files": []
|
|
19
|
+
}
|
|
20
|
+
]
|
|
@@ -0,0 +1,218 @@
|
|
|
1
|
+
# Flywheel Artifacts
|
|
2
|
+
|
|
3
|
+
Canonical reference for node artifact publishing in Flywheel MCP 0.9.
|
|
4
|
+
|
|
5
|
+
Legacy note:
|
|
6
|
+
|
|
7
|
+
- historical `run_artifacts` rows are retained for backward reads.
|
|
8
|
+
- new artifact writes must use the MCP batch upload workflow:
|
|
9
|
+
`flywheel_prepare_artifact_uploads` -> raw file upload(s) ->
|
|
10
|
+
`flywheel_finalize_artifact_uploads`.
|
|
11
|
+
|
|
12
|
+
## Node MCP Contract
|
|
13
|
+
|
|
14
|
+
Artifacts are managed through node MCP tools:
|
|
15
|
+
|
|
16
|
+
- `flywheel_prepare_artifact_uploads` prepares one or more signed raw-file
|
|
17
|
+
upload requests for a node.
|
|
18
|
+
- The caller executes each returned upload request with raw bytes.
|
|
19
|
+
- `flywheel_finalize_artifact_uploads` appends all staged uploads in that batch
|
|
20
|
+
to the node and bumps node revision once.
|
|
21
|
+
- `flywheel_list_artifacts` and `flywheel_get_artifact` return artifact
|
|
22
|
+
metadata.
|
|
23
|
+
- `flywheel_get_artifact_preview` reads persisted preview payload content by
|
|
24
|
+
artifact id.
|
|
25
|
+
- `flywheel_commit_node` commits/finalizes node state after terminal fields are
|
|
26
|
+
already staged.
|
|
27
|
+
|
|
28
|
+
Contract rules:
|
|
29
|
+
|
|
30
|
+
- `flywheel_prepare_artifact_uploads` requires `expected_revision` and enforces
|
|
31
|
+
optimistic locking before issuing upload tickets.
|
|
32
|
+
- Upload uses the signed one-time ticket in each returned `upload_url`;
|
|
33
|
+
client-supplied path/reference fields are not part of this contract.
|
|
34
|
+
- Raw upload only stages payloads. It does not mutate node state or bump node
|
|
35
|
+
revision.
|
|
36
|
+
- `flywheel_finalize_artifact_uploads` is the single node mutation point for an
|
|
37
|
+
artifact batch.
|
|
38
|
+
- `flywheel_commit_node` is finalize-only:
|
|
39
|
+
- request shape is `expected_revision` with optional `summary` override.
|
|
40
|
+
- node kind/outcome/hypothesis/insights/no_artifacts_reason must already be
|
|
41
|
+
staged.
|
|
42
|
+
- commit transitions lifecycle to `committed`.
|
|
43
|
+
- committed node contract rules remain strict:
|
|
44
|
+
- `kind=empirical` + `outcome=completed` requires artifacts or
|
|
45
|
+
`no_artifacts_reason`.
|
|
46
|
+
- `kind=insight` requires non-empty `insights`.
|
|
47
|
+
- `kind=empirical` requires empty `insights`.
|
|
48
|
+
- MCP mutating calls require idempotency:
|
|
49
|
+
- tool transport auto-manages idempotency keys for tool calls.
|
|
50
|
+
- direct HTTP callers must provide `Idempotency-Key` on mutating MCP
|
|
51
|
+
endpoints.
|
|
52
|
+
|
|
53
|
+
`artifact_type=banner` is supported for campaign root visuals. It follows the
|
|
54
|
+
same raw image upload validation path as `artifact_type=image` and is intended
|
|
55
|
+
for zoomed-out canvas visibility.
|
|
56
|
+
|
|
57
|
+
## Prepare Request Shape
|
|
58
|
+
|
|
59
|
+
`POST /mcp/nodes/{node_id}/artifacts/uploads/prepare`
|
|
60
|
+
|
|
61
|
+
```json
|
|
62
|
+
{
|
|
63
|
+
"expected_revision": 7,
|
|
64
|
+
"items": [
|
|
65
|
+
{
|
|
66
|
+
"artifact_type": "image",
|
|
67
|
+
"title": "Loss curve",
|
|
68
|
+
"execution_id": "optional-execution-id",
|
|
69
|
+
"metadata": {
|
|
70
|
+
"source": "training-run"
|
|
71
|
+
},
|
|
72
|
+
"filename": "loss_curve.png",
|
|
73
|
+
"media_type": "image/png"
|
|
74
|
+
}
|
|
75
|
+
]
|
|
76
|
+
}
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
Notes:
|
|
80
|
+
|
|
81
|
+
- `items` must contain at least one structured object item.
|
|
82
|
+
- String or JSON-encoded item payloads are invalid at the tool boundary.
|
|
83
|
+
- `filename` and `media_type` are required for each item.
|
|
84
|
+
- `metadata` is caller-defined JSON.
|
|
85
|
+
|
|
86
|
+
## Prepare Response Shape
|
|
87
|
+
|
|
88
|
+
```json
|
|
89
|
+
{
|
|
90
|
+
"batch": {
|
|
91
|
+
"batch_token": "uuid",
|
|
92
|
+
"expires_at": "2026-03-09T16:00:00+00:00",
|
|
93
|
+
"max_upload_bytes": 10485760,
|
|
94
|
+
"items": [
|
|
95
|
+
{
|
|
96
|
+
"upload_id": "uuid",
|
|
97
|
+
"upload_url": "https://.../mcp/artifacts/uploads/{upload_id}?ticket=...",
|
|
98
|
+
"method": "PUT",
|
|
99
|
+
"headers": {
|
|
100
|
+
"Content-Type": "image/png",
|
|
101
|
+
"X-Flywheel-Artifact-Filename": "loss_curve.png"
|
|
102
|
+
},
|
|
103
|
+
"curl_command": "curl -sS -X PUT '...' -H 'Content-Type: image/png' -H 'X-Flywheel-Artifact-Filename: loss_curve.png' --data-binary @/absolute/path/to/file"
|
|
104
|
+
}
|
|
105
|
+
]
|
|
106
|
+
}
|
|
107
|
+
}
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
## Raw Upload Step
|
|
111
|
+
|
|
112
|
+
Execute each returned request exactly:
|
|
113
|
+
|
|
114
|
+
- Method: `PUT`
|
|
115
|
+
- URL: `batch.items[i].upload_url`
|
|
116
|
+
- Body: raw file bytes
|
|
117
|
+
- Headers:
|
|
118
|
+
- `Content-Type` (media type)
|
|
119
|
+
- `X-Flywheel-Artifact-Filename` (filename hint)
|
|
120
|
+
|
|
121
|
+
A successful upload:
|
|
122
|
+
|
|
123
|
+
- validates the uploaded bytes against the requested artifact type
|
|
124
|
+
- stages canonical payload JSON in blob storage
|
|
125
|
+
- returns `202 Accepted`
|
|
126
|
+
- does not yet append an artifact record to the node
|
|
127
|
+
|
|
128
|
+
## Finalize Request and Response
|
|
129
|
+
|
|
130
|
+
`POST /mcp/nodes/{node_id}/artifacts/uploads/finalize`
|
|
131
|
+
|
|
132
|
+
```json
|
|
133
|
+
{
|
|
134
|
+
"batch_token": "uuid"
|
|
135
|
+
}
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
Successful finalize:
|
|
139
|
+
|
|
140
|
+
- validates the batch is complete and still revision-compatible
|
|
141
|
+
- appends all staged artifacts to the node
|
|
142
|
+
- persists canonical payload JSON to `artifacts/nodes/{node_id}/{artifact_id}.json`
|
|
143
|
+
- bumps node revision once
|
|
144
|
+
- returns `{ "node": ..., "artifacts": [...] }`
|
|
145
|
+
|
|
146
|
+
## Artifact Preview Behavior
|
|
147
|
+
|
|
148
|
+
Artifact preview endpoint:
|
|
149
|
+
`GET /mcp/nodes/{node_id}/artifacts/{artifact_id}/preview`.
|
|
150
|
+
MCP tool: `flywheel_get_artifact_preview`.
|
|
151
|
+
|
|
152
|
+
- Preview reads canonical persisted payload blob (`storage_path`) only.
|
|
153
|
+
- No workspace dependency or local-file fallback is required.
|
|
154
|
+
- `data_url` in preview responses is render output only; never upload JSON
|
|
155
|
+
metadata wrappers.
|
|
156
|
+
- Preview-normalized types:
|
|
157
|
+
- `image` -> image payload with `data_url`
|
|
158
|
+
- `html` / `plotly_html` -> HTML payload
|
|
159
|
+
- `json` -> JSON payload
|
|
160
|
+
- `text` / `diff_carousel` and common text/code extensions -> text payload
|
|
161
|
+
|
|
162
|
+
## WebUI Artifact Payload Reads
|
|
163
|
+
|
|
164
|
+
When artifacts are projected through node responses, the server returns
|
|
165
|
+
normalized storage references for each artifact payload:
|
|
166
|
+
|
|
167
|
+
- `storage_path`: canonical blob path (for example
|
|
168
|
+
`artifacts/nodes/{node_id}/{artifact_id}.json`).
|
|
169
|
+
- `storage_url`: the single client/host read URL for that payload.
|
|
170
|
+
- All blob backends: `/blobs/{storage_path}` authenticated byte-serving
|
|
171
|
+
proxy after access checks.
|
|
172
|
+
|
|
173
|
+
Clients should read artifact bytes from `storage_url` only. `storage_path`
|
|
174
|
+
remains metadata/debug context and must not be reconstructed into fetch URLs by
|
|
175
|
+
clients. Payload loads are coordinated through a shared loader with in-flight
|
|
176
|
+
deduplication, cache reuse, and bounded fetch concurrency to avoid bursty
|
|
177
|
+
request storms and `429` backpressure under artifact-heavy nodes.
|
|
178
|
+
|
|
179
|
+
The node overview panel additionally avoids eager load spikes by defaulting to
|
|
180
|
+
collapsed mode for artifact-heavy nodes and deferring artifact rendering until
|
|
181
|
+
cards approach the viewport.
|
|
182
|
+
|
|
183
|
+
## Artifact Load Telemetry
|
|
184
|
+
|
|
185
|
+
The WebUI emits a batched first-party product analytics event,
|
|
186
|
+
`web_artifact_payload_batch`, through `POST /analytics/events`.
|
|
187
|
+
|
|
188
|
+
This event is intended for aggregate artifact read-path observability and
|
|
189
|
+
includes fields such as:
|
|
190
|
+
|
|
191
|
+
- load volume (`loads_started`, `loads_completed`, `loads_failed`)
|
|
192
|
+
- rate-limit incidence (`loads_429`)
|
|
193
|
+
- queue/load latency aggregates
|
|
194
|
+
- source mix (`/blobs/*` authenticated proxy)
|
|
195
|
+
- top per-node load/failure summaries in the batch window
|
|
196
|
+
|
|
197
|
+
## File Inventory Surfaces
|
|
198
|
+
|
|
199
|
+
Artifacts and attachments are exposed through two HTTP inventory endpoints:
|
|
200
|
+
|
|
201
|
+
- `GET /users/me/files` for account-wide browsing in Settings.
|
|
202
|
+
- `GET /nodes/{node_id}/files` for node lineage-scoped browsing in the node
|
|
203
|
+
details panel.
|
|
204
|
+
|
|
205
|
+
Inventory entries include source context (`node_id`, `execution_id`) so the UI
|
|
206
|
+
can jump directly to the originating node or execution.
|
|
207
|
+
|
|
208
|
+
## Common Invalid Payload Causes
|
|
209
|
+
|
|
210
|
+
- stale `expected_revision` at prepare or finalize time
|
|
211
|
+
- missing/invalid upload ticket
|
|
212
|
+
- expired upload ticket or batch
|
|
213
|
+
- upload body exceeds configured size limit
|
|
214
|
+
- uploaded bytes do not match requested artifact format (for example invalid
|
|
215
|
+
JSON)
|
|
216
|
+
- finalize called before every prepared upload is staged
|
|
217
|
+
- commit contract violations (for example empirical `completed` without
|
|
218
|
+
artifacts or `no_artifacts_reason`)
|
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
# Interfaces
|
|
2
|
+
|
|
3
|
+
Canonical reference for Flywheel user-facing interfaces and public contracts.
|
|
4
|
+
|
|
5
|
+
Last updated: 2026-03-21
|
|
6
|
+
|
|
7
|
+
## Primary Clients
|
|
8
|
+
|
|
9
|
+
- `project/flywheel-webui` - canonical web product UI
|
|
10
|
+
- `project/flywheel-api` - canonical programmatic client interface (local + HTTP)
|
|
11
|
+
- MCP hosts (Codex/Claude/ChatGPT) via `/mcp-server`
|
|
12
|
+
|
|
13
|
+
## Canonical Entity Model
|
|
14
|
+
|
|
15
|
+
All interfaces operate on the same core entities:
|
|
16
|
+
|
|
17
|
+
- node
|
|
18
|
+
- node edge (branch/merge graph links)
|
|
19
|
+
- artifact
|
|
20
|
+
- execution
|
|
21
|
+
- compute lease
|
|
22
|
+
- budget grant
|
|
23
|
+
|
|
24
|
+
Node snapshots are the canonical durable contract for resume, review, and
|
|
25
|
+
cross-client interoperability.
|
|
26
|
+
|
|
27
|
+
## Core HTTP Surface
|
|
28
|
+
|
|
29
|
+
### Node lifecycle and graph
|
|
30
|
+
|
|
31
|
+
- `GET /mcp/nodes`
|
|
32
|
+
- `GET /mcp/nodes/{node_id}`
|
|
33
|
+
- `GET /mcp/nodes/{node_id}/tree`
|
|
34
|
+
- `POST /mcp/nodes/stage/create`
|
|
35
|
+
- `PATCH /mcp/nodes/{node_id}/stage/update`
|
|
36
|
+
- `POST /mcp/nodes/{node_id}/commit`
|
|
37
|
+
- `POST /mcp/nodes/{node_id}/branch`
|
|
38
|
+
- `POST /mcp/nodes/merge`
|
|
39
|
+
- `DELETE /mcp/nodes/{node_id}`
|
|
40
|
+
- `POST /mcp/nodes/bulk-delete`
|
|
41
|
+
|
|
42
|
+
### Artifact lifecycle
|
|
43
|
+
|
|
44
|
+
- `POST /mcp/nodes/{node_id}/artifacts/uploads/prepare`
|
|
45
|
+
- `POST /mcp/nodes/{node_id}/artifacts/uploads/finalize`
|
|
46
|
+
- `GET /mcp/nodes/{node_id}/artifacts`
|
|
47
|
+
- `GET /mcp/nodes/{node_id}/artifacts/{artifact_id}`
|
|
48
|
+
- `GET /mcp/nodes/{node_id}/artifacts/{artifact_id}/preview`
|
|
49
|
+
- `DELETE /mcp/nodes/{node_id}/artifacts/{artifact_id}`
|
|
50
|
+
- `PUT /mcp/artifacts/uploads/{upload_id}`
|
|
51
|
+
|
|
52
|
+
### Execution lifecycle
|
|
53
|
+
|
|
54
|
+
- `POST /mcp/nodes/{node_id}/executions`
|
|
55
|
+
- `GET /mcp/nodes/{node_id}/executions`
|
|
56
|
+
- `POST /mcp/nodes/{node_id}/executions/{execution_id}/terminate`
|
|
57
|
+
|
|
58
|
+
### Compute catalog
|
|
59
|
+
|
|
60
|
+
- `GET /compute/providers`
|
|
61
|
+
- `GET /compute/offers`
|
|
62
|
+
- `GET /compute/offers/{provider}`
|
|
63
|
+
|
|
64
|
+
### Managed compute and budgets
|
|
65
|
+
|
|
66
|
+
- `GET /mcp/nodes/{node_id}/compute/options`
|
|
67
|
+
- `POST /mcp/nodes/{node_id}/compute/acquire`
|
|
68
|
+
- `GET /mcp/compute/status`
|
|
69
|
+
- `GET /mcp/compute/connection`
|
|
70
|
+
- `POST /mcp/compute/release`
|
|
71
|
+
- `POST /mcp/compute/release-all`
|
|
72
|
+
- `GET /mcp/nodes/{node_id}/budget/grants`
|
|
73
|
+
- `GET /mcp/nodes/{node_id}/budget/campaign-grants`
|
|
74
|
+
- `POST /mcp/nodes/{node_id}/budget/campaign-grants`
|
|
75
|
+
- `PATCH /mcp/nodes/{node_id}/budget/campaign-grants/{budget_grant_id}`
|
|
76
|
+
- `DELETE /mcp/nodes/{node_id}/budget/campaign-grants/{budget_grant_id}`
|
|
77
|
+
|
|
78
|
+
### Sharing, tags, and audit
|
|
79
|
+
|
|
80
|
+
- `GET /mcp/nodes/{node_id}/sharing`
|
|
81
|
+
- `PUT /mcp/nodes/{node_id}/sharing`
|
|
82
|
+
- `POST /mcp/nodes/sharing/bulk`
|
|
83
|
+
- `GET /mcp/nodes/{node_id}/audit`
|
|
84
|
+
- `POST /mcp/nodes/{root_node_id}/tags`
|
|
85
|
+
- `PATCH /mcp/nodes/{root_node_id}/tags/{tag_id}`
|
|
86
|
+
- `DELETE /mcp/nodes/{root_node_id}/tags/{tag_id}`
|
|
87
|
+
- `PUT /mcp/nodes/{node_id}/tags`
|
|
88
|
+
|
|
89
|
+
### Export and summaries
|
|
90
|
+
|
|
91
|
+
- `POST /mcp/export`
|
|
92
|
+
- `POST /mcp/import`
|
|
93
|
+
- `POST /mcp/export-summary`
|
|
94
|
+
- `POST /mcp/export-summary-stream`
|
|
95
|
+
- `POST /mcp/export-summary-pdf`
|
|
96
|
+
- `POST /mcp/export-summary-render-pdf`
|
|
97
|
+
|
|
98
|
+
### Auth and integrations
|
|
99
|
+
|
|
100
|
+
- `GET /auth/status`
|
|
101
|
+
- `GET /auth/accounts`
|
|
102
|
+
- `POST /auth/accounts/merge/source-proof`
|
|
103
|
+
- `POST /auth/accounts/merge/preview`
|
|
104
|
+
- `POST /auth/accounts/merge`
|
|
105
|
+
- `POST /auth/accounts/detach`
|
|
106
|
+
- `GET /auth/integrations/status`
|
|
107
|
+
- `PUT /auth/integrations/wandb`
|
|
108
|
+
- `PUT /auth/integrations/huggingface`
|
|
109
|
+
- `DELETE /auth/integrations/wandb`
|
|
110
|
+
- `DELETE /auth/integrations/huggingface`
|
|
111
|
+
|
|
112
|
+
### Analytics
|
|
113
|
+
|
|
114
|
+
- `POST /analytics/events`
|
|
115
|
+
- `GET /admin/analytics/kpis`
|
|
116
|
+
- `GET /admin/analytics/overview`
|
|
117
|
+
|
|
118
|
+
## MCP Tool Surface
|
|
119
|
+
|
|
120
|
+
### Discovery and sharing tools
|
|
121
|
+
|
|
122
|
+
- `flywheel_auth_status`
|
|
123
|
+
- `flywheel_get_credits_balance`
|
|
124
|
+
- `flywheel_list_nodes`
|
|
125
|
+
- `flywheel_get_node`
|
|
126
|
+
- `flywheel_get_node_tree`
|
|
127
|
+
- `flywheel_get_node_sharing`
|
|
128
|
+
- `flywheel_set_node_sharing`
|
|
129
|
+
- `flywheel_bulk_set_node_sharing`
|
|
130
|
+
- `flywheel_create_node_tag`
|
|
131
|
+
- `flywheel_update_node_tag`
|
|
132
|
+
- `flywheel_delete_node_tag`
|
|
133
|
+
- `flywheel_set_node_tag_assignments`
|
|
134
|
+
|
|
135
|
+
### Node and graph tools
|
|
136
|
+
|
|
137
|
+
- `flywheel_stage_node_create`
|
|
138
|
+
- `flywheel_stage_node_update`
|
|
139
|
+
- `flywheel_commit_node`
|
|
140
|
+
- `flywheel_branch_node`
|
|
141
|
+
- `flywheel_merge_nodes`
|
|
142
|
+
- `flywheel_delete_node`
|
|
143
|
+
- `flywheel_bulk_delete_nodes`
|
|
144
|
+
|
|
145
|
+
### Artifact tools
|
|
146
|
+
|
|
147
|
+
- `flywheel_prepare_artifact_uploads`
|
|
148
|
+
- `flywheel_finalize_artifact_uploads`
|
|
149
|
+
- `flywheel_list_artifacts`
|
|
150
|
+
- `flywheel_get_artifact`
|
|
151
|
+
- `flywheel_get_artifact_preview`
|
|
152
|
+
- `flywheel_delete_artifact`
|
|
153
|
+
|
|
154
|
+
### Execution tools
|
|
155
|
+
|
|
156
|
+
- `flywheel_launch_execution`
|
|
157
|
+
- `flywheel_list_executions`
|
|
158
|
+
- `flywheel_terminate_execution`
|
|
159
|
+
|
|
160
|
+
### Compute lease and budget tools
|
|
161
|
+
|
|
162
|
+
- `flywheel_compute_list_options`
|
|
163
|
+
- `flywheel_request_compute_grant_approval`
|
|
164
|
+
- `flywheel_list_compute_grants`
|
|
165
|
+
- `flywheel_compute_acquire`
|
|
166
|
+
- `flywheel_compute_status`
|
|
167
|
+
- `flywheel_compute_connection`
|
|
168
|
+
- `flywheel_compute_release`
|
|
169
|
+
- `flywheel_compute_release_all`
|
|
170
|
+
|
|
171
|
+
### Campaign budget tools
|
|
172
|
+
|
|
173
|
+
- `flywheel_list_campaign_budgets`
|
|
174
|
+
- `flywheel_create_campaign_budget`
|
|
175
|
+
- `flywheel_update_campaign_budget`
|
|
176
|
+
- `flywheel_revoke_campaign_budget`
|
|
177
|
+
|
|
178
|
+
### Contract, audit, and export tools
|
|
179
|
+
|
|
180
|
+
- `flywheel_get_contract`
|
|
181
|
+
- `flywheel_list_audit`
|
|
182
|
+
- `flywheel_summarize_node_tree`
|
|
183
|
+
- `flywheel_export_subgraph`
|
|
184
|
+
- `flywheel_import_subgraph`
|
|
185
|
+
- `flywheel_export_summary`
|
|
186
|
+
- `flywheel_export_summary_stream`
|
|
187
|
+
- `flywheel_export_summary_pdf`
|
|
188
|
+
- `flywheel_export_summary_render_pdf`
|
|
189
|
+
|
|
190
|
+
## Legacy Archival Export
|
|
191
|
+
|
|
192
|
+
Experimental settings keep legacy history export available as an archival
|
|
193
|
+
migration aid. This path is read-only and outside canonical node workflows.
|
|
194
|
+
|
|
195
|
+
## Related Docs
|
|
196
|
+
|
|
197
|
+
- `docs/flywheel/CONCEPT.md`
|
|
198
|
+
- `docs/flywheel/FLYWHEEL_MCP.md`
|
|
199
|
+
- `docs/flywheel/PROVISIONING.md`
|
|
200
|
+
- `docs/flywheel/ARTIFACTS.md`
|
|
201
|
+
- `docs/flywheel/GIT_INTEGRATION.md`
|