registrystack / registrystack/registry-stack
Epic: First-class editor support for Registry Stack project authoring
- Lingua principale
- Rust
- Stelle
- 2
- Fork
- 0
- Merge medio
- 2h 55m
- PR unite (30g)
- 130
Descrizione
## 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.
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
Leggi il piano di rilascio e la catena delle dipendenze, in particolare #393, #395, #397 e #398, quindi esamina i cinque JSON Schemas esistenti di project-authoring e la configurazione standard di YAML language-server descritta per 1.0. Il lavoro è completato quando sia VS Code sia Zed utilizzano gli strumenti condivisi e compatibili con la versione, con un’editing utile, diagnostica precisa, navigazione sicura dei riferimenti e installazione e risoluzione dei problemi documentate.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- rust, vscode, yaml
- Ambito
- developer-experience, devtools, tooling
- Tipo di issue
- Funzionalità
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Stato di attività
- Tranquilla
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 25/100