registrystack / registrystack/registry-stack
Epic: First-class editor support for Registry Stack project authoring
- Vorherrschende Sprache
- Rust
- Sterne
- 2
- Forks
- 0
- Ø Merge
- 2 Std. 55 Min.
- Gemergte PRs (30 T.)
- 130
Beschreibung
## Outcome
Registry Stack project YAML has first-class editing support in VS Code and Zed, beginning with a schema-driven 1.0 demo baseline and growing into one shared semantic language server. The editor packages remain thin and do not duplicate the project compiler, security rules, or released Rhai/CEL surface.
## Release plan
### 1.0: useful demo baseline
- [x] #394
The 1.0 scope uses the five existing project-authoring JSON Schemas with the editors' normal YAML language servers. It delivers validation, completion, hover documentation, and outlining without waiting for custom semantic tooling.
### 1.2: shared semantic tooling
- [x] #396
- [x] #401
- [x] #393
- [ ] #395
- [ ] #397
- [ ] #398
## Dependency order
```text
#394 schema-driven baseline (1.0)
#396 structured diagnostics and editor metadata
#401 span-preserving authoring YAML parsing
-> #393 shared Registry Stack language server
-> #395 VS Code extension
-> #397 Zed extension
-> #398 references, safe rename, and embedded Rhai/CEL assistance
```
#396 and #401 can proceed in parallel; #393 depends on both. The VS Code and Zed packaging issues can proceed in parallel once the shared language-server contract and MVP are stable.
## Design constraints
- Use the exact schemas, diagnostics, and expression metadata from the selected Registry Stack or `registryctl` release.
- Do not bind editor behavior to a mutable branch or silently mix incompatible versions.
- Preserve normal YAML editing and avoid claiming unrelated YAML files.
- Keep the compiler's trust-boundary checks, bounded paths, and secret handling intact.
- Do not read secret values, execute project scripts, perform live tests, or make source-registry network requests as a side effect of editing.
- Share semantic behavior through LSP instead of implementing it separately in VS Code and Zed.
- Verify a clean developer journey in both editors, separately from protocol and security tests.
## Success criteria
- [ ] A 1.0 demo project gets useful schema-driven editing in VS Code and Zed through a short deterministic setup.
- [ ] Cross-file paths and project-local references navigate correctly through the shared LSP.
- [ ] Invalid syntax and semantic references produce precise, structured diagnostics.
- [ ] Both editor integrations use the same language server and version compatibility contract.
- [ ] Published extension installation, binary discovery, troubleshooting, and release ownership are documented.
- [ ] Advanced rename and expression support never executes authored code or weakens project validation.
Beitragsleitfaden
Rechercherichtung
Lies den Release-Plan und die Abhängigkeitskette, insbesondere #393, #395, #397 und #398, und prüfe anschließend die fünf vorhandenen project-authoring JSON Schemas sowie das normale YAML language-server-Setup, das für 1.0 beschrieben ist. Abgeschlossen ist die Arbeit, wenn sowohl VS Code als auch Zed die gemeinsam genutzten, versionskompatiblen Tools mit nützlicher Bearbeitung, präzisen Diagnosen, sicherer Referenznavigation sowie dokumentierter Installation und Fehlerbehebung verwenden.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- rust, vscode, yaml
- Bereich
- developer-experience, devtools, tooling
- Issue-Typ
- Feature
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Ruhig
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 25/100