mirror of
https://github.com/nexu-io/open-design.git
synced 2026-10-27 09:51:12 +01:00
Cursor AgentandTom Huang
cfdc79f859
Plan N4 / spec §10.1 / §23.3.3.
Lands one bundled `od.kind: 'scenario'` plugin per taskKind enum
value under plugins/_official/scenarios/. The daemon's bundled
boot walker (§3.I3) already registers them via the existing
'tier/<id>' layout, so no changes to bundled.ts.
Four scenarios:
od-new-generation discovery → plan → generate → critique (devloop)
od-figma-migration extract → tokens → generate → critique (devloop)
declares od.connectors.required: [{id:'figma'}]
so the daemon auto-derives the figma-oauth
surface at apply time
od-code-migration import → tokens → plan
→ verify (patch-edit ↔ build-test devloop, until
'build.passing && tests.passing || iterations>=8')
→ review → handoff
od-tune-collab direction → patch → critique (devloop) → handoff
Locks the spec §23.3.3 patch 3 contract: 'no od.pipeline + has
taskKind → look up the bundled scenario plugin'. The daemon-side
resolver wiring is the next PR; the substrate is in place so a
plugin author who omits the pipeline gets a deterministic default.
Daemon tests: 1543 → 1548 (+5 cases on
plugins-bundled-scenarios-roster: roster shape + per-scenario
taskKind / kind / pipeline-stage-id assertions). The atom roster
test from §3.M3+M4 stays focused on plugins/_official/atoms/.
Co-authored-by: Tom Huang <1043269994@qq.com>
1.5 KiB
1.5 KiB
name, description, od
| name | description | od | ||||
|---|---|---|---|---|---|---|
| od-code-migration | Default reference pipeline for the code-migration taskKind — code-import → design-extract → token-map → rewrite-plan → patch-edit ↔ build-test devloop → diff-review → handoff. |
|
od-code-migration (scenario)
Spec §1 / §10.1 / §20.3 / §21.3.2 / §23.3.3: the canonical
code-migration flow. The pipeline cannot ship an accept decision
without a passing build — the patch-edit ↔ build-test devloop is
the convergence engine.
Default pipeline
{
"stages": [
{ "id": "import", "atoms": ["code-import"] },
{ "id": "tokens", "atoms": ["design-extract", "token-map"] },
{ "id": "plan", "atoms": ["rewrite-plan"] },
{
"id": "verify",
"atoms": ["patch-edit", "build-test"],
"repeat": true,
"until": "(build.passing && tests.passing) || iterations>=8"
},
{ "id": "review", "atoms": ["diff-review"] },
{ "id": "handoff", "atoms": ["handoff"] }
]
}
The scenario uses build.passing && tests.passing as the
convergence signal — promoted into the spec §22.4 vocabulary by
the build-test atom.
Required user inputs
A plugin built on this scenario typically declares od.inputs:
repoPath(string, required): pulled fromod project import.targetStack(form): collected byrewrite-plan.testCommand/buildCommand(string, optional): overrides the inferred package.json scripts in thebuild-testatom.